RIETA CARBONELL, Joaquin (C/ Colón, 7 8, 23ª Valencia, E-46004, ES)
| REIVINDICACIONES Ia.- Sistema móvil de tele-asistencia, que comprende un teléfono móvil (1) y una pulsera-reloj (2) o colgante (2'), en donde el teléfono móvil (1) comprende, a su vez, un microprocesador (3), con su correspondiente batería recargable (4), teclado (5) y pantalla (6), módulo GSM/PGRS (7), módulo de comunicaciones GPS (8) y módulo de comunicaciones vía Bluetooth (9) y que se caracteriza porque dicho teléfono (1) comprende, al menos, una pareja de pulsadores de marcación directa, un primer pulsador de ayuda (10) programado para realizar una llamada directa a un familiar (12) o responsable (13) del usuario del teléfono, y un segundo pulsador, de emergencia (11) de contacto con los servicios de emergencia (14), y en donde el reloj o pulsera (2), o en su caso el colgante (2'), está constituido, al igual que el teléfono móvil (1) a partir de una carcasa ergonómica, resistente al agua y a los golpes, en cuyo seno se establece un circuito de control (16), asistido por su correspondiente batería (17), dotado de un circuito de comunicación vía Bluetooth (19), con el teléfono móvil (1), circuito de control (16) al que se asocian una pluralidad de sensores del estado del usuario, información que es enviada al teléfono móvil a través del circuito de comunicación (19), y de éste a un servidor (23) dotado de un software de registro e interpretación de dichos datos, así como de comunicación automática con las personas o servicios de urgencia de que se traten en función de la gravedad de cada caso; caracterizándose además porque en el caso de que el envío de mensaje falle, el sistema comprende medios de reenvío automático, de forma que el usuario no tenga que pulsar de nuevo para enviar un mensaje de socorro. 2a.- Sistema móvil de tele-asistencia, según reivindicación Ia, caracterizado porque los sensores de estado del usuario se materializan en un acelerómetro (34), un sensor de temperatura corporal (31), un pulsímetro (32), un podómetro (33), así como sensores (24) de parámetros ambientales. 3a.- Sistema móvil de tele-asistencia, según reivindicación Ia, caracterizado porque el citado reloj o pulsera (2), o en su caso el colgante (2'), está dotado de un pulsador, de emergencia (11 ') análogos a los del teléfono móvil (1), y asociados al circuito de control (16), cuya señal es enviada por el circuito de comunicación vía Bluetooth (19) al teléfono móvil (1). |
La presente invención se refiere a un sistema que ha sido especialmente concebido para la tele-asistencia y seguridad personal de personas mayores o dependientes (niños, enfermos y discapacitados).
El objeto de la invención es proporcionar una serie de dispositivos ergonómicos, fáciles de utilizar, especialmente concebidos para luchar contra la soledad de las personas dependientes, incrementar su autonomía, mejorar su calidad de vida, reducir el estrés de sus familiares y cuidadores, facilitar y potenciar el control y la comunicación de estas personas con familiares, amigos, etc., ayudando a reducir el tiempo de respuesta ante situaciones de riesgo o emergencia, mejorando la atención asistencial de dicho colectivo dependiente.
ESTADO DE LA TÉCNICA ANTERIOR
Como es sabido, las personas mayores o dependientes tienen una autonomía reducida, al ser necesario tener a alguien a su cargo. En este sentido, y en función del grado de dependencia de los mismos, son conocidos teléfonos móviles con una interfaz mucho más sencilla que los teléfonos convencionales, en el que los números del teclado presentan una considerable volumetría, en orden a facilitar su visualización por parte de personas con deficiencias visuales, etc.
Sin embargo, éste tipo de dispositivos siguen resultando funcionalmente insuficientes a la hora de pretender dar mayor autonomía a éste colectivo, dado el riesgo que pueden tener de caídas, accidentes, etc.
EXPLICACIÓN DE LA INVENCIÓN
El sistema móvil de tele-asistencia que la invención propone resuelve de forma plenamente satisfactoria la problemática anteriormente expuesta, proporcionando a dicho colectivo un incremento en su autonomía, una mejora en su calidad de vida, con la consecuente reducción del estrés por parte de sus familiares y cuidadores, todo ello con unas características que permiten reducir el tiempo de respuesta ante situaciones de riesgo o emergencia. Para ello, el sistema que se preconiza está constituido a partir de dos dispositivos, que se comunican entre sí; un teléfono móvil, y un módulo pulsera o reloj .
De forma más concreta, el teléfono móvil se materializará en un dispositivo GSM/UMTS/GPRS, con una especial interfaz de control, que lo haga fácil de utilizar por personas mayores o dependientes, con teclas en relieve y braille, con una gran pantalla, y la correspondiente electrónica de control para establecer comunicación mediante llamadas o mensajes cortos.
Adicionalmente, se ha previsto que en la interfaz del teléfono se establezca una tecla de "ayuda", de marcación directa de un teléfono de un familiar o persona al cargo, y una tecla de socorro o SOS, de llamada automática a los servicios de emergencia.
Tanto el teclado como las teclas auxiliares serán luminiscentes, en orden a facilitar su visión en la oscuridad.
De acuerdo con otra de las características de la invención, el teléfono móvil se complementa con un reloj o pulsera, que igualmente podría materializarse en un colgante, dispositivo dotado con un circuito de comunicación vía Bluetooth con el teléfono móvil, circuito al que están asociados, al igual que al teléfono, un pulsado de "socorro".
Adicionalmente, se ha previsto que la pulsera esté dotada de diferentes tipos de sensores, que permitan obtener la temperatura corporal del usuario, y la pulsioximetría (medida del pulso) del citado usuario,
Estos parámetros son registrados por el circuito asociado a la pusera/reloj, y enviados por conexión Bluetooth al teléfono móvil, el cual los almacenará en un registro, que se podrá mostrar en el display del teléfono o enviarse a un servidor de Internet.
El teléfono móvil igualmente incorpora elementos captadores de parámetros ambientales, incorporando igualmente un acelerómetro, que permita detectar una posible caída del sujeto.
Así pues, el teléfono móvil es susceptible de comunicarse vía SMS y GPRS con un servidor web, de modo que al detectarse algún tipo de señal alerta, se enviará dicho mensaje SMS al servidor (o mediante conexión GPRS), desde el cual, dependiendo de la gravedad de la alerta se contactará con los familiares, o bien con los servicios de urgencia que procedan. Desde el propio servidor se podrán configurar los contactos a los que llamar en caso de situación de riesgo, así como el envío de mensajes de alerta enviados al teléfono móvil a determinadas horas, como por ejemplo el aviso de la toma de medicinas, hora de paseo, etc.
Finalmente cabe destacar que, también de forma opcional, se ha previsto que dicho teléfono móvil incorpore medios de iluminación, asociados a su correspondiente pulsador, que permitan que dicho dispositivo pueda ser utilizado en funciones de linterna.
A lo largo de la descripción y las reivindicaciones la palabra "comprende" y sus variantes no pretenden excluir otras características técnicas, aditivos, componentes o pasos. Para los expertos en la materia, otros objetos, ventajas y características de la invención se desprenderán en parte de la descripción y en parte de la práctica de la invención. Los siguientes ejemplos y dibujos se proporcionan a modo de ilustración, y no se pretende que sean limitativos de la presente invención. Además, la presente invención cubre todas las posibles combinaciones de realizaciones particulares y preferidas aquí indicadas.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Para complementar la descripción que se está realizando y con objeto de ayudar a una mejor comprensión de las características del invento, de acuerdo con un ejemplo preferente de realización práctica del mismo, se acompaña como parte integrante de dicha descripción, un juego de dibujos en donde con carácter ilustrativo y no limitativo, se ha representado lo siguiente.
La figura 1.- Muestra una vista en perspectiva de los dos elementos principales que participan en el sistema móvil de tele-asistencia objeto de la presente invención.
La figura 2.- Muestra un diagrama de bloques de los diferentes elementos electrónicos principales que participan en ambos dispositivos de la figura anterior.
La figura 3.- Muestra un diagrama de flujo del modo de funcionamiento del sistema.
EXPOSICIÓN DETALLADA DE MODOS DE REALIZACIÓN
A la vista de las figuras reseñadas puede observarse como en el sistema de la invención participa un teléfono móvil (1), que se complementa con una pulsera o reloj (2), el cual, opcionalmente podría materializarse en un colgante (2'), tal como muestra la figura 1.
Pues bien, el teléfono móvil (1) estará constituido, como cualquier teléfono móvil convencional, a partir de un microprocesador (3), con su correspondiente batería recargable (4), teclado (5) y pantalla (6), contando con un módulo GSM/GPRS (7), un módulo de comunicaciones GPS (8) y un módulo de comunicaciones vía Bluetooth (9).
A partir de esta estructuración convencional, el teléfono móvil se caracterizará porque el teclado (5) presentará unas teclas con unas dimensiones sobre-elevadas con respecto a los teclados convencionales, que hagan fácilmente visibles dichas teclas por personas con problemas de vista, presentando éstas relieves en braille.
Complementariamente se ha previsto la inclusión de una pareja de pulsadores de marcación directa, un primer pulsador de ayuda (10) que se configurará para permitir realizar una llamada directa a un familiar (12) o responsable (13) del usuario del teléfono, y un segundo pulsador, de emergencia (11) para contactar con los servicios de emergencia (14), como por ejemplo con el 112.
El teléfono podrá tener un software mediante el cual, y a través del correspondiente altavoz (15), cada vez que se pulse una tecla se emita un mensaje sonoro correspondiente al contenido de dicha tecla, en orden a permitir utilizar el dispositivo por personas invidentes.
Las teclas del teclado estarán asistidas por los correspondientes diodos LED o elementos de iluminación complementarios, en orden a que éstas sean fácilmente identificables en condiciones de baja luminosidad.
Por su parte, el reloj o pulsera (2), o en su caso el colgante (2'), estará constituido, al igual que el teléfono móvil (1) a partir de una carcasa ergonómica, resistente al agua y a los golpes, en cuyo seno se establece un circuito de control (16), asistido por su correspondiente batería (17), dotado de un circuito de comunicación vía Bluetooth (19), con la particularidad de que a dicho circuito de control (16) se asocian una pluralidad de sensores, tales como un sensor de temperatura corporal (31), y un pulsioxímetro (32).
El citado reloj o pulsera (2), o en su caso el colgante (2'), estará igualmente dotado de un pulsador de emergencia (11 ') análogo a los del teléfono móvil (1), señal que será igualmente enviada al teléfono móvil para que a través de éste se lleve a cabo y de forma automática la marcación directa de los teléfonos programados para cada pulsador. Así pues, y de acuerdo con la figura 3, el teléfono móvil (1) de usuario (20) se comunica vía satélite (21), a través de Internet (22) con un servidor (23) en el que se almacenan los datos tomados por los diferentes sensores, datos a los que pueden acceder los familiares (12) personas al cuidado o responsables (13), ya sea a través de sus propios teléfonos (25), o a través de respectivos ordenadores (26) mediante comunicación con el citado servidor (23), estando dicho servidor capacitado para contactar igualmente con las personas o servicios de que se trate de forma totalmente automática, en función de la gravedad que se determine en el análisis de los citados datos enviados por los diferentes sensores.
Complementariamente, el teléfono móvil comprende un acelerómetro (34) y una pluralidad de sensores ambientales (24) que permitan registrar la mayor cantidad posible de información.
Por su parte, se ha previsto que el teléfono móvil (1) incorpore medios de iluminación (28), para poder utilizarla en funciones de linterna, con su correspondiente circuito integrado (29) al que está asociado el correspondiente interruptor (30).
Así pues, y como ya se ha repetido con anterioridad, el sistema de la invención permite su uso como un teléfono móvil convencional, pero con una interfaz mucho más sencilla de utilizar, con las funciones habituales en este tipo de dispositivos, a las que hay que añadir la posibilidad de realizar llamadas de marcación directa de ayuda o socorro, envío automático de datos del estado del usuario al servidor central para su interpretación de su estado y actuación automática, generación automática de mensajes para el usuario, utilización a modo de linterna, marcación por voz, localización y posicionamiento del usuario en un mapa vía GPS, etc.
En general, la arquitectura del sistema es una arquitectura cliente - servidor, en donde se entiende por cliente tanto al paciente como al técnico de teleasistencia, y donde desde dicha aplicación se accede a un servidor, que a su vez está conectado con una base de datos.
Ejemplo de realización práctica de la pulsera (2)
En general la correa o sistema de cierre debe regularse para cubrir la circunferencia de la muñeca de las personas mayores. El rango de regulación para el sistema de cierre para cubrir el 90% de población debe ser de 143mm a 194mm. Para el cierre se recomienda un sistema tipo Velero ® o similar, puesto que las hebillas pueden dar problemas de manipulación en algunos casos, por ejemplo personas con artrosis. En general, para el tamaño del módulo se recomienda no superar los 42mm, o bien diseñar 2 o 3 tamaños, por ejemplo 40 - 45 - 50 mm.
Los mensajes de la pulsera se transmiten con los LED. Cada uno debe servir para transmitir un mensaje único. No es recomendable que el mensaje dependa de la combinación de dos luces separadas. Por ello, para cada mensaje se emplean dos LED (rojo y verde) dentro de un mismo hueco, de forma que el rojo indica que existe un problema y el verde que está correcto. Por ejemplo:
- Hueco de batería cargada (verde) o poca batería (rojo)
- Hueco teléfono conectado (verde) o desconectado (rojo)
Para indicar que se está transmitiendo un mensaje de SOS sería recomendable que se iluminara el botón o pulsador de emergencia (1 Γ). Podría tener una retro-iluminación o un círculo luminoso alrededor.
La pulsera comprende medios vibradores que deberían avisar de que algo no funciona correctamente y, por tanto, activarse cuando se encienda un LED en color rojo. Es recomendable que el LED rojo parpadee para llamar más la atención del usuario, aunque teniendo la vibración no es imprescindible. El parpadeo del LED rojo debe estar entre 2 y 5Hz, estando activado durante un 50% del ciclo.
Existe la posibilidad (menos recomendable) de no utilizar la vibración como refuerzo de que un LED se ha puesto en rojo. En este caso, es más importante que el LED parpadee, y la pulsera solo vibraría cuando el móvil recibe una llamada entrante.
También se puede configurar con dos ritmos diferentes en la vibración (habría que validarlo con usuarios):
a) El motor vibra de forma continua cuando un LED está en rojo para avisar de que algo va mal.
b) El motor vibra-para- vibra-... para indicar que el móvil ha recibido una llamada. El ciclo puede ser similar al parpadeo del LE, de 2 a 5 Hz.
No es recomendable transmitir más mensajes, a no ser que se disponga de salida de sonido y se puedan emitir mensajes con voz.
En cuanto a los materiales es recomendable asegurar que no se utilizan materiales que provoquen algún tipo de alergia. Por otro lado, el tiempo de activación está comprendido entre 1 y 2s. El dispositivo no debe activarse si se pulsa con una fuerza menor o igual de 0,5N.
En el caso de que el envío de mensaje falle, el sistema comprende medios de reenvío automático, de forma que el usuario no tenga que pulsar de nuevo para enviar un mensaje de socorro.
Arquitectura del sistema de sensores
El presente sistema define una arquitectura de sensores (biosensores) definiendo la comunicación entre estos y el dispositivo central. Para ello primero se definirán los sensores empleados. Como estos sensores pueden tener distintos protocolos, se definirá también un API general de comunicación que haga transparente el empleo de los diferentes protocolos permitiendo de este modo integrar o incorporar distintos sensores sin esfuerzo.
La arquitectura estará formada por los siguientes elementos:
Dispositivo central, que será un dispositivo con la suficiente potencia de cálculo y de memoria para albergar un software que permita gestionar la comunicación con los diferentes sensores del sistema, el procesamiento de los datos recibidos y la aplicación que haga uso de los mismos. Básicamente consistirá en un teléfono móvil inteligente que integre soporte a diferentes protocolos de comunicación, como se ha indicado anteriormente.
Sensores que serán los que proporcionen los datos de monitorización de los usuarios al sistema.
Protocolos de comunicación que serán los que permitan la comunicación (ya sea inalámbrica, cableada o manual) entre los sensores y el dispositivo central. El sistema deberá dar soporte a todos aquellos protocolos existentes en el sistema.
1.- Selección y propuesta de sensores.
En base al estudio realizado sobre sensores que pueden ser aplicados a la monitorización de personas. Estos sensores han sido seleccionados en función de una serie de factores como la intrusividad que presentan, la facilidad de uso y la utilidad de los datos proporcionados entre otros. El pulsómetro preferido es un pulsómetro de cinta pectoral que incorpora el protocolo Bluetooth para emitir los datos que recibe de forma que un dispositivo móvil pueda utilizarlos y, además, permitiendo un alcance mayor de la señal transmitida. Este dispositivo puede ser llevado de forma transparente por el usuario a monitorizar, pudiendo efectuar la lectura de sus datos en cualquier instante.
El dispositivo medidor de tensión arterial comprende un dispositivo para la captura de los valores de tensión arterial del usuario. Este dispositivo no está pensado para ser llevado de forma transparente por el usuario, sin embargo, comprende medios de transmisión Bluetooth.
Los acelerometros integrados en el dispositivo principal en general se trata de considerar el uso de los acelerometros que disponga el dispositivo principal o bien generar un prototipo propio, a fin de monitorizar cambios o movimientos bruscos efectuados por el usuario monitorizado. Si los acelerometros se encuentran dispuestos en el propio dispositivo no es necesario el empleo de ningún protocolo de comunicación. Si por contra se realiza un diseño de prototipo propio se deberá incorporar algún protocolo de comunicación que en este caso se muestra como más efectivo el protocolo Bluetooth.
Como el sistema debe permitir además la introducción de datos de forma manual por parte del usuario se considera interesante el uso de un termómetro de temperatura corporal, de forma que el sistema demande al usuario que realice tomas periódicas e inserte los datos en el dispositivo si es posible de tal modo que pueda tenerse un historial de las tomas. Otro dispositivo a considerar sería el empleo de una báscula que permita controlar el peso del usuario. Con ella se facilitaría los datos o bien de forma manual por parte del usuario o bien de forma inalámbrica si la báscula permite la comunicación mediante Bluetooth
2.- Protocolos de comunicación
En la actualidad existen diferentes protocolos de comunicación inalámbrica disponibles en el mercado, cada uno teniendo en mente diferentes objetivos. En el caso de tratarse de dispositivos móviles como teléfonos móviles inteligentes parece ser que el protocolo Bluetooth es el más extendido ya que tiene unas buenas características para los propósitos de este. Además, y concretamente en el campo de la telemedicina, el Bluetooth parece ser el protocolo que más auge está teniendo dentro de este sector. Es por ello que se considera la utilización para este sistema.
2.1.-Bluetooth La tecnología Bluetooth es una especificación que define un estándar global de comunicación inalámbrica para redes de área personal o PAN. Está especialmente indicada para la transmisión de voz y datos entre diferentes equipos en entornos de comunicación tanto móviles como estáticos.
Entre sus ventajas se encuentran el poco consumo del emisor de radio y sobretodo el bajo coste del chip transmisor. Esto hace que casi todos los dispositivos móviles integren un chip Bluetooth. Con todo ello Bluetooth tiene un alcance de señal en torno a los diez metros (aunque existen versiones con mucho más alcance) y una velocidad aproximada de IMbps que está siendo mejorada con las últimas revisiones.
Cuando varios dispositivos Bluetooth desean establecer comunicaciones entre ellos formarán una piconet. En ella, uno de los dispositivos tomará el rol de dispositivo maestro (que actuará de forma similar a un punto de acceso) mientras que el resto actuarán como dispositivos esclavos. Al igual que ocurre con la tecnología WiFI (pero no es condición necesaria) el dispositivo maestro podrá actuar como una puerta de enlace proporcionando internet a los dispositivos.
Por todas estas características y al presentar una velocidad óptima y un rango de señal aceptable la tecnología Bluetooth se muestra como una solución factible en la telemedicina. Muchos dispositivos de este ámbito están empezando a incorporar este protocolo para transmitir sus datos hacia aplicaciones software más complejas.
2.2.- APIs de programación particular de los sensores integrantes
En este apartado se tratará de proporcionar unas reseñas básicas sobre las facilidades de programación que ofrecen los diferentes dispositivos seleccionados o bien como estos podrán proporcionar al sistema los datos capturados.
Para el caso del pulsometro el modo de empleo es la de instalar un Thread permanente de escucha que obtiene los datos que el sensor va generando. Este Thread deberá tratar las lecturas y obtener el buffer de datos con todos los campos o datos que el sensor posee (además de las lecturas propias del pulsometro, ofrece información sobre la distancia y velocidad [si se dispone de acelerómetros incorporados en el dispositivo]) así como otras informaciones referentes a la versión del dispositivo, etcétera. En caso de no querer emplearse la librería proporcionada es factible el acceso a los datos por medio de Bluetooth al dispositivo de una forma "cruda" ya que la forma en que el dispositivo proporciona la información es por medio de un "buffer" en donde en cada posición se encuentra un campo o dato determinado.
En el caso de los sensores integrados en el dispositivo central, la mayoría de dispositivos portables (ya sean teléfonos móviles inteligentes o pequeños computadores) incorporan diferentes sensores que pueden ser utilizados para usos en aplicaciones particulares. Uno de los sensores más útiles para un proyecto de telemedicina es el del conjunto de acelerómetros del que pueda disponer el dispositivo. Con ellos puede determinarse si el usuario se encuentra en reposo o ha realizado un movimiento brusco.
La capacidad para detectar diferentes situaciones vendrá dada por dos características:
Calidad y cantidad de acelerómetros empleados. Esto determina cuantos ejes o canales proporcionan en cada lectura, la sensibilidad de los mismos frente a cualquier cambio o movimiento y por supuesto el número de los que se dispone para poder realizar un mejor análisis de los movimientos.
Ubicación de los acelerómetros. Esto determina que movimientos y situaciones pueden ser analizados. Usualmente los dispositivos móviles son portados en zonas próximas a la cintura del paciente (bien sea en un bolsillo o en un compartimento a modo de cinturón). Esto debe ser tenido en cuenta para escoger y seleccionar aquellos patrones de cambios en los valores del acelerómetro que signifiquen los diferentes cambios que se buscan. Si los acelerómetros están integrados en el propio dispositivo inteligente el acceso a los mismos se hará con la librería pertinente del lenguaje de programación que se use en el desarrollo de la aplicación.
Si por el contrario ciertos sensores no se encuentran disponibles en el dispositivo central y se decide construir un prototipo propio para incorporar acelerómetros este deberá tener capacidades de comunicación con el dispositivo central. Esto se conseguiría añadiendo un módulo de comunicación inalámbrica adecuado al protocolo a emplearse, en este caso Bluetooh. Con la construcción de un prototipo propio se permitiría diseñarlo e implantarlo en el lugar especialmente que se desea. Por ejemplo, es útil emplazar un dispositivo con sensores acelerómetros en la zona del tobillo del usuario para determinar si se ha producido la caída del mismo. Una posible solución para la construcción del prototipo sería utilizar la arquitectura Arduino que ofrece múltiples posibilidades de construcción pequeños prototipos con hardware programable de una forma fácil y económica. El módulo base donde se encuentra el micro- controlador programable incorpora un acelerómetro de tres ejes. Además se disponen de diferentes módulos adicionales de comunicación inalámbrica, entre ellos el de protocolo Bluetooth.
Para sensores que utilizan protocolos diferentes a Bluetooth, y debido a la proliferación de diferentes protocolos de comunicación inalámbrica, los fabricantes pueden diseñar dispositivos con protocolos de comunicación distintos a Bluetooth empleado en este proyecto. En este caso, debería estudiarse cuáles son las librerías y facilidades de programación que ofrecen y en base a estas tratar de construir un módulo pasarela (ya sea en el propio dispositivo central o bien en un dispositivo autónomo que se encargue de la traducción entre los protocolos) totalmente transparente. Esto permitiría la adopción o reemplazo de diferentes sensores nuevos en la aplicación sin un coste añadido. Para ello se pueden optar par las siguientes soluciones:
Soporte a varios interfaces en el propio dispositivo móvil: en este caso el dispositivo móvil incorpora varios interfaces para los distintos protocolos de comunicación que se utilizan en el proyecto. Actualmente muchos teléfonos móviles inteligentes incorporan soporte a varios protocolos como son WiFI, Bluetooth y el propio protocolo de telefonía móvil (GSM,GPRS o similar) permitiendo usar estos protocolos sin tener que añadir ningún hardware adicional. En este caso se deberán utilizar las librerías que aporte el sistema para su programación e implementar el soporte a cada protocolo.
Módulo pasarela: en este caso se trata de la instalación por cada uno de los protocolos diferentes al protocolo base (que en este caso es Bluetooth) de un hardware que tenga dos interfaces: el primero el del protocolo particular al que se quiere dar soporte y el segundo el del propio adoptado como base para el proyecto. Este se encargaría de capturar los paquetes del primero y realizar la traducción y emisión en el formato del segundo protocolo. Esto presenta la ventaja de facilitar la implementación y manejo de la comunicación por parte del dispositivo principal ya que no debe de incorporar el hardware de interfaz ni la programación del mismo. Además de este modo se permite añadir de forma transparente cuantos nuevos protocolos aparezcan o se necesiten.
Por otro lado, existirán muchos casos en los que se necesite realizar medidas con diferentes sensores que no disponen de capacidades de comunicación y no sea posible adaptar ningún módulo de comunicación. Para ello se deberá proporcionar un método de introducción de datos de forma manual pero que sea visto por el sistema como datos de entrada del mismo modo que si los datos fueran capturados de una comunicación inalámbrica.
3.- Arquitectura de comunicación de los biosensores
Como se ha indicado la arquitectura de comunicación constará de un dispositivo central, que podrá ser un teléfono móvil inteligente o bien un dispositivo especialmente diseñado para tal fin y el conjunto de sensores que se desean utilizar en la aplicación.
Con respecto al dispositivo central, los modelos de teléfonos móviles actuales incorporan grandes facilidades de comunicación inalámbrica (integrando protocolos como Bluetooth y WiFi entre otros) además de tener disponibles diferentes sensores adicionales, como pueden ser aceleróme tros y sobretodo sistemas de posicionamiento como GPS. Unidos a la creciente potencia que ofrecen es posible instalar complejas aplicaciones software que hagan uso de las características que integran. Como ventaja adicional es que además permiten efectuar los servicios de telefonía para los cuales están diseñados. Por otra parte, si se usa una implementación particular para el dispositivo central se tendrá la ventaja de un diseño mucho más optimizado, sobre todo de cara al consumo energético ya que una de las principales características a tener en cuenta en la aplicación es la autonomía de este tipo de dispositivos. Además podría ser estudiado su diseño para ser llevado o portado en zonas concretas por parte del usuario que faciliten tanto su comodidad como la utilización de los sensores integrados.
El consumo energético del dispositivo tendrá que ser tenido en cuenta, ya que un consumo excesivo que haga dependiente de frecuentes recargas al mismo hará que el sistema no sea lo completamente funcional y atractivo que se desea. El uso de sensores incorporados en el dispositivo pero sobretodo el uso de los interfaces de comunicación y de los sistemas de posicionamiento hacen un uso intensivo del dispositivo consumiendo gran parte de la energía del mismo.
La otra parte importante dentro de la arquitectura será la formada por los distintos sensores que se deseen utilizar en el sistema. Para una mayor versatilidad y comodidad es importante considerar que estos deberían tener capacidad de comunicación inalámbrica y si es posible ser portados de la forma menos intrusiva posible para el usuario. Actualmente el protocolo de comunicación más usado para la formación de redes de área personal y que está integrado tanto en dispositivos móviles como en diferentes sensores es Bluetooth, pero no deben descartarse otras opciones de cara a la integración de otros sensores. El sistema por tanto deberá conocer y manejar diferentes protocolos de comunicación haciendo transparente la comunicación entre ellos.
Otra opción a tener en cuenta es la instalación de posibles pasarelas entre protocolos inalámbricos de tal forma que puedan coexistir diferentes protocolos en el sistema pero la comunicación con el sistema principal se produzca con el mismo protocolo, sin embargo esto exigiría portar más dispositivos o bien estos sólo podrían actuar en cierto rango o zona de cobertura.
Sin embargo puede ser interesante disponer de esta solución en aquellos lugares donde los dispositivos sensores estén en un lugar fijo simplificando así la programación y complejidad del API del sistema para comunicación.
Además debe facilitarse la posibilidad de introducir datos de forma manual, ya sea porque no exista un sensor específico con capacidades de conexión para los requerimientos de la aplicación o bien no pueda ser construido o integrado el protocolo de comunicación dentro de la misma. Dentro del sistema deberá verse como un sensor más de los disponibles y la forma de notificar la recepción o el envío de datos debe ser exactamente igual, ya que así se facilita la integración y/o sustitución de los sensores.
4.- APIs de programación general de la arquitectura de los sensores.
Como se ha visto en los anteriores apartados del documento la arquitectura de comunicación para los biosensores debe poder ser compatible con diferentes protocolos o medios de captura/introducción de información. Por ello debe existir una capa que enmascare los diferentes protocolos, servicios o métodos de proporción de información que existan en el sistema.
En general, el protocolo principal usado es Bluetooh pero incluso en muchas ocasiones podremos encontrarnos sensores que sólo ofrezcan acceso a sus datos a través de librerías propias u otros métodos diferentes por lo que es aconsejable enmascarar también el acceso diferenciado de cada uno. Además, las entradas de datos manuales deberían verse también en el sistema como entradas o salidas del sistema al mismo.
Para conseguir esto se propone un API orientado a objetos en la que distinguimos las siguientes clases principales: APIComunicación: que será la clase que albergue el interfaz principal de comunicación entre las capas superiores por medio de métodos de tipo send y receive.
Sensor: que será una clase abstracta de la cual se generarán tantas instancias como sensores diferentes haya en el sistema y servirá para conocer el tipo, la configuración y el protocolo asociado al mismo. Esta clase proporcionará además un sistema de direccionamiento único para todos los sensores independientemente de su tipo dentro del sistema.
Protocolo Particular: que será una clase abstracta de la cual derivarán las implementaciones particulares de cada uno de los protocolos presentes en el sistema y que se asociará con el sensor correspondiente.
Datos: que será una clase general que servirá como transporte del buffer de que se almacene en el sistema. Definirá una trama única que sea válida para todos los protocolos de comunicación existentes en el sistema.
Toda esta API residirá en el dispositivo central ya que será este el que tenga las capacidades suficientes para manejarlo. Los sensores únicamente envían datos al dispositivo central o bien le son enviadas ciertas tramas. El dispositivo central por medio de esta API será el encargado de gestionar el correcto envío y recepción de datos de los diferentes sensores, gestionando el direccionamiento correcto de cada uno de ellos de una forma totalmente transparente al nivel de aplicación. Con ello se consigue ocultar al nivel de aplicación de los problemas de comunicación que subyacen a los diferentes protocolos.
Hay que destacar que esta API deberá ser diseñada y mejor definida de cara a su implementación, por lo que podrán aparecer nuevas clases, propiedades y métodos que no se hayan detectado en una primera fase de análisis. Para ello deberá conocerse el interfaz que ofrece el nivel superior y como este debe interactuar el sistema y también las características y facilidades que ofrece el dispositivo central que se utilizará en el proyecto.
En las siguientes secciones mostramos una descripción de cada una de las clases y cuales son sus objetivos dentro de la arquitectura.
Clase APIComunicación: Esta clase establecerá la interfaz de comunicación con las capas software del sistema ofreciendo un modo único de envío y recepción de información independientemente de los sensores y protocolos de comunicación usados. Mantendrá una lista con todos los objetos sensores creados en el sistema asignándoles una dirección única y que será la utilizada para establecer las comunicaciones. Los principales métodos e interfaces que debe ofrecer son: send(id,data) permite enviar un paquete de datos al sensor id. Solo para el caso de sensores a los cuales puedan enviarse paquetes de datos.
receive(id,data) que es activado cuando un paquete de datos es recibido, indicando el sensor que ha enviado por medio de id.
setConfig(id, data) que sirve para enviar datos de configuración al sensor id.
getConfig(id,data) que sirve para recibir la configuración del sensor id.
addSensor(id, sensor) permite insertar un nuevo sensor dentro del sistema de comunicación. El sensor deberá haber sido creado con anterioridad.
removeSensor(id) permite eliminar un sensor del sistema.
El método receive será de tipo evento y deberá enlazar con un método de la aplicación de nivel superior para poder tratar el dato recibido. Se considerará también implementar métodos de acceso explícito a la consulta y recepción de datos, esto es preguntar si en lugar de ser avisado de la recepción de un paquete por medio de receive se prefiere analizar el buffer en busca de datos nuevos y tratarlos.
Cada vez que un dato desea ser enviado hacia alguno de los sensores esta clase activará el método send del objeto Sensor específico en base al identificador asignado, buscándolo en la lista de sensores.
Por otra parte la clase tendrá un proceso o thread en ejecución constante que monitorice y compruebe en cada instante se ha recibido un dato de algún sensor y si es así recogerlo, tratarlo y comunicarlo a la capa de aplicación superior por medio del evento receive. El API podrá realizar una colección de todos los paquetes recibidos por los distintos sensores y realizar a un empaquetado de todo el volumen de los mismos, reduciendo de esta manera la sobrecarga de paquetes recibidos y el posterior manejo del mismo.
Clase Sensor
Esta clase define una clase abstracta sobre la cual se crearán tantas instancias como sensores existan en el sistema. El objetivo es ofrecer una capa de adicional que permita direccionar los sensores de forma única dentro del sistema, independientemente del protocolo de comunicación que utilicen, además de poder tratar los datos a enviar y recibir de forma particular según los requerimientos de forma también independiente. A cada sensor le será asociada una implementación del protocolo de comunicación a emplear. Los principales métodos e interfaces que ofrece son: send(data) permite enviar un paquete de datos al sensor desde la aplicación. Solo para el caso de sensores a los cuales puedan enviarse paquetes de datos.
receive(data) que es activado cuando paquete de datos es recibido.
setConfig(data) que sirve para especificar los datos de configuración al sensor. getConfig(data) que sirve para obtener los datos de la configuración del sensor . attachCommProtocol(ProtocoloParticular) permite asociar el protocolo de comunicación a emplear para el sensor.
Esta clase permitirá utilizar un mismo direccionamiento entre los sensores del sistema sin importar el protocolo de comunicación subyacente. Para ello se considera necesario que cada objeto disponga de la siguiente información:
• identificador que será el identificador o dirección único del sistema para este sensor.
• MAC/Dirección protocolo que albergará la dirección del sensor en base al protocolo de comunicación usado.
• ProtocoloParticular que almacenará el protocolo particular usado.
Con los datos anteriores podrá realizarse una traducción casi automática entre las direcciones propias del protocolo de comunicación y el identificador asignado dentro de la aplicación. Además, separando la programación del protocolo de comunicación permite no tener que modificar en demasía la aplicación en caso de que el sensor cambie de protocolo o sea sustituido por otro modelo diferente.
Se permitirá desde esta clase establecer diversos parámetros de configuración, tanto para el propio sensor como opciones relativas al interfaz. Entre estas últimas podría ser interesante dar la posibilidad de especificar el intervalo, frecuencia, número, etcétera con la cual los datos son pasados al nivel superior con vistas a reducir tanto el consumo energético como la sobrecarga de computación. Por ejemplo podría configurarse para que únicamente comunicase los datos cada cinco lecturas recibidas, crear funciones especiales sobre medias de los últimos valores o proporcionar el último valor disponible cada minuto. Esto deberá ser programado como métodos propios dentro de la clase sensor.
Clase ProtocoloP articular
De esta clase serán derivados e implementados los distintos protocolos de comunicación que se den en el sistema (inclusive un modo de introducción manual será tratado como un protocolo de comunicación) pudiendo existir diferentes implementaciones para un mismo protocolo debido a las particularidades que puedan darse. Los protocolos serán asociados a los sensores. Los principales métodos e interfaces que debe ofrecer son:
- send(data) permite enviar un paquete de datos al sensor desde la aplicación. Solo para el caso de sensores a los cuales puedan enviarse paquetes de datos. Aquí se implementará la forma de envío para el protocolo determinado.
- receive(data) que es activado cuando paquete de datos es recibido. Aquí se implementará la forma de recepción de datos para el protocolo determinado.
- setConfig(data) que sirve para especificar los datos de configuración relativos al protocolo.
- getConfig(data) que sirve para obtener los datos de la configuración del protocolo.
Finalmente se usará la clase Datos como clase abstracta general y que nos servirá para definir nuestro propio formato de trama de intercambio de datos. Esto definirá la trama a utilizar dentro del sistema y que deberá ser compatible (tamaño, formato de codificación, etcétera) entre todos los posibles protocolos a emplear. Básicamente se considera el uso de un vector de bytes donde en cada posición se establecerán los diferentes datos a enviar, reservándose algunos bytes iniciales para posibles opciones del protocolo (deberá ser estudiado en el diseño detallado de cara a su implementación).
Dentro de esta clase se implementarán diversos métodos para extraer la información, añadir datos y conversión de los tipos de los mismos, de tal manera que simplifique los datos proporcionados al nivel de aplicación superior.
5.- Descripción de uso del API
A continuación mostramos brevemente cual sería la forma de trabajar con este API y como funciona. Se han distinguido diferentes casos que expresan las situaciones más características dentro del sistema. 5.1. - Inicialización del sistema
Para ver una muestra de cómo se procedería a utilizar este API realizamos una reseña de cuáles serían los pasos a realizar.
1. En primer lugar, se debería implementar el protocolo o protocolos de comunicación que se tengan en el sistema, incluyendo las implementaciones particulares del mismo. Para ello se obtendría una clase derivada de ProtocoloParticular y se procedería a implementación. Destacar que las interfaces send y receive deben ser los puntos de entrada/salida entre esta clase y el API. El método receive actuará como un eventHandler de tal forma que será el encargado de activarse cuando un dato es recibido, indicándolo a nivel de sensor. Si existen varios sensores que comparten exactamente la misma implementación del protocolo simplemente deberán crearse tantas instancias del protocolo como sea necesario y asociarlas a cada uno de los sensores. Se deberá también inicializar cada protocolo con la configuración particular.
2. Una vez efectuado el paso anterior, se deberán crear tantos sensores en el sistema como se tengan. Cada instancia representará un sensor particular del sistema y deberá ser configurado tanto el protocolo que emplea (asociándolo de algunas de las instancias previas creadas) definiendo la dirección real que tiene como la identificación que usará dentro del sistema, que podrá ser facilitada por el propio API.
3. Tras ello se darían de alta dentro del API por medio del método addSensor pasando a estar disponibles ya para su utilización.
5.2. - Recepción de datos
Una vez se ha inicializado el sistema este ya se encuentra disponible para recibir los diferentes datos que los sensores envían. Para ver una muestra de cómo esto se produciría describimos los pasos brevemente.
1. Cuando se define se implementa el protocolo particular de comunicación se debe implantar el interfaz receive que actuará como un evento. Esto quiere decir que cuando un paquete de datos llega al sistema este evento será lanzado. Como se da total libertad a implementar el protocolo particular la activación de este método no tendrá que estar asociada a la recepción de un único paquete sino que puede hacerse cuando se ha recibido un cierto volumen de datos.
2. Con la activación de este evento también lo hará el evento receive de la clase Sensor, que será la que recoja el paquete o volumen de datos recibidos y realice un tratamiento (si es necesario) con ellos y establezca en su estado que tiene datos disponibles para ser procesado. La clase sensor asociará los datos recibidos del sensor con MAC definida con el identificador único que tienen dentro del sistema.
3. El API general tendrá un thread que monitorizará todos los sensores que tengan algún dato como recibido. Cuando uno es detectado se procesa adecuadamente por parte del API y generará el evento receive final que será el interfaz con la aplicación de nivel superior. En la información facilitada se informará no sólo del paquete de datos que se ha recibido sino también con el identificador del sensor que ha enviado los datos. Se producirán tantas llamadas como paquetes se reciban, de tal forma que la aplicación será la encargada de gestionar y tratar con los paquetes recibidos.
5.3.- Envío de datos
El sistema debe permitir el envío de tramas de información hacia los diferentes sensores que permitan la recepción de datos (por ejemplo para poder ser configurados o solicitarles el envío explícito de información). Para ver una muestra de cómo esto se produciría describimos los pasos brevemente.
1. En este caso, la aplicación desea enviar cierta información, por lo que deberá crear la trama pertinente para ser enviada y comunicará el envío al sensor con identificador único del sistema el envío de datos por medio del método send.
2. El API comprobará cual es el sensor con la identificación proporcionada y le trasladará el paquete de datos a transmitir, realizando algún tratamiento si es necesario y pasándolo hacía el protocolo particular implementado por medio del método send definido.
3. La implementación particular del protocolo realizará la transmisión de datos de acuerdo al protocolo.