Prototipo funcional de un sistema de detección de caídas...
Transcript of Prototipo funcional de un sistema de detección de caídas...
UNIVERSIDAD DE BUENOS AIRES
Facultad de Ingeniería
Carrera de Especialización en Sistemas Embebidos
Memoria del Trabajo Final:
Prototipo funcional de un sistema de detección de caídas basado
en la plataforma CIAA
Autor:
Ing. Matías Dell’Oso
Director:
Esp. Ing. Pablo Ridolfi
Jurado:
Ing. Roberto Barneda
Ing. Gerardo Sager
Dr. Ing. Pablo Gomez
Presentado para obtener el título de Especialista en Sistemas Embebidos.
Universidad de Buenos Aires,
Julio de 2016.
i
Resumen
La presente tesis describe el desarrollo del proyecto “Prototipo funcional de un sistema de
detección de caídas basado en la plataforma CIAA”, presentado para la obtención del título de
posgrado Especialista en Sistemas Embebidos. Esta tesis constituye el trabajo final de la
carrera de Especialización en Sistemas Embebidos ofrecida por la Facultad de Ingeniería de la
Universidad de Buenos Aires.
En este trabajo se describe un dispositivo capaz de detectar una caída y dar alerta a un centro
de monitoreo y a familiares de la víctima. Dicho dispositivo está orientado principalmente a
los adultos mayores que viven solos y a personas con movilidad reducida. Con él, se busca
dar solución a las consecuencias adversas que se presentan al no detectar una caída
rápidamente.
Para llevar a cabo este trabajo en tiempo y forma, fueron de suma importancia los
conocimientos adquiridos a lo largo de la carrera. En particular, se hizo uso de técnicas de
gestión de proyecto e ingeniería de software; herramientas de programación de
microcontroladores y métodos y procedimientos para el diseño de circuitos impresos.
ii
Abstract
This thesis describes the development of the project “Functional prototype of a falling
detector system based on platform CIAA”, presented to obtain the graduate degree in
Embedded Systems Specialist. The thesis constitutes the final work of the course of studies
Specialization in Embedded Systems of the School of Engineering, University of Buenos
Aires.
This work describes a device capable of detecting a fall and alerting a monitoring center and
the victim’s relatives. The device is oriented, mainly, to elder people who live alone and to
people with reduced mobility. Its aim is to solve the adverse effects of not detecting a fall
immediately.
The knowledge acquired during the course of studies was of great importance to conduct this
work on time and correctly. Particularly, there were used project management and software
engineering techniques; microcontrollers programming tools and methods; and procedures for
designing printed circuits.
iii
Agradecimientos
A mis padres, quienes me han educado y apoyado a lo largo de mi vida y han puesto un
enorme esfuerzo para que pueda seguir perfeccionándome académicamente.
A Florencia, por apoyarme en cada decisión que he tomado en los últimos años a pesar de que
esto implicara pasar menos tiempo junto a ella. Sin su paciencia y cariño este trabajo no
hubiera sido posible.
A mi director, Esp. Ing. Pablo Ridolfi, por todo el apoyo que me brindó a lo largo de este
proyecto y por su infinita paciencia y predisposición.
Al Dr. Ing. Ariel Lutenberg, por involucrarse en cada proyecto como si fuera propio.
Al Laboratorio de Investigación III-LIDI, por brindarme un lugar físico para que pueda
desarrollar este proyecto y en especial a la Lic. Laura Lanzarini por brindarme su apoyo para
que continúe mi carrera en el ámbito académico.
A mis amigos, por todos los momentos compartidos que hicieron todo este proceso un poco
menos productivo, pero mucho más interesante.
A mis compañeros y amigos de trabajo, con quienes comparto mis inquietudes diarias y hacen
que cada día sea un poco más llevadero.
A mis compañeros de la segunda cohorte de la Carrera de Especialización en Sistemas
Embebidos, con quienes nos reunimos semanalmente para intercambiar ideas y
recomendaciones.
iv
Índice
Introducción general ................................................................................................................ 1
1.1 Motivación .................................................................................................................................... 1
1.2 Soluciones comerciales ................................................................................................................. 3
1.3 Objetivos ....................................................................................................................................... 4
1.4 Alcances y limitaciones ................................................................................................................. 4
Introducción específica ............................................................................................................ 5
2.1 Funcionamiento general del sistema ............................................................................................. 5
2.2 Requerimientos ............................................................................................................................. 7
2.3 Planificación .................................................................................................................................. 8
Diseño e Implementación ......................................................................................................... 9
3.1 Selección de componentes ............................................................................................................ 9
3.2 Diseño de hardware ..................................................................................................................... 14
3.3 Software ...................................................................................................................................... 16
3.3.1 Ingeniería de Software ......................................................................................................... 16
3.3.2 Diseño del software embebido ............................................................................................. 17
3.3.3 Modelo de datos ................................................................................................................... 25
3.3.4 Diseño de la interfaz de usuario ........................................................................................... 26
Ensayos y Resultados ............................................................................................................. 30
4.1 Prototipo de detector de caídas .................................................................................................... 30
4.2 Pruebas unitarias sobre los módulos de comunicación y acelerómetro ...................................... 30
4.3 Pruebas del sistema en conjunto .................................................................................................. 32
Conclusiones y trabajo futuro ............................................................................................... 37
Conclusiones ..................................................................................................................................... 37
Trabajo futuro .................................................................................................................................... 38
Bibliografía .............................................................................................................................. 39
Anexos ...................................................................................................................................... 41
A. Diagrama de Gantt........................................................................................................................ 41
B. Secciones de la aplicación web .................................................................................................... 42
C. Esquemáticos del proyecto ........................................................................................................... 45
1
Capítulo 1
Introducción general
1.1 Motivación
Las caídas son la principal causa de lesiones en personas mayores de 65 años [1]. El 30% de
esta población sufre una caída cada año [2-5], y dicho número aumenta de manera constante
debido a que la población de adultos mayores crece anualmente [6].
Un informe de la OMS (Organización Mundial de la Salud) en 2012, señala que anualmente
se producen 37,3 millones de caídas que requieren atención médica, de ellas 424 mil derivan
en muerte, lo que convierte a las caídas en la segunda causa mundial de muerte por lesiones
no intencionales, luego de los traumatismos causados por accidentes de tránsito [7].
Algunos estudios [8-11] demuestran que esta situación se presenta de forma similar en
diversas partes del mundo.
Figura 1.1: Distribución de los encuestados por caídas y número de caídas. N hace referencia al número de
encuestados.
En España, por ejemplo, un estudio realizado por la Fundación MAPFRE mostró que el
14,7% de los adultos mayores de 65 años que viven solos, sufren por lo menos una caída
anualmente [9]. El 63,4%, refieren haberse caído una única vez, un 11,3% dos veces, 6,7%
tres veces, 0,8% cuatro veces y un 7,6% más de cuatro veces (ver Figura 1.1).
2
Tabla 1.1: Distribución de los encuestados por lugar de caída
¿Dónde sufrió la caída? Encuestados %
Fuera del domicilio 107 45,0%
En el domicilio 95 39,9%
NS/NC 36 15,1%
Total 238 100.0%
En cuanto a los lugares donde se producen las caídas, el 45% se cayeron fuera de su domicilio
mientras que el 39,9% lo hizo en su propio domicilio (ver Tabla 1.1). En Estados Unidos, se
estima que 1 de cada 3 adultos mayores sufre algún tipo de caída cada año. Esto se traduce a
una caída cada 13 segundos y en una muerte cada 20 minutos [10] [11]. La Figura 1.2 muestra
datos preocupantes sobre la tasa de mortalidad debido a caídas en este país con un claro
incremento a través de los años.
Figura 1.2: Tasa de mortalidad por caídas no intencionales en adultos mayores a 65 años
En Argentina, un artículo publicado por el CoKiBA (Colegio de Kinesiólogos de la Provincia
de Buenos Aires) en 2014 [8], advierte que 1 de cada 5 adultos mayores de 65 años sufre al
menos una caída al año, y más del 80% de los episodios ocurren en el ámbito doméstico.
Además, da cuenta de que, en hospitales públicos de la Provincia de Buenos Aires, 2 de cada
5 adultos de más de 80 años han sufrido al menos una caída al año.
3
Existen indicadores para determinar alteración en el equilibrio,
una de las principales causas de las caídas. Además, es
importante tomar medidas de prevención en los domicilios,
porque es el ámbito donde ocurren la mayor cantidad de
accidentes.
La Spina, Licenciado kinesiólogo fisiatra,
Egresado de la UBA e integrante del CoKiBA.
En función de estas estadísticas, resulta imprescindible el desarrollo de sistemas que ayuden a
la rápida detección de una caída, enviando una alarma al personal médico o a familiares,
minimizando así las posibles consecuencias adversas.
1.2 Soluciones comerciales
A continuación, se presentarán dos empresas cuyos productos intentan dar solución a la
problemática planteada: Medical Guardian (Estados Unidos) y Atempo (Argentina). La
primera, ganadora del premio al mejor detector de caídas en el año 2016 [12], ofrece cuatro
productos (ver Tabla 1.2) cada uno de ellos adaptado a las diferentes situaciones en que se
puede producir una caída, convirtiéndola en un buen referente en el ámbito de la detección de
caídas.
Tabla 1.2: Productos comerciales ofrecidos por Medical Guardian - Estados Unidos
Nombre del
producto
Costo
(U$D)
Modo de
comunicación
Batería
(horas)
GPS Detección
automática
Resistente
al agua
Classic
Guardian
30/mes +
Instalación
Línea
telefónica
32
(backup)
No No Si
Home
Guardian
35/mes +
Instalación
Tecnología
celular
30
(backup)
No Si Si
Mobile
Guardian
40/mes +
Instalación
Tecnología
celular
24 Si No Si
Premium
Guardian
50/mes +
Instalación
Tecnología
celular
36 Si Si Si
En Argentina, la cantidad de empresas que ofrecen un servicio de detección de caídas es
escaza. Atempo está posicionada como empresa líder en nuestro país, con un producto que se
asemeja al Classic Guardian. A grandes rasgos, es un dispositivo que se coloca en la muñeca
o con un collar en el cuello y que contiene un botón de pánico. Al pulsar el botón, se envía
una señal de alerta a una central de monitoreo y se establece una comunicación telefónica (por
medio de altavoz) para asistir a la persona. Si bien este tipo de dispositivo es útil y da una
cierta seguridad a los adultos mayores que viven solos, no es completamente seguro. Si la
persona queda inconsciente al caerse o sufre una fractura que le impide moverse, le será
imposible presionar el botón de pánico. Por esta razón, es de suma importancia que exista un
producto con la capacidad de detectar y alertar automáticamente una caída.
4
Si bien en otros países existen dispositivos comerciales eficaces para la detección de caídas,
en Argentina aún no existe un desarrollo significativo. Es necesario mejorar el desempeño de
los dispositivos existentes, de tal manera que se le pueda garantizar al usuario un servicio
confiable, que detecte las caídas con una alta tasa de acierto y no genere falsas alarmas, las
cuales restan confiabilidad al sistema.
1.3 Objetivos
Teniendo en cuenta la expuesto anteriormente, el objetivo general de este proyecto es
implementar un prototipo funcional de un sistema de detección de caída. Este proyecto
también tiene como propósito ser un punto de partida para luego crear un nuevo sistema
reutilizando el hardware y modificando el algoritmo a uno basado en sistemas inteligentes
(redes neuronales, lógica difusa, entre otros.), con el fin de aumentar en gran medida la tasa
de aciertos del dispositivo.
A fin de orientar el trabajo, se definieron los siguientes objetivos específicos:
Cumplir en tiempo y forma con la finalización del proyecto. Esto es, terminar y
facilitarle los entregables al jurado antes del 18 de julio para luego realizar la defensa
del trabajo el día 1 de agosto.
Identificar una buena combinación de dispositivos (acelerómetro, microcontrolador,
módulos de comunicación) para crear una solución económica (tratar de mantener el
precio cercano a los U$D100) y al mismo tiempo que arroje datos confiables.
1.4 Alcances y limitaciones
Con el objetivo de determinar en forma precisa el trabajo a realizar, a continuación, se detalla
el alcance del proyecto:
El proyecto incluye la realización de un prototipo de hardware completamente
funcional, con el cual se podrán detectar caídas.
Se crearán los manejadores para manejar los distintos módulos utilizados.
Se implementará un algoritmo basado en umbrales para verificar el correcto
funcionamiento del dispositivo.
Se creará un software a modo de interfaz de usuario, en el cual se recibirán las
notificaciones provenientes del dispositivo.
El proyecto no incluye la creación de una base de conocimientos.
El proyecto no incluye la realización de un algoritmo inteligente.
5
Capítulo 2
Introducción específica
2.1 Funcionamiento general del sistema
El paciente tendrá consigo un dispositivo capaz de detectar caídas. Dicho dispositivo contará
con un botón de pánico, el cual el usuario puede presionar en caso de necesitar asistencia;
indicadores de estado que le informarán al paciente si la alerta ha sido enviada o no; dos
módulos de comunicación, WiFi y GSM, con el fin de generar redundancia para asegurar el
envío de la alerta ante posibles fallos (falta de señal, desconexión de Internet, entre otros); una
memoria EEPROM para guardar información de contacto (números telefónicos de familiares,
servidor de la central, etc.); una batería y un acelerómetro con el cual se detectará la
ocurrencia de una caída (ver Figura 2.1).
Figura 2.1: Esquema del dispositivo de detección de caídas
El envío de una señal de alarma puede ocurrir por dos motivos: el usuario presiona el botón de
pánico, o el sistema detecta una caída automáticamente. Esto añade un valor agregado a los
productos comerciales actuales de nuestro país, debido a que, si el paciente sufre un desmayo
o queda inhabilitado para presionar el botón, la caída será informada automáticamente.
6
En cuanto al modo de funcionamiento, el dispositivo medirá periódicamente la aceleración del
paciente. Si se detecta una caída (o si el usuario presiona el botón de pánico), se iniciará la
secuencia de envío de datos:
1. Se despertarán los dos módulos de comunicación. Inicialmente estos módulos se
encontrarán apagados con el fin de prolongar la duración de la batería.
2. Comenzarán las secuencias de inicialización de ambos. En caso de que uno de los
módulos no sea inicializado de manera correcta, se aplicará una estrategia de
tolerancia a fallas.
3. Una vez inicializados los módulos, se enviarán las alertas correspondientes. Esto es,
una alerta WiFi al servidor vía protocolo HTTP, y un mensaje de texto a todos los
familiares del paciente que estén registrados como contactos de ayuda. Nuevamente,
en caso de que ocurra un error en el envío de una de las alertas, se aplicará una
estrategia de tolerancia a fallas.
4. Ya en la central, la persona a cargo del monitoreo, verá en la pantalla que un paciente
ha sufrido una caída y llamará a una ambulancia para que lo asista.
En la Figura 2.2 se muestra este proceso.
Figura 2.2: Esquema general del sistema
7
En lo que respecta al software de monitoreo, se trata de una interfaz web, diseñada para
acceder desde un ordenador o desde un teléfono móvil. Tanto la persona encargada de
monitorear a los pacientes como los familiares de los mismos, tienen acceso a dicha página.
Sin embargo, existen distintos niveles de acceso a los datos dependiendo del tipo de usuario.
Los usuarios normales tienen acceso a funciones reducidas y la única función que pueden
realizar es la de monitorear a su familiar. Por otro lado, el administrador tiene acceso a
funciones privilegiadas, pudiendo así, monitorear a todos los pacientes que estén utilizando el
dispositivo detector de caídas (ver Figura 2.3). Además, podrá acceder a la función
administración, la cual le permite agregar, editar o eliminar pacientes, información de
contacto de cada uno, y visualizar sus historias clínicas. Esto último resulta útil para informar
a la ambulancia sobre posibles alergias a medicamentos que pueda tener el paciente, por
ejemplo. Para más detalles sobre las diferentes secciones de la aplicación web, referirse al
Anexo B.
Figura 2.3: Pantalla monitoreo – Vista del administrador
2.2 Requerimientos
A continuación, se detallan los requerimientos del proyecto:
1. Características del sistema
1. El sistema debe contar con una batería de alimentación que dure al menos 12
horas.
2. El sistema deberá contar con al menos un sensor que permita medir aceleración.
3. El sistema deberá contar con un módulo WiFi y un módulo GSM.
4. El microcontrolador utilizado debe pertenecer a una gama de bajo consumo.
2. Software necesario
1. El sistema debe contar con una aplicación web para visualizar los datos
recolectados por el dispositivo.
3. Control de versiones y documentación
1. Se utilizará GIT como herramienta de control de versiones.
2. Se utilizará Doxygen como herramienta para generar la documentación.
8
2.3 Planificación
Una vez establecidos los objetivos, alcances y requerimientos del sistema, se realizó una
planificación de las tareas a realizar con el fin de optimizar lo mejor posible el tiempo
disponible para la realización del trabajo.
En el Anexo A puede apreciarse el diagrama de Gantt de la planificación que se detalla a
continuación:
1. Búsqueda del material bibliográfico
1. Buscar hoja de datos de todos los componentes
2. Estudiar cómo funciona cada uno de los componentes
2. Elección del hardware a utilizar
1. Elegir el microcontrolador a utilizar
2. Elegir en función de lo estudiado qué dispositivos van a utilizarse en el proyecto
3. Elegir la batería a utilizar
3. Implementación de los manejadores de los dispositivos elegidos
1. Implementar el manejador del acelerómetro
2. Implementar los manejadores de los módulos de comunicación
4. Implementación del sistema
1. Desarrollar el código utilizando los manejadores ya creados
2. Desarrollar el programa de interfaz con el usuario
5. Diseño de un circuito impreso para integrar todos los componentes
6. Testing
1. Testear el correcto funcionamiento del dispositivo
2. Testear el correcto funcionamiento de la aplicación
3. Testear el sistema en conjunto
7. Presentación del trabajo
1. Presentar el informe de avance
2. Presentar la memoria escrita
3. Presentar el trabajo ante el jurado
9
1Microcontrolador multinucleo asimétrico: los núcleos que componen al microcontrolador no son iguales,
pueden presentar arquitecturas, funcionalidades e interfaces diferentes. Además, cada uno de ellos corre su
propia imagen de kernel, la cual puede diferir entre ambos.
Capítulo 3
Diseño e Implementación
3.1 Selección de componentes
Para poder detectar una caída es necesario que la persona cargue consigo un dispositivo que le
permita enviar una señal de auxilio cuando sea necesario. A la hora de elegir cuál sería este
dispositivo, se contemplaron dos opciones: utilizar un teléfono inteligente moderno, el cual
cumpla con todas las características necesarias para detectar y alertar una caída (Procesador,
conexión GSM y WiFi, y acelerómetro), o diseñar un sistema embebido. Finalmente, se
decidió diseñar un sistema embebido por las siguientes razones:
Los adultos mayores se resisten al uso de teléfonos celulares, por lo que no se podría
garantizar que lo fueran a tener con ellos en todo momento.
Los teléfonos celulares no poseen un sistema operativo de tiempo real, por lo que una
tarea ajena a la detección de caídas podría retrasar la activación de una tarea crítica.
Además, al contar con aplicaciones en segundo plano, el tiempo de vida de la batería
se vería afectado significativamente.
Con mente en el futuro, si se deseara comercializar el producto final como un
dispositivo médico, es necesario cumplir con un cierto número de certificaciones las
cuales un teléfono celular no podría cumplir.
No obstante, no se descarta la posibilidad de desarrollar en un futuro una aplicación para
dispositivos móviles, utilizando como base el algoritmo implementado en el sistema
embebido, con el fin de realizar comparaciones de rendimiento o para ofrecerla como una
aplicación complementaria.
A continuación, se listarán los principales componentes electrónicos utilizados en el
desarrollo del dispositivo detector de caídas. Cabe aclarar que, para el diseño de este
prototipo, se utilizó una placa de desarrollo (más información en la sección 3.2). Además,
tanto el acelerómetro como los módulos de comunicación utilizados son módulos
independientes que contienen la electrónica básica necesaria para funcionar. Queda como
trabajo futuro a la hora de desarrollar el producto final, integrar dichos módulos y el
microcontrolador en un único circuito impreso.
Microcontrolador
A la hora de seleccionar el microcontrolador a utilizar, se buscó uno que perteneciera a la
gama de bajo consumo, pero que al mismo tiempo tenga un poder de cómputo adecuado para
en un futuro procesar algoritmos complejos. Bajo dichas condiciones, se preseleccionaron los
microcontroladores multinucleos asimétricos1 LPC4337 y LPC54102, cuyas características
principales pueden observarse en la Tabla 3.1.
10
2Asociación Civil para la investigación, promoción y desarrollo de los Sistemas electrónicos Embebidos. Sitio web: http://www.sase.com.ar/asociacion-civil-sistemas-embebidos 3Cámara Argentina de Industrias Electrónicas, Electromecánicas y Luminotécnicas. Sitio web: http://www.cadieel.org.ar/
Tabla 3.1: Características principales del microcontrolador LPC4337 y LPC54102
Características LPC4337 LPC54102
Procesador de alto rendimiento ARM Cortex-M4F ARM Cortex-M4F
Procesador de bajo rendimiento ARM Cortex-M0 ARM Cortex-M0+
Frecuencia de reloj 204 MHz (compartido) 100 MHz (compartido)
Soporte para instrucciones SIMD Si Si
Unidad de punto flotante por hardware Si Si
SRAM 136 kB 104 kB
Flash 1 MB 512 kB
La principal ventaja de utilizar uno de estos dos microcontroladores es que, en principio, se
puede ahorrar mucha energía utilizando el núcleo de baja potencia para las operaciones que
no requieran una gran capacidad de cómputo, y activando el núcleo de alta potencia cuando el
programa demande cálculos más complejos. Esta característica convierte a estos dos
microcontroladores en buenos candidatos para utilizar en este proyecto.
Debido a que el LPC54102 es un microcontrolador relativamente nuevo y aún no hay
demasiada documentación al respecto, se optó por utilizar el LPC4337 (ver Figura 3.1). Sin
embargo, esta elección no impide un posible cambio de microcontrolador en el futuro si así se
requiere, debido a que se utilizó LPCOpen como capa intermedia para desarrollar los
manejadores de todos los módulos (para más información referirse a la sección 3.3.2).
Otra de las razones por la que se decidió a utilizar el LPC4337, es ubicar el trabajo en el
marco del proyecto CIAA (Computadora Industrial Abierta Argentina). Dicho proyecto nació
en 2013 como una iniciativa conjunta entre el sector académico y el industrial, representados
por la ACSE2 y CADIEEL
3 respectivamente. Los principales objetivos de dicho proyecto son:
Impulsar el desarrollo tecnológico nacional, a partir de sumar valor agregado al
trabajo y a los productos y servicios, mediante el uso de sistemas electrónicos, en
el marco de la vinculación de las instituciones educativas y el sistema científico-
tecnológico con la industria.
Darle visibilidad positiva a la electrónica argentina.
Generar cambios estructurales en la forma en la que se desarrollan y utilizan en
nuestro país los conocimientos en el ámbito de la electrónica y de las
instituciones y empresas que hacen uso de ella.
Para más información sobre el proyecto CIAA referirse a la página web oficial [13].
11
Figura 3.1: Diagrama en bloques LPC4337
Módulo GSM
En lo que respecta a la comunicación GSM, se preseleccionaron los módulos SIM900 y
SIM800, en particular la versión SIM800L (ver Figura 3.2). El primero es uno de los módulos
GSM más utilizados del mercado y, el segundo, su versión mejorada, la cual incluye soporte
para conexión bluetooth, radio FM, entre otros.
Si bien ambos presentan características muy similares en lo que respecta a los objetivos de
este proyecto, se decidió utilizar el SIM800L debido a que su costo es aproximadamente la
mitad del costo del SIM900. Además, al contar con pila bluetooth, queda abierta la
posibilidad de utilizar, en un futuro, conexión bluetooth como método de comunicación
adicional.
Las principales características del módulo SIM800L son:
Voltaje de alimentación: 3,4 V – 4,4 V
Modo bajo consumo: 0,7 mA en modo reposo
Bandas de frecuencias: 4 bandas (850/900/1800/1900)
GPRS – transferencia de datos (bajada y subida): hasta 85,6 Kbps
Stack TCP/IP integrado
Modo de comunicación: UART
Velocidad del puerto serie: 1200 bps hasta 115200 bps
Soporta “Autobauding” entre 1200 bps y 57600 bps
12
Figura 3.2: Módulo GSM – SIM800L
Acelerómetro
Como se mencionó en el apartado 2.1, se utilizó un acelerómetro para detectar la ocurrencia
de una caída. En particular, se seleccionó el módulo ADXL345 (ver Figura 3.3) debido a su
bajo consumo, bajo costo y amplio rango de sensibilidad. A continuación, se detallan sus
características principales:
Voltaje de alimentación: 2 V – 3,6 V
Bajo consumo: 40 uA mientras adquiere muestras y 0,1 uA en modo reposo
Rango de sensibilidad: ±2g/±4g/±8g/±16g
Resolución seleccionable: hasta 13 bits de resolución
Frecuencia de muestreo: 6,25 Hz – 3200 Hz
Modo de comunicación: I2C y SPI
Detección de caída libre
Resistente a golpes
Figura 3.3: Módulo acelerómetro – ADL345
13
Módulo WiFi
Si bien se podría haber aprovechado la función GPRS del SIM800L para la comunicación con
el servidor, se optó por utilizar WiFi con el fin de generar redundancia para asegurar el envío
de la alerta ante posibles fallos. En particular, el módulo elegido fue el ESP8266 en su versión
ESP-01 (ver Figura 3.4). Módulo muy difundido en el mercado del cual se puede encontrar
mucha documentación.
Figura 3.4: Módulo WiFi – ESP8266-01
A continuación, se detallan sus características principales:
Voltaje de alimentación: 3 V – 3,6 V
Modo bajo consumo: 0,9 mA en modo reposo y 10 uA en modo "deep sleep"
Protocolos soportados: 802.11 b/g/n
Stack TCP/IP integrado
Wi-Fi 2.4 GHz, soporta WPA/WPA2
Modo de comunicación: UART
Memoria no volátil
Para almacenar información del servidor y de los contactos del paciente se utilizó la memoria
EEPROM 24LC64, la cual tiene las siguientes características:
Voltaje de alimentación: 2,2 V – 5,5 V
Tecnología CMOS de bajo consumo: 3,3 mA estando activa y 1 uA en modo reposo
Tamaño de memoria: 64 Kbit (8 x 8 Kbit)
Modo de comunicación: I2C
Batería
Para alimentar el microcontrolador y los módulos de comunicación mientras se realizaron las
pruebas, se utilizaron dos pilas del tipo 18650 en serie, cada una de ellas de 3,2 V y 3200
mAh.
14
Costo del detector de caídas
En la Tabla 3.2 se puede observar el costo de cada uno de los componentes utilizados y el
precio final del dispositivo. En dicho precio no está incluido el costo de la placa de desarrollo,
sino que sólo se incluyó el precio del microcontrolador LPC4337.
Tabla 3.2: Costo en dólares del dispositivo detector de caídas
Dispositivo Precio en U$D por unidad
Módulo acelerómetro 1,4
Módulo WiFi 2,78
Módulo GSM 7,79
Memoria EEPROM 0,54
Microcontrolador LPC4337 22,64
Fuente de switching - 5 V 8,17
Regulador linear - 3,3 V 0,46
Indicadores de estado 0,76
Pulsadores 0,1
Batería 40,9
PCB 34,79
TOTAL 120,33
Como se observa en la tabla anterior, la mayor parte del costo está repartida entre el
microcontrolador, la batería y el circuito impreso. Si bien el precio alcanzado satisface el
objetivo de mantener el costo cercano a los U$D 100, como trabajo futuro se hará hincapié en
reducir el consumo del dispositivo, disminuyendo así, el costo de la batería. También se
espera reducir el costo del circuito impreso integrando los módulos y el microcontrolador en
una única placa, con el fin de reducir sus dimensiones. Además, pensando ya en introducir el
dispositivo en el mercado, el costo por unidad del circuito impreso se reducirá notablemente
al aumentar el número de unidades fabricadas.
3.2 Diseño de hardware
En la sección anterior se mencionó que se utilizó una placa de desarrollo que utilizara el
microcontrolador LPC4337. La placa en cuestión es la versión educativa de la CIAA-NXP, la
EDU-CIAA-NXP (ver Figura 3.5). Esta versión educativa, con el objetivo de abaratar costos
y reducir la complejidad de la CIAA, incorpora sólo algunas de sus funcionalidades. A su vez,
15
con el fin de permitir el desarrollo de algunas prácticas sencillas sin que sea necesario recurrir
a hardware adicional, incluye algunos recursos que no están presentes en la CIAA.
Para conectar los módulos anteriormente mencionados, los pulsadores e indicadores de
estados y la memoria EEPROM, se diseñó una placa de expansión para la EDU-CIAA-NXP
(denominada “poncho” en el marco del Proyecto CIAA [14]) cuyo diagrama esquemático
puede encontrase en el Anexo C.
El diseño incluye: tres LEDs indicadores de estado, la memoria EEPROM, tres conectores
para insertar los dos módulos de comunicación y el acelerómetro, una fuente de switching
para alimentar la EDU-CIAA con voltajes superiores a 5 V, y un regulador lineal de 3,3V.
Figura 3.5: EDU-CIAA-NXP
Software de diseño
El software utilizado para el diseño del circuito fue KiCAD [15]. El principal motivo por el
cual se eligió utilizarlo es por ser un software libre y relativamente sencillo de utilizar. Otra de
las razones, es que todas las placas del proyecto CIAA fueron diseñadas en este programa, lo
cual permitió reutilizar diseños creados por la comunidad. En particular, se utilizó un modelo
de poncho obtenido del repositorio oficial del proyecto CIAA, que proveía las dimensiones
del circuito impreso y una hoja jerárquica con los conectores de la EDU-CIAA.
Configuración de pines
Para conectar los módulos mencionados en la sección 3.1 a la EDU-CIAA-NXP, se realizaron
los mapeos de pines observados en la Figura 3.6.
16
Figura 3.6: Mapeo de pines de la plataforma EDU-CIAA-NXP
Núcleo utilizado
Como se mencionó en apartados anteriores, la razón por la que se optó por un procesador
asimétrico era utilizar el Cortex-M0 para el procesamiento regular y sólo activar el Cortex-
M4F cuando fuera necesario. Sin embargo, el trabajo realizado por el Esp. Ing. Pablo Ridolfi
[16] y pruebas de laboratorio, demostraron que la diferencia de consumo entre ambos núcleos
es despreciable, lo que llevó a utilizar el Cortex-M4F en todo momento, reduciendo su
frecuencia de reloj a 22 MHz (frecuencia mínima en la cual el sistema funciona de manera
estable).
3.3 Software
En los siguientes apartados se abordarán los aspectos relacionados con el software
desarrollado. En primer lugar, se listarán las herramientas de software complementarias
utilizadas para facilitar el desarrollo de las aplicaciones. Luego, se detallará el modelo de la
base de datos utilizada para almacenar la información de pacientes, familiares, entre otros. A
continuación, se abarcará todo lo que respecta al software embebido (codificación principal,
bibliotecas desarrolladas, etc.). Por último, se listarán las tecnologías utilizadas para el
desarrollo de la aplicación web, remarcando sus ventajas y por qué fueron elegidas.
3.3.1 Ingeniería de Software
A continuación, se detallarán las técnicas aplicadas para facilitar y agilizar el desarrollo de la
aplicación embebida y de la aplicación web, mencionando la herramienta de software
utilizada en cada caso:
17
Control de versiones: para llevar un historial del código desarrollado y poder recuperar
versiones anteriores de la aplicación, se utilizó Git, uno de los sistemas de control de
versiones distribuido más utilizados por los desarrolladores de software.
Documentación: para generar documentación en el código fuente de las aplicaciones
se utilizó Doxygen, un sistema de documentación para C/C++, Java, Python, VHDL,
PHP, entre otros.
Gestión de tareas: con el fin de optimizar el tiempo de desarrollo lo mayor posible, se
utilizó la herramienta Trello. Este programa permite cargar historias de usuario y
gestionar fácilmente las tareas que se deben desarrollar, la tarea que se está
desarrollando actualmente y las tareas que ya han finalizado.
3.3.2 Diseño del software embebido
Sistema operativo de tiempo real
A la hora de desarrollar el software embebido, una de las principales decisiones a tomar fue la
de usar, o no, un sistema operativo de tiempo real (RTOS, del inglés Real Time Operating
System) y, en caso de utilizar uno, cuál elegir. Finalmente se optó por utilizar un RTOS por
los siguientes motivos:
Aprovechar sus mecanismos de sincronización entre tareas, dado que, luego de un
análisis previo, se determinó que el código principal iba a tener muchas secciones que
permanecerían bloqueadas hasta que ocurra un evento determinado.
Facilitar la codificación de tolerancia a fallas. Por ejemplo, si el envío de un mensaje
falla, la tarea encargada de alertar la caída seguirá intentado enviar el mensaje de
alerta, mientras la tarea de adquisición de datos continuará su ejecución normalmente.
Pensando en una posible ampliación del sistema, si se quieren agregar más
funcionalidades, bastará con crear una nueva tarea específica para esa funcionalidad y
darle la prioridad adecuada para que coopere con las tareas existentes.
En cuanto a qué RTOS utilizar, las opciones contempladas fueron FreeOSEK y FreeRTOSTM
.
El primero es un RTOS estático de código abierto utilizado en el Firmware de la CIAA y está
basado en el estándar OSEK-OS. El segundo, también de código abierto, es uno de los RTOS
más utilizado en el mundo. Se trata de un RTOS dinámico programado la mayor parte en C y
es relativamente sencillo de portar a distintas plataformas.
La principal diferencia entre FreeOSEK y FreeRTOS es la manera en la que alocan memoria
para los recursos y tareas. El primero, al ser un RTOS estático, asignará un espacio de
memoria específico para cada tarea y para cada recurso y, si la memoria es insuficiente, se
producirá un error en compilación. Esto es una gran ventaja en los sistemas en los cuales un
fallo en la creación de una tarea o un recurso puede significar graves daños en el mundo real.
El segundo, en cambio, asigna memoria para las tareas y los recursos en tiempo de ejecución,
lo cual lleva a que, si no hay memoria disponible, el sistema falle.
Debido a que el dispositivo de detección de caídas se trata de un sistema crítico, un RTOS
estático sería más adecuado que uno dinámico. Sin embargo, se decidió utilizar FreeRTOS
18
(versión 8.2.3) debido a que, al tratarse de un RTOS muy difundido, está portado a múltiples
plataformas, lo que facilitaría, en un futuro, el cambio del microcontrolador utilizado.
Además, cuenta con una amplia comunidad, por lo que hay mucha documentación al respecto.
Para evitar que se produzcan fallos en el sistema debido a que una tarea o un recurso no
pueden crearse por falta de memoria, todas las tareas y semáforos son creados antes de que
comience a funcionar el sistema operativo. En el instante inicial, el planificador pondrá todas
las tareas a correr, y las que no necesiten una ejecución inmediata quedarán bloqueadas en un
semáforo a la espera de un evento.
Por último, cabe mencionar que, en el transcurso del desarrollo de este proyecto, fue lanzada
la versión 9 de FreeRTOS la cual da soporte a tareas y recursos estáticos, quedando como
trabajo futuro la utilización de estas nuevas funciones.
Código principal
Como se mencionó anteriormente, el código principal del detector de caídas está basado en el
sistema de tiempo real FreeRTOS (en el Listado 3.1 se puede observar su pseudocódigo). A
continuación, se detallará el funcionamiento de cada función y de cada tarea.
initHardware: esta función se encarga de inicializar todos los periféricos de la EDU-
CIAA-NXP y los módulos utilizados. En particular se inicializan:
GPIOs de entrada y salida
UART0 (asociada al módulo GSM) en modo FIFO y 57600 bps
UART2 (utilizada para debugging) en modo FIFO y 115200 bps
UART3 (asociada al módulo WiFi) en modo FIFO y 115200 bps
I2C0 a una velocidad de 100 KHz y en modo polling (sin interrupciones).
ADXL345 configurado en modo Auto Sleep (el módulo entra en modo bajo
consumo automáticamente cuando no esté adquiriendo muestras), frecuencia
de muestreo 200 Hz, rango de ±8g y 12 bits de resolución. Tanto la frecuencia
de muestreo como el rango fueron determinados empíricamente basándose en
los estudios realizados en [17] [18].
main: esta función es la encargada de crear las tareas que componen el sistema,
asignarles el nivel de prioridad y el tamaño de pila que tendrán disponible (ver Tabla
3.3). A su vez, instancia los semáforos y libera los que sean necesarios (por defecto los
semáforos están tomados).
keepAlive: esta tarea envía una señal al servidor con el fin de informar que el
dispositivo está encendido y funcionando correctamente. Los pasos a seguir son los
mismos que realiza la tarea fallAlert (ver a continuación) para enviar la alerta WiFi.
Este envío se realiza periódicamente cada media hora y, en caso de que falle, cada
cinco minutos hasta que el envío se complete con éxito.
19
Listado 3.1. Pseudocódigo del código principal ------------------------------------
tarea measure()
{
medir aceleración
procesar datos
si hay caída:
liberar semáforo de alerta
}
tarea wifiInit()
{
esperar semáforo
mientras no expire el time out:
configurar módulos
si no expiro el time out
liberar semáforo wifiInit
}
tarea gsmInit()
{
esperar semáforo
mientras no expire el time out:
configurar módulos
si no expiro el time out
liberar semáforo gsmInit
}
------------------------------------
tarea wifiAlert()
{
esperar semáforo
mientras no expire el time out:
configurar módulos
enviar alerta
si no expiro el time out
liberar semáforo de wifiAlert
} tarea gsmAlert()
{
esperar semáforo
mientras no expire el time out:
configurar módulos
enviar alerta
si no expiro el time out
liberar semáforo gsmAlert
}
tarea fallAlert()
{
esperar semáforo de alerta
mientras ambas alertas se hayan enviado correctamente:
esperar semáforo de sincronización con keep
liberar semáforo de inicialización de módulos
si ambos módulos se inicializaron correctamente
liberar semáforo de enviar alerta
si ambas alertas se enviaron correctamente
limpiar flag de reenvío
sino liberar semáforo de enviar alerta del módulo inicializado
}
tarea keepAlive()
{
esperar semáforo de sincronización con fallAlert
liberar semáforo de inicialización de módulo wifi
si se inicializó correctamente
liberar semáforo de enviar alerta wifi
si la alerta se envió correctamente
dormir por media hora
sino
dormir por 5 minutos
}
función initHardware()
{
iniciar módulos de la CIAA // IO, UART, I2C
iniciar módulos del usuario // GSM, WIFI, ACCEL, EEPROM
}
función main()
{
instanciar semáforos
inicializar hardware
crear tareas
iniciar el sistema operativo
}
--------------------------------------------------------------------------
20
fallAlert: esta tarea es activada por la tarea measure en el momento que se detecta una
caída o si el usuario presiona el botón de emergencia. Una vez activada, libera los
semáforos de inicialización de los módulos de comunicación y aguarda su correcta
inicialización. Si la inicialización de los módulos se realiza de manera correcta, libera
los semáforos de alerta y aguarda a que la alerta se envíe correctamente. Si la
inicialización de alguno de los módulos o el envío de una alerta falla, se repite el ciclo
nuevamente hasta que ambos módulos envían sus respectivas alertas.
wifiInit: esta tarea es activada por la tarea fallAlert o por la tarea keepAlive para
inicializar el módulo WiFi. Para ello, mediante comandos AT, se envían al módulo las
siguientes configuraciones:
Deshabilitar el eco. Esta opción deshabilita el eco del comando.
Configurar el módulo como estación (los modos posibles son: estación, punto
de acceso y la combinación de ambos)
Chequear si el módulo está conectado a la red (ya conocida). Si no lo está, se
envía el comando de conexión utilizando el nombre de la red (SSID, del inglés
Service Set Identifier) y la contraseña almacenados en la memoria EEPROM.
gsmInit: esta tarea, encargada de inicializar el módulo GSM, es activada por la tarea
fallAlert. Para ello, también mediante comandos AT, se envían al módulo las
siguientes configuraciones:
Deshabilitar el eco. Esta opción deshabilita el eco del comando.
Chequear si el módulo está conectado a la red. Si no lo está, se chequea si el
SIM está conectado y si el módulo tiene un nivel de señal adecuado. Si esto se
cumple, se envía un comando de conexión a la red con los datos de la
operadora almacenados en la memoria EEPROM.
wifiAlert: esta tarea es la encargada de enviar la alerta de caídas al servidor. Para ello,
en primer lugar, arma el mensaje a enviar en formato JSON (acrónimo de JavaScript
Object Notation, es un formato de texto ligero para el intercambio de datos), el cual
contiene información del servidor (IP y archivo que procesará el mensaje) y del
dispositivo (IMEI y porcentaje de la batería). Una vez construido el mensaje, se envían
al módulo las siguientes configuraciones:
Establecer la conexión TCP con el servidor. Para esto es necesario recuperar de
la memoria EEPROM, su dirección IP y el puerto por el cual se estable la
comunicación.
Enviar la longitud del mensaje a enviar
Enviar el mensaje
gsmAlert: esta tarea se encarga de enviar un mensaje de texto a todos los contactos
registrados del paciente en caso de que ocurra una caída. Para ello, se envían al
módulo las siguientes configuraciones:
Seleccionar el conjunto de caracteres GSM
Establecer el formato de los SMS en modo texto
Enviar el número telefónico que recibirá el mensaje
Enviar el mensaje
measure: esta tarea es la encargada de medir la aceleración de la persona y, en caso de
detectar una caída, activar la tarea que envía la alerta (fallAlert). Para ello, se
21
desarrolló un algoritmo basado en umbrales el cual toma muestras del acelerómetro
cada 8 ms (125 Hz), las procesa y, si se superan los valores de umbral, se activará la
tarea fallAlert. A continuación, se detallará el algoritmo utilizado:
En primer lugar, se determinó qué umbrales se establecerán para la detección de una
caída. Para ello, basándose en [17] [18], se definió el primer umbral de 6g para el
vector de magnitud de las aceleraciones en los tres ejes (VMA) calculada según (1.1).
(1.1)
Donde ax, ay y az son respectivamente las aceleraciones en los ejes X, Y y Z, tomados
como se muestra en la Figura 3.7.
El segundo umbral es de 2g para la suma de las aceleraciones en el plano XZ (VMP)
calculada según (1.2). El plano Y no fue incluido debido a que, según pruebas
realizadas, se detectaron grandes valores de aceleración en este eje mientras la persona
corría o se sentaba abruptamente, las cuales hubiesen dado una señal de falsa alarma.
(1.2)
El tercer umbral es de 1,5
para la velocidad (V0) de la persona en el instante que
toca el suelo, calculada según (1.3).
(1.3)
Para realizar esta integración, se integra hacia atrás la aceleración medida en todos los
ejes (VMA) desde t1 (1500 ms luego del contacto inicial) hasta t0 (momento en el que
la persona toca el suelo), teniendo así los tiempos de integración. El valor de 1500 ms
fue obtenido empíricamente, debido a que, en todas las caídas realizadas
intencionalmente, luego de un segundo y medio, no se observaron cambios
significativos en los valores de aceleración en ninguno de los ejes de coordenadas.
Figura 3.7: Localización del acelerómetro en el cuerpo de la persona
Para programar la operación de integración en C, se utilizó el método de integración
numérica Simpson compuesto [19]. El valor de n (cantidad de sub-intervalos) fue
22
establecido en 94, la mitad de la cantidad de muestras capturadas durante el período de
integración (188 muestras). Con este valor se pretende alcanzar un punto medio entre
la calidad de la aproximación del cálculo y el cómputo que debe realizar el
microcontrolador. Queda como trabajo futuro realizar pruebas variando el valor de n.
El sistema detectará una caída cuando se supere el primer umbral o cuando se superen
el segundo y el tercero conjuntamente, tal como se puede observar en la Figura 3.8.
Figura 3.8: Diagrama de bloques del algoritmo utilizado para detectar una caída
En las tareas wifiInit, gsmInit, wifiAlert y gsmAlert, si alguno de los comandos de
configuración o envío falla, se reiniciará el proceso desde el primer comando hasta un
máximo de cinco veces. Luego del quinto fallo, la tarea retornará informando un error. Si esto
último ocurre, la tarea fallAlert aguardará 15 segundos y volverá a activar la tarea que falló.
Tabla 3.3: Parámetros en la creación de las tareas
Nombre de la tarea Prioridad (IDLE es la menor) Tamaño de la pila (en Bytes)
Measure IDLE + 2 12288
wifiInit IDLE + 1 8192
gsmInit IDLE + 1 8192
fallAlert IDLE + 3 8192
wifiAlert IDLE + 4 8192
gsmAlert IDLE + 4 8192
keepAlive IDLE + 1 8192
23
4LPCOpen es una extensa colección de bibliotecas de software (manejadores y middleware) y programas de ejemplo que permiten a los desarrolladores crear productos multifuncionales para la familia de microcontroladores LPC. Para más información dirigirse a: http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/software-tools/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES
Diseño de software en capas
Con el objetivo de independizar el código principal de la plataforma utilizada, se crearon
manejadores (en inglés, drivers) para utilizar los módulos y periféricos de la placa de
desarrollo. Es decir, el programa de usuario hace llamados a las funciones implementadas en
los manejadores, y estos hacen llamadas a las funciones de las bibliotecas propietarias del
fabricante de la plataforma. En este proyecto, los manejadores utilizan LPCOpen4. En caso de
que se quiera migrar el código a un microcontrolador perteneciente a una familia diferente, el
código de usuario no sufriría ningún cambio. Bastará con reemplazar las funciones de
LPCOpen utilizadas en los manejadores por las del nuevo framework en cuestión. Dicho nivel
de abstracción puede observarse en la Figura 3.9.
Figura 3.9: Modelado de capas del sistema
A continuación, se detallará brevemente la función de cada manejador. En la Figura 3.10 se
pueden observar las funciones que componen a cada uno.
Figura 3.10: Funciones que componen los drivers desarrollados
24
Manejador de la UART
Para hacer uso de la UART se utilizó un manejador desarrollado por el Esp. Ing. Pablo
Ridolfi. Dicho manejador implementa un búfer circular para el envío y recepción de los datos.
Para más información, el código puede encontrarse en [20].
Manejador del módulo GSM
La estrategia elegida para desarrollar este manejador fue crear funciones de envío de
comandos y funciones que reciban la respuesta del módulo GSM. El retardo necesario para
leer la respuesta del módulo no fue implementado en el manejador, delegando dicha tarea al
programador. De esta manera, el programador puede utilizar el tipo de retardo que crea más
adecuado para su aplicación (funciones del sistema operativo, retardo por software, timers,
etc.). En este caso en particular, se utilizaron funciones de retardo brindadas por FreeRTOS.
El manejador cuenta con funciones para enviar todos los comandos AT necesarios para una
comunicación SMS, funciones para retornar las características asociadas al módulo
(operadora, IMEI, etc.) y su estado (listo para enviar, señal, entre otros.), y funciones para
habilitar o deshabilitar el debugging por UART.
Manejador del módulo WiFi
Para este manejador se utilizó la misma estrategia utilizada en el manejador GSM en lo que
respecta a las funciones de envío y de recepción. Las funciones desarrolladas permiten
conectarse a una red WiFi y establecer una comunicación TCP/IP con un servidor, encuestar
al módulo sobre su estado y configuraciones (modo de operación, IP, SSID, etc.), y habilitar o
deshabilitar el debugging por UART.
Manejador GPIO
Para manejar las entradas y salidas de propósito general, se implementaron los manejadores
leds_driver y buttons_driver. El primero cuenta con funciones para inicializar los leds,
prenderlos, apagarlos e invertir su estado. El segundo tiene una única función encargada de
retornar cuál es el botón que fue presionado (no está contemplado que se presionen dos
botones al mismo tiempo).
Manejador I2C
Este manejador se implementó para que los manejadores de la memoria EEPROM y del
acelerómetro no utilicen directamente el manejador I2C brindado por LPCOpen. Además de
hacer las veces de capa de abstracción, las funciones implementadas facilitan el envío y
recepción de los datos.
25
Manejador del acelerómetro
Este manejador contiene funciones para establecer la dirección y el modo de funcionamiento
(modo sleep, frecuencia de muestreo, resolución, rango) del acelerómetro, y para leer los
datos de la aceleración sensada. Esta última adquiere los datos de los tres ejes (x, y, z), los
mapea en un rango de valores válidos y luego se los devuelve al programa principal.
Manejador de la memoria EEPROM
Este manejador contiene las funciones necesarias para leer y escribir en la memoria
EEPROM.
3.3.3 Modelo de datos
Para almacenar toda la información del sistema se utilizó una base de datos MariaDB
(derivado de MySQL con licencia GNU GPL) provista por el programa XAMPP [21]. En la
Figura 3.11 se puede observar el modelo lógico de la base y, a continuación, se listarán las
tablas que la componen:
Pacientes: contiene la información personal de los pacientes y su historia clínica. Esta
última resulta útil para informar a la ambulancia sobre, por ejemplo, posibles alergias
a medicamentos.
Dispositivos: contiene los datos capturados por los detectores de caídas e información
para distinguirlos unívocamente.
Contactos: contiene la información de contacto de los familiares de los pacientes.
Usuarios: aquí se guarda el usuario, correo y contraseña de los usuarios registrados en
el sistema. Además, contiene un campo adicional para identificar si el usuario tiene o
no funciones de administrador.
Figura 3.11: Modelado lógico de la base de datos
26
En las tablas Dispositivos, Contactos y Usuarios se creó una clave foránea id_paciente con el
fin de relacionarlas con la tabla Pacientes. En particular, la clave foránea de la tabla Usuarios
admite valor nulo debido a que los usuarios administradores pueden monitorear a más de un
paciente.
3.3.4 Diseño de la interfaz de usuario
Modelo-Vista-Controlador
Con el fin de facilitar el desarrollo y posterior mantenimiento de la aplicación web, se siguió
la filosofía MVC (Modelo, Vista y Controlador). MVC es un patrón de arquitectura de diseño
de software que se basa en las ideas de reutilización de código y la separación de conceptos.
Para ello, separa los datos de una aplicación (Modelo), la interfaz de usuario (Vista), y la
lógica de control (Controlador) en tres componentes distintos, detallando las
responsabilidades exactas de cada capa y la forma en la cual se relacionan. Se trata de un
modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo tipo de
aplicaciones, sobre multitud de lenguajes y plataformas de desarrollo [22].
Figura 3.12: Flujo de control en el modelo MVC
A modo de ejemplo para comprender el flujo de control en un esquema MVC (ver Figura
3.12), se listarán los pasos que se realizan internamente cuando un usuario intenta acceder a la
pantalla Monitoreo:
1. El usuario presiona el botón de Monitoreo en la barra de menú.
2. El controlador recibe la petición del usuario y la gestiona a través de un manejador de
eventos específico que llamaremos, a modo de referencia, manejador A. Dicho
manejador llama a diferentes funciones del modelo, dependiendo del rol del usuario
27
(pide datos de todos los pacientes o de uno en particular, en función de si el usuario es
o no administrador).
3. La función invocada accede a la base de datos utilizando comandos SQL o funciones
particulares del Framework utilizado (detallado más adelante).
4. La base de datos devuelve los datos al modelo.
5. El modelo le transfiere la información recuperada de la base de datos al manejador A.
6. Este mismo controlador ejecuta la vista correspondiente a monitorear, pasándole por
parámetro los datos recibidos del modelo.
7. La vista arma la interfaz de usuario utilizando el código HTML y los datos recibidos,
y se la envía al controlador (a partir de aquí el manejador A ya no interactúa). Cabe
destacar que la vista puede requerir más datos del modelo, por lo que llamaría a otro
manejador de eventos del controlador, repitiéndose así los pasos 2 a 7.
8. Por último, el controlador le envía al navegador la interfaz gráfica que el usuario verá
en pantalla.
Si bien se podrían seguir detallando más funcionalidades de este tipo de arquitectura y
resaltando las ventajas de utilizarla, no está en los objetivos de este proyecto. Para más
información referirse a [23] [24].
Framework CodeIgniter
Para la implementación de la aplicación web se utilizó el framework de código abierto
CodeIgniter [25]. Dicho Framework, desarrollado en lenguaje PHP, tiene como objetivo
agilizar el desarrollo de aplicaciones web, brindando un conjunto de bibliotecas que dan
solución a una gran parte de los problemas que se presentan en el desarrollo de este tipo de
aplicaciones. Además, utiliza como base el modelo MVC que se mencionó anteriormente, lo
que permite reutilizar código y mantener una orden general, lo que facilita el desarrollo y el
mantenimiento de la aplicación.
Otra ventaja de utilizar un framework como CodeIgniter es que las URLs se presentan en un
formato amigable a los buscadores. Esto quiere decir que cualquier motor de búsqueda
puntuará positivamente, a priori, las direcciones de las páginas. Del mismo modo, las
direcciones tendrán una forma fácil de entender y recordar por las personas.
En la Figura 3.13 se puede observar una URL generada por CodeIgniter (enfoque basado en
segmentos) y una URL estándar del tipo query string. Estas últimas no son amigable con los
motores de búsqueda, por lo que resultan puntuadas negativamente.
Siguiendo el enfoque Modelo-Vista-Controlador, el primer segmento representa la clase del
controlador que se debería invocar, el segundo segmento representa la función de la clase, o
método que se debería llamar y el tercer y cualquier otro segmento adicional, representan
cualquier variable que se pasará al controlador.
Las razones por las cuales se escogió CodeIgniter y no otros frameworks más utilizados como
Rails [26], Django [27] o Symfony2 [28], son su reducida complejidad y su facilidad para
alojarlo en un servidor. El framework en sí, se compone de ficheros que pueden ser enviados
28
a un servidor por protocolo FTP, por ejemplo, sin necesidad de realizar ninguna otra
configuración.
Figura 3.13: URL amigable vs URL no amigable
Diseño web adaptable
El diseño web adaptable (en inglés, Responsive Web Design), es una filosofía de diseño y
desarrollo cuyo objetivo es adaptar la apariencia de las páginas web al dispositivo que se esté
utilizando para visualizarlas (ver Figura 3.14). En la última década, el crecimiento y
expansión de los sistemas móviles, como los teléfonos inteligentes y las tabletas, se ha
incrementado exponencialmente. Esto lleva a que los sitios web tengan que ser adaptados para
que puedan visualizarse correctamente, cualquiera sea el dispositivo utilizado por el usuario.
La idea de crear un diseño web diferente para cada dispositivo es ineficiente desde cualquier
punto de vista, es por esto que es necesaria una tecnología que, con un único diseño, se
obtenga una visualización adecuada desde cualquier dispositivo.
Figura 3.14: Diferentes modos de visualizar una aplicación web en función del dispositivo utilizado
29
Para conseguir un diseño web adaptable, en este trabajo se utilizó el Framework Boostrap
[29], el cual cuenta con un conjunto de herramientas de código abierto para el diseño de este
tipo de sitios. Boostrap utiliza un sistema de grillas para almacenar los distintos componentes
de una página web (etiquetas, botones, tablas, etc.). El programador debe asignarle un ancho a
la grilla para cada tipo de dispositivo que su aplicación web vaya a soportar (chico, mediano,
grande, entre otros). Luego, si un usuario visita la página desde un teléfono celular, por
ejemplo, el framework detectará automáticamente que se trata de una pantalla pequeña y
utilizará el tamaño de grilla que el programador definió para este tipo de dispositivos.
Aplicación web dinámica
Para que la aplicación web permita la interacción de los usuarios, se utilizó el lenguaje de
programación JavaScript en conjunto con jQuery [30], una de sus bibliotecas más utilizadas.
JavaScript es un lenguaje interpretado que se utiliza principalmente del lado del cliente,
permitiendo la creación de aplicaciones dinámicas. En la aplicación desarrollada, por ejemplo,
si un usuario hace click en el botón Eliminar paciente, se llamará a una rutina JavaScript que
procesará esta petición.
A su vez, se utilizó JavaScript para efectuar las funciones de llamada de Ajax (Asynchronous
JavaScript And XML), una técnica que permite mantener una comunicación asíncrona con el
servidor en segundo plano. De esta forma, es posible realizar cambios sobre las páginas sin
necesidad de recargarlas. En la aplicación desarrollada para este proyecto, se utilizó Ajax para
actualizar la información de cada dispositivo (nivel de batería, estado de la alerta, y estado del
dispositivo) cada treinta segundos. Así, si un paciente sufre una caída, la página web lo
informará automáticamente sin necesidad de actualizar la página.
30
Capítulo 4
Ensayos y Resultados
4.1 Prototipo de detector de caídas
En las siguientes secciones se presentarán algunos de los ensayos realizados para verificar y
validar el correcto funcionamiento de los módulos utilizados y del sistema en conjunto.
Tanto las pruebas unitarias como las pruebas del sistema en conjunto, fueron realizadas
utilizando la placa de expansión para la EDU-CIAA-NXP (ver Figura 4.1) mencionada en la
sección 3.2.
Figura 4.1: Placa de expansión conectada a la EDU-CIAA-NXP
4.2 Pruebas unitarias sobre los módulos de comunicación y acelerómetro
Módulo acelerómetro
Con el fin de comprobar que la resolución elegida para el acelerómetro (±8g) es adecuada
para captar los movimientos de una persona, se desarrolló una función en MATLAB que
recibe por puerto serie los datos de la aceleración de los tres ejes y los grafica durante un
período determinado. Para realizar esta prueba, se colocó el dispositivo en la cintura y se
ejecutaron varias pruebas realizando movimientos bruscos (saltar, correr, sacudir el cuerpo,
entre otras.) durante 8 segundos (1000 muestras). Como resultado, se observó que la
aceleración de todos los ejes es, en todo momento, menor que 8g. La Figura 4.2 muestra el
31
gráfico de la aceleración en los tres ejes mientras el sujeto de prueba realizaba saltos cortos y
sacudía el cuerpo.
Figura 4.2: Valores obtenidos por el acelerómetro al saltar y sacudir el cuerpo
Módulo WiFi
Para comprobar que la comunicación con el servidor mediante el módulo WiFi se establece de
manera correcta, se utilizó la UART para monitorear cada comando enviado a dicho módulo.
En primer lugar, se desconectó el módulo WiFi, se pulsó el botón de emergencia y, a
continuación, se lo volvió a conectar. En la Figura 4.3 se puede observar que, aunque la
comunicación falle, el dispositivo se recupera y, luego de un tiempo determinado, intenta
establecer la comunicación nuevamente.
Figura 4.3: Falla en la inicialización del módulo WiFi y correcta recuperación
En segundo lugar, se pulsó nuevamente el botón de emergencia, pero esta vez el módulo
estaba conectado. En la Figura 4.4 se puede observar que los primeros comandos de
configuración fallan. Esto se debe a que, inicialmente, el módulo WiFi se encuentra apagado
32
para ahorrar batería. Antes de ejecutar la tarea de inicialización, el módulo es encendido, pero
la tarea wifiInit comienza a ejecutarse antes de que el módulo esté estable. Una vez encendido,
el módulo es configurado correctamente y el mensaje de alerta se envía satisfactoriamente.
Figura 4.4: Correcta inicialización del módulo WiFi y envío de alerta exitoso
Módulo GSM
Al igual que con el módulo WiFi, para comprobar que los mensajes de alerta a los familiares
del paciente se envíen con éxito, se utilizó la UART para monitorear cada comando enviado
al módulo GSM. Las pruebas realizadas sobre este módulo fueron las mismas que se
realizaron sobre el módulo WiFi. En la Figura 4.5 y 4.6 se puede observar que se obtuvieron
resultados similares a la primera y la segunda prueba realizadas con el módulo anterior
respectivamente.
Figura 4.5: Falla en la inicialización del módulo GSM
y correcta recuperación
Figura 4.6: Correcta inicialización del módulo GSM y
envío de alerta exitoso
4.3 Pruebas del sistema en conjunto
Para comprobar que el sistema funciona de manera correcta, se plantearon 4 escenarios de la
vida cotidiana y se observó el comportamiento del dispositivo en cada uno de ellos. Para ello,
se utilizó la función de MATLAB mencionada anteriormente para monitorear la aceleración
medida por el dispositivo en cada escenario y, en los casos que se detectó una caída, se
corroboró que la alerta haya sido recibida tanto en la página web, como en el teléfono celular
33
asociado. En todos los casos, el dispositivo detector de caídas fue colocado en la cintura del
sujeto de pruebas. A continuación, se detallan los escenarios planteados:
1. Una persona sube y baja escalones de una escalera. En la Figura 4.7 los primeros
cinco picos en el eje Y representan la subida de la escalera, luego el sujeto de prueba
se da vuelta y comienza a bajar, observándose nuevamente cinco picos en la
aceleración del mismo eje. Para este escenario, ninguno de los umbrales fue superado,
por lo que no se ha detectado ninguna caída.
Figura 4.7: Valores obtenidos por el acelerómetro al subir y bajar 5 escalones
2. Una persona se descompensa y, mientras está cayendo, se agarra de un objeto
para no golpear contra el piso. En este caso el dispositivo no pudo detectar la caída.
Debido a que el sujeto de pruebas se agarró de un objeto mientras caía, su aceleración
disminuyó y el impacto contra el piso no fue lo suficientemente fuerte como para
superar los umbrales establecidos (ver Figura 4.8). En este escenario, el algoritmo
basado en umbrales falla. Es por ello que es de suma importancia implementar, en un
futuro, un algoritmo inteligente que pueda detectar este tipo de caídas. De todas
maneras, si el paciente sigue consiente luego de producirse la caída, será capaz de
pulsar el botón de alerta y enviar la señal de auxilio.
34
Figura 4.8: Valores obtenidos por el acelerómetro al producirse una caída controlada
3. Una persona camina hacia una silla, se sienta abruptamente y luego cae al piso
hacia su derecha. En la Figura 4.9, se puede observar que el umbral de 6g no es
alcanzado, pero el dispositivo detecta la caída debido a que supera el umbral de la
velocidad con la cual la persona impacta contra el piso.
Figura 4.9: Valores obtenidos por el acelerómetro al caer desde una silla
4. Una persona tropieza, cae al piso y permanece tendida en el suelo. Esta prueba
consistió en dejarse caer sobre una colchoneta y observar la aceleración en el
transcurso de la caída. En la Figura 4.10 se puede observar que, en el momento de la
35
caída, el vector magnitud de la aceleración supera el umbral establecido (6g)
detectándose así, una caída.
Figura 4.10: Valores obtenidos por el acelerómetro al producirse una caída desde una gran altura
En los escenarios en los cuales el dispositivo detectó una caída, los módulos de comunicación
se inicializaron correctamente y se enviaron las alertas pertinentes en cada caso.
Figura 4.11: Alerta recibida en la aplicación web
36
Figura 4.12: Alerta recibida en el teléfono de contacto
En La Figura 4.11 se puede observar la alerta recibida en la aplicación web y en la Figura
4.12, la alerta recibida en el teléfono celular de contacto.
37
Capítulo 5
Conclusiones y trabajo futuro
Conclusiones
Tomando como referencia los Objetivos definidos en la sección 1.3, se puede concluir, en
principio, que la implementación del prototipo para la detección de caídas basado en la
plataforma CIAA ha resultado satisfactoria. Se ha logrado diseñar un dispositivo económico,
capaz de detectar y alertar caídas, que sienta las bases para en un futuro desarrollar un
software que permita mejorar la tasa de aciertos del dispositivo.
Durante el desarrollo de este proyecto se aplicaron los conocimientos adquiridos a lo largo de
la carreara de Especialización en Sistemas Embebidos, en especial las asignaturas:
Arquitectura de microprocesadores: esta materia resultó útil para reforzar los
conocimientos sobre la arquitectura ARM Cortex-M. Resulta imprescindible conocer
la arquitectura sobre la cual se está programando para lograr un buen resultado final.
Programación de microprocesadores: de esta asignatura fueron sumamente útiles
los conocimientos adquiridos sobre las buenas prácticas de programación de sistemas
embebidos y el diseño de software en capas a la hora de desarrollar el código principal
del dispositivo y los manejadores de los módulos.
Ingeniería de software en sistemas embebidos: gracias a esta asignatura se
aprendieron metodologías de trabajo que aportan calidad y eficiencia al producto final
desarrollado. En particular, se aplicaron técnicas de metodologías ágiles (Scrum),
control de versiones, documentación y organización de tareas.
Gestión de proyectos: esta es otra de las asignaturas que ha resultado imprescindible
para el desarrollo de este proyecto. A lo largo del curso se desarrollaron el plan de
proyecto del trabajo final, lo que permitió sentar las bases del proyecto desde el
instante inicial, e informes de avances para corroborar que el trabajo se estaba
realizando de manera correcta.
Protocolos de comunicación en sistemas embebidos: dado que el sistema
desarrollado contiene un alto grado de comunicaciones internas y externas, esta
asignatura ha resultado sumamente útil, en especial los conocimientos adquiridos
sobre protocolo TCP/IP, I2C y UART.
Sistemas operativos de tiempo real (I y II): de esta asignatura se aprendieron los
conocimientos tanto teóricos como prácticos sobre FreeRTOS y FreeOSEK. No solo
se aprendió a programar utilizando un sistema operativo de tiempo real, sino que se
adquirió la capacidad de elegir cuál de ellos utilizar para resolver un problema
determinado.
Diseño para manufacturabilidad: en esta asignatura se adquirieron conocimientos
sobre los diferentes tipos de encapsulados de los componentes, los diferentes métodos
de soldadura y las normas asociadas al diseño de circuitos impresos. Todo ello fue
aplicado a la hora de llevar a cabo el circuito impreso desarrollado.
Diseño de circuitos impresos: si bien el circuito desarrollado fue realizado previo a
cursar esta asignatura, los conocimientos adquiridos permitieron entender y corregir
los errores cometidos en el diseño original. Además, se aprendieron metodologías de
38
trabajo que serán aplicadas a la hora de diseñar un PCB con el microcontrolador y los
módulos integrados.
Trabajo futuro
Si bien los objetivos propuestos para el proyecto fueron cumplidos, quedan aún varias líneas
de trabajo futuro que se desprenden de esta tesis:
Reemplazar el algoritmo utilizado para detectar las caídas por uno basado en sistemas
inteligentes. Esto permitirá aumentar en gran medida la tasa de aciertos del
dispositivo.
Realizar pruebas de consumo sobre el microcontrolador LPC54102 con el fin de
evaluar una migración hacia esta plataforma.
Separar los módulos de adquisición de datos y procesamiento de los módulos de
comunicación GSM y WiFi con el fin de reducir el consumo y, así, prolongar la vida
útil de la batería.
Contactar un Ingeniero Industrial o con un especialista en materiales para diseñar una
carcasa para el dispositivo. Se buscará que dicho recubrimiento sea resistente al agua
con el fin de que el detector de caídas pueda ser utilizado mientras el paciente se baña.
Desarrollar una aplicación para teléfonos móviles utilizando el algoritmo basado en
sistemas inteligentes con el fin compararla con el dispositivo embebido desarrollado.
Actualizar FreeRTOS a la versión 9, la cual da soporte a tareas y a recursos estáticos.
Pensando en la posible distribución comercial del productor, será de suma importancia
adquirir conocimientos sobre normas y certificaciones de dispositivos electrónicos
para la salud.
39
Bibliografía
[1] Hornbrook MC, Stevens VJ, Wingfield DJ, Hollis JF, Greenlick MR, Ory MG. Preventing
falls among community-dwelling older persons: results from a randomized trial.
Gerontologist 1994;34(1):16e23.
[2] Hale WA, Delaney MJ, McGaghie WC. Characteristics and predictors of falls in elderly
patients. J Fam Pract 1992;34:577e81.
[3] Hausdorff JM, Rios DA, Edelberg HK. Gait variability and fall risk in community-living
older adults: a 1-year prospective study. Arch Phys Med Rehabil 2001;82:1050e6.
[4] Graafmans WC, Ooms ME, Hofstee HM, Bezemer PD, Bouter LM, Lips P. Falls in the
elderly: a prospective study of risk factors and risk profiles. Am J Epidemiol
1996;143:1129e36.
[5] Tinetti ME, Speechley M, Ginter SF. Risk factors for falls among elderly persons living in
the community. N Engl J Med 1988;319: 1701e7.
[6] Peeters GM, Pluijm SM, van Schoor NM, Elders PJ, Bouter LM, Lips P. Validation of the
LASA fall risk profile for recurrent falling in older recent fallers. J Clin Epidemiol
2010;63:1242e8.
[7] Organización Mundial de la Salud (2016, Apr 4). Centro de prensa [Online]. 2012.
Disponible en: http://www.who.int/mediacentre/factsheets/fs344/es/
[8] Colegio de Kinesiólogos de la Provincia de Buenos Aires (2016, Jun 14). Centro de
prensa. [Online]. Disponible en: http://www.cokiba.org.ar/web/?q=node/116
[9] Sáinz M. Estudio de investigación sobre Seguridad en el domicilio de personas mayores
(2016, Jun 27). Fundación MAPFRE [Online]. 2008. Disponible en:
http://www.mapfre.com/documentacion/publico/i18n/consulta/registro.cmd?id=128697
[10] Stevens J. A., Mack K. A., Paulozzi L. J., Ballesteros M. F. Self-Reported Falls and Fall-
Related Injuries Among Persons Aged >65 Years. Morbidity and Mortality Weekly Report.
Vol. 57. No. 9. 2008.
[11] Centers for Disease Control and Prevention (2016, Apr 2). Important Facts About Falls
[Online]. Disponible en: http://www.cdc.gov/homeandrecreationalsafety/falls/adultfalls.html
[12] Fall Detection Sensors Reviews (2016, May 10). 10 TopTenReviews [Online].
Disponible en: http://medical-alert-systems-review.toptenreviews.com/fall-detection/
[13] Proyecto CIAA (2016, Jul 5). EDU-CIAA-NXP [Online]. Disponible en:
http://www.proyecto-ciaa.com.ar/devwiki/doku.php
[14] Proyecto CIAA (2016, Jul 5). Ponchos [Online]. Disponible en: http://proyecto-
ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:ponchos
[15] Kicad EDA (2016, Jul 9). Enlace de descarga [Online]. Disponible en: http://kicad-
pcb.org/
40
[16] Ridolfi P. Extensión del Sistema Operativo FreeOSEK para multiprocesadores
asimétricos. 2015.
[17] Perry J.T., Kellog S., Vaidva S. M., Jong-Hoon Y., Hesham A . Sharif H. Survey and
evaluation of real-time fall detection approaches. 6th International Symposium on High-
Capacity Optical Networks and Enabling Technologies (HONET), 2009.
[18] Lindemann U. Evaluation of a fall detector based on accelerometers: a pilot study.
Medical & Biological Engineering & Computing. Vol. 43. No 5.2005.
[19] Simpson’s Rule (2016, Apr 7). Wolfram MathWorld [Online]. Disponible en:
http://mathworld.wolfram.com/SimpsonsRule.html
[20] Ridolfi P. UART Driver utilizando búfer circular (2016, Jan 14). Disponible en:
https://github.com/pridolfi/workspace/blob/master/modules/lpc4337_m4/ciaa/src/ciaaUART.c
[21] XAMPP (2016, Jul 10). Enlace de descarga [Online]. Disponible en:
https://www.apachefriends.org/es/download.html
[22] Vallés Botella A. ASP.NET MVC 3 y 4 (2016, Jul 10). Universidad de Alicante
[Online]. Disponible en: http://si.ua.es/es/documentacion/asp-net-mvc-
3/documentos/material/contacto-con-mvc.pdf
[23] Munro J. Programming MVC 3. O’Reilly Media. 2011. ISBN: 1449309860,
9781449309862
[24] Bretet A. Spring MVC Cookbook. Packt Publishing. 2016. ISBN:
978-1-78439-641-1
[25] CodeIgniter (2016, Jul 10). Enlace de descarga [Online]. Disponible en:
http://www.codeigniter.com/download
[26] Rails (2016, Jul 10). Enlace de descarga [Online]. Disponible en: http://rubyonrails.org/
[27] Django (2016, Jul 7). Enlace de descarga [Online]. Disponible en:
https://www.djangoproject.com
[28] Bootstrap (2016, Jul 8). Enlace de descarga [Online]. Disponible en:
http://symfony.com/download
[29] Symgony (2016, Jul 9). Enlace de descarga [Online]. Disponible en:
http://getbootstrap.com
[30] jQuery (2016, Jul 9). Enlace de descarga [Online]. Disponible en: https://jquery.com
41
Anexos
A. Diagrama de Gantt
En la Figura A1 se observa el Diagrama de Gantt correspondiente a la planificación
presentada en el apartado 2.3.
Figura A1: Diagrama de Gantt del proyecto
42
B. Secciones de la aplicación web
Al entrar al sitio web, el usuario se encontrará en la página de inicio (ver Figura B1). En ella,
encontrará el nombre de la empresa y su eslogan, un menú con el cual podrá navegar entre las
diferentes secciones de la página y una galería de imágenes del sistema y del producto en sí.
Figura B1: Página de inicio
A continuación, se describirán las secciones de la aplicación web:
Contacto
Como se observa en la Figura B2, esta sección contiene la información de contacto de la
central de monitoreo (dirección, teléfono, mail) y un formulario a través del cual el usuario
puede enviar mensajes de consulta.
Figura B2: Sección de contacto
43
Mi cuenta
En este apartado el usuario deberá ingresar su usuario y contraseña para entrar en el sistema.
Una vez que ingrese, si el usuario es administrador se habilitará la sección Administración. Si
el usuario ya se encuentra logueado, accederá a una sección que le permite ver la información
de su cuenta y cerrar sesión. En la Figura B3 se pueden observar de izquierda a derecha los
pasos que realiza un usuario para entrar en el sistema.
Figura B3: Pasos realizados para entrar en el sistema visto desde un iPhone 6
Administración
En esta sección, como su nombre lo indica, los administradores encontrarán las herramientas
necesarias para administrar la información de los pacientes. Al ingresar, el usuario visualizará
un listado de todos los pacientes registrados en el sistema con sus respectivos datos (ver
Figura B4). También, tendrá opciones para crear, editar y eliminar pacientes.
Figura B4: Administrador de pacientes.
44
La Figura B5 muestra la sección que permite dar de alta a un paciente. En ella, se debe
ingresar la información requerida, la cual es de carácter obligatorio, excepto el campo
observaciones. Este campo es útil para almacenar información relevante sobre el paciente
como, por ejemplo, alergias a medicamentos, historia clínica, historial de caídas, etc.
Figura B5: Administrador de paciente - Agregar paciente
Además de cargar la información personal del paciente, el usuario podrá acceder al panel
Administrador de contactos (ver Figura B6). Aquí podrá agregar información de contacto de
los pacientes, es decir, las personas que deben ser informadas ante la ocurrencia de una caída.
También, al igual que en el panel Administrador de pacientes, tendrá opciones para crear,
editar y eliminar contactos.
Figura B6: Administrador de contactos
Monitoreo
Para poder acceder a esta sección es necesario que haya un usuario registrado en el sistema.
Una vez que esto se cumpla, si se trata de un usuario normal, se mostrará información sobre el
paciente que tenga asociado. Por otro lado, si el usuario es administrador, se mostrará
información de todos los pacientes. Esta sección se observó en la Figura 2.3.
45
C. Esquemáticos del proyecto
La Figura C1 muestra la interconexión entre los pines de la EDU-CIAA-NXP y el circuito
impreso desarrollado.
Figura C1: Diagrama jerárquico del sistema
46
La Figura C2 muestra ambos conectores de la EDU-CIAA-NXP con sus respectivas etiquetas
jerárquicas.
Figura C2: Diagrama de los pines de la EDU-CIAA-NXP
47
En la Figura C3 contiene el diagrama esquemático del circuito desarrollado.
Figura C3: Esquema del circuito desarrollado