Desarrollo de una red de comunicaci on para la transmisi on de...

Desarrollo de una red decomunicacion para la transmision de

senales cardiacas de pacientesdomiciliarios a una interfaz Web a

bajo costo

Juan Carlos Diaz Mosquera

Cristhian Daniel Lozano Junco

Ingenieria Electronica

Director:

Edmundo Vega

Telematica

Universidad Distrital Francisco Jose de Caldas

Facultad de ingenieria

Bogota, Colombia

2017

ii

Dedicatoria

Principalmente dedico este proyecto de grado a mi madrina Lucy Nicolasa Mosquera, quien

desde siempre me ofrecio sus consejos, companıa, comprension y, sobre todo, amor. Le agra-

dezco por haberme guiado en el camino universitario, ensenarme el valor del esfuerzo y la

constancia. Gracias a cada una de sus palabras y acciones dirigidas hacia mı, he podido

crecer como persona y superar con exito las dificultades que la vida me a propuesto. Hoy y

siempre agradecere su presencia en mi vida, agradezco mi profunda admiracion hacia ella,

motor de impulso para ser cada dıa una persona mas integra.

Le dedico y agradezco con mucho amor y respeto a mi mama, quien nunca a dejado de

preocuparse por mı, le agradezco su paciencia, ensenanzas y su incondicionalidad. A mi fa-

milia por siempre creer en mi, y apoyarme en cada uno de los pasos que voy dando en la vida.

Juan Carlos Diaz Mosquera

Dedico principalmente este proyecto a mis padres, por su incondicional amor. Porque siem-

pre estuvieron presentes con su apoyo, afecto, paciencia y acciones. Por ayudarme y guiarme

en todo este proceso, por ensenarme valores y que todo con esfuerzo puede ser posible y

especialmente por ser un ejemplo a seguir.

Agradezco tambien a mis companeros y profesores, que de alguna forma me ayudaron en

todo este proceso, me brindaron sus experiencias, consejos, conocimientos y lecciones que

contribuyeron no solo en esta etapa profesional sino en mi vida general.

Cristhian Daniel Lozano Junco

iii

Agradecimientos

Los autores expresan sus agradecimientos a:

Al ingeniero Edmundo Vega Osorio, director del proyecto de grado, por su guıa, disposi-

cion e interes, por sus consejos y metodos eficientes para poder encontrar el camino correcto

hacia el desarrollo exitoso del proyecto.

A la Universidad Distrital Francisco Jose de Caldas y a todos los profesores quienes en

conjunto compartieron con nosotros conocimientos y experiencias invaluables. Por haber

sido parte del forjamiento de las bases que nos definen como personas productivas en la

sociedad.

iv

Resumen

Este trabajo describe el proceso de desarrollo e implementacion de una red de comunicacion

que tenga la capacidad de transmitir senales electrocardiograficas de pacientes domiciliarios

a una interfaz web a bajo costo.

Inicialmente se realiza la investigacion pertinente, enfocada a los distintos sistemas o pro-

tocolos necesarios para el desarrollo de esta red de comunicacion, ası como las variables y

factores que puedan afectar el rendimiento promedio de esta vista por el usuario. Posterior-

mente, con asesorıas y consultas realizadas a especialistas en salud, se realiza el diseno e

implementacion de la red de comunicacion teniendo en cuenta los requerimientos y sugeren-

cias suministrados por ellos.

Finalmente se llevan a cabo una serie de pruebas que permitan evaluar y analizar los resulta-

dos obtenidos y con ellos el rendimiento general que muestra la red basandose en la calidad

del servicio (QoS).

Contenido

Lista de figuras 1

1 Introduccion 4

2 Planteamiento del problema 5

3 Justificacion 6

4 Objetivos 8

4.1 Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4.2 Objetivos especificos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Marco referencial 9

5.1 Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.1.1 Modelo TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.1.2 Protocolo TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.1.3 Protocolo IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.1.4 QoS - Calidad de servicio . . . . . . . . . . . . . . . . . . . . . . . . 14

5.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2.1 Caracterısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2.3 Protocolo de control y adaptacion de enlace logico . . . . . . . . . . . 17

5.2.4 Piconet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2.5 Calidad de servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3.1 Definicion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3.2 Modelo Vista Controlador (MVC) . . . . . . . . . . . . . . . . . . . . 20

5.3.3 Aplicacion movil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3.4 Aplicacion web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.4 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 Metodologıa 31

6.1 Dispositivo transmisor de corto alcance (Fase 1) . . . . . . . . . . . . . . . . 31

6.1.1 Desarrollo electronico . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.2 Funcionamiento del dispositivo . . . . . . . . . . . . . . . . . . . . . 33

vi Contenido

6.2 Interfaz para dispositivos moviles (Fase 2) . . . . . . . . . . . . . . . . . . . 40

6.2.1 Permisos, peticiones y servicios . . . . . . . . . . . . . . . . . . . . . 40

6.2.2 Interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2.3 Analisis y procesamiento de la senal ECG . . . . . . . . . . . . . . . 49

6.3 Interfaz web para la visualizacion de datos y notificaciones (Fase 3) . . . . . 50

6.3.1 Instalacion del framework Laravel . . . . . . . . . . . . . . . . . . . . 50

6.3.2 Contenido de la interfaz web . . . . . . . . . . . . . . . . . . . . . . . 50

6.4 Pruebas de calidad y control (Fase 4) . . . . . . . . . . . . . . . . . . . . . . 66

6.4.1 Variables a evaluar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.4.2 Pruebas realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7 Analisis de resultados 75

7.1 Prueba de potencia de la senal Bluetooth . . . . . . . . . . . . . . . . . . . . 75

7.2 Prueba de distancia Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.3 Prueba de retardo en el servidor . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.4 Analisis general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8 Conclusiones 77

9 Trabajos futuros 78

Lista de Figuras

