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