PASARELA BLUETOOTH/GPRS PARA DISPOSITIVOS MVILES

Antonio ngel Botella Galindo 21 de junio de 2007

ndice general
1. Introduccin 2. Descripcin del sistema 2.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. mbito del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. iBAN del paciente . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2. Terminales mviles para recepcin de alarmas . . . . . . . . . . . 2.3. Estructura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. Subsistemas del software del NI . . . . . . . . . . . . . . . . . . . 2.3.1.1. 2.3.1.2. 2.3.1.3. 2.3.1.4. Mdulo de comunicaciones Bluetooth . . . . . . . . . . Mdulo de comunicaciones con el SCC . . . . . . . . . . Mdulo de gestin de comandos y control . . . . . . . . Mdulo de procesamiento y gestin de alarmas . . . . . . 1 3 3 5 5 7 8 8 8 9 9 10 10 11 13 13 13 13 15 15 16 16 16 17 17

2.3.2. Subsistemas del software de recepcin y noticacin de alarmas en terminales mviles . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3. Aplicacin web para la descarga de MIDlets . . . . . . . . . . . . . 3. Tecnologas implicadas 3.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Tecnologas de Comunicacin . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2. Tecnologas de comunicaciones mviles . . . . . . . . . . . . . . . 3.2.2.1. 3.2.2.2. 3.2.2.3. 3.2.2.4. GSM . . . . . . . . . . . . . . . . . . . . . . . . . . .

GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.3. WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Sistemas operativos para telfonos mviles . . . . . . . . . . . . . . . . .

I

3.3.1. El sistema operativo Symbian OS . . . . . . . . . . . . . . . . . . 3.3.2. Otros sistemas operativos utilizados en telfonos mviles . . . . . . 3.4. Lenguajes de Programacin . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2. J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5. Lenguaje Unicado de Modelado (UML) . . . . . . . . . . . . . . . . . . 3.6. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1. Eclipse SDK (Software Development Kit) . . . . . . . . . . . . . . 3.6.2. Carbide.j (Nokia Developers Suite for J2ME) . . . . . . . . . . . . 3.6.3. NCF (Nokia Connectivity Framework) . . . . . . . . . . . . . . .

17 18 18 18 19 21 21 22 23 24 29 33 34 37 40 43 43 44 44 44 46 47 47 47 49 49 49 50 52 59 63 63

3.6.4. Nokia PC Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.5. Sun Java Wireless Toolkit for CLDC . . . . . . . . . . . . . . . . . 3.6.6. Ethereal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Dispositivos Hardware utilizados 4.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Dispositivos Hardware utilizados para el desarrollo de la aplicacin del NI . 4.2.1. Telfono Nokia 9500 (Serie 80 2a Edicin) . . . . . . . . . . . . . 4.2.2. Telfono Nokia N93 (Serie 60 3a Edicin) . . . . . . . . . . . . . . 4.2.3. Telfono Nokia E61 (Serie 60 3a Edicin) . . . . . . . . . . . . . . 4.2.4. Telfono Nokia N70 (Serie 60 2a Edicin, Feature Pack 3) . . . . . 4.2.5. Telfono Nokia 6680 (Serie 60 2a Edicin, Feature Pack 2) . . . . . 4.2.6. Telfono Nokia 6230 (Serie 40 2a Edicin) . . . . . . . . . . . . . 4.2.7. Telfono Sony-Ericsson K608i . . . . . . . . . . . . . . . . . . . . 4.2.8. Pulsioxmetro Nonin 4100 . . . . . . . . . . . . . . . . . . . . . . 4.2.8.1. 4.2.8.2. 4.2.8.3. Qu es la pulsioximetra? . . . . . . . . . . . . . . . . . Cmo se mide el SPO2? . . . . . . . . . . . . . . . . . Pulsioxmetro Nonin 4100 . . . . . . . . . . . . . . . . .

4.2.9. GPS Leadtek 9553X . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Dispositivos Hardware utilizados para el desarrollo de la aplicacin de recepcin y aviso de alarmas . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. Dispositivos Hardware utilizados para el desarrollo de la aplicacin web para la descarga de MIDlets . . . . . . . . . . . . . . . . . . . . . . . . . . . .
II

5. Desarrollo del software del Nodo Inteligente 5.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2. Desarrollo software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1. Lenguaje de programacin . . . . . . . . . . . . . . . . . . . . . . 5.2.2. Filosofa de diseo . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2.1. 5.2.2.2. Modelo de Ingeniera del Software . . . . . . . . . . . . Patrn de Diseo software . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73 73 73 73 74 74 75 76 78 78 78 92 93 93 101 109 109 109 111 111 111 114 117 121 121 121 121 122 122 122 123 125 131 131

5.2.3. Anlisis de la aplicacin del Nodo Inteligente

5.2.4. Subsistema de comunicaciones Bluetooth . . . . . . . . . . . . . . 5.2.4.1. 5.2.4.2. 5.2.4.3. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . Diseo software . . . . . . . . . . . . . . . . . . . . . . Funcionamiento . . . . . . . . . . . . . . . . . . . . . .

5.2.5. Subsistema de comunicaciones con el SCC . . . . . . . . . . . . . 5.2.5.1. 5.2.5.2. 5.2.5.3. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . Diseo software . . . . . . . . . . . . . . . . . . . . . . Funcionamiento . . . . . . . . . . . . . . . . . . . . . .

5.2.6. Subsistema de gestin de comandos y control . . . . . . . . . . . . 5.2.6.1. 5.2.6.2. Diseo software . . . . . . . . . . . . . . . . . . . . . . Funcionamiento . . . . . . . . . . . . . . . . . . . . . .

5.2.7. Subsistema de procesamiento y gestin de alarmas . . . . . . . . . 5.2.7.1. 5.2.7.2. Diseo software . . . . . . . . . . . . . . . . . . . . . . Funcionamiento . . . . . . . . . . . . . . . . . . . . . .

5.2.8. Implementacin del patrn de diseo MVC . . . . . . . . . . . . . 6. Desarrollo del software de recepcin y noticacin de alarmas 6.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Desarrollo del software de recepcin y noticacin de alarmas . . . . . . . 6.2.1. Lenguaje de programacin . . . . . . . . . . . . . . . . . . . . . . 6.2.2. Anlisis de la aplicacin de recepcin y noticacin de alarmas . . 6.2.3. Subsistema de recepcin de mensajes SMS/MMS . . . . . . . . . . 6.2.3.1. 6.2.3.2. 6.2.3.3. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . Diseo software . . . . . . . . . . . . . . . . . . . . . . Funcionamiento . . . . . . . . . . . . . . . . . . . . . .

7. Desarrollo de la aplicacin web para la descarga de MIDlets 7.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

III

7.2. Lenguajes de programacin y herramientas utilizadas . . . . . . . . . . . . 7.3. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4. Diseo software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Manual de instalacin y usuario 8.1. Manual de instalacin de los MIDlets desarrollados . . . . . . . . . . . . . 8.1.1. Requisitos de instalacin . . . . . . . . . . . . . . . . . . . . . . . 8.1.2. Proceso de instalacin . . . . . . . . . . . . . . . . . . . . . . . . 8.1.3. Instalacin mediante el envo directo de la aplicacin al terminal destino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.4. Instalacin mediante la herramienta propietaria del fabricante del telfono destino . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.5. Instalacin mediante la aplicacin web para la descarga de MIDlets 8.2. Manual de instalacin de la aplicacin web para la descarga de MIDlets . . 8.2.1. Requisitos de instalacin . . . . . . . . . . . . . . . . . . . . . . . 8.2.2. Proceso de instalacin . . . . . . . . . . . . . . . . . . . . . . . . 8.3. Manual de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1. Manual de usuario de la aplicacin del Nodo Inteligente . . . . . . 8.3.2. Manual de usuario de la aplicacin de recepcin y noticacin de alarmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Pruebas realizadas 9.1. Software del Nodo Inteligente . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1. Pruebas de funcionalidad . . . . . . . . . . . . . . . . . . . . . . . 9.1.1.1. 9.1.1.2. 9.1.1.3. 9.1.1.4. Subsistema de comunicaciones Bluetooth . . . . . . . . . Subsistema de comunicaciones con el SCC . . . . . . . . Subsistema de gestin de comandos y control . . . . . . Subsistema de procesamiento y gestin de alarmas . . . .

131 131 132 133 135 135 135 135 136 140 140 143 143 143 144 144 148 151 151 151 151 156 157 158 159 159 163 163 164 165 165 167

9.1.2. Pruebas de integracin del NI con el SCC . . . . . . . . . . . . . . 9.1.3. Pruebas de jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.4. Pruebas de medida de la batera del telfono Nokia N93 . . . . . . 9.2. Software de recepcin y noticacin de alarmas . . . . . . . . . . . . . . . 9.3. Aplicacin web para la descarga de MIDlets . . . . . . . . . . . . . . . . . 10. Conclusiones y lneas futuras 10.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2. Lneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IV

A. Terminologa relacionada con Java B. Principales Java Specication Request de J2ME C. Plataformas de telfonos mviles Nokia D. Protocolo de comunicacin entre el NI y el SCC D.1. Paquetes del protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.1.1. Paquete de identicacin de paciente . . . . . . . . . . . . . . . . D.1.2. Paquete de envo de comandos . . . . . . . . . . . . . . . . . . . . D.1.3. Paquete de envo de datos . . . . . . . . . . . . . . . . . . . . . . D.1.4. Paquete de indicacin/respuesta . . . . . . . . . . . . . . . . . . . D.1.5. Paquete de indicacin del puerto UDP . . . . . . . . . . . . . . . . D.2. Formato de las tramas GPS a recibir en el SCC . . . . . . . . . . . . . . .

183 187 191 195 195 195 196 197 198 198 199

VI

ndice de guras
2.1. Sistema de monitorizacin inalmbrica de pacientes. . . . . . . . . . . . . 2.2. mbito de los proyectos realizados por Antonio ngel Botella Galindo y Emilio Jess Cuberos Jimnez, respecto al sistema de la gura 2.1. . . . . . 2.3. iBAN desarrollada en este Proyecto Fin de Carrera. . . . . . . . . . . . . . 2.4. Envo de alarmas desde el NI a los familiares del paciente. . . . . . . . . . 3.1. Arquitectura de Bluetooth v1.1. Fuente: [11]. . . . . . . . . . . . . . . . . 3.2. Arquitectura Java. Fuente: [36]. . . . . . . . . . . . . . . . . . . . . . . . 3.3. Arquitectura de Eclipse SDK [55]. . . . . . . . . . . . . . . . . . . . . . . 3.4. Vistas y perspectivas de Eclipse. . . . . . . . . . . . . . . . . . . . . . . . 3.5. Perspectiva Java de Eclipse. . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6. Perspectiva Debug de Eclipse. . . . . . . . . . . . . . . . . . . . . . . . . 3.7. Editor Java y algunos servicios del JDT. . . . . . . . . . . . . . . . . . . . 3.8. Pestaa de creacin/edicin de los cheros .JAR y .JAD, en Carbide.j 1.5. . 3.9. Emuladores de la Serie 80, Serie 60 y Serie 40 de Nokia, que incorpora Carbide.j 1.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10. Aspecto de la ventana principal del programa Nokia Connectivity Framework 1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11. Escenario de test con un emulador de la Serie 60 y un adaptador USB Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.12. Ventana principal del programa PC Suite 6.8. . . . . . . . . . . . . . . . . 3.13. Instalacin de un programa J2ME, en un telfono Nokia N70, mediante PC Suite 6.8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14. Panel de utilidades, en Sun Java Wireless Toookit 2.5 for CLDC Beta 2. . . 3.15. Ventana de seleccin de API del proyecto BluetoothDemo en Sun Java Wireless Toolkit 2.5 for CLDC Beta 2. . . . . . . . . . . . . . . . . . . . . 3.16. Instancias de emulador que se comunican entre s. . . . . . . . . . . . . . . 3.17. Ejemplo de anlisis de un paquete HTTP, en Ethereal 0.10.14. . . . . . . . 4.1. Telfono Nokia 9500. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VII

4 5 6 8 16 19 24 27 27 28 28 31 32 34 35 36 37 39 39 40 41 44

4.2. Telfono Nokia N93. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Telfono Nokia E61. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4. Telfono Nokia N70. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5. Telfono Nokia 6680. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Telfono Nokia 6230. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7. Telfono Sony-Ericsson K608i. . . . . . . . . . . . . . . . . . . . . . . . . 4.8. Pulsioxmetro de Aoyagi [99]. . . . . . . . . . . . . . . . . . . . . . . . . 4.9. LEDs y fotodetector de un pulsioxmetro. . . . . . . . . . . . . . . . . . . 4.10. Posibles sensores usados en pulsioximetra. . . . . . . . . . . . . . . . . . 4.11. Pulsioxmetro Nonin 4100. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12. Modos de funcionamiento del pulsioxmetro Nonin 4100 [114]. . . . . . . . 4.13. Formato de los paquetes de Modo 1 [114]. . . . . . . . . . . . . . . . . . . 4.14. Formato de los paquetes de Modo 2 [114]. . . . . . . . . . . . . . . . . . . 4.15. Bits del byte de estado, en el Modo 2. . . . . . . . . . . . . . . . . . . . . 4.16. Estructura genrica de los bytes HR-MSB, HR-LSB y SPO2. . . . . . . . . 4.17. Ejemplo de establecimiento del modo de funcionamiento, en el Nonin 4100. 4.18. GPS Leadtek 9553X. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.19. Sentencias NMEA-0183, en situaciones con cobertura y sin cobertura GPS. 5.1. Fases que componen cada ciclo del modelo incremental. . . . . . . . . . . 5.2. Patrn de diseo Modelo-Vista-Controlador (MVC). . . . . . . . . . . . . 5.3. Diagrama de actividad que muestra la interaccin entre los elementos del patrn MVC, en una aplicacin software del juego del ajedrez. . . . . . . . 5.4. Diagrama de componentes que representa los mdulos que integran el software del NI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5. Diagrama de componentes del mdulo de comunicaciones Bluetooth. . . . 5.6. Diseo software de cada uno de los componentes del mdulo de comunicaciones Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7. Diagrama de clases del componente para la bsqueda de dispositivos (Inquiry process) y de servicios (Service Discovery process) Bluetooth. . . 5.8. Diagrama de clases del componente para la comunicacin Bluetooth. . . . . 5.9. Diagrama de clases del componente para la comunicacin con el pulsioxmetro Nonin 4100. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.10. Diagrama de clases del componente para la comunicacin con el GPS. Clases principales asociadas al uso de las interfaces JSR-82 y JSR-179 y otras clases de uso general. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VIII

46 46 47 48 48 49 51 52 52 53 54 55 56 57 58 60 61 62 74 76 77 77 79 80 81 83 85

89

5.11. Diagrama de clases del componente para la comunicacin con el GPS. Clases asociadas al uso de la interfaz JSR-179. . . . . . . . . . . . . . . . . . . . 5.12. Diagrama de actividad que detalla las tareas que se realizan dentro del subsistema de comunicaciones Bluetooth. . . . . . . . . . . . . . . . . . . 5.13. Diagrama de secuencia que muestra la inicializacin de un objeto de la clase Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.14. Diagrama de secuencia que reeja el proceso de bsqueda de dispositivos Bluetooth (Inquiry process). . . . . . . . . . . . . . . . . . . . . . . . . . 5.15. Diagrama de secuencia que reeja el proceso de bsqueda de servicios Bluetooth (Service Discovery process). . . . . . . . . . . . . . . . . . . . . 5.16. Diagrama de secuencia que ilustra el proceso de conexin con los dispositivos de la iBAN, a travs del mtodo initiateComms(). . . . . . . . . . . . 5.17. Diagrama de secuencia que muestra el proceso de lectura de datos procedentes del pulsioxmetro Nonin 4100. . . . . . . . . . . . . . . . . . 5.18. Diagrama de secuencia que muestra el proceso de lectura de datos procedentes del GPS Leadtek 9553X, mediante el uso de la interfaz JSR179 (Location API). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.19. Diagrama de componentes del mdulo de comunicaciones con el SCC. . . . 5.20. Diseo software de cada uno de los componentes del mdulo de comunicaciones con el SCC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.21. Diagrama de clases del componente para la implementacin del protocolo de comunicacin entre el NI y el SCC. . . . . . . . . . . . . . . . . . . . . . 5.22. Diagrama de clases del componente para la comunicacin HTTP. . . . . . . . .

90 94 95 96 97 98 99

100 101 102 104 105 107 107 108 109 110 112 113 115 116 118 119

5.23. Diagrama de clases del componente para la comunicacin TCP/UDP.

5.24. Diagrama de clases del componente para el cifrado de datos. . . . . . . . . 5.25. Diagrama de clases del componente gestor de datos. . . . . . . . . . . . . . 5.26. Diagrama de clases del componente gestor de indicaciones/respuestas. . . . 5.27. Diagrama de secuencia que reeja el funcionamiento del mdulo de comunicaciones con el SCC. . . . . . . . . . . . . . . . . . . . . . . . . . 5.28. Diagrama de clases del subsistema de gestin de comandos y control. . . . 5.29. Diagrama de secuencia que explica el funcionamiento del mdulo de gestin de comandos y control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.30. Diagrama de clases del subsistema de procesamiento y gestin de alarmas. . 5.31. Diagrama de secuencia que explica el funcionamiento del mdulo de procesamiento y gestin de alarmas. . . . . . . . . . . . . . . . . . . . . . 5.32. Clases que implementan el patrn de diseo MVC en la aplicacin del NI. . 5.33. Diagrama de secuencia que muestra el funcionamiento de la aplicacin del NI (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IX

5.34. Diagrama de secuencia que muestra el funcionamiento de la aplicacin del NI (II). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1. Ciclo de vida y activacin de MIDlets desarrollados con MIDP 2.0 [145]. . 6.2. Estructura de la aplicacin de recepcin y noticacin de alarmas. . . . . . 6.3. Diseo software del subsistema de recepcin de mensajes SMS/MMS. . . . 6.4. Diagrama de clases del subsistema de recepcin de mensajes SMS/MMS. . 6.5. Diagrama de actividad: Funcionamiento de la aplicacin de recepcin y noticacin de alarmas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6. Diagrama de secuencia: Funcionamiento de la aplicacin de recepcin y noticacin de alarmas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.7. Diagrama de secuencia: Tratamiento de las opciones del usuario en la aplicacin de recepcin y noticacin de alarmas. . . . . . . . . . . . . . 7.1. Estructura de la aplicacin web para la descarga de MIDlets. . . . . . . . . 7.2. Diseo software de los subsistemas de la aplicacin para la descarga de MIDlets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3. Diagrama de actividad: Funcionamiento de la aplicacin web para la descarga de MIDlets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1. Enviar un archivo, a un dispositivo, a travs de Bluetooth. . . . . . . . . . . 8.2. Examinar dispositivos Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . 8.3. Seleccionar dispositivo Bluetooth. . . . . . . . . . . . . . . . . . . . . . . 8.4. Iniciar transferencia de chero. . . . . . . . . . . . . . . . . . . . . . . . . 8.5. Peticin para recibir el chero. . . . . . . . . . . . . . . . . . . . . . . . . 8.6. Apertura del mensaje recibido, que adjunta el MIDlet. . . . . . . . . . . . . 8.7. Peticin para ejecutar la instalacin del MIDlet. . . . . . . . . . . . . . . . 8.8. Motorola Phone Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.9. Navegador web del telfono Nokia N93. . . . . . . . . . . . . . . . . . . . 8.10. Pantalla principal de la aplicacin web para la descarga de MIDlets. . . . . 8.11. Pantalla de descarga. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.12. Peticin para ejecutar la instalacin del MIDlet. . . . . . . . . . . . . . . . 8.13. Icono de la aplicacin del Nodo Inteligente. . . . . . . . . . . . . . . . . . 8.14. Pantalla de Inquiry de la aplicacin del Nodo Inteligente. . . . . . . . . . . 8.15. Pantalla de ServiceDiscovery de la aplicacin del Nodo Inteligente. . . . . .

120 123 124 126 127 128 129 130 132 133 134 137 137 138 138 139 139 139 140 141 142 142 143 144 145 146

8.16. Pantalla de log y representacin de datos de la aplicacin del Nodo Inteligente.146 8.17. Icono de la aplicacin de recepcin y noticacin de alarmas SMS. . . . . . 8.18. Pantalla de espera de alarmas SMS entrantes. . . . . . . . . . . . . . . . .
X

148 149

8.19. Pantalla de representacin de alarmas SMS. . . . . . . . . . . . . . . . . . 9.1. Fichero de traza donde se han almacenado paquetes de datos en Modo 1. . . 9.2. Fichero de traza donde se han almacenado paquetes de datos en Modo 2. . . 9.3. Valores de jitter para tiempo de monitorizacin de 1 segundo. . . . . . . . . 9.4. Valores de jitter para tiempo de monitorizacin de 10 segundos. . . . . . . 9.5. Histograma del jitter con tiempo de monitorizacin de 1 segundo. . . . . . 9.6. Histograma del jitter con tiempo de monitorizacin de 10 segundos. . . . . D.1. Paquete de identicacin de paciente [4]. . . . . . . . . . . . . . . . . . . D.2. Paquete de envo de un comando [4]. . . . . . . . . . . . . . . . . . . . . . D.3. Paquete de envo de datos [4]. . . . . . . . . . . . . . . . . . . . . . . . . D.4. Paquete de indicacin/respuesta [4]. . . . . . . . . . . . . . . . . . . . . . D.5. Paquete de puerto UDP [4]. . . . . . . . . . . . . . . . . . . . . . . . . . .

149 155 155 161 161 162 162 196 197 197 198 199

XI

XII

ndice de tablas
4.1. Caractersticas del telfono Nokia 9500 [82]. . . . . . . . . . . . . . . . . 4.2. Caractersticas del telfono Nokia N93 [79]. . . . . . . . . . . . . . . . . . 4.3. Caractersticas del telfono Nokia E61 [85]. . . . . . . . . . . . . . . . . . 4.4. Caractersticas del telfono Nokia N70 [87]. . . . . . . . . . . . . . . . . . 4.5. Caractersticas del telfono Nokia 6680 [89]. . . . . . . . . . . . . . . . . 4.6. Caractersticas del telfono Nokia 6230 [91]. . . . . . . . . . . . . . . . . 4.7. Caractersticas del telfono Sony-Ericsson K608i [93][94]. . . . . . . . . . 4.8. Caractersticas principales del pulsioxmetro Nonin 4100 [114]. . . . . . . 4.9. Caractersticas principales del GPS Leadtek 9553X [124]. . . . . . . . . . . 4.10. Anlisis de una sentencia $GPGGA. . . . . . . . . . . . . . . . . . . . . . 4.11. Anlisis de una sentencia $GPRMC. . . . . . . . . . . . . . . . . . . . . . 8.1. Descripcin de los valores monitorizados por el pulsioxmetro Nonin 4100 que aparecen en la gura 8.16 [114]. . . . . . . . . . . . . . . . . . . . . . 9.1. Errores Symbian presentados por el telfono Nokia 9500 durante la comunicacin SPP de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . B.1. Principales JSR relacionadas con CDC y sus perles [40]. . . . . . . . . . . B.2. Principales JSR relacionadas con CLDC y MIDP [76][40] (I). . . . . . . . 45 64 65 66 67 68 69 69 70 71 72

147

154 187 188

B.3. Principales JSR relacionadas con CLDC y MIDP [76][40] (II) (continuacin). 189 C.1. Principales caractersticas de los telfonos Nokia de la Serie 40 [169][171] (I).191 C.2. Principales caractersticas de los telfonos Nokia de la Serie 40 [169][171] (II) (continuacin). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.3. Principales caractersticas de los telfonos Nokia de la Serie 60 [169][170][172]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.4. Principales caractersticas de los telfonos Nokia de la Serie 80 [169][173]. 192 193 194

XIII

XIV

Captulo 1 Introduccin
La monitorizacin de pacientes con sensores cableados, que es todava una prctica normal en hospitales y centros mdicos, tiene como principal inconveniente la reduccin de la movilidad del paciente y la consecuente disminucin de su calidad de vida. El concepto de e-health o aplicacin de las tecnologas de la informacin al campo de la salud, representa una alternativa y es una solucin para la monitorizacin a distancia de pacientes (Telemedicine) [1].Gracias al desarrollo de la microelectrnica (aumento de la capacidad de integracin) y a la aparicin e implantacin de nuevas tecnologas inalmbricas como Bluetooth, WiFi (Wireless Fidelity), etc., es cada vez ms factible la creacin e implantacin de este tipo de sistemas de monitorizacin a distancia, cuyo n es mejorar la vida de los pacientes sin degradar la calidad en la supervisin de su salud. El presente Proyecto Fin de Carrera se encuadra dentro del mbito de la e-health. El objetivo principal es la realizacin de un software capaz de concentrar la informacin de monitorizacin procedente de varios dispositivos electrnicos, portados por un paciente, y enviarla a un sistema externo encargado de gestionarla. Adems, este software debe ser capaz de interpretar los datos del paciente monitorizado con el n de generar alertas en situaciones crticas. Por otro lado, tambin es objetivo de este proyecto el desarrollo de un software adicional, para familiares del paciente, que se encargue de la recepcin y de la noticacin de estas alertas. Esta memoria cubre los aspectos ms destacados del estudio y trabajo llevados a cabo durante la realizacin del presente Proyecto Fin de Carrera, por lo que ha sido dividida y estructurada en una serie de captulos, con el n de facilitar al lector su comprensin y su seguimiento. A continuacin, siguiendo el orden de esta memoria, se describir brevemente el contenido de cada uno de ellos. La descripcin del sistema en el que se enmarca este proyecto, introduciendo de forma 1

concisa el software que se ha desarrollado, se presenta en el captulo 2. En los captulos 3 y 4 se hace un repaso todas las tecnologas (tecnologas de comunicacin, lenguajes de programacin, herramientas de desarrollo, etc.) y dispositivos hardware (telfonos mviles, sensores, etc.), respectivamente, que se han utilizado en la ejecucin del proyecto. Para cada tecnologa y dispositivo hardware se efecta un anlisis tcnico, resaltando sus principales caractersticas. La estructura, el diseo y el funcionamiento del software desarrollado en el presente Proyecto Fin de Carrera se detalla en los captulos 5, 6 y 7. En el captulo 5 se aborda el software de monitorizacin de pacientes que constituye el ncleo de este proyecto. La aplicacin para la recepcin y noticacin de alarmas se estudia en el captulo 6, siguiendo una estructura similar a la del captulo 5. Adems, se ha creado una aplicacin web para la instalacin del software objetivo (captulos 5 y 6) que se describe en el captulo 7. Para la instalacin y la utilizacin de las aplicaciones detalladas en los captulos 5, 6 y 7 se ha incluido un manual de instalacin y de usuario, de cada una de ellas, en el captulo 8 de esta memoria. Una descripcin de todas la pruebas realizadas durante el desarrollo software de las aplicaciones diseadas en este Proyecto Fin de Carrera se incluye en el captulo 9, mientras que en el captulo 10 se exponen las principales conclusiones extradas de la realizacin del proyecto y se indican posibles lneas de trabajo futuras. Por ltimo, hay que aadir que al nal de la memoria se han adjuntado una serie de apndices, que complementan la informacin incluida en alguno de los captulos anteriormente sealados.

Captulo 2 Descripcin del sistema

2.1. Introduccin

Las personas que sufren enfermedades o afecciones que requieren una atencin continua por parte de sus familiares y/o mdicos, ven mermada su calidad de vida con motivo de las revisiones mdicas continuas o de la propia monitorizacin que dicha enfermedad requiera segn su relevancia. En casos extremos, hay pacientes que ven reducida notablemente su propia libertad de movimiento, al verse obligados a estar conectados a una mquina en el interior de un hospital o de un centro mdico. En [2][3] se propone un sistema que pretende mejorar la calidad de vida de algunas personas que se encuentran en esta situacin. El sistema presentado en [2][3] tiene por objetivo la monitorizacin continua, inalmbrica e inteligente de pacientes en entornos cerrados (hospital, residencia de ancianos, etc.) y abiertos (escenario urbano, rural, etc.). Est basado en una red de rea corporal Bluetooth, portada por el paciente, cuyo nodo central recibe informacin sobre su estado de salud y localizacin. Estos datos son cifrados y enviados a un servidor mediante Wi-Fi o GPRS/UMTS. Adems, el sistema permite el acceso remoto a los datos del paciente, desde un PC o desde un terminal mvil, y proporciona un mecanismo de generacin de alarmas para avisar, al personal mdico y a los familiares del paciente, de la ocurrencia de situaciones de emergencia: valores monitorizados fuera de rango, paciente fuera de un rea controlada o segura, molestias del paciente, etc. La arquitectura del sistema global, que se muestra en la gura 2.1, est compuesta por los siguientes elementos: 1. El SCC (Servidor de Control Central) que es un equipo servidor, dotado de conexin a internet, que centraliza la informacin de los pacientes monitorizados y proporciona acceso a sus datos desde cualquier PC o dispositivo mvil. 2. La iBAN (intelligent Body Area Network) Bluetooth del paciente, que est formada 3

PC DE MONITORIZACIN (UCMNM)

PC DE MONITORIZACIN (UCMNM)

INTERNET

SCC

GPS Sensor 1
... RED DE TELEFONA MVIL

Bluetooth
NI

WiFi

Sensor N

iBAN del paciente

UCMM

GSM/GPRS/UMTS WiFi GPRS/UMTS

...

FAMILIARES DEL PACIENTE

Figura 2.1: Sistema de monitorizacin inalmbrica de pacientes. por sensores Bluetooth y por un nodo central, denominado NI (Nodo Inteligente)1 . Estos dispositivos forman una red Bluetooth, donde el NI centraliza todas las comunicaciones. Este nodo central posee, adems, interfaces de WiFi y GSM/GPRS/UMTS que utiliza para la transmisin de la informacin del paciente al SCC o (WiFi o GPRS/UMTS) y para el envo de las alarmas, a la Unidad de Control y Monitorizacin Mvil (UCMM) y a los terminales de los familiares del paciente (GSM/GPRS/UMTS). 3. La UCMM, que es un terminal mvil, que posee interfaces WiFi y GSM/GPRS/UMTS para la comunicacin con el SCC (WiFi o GPRS/UMTS) y para la recepcin de alarmas procedentes del NI (GSM/GPRS/UMTS). Se conecta con el SCC para supervisar remotamente la informacin de los pacientes. 4. Los terminales mviles de los familiares del paciente. Son telfonos mviles con conexin a la red de telefona (GSM/GPRS o GSM/GPRS/UMTS), que permiten la recepcin de alarmas que enva el NI a travs de dicha red. 5. Los PC de monitorizacin o Unidades de Control y Monitorizacin No Mvil (UCMNM), con conexin a internet, que acceden al SCC y hacen posible la supervisin remota de los pacientes. El presente Proyecto Fin de Carrera abarca, principalmente, el desarrollo del software de control de la iBAN del paciente, residente en el nodo central (NI), que ha sido el protagonista del proyecto. Adems, se ha diseado el software de recepcin y noticacin de alarmas para familiares del paciente.
1

Este nombre ha sido adquirido de la notacin del sistema propuesto en [2][3].

ANTONIO NGEL BOTELLA GALINDO

EMILIO JESS CUBEROS JIMNEZ

Aplicacin SW

NI

UCMM

Aplicacin SW

Aplicacin SW

Terminal mvil Familiar

SCC

Aplicacin SW

Aplicacin SW

Aplicacin SW
Descarga/Instalacin de las aplicaciones del NI y familiares PC de monitorizacin (UCMNM)

Figura 2.2: mbito de los proyectos realizados por Antonio ngel Botella Galindo y Emilio Jess Cuberos Jimnez, respecto al sistema de la gura 2.1. Adicionalmente, se ha desarrollado una aplicacin web para la descarga e instalacin de dichas aplicaciones en los terminales mviles2 . El resto de componentes del sistema, la UCMM, el SCC y los PC de monitorizacin, han sido abarcados por el Proyecto Fin de Carrera realizado por Emilio Jess Cuberos Jimnez, que lleva por ttulo Desarrollo de una aplicacin de telemedicina para el acceso remoto a bioseales desde dispositivos mviles [4] (vase la gura 2.2). Seguidamente, en el apartado 2.2, se describen los componentes del sistema objeto de este proyecto y en el apartado 2.3, se desglosa los mdulos en los que se ha estructurado la implementacin del software asociado a dichos componentes.

2.2.

mbito del proyecto

A continuacin, se detallan los bloques en los que se encuadra el software desarrollado en el mbito de este proyecto: la iBAN del paciente y los terminales mviles de los familiares.

2.2.1.

iBAN del paciente

La iBAN consta de un conjunto de dispositivos que se comunican entre s mediante Bluetooth. Dicha red puede estar constituida por un nmero mximo de dispositivos (hasta N sensores, un dispositivo GPS y un telfono mvil) que vendr limitado por la tecnologa
Esta aplicacin web tiene por objetivo facilitar la instalacin del software desarrollado en los terminales nales.
2

iBAN
Figura 2.3: iBAN desarrollada en este Proyecto Fin de Carrera. empleada, en este caso, Bluetooth. En el caso particular del presente Proyecto Fin de Carrera, la iBAN est compuesta por tres elementos, tal y como se muestra en la gura 2.3, que son: 1. Un pulsioxmetro (vase el apartado 4.2.8.3), capaz de medir la saturacin de oxgeno en sangre, el ritmo cardaco e informacin pletismogrca (onda pletismogrca) de la persona que lo porta. Aunque en este caso slo hay un sensor, la arquitectura se ha diseado para que sea sencillo adaptarla a las necesidades de cada paciente. Por ejemplo, una persona diabtica podra llevar un glucmetro, o si tiene problemas vasculares, un pulsioxmetro y un electrocardigrafo (ECG) simultneamente. Al cambiar los componentes de la iBAN, el software del NI debe ser modicado para que tenga en cuenta dichos cambios. As pues, el diseo del software del nodo central (NI) se ha llevado a cabo pensando en esta propiedad de escalabilidad, es decir, que la introduccin de un nuevo elemento, o la eliminacin de uno ya existente, tenga el menor impacto posible en el cdigo de la aplicacin, siendo reutilizable para pacientes con diferentes afecciones mdicas y que porten diferentes dispositivos. 6

2. Un terminal GPS (vase el apartado 4.2.9) que proporciona la posicin del paciente en entornos abiertos. 3. Un nodo central (NI), que es un telfono mvil, donde reside la aplicacin software desarrollada en este Proyecto Fin de Carrera y que lleva a cabo las siguientes funciones: Localizar al resto de los dispositivos de la iBAN y conectarse a ellos va Bluetooth. Gestionar la comunicaciones Bluetooth, posibilitando la lectura de los datos medidos y la conguracin del resto de componentes de la iBAN (pulsioxmetro y GPS). Procesar la informacin de monitorizacin necesaria para detectar posibles situaciones de emergencia. Detectar una situacin de emergencia, generar alarmas que enva a la UCMM y a los familiares del paciente monitorizado. Transmitir la informacin mdica y de localizacin al SCC. Permitir al SCC la gestin remota de la iBAN, por medio del envo de comandos que el NI debe recibir e interpretar. Por ejemplo, ofrecer la posibilidad de modicar los valores umbrales de los parmetros usados para la deteccin de alarmas, cambiar el modo de funcionamiento de los sensores de la iBAN, resetear un sensor en un instante determinado, cambiar el perodo de transmisin de los datos, etc. Gracias a ello, la UCMM y los PC de monitorizacin tambin podrn congurar la iBAN, a travs de su conexin con el SCC. Finalmente, se puede decir que el nodo central de la iBAN (NI) acta como una pasarela o gateway, entre la iBAN Bluetooth y el SCC, aadiendo a dicha comunicacin una cierta inteligencia, gracias al tratamiento de la informacin para detectar situaciones de emergencia y a la posibilidad de gestionar remotamente la iBAN, desde el SCC, a travs del propio NI.

2.2.2.

Terminales mviles para recepcin de alarmas

Son terminales con conexin a la red de telefona mvil, receptores de las alarmas generadas por el NI en casos de emergencia3 . En cada uno de ellos se ejecuta una aplicacin software que se encarga de recibir estas alertas y noticar su llegada al usuario. La gura 2.4 muestra el esquema utilizado.
En el apartado 2.1, se seala claramente que las alarmas llegan tanto a la UCMM de mdico, como a los terminales de los familiares.
3

APLICACIN DE RECEPCIN Y NOTIFICACIN DE ALARMAS

...

...

...

NI RED DE TELEFONA MVIL

FAMILIARES DEL PACIENTE

Figura 2.4: Envo de alarmas desde el NI a los familiares del paciente.

2.3.

Estructura del sistema

En los siguientes apartados se especican los objetivos y funciones de los subsistemas correspondientes a la implementacin del software del nodo central de la iBAN (apartado 2.3.1) y de recepcin de alertas en los terminales mviles de los familiares de los pacientes (apartado 2.3.2). Finalmente, en el apartado 2.3.3, se describe brevemente la aplicacin de instalacin del software desarrollado.

2.3.1.

Subsistemas del software del NI

En el software del nodo central (NI), se pueden diferenciar los siguientes mdulos o subsistemas: 1. Mdulo de comunicaciones Bluetooth. 2. Mdulo de comunicaciones con el Servidor de Control Central. 3. Mdulo de gestin de comandos y control. 4. Mdulo de procesamiento y gestin de alarmas. 2.3.1.1. Mdulo de comunicaciones Bluetooth

Este mdulo, que se detalla en el apartado 5.2.4, tiene por objetivo gestionar la comunicacin con el resto de componentes de la iBAN (pulsioxmetro y GPS) y la informacin de 8

monitorizacin que genera, segn la conguracin establecida en la red de rea corporal (modos de funcionamiento, tiempo de monitorizacin establecido, etc.). Sus funciones principales son: 1. Buscar al resto de los dispositivos pertenecientes a la iBAN. 2. Establecer la conexin Bluetooth con todos ellos. 3. Recibir y almacenar la informacin procedente del pulsioxmetro y del GPS, segn la conguracin que tengan estos dispositivos en cada momento. 4. Registrar los estados de todas las conexiones Bluetooth establecidas, indicando si en un momento dado estn activas o cadas. 5. Recuperar la conexin de las comunicaciones Bluetooth que se hayan perdido. 2.3.1.2. Mdulo de comunicaciones con el SCC

El principal objetivo de este mdulo es permitir al SCC la gestin remota de la iBAN: lectura de datos, conocimiento del estado de la iBAN, conguracin de la iBAN, etc. Las funciones que lleva a cabo son: 1. Enviar los datos recibidos de los dispositivos Bluetooth al SCC. 2. Recibir los comandos del SCC y entregarlos al mdulo de gestin y control de comandos. 3. Enviar todas las respuestas e indicaciones generadas por el mdulo de gestin y control de comandos, al SCC. 4. Recuperar la conexin con el SCC, en caso de que se haya perdido. En el apartado 5.2.5, se detalla su estructura y funcionamiento. 2.3.1.3. Mdulo de gestin de comandos y control

Este mdulo, que se detalla en el apartado 5.2.6, tiene como principal objetivo interpretar los comandos generados por el SCC y supervisar el estado de los componentes de la iBAN para noticar la ocurrencia de eventos. Sus funciones son: 1. Interpretar los comandos del SCC (un comando por cada peticin) para llevar a cabo las acciones adecuadas sobre la iBAN. 2. Ejecutar cada comando sobre el dispositivo pertinente. 9

3. Generar la respuesta con el resultado de la accin ejecutada (una respuesta por cada comando) y noticarla al mdulo de comunicaciones SCC, para que sea enviada al SCC. 4. Supervisar el estado de los elementos de la iBAN, a travs del registro de estados realizado por el mdulo de comunicaciones Bluetooth. 5. Indicar si algn elemento de la iBAN pierde su conexin con el NI a travs del mdulo de comunicaciones con el SCC. 2.3.1.4. Mdulo de procesamiento y gestin de alarmas

Este mdulo tiene como objetivo supervisar los datos mdicos y de localizacin del paciente y generar/enviar alarmas, a la UCMM del mdico y a los mviles de los familiares, en caso de detectarse una situacin de emergencia. Sus funciones son: 1. Procesar los datos del paciente, vericando si los valores predenidos de determinados parmetros se encuentran fuera de rango. 2. Generar y enviar la alarma adecuada, segn el evento ocurrido. 3. Posibilitar la modicacin de los criterios usados para detectar esas situaciones de emergencia: valores umbrales de los parmetros mdicos, valores umbrales de posicin, etc. En el apartado 5.2.7, se detalla su estructura y funcionamiento.

2.3.2.

Subsistemas del software de recepcin y noticacin de alarmas en terminales mviles

Para la recepcin y noticacin de alarmas, se ha desarrollado un mdulo de recepcin de mensajes de texto (SMS o Short Message Service) y mensajes multimedia (MMS o Multimedia Messaging Service). Este mdulo, que se detalla en el apartado 6.2.3, lleva a cabo las siguientes funciones: 1. Recibir las alarmas SMS/MMS enviadas por el NI. 2. Noticar al usuario la entrada de una alarma SMS/MMS de una manera insistente, dada la importancia de la informacin que contiene dicho mensaje. 3. Permitir la posibilidad de realizar una llamada de telfono, desde la propia aplicacin, a un telfono de emergencias mdicas prejado o incluso al del propio paciente monitorizado. 10

2.3.3.

Aplicacin web para la descarga de MIDlets

La aplicacin web para la descarga de las aplicaciones del NI y de recepcin de alarmas, consta de los siguientes mdulos, que proporcionan una interfaz grca, sencilla y amigable, especialmente diseada para usuarios con poca experiencia en navegacin a travs de internet: 1. Mdulo de autenticacin de usuario que permite slo el acceso a los usuarios que han sido previamente registrados, mediante la realizacin de un ltrado de las peticiones entrantes. Dichas peticiones se harn a travs de un nombre de usuario (user) y una clave (password). El apartado 7.4, aborda con detalle este mdulo. 2. Mdulo de descarga de software que facilita la descarga de las aplicaciones, en la medida de lo posible, con una explicacin clara y concisa de cmo el usuario debe proceder para su realizacin, sea desde un PC o desde un telfono mvil. En el apartado 7.4, se detalla su funcionamiento.

11

12

Captulo 3 Tecnologas implicadas

3.1. Introduccin

Este captulo se divide en tres apartados, donde se presentan, respectivamente, las tecnologas de comunicacin implicadas en la realizacin del proyecto, los sistemas operativos ms utilizados en la telefona mvil y los lenguajes de programacin empleados para el desarrollo del software objetivo.

3.2.
3.2.1.

Tecnologas de Comunicacin
Bluetooth

Bluetooth es una tecnologa de comunicacin inalmbrica, creada por el SIG (Special Interest Group) [5], en la que se basa el estndar IEEE 802.15.1 (Standard for Wireless Personal Area Networks adapted from the Bluetooth specicacion)[6]. Su principal objetivo es reemplazar los cables para la comunicacin entre dispositivos electrnicos portables y/o jos (ordenadores, telfonos mviles, PDA, impresoras, auriculares, etc.), facilitando as la comunicacin entre ellos [7][8]. Opera en la banda de frecuencias sin licencia ISM (Industrial, Scientic and Medical) [9], a 2.4 GHz, utilizando la tcnica de frequency hopping para evitar interferencias y desvanecimientos (fading). Su rgimen binario oscila entre 1 Mbps (Basic Rate) de Bluetooth v1.1 y 2-3 Mbps (Enhaced Data Rate) de Bluetooth v2.0. Esta tecnologa se caracteriza, principalmente, por su robustez, su bajo consumo y su coste reducido [7]. Las redes de dispositivos Bluetooth se denominan Piconets. En ellas uno de los dispositivos acta como maestro, el cual establece y gestiona el patrn de frequency hopping que se va a usar, y el resto, hasta 7 dispositivos en modo activo, como esclavos [7]. Los esclavos pueden participar en Piconets distintas, de modo que varias Piconets conectadas entre s forman lo que se denomina una red Scatternet [10] (conexin entre dos maestros de Piconets 13

diferentes). La arquitectura de protocolos de Bluetooth v1.1 se muestra en la gura 3.1 [11]. Esta arquitectura se divide en una serie de niveles con sus protocolos asociados, donde destacan los siguientes: Protocolos del ncleo Bluetooth (Bluetooth Core Protocols): Protocolo de RF (Radio Frequency). Se utiliza en el nivel radio (Bluetooth Radio) que es, principalmente, un circuito de RF (Radio Frequency) a 2.4 GHz que modula y transmite la seal. Como tcnica de modulacin utiliza GFSK (Gaussian Frequency Shift Keying) y las potencias de transmisin oscilan entre los 0 dBm (dispositivo de Clase 3) a 20 dBm (dispositivo de Clase 1) [7]. Transforma los paquetes del Baseband a seal de RF y viceversa. Protocolo de Baseband. Se emplea en el nivel de banda base (Baseband). Especica e implementa los mecanismos de acceso al medio y de la capa fsica para proporcionar comunicacin de voz en tiempo real, intercambio de datos y gestin de la red Bluetooth (codicacin/decodicacin de paquetes Bluetooth, sealizacin de control, acceso a los canales radio, etc.) [7]. Link ManagerProtocol (LMP). Permite al nivel Link Manager controlar el modo de operacin de los dispositivos Bluetooth (creacin y control de enlaces lgicos, seguridad, adaptacin de la potencia de transmisin, etc.) y proporcionar los servicios necesarios para la gestin de los niveles inferiores (Bluetooth Radio y Baseband) [7]. L2CAP (Logical Link Control and Adaptation Protocol). Se responsabiliza de la creacin, gestin y destruccin de canales L2CAP para el transporte de datos, de la provisin de calidad de servicio (QoS), etc. [7]. SDP (Service Discovery Protocol). Es un protocolo de aplicacin, requerido por todos los dispositivos Bluetooth [7], que sirve para descubrir servicios Bluetooth disponibles. Otros protocolos de entidades de nivel superior que utilizan los servicios de L2CAP son: RFCOMM (Radio Frequency Communication). Es un protocolo que permite la emulacin de comunicaciones de cable serie (RS-232) [11]. TCS-BIN (Telephony Control Protocol Binary). Dene la sealizacin de control en comunicaciones de voz entre dispositivos Bluetooth [11]. Tras explicar la pila de protocolos Bluetooth se ha de puntualizar que el nivel HCI (Host to Controller Interface), cuya implementacin es opcional [7], hace de interfaz entre el 14

Bluetooth Controller Subsystem (niveles RF, Baseband y LMP) y el resto de la arquitectura Bluetooth (Bluetooth Host System). Una vez estudiada la pila de protocolos de Bluetooth (gura 3.1), hay que mencionar el concepto de perl Bluetooth. Los perles Bluetooth especican los protocolos necesarios y sus modos de uso para proporcionar al usuario una funcionalidad determinada. Por ejemplo, en Bluetooth v.1.1 se han denido, entre otros, los siguiente perles [11]:

GAP (General Access Prole). Detalla los procedimientos generales para el descubrimiento y conexin entre dispositivos Bluetooth, adems de ciertos aspectos de seguridad. Debe ser soportado obligatoriamente por todos los dispositivos Bluetooth. Service Discovery Application Prole. Dene los procedimientos y caractersticas que debe tener una aplicacin que reside en un dispositivo Bluetooth para poder llevar a cabo el descubrimiento de otro dispositivo Bluetooth. SPP (Serial Port Prole). Establece los requisitos necesarios para que un dispositivo Bluetooth pueda emular conexiones de cable serie usando el protocolo RFCOMM. Generic Object Exchange Prole. Detalla los protocolos y procedimientos que las aplicaciones necesitan para el intercambio de objetos.

La ltima versin de Bluetooth es la 2.1, que ha sido anunciada para el ao 2007 [12][13]. En el mbito de este proyecto hay que destacar que el telfono utilizado como Nodo Inteligente (Nokia N93) posee Bluetooth v2.0, mientras que el pulsioxmetro Nonin 4100 y el mdulo GPS Leadtek 9553X soportan Bluetooth v1.1 y v1.2, respectivamente. Todos estos dispositivos operan a nivel RFCOMM. Para mayor informacin sobre la tecnologa Bluetooth se recomienda la lectura de [7].

3.2.2.
3.2.2.1.

Tecnologas de comunicaciones mviles

GSM

GSM (Global System for Mobile communications) es un estndar de telefona mvil que introdujo importantes cambios respecto a sus predecesores (estndares de 1a generacin), por lo que se considera dentro de la 2a generacin (2G) de sistemas de comunicacin mvil [14]. Las bandas de frecuencias que emplea son las de 900/1800 MHz (Europa) y las de 850/1900 MHz (Estados Unidos y Canad). La velocidad mxima que ofrece es inferior a 14.4 Kbps (Kilobits por segundo) y entre los servicios que proporciona destacan [15]: Fax, SMS (Short Message Service) y CBS (Cell Broadcast Service), etc. 15

vCard/vCal OBEX

WAE WAP TCP|UDP IP PPP RFCOMM L2CAP ATCommands TCS BIN SDP BLUETOOTH HOST SYSTEM

Audio

HCI (Host to Controller Interface) Link Manager Baseband Bluetooth Radio BLUETOOTH CONTROLLER SUBSYSTEM

Figura 3.1: Arquitectura de Bluetooth v1.1. Fuente: [11]. 3.2.2.2. GPRS

GPRS (General Packet Radio Service) es un sistema de conmutacin de paquetes, que hace uso de GSM para transmitir datos usando el protocolo IP (Internet Protocol) [15]. Combinado con GSM, constituye un sistema de telefona de generacin 2.5 (2.5G). Sus velocidades estn comprendidas entre los 64-144 Kbps [15], lo que le permite ofrecer los siguientes servicios [16]: acceso WAP (Wireless Application Protocol), SMS, CBS, MMS (Multimedia Messaging Service), PTT (Push To Talk), email, acceso a web, mensajera instantnea, etc.

3.2.2.3.

EGPRS

EGPRS (Enhanced GPRS) es una evolucin de GPRS que ofrece mejores velocidades (mximo terico de 473.6 Kbps) y abilidad en la transmisin de datos [17]. Se considera un sistema de generacin 2.75 (2.75G).

3.2.2.4.

UMTS

UMTS (Universal Mobile Telecommunications System) constituye la 3a generacin de sistemas de comunicacin mvil, alcanzando velocidades de transmisin superiores a las de sus predecesoras (2G, 2.5G y 2.75G): 384-3600 Kbps. Las bandas de frecuencia utilizadas por UMTS son las de 2100/1900 MHz (Europa), 850/1900 MHz (Estados Unidos) o 850/2100 MHz (Australia) [18]. Gracias a su mayor ancho de banda, es capaz de ofrecer nuevos servicios como: videoconferencia, descarga de audio y vdeo, TV en tiempo real, etc. 16

3.2.3.

WiFi

WiFi (Wireless Fidelity) engloba un conjunto de estndares de comunicacin inalmbrica basados en la norma IEEE 802.11 [19]. El IEEE 802.11 dene un protocolo de comunicaciones, en sus niveles OSI (Open System Interconnection) fsico y de enlace, para su funcionamiento en una red de rea local inalmbrica o WLAN (Wireless Local Area Network) [20]. Actualmente destacan los siguientes estndares [20]: 1. IEEE 802.11b. Trabaja en la banda de 2.4 GHz (ISM) ofreciendo una velocidad mxima de 11 Mbps (Megabits por segundo). 2. IEEE 802.11a. Emplea la banda de los 5 GHz, que est libre de otras tecnologas que coinciden con la banda de 2.4 GHz (Bluetooth, microondas, etc.). Su velocidad alcanza los 54 Mbps, pero al presentar problemas de compatibilidad con productos 802.11b no cosecha el xito de su sucesor (802.11g). 3. IEEE 802.11g. Utiliza tambin la banda de 2.4 GHz, pero su velocidad mxima es de 54 Mbps. Permite la compatibilidad con productos conformes a la norma IEEE 802.11b. 4. IEEE 802.11n. Hace uso de las bandas de frecuencias de 2.4 GHz y 5 GHz, con una velocidad terica que alcanza los 600 Mbps. En la actualidad, el estndar est siendo completado y revisado, pero algunos productos cumplen con las especicaciones de un borrador de ste, alcanzando velocidades reales de 80-100 Mbps. La mayora de los dispositivos WiFi actuales cumplen los estndares IEEE 802.11b y/o IEEE 802.11g. Vase [21] y [22] para obtener ms informacin.

3.3.
3.3.1.

Sistemas operativos para telfonos mviles

El sistema operativo Symbian OS

Symbian es un sistema operativo propietario, para telfonos mviles, creado por un consorcio de fabricantes (Nokia, Sony-Ericsson, Samsung, Siemens, etc.) denominado Symbian Ltd [23][24]. Su primera versin fue lanzada en 1999 (Symbian OS v5.0) y desde entonces ha ido evolucionando hasta la versin 9.5 (Marzo de 2007) [25]. Symbian se ejecuta, exclusivamente, en procesadores ARM [24][26] y de los fabricantes que lo soportan destacan Nokia y Sony-Ericsson, entre otros [27]. En la actualidad, es el sistema operativo ms utilizado en telefona mvil, alcanzando el nmero de 110 millones de terminales en el ao 2006 [28]. Sus principales caractersticas son [29]: 17

Posibilita el desarrollo de aplicaciones y servicios, en diferentes lenguajes de programacin (C++, Java, etc.) y usando distintos tipos de contenidos. Implementacin modular, constituida por un conjunto de API (Application Programming Interface) y tecnologas, compartida por todos los dispositivos Symbian. Hace posible la interoperabilidad entre fabricantes. Sistema multitarea (kernel multitarea, comunicaciones, gestin de datos y grcos, etc.). Diseo exible de la interfaz grca de usuario. Para obtener mayor informacin sobre Symbian OS y sus versiones, consultar [25] y [30].

3.3.2.

Otros sistemas operativos utilizados en telfonos mviles

Adems de Symbian, existen otros sistemas operativos para mviles como son: Sistemas operativos propietarios: Nokia OS, Sony-Ericsson OS, etc. Palm OS. Windows Mobile. Para ms informacin vase las referencias [31], [32], [33] y [34].

3.4.
3.4.1.

Lenguajes de Programacin
Java

Java, creado por Sun Microsystems, Inc. en 1991 [35], es un lenguaje de alto nivel y orientado a objetos que desde su fecha de lanzamiento (1995), ha ido evolucionando y abarcando mbitos a los que inicialmente no estaba dirigido. En principio, fue concebido para el desarrollo de programas para ordenadores de sobremesa (J2SE, Java 2 Standard Edition). Con el tiempo, el lenguaje ha sido mejorado haciendo posible el desarrollo de aplicaciones distribuidas (J2EE, Java 2 Enterprise Edition) y aplicaciones para telfonos mviles1 (J2ME, Java 2 Micro Edition). Su principal ventaja es la portabilidad, es decir, la independencia de la plataforma sobre la que el cdigo Java va a ser ejecutado. En la gura 3.2, se muestran las tres plataformas que se engloban dentro del lenguaje Java y que anteriormente han sido comentadas [36]: J2SE, J2EE y J2ME .
Se recomienda la lectura del apndice A que incluye un glosario de terminologa Java relacionada con J2ME.
1

18

Java 2 Platform
1
Servers

2
Desktop machines

Java 2 Micro Edition (J2ME)

Optional Packages

3
Optional Packages High-end consumer devices

4
Low-end consumer devices Optional Packages MIDP CLDC KVM Java Card APIs CardVM

5
SmartCards

Java 2 Enterprise Edition (J2EE)

Java 2 Standard Edition (J2SE)

Personal Profile Foundation Profile CDC

JAVA VIRTUAL MACHINE (JVM)

OPERATING SYSTEM

HARDWARE

Figura 3.2: Arquitectura Java. Fuente: [36].

3.4.2.

J2ME

J2ME (Java 2 Micro Edition), tal y como se ha visto en el apartado anterior, es la plataforma que ofrece Java para la creacin de aplicaciones en dispositivos con recursos limitados (telfonos mviles, PDA, smartphones, etc.). Su arquitectura aparece en la gura 3.2, y los elementos que la componen son los siguientes [37][38][39]: 1. Las conguraciones, que son el conjunto mnimo de libreras que proporcionan la funcionalidad bsica para la creacin de aplicaciones J2ME y que son independientes del propsito de los dispositivos. Hay dos tipos, que se explican a continuacin: CLDC (Connected Limited Device Conguration). Pone a disposicin del programador una versin reducida de algunos paquetes de J2SE (java.lang, java.io, java.util) y un paquete llamado javax.microedition.io, para conexiones de red [38]. Es apropiada para el desarrollo de programas que se van a ejecutar en dispositivos con capacidades de proceso y memoria limitadas, tales como telfonos mviles y PDA (Personal Digital Assistant). CLDC 1.1 es la versin actual, que se dene en la JSR (Java Specication Request)-1392 .
Aunque todas las JSR se encuentran disponibles en [40], se recomienda la lectura del apndice B, donde se ha incluido cierta informacin sobre las principales JSR de J2ME (nmero de JSR, API, nombre y URL para su descarga).
2

19

CDC (Connected Device Conguration). Ofrece un mayor nmero de paquetes que CLDC, siendo su funcionalidad bastante ms parecida a la de J2SE (versin 1.4) . Se ajusta a dispositivos que tienen mayor velocidad de proceso y memoria que los dispositivos propios de CLDC. Entre ellos se encuentran algunos electrodomsticos inteligentes (domtica), decodicadores de televisin por satlite, sistemas de telemetra, dispositivos embedidos, etc. [37]. La ltima versin es la CDC 1.1, denida en la JSR-218. Actualmente, la funcionalidad ofrecida por CLDC, su perl (MIDP, Mobile Information Device Prole) y sus paquetes opcionales est muy prxima a la de CDC, lo que se maniesta en el hecho de que CLDC, a diferencia de CDC, est presente en la mayora de telfonos Java actuales [41]. La portabilidad de una misma aplicacin entre un gran nmero de terminales, junto con la funcionalidad total capaz de proveer, convierten a CLDC en la conguracin preferida para la creacin de aplicaciones para dispositivos mviles [37]. 2. Los perles, que extienden la funcionalidad de las conguraciones subyacentes ofreciendo, por tanto, las liberas necesarias para ello. Se denen segn las caractersticas y propsito de los dispositivos nales. Son cuatro y se clasican segn la conguracin sobre la que trabajan [37]: Un nico perl asociado a la conguracin CLDC, que es el MIDP (Mobile Information Device Prole). Ofrece la funcionalidad necesaria para el desarrollo de aplicaciones para terminales mviles (interfaz grca de usuario, conectividad, almacenamiento persistente de datos, etc.). Aunque MIDP 2.0, denido en la JSR-118, es el perl actualmente implementado por los telfonos mviles, la versin 3.0 ya est especicada en la JSR-271[40]. Encima de MIDP 2.0 se disponen los paquetes opcionales JSR-75 (PDA Optional Packages for the J2MEPlatform), JSR-82 (Java APIs for Bluetooth), JSR-135 (Mobile Media API 1.1), JSR-177 (Security and Trust Services API), JSR-205 (Wireless Messaging API 2.0), etc., que aumentan, a su vez, la funcionalidad y los servicios que este perl ofrece. Tres perles asociados a CDC: Foundation Prole. Este perl trabaja sobre la conguracin CDC. Proporciona conectividad, pero no permite crear interfaces grcas de usuario. En la JSR-219, se dene su versin 1.1. Personal Prole. Aade al perl Foundation Prole las funciones necesarias para crear una interfaz grca de usuario y otras de conectividad adicionales. El Personal Prole 1.1 que se dene en la JSR-216. Personal Basis Prole. Es un subconjunto del Personal Prole que proporciona funciones de conectividad y una interfaz grca limitada . Su ltima 20

versin es la 1.1, denida en la JSR-217. 3. Una mquina virtual Java. Segn la conguracin y perles empleados, las necesidades (capacidades de proceso, memoria, interfaz grca, etc.) sern diferentes. De acuerdo con esto, la mquina virtual Java asociada tambin ser diferente. Hay dos tipos, que son los siguientes [37]: KVM (Kilobyte Virtual Machine). Ocupa tan slo unos kilobytes, como su propio nombre indica, estando optimizada para dispositivos mviles, sistemas embedidos y PDA. Se implementa en los dispositivos MIDP (CLDC). JVM (Java Virtual Machine). Se caracteriza porque es utilizada por las plataformas J2SE y J2EE, y tambin por los programas J2ME desarrollados mediante la conguracin CDC. Una exposicin ms detallada de la plataforma J2ME puede encontrarse en [37][38][39].

3.4.3.

HTML

HTML (Hyper Text Markup Language) es un lenguaje creado en los aos 90, por el Word Wide Web Consortium (W3C), www.w3c.org, con el n de especicar la estructura y el formato de un pgina web de una manera universal [42]. HTML permite [43]: Crear documentos web con cabeceras, texto, tablas, listas, fotos, etc. especicando todas sus caractersticas. Recuperar informacin o vincular una informacin con otra, a travs de enlaces de hipertexto. Disear formularios para llevar a cabo transacciones de diversos tipos: bsqueda de informacin, reservas, compra de productos, etc. Incluir, directamente, vdeo, sonido y otras aplicaciones en una pgina web. En Diciembre de 1999 aparece su ltima versin que es HTML 4.01 [43].

3.4.4.

PHP

PHP (PHP Hypertex Pre-processor) es un lenguaje de alto nivel, de cdigo abierto, orientado al desarrollo de aplicaciones servidoras que permiten crear y gestionar contenido dinmico en pginas web [44]. Est embedido en el cdigo HTML y es ledo, interpretado y ejecutado por el servidor web que aloja la pgina HTML, y nunca por el cliente, es decir, por el navegador que solicita la pgina. Tiene una sintaxis parecida a los lenguajes C y Perl y 21

es muy utilizado para la conectividad a bases de datos (posee soporte para un gran nmero de bases de datos nativas) [45]. Su ltima versin, PHP 5.2.2, ha sido lanzada en Mayo de 2007 [46] y est disponible para su descarga en [47].

3.5.

Lenguaje Unicado de Modelado (UML)

UML (Unied Modeling Language) es un lenguaje para el modelado de software, creado por la OMG (Object Management Group) en 1997 [48]. Segn el OMG [49]: UML ayuda a especicar, visualizar y documentar, modelos de sistemas software, incluyendo su estructura y diseo, cumpliendo los requisitos solicitados. Se puede modelar cualquier tipo de aplicacin, sea cual sea el hardware donde se ejecute, el sistema operativo, el lenguaje de programacin y la red utilizada. Por lo tanto, UML es un lenguaje que permite especicar y construir el modelo de un sistema software objetivo (modelo UML), sin establecer la metodologa o el proceso a seguir en su creacin. En su versin 2.0 (2005), que incluye importantes cambios respecto a las versiones anteriores, se dispone de trece tipos de diagramas que se dividen en tres grupos claramente diferenciados[48][49]: 1. Diagramas de estructura. Representan la estructura esttica del sistema. Aunque incluye seis tipos, los ms representativos son [54]: Diagrama de Clases. Detalla la estructura de las clases e interfaces que componen el sistema (atributos y mtodos), adems de reejar cmo se relacionan entre s. Diagrama de Componentes. Ofrece una vista fsica del sistema. Sirve para representar las dependencias que existen entre los componentes software que constituyen el sistema (libreras que utiliza una clase, cheros que implementan un elemento software, etc.). Diagrama de Despliegue. Muestra el hardware donde se ejecutarn los distintos elementos del sistema y cmo estos se comunican entre s. 2. Diagramas de comportamiento. Representan cmo se comporta el modelo. Hay tres tipos [54]: Diagrama de Casos de Uso. Expresa la funcionalidad que proporciona el sistema, reejando cmo los actores (una persona, una mquina, etc.) interaccionan con ste, a travs de los diferentes casos de uso. Un caso de uso representa una unidad de funcionalidad que puede ser empleada por un actor o por otro caso de uso. 22

Diagrama de Actividades. Se utilizan para mostrar el ujo de control entre dos o ms entidades mientras procesan una actividad. Diagrama de Mquinas de Estados. Representa los diferentes estados en los que puede estar una clase y cmo realiza la transicin entre ellos. 3. Diagramas de interaccin. Son derivados de los Diagramas de comportamiento y reejan la interaccin y el ujo de datos entre los distintos elementos del sistema modelado. Existen cuatro tipos, pero destaca principalmente uno de ellos [54]: Diagrama de Secuencia. Detalla el ujo de ejecucin de un caso de uso especco o de una parte de ste. En l se aprecian las llamadas entre los diferentes objetos que intervienen en la secuencia.

Aunque su ltima versin es UML 2.1.1 [51], en este proyecto se ha utilizado UML 2.1. Para obtener ms informacin sobre UML y sus diferentes tipos de diagramas, se recomienda la lectura de [52][53][54].

3.6.

Herramientas de desarrollo

En esta seccin se presenta el software empleado en el desarrollo de las aplicaciones que forman parte del mbito del presente Proyecto Fin de Carrera. Las herramientas de desarrollo utilizadas han sido las siguientes:

Eclipse SDK (Software Development Kit). Carbide.j (Nokia Developers Suite for J2ME). NCF (Nokia Connectivity Framework). Nokia PC Suite. Sun Java Wireless Toolkit for CLDC. Ethereal.

En cada uno de los apartados sucesivos se describir el mbito de utilizacin de cada una de estas herramientas, sus principales funciones y caractersticas, adems del uso particular que se ha hecho de ellas durante la ejecucin de este proyecto. 23

Contributed Plug-ins Web Tools Platform (WTP) JDT CDT PDE Rich Client Platform (RCP) Applications

Eclipse Runtime Platform

Integrated Development Environment (IDE)

Bloques incluidos, por defecto, en Eclipse SDK.

Figura 3.3: Arquitectura de Eclipse SDK [55].

3.6.1.

Eclipse SDK (Software Development Kit)

Centrndose en el uso que se ha hecho de esta herramienta, durante el presente Proyecto Fin de Carrera, Eclipse podra denirse como un entorno de desarrollo integrado o IDE, de cdigo abierto, que facilita al desarrollador la tarea de la programacin gracias a sus mltiples caractersticas. Adems, es funcionalmente extensible mediante la adicin de mdulos o plug-ins, lo que le permite adaptarse a las necesidades de cada usuario. Las propiedades que lo caracterizan son [55]: Multi-plataforma. Permite su ejecucin en varios sistemas operativos como son Windows, Linux, Solaris, AIX, HP-UX y Mac OSX. Multi-lenguaje. Aunque est escrito en lenguaje Java y por defecto slo permite el desarrollo de este tipo de aplicaciones, con la integracin de los plug-ins correspondientes es posible utilizar otros lenguajes de programacin como C/C++, Cobol, Python, Perl, PHP, etc. Tambin est disponible en un gran nmero de idiomas [56], incluyendo el espaol. Multi-rol. Adems de las utilidades para la programacin, Eclipse permite realizar modelado (UML, por ejemplo), test de aplicaciones, creacin de pginas web de forma visual (Web authoring), etc. Eclipse posee una arquitectura modular, tal y como reeja el esquema de bloques de la gura 3.3 [55][57]: A continuacin, se describen sus componentes brevemente: 1. Eclipse Runtime Platform: es la base de la arquitectura y provee los siguientes servicios bsicos: 24

Registro de plug-ins: carga y gestiona los mdulos disponibles. Gestin de los recursos del sistema operativo. Componentes de la interfaz grca de usuario. Herramienta de actualizacin de plug-ins. Ayuda de Eclipse. 2. Integrated Development Environment (IDE): sus servicios genricos, idnticos en todos los plug-ins de lenguajes de programacin, son: Vistas: elementos grcos, generalmente pestaas con listas de elementos, utilizados para la ejecucin de tareas de bajo nivel (creacin de un proyecto, bsqueda de cheros, visualizacin de errores de compilacin, etc.). En la gura 3.4, se aprecian varias vistas dentro de la perspectiva Java de Eclipse. Perspectivas: conjunto de vistas, relacionadas entre s, que unican su funcionalidad para la realizacin de tareas de alto nivel (creacin de una aplicacin en Java, depuracin de un programa, etc.). Las guras 3.5 y 3.6, presentan dos de estas perspectivas. Conguracin de preferencias de los mdulos instalados en Eclipse. Motor de bsqueda de archivos (Java, C/C++, texto, UML, etc.) incluidos en los proyectos creados con Eclipse. Depuracin de aplicaciones por medio del depurador o debugger. Cabe destacar la existencia de problemas en la depuracin de programas J2ME, mediante el uso del plug-in EclipseME [58]. Debido a ello, no ha sido posible aprovechar esta facilidad. No obstante, la depuracin de cdigo J2SE, que es la que Eclipse permite por defecto, ha sido testeada y probada satisfactoriamente. Integracin de Ant. Ant es una herramienta que posibilita el procesamiento automtico de tareas (compilacin, creacin de paquetes y emulacin), sobre cheros de cdigo que forman parte de un proyecto, mediante la edicin de un chero XML (eXtensible Markup Language) [59]. Control de versiones con CVS (Current Versioning System). Herramienta que permite la modicacin simultnea de cdigo de un proyecto, por parte de varios programadores, registrando todos los cambios realizados y un historial de sus versiones existentes [60]. Otros servicios, no genricos, son: Asistente de contenido (resaltado de sintaxis, sugerencia de atributos de un mtodo/procedimiento, etc.) 25

 Plantillas de cdigo: bucles for, while, etc. Asistente para el formato del cdigo: sangras, alineacin, etc. Identicacin de problemas en tiempo real: la compilacin se hace en tiempo real, as que los errores del programa se notican tras la realizacin de este proceso. 3. JDT (Java Development Tool). nico plug-in de lenguaje de programacin que incluye Eclipse por defecto. Es el conjunto de funcionalidades (editor, depurador, etc. ) necesarias para el desarrollo de aplicaciones Java (J2SE). Sus servicios son: Editor, diagramas de jerarqua de clases, asistente de contenido, plantillas de cdigo y asistente para el formato del cdigo. Vistas Java. Asistente de conguracin de proyectos. Depurador o debugger. La gura 3.7, muestra el editor Java y otros servicios del JDT. 4. WTP (Web Tools Platform): soporte para aplicaciones web y J2EE. 5. CDT (C/C++ Development Tools): soporte para los lenguajes de programacin C y C++. 6. PDE (Plug-in Development Environment): herramientas para el desarrollo de mdulos para Eclipse. 7. Aplicaciones RCP (Rich Client Platform): aplicaciones de usuario, de alto contenido grco, que el programador puede disear basndose en los elementos grcos y mdulos empleados para la construccin de Eclipse. 8. Plug-ins: mdulos opcionales capaces de aumentar las funciones y prestaciones de Eclipse. La versin disponible de Eclipse SDK [61], incluye las capas Eclipse Runtime Platform, Integrated Development Environment, JDT y PDE (vase la gura 3.3). El amplio abanico de posibilidades que ofrece, el hecho de ser de cdigo abierto y la exibilidad que existe a travs de la integracin de plug-ins, han sido determinantes para la eleccin de Eclipse como herramienta de desarrollo en este proyecto. Aunque su versin actual es la 3.2.2, se han empleado las versiones 3.1.1 y 3.1.2, debido a motivos de compatibilidad con Carbide.j, software que se trata en el siguiente apartado.

26

Vista Package Explorer (exploracin de los proyectos creados)

Vista Outline (jerarqua de clases)

Vista Search (bsqueda de ficheros)

PERSPECTIVA JAVA

Figura 3.4: Vistas y perspectivas de Eclipse.

Figura 3.5: Perspectiva Java de Eclipse.

27

Figura 3.6: Perspectiva Debug de Eclipse.

Figura 3.7: Editor Java y algunos servicios del JDT.

28

La utilizacin de Eclipse se ha centrado, bsicamente, en la escritura y correccin del cdigo de las aplicaciones J2ME desarrolladas. Para obtener mayor informacin sobre Eclipse vase [55][62][63].

3.6.2.

Carbide.j (Nokia Developers Suite for J2ME)

Carbide.j, formalmente Nokia Developers Suite for J2ME, es un software para desarrolladores de aplicaciones J2ME que puede ser incluido, como plug-in, en diferentes IDE como son Eclipse, NetBeans o IBM WebSphere Studio Developer, entre otros [64]. Esta herramienta es gratuita y se puede descargar desde la pgina ocial de Forum Nokia [65]. Aunque Carbide.j se ha utilizado como un software asociado a un IDE, tambin es posible su uso como una herramienta independiente. Carbide.j proporciona un amplio conjunto de herramientas para que el programador pueda crear, emular, vericar y rmar aplicaciones J2ME para dispositivos Nokia. Los emuladores que incluye inicialmente abarcan todas las plataformas de telfonos mviles que Nokia tiene actualmente en el mercado: Serie 80, Serie 60 y Serie 40. Vase el apndice C para ms informacin. Entre sus caractersticas principales destacan [66][67]: 1. Asistente de creacin de clases Java. 2. Diseo de interfaces grcas de usuario. 3. Asistente de creacin de paquetes. En J2ME la creacin de un paquete est asociada a la creacin de los cheros .JAD (Java Application Descriptor) y .JAR (Java ARchive) que son necesarios para la instalacin del programa J2ME en el telfono mvil correspondiente. El chero .JAD contiene informacin (atributos) sobre la aplicacin creada: nombre, versin, autor, conguracin y perl utilizados, MIDlet/s que contiene, icono representativo de cada MIDlet, etc. Por otro lado, el chero .JAR guarda las clases de Java compiladas (cheros .class), algunos de los recursos adicionales utilizados por el programa (cheros de texto, imagen y sonido)3 y varios de los atributos ms signicativos del chero .JAD. Este subconjunto de atributos se guardan en un chero, denominado maniesto del .JAR, cuyo contenido ser incluido en el .JAR nal. En la gura 3.8, se observa la pestaa de creacin/edicin de los cheros .JAR y .JAD que ofrece Carbide.j, durante la creacin de un paquete.
En J2ME es posible utilizar un recurso externo, por ejemplo un chero de texto, que se encuentre en la memoria interna o externa del dispositivo mvil donde reside la aplicacin. Esto es posible mediante el uso la JSR-75 (File Connection and PIM API).
3

29

4. Firma de paquetes. Carbide.j ofrece la posibilidad de rmar una aplicacin mediante un certicado expedido por una Autoridad de Certicados (CA o Certicate Authority) o generado por el propio programador (autocerticado o self-certicate). Vase [68] [69] [70], para conocer ms detalles sobre el modelo de seguridad de J2ME y la rma de este tipo de aplicaciones. 5. Soporte para los perles MIDP (Mobile Information Device Prole) y PP (Personal Prole). Permite la creacin, prueba y emulacin de aplicaciones MIDP y PP. 6. Gestin y conguracin de los emuladores integrados. La gura 3.9 reeja la apariencia de varios de los emuladores que Carbide.j integra por defecto. Adems de los disponibles, la herramienta permite la utilizacin de nuevos emuladores por medio de la instalacin de los denominados SDK (Software Development Kit). Un SDK es un conjunto de herramientas asociado a una plataforma mvil (Serie 80, Serie 60 o Serie 40) o a un modelo de telfono mvil concreto, integrado por: Prevericador de clases. Emuladores. Ejemplos de cdigo. Documentacin. El SDK correspondiente a una serie o a un telfono ofrecer al desarrollador las API de programacin correspondientes a los interfaces JSR soportadas por el telfono o la serie a la que representa. En Forum Nokia [71] estn disponibles los SDK de las Series 80, 60 y 40, as como de ciertos modelos Nokia especcos. Cuando un nuevo SDK Java es descargado e instalado, ste se integra en Carbide.j, permitiendo al usuario la emulacin de toda su funcionalidad a travs de su interfaz grca. Adems, si la herramienta est integrada con Eclipse, el nuevo SDK es detectado por dicho IDE mediante una operacin manual. Una vez nalizada la deteccin, Eclipse permite seleccionar el SDK con el que se desea desarrollar una aplicacin. 7. Depuracin de aplicaciones J2ME en el propio dispositivo mvil. Es lo que se denomina ODD (On-Device-Debugging). Este aspecto slo est disponible para Carbide.j versin 1.5 (Julio del 2006) y dispositivos pertenecientes a 30

(a) Atributos de los cheros .JAD y maniesto del .JAR.

(b) Vista previa de los cheros .JAD y maniesto del .JAR, que se van a generar.

Figura 3.8: Pestaa de creacin/edicin de los cheros .JAR y .JAD, en Carbide.j 1.5. la Serie 60 3a Edicin. La conexin entre el dispositivo mvil y el PC donde reside Carbide.j se realiza a travs de Bluetooth o WiFi. A lo largo de la realizacin de este proyecto se ha comprobado que la depuracin ODD falla con programas J2ME con un alto grado de complejidad: multithread, comunicaciones de diferentes tipos (Bluetooth, TCP/IP, UDP, HTTP, etc. 8. Soporte de scripts Ant, para la automatizacin de tareas de compilacin, creacin de paquetes y emulacin. Entre los requisitos de sistema para su instalacin destaca la necesidad de emplear el Sistema Operativo Windows XP Professional (SP2 o posterior) y la del Sun Java Runtime Environment (JRE) v1.4.2_06 o posterior. Su eleccin como software de desarrollo, adems de por sus notables caractersticas, se ha debido al requisito de utilizacin del telfono mvil Nokia 9500, nico terminal disponible al inicio del proyecto. Durante la ejecucin del proyecto han sido empleadas la versin 3.0.1 (Nokia Developers Suite) y las versiones 1.0 y 1.5 (Carbide.j). El uso de esta herramienta se ha centrado en la prueba, vericacin y depuracin de las aplicaciones desarrolladas, en aquellos casos en los que la emulacin era posible. Para profundizar ms en las caractersticas y el manejo de Carbide.j 1.5, vase [67]. 31

(a) Emulador de la Serie 40.

(b) Emulador de la Serie 60.

(c) Emulador de la Serie 80.

Figura 3.9: Emuladores de la Serie 80, Serie 60 y Serie 40 de Nokia, que incorpora Carbide.j 1.5.

32

3.6.3.

NCF (Nokia Connectivity Framework)

Esta herramienta se instala junto con Carbide.j, siendo su funcin principal proporcionar el soporte necesario para permitir el correcto funcionamiento de los emuladores integrados en dicha herramienta. NFC posee las siguientes caractersticas [72][73]: 1. Soporte para diferentes tecnologas de comunicacin. Se puede vericar la conectividad de una aplicacin (conexin a internet, Bluetooth, IrDA, SMS o MMS) sin instalar el programa en el dispositivo nal. 2. Conectividad entre software SDK diferentes. Es posible la comunicacin entre emuladores pertenecientes a SDK diferentes, instalados en un mismo PC. Esta funcionalidad ha sido utilizada en el proyecto para la realizacin de pruebas de comunicacin Bluetooth entre instancias de emulador distintas. 3. Conectividad entre software SDK y dispositivos reales . Permite la conexin entre emuladores pertenecientes a los SDK que residen en el PC y dispositivos hardware con tecnologa Bluetooth, IrDA, SMS o MMS. Gracias a ello, a travs de un programa ejecutado en un emulador, ha sido posible realizar la bsqueda de dispositivos y servicios Bluetooth reales, en una de las pruebas realizadas en el presente Proyecto Fin de Carrera. Vase el apartado de pruebas realizadas 9.1.1.1, para ms detalles. 4. Conectividad entre software SDK y un servidor de aplicaciones. 5. Soporte para monitorizacin de las comunicaciones. Las comunicaciones gestionadas por NCF, pueden ser monitorizadas gracias a una herramienta de log que ofrece la informacin a travs de una consola. Se puede, por ejemplo, analizar el contenido del trco HCI (Host Controller Interface) Bluetooth. 6. Autodeteccin de nuevos SDK. Los nuevos SDK de Nokia instalados se detectan e integran automticamente en NCF. 7. Asistentes o wizards para la integracin de software o hardware, compatible con NCF, no autodetectable. 8. Soporte hardware. NCF admite la conectividad entre emuladores y tarjetas hardware (Nokia D211, Socket Bluetooth, etc.) o entre emuladores y adaptadores USB con tecnologa Bluetooth. La gura 3.10 muestra la pantalla principal del programa. En la ventana derecha, de color blanco, la aplicacin permite arrastrar elementos grcos. Estos elementos grcos representan a componentes software y hardware, integrados en NCF, que el usuario desea 33

Figura 3.10: Aspecto de la ventana principal del programa Nokia Connectivity Framework 1.2. comunicar entre s. Una vez ubicados en el panel, los elementos se conguran segn las propiedades de las comunicaciones que se quiera establecer entre ellos. Tras esta conguracin, queda denido lo que se denomina escenario de test [72] [73]. Finalmente, el usuario puede monitorizar dichas comunicaciones, e incluso llevarlas a cabo de forma real, sin necesidad del dispositivo nal. Un ejemplo de escenario de test es representado en la gura 3.11, donde un emulador perteneciente al Prototype SDK 4.0 S60 MIDP Emulator pretende comunicarse con dispositivos Bluetooth reales, por medio de un adaptador USB Bluetooth. La eleccin de Carbide.j lleva implcito este software, como se ha comentado al inicio del apartado. En todo el perodo de realizacin del proyecto se ha utilizado el programa NCF versin 1.2.

3.6.4.

Nokia PC Suite

Es otro de los programas que se instalan junto con Carbide.j, aunque tambin es posible encontrarlo para descargar individualmente en Forum Nokia [74]. Est orientado ms hacia el usuario que hacia el programador de aplicaciones, ya que se utiliza para el manejo y conguracin de las comunicaciones entre un PC y un telfono Nokia, permitiendo la gestin del dispositivo mvil desde el PC. Posee soporte para conexiones Bluetooth, infrarrojos y 34

Figura 3.11: Escenario de test con un emulador de la Serie 60 y un adaptador USB Bluetooth. USB. En la gura 3.12, que reeja la ventana principal del programa, hay un icono por cada uno de las funciones ofrecidas. Todas las funciones son bastante autoexplicativas. Por ejemplo, PC Suite permite al usuario el acceso a la agenda de contactos, mensajes de texto/multimedia, imgenes y vdeos almacenados en el terminal. Adems, es posible la trasferencia, en ambos sentidos, de cheros de texto, audio y vdeo. Para el desarrollo de las aplicaciones del proyecto, las funciones ms utilizadas han sido: 1. Gestin de conexiones. Esta funcin es muy til para conectar terminales mviles a PC Suite, via Bluetooth, IrDA o USB. En el proyecto se ha empleado la conexin Bluetooth y USB. 2. Instalacin de aplicaciones. Ha sido la funcin ms empleada de todas ya que era necesaria para la realizacin de pruebas en los dispositivos reales. Un proceso de instalacin de una aplicacin J2ME, en un telfono Nokia, se muestra en la gura 3.13. A la izquierda se aprecia el sistema de cheros del equipo donde reside PC Suite. A la derecha, el sistema de cheros de la memoria interna o externa del telfono 35

Figura 3.12: Ventana principal del programa PC Suite 6.8.

36

Figura 3.13: Instalacin de un programa J2ME, en un telfono Nokia N70, mediante PC Suite 6.8. mvil destino. Si hay varios telfonos conectados, la herramienta permite fcilmente la seleccin de cualquiera de ellos en la misma pantalla de instalacin. 3. Gestin de sistema de cheros. Posibilita el envo y la recepcin de cheros entre el terminal mvil y el ordenador. Muy til para almacenar en el PC los cheros de traza obtenidos tras la ejecucin de las aplicaciones en los terminales reales. Vase el captulo 9, para ms informacin. Para la gestin de un telfono mvil Nokia, desde un PC, es imprescindible el uso de este software. Por lo tanto, la utilizacin de telfonos mviles Nokia, durante la ejecucin del presente Proyecto Fin de Carrera, ha llevado implcito el empleo de esta herramienta en sus versiones 6.5 y 6.8.

3.6.5.

Sun Java Wireless Toolkit for CLDC

Sun Java Wireless Toolkit for CLDC (Connected Limited Device Conguration) es un paquete software que incluye herramientas, ejemplos y documentacin, que permite la creacin, emulacin, vericacin y prueba de aplicaciones J2ME. Se trata de un programa gratuito que est disponible en la pgina ocial de Sun Microsystems [75]. Algunas de sus caractersticas ms importantes son [76]: 1. Construccin y creacin de paquetes. Aunque no est orientado a la escritura y edicin de cdigo, Sun Java Wireless Toolkit for CLDC permite todo el proceso subsiguiente: 37

compilacin del cdigo fuente, prevericacin de los cheros .class y creacin de paquetes J2ME. 2. Ejecucin y monitorizacin de aplicaciones. Permite la ejecucin de aplicaciones J2ME mediante el uso de los emuladores que incluye. Esta es la funcin ms completa, que engloba las siguientes funcionalidades: Monitorizacin de la memoria usada (Memory monitor). Visualiza el uso que hace de la memoria la aplicacin. Las medidas que se representan son aproximadas y no tienen por qu coincidir con las medidas correspondientes a los dispositivos reales [76]. Monitorizacin del trco de red (Network monitor). Posibilita el anlisis del trco intercambiado entre instancias de emulador. Entre los protocolos soportados se encuentran [76]: HTTP, HTTPS, SMS, CBS, MMS, TCP, UDP, etc. Proler o medidor de rendimiento (Method Proler). Permite medir la frecuencia de uso de la CPU (Central Processing Unit) y el tiempo de ejecucin de cada mtodo de la aplicacin. En la gura 3.14, se presenta el panel de utilidades de la aplicacin. Opciones de visualizacin de traza (excepciones, llamadas a mtodos, etc.). Soporte de mltiples API. La herramienta ofrece un amplio nmero de API que el programador puede emplear en el desarrollo de sus aplicaciones. En la gura 3.15, se muestran las API seleccionadas, entre todas las disponibles, que se van a incluir en un proyecto determinado. Una gran diferencia con Carbide.j es que los emuladores que Sun Java Wireless Toolkit for CLDC proporciona por defecto son genricos y no se ajustan a ningn dispositivo real en particular. Aqu, es el usuario quien limita las prestaciones de los emuladores que utiliza (API disponibles en el emulador), mediante su seleccin directa (gura 3.15), antes de la creacin de cada paquete. La gura 3.16, muestra la apariencia de algunos de estos emuladores que posee la aplicacin. 3. Firma de aplicaciones. El usuario, gracias a las herramientas de rma y manejo de certicados que Sun Java Wireless Toolkit for CLDC incorpora, puede rmar sus aplicaciones y vericar su comportamiento en los diferentes dominios de seguridad existentes en J2ME. Vase Vase [76] [68] [69], para ms informacin. La sencillez de instalacin y utilizacin, el hecho de ser una herramienta libre, adems de sus interesantes ejemplos y documentacin, han determinado su uso como herramienta de 38

Figura 3.14: Panel de utilidades, en Sun Java Wireless Toookit 2.5 for CLDC Beta 2.

Figura 3.15: Ventana de seleccin de API del proyecto BluetoothDemo en Sun Java Wireless Toolkit 2.5 for CLDC Beta 2. 39

Figura 3.16: Instancias de emulador que se comunican entre s. desarrollo de este proyecto La utilizacin de este software se ha centrado en la simulacin y el rmado de aplicaciones J2ME, permitiendo comparar y contrastar los resultados obtenidos con los de Carbide.j. En el desarrollo del proyecto se han utilizado las versiones 2.3 Beta y 2.5 Beta 2.

3.6.6.

Ethereal

Ethereal es un analizador de protocolos que permite la monitorizacin del trco entrante y saliente de un ordenador a travs de cada uno de sus interfaces fsicos: tarjeta de Ethernet, tarjeta WiFi inalmbrica, etc. Adems, es capaz de decodicar cada uno de los paquetes monitorizados en los campos correspondientes al protocolo de comunicacin utilizado. Un ejemplo de ello se aprecia en la gura 3.17. Ethereal es una herramienta de cdigo abierto, que est disponible en su pgina ocial [77]. Ofrece un conjunto de funcionalidades entre las que destacan [78]: Filtrado del trco entrante/saliente, segn diferentes criterios: tipo de protocolo, direccin IP, direccin MAC, puerto origen, puerto destino, longitud del paquete, etc. Filtrado de visualizacin de paquetes (Display lter), segn diferentes criterios. Almacenamiento de los paquetes capturados. 40

Figura 3.17: Ejemplo de anlisis de un paquete HTTP, en Ethereal 0.10.14. Conguracin del formato de los cheros de almacenamiento, compatible con otras herramientas (formato libpcap). Ethereal ha sido, desde el principio, una herramienta de uso obligatorio, ya que hace posible la monitorizacin del trco que se intercambian dispositivos conectados entre s por medio de redes. Precisamente, la comunicacin existente entre el Servidor de Control Central y el Nodo Inteligente en la arquitectura del apartado 2.1 ha supuesto el punto principal de anlisis de trco. La utilizacin de Ethereal ha sido crucial para la realizacin de pruebas reales de comunicacin y de integracin, entre el Servidor de Control Central (SCC) y el software del nodo central (NI). Vase el apartado de pruebas 9.1.1.2, para ms informacin. Durante la ejecucin del presente Proyecto Fin de Carrera se ha utilizado el Ethereal versin 0.10.14.

41

42

Captulo 4 Dispositivos Hardware utilizados

4.1. Introduccin

En la secciones 2.1 y 2.2, se mencionaron las partes abarcadas en este Proyecto Fin de Carrera. A continuacin, se van a describir los dispositivos hardware utilizados en cada una de ellas: 1. La red de rea corporal se compone de tres dispositivos hardware que son: a) Un telfono mvil Nokia N93, como plataforma hardware del nodo central (NI), con soporte J2ME (CLDC 1.1 y MIDP 2.0) y las API (Application Programming Interface) JSR-82 (Bluetooth API), JSR-75 (File Connection and PIM API), JSR205 (Wireless Messaging API 2.0), JSR-177 (Security and Trust Services API) y JSR-179 (Location API), entre otras [79]. Aunque el Nokia N93 ha sido el modelo principal para el desarrollo de la aplicacin del NI, otros terminales utilizados fueron estos: Nokia 9500, Nokia E61, Nokia N70, Nokia 6680, Nokia 6230 y Sony-Ericsson K608i. b) Un pulsioxmetro Bluetooth, modelo Nonin 4100, fabricado por Nonin Medical [80]. c) Un receptor GPS con tecnologa Bluetooth, modelo Leadtek LR9553X, fabricado por Leadtek [81]. 2. El terminal para recepcin y aviso de alarmas ha sido un telfono mvil con soporte J2ME (CLDC 1.1 y MIDP 2.0) y las API JSR-120 (Wireless Messaging API 1.1) y/o JSR-205 (Wireless Messaging API 2.0) y JSR-75 (File Connection and PIM API), entre otras. 3. El soporte hardware para la aplicacin web de descarga de MIDlets, ha sido un PC con arquitectura LAMP (Linux+Apache Web Server+MySQL+PHP). 43

Figura 4.1: Telfono Nokia 9500.

4.2.

Dispositivos Hardware utilizados para el desarrollo de la aplicacin del NI

En esta seccin se van a tratar todos los terminales mviles empleados para desarrollar el software del nodo central (NI), durante este proyecto. Puesto que la mayora de los telfonos utilizados son terminales Nokia, se recomienda la lectura del apndice C, para poder familiarizarse con las distintas plataformas que Nokia tiene actualmente en el mercado (Serie 80, Serie 60 y Serie 40) y con sus principales caractersticas.

4.2.1.

Telfono Nokia 9500 (Serie 80 2a Edicin)

El Nokia 9500, perteneciente a la Serie 80 2a Edicin, rene caractersticas de PDA (Personal Digital Assitant) y telfono mvil y fue lanzado al mercado a nales de Febrero del ao 2004. Fsicamente es bastante ms grande que los mviles Nokia pertenecientes a las Series 40 y 60, debido principalmente al mayor tamao de su pantalla y su batera (vase la gura 4.1). Las caractersticas ms relevantes de este dispositivo se agrupan en la tabla 4.1 [82]. Aunque inicialmente fue utilizado para el diseo de la aplicacin del nodo central (NI), en ltima instancia ha sido relegado a tareas relacionadas con el desarrollo del software de la UCMM del mdico (vase la gura 2.2), debido a la aparicin de continuos fallos Symbian durante el uso de las comunicaciones Bluetooth. Vase el apartado de pruebas realizadas 9.1.1.1, para ms detalles.

4.2.2.

Telfono Nokia N93 (Serie 60 3a Edicin)

El telfono Nokia N93, mostrado en la gura 4.2, es un telfono mvil de ltima generacin y altas prestaciones, que fue lanzado al mercado a nales de Abril del ao 2006. Pertenece a la Serie 60 3a Edicin y sus principales caractersticas se resumen en la tabla 4.2 [79]. 44

CARACTERSTICA Sistema Operativo Plataforma de desarrollo Banda de frecuencias (MHz) 2 Displays (resolucin y profundidad del color) Cmara Memoria Conexiones de datos Conectividad Local Java (soporte J2ME y API adicionales soportadas) Navegador Mensajera Dimensiones (Longitud x Anchura x Altura) (mm) Peso (g)

DESCRIPCIN Symbian OS v7.0s Serie 80 2a Edicin GSM 850/900/1800/1900 Primario: 640 x 200 (16 bits) Secundario: 128 x 128 VGA Memoria interna de 76 MB, Memmory Card MMC (MultiMedia Card), tamao .Jar no limitado y memoria heap (memoria dinmica) no limitada. EGPRS, GPRS, HSCSD y CSD. Bluetooth, Infrarrojos, USB y WLAN (802.11b). CLDC 1.1 (JSR-139), MIDP 2.0 (JSR-118), JSR-135, JSR-120, JSR-75, JSR-82 (No OBEX) y Nokia UI API. CDC (JSR-36), Foundation Prole (JSR-46) y Personal Prole (JSR-62). HTML sobre TCP/IP y XHTML sobre TCP/IP. MMS+SMIL y SMS. 148 x 56 x 23.6 222 Batera BP-5L 1300 mAh Tiempo de conversacin: hasta 4-6 horas* Tiempo de espera: hasta 200-300 horas* (WLAN desactivada)/ hasta 180-240 horas* (WLAN en espera) *Depende de la tecnologa de acceso de radio, la conguracin de la red del operador y el uso.

Batera [83]

Tabla 4.1: Caractersticas del telfono Nokia 9500 [82].

Este terminal ha sido empleado, mayormente, para el desarrollo de la aplicacin del Nodo Inteligente (NI) y ha sustituido al telfono Nokia 9500, que se haba usado inicialmente con el mismo n. Gracias a que incluye soporte para WiFi, ha hecho posible la realizacin de pruebas de comunicacin real entre el NI y el SCC durante el diseo y desarrollo de la aplicacin. Adems, se ha empleado para comprobar el funcionamiento de las comunicaciones Bluetooth, as como otras funcionalidades de la aplicacin (apartado 9.1.1.4). Para ms detalles sobre las pruebas realizadas se recomienda la lectura del apartado 9.1. 45

Figura 4.2: Telfono Nokia N93.

Figura 4.3: Telfono Nokia E61.

4.2.3.

Telfono Nokia E61 (Serie 60 3a Edicin)

Este telfono, al igual que el Nokia N93, pertenece a la Serie 60 3a Edicin. Aparece en el mercado en Octubre del 2005 y ha sido utilizado en el proyecto para probar la compatibilidad de la aplicacin con otros dispositivos J2ME. Tambin ha resultado til para la depuracin de las comunicaciones Bluetooth (apartado 9.1.1.1) y para la realizacin de pruebas de comunicacin real entre el NI y el SCC (apartados 9.1.1.2, 9.1.1.3 y 9.1.2) ya que consta de tecnologa WiFi. Posee un teclado QWERTY y tiene un aspecto parecido al de una agenda electrnica (vase la gura 4.3). En la tabla 4.3, se reejan sus principales caractersticas [85]. 46

Figura 4.4: Telfono Nokia N70.

4.2.4.

Telfono Nokia N70 (Serie 60 2a Edicin, Feature Pack 3)

El terminal Nokia N70 pertenece a la Serie 60 2a Edicin, Feature Pack 3 (FP3). Es un dispositivo que estaba disponible en el mercado desde nales de Abril de 2005 y cuya apariencia se hace patente en la gura 4.4. Sus caractersticas ms importantes se concentran en la tabla 4.4 [87]. Este dispositivo ha sido utilizado, sobre todo, en test relacionados con la aplicacin del NI, para la vericacin de las comunicaciones Bluetooth (apertura, cierre, reconexin, etc.) (apartado 9.1.1.1) y en pruebas de recepcin de mensajes de texto y multimedia (apartados 9.1.1.4 y 9.2).

4.2.5.

Telfono Nokia 6680 (Serie 60 2a Edicin, Feature Pack 2)

El telfono Nokia 6680 pertenece a la Serie 60 2a Edicin, Feature Pack 2 (FP2). Posee menos caractersticas que el Nokia N70 al ser predecesor de ste (lanzado al mercado a mediados de Febrero de 2005). Su aspecto fsico se muestra en la gura 4.5 y sus caractersticas ms relevantes en la tabla 4.5 [89]. Al igual que el Nokia N70, se ha utilizado en tareas de depuracin y vericacin de las comunicaciones Bluetooth (apartado 9.1.1.1).

4.2.6.

Telfono Nokia 6230 (Serie 40 2a Edicin)

El terminal Nokia 6230 pertenece a la Serie 40 2a Edicin. De menor tamao que los telfonos de la Series 60 y 80, tiene un aspecto como el de la gura 4.6. Su fecha de lanzamiento al mercado tuvo lugar a nales de Octubre del ao 2003. En la tabla 4.6, se ofrece un resumen de sus caractersticas principales [91]. Este telfono ha sido empleado para la realizacin de pruebas de las comunicaciones 47

Figura 4.5: Telfono Nokia 6680.

Figura 4.6: Telfono Nokia 6230.

48

Figura 4.7: Telfono Sony-Ericsson K608i. Bluetooth (apartado 9.1.1.1) y para la recepcin de mensajes texto y multimedia (apartado 9.1.1.4).

4.2.7.

Telfono Sony-Ericsson K608i

El Sony-Ericsson K608i es un telfono 3G, cuya apariencia es la de la gura 4.7. Sus principales caractersticas se renen en la tabla 4.7 [93][94]1 . Este terminal ha sido utilizado en tareas de depuracin de la aplicacin del Nodo Inteligente (NI), vericacin de las comunicaciones Bluetooth (apartado 9.1.1.1) y pruebas de UMTS (apartado 9.1.2).

4.2.8.
4.2.8.1.

Pulsioxmetro Nonin 4100

Qu es la pulsioximetra?

En [96] se dene la pulsioximetra y los conceptos que son necesarios para comprender su medida: La pulsioximetra es un procedimiento no invasivo para medir de forma continua la saturacin arterial de oxgeno (SaO2 ). La SaO2 es la fraccin porcentual de molculas de hemoglobina (Hb) que transportan oxgeno en la sangre arterial.
En esta ltima referencia se da constancia de que K608i es el nombre que Sony-Ericsson dio internacionalmente a su telfono K608.
1

49

En la sangre humana existen dos tipos de hemoglobina, la Oxihemoglobina (HbO2 ), que transporta fundamentalmente oxgeno (O2 ) hasta los tejidos, y la Deoxihemoglobina (HHb), que no est saturada de O2 en su totalidad, y que se haya principalmente en la sangre de las venas. Cuando llega a los pulmones, se satura completamente de oxgeno transformndose en HbO2. A la medida de la SaO2 por pulsioximetra, se le llama medida del SPO2 (Saturation of Peripheral Oxygen). Con esta informacin se puede concluir que las cantidades de molculas de HbO2 y HHb, presentes en la sangre arterial, y el valor del SPO2 se relacionan de la siguiente manera: SP O2( %) =
HbO2 100 HbO2 +HHb

El rango de valores normales del SPO2 es de 95-100 % [96][97]. 4.2.8.2. Cmo se mide el SPO2?

La medida del SPO2 se basa en la relacin que existe entre la cantidad de luz absorbida por una sustancia y la concentracin que sta posee (vase la ley de Beer-Lambert en [98]). Una de las primeras tcnicas de pulsioximetra, basada en este principio, apareci en 1973 de la mano del cientco japons Takuo Aoyagi [99]: Conociendo que las molculas de deoxihemoglobina absorben ms luz roja que las de oxihemoglobina, y que la absorcin de la luz infrarroja no se ve afectada por la presencia de oxgeno en las molculas de hemoglobina, Aoyagi ide un pulsioxmetro que utilizaba una fuente de luz de banda ancha y dos circuitos fotodetectores independientes, enfrentados al emisor, recubiertos por sendos ltros pticos, uno de luz roja y otro de luz infrarroja, respectivamente. El haz de luz atravesaba un tejido corporal, como el dedo de una mano o el lbulo de una oreja, y la cantidad de luz transmitida era medida por ambos circuitos fotodetectores . Ambas medidas eran utilizadas para hallar la relacin entre la parte pulstil de la cantidad de luz roja absorbida y la parte pulstil de la cantidad de luz infrarroja absorbida. Este clculo permita obtener el valor de SPO2, debido exclusivamente a la sangre arterial, y resolva el problema de la existencia de otros tejidos implicados en la medida (sangre venosa, huesos, uas, etc.) [97][100]. En la gura 4.8, se presenta la estructura del pulsioxmetro de Aoyagi y el clculo que realizaba para la obtencin del SPO2 [99]. Los pulsioxmetros actuales se basan en los estudios de Aoyagi, pero aadiendo procesado digital de la seal, de forma que consiguen realizar medidas ms exactas en condiciones 50

FUENTE DE LUZ DE BANDA ANCHA

TORRENTE SANGUNEO (dedo de la mano, lbulo de la oreja, etc.)

FOTODETECTOR ROJO

FOTODETECTOR INFRARROJO

SRojo

SInfrarrojo

FILTRO

FILTRO

ACRojo

DCRojo

ACInfrarrojo

DCInfrarrojo

A/B

A/B

ACRojo DCRojo

ACInfrarrojo DCInfrarrojo

A/B

Medida proporcional al SPO2

Figura 4.8: Pulsioxmetro de Aoyagi [99].

51

(a) Leds arriba y fotodetector abajo.

(b) Fotodetector arriba y leds abajo.

Figura 4.9: LEDs y fotodetector de un pulsioxmetro.

(a) Sensor situado en el dedo de un adulto.

(b) Sensor situado en el pie de un recin nacido.

Figura 4.10: Posibles sensores usados en pulsioximetra. donde antes no era posible realizarlas (paciente en movimiento, existencia de interferencia ptica, etc.)[97][99]. Estos dispositivos utilizan dos haces de luz que son enviados por dos LEDs, uno de luz roja (660 nm) y otro de luz infrarroja (generalmente de 905, 910 o 940 nm), que se hallan enfrentados a un detector fotosensible (vase la gura 4.9) . Los dos LEDs y el fotodetector estn integrados en un sensor que se coloca habitualmente en el dedo de la mano o en el lbulo de la oreja, aunque tambin es posible ubicarlo alrededor del pie, sobre todo en recin nacidos [101] (vase la gura 4.10).

4.2.8.3.

Pulsioxmetro Nonin 4100

El pulsioxmetro Nonin 4100 de Nonin Medical [80] tiene la apariencia que presenta en la gura 4.11. Est compuesto por un sensor cuyo cable se conecta a un circuito elctrico que recoge sus medidas, las procesa para generar los datos nales y, posteriormente, enva dichos datos, mediante Bluetooth, al dispositivo que est conectado con l en ese momento. 52

(a) Aspecto del Nonin 4100.

(b) Componentes del Nonin 4100.

Figura 4.11: Pulsioxmetro Nonin 4100. Adems de Nonin Medical [80], otros fabricantes que proporcionan dispositivos Bluetooth para la monitorizacin de pacientes (pulsioxmetros, glucmetros, electrocardigrafos, etc. ) son Alive Technologies [102][103], Card Guard [104][105], A & D Medical [106][107] o GMP|Wireless Medicine, Inc. [110][111], entre otros [112]. Este dispositivo ofrece datos sobre el SPO2 y el ritmo cardaco, adems de un pletismograma del paciente, que es un diagrama en forma de onda que representa cambios en el volumen del torrente sanguneo y donde cada ciclo cardaco aparece como un pico2 (se aprecia un pico mayor que representa el pulso arterial y otro pico secundario, ms pequeo, asociado al pulso venoso) [113]. Estos datos son medidos por un sensor, situado en el dedo de una mano, y transmitidos a un circuito que se encuentra integrado en la carcasa del dispositivo, va cable. Este mdulo circuital se encarga de recoger la informacin del sensor y la procesa para transmitirla va Bluetooth, segn el formato de las especicaciones [114]3 . Las principales caractersticas tcnicas de este dispositivo vienen resumidas en la tabla 4.8 [114].

Desde el punto de vista del funcionamiento, el Nonin 4100 ofrece dos comportamientos diferentes [114]: Modo 1: Enva un paquete de 3 bytes de datos por segundo. Ofrece informacin sobre el SPO2, el pulso y algunos ags de estado (estado de las medidas, del sensor, etc.).
El pletismograma permite la deteccin de afecciones cardacas (contraccin ventricular prematura, taquicardia, brilacin, etc.), respiratorias, etc. [113]. 3 El documento de especicaciones disponible actualmente en la web, es el de la ltima versin del rmware del producto. El rmware del pulsioxmetro utilizado en el proyecto corresponde a la versin 12.
2

53

3 bytes/s

1 s. 3 bytes Paquete i

1 s. 3 bytes Paquete i+1 Paquete i+2

t0

t0+1

t0+2

t(s)

(a) Funcionamiento en Modo 1.

375 bytes/s

1 s. 125 bytes Paquete i 125 bytes Paquete i+1 125 bytes Paquete i+2 Paquete i+3

1 s. 125 bytes Paquete i+4 Paquete i+5 Paquete i+6

t0

t0+1/3

t0+2/3

t0+1

t0+4/3

t0+5/3

t0+2

t(s)

(b) Funcionamiento en Modo 2.

Figura 4.12: Modos de funcionamiento del pulsioxmetro Nonin 4100 [114]. Modo 2: Enva tres paquetes de 125 bytes de datos por segundo, es decir, 375 bytes de datos por segundo. Cada paquete de 125 bytes contiene informacin sobre el SPO2, el pulso, varias muestras de pletismograma y algunos ags de estado (estado de las medidas, del sensor, de la batera, etc.). Ambos modos de funcionamiento se muestran en la gura 4.12, donde se aprecia la diferencia del rgimen binario de datos usado en cada uno: 3 bytes/s en el Modo 1 por 375 bytes/s en el Modo 2. Mientras el Modo 1 ofrece informacin bsica de monitorizacin, el Modo 2 se corresponde con un modo ms detallado donde la principal diferencia, adems del mayor nmero de medidas realizadas para el SPO2 y el ritmo cardaco [114], es la produccin de un pletismograma que ser de gran utilidad, sobre todo, en casos de enfermedades cardiovasculares y/o respiratorias [113]. El formato de los paquetes de Modo 1 es el de la gura 4.13 [114]. Los bits HR8-HR0 generan el ritmo cardaco medido, donde HR0 es el bit menos signicativo y HR8 el bit ms signicativo. Anlogamente, el valor del SPO2 viene dado por los bits SP6-SP0. Obviamente, ambos valores carecen de signo. Los bits SNSD (Sensor 54

Figura 4.13: Formato de los paquetes de Modo 1 [114]. Disconnect), OOT (Out Of Track), LPRF (Low Perfusion), MPRF (Marginal Perfusion) y ARTF (Artifact) son bits de estado, activos a nivel alto (1), que se interpretan de la siguiente manera [114]: SNSD: Activo cuando el dispositivo no recibe seal del sensor. Esta falta de seal puede ser debida a que el paciente tiene quitado el sensor o porque el cable se ha desconectado. OOT: Se activa si hay seal de pulso intermitente (primeros instantes de la medicin cuando el usuario se coloca el sensor, momentos en los que el pulsioxmetro pasa de una persona a otra, etc.) y cuando el usuario se quita el pulsioxmetro y se produce ausencia de seal. LPRF: Indica que las medidas obtenidas por el sensor son de baja calidad, debido a causas siolgicas. MPRF: Igual que el LPRF, pero esta vez la seal medida posee una calidad aceptable. ARTF: Su activacin advierte que las medidas pueden ser no exactas, a causa de movimientos bruscos del paciente (agitacin de la mano, del brazo, etc.). El formato de los paquetes de Modo 2 es el de la gura 4.14 [114]. En primer lugar, hay que sealar la distincin que se hace entre los conceptos de paquete y trama. Un paquete es la informacin que el Nonin 4100 transmite en Modo 2, cada tercio de segundo, que est compuesto de 25 tramas, cada una de 5 bytes. En la gura 4.14, el paquete queda representado como la estructura global (125 bytes), mientras que la trama se corresponde con 5 bytes, en este caso representada por cada una de las las del paquete.

55

TRAMA (5 bytes) Byte1 1 2 3 4 5 6 7 8 9 10 11 PAQUETE (125 bytes) 12 13 14 15 16 17 18 19 20 21 22 23 24 25 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 Byte2 STATUS* STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS STATUS Byte3 PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH PLETH Byte4 HR MSB HR LSB SpO2 SREV reservado reservado reservado BTS SpO2-D SpO2-Fast SpO2-B-B reservado reservado E-HR MSB E-HR LSB E-SpO2 E-SpO2-D reservado reservado HR-D MSB HR-D LSB E-HR-D MSB E-HR-D LSB reservado reservado Byte5 CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK CHK

*NOTA: El primer byte de estado (STATUS) de un paquete, tiene su bit menos significativo siempre a 1. El resto de los bytes de estado, del mismo paquete, lo tienen siempre a 0. NOTA 1: El primer byte de cada trama siempre vale 1. NOTA 2: Los bytes reservados no estn definidos.

Figura 4.14: Formato de los paquetes de Modo 2 [114].

56

Byte de estado (STATUS) BIT7 1 BIT6 SNSD BIT5 ARTF BIT4 OOT BIT3 SNSA BIT2 BIT1 BIT0

YPRF SYNC* RPRF GPRF

*Nota: El bit SYNC del primer byte de estado del paquete, siempre vale 1. Para el resto de los bytes de estado del mismo paquete, vale 0.

Figura 4.15: Bits del byte de estado, en el Modo 2. A primera vista, llama la atencin cmo el primer byte de todas las tramas que integran el paquete siempre tiene el valor 1. Este patrn puede ser utilizado, por ejemplo, para asegurar una lectura correcta de los datos. En la segunda columna se encuentran los bytes de estado (STATUS). Cada uno de estos bytes presenta informacin de estado parecida a la que ya se ofreca en el Modo 1. En la gura 4.15, se visualizan los bits que lo componen, todos ellos activos a nivel alto (1). Los bits SNSD, ARTF y OOT poseen el mismo signicado. Ahora aparecen nuevos bits como SNSA (Sensor Alarm), GPRF (Green Perfusion), YPRF (Yellow Perfusion), RPRF (Red Perfusion) y SYNC (Synchronization), que se interpretan como sigue [114]: SNSA: Si est activo seala que los datos del sensor no son vlidos para su anlisis. RPRF: Indica que la amplitud del pletismograma, el SPO2 y el ritmo cardaco han sido obtenidos mediante el anlisis de una seal, medida por el sensor, de baja calidad (el ujo sanguneo no tena las caractersticas ptimas para la realizacin de las medidas en ese instante). YPRF: Igual que el RPRF, pero en esta vez la seal medida tiene calidad media. GPRF: dem que el RPRF, pero en este caso la seal medida tiene calidad alta. SYNC: Es un bit que sirve para sincronizar el ujo de datos, de ah que slo est activo en el primer byte de estado de cada paquete (guras 4.14 y 4.15), es decir, cada veinticinco tramas. Con la ayuda de este bit SYNC y del bit ms signicativo de cada uno de los bytes de estado (siempre activo a 1), es posible volver a sincronizar el ujo si ste perdi previamente el sincronismo. Un problema de difcil depuracin, ha sido la continua prdida de sincronizacin del ujo de bytes procedentes del pulsioxmetro Nonin 4100. A pesar de volver a sincronizar dicho ujo, continuamente se producan prdidas de sincronismo.Vase el apartado de pruebas realizadas 9.1.1.1, para ms detalles. Los bytes etiquetados como PLETH constituyen veinticinco muestras del pletismograma del paciente, que el pulsioxmetro va generando a lo largo del tiempo. Se tratan de valores de 8 57

HR-MSB
BIT7 X BIT6 X BIT5 X BIT4 X BIT3 X BIT2 X BIT1 HR8 BIT0 HR7

HR-LSB
BIT7 X BIT6 HR6 BIT5 HR5 BIT4 HR4 BIT3 HR3 BIT2 HR2 BIT1 HR1 BIT0 HR0

SPO2
BIT7 X BIT6 SP6 BIT5 SP5 BIT4 SP4 BIT3 SP3 BIT2 SP2 BIT1 SP1 BIT0 SP0

NOTA: Los bits X no estn definidos en las especificaciones.

Figura 4.16: Estructura genrica de los bytes HR-MSB, HR-LSB y SPO2. bits sin signo (rango de 0-255). La cuarta columna contiene los valores calculados del SPO2 y del ritmo cardaco, segn diferentes criterios4 , as como otra informacin (SREV (Firmware Revision) y BTS (Battery Status)) como la versin del rmware del dispositivo y el estado actual de la batera. La estructura genrica de los bytes HR-MSB (Heart Rate-Most Signicant Byte), HR-LSB (Heart Rate-Least Signicant Byte) y SPO2, vlida para todas las variantes de ritmo cardaco y SPO2 que ofrece el pulsioxmetro (HR, SPO2, HR-D, SPO2-D, etc.), se reeja en la gura 4.16. La forma en la que se genera el valor del ritmo cardaco y del SPO2, a partir de sus bytes correspondientes, es la misma que la explicada anteriormente para el Modo 1. Los bits HR8-HR0 dan el valor del pulso y los bits de SP6-SP0 el del SPO2. Por ltimo, los bytes CHK corresponden con el checksum de cada una de las veinticinco tramas, donde CHK= (Byte1+Byte2+Byte3+Byte4) mdulo 256. Por defecto, el pulsioxmetro trabajar en Modo 2 si una vez establecida la conexin Bluetooth, el otro extremo no indica explcitamente el modo de funcionamiento. Con ese n, el Nonin 4100 espera durante cinco segundos un posible establecimiento del modo, a travs de la recepcin de las cadenas ASCII D1 y D2 que indican el establecimiento del Modo 1 y Modo 2, respectivamente. Si la conguracin se realiza con xito, el pulsioxmetro devuelve el carcter ASCII ACK (equivale a un byte con valor hexadecimal 0x06). En caso contrario (si la cadena ACII enviada no es correcta o el dispositivo no pudo cambiar al modo que se le indica), devuelve el carcter ASCII NACK (equivale a un byte con valor hexadecimal 0x15). En la gura 4.17, se muestra un ejemplo de establecimiento de la
Los valores pueden ser actualizados, con cada latido (modo estndar) o cada segundo y medio (modo display). Adems pueden ser promediados cada cuatro u ocho latidos. Para ms detalles vase [114].
4

58

conexin en el pulsioxmetro Nonin 4100.

4.2.9.

GPS Leadtek 9553X

El GPS Leadtek 9553X, fabricado por Leadtek [81], se presenta en la gura 4.18. Es un receptor GPS, dotado de tecnologa Bluetooth, pensado para su conexin con dispositivos PDA, telfonos mviles, smart phones, etc. Aunque el mdulo GPS 9553X de Leadtek ha sido adquirido para este proyecto, en el mercado existen otros dispositivos similiares fabricados por Belkin [115][116], EMTAC Technology Corp. [117][118], Nokia [119][120] o Globalsat Technology Corporation [121][122], entre otros [123]. Sus principales caractersticas tcnicas vienen resumidas en la tabla 4.9 [124]. El uso del chipset SiRF StarIII, que ofrece una alta sensibilidad (-159 dBm) y un bajo consumo [125], hace posible que la duracin de la batera pueda prolongarse hasta un mximo de 8/11 horas [124]. Por otra parte, el hecho de implementar el perl SPP permite su utilizacin con un amplio conjunto de dispositivos Bluetooth. Adems, es compatible con aquellas PDA que tengan los sistemas operativos Palm OS o Windows CE [124]. Puesto que los datos generados por el Leadtek 9553X siguen el formato especicado por el protocolo NMEA-0183 [127], este mdulo GPS puede trabajar con todo tipo de sistemas de localizacin y navegacin compatibles con dicho protocolo. El sistema GPS ha sido compatible, por ejemplo, para la extraccin de los datos de longitud, latitud, altitud, velocidad, etc. a travs del uso de la JSR-179 (Location API), que se incluye en el telfono Nokia N93. Vase el apartado 5.2.4.2.4, para ms informacin. En la gura 4.19, se presenta el formato de las sentencias NMEA-0183 [128][129] recibidas mediante la aplicacin HyperTerminal de Windows XP, a travs de una comunicacin Bluetooth entre un PC y el GPS Leadtek 9553X. Todas las sentencias NMEA-0183 comienzan con el carcter $ y terminan con la cadena de caracteres CRLF (CR=Retorno de carro=\r, LF=Fin de lnea=\n). La cadena GP que se encuentra en todas las lneas, justo detrs del carcter $, hace referencia a que el dispositivo que est empleando el protocolo NMEA-0183 es un dispositivo GPS. En dicha gura se puede ver el modo en que, en un intervalo temporal de un segundo, se produce un ciclo de transmisin de datos del GPS, desde la lnea $GPGGA... hasta la lnea $GPRMC..., ambas incluidas. El ciclo se va repitiendo indenidamente aunque los datos proporcionados no sean vlidos (falta de cobertura GPS). En este caso particular, la mayora de los campos que deberan ir ocupados por datos vlidos se omiten. De todas las sentencias que aparecen en 4.19, hay que destacar las sentencias $GPGGA y $GPRMC donde estn contenidos los datos de localizacin ms relevantes (longitud, latitud, altitud, velocidad, hora y fecha de los datos, etc.): 59

RECHAZO A UN ESTABLECIMIENTO DE MODO, POSTERIOR ESTABLECIMIENTO DEL MODO POR DEFECTO Y CAMBIO AL MODO 1

NONIN 4100

DISPOSITIVO BLUETOOTH

ESTABLECIMIENTO DE LA CONEXIN BLUETOOTH

...

TIMEOUT 5 s.

Dx con x 0,3,4,...,9 o cadena desconocida (en ASCII) NACK (en ASCII)

1/3 s. Datos de Modo 2 (125 bytes) 1/3 s. Datos de Modo 2 (125 bytes) 1/3 s.

Datos de Modo 2 (125 bytes) ...

CIERRE DE LA CONEXIN BLUETOOTH

...

ESTABLECIMIENTO DE LA CONEXIN BLUETOOTH D1 (en ASCII)

...

TIMEOUT 5 s.

ACK (en ASCII)

1 s. Datos de Modo 1 (3 bytes)

1 s. Datos de Modo 1 (3 bytes)

1 s. Datos de Modo 1 (3 bytes) ...

NOTA: Tras el cierre de la conexin Bluetooth y su posterior apertura, es posible establecer el Modo 1 ("D1" en ASCII) o el Modo 2 ("D2" en ASCII).

Figura 4.17: Ejemplo de establecimiento del modo de funcionamiento, en el Nonin 4100.

60

...

...

...

Figura 4.18: GPS Leadtek 9553X. 1. La sentencia $GPGGA contiene informacin sobre el instante en el que se produjo la captura, datos de posicionamiento 3D (longitud, latitud y altitud), precisin de la medida, etc. Un ejemplo de su anlisis se presenta en la tabla 4.10. 2. La sentencia $GPRMC contiene informacin sobre el instante y la fecha en la que tuvo lugar la captura, datos de posicionamiento 2D (longitud y latitud), velocidad, etc. Un ejemplo de su anlisis se presenta en la tabla 4.11. La obtencin de estos datos (latitud, longitud, velocidad, etc.), por parte de la aplicacin del nodo central (NI), se ha llevado a cabo de dos maneras diferentes: 1. Utilizando la interfaz JSR-179 (Location API for J2ME). En este caso, los datos de posicionamiento no son adquiridos directamente del ujo Bluetooth, sino a travs de llamadas que la Location API posee a tal efecto. Las principales ventajas de su utilizacin son la facilidad de extraccin de los datos, la abilidad de los datos obtenidos y la posibilidad de cambiar, automticamente y cuando sea necesario7 , el mtodo de localizacin empleado (GPS, Enhanced Observed Time Difference (EOTD) for GSM, Time of Arrival (TOA), Cell-ID, etc. [130]). El cambio slo es posible si el terminal dispone de otros mtodos de localizacin alternativos (por ejemplo, tiene contratado un servicio del operador) activados. Este enfoque simplica bastante la tarea del programador, ya que la complejidad del cdigo recae en el Location API. 2. Analizando las sentencias NMEA-0183, directamente, del ujo Bluetooth. Para ello, es necesario la lectura de las sentencias, a travs de la interfaz JSR-82 (Java APIs for Bluetooth), y su posterior interpretacin. En este caso se delega toda la responsabilidad de las operaciones en el programador, quien debe disear el cdigo para la lectura de sentencias, decodicacin y extraccin de los datos de inters e intercambio entre mtodos de localizacin disponibles, cuando corresponda.
El usuario se encuentra en una posicin donde no haya cobertura para el mtodo de localizacin empleado en ese momento.
7

61

(a) Sentencias NMEA-0183, con datos no vlidos.

(b) Sentencias NMEA-0183, con datos vlidos.

Figura 4.19: Sentencias NMEA-0183, en situaciones con cobertura y sin cobertura GPS.

62

4.3.

Dispositivos Hardware utilizados para el desarrollo de la aplicacin de recepcin y aviso de alarmas

Los terminales utilizados para el desarrollo de la aplicacin de recepcin y aviso de alarmas, han sido algunos de los descritos anteriormente en el apartado 4.2. As, por ejemplo, los telfonos Nokia N93 y N70 se han empleado en pruebas de transmisin y recepcin de mensajes de texto (SMS). Vase el apartado de pruebas realizadas 9.2, para ms detalles.

4.4.

Dispositivos Hardware utilizados para el desarrollo de la aplicacin web para la descarga de MIDlets

En cuanto al hardware utilizado en el diseo y desarrollo de la aplicacin web para la descarga de aplicaciones, ste se resume en el uso de un PC de sobremesa con las siguientes caractersticas : Procesador: Intel Pentium IV a 2.8 GHz, 1024 KB de memoria cach de nivel 2 (L2) y tecnologa Hyper-Threading. Memoria RAM: 1024 MB Disco duro: 180 GB Arquitectura LAMP: 1. Sistema Operativo Linux, distribucin Kubuntu, versin del kernel 2.6.17. 2. Servidor Apache, versin 2.2.4. 3. MySQL versin 5.0.37. 4. PHP 5.2.1. El Sistema Operativo Linux podra ser, en principio, de cualquier distribucin conocida [131] (Debian, Ubuntu, SUSE, etc.) ya que el software restante, necesario para completar la arquitectura LAMP, es decir, Apache, MySQL y PHP puede ser instalado de forma sencilla y conjunta a travs del paquete XAMPP [132], disponible en [133]. Este paquete permite la utilizacin de varios sistemas operativos, como son: Linux, Windows, Solaris, etc. [132][133]. XAMPP tambin est disponible junto con una gua de instalacin en [134].

63

CARACTERSTICA Sistema Operativo Plataforma de desarrollo Banda de frecuencias (MHz) 2 Displays (resolucin y profundidad del color) 2 Cmaras (resolucin de imagen y de vdeo) Memoria Conexiones de datos Conectividad Local Java (soporte J2ME y API adicionales soportadas) Navegador Mensajera Dimensiones (Longitud x Anchura x Altura) (mm) Peso (gramos)

DESCRIPCIN Symbian OS v9.1 Serie 60 3a Edicin GSM 900/1800/1900 y WCDMA 2100. Primario: 240 x 320 (18 bits) Secundario: 128 x 36 (16 bits) Primaria: 2048 x 1536 (Resol. vdeo 640 x 480) Secundaria (frontal): 288 x 352 (Resol. vdeo 176 x 144) Memoria interna de 50 MB, Memmory Card Mini SD (Secure Digital), tamao .Jar no limitado y memoria heap (memoria dinmica) no limitada. WCDMA, EGPRS, GPRS, HSCSD y CSD. Bluetooth v2.0, Infrarrojos, UPnP, USB 2.0 y WLAN (802.11b/g). CLDC 1.1 (JSR-139), MIDP 2.0 (JSR-118), JSR-135, JSR-172, JSR-177, JSR-179, JSR-180, JSR-184, JSR-185, JSR-205, JSR-75, JSR-82 y Nokia UI API. HTML 4.0 (XHTML 1.1), HTML sobre TCP/IP, WAP 2.0, XHTML sobre TCP/IP y XHTML sobre WAP. MMS, MMS+SMIL y SMS. 118.2 x 55.5 x 28.2 180 Batera BP-6M 1100mAh Tiempo en conversacin: hasta 3.7 h. (WCDMA)/hasta 5.1 h. (GSM)* Tiempo en espera: hasta 10 das (WCDMA)/hasta 10 das (GSM)* *Depende de la tecnologa de acceso de radio, la conguracin de la red del operador y el uso.

Batera [84]

Tabla 4.2: Caractersticas del telfono Nokia N93 [79].

64

CARACTERSTICA Sistema Operativo Plataforma de desarrollo Banda de frecuencias (MHz) Display (resolucin y profundidad del color) Cmara (resolucin de imagen y de vdeo) Memoria Conexiones de datos Conectividad Local Java (soporte J2ME y API adicionales soportadas) Navegador Mensajera Dimensiones (Longitud x Anchura x Altura) (mm) Peso (gramos)

DESCRIPCIN Symbian OS v9.1 Serie 60 3a Edicin GSM 850/900/1800/1900 y WCDMA 2100. 320 x 240 (24 bits) No dispone de cmara. Memoria interna de 75 MB, Memmory Card Mini SD, tamao .Jar no limitado y memoria heap (memoria dinmica) no limitada. WCDMA, EGPRS, GPRS, HSCSD y CSD. Bluetooth v1.2, Infrarrojos, USB y WLAN (802.11b/g). CLDC 1.1 (JSR-139), MIDP 2.0 (JSR-118), JSR-135, JSR-172, JSR-177, JSR-179, JSR-180, JSR-184, JSR-185, JSR-205, JSR-75, JSR-82 y Nokia UI API. HTML sobre TCP/IP, WAP 2.0 y XHTML sobre TCP/IP. IM, MMS+SMIL y SMS. 118 x 70 x 14 144 Batera BP-5L 1500mAh Tiempo en conversacin: hasta 2.2-5.0 h. (WCDMA)/hasta 4.3-9.5 h. (GSM)* Tiempo en espera: hasta 13-19 das (WCDMA)/hasta 13-17 das (GSM)* *Depende de la tecnologa de acceso de radio, la conguracin de la red del operador y el uso.

Batera [86]

Tabla 4.3: Caractersticas del telfono Nokia E61 [85].

65

CARACTERSTICA Sistema Operativo Plataforma de desarrollo Banda de frecuencias (MHz) Display (resolucin y profundidad del color) 2 Cmaras (resolucin de imagen y de vdeo) Memoria Conexiones de datos Conectividad Local Java (soporte J2ME y API adicionales soportadas) Navegador Mensajera Dimensiones (Longitud x Anchura x Altura) (mm) Peso (g)

DESCRIPCIN Symbian OS v8.1a Serie 60 2a Edicin, FP3 GSM 900/1800/1900 y WCDMA 2100. 176 x 208 (18 bits) Primaria: 1600 x 1200 (Resol. vdeo 352 x 288) Secundaria (frontal): 640 x 480 Memoria interna de 22 MB, Memmory Card MMC, tamao .Jar no limitado y memoria heap (memoria dinmica) no limitada. WCDMA, EGPRS, GPRS, HSCSD y CSD. Bluetooth v2.0 y USB 2.0. CLDC 1.1 (JSR-139), MIDP 2.0 (JSR-118), JSR-120, JSR-135, JSR-172, JSR-184, JSR-185, JSR-75, JSR-82 y Nokia UI API. HTML sobre TCP/IP, WAP 2.0 y XHTML sobre TCP/IP. IM, MMS+SMIL y SMS. 108.8 x 53 x 22.8 126 Batera BL-5C 970mAh Tiempo de conversacin: hasta 4 horas* Tiempo de espera: hasta 11 das* *Depende de la tecnologa de acceso de radio, la conguracin de la red del operador y el uso.

Batera [88]

Tabla 4.4: Caractersticas del telfono Nokia N70 [87].

66

CARACTERSTICA Sistema Operativo Plataforma de desarrollo Banda de frecuencias (MHz) Display (resolucin y profundidad del color) 2 Cmaras Memoria Conexiones de datos Conectividad Local Java (soporte J2ME y API adicionales soportadas) Navegador Mensajera Dimensiones (Longitud x Anchura x Altura) (mm) Peso (g)

DESCRIPCIN Symbian OS v8.0a Serie 60 2a Edicin, FP2 GSM 900/1800/1900 y WCDMA 2100. 176 x 208 (18 bits) Primaria: 1.3 Megapxeles Secundaria (frontal): VGA Memoria interna de 10 MB, Memmory Card RS-MMC (Reduced Size MultiMedia Card), tamao .Jar no limitado y memoria heap (memoria dinmica) no limitada. WCDMA, EGPRS, GPRS, HSCSD y CSD. Bluetooth v1.2 y USB 2.0. CLDC 1.1 (JSR-139), MIDP 2.0 (JSR-118), JSR-120, JSR-135, JSR-184, JSR-185, JSR-75, JSR-82 y Nokia UI API. HTML sobre TCP/IP, WAP 2.0 y XHTML sobre TCP/IP. MMS+SMIL y SMS. 108.4 x 55.2 x 21.2 133 Batera BL-5C 900mAh Capacidad: hasta 2.2-3.3 horas (WCDMA)/hasta 3-6 horas (GSM) Tiempo de conversacin: hasta 3 horas* Tiempo de espera: hasta 14 das* *Depende de la tecnologa de acceso de radio, la conguracin de la red del operador y el uso.

Batera [90]

Tabla 4.5: Caractersticas del telfono Nokia 6680 [89].

67

CARACTERSTICA Sistema Operativo Plataforma de desarrollo Banda de frecuencias (MHz) Display (resolucin y profundidad del color) Cmara Memoria Conexiones de datos Conectividad Local Java (soporte J2ME y API adicionales soportadas) Navegador Mensajera Dimensiones (Longitud x Anchura x Altura) (mm) Peso (g)

DESCRIPCIN Nokia OS Serie 40 2a Edicin GSM 900/1800/1900 128 x 128 (16 bits) VGA Memoria interna de 3 MB, tamao .Jar limitado (125 KB) y memoria heap (memoria dinmica) limitada (1 MB). EGPRS, GPRS, HSCSD y CSD. Bluetooth, Infrarrojos y USB. CLDC 1.1 (JSR-139), MIDP 2.0 (JSR-118), JSR-120, JSR-135, JSR-185, JSR-82 (No OBEX) y Nokia UI API. WAP 2.0 y XHTML sobre TCP/IP. MMS+SMIL y SMS. 103 x 44 x 20 97 Batera BL-5C 850 mAh Tiempo de conversacin: hasta 3-5 horas* Tiempo de espera: hasta 150-300 horas* *Depende de la tecnologa de acceso de radio, la conguracin de la red del operador y el uso.

Batera [92]

Tabla 4.6: Caractersticas del telfono Nokia 6230 [91].

68

CARACTERSTICA Sistema Operativo Banda de frecuencias (MHz) Display (resolucin y profundidad del color) Cmara Memoria Conexiones de datos Conectividad Local Java (soporte J2ME y API adicionales soportadas) Navegador Mensajera Dimensiones (Longitud x Anchura x Altura) (mm) Peso (g)

DESCRIPCIN Propietario Sony-Ericsson GSM/GPRS 900/1800/1900 y WCDMA 2100 (UMTS). 176 x 220 (18 bit) 1.3 Megapxeles Memoria interna de 32 MB, no permite expansin de memoria (tarjeta externa), tamao .Jar no limitado y memoria heap (memoria dinmica) limitada (512 kB-1.5 MB). WCDMA, GPRS, HSCSD y CSD Bluetooth, Infrarrojos y USB. CLDC 1.1, MIDP 2.0, JSR-120, JSR-135, JSR-172, JSR-184, JSR-185, JSR-234, JSR-75, JSR-82 y Nokia UI API. Interfaz de depuracin KDWP (KVM Debug Wire Protocol). WAP 2.0 y XHTML. SMS, EMS, MMS y MMS+SMIL 105 x 45 x 19 100 (incluida batera) Batera 900 mAh Tiempo de conversacin: hasta 2 horas y 10 minutos* (WCDMA)/ hasta 8 horas y 15 minutos* (GSM) Tiempo de espera: hasta 290 horas* (WCDMA)/ hasta 370 horas* (GSM) *Depende de la tecnologa de acceso de radio, la conguracin de la red del operador y el uso.

Batera [95]

Tabla 4.7: Caractersticas del telfono Sony-Ericsson K608i [93][94].

CARACTERSTICA Rango del SPO2 ( %) Rango del ritmo cardaco (latidos/minuto) Longitudes de onda Rojo/Infrarrojo (nanmetros) Batera Duracin de la batera en funcionamiento continuo (horas) Especicacin Bluetooth Perles Bluetooth implementados Firmware Dimensiones (Longitud x Anchura x Altura) (mm) Peso (g)

VALOR/RANGO 0-100 18-300 660/910 (3mW de potencia nominal) 2 pilas AA (1.5 V cada una) 120 V1.1 SPP (Serial Port Prole) V12 7.62 x 6.96 x 3.40 (sin pulsera) 125 (pilas incluidas)

Tabla 4.8: Caractersticas principales del pulsioxmetro Nonin 4100 [114].

69

CARACTERSTICA Chipset Leds de indicacin de estado Batera recargable (no removible) Duracin de la batera en funcionamiento continuo (horas) Especicacin Bluetooth Perles Bluetooth implementados Datum5 TTFF6 (Time To First Fix) Cold/Warm/Hot (promediado) Protocolo Dimensiones (Longitud x Anchura x Altura) (mm) Peso (gramos)

VALOR/RANGO SiRF StarIII 2 leds, uno para Bluetooth y otro para GPS 5V 5 %V DC 8 (full charge)/11 (trickle charge) V1.2 SPP (Serial Port Prole) WGS-84 (World Geodetic System 1984) (por defecto) 42/38/1 segundos NMEA-0183 (National Marine Electronics Association-0183) (57600bps por defecto) 61.4 x 42.3 x 25.4 44 (batera incluida)

Tabla 4.9: Caractersticas principales del GPS Leadtek 9553X [124].

70

El anlisis de la sentencia $GPGGA,171224.490,3642.6621,N,00426.0324,W,1,03,50.0,94.0,M,48.5,M0000*47 sera el siguiente: VALOR GGA 171224.490 3642.6621,N, 00426.0324,W, DESCRIPCIN Indicacin de datos de localizacin GPS (Global Positioning System Data Fix). Captura realizada a las 17:12:24.490 UTC (Coordinated Universal Time). Latitud 36 grados 42.6621 N (Norte). Longitud 4 grados 26.0324 W (Oeste). Calidad de la captura, que puede ser: 0 = captura no vlida 1 = captura GPS (Standard Positioning Service (SPS)) 2 = captura DGPS (Differential GPS) 3 = captura PPS (Precise Positioning Service) 4 = captura RTK (Real Time Kinematic) 5 = captura Float RTK 6 = captura DR (Dead Reckoning) estimada (Disponible en NMEA-0183 v2.3) 7 = modo de Entrada Manual (Manual input mode) 8 = modo de Simulacin (Simulation mode) Nmero de satlites sincronizados Dilucin horizontal de la posicin (Horizontal dilution of position) (la medida es ms precisa cuanto menor sea este valor). Altitud del dispositivo, en metros (M), sobre/bajo el nivel del mar (si este valor es negativo, el dispositivo est por debajo del nivel del mar). Separacin, en metros (M), entre el elipsoide WGS84 y el nivel del mar (si este valor es negativo, el nivel del mar est por debajo del elipsoide WGS84). Tiempo, en segundos, desde la ltima captura DGPS. Nmero de identicacin (ID) de la estacin DGPS. Checksum (siempre comienza por *).

03 50.0

94.0,M,

48.5,M, (campo vaco) 0000 *47

Tabla 4.10: Anlisis de una sentencia $GPGGA.

71

El anlisis de la sentencia $GPRMC,171224.490,A,3642.6621,N,00426.0324,W,1.75,110.28,140307,A*7F sera el siguiente: VALOR RMC 171224.490 A 3642.6621,N, 00426.0324,W, 1.75 110.28 140307 (campo vaco),(campo vaco), A *7F DESCRIPCIN Datos GPS mnimos recomendados (Recommended Minimum Specic GPS/TRANSIT Data). Captura realizada a las 17:12:24.490 UTC (Coordinated Universal Time). Estado de los datos (A=Activo, V=Vaco). Latitud 36 grados 42.6621 N (Norte). Longitud 4 grados 26.0324 W (Oeste). Velocidad en nudos (multiplicar por 1.85 para obtener Km/h). ngulo de seguimiento (en grados). Fecha (14 de Marzo de 2007). Variacin magntica (en grados), E(Este)/W(Oeste), Indicador del modo de captura (A=Automtica, D=Diferencial, E=Estimada, N=No vlida, S=Simulacin, null) donde slo los valores A y D indican datos ables. (Disponible en NMEA-0183 v2.3) Checksum (siempre comienza por *). Tabla 4.11: Anlisis de una sentencia $GPRMC.

72

Captulo 5 Desarrollo del software del Nodo Inteligente

5.1. Introduccin

Este captulo abarca todo el diseo y desarrollo de la aplicacin software del Nodo Inteligente, realizada en el mbito de este proyecto. Los principales aspectos que se van a abordar son los siguientes: El lenguaje o lenguajes de programacin utilizado/s. Las losofas de diseo empleadas en cada una de las aplicaciones creadas. El diseo de las aplicaciones, descrito desde distintos niveles de abstraccin y utilizando como herramienta de modelado diagramas UML. Se partir desde el nivel de abstraccin ms bsico (subsistemas que componen el software objeto de estudio) y se alcanzar, de forma gradual, el nivel ms complejo (funcionamiento e interaccin entre elementos software que componen cada subsistema). Para el desarrollo de este aspecto, cabe destacar la utilizacin de herramientas de modelado propias del diseo software. Se han empleado, pues, diagramas UML (Unied Modeling Language) que complementan y facilitan la comprensin de las ideas que se tratan por escrito.

5.2.
5.2.1.

Desarrollo software
Lenguaje de programacin

El lenguaje de programacin empleado para la implementacin de esta aplicacin ha sido J2ME. La principal ventaja que ofrece, frente a otros lenguajes de programacin como C++ (aplicaciones Symbian), es la portabilidad. Gracias a ella, todo programa J2ME puede 73

Anlisis

Anlisis

...

Anlisis

Diseo

Diseo

...

Diseo

Implementacin

Implementacin

...

Implementacin

Pruebas

Pruebas

...

Pruebas

Incremento 1

Incremento 2

...

Incremento k

Figura 5.1: Fases que componen cada ciclo del modelo incremental. funcionar en diferentes plataformas mviles (Nokia, Sony-Ericsson, Motorola, Siemens, etc.) con soporte J2ME, no limitndose a una plataforma o a unos dispositivos concretos (Symbian).

5.2.2.
5.2.2.1.

Filosofa de diseo
Modelo de Ingeniera del Software

La tcnica de Ingeniera del Software empleada para el desarrollo de la aplicacin del nodo central (NI), ha sido el denominado modelo incremental [135][136] que permite el aumento de funcionalidad del software creado, en cada ciclo del diseo. En la gura 5.1, se presenta un esquema de las fases que incluye cada uno de esos ciclos de diseo. La eleccin de este modelo ha estado motivada porque es el que mejor se ajusta, de entre todos los modelos de diseo, al tipo de aplicacin a desarrollar, cuyos requisitos son: 1. El software ha de ejecutarse en dispositivos con capacidades limitadas (CPU, memoria, alimentacin, etc.), principalmente, en telfonos mviles. 2. En la aplicacin se deben emplear varios tipos de comunicaciones simultneamente: Bluetooth para la comunicacin entre el Nodo Inteligente (NI) y la iBAN. HTTP(S)/TCP-UDP para la comunicacin entre el Nodo Inteligente (NI) y el Servidor de Control Cetral (SCC). 74

De estos requisitos, se desprende la necesidad de llevar a cabo un desarrollo progresivo, de forma que cada vez que se completa la implementacin de un mdulo ste debe ser probado antes de continuar extendiendo su funcionalidad. 5.2.2.2. Patrn de Diseo software

El diseo software se ha llevado a cabo utilizando un patrn de diseo conocido como patrn MVC (Modelo-Vista-Controlador). Este patrn de diseo se caracteriza por denir una separacin lgica entre la funcionalidad de la aplicacin y la visualizacin de sta para el usuario (GUI, Graphical User Interface), de manera que el software permite cambiar la GUI, sin alterar sus datos o su funcionalidad, y viceversa. Esta divisin lgica facilita la reutilizacin del cdigo y la escalabilidad del mismo, es decir, que la adicin o reduccin de funcionalidad conlleve pocos cambios en el programa. En el MVC se tienen los siguientes elementos: Un modelo. El modelo incluye toda la lgica de la aplicacin: almacenamiento/gestin de datos, funcionalidad del programa, etc. Tiene asociado un nico controlador, que ser el correspondiente a la vista de usuario (GUI) que est activa en cada momento. Una o varias vistas. La vista representa la interfaz grca de usuario (GUI). Cada vista posee un aspecto diferente y es diseada conforme a la funcionalidad que el programa quiere proporcionar. Por ejemplo, la vista de un juego de cartas es diferente a la vista de un programa que realiza una conversin bidireccional entre euros y pesetas o a la de un editor de texto. Una vista se corresponde con un nico controlador. Uno o varios controladores. El controlador se encarga de recoger los eventos de la vista (seleccin de una accin, pulsacin de un botn, mostrar un listado de los datos almacenados, etc.) y de mapear la accin correspondiente en el modelo. Una vez realizada la accin, generalmente el resultado se muestra a travs de la vista correspondiente. Tambin sirve para que el modelo pueda usar la vista, evitando el manejo directo de sta. Un controlador puede disponer de una o varias vistas y tiene asociado un nico modelo. La gura 5.2, reeja la relacin entre los diferentes elementos que integran este patrn de diseo. Se observa cmo a travs del controlador, la vista puede comunicarse con el modelo para la realizacin de una accin solicitada por el usuario, o bien para pedirle datos que ella necesita, y a su vez el modelo puede utilizar la vista correspondiente, para mostrar el resultado de la accin solicitada o un mensaje por pantalla. Un ejemplo de software que se ajusta muy bien al MVC, y fcil de entender, sera una aplicacin del juego del ajedrez. En este programa toda la dinmica del juego (tablero, piezas y reglas) constituira el modelo. Las vistas seran los diferentes aspectos visuales que podran 75

Modelo

Accin

Controlador

Evento

Vista

Resultados de la accin/Mostrar mensaje en Vista

Actualizar Vista

(a) Diagrama de despliegue UML.

Modelo

Controlador -Controlador asociado 1 -Controlador asociado 1 1..*

Vista

-Modelo asociado

-Vista asociada

(b) Diagrama de clases UML.

Figura 5.2: Patrn de diseo Modelo-Vista-Controlador (MVC). tener el tablero y las piezas (por ejemplo, vista futurista, vista clsica, vista infantil, etc.). Por su parte, los controladores estaran asociados a cada una de esas vistas (controlador para la vista futurista, controlador para la vista clsica, controlador para la vista infantil, etc.) y se encargaran de responder a los estmulos de cada jugador y de actualizar la situacin del juego (tablero y piezas) en el modelo y en su vista correspondiente. As, por ejemplo, cuando un jugador mueve de forma invlida una pieza del tablero, en la vista (GUI), el controlador se percata de la accin, sta se comunica al modelo, el modelo seala al controlador que la jugada no es posible y el controlador se encargara de mostrar un mensaje de error a travs de la vista. Esta interaccin se reeja en la gura 5.3. El desarrollo del software del nodo central (NI) se ha basado en el patrn MVC. Por ello, en el apartado 5.2.8 se presentar el uso exacto de este patrn.

5.2.3.

Anlisis de la aplicacin del Nodo Inteligente

El anlisis de cada uno de los subsistemas o mdulos que constituyen la aplicacin del nodo central (NI), presentados en el apartado 2.3.1, constar de las siguientes secciones: 1. Estructura. En este apartado se detallarn los componentes software de cada uno de los subsistemas del nodo inteligente (NI), cuyas funciones y objetivos se indicaron en el apartado 2.3.1, mediante el uso de diagramas de componentes UML, siempre que sea necesario1 . 2. Diseo software.
1

Si el subsistema bajo estudio posee un nico componente software, se prescindir de esta seccin.

76

Modelo

Controlador

Vista

Movimiento invlido de una pieza Peticin del usuario para realizar un movimiento Realizar un movimiento sobre el tablero

[else]

[Movimiento no vlido] Actualizar situacin del juego

Actualizar la vista

[Error]

Dibujar mensaje de error

[else] Actualizar tablero y piezas

Figura 5.3: Diagrama de actividad que muestra la interaccin entre los elementos del patrn MVC, en una aplicacin software del juego del ajedrez.

Software del NI

subsistema Comunicaciones Bluetooth

subsistema Comunicaciones SCC

subsistema Gestin de comandos y control

subsistema Procesamiento y gestin de alarmas

Figura 5.4: Diagrama de componentes que representa los mdulos que integran el software del NI. 77

Se trata de una seccin donde se detallarn, mediante la ayuda de diagramas de clases UML, las clases que implementan los diferentes componentes de la estructura del subsistema, indicando sus principales atributos y mtodos. Adems, se mencionarn las interfaces JSR (Java Specication Request) empleadas. 3. Funcionamiento. En esta seccin, mediante el uso de diagramas UML de actividad y/o de secuencia, se explicar el funcionamiento del subsistema sometido a estudio.

5.2.4.
5.2.4.1.

Subsistema de comunicaciones Bluetooth

Estructura

Este subsistema se divide en varios componentes, tal y como se muestra en la gura 5.5, que son: Componente para la bsqueda de dispositivos (Inquiry) y servicios (Service Discovery) Bluetooth. Como su nombre indica, lleva a cabo la bsqueda de dispostivos y servicios Bluetooth, y el subsiguiente establecimiento de la conexin con dichos servicios. Componente para la comunicacin Bluetooth. Proporciona la funcionalidad comn a todas las conexiones Bluetooth que el Nodo Inteligente establece. Como se ver a continuacin, es empleado por otros componentes de este mdulo. Componente para la comunicacin con el pulsioxmetro Nonin 4100. Posee las funciones necesarias para llevar a cabo la comunicacin Bluetooth entre el nodo central (NI) y el pulsioxmetro Nonin 4100. Hace uso del componente para la comunicacin Bluetooth. Componente para la comunicacin con el GPS. Tiene la funcionalidad que el Nodo Inteligente necesita para comunicarse con el dispositivo GPS. Tambin utiliza el componente para la comunicacin Bluetooth.

5.2.4.2.

Diseo software

Para la implementacin de algunas de las clases pertenecientes a este subsistema, ha sido necesaria la utilizacin de la interfaz JSR-82 (Java APIs for Bluetooth) [137], que permite la comunicacin del terminal mvil con dispositivos Bluetooth, mediante el uso 78

subsistema Comunicaciones Bluetooth

componente Bsqueda de dispositivos (Inquiry) y de servicios (Service Discovery) Bluetooth

componente Comunicacin Bluetooth

use

use

componente Comunicacin con el GPS

componente Comunicacin con el pulsioxmetro Nonin 4100

Figura 5.5: Diagrama de componentes del mdulo de comunicaciones Bluetooth. del protocolo RFCOMM, L2CAP u OBEX2 . El empleo de la interfaz JSR-82 se ha limitado al uso del paquete javax.bluetooth que proporciona las clases necesarias para el utilizar los protocolos RFCOMM (Radio Frequency Communication) y L2CAP (Logical Link Control and Adaptation Protocol). En particular, la aplicacin ha utilizado el Perl de Puerto Serie o Serial Port Prole (SPP) que funciona sobre el protocolo RFCOMM, ya que es el perl implementado por los componentes de la red de rea corporal (iBAN): pulsioxmetro Nonin 4100 y GPS. Adems, se ha hecho uso de la interfaz JSR-179 (Location API) [130] para la obtencin de los datos del GPS (latitud, longitud y velocidad). A pesar de ello, tal y como se coment en el apartado 4.2.9, tambin se ha desarrollado el cdigo necesario para la extraccin de estos datos, a partir del ujo Bluetooth (uso de la JSR-82), mediante el anlisis de las sentencias NMEA-0183. Tambin ha sido necesaria la utilizacin de la interfaz JSR-75 (File Connection and PIM API) [138], para poder realizar el almacenamiento de la informacin de localizacin (GPS) en un chero. La gura 5.6 muestra las principales clases que implementan cada uno de los componentes del subsistema de comunicaciones Bluetooth, que se explican y analizan a continuacin.

5.2.4.2.1. Componente para la bsqueda de dispositivos (Inquiry) y de servicios (Service Discovery) Bluetooth Est integrado, principalmente, por las clases Bluetooth, Inquiry, ServiceDiscovery, InquiryListener y ServiceDiscoveryListener. El diagrama de la gura 5.7, reeja la relacin que existe entre estas clases, as como sus atributos y mtodos ms importantes: Bluetooth. Esta clase integra toda la funcionalidad necesaria para llevar a cabo la
La especicacin JSR-82 no obliga al fabricante a implementar el protocolo OBEX. Es un aspecto opcional que el API implementado por el telfono proporcione esta funcionalidad.
2

79

Inquiry.java

componente Bsqueda de dispositivos (Inquiry) y de servicios (ServiceDiscovery) Bluetooth

componente Comunicacin Bluetooth ServiceDiscovery.java

InquiryListener.java

Bluetooth.java

ServiceDiscoveryListener.java

BTComm.java

Status.java

LocationApiLauncher.java

Status.java

JSRTester.java

Queue.java componente Comunicacin pulsioxmetro Nonin 4100

Decoder2.java Queue.java componente Comunicacin con el GPS FrameBuilder.java

DataBuffer.java

Decoder1.java

BTracer.java

NoninBTHandler.java

Parser.java

GPSBTHandler.java

Record.java

Figura 5.6: Diseo software de cada uno de los componentes del mdulo de comunicaciones Bluetooth.

80

ServiceDiscoveryListener + + + + csd: CServiceDiscovery repeatServiceSearch: boolean = false ServiceDiscoveryListener() setCServiceDiscovery(CServiceDiscovery) : void isRepeatServiceSearch() : boolean setRepeatServiceSearch(boolean) : void initiateComms() : void + + + + + + + +

ServiceDiscovery SPP: UUID = new UUID(0x1101) {readOnly} uuidSet: UUID ([]) = new UUID[]{ SPP } {readOnly} attrSet: int ([]) = null {readOnly} remoteDevices: Vector searches: Vector sdl: ServiceDiscoveryListener ServiceDiscovery() setServiceDiscoveryListener(ServiceDiscoveryListener) : void setRemoteDevices(Vector) : void startSearchServices() : void cancelSearchServices() : void -serviceDiscovery 1

-sdl

-sdl

Bluetooth + + + + + inquiry: Inquiry il: InquiryListener serviceDiscovery: ServiceDiscovery sdl: ServiceDiscoveryListener Bluetooth(Hashtable) getInquiry() : Inquiry getServiceDiscovery() : ServiceDiscovery setCInquiry(CInquiry) : void setCServiceDiscovery(CServiceDiscovery) : void

Los mtodos deviceDiscovered() y inquiryCompleted() estn vacos, ya que estn asociados a la bsqueda de dispositivos (Inquiry) y se implementan en la clase InquiryListener.

Los mtodos servicesDiscovered() y serviceSearchCompleted() estn vacos, ya que estn asociados a la bsqueda de servicios (Service Discovery) y se implementan en la clase ServiceDiscoveryListener.

-il

1 -inquiry Inquiry -il 1 + + + + il: InquiryListener Inquiry() setInquiryListener(InquiryListener) : void startInquiry() : void cancelInquiry() : void 1

InquiryListener + + + indexes: Hashtable remoteDevices: Vector ci: CInquiry InquiryListener(Hashtable) setCInquiry(CInquiry) : void clearRemoteDevices() : void filterRemoteDevices() : void

interface DiscoveryListener implements + + + + deviceDiscovered(RemoteDevice, DeviceClass) : void inquiryCompleted(int) : void servicesDiscovered(int, ServiceRecord[]) : void serviceSearchCompleted(int, int) : void

implements

Figura 5.7: Diagrama de clases del componente para la bsqueda de dispositivos (Inquiry process) y de servicios (Service Discovery process) Bluetooth.

81

bsqueda de dispositivos (Inquiry process) y servicios (Service Discovery process) Bluetooth. Como se observa en la gura 5.7, contiene cuatro atributos que se corresponden con las clases con las que mantiene una relacin de composicin, que son: Inquiry, InquiryListener, ServiceDiscovery y ServiceDiscoveryListener. Inquiry. Como indica su nombre, sirve para la realizacin de la bsqueda de dispositivos Bluetooth. Esta clase ofrece un mtodo para el inicio del proceso de bsqueda y otro para su cancelacin, que son startInquiry() y cancelInquiry(), respectivamente. InquiryListener. Los objetos de esta clase actan como listener de eventos concernientes a la bsqueda de dispositivos. Estos eventos pueden ser el encuentro de un nuevo dispositivo, la nalizacin de la bsqueda a causa de un error, cancelacin de la bsqueda por parte del usuario, etc. Adems, destaca por implementar los mtodos deviceDiscovered(RemoteDevice rd, DeviceClass dc) y inquiryCompleted(int code), pertenecientes a la interfaz DiscoveryListener [137], relacionados con el proceso de Inquiry. El mtodo deviceDiscovered(RemoteDevice rd, DeviceClass dc) es ejecutado cada vez que se encuentra un nuevo dispositivo Bluetooth, a diferencia del mtodo inquiryCompleted(int code), que es ejecutado una sola vez cuando el proceso de bsqueda de dispositivos ha nalizado. ServiceDiscoveryListener. Esta clase es anloga a InquiryListener, pero en relacin a la bsqueda de servicios. Se encarga, adems, de la implementacin de los mtodos servicesDiscovered(int transID, ServiceRecord[] serviceRecord) y serviceSearchCompleted(int transID, int respCode), de la interfaz DiscoveryListener, relacionados con el proceso de bsqueda de servicios. El mtodo servicesDiscovered(int transID, ServiceRecord[] serviceRecord) se ejecuta cuando se han encontrado los servicios Bluetooth correspondientes al dispositivo sobre el que se inici dicha bsqueda. Por otro lado, el mtodo serviceSearchCompleted(int transID, int respCode) se ejecuta cuando la bsqueda sobre el dispositivo objetivo, ha nalizado. Se ha de puntualizar que las clases Inquiry, InquiryListener, ServiceDiscovery y ServiceDiscoveryListener hacen uso de la interfaz JSR-82 para la implementacin de los procesos de bsqueda de dispositivos y servicios Bluetooth. 5.2.4.2.2. Componente para la comunicacin Bluetooth Est formado nicamente por la clase BTComm, que agrupa los atributos y las operaciones comunes que caracterizan una comunicacin Bluetooth. BTComm es utilizada por las clases NoninBTHandler y GPSBTHandler, que gestionan las comunicaciones Bluetooth con el pulsioxmetro Nonin 4100 y el mdulo GPS Leadtek 9553X, respectivamente. En el diagrama de la gura 5.8 se presenta la relacin que hay entre estas clases, junto con sus principales atributos y mtodos: 82

interface Communication + + + openComm() : void closeComm() : void destroyComm() : void

implements

BTComm # # # + + + + + + + + BREAK: int = 2000 {readOnly} timeToSleep: int = BREAK btAddress: String url: String sc: StreamConnection dos: DataOutputStream dis: DataInputStream c: Controller BTComm(String, String) setController(Controller) : void reOpenComm() : void reOpenComm(int) : void resetTimeToSleep() : void readStream(int) : byte[] getDis() : DataInputStream getDos() : DataOutputStream

Pre-condition {if (JSR-179 NO es soportada){ //Usar JSR-82 (BTComm). }else{ //Usar JSR-179. }

extends

uses

NoninBTHandler

GPSBTHandler

Componente comunicacin Nonin 4100

Componente comunicacin GPS

Figura 5.8: Diagrama de clases del componente para la comunicacin Bluetooth.

83

BTComm. Sus atributos contienen la informacin necesaria para caracterizar una comunicacin Bluetooth (URL de la conexin establecida, direccin Bluetooth del extemo remoto, ujos o streams de entrada/salida, etc.) y sus mtodos proporcionan las operaciones necesarias para el manejo y la gestin de enlaces Bluetooth. Como se observa en el diagrama (gura 5.8), implementa la interfaz Communication que incluye la funcionalidad bsica para la gestin de comunicaciones Bluetooth, HTTP, TCP, UDP, etc. (vase el apartado 5.2.5), a travs de los siguientes mtodos: openComm(). Sirve para abrir una comunicacin. closeComm(). Se utiliza para cerrar una comunicacin. destroyComm(). Permite cerrar la comunicacin y liberar todos los recursos utilizados por sta. Adems de estas operaciones, BTComm incluye mtodos para la recuperacin de enlaces Bluetooth cados, reOpenComm() y reOpenComm(int time), as como para el manejo de los streams de entrada/salida Bluetooh, getDis() y getDos(), y lectura de datos, readStream(int length). NoninBTHandler y GPSBTHandler. Aunque se han incluido en la gura 5.8, estas clases pertenecen a otros componentes que se detallarn a continuacin. No obstante, con su inclusin se quiere enfatizar el hecho de que la clase BTComm es empleada en otros componentes del subsistema de comunicaciones Bluetooth. En la gura 5.8, se ilustra cmo NoninBTHandler hereda de la clase BTComm, mientras que GPSBTHandler la utiliza, slo, en el caso de que la interfaz JSR-179 (Location API) no sea implementada por el telfono mvil donde reside la aplicacin.

5.2.4.2.3. Componente para la comunicacin con el pulsioxmetro Nonin 4100 El elemento principal de este componente es la clase NoninBTHandler, que a su vez hace uso de las clases Decoder1, Decoder2, DataBuffer, Queue, Status y de la interfaz Synchronization. Tambin, es subclase (extiende) de BTComm (apartado 5.2.4.2.2) y emplea la clase NoninThresholdManager, que pertenece al subsistema de procesamiento y gestin de alarmas que se analizar ms adelante, en el apartado 5.2.7. Todas estas clases, sus relaciones, atributos y mtodos estn reejados en el diagrama de la gura 5.9: NoninBTHandler. Tal y como se ha sealado en el apartado 5.2.4.2.2, esta clase hereda de BTComm (uso de la interfaz JSR-82) con el n de realizar la gestin de la conexin Bluetooth que se establece con el pulsioxmetro Nonin 4100. En este caso, la herencia est justicada puesto que la lectura de datos siempre debe realizarse, de forma directa, 84

interface Synchronization + isSynchronized(byte[]) : boolean -d implements implements

Decoder2 + + + + + + + + + + + + + + + + + + + + INVALID_FRAME: byte ([]) = { 0x01, (b... {readOnly} LPACKET: int = 125 {readOnly} LFRAME: int = 5 {readOnly} LPLETH: int = 25 {readOnly} MODULE: int = 256 {readOnly} Decoder2() getLPACKET() : int isSynchronized(byte[]) : boolean isPacketOk(byte[]) : boolean repairFluxOfData(byte[], byte[]) : int repairFluxOfData2(byte[], byte[], byte[]) : int STATUS(byte[]) : boolean[] PLETH(byte[]) : int[] HR(byte[]) : int SPO2(byte[]) : int E_HR(byte[]) : int E_SPO2(byte[]) : int HR_D(byte[]) : int SPO2_D(byte[]) : int E_HR_D(byte[]) : int E_SPO2_D(byte[]) : int SREV(byte[]) : byte BTS(byte[]) : byte SPO2Fast(byte[]) : byte SPO2BB(byte[]) : byte + + + + + + +

Decoder1 LPACKET: int = 3 {readOnly} Decoder1() getLPACKET() : int isSynchronized(byte[]) : boolean isPacketOk(byte[]) : boolean STATUS(byte[]) : boolean[] HR(byte[]) : int SPO2(byte[]) : int

-d2

-d1

Componente para el procesamiento y gestin de alarmas NoninThresholdManager

-noninThresholdManager

Componente de Comunicacin Bluetooth BTComm

DataBuffer + + + + + + + + TDATA: int = 5 baos: ByteArrayOutputStream isBaosCompleted: boolean DataBuffer() isEmpty() : boolean isCompleted() : boolean setTDATA(int) : boolean getTDATA() : int writeBuffer(byte[]) : void readBuffer() : byte[] reset() : void

extends BTComm Runnable NoninBTHandler + + + + + + + + MODE1: int = 1 {readOnly} MODE2: int = 2 {readOnly} DEFAULTMODE: int = MODE2 {readOnly} d: Synchronization d1: Decoder1 d2: Decoder2 mode: int length: int dataBuffer: DataBuffer data: Queue nbthThread: Thread sensorDisconnected: Status noninThresholdManager: NoninThresholdManager NoninBTHandler(String, String, Controller) getData() : Queue isSensorDisconnected() : boolean run() : void setModeParameters(int) : void setDefaultMode() : void resetDataStore() : void setNoninData(byte[]) : void setModeInternally(int) : boolean setMode(int) : boolean configureValue(int, byte[]) : boolean configureMonitoringTime(int) : boolean destroyBTHandler() : void

-dataBuffer

Queue + + + + + v: Vector Queue() setElement(byte[]) : void getElement() : byte[] isEmpty() : boolean reset() : void -data

Status + + + status: boolean Status(boolean) getStatus() : boolean setStatus(boolean) : void -sensorDisconnected

Figura 5.9: Diagrama de clases del componente para la comunicacin con el pulsioxmetro Nonin 4100.

85

a travs del ujo o stream asociado a la comunicacin Bluetooth3 . La lectura continua del ujo Bluetooth es la tarea principal de esta clase, por lo que es realizada por una thread de Java que se encarga de: 1. Leer paquetes de datos procedentes del pulsioxmetro segn el modo de funcionamiento establecido (Modo 1 o Modo 2). 2. Concatenarlos en un buffer, que est representado por el atributo de la clase DataBuffer, para obtener el nmero de segundos de monitorizacin jado en la conguracin (parmetro tiempo de monitorizacin). 3. Almacenar la informacin concatenada en una cola FIFO (First Input First Output), implementada por la clase Queue. Al insertar los datos en la cola FIFO, implcitamente, se ponen a disposicin de un objeto gestor de datos, de la clase DataHandler, que se encargar de recopilar la informacin obtenida de la iBAN y de enviarla, posteriormente, al Servidor de Control Central (SCC). Vase el apartado 5.2.5.2.5 para obtener ms informacin sobre este objeto gestor de datos (DataHandler). Adicionalmente, la clase posee los mtodos necesarios para ejecutar los comandos de conguracin del Nonin 4100 que son enviados por el servidor (apndice D). Aunque la recepcin y gestin de estos comandos es realizada por el subsistema que se detalla en el apartado 5.2.6, se han de mencionar los parmetros congurables asociados al pulsioxmetro, que son los siguientes (apndice D): Modo de funcionamiento. Puesto que el dispositivo Nonin 4100 tiene dos modos de funcionamiento, se da la posibilidad de establecer uno u otro a travs del mtodo setMode(int mode). Tiempo de monitorizacin. Es el nmero de segundos de informacin de monitorizacin que debe ser concatenada antes de estar disponible para el objeto gestor de datos (apartado 5.2.5.2.5). Se modica a travs del mtodo congureMonitoringTime (int time). Valores umbrales. Es posible congurar los valores umbrales (valores mnimo y mximo) de Heart Rate y SPO2 que servirn de referencia para la generacin de alarmas (vase el apartado 5.2.7). Se puede hacer mediante el uso del mtodo congureValue (int type, byte[] thresholds). Synchronization. Es una interfaz que proporciona un nico mtodo, boolean isSynchronized (byte[] data), para comprobar si un array de bytes sigue un formato especco establecido. En caso armativo, devuelve un valor a true considerando que el paquete analizado est sincronizado con el ujo de informacin del que proviene, es
A diferencia del mdulo GPS, donde la lectura de datos puede realizarse usando las interfaces JSR-82 o JSR-179, la nica forma de obtener los datos procedentes del Nonin 4100 es leyendo directamente de la conexin Bluetooth (JSR-82).
3

86

decir, es conforme al formato establecido. Este mtodo debe ser implementado por las clases que cumplen con la interfaz. Decoder1 y Decoder2. Poseen la funcionalidad necesaria para decodicar los paquetes de informacin procedentes del Nonin 4100, en el Modo 1 y en el Modo 2, respectivamente. Ambas clases implementan el interfaz Synchronization, por lo que dado un array de bytes de Modo 1 o Modo 2, comprueba si cumple o no el formato de los paquetes denido en las especicaciones del pulsioxmetro [114]. Por lo tanto, son muy tiles para la deteccin de la prdida de sincronismo del ujo Bluetooth, para la recuperacin del sincronismo, para la comparacin entre los valores medidos y los umbrales, etc. DataBuffer. Se trata de un buffer para almacenar la informacin procedente del pulsioxmetro antes de ponerla a disposicin del objeto gestor de datos (apartado 5.2.5.2.5). Hace posible concatenar x segundos de datos de monitorizacin, segn la conguracin del Nonin 4100 establecida. Este valor x puede ser modicado a travs de su atributo TDATA que ser uno de los parmetros que el servidor podr congurar remotamente (vase el comando MONITORING TIME dentro del apndice D). Queue. Esta clase acta como almacn de paquetes de datos concatenados procedentes del objeto de la clase DataBuffer. A esta cola tiene acceso el objeto gestor de datos (apartado 5.2.5.2.5), que nalmente enviar la informacin al Servidor de Control Central (SCC). Status. Almacena un estado que puede ser consultado y/o modicado. En particular, el atributo de esta clase incluido en NoninBTHandler (sensorDisconnected) representa el estado del enlace Bluetooth con el pulsioxmetro: true signica que el dispositivo est desconectado y false que est conectado. Su lectura permite avisar al Servidor de Control Central cuando el Nonin 4100 ha perdido la conexin con el Nodo Inteligente. NoninThresholdManager. Permite detectar si los valores de Heart Rate y SPO2, una vez decodicados, se encuentran dentro de los umbrales prejados. Un anlisis completo de esta clase se llevar a cabo en el apartado 5.2.7. Para concluir, se ha de destacar el hecho de que la clase NoninBTHandler constituye el pilar bsico para que la comunicacin y la gestin del pulsioxmetro Nonin 4100 se realicen correctamente, de ah su alta complejidad, que se hace patente en el diagrama de la gura 5.9.

5.2.4.2.4. Componente para la comunicacin con el GPS Este componente es bastante similar al anterior, pero est asociado a la comunicacin 87

con el GPS Leadtek 9553X. Su clase principal es GPSBTHandler que emplea otras clases como JSRTester, FrameBuilder, Utils, BTracer, Queue, Status LocationApiLauncher, Parser y Record para proporcionar toda su funcionalidad. Adems, utiliza la clase BTComm (JSR82), si la interfaz Location API (JSR-179) no es implementada por el terminal mvil donde se ejecuta la aplicacin (apartado 5.2.4.2.2), y la clase GPSThresholdManager, que forma parte del subsistema de procesamiento y gestin de alarmas que se explicar posteriormente en el apartado 5.2.7. El diagrama de la gura 5.105.11, ilustra la relacin que existe entre estas clases, as como sus atributos y operaciones ms importantes: GPSBTHandler. Gestiona la conexin Bluetooth con el GPS Leadtek 9553X. En el caso de utilizar la interfaz JSR-179 para lo obtencin de los datos del GPS [130], las clases involucradas se inicializan a travs de la creacin de un objeto de la clase LocationApiLauncher. En otro caso, si se emplea la interfaz JSR-82, se crea una thread de Java para realizar una lectura continua del ujo Bluetooth, junto con otras tareas: 1. Leer tramas NMEA-0183 del ujo Bluetooth a travs de un objeto de la clase BTComm. 2. Interpretar la informacin leda, empleando la clase Parser, para obtener los datos de latitud, longitud y velocidad. 3. Generar nuevas tramas con el formato establecido en el protocolo de comunicacin entre el Nodo Inteligente y el Servidor de Control Central (SCC) (vase el apndice D). Para ello, utiliza la clase FrameBuilder. 4. Almacenar las nuevas tramas generadas en una cola FIFO (First Input First Output), implementada por la clase Queue, a la que tiene acceso el objeto gestor de datos (apartado 5.2.5.2.5) para enviarlas posteriomente al servidor. Hay que destacar, que la clase tambin proporciona varios mtodos que permiten la conguracin del dispositivo GPS a travs de comandos que son enviados por el Servidor de Control Central (SCC) (apndice D). El subsistema del apartado 5.2.6 se encarga de recibir estos comandos, que dar lugar a la modicacin de los siguientes parmetros congurables (apndice D): Modo de funcionamiento. Para el GPS se denen dos modos de funcionamiento: 1. Modo NO_VERBOSE. Es un modo en el que no se envan los datos del GPS al SCC, sino que se almacenan en un chero de texto dentro del terminal mvil donde reside la aplicacin del NI. 2. Modo VERBOSE. Los datos del GPS se envan al SCC en todo momento. Mediante el mtodo setMode(int mode) se puede establecer un modo u otro. 88

JSRTester + + + + + JSRTester() isJSR120Supported() : boolean isJSR205Supported() : boolean isJSR179Supported() : boolean isJSR177Supported() : boolean

Utils

use FrameBuilder

Pre-condition {if (JSR-179 NO es soportada){ //Usar JSR-82 (BTComm) }else{ //Usar JSR-179 (LocationApiLauncher) }

use use Runnable GPSBTHandler ~ ~ ~ ~ ~ ~ ~ ~ + + + + + + + + + DATA_NOT_AVAILABLE: String = "0.000000 N;0.0... {readOnly} NOVERBOSEMODE: int = 1 {readOnly} VERBOSEMODE: int = 2 {readOnly} DEFAULTMODE: int = VERBOSEMODE {readOnly} SLEEP_TIME: int = 300 {readOnly} btComm: BTComm mode: int data: Queue gpsbthThread: Thread sensorDisconnected: Status gpsThresholdManager: GPSThresholdManager lal: LocationApiLauncher dis: DataInputStream startType: int = Parser.TYPE_START type: int = Parser.TYPE_NA record: Record = new Record() CR: int = 13 LF: int = 10 ch: int output: String bTracer: BasicTracer GPSBTHandler(String, String, Controller) getData() : Queue isSensorDisconnected() : boolean run() : void getStream() : DataInputStream receiveMessages() : void processGpsData(int, Record) : void processGpsFrame(String) : void setMode(int) : boolean configureValue(int, byte[]) : boolean configureMonitoringTime(int) : boolean destroyBTHandler() : void destroyThread() : void destroyComm() : void -btComm BTComm Componente de Comunicacin Bluetooth

Componente para el procesamiento y gestin de alarmas

-gpsThresholdManager

GPSThresholdManager

-data

Queue

-sensorDisconnected

Status

-lal

LocationApiLauncher

-bTracer

use

use

Record + + + + + + + speed: String = "" latitude: String = "" latitudeDirection: String = "" longitude: String = "" longitudeDirection: String = "" quality: String = "" reset() : void + + + + +

Parser TYPE_NA: int = -1 {readOnly} TYPE_START: int = -2 {readOnly} TYPE_GPRMC: int = 0 {readOnly} TYPE_GPGGA: int = 1 {readOnly} parse(String, Record) : int

Pre-condition {if (JSR-179 NO es soportada){ //Usar JSR-82 (BTComm) }else{ //Usar JSR-179 (LocationApiLauncher) }

Tracer BasicTracer + + + + + + + + + + BasicTracer(String) writeTimeStamp() : void writeString(String) : void writeByteArray(byte[]) : void writeString2(String) : void writeByteArray2(byte[]) : void writeLongWithSemiColon(long) : void writeLong(long) : void writeLongWithLn(long) : void writeln() : void

{if (JSR-179 NO es soportada){ //Usar Parser y Record. }else{ //Usar las clases que inicializa LocationApiLauncher }

Figura 5.10: Diagrama de clases del componente para la comunicacin con el GPS. Clases principales asociadas al uso de las interfaces JSR-82 y JSR-179 y otras clases de uso general.

89

LocationListener LocationManager interface ProviderStatusListener + + + providerSelectedEvent() : void providerNotFoundEvent() : void providerOutOfServiceEvent() : void + + + + gpsbth: GPSBTHandler = null LocationManager(ProviderStatusListener, GPSBTHandler) locationUpdated(LocationProvider, Location) : void providerStateChanged(LocationProvider, int) : void destroyLocationProvider() : void deregisterLocationListener(LocationProvider) : void resetLocationProvider(LocationProvider) : void use

implements

-lm

-gpsbth

LocationApiLauncher + + + + + gpsbth: GPSBTHandler = null lm: LocationManager = null LocationApiLauncher(GPSBTHandler) getLocationManager() : LocationManager providerSelectedEvent() : void providerNotFoundEvent() : void providerOutOfServiceEvent() : void -gpsbth

GPSBTHandler + + + + + + +

FrameBuilder decimals: int = 6 tw: TimeWriter = new TimeWriter() FrameBuilder() getDecimals() : int setDecimals(int) : void buildFrame(double, double, float) : String buildFrame(String, String, String) : String toDecimalDegrees(String, String) : double toMetersPerSecond(String) : float

-lal

use

ConfigurationProvider ~ + + + + INSTANCE: ConfigurationProvider = null freeCriterias: Criteria ([]) = null freeCriteriaNames: String ([]) = null costCriterias: Criteria ([]) = null costCriteriaNames: String ([]) = null criteria: Criteria = null provider: LocationProvider = null mycrit: Criteria = new Criteria() ConfigurationProvider() getInstance() : ConfigurationProvider isLocationApiSupported() : boolean getSelectedProvider() : LocationProvider autoSearch(ProviderStatusListener) : void

-INSTANCE

use

Utils + formatDouble(double, int) : String

use

Figura 5.11: Diagrama de clases del componente para la comunicacin con el GPS. Clases asociadas al uso de la interfaz JSR-179.

90

 Tiempo de monitorizacin. En este caso es interpretado como el tiempo entre dos capturas consecutivas de muestras de GPS. El mtodo congureMonitoringTime (int time) permite su conguracin. Valores umbrales. Es posible congurar los valores umbrales (valores mnimo y mximo) de latitud y longitud que servirn de referencia para la generacin de alarmas (vase el apartado 5.2.7). Se puede hacer mediante el uso del mtodo congureValue (int type, byte[] thresholds). JSRTester. Esta clase es muy til para conocer si una interfaz JSR (Java Specication Request) es soportada o no por el terminal mvil. En este caso, es utilizada para comprobar si el telfono tiene implementada la interfaz JSR-179 (Location API) antes de emplear la interfaz JSR-82 (APIs for Bluetooth). FrameBuilder. Se emplea para la creacin de las tramas GPS que el Servidor de Control Central debe interpretar y cuyo formato es el siguiente (apndice D): latitud;longitud;velocidad;fecha. Permite realizar la conversin unidireccional desde la velocidad en nudos (NMEA0183 [128]) a metros por segundo, as como tambin de coordenadas expresadas en grados y minutos decimales (NMEA-0183 [128]) a grados decimales. Utils. Permite la conversin de un tipo double en un objeto String con el nmero de decimales que se indique. Es utilizada por la clase FrameBuilder. BTracer. Permite escribir informacin en un chero del terminal mvil. Para ello es necesario el uso de la interfaz JSR-75 (File Connection and PIM API) [138]. Se utiliza para guardar las tramas generadas mediante la clase FrameBuilder en el modo de funcionamiento NOVERBOSE. Asimismo, esta clase se ha utilizado para la creacin de cheros de traza usados para la vericacin y comprobacin de las funcionalidades de los distintos subsistemas que componen la aplicacin del Nodo Inteligente (NI). Vase el apartado 9.1.1 para ms informacin. Queue. Almacena tramas GPS con el formato establecido en el protocolo de comunicacin entre el Nodo Inteligente y el Servidor de Control Central (SCC). A l accede el objeto gestor de datos (apartado 5.2.5.2.5) para enviar esta informacin al SCC. Status. En este caso, el atributo de esta clase incluido en GPSBTHandler (sensorDisconnected) representa el estado de la conexin Bluetooth con el GPS Leadtek 9553X: true si est desconectado y false si est conectado. Al igual que antes, se utiliza para noticar al SCC la prdida de la conexin con el GPS. 91

GPSThresholdManager. Permite detectar si los valores de latitud y longitud proporcionados por el GPS se encuentran dentro de los umbrales prejados. Esta clase se ver con detalle en el apartado 5.2.7. Clases especcas del uso de la interfaz JSR-179: LocationApiLauncher. Sirve para inicializar todos los objetos necesarios para el uso de la interfaz JSR-179, que pertenecen a las clases: CongurationProvider y LocationManager. Implementa la interfaz ProviderStatusListener. CongurationProvider. Se utiliza para buscar un proveedor de servicios de localizacin, objeto de la clase LocationProvider [130], que permita leer los datos del GPS. Si ste es encontrado, el MIDlet podr disponer de tales datos, sin tener que analizar el ujo Bluetooth ni las sentencias NMEA-0183. LocationManager. Esta clase implementa la interfaz LocationListener, denida en la JSR-179 [130] e indica la disponibilidad de nuevos datos procedentes del GPS. ProviderStatusListener. Interfaz que implementa la clase LocationApiLauncher (gura 5.11), cuyos mtodos sirven para indicar que se encontr un proveedor de servicios de localizacin, mtodo providerSelectedEvent(), que ste no fue encontrado, mtodo providerNotFoundEvent(), o que se ha encontrado pero est momentneamente fuera de servicio, mtodo providerOutOfServiceEvent(). Clases especcas del uso de la interfaz JSR-82: Parser. Es una clase que contiene toda la funcionalidad necesaria para interpretar las sentencias NMEA-0183 de las que se extraer la informacin de inters: latitud, longitud y velocidad. Record. Esta clase tiene una serie de atributos donde se introducen los campos de la sentencia NMEA-0183 que es interpretada por la clase Parser. Mediante el anlisis de los diagramas de las guras 5.10 y 5.11 se hace patente la dicultad de este componente debido a la posibilidad de utilizar dos interfaces diferentes, JSR-179 y JSR-82, para proporcionar la misma funcionalidad objetivo, es decir, la comunicacin y la gestin del GPS Leadtek 9553X. 5.2.4.3. Funcionamiento

La gura 5.12 presenta un diagrama de actividad que ilustra las principales actividades que realiza el subsistema de comunicaciones Bluetooth. El diagrama se inicia con la creacin del modelo del patrn de diseo MVC (vase el apartado 5.2.8), en el que se basa la aplicacin del Nodo Inteligente (NI). En esta creacin tiene lugar la generacin de un objeto de la clase 92

Bluetooth, previa a la realizacin de la bsqueda de dispositivos y servicios Bluetooth. En la gura 5.13 se muestra el proceso de creacin de un objeto de esta clase. Tras la generacin del objeto de la clase Bluetooth, habr un momento en la ejecucin de la aplicacin del NI en el que se inicia la bsqueda de dispositivos Bluetooth o Inquiry. Una vez iniciado el proceso de Inquiry (gura 5.14), a medida que se encuentran los dispositivos pertenecientes a la iBAN (pulsioxmetro Nonin 4100 y GPS Leadtek 9553X), estos se almacenan en el atributo remoteDevices (clase Vector) del objeto inquiryListener (clase InquiryListener). La bsqueda de dispositivos se repite hasta que se encuentran todos los elementos de la red de rea corporal (iBAN), o bien hasta que se alcanza un mximo nmero de intentos de Inquiry permitidos (parmetro congurable en el cdigo). En este ltimo caso, el programa muestra un mensaje al usuario antes de su cierre. Los dispositivos Bluetooth detectados durante el proceso de Inquiry que sean desconocidos no se tendrn en cuenta en la bsqueda de servicios o proceso de Service Discovery (gura 5.15). Este ltrado de dispositivos lo lleva a cabo el objeto inquiryListener por medio del mtodo lterRemoteDevices(). Tras ello, el objeto remoteDevices es asignado al objeto serviceDiscovery (clase ServiceDiscovery) para que ste pueda comenzar una bsqueda de servicios selectiva, es decir, slo sobre los dispositivos pertenecientes a la red de rea corporal del paciente (iBAN). Este proceso se realiza secuencialmente, dispositivo a dispositivo, y es repetido hasta que se encuentran todos los servicios de la iBAN o hasta que se alcanza un nmero mximo de intentos de Service Discovery permitidos (parmetro congurable en el cdigo). De nuevo, la aplicacin muestra un mensaje al usuario antes de su cierre. Finalizado el proceso de Service Discovery, se procede al inicio de las comunicaciones Nonin 4100-Nodo Inteligente y GPS Leadtek 9553X-Nodo Inteligente, mediante el uso del mtodo initiateComms() de la clase ServiceDiscoveryListener (gura 5.16). Por ltimo, tiene lugar la lectura de los datos de cada uno de los dispositivos de la iBAN, el almacenamiento y el procesamiento de los mismos, para su posterior envo al servidor por parte del objeto gestor de datos (guras 5.17 y 5.18). Slamente se ha de mencionar que algunas de las clases que aparecen en los diagramas de este apartado, y que no han sido detalladas, se tratarn en los subsistemas que se estudiarn a continuacin.

5.2.5.
5.2.5.1.

Subsistema de comunicaciones con el SCC

Estructura

La gura 5.19 ilustra los dos componentes en los que se divide este subsistema, que son: Componente para la implementacin del protocolo de comunicacin entre el Nodo Inteligente (NI) y el Servidor de Control Central (SCC). Como su nombre indica, 93

Creacin del Modelo del patrn MVC

Creacin del objeto Bluetooth

Bsqueda de dispositivos Bluetooth (Inquiry process)

NO

NO Todos los dispositivos encontrados? S S Salir del MIDlet Bsqueda de servicios Bluetooth (Service Discovery process) NO Se ha sobrepasado el nmero de intentos de Inquiry?

NO Todos los servicios fueron encontrados? S Se ha sobrepasado el nmero de intentos de Service Discovery?

Conexin con los dispositivos Bluetooth de la iBAN: initiateComms()

Salir del MIDlet

Lectura de datos de los dispositivos Bluetooth de la iBAN

Figura 5.12: Diagrama de actividad que detalla las tareas que se realizan dentro del subsistema de comunicaciones Bluetooth.

94

"indexes" es una Hashtable cuyas claves son las direcciones Bluetooth de los dispositivos de la iBAN y cuyos valores son los identificadores utilizados para identificarlos: 0x01 para el Nonin 4100 y 0x02 para el GPS. m:Model

new(indexes) bluetooth:Bluetooth new() inquiry:Inquiry localDevice = LocalDevice.getLocalDevice()

discoveryAgent =localDevice.getDiscoveryAgent()

new(indexes) il:InquiryListener this.indexes=indexes

remoteDevices=new Vector()

setInquiryListener(il)

new() serviceDiscovery: ServiceDiscovery localDevice = LocalDevice.getLocalDevice()

discoveryAgent =localDevice.getDiscoveryAgent()

new() sdl:ServiceDiscoveryListener numberOfCompletedSearches=0

foundServiceRecords=new Vector()

setServiceDiscoveryListener(sdl)

Figura 5.13: Diagrama de secuencia que muestra la inicializacin de un objeto de la clase Bluetooth.

95

AMS (Application Management System) iw:InquiryWorker inquiry:Inquiry ci:CInquiry il:InquiryListener serviceDiscovery: ServiceDiscovery

Mtodo run() de InquiryWorker

startInquiry()

il.clearRemoteDevices()

discoveryAgent.startInquiry(DiscoveryAgent.GIAC,il);

alt DeviceDiscovered deviceDiscovered(btDevice1, cod1) [if (!remoteDevices.contains((btDevice)] wait() deviceDiscovered(btDevice2, cod2)

remoteDevices.addElement(btDevice)

. . .
deviceDiscovered(btDeviceN, codN)

inquiryCompleted(eventType) alt InquiryCompleted [if(eventType==DiscoveryListener.INQUIRY_COMPLETED)] filterRemoteDevices()

alt [if (remoteDevices.size()==ci.getModel().getNMODELS())] allDevicesDiscovered=true

setRemoteDevices(remoteDevices) [else]

allDevicesDiscovered=false

inquiryCompleted(allDevicesDiscovered,discovered)

[else] appendln(errorMessage)

(from IN application)

(from IN application)

Figura 5.14: Diagrama de secuencia que reeja el proceso de bsqueda de dispositivos Bluetooth (Inquiry process).

96

AMS (Application Management System) sdw: ServiceDiscoveryWorker serviceDiscovery: ServiceDiscovery csd: CServiceDiscovery sdl: ServiceDiscoveryListener

startSearchServices()

FOR ( i=0;

i<remoteDevices.size() )
remoteDevice=(RemoteDevice) remoteDevices.elementAt(i)

transId =discoveryAgent.searchServices(attrSet,uuidSet,remoteDevice,sdl)

searches.addElement(new Integer (transId))

wait() servicesDiscovered(transId1, serviceRecord1)

foundServiceRecords.addElement(serviceRecord1[0])

Mtodo run() de ServiceDiscoveryWorker

serviceSearchCompleted(transID1, respCode) alt ServiceSearchCompleted numberOfCompletedSearches++ [if (respCode==SERVICE_SEARCH_COMPLETED)] notify()

alt ServiceSearchCompleted i++ [if (numberOfCompletedSearches==csd.getModel().getNMODELS())] initiateComms() remoteDevice=(RemoteDevice) remoteDevices.elementAt(i)

transId =discoveryAgent.searchServices(attrSet,uuidSet,remoteDevice,sdl)

searches.addElement(new Integer (transId))

wait()

servicesDiscovered(transId2, serviceRecord2) foundServiceRecords.addElement(serviceRecord2[0])

serviceSearchCompleted(transID2, respCode) alt ServiceSearchCompleted numberOfCompletedSearches++ [if (respCode==SERVICE_SEARCH_COMPLETED)] notify()

alt ServiceSearchCompleted Se conecta a los dispositivos de la iBAN, mediante el mtodo initiateComms(), si todos los servicios fueron encontrados. En caso contrario, no hace nada. [if (numberOfCompletedSearches==csd.getModel().getNMODELS())] initiateComms()

serviceSearchCompleted()

Figura 5.15: Diagrama de secuencia que reeja el proceso de bsqueda de servicios Bluetooth (Service Discovery process).

97

sdl: ServiceDiscoveryListener

model:Model

nonin:NONIN

gps:GPS

Enumeration e=foundServices.elements()

WHILE ( e.hasMoreElements() )
sr=(ServiceRecord)e.nextElement()

rdBTAddress=sr.getHostDevice().getBluetoothAddress()

btURL=sr.getConnectionURL(ServiceRecord.AUTHENTICATE_NOENCRYPT,false)

startBaseModel(rdBTAddress,btURL)

startBaseModel( rdBTAddress, btURL)

new (btAddress, btURL, c) nbth: NoninBTHandler super(btAddress, btURL)

...
nbthThread=new Thread(this)

nbthThread.start()

Mtodo run() de NoninBTHandler ...

startBaseModel(rdBTAddress,btURL) new (btAddress, btURL, c) gpsbth: GPSBTHandler alt [if (JSRTester.isJSR179Supported())] new (this) lal: LocationApiLauncher

[else]

new BTComm(btAddress, btURL)

...
gpsbthThread=new Thread(this)

gpsbth.start()

Mtodo run() de GPSBTHandler

Figura 5.16: Diagrama de secuencia que ilustra el proceso de conexin con los dispositivos de la iBAN, a travs del mtodo initiateComms().

98

pulseoximeter NONIN 4100 dis:DataInputStream nbth: NoninBTHandler dataBuffer: DataBuffer data:Queue dataHandler: DataHandler

SCC (Servidor de Control Central)

WHILE trucking
readFully(buffer,0,length)

getData(length)

data buffer writeBuffer(buffer)

isCompleted() isCompleted alt [if (isCompleted==true)] readBuffer() allDataStored

setElement(allDataStored)

notify()

getAllElements()

allElements sendPacket(allElements)

Figura 5.17: Diagrama de secuencia que muestra el proceso de lectura de datos procedentes del pulsioxmetro Nonin 4100.

99

GPS device GPS Leadtek 9553X

SCC (Servidor de Control Central) lm:LocationManager :FrameBuilder gpsbth: GPSBTHandler data:Queue dataHandler: DataHandler

locationUpdated(locationProvider, location)

alt [if(location != null && location.isValid())] QualifiedCoordinates coord = location.getQualifiedCoordinates()

alt [if (coord!=null)] double lat=coord.getLatitude()

double lon=coord.getLongitude()

float speed = location.getSpeed() Escritura en fichero de los datos del GPS representados por el String "frame". Su formato es: "latitud;longitud;velocidad;fecha"

buildFrame(lat, lon, speed) frame

processGpsFrame(frame)

alt [if (mode=NOVERBOSEMODE && frame!=null)] bTracer.writeString(frame)

[else if (mode=VERBOSEMODE)] alt [if (frame!=null)] setElement(frame.getBytes())

[else]

DATA_NOT_AVAILABLE.getBytes()

notify()

getAllElements() allElements sendPacket(allElements) [else] processGpsFrame(null)

. . .

Figura 5.18: Diagrama de secuencia que muestra el proceso de lectura de datos procedentes del GPS Leadtek 9553X, mediante el uso de la interfaz JSR-179 (Location API).

100

subsistema Comunicaciones SCC

componente Protocolo comunicacin NI-SCC

componente Comunicacin HTTP

componente Comunicacin TCP/UDP

componente Cifrado de datos

componente Gestor de datos

componente Gestor de indicaciones/respuestas

Figura 5.19: Diagrama de componentes del mdulo de comunicaciones con el SCC. implementa el protocolo de comunicacin que utilizarn el NI y el SCC para comunicarse entre s. Componente para la comunicacin HTTP. Ofrece la funcionalidad necesaria para comunicar el NI con el SCC a travs de HTTP. Componente para la comunicacin TCP/UDP. Proporciona toda la funcionalidad que se necesita para comunicar el NI con el SCC mediante TCP/UDP. Componente para el cifrado de datos. Posibilita el encriptado de los datos, lo que proporciona condencialidad a la comunicacin con el SCC. Componente gestor de datos. Se encarga de recolectar los datos recibidos por el subsistema de comunicaciones Bluetooth y de enviarlos al SCC, va HTTP o TCP/UDP. Componente gestor de indicaciones/respuestas. Realiza el envo de los paquetes de indicacin/respuesta (apndice D) al SCC.

5.2.5.2.

Diseo software

El desarrollo de las clases pertenecientes a este subsistema ha requerido adems de la funcionalidad proporcionada por la conguracin CLDC 1.1 y el perl MIDP 2.0, la ofrecida por la interfaz JSR-177 (Security and Trust Services API for J2ME)[139] que se emplea para el cifrado de los datos de monitorizacin que se transmiten desde el Nodo Inteligente (NI) hacia el Servidor de Control Central (SCC). La comunicacin entre el NI y el SCC se lleva a cabo utilizando: 101

componente Protocolo comunicacin NI-SCC HTTPComm.java

componente Comunicacin HTTP

IntValue.java

ProtocolHandler.java NetworkParameters.java Communication.java

componente Cifrado de datos

componente Comunicacin TCP/UDP

SecureMessage.java

UDPComm.java

TCPComm.java

TCPServerComm.java

componente Gestor de datos ReadableStatus.java

componente Gestor de indicaciones/respuestas

PacketBuffer.java

DataHandler.java

NSeqHandler.java

ResponseHandler.java

Figura 5.20: Diseo software de cada uno de los componentes del mdulo de comunicaciones con el SCC. 1. El protocolo HTTP: La informacin se enva desde el NI al SCC a travs de peticiones HTTP, y los comandos transmitidos desde el SCC al NI en las respuestas a estas peticiones (comunicacin sncrona). 2. Los protocolos TCP y UDP: La informacin de control se comunica entre el Nodo Inteligente (NI) y el Servidor Central (SCC) mediante TCP. Por otro lado, los datos son enviados por el NI al SCC mediante UDP (comunicacin asncrona). En la gura 5.20 se muestra las clases ms importantes que implementan los distintos componentes del subsistema de comunicaciones con el SCC, que se explican y analizan a continuacin. 5.2.5.2.1. Componente para la implementacin del protocolo de comunicacin entre el NI y el SCC Este componente est integrado por las clases que modelan el protocolo de comunicacin que usarn el NI y el SCC para enviar y recibir informacin entre s. Los paquetes denidos 102

en este protocolo se detallan en el apndice D, por lo que se recomienda su lectura para facilitar el seguimiento de la explicacin de este subsistema. La gura 5.21, reeja la relacin que existe entre las clases ProtocolHandler e IntValue, as como tambin sus atributos y mtodos ms importantes: ProtocolHandler. Implementa el protocolo de comunicacin que se detalla en el apndice D. IntValue. Permite realizar conversiones desde un valor entero (int de 4 bytes) a un array de bytes y viceversa.

5.2.5.2.2. Componente para la comunicacin HTTP Este subsistema integra las funciones necesarias para gestionar comunicaciones HTTP entre el NI y el SCC. Es muy importante destacar que todos los telfonos mviles MIDP 2.0 utilizados en este proyecto, poseen implementaciones de clientes HTTP [140], es decir, permiten el envo de peticiones HTTP y la recepcin de sus respuestas. Esto es debido a que la mayora de los terminales actuales disponen de navegador navegador web (cliente HTTP), cuyo consumo de recursos es mucho menor que el de un servidor HTTP. Por ello, es de suponer que debido a limitaciones de memoria y CPU la incorporacin de un servidor HTTP an no es factible en este tipo de dispositivos. De hecho, aunque sera factible dicha incorporacin, no se dispone de un API para programar con facilidad un servidor web en un telfono mvil. Gracias a la implementacin de los clientes HTTP ha sido posible desarrollar el esquema de comunicacin HTTP entre el NI y el SCC. El diagrama de la gura 5.22, muestra las clases NetworkParameters, HTTPComm y Communication, sus atributos y mtodos principales y las relaciones que hay entre ellas: NetworkParameters. Es una clase que contiene informacin genrica de una comunicacin que se realiza sobre IP (Internet Protocol): URL, direccin IP, puerto, etc. Es superclase de HTTPComm. Communication. Interfaz que ya se ha explicado en el apartado 5.2.4.2.2. Es implementada por HTTPComm. HTTPComm. Clase que gestiona las comunicaciones HTTP. Permite la apertura y el cierre de una conexin HTTP, el envo de peticiones HTTP y la recepcin de sus respuestas. En este caso particular, la reconexin de un enlace cado no tiene sentido, ya que para el envo de cada peticin HTTP ha sido necesaria la apertura y el cierre de la conexin. Se ha empleado para el envo de datos desde el NI hacia el SCC, a travs de peticiones HTTP, y para la recepcin de comandos encapsulados en las respuestas a estas peticiones. Vase el apartado 5.2.5.3 y el apndice D para ms informacin. 103

IntValue + + + + + + + + + IntValue() intValueToByteArray(int) : byte[] intValueToByteArray(int, int) : byte[] intValueToByteArray1(int) : byte[] intValueToByteArray2(int) : byte[] intValueToByteArray3(int) : byte[] intValueToByteArray4(int) : byte[] intValue(byte[]) : int intValue(byte) : int

use

ProtocolHandler + + + + + + + + + + + + + + + SYNC_BYTE: int = 0XFF {readOnly} UDP_PACKET_LENGTH: int = 7 {readOnly} LENGTH_FIELD_LENGTH: int = 2 {readOnly} IDPATIENT_FIELD_LENGTH: int = 4 {readOnly} NSEQ_FIELD_LENGTH: int = 2 {readOnly} MIN_VALUE_FIELD_LENGTH: int = 4 {readOnly} MAX_VALUE_FIELD_LENGTH: int = 4 {readOnly} PATIENT_PACKET_CODE: int = 0x01 {readOnly} COMMAND_PACKET_CODE: int = 0X02 {readOnly} DATA_PACKET_CODE: int = 0X03 {readOnly} RESPONSE_PACKET_CODE: int = 0x04 {readOnly} UDP_PACKET_CODE: int = 0X05 {readOnly} MAXNSEQ: int = 65535 {readOnly} RESTART_COMMAND_CODE: int = 0X01 {readOnly} CHANGE_MODE_COMMAND_CODE: int = 0X02 {readOnly} CONFIGURE_VALUE_COMMAND_CODE: int = 0X03 {readOnly} CONFIGURE_MONITORING_TIME_COMMAND_CODE: int = 0x04 {readOnly} CIPHER_COMMAND_CODE: int = 0x05 {readOnly} SENSORDISC_RESPONSE_CODE: int = 0x01 {readOnly} ACK_RESPONSE_CODE: int = 0x02 {readOnly} NAK_RESPONSE_CODE: int = 0x03 {readOnly} ERROR_RESPONSE_CODE: int = 0x04 {readOnly} SPO2_RANGE_CODE: int = 0X01 {readOnly} HR_RANGE_CODE: int = 0X02 {readOnly} LATITUDE_RANGE_CODE: int = 0X01 {readOnly} LONGITUDE_RANGE_CODE: int = 0X02 {readOnly} baos: ByteArrayOutputStream ProtocolHandler() getCONFIGURE_MONITORING_TIME__COMMAND_CODE() : int PatientPacket(int) : byte[] DataPacket(int, int, byte[]) : byte[] ResponsePacket(int, int, int) : byte[] isUDPPacket(byte[]) : boolean getUDPPort(byte[]) : int getCommandData(byte[]) : byte[] isCipherCommandData(byte[]) : boolean getId(byte[]) : int getCommand(byte[]) : byte[] getCommandCode(byte[]) : int getMode(byte[]) : int getConfigureValueCode(byte[]) : int getMonitoringTime(byte[]) : int

property get + getMAXNSEQ() : int + getRESTART_COMMAND_CODE() : int + getCHANGE_MODE_COMMAND_CODE() : int + getCONFIGURE_VALUE_COMMAND_CODE() : int + getSENSORDISC_RESPONSE_CODE() : int + getACK_RESPONSE_CODE() : int + getNAK_RESPONSE_CODE() : int + getERROR_RESPONSE_CODE() : int + getMAX_VALUE_FIELD_LENGTH() : int + getMIN_VALUE_FIELD_LENGTH() : int + getHR_RANGE_CODE() : int + getSPO2_RANGE_CODE() : int + getLONGITUDE_RANGE_CODE() : int + getLATITUDE_RANGE_CODE() : int + getUDP_PACKET_LENGTH() : int

Figura 5.21: Diagrama de clases del componente para la implementacin del protocolo de comunicacin entre el NI y el SCC.

104

NetworkParameters # # # # # + + + + + + + LOOPBACK: String = "127.0.0.1" {readOnly} LOCALHOST: String = "localhost" {readOnly} url: String ip: String port: int NetworkParameters() getIp() : String setIp(String) : void getPort() : int setPort(int) : void getUrl() : String setUrl(String) : void

extends NetworkParameters HTTPComm # # # + + + + + + httpc: HttpConnection dis: DataInputStream dos: DataOutputStream HTTPComm(String) openComm() : void sendPacket(byte[], byte[]) : boolean sendPacket(byte[]) : byte[] destroyComm() : void closeComm() : void implements interface Communication

Figura 5.22: Diagrama de clases del componente para la comunicacin HTTP. 5.2.5.2.3. Componente para la comunicacin TCP/UDP Integra toda la funcionalidad necesaria para gestionar comunicaciones TCP/UDP entre el NI y el SCC. En el diagrama de la gura 5.23 se ilustran las clases principales que integran este componente, junto con sus atributos, mtodos y relaciones: NetworkParameters. Esta clase es heredada por TCPComm y UDPComm. Communication. Interfaz que es implementada por las clases TCPComm y UDPComm. TCPComm. Consta de los mtodos y atributos necesarios para gestionar comunicaciones TCP (apertura/cierre de la conexin, reconexin, etc.). Ha sido utilizada para el establecimiento de la conexin entre el NI y el SCC y para el envo de indicaciones/respuestas desde el NI hacia el SCC, en el esquema de comunicacin TCP/UDP. Vase el apartado 5.2.5.3 y el apndice D para ms informacin. TCPServerComm. Hereda de la clase TCPComm y posibilita la gestin de conexiones TCP servidoras. Por cuestin de diseo, se ha usado para la recepcin de comandos procedentes del SCC en el esquema de comunicacin TCP/UDP. La razn principal de emplear esta clase, en vez de la clase TCPComm, ha sido porque TCPServerComm contiene un atributo de la interfaz ServerSocketConnection, que proporciona MIDP 2.0 [140] y que implementa el telfono, que est optimizada para gestionar conexiones TCP entrantes. Sin embargo, el uso de la clase TCPComm hubiera supuesto la necesidad de emplear threads Java adicionales para leer de forma continua el ujo de comunicacin TCP con el n de supervisar la llegada de nuevos comandos. Este 105

enfoque no estara optimizado respecto al S.O. (Sistema Operativo) y al hardware subyacente, por lo que conllevara el aumento del consumo de recursos de CPU, memoria y de batera. Vase el apartado 5.2.5.3 y el apndice D para ms informacin. UDPComm. Consta de los mtodos y atributos necesarios para gestionar comunicaciones UDP. En el esquema de comunicacin TCP/UDP ha sido empleada para el envo de datos de monitorizacin desde el NI hacia el SCC. Puesto que la informacin de monitorizacin se actualiza cada segundo (pulsioxmetro Nonin 4100 [114] y GPS Leadtek 9553X [128]), es factible el uso de UDP como protocolo de transporte aunque exista la posibilidad de prdida de datos durante la comunicacin.

5.2.5.2.4. Componente para el cifrado de datos La gura 5.24 detalla los principales mtodos y atributos de la clase SecureMessage que se utilizan para cifrar los datos de monitorizacin que se envan desde el NI al SCC. Para su implementacin ha sido necesario el uso de la interfaz JSR-177 (Security and Trust Services API for J2ME)[139]. El algoritmo de cifrado utilizado ha sido el DES (Data Encryption Standard) [141], con una clave privada compartida por el NI y el SCC de 8 bytes de longitud. 5.2.5.2.5. Componente gestor de datos La gura 5.25, reeja la relacin que existe entre las principales clases que integran este componente, as como sus atributos y mtodos ms importantes: DataHandler. Contiene toda la funcionalidad necesaria para gestionar el envo de datos desde el NI al SCC. Tiene una thread Java (interfaz R) que supervisa si los dispositivos de la iBAN tienen datos disponibles para ser enviados al SCC (HTTP o UDP). Para el esquema de comunicacin HTTP, adems, analiza las respuestas HTTP por si contienen un comando y, en caso armativo, lo enva al subsistema de gestin de comandos y control que en la gura 5.25 est representado por la clase ResponseHandler. PacketBuffer. Esta clase implementa un buffer donde se van acumulando los paquetes de datos asociados a cada dispositivo de la iBAN (apndice D), antes de ser enviados al SCC. ReadableStatus. Es una clase que implementa una tabla de estados donde se registra para cada dispositivo de la iBAN, en cada instante, si est generando datos de monitorizacin (funcionamiento correcto) o no (est desconectado, se est ejecutando un comando sobre l, etc.). NSeqHandler. Proporciona las funciones necesarias para la gestin de los nmeros de secuencia que van incluidos en los paquetes de datos que se envan al SCC. 106

interface Communication

NetworkParameters

implements

implements

NetworkParameters TCPComm # # + + + + + + + + + KEEPALIVE_VALUE: int = 1 LINGER_VALUE: int = 5 RCVBUF_SIZE: int = 256 SNDBUF_SIZE: int = 256 DELAY_VALUE: int = 0 sc: SocketConnection dos: DataOutputStream dis: DataInputStream inputPacket: ByteArrayOutputStream v: View connectedToNetwork: boolean = false trucking: boolean = true bTracer: BasicTracer TCPComm(View) setHostPort(String, int) : void setHostPort() : void openCommUntilIsConnectedToServer() : void reOpenComm(int) : void openComm() : void setSocketOptions(int, int, int, int, int) : void sendPacket(byte[]) : void readPacket() : byte[] readUDPPacket(int) : byte[] closeComm() : void destroyComm() : void extends extends

NetworkParameters UDPComm + + + + + + + udpConn: UDPDatagramConnection datagram: Datagram UDPComm() setHostPort(String, int) : void setHostPort() : void openComm() : void sendPacket(byte[]) : void closeComm() : void destroyComm() : void

property get + getDELAY_VALUE() : int + getKEEPALIVE_VALUE() : int + getLINGER_VALUE() : int + getRCVBUF_SIZE() : int + getSNDBUF_SIZE() : int

extends

TCPComm TCPServerComm + + + + + + PORT: int = 50000 ssc: ServerSocketConnection TCPServerComm() setHostPort() : void openComm() : void getServerSocketConnection() : ServerSocketConnection closeComm() : void destroyComm() : void

Figura 5.23: Diagrama de clases del componente para la comunicacin TCP/UDP.

SecureMessage + + + + BLOCK_LENGTH: int = 8 ivps: IvParameterSpec cipher: Cipher secretKeySpec: SecretKeySpec SecureMessage() getEncodingMessage(byte[]) : byte[] getEncodingMessageLength(byte[]) : int getDecodingMessage(byte[]) : byte[]

Figura 5.24: Diagrama de clases del componente para el cifrado de datos. 107

PacketBuffer + + + + + baos: ByteArrayOutputStream PacketBuffer() writeBuffer(byte[]) : void readBuffer() : byte[] isEmpty() : boolean reset() : void -pbuff + + + BaseModelsStatus ReadableStatus ReadableStatus() setReadable(int, boolean) : void isReadable(int) : boolean + + +

NSeqHandler MINNSEQ: int = 0 {readOnly} MAXNSEQ: int ht: Hashtable NSeqHandler(int, int) getNSeq(int) : int resetAllNSeq(int) : void -nsh Runnable DataHandler

-readableStatus

Componente cifrado de datos

SecureMessage -sm

Componente protocolo NI-SCC

+ + + + + + + -

useHTTP: boolean = false rh: ResponseHandler comm: Communication c: Controller models: Hashtable pbuff: PacketBuffer ph: ProtocolHandler nsh: NSeqHandler dh: Thread sm: SecureMessage readableStatus: ReadableStatus DataHandler(String, Controller, Hashtable) getDataStore() : DataStore getReadableStatus() : ReadableStatus setResponseHandler(ResponseHandler) : void initiateUDPComm(String, int) : void run() : void getAvailableData(int) : void sendDataPackets() : void destroyDataHandler() : void destroyThread() : void destroyComm() : void

Subsistema de gestin de comandos y control

ResponseHandler -rh

ProtocolHandler -ph

Componente comunicacin HTTP-TCP/UDP

Communication -comm

Figura 5.25: Diagrama de clases del componente gestor de datos. ResponseHandler. Posee funcionalidades que estn asociadas al subsistema de gestin de comandos y control, que se vern en el apartado 9.1.1.3, y al propio subsistema de comunicaciones con el SCC, las cuales se detallan en el siguiente apartado.

5.2.5.2.6. Componente gestor de indicaciones/respuestas Como puede verse en la gura 5.26, la clase ResponseHandler es el elemento principal de este componente. Es parecida a la clase DataHandler, pero su principal diferencia es que se encarga de enviar al SCC los paquetes de indicacin/respuesta en vez de los paquetes de datos. Tambin, dispone de una thread Java que supervisa si los dispositivos de la iBAN estn conectados o no, de forma que enva una indicacin de desconexin cuando alguno de ellos deja de funcionar. Adems, es responsable de la transmisin de la respuestas a los comandos enviados por el SCC. Vase el apndice D para obtener ms informacin acerca de los paquetes de indicacin/respuesta del protocolo de comunicacin empleado por el NI y el SCC. Aunque posee ms funcionalidades, stas se detallarn en el apartado 9.1.1.3. 108

Runnable ResponseHandler Componente protocolo NI-SCC + + + + + useHTTP: boolean = false SERVER_IP: String = "192.168.1.2" SERVER_TCP_PORT: int = 33333 idPatient: int commandServer: CommandServer commandQueue: Queue dh: DataHandler comm: Communication c: Controller models: Hashtable ph: ProtocolHandler rh: Thread sdiscStatus: SensorDisconnectStatus ResponseHandler(String, Controller, Hashtable, int) setDataHandler(DataHandler) : void run() : void sendPatientPacket() : boolean updateBaseModelsStatus() : void updateBaseModelStatus(BaseModel, int) : void isSensorDisconnected(int) : boolean processCommands() : void setCommandPacket(byte[]) : void destroyResponseHandler() : void destroyThread() : void destroyComm() : void

ProtocolHandler -ph

DataHandler -dh

Componente comunicacin HTTP-TCP/UDP

Communication -comm

Figura 5.26: Diagrama de clases del componente gestor de indicaciones/respuestas. 5.2.5.3. Funcionamiento

En el diagrama de la gura 5.27, se muestra el funcionamieto general de este subsistema.

5.2.6.
5.2.6.1.

Subsistema de gestin de comandos y control

Diseo software

Para la implementacin de este subsistema hay que puntualizar que no ha sido necesario el uso otras interfaces JSR adicionales a la conguracin CLDC 1.1 y al perl MIDP 2.0. Las principales clases implicadas en el diseo software del subsistema de gestin de comandos y control, se muestran en el diagrama de clases de la gura 5.28: ResponseHandler. En relacin al subsistema objeto de estudio, su tarea principal es la de gestionar los comandos que llegan desde el SCC. Esta tarea, junto con la supervisin del estado de cada uno de los dispositivos de la iBAN (apartado 5.2.5.2.6), es realizada por una thread de Java. Esta thread gestiona la cola de comandos (objeto de la clase Queue), de manera que si hay algn comando almacenado lo extrae de la cola, lo interpreta, indica al gestor de datos (objeto de la clase DataHandler) que el dispositivo sobre el que hay que ejecutar el comando no est disponible para enviar datos de monitorizacin (modica el atributo de la clase ReadableStatus del gestor de datos DataHandler) y lo ejecuta sobre el dispositivo que corresponda. El resultado de la ejecucin se notica al SCC, de nuevo, a travs de un paquete de indicacin/respuesta. Hay que destacar que las clases sobre las que se ejecutan los comandos interpretados por ResponseHandler se llaman NONIN y GPS (vase el apartado 5.2.8), que estn 109

SCC (Servidor de Control Central) nbth: gpsbth: NoninBTHandler GPSBTHandler dh:DataHandler commDH: ph:ProtocolHandler rh: sm:SecureMessage commRH: Communication ResponseHandler Communication sendPatientPacket()

patientPacket(idPatient) patientPacket

alt SCC COMMUNICATION STABLISHMENT [if (useHTTP)]

((HTTPComm) comm).sendPacker(patientPacket) sendHttpPacket(patientPacket)

[else]

((TCPComm) comm).sendPacket(patientPacket) sendTCPPacket(patientPacket) udpPacket udpPacket getUDPPort(udpPacket) udpPort

initiateUDPComm(SERVER_IP,udpPort) ((UDPComm)comm).setHostPort(ip, port)

wait()

notify()

alt NONIN DATA [isReadable(idSensor1)] getData() NoninData getEncodingMessage(NoninData) NoninDataEncrypted getDataPacket(NoninDataEncrypted) NoninDataPacket pbuff.writeBuffer(NoninDataPacket)

alt [isReadable(idSensor2)] getData() GPSData

...
pbuff.writeBuffer(GPSDataPacket)

alt [if (!pbuff.isEmpty())] sendDataPackets(pbuff.readBuffer()) alt [if (useHTTP)] sendHTTPacket(pbuff.readBuffer())

[else]

sendUDPacket(pbuff.readBuffer())

Figura 5.27: Diagrama de secuencia que reeja el funcionamiento del mdulo de comunicaciones con el SCC. 110

asociadas al pulsioxmetro Nonin 4100 y al GPS Leadtek 9553X, respectivamente. A su vez, estas clases ejecutarn los comandos que reciben de ResponseHandler sobre las clases NoninBTHandler (apartado 5.2.4.2.3) y GPSBTHandler (apartado 5.2.4.2.4), que son las que realmente interaccionan con los dispositivos Bluetooth de la iBAN. Este aspecto del diseo queda ilustrado en la gura 5.29. Queue. Esta clase se ha empleado para la modelar la cola de comandos procedentes del SCC. SensorDisconnectStatus. Es una clase que representa una tabla de estados donde se registra para cada dispositivo de la iBAN, en cada momento, si est conectado o desconectado. CommandServer. Se emplea en el esquema de comunicacin TCP/UDP para la recepcin asncrona de comandos del SCC, a travs de una conexin TCP servidora (TCPServerComm). Una vez que se recibe un comando, ste se introduce en la cola de comandos que es implementada por el objeto de la clase Queue.

5.2.6.2.

Funcionamiento

La gura 5.29 detalla el proceso de recepcin y ejecucin de un comando sobre el dispositivo GPS Leadtek 9553X y la posterior generacin del paquete de indicacin/respuesta que se enva al SCC. Aunque el ejemplo se basa en el esquema de comunicacin HTTP, para el esquema TCP/UDP el proceso es equivalente, con la nica diferencia de que el comando entrante es recibido por medio de una conexin TCP servidora, objeto de la clase TCPServerComm, en vez de estar encapsulado en una respuesta HTTP. Esta conexin TCP servidora, como se ha explicado en el apartado anterior, est gestionada por un objeto de la clase CommandServer.

5.2.7.
5.2.7.1.

Subsistema de procesamiento y gestin de alarmas

Diseo software

La implementacin de este subsistema ha requerido el uso de las interfaces JSR-205 (Wireless Messaging API 2.0) [142] y JSR-75 (File Connection and PIM API) [138]. As, la interfaz JSR-205 ha sido empleada para la generacin y el envo de mensajes de SMS/MMS, mientras que la interfaz JSR-75 se ha utilizado para la recuperacin de los nmeros de telfono de los destinatarios de dichos mensajes. En la gura 5.30, se detallan las principales clases que integran este subsistema, sus atributos, sus mtodos y las relaciones que hay entre ellas: NoninThresholdManager. Clase que modela los umbrales mximo y mnimo de HR (Heart Rate) y SPO2 asociados al pulsioxmetro Nonin 4100. Como estos umbrales 111

BaseModelsStatus SensorDisconnectStatus + + + SensorDisconnectStatus() setStatus(int, boolean) : void getStatus(int) : boolean

-sdiscStatus

Runnable ResponseHandler + + + + + useHTTP: boolean = false SERVER_IP: String = "192.168.1.2" SERVER_TCP_PORT: int = 33333 idPatient: int commandServer: CommandServer commandQueue: Queue dh: DataHandler comm: Communication c: Controller models: Hashtable ph: ProtocolHandler rh: Thread sdiscStatus: SensorDisconnectStatus ResponseHandler(String, Controller, Hashtable, int) setDataHandler(DataHandler) : void run() : void sendPatientPacket() : boolean updateBaseModelsStatus() : void updateBaseModelStatus(BaseModel, int) : void isSensorDisconnected(int) : boolean processCommands() : void setCommandPacket(byte[]) : void destroyResponseHandler() : void destroyThread() : void destroyComm() : void -commandServer

Queue -commandQueue

Thread CommandServer + + + + tcpServerComm: TCPServerComm rh: ResponseHandler CommandServer() setResponseHandler(ResponseHandler) : void run() : void startCommandServer() : void initCommandServerThread() : void waitForConnection() : void destroyCommandServer() : void destroyThread() : void destroyComm() : void

Figura 5.28: Diagrama de clases del subsistema de gestin de comandos y control.

112

SCC (Servidor de Control Central) gpsbth: gps:GPS nbth: nonin:NONIN GPSBTHandler NoninBTHandler commandQueue: ph:ProtocolHandler Queue rh: ResponseHandler

WHILE trucking
updateBaseModelStatus(NONIN, idSensor1) Mientras el programa est ejecutndose... getBTHandler() nbth isSensorDisconnected() isDisconnectedBoolean alt [if (isDisconnectedBoolean=true)] Se supervisa el estado del pulsioximetro y se observa que est desconectado. Por ello, se notifica al SCC mediante un paquete de indicacin/respuesta que informa que el Nonin 4100 se ha desconectado. sendHTTPacket(indicationPacket) commandPacket

setCommandPacket(commandPacket)

alt [if (commandPacket!=null)] getCommandData(commandPacket) command

Coincide que el SCC deseaba enviar un comando al NI. Por lo tanto, lo enva en la respuesta HTTP. getBTHandler() gpsbth isSensorDisconnected() isDisconnectedBoolean

setElement(command)

updateBaseModelStatus(GPS, idSensor2)

alt Solicita un comando de la cola de comandos. getElement() command [if (isDisconnectedBoolean)]

Se trata de un comando asociado al dispositivo GPS ya que el identificador es idSensor2.

alt [if(command!=null)] getId(command)

idSensor2 Se supervisa el estado del dispositivo sobre el que se va a ejecutar el comando. isDisconnectedBoolean alt El comando no se ejecuta y, por lo tanto, se enva un paquete de respuesta con NAK. [if (isDisconnectedBoolean)] sendHTTPacket(responsePacket,NAK)

updateBaseModelStatus(GPS, idSensor2)

...

processCommand(command) ok

[else] sendHTTPPacket(response,ACK)

Figura 5.29: Diagrama de secuencia que explica el funcionamiento del mdulo de gestin de comandos y control.

113

son congurables por el Servidor de Control Central (SCC), la clase proporciona los mtodos necesarios para su modicacin. Adicionalmente, posee un mtodo que permite comprobar si unos valores dados de HR y SPO2 se encuentran dentro de los umbrales establecidos, mtodo checkPatientData(HR, SPO2). Si los valores chequeados se hallan fuera de los umbrales prejados, este mtodo enviar una alarma MMS, modelada por la clase MultimediaMessageHandler, al telfono del mdico que supervisa al paciente monitorizado y una serie de alarmas SMS/MMS, modeladas por las clases TextMessageHandler/MultimediaMessageHandler, a los terminales mviles de los familiares del paciente interesados en la recepcin y noticacin de este tipo de alarmas. Los nmeros de telfono de los terminales receptores se encuentran almacenados en un chero conocido, dentro del telfono donde se ejecuta la aplicacin del Nodo Inteligente (NI), y su obtencin se realiza por medio de la interfaz JSR-75. La informacin contenida en dichas alarmas incluye la causa que ha provocado el envo de la misma (HR o SPO2 fuera de rango, datos personales del paciente, informacin de contacto (telfono del paciente), foto del paciente, etc. GPSThresholdManager. Esta clase es anloga a la anterior, pero modela los umbrales mximo y mnimo de latitud y longitud asociados al dispositivo GPS. WMAConnection. Ofrece la funcionalidad bsica de las conexiones SMS y MMS: apertura y cierre de conexiones SMS/MMS, envo de mensajes SMS/MMS y vericacin de la validez de un nmero de telfono (el nmero slo contiene dgitos y, a lo sumo, el carcter +). Hace uso de la interfaz JSR-205 para la realizacin de estas funciones. TextMessageHandler. Implementa la funcionalidad necesaria para enviar mensajes de texto (SMS). Utiliza para ello, la interfaz JSR-205. MultimediaMessageHandler. Es un clase que provee las funciones necesarias para el envo de mensajes multimedia (MMS) que pueden contener texto, imagen y audio. Adems, posibilita la realizacin de presentaciones multimedia en los terminales destino, gracias a la utilizacin de un chero adicional, con formato SMIL (Synchronized Multimedia Integration Language) que se aade al contenido del MMS. SMIL es un estndar del World Wide Web Consortium (W3C) [143], para presentaciones multimedia, que permite integrar audio, video, imgenes, texto o cualquier otro contenido multimedia [144]. Esta clase emplea la interfaz JSR-205, para proporcionar todas estas funciones.

5.2.7.2.

Funcionamiento

En el diagrama de la gura 5.31 se expone un ejemplo de funcionamiento de este mdulo. 114

WMAConnection ~ ~ ~ ~ ~ ~ + + + + SMS_PROTOCOL: String = "sms://" {readOnly} MMS_PROTOCOL: String = "mms://" {readOnly} PROTOCOL_ID_LENGTH: int = 6 {readOnly} midlet: MIDlet smsAppPort: String mmsAppId: String openConnection(String, MessageListener) : MessageConnection closeConnection(MessageConnection) : void sendMessage(MessageConnection, Message, String) : void isValidPhoneNumber(String) : boolean uses

TextMessageHandler + sendTextMessage(MessageConnection, String, String) : void

uses uses uses

GPSThresholdManager + + + + + + + + + maxLat: double = 90 minLat: double = -90 minLon: double = -180 maxLon: double = 180 checkPatientCoordinates(double, double) : void getMaxLat() : double setMaxLat(double) : void getMaxLon() : double setMaxLon(double) : void getMinLat() : double setMinLat(double) : void getMinLon() : double setMinLon(double) : void + + + + + + + + +

NoninThresholdManager minHR: int = 55 maxHR: int = 150 minSPO2: int = 97 maxSPO2: int = 99 checkPatientData(int, int) : void getMaxHR() : int setMaxHR(int) : void getMaxSPO2() : int setMaxSPO2(int) : void getMinHR() : int setMinHR(int) : void getMinSPO2() : int setMinSPO2(int) : void

uses

uses

MultimediaMessageHandler + + + + + + + + + + + MIMETYPE_TEXT_PLAIN: String = "text/plain" {readOnly} MIMETYPE_IMAGE_JPEG: String = "image/jpeg" {readOnly} MIMETYPE_AUDIO_AMR: String = "audio/amr" {readOnly} MIMETYPE_SMIL: String = "application/smil" {readOnly} SMIL_ContentId: String = "smil_patient" {readOnly} newTextMessagePart() : MessagePart newImageMessagePart() : MessagePart newClipMessagePart() : MessagePart newSmilMessagePart() : MessagePart createAndSendMultipartMessage(String, String) : void sendMultipartMessage(MessageConnection, MessagePart[], String, String[], String[], String[], String, String, String) : void

Figura 5.30: Diagrama de clases del subsistema de procesamiento y gestin de alarmas.

115

mobile phone Doctor nbth: NoninBTHandler noninthHandler: NONINThresholdHandler mmh: MultimediaMessageHandler

Relative 1

Relative N

...

checkPatientData(HR, SPO2)

alt [if (HR<HRmin)] message1 Mensaje con la causa que provoc el envo de la alarma, junto con otra informacin adicional (datos personales, nmero de telfono del terminal, etc.)

alt [if (HR>HRmax)] message2

alt [if (SPO2<SPO2min)] message3

alt [if (SPO2>SPO2max)] message4

alt [if (value_out_of_range)] doctorNumber=retrievePhoneNumber("Doctor")

createAndSendMultipartMessage(doctorNumberUrl, message)

sendMMS()

doctorNumber=retrievePhoneNumber("Relative1")

createAndSendMultipartMessage(relative1NumberUrl, message)

sendMMS()

...

sendMMS()

Figura 5.31: Diagrama de secuencia que explica el funcionamiento del mdulo de procesamiento y gestin de alarmas.

116

5.2.8.

Implementacin del patrn de diseo MVC

En la aplicacin del Nodo Inteligente (NI) el patrn de diseo MVC est implementado por una serie de clases donde las ms importantes aparecen en la gura 5.32. Model. Esta clase se corresponde con el Modelo del patrn MVC. Sus principales atributos pertenecen a las siguientes clases: Bluetooth. Clase que incluye toda la funcionalidad necesaria para efectuar la bsqueda de dispositivos (Inquiry) y servicios (ServiceDiscovery) Bluetooth. Basemodel. Es la superclase de las clases NONIN y GPS. Contiene la funcionalidad comn de ambas clases. NONIN. Permite acceder a las conexin Bluetooth asociada al pulsioxmetro Nonin 4100 mediante su atributo nbth (NoninBTHandler). Proporciona los mtodos necesarios para congurar los parmetros ofrecidos del pulsioxmetro Nonin 4100: umbrales, tiempo de monitorizacin, etc. Extiende de la clase BaseModel. GPS. Es anloga a la clase NONIN pero est asociada al GPS Leadtek 9553X. View. Modela la Vista del patrn de diseo MVC. De ella heredan las diferentes vistas que tiene la aplicacin y que pertenecen a las clases VInquiry y VServiceDiscovery. Controller. Es la clase que implementa el Controlador del patrn MVC. Todos los controladores especcos que posee la aplicacin extienden de l: clases CInquiry y CServiceDiscovery. VInquiry. Extiende de la clase View. Es la vista asociada al proceso de bsqueda de dispositivos Bluetooth o Inquiry. Los objetos que actan durante el proceso de Inquiry y que necesiten acceder a ella, lo hacen por medio de un objeto de la clase CInquiry. CInquiry. Controlador asociado a la Vista VInquiry. Hereda de Controller. VServiceDiscovery. Vista asociada al proceso de ServiceDiscovery. Es anloga a VInquiry. CServiceDiscovery. Clase similar a CInquiry, pero cuya vista asociada es VServiceDiscovery. Extiende de la clase Controller. El funcionamiento general de la aplicacin del NI, usando el patrn MVC, se ilustra mediante los diagramas de secuencia de las guras 5.33 y 5.34.

117

CServiceDiscovery -vsd

VServiceDiscovery

-m

extends

extends

Model

Controller

View

-m -models extends extends

CInquiry Basemodel -csd

VInquiry

extends

extends

GPS

NONIN

Figura 5.32: Clases que implementan el patrn de diseo MVC en la aplicacin del NI.

118

INMIDlet Usuario new() d=Display.getDisplay(this)

Inicializacin del patrn de diseo MVC.

new() m:Model seq Bluetooth object initiation Creacin del objeto Bluetooth. new(d) vi:VInquiry new(m,vi) ci:CInquiry getBluetooth().getInquiry() inquiry

new(inquiry) iw:InquiryWorker start() Mtodo run() de InquiryWorker wait() setCInquiry(ci) setController(ci)

cms=new ControlMIDletState() setControlMIDletState(cms)

startApp()

startHandlers() seq startHandlers() Conexin con el Servidor de Control Central (SCC). automaticInquiry()

go() notify() seq Inquiry process startInquiry() Indica si se encontraron todos los dispositivos de la iBAN o no. La variable booleana "allDevicesDiscovered" contiene esta informacin: "true" si se encontraron todos y "false" en caso contrario. El argumento "discovered" contiene la direccin Bluetooth y el nombre de los dispositivos encontrados durante el proceso de Inquiry. Realizacin de la bsqueda de dispositivos Bluetooth (Inquiry process). Una vez finalizada, se inicia la bsqueda y conexin de servicios (Service Discovery process).

wait()

inquiryCompleted(allDevicesDiscovered,discovered)

Figura 5.33: Diagrama de secuencia que muestra el funcionamiento de la aplicacin del NI (I).

119

il:InquiryListener

m:Model

vi:VInquiry

ci:CInquiry

iw:InquiryWorker Mtodo run() de Inquiry Worker

inquiryCompleted(allDevicesDiscovered,discovered)

removeCommand("Cancel") paintDevicesDiscovered(discovered)

alt [if(allDevicesDiscovered==true)] destroy() getDisplay()

display new (display) vsd: VServiceDiscovery new(m, vsd) csd: CServiceDiscovery

getBluetooth().getServiceDiscovery() serviceDiscovery

new(serviceDiscovery) sdw: ServiceDiscoveryWorker this.serviceDiscovery=serviceDiscovery

setCServiceDiscovery(csd)

Mtodo run() de ServiceDiscoveryWorker start() setController(csd) setControlMIDletState(cms) seq ServDiscovery process Realizacin de la bsqueda de servicios serviceSearchCompleted() Bluetooth (ServiceDiscovery process). Una vez finalizada, se realiza la conexin con los dispositivos de la iBAN.

[else]

go() notify()

startInquiry()

seq Inquiry process

wait()

Se repite el proceso de Inquiry un nmero de veces prefijado. Si no hay xito, se sale del MIDlet mostrando un mensaje al usuario.

Figura 5.34: Diagrama de secuencia que muestra el funcionamiento de la aplicacin del NI (II).

120

Captulo 6 Desarrollo del software de recepcin y noticacin de alarmas

6.1. Introduccin

Este captulo detalla el desarrollo del software de recepcin y noticacin de alarmas, siguiendo un enfoque similar al del captulo 5. Por lo tanto, la estructura, el diseo y el funcionamiento de est aplicacin sern algunos de los aspectos aqu abarcados.

6.2.

Desarrollo del software de recepcin y noticacin de alarmas

6.2.1.

Lenguaje de programacin

Al igual que la aplicacin del Nodo Inteligente (NI), el software de recepcin y noticacin de alarmas ha sido implementado usando J2ME. Aunque en el apartado 3.4.2 ya se ha hablado de este lenguaje, de su conguracin CLDC y de su perl MIDP, aqu hay que destacar el uso de una caracterstica que introduce MIDP 2.0 que permite el inicio automtico de una aplicacin sin la intervencin del usuario. En un entorno MIDP 2.0, las threads del sistema son creadas por un software de Gestin de Aplicaciones, AMS (Application Management System), que gestiona el ciclo de vida de todo MIDlet (vase la gura 6.1 [145]): instalacin, activacin, ejecucin y desinstalacin. Un componente importante del AMS es el denominado Push Registry que proporciona las funciones (Push Registry API)1 y la informacin necesaria para lanzar MIDlets automticamente (gura 6.1 [145]). Esta informacin es la siguiente [145]: Una lista de las conexiones entrantes que lanzarn MIDlets de forma automtica.
1

Se recomienda la lectura de [145] para ms informacin sobre estas funciones.

121

Una lista de las alarmas temporales que lanzarn MIDlets automticamente. Una lista de MIDlets que solicitan su ejecucin automtica a travs de conexiones entrantes. Una lista de MIDlets que solicitan su ejecucin automtica mediante alarmas temporales. Para iniciar automticamente un MIDlet, Push Registry ofrece dos opciones [145][146]: 1. Inicio automtico en respuesta a una conexin entrante [145][147][148]: a) Bluetooth. b) HTTP. c) TCP. d) UDP. e) SMS, CBS (Cell Broadcast Service)2 o MMS. 2. Inicio automtico mediante una alarma temporal establecida. MIDP 2.0 slo admite una alarma por MIDlet [146]. En el caso particular de la aplicacin de recepcin y noticacin de alarmas, se ha utilizado Push Registry para que el programa se inicie automticamente cuando se produzca la llegada de una alarma SMS/MMS.

6.2.2.

Anlisis de la aplicacin de recepcin y noticacin de alarmas

La exposicin de cada uno de los subsistemas o mdulos de la aplicacin de recepcin y noticacin de alarmas, presentados en el apartado 2.3.2, se realizar abordando la estructura, diseo software y funcionamiento en los apartados 6.2.3.1, 6.2.3.2 y 6.2.3.3, respectivamente.

6.2.3.
6.2.3.1.

Subsistema de recepcin de mensajes SMS/MMS

Estructura

Como ya se ha indicado en el apartado 2.3.2, la aplicacin para la recepcin y noticacin de alarmas consta de un nico subsistema para la recepcin de mensajes SMS/MMS. El diagrama de despliegue de la gura 6.2 ofrece una vista de la estructura hardware de un escenario de aplicacin, en el que uno de los dispositivos representa al Nodo Inteligente que
Es un servicio de telefona mvil para la entrega de mensajes a mltiples usuarios que se encuentran dentro de una misma zona de cobertura [149].
2

122

ACTIVACIN MEDIANTE PUSH REGISTRY (MIDP 2.0)

ACTIVACIN MANUAL POR EL USUARIO

ACTIVACIN AUTOMTICA POR CONEXIN ENTRANTE

ACTIVACIN AUTOMTICA A TRAVS DE UNA ALARMA TEMPORAL ESTABLECIDA

ACTIVAR MIDLET new() startApp() En Pausa pauseApp() Activo

destroyApp()

Destruido

destroyApp()

CICLO DE VIDA DE UN MIDLET MIDP 2.0

Figura 6.1: Ciclo de vida y activacin de MIDlets desarrollados con MIDP 2.0 [145]. enva la alarma SMS/MMS, a travs del subsistema de procesamiento y gestin de alarmas (vase el apartado 5.2.7), y el otro corresponde al terminal mvil donde reside la aplicacin de recepcin y noticacin de alarmas. Cuando una alarma llega al dispositivo receptor, mediante un mensaje SMS o MMS, se produce una peticin de conexin entrante que es supervisada por el AMS (Application Management System). Si la conexin estaba registrada en el Push Registry, entonces se inicia de forma automtica el MIDlet que estaba asociado a dicha conexin y que es parte del software de recepcin y noticacin de alarmas (est incluido en el .JAR de la aplicacin).

6.2.3.2.

Diseo software

La utilizacin de las interfaces JSR-205 (Wireless Messaging API 2.0) y JSR-75 (FileConnection and PIM API) ha sido necesaria para la implementacin de algunas de las clases pertenecientes a este subsistema. La interfaz JSR-205 se ha usado para el manejo y la gestin de las conexiones SMS/MMS, mientras que la interfaz JSR-75 se ha empleado para la recuperacin, a partir de un chero, de los nmeros de telfono, del mdico y de emergencias, prejados. Vase el apndice B para obtener las URL donde se encuentran disponibles estas especicaciones. En la gura 6.3 se muestran las clases que implementan el mdulo de recepcin de mensajes SMS/MMS, que son las siguientes: 123

device Terminal mvil MIDP 2.0 del NI

device Terminal mvil MIDP 2.0 receptor de alarmas

Softwre del NI

Subsistema de procesamiento y gestin de alarmas

Alarma SMS/MMS

AMS (Application Management Software)

Conexin SMS/MMS entrante registrada en Push Registry?

Push Registry

Ejecutar aplicacin receptora SMS/MMS

Software de recepcin y notificacin de alarmas

Subsistema de recepcin de mensajes SMS/MMS

(a) Diagrama de despliegue UML.

Figura 6.2: Estructura de la aplicacin de recepcin y noticacin de alarmas.

124

Receive. Es una clase abstracta que extiende de MIDlet y que posee todos los elementos comunes en el tratamiento de mensajes SMS y MMS: creacin de la interfaz grca de usuario, gestin de los comandos de la interfaz, recuperacin de los nmeros de telfono, mtodos para realizar las llamadas telefnicas, etc. Sus mtodos abstractos sern implementados por las clases que heredan de ella, que son, en este caso, SMSReceive y MMSReceive, que emplean las interfaces JSR-205 y JSR-75. SMSReceive. Es un MIDlet que se ejecuta de forma automtica cuando se produce la entrada de una alarma SMS. Como el contenido de un mensaje SMS es solamente texto, este MIDlet se encarga de recibirlo, de extraer su contenido textual y de mostrarlo, nalmente, en la interfaz grca de usuario. Hace uso de la interfaz JSR205, para la recepcin y la decodicacin del mensaje SMS, y de la interfaz JSR-75. MMSReceive. Se trata tambin de un MIDlet, pero cuya ejecucin se lanza automticamente cuando se produce la entrada de una alarma MMS. En este caso, puesto que el MMS permite el transporte de texto, audio y vdeo, el contenido de la alarma puede ser ms completo: texto de mayor longitud, foto, clip de audio del paciente, etc. De manera anloga al MIDlet para la recepcin de alarmas SMS, MMSRecieve recibe el mensaje, extrae su contenido y lo muestra por pantalla al usuario de la aplicacin. Utiliza la interfaz JSR-205, para recibir y decodicar el mensaje MMS, y la interfaz JSR-75. WMAConnection. Es una clase que implementa la funcionalidad bsica de las conexiones SMS y MMS. Por ejemplo, permite abrir y cerrar conexiones SMS/MMS, enviar mensajes SMS/MMS y comprobar que un nmero de telfono es vlido (contiene slo dgitos y, a lo sumo, el carcter +). Emplea la interfaz JSR-205 para la realizacin de estas funciones. Status. Es una clase que almacena un estado (true o false) que puede ser consultado y/o modicado. Effects. Esta clase sirve para activar o desactivar los efectos de vibracin y sonido utilizados en la aplicacin. Estos efectos permiten avisar al usuario de forma insistente de la llegada de una alarma SMS/MMS. La gura 6.4 muestra los principales atributos y mtodos de las clases anteriormente comentadas. 6.2.3.3. Funcionamiento

El funcionamiento de esta aplicacin se detalla en las guras 6.5, 6.6 y 6.7. El diagrama de actividad (gura 6.5) muestra las tareas que llevan a cabo cuando llega una alarma 125

WMAConnection.java

Effects.java

Subsistema para la recepcin de mensajes SMS/MMS

Status.java

SMSReceive.java

Receive.java

MMSReceive.java

Figura 6.3: Diseo software del subsistema de recepcin de mensajes SMS/MMS. SMS/MMS al terminal mvil donde reside la aplicacin y sta es lanzada automticamente por el AMS (Application Management System). Las entidades participantes en este escenario son el AMS, el subsistema de recepcin de mensajes SMS/MMS y el propio usuario del programa. Por otro lado, el diagrama de la gura 6.6 reeja el funcionamiento general de la aplicacin, mientras que el de la gura 6.7 detalla cmo se realiza el procesamiento de comandos de la interfaz grca de usuario, cuando se pulsa una opcin. En ambos casos, se trata de diagramas de secuencia que ilustran el intercambio de mensajes y la interaccin entre los objetos y entidades que intervienen durante la ejecucin de la aplicacin. El escenario descrito es el mismo que en el diagrama de actividad, pero particularizando para la llegada de una alarma SMS. Para el caso de alarmas MMS, los diagramas son anlogos, con la nica diferencia del tipo de contenido a procesar: texto/audio/imagen del MMS frente a texto del SMS.

126

Status + + + status: boolean Status(boolean) getStatus() : boolean setStatus(boolean) : void -vibrateOn Effects + + + + vibrateOn: Status done: boolean display: Display Effects(Display) startVibrator(int, int) : void stopVibrator() : void destroyEffects() : void #effects MIDlet CommandListener Receive # # # # # # # # # # # # # # + + + + + exitCommand: Command = new Command("Ex... stopVibratorCommand: Command = new Command("St... call1Command: Command = new Command("Ca... call2Command: Command = new Command("Ca... call3Command: Command = new Command("Ca... content: Form display: Display thread: Thread connections: String ([]) effects: Effects port: String conn: MessageConnection msg: Message senderAddress: String Receive() startApp() : void pauseApp() : void destroyApp(boolean) : void commandAction(Command, Displayable) : void retrievePhoneNumber(int) : String phoneCall(String) : void callUp(String) : void

extends Runnable MessageListener MMSReceive + + + + MMSReceive() startApp() : void notifyIncomingMessage(MessageConnection) : void run() : void + + + +

extends Runnable MessageListener SMSReceive SMSReceive() startApp() : void notifyIncomingMessage(MessageConnection) : void run() : void

use WMAConnection ~ ~ ~ + + + +

use

SMS_PROTOCOL: String = "sms://" {readOnly} MMS_PROTOCOL: String = "mms://" {readOnly} PROTOCOL_ID_LENGTH: int = 6 {readOnly} openConnection(String, MessageListener) : MessageConnection closeConnection(MessageConnection) : void sendMessage(MessageConnection, Message, String) : void isValidPhoneNumber(String) : boolean

Figura 6.4: Diagrama de clases del subsistema de recepcin de mensajes SMS/MMS.

127

AMS (Application Management System)

Subsistema de recepcin de mensajes SMS/MMS

Usuario

Iniciar aplicacin de recepcin y notificacin de alarmas

LLeg SMS o MMS?

Ejecutar MIDlet SMSReceive.java

Ejecutar MIDlet MMSReceive.java

SMSReceive.java

MMSReceive.java

Activar vibracin y sonido

Activar vibracin y sonido

Recibir mensaje SMS

Recibir mensaje MMS

Decodificar mensaje SMS

Decodifcar mensaje MMS

Mostrar informacin SMS por pantalla

Mostrar informacin MMS por pantalla

Aadir botones software Call1, Call2 y Call3

Esperar una accin del usuario Ejecutar una opcin Pulsar opcin Exit

Pulsar opcin Call1 Pulsar opcin Call2

Pulsar opcin Call3

Llamar por telfono al paciente

Llamar por telfono al mdico Desactivar vibracin y sonido

Llamar por telfono al nmero de emergencias

Salir del programa

Fin de la ejecucin del programa

Realizar llamada telefnica

Figura 6.5: Diagrama de actividad: Funcionamiento de la aplicacin de recepcin y noticacin de alarmas.

128

AMS Usuario SMSReceive new() Receive super()

new() content:Form addCommand(exit) addCommand(stopVibrator) setCommandListener(this) Interfaz CommandListener Establece como "Listener" de comandos la clase Receive.

display=getDisplay(this) new(display) effects:Effects Interfaz MessageListener startVibrator(time, pause) Establece como "Listener" de mensajes entrantes la clase SMSReceive. port=getAppProperty("SMS-Port")

setTitle("SMS Receive")

Interfaz Runnable Establece que el mtodo run() est definido en la clase SMSReceive. Este mtodo se encarga de la recepcin del mensaje SMS entrante, de su decodificacin y de su muestra por pantalla. conn: MessageConnection

startApp() smsConnection="sms://:"+port new(smsConnection)

setMessageListener(this)

append("Waiting for SMS on port "+port) new(this) thread:Thread start() run() display.setCurrent(content) receive()

notifyIncomingMessage(conn) smsText deleteAll() setTitle("From: " + sender) append(smsText) addCommand(Call1) addCommand(Call2) seq Tratamiento de opciones Pulsar opcin addCommand(Call3)

Figura 6.6: Diagrama de secuencia: Funcionamiento de la aplicacin de recepcin y noticacin de alarmas.

129

Receive conn: MessageConnection effects:Effects Usuario

Pulsar opcin

commandAction(command, displayable)

alt [command==exit]

destroyApp(false)

setMessageListener(null) El mtodo "phoneCall(int phone)" desactiva la vibracin del telfono y adems realiza una llamada telefnica al nmero solicitado, mediante el mtodo "callUp(int phone)". close() destroyEffects() notifyDestroyed()

Fin del programa [command==call1] phoneCall(retrievePhoneNumber(patient)) stopVibrator() callUp(patient)

[command==call2] phoneCall(retrievePhoneNumber(doctor))

stopVibrator() callUp(doctor)

[command==call3] phoneCall(retrievePhoneNumber(emergencies))

stopVibrator() callUp(emergencies)

Figura 6.7: Diagrama de secuencia: Tratamiento de las opciones del usuario en la aplicacin de recepcin y noticacin de alarmas.

130

Captulo 7 Desarrollo de la aplicacin web para la descarga de MIDlets

7.1. Introduccin

A continuacin, se va a hacer una descripcin de la estructuara, diseo y funcionamiento de la aplicacin web implementada para la descarga del software descrito en los captulos 5 y 6. Se ha de puntualizar que el anlisis realizado es conciso y menos detallado que en las dos aplicaciones anteriores, dada su menor relevancia dentro del presente Proyecto Fin de Carrera.

7.2.

Lenguajes de programacin y herramientas utilizadas

Para la realizacin de esta aplicacin, se han utilizado los lenguajes HTML y PHP, previamente introducidos en los apartados 3.4.3 y 3.4.4, respectivamente. Adems, la herramienta de desarrollo utilizada ha sido Macromedia Dreamweaver 8.0, que es un editor HTML grco orientado al desarrollo web[150], disponible en su versin de prueba en [151].

7.3.

Estructura

La aplicacin web para la descarga de MIDlets, tal y como se ha comentado en el apartado 2.3.2, consta de dos mdulos o subsistemas que son (vase la gura 7.1): 1. Mdulo o subsistema de autenticacin de usuario. Verica la identidad del usuario que solicita la entrada a la pgina web. 2. Mdulo o subsistema de descarga de software. Ofrece, de forma grca, instrucciones para la descarga del software del Nodo Inteligente (usuario registrado como paciente) o de recepcin y noticacin de alarmas (usuario registrado como familiar). 131

Aplicacin web

Subsistema de autenticacin de usuario

Subsistema de descarga de software

(a) Diagrama de componentes UML.

device PC usuario

device Servidor web

Navegador web HTTP

Servidor web Apache

Aplicacin web para descarga de MIDlets

PHP

Servidor MySQL

Base de datos de pacientes y familiares

(b) Diagrama de despliegue UML.

Figura 7.1: Estructura de la aplicacin web para la descarga de MIDlets. Adems de la estructura lgica de la aplicacin, en la gura 7.1 se presenta un diagrama de despliegue UML con la estructura hardware y software de un escenario de utilizacin del programa. En este escenario se observan dos equipos, uno que representa al usuario que va acceder a la aplicacin y el otro a la mquina donde reside el servidor. A su vez, dentro del equipo del servidor estn ejecutndose los servidores Apache y MySQL correspondientes.

7.4.

Diseo software

En la gura 7.2 se presentan los cheros ms importantes que implementan cada uno de los mdulos de la aplicacin web para la descarga de MIDlets: 1. Ficheros asociados al mdulo de autenticacin de usuario. 132

Subsistema de autenticacin de usuario

Subsistema de descarga de software

main.php

accessControl.php

inPage.php

alarmsPage.php

security.php

close.php

Figura 7.2: Diseo software de los subsistemas de la aplicacin para la descarga de MIDlets. main.php. En este chero se dene el aspecto de la pantalla principal de la aplicacin. Recoge los datos de la interfaz de usuario y los verica mediante el uso del chero accessControl.php. accessControl.php.Verica la identidad del usuario que ha solicitado la entrada en la aplicacin. Si los datos son correctos, ejecuta el cdigo del chero inPage.php o alarmsPage.php, segn el usuario desee descargar la aplicacin del Nodo Inteligente o de recepcin y noticacin de alarmas, respectivamente. 2. Ficheros asociados al mdulo de descarga de software. inPage.php. Pgina de descarga del software del Nodo Inteligente, a la que slo tendrn acceso aquellos usuarios registrados como pacientes del sistema.. alarmsPage.php. Pgina de descarga del software de recepcin y noticacin de alarmas en dispositivos mviles, a la que slo podrn acceder aquellos usuarios registrados que no sean pacientes del sistema. Este grupo de usuarios se ha asociado, principalmente, a los familiares del paciente.. security.php. Comprueba que la sesin actual es vlida. Por ejemplo, al pasar de la pantalla principal a la de descarga verica si el identicador de sesin asociado no ha sido alterado. En caso contrario, vuelve a la pantalla principal y muestra un mensaje de error. close.php. Se encarga de cerrar correctamente la aplicacin destruyendo la sesin actual y volviendo, posteriormente, a la pantalla principal (main.php). Muestra un mensaje conrmando el cierre de la sesin.

7.5.

Funcionamiento

En la gura 7.3, se presenta un diagrama de actividad UML que reeja, de manera sencilla, el funcionamiento de la aplicacin web objeto de estudio.

133

Usuario Iniciar aplicacin web

Subsistema de autenticacin de usuario

Subsistema de descarga de software

Introducir identificadores de "user" y "password"

Comprobar identificadores de usuario (user) y contrasea (password)

[Familiar registrado]

[Paciente registrado]

Dibujar pantalla de descarga de INMIDlet

Dibujar pantalla de descarga de AlarmsMIDlet

[else] Escribir mensaje de error Descargar software INMIDlet Descargar software AlarmsMIDlet

Pantalla inicial

Salir de la aplicacin

Pantalla inicial

Figura 7.3: Diagrama de actividad: Funcionamiento de la aplicacin web para la descarga de MIDlets.

134

Captulo 8 Manual de instalacin y usuario

8.1.
8.1.1.

Manual de instalacin de los MIDlets desarrollados

Requisitos de instalacin

Los requisitos necesarios para la correcta instalacin de las aplicaciones descritas en los captulos 5 y 6 son los siguientes: Un telfono mvil J2ME, con soporte MIDP 2.0 (JSR-118) y CLDC 1.1 (JSR-139). Aparte, el terminal mvil debe poseer los siguientes paquetes J2ME opcionales: Para la aplicacin del Nodo Inteligente: JSR-75 (PDA Optional Packages for the J2MEPlatform), JSR-82 (Java APIs for Bluetooth), JSR-177 (Security and Trust Services API), JSR-179 (Location API) y JSR-205 (Wireless Messaging API 2.0). La inclusin de la JSR-179 se establece como un requisito dada las ventajas que proporciona y que fueron sealadas en el apartado 4.2.9. A pesar de ello, si el terminal no dispone de la JSR-179 los datos del mdulo GPS se extraen usando la JSR-82 (vase el apartado 4.2.9). Para la aplicacin de recepcin y aviso de alarmas: JSR-205 (Wireless Messaging API 2.0) y JSR-75 (PDA Optional Packages for the J2MEPlatform).

8.1.2.

Proceso de instalacin

La instalacin de los MIDlets desarrollados en el presente Proyecto Fin de Carrera puede realizarse de tres maneras distintas, que se detallan en los apartados siguientes: 1. Enviando directamente la aplicacin al terminal destino mediante Bluetooth, infrarrojos o va cable (vase apartado 8.1.3). 2. A travs de la herramienta propietaria correspondiente, diseada a tal efecto (vase apartado 8.1.4). 135

3. Mediante la aplicacin web para la descarga de MIDlets creada en este proyecto (vase apartado 8.1.5).

8.1.3.

Instalacin mediante el envo directo de la aplicacin al terminal destino

A travs de un dispositivo mvil o un ordenador es posible enviar un MIDlet a un telfono destino. Para ello, se necesita que ambos dispostivos establezcan previamente una conexin Bluetooth, de infrarrojos o va cable. En el ejemplo que se explica a continuacin, se enva un MIDlet a un telfono J2ME, desde el sistema operativo Windows XP SP2 (Service Pack 2) mediante una conexin Bluetooth. Suponiendo que se dispone de un adaptador USB Bluetooth, compatible con Windows XP SP2 [152], y que previamente se ha realizado el proceso de pairing con el dispositivo destino [153], los pasos a seguir son los siguientes 1 : 1. Seleccionar el chero .JAR o .JAD, asociado al MIDlet que se desea instalar. 2. Hacer click con el botn derecho del ratn y seleccionar la opcin Enviar a >Dispositivo Bluetooth, tal y como aparece en la gura 8.1. 3. Pulsar el botn Examinar del Asistente para la transferencia de archivos Bluetooth de la gura 8.2, si el dispositivo destino es diferente al seleccionado por defecto. En caso contrario, ir al paso siguiente. A continuacin, se inicia una bsqueda de los dispositivos que se encuentran en el rea de cobertura del adaptador USB Bluetooth. Tras nalizar el proceso, aparece una ventana como la de la gura 8.3, en la que hay que seleccionar el terminal al que se desea enviar, y pulsar Aceptar. 4. Pulsar el botn Siguiente para iniciar la transferencia, tal y como aparece en la gura 8.4, 5. En el terminal destino, aparece el cuadro de dilogo de la gura 8.5. Pulsar S para recibir el chero. 6. Terminada la recepcin, el mvil presenta la pantalla de mensaje recibido (vase la gura 8.6). Pulsar el botn Mostrar y luego Opciones>Abrir para iniciar el proceso de instalacin del MIDlet asociado. 7. Aceptar, pulsando S, todas las peticiones que realice el asistente de instalacin del telfono mvil (vase la gura 8.7).
1

Este proceso de instalacin se ha realizado utilizando el mvil Nokia N70, con idioma por defecto Espaol.

136

Figura 8.1: Enviar un archivo, a un dispositivo, a travs de Bluetooth.

Figura 8.2: Examinar dispositivos Bluetooth. 137

Figura 8.3: Seleccionar dispositivo Bluetooth.

Figura 8.4: Iniciar transferencia de chero. 138

Figura 8.5: Peticin para recibir el chero.

(a) Pantalla de mensaje recibido.

(b) Mensaje asociado al MIDlet.

Figura 8.6: Apertura del mensaje recibido, que adjunta el MIDlet.

Figura 8.7: Peticin para ejecutar la instalacin del MIDlet.

139

8.1.4.

Instalacin mediante la herramienta propietaria del fabricante del telfono destino

En este apartado se va a explicar la instalacin de un MIDlet, en un teminal Nokia, mediante el uso de la herramienta Nokia PC Suite 6.5. Para terminales de otros fabricantes (SonyEricsson, Motorola, etc.) existen herramientas equivalentes, cuyo manejo ser similar al de PC Suite. Como ejemplo, se muestra en la gura 8.8, el programa Motorola Phone Tools para telfonos Motorola [154].

Figura 8.8: Motorola Phone Tools. El proceso de instalacin de aplicaciones J2ME, mediante PC Suite 6.5, se ha descrito en el apartado 3.6.4. En consecuencia, se mencionarn nicamente los pasos que el usuario debe llevar a cabo, que son los siguientes: 1. Ejecutar Nokia PC Suite y pulsar la opcin de Instalar aplicaciones (gura 3.12). 2. Seleccionar el telfono destino y su memoria interna o externa (Memory Card), donde residir el MIDlet, por medio de los iconos de la parte derecha de la gura 3.13. 3. Elegir la aplicacin J2ME, que se va a instalar, a travs del sistema de gestin de cheros de la gura 3.13. 4. Pulsar la echa verde central, que denota la operacin de instalacin (gura 3.13). 5. Aceptar, pulsando S, todas las peticiones que realice el asistente instalacin del telfono mvil (vase la gura 8.7).

8.1.5.

Instalacin mediante la aplicacin web para la descarga de MIDlets

Se ha desarrollo una aplicacin web para la descarga de MIDlets. El principal objetivo de esta aplicacin ha sido simplicar al mximo el proceso de instalacin. Con este n, y haciendo uso de una nueva funcionalidad disponible en MIDP 2.0, denominada Over the Air (OTA) Provisioning [155], se permite al usuario acceder a un MIDlet e instalarlo directamente a travs del navegador del telfono. 140

Figura 8.9: Navegador web del telfono Nokia N93. Hay que resaltar que la aplicacin est orientada, principalmente, a su uso desde el dispositivo mvil nal, ya que, si se accede a la aplicacin a travs del navegador web de un ordenador, habra que recurrir a alguno de los procesos descritos en los apartados 8.1.3 y 8.1.4 para completar la instalacin. El proceso de instalacin consta de las siguientes fases2 : 1. Introducir la URL correspondiente, por ejemplo http://192.168.1.2/ server3 , en el navegador web del telfono mvil destino, y pulsar Go to. Este paso se reeja en la gura 8.9. 2. En la pantalla principal de la aplicacin, gura 8.10, escribir los campos user y password de usuario y pulsar Login. Si la informacin no es correcta, aparece un mensaje de error (gura 8.10) solicitando la introduccin correcta de los datos. Repetir el proceso, si es necesario, hasta visualizar la pantalla de descarga. 3. La pantalla de descarga (gura 8.11) ser diferente segn el usuario sea un paciente o un familiar. As, cuando el usuario es un paciente, el vnculo que aparece en la pgina est asociado al MIDlet del Nodo Inteligente, mientras que si se trata de un familiar, est ligado al MIDlet para la recepcin y noticacin de alarmas. Pulsar el vnculo Download para iniciar la descarga de la aplicacin, tal y como aparece en la gura 8.11. 4. Aceptar, pulsando Yes, todas las peticiones que realice el asistente instalacin del telfono mvil (vase la gura 8.12). 5. Una vez nalizada la descarga, salir de la aplicacin web pulsando primero el botn Exit (gura 8.11). As, se vuelve a la pantalla principal cerrando la sesin actual. Despus, pulsar Options>Exit para salir del navegador web del telfono.

Este proceso de instalacin se ha realizado utilizando el mvil Nokia N93, con idioma por defecto Ingls. Adems, se ha empleado una conexin WiFi para acceder a la aplicacin web. 3 La URL empleada en este ejemplo incluye una direccin IP privada que se corresponde con el PC donde se ha ejecutado la aplicacin web. Obviamente, para el caso de un servidor real que alojase la aplicacin, sera necesario el uso de una IP pblica.

141

(a) Datos de una paciente.

(b) Datos de un familiar.

(c) Botn de Login.

(d) Mensaje de error en la pantalla principal.

Figura 8.10: Pantalla principal de la aplicacin web para la descarga de MIDlets.

(a) Pantalla de descarga de INMIDlet.

(b) Pantalla de descarga de AlarmsMIDlet.

(c) Botones de Download y Exit.

Figura 8.11: Pantalla de descarga.

142

(a) Peticin de instalacin de INMIDlet.

(b) Peticin de AlarmsMIDlet.

instalacin

de

Figura 8.12: Peticin para ejecutar la instalacin del MIDlet.

8.2.

Manual de instalacin de la aplicacin web para la descarga de MIDlets

8.2.1.

Requisitos de instalacin

Para la instalacin de la aplicacin web servidora de MIDlets, es necesario un PC con las caractersticas indicadas en el apartado 4.4.

8.2.2.

Proceso de instalacin

Los pasos a seguir en la instalacin de la aplicacin web para la descarga de MIDlets son los siguientes: 1. Instalar Linux en el equipo, si no estaba previamente instalado [131][156]. 2. Instalar XAMPP para Linux, siguiendo las instrucciones que se indican en [157]. 3. Modicar el chero de conguracin de Apache http.conf que se encuentra en la ruta "/opt/lampp/etc/httpd.conf" [157]. Aadir las lneas "AddTypeapplication/java-archive .jar" y "AddTypetext/vnd. sun.j2me.app-descriptor .jad" para que el servidor reconozca los tipos .JAR y .JAD, respectivamente. 4. Copiar en el directorio "/opt/lampp/htdocs/" [157] la carpeta server4 donde se encuentran todos los cheros de la aplicacin web para la descarga de MIDlets. 5. Arrancar XAMPP, escribiendo en la consola "/opt/lampp/lampp start", tal y como se indica en [157].
Los cheros de cdigo de la aplicacin web estn en el interior de la carpeta server, que forma parte del DVD adjunto a la memoria del proyecto.
4

143

Figura 8.13: Icono de la aplicacin del Nodo Inteligente.

8.3.

Manual de usuario

En este apartado se aborda cmo el usuario debe utilizar las aplicaciones desarrolladas en el mbito de este proyecto. Para ello se describirn, las pantallas y los botones que aparecen en la interfaz grca, as como sus funciones. Antes de empezar, hay que sealar que debido al modelo de seguridad de J2ME, durante la ejecucin de las aplicaciones aparecen mensajes que solicitan la conrmacin del usuario para la realizacin de ciertas operaciones (conexin a Internet, conexin Bluetooth, etc.). Estos mensajes no se describen aqu ya que no forman parte de la interfaz de usuario implementada. Adems, este problema desaparece rmando la aplicacin con un certicado digital emitido por una entidad TTP (Trusted Third Party), denominada CA (Certicate Authority). Vase el apndice ??, para ms informacin.

8.3.1.

Manual de usuario de la aplicacin del Nodo Inteligente

En la gura 8.13 se observa el icono asociado a la aplicacin del Nodo Inteligente en el telfono Nokia N93. Posicionndose sobre ste y presionando Options>Open se inicia la ejecucin del programa. La aplicacin del Nodo Inteligente tiene tres pantallas con las funciones que se indican a continuacin: 1. Pantalla de bsqueda de dispositivos Bluetooth o Inquiry. Aparece durante todo el proceso de Inquiry. Presenta el aspecto de la gura 8.14, y posee tres botones que el usuario puede utilizar: El botn Start sirve para iniciar la bsqueda de dispositivos Bluetooth. Una vez pulsado, es suprimido de la interfaz grca y se aade a ella el botn Cancel. El botn Cancel permite interrumpir el proceso de Inquiry actual. Si se presiona, desaparece y el botn de Start se aade a la interfaz de usuario. 144

(a) Inquiry en pleno proceso.

(b) Inquiry cancelado.

(c) Proceso de Inquiry automtico.

Figura 8.14: Pantalla de Inquiry de la aplicacin del Nodo Inteligente. El botn Exit, cuya funcin es el cierre de la aplicacin liberando, previamente, todos los recursos del programa. Una vez terminada la bsqueda, y encontrados todos los dispositivos de la iBAN, se inicia el proceso de Service Discovery, adems de pasar a la pantalla siguiente de la aplicacin.. 2. Pantalla de bsqueda de servicios o ServiceDiscovery. Se corresponde con la bsqueda de servicios Bluetooth. La gura 8.15, muestra la apariencia de esta pantalla y los botones de los que consta, que son: El botn Connect permite comenzar el proceso de Service Discovery y conectar con los dispositivos de la iBAN. Si se presiona, es sustituido por el botn Cancel. El botn Cancel se emplea para abortar la bsqueda de servicios Bluetooth iniciada previamente. Cuando es pulsado, desaparece y el botn de Start se aade a la interfaz grca. El botn Exit, posee la misma funcin que en la pantalla anterior. Finalizada la bsqueda de servicios, y una vez que el NI se conecta a todos los dispositivos de la iBAN, tiene lugar la transicin a la siguiente pantalla del programa. 3. Pantalla de log y representacin de datos del paciente (Monitoring Patient). Muestra los datos monitorizados y algunos mensajes de traza de la aplicacin. En la gura 8.16, se reeja su aspecto. Tiene nicamente el botn Exit, cuya funcin no vara a lo largo de toda la ejecucin. La tabla 8.1 explica el signicado de los valores presentados en las pantallas de la gura 8.16 [114], que corresponden a los datos monitorizados por el pulsioxmetro Nonin 4100 (apartado 4.2.8.3). 145

(a) ServiceDiscovery pleno proceso.

en (b) Service Discovery cance- (c) Proceso de Service Dislado. covery automtico.

Figura 8.15: Pantalla de ServiceDiscovery de la aplicacin del Nodo Inteligente.

(a) Pantalla de representacin de datos, con Nonin 4100 en modo 1.

(b) Pantalla de representacin de datos, con Nonin 4100 en modo 2.

Figura 8.16: Pantalla de log y representacin de datos de la aplicacin del Nodo Inteligente.

146

VALOR HR

HRD

EHR

EHRD

SPO2

SPO2D

ESPO2

ESPO2D

SPO2BB

SPO2Fast

SREV BTS

DESCRIPCIN Ritmo cardaco promediado cada 4 latidos, en modo estndar (medidas de SPO2 y HR actualizadas con cada latido). Ritmo cardaco promediado cada 4 latidos, en modo display (medidas de SPO2 y HR actualizadas cada segundo y medio). Ritmo cardaco promediado cada 8 latidos, en modo estndar (medidas de SPO2 y HR actualizadas con cada latido). Ritmo cardaco promediado cada 8 latidos, en modo display (medidas de SPO2 y HR actualizadas cada segundo y medio). SPO2 promediado cada 4 latidos, en modo estndar (medidas de SPO2 y HR actualizadas con cada latido). SPO2 promediado cada 4 latidos, en modo display (medidas de SPO2 y HR actualizadas cada segundo y medio). SPO2 promediado cada 8 latidos, en modo estndar (medidas de SPO2 y HR actualizadas con cada latido). SPO2 promediado cada 8 latidos, en modo display (medidas de SPO2 y HR actualizadas cada segundo y medio). SPO2 en cada latido (Beat to Beat). No es un valor promedido, ni tampoco est limitado en amplitud en caso de que se produzca saturacin. SPO2 promediado cada 4 latidos, en modo estndar (medidas de SPO2 y HR actualizadas con cada latido). Su valor no est limitado en amplitud en caso de que se produzca saturacin. Versin del rmware del dispositivo Nonin 4100. Estado de la batera (Battery Status). Su valor puede ser 0 (Normal), 1 (Bajo) y 2 (Crtico).

Tabla 8.1: Descripcin de los valores monitorizados por el pulsioxmetro Nonin 4100 que aparecen en la gura 8.16 [114].

147

Figura 8.17: Icono de la aplicacin de recepcin y noticacin de alarmas SMS. Por ltimo, se destaca que el proceso de bsqueda de dispositivos (Inquiry) y servicios (Service Discovery) est automatizado, por lo que no se necesita la intervencin del usuario para que ambos se lleven a cabo5 . En las guras 8.14 y 8.15, se aprecian dos capturas de sendos procesos automticos.

8.3.2.

Manual de usuario de la aplicacin de recepcin y noticacin de alarmas

La aplicacin de recepcin y noticacin de alarmas puede ser ejecutada de forma manual o automticamente, tal y como se ha explicado en el apartado 6. Gracias a esto, el usuario puede despreocuparse de la aplicacin, por completo, ya que ella misma se encargar de avisarle de la llegada de una alarma. De todas formas, aqu se reeja la ejecucin manual del programa, para ilustrar todas las pantallas y botones de la iterfaz grca de usuario. La gura 8.17, muestra el icono asociado al programa de recepcin y noticacin de alarmas SMS, en el telfono Nokia N70. Para la aplicacin de recepcin y noticacin de alarmas MMS, el proceso es anlogo. Seleccionando el icono y presionando Options>Open, se inicia la ejecucin del programa, que posee dos pantallas: 1. Pantalla de espera de alarmas entrantes. Tiene la apariencia mostrada en la gura 8.18, y posee los siguientes botones: El botn Stop Vibration, cuya funcin es interrumpir la vibracin del telfono, que fue activada por el propio programa, para llamar la atencin del usuario. El botn Exit, que se emplea para salir del programa.
Se hace referencia a que el usuario no necesita pulsar, explcitamente, ningn botn para iniciar estos procesos.
5

148

Figura 8.18: Pantalla de espera de alarmas SMS entrantes.

(a) SMS recibido, imagen 1.

(b) SMS recibido, imagen 2.

(c) SMS recibido, imagen 3.

Figura 8.19: Pantalla de representacin de alarmas SMS. 2. Pantalla de representacin de alarmas. Presentada en la gura 8.19, incorpora los siguientes botones: El botn Options>Call1, que permite realizar una llamada al telfono del paciente que envi la alarma. El botn Options>Call2, que sirve para hacer una llamada al terminal del mdico que supervisa al paciente. El botn Options>Call3, que se utiliza para llamar a un telfono de emergencias. El botn Exit, que posee la misma funcin que en la pantalla anterior.

149

150

Captulo 9 Pruebas realizadas

9.1.
9.1.1.

Software del Nodo Inteligente

Pruebas de funcionalidad

En este apartado se abordan las principales pruebas que se han realizado para la depuracin de los diferentes subsistemas o mdulos que componen la aplicacin del Nodo Inteligente (NI).

9.1.1.1.

Subsistema de comunicaciones Bluetooth

Para el subsistema de comunicaciones Bluetooth se han llevado a cabo las pruebas que se enumeran a continuacin: Pruebas de funcionamiento general de la comunicacin Bluetooth. En ellas se han utilizado los telfonos mviles Nokia 9500, Nokia N93, Nokia E61, Nokia N70, Nokia 6680, Nokia 6230 y Sony-Ericsson K608i. 1. Bsqueda de dispositivos (Inquiry) y de servicios (Service Discovery) Bluetooth. Con antelacin a los test reales, se probaron ambos procesos, Inquiry y Service Discovery, ejecutando la aplicacin en un emulador Nokia perteneciente al Prototype SDK 4.0 S60 MIDP Emulator y utilizando los dispositivos reales que componen la iBAN (Nonin 4100 y GPS Leadtek 9553X). Para ello, fue necesario el uso del software de desarrollo NCF (Nokia Connectivity Framework) y de un adaptador USB Bluetooth (marca Conceptronic y modelo CBT200U2). Un ejemplo de realizacin de esta prueba se ha mostrado en la gura 3.11. Tras los test de emulacin se llevaron a cabo las pruebas en los dispositivos reales. En todos los terminales probados, los procesos de Inquiry y Service Discovery siempre se efectuaron satisfactoriamente. 151

2. Conexin a dispositivos Bluetooth, basados en SPP (Serial Port Prole), utilizando el protocolo RFCOMM (Radio Frequency Communication). La existencia de limitaciones en la emulacin de dispositivos mviles, ms concretamente en su comunicacin con dispositivos Bluetooth reales, impidieron que la aplicacin del Nodo Inteligente (NI), ejecutndose en un PC, estableciera una conexin Bluetooth con el sensor Nonin 4100 y/o con el GPS Leadtek 9553X. Este hecho se ha debido a la necesidad de realizar el proceso de pairing Bluetooth, previo al establecimiento de la conexin, y a la imposibilidad de los emuladores de introducir/congurar el PIN correspondiente en cada caso. La ausencia de esta funcionalidad provoca que el proceso de desarrollo de las aplicaciones sea ms complicado, haciendo estrictamente necesaria la posesin del telfono mvil para probar el software diseado. Adems, el programador se ve obligado a idear un proceso de depuracin alternativo al uso de la salida estndar (consola de depuracin de los emuladores), por ejemplo, escribiendo traza por pantalla o en cheros del telfono que leer tras la ejecucin de la aplicacin. Vase el apartado 5.2.4.2.4 para obtener ms informacin sobre el software utilizado para la generacin de cheros de traza. Respecto a las pruebas reales, exceptuando al telfono Nokia 9500 que la mayora de las veces ha presentado errores Symbian al inicio de la conexin SPP, el resto de los terminales mviles se conectaron al pulsioxmetro Nonin 4100 y al GPS Leadtek 9553X sin problemas. En la tabla 9.1 se detalla la informacin mostrada por pantalla tras la ocurrencia de algunos de estos fallos. Para ms informacin sobre errores Symbian vase [158]. Hay que aadir que en el DVD adjunto a la memoria se han incluido una serie de vdeos donde se aprecian los fallos Symbian que el telfono Nokia 9500 mostraba por pantalla durante el inicio de las conexiones SPP. As, queda constancia de la ocurrencia de estos errores con varios prototipos de la aplicacin del NI y tambin con otras aplicaciones que usaban el perl SPP ajenas a este proyecto [159]. 3. Reconexin de enlaces Bluetooth cados. La reconexin de los enlaces Bluetooth cados ha sido satisfactoria en todos los terminales probados a excepcin, de nuevo, del telfono Nokia 9500 que presentaba errores Symbian durante su realizacin. Pruebas de funcionamiento de la comunicacin Bluetooth con el pulsioxmetro Nonin 4100. Estas pruebas se llevaron a cabo mediante el uso de los terminales mviles Nokia N93, Nokia E61, Nokia N70, Nokia 6680, Nokia 6230 y Sony-Ericsson K608i. 1. Conexin. En todos los dispostivos probados la conexin con el pulsioxmetro Nonin 4100 se efectu correctamente. 152

2. Conguracin. En cuanto a la conguracin del pulsioxmetro Nonin 4100, tampoco se han producido problemas con ninguno de los terminales usados. Por lo tanto, la transicin del Modo 1 al Modo 2, y viceversa, se ha realizado de forma adecuada en todos los test. 3. Recepcin y decodicacin de datos en Modo 1. En todas las pruebas, los datos en Modo 1 se han recibido y decodicado de acuerdo a las especicaciones del pulsioxmetro [114]. Este hecho se ha comprobado de forma visual al vericar que los valores decodicados, mostrados por pantalla (gura 8.16), eran coherentes y a travs del anlisis cheros de traza donde se almacenaban paquetes de datos en Modo 1. En la gura 9.1 aparece un ejemplo de chero de traza que almacena datos en Modo 1. 4. Recepcin y decodicacin de datos en Modo 2. Siempre que la aplicacin se ha ejecutado empleando nicamente las comunicaciones Bluetooth, los datos en Modo 2 se han recibido y decodicado bien. El problema ha surgido durante el uso simultneo de las comunicaciones Bluetooth y las comunicaciones HTTP o TCP/UDP (WiFi, GPRS o UMTS). Para este escenario de prueba, a veces, los datos en Modo 2 se han recibido solapados entre s e incumpliendo el formato de las especicaciones del pulsioxmetro [114]. A este problema se le ha hecho referencia en el presente Proyecto Fin de Carrera como prdida de sincronismo del ujo Bluetooth. Su deteccin tuvo lugar a travs del anlisis de los valores decodicados mostrados por pantalla, gura 8.16, y posteriormente vericando el formato de los paquetes recibidos que eran almacenados en cheros de traza. Un ejemplo de chero de traza que contiene datos en Modo 2 se muestra en la gura 9.2. Finalmente, una optimizacin en el cdigo de envo de los paquetes de datos, desde el NI al SCC, ha solucionado esta incidencia. Para ms informacin vase el apartado 9.1.1.2. Pruebas de funcionamiento de la comunicacin Bluetooth con el GPS Leadtek 9553X. En esta ocasin, los dispositivos mviles empleados para la realizacin de estas pruebas han sido: Nokia N93, Nokia E61, Nokia N70, Nokia 6680, Nokia 6230 y Sony-Ericsson K608i. 1. Conexin. Antes de efectuar pruebas con los terminales reales se llevaron a cabo varios test para comprobar el correcto funcionamiento del GPS Leadtek 9553X. El primer test consisti en usar la aplicacin Hyperterminal de Windows XP para monitorizar una comunicacin Bluetooth entre un PC con adaptador USB Bluetooth y el GPS Leadtek 9553X. Este procedimiento ya se ha explicado en 153

TEST 1 2 3 4 5 6 7 8 9 10 11 12 13 14

PROGRAM Main jes-39c-java-comms@14437e jes-c8-java-comms@144378 Main jes-121-java-comms@14437e jes-f5-java-comms@144375 jes-290-java-comms@14437e jes-f4-java-comms@14437d jes-1ba-java-comms@14435d jes-11a-java-comms@14435d JFServerMidp2[00000000]0001 jes-dc-java-comms@14435d jes-e3-java-comms@14435d jes-d4-java-comms@14436b

REASON CODE KERN-EXEC KERN-EXEC E32USER-Cbase USER E32USER-Cbase E32USER-Cbase KERN-EXEC E32USER-Cbase E32USER-Cbase E32USER-Cbase KERN-EXEC E32USER-Cbase E32USER-Cbase KERN-EXEC

REASON NUMBER 3 3 40 42 40 40 3 40 40 40 3 40 40 0

Tabla 9.1: Errores Symbian presentados por el telfono Nokia 9500 durante la comunicacin SPP de Bluetooth . el apartado 4.2.9. La gura 4.19 muestra alguna de las tramas NMEA-0183 recibidas en esta prueba. Posteriormente, se efectuaron con xito pruebas de conexin de los terminales reales con el mdulo GPS Leadtek 9553X. 2. Recepcin y decodicacin de datos. Anlogamente al pulsioxmetro, se hicieron test de vericacin de recepcin y decodicacin de los datos del GPS. Estas pruebas han consistido en el anlisis visual de las sentencias NMEA-0183 mostradas por pantalla y en el anlisis de la informacin recibida del GPS almacenada en cheros de traza. Como ocurra con el Nonin 4100, los datos del GPS se han recibido y decodicado bien cuando la aplicacin se ha ejecutado utilizando nicamente las comunicaciones Bluetooth. Al emplear de manera simultnea las comunicaciones Bluetooth y HTTP o TCP/UDP (WiFi, GPRS o UMTS), se producan de forma muy espordica solapes entre tramas de GPS consecutivas. La optimizacin del cdigo de envo de los paquetes de datos, desde el NI al SCC, ha resuelto el problema. Vase el apartado 9.1.1.2 para ms informacin. Adems de las pruebas anteriores, se realizaron test donde se emple una comunicacin de puerto serie, a travs de un cable USB, que conectaba un PC y el telfono mvil utilizado en la prueba. El terminal mvil reciba los datos del GPS por Bluetooth y los direccionaba al PC, donde eran visualizados por medio de la aplicacin Hyperterminal de Windows XP. Esta prueba permita vericar si las sentencias NMEA-0183 llegaban o no de forma correcta al telfono bajo estudio.

154

Figura 9.1: Fichero de traza donde se han almacenado paquetes de datos en Modo 1.

Figura 9.2: Fichero de traza donde se han almacenado paquetes de datos en Modo 2.

155

9.1.1.2.

Subsistema de comunicaciones con el SCC

Las pruebas de este subsistema se han llevado a cabo utilizando, como soporte hardware para el Nodo Inteligente (NI), los telfonos mviles Nokia N93, Nokia E61 y Sony-Ericsson K608i. Adems, se han empleado varios emuladores del pulsioxmetro Nonin 4100, que son: Emulador del pulsioxmetro Nonin 4100 ejecutado en un PC con Sistema Operativo Linux (desarrollado en el mbito del proyecto AIRES). Emulador del pulsioxmetro Nonin 4100 ejecutado en una PDA con Sistema Operativo Palm OS (desarrollado en el mbito del proyecto AIRES). Emulador del pulsioxmetro Nonin 4100 desarrollado en J2ME (desarrollado por Antonio ngel Botella Galindo en el mbito del presente Proyecto Fin de Carrera). Este emulador J2ME modela el Modo 2 del pulsioxmetro Nonin 4100 [114]. Su funcionamiento consiste en la lectura de tramas de Modo 2 almacenadas en un chero y su posterior envo a travs de una conexin Bluetooth previamente establecida. Por lo tanto, los escenarios de test donde se han realizado las pruebas de este subsistema han sido los siguientes: 1. Telfono mvil (NI), pulsioxmetro Nonin 4100, GPS Leadtek 9553X y SCC. 2. Telfono mvil (NI), emulador del pulsioxmetro Nonin 4100 PC Linux, GPS Leadtek 9553X y SCC. 3. Telfono mvil (NI), emulador del pulsioxmetro Nonin 4100 PDA, GPS Leadtek 9553X y SCC. 4. Telfono mvil (NI), emulador del pulsioxmetro Nonin 4100 J2ME, GPS Leadtek 9553X y SCC. Las pruebas efectuadas a este subsistema se describen a continuacin: Transmisin/Recepcion de datos y de informacin de control por HTTP. Se han efectuado pruebas reales de transmisin/recepcin de datos y de informacin de control (comandos, indicaciones y respuestas, apndice D) , entre la aplicacin del NI y el SCC, utilizando el protocolo de comunicacin HTTP. En estas pruebas, mediante el uso de la herramienta Ethereal que ha sido detallada en el apartado 3.6.6, se ha analizado el trco entrante y saliente al SCC de manera que ha sido posible visualizar el contenido de cada uno de los paquetes que haban intervenido en el proceso de comunicacin. Gracias a ello, ha sido posible depurar la funcionalidad de este subsistema hasta conseguir que su funcionamiento fuese correcto. 156

Transmisin de datos por UDP y transmisin/recepcin de informacin de control por TCP. El esquema de comunicacin TCP/UDP ha sido vericado de manera equivalente al esquema de comunicacin HTTP, es decir, por medio del anlisis del trco entrante y saliente al SCC con la herramienta Ethereal. Todos los test realizados han permitido el renamiento de las funciones de transmisin de datos por UDP y de transmisin/recepcin de informacin de control por TCP, implementadas por este subsistema. En ambos esquemas de comunicacin se ha vericado, mediante el analizador de protocolos Ethereal, que no hay prdidas de paquetes. Emulacin de la transmisin/recepcin de datos cifrados. Se han empleado las herramientas software Carbide.j (apartado 3.6.2) y Sun Java Wireless Toolkit for CLDC (apartado 3.14) para probar el correcto funcionamiento del componente que realiza el cifrado de datos dentro del subsistema de comunicaciones con el SCC (apartado 5.2.5.2.4). Transmisin de datos cifrados por HTTP o UDP. A travs de la herramienta Ethereal se ha comprobado que la transmisin real de datos cifrados al SCC, usando HTTP o UDP, se llevaba a cabo adecuadamente. Cabe destacar que durante el desarrollo de las pruebas reales se han detectado problemas de solapamiento o prdida de sincronismo en la informacin recibida de los dispositivos de la iBAN Bluetooth (pulsioxmetro y GPS), que se producan con el uso simultneo de Bluetooth y de las comunicaciones HTTP o TCP/UDP (WiFi, GPRS o UMTS). Una modicacin en el diseo del cdigo ha solucionado estos problemas. El comportamiento indeseado en la recepcin de la informacin Bluetooth se ha resuelto evitando la acumulacin excesiva de paquetes de datos en el buffer implementado por la clase Queue (apartados 5.2.4.2.3 y 5.2.4.2.4), donde se almacenaba la informacin de monitorizacin de cada dispositivo de la iBAN antes de ser enviada al SCC por el gestor de datos DataHandler (apartado 5.2.5.2.5). El cambio de diseo se ha basado en que cada lectura del buffer sea total, es decir, que se lean todos los paquetes acumulados en l, y no parcial, lectura de un nico paquete, como se haca originalmente. Por ltimo, hay que poner de maniesto que las pruebas efectuadas a este subsistema forman parte del conjunto de pruebas de integracin del NI con el SCC, puesto que su realizacin conlleva la conexin e interaccin entre ambos sistemas. 9.1.1.3. Subsistema de gestin de comandos y control

La funcionalidad de este subsistema ha sido probada mediante la utilizacin de los terminales mviles Nokia N93, Nokia E61 y Sony-Ericsson K608i en los que se ha ejecutado la 157

aplicacin del NI. Las pruebas realizadas han sido las siguientes: Recepcin y decodicacin de comandos procedentes del SCC enviados por HTTP o TCP. Los comandos recibidos del SCC se han almacenado en cheros de traza donde se aada, posteriormente, informacin sobre el proceso de decodicacin realizado por este subsistema antes de la ejecucin de cada comando. Comprobacin de la correcta ejecucin de los comandos mediante el uso de traza visual y cheros de traza en el telfono. Por medio de traza visual ha sido posible conocer si un comando del SCC era ejecutado o no sobre el dispositivo de la iBAN correspondiente. Adems, la informacin visual se ha vericado con la informacin almacenada en cheros de traza que, a su vez, ha sido constatada con el resultado real de la ejecucin del comando: envo del paquete de respuesta al SCC. Comprobacin de la correcta ejecucin de los comandos mediante el uso de las interfaces grcas de las unidades de control y monitorizacin mviles (UCMM) y no mviles (UCMNM) (apartado 2). En las pruebas reales donde han participado las unidades UCMM y UCMNM, se ha dispuesto de estas fuentes de informacin adicionales, junto con las anteriormente mencionadas, para constatar que el funcionamiento de este subsistema era satisfactorio. Otra vez hay que resaltar que las pruebas realizadas a este subsistema se encuentran dentro del grupo de pruebas de integracin del NI con el SCC, ya que su ejecucin conlleva la conexin e interaccin de ambos sistemas. 9.1.1.4. Subsistema de procesamiento y gestin de alarmas

Emulacin de la generacin y del envo de alarmas SMS/MMS. Con anterioridad a la utilizacin de los dispositivos reales, la funcionalidad de este subsistema fue probada mediante el uso de emuladores de las herramientas software Carbide.j (apartado 3.6.2) y Sun Java Wireless Toolkit for CLDC (apartado 3.6.5). Generacin y envo real de alarmas SMS/MMS. Una vez comprobada su correcta funcionalidad, se hicieron pruebas reales de generacin y envo de alarmas SMS/MMS, donde los terminales mviles involucrados fueron los siguientes: 1. Nokia N93 como soporte hardware del NI. 158

2. Nokia N70 y Nokia 6230 como terminales de recepcin de las alarmas SMS/MMS. Se ha de puntualizar que los telfonos utilizados en estas pruebas para recibir las alarmas SMS/MMS, Nokia N70 y Nokia 6230, han actuado como cualquier telfono de uso normal, es decir, se han limitado a recibir el mensaje SMS/MMS correspondiente y a almacenarlo en la bandeja de entrada del terminal. Una vez que los mensajes eran recibidos, se comprobaba si su contenido era correcto y se ajustaba al formato la alarma creada.

9.1.2.

Pruebas de integracin del NI con el SCC

La integracin del Nodo Inteligente (NI) con el Servidor de Control Central (SCC) se ha vericado a partir de la conexin e interaccin entre ambos sistemas. Ambos aspectos han sido previamente depurados en las pruebas de funcionalidad del subsistema de comunicaciones con el SCC (9.1.1.2) y del subsistema de gestin de comandos y control (9.1.1.3). A esto, aadir slamente que para la conexin del NI con el SCC se llevaron a cabo pruebas utilizando las siguientes tecnologas de comunicacin: WiFi. La mayora de los test de integracin se han realizado utilizando esta tecnologa de comunicacin y el telfono Nokia N93. No obstante, algunas de estas pruebas se efectuaron usando el telfono Nokia E61. En todas ellas, el comportamiento del NI y del SCC era el esperado. UMTS. Algunos test fueron realizados con UMTS empleando el telfono SonyEricsson K608i y una tarjeta SIM, de pruebas, que haba sido proporcionada por MovilForum [160]. Lo ms signicativo es que durante el desarrollo de la prueba, a veces, se perda la conexin por UMTS y dejaban de llegar paquetes de datos al SCC. Este hecho fue detectado gracias al anlisis del trco del SCC con la herramienta Ethereal y no se ha podido desvelar si se deba al propio telfono, a la red del operador o a las restricciones de transmisin impuestas por MovilForum.

9.1.3.

Pruebas de jitter

Algunas pruebas en relacin al jitter han sido realizadas. El jitter se dene como la diferencia de tiempos entre dos recepciones consecutivas. En nuestro caso particular se enviarn paquetes desde el NI al SCC, por lo que ser en este ltimo donde se mida este parmetro. Se han realizado dos test, referidos como test1 y test2, cuyas condiciones de realizacin se enumeran a continuacin: iBAN compuesta por un nico dispositivo que es el pulsioxmetro Nonin 4100. 159

Pulsioxmetro funcionando en Modo 2 (375 bytes/s). Esquema de comunicacin HTTP. Es ms restrictivo que el esquema TCP/UDP ya que en ste ltimo los datos se transmiten por UDP, no orientado a la conexin, mientras que en HTTP, orientado a la conexin, para cada envo efectuado se abre y se cierra la conexin subyacente (TCP). Datos cifrados con DES, clave compartida de 8 bytes. Tiempo de monitorizacin: Test1: 1 segundo. Test2: 10 segundos Los paquetes de datos en Modo 2 son recibidos por el NI a travs de Bluetooth. Una vez que se tiene la informacin acorde al tiempo de monitorizacin establecido, 1 segundo para test1 (375 bytes) y 10 segundos para test2 (3750 bytes), se encapsula en un paquete que contiene un campo de timestamp (tiempo actual, en milisegundos, referido desde el 1 de Enero de 1970) y un nmero de secuencia. Despus, se enva al SCC que se encargar de recibirlo y decodicarlo. Hay que destacar que este paquete con los campos de timestamp y nmero de secuencia ha sido creado exclusivamente para la realizacin de estas pruebas de jitter. Gracias al campo de nmero de secuencia se ha comprobado que no se han producido prdidas de paquetes. Tecnologa de comunicacin: WiFi. En las guras 9.3 y 9.4 se aprecia la evolucin temporal del jitter para las pruebas test1 y test2, repectivamente. Los histogramas obtenidos a partir de estas evoluciones temporales se muestran en las guras 9.5 y 9.6, respectivamente. Las observaciones que se pueden extraer del anlisis de estas grcas son las siguientes: Test1 (envo de datos desde el NI al SCC cada 1 segundo). Su histograma asociado, vase la gura 9.5, reeja que gran parte de los paquetes que llegan al SCC se reciben con un jitter que se encuentra entre los 1.2 y los 1.4 segundos, que son valores parecidos al tiempo de monitorizacin de la prueba (1 segundo). A pesar de ello, el intervalo que est entre los 0.5 y los 0.7 segundos es el de mayor frecuencia, lo que se debe al modo en el que el NI lee del buffer y enva los datos al SCC (lectura de todos los datos acumulados hasta el momento en el buffer y envo de esta informacin al SCC). Test2 (envo de datos desde el NI al SCC cada 10 segundos). Su histograma asociado, vase la gura 9.6, reeja que el intervalo con mayor frecuencia es el que abarca desde los 9.75 a los 10.75 segundos, que son valores cercanos al tiempo de monitorizacin de la prueba (10 segundos).

160

6.000,00

5.000,00

4.000,00 Jitter (mseg)

3.000,00

2.000,00

1.000,00

0,00 1 68 135 202 269 336 403 470 537 604 671 738 805 872 939 1006 1073 1140 1207 1274 Num. Muestras

Figura 9.3: Valores de jitter para tiempo de monitorizacin de 1 segundo.

20.000,00 18.000,00 16.000,00 14.000,00 12.000,00 Jitter 10.000,00 8.000,00 6.000,00 4.000,00 2.000,00 0,00 1 69 137 205 273 341 409 477 545 613 681 749 817 885 953 1021 1089 1157 1225 1293 Num. Muestras

Figura 9.4: Valores de jitter para tiempo de monitorizacin de 10 segundos.

161

400 350 300 250 Frecuencia 200 150 100 50 0 0 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600 1700 1800 Jitter (mseg)

Figura 9.5: Histograma del jitter con tiempo de monitorizacin de 1 segundo.

700

600

500 Frecuencia

400

300

200

100

0 0 9000 9500 10000 10500 11000 11500 12000 12500 Jitter (mseg)

Figura 9.6: Histograma del jitter con tiempo de monitorizacin de 10 segundos.

162

9.1.4.

Pruebas de medida de la batera del telfono Nokia N93

Se ha llevado a cabo una prueba para medir el tiempo de duracin de la batera del telfono Nokia N93, funcionando como Nodo Inteligente (NI). Las condiciones de realizacin de la prueba se enumeran a continuacin: iBAN compuesta por un nico dispositivo que es el pulsioxmetro Nonin 4100. Pulsioxmetro funcionando en Modo 2 (375 bytes/s). De los dos modos es el de mayor rgimen binario, lo que implica un aumento en el consumo de la batera respecto al uso del Modo 1 (3 bytes/s). Esquema de comunicacin HTTP. Es ms restrictivo que el esquema TCP/UDP ya que en ste ltimo los datos se transmiten por UDP, no orientado a la conexin, mientras que en HTTP, orientado a la conexin, para cada envo efectuado se abre y se cierra la conexin subyacente (TCP). Datos cifrados con DES, clave compartida de 8 bytes. Tiempo de monitorizacin de 1 segundo. Cada paquete de datos en Modo 2 recibido por Bluetooth se retransmite al SCC cada segundo. Tecnologa de comunicacin: WiFi. El tiempo de duracin de la batera medido en estas condiciones de funcionamiento ha sido de 4 horas y 11 minutos.

9.2.

Software de recepcin y noticacin de alarmas

Los test efectuados para probar el funcionamiento de esta aplicacin han sido los siguientes: Emulacin de la aplicacin de recepcin y noticacin de alarmas. Antes de hacer pruebas con dispositivos reales, la funcionalidad de esta aplicacin ha sido probada mediante el uso de emuladores las herramientas software Carbide.j (apartado 3.6.2) y Sun Java Wireless Toolkit for CLDC (apartado 3.6.5). Todas las pruebas llevadas a cabo se realizaron con xito, comprobndose el buen funcionamiento de la aplicacin al ejecutarse en los emuladores. Prueba real utilizando el terminal Nokia N93 como Nodo Inteligente (NI) y el telfono Nokia N70 como soporte hardware para la aplicacin de recepcin y noticacin de alarmas. Hay que destacar que nicamente se ha probado la recepcin de alarmas SMS ya que el terminal Nokia N70 slo dispone de la interfaz JSR-120 (creacin y gestin 163

de mensajes SMS) que es un subconjunto de la interfaz JSR-205 (creacin y gestin de mensajes SMS/MMS) requerida para el uso de esta aplicacin. Con esta prueba real se comprob el correcto funcionamiento del MIDlet de recepcin y noticacin de alarmas SMS, incluido en la aplicacin de recepcin y de noticacin de alarmas (apartado 6.2.3.2).

9.3.

Aplicacin web para la descarga de MIDlets

Las pruebas realizadas para comprobar el correcto funcionamiento de la aplicacin web para la descarga de MIDlets, han sido las siguientes: Conexin de un PC a la aplicacin web para la descarga de MIDlets. En este caso, el cliente y el servidor web se encontraban en la misma mquina. Se utilizaron los navegadores Mozilla e Internet Explorer indistintamente, comprobndose que el comportamiento de la aplicacin era correcto. Conexin del telfono mvil Nokia N93 a la aplicacin web para la descarga de MIDlets, a travs de WiFi. Cabe destacar que el acceso a la aplicacin se hizo desde el cliente web del telfono mvil, usando la tecnologa de comunicacin WiFi. Todas las pruebas realizadas probaron que la aplicacin funcionaba adecuadamente en el caso de interaccionar con terminales mviles.

164

Captulo 10 Conclusiones y lneas futuras

10.1. Conclusiones

Las conclusiones que han podido obtenerse tras el diseo, desarrollo y pruebas del presente PFC, son las siguientes: La eleccin de J2ME como lenguaje de programacin de aplicaciones para terminales mviles, conlleva sus ventajas e inconvenientes. Ventajas: Portabilidad, que permite la migracin de programas J2ME a cualquier plataforma mvil que la soporte (Nokia, Sony-Ericsson, Motorola, Siemens, etc.). Sintaxis sencilla, propia del lenguaje Java, que facilita la tarea de la programacin al desarrollador. Incovenientes: Imposibilidad de acceso a ciertas funcionalidades del telfono, como la conguracin y gestin de las conexiones WiFi, o el conocimiento de algunos parmetros tcnicos del telfono como el nivel de batera, etc. Estricto modelo de seguridad: El estricto modelo de seguridad de J2ME origina que la ejecucin de aplicaciones que realizan operaciones protegidas [68] necesite, a primera vista, la intervencin del usuario. Este hecho se maniesta con la aparicin de continuos cuadros de dilogo que notican dichas operaciones y solicitan el consentimiento del usuario para proseguir con la ejecucin del programa. Aunque existe un aparente problema de usabilidad, una solucin es posible mediante la adquisicin de un certicado de seguridad digital, emitido por una autoridad de certicacin o Certication Authority (CA), previo pago, y posteriormente rmando la aplicacin desarrollada [68]. 165

Symbian, sin embargo, proporciona a sus programadores certicados gratuitos para tal n [161][162]. Dicultad para resolver determinados problemas de programacin: J2ME no permite acceso a todas las capacidades del telfono, lo cual constituye una limitacin para el programador. No obstante, progresivamente aparecen nuevas API para suplir este aspecto. As, es de suponer que a medio plazo se consiga igualar en este aspecto a otros lenguajes como C++, empleado por desarrolladores de aplicaciones Symbian. Asimismo, la falta de acceso al cdigo fuente y el alto nivel de abstraccin que Java ofrece al programador constituyen una limitacin importante a la hora de detectar y resolver problemas relacionados con la mquina virtual de Java (JVM). Por ejemplo, un fallo de la JVM podra ser interpretado errneamente como un fallo de diseo del programador, perdiendose tiempo en el anlisis y la deteccin del mismo. El medio para eliminar el fallo de la JVM consistira en reportarlo a Sun Microsystems. Limitacin de las herramientas de desarrollo software: Durante las pruebas de este proyecto se ha advertido que para la realizacin de aplicaciones J2ME de alta complejidad donde se manejan varias conexiones simultneas (concurrencia) y de diferentes tipos (Bluetooth, HTTP, TCP, UDP, WiFi, etc.), y donde se somete al telfono a continuas aperturas y cierres de conexiones, gran parte de las herramientas de desarrollo software que ofrecen los fabricantes son de utilidad limitada. Por tanto, el escenario objetivo y los dispositivos reales que intervienen en l son los principales recursos que puede emplear el desarrollador para la programacin de dispositivos de capacidad de proceso y memoria limitada. Estas limitaciones se reeren a la emulacin software de dispositivos mviles, ms concretamente, en el presente proyecto, en su comunicacin con dispositivos Bluetooth reales. Por ejemplo, no ha sido posible que la aplicacin del nodo central (NI), ejecutndose en un PC, estableciera una conexin Bluetooth con el sensor Nonin 4100 ni con el GPS. Este hecho se ha debido a la necesidad de realizar el proceso de pairing Bluetooth, previo al establecimiento de la conexin, y a la imposibilidad de los emuladores de introducir/congurar el PIN correspondiente en cada caso. La ausencia de esta funcionalidad provoca que el proceso de desarrollo de las aplicaciones sea ms complicado, haciendo estrictamente necesaria el empleo del telfono mvil para probar el software diseado. Ausencia en el mercado de herramientas para la medicin able del rendimiento de CPU y la utilizacin de memoria (prolers) de las aplicaciones que se ejecutan en telfonos mviles. Adems de la medicin del rendimiento, una herramienta de este tipo podra permitir la visualizacin de las hebras (threads) del Sistema Operativo que se utilizan durante 166

la ejecucin de un programa, facilitando la resolucin de problemas relacionados con stas. Al no disponerse de las mencionadas herramientas prolers, es mayor tanto la complejidad como el tiempo de diseo y desarrollo de los programas.

10.2.

Lneas futuras

A continuacin, se proponen algunas lneas de investigacin futuras, en relacin al presente Proyecto Fin de Carrera, que son las siguientes: Desarrollo de un programa similar al software del Nodo Inteligente (NI) para telfonos Symbian (C++) y realizacin de una comparativa del rendimiento de ambas aplicaciones. Optimizacin y mejora del cdigo de las aplicaciones del Nodo Inteligente (NI) y de recepcin y noticacin de alarmas. Ampliacin y mejora del protocolo denido para la comunicacin entre la aplicacin del Nodo Inteligente (NI) y el Servidor de Control Central (SCC). Integracin de los dos protocolos de envo de datos HTTP y UDP, en la aplicacin del nodo central (NI), de forma que puedan ser utilizados conjuntamente y sea posible conmutar de uno a otro, segn convenga. Diseo de un modelo de prediccin lineal para predecir el valor de los parmetros monitorizados por la iBAN (parmetros mdicos, de localizacin, etc.), mediante el estudio estadstico de la informacin monitorizada con anterioridad. Desarrollar, posteriormente, el cdigo necesario para su inclusin en la aplicacin del nodo central (NI). Introduccin de nuevos sensores biomdicos (electrocardigrafo (ECG), tensimetro, etc.) en la red de rea corporal inteligente (iBAN) desarrollada en este proyecto. Desarrollo de aplicaciones J2ME que emulen sensores biomdicos que puedan funcionar en una red de rea corporal inteligente (iBAN). Desarrollo de una aplicacin J2ME para medir el rendimiento de CPU y memoria (proler) de otra aplicacin J2ME objetivo, que se ejecute en el mismo terminal. Desarrollo de una aplicacin servidora Symbian (C++) que permita a una aplicacin cliente J2ME solicitar parmetros y operaciones del telfono no accesibles a travs de las API J2ME disponibles en los telfonos actuales. Desarrollo de la aplicacin web para la descarga de MIDlets, en formato XHTML.

167

168

Bibliografa
[1] Denicin de e-health en http://en.wikipedia.org/wiki/EHealth. [2] M.J. Morn Fernndez, J.R. Luque Girldez, E. Casilari Prez y A. Daz Estrella, Monitorizacin Inteligente de Pacientes Mediante Tecnologas Inalmbricas, Abril, 2005. [3] M.J. Morn Fernndez, J.R. Luque Girldez, A.A. Botella, E.J. Cuberos, E. Casilari y A. Daz Estrella, A Smart Phone-based Personal Area Network for Remote Monitoring of Biosignals, Enero, 2007. [4] E.J. Cuberos, Desarrollo de una aplicacin de telemedicina para el acceso remoto a bioseales desde dispositivos mviles, Proyecto Fin de Carrera, Universidad de Mlaga, Junio, 2007. [5] SIG (Special Interest Group) en http://www.bluetooth.com/Bluetooth/ SIG/. [6] Estndar IEEE 802.15.1 en http://standards.ieee.org/getieee802/ 802.15.html. [7] Bluetooth SIG (Special Interest Group), Bluetooth Specication Version 2.0 + EDR, Mayo 2007, Documento en formato pdf accesible por internet en la direccin: http://www.bluetooth.com/Bluetooth/Learn/Technology/ Specifications/. [8] Denicin de Bluetooth. Bluetooth en http://es.wikipedia.org/wiki/

[9] Denicin de ISM band en http://en.wikipedia.org/wiki/ISM_ band. [10] Sony-Ericsson, Developing Applications with the Java APIs for Bluetooth (JSR-82), Mayo 2007, Documento en formato pdf accesible por internet en la direccin: http://www.microjava.com/articles/ Bluetooth-jsr-82-training.pdf. 169

[11] Forum Nokia, Bluetooth Technology Overview v1.0, Mayo 2007, Documento en formato pdf accesible por internet en la direccin: http://forum.nokia.com/info/sw.nokia.com/id/ 98f61174-e3fc-499f-be81-7ce66c0a99aa/Bluetooth_ Technology_Overview_v1_0_en.pdf.html. [12] Bluetooth Core Specication v2.1 + EDR en http://www.bluetooth.com/ Bluetooth/Learn/Technology/Core_Specification_v21__EDR. htm. [13] Bluetooth Press Release, Bluetooth Core Specication Version 2.1 + EDR Makes Initial Device Set-Up Faster, Easier and Increases Battery Life, Documento en formato HTML accesible por internet en la direccin: http://www.bluetooth.com/Bluetooth/Press/SIG/BLUETOOTH_ SIG_IMPROVES_USER_EXPERIENCE.htm. [14] GSM en http://en.wikipedia.org/wiki/GSM. [15] Dreamtech Software Team, WAP, Bluetooth, and 3G Programming: Cracking the Code. Nueva York: Hungry Minds, Inc., 2002. [16] GPRS en http://en.wikipedia.org/wiki/General_Packet_Radio_ Service. [17] EGPRS en http://en.wikipedia.org/wiki/Enhanced_Data_Rates_ for_GSM_Evolution. [18] UMTS en http://en.wikipedia.org/wiki/Universal_Mobile_ Telecommunications_System. [19] Denicin de WiFi en http://es.wikipedia.org/wiki/Wi-Fi. [20] Denicin de IEEE 802.11 en http://es.wikipedia.org/wiki/IEEE_ 802.11. [21] IEEE 802.11 Wireless Local Area Networks en http://www.ieee802.org/ 11/. [22] WiFi Alliance en http://www.wi-fi.org/. [23] Denicin de Symbian OS en http://es.wikipedia.org/wiki/ Symbian. [24] Denicin de Symbian OS en http://en.wikipedia.org/wiki/ Symbian_OS. [25] Pgina ocial de Symbian en http://www.symbian.com/. 170

[26] Procesadores ARM en http://www.arm.com/products/CPUs/index. html. [27] Lista de dispositivos Symbian en http://www.symbian.com/phones/ index_disc.html. [28] Symbian Press Release, Symbian to release its rst quarterly nancial and operational results for 2007 on 16 May 2007, Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.symbian.com/ news/pr/2007/pr20079051.html. [29] D. Mery, Symbian OS Version 7, Functional description, Mayo 2007, Documento en formato pdf accesible por internet en la direccin: http://www.symbian. com/files/rx/file6386.pdf. [30] Versiones de Symbian OS en http://www.symbian.com/symbianos/ releases/symbianosreleases.html. [31] Denicin de Windows Mobile en http://es.wikipedia.org/wiki/ Windows_Mobile. [32] Denicin de Palm OS en http://es.wikipedia.org/wiki/Palm_OS# Aplicaciones_incluidas_con_el_Palm_OS. [33] Windows Mobile en http://www.microsoft.com/spain/ windowsmobile/default.mspx. [34] Palm OS en http://euro.palm.com/europe/. [35] P. Naughton y H. Schildt, Java 2: The Complete Reference, 4th Edition. Osborne/McGraw-Hill, 1999. [36] Arquitectura Java en http://www.javahispano.org/text.viewer. action?file=angela_es. [37] M. de Jode, Programming Java 2 Micro Edition on Symbian OS. John Wiley & Sons, Ltd, 2004. [38] M. Kroll y S. Haustein, Java 2 Micro Edition Application Development. Sams Publishing, 2002. [39] S. Glvez y L. Ortega, Java a tope: J2ME (Java 2 Micro Edition). Universidad de Mlaga, 2003. Documento en formato pdf accesible por internet en la direccin: http://www.lcc.uma.es/~galvez/J2ME.html. [40] Listado de todas las JSR (Java Specication Request) denidas por el Java Community Process en http://jcp.org/en/jsr/all. 171

[41] Base de datos de dispositivos J2ME, ordenados segn la plataforma, en http: //www.j2mepolish.org/devices/platform.html. [42] S. Holzner, XHTML. Coriolis, 2000. [43] World Wide Web Consortium, HTML 4.01 Specication, Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.w3.org/ TR/html401/. [44] Manual de PHP en http://es2.php.net/manual/es/introduction. php. [45] R. Lerdorf, PHP Pocket Reference. OReilly, 2000. [46] Pgina ocial de PHP en http://www.php.net/. [47] Descarga de PHP 5.2.2, disponible por internet en la direccin:http://es2.php. net/downloads.php. [48] Denicin de Unied Modeling Language en http://en.wikipedia.org/ wiki/Unified_Modeling_Language. [49] OMG, Introduction to OMGs Unied Modeling Language (UML), Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http://www. omg.org/gettingstarted/what_is_uml.htm. [50] D. Bell, UML basics: An introduction to the Unied Modeling Language, Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http: //www.ibm.com/developerworks/rational/library/769.html. [51] OMG, Unied Modeling Language (UML) version 2.1.1, Mayo 2007, Documento en formato pdf accesible por internet en la direccin: http://www.omg.org/ technology/documents/formal/uml.htm. [52] Sparx Systems, UML Tutorial, Mayor 2007, en http://www.sparxsystems. com.au/UML_Tutorial.htm. [53] OMGs UML Resource Page en http://www.uml.org/#Articles. [54] IBM Rational Softwares UML Resource Page en http://www-306.ibm.com/ software/rational/uml/. [55] D. Carlson, Eclipse Distilled. Addison Wesley Professional, 2005. [56] Denicin de Eclipse Software en http://en.wikipedia.org/wiki/ Eclipse_(software). [57] Manual de ayuda incluido en Eclipse SDK. 172

[58] Proyecto EclipseME en http://eclipseme.org/blog/2005/10/30/ version-121-released/. [59] Proyecto Apache Ant en http://ant.apache.org/. [60] Proyecto CVS en http://www.nongnu.org/cvs/. [61] Descarga de Eclipse SDK, disponible por internet en la direccin: http: //download.eclipse.org/eclipse/downloads/drops/R-3.2. 2-200702121330/. [62] S. Holzner, Eclipse. OReilly, 2004. [63] Eclipse foundation en http://www.eclipse.org/. [64] Forum Nokia, Installation Guide for Carbide.j 1.5, Abril 2007, Documento en formato pdf accesible por internet en la direccin: http://www.forum.nokia.com/info/sw.nokia.com/id/ 5644161a-4009-4814-a6d8-bd0eb9ea6726.html. [65] Descarga de Carbide.j 1.5, disponible por internet en la http://www.forum.nokia.com/info/sw.nokia.com/id/ d9f7e9b2-3932-4358-9e8e-aa5cd26be54e.html. direccin:

[66] Forum Nokia, Datasheet of Carbide.j 1.5, Abril 2007, Documento en formato pdf accesible por internet en la direccin: http://www.forum.nokia.com/info/ sw.nokia.com/id/c01729e1-b387-4787-9add-4d37276965dc/DS_ Carbide_j_1_5.pdf.html. [67] Gua de usuario incluida en Carbide.j 1.5. [68] Forum Nokia, MIDP 2.0: Signed MIDlet Developers Guide v2.0, Abril 2007, Documento en formato pdf accesible por internet en la direccin: http://www.forum.nokia.com/info/sw.nokia.com/id/ 3f8c9f9e-e940-4327-8548-49ed023bfe88/MIDP_2_0_Signed_ MIDlet_Developers_Guide_v2_0_en.pdf.html. [69] J. Knudsen ,Understanding the MIDP 2.0s Security Architecture, Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http:// developers.sun.com/mobility/midp/articles/permissions/. [70] S. Zanella, A Formal Specication of the MIDP 2.0 Security Model, Documento en formato pdf accesible por internet en la direccin: http://www-sop.inria. fr/everest/personnel/Santiago.Zanella/MIDP/. 173

[71] Descarga de herramientas y SDK de Nokia, disponible por internet en la direccin: http://www.forum.nokia.com/main/resources/tools_ and_sdks/listings/index.html. [72] Forum Nokia, Datasheet of Nokia Connectivity Framework 1.2, Abril 2007, Documento en formato pdf accesible por internet en la direccin: http://www.forum.nokia.com/info/sw.nokia.com/ id/da2861ce-8e48-4399-b35f-d332e210cc48/DS__Nokia_ Connectivity_Framework.pdf.html. [73] Gua de usuario incluida en Nokia Connectivity Framework 1.2. [74] Descarga de PC Suite v6.83, disponible por internet en la direccin: http:// europe.nokia.com/A4144905. [75] Descarga de Sun Java Wireless Toolkit for CLDC, disponible por internet en la direccin: http://java.sun.com/products/sjwtoolkit/. [76] Gua de usuario incluida en Sun Java Wireless Toolkit 2.5 Beta 2. [77] Descarga de Ethereal, disponible por internet en la direccin: http://www. ethereal.com/. [78] Ayuda incluida en Ethereal 0.10.14. [79] Especicaciones del telfono Nokia N93, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.forum.nokia.com/ devices/N93. [80] Nonin Medical Inc. en http://www.nonin.com/. [81] Leadtek Research Inc. en http://leadtek.com/. [82] Especicaciones del telfono Nokia 9500, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.forum.nokia.com/ devices/9500. [83] Especicaciones del telfono Nokia 9500, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.nokia.es/ A4180009. [84] Especicaciones del telfono Nokia N93, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.nokia.es/A4353704. [85] Especicaciones del telfono Nokia E61, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.forum.nokia.com/ devices/E61. 174

[86] Especicaciones del telfono Nokia E61, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://europe.nokia.com/ A4145129. [87] Especicaciones del telfono Nokia N70, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.forum.nokia.com/ devices/N70. [88] Especicaciones del telfono Nokia N70, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.nokia.es/A4254082. [89] Especicaciones del telfono Nokia 6680, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.forum.nokia.com/ devices/6680. [90] Especicaciones del telfono Nokia 6680, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.nokia.es/ A4180044. [91] Especicaciones del telfono Nokia 6230, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://www.forum.nokia.com/ devices/6230. [92] Especicaciones del telfono Nokia 6230, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http://europe.nokia.com/ A4145035. [93] Especicaciones del telfono Sony-Ericsson K608i, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http: //www.sonyericsson.com/spg.jsp?cc=global&lc=en&ver= 4001&template=pp1_1_1&zone=pp&lm=pp1&pid=10297. [94] Especicaciones del telfono Sony-Ericsson K608, Marzo 2007, Documento en formato HTML accesible por internet en la direccin: http: //developer.sonyericsson.com/site/global/products/ phonegallery/k608/p_k608.jsp. [95] Sony-Ericsson, Sony-Ericsson K608 White Paper (R2A), Marzo 2007, Documento en formato pdf accesible por internet en la direccin: http: //developer.sonyericsson.com/site/global/docstools/ phonespecs/p_phonespecs.jsp. [96] J.M. Rabanal, Monitorizacin de la pulsioximetra, Febrero 2007, Documento en formato HTML accesible por internet en la direccin: http://www. anestesiavirtual.com/menupulsio.htm. 175

[97] Denicin de pulsioxmetro Pulse_oximeter.

en

http://en.wikipedia.org/wiki/

[98] Denicin de Ley de Beer-Lambert en http://en.wikipedia.org/wiki/ Beer-Lambert_law. [99] M. J. R. Polson y G. L. Morris, Pulse oximeter with improved accuracy and response time, Febrero 2007, Documento en formato HTML accesible por internet en la direccin: http://www.wikipatents.com/5190038.html. [100] J.L. Ayala, A. Padrn, R. Brunet, A. Quiones, T. Salazar y A. M. Martnez, Comparacin de la saturacin arterial del oxgeno por oximetra de pulso y gasometra arterial, Revista Cubana de Medicina Intensiva y Emergencias, Vol.2, No 2, Octubre, 2004. Documento en formato pdf accesible por internet en la direccin: http://bvs.sld.cu/revistas/mie/vol2_2_03/mie05104.pdf. [101] Denicin de pulsioximetra en http://en.wikipedia.org/wiki/ Pulse_oximetry. [102] Alive Technologies en http://www.alivetec.com/. [103] Pulsioxmetro Bluetooth de Alive Technologies en http://www.alivetec. com/products.htm. [104] Card Guard en http://www.cardguard.com/newsite/index.asp. [105] Dispositivos mdicos Bluetooth de Card Guard en http://www.cardguard. com/newsite/inner.asp?cat=20&type=2&lang=1. [106] A & D Medical en http://www.andmedical.com/and_med.nsf/index. [107] Dispositivos mdicos Bluetooth de A & D Medical en http://www. andmedical.com/and_med.nsf/html/telemonitoring. [108] Corscience en http://www.corscience.de/en-index.html. [109] Dispositivos mdicos Bluetooth de Corscience en http://www.corscience. de/en-telemedicine.html. [110] GMP|Wireless Medicine, Inc. en http://www.gmpcompanies.com/. [111] Dispositivos mdicos Bluetooth de GMP|Wireless Medicine, Inc. en http://www. lifesynccorp.com/products/wireless-system.html. [112] Distintos proveedores de dispositivos mdicos para la monitorizacin de pacientes en http://www.ihe-online.com/supplierslist.asp?mai_ id=20&sub_id=259&sub_desc=Oximetry&supsubcatlist=J. 176

[113] Denicin de fotopletismograma en http://en.wikipedia.org/wiki/ Photoplethysmograph. [114] Nonin Medical, Nonin Model 4100 containing Bluetooth Technology Specications, Septiembre 2006, Documento en formato pdf accesible por internet en la direccin: http://www.nonin.com/documents/4100%20Specifications. pdf. [115] Belkin Components en http://www.belkin.com/. [116] Dispositivo GPS Bluetooth F8T051 de Belkin Components en http://www. belkin.com/support/product/?lid=en&pid=F8T051&scid=228. [117] EMTAC Technology Corp. en http://www.emtac.com/. [118] Dispositivos GPS Bluetooth de EMTAC Technology Corp. en http://www. emtac.com/products/index.html. [119] Nokia en http://www.nokia.com/. [120] Dispositivo GPS Bluetooth LD-3W de Nokia en http://www.nokia.es/ soporte_ld3w. [121] Globalsat Technology Corporation en http://www.globalsat.com.tw/ eng/index.htm. [122] Dispositivos GPS Bluetooth de Globalsat Technology Corporation en http:// www.globalsat.com.tw/eng/product_024_00001.htm. [123] Dispositivos GPS Bluetooth de diferentes fabricantes en http://www. btdesigner.com/endproducts/endprod.php?catID=6. [124] Leadtek, Leadtek GPS 9553 Series Wireless Bluetooth GPS: Users Manual, Febrero 2007, Documento en formato pdf accesible por internet en la direccin: http://www.leadtek.com/uk/support/manual.asp?manulineid= 71&manuline=Leadtek+LR9553X. [125] GPS chipsets de chipsets.htm. TDC Ltd. en http://www.tdc.co.uk/gps/gps_

[126] Denicin de Time To First Fix en http://en.wikipedia.org/wiki/ Time_to_first_fix. [127] Protocolo NMEA-0183 en http://www.nmea.org/pub/0183/index. html. [128] Formato de las tramas NMEA-0183 en http://www.gpsinformation.org/ dale/nmea.htm#RMC. 177

[129] Formato de las tramas NMEA-0183 en http://www.kh-gps.de/nmea-faq. htm. [130] JSR 179 Expert Group, Location API for J2ME version 1.0.1, Java Community Process, Java Specicacin Request (JSR) 179, Marzo, 2006. Documento en formato pdf accesible por internet en la direccin: http://jcp.org/aboutJava/ communityprocess/final/jsr179/index.html. [131] Denicin de Distribucin Linux en http://es.wikipedia.org/wiki/ Distribuci%C3%B3n_Linux. [132] Proyecto XAMPP en http://sourceforge.net/projects/xampp/. [133] Descarga de XAMPP disponible en http://sourceforge.net/project/ showfiles.php?group_id=61776. [134] Descarga e instrucciones de instalacin de XAMPP en http://www. apachefriends.org/en/xampp.html. [135] R.S. Pressman, Software Engineering: A Practitioners approach, 5th Edition. Nueva York: McGraw-Hill, 2001. [136] I. Sommerville, Software Engineering, 6th Edition. Addison Wesley, 2000. [137] Motorola, Java APIs for Bluetooth Wireless Technology (JSR-82), Specication Version 1.1, Java Community Process, Java Specicacin Request (JSR) 82, Septiembre, 2005. Documento en formato pdf accesible por internet en la direccin: http://jcp.org/en/jsr/detail?id=82. [138] JSR 75 Expert Group, FileConnection Optional Package 1.0 Specication Rev. 1.00 - Final Release, Java Community Process, Java Specicacin Request (JSR) 75, Junio, 2004. Documento en formato HTML accesible por internet en la direccin: http://www.jcp.org/en/jsr/detail?id=75. [139] JSR 177 Expert Group, Security and Trust Services API (SATSA) for Java 2 Platform, Micro Edition Version 1.0, Java Community Process, Java Specicacin Request (JSR) 177, Septiembre, 2004. Documento en formato pdf accesible por internet en la direccin: http://www.jcp.org/en/jsr/detail?id=177. [140] JSR 118 Expert Group, Mobile Information Device Prole for Java 2 Micro Edition Version 2.1, Java Community Process, Java Specicacin Request (JSR) 118, Junio, 2006. Documento en formato pdf accesible por internet en la direccin: http: //www.jcp.org/en/jsr/detail?id=118. [141] Denicin del algoritmo de cifrado DES (Data Encryption Standard) en http: //es.wikipedia.org/wiki/Data_Encryption_Standard. 178

[142] JSR 205 Expert Group, Wireless Messaging API (WMA) for Java 2 Micro Edition Version 1.0.2 Final Release, Java Community Process, Java Specicacin Request (JSR) 205, Junio, 2004. Documento en formato pdf accesible por internet en la direccin: http://www.jcp.org/en/jsr/detail?id=205. [143] SMIL (Synchronized Multimedia Integration Language) en http://www.w3. org/AudioVideo/. [144] SMIL (Synchronized Multimedia Integration Language) en http://es. wikipedia.org/wiki/SMIL. [145] Sun Microsystems, The MIDP 2.0 Push Registry, Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http://developers.sun. com/techtopics/mobility/midp/articles/pushreg/index.html. [146] Sun Microsystems, How can a MIDlet be launched automatically?, Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http://developers.sun.com/techtopics/mobility/midp/ questions/pushregistry/index.html. [147] Sun Microsystems, Using the Java APIs for Bluetooth, Part 2 - Putting the Core APIs to Work , Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http://developers.sun.com/techtopics/mobility/ apis/articles/bluetoothcore/index.html. [148] Sun Microsystems, The Wireless Messaging API 2.0, Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http://developers. sun.com/techtopics/mobility/midp/articles/wma2/. [149] Denicin de CBS (Cell Broadcast Service) en http://en.wikipedia.org/ wiki/Cell_Broadcast. [150] Denicin de Adobe Dreamweaver en http://es.wikipedia.org/wiki/ Adobe_Dreamweaver. [151] Descarga de Macromedia DreamWeaver 8.0, disponible por internet en la direccin:http://macromedia-dreamweaver.softonic.com/. [152] Microsoft, Lista de controladores de radio Bluetooth incluidos en el Service Pack 2 de Windows XP, Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http://support.microsoft.com/kb/841803/. [153] Microsoft, Cmo instalar y congurar dispositivos Bluetooth en el Service Pack 2 de Windows XP, Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http://support.microsoft.com/kb/883259/es. 179

[154] Motorola, Motorola Phone Tools: Installation and Setup, Mayo 2007, Documento en formato pdf accesible por internet en la direccin: http://www.motorola. com/mdirect/manuals/mpt4Cable_9476A88D.pdf. [155] Sun Microsystems, Whats New in MIDP 2.0, Mayo 2007, Documento en formato HTML accesible por internet en la direccin: http://java.sun.com/ products/midp/whatsnew.html#overtheair. [156] Primeros pasos con Linux http://www.linux-es.org/primeros_pasos. [157] XAMPP para Linux xampp-linux.html. en http://www.apachefriends.org/en/

[158] Lista de errores Symbian Symbian-OS-Error-Codes.html.

en

http://newlc.com/

[159] Prototipo de la aplicacin J2ME desarrollada por Susana Lozano Rodrguez en el Proyecto Fin de Carrera titulado Motor de imgenes para sistema cliente/servidor en J2ME, tutorizado por D. Jos Manuel Cano Garca. Marzo 2006. [160] MovilForum en http://www.movilforum.com/servlet/SrvInicio. [161] Symbian Signed en https://www.symbiansigned.com/app/page. [162] Symbian, Symbian Developer Certicate Request Process v2.0, Abril 2007, Documento en formato pdf accesible por internet en la direccin: https://www.symbiansigned.com/Developer_Certificate_ Request_Process_v2.0.pdf. [163] Denicin de Java Development Kit (JDK) en http://en.wikipedia.org/ wiki/Java_Development_Kit. [164] Denicin de Java Runtime Environment (JRE) en http://en.wikipedia. org/wiki/Java_Runtime_Environment. [165] Denicin de Java Community Process (JCP) en http://jcp.org/en/ introduction/faq. [166] Denicin de Java Specication Request (JSR) enhttp://jcp.org/en/ introduction/faq. [167] Sun Microsystems, Java 2 Starndard Edition API Specication, Abril 2007. Documento en formato HTML accesible por internet en la direccin: http:// java.sun.com/j2se/1.5.0/docs/api/. [168] Denicin de Java ARchive (JAR) en http://en.wikipedia.org/wiki/ JAR_%28file_format%29. 180

[169] Plataformas de telfonos Nokia en devices/matrix_all_1.html.

http://www.forum.nokia.com/

[170] Forum Nokia,Best Practices in UI Design and Programming on Nokia Platforms, Mayo 2007, en http://developers.sun.com/learning/ javaoneonline/2006/mobility/TS-1281.pdf?. [171] Forum Nokia, Series 40 Platform: Introductory White Paper, v2.2, Mayo 2007, en http://forum.nokia.com/info/sw.nokia.com/id/ c1e1cc74-1a9b-46f6-800a-685addae9897/Series_40_Platform_ White_Paper_V2_2_en.pdf.html. [172] Forum Nokia, S60 3rd Edition: Whats New for Developers, v1.6, Mayo 2007, en http://www.forum.nokia.com/info/sw.nokia.com/id/ 9e57fc3c-fdbc-4325-b16a-daf960b716dc/S60_3rd_Edition_ Whats_New_for_Developers_v1_6_en.pdf.html. [173] Forum Nokia, Series 80 Platform 2nd Edition: Introductory White Paper, v1.2, Mayo 2007, en http://forum.nokia.com/info/sw.nokia.com/id/ 40e5c302-5f45-4d26-aa5c-b2f0932a1451/Series_80_Platform_ 2nd_Edition_White_Paper_V1_2_en.pdf.html.

181

182

Apndice A Terminologa relacionada con Java

A continuacin se describen, brevemente, algunos de los conceptos principales relacionados con el lenguaje de programacin Java. Java Lenguaje de programacin de alto nivel, orientado a objetos, creado por Sun Microsystems, Inc. en 1991. Originalmente se llamaba Oak, pero fue renombrado a Java en 1995, tras el lanzamiento de primera versin estable [35]. J2SE (Java 2 Standard Edition) Plataforma Java inicial, orientada al desarrollo de aplicaciones de sobremesa. Contiene las libreras de programacin bsicas, para crear este tipo de aplicaciones. J2EE (Java 2 Enterprise Edition) Plataforma Java que surge con el n de proporcionar a los programadores soporte para la realizacin de aplicaciones distribuidas.Contiene todas las libreras que posee J2SE y aade otras nuevas que son necesarias para la creacin de este tipo de programas. J2ME (Java 2 Micro Edition) Plataforma Java que permite la programacin de aplicaciones para dispositivos con recursos limitados, capacidad de proceso y memoria reducida: telfonos mviles, PDA (Personal Digital Assitant), etc. CLDC (Connected Limited Device Conguration) Conjunto bsico de libreras de J2ME (conguracin), que ofrece la funcionalidad mnima necesaria para la construccin de aplicaciones Java para dispositivos mviles. MIDP (Mobile Information Device Prole) 183

Conjunto adicional de libreras J2ME (perl), que aade nuevos aspectos a la funcionalidad bsica ofrecida por la conguracin que debajo, en su caso, CLDC. Los programas J2ME que se desarrollan de acuerdo a este perl, reciben el nombre de MIDlets. MIDlet Aplicacin J2ME desarrollada de acuerdo al perl MIDP y a la conguracin CLDC. Su clase principal tiene que extender de la clase javax.microedition.midlet.MIDlet, de ah su nombre. Est empaquetado en un chero .JAR (Java ARchive). MIDlet Suite Se denomina as a un chero .JAR (Java ARchive) que alberga varios MIDlets. JDK (Java Development Kit) Conjunto de herramientas para el desarrollo de programas Java, entre las que se encuentran [163]: Compilador (javac). Documentacin de las API de Java (javadoc). Depurador (java debugger o jdb). JRE (Java Runtime Environment). Herramientas adicionales: rmado de aplicaciones (jarsigner), generacin de documentacin Java, etc. Adems, incluye ejemplos de utilizacin de las diferentes API de Java (documentacin explicativa y cdigo fuente). JRE (Java Runtime Environment) Permite la ejecucin de programas Java (J2SE y J2EE) en un ordenador [164]. Est formado por la mquina virtual de Java (Java Virtual Machine) y las libreras bsicas que las aplicaciones pueden usar para su ejecucin. Si adems de la funcionalidad bsica, los programas utilizan otras libreras adicionales, stas hay que aadirlas al JRE para poder ejecutarlos. Ficheros .java Son los cheros que contienen el cdigo fuente de una aplicacin Java. Sern utilizados por el compilador para generar los cheros .class.

184

Ficheros .class Son los cheros Java compilados. Estn formados por lo que se denomina bytecode, que no es ms que una sintaxis intermedia entre el lenguaje Java y el cdigo mquina. El bytecode es la base de la portabilidad de Java. Mquina virtual de Java Se encarga de mapear el bytecode, de los cheros .class, en llamadas del sistema operativo subyacente. La portabilidad que ofrece Java se consigue, por tanto, usando una mquina virtual diferente para cada sistema operativo. JVM (Java Virtual Machine) Mquina virtual Java para las plataformas J2SE y J2EE. KVM (Kilobyte Virtual Machine) Mquina virtual Java para la plataforma J2ME. JCP (Java Community Process) Es un proceso participativo, establecido en 1998, para desarrollar y revisar las especicaciones de la tecnologa Java y sus implementaciones [165]. JSR (Java Specication Request) Documento formal donde se propone el desarrollo de una nueva especicacion o una revisin signicativa de una especicacin existente [166]. API (Application Programming Interface) Una API es una libera Java que contiene un conjunto de paquetes (packages), donde se incluyen una serie de clases e interfaces, que ofrecen una funcionalidad general, ya implementada, y a disposicin del programador. Son creadas de acuerdo a una especicacin (JSR) que las dene . Por ejemplo, en la especicacin de la API J2SE versin 5.0 [167], se encuentran paquetes para la construccin de la interfaz grca de usuario (java.awt), para realizar operaciones de entrada/salida (java.io), para usar comunicaciones HTTP/TCP/UDP (java.net),etc. JAR (Java ARchive) Es un tipo de chero, comprimido, que almacena los .class, y otros datos asociados (texto, fotos, audio, etc.) que constituyen un programa Java [168]. Un chero JAR siempre contiene un chero de maniesto (Manifest).

185

Manifest Se encuentra dentro de un chero JAR e indica la manera en la que ste se va a usar, por ejemplo, estableciendo los parmetros de entrada de la clase principal del programa [168]. JAD (Java Application Descriptor) En J2ME, chero que contiene informacin (atributos) sobre la aplicacin creada: nombre, versin, autor, conguracin y perl utilizados, MIDlet/s que contiene, icono representativo de cada MIDlet, etc.

186

Apndice B Principales Java Specication Request de J2ME

En las tablas B.1 y B.2 se presentan las principales JSR (Java Specication Request) relacionadas con las dos conguraciones de J2ME, CDC y CLDC, respectivamente [76][40]. JSR JSR 218 API CDC 1.1 Name Connected Device Conguration Foundation Prole Personal Prole Personal Basis Prole URL http: //jcp.org/en/jsr/detail?id=218 http: //jcp.org/en/jsr/detail?id=219 http: //jcp.org/en/jsr/detail?id=216 http: //jcp.org/en/jsr/detail?id=217

JSR 219 JSR 216 JSR 217

Foundation Prole 1.1 Personal Prole 1.1 Personal Basis Prole 1.1

Tabla B.1: Principales JSR relacionadas con CDC y sus perles [40].

187

JSR

API Name

URL

JSR 248

JSR 185

JSR 139

JSR 118

JSR 75

JSR 82

JSR 135 JSR 120

JSR 172

JSR 177

JSR 179 JSR 180 JSR 184

JSR 205

Mobile Service Architecture JTWI Java 1.0 Technology for the Wireless Industry CLDC Connected 1.1 Limited Device Conguration MIDP Mobile 2.0 Information Device Prole PIM and PDA Optional File Packages for the J2ME Platform Bluetooth Java APIs for and Bluetooth OBEX MMAPI Mobile Media 1.1 API WMA Wireless 1.0 Messaging API J2ME Web Services Specication SATSA Security and Trust Services API for Java ME Location Location API for Java ME SIP SIP API for Java ME 3D Mobile 3D GraphGraphics API ics for J2ME WMA Wireless 2.0 Messaging API

MSA 1.0

http: //jcp.org/en/jsr/detail?id=248 http: //jcp.org/en/jsr/detail?id=185

http: //jcp.org/en/jsr/detail?id=139

http: //jcp.org/en/jsr/detail?id=118 http: //jcp.org/en/jsr/detail?id=75

http: //jcp.org/en/jsr/detail?id=82 http: //jcp.org/en/jsr/detail?id=135 http: //jcp.org/en/jsr/detail?id=120 http: //jcp.org/en/jsr/detail?id=172 http: //jcp.org/en/jsr/detail?id=177

http: //jcp.org/en/jsr/detail?id=179 http: //jcp.org/en/jsr/detail?id=180 http: //jcp.org/en/jsr/detail?id=184 http: //jcp.org/en/jsr/detail?id=205

Tabla B.2: Principales JSR relacionadas con CLDC y MIDP [76][40] (I). 188

JSR

API Name

URL

JSR 211 JSR 226

CHAPI

JSR 229 JSR 234 AMMS

Content Handler API Scalable 2D Vector Graphics API for J2ME Payment API Advanced Multimedia Supplements Mobile Internationalization API Java Binding for OpenGL R ES API Mobile Information Device Prole

http: //jcp.org/en/jsr/detail?id=211 http: //jcp.org/en/jsr/detail?id=226

http: //jcp.org/en/jsr/detail?id=229 http: //jcp.org/en/jsr/detail?id=234 http: //jcp.org/en/jsr/detail?id=238

JSR 238

MIA

JSR 239

http: //jcp.org/en/jsr/detail?id=239 http: //jcp.org/en/jsr/detail?id=271

JSR 271

MIDP 3.0

Tabla B.3: Principales JSR relacionadas con CLDC y MIDP [76][40] (II) (continuacin).

189

190

Apndice C Plataformas de telfonos mviles Nokia

En las tablas C.1, C.3, y C.4 se resumen las principales caractersticas de las tres plataformas de telfonos mviles que Nokia tiene actualmente en el mercado, es decir, las Series 40, 60 y 80, respectivamente [169][170][171][172][173]. Adems, se recomienda la lectura del apndice B, para la consulta de las siglas que aqu se utilizan, puesto que han sido previamente denidas en dicho apndice. Para ms informacin vase la pgina ocial de Forum Nokia [169].

Caractersticas Sistema Operativo Resolucin (pxeles) y Nmero de teclas software

S40 1st Edition Nokia OS 128 x 128 o3 128 x 160 208 x 208 240 x 320 2 3 3 3

S40 2nd Edition Nokia OS 128 x 128 o3 128 x 160 208 x 208 240 x 320 2 3 3 3

S40 3rd Edition Nokia OS 128 x 128 o3 128 x 160 208 x 208 240 x 320 2 3 3 3

Tabla C.1: Principales caractersticas de los telfonos Nokia de la Serie 40 [169][171] (I). 191

API incluidas

CLDC1.0 (JSR 30) MIDP 1.0 (JSR 37)

CLDC 1.1 (JSR 139) MIDP 2.0 (JSR 118) Bluetooth API (No OBEX) (JSR 82) WMA 1.0 (JSR 120) MMAPI 1.0 (JSR 135) Paquetes opcionales (slo en algunos telfonos):

CLDC 1.1 (JSR 139) MIDP 2.0 (JSR 118) Bluetooth API (with OBEX) (JSR 82) WMA 1.0 (JSR 120) MMAPI 1.1 (JSR 135) FileConnection and PIM API (JSR 75) Mobile 3D Graphics API (JSR 184) Scalable 2D Vector Graphics API for J2ME1 (JSR-226) Adems de todas las API anteriores, la S40 3rd Edition FP1 (Feature Pack 1) incluye: WMA 1.1 (JSR 205) Scalable 2D Vector Graphics API for J2ME (JSR 226) Web Services API (JSR 172) Adems de todas las API anteriores, la S40 3rd Edition FP2 (Feature Pack 2) incluye: SATSA API (JSR 177) MMAPI 1.1 (JSR 135) con soporte RTSP (Real Time Streaming Protocol).

FileConnection and PIM API (JSR 75) Mobile 3D Graphics API (JSR 184)

Tabla C.2: Principales caractersticas de los telfonos Nokia de la Serie 40 [169][171] (II) (continuacin).

192

Caractersticas Sistema Operativo Resolucin (pxeles)

S60 1st Edition Symbian OS 176 x 208 240 x 320 352 x 416

S60 2nd Edition Symbian OS 176 x 208 240 x 320 352 x 416

S60 3rd Edition Symbian OS 176 x 208 240 x 320 352 x 416 MIDP 2.0 (JSR 118)

MIDP 2.0 (JSR 118) CLDC 1.1 (JSR 139) o CLDC 1.0 (JSR 30) MIDP 1.0 (JSR 37) CLDC1.0 (JSR 30) API incluidas WMA 1.0 (JSR 120) Paquetes opcionales (slo en algunos telfonos): WMA 1.0 (JSR 120) MMAPI 1.0/1.1 (JSR 135) Bluetooth API (No OBEX) (JSR 82)

CLDC 1.1 (JSR 139) WMA 1.1 (JSR 205) MMAPI 1.0/1.1 (JSR 135) Bluetooth API (with OBEX) (JSR 82) FileConnection and PIM API (JSR 75) Location API (JSR 179) SATSA API (JSR 177) SIP API (JSR 180) Adems de todas las API anteriores, la S60 3rd Edition FP1 (Feature Pack 1) incluye: Advanced Multimedia Supplements API (JSR-234) Scalable Vector Graphics 2D API (JSR-226) Mobile 3D Graphics API (JSR 184) Mejoras de la S60 3rd Edition FP2 (Feature Pack 2) sobre el FP1: MIDP 2.1 (JSR 118) Scalable Vector Graphics 2D API (JSR-226) mejorada. Bluetooth API (JSR 82) mejorada. Antes v1.0 y ahora v1.1.

MMAPI 1.0 (JSR 135)

FileConnection and PIM API (JSR 75) Mobile 3D Graphics API (JSR 184)

Tabla C.3: Principales caractersticas de los telfonos Nokia de la Serie 60 [169][170][172]. 193

Caractersticas Sistema Operativo Resolucin (pxeles)

S80 1st Edition Symbian OS v6.0 640 x 200

S80 2nd Edition Symbian OS v7.0s 640 x 200 Mobile Information Device Prole (MIDP) 2.0 y Connected Limited Device Conguration (CLDC) 1.1: MIDP 2.0 (JSR 118) CLDC 1.1 (JSR 139) WMA 1.0 (JSR 120) MMAPI 1.0 (JSR 135) Bluetooth API OBEX) (JSR 82) (No

JavaPhone API API incluidas Personal Java

FileConnection and PIM API (JSR 75) Personal Prole y Connected Device Conguration (CDC): CDC 1.0 (JSR 36). Foundation Prole 1.0 (JSR 46) Personal (JSR 62) Prole 1.0

Tabla C.4: Principales caractersticas de los telfonos Nokia de la Serie 80 [169][173].

194

Apndice D Protocolo de comunicacin entre el NI y el SCC

A continuacin, se muestran los distintos paquetes de informacin que se denen dentro del protocolo de comunicacin especco utilizado por el Nodo Inteligente (NI) y el Servidor de Control Central (SCC), as como tambin el formato de las tramas GPS que el SCC ser capaz de decodicar.

D.1.
D.1.1.

Paquetes del protocolo

Paquete de identicacin de paciente

Este paquete se utiliza durante el establecimiento de la comunicacin entre el NI y el SCC para identicar al paciente del sistema (gura 2.1) que est solicitando la conexin con el Servidor de Control Central (SCC). La gura D.1 [4] muestra el contenido de este paquete, que es el siguiente: 1. Bytes de sincronizacin. Siempre son dos bytes y tienen valor 0xFF. Facilitan la lectura de los paquetes que pertenecen a este protocolo dentro del ujo de bytes de la comunicacin entre el NI y el SCC. Indican que el MSB (byte ms signicativo) es el ms situado a la izquierda del paquete (0xFF) y que el LSB (byte menos signicativo) el ms situado a la derecha. 2. Campo de identicacin de paquete. Est formado por un nico byte que tendr un valor distinto segn el signicado del paquete. El valor 0x01 indica que se trata del paquete de identicacin de paciente. 3. Campo de longitud (LENGTH). Est formado por dos bytes que representan un valor entero que indica la longitud del resto de la informacin del paquete. El MSB (byte ms signicativo) es el byte situado ms a la izquierda, que es el criterio general utilizado para todos los campos. 195

Figura D.1: Paquete de identicacin de paciente [4]. 4. Campo de identicacin de paciente. Posee 4 bytes que representan el valor entero que designa al paciente que ha efectuado el envo de este paquete. De nuevo, el MSB (byte ms signicativo) es el byte situado ms a la izquierda. Para el resto de paquetes del protocolo slo se detallarn los campos que son especcos de cada uno de ellos.

D.1.2.

Paquete de envo de comandos

Se emplea para el envo de comandos desde el SCC hacia el NI. El campo de identicacin de paquete vale 0x02 y sus campos especcos son (gura D.2 [4]): 1. Campo de identicacin de sensor (ID Sensor). El valor 0x01 indica que se tratan de datos procedentes del pulsioxmetro, mientras que el valor 0x02 est asociado a datos que genera el GPS. 2. Campo de identicacin de comando (CMD). Puede tener distintos valores que representan a diferentes comandos que se pueden aplicar sobre cada dispositivo. Estos comandos son: RESTART. Indica que el dispositivo debe pasar de su modo de funcionamiento actual a su modo por defecto, es decir, al modo en el que inici su funcionamiento. CHANGE MODE. Se utiliza para cambiar entre modos de funcionamiento distintos. La informacin que le sigue (Mode) es un byte que indica el modo al que se desea cambiar (modo destino). PARAMETERS THRESHOLD. Permite modicar los valores umbrales de los parmetros que son monitorizados para un dispositivo en concreto. El campo Code hace referencia al parmetro en cuestin, que ser HR (Heart Rate) (0x01) o SPO2 (0x02) para el pulsioxmetro y latitud (0x01) o longitud (0x02) para el GPS. El campo Vmin contiene el umbral mnimo y el campo Vmax el umbral mximo, siendo el MSB (byte ms signicativo) es el byte situado ms a la izquierda. 196

Figura D.2: Paquete de envo de un comando [4].

Figura D.3: Paquete de envo de datos [4]. MONITORING TIME. Se utiliza para indicar el nmero de segundos de monitorizacin que el NI debe almacenar antes de enviar un paquete de datos hacia el SCC o para cambiar el tiempo de adquisicin entre muestras de GPS consecutivas.

D.1.3.

Paquete de envo de datos

Se utiliza para el envo de datos desde el NI hacia el SCC. El campo de identicacin de paquete vale 0x03 y sus campos especcos son (gura D.3 [4]):

1. SEQ No. Nmero de secuencia del paquete de datos. 2. GPS or sensor data. Contiene los datos del pulsioxmetro o del GPS que se quieren transmitir.

197

Figura D.4: Paquete de indicacin/respuesta [4].

D.1.4.

Paquete de indicacin/respuesta

Es enviado desde el NI hacia el SCC cuando un dispositivo de la iBAN se desconecta o para responder a la peticin de ejecucin de un comando. El campo de identicacin de paquete vale 0x04 y sus campos especcos son (gura D.4 [4]): CODE. Es el cdigo que describe si el envo fue una indicacin de desconexin (SENSOR DISC) o una respuesta a una solicitud de ejecucin de un comando (ACK, NAK o ERR). ACK y NAK indican si el comando fue o no fue ejecutado, respectivamente. ERR seala que hubo algn tipo de error y que el comando no pudo ser ejecutado. CMD. El valor de este campo est asociado al comando solicitado cuya respuesta se incluye en el paquete.

D.1.5.

Paquete de indicacin del puerto UDP

Es enviado desde el SCC hacia el NI como respuesta al paquete de identicacin de paciente en comunicaciones TCP/UDP . El puerto UDP donde el SCC debe recibir los paquetes de 198

Figura D.5: Paquete de puerto UDP [4]. datos del NI est representado por el campo UDP PORT (gura D.5 [4]). En este caso, el campo de identicacin de paquete vale 0x05.

D.2.

Formato de las tramas GPS a recibir en el SCC

Los datos de latitud, longitud y velocidad proporcionados por el mdulo GPS, junto con la fecha de adquisin de dicha informacin, debern unicarse en una misma trama, entendible por el Servidor de Control Central (SCC) cuyo formato se dene como: latitud;longitud;velocidad;fecha. Por ejemplo, una trama vlida sera la siguiente: "36.715570 S;4.478403 W;0.000000;2006-11-27T15:48:52.00Z".

199