5-1. Modelo OSI [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5-2. Modelo TCP/IP y OSI [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5-3. Segmento TCP [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5-4. Interfaz de usuario Android Studio [12] . . . . . . . . . . . . . . . . . . . . . 22

5-5. ECG Telemedicine System Block Diagram [18] . . . . . . . . . . . . . . . . . 27

5-6. Diagrama de flujo basico del dispositivo [19] . . . . . . . . . . . . . . . . . . 28

5-7. Graficos de la senal cardiaca. [20] . . . . . . . . . . . . . . . . . . . . . . . . 30

6-1. Fases del proyecto (Fuente: Elaboracion propia) . . . . . . . . . . . . . . . . 31

6-2. PIC18F2550 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6-3. Modulo HC-05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6-4. Modulo ADC del PIC18F2550 . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6-5. Conexion del recolector de senales con el PIC18F2550 por ADC (Fuente: Ela-

boracion propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6-6. Registros del modulo ADC del PIC18F2550 . . . . . . . . . . . . . . . . . . 36

6-7. Conexion del modulo Bluetooth con el PIC18F2550 por UART (Fuente: Ela-

boracion propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6-8. Diagrama de flujo de funcionamiento del dispositivo . . . . . . . . . . . . . . 39

6-9. Funcion de peticiones a servidores alojados en internet (Fuente: Elaboracion

propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6-10.Controlador de peticiones del servidor para muestras de la senal ECG (Fuente:

Elaboracion propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6-11.Peticion para activar el Bluetooth del telefono celular. (Fuente: Elaboracion

propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6-12.Esquema de registro de pacientes (Fuente: Elaboracion propia) . . . . . . . 43

6-13.Panel de registro en la interfaz movil (Fuente: Elaboracion propia) . . . . . 44

6-14.Esquema de inicio de sesion de pacientes (Fuente: Elaboracion propia) . . . 45

6-15.Panel de inicio de sesion en la interfaz movil (Fuente: Elaboracion propia) . 45

6-16.Panel principal antes de conectarse al dispositivo transmisor. (Fuente: Elabo-

racion propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6-17.Error cuando el dispositivo no esta vinculado. (Fuente: Elaboracion propia) 47

6-18.Conexion exitosa con el dispositivo transmisor. (Fuente: Elaboracion propia) 47

6-19.Esquema de almacenamiento de muestras (Fuente: Elaboracion propia) . . . 48

2 Lista de Figuras

6-20.Panel principal en la interfaz movil (Fuente: Elaboracion propia) . . . . . . 48

6-21.Segmentos de la senal ECG (Fuente: Elaboracion propia) . . . . . . . . . . . 50

6-22.Instalacion del framework Laravel en el proyecto (Fuente: Elaboracion propia) 51

6-23.Carpetas y archivos Laravel (Fuente: Elaboracion propia) . . . . . . . . . . 51

6-24.Controlador de eventos de los doctores (Fuente: Elaboracion propia) . . . . 53

6-25.Controlador de token de la interfaz web (Fuente: Elaboracion propia) . . . . 53

6-26.Controlador de muestras (Fuente: Elaboracion propia) . . . . . . . . . . . . 54

6-27.Controlador de pacientes (Fuente: Elaboracion propia) . . . . . . . . . . . . 55

6-28.Controlador de la aplicacion web (Fuente: Elaboracion propia) . . . . . . . . 56

6-29.Configuracion de la base de datos en Laravel (Fuente: Elaboracion propia) . 57

6-30.Configuracion de canal de correos en Laravel (Fuente: Elaboracion propia) . 57

6-31.Configuracion de sesion en Laravel (Fuente: Elaboracion propia) . . . . . . . 58

6-32.Columnas de la tabla ’users’ en la base de datos (Fuente: Elaboracion propia) 58

6-33.Columnas de la tabla ’doctors’ en la base de datos (Fuente: Elaboracion pro-

pia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6-34.Columnas de la tabla ’samples’ en la base de datos (Fuente: Elaboracion

propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6-35.Vista principal de la aplicacion (Fuente: Elaboracion propia) . . . . . . . . . 61

6-36.Vista sobre informacion del proyecto (Fuente: Elaboracion propia) . . . . . 61

6-37.Vista sobre autores del proyecto (Fuente: Elaboracion propia) . . . . . . . . 62

6-38.Vista de listado de pacientes (Fuente: Elaboracion propia) . . . . . . . . . . 62

6-39.Vista de mueestras de paciente especifico (Fuente: Elaboracion propia) . . . 63

6-40.Vista de inicio de sesion de doctores (Fuente: Elaboracion propia) . . . . . . 63

6-41.Vista de registro de doctores (Fuente: Elaboracion propia) . . . . . . . . . . 64

6-42.Vista de muestra de paciente especifico para cuidadores . . . . . . . . . . . 64

6-43.Vista enviada en el correo de notificacion de anomalia (Fuente: Elaboracion

propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6-44.Asignacion de URL’s de la red (Fuente: Elaboracion propia) . . . . . . . . . 65

6-45.Archivo de configuracion de red (Fuente: Elaboracion propia) . . . . . . . . 66

6-46.Resultados de los valores de potencia a diferentes distancias. (Fuente: Elabo-

racion propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6-47.Interfaz de la aplicacion con valores de retardo y perdidas (Fuente: Elaboracion

propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6-48.Resultados obtenidos a 0m de distancia (Fuente: Elaboracion propia) . . . . 69

6-49.Resultados obtenidos a 5m de distancia (Fuente: Elaboracion propia) . . . . 70

6-50.Resultados obtenidos a 10m de distancia (Fuente: Elaboracion propia) . . . 70

6-51.Promedio de perdida de paquetes (Fuente: Elaboracion propia) . . . . . . . 71




Lista de Figuras 3

6-55.Promedio de retardo en la transmision TCP/IP (Fuente: Elaboracion propia) 74

1 Introduccion

En el desarrollo del pregrado de Ingenierıa Electronica en la Universidad Distrital Francisco

Jose de Caldas se adquirieron conocimientos y habilidades en el desarrollo de nuevas tecno-

logıas utilices para la sociedad. Con el objetivo de contribuir en la mejora de la calidad de

vida de las personas, se desarrolla una red de transmision de datos que permite el control

dinamico y remoto de la senal cardiaca de pacientes.

Se detecta en Colombia problemas respecto a la atencion de pacientes en los hospitales,

el numero de pacientes que requieren un control rutinario colapsa las instalaciones fısicas de

salud, entorpeciendo la atencion y representando un riesgo para quienes requieren atencion

inmediata. Como un aporte a la solucion de este problema se propone el uso de la tele-

medicina para la atencion de pacientes quienes requieren un control periodico de su senal

electrocardiografica, con el objetivo de descongestionar los hospitales se disena una red de

transmision que permita a los doctores el monitoreo dinamico de la senal electrocardiografica

de pacientes, ademas de un sistema de analisis y alerta el cual detecta anomalıas en la senal

cardiaca como la bradicardia, la taquicardia o la ausencia de actividad cardiaca.

2 Planteamiento del problema

La mortalidad por enfermedades cardiacas constituye la primera causa de muerte en Co-

lombia, segun un informe del DANE, y las estadısticas vitales en Colombia, las muertes

cardiacas comprenden casi el 30 % de los fallecimientos del paıs [1]. Tambien, en la actua-

lidad, existen tecnologıas de prevencion para enfermedades cardiacas en Clınicas y centros

hospitalarios especializados donde se pueden llevar a cabo monitorizaciones y seguimien-

tos pertinentes del comportamiento cardiaco de cada paciente [2]. Sin embargo, un aspecto

necesario y de gran importancia para mejorar la prevencion de enfermedades cardiacas es

facilitar la monitorizacion de la senal cardiaca de los pacientes, actualmente cada paciente

debe asistir continuamente a centros hospitalarios para realizar seguimientos respecto a su

comportamiento cardiaco, ante esto, surge la idea de facilitar dicha monitorizacion para que

pueda hacerse en cualquier momento y en cualquier parte mediante un dispositivo portatil

que recolecta la senal cardiaca, y la pueda enviar a una base de datos alojada en internet por

medio de protocolos de comunicacion inalambrica como Bluetooth (corto alcance) y TCP/IP

(largo alcance), donde el especialista o centro hospitalario a cargo tenga acceso y pueda su-

pervisar el estado del paciente de forma practica y en cualquier momento remotamente.

La importancia de enviar la senal cardiaca de forma remota es que simplifica enormemente

el proceso de monitorizacion de cada paciente, ya que el especialista a cargo puede obtener

los datos del estado actual del paciente en cualquier momento, lo cual serıa una gran ventaja

para llevar a cabo acciones que puedan ser necesarias de acuerdo al estado del paciente en

el menor tiempo posible. Este dispositivo esta enfocado para uso en personas en condicion

de discapacidad o personas de la tercera edad que tengan limitaciones para desplazarse con-

tinuamente a los centros hospitalarios; ası como tambien para cualquier persona que busque

prevenir el desarrollo de alguna enfermedad cardiaca, mejorando ası la calidad de vida de las

personas que utilicen el dispositivo. Ante esto, el objetivo es resolver el problema de: ¿Como

transferir la senal cardiaca, de un dispositivo recolector de signos vitales a una interfaz web?

3 Justificacion

El presente proyecto se enfoca en la trasmision de la senal cardiaca de un paciente a una base

de datos accesible desde internet, contribuyendo ası en la mejora del monitoreo de pacientes

con problemas cardıacos por parte de los medicos y hospitales. Este metodo de monitoreo

busca aportar en la transicion de la medicina curativa hacia la medicina preventiva. La sa-

lud es la base misma de la vida, se desea poner a disposicion tecnologıa capaz de ayudar a

mejorar la calidad de vida de los habitantes de cierta manera.

Como metodos de desarrollo del proyecto se utilizara comunicacion de corto alcance tipo

bluetooth y comunicacion de largo alcance TCP/IP. Al desarrollar un algoritmo que ademas

de integrar ambas tecnologıas permite la transferencia de un alto numero de datos (alre-

dedor de 10000 muestras por peticion) y gestione retardos para evitar la perdida de datos

por un alto numero de peticiones simultaneas en el servidor de destino, aportando ası en el

desarrollo de cualquier otra aplicacion con requerimientos similares.

Actualmente no se cuenta con esta clase de dispositivos en la medicina Colombiana que

permita la transmision y monitoreo remoto de la senal cardiaca, con este proyecto se pre-

tende dar un paso en la medicina preventiva, modelo fuertemente utilizado en los sistemas

de salud mas avanzados alrededor del mundo.

La medicina curativa, enfocada en la atencion de pacientes enfermos fue durante mucho

tiempo la unica pauta en salud a nivel mundial, sin embargo, esta ha empezado a ser com-

plementada por la medicina preventiva, enfocada en evitar el surgimiento de enfermedades.

Este nuevo sistema de salud ha demostrado tener mejores resultados en la longevidad de la

poblacion donde se aplica, ademas de la reduccion de costos en terminos de infraestructura

hospitalaria.[2]

Con el desarrollo de este proyecto se pretende estar mas cerca del analisis de los signos

vitales de los pacientes de forma remota, descongestionando ası los centros hospitalarios y

facilitando la adquisicion de datos relevantes para el tratamiento de enfermedades cardiacas

(entre otras).

Transmitiendo la senal cardiaca del paciente a los medicos o especialistas con acceso a la

plataforma, se busca detectar enfermedades de tipo cardiovascular por medio de tecnologıas

7

no invasivas, con lo cual se minimiza el riesgo para los pacientes al momento de monito-

rear. La acumulacion de un gran numero de informacion en intervalos de tiempo amplios

permite efectuar un analisis mas preciso y efectivo, por lo tanto, este proyecto contribuye

directamente con la calidad en la atencion medica de manera sostenible.

4 Objetivos

4.1. Objetivo general

Desarrollar una red de comunicacion para la transmision de senales cardiacas de pacientes

domiciliarios a una interfaz Web a bajo costo.

4.2. Objetivos especificos

Disenar e implementar un dispositivo que almacene y transmita periodicamente la senal

cardiaca del paciente a un dispositivo movil.

Desarrollar una interfaz que transmita la senal cardiaca desde el dispositivo movil a

una base de datos alojada en internet.

Desarrollar una interfaz amigable con el usuario (medicos), con la cual puedan analizar

de forma rapida y eficaz la informacion suministrada por nuestro dispositivo.

Evaluar el correcto funcionamiento del dispositivo.

5 Marco referencial

En este capıtulo se muestran las investigaciones de conceptos que aportan a la compresion

y desarrollo del proyecto de grado, ası como tambien se muestran antecedentes que estan

relacionados con los temas abarcados en este proyecto.

5.1. Modelo OSI

El modelo OSI (Open Systems Interconnection) es un modelo de red de referencia para per-

mitir la comunicacion e interoperabilidad entre distintas redes y sistemas tecnicos. el modelo

OSI divide los problemas de comunicacion en tareas mas sencillas acomodando cada tipo

de problema en una capa determinada. Este modelo de referencia tiene siete capas, que se

mostraran a continuacion detalladamente.[3]

Capa 1: Fisica

Esta capa define la topologıa de la red y las conexiones fısicas que se deben realizar como

medio por donde viaja la informacion. En esta capa se definen variables como niveles de

voltaje, la velocidad de transmision de datos, tipos de conectores, materiales que se utilizaran

para las conexiones, etc.

Capa 2: Enlace de datos

La capa de enlace de datos proporciona el transito de datos confiable por medio de un enlace

fısico.Se encarga del direccionamiento fısico, del acceso al medio, deteccion de errores, de

la distribucion ordenada de tramas y el control del flujo. En esta capa se encuentran las

siguientes tecnologıas de red: Ethernet, Frame Relay, ATM, PPP y Wi-Fi.

Capa 3: Red

La capa de red se encarga de brindar la conectividad y encontrar la mejor ruta para el flujo

de informacion entre dos puntos. En esta capa se encuentran los protocolos encargados del

enrutamiento, como los protocolos RIP, IGRP, OSPF, BGP. en esta capa tambien se realiza

10 5 Marco referencial

Figura 5-1: Modelo OSI [3]

el direccionamiento logico (protocolo IP) y la determinacion de la ruta de los datos hasta su

receptor final.

Capa 4: Transporte

La capa de transporte se encarga de la segmentacion de los datos para que puedan ser

transmitidos desde un host a otro. Para brindar un servicio confiable se emplea la deteccion

y recuperacion de errores en el transporte ası como la informacion en el control de flujo. Los

protocolos mas importantes presentes en esta capa son TCP y UDP.

Capa 5: Sesion

La capa de sesion se encarga de establecer, administrar y finalizar la comunicacion entre

dos host diferentes, por tanto, el servicio provisto por esta capa es la capacidad de asegurar

que, dada una sesion establecida entre dos maquinas, la misma se pueda efectuar para las

operaciones definidas de principio a fin, reanudandose en caso de interrupcion. En muchos

casos, los servicios de la capa de sesion son parcial o totalmente prescindibles.

Capa 6: Presentacion

Esta capa se encarga de asegurar que la informacion que fluye entre las capas de aplicacion de

dos sistemas que estan en comunicacion pueda ser leıda de forma adecuada. Tambien en esta

5.1 Modelo OSI 11

Figura 5-2: Modelo TCP/IP y OSI [3]

capa se realiza el proceso de cifrado y descifrado de datos. Algunos protocolos comunmente

utilizados en esta capa son SSL y TLS.

Capa 7: Aplicacion

Esta es la capa que se encuentra en la parte superior del modelo OSI, y su funcion es in-

teractuar directamente con las aplicaciones del usuario, proporciona servicios de red a los

programas, tambien sincroniza y establece acuerdos en los procedimientos para la recupera-

cion de errores e integridad en el control de datos. Algunos protocolos comunes en esta capa

son FTP y HTTP.

5.1.1. Modelo TCP/IP

El modelo TCP/IP es una descripcion de protocolos de red que inicialmente fue implantado

en la red ARPANET. Es usado para comunicaciones en redes y describe un conjunto de

guıas generales de operacion para permitir que un equipo se pueda comunicar en una red. El

modelo TCP/IP esta dividido en cuatro capas: aplicacion, transporte, internet y acceso a red.

Algunas de estas capas pueden abarcar mas de una capa del modelo OSI. TCP/IP combina

las capas de aplicacion, presentacion y sesion del modelo OSI en la capa de aplicacion; las

capas de enlace de datos y fısica en la capa de acceso a red.

Capa de acceso a red

La capa de acceso a red es la encargada de crear un enlace fısico con el medio de red. se

encarga tambien de dirigir (rutear) los datos que fluyen entre dos hosts de una LAN. Los

servicios que provee esta capa son control de flujo y de errores de datos que viajan entre los

hosts. Esta capa es asimilable a la capa de enlace de datos y la capa fısica del modelo OSI.


Capa de Internet

Esta capa tiene como proposito enviar paquetes desde un dispositivo a otro, por medio del

protocolo adecuado. Tambien se determina la mejor ruta para entregar los paquetes. En esta

capa se encuentra el protocolo IP el cual realiza las funciones de capa de red en el modelo

OSI para el modelo TCP/IP. Otros protocolos importantes presentes en esta capa son ICMP,

ARP, RARP.

Capa de transporte

La capa de transporte proporciona los servicios para transportar la informacion desde un

host a otro, por medio de una conexion logica entre estos. los protocolos presentes en esta

capa segmentan la informacion para poder ser enviada, y posteriormente re ensamblarlos

cuando esta llega a su destino. La capa de transporte asume que puede utilizar la red como

una nube para enviar paquetes de datos desde un origen hasta un destino. En esta capa

trabajan los protocolos TCP y UDP.

Capa de aplicacion

La capa de aplicacion se encarga de manipular la informacion para que esta pueda ser leıda

adecuadamente. Dentro de esta se encuentran los protocolos HTTP, DNS, FTP, NFS, SMTP,

SNMP, entre otros. Esta capa es la que engloba mas capas del modelo OSI, ya que tiene

inmersas las capas de sesion, presentacion y aplicacion, por lo tanto, en esta capa tambien

se realizan las funciones de codificacion y se utilizan protocolos de cifrado como SSL y TLS.

5.1.2. Protocolo TCP

El protocolo TCP (protocolo de control de transmision) es uno de los protocolos fundamen-

tales de Internet. Trabaja sobre la capa de transporte y es el encargado de proporcionar una

transmision fiable de datos orientada a la conexion. El protocolo TCP divide la informacion

en paquetes de datos llamados segmentos, y tambien los reensambla cuando estos son recibi-

dos, para esto, el protocolo tiene la capacidad de identificar de alguna manera cada uno de

los segmentos. El protocolo TCP da soporte a muchas aplicaciones de internet y protocolos

de aplicacion como HTTP, FTP, SMTP, SSH, etc.

Puerto de origen: Numero de puerto que realiza la llamada.

Puerto de destino: Numero del puerto que es llamado.

Numero de secuencia: Numero utilizado para garantizar la secuenciacion correcta de

la llegada de datos.

Numero de acuse: Siguiente octeto TCP esperado.

5.1 Modelo OSI 13

Figura 5-3: Segmento TCP [3]

Longitud de cabecera: Numero de palabras de 32 bits de la cabecera.

Reservado: Establecido a cero.

Bits de codigo: Funciones de control (como configuracion y finalizacion de una sesion).

Ventana: Numero de octetos que el emisor es capaz de aceptar.

Suma de comprobacion: Suma de comprobacion que incluye la cabecera y los campos

de datos.

Puntero urgente. Indicacion del final de datos urgentes.

Datos: Datos del protocolo de capa superior.

Opciones: Una opcion definida actualmente es el tamano maximo del segmento TCP.

5.1.3. Protocolo IP

El protocolo de internet IP, es un protocolo de comunicacion de datos digitales, que trabaja

en la capa de red del modelo OSI. La funcion principal de este protocolo es el uso bidireccional

para comunicacion de datos mediante un protocolo no orientado a conexion que transfiere

paquetes conmutados a traves de varias redes fısicas enlazadas segun la norma OSI de enlace

de datos. Permite el desarrollo y transporte de datagramas de IP (paquetes de datos), pero no

garantiza su entrega. El protocolo IP puede determinar el destinatario del mensaje mediante

tres campos:[4]


Campo de direccion IP: Esta dada por la direccion del equipo.

Campo de mascara de subred: La cual permite al protocolo IP establecer la parte de

la direccion IP que se relaciona con la red.

Puerta de enlace predeterminada: La cual permite al protocolo IP saber a que equipo

enviar un datagrama.

5.1.4. QoS - Calidad de servicio

QoS o Calidad de servicio es un termino referente al rendimiento promedio de una red digital,

especialmente orientado al rendimiento visto por los usuarios de la red. Mide la calidad de

los servicios prestados por la red con varios aspectos como tasas de errores, ancho de bandam

rendimiento, retraso en la transmision, jitter, disponibilidad, etc.[5]

Variables a medir con el QoS

Bajo rendimiento: Debido a la carga variante de otros usuarios compartiendo los mis-

mos recursos de red, la tasa de bits (el maximo rendimiento) que puede ser provista

para una cierta transmision de datos puede ser muy lenta para servicios en tiempo real

si toda la transmision de datos obtiene el mismo nivel de prioridad.

Paquetes mom:Los ruteadores pueden fallar en liberar algunos paquetes si ellos llegan

cuando los buffers ya estan llenos. Algunos, ninguno o todos los paquetes pueden

quedar sueltos dependiendo del estado de la red, y es imposible determinar que pasara

de antemano. La aplicacion del receptor puede preguntar por la informacion que sera

retransmitida posiblemente causando largos retardos a lo largo de la transmision.

Retardos: Puede ocurrir que los paquetes tomen un largo perıodo en alcanzar su des-

tino, debido a que pueden permanecer en largas colas o tomen una ruta menos directa

para prevenir la congestion de la red. En algunos casos, los retardos excesivos pueden

inutilizar aplicaciones tales como VoIP o juegos en lınea.

Latencia: Puede tomar bastante tiempo para que cada paquete llegue a su destino,

porque puede quedar atascado en largas colas, o tomar una ruta menos directa para

evitar la congestion. Esto es diferente de rendimiento, ya que el retraso puede mejorar

con el tiempo, incluso si el rendimiento es casi normal. En algunos casos, latencia

excesiva puede convertir a una aplicacion como VoIP juegos online inusable.

Jitter: Los paquetes del transmisor pueden llegar a su destino con diferentes retardos.

Un retardo de un paquete varıa impredeciblemente con su posicion en las colas de los

ruteadores a lo largo del camino entre el transmisor y el destino. Esta variacion en

retardo se conoce como jitter y puede afectar seriamente la calidad del flujo de audio

y/o vıdeo.

5.1 Modelo OSI 15

Entrega de paquetes fuera de orden: Cuando un conjunto de paquetes relacionados entre

sı son encaminados a Internet, los paquetes pueden tomar diferentes rutas, resultando

en diferentes retardos. Esto ocasiona que los paquetes lleguen en diferente orden de

como fueron enviados. Este problema requiere un protocolo que pueda arreglar los

paquetes fuera de orden a un estado isocrono una vez que ellos lleguen a su destino.

Esto es especialmente importante para flujos de datos de vıdeo y VoIP donde la calidad

es dramaticamente afectada tanto por latencia y perdida de sincronıa.

Errores: A veces, los paquetes son mal dirigidos, combinados entre sı o corrompidos

cuando se encaminan. El receptor tiene que detectarlos y justo cuando el paquete es

liberado, pregunta al transmisor para repetirlo ası mismo.

Entrega de paquetes fuera de orden Cuando un conjunto de paquetes relacionados entre

sı son encaminados a Internet, los paquetes pueden tomar diferentes rutas, resultando

en diferentes retardos. Esto ocasiona que los paquetes lleguen en diferente orden de

como fueron enviados. Este problema requiere un protocolo que pueda arreglar los

paquetes fuera de orden a un estado isocrono una vez que ellos lleguen a su destino.

Esto es especialmente importante para flujos de datos de vıdeo y VoIP donde la calidad

es dramaticamente afectada tanto por latencia y perdida de sincronıa. Errores. A veces,

los paquetes son mal dirigidos, combinados entre sı o corrompidos cuando se encaminan.

El receptor tiene que detectarlos y justo cuando el paquete es liberado, pregunta al

transmisor para repetirlo ası mismo.


5.2. Bluetooth

Bluetooth es un estandar de comunicacion inalambrica de corto alcance, baja potencia y

costo reducido que utiliza frecuencias radiales para su funcionamiento. Fue desarrollado ori-

ginalmente por la empresa fabricante de celulares Ericsson en 1994. Por su capacidad de

integracion, esta tecnologıa ha sido ampliamente utilizada en celulares, computadores, pe-

rifericos de datos y audio.[6]

En la actualidad las implementaciones Bluetooth son de topologıa punto a punto con enlaces

directos entre el receptor y el transmisor. Sin embargo, de acuerdo a las especificaciones del

protocolo de comunicacion tienen como objetivo brindar soluciones de redes mas complejas,

con la implementacion scatternets las cuales proporcionan una pasarela eficaz y eficiente de

multiples saltos y retardos aceptables con bajo consumo de energıa que puedan brindar una

transferencia de datos correcta de extremo a extremo en una red.

5.2.1. Caracterısticas

El estandar de comunicacion bluetooth cumple en la actualidad con las siguientes carac-

terısticas:[4]

La velocidad maxima de comunicacion es de 720 Kb por segundo.

La distancia maxima optima de comunicacion es de 10 metros.

La frecuencia de radio de trabajo esta entre los 2.4Ghz a los 2.48Ghz.

Posibilidad de transmision Full Duplex.

La potencia maxima de transmision para la version bluetooth tradicional es de 0dBM,

es decir, 1mW.

La potencia maxima de transmision para la version bluetooth de largo alcance es de

20dBM (100mW).

Combina protocolos de empaquetamiento y switcheo para asegurar que los paquetes

lleguen en orden.

Cada dispositivo debe contar con un tranceptor, el cual permite la transmision y re-

cepcion de datos en la frecuencia de 2.4Ghz (ISM).

5.2.2. Hardware

Segun la especificacion Bluetooth denominada Core, la cual define el nivel fısico (PHY) y el

control de acceso al medio (MAC), los protocolos base de esta tecnologıa, son: [7]

5.2 Bluetooth 17

Nivel de radiofrecuencia: En este nivel se encuentra el dispositivo fısico denominado

transceptor, el cual utiliza la banda ISM de 2.4GHz. Con el uso unanime y general de

esta banda como medio de comunicacion entre transceptores bluetooth se asegura la

compatibilidad entre los diferentes dispositivos independiente del fabricante.

Nivel de banda base: en este nivel se hace el control de la transicion y recepcion

de datos, se realizan correccion de errores, brodcast automaticos y cifrado de la infor-

macion. Ademas se gestiona la peticion de repeticiones de transmision ante posibles

perdidas en el canal de datos.

Nivel de gestion: Por medio de este nivel de la capa fısica de la comunicacion se

gestiona el inicio y final de la comunicacion entre dos o mas dispositivos. Se realiza

control y planificacion de trafico, ademas de autenticaciones al momento de iniciar la

conexion entre dispositivos. Esta gestion se hace a traves del protocolo LMP (Link

Manager Protocol).

El protocolo LMP utilizado en este nivel, tambien se encarga de la administracion

de la energıa de la comunicacion bluetooth, ası como notificacion del estado de la co-

municacion. Constantemente se realizan busquedas de otros dispositivos en el rango de

establecimiento de conexion, y de ser encontrado alguno, inicia una comunicacion de

deciframiento para determinar si es posible establecer la comunicacion.

5.2.3. Protocolo de control y adaptacion de enlace logico

L2CAP

Por medio del protocolo L2CAP se habilita la funcionalidad de segmentar paquetes, por lo

cual, paquetes muy grandes no admisibles en capas inferiores, son segmentados en tramas

de tamano admisible para el transito y posterior recomposicion de la trama completa en la

capa L2CAP del dispositivo receptor.[7]

5.2.4. Piconet

Se define como una agrupacion espontanea de dispositivos bluetooth. En una piconet, uno

de los dispositivos se le denomina maestro, mientras que a los demas se les llama esclavos.

El numero de dispositivos esclavos dentro de una piconet es ilimitado, sin embargo se deben

tener en cuenta ciertas apreciaciones:

El numero maximo de esclavos activos en una piconet en un instante de tiempo es de

siete, si hay mas, estos se encuentran en un estado de inactividad.


El numero maximo de esclavos directos es de 255, sin embargo, es posible conectar

mas dispositivos a una piconet de manera indirecta respecto a su direccion especifica

bluetooth.[6]

5.2.5. Calidad de servicio

Para poder entender el formato de funcionamiento de la calidad de servicio en la comunica-

cion bluetooth, es necesario conocer la capa HIC, disponible en algunos dispositivos de esta

tecnologıa.

Capa HIC

La interfaz de control de host estandariza las aplicaciones de nivel superior, de esta manera

es posible acceder a capas inferiores en la pila del estandar. Esta capa no es un requeri-

miento obligatorio del estandar, sin embargo, con la implementacion de esta se busca la

interoperabilidad entre dispositivos.[6]

Calidad de servicio

En terminos de programacion, la comunicacion bluetooth ofrece llamadas al protocolo HCI

para la configuracion y observacion de algunos parametros de enlace, como el tipo de pa-

quete o el tiempo de descarga, los cuales afectan directamente el uso del ancho de banda, la

latencia y la tasa de error de los canales.[8]

Una vez configurados los parametros de calidad de servicio, estos pueden ser transmiti-

dos tanto por un esclavo como por un maestro. Si el esclavo es quien envıa los parametros

de configuracion a un maestro, el maestro podra aceptar o rechazar dichos parametros, sin

embargo, en el caso contrario, si el maestro envıa parametros de configuracion de calidad de

servicio a un esclavo, este tendra que aceptarlos y configurarse de acuerdo con esta. Quien

inicial la configuiracion esta directamente relacionado con el flujo de datos que va a haber

en la comunicacion, si la transmision es de esclavo a maestro (tranmsision ascendente) la

configuracion de calidad de servicio tambien sera enviada en ese sentido, de manera equiva-

lente, si la transmision es de maestro a esclavo (transmision descendete) la configuracion de

calidad de servicio ira en ese sentido.

La comunicacion bluetooth ofrece distintas configuraciones de calidad de servicio, en las

que se encuentran:

Sin trafico

significa que la transmision solo debe generarse en el sentido de flujo de datos.

5.2 Bluetooth 19

Mejor esfuerzo

esta configuracion indica que el dispositivo receptor podra:

• Ignorar el resto de los parametros de calidad de servicio locales.

• Tratar de satisfacer la solicitud de calidad de servicio sin transmitir respuesta.

• Responder con la configuracion de calidad de servicio que puede lograr.

Esta configuracion requiere de los siguientes parametros de configuracion, de lo con-

trario se generara una interrupcion en la comunicacion:

• Tokenrate:la velocidad de datos continua requerida.

• Tamano del contenedor token: La velocidad de transmision de datos maxima

a la que equivale una transmision continua.

• Ancho de banda maximo:La velocidad de transmision de datos maxima a la

que equivale una transmision continua.

• Latencia:La demora maxima aceptada.

• Variacion de retardo: la variacion en el tiempo de retardo entre paquetes.

Como se puede observar en los parametros de configuracion de la calidad de servicio

Bluetooth, no existe un parametro que establezca la tasa de error de la transmision,

sin embargo, para esto, se hace uso del tiempo de retransmision de descarga, en la

cual se define el tiempo que puede durar un dato en el buffer antes de ser remplazado

por datos mas recientes. De acuerdo con este tiempo y al tiempo de transmision de

paquetes, se puede establecer la tasa de error admitida en la comunicacion.


5.3. Software

5.3.1. Definicion

Es el conjunto que contiene un set de instrucciones organizadas de manera logica para la

ejecucion de un programa de computadora junto con la documentacion y datos relacionados

con la operacion de dicho sistema.[9]

5.3.2. Modelo Vista Controlador (MVC)

El modelo de referencia (framework) MVC (Model-View-Controller), aplica el concepto de

separacion de codigo en el proceso de desarrollo de un software, es decir, en vez de ubicar

todo el codigo en un lugar, el modelo de referencia segmenta el codigo en tres partes.[10]

Modelo: En este segmento del codigo de programacion se ubica toda la logica relacio-

nada con la conexion y comunicacion con las bases de datos.

Vista: En este segmento del codigo de programacion se almacena la logica relacionada

con la visualizacion y presentacion de datos al usuario.

Controlador: En este segmento del codigo de programacion se almacena la logica

comercial, es decir toda la logica que hace posible la interaccion entre el modelo y la

vista. Para describir este segmento de manera mas simple, aquı se almacena el codigo

que diferencia un software de otro, ya que se definen todos los eventos he interacciones

que este tendra desde los datos hacia los usuarios.

5.3.3. Aplicacion movil

Lenguaje de programacion Java

Java es un lenguaje de programacion creado por Sun Microsystems Inc desde 1990. Es un

lenguaje de proposito general, valido para realizar todo tipo de aplicaciones profesionales.

Los softwares desarrollados sobre este lenguaje de programacion no son dependientes de la

arquitectura del equipo que lo contenga, son capaces de ejecutarse una gran variedad de

sistemas operativos, incluyendo, Windows, Linux y Android.

Es un lenguaje publico, por lo cual unicamente se requiere un JDK (Java Developers kit)

para poderlo utilizar. Permite escribir pequenos programas ejecutables en paginas HTML

En terminos de seguridad es capaz de administrar los recursos del sistema de manera con-

trolada, gestionar permisos criptograficos y ademas proveen seguridad frente a virus a traves

de redes locales e internet.

Java como lenguaje de programacion, cuenta con las siguientes caracterısticas:

5.3 Software 21

Lenguaje orientado a objetos.

Funcionamiento integro con la red (internet).

Aprovecha caracterısticas de otros lenguajes modernos, intentando evitar ciertos in-

convenientes que estos posees, como C++.

Gran repositorio de libreririas.

El manejo de punteros de memoria es independiente del usuario y del programador, es

decir, la asignacion de espacio de memoria para variables se hace de manera autonoma

y transparente.

Incorpora Multi-threading, con lo cual es posible ejecutar varios hilos de codigo en

paralelo de un mismo programa.

Este lenguaje se considera una evolucion del lenguaje C++. Su sintaxis es muy parecida, sin

embargo, Java fue disenado desde cero, en un intento por evitar errores detectados en C++

y C.

Java es un lenguaje interpretado, de esta manera es posible ejecutar un programa inde-

pendiente del sistema operativo. En el proceso de publicacion de un proyecto, el programa

es inicialmente compilado, una vez supera el filtro de compilacion, se crea un fichero que

almacena el codigo de programacion a nivel de maquina y este es el que se utiliza para ser

ejecutado por medio de una maquina virtual java en cualquier dispositivo.

Android studio

Es un entorno de desarrollo integrado (IDE), disenado especialmente para el desarrollo de

aplicaciones moviles para dispositivos con plataforma Android. Este entorno esta basado en

el modelo de referencia MVC y compila el lenguaje de programacion Java. Como principales

caracterısticas de desarrollo cuenta con: [12]

Emulador de la aplicacion.

Entorno unificado para el desarrollo de aplicaciones para distindos dispositivos An-

droid.

Instant Run, con el cual es posible aplicar cambios sobre una aplicacion en tiempo de

ejecucion.

Herramienta Lint, con la cual se detectan errores en rendimiento, usabilidad y compa-

tibilidad de versiones.


Figura 5-4: Interfaz de usuario Android Studio [12]

1. Barra de herramientas: Permite realizar acciones, como la ejecucion de la aplicacion

y el uso de herramientas de Android Studio.

2. Barra de navegacion: Permite explorar el proyecto, por lo tanto, por medio de esta

ventana se pueden abrir los diversos archivos que compren el codigo de programacion

y editarlos.

3. Ventana del editor: En este espacio se realizan todos los desarrollos respecto al

codigo de programacion del software.

4. Barra de la ventana de herramientas: Permite contraer y expandir ventanas de

herramientas individuales.

5. Ventanas de herramientas: Permite acceder a tareas especıficas, como la adminis-

tracion de proyectos, las busquedas, los controles de version (entre otros).

6. Barra de estado: Permite visualizar el estado actual del proyecto y del IDE, se

muestran advertencias y alertas.

Play store

Es una plataforma de distribucion digital propiedad de la companıa Google Inc, por medio

de esta aplicacion es posible publicar y descargar aplicaciones moviles para dispositivos con

5.3 Software 23

sistema operativo Android.[13]

Desde la plataforma de ventas, los usuarios podran navegar y descargar cualquier aplica-

cion publicada dentro de la plataforma siempre y cuando posean el espacio de memoria y la

cantidad monetaria requerida por dicha aplicacion.

Desde la plataforma de desarrolladores, es posible subir aplicaciones y gestionar las ya al-

macenadas por el desarrollador en la plataforma.

Antes del 2012 los usuarios con dispositivos Android contaban con la aplicacion Android

Market y Google music (ambas plataformas de descarga de contenido), sin embargo, a partir

de ese ano, ambas plataformas fueron fusionadas y renombradas al nombre unico de Google

Play, todo como una estrategia de distribucion digital.

5.3.4. Aplicacion web

Lenguajes de desarrollo

HTML

Es un lenguaje de etiquetas utilizado en el desarrollo web para definir la estructura de una

pagina web, por medio de este lenguaje los desarrolladores web son capaces de:[14]

Publicar documentos estaticos con cabeceras, texto, tablas, listas y fotos (entre otras).

Asociar otro contenido web por medio de links, o pulsando botones.

Disenar formularios que permitan realizar transacciones con direccion a servicios re-

motos.

Incluir aplicaciones en una pagina web que contengan hojas de calculo, videoclips, clips

de sonido y cualquier otro tipo de aplicacion compatible.

CSS

Por medio del lenguaje de etiquetas CSS se define la presentacion de una pagina web, es

decir, se configuran todos los parametros de diseno como: los colores de fondo, los colores de

la fuente, el tamano de los textos, la posicion de los contenedores, las animaciones visuales

respecto a eventos, la distribucion de los textos, la visualizacion respecto a la resolucion de

la pantalla (entre otros)

.


JavaScript

JavaScript es un lenguaje de programacion basado en script ejecutado en el lado del cliente,

es decir, una secuencia de comandos en un codigo que no necesitan ser preprocesador para

poderse ejecutar. JavaScript es utilizado en la web para descargar paginas o como respuesta

e eventos de interaccion entra la pagina y el usuario.[15]

Por medio de este lenguaje de programacion se desarrollan paginas web mas dinamicas,

ya que permiten que la pagina interactue con el usuario sin necesidad de descargar conteni-

do desde el servidor que la aloja, y una vez la interaccion es completada se pueden ejecutar

acciones de comunicacion con el servidor sin necesidad de recargar la pagina.

Los scripts en la pagina web tambien permiten recolectar informacion acerca del disposi-

tivo desde el cual se esta visualizando la pagina web, de esta manera es posible cambiar

aspectos visuales de la misma en relacion con los parametros capturados. Junto con los len-

guajes basicos del desarrollo web (HTML y CSS), con el uso de JavaScript se desarrollan

aplicaciones web, las cuales se comportan como software tradicionales de escritorio.

Hypertext Preprocessor (PHP)

Es un lenguaje de script de codigo abierto adecuado para el desarrollo web para uso inte-

grado con el HTML. El uso mas simple de PHP en HTML es incluir las etiquetas de inicio

y fin php dentro de la hoja html, de esta manera se le senala al navegador, cuando entrar o

salir del modo PHP.[16]

Este lenguaje (a diferencia de JavaScript) se ejecuta del lado del servidor, esto repercute

en la seguridad de las paginas web puesto, que el codigo PHP implementado en una pagi-

na web no sera visible para los usuarios, ellos solicitaran su uso, y el servidor unicamente

ejecutara el codigo solicitada y enviara un HTML con la respuesta del codigo. Este funcio-

namiento lo hace ideal para desarrollo de aplicaciones web robustas con alta fiabilidad en el

manejo de datos.

Marco de referencia (Framework)

Laravel

Es un framework disenado para el desarrollo de paginas y aplicaciones web, nativo de PHP,

utiliza el modelo de referencia MVC y programacion orientada a objetos. A traves de este

framework se facilita la configuracion y manejo de tareas web genericas, como la autentica-

cion, el enrutamiento, las sesiones de usuario y el almacenamiento en cache.[17]

Es un framework disenado para el desarrollo de paginas y aplicaciones web, nativo de PHP,

5.3 Software 25

utiliza el modelo de referencia MVC y programacion orientada a objetos. A traves de este

framework se facilita la configuracion y manejo de tareas web genericas, como la autentica-

cion, el enrutamiento, las sesiones de usuario y el almacenamiento en cache.

Laravel hace uso de la API lluminate, propia de este framework, la cual cuenta con un

gran numero de clases y funciones que conforman el nucleo de este marco de referencia.


5.4. Antecedentes

A continuacion, se muestran tres proyectos quasi-experimentales en los cuales se utilizaron

diferentes metodos de captura y transmision de muestras de la senal ECG vıa inalambrica

con el objetivo de monitorizar pacientes de manera remota.

La seleccion de estos artıculos se hizo en base a las similitudes que tienen respecto a es-

te proyecto para poder evidenciar las facilidades y complicaciones que se tuvieron, ası como

sentar una base respecto a los alcances y limitaciones.

Monitorizacion de la senal ECG de forma remota para aplicaciones de telemedicina

Este dispositivo fue disenado bajo el objetivo de lograr visualizar la senal ECG de un paciente

de forma remota, cuenta con bastantes herramientas que permiten la captura y transmision

exitosa de datos, utilizando almacenamiento de datos removible como perifericos USB y me-

morias flash, ademas de transmision de datos inalambricos haciendo uno de protocolos de

corto y largo alcance como el protocolo bluetooth y TCP/IP respectivamente.

El proyecto fue segmentado en tres bloques generales:

El primero de los bloques denominado “DAM” es el encargado de la adquisicion y

procesamiento de la senal ECG del paciente, de tal forma que pueda ser transmitida y

visualizada en los siguientes bloques.

El segundo bloque, denominado “AP” cumple la funcion de recolectar los datos entre-

gados por el bloque DAM para ser visualizado y nuevamente transmitidos mediante el

protocolo de comunicacion TCP/IP a una estacion remota.

El tercero de los bloques denominado “aplicacion de software”, es la encargada de la

visualizacion local y/o remota de los datos recolectados.

A continuacion, se muestra el diagrama de bloques completo del dispositivo:

5.4 Antecedentes 27

Figura 5-5: ECG Telemedicine System Block Diagram [18]

Respecto a los resultados obtenidos, los tres bloques del sistema funcionaron con exito, no

se encontro perdida de datos, y las transmisiones no presentaron latencia por encima de lo

esperado respecto a los protocolos de comunicacion implementados.

Aunque es un dispositivo integro respecto a los diferentes modulos y funcionalidades im-

plementadas, no incluye funcionalidades de analisis y por tanto excluye un esquema de

notificaciones que permita la monitorizacion dinamica de datos, ademas al solo tomar como

punto de referencial la senal ECG del paciente no es posible establecer una amplia gama de

anomalıas que este pueda padecer.

Dispositivo de bajo consumo energetico y transmision de datos via bluetooth

El dispositivo desarrollado en el artıculo se destaca por haber sido disenado para un bajo

consumo de energıa durante el proceso de recoleccion y transmision de datos, ademas, hace

uso del protocolo de comunicacion de corto alcance bluetooth.


Este dispositivo captura la senal ECG, la temperatura y el nivel de oxigeno del paciente

por medio del dispositivo Arduino, el cual a su vez analiza los datos capturados y emite

senales de alerta vıa bluetooth a celulares inteligentes, computadoras u otros dispositivos

con puerta de enlace bluetooth, en caso de encontrar anomalıas en alguno de los datos cap-

turados.

A continuacion, se muestra el diagrama de flujo que representa el funcionamiento ıntegro del

dispositivo:

Figura 5-6: Diagrama de flujo basico del dispositivo [19]

Respecto a la implementacion del dispositivo, se consiguio con exito capturar las muestras

de 20 pacientes, ademas, el analisis de los datos mostros resultados positivos emitiendo aler-

5.4 Antecedentes 29

tas cuando se encontraban anomalıas en alguna de las senales. El impacto que tuvo este

dispositivo en la comunicad fue ampliamente valorado puesto que, segun los cardiologos in-

volucrados, se redujo hasta en un 50 % el trabajo en el laboratorio.

De acuerdo con el analisis del dispositivo vale la pena destacar que dejando a un lado las

ventajas que este tiene en cuanto a consumo de energıa y analisis de datos, no es capaz de

transmitir informacion a grandes distancias, y por tanto no es posible un analisis de datos

realmente remoto.

Holter de transmision inalambrica

Este dispositivo captura todos los procesos necesarios para la recoleccion de la senal ECG

hasta el almacenamiento digital de esta en destinos remotos. El dispositivo captura la senal

ECG por medio de electrodos ubicados estrategicamente en el paciente para su posterior

transduccion a senales electronicas analogicas, una vez se captura la senal en energıa electri-

ca esta es filtrada por medio de circuitos electronicos para eliminar el ruido capturado en el

proceso de conversion, luego del proceso de filtrado la senal es acondicionada y digitalizada

por medio de un microprocesador, el cual a su vez se encarga de la transmision de estos datos

vıa TCP/IP hacia un servidor remoto el cual almacenara las muestras para ser visualizadas

por medio de una pagina web.

El desarrollo del dispositivo fue segmentado en cuatro bloques generales los cuales cum-

plen las funciones de capturar, acondicionar, procesar/transmitir y almacenar la senal ECG

respectivamente. Se obtuvieron resultados positivos en todos los segmentos del dispositivo

sometiendolo a prueba en diez pacientes.

El desarrollo del dispositivo fue segmentado en cuatro bloques generales los cuales cum-

plen las funciones de capturar, acondicionar, procesar/transmitir y almacenar la senal ECG

respectivamente. Se obtuvieron resultados positivos en todos los segmentos del dispositivo

sometiendolo a prueba en diez pacientes.

Vale la pena destacar el proceso de filtrado de la senal ECG capturada, puesto que en

la grafica obtenida desde el servidor es facil de observar la nitidez de la senal almacenada,

como se muestra a continuacion:


Figura 5-7: Graficos de la senal cardiaca. [20]

Del dispositivo se puede observar que pese a su integridad, no cuenta con un metodo de

transmision de datos a corto alcance, por lo tanto el paciente estara sometido a permanecer

en un lugar especifico mientras se capturan los datos de la senal ECG, ademas no se cuenta

con un sistema de analisis y notificacion de anomalıas sobre la senal, por lo tanto sera

necesario permanecer en contante analisis presencial de los datos en busqueda de dichas

anomalıas, haciendo ineficiente la implementacion masiva del dispositivo.

6 Metodologıa

Para la metodologıa del proyecto se tuvo en cuenta el tipo de investigacion cuasi-experimental

propuesto por Mario Tamayo y Tamayo en su libro El proceso de la investigacion, en el que

propone que este modelo investigativo es “Apropiado en situaciones naturales en que no es

posible el control experimental riguroso“ [21]

Figura 6-1: Fases del proyecto (Fuente: Elaboracion propia)

6.1. Dispositivo transmisor de corto alcance (Fase 1)

El objetivo de la primera fase es el diseno e implementacion del dispositivo desde el cual

se recibira la senal cardiaca para su posterior transmision haciendo uso del protocolo de

comunicacion de corto alcance Bluetooth.

Se diseno un dispositivo con la capacidad de captar la senal electrocardiografica del recolector

de senales ECG, y posteriormente enviarla a traves del protocolo Bluetooth a una aplicacion

movil (fase 2). Adicionalmente, con el fin de identificar los requerimientos y necesidades

del usuario final (medicos) se llevaron a cabo varias reuniones con el Dr. Adalberto Amaya

Afanador, director del centro de simulacion clınica de la Pontificia Universidad Javeriana

con el cual se establecieron las siguientes especificaciones:

Recoleccion de la senal cardiaca en un intervalo de diez segundos.

Intervalo entre cada recoleccion de cinco minutos.

6.1.1. Desarrollo electronico

Con base a las especificaciones y requerimientos anteriormente descritos, se decidio utilizar

los siguientes componentes electronicos para la implementacion del dispositivo.

32 6 Metodologıa

Microcontrolador

El microcontrolador es el encargado de recibir la senal ECG, y luego enviarla a la aplica-

cion movil para su posterior procesamiento. Para esto fue necesario que el microcontrolador

tuviese:

Un modulo conversor analogico digital (ADC) para recibir la senal electrocardiografica

del dispositivo recolector de senales ECG.

Un modulo UART para transferir la informacion guardada a traves del modulo Blue-

tooth.

Debido a esto, se decidio utilizar el PIC18F2550, el cual tiene un modulo UART, canales

de conversion analogica digital de 10 bits, un modo de energıa (IDLE) en el cual la CPU se

apaga para ahorrar energıa, pero los perifericos siguen encendidos, lo cual genera un ahorro

de energıa importante mientras el dispositivo esta en reposo, ademas es un dispositivo de

bajo costo, lo cual lo hace ideal para la implementacion del prototipo.

Figura 6-2: PIC18F2550

Modulo Bluetooth

La razon mas importante de usar un modulo Bluetooth es que este protocolo actualmente se

encuentra en la mayorıa de los dispositivos moviles, por lo cual su implementacion permite

que la mayorıa de personas puedan utilizar este dispositivo con su telefono celular. Se utilizo

el modulo Bluetooth HC-05, el cual tiene unas dimensiones de 1,7cm X 4cm, transmite a

2,4GHz, brinda un alcance de hasta 10 metros, y su funcionamiento es de bajo consumo con

una corriente de 8mA en modo de espera.

6.1 Dispositivo transmisor de corto alcance (Fase 1) 33

Figura 6-3: Modulo HC-05

6.1.2. Funcionamiento del dispositivo

El microcontrolador requiere de un voltaje de alimentacion entre 2,2 y 5,5 V, por lo tanto,

se decidio utilizar un voltaje de 3,3V debido a que con este mismo voltaje trabaja el modulo

Bluetooth utilizado. Para que el microcontrolador pueda trabajar correctamente requiere de

una senal de reloj, que puede ser obtenida de un oscilador interno o externo, para este fin se

opto por un oscilador externo compuesto por un cristal de 20MHz. la implementacion de las

funciones logicas requeridas para el funcionamiento integro del dispositivo fue segmentado

en dos bloques:

Adquisicion de las muestras de la senal ECG: la adquisicion de datos se realizo

a traves del modulo ADC, para esto, es necesario que el microcontrolador detecte

una senal en dicho periferico ademas de una bandera de activacion proveniente de la

aplicacion movil (fase 2).

34 6 Metodologıa

Figura 6-4: Modulo ADC del PIC18F2550

De los 28 pines que tiene el microcontrolador, se utilizo el pin AN0/RA0, configurado

como entrada y como pin analogico, para la adquisicion de las muestras de la senal

electrocardiografica.

Figura 6-5: Conexion del recolector de senales con el PIC18F2550 por ADC (Fuente: Ela-

boracion propia)

Algunas especificaciones relativas a la configuracion del modulo ADC son las siguientes:


• Frecuencia de muestreo: Para seleccionar el valor de la frecuencia a la que

funciona el modulo ADC, se tuvo en cuenta el teorema del muestreo de Nyquist-

Shannon, que establece que la senal analogica puede ser reproducida con fidelidad

a partir de la digital si la frecuencia de muestreo es al menos del doble de la

maxima frecuencia de la senal a muestrear. Por lo tanto, teniendo en cuenta que

la senal electrocardiografica tiene componentes de frecuencia de hasta 150 Hz, se

decidio fijar la frecuencia de muestro en 300 Hz.

Fm > 2FMax (6-1)

El periodo de muestreo es el inverso de la frecuencia de muestreo y es:

Tm =1

Fm

=1

300Hz

= 0,00333ms (6-2)

• Rango de voltaje: El rango de voltaje que se establecio fue desde 0 V hasta

Vcc, es decir, hasta 3,3 V.

• Resolucion: La resolucion de un conversor ADC indica el numero de valores

discretos que se obtienen a la salida del conversor. En este caso, el modulo ADC

trabaja con una resolucion de 10 bits, con lo cual a la salida se tienen 1024 posibles

valores. El valor de LSB (Least significant bit) es el minimo cambio de voltaje

que debe ocurrir en la senal analogica para que cambie el valor de la senal digital,

y su valor es el siguiente:

LSB =VREF

2n − 1=

3, 3V

1023= 3, 22mV (6-3)

• Tiempo de conversion Para el PIC18F2550, el fabricante recomienda que el

tiempo de conversion sea de mınimo 0,7uS, por lo tanto, para obtener un valor

cercano a este se configura el dispositivo con Fosc/16, el cual nos da un valor de:

Fconv =20MHz

16= 1,25MHz (6-4)

Tad =1

Fconv

= 0, 8uS (6-5)

36 6 Metodologıa

• Tiempo de adquisicion Para el PIC18F2550, el fabricante sugiere un tiempo

de adquisicion mayor a 2.45 us, por lo cual se selecciono un tiempo de adquisicion

de 4 TAD:

Tacq = 4 ∗ 0, 8 = 3, 2uS (6-6)

Para la lectura de la conversion hecha, se leen los registros ADRESH; en el cual se en-

cuentran los dos bits mas significativos; y ADRESL donde estan los ocho bits restantes

de la conversion.

Figura 6-6: Registros del modulo ADC del PIC18F2550

Transmision de las muestras: La transmision de las muestras recolectadas por el

modulo ADC se hizo a traves del modulo UART del microcontrolador. Este periferico se

encarga de enviar o recibir informacion de manera serial (un bit tras otro). Los pines que

se utilizaron para llevar a cabo la comunicacion fueron RC6/TX configurandolo como

salida para la transmision; y RC7/RX configurandolo como entrada para la recepcion

de informacion. Estos pines van conectados de forma ”cruzada” con los pines TX y

RX del modulo Bluetooth.

Figura 6-7: Conexion del modulo Bluetooth con el PIC18F2550 por UART (Fuente: Ela-

boracion propia)

Algunas especificaciones relativas a la configuracion del modulo UART son las siguien-

tes:


• Tasa de baudios: la tasa de baudios se refiere al numero de bits por segundo que

es posible transmitir. El modulo HC-05 esta configurado por defecto a una tasa de

baudios de 9600. Para que la comunicacion sea efectiva es necesario que tanto el

modulo como el microcontrolador se encuentren a la misma tasa de baudios. Ası

que se procede a configurar la tasa de baudios en el microcontrolador definiendo

los valores de los registros SPBRGH y SPBRG, y el bit BRGH que en caso de

estar en 1 multiplica la tasa de baudios por 4. Para calcular el valor de SPBRG

se utilizo la siguiente formula:

Tasa de baudios =FOSC

16(n + 1)= 9600 (6-7)

Donde la parte entera de n es el valor de SPBRG, despejando la ecuacion y

teniendo en cuenta que la frecuencia de reloj del microcontrolador es de 20 Mhz:

n =20MHz

16(9600)− 1 = 129,2 (6-8)

Debido a que el valor entero de n calculado es menor a 255, no es necesario el uso

del registro SPBRGH. Al reemplazar el valor obtenido de n se obtuvo la tasa de

baudios exacta a la que trabaja el microcontrolador:

Tasa de baudios =20MHz

16(129 + 1)= 9615,38 (6-9)

Error =Tasa de baudios real − Tasa de baudios deseada

Tasa de baudios deseadax100 = 0,16 % (6-10)

• Tamano del paquete de datos: el modulo UART permite enviar paquetes de

8 o 9 bits. Se utilizo un tamano de 8 bits en el cual el primer bit transmitido es

el menos significativo.

• Modo de transmision: el modulo UART del PIC18F2550 permite los modos de

comunicacion sincronica y asincronica. Se establecio utilizar el modo asincronico

puesto que este permite congestion de datos en caso de retardo en la transmision o

recepcion de datos y en vez de descartar los datos a enviar o recibir, los almacena

temporalmente en un buffer.

• Metodo de envio de informacion: como se dijo anteriormente, cada muestra

que toma el modulo ADC del microcontrolador esta compuesta de 10 bits, de los

38 6 Metodologıa

cuales se reparten los 2 mas significativos en el registro ADRESH y los 8 restantes

en ADRESL. Debido a que el modulo UART envıa paquetes de a 8 bits, el metodo

de envio de cada muestra estara compuesto por dos datos de 8 bits, donde primero

se envıa la informacion de ADRESH y seguidamente se envıa la informacion de

ADRESL. La importancia de enviar estos datos uno detras del otro por cada

muestra es que la aplicacion movil tenga la capacidad de unir los datos en parejas

conforme van llegando.


Figura 6-8: Diagrama de flujo de funcionamiento del dispositivo

40 6 Metodologıa

6.2. Interfaz para dispositivos moviles (Fase 2)

La segunda fase del proyecto tiene como objetivo el diseno e implementacion de la interfaz

para dispositivos moviles encargada de:

Recibir las muestras de la senal cardiaca bajo el protocolo de comunicacion Bluetooth.

Almacenar los paquetes de datos recibidos y acondicionarlos para su posterior visuali-

zacion.

Transmitir las muestras de la senal cardiaca bajo el protocolo de comunicacion TCP/IP

hacia una base de datos alojada en internet.

La interfaz movil fue disenada con el fin de recibir los datos provenientes del dispositivo

transmisor de corto alcance (fase 1), procesar dichos datos para graficarlos, analizarlos y

transmitirlos a las bases de datos de la interfaz web (fase 3) vıa TCP/IP. Esta interfaz fue

desarrollada y compilada bajo el IDE nativo de Java, Android Studio para el soporte de

versiones 4.4.2 en adelante, lo que significa una brecha de usuarios Android del 90 %.

Como caracterısticas basicas de la aplicacion se implemento la conexion Bluetooth con el

dispositivo transmisor de corto alcance (fase 1), ademas de la habilitacion de los permisos

para la conexion a internet por medio del protocolo TCP/IP.

6.2.1. Permisos, peticiones y servicios

Permisos de la aplicacion

En principio fue necesario configurar los permisos de la aplicacion para el acceso a los pe-

rifericos de comunicacion tanto Bluetooth (corto alcance) como TCP/IP (largo alcance),

ya que son indispensables para el desarrollo de los diferentes apartados que comprenden la

interfaz movil. Los permisos deben ser configurandos en el archivo manifest de la aplicacion,

las sentencias implementadas fueron:

uses-permission android:name=.android.permission.BLUETOOTH

uses-permission android:name=.android.permission.BLUETOOTHADMIN

uses-permission android:name=.android.permission.INTERNET

uses-permission android:name=.android.permission.ACCESSNETWORKSTATE

6.2 Interfaz para dispositivos moviles (Fase 2) 41

Peticiones TCP/IP al servidor de base de datos

Se disenaron las funciones necesarias para la comunicacion entre la aplicacion movil y el

servidor de bases de datos por medio del protocolo TCP/IP, para ello se utilizo el metodo

de peticion post request , el cual envıa los datos en el encabezado de la peticion TCP/IP a

diferencia del metodo de peticion get request el cual envıa los datos sujetos a la URL. La

funcion de manejo de peticiones TCP/IP utilizada en la interfaz web se muestra a continua-

cion:

Figura 6-9: Funcion de peticiones a servidores alojados en internet (Fuente: Elaboracion

propia)

Ya que en la fase 3 se hace uso del Framework Laravel para la administracion del Back-

end y el Front-end de la aplicacion, en esta fase se aprovechan las herramientas de dicho

Framework para la recepcion de las peticiones en el servidor, por medio de los denominados

controladores. En Laravel, los controladores son los segmentos de codigo logico basados en

42 6 Metodologıa

PHP capaces de recibir una peticion por medio de una URL, ejecutar un procedimiento y

responder de vuelta, todo haciendo uso del protocolo TCP/IP. A continuacion, se muestra

un ejemplo de controlador implementado en el servidor:

Figura 6-10: Controlador de peticiones del servidor para muestras de la senal ECG (Fuente:

Elaboracion propia)

Conexion Bluetooth

Para establecer la conexion Bluetooth entre la aplicacion movil y el microcontrolador se

comprueba primero que este encendido en el telefono celular, en caso contrario, se envıa una

peticion para encenderlo. Luego se escanean los dispositivos que esten vinculados al telefono,

y en caso que no lo este se muestra el panel para vincular dispositivos Bluetooth.

Figura 6-11: Peticion para activar el Bluetooth del telefono celular. (Fuente: Elaboracion

propia)


6.2.2. Interfaz de usuario

La interfaz de usuario esta compuesta por tres actividades, de las cuales una permite el

registro de nuevos usuarios a la base de datos, la segunda es la pantalla de login para

usuarios registrados anteriormente, y la actividad principal, que comprende el procedimiento

para vincular el dispositivo y observar los datos recolectados por el dispositivo transmisor

de corto alcance (fase 1).

Panel de registro

En el panel de registro se capturan los datos del paciente, ademas de los datos de notificacion

para el cuidador de este. Cuando los pacientes se registran como usuarios activos de la

aplicacion se les asigna automaticamente un numero unico de identificacion en la base de

datos y con este el paciente es identificado inequıvocamente dentro de la red de datos.

Ademas, capturando el correo del cuidador se habilita la posibilidad de envio de notificaciones

en caso de encontrar anomalıas en alguno de los bloques de muestras almacenados en el

servidor.

Figura 6-12: Esquema de registro de pacientes (Fuente: Elaboracion propia)

44 6 Metodologıa

Figura 6-13: Panel de registro en la interfaz movil (Fuente: Elaboracion propia)

Panel de inicio de sesion

El panel de inicio de sesion para el paciente fue desarrollado con el proposito de identificarlo

dentro de la red de datos. Al paciente se le solicita el numero de identificacion y contrasena

ingresados al momento de registrarse, cuando el paciente pulsa el boton de inicio de sesion, es

enviada una peticion de inicio de sesion al servidor, si el servidor responde con otro numero de

identificacion (el determinado por la base de datos), la interfaz le concede el paso al usuario

y habilita el panel de recoleccion, visualizacion y transmision de la senal electrocardiografica.


Figura 6-14: Esquema de inicio de sesion de pacientes (Fuente: Elaboracion propia)

Figura 6-15: Panel de inicio de sesion en la interfaz movil (Fuente: Elaboracion propia)

46 6 Metodologıa

Panel principal de la interfaz

El panel principal de la interfaz es el encargado de ejecutar todas las funciones de la recepcion,

transmision y procesamiento de las muestras obtenidas de la senal ECG. En esta pantalla

tambien se muestran los datos de la ultima recoleccion de la senal ECG tales como ritmo

cardiaco, fecha y hora de la ultima recoleccion exitosa y una grafica de la senal ECG.

Figura 6-16: Panel principal antes de conectarse al dispositivo transmisor. (Fuente: Elabo-

racion propia)

En cuanto se presiona el boton de iniciar conexion, la interfaz inicia el proceso de busqueda

del dispositivo transmisor de corto alcance (fase 1), de recibir alguna respuesta, se ejecuta

la solicitud de emparejamiento para posteriormente enviar la bandera de activacion de reco-

leccion de muestras. Una vez la interfaz recibe todas las muestras, se inicia con el proceso

de adecuacion de estas para ası graficarlas y a su vez enviarlas al servidor remoto de base

de datos.


Figura 6-17: Error cuando el dispositivo no esta vinculado. (Fuente: Elaboracion propia)

Figura 6-18: Conexion exitosa con el dispositivo transmisor. (Fuente: Elaboracion propia)

48 6 Metodologıa

Figura 6-19: Esquema de almacenamiento de muestras (Fuente: Elaboracion propia)

Figura 6-20: Panel principal en la interfaz movil (Fuente: Elaboracion propia)


6.2.3. Analisis y procesamiento de la senal ECG

Recoleccion de la senal ECG

Cuando el proceso de conexion es finalizado, la aplicacion empieza a recibir la senal pro-

veniente del modulo Bluetooth, debido a que la frecuencia de muestreo es de 300Hz y el

tiempo de la captura de informacion es de 10 segundos, la aplicacion espera hasta conseguir

al menos 3000 muestras. Como se dijo anteriormente, cada muestra esta compuesta por dos

paquetes de ocho bits. Para reagrupar de nuevo cada muestra en una sola variable se lleva a

cabo la siguiente formula:

Muestra = (dato1 << 8) + dato2 (6-11)

El resultado obtenido de cada muestra tiene un valor comprendido entre 0 y 1023, para

obtener este valor en milivoltios de la senal cardiaca se realizo la siguiente operacion para

garantizar valores entre 0 V y 3 mV:

Muestra =muestra

341(6-12)

Calculo de ritmo cardiaco

Para el calculo del ritmo cardiaco, se tuvo en cuenta el complejo QRS de la senal ECG,

debido a que este segmento de la senal tiene un valor significativamente mas alto se hace un

conteo de las veces que la senal pasa por los valores mas altos posibles, y debido a que las

muestras solo representan diez segundos, se multiplica el valor anteriormente hallado por 6.

50 6 Metodologıa

Figura 6-21: Segmentos de la senal ECG (Fuente: Elaboracion propia)

6.3. Interfaz web para la visualizacion de datos y

notificaciones (Fase 3)

la tercera fase del proyecto tiene como objetivo el diseno e implementacion de la interfaz

web encargada de la visualizacion de datos almacenados en la base de datos, esta es capaz

de discriminar las muestras respecto a cada paciente y hora de recepcion en internet.

La interfaz web del proyecto permite la conexion de la red de datos con la base de datos

del servidor remoto, ademas, permite el desarrollo de una aplicacion web desde la cual los

medicos pueden visualizar el estado de la senal cardiaca de sus pacientes e informacion

sobre el funcionamiento del proyecto. La interfaz web fue desarrollada bajo el framework de

Laravel.

6.3.1. Instalacion del framework Laravel

Inicialmente es necesario descargar el framework sobre el proyecto que se desea desarrollar,

para ello se hizo uso de ejecutor de comandos de Windows, se accedio a la carpeta donde se

ubica el proyecto y posteriormente se ejecuto el comando de descarga del Laravel.

6.3.2. Contenido de la interfaz web

Una vez instalado el framework se tienen acceso a todas las carpetas y archivos que com-

prenden el cuerpo de la interfaz, muchas de estas carpetas no son editables ya que son

6.3 Interfaz web para la visualizacion de datos y notificaciones (Fase 3) 51

Figura 6-22: Instalacion del framework Laravel en el proyecto (Fuente: Elaboracion propia)

estrictamente requeridas para el correcto funcionamiento del framework, las demas carpe-

tas son utilizadas para implementar todas las funciones y visualizaciones que hacen parte

del proyecto, a continuacion se muestran las carpetas editables del proyecto junto con su

correspondiente descripcion de funcionamiento puntual para la interfaz:

Figura 6-23: Carpetas y archivos Laravel (Fuente: Elaboracion propia)

52 6 Metodologıa

1. Modelos y controladores: En la carpeta app del framework se almacenan tanto los

modelos de la aplicacion como los controladores. Un modelo es el conector entre un

controlador y una tabla de la base de datos, mientras que el controlador es un bloque

de funciones logicas que ejecutan una accion determinada al momento de ser llamados.

Se desarrollaron los siguientes modelos:

Doctor: Modelo encargado de conectar con la tabla en la base de datos que

almacena la informacion de los doctores.

Sample: Modelo encargado de conectar con la tabla en la base de datos que

almacena la informacion de las muestras de los pacientes.

User: Modelo encargado de conectar con la tabla en la base de datos que almacena

la informacion de las paciones, ası como el correo de su respectivo cuidador.

Se desarrollaron los siguientes controladores:

DoctorController: Este controlador almacena todas las funciones encargadas

del control de informacion de los doctores, inmerso en este controlador se desa-

rrollaron las siguientes funciones:

• Index: Direccionamiento al panel de inicio de sesion o al panel principal de

visualizacion de datos, dependiendo de si se ha iniciado sesion con anteriori-

dad.

• Create: Direccionamiento a la vista web de registro donde este podra ingresar

sus datos y almacenarlos en la base de datos.

• Store: Se encarga de procesar la peticion de registro de un doctor, por medio

de esta funcion los doctores quedan almacenados en la base de datos, de haber

ingresado correctamente la informacion en la vista de registro.

• Login: Se encarga de procesar la peticion de inicio de sesion de un doctor,

si el doctor ingreso sus credenciales correctamente, esta funcion habilita la

bandera de sesion activa en el servidor.


Figura 6-24: Controlador de eventos de los doctores (Fuente: Elaboracion propia)

ExternConectionController: Este controlador contiene una unica funcion la

cual se encarga de asociar un token al flujo de datos bajo el protocolo TCP/IP,

de esta forma se previenen peticiones maliciosas hacia el servidor ya que sin este

token las peticiones son rechazadas independientemente de la funcion que deseen

alcanzar.

Figura 6-25: Controlador de token de la interfaz web (Fuente: Elaboracion propia)

54 6 Metodologıa

SamplesController: Este controlador contiene cuatro funciones para la mani-

pulacion de las muestras de la senal cardiaca dentro de la interfaz:

• CargarMuestra: Esta funcion procesa las peticiones entrantes que solicitan

el almacenamiento de un banco de muestras dentro de la base de datos.

De ser aprobada la solicitud, una vez almacenada la muestra en la base de

datos, se desarrollo el analisis del ritmo cardiaco en busca de anomalıas, de

encontrar alguna anomalıa esta funcion envıa un correo de alerta al cuidador

correspondiente.

• MostrarMuestra: Esta funcion se encarga de extraer las muestras de la

base de datos de un paciente especifico, dentro de la solicitud que requiere

esta funcion debe estar incluido el id del paciente, de esta manera la funcion

filtra los datos en la base de datos y devuelve unicamente las muestras del

paciente solicitado.

• CalcularNumeroDeBloques: Esta funcion retorna la cantidad de bloques

de muestras que contiene un paciente.

Figura 6-26: Controlador de muestras (Fuente: Elaboracion propia)

UserController: Este controlador contiene dos funciones encargadas del registro

e inicio de sesion de los pacientes.

• RegisterUser: Funcion encargada de gestionar las peticiones de registro de

pacientes, si los datos son correctos, estos quedan almacenados en la base de

datos.


• Login: funcion encargada del inicio de sesion de los pacientes, si las creden-

ciales enviadas en la solicitud de inicio de sesion son correctos, la funcion

retorna el id unico asignado por la base de datos.

Figura 6-27: Controlador de pacientes (Fuente: Elaboracion propia)

WebPageController: Este controlador contiene todas las funciones encargadas

de gestionar las peticiones y visualizaciones hechas desde la aplicacion web, a

excepcion de aquellas hechas por los doctores ya que estas hacen uso del Doctor-

Controller.

• General: Redirige a la visualizacion principal de la aplicacion web.

• Webindex: Redirige a la visualizacion de inicio de la aplicacion web.

• Webaboutproyect: Redirige a la visualizacion que habla sobre el proyecto

en la aplicacion web.

• Webwhoweare: Redirige a la visualizacion que habla sobre quienes hicieron

el proyecto en la aplicacion web.

56 6 Metodologıa

Figura 6-28: Controlador de la aplicacion web (Fuente: Elaboracion propia)

2. Configuraciones generales: La carpeta config del framework Laravel permite hacer

configuraciones sobre las herramientas principales de la interfaz, contiene once archivos

de configuracion, sin embargo, en el desarrollo de la interfaz solo fue necesario utilizar

tres de ellos:

Database.php: Este archivo de configuracion nos permite indicarle al framework

las caracterısticas de nuestra base de datos, se establecio el tipo de base de datos

como MySql, ademas se configuro la IP del servidor que aloja la base de datos, el

nombre de la base de datos y las credenciales de acceso a la misma.


Figura 6-29: Configuracion de la base de datos en Laravel (Fuente: Elaboracion propia)

Mail.php: Este archivo de configuracion nos permite indicarle al framework las

caracterısticas del canal de envio de correos. Se configuro dicho canal bajo el

protocolo de comunicacion SMTP, se establecio el puerto 25 como puerto de salida

de correos, no se establecio ningun protocolo de encriptacion y finalmente se asigno

el correo y respectiva contrasena desde el cual se enviaran los correos para las

alertas.

Figura 6-30: Configuracion de canal de correos en Laravel (Fuente: Elaboracion propia)

Sesion.php: Este archivo de configuracion unicamente fue modificado en el apar-

tado de lifetime, el cual le asigna un tiempo maximo de duracion a una sesion

inactiva dentro de la interfaz. El tiempo de vida maximo de una sesion inactiva

fue establecido en 120 minutos.

58 6 Metodologıa

Figura 6-31: Configuracion de sesion en Laravel (Fuente: Elaboracion propia)

3. Contenido en la base de datos: En la carpeta Database se hizo uso de la sub

carpeta Migrations en donde fueron implementados los archivos necesarios para definir

las tablas y las columnas que cada una de estas contiene. En la interfaz web fueron

disenadas tres tablas:

Tabla de pacientes: Esta tabla contiene los datos del paciente, aquı son alma-

cenados los datos que se envıan desde la interfaz movil (fase 2), en la peticion de

registro.

Figura 6-32: Columnas de la tabla ’users’ en la base de datos (Fuente: Elaboracion propia)

Tabla de doctores: Esta tabla contiene los datos de los doctores, aquı son

almacenados los datos que se envıan desde la aplicacion web desde la vista de

registro de doctores.


Figura 6-33: Columnas de la tabla ’doctors’ en la base de datos (Fuente: Elaboracion

propia)

60 6 Metodologıa

Tabla de muestras: Esta tabla contiene los datos de las muestras, las cuales

son enviadas desde la interfaz movil (fase 2), en la peticion de almacenamiento

de muestra.

Figura 6-34: Columnas de la tabla ’samples’ en la base de datos (Fuente: Elaboracion

propia)

4. Html enriquecido: La carpeta public del framework permite la insercion de com-

plementos que enriquecen las vistas sobre la aplicacion web, en esta carpeta fueron

incluidos todos los archivos .css y .js de cada una de las vistas disponibles en la apli-

cacion, ademas, para el almacenamiento de las imagenes y videos disponibles fueron

creadas las sub carpetas img y videos respectivamente.

5. Vistas de la interfaz web: La carpeta resources contiene todas las vistas disponibles

en la aplicacion movil, es decir el front-end de la interfaz web, dentro de la sub carpeta

views se encuentran todas las vistas desarrolladas bajo el lenguaje de etiquetas html

que permiten la visualizacion de todos los datos disponibles en la aplicacion web.

Fue necesario desarrollar 10 vistas independientes y 5 base (se usan para formar una

estructura base sobre las vistas independientes).

Vistas de la aplicacion web

• Webpageindex: Esta vista es la primera al aparecer en la aplicacion web,

con un mensaje llamativo se contextualiza al usuario acerca del proyecto de

forma directa.


Figura 6-35: Vista principal de la aplicacion (Fuente: Elaboracion propia)

• Webaboutproyect: Esta vista muestra en detalle las caracterısticas del pro-

yecto describiendolo y justificandolo, se introdujo el contenido del plantea-

miento del problema y justificacion del documento del ante proyecto.

Figura 6-36: Vista sobre informacion del proyecto (Fuente: Elaboracion propia)

• Webwhoweare: En esta vista fueron introducidos los nombres de los desa-

rrolladores del proyecto.

62 6 Metodologıa

Figura 6-37: Vista sobre autores del proyecto (Fuente: Elaboracion propia)

Vistas para los doctores

• Applicationindex: Esta vista muestra el listado de pacientes registrados en

la red, una vez es seleccionado alguno de los pacientes, la aplicacion web hace

uso de la vista applicationpanel.

Figura 6-38: Vista de listado de pacientes (Fuente: Elaboracion propia)

• Applicationpanel: Esta vista muestra el listado de muestras del paciente

seleccionado desde la vista ApplicationIndex, ademas, de ser seleccionada al-

guna muestra, esta vista se encarga de graficar las muestras y mostrar los

correspondientes pulsos por minuto.


Figura 6-39: Vista de mueestras de paciente especifico (Fuente: Elaboracion propia)

• Logindoctor: Esta vista muestra el panel de inicio de sesion para los doc-

tores, desde esta vista es enviada la solicitud de inicio de sesion hacia el

controlador DoctorController a la funcion Login.

Figura 6-40: Vista de inicio de sesion de doctores (Fuente: Elaboracion propia)

• Registerdoctor: Esta vista muestra el panel de registro para los doctores,

desde esta vista es enviada la solicitud de registro hacia el controlador Doc-

torController a la funcion store.

64 6 Metodologıa

Figura 6-41: Vista de registro de doctores (Fuente: Elaboracion propia)

• Specificpacient: Esta vista es muy similar a Applicationpanel, sin embargo,

no permite seleccionar a diferentes pacientes para visualizar sus muestras.

Por medio de esta vista se le permite al cuidador de un paciente revisar sus

respectivas muestras en caso de recibir una alerta por anomalıa cardiaca vıa

correo electronico.

Figura 6-42: Vista de muestra de paciente especifico para cuidadores

Vista de notificaciones

• Alerta: Esta vista fue disenada para ser enviada como contenido del correo

de alerta enviado a los cuidadores de los pacientes, dentro de esta vista se

encuentra un boton que al ser pulsado redirecciona al cuidador a la vista de

specificpacient.


Figura 6-43: Vista enviada en el correo de notificacion de anomalia (Fuente: Elaboracion

propia)

6. Rutas de la interfaz web: En la carpeta Routes se asignaron las diferentes URL’s

de la interfaz web que gestionan las peticiones tanto de la interfaz movil como de la

aplicacion web hacia framework de Laravel. En total fue necesario asignar 17 URL’s

para el funcionamiento integro de la red.

Figura 6-44: Asignacion de URL’s de la red (Fuente: Elaboracion propia)

7. Configuracion de red del framework: Por medio del archivo .env se realizaron

todas las configuraciones necesarias para el correcto funcionamiento de la interfaz web

y por tanto de la red de comunicacion con la base de datos remota. En este archivo fue

66 6 Metodologıa

configurada la direccion IP del servidor remoto, la asignacion del dominio equivalente

a la direccion IP asignada, los datos de conexion con la base de datos ası como las

credenciales necesarias para el acceso.

Figura 6-45: Archivo de configuracion de red (Fuente: Elaboracion propia)

6.4. Pruebas de calidad y control (Fase 4)

Para la fase final del proyecto se realizaran pruebas del funcionamiento individual e integro

de todas las fases desarrolladas previamente.

En este capıtulo, se exponen las pruebas realizadas en cada fase del proyecto, y tambien

de todo el proyecto en conjunto. Tambien, se analizaron los resultados que se obtuvieron de

estas pruebas para verificar el cumplimiento de cada uno de los objetivos propuestos al inicio

del proyecto de grado.

6.4.1. Variables a evaluar

Las redes de comunicacion actualmente son disenadas de modo que estas puedan proporcio-

nar un servicio que realice el mejor “esfuerzo” en la entrega de paquetes, con base a esto,

la evaluacion del funcionamiento del proyecto se realizo teniendo en cuenta como factor mas

importante la calidad de servicio (QoS) que presente la red de comunicacion, tieniendo asi

un conjunto de requisitos que la red debe cumplir para garantizar un buen rendimiento pro-

medio visto por el usuario de la red. Para esto, respecto a la calidad de servicio se tuvieron

en cuenta las siguientes variables:

6.4 Pruebas de calidad y control (Fase 4) 67

Comunicacion Bluetooth

Potencia de la senal:

Medicion de la potencia de la senal entregada por el modulo Bluetooth en dBm, con base

a diferentes distancias, los valores recomendados de potencia para una conexion fiable estan

entre -20dBm y -90 dBm.

Distancia:

Se hicieron pruebas con el dispositivo transmisor de corto alcance para determinar la maxima

separacion que puede tener este con el telefono celular manteniendo una conexion fiable.

Retardo:

Se calculo el tiempo de mas que tarda una muestra de diez segundos en ser enviada.

Jitter:

Cada muestra puede llegar a su destino con diferentes valores de retardo, por esto, se tuvo

en cuenta la variabilidad que tiene el retardo de cada muestra con respecto al promedio de

todas ellas para tener un valor de Jitter.

Perdida de paquetes:

Se hicieron pruebas para determinar si hubo perdida de informacion durante los muestreos

transmitidos, este valor se muestra de forma porcentual con respecto al total de paquetes

enviados.

Comunicacion TCP/IP

Retardo:

Medicion del tiempo que toma cada muestra en transmitirse desde la aplicacion movil hasta

la base de datos de la interfaz web, este tiempo puede variar del ancho de banda y la latencia

de la conexion a Internet a la que este conectado el telefono celular.

Ancho de banda de la red:

Este valor indica la velocidad maxima a la que puede se puede transmitir, el valor que es

relevante en este caso es el ancho de banda de subida.

68 6 Metodologıa

Latencia de la red:

El tiempo que se tarda en transmitir un paquete, es decir la inmediatez del establecimiento

completo de la conexion.

6.4.2. Pruebas realizadas

Prueba de potencia de la senal Bluetooth

En esta prueba se obtuvo la potencia que entrega el modulo Bluetooth utilizado en el dispo-

sitivo transmisor de corto alcance, en diferentes distancias, para esto se utilizo la aplicacion

de Android “Bluetooth signal meter”, el cual muestra el valor en dBm de todos los dispositi-

vos Bluetooth cercanos. Los resultados obtenidos de esta prueba se muestran en la siguiente

tabla:

Figura 6-46: Resultados de los valores de potencia a diferentes distancias. (Fuente: Elabo-

racion propia)

Prueba de distancia Bluetooth

En esta prueba se realizo el envio de diez muestras desde el dispositivo transmisor de corto

alcance a la aplicacion movil para observar los valores de retardos y perdidas de paquetes

que ocurren a diferentes distancias.


Figura 6-47: Interfaz de la aplicacion con valores de retardo y perdidas (Fuente: Elaboracion

propia)

Prueba a 0 metros

Los resultados obtenidos de esta prueba se muestran en la siguiente tabla:

Figura 6-48: Resultados obtenidos a 0m de distancia (Fuente: Elaboracion propia)

Prueba a 5 metros


70 6 Metodologıa


Prueba a 10 metros




Promedio de perdida de paquetes

Se calculo el promedio de perdida de paquetes respecto a la distancia de transmision, obte-

niendo los siguientes resultados:

Figura 6-51: Promedio de perdida de paquetes (Fuente: Elaboracion propia)

Prueba de retardo en el servidor

En esta prueba se realizo el envio de diez muestras desde la aplicacion movil a las bases de

datos de la interfaz web para observar los valores de retardos que ocurren con diferentes tipos

de conexiones a internet. Tambien, para cada prueba se hicieron pings al servidor donde esta

alojada la interfaz web para determinar la latencia de la conexion y medidores de ancho de

banda.

Prueba con conexion Wi-Fi

Los resultados de los pings realizados arrojaron una latencia de 184mS. El ancho de banda

de esta conexion a internet en subida es de 132,98 Mbps


72 6 Metodologıa


Prueba con conexion 3G

Los resultados de los pings realizados arrojaron una latencia de 214 mS. El ancho de banda

de esta conexion a internet en subida es de 1,22 Mbps




Prueba con conexion 4G

Los resultados de los pings realizados arrojaron una latencia de 114 mS. El ancho de banda

de esta conexion a internet en subida es de 4,08Mbps



Promedio de retardo en la transmision TCP/IP

Se calculo el promedio de retardo de la transmision TCP/IP segun el metodo de transmision

utilizado. Obteniendo los siguientes resultados:

74 6 Metodologıa

Figura 6-55: Promedio de retardo en la transmision TCP/IP (Fuente: Elaboracion propia)

7 Analisis de resultados

7.1. Prueba de potencia de la senal Bluetooth

Con base a la prueba realizada al modulo Bluetooth para determinar los niveles de potencia

que entrega a diferentes distancias, se observa que el rango optimo para garantizar un buen

funcionamiento esta entre los cero y ocho metros. A una distancia mas alta la potencia de

la senal oscila con valores mas bajos a -90 dBm (1 pW) lo cual es una senal muy debil que

generara cortes en la comunicacion con el telefono celular.

7.2. Prueba de distancia Bluetooth

Podemos observar que la perdida de paquetes en la transmision a corto alcance basada en

el protocolo de transmision Bluetooth no supera el 1 % de perdidas independiente de la dis-

tancia a la que se encuentre el transmisor de la interfaz movil. Por otro lado, vale la pena

recordar que existe un tiempo de muestreo muerto mientras la bandera de detencion enviada

por la aplicacion movil es recibida por el dispositivo transmisor de corto alcance, en este

tiempo muerto se envıan muestras que la interfaz movil ya no procesa y estos son tenidos

en cuenta como paquetes perdidos, sin embargo no hacen parte de los datos requeridos de

la senal cardiaca del paciente.

Respecto al retardo presentado en la transmision de datos a corto alcance, podemos ob-

servar que se encuentra en un rango de entre 300 ms y 400ms, teniendo en cuenta el numero

de muestras transmitido (3000 muestras), no afecta la usabilidad de la interfaz movil al

momento de la traficacion y retransmision de datos hacia la base de datos remota.

7.3. Prueba de retardo en el servidor

Respecto al promedio sobre el retardo obtenido y el retardo en la transmision de datos sobre

la senal Bluetooth, podemos observar que este es comparativamente mas alto, alrededor de

un 571 % mas alto, sin embargo esto es justificable puesto que el protocolo de transmision

TCP/IP utiliza encabezados de paquetes mas grandes que los utilizados en la transmision

Bluetooth, ademas, la distancia que tienen que recorrer los paquetes es (en general), mas

grande que la recorrida por la transmision Bluetooth. El retardo no afecta la usabilidad de

76 7 Analisis de resultados

la interfaz web puesto que para los doctores (usuarios principales de la interfaz) no sera

perceptible teniendo en cuenta que se encuentran en una ubicacion remota respecto a los

pacientes.

7.4. Analisis general

Sumando el retardo promedio proveniente del dispositivo transmisor de corto alcance y el

retardo proveniente de la transmision de datos de la interfaz movil hacia la base de datos

remota, se encuentra que el retardo total de transmision de datos se encuentra entre un

rango de 2500 ms a 2800 ms, independiente de la distancia de la transmision Bluetooth y

del metodo de transmision TCP/IP utilizados. Este retardo es insignificante para el objetivo

de uso del proyecto puesto que lo que se pretende es el monitoreo efectivo de los pacientes

y un retardo de unos cuantos miles de milisegundos no es comparable respecto al rango de

respuesta de lso doctores ante alertas sobre anomalıas.

La perdida de datos esta dentro de los parametros aceptados de calidad de servicio, ademas,

este es mucho menor que el maximo permitido, por lo tanto, la perdida de datos percibi-

da en la red es insignificante respecto a los intereses de visualizacion y analisis de la senal

electrocardiografica.

8 Conclusiones

Debido a que este proyecto no incluye al dispositivo recolector de la senal cardiaca, no fue

posible realizar un gran numero de pruebas y de esta manera generalizar los resultados ob-

tenidos del proyecto. Sin embargo, se utilizo el modulo AD-8232, para obtener resultados

concluyentes que permitan dar un indicio al funcionamiento de la red de comunicacion y que

esta se encuentre dentro del rango de parametros adecuados de calidad de servicio.

Respecto al funcionamiento del transmisor de corto alcance se cumplio el objetivo de diseno

e implementacion del dispositivo, tomando como base el funcionamiento de la transmision

periodica de datos por Bluetooth, en la que se obtuvo una perdida de datos menor al 1 %,

sin embargo, los valores de retardo obtenidos presentan fluctuaciones (Jitter) debido a que

los datos son enviados inmediatamente una vez recolectados en vez de ser guardados en

un buffer para un envıo masivo. Sin embargo, la calidad de servicio vista por el usuario se

mantiene dentro de los parametros adecuados.

Con base en los resultados obtenidos en las pruebas sobre la interfaz web se logro con

exito la recepcion de datos desde el transmisor de corto alcance, ası como la transmision a

la interfaz web por medio del protocolo TCP/IP en una unica peticion al servidor remoto.

Se logro un envio de cada una de las muestras en un intervalo no mayor de tres segundo

desde su recoleccion hasta su almacenamiento en la base de datos. Por otro lado, el metodo

utilizado para la deteccion del ritmo cardiaco no es muy exacta, debido a que el intervalo de

cada paquete de muestras es de 10 segundos.

Se logro el almacenamiento de los paquetes de muestras en la base de datos remota de

la interfaz web, discriminando cada una de estas por paciente y por hora de recoleccion,

respecto al analisis de las muestras se logro el envio de alertas vıa correo electronico al cui-

dador, gracias a esto el cuidador puede tener un control dinamico y permanente del paciente

y ası poder actuar de manera oportuna ante alguna anomalıa notificada. Sin embargo, esta

notificacion es recibida por el cuidador en un lapso dependiente del proveedor de correo

electronico de dicho sujeto.

9 Trabajos futuros

En este proyecto se sientan las bases para la implementacion integra de una red de analisis

de estado de pacientes, aportando ası con el desarrollo tecnologico de la telemedicina. Los

trabajos propuestos a continuacion se dividen en sub proyectos que mejoran cada una de las

fases de este proyecto.

Respecto al dispositivo transmisor de corto alcance (fase 1), se propone la recoleccion y trans-

mision de otras variables de los pacientes, de esta manera se busca facilitar un diagnostico

acertado por parte de los doctores. Algunas variables que considerar son: La temperatura,

el nivel de oxıgeno en la sangre y la velocidad de desplazamiento.

Respecto a la interfaz para dispositivos moviles (fase 2), se propone la adecuacion del codigo

logico implementado para dispositivos basados en sistema operativo Android para su imple-

mentacion en otros dispositivos basados en otros sistemas operativos como: iOS, Windows

Phone, Symbian (entre otros). Aumentando la accesibilidad general del proyecto. Tambien

se propone la implementacion de un panel de registro de muestras en a interfaz movil, con

el objetivo de poder acceder a resultados de las variables capturadas de forma local.

Respecto a la interfaz web (fase 3), se propone la mayor cantidad de trabajos futuros ya

que por medio de esta y de ser correctamente mejorada se lograra el mayor impacto en el

uso de nuevas tecnologıas para la salud. Se propone un mayor analisis de las muestras cap-

turadas de la senal ECG desde la interfaz movil, ya que con el procesamiento analıtico de

estas muestras se pueden alertar mas anomalıas cardiacas presentes en el paciente. Ademas,

se propone la integracion de un nuevo banco de datos en el cual se incluyan los antecedentes

clınicos del paciente. Finalmente, se propone la implementacion de un modo de uso Offline,

en el cual los doctores no requieran acceso internet para acceder a la informacion capturada

de sus pacientes, con el objetivo de tener acceso permanente a la informacion independien-

temente del estado de la red de datos.

Respecto a la red de comunicacion se propone la implementacion de metodos de trans-

mision complementarios tanto en la fase 1 (Bluetooth) como en la fase 2 (TCP/IP), que

permitan la transmision de datos a traves de multiples canales de comunicacion en caso del

mal funcionamiento de algun otro metodo utilizado, o simplemente de la falta de disponi-

bilidad en el contexto donde se este utilizando la red de comunicacion. Se busca con esta

79

propuesta aumentar el alcance de la red en diferentes pacientes.

Bibliografıa

[1] Analisis de situacion de salud (ASIS), Colombia,

2016 - Direccion de epidemiologia y demografia:

https://www.minsalud.gov.co/sites/rid/Lists/BibliotecaDigital/RIDE/VS/ED/PSP/asis-

colombia-2016.pdf.

[2] Centro de prevencion cardiovascular, Funcion Clinica Shaio:

https://www.shaio.org/centro-de-prevenci

[3] El modelo OSI,2009 - Universidad Nacional

del Centro de la Provincia de Buenos Aires

http://www.exa.unicen.edu.ar/catedras/comdat1/material/ElmodeloOSI.pdf

[4] Protocolo internet, IBM Knowladge Center

[5] Fundamentos de QoS,2016 Gustavo Salazar - CISCO

https://supportforums.cisco.com/t5/routing-y-switching-blogs/fundamentos-de-qos-

calidad-de-servicio-en-capa-2-y-capa-3/ba-p/3103715

[6] ¿What is Bluetooth?, 2004 - Patricia McDermott-Wells

http://ieeexplore.ieee.org.bdigital.udistrital.edu.co:8080/document/1368913/

[7] Estudio comparativo e implementacion de tecnologıas inalambricas para

plataforma robotica en el grupo de investigacion roma., 2016 - Gloria

Alicia Beltran Villalobos y Andres Felipe Bonilla Cortes.

Monografıa para optar el tıtulo de ingeniero en telecomunicaciones - Universidad Distri-

tal Francisco Jose de Caldas

[8] QoS Aware Bluetooth Middleware., 2006 - Ural Mutulu, Rouben Ed-

wards, Paul Coulton.

Department ofCommunication Systems, InfoLab, Lancaster University, Lancaster, UK

[9] IEEE standard glossary of software engineering terminology - IEEE

Std 610.12-1990

[10] Software application to prevent suicides of farmers with asp.net MVC,

2016 - A.Yaganteeswarudu - Vishnu Vardhan Y - Bangalore, Karnataka,

India - IEEE

Bibliografıa 81

[11] El lenguaje de Programacion Java, 1997 Sun Microsystems Inc.

[12] User Guide for Android Studio, 2017 Android Developers

https://developer.android.com/studio/intro/index.html?hl

[13] Google Play Help, 2017

https://support.google.com/googleplay/#topic=3364260

[14] W3C standard, web desiggn and applications HTML and CSS, 2016

https://www.w3.org/standards/webdesign/htmlcss

[15] W3C standard, web desiggn and applications JavaScript, 2016

https://www.w3.org/standards/webdesign/script.html

[16] ¿What is PHP?, 2017

http://php.net/manual/en/intro-whatis.php

[17] Laravel introduction, 2017

https://laravel.com/docs/4.2/introduction

[18] A portable ECG monitoring device with Bluetoothand Holter capabili-

ties for telemedicine applications, 2006 -Daniel Lucani, Student Member,

IEEE, Giancarlos Cataldo, Student Member, IEEE, Julio Cruz, Guiller-

mo Villegas, and Sara Wong

[19] Smart Detection and Transmission of Abnormalitiesin ECG Via Blue-

tooth, 2016 - Pavani Lakshmi Penmatsa, Dr. D.V. Rama Koti Reddy - Dept.

of EIE, VNR VJIET, IEEE International Conference on Smart Cloud

[20] Estudio Holter de tranmision inlambrica, 2017 - Alexis Augoustis, Ariel

Benkel, Juan Jose Pose https://bibliotecas.ort.edu.uy/bibid/85425/file/3838

[21] El proceso de la investigacion, 2003 - Mario Tama-

yo y Tamayo https://clea.edu.mx/biblioteca/Tamayo %20Mario %20-

%20El %20Proceso %20De %20La %20Investigacion %20Cientifica.pdf

82 Bibliografıa

Bibliografıa

Desarrollo de una red de comunicaci on para la transmisi on de...

Documents

Transcript of Desarrollo de una red de comunicaci on para la transmisi on de...