Documentos de Académico
Documentos de Profesional
Documentos de Cultura
corporal
8 de enero de 2020
Resumen
1. Introducción 9
1.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.1. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.2. Objetivos Particulares . . . . . . . . . . . . . . . . . . . . 12
1.5. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Marco Teórico 25
3.1. Internet de las cosas . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1. Capa de sensado . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2. Sistemas cloud . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2. Monitoreo de salud . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4. Metodología y Desarrollo 32
4.1. Entorno IoT para BSN y Domótica . . . . . . . . . . . . . . . . 32
4.2. Red de Sensores Corporal. BSN . . . . . . . . . . . . . . . . . . . 33
4.3. Bases de datos de señales fisiológicas . . . . . . . . . . . . . . . . 34
4.4. Limitaciones del sistema . . . . . . . . . . . . . . . . . . . . . . . 36
1
5. Diseño y Arquitectura del sistema 37
5.1. Arquitectura para entorno IoT . . . . . . . . . . . . . . . . . . . 37
5.2. Diseño de las capas . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.1. Capa:Red de sensores corporal . . . . . . . . . . . . . . . 38
5.2.2. Capa: Servidor en la nube . . . . . . . . . . . . . . . . . . 41
5.2.3. Proceso de Normalización de la Base de Datos . . . . . . 45
5.2.4. Detección de arritmias y taquicardias . . . . . . . . . . . 45
5.2.5. Sistema domótico . . . . . . . . . . . . . . . . . . . . . . . 45
5.3. Desarrollo preliminar . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.1. Modulo Cloud . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.2. Módulo de detección de arritmias y taquicardias . . . . . 50
5.3.3. Capa domótica: Envío de mensaje SMS . . . . . . . . . . 53
5.4. Capa o Módulo BSN . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.5. Detección de arritmimias y fibrilación ventricular . . . . . . . . . 55
5.6. Servidor en la nube . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.6.1. Persistencia de datos . . . . . . . . . . . . . . . . . . . . . 58
5.6.2. Servidor Web con reglas de negocio . . . . . . . . . . . . . 60
5.6.3. Algoritmo de detección de arritmias y taquicardias . . . . 66
5.6.4. Despliegue en Servidor de la Nube . . . . . . . . . . . . . 71
5.7. Módulo domótico . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6. Pruebas y resultados 76
6.1. Red de sensores corporal . . . . . . . . . . . . . . . . . . . . . . . 76
6.1.1. Verificación de validez matemática . . . . . . . . . . . . . 76
6.1.2. Pruebas de conectividad hacia módulo en la nube . . . . . 78
6.2. Extracción de características y red neuronal . . . . . . . . . . . . 81
6.2.1. Pruebas de éxito de clasificación . . . . . . . . . . . . . . 82
6.2.2. Pruebas de instanciación de red neuronal . . . . . . . . . 83
6.2.3. Pruebas de generación de acciones . . . . . . . . . . . . . 83
6.3. Sistema en la nube . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.3.1. Pruebas de comportamiento de operaciones CRUD . . . . 84
6.3.2. Prueba de acceso . . . . . . . . . . . . . . . . . . . . . . . 85
6.4. Sistema domótico . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.5. Pruebas integrales . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7. Conclusiones 98
2
Índice de figuras
3
5.12. Datos adicionales presentes en registro de señal ECG de la base
de datos nsrdb. Estos datos aportan información adicional acerca
de la señal misma. En este caso específico podemos ver el campo
’comments’ con un valor ’32 M’, lo cual indica que esta señal ECG
pertenece a una persona de sexo masulino de 32 años de edad. . 52
5.13. Código HTML generado por una etiqueta de token crsf. Este nú-
mero representa el número aleatorio generado para el usuario que
ha iniciado sesión después de habérsele añadido una sal igualmen-
te aleatoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.14. Protocolo de clasificación de señales electrocardiográficas, este
proceso asume que la red neuronal ya ha sido entrenada. . . . . . 57
5.15. Diagrama de red neuronal tomada como base . . . . . . . . . . . 58
5.16. Modelos Django que son mapeados a la base de datos. En este
diagrama los atributos de los modelos han sido expresados como
tipos de dato nativos de Python y Django. . . . . . . . . . . . . . 59
5.17. Captura de pantalla de la página de inicio de la página del servi-
dor web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.18. Misma vista que la figura 5.17, sin embargo, esta vez mostrando
la información desde una vista de administración. . . . . . . . . . 63
5.19. Misma vista que la figura 5.17 pero mostrando la información
como un objeto JSON. Esta vez la página de inicio solamente
muestra las direcciones de los directorios mediante las urls donde
se localizan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.20. Directorio Personas visto desde una plantilla HTML. Gracias a
la naturaleza iterativa de Vue es posible reutilizar componentes
HTML mostrando información de distintas personas mediante el
mismo componente HTML. . . . . . . . . . . . . . . . . . . . . . 64
5.21. Misma vista que la figura 5.20, sin embargo, esta vez mostrando
la información desde una vista API. . . . . . . . . . . . . . . . . 65
5.22. Misma vista que la figura 5.20 pero mostrando la información
como un objeto JSON. . . . . . . . . . . . . . . . . . . . . . . . . 65
5.23. Vista detallada de un registro del directorio de persona. Esta
misma vista permite la edición de los campos de dicho registro. . 65
5.24. Vista JSON de un objeto del directorio Personas. Aunque esta
vista es accesada desde la misma dirección URL que la figura
5.23 no provee métodos de edición. . . . . . . . . . . . . . . . . . 65
5.25. Vista API del registro de la figura 5.23. Esta vista ofrece métodos
de edición a dicho registro. . . . . . . . . . . . . . . . . . . . . . 66
5.26. Diez muestras aleatorias superpuestas del registro 18177 de la
base de datos nsrdb. Como se puede apreciar, es una ventana de
muestreo demasiado corta. . . . . . . . . . . . . . . . . . . . . . . 67
5.27. Diez muestras aleatorias superpuestas del registro 18177 de la
base de datos nsrdb. Como se puede apreciar, esta ventana tiene
el largo suficiente para incluir información relevante. . . . . . . . 68
4
5.28. Diez muestras aleatorias superpuestas del registro cu01 de la base
de datos cudb. Esta ventana no muestra los datos suficientes para
hacer una clasificación adecuada. . . . . . . . . . . . . . . . . . . 68
5.29. Diez muestras aleatorias superpuestas del registro cu01 de la base
de datos cudb. Como se puede apreciar, esta ventana tiene el largo
suficiente para incluir información relevante. . . . . . . . . . . . . 69
5.30. Señales P, Q, R, S y T detectadas en un latido de ritmo sinusal
normal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.31. Inicio de señales P y Q y final de señales S, P y T indicado sobre
una señal que presenta ritmo sinusal normal. . . . . . . . . . . . 70
5.32. Directorio con señales registradas. Con el uso del entorno Vue se
puede reutilizar el elemento HTML que muestra señales ECG. . . 71
5.33. Directorio de señales accesado desde dos diferentes tipos de vista,
la vista en formaton JSON y en versión API. Se puede apreciar
que desde un punto de vista lógico, ambas vistas despliegan una
lista de datos llamada senal_list. . . . . . . . . . . . . . . . . . . 72
5.34. Representación JSON de un registro de acción en la base de datos. 73
5.35. Mensaje recibido mediante el módulo GSM controlado a través
de la tablilla Arduino. . . . . . . . . . . . . . . . . . . . . . . . . 74
5
6.7. Resultado de una prueba de clasificación impreso en consola, es-
to muestra que la clase está siendo correctamente instanciada y
ejecutada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.8. Señal que presenta taquicardia (arriba) y el registro de acción
generado a partir de su clasificación (abajo). . . . . . . . . . . . . 83
6.9. Señal que presenta fibrilación (arriba) y el registro de acción gene-
rado a partir de su clasificación (abajo). En este caso en específico,
la señal no necesita de una plantilla de texto para su ejecución,
debido a que representa una activación de alerta luminosa. . . . . 84
6.10. Respuesta de los directorios ante la creación de un nuevo regis-
tro. Como se puede apreciar todos los directorios devuelven una
respuesta HTTP que contiene el objeto en formato JSON del
registro recién generado. . . . . . . . . . . . . . . . . . . . . . . . 85
6.11. Actualización de un dispositivo mediante plantilla HTML. En
orden descendente, podemos ver primero el estado original del
dispositivo desde el directorio de Dispositivos, seguido de la vista
detallada del registro mismo, el cual cuenta con ’UUID’ y ’es-
tado’ como datos editables siento ’Apagado’ su estado original.
Después, en la tercera casilla, el nuevo estado del dispositivo,
específicamente ’Encendido’. Finalmente, en la cuarta casilla, se
aprecia el registro modificado en el directorio de Dispositivos. . . 86
6.12. Eliminación de datos de una acción de prueba mediante vista
API. Como se puede apreciar Django provee un dialogo de ad-
vertencia que impide borrar datos por error. De igual manera,
después de la eliminación se recibe una respuesta HTTP con có-
digo 204 el cual significa ’No hay contenido’. . . . . . . . . . . . . 87
6.13. Intento de acceso a datos de una cuenta ajena desde una cuenta de
usuario. En la primer figura, arriba, podemos apreciar los detalles
de edición de un registro de señal que son mostrados a la cuenta
que creó dicho registro. En la segunda imagen, abajo, podemos
ver la respuesta HTTP del servidor, la cual está compuesta por
un código HTTP 404 el cuál indica que el contenido solicitado
’No fue encontrado’. . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.14. Datos en formato JSON obtenidos al realizar una consulta al
directorio de acciones después de haber realizado un inicio de
sesión de forma programática. . . . . . . . . . . . . . . . . . . . . 89
6.15. Datos de acción de prueba para envío de SMS (arriba), así como
el mensaje de texto recibido en el teléfono provisto (abajo). . . . 90
6.16. Datos de registro de acción de prueba para envío de aviso por
luminosidad (arriba), así como el foco de prueba siendo encendido
(abajo). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.17. Registro de señal generada en la base de datos junto con marca
de tiempo señalada. Esta señal presenta ritmo sinusal normal. . . 92
6.18. Registro de señal con ritmo sinusal normal generado en la base
de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6
6.19. Directorio de acciones vacío después del registro de una señal con
ritmo sinusal normal. . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.20. Registro de señal que presenta taquicardia generado en la base
de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.21. Registro de acción generado después de la detección de una señal
que presenta taquicardia. . . . . . . . . . . . . . . . . . . . . . . 93
6.22. Información consultada por el sistema domótico. Como se puede
apreciar esta información está condensada en un objeto JSON,
el cual llega como texto plano al sistema domótico gracias a la
plantilla JSON provista por el entorno de desarrollo de Django
REST. En esta imagen se aprecian dos tipos de acciones sien-
do consultadas. Para esta prueba se utilizó el primer registro,
un registro de acción generado por la creación de una señal que
presenta taquicardia. . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.23. Mensaje de texto recibido en el número de teléfono celular regis-
trado para una persona de confianza del usuario que registró la
señal con taquicardia. . . . . . . . . . . . . . . . . . . . . . . . . 95
6.24. Registro de señal que presenta fibrilación ventricular generado en
la base de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.25. Registro de acción generado después e la detección de una señal
que presenta fibrilación ventricular. En este caso la acción no
cuenta con título o plantilla debido a que el sistema domótico la
interpreta como activación de alerta luminosa. . . . . . . . . . . . 96
6.26. Información consultada por el sistema domótico. Como se puede
apreciar esta información está condensada en un objeto JSON,
el cual llega como texto plano al sistema domótico gracias a la
plantilla JSON provista por el entorno de desarrollo de Django
REST. En esta imagen se aprecian dos tipos de acciones sien-
do consultadas. Para esta prueba se utilizó el primer registro,
un registro de acción generado por la creación de una señal que
presenta fibrilación. . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.27. Activación intermitente de de una fuente luminosa debido a la
detección de fibrilación ventricular. . . . . . . . . . . . . . . . . . 97
7
Índice de cuadros
8
Capítulo 1
Introducción
1.1. Generalidades
El desarrollo de la tecnología durante las décadas pasadas ha ido inclinán-
dose hacia las tecnologías IoT (Internet of Things) (Ashton 2009) las cuales
están enfocadas en la interconexión en red de distintos dispositivos, desde elec-
trodomésticos hasta dispositivos de uso personal. Como se aprecia en la figura
1.1 esta tecnología ha sido considerada por una de las principales empresas de
análisis de tendencias tecnológicas como una de las tecnologías emergentes que
más expectativa está generando expectativa, aunque no como tecnología inde-
pendiente, sino de forma integral como plataforma IoT. Esto quiere decir que
las tecnologías IoT ya son vistas como un conjunto, no como una aplicación o
implementación de alguna tecnología específica. Una de las áreas que suelen ser
consideradas dentro de las tecnologías IoT es la domótica, la cual es un área
enfocada principalmente en la automatización y monitoreo del hogar o espacio
físico mediante distintos actuadores y sensores. Actualmente esta área suele ser
considerada como intrínseca a los sistema IoT por algunos autores (Luigi Atzori
y col. 2010; Luigi Atzori y col. 2017; Al-Fuqaha y col. 2015; Li y col. 2015; Mio-
randi y col. 2012), sin embargo, aún no existe realmente una opinión decisiva al
respecto. Por otra parte, las redes de sensores son aceptadas de forma unánime
como un componente de los sistemas IoT. Mismos autores ofrecen diferentes
opiniones respecto a lo que el término Internet de las cosas engloba, sin embar-
go, se pueden denotar tres áreas presentes en la mayoría de las arquitecturas
IoT analizadas en este estado del arte: Redes de sensores, Cómputo en la nube
y Big Data. Estas tres áreas caracterizan las generaciones de esta tecnología, las
redes de sensores son la primer generación, el cómputo en la nube es la segunda
generación y el Big Data representa la tercer generación. Las redes de sensores
presentan una forma de adquirir datos de forma directa y transmitirlos a dispo-
sitivos donde se puedan administrar. El cómputo en la nube permite manejar
y procesar la gran cantidad de información generada por las redes de senso-
res. Finalmente, la inclusión de Big Data permite realizar análisis exhaustivos
9
Figura 1.1: Gráfica de las tecnologías que generaron expectativa en el año 2017
según la empresa Gartner.
10
sobre la información generada, así como detectar patrones y realizar posibles
predicciones sobre los datos obtenidos. Actualmente Los entornos IoT han evo-
lucionado de forma que sus tareas no consisten únicamente en la automatización
y la conectividad, sino en dotarlos de inteligencia (e.g. que reaccione ante ciertos
eventos). Este trabajo aborda este enfoque basado en un entorno IoT.
1.2. Problemática
Un entorno IoT es interdisciplinario por naturaleza, donde convergen líneas
de investigación de computo y comunicaciones, de salud y en el contexto de
casas conectadas y domóticas. En este trabajo se describe la interoperación de
las mismas, usando una red de sensores corporales (BSN) para monitoreo de
signos fisiológicos , en un ambiente de Computo en la Nube y con enfoque do-
mótico. Se abordan tres probelmaticas : 1.- en la BSN desde la perspectiva de
conocer el consumo energético (desempeño de la red). 2.- Monitoreo de perso-
nas y activacion de alertas al detectar anomalias en una señal fisiologica, En
especifico, se centro en el escenario de una persona que presente riesgo de sufrir
algún padecimiento cardiacom la cual es monitoreada constantemente ( por una
BSN) y por periodos largos. La problematica surge cuando se requiere poder
reaccionar frente a algún episodio cardiaco (e.g. arritmia) que permita recibir
atención inmediata o solicitarla ( e.g. mensajes o activacion de alarmas sono-
ras o de luminosidad. La aportación principal de este trabajo es el diseño de
conectividad e interoperatividad con una arquitectura de servicios web entre
diferentes elementos domóticos y una red de sensores corporal, lo cual vive en
conjunto en un entorno IoT. Esta infraestructura representa el aporte principal
de este proyecto.
1.3. Hipótesis
La hipótesis que sustenta este trabajo es que es posible crear un sistema que
obtenga datos de señales fisiológicas de una persona, que estos sean monitorea-
dos y analizados, para detectar anomalias, y en caso de existir entonces activar
mecanismos de atencion a traves de mensajeria y alertas usando protocolos de
comunicacion en un entorno IoT.
11
análisis del monitoreo de las señales fisiológicas, asi como la conectividad con un
sistema domótico. Lo cual es otra de las aportaciones de este proyecto, la imple-
mentación del paradigma IoT enfocado a monitoreo de salud con una respuesta
directa ante el evento.
1.4. Objetivos
1.4.1. Objetivo General
Diseño de sistema domótico en un entorno IoT con comunicación a una red
de sensores corporal(BSN) para el monitoreo de señales cardiacas e identificación
de anomalías en dichas señales usando redes neuronales.
1.5. Justificación
En la actualidad existen distintos intentos por integrar las tecnologías IoT a
plataformas centradas en redes de sensores (Giancarlo Fortino, Di Fatta y col.
2014; Wan y col. 2013). Sin embargo, estos esfuerzos nunca logran una imple-
mentación completa de todos los aspectos que identifican un sistema IoT de
acuerdo a los aspectos mencionados previamente. Esto debido a que dichos pro-
yectos no lo contemplan dentro de sus objetivos o se valen de otras tecnologías
para cumplir objetivos similares.
Por otra parte, existe plataformas de cómputo disponibles que ofrecen ser-
vicios para sistemas IoT o domóticos, pero no dejan de ser ”cajas negras” ya
que no esta disponible la respuesta al como realizan el servicio. Por ejemplo, el
servicio ’AWS IoT 1-Click’ permite que dispositivos sencillos ejecuten funciones
lambda que permiten ejecutar una acción como enviar notificaciones al soporte
técnico, realizar el seguimiento de recursos y reponer bienes o servicios; el cual
puede ser visto como una implementación de un sistema IoT, en menor escala,
pero enfocada a solo el envío de mensajes.
12
Capítulo 2
13
2.1. Redes de sensores
En el caso de las redes de sensores, estas dependen en gran medida de las
capacidades que los nodos que las componen puedan proveer, así como el obje-
tivo que dicha red de sensores pueda tener. En la actualidad se han desarrollado
nodos con capacidades orientadas a aplicaciones generales, como menciona (Na-
rayanan y col. 2016), esto permite asociar tipos de aplicaciones con las carac-
terísticas de los nodos. Por ejemplo, Consumo de energía, vida media del nodo,
capacidades de calidad de servicio (QoS) en la transmisión y capacidades de
sensado; estas son algunas de las áreas, en las que los nodos pueden especiali-
zarse y agruparse. Algunos de estos nodos, como TelosB (S.L. 2018, diciembre)
y Mica2 (C. M. Technology 2018, diciembre), han tenido relevancia a lo largo
de casi una década de desarrollo y han estado relacionados a un gran número de
desarrollos en distintas áreas de la industria privada e investigación (Narayanan
y col. 2016). Mientras que otros como iSense (Frick 2018, diciembre), Waspmote
(libelium 2018, diciembre) o Indriya (Indrion 2018, diciembre) han tenido auge
en años recientes y están enfocados en ofrecer plataformas para hacer pruebas
sobre algoritmos inherentes o enfocados en redes de sensores. En estos nodos se
tiene una tendencia arquitectónica modular, donde un procesador central regula
la información generada por los sensores del nodo y las funciones de comuni-
cación. De igual manera, en el aspecto de conectividad los principales módulos
son las familias cc1xxx y cc2xxx de transceptores de radiofrecuencia de Texas
Instruments (Instruments 2018, diciembre). la primera está enfocada en trans-
misiones de larga distancia y baja potencia, mientras que la segunda el enfoque
se encuentra en transmisiones de alta frecuencia mediante tecnología ZigBee (Z.
Alliance 2018, diciembre) y 6LowPAN (Force 2018, diciembre). Finalmente, se
puede apreciar que la mayoría de estos nodos citan la capacidad de ejecutar el
sistema operativo TinyOs, el cual es un sistema operativo de libre acceso dise-
ñado para operar en dispositivos de gama baja (Community 2018, diciembre).
Otros sistemas operativos populares son Contiki (Contiki 2018, diciembre) y
Nano-RK (Lang 2018, diciembre), los cuales, son sistemas operativos enfocados
en la optimización de recursos en dispositivos de gama baja y que se diferencian
en el manejo de eventos o los sistemas de archivos que manejan. Por otra parte,
la forma en que se transmiten los datos, tambien es tema de estudio, donde la
tecnología de identificación por radiofrecuencia (RFID) se encuentra presente
en un gran número de trabajos relativos a IoT ya que esta tecnología permite
obtener datos de forma rápida y con un consumo mínimo de recursos.
Finalmente, es pertinente mencionar los principales protocolos utilizados en
redes de sensores y redes de sensores corporales. Estos protocolos pueden ser
organizados en dos mayores categorías: acceso al medio y ruteo de información,
sin embargo, la mayoría de ellos está relacionado en cierta medida con el ahorro
energético debido a que las limitaciones de esta capa IoT exigen un uso eficiente
de recursos. Por ejemplo, diversos autores coinciden (Demirkol y col. 2006)en
que en cuanto a protocolos utilizados por las redes de sensores y dispositivos de
gama baja el conjunto de protocolos Zigbee (Z. Alliance 2018, diciembre) es el
mayormente utilizado, esto debido a que parte de la versión 2003 del estándar
14
IEEE 802.15.4 («IEEE Standard for Information Technology - Telecommuni-
cations and Information Exchange Between Systems - Local and Metropolitan
Area Networks Specific Requirements Part 15.4: Wireless Medium Access Con-
trol (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless
Personal Area Networks (LR-WPANs)» 2003) y construye protocolos especiali-
zados que permiten su uso en un amplio rango de aplicaciones. Por otra parte,
Sensor medium access control (S-MAC) y sus derivados son protocolos de acceso
al medio diseñados para WSN los cuales, por su naturaleza simple y eficiente,
han servido como base para un amplio número de estudios y desarrollos. De igual
manera existen algunas opciones de aplicaciones WSN que utilizan Bluetooth
como conjunto de protocolos de comunicación, este protocolo no es realmente
eficiente en comparación con Zigbee pero su uso extendido en otras tecnologías
ha llevado a su uso esporádico en esta área. Por otro lado, el área de las redes de
sensores corporales (BSN) que son un tipo específico de WSN, se enfocada en
redes de sensores inalámbricos desplegados sobre los cuerpos de seres humanos
con fines de monitoreo fisiológico. La mayoría de los parámetros y consideracio-
nes aplicables a las WSN, se aplican tambiñen a las BSN, por ello, la elección de
protocolos de acceso al medio realizada en capítulos posteriores. En el capítulo
3, sección 2 se habla a fondo acerca de este tema. En la actualidad el estado del
arte se ha enfocado en abordar retos como la optimización de capa física y su
acceso y calidad de servicio(QoS) en el transporte de información (Movassaghi
y col. 2014). Actualmente, los trabajos con redes de sensores, se enfocan en tres
pilares fundamentales: seguridad, recolección de energía del medio y optimiza-
ción en su implementación con otras tecnologías. En cuanto a la optimización,
se encuentran de proyectos que buscan hacer más eficiente el acceso a las ca-
pas PHY/MAC (Goursaud y Gorce 2015), Mientras que en la recolección de
energía del medio para su uso dentro de la red, hay trabajos que usan energía
solar(Visconti y col. 2017) también existen trabajos que exploran distintos ti-
pos de ataques en la red para fortalecer los esquemas de seguridad (Riaz y col.
2018). Cabe señalar que, como en cualquier otro desarrollo, la elección de pro-
tocolos de comunicación depende de muchos aspectos, siendo uno de los más
importantes la topología de la red. En el capítulo 3 se discuten las topologías de
red mayormente utilizadas en las BSN y los protocolos predominantes en dichas
topologías.
15
distintas aplicaciones. De igual manera, empresas de menor tamaño ofrecen ser-
vicios similares como los servicios de cómputo de Digital Ocean(Ocean 2018,
diciembre), OVH(Ovh 2018, diciembre), entre otras.
De hecho, existen sistemas cloud diseñados con una filosofía IoT , como Open
Source IoT Cloud(Hartman 2018, diciembre), que es un proyecto que busca ofre-
cer una nueva filosofía de implementación del paradigma IoT con la ayuda de
herramientas de uso libre. Otro sistema con este enfoque híbrido es OpenIoT, el
cual ofrece herramientas de administración de datos enfocadas entéramente en
IoT, desde Ontologías y modelos de datos semánticos hasta ”herramientas de
cómputo y almacenamiento cloud que incluyen utilidades de seguridad y priva-
cidad” (Consortium 2018, diciembre). Este paradigma que modela la estructura
del sistema cloud alrededor de la filosofía IoT puede verse como el precursor
de sistemas cloud que tienen metas con mayor amplitud como por ejemplo el
proyecto ”CCIoT-CMfg: Cloud Computing and Internet of Things-Based Cloud
Manufacturing Service System” (Tao y col. 2014) el cual propone una arquitec-
tura robusta de servicios máquina a máquina (M2M) que pretenden ofrecer a
un sistema de manufactura control y conocimiento completo sobre los recursos
disponibles y las capacidades del sistema.
Existen plataformas de paga similares a las mencionadas en esta sección rea-
lizan toda la administración IoT de los datos o que ofrecen inclusive toda la ins-
fraestructura IoT incluyendo el hardware, como KAAIOT(KaaIoT Technologies
2018, diciembre) que ofrece paquetes de cómputo y almacenamiento cloud jun-
to con administración IoT del sistema, o Artik Cloud Services(Samsung 2018a,
diciembre) que de igual manera ofrece los servicios de cómputo específicamen-
te diseñados para trabajar junto con un sistema IoT que ellos mismos ofrecen.
Además de estas plataformas de cómputo, privadas o de uso público, existen
en la actualidad diversas herramientas que permiten a sus usuarios construir
sus propios sistemas cloud. Entre estas herramientas se encuentran software
de sincronización de archivos como owncloud(ownCloud GmbH 2018, diciem-
bre) o SeaFile(Ltd 2018, diciembre), y software de virtualización como VMware
Workstation(VMWare 2018, diciembre) u Oracle VM VirtualBox(Oracle 2018,
diciembre).
16
2.4. Entornos o ambientes IoT
CloudPlugs (Inc. 2018, diciembre) es un proyecto que provee servicios de
cómputo e interpretación de datos sin proveer una red de sensores o almacena-
miento cloud, este sistema en específico ofrece una serie de servicios encapsu-
lados y herramientas que permiten utilizar sistemas de Big Data de empresas
grandes. En un enfoque diametralmente opuesto se encuentra proyectos de gran
escala como ClouT (Samsung 2018b, diciembre), el cual es una infraestructura
comleta que brinda las bases para Smart Cities, esto mediante la implementa-
ción de servicios cloud estratificados que van aumentando en complejidad según
aumenta su generalidad hasta tener un servicio completo que abarca ciudades
completas. En cuanto a investigación se refiere, en la actualidad los efuerzos se
encuentran enfocados en desarrollos específicos que buscan analizar o resolver
problemáticas específicas, por ejemplo, sistemas enfocados en proveer seguridad
a sistemas de adquisición de datos y control mediante supervisión (Sajid y col.
2016), sistemas de monitoreo de salud (Kale y Bhagwat 2018) y sistemas de
monitoreo industrial (Sanchez-Iborra y Cano 2016). Mainflux que ofrece una
arquitectura de software completa para el manejo de un sistema IoT (Mainflux
2018, diciembre) mediante software especializado para crear sistemas cloud es-
pecializados. Otro ejemplo es kinoma (Kinoma 2018, diciembre) que provee una
máquina virtual que utiliza javascript ECMA versión 6 para que dispositivos de
baja gama compartan el mismo conjunto de instrucciones que dispositivos de
gama alta o media. Un ejemplo más de herramientas IoT de uso libre es armbed
(Limited 2018, diciembre), el cual ofrece una infraestructura de software para
nodos de gama baja y les permite comunicarse de forma sencilla con sistemas
cloud.
Inclusive hay esfuerzos de algunas empresas por incentivar el desarrollo de
propuestas IoT de libre acceso, como el Open IoT Challenge 5.0 (Eclipse Foun-
dation 2018, diciembre) el cual es un concurso que ofrece un premio de más
de 5,000 USD para el ganador donde las bases requieren que los participantes
propongan proyectos IoT que utilicen completamente elementos de libre acceso.
Finalmente, es conveniente mencionar un proyecto IoT que tiene un enfoque si-
milar al caso de estudio propuesto, este es el propuesto por (Pang y Tian 2014)
en el cual se propone una arquitectura diseñada específicamente para ayudar a
personas con discapacidades, la cual es consciente del entorno en donde las per-
sonas se desenvuelven. Este sistema propone tres capas: la capa de percepción
que contiene elementos que permiten ofrecer facilidades específicas para cada
tipo de discapacidad presente, la capa de middleware que se encarga de ofrecer
comunicación de los sensores hacia el sistema cloud y la capa de procesamiento
que representa el sistema cloud, además que menciona que el siguiente paso en
el desarrollo de estas tecnologías es la creación de sistemas conscientes de su
contexto que permitan a los usuarios obtener información compleja a partir de
datos simples obtenidos de la capa de sensado. Otro proyecto importante en
el estado del arte es el propuesto por (L. Atzori y col. 2014), el cual acuña el
término Web of things. Este proyecto busca poder descubrir fácilmente objec-
tos y servicios en la red de dispositivos de baja gama mediante las ”relaciones
17
sociales” que estos entablan. Hay tres aspectos que son escenciales para tener
redes sociales entre objetos que sean similares a las que existen entre personas:
primero debe haber una definición de relación social entre objetos, después un
modelo de referencia de arquitectura de relaciones y finalmente un método de
análisis de la estructura social derivada de las interacciones mismas. Para esto
se propone una red formada por agentes que publiquen información y servicios,
y dicha red sea explorada a través de los amigos de los agentes. Esto permitiría
tener un mecanismo de descubrimiento relativamente sencillo así como un alto
grado de escalabilidad en la red.
18
vee APIs y protocolos para soportar ciertos servicios. Esta capa puede contener
los siguientes componentes:
Descubrimiento de servicios y composición de servicios. Este componente
tiene la función de permitir la interconexión de servicios y dispositivos
a partir de los datos que se obtengan del descubrimiento de servicios.
Primero se descubren los servicios y luego a partir de ellos y sus datos se
determina en este sistema o en la capa cloud cuál es el mejor para lograr
un determinado fin.
Manejo de la confianza. Este componente implementa mecanismos que
buscan determinar la credibilidad de las fuentes de información
APIs de servicio. Estas encapsulan y exponen la funcionalidad de los ser-
vicios hacia otras capas una vez descubiertos.
Capa de interfaz: Esta capa se encarga de ofrecer interfaces de comu-
nicación entre dispositivos que vienen de distintas empresas, las cuales
contienen distintos protocolos de comunicación. Para esto se necesita un
perfil de interfaz y se propone una implementación del protocolo Universal
Plug & Play(UPnP).
Como se puede ver, esta capa puede ser compleja en implementación ya que es
la encargada de homogeneizar el comportamiento de los servicios por defecto
heterogéneos, sin embargo, algunos autores mezclan esta capa con la capa de
procesamiento o capa cloud y los componentes mencionados anteriormente se
convierten en APIs de servicio remoto. Esta capa de middleware ha sido ob-
jeto de amplio estudio y han surgido propuestas robustas que buscan resolver
la mayoría de las problemáticas presentes. Algunas fuentes sugieren una arqui-
tectura integrada con la tecnología SOCRADES (Service-Oriented Cross-layer
Infrastructure for Distributed smart Embedded devices) (Gerosa y col. 2009)
el cual es un sistema que ofece una infraestructura de software para el manejo
de servicios en sistemas orientados a la manufactura. Otras fuentes sugieren el
middleware HYDRA (Jahn y col. 2009), el cual está enfocado en aplicaciones
de monitoreo de salud y expone los servicios que descubre mediante conexiones
punto a punto (P2P) a través de servicios web. Otra propuesta es la utilización
del servicio de provisión de procesos (SPP), el cual se apoya en consultas de
lenguaje de descripción de servicios web (WSDL) (W3C 2018, diciembre) para
obtener los candidatos para peticiones, los cuales se clasifican con base en el
contexto de la aplicación y la información QoS.
Finalmente la capa de servidor en la nube se encuentra presente en todos
los ejemplos literarios mencionados anteriormente. Esta capa es vital para todo
sistema IoT ya que es la que se encarga de realizar las tareas de cómputo que exi-
gen mayores recursos. Esta capa, como se mencionó al principio de esta sección
suele estar enfocada a servicios, por lo tanto, su consumo, consulta y descubri-
miento suele ser ayudado por algún lenguaje de marcado o lenguaje descriptivo,
entre estos lenguajes los más utilizados son XML, Json y WSDL que extiende de
XML. Además, esta capa suele exponer servicios mediante distintos métodos,
19
entre los cuales sobresalen el protocolo de acceso de objetos simples (SOAP)
y las transferencias de representación de estado (REST) y aunque en ámbitos
web algunos autores consideran estas tecnologías intercambiables, en entornos
IoT se considera que servicios REST que se comunican mediante objetos JSON
tiene mayor compatibilidad con sistema actuales, a tal grado que grandes em-
presas como Google han cambiado sus tecnologías de SOAP a REST (Tan y col.
2016), de hecho, en (Ben Hamida y col. 2015) hacen una comparación completa
de distintas métricas de rendimiento de distintos lenguajes de representación de
datos, siendo XML un tanto más eficiente que JSON en algunas métricas.
20
que aborde el mismo tema desde un punto de vista de actuadores domóticos,
donde la principal prioridad de la red es distribuir la información a los nodos
de forma eficiente, regularmente de forma unidireccional.
21
Figura 2.1: Ciclo de operación de un radio cognitivo convencional
22
la WBAN cuentan con la tecnología de radio cognitivo y el área de aplicación
es la telemedicina. Por ejemplo, en (Chavez-Santiago y col. 2012) se propone
una red de área corporal basada en radio cognitivo para la banda ultra ancha
(UWB, la cuál es mayor a los 500 MHz), la cual utiliza radios de impulso en los
nodos de la red. Este conjunto de tecnología provee a la red una flexibilidad en
cuanto a frecuencia se refiere y permite modificaciones al espectro del dominio
de la frecuencia, lo cual se vuelve de gran ayuda en escenarios donde dispositi-
vos similares se encuentren presentes, como podría ser un centro médico. Otro
esfuerzo importante en esta área es la utilización de la banda de 2360 a 2400
MHz para interconectar equipo médico debido a que esta banda en específico no
es generalmente utilizada en aplicaciones de MBAN (Wang y col. 2011). Esta
tecnología, como ya se mencionó, ofrece al IoT un gran número de oportunida-
des de optimización en cuanto a la BAN se refiere, sin embargo, en el caso de
estudio propuesto esta tecnología resulta sobrada puesto que el análisis de la red
tiene como principal objetivo determinar el rendimiento de la misma y, como se
discutió previamente, el radio cognitivo sacrifica muchas veces el rendimiento
de la red al permitir a usuarios secundarios el uso del canal. En los capítulos
finales de este documento se discute el trabajo futuro que pudiera incluir esta
área de conocimiento y se señalan áreas de oportunidad de crecimiento basadas
en M2M.
23
efectividad de programación, interoperabilidad dentro del sistema, usabilidad
y soporte de privacidad de información. Este trabajo, como se puede apreciar,
está enfocado mayormente hacia el área pedagógica y en él utilizan señales fi-
siológicas para hacer pruebas al sistema. Similar a este proyecto existen dos
frameworks enfocados al desarrollo de aplicaciones de sensado de señales fisio-
lógicas, estos frameworks son CodeBlue (Kambourakis y col. 2007) y SunSPOT
(M. Zhang y Sawchuk 2009) y aunque demostraron ser poderosos hace casi una
década, actualmente han sido superados por SPINE. Otro trabajo similar es el
propuesto por (Alnosayan y col. 2014), el cual busca facilitar la transición de
pacientes que hayan tenido fallas cardiacas del cuidado del hospital al cuidado
en sus hogares. Esto mediante monitoreo de señales fisiológicas y su respecti-
vo análisis mediante un sistema experto. Este sistema además retroalimenta al
usuario mediante una aplicación móvil, la cual le muestra mensajes de apoyo.
Este proyecto es de los pocos proyectos que además de cumplir con la mayoría de
las generaciones tecnológicas de los sistemas IoT busca retroalimentar al usuario
de forma activa. Otro trabajo similar es el propuesto por (Z. Zhang y Hu 2013),
en el cual se busca crear una red de monitoreo de pacientes de bajo costo de
despliegue y mantenimiento mediante el uso de una red de sensores ZigBee y
un dispositivo eWatch, el cual es un dispositivo multisensor, a través del cual
se determinan las acciones que el usuario realiza a partir del acelerómetro y el
sensor de luminosidad en el dispositivo. Este proyecto, mediante el uso de si-
mulaciones generadas en el software OPNET-ZB (open-zb.net 2018, diciembre)
demostró que la aplicación de redes de sensores y sensores corporales en clínicas
o asílos puede aportar significativas ventajas a un costo mínimo. Este proyecto,
aunque en pequeña escala, muestra una interacción directa entre dos tecnologías
de bajo nivel y un middleware común, esto es relevante pues el uso del eWatch
muestra que la retroalimentación es posible en este sistema aunque no existan
capas complejas de procesamiento. Otro proyecto notable es el propuesto por
(Gia y col. 2015) donde, al igual que este proyecto, proponen una estructura IoT
para un sistema de análisis ECG, el cuál es un sistema autocontenido que pro-
pone una segmentación amplia de la base de datos con un gateway inteligente
que permite a distintos dispostivos de distintas marcas conectarse y almacenar
información. Al igual que el presente proyecto este sistema utiliza la base de
datos (Center) 1990) para realizar pruebas en cuanto a detección de anomalías,
almacenamiento y presentación de datos. Finalmente, es pertinente mencionar el
proyecto propuesto en (Lisetti y Nasoz 2004)el cual busca reconocer emociones
mediante el análisis de distintas señales fisiológicas. los resultados reportados
muestran un porcentaje cercano a 80 % de reconocimiento exitoso de dichas
emociones, y aunque este es un proyecto de hace más de una década muestra
que la utilización de sensores corporales para la extracción de señales fisiológicas
para su posterior análisis es un tema que se ha investigado desde hace tiempo.
24
Capítulo 3
Marco Teórico
25
Figura 3.1: Ejemplo de la estructura de un sistema considerado IoT
26
Figura 3.2: Ejemplo de un sistema RFID.
a capas superiores. Para esto, se tienen las dos tecnologías principales de esta
capa: RFID y WSN.
El RFID surgió originalmente como un sustituto de los código de barras cer-
ca del año 1920 por parte del MIT (mitrfid). Los sistemas RFID funcionan con
base en etiquetas y lectores, donde los lectores transmiten señales electromag-
néticas en periodos constantes y esperan obtener una respuesta. Los sistemas
RFID pueden clasificarse en las siguientes frecuencias de operación: 30KHz a
500KHz, 3M Hz a 30M Hz y 300M Hz a 960M Hz. Inclusive existen sistemas
RFID que operan en la banda de 2,4GHz (Rouse 2018, diciembre). En la 3.2 se
muestra un diagrama que muestra un sistema RFID y sus componente princi-
pales.
La siguiente tecnología clave de la capa de sensado son las redes de sensores
inalámbricas. Estas pueden trabajar en conjunto con las tecnologías RFID para
obtener aún más información del entorno de un determinado objeto o persona.
Regularmente las redes de sensores están compuestas por un gran número de no-
dos que se comunican entre si en una estructura multisalto. Los nodos utilizados
para estas redes pueden varían ampliamente dependiendo de la aplicación que
se tenga en mente, sin embargo la mayoría de ellos comparten una arquitectura
en común.
Los parámetros de configuración de las BSN dependen enteramente de la
función que se busque cumplir. Ya sea que se cree una red con un gran número de
nodos o que se utilice un protocolo de acceso al medio. en el caso de las topologías
de red, las más utilizadas en las WSN son: estrella, red y árbol (Gutiérrez y col.
2013). Esto se debe a que en este tipo de red la información generada por los
nodos suele ser enviada enteramente al gateway.
Otro aspecto importante de las WSN son los protocolos de comunicación
utilizados. Específicamente, los protocolos de acceso al medio y ruteo son los
más estudiados en cuanto a WSN se refiere. Los protocolos de ruteo pueden
clasificarse como: protocolos centrados en datos, protocolos de ruteo jerárqui-
co, protocolos de ruteo basado en posición, protocolos de ruteo multiruta y
27
protocolos centrados en calidad de servicio (Akkaya y Younis 2005). Como su
nombre lo indica, estos protocolos están enfocados en transmitir la información
hacia el gateway de la red basándose en alguna métrica determinada, por lo
tanto su rendimiento dependerá de la naturaleza de la red misma. Por otra
parte, las redes de sensores inalámbricas corporales (WBSN), estas redes, como
el nombre lo indica están diseñadas para abarcar el área superficial del cuerpo
humano. En cuanto a implementación, las consideraciones hechas para las WSN
se mantienen, sin embargo, debido a las características del cuerpo humano, se
abren nuevas oportunidades y retos por analizar. Por ejemplo, como lo mencio-
na (Zuhra y col. 2017) los protocolos de BSN pueden ser optimizados debido a
los cambios de distancia en la superficie donde se despliega la red, así como el
menor número de nodos en la red.
28
Teniendo los servicios en mente ha surgido el concepto de arquitectura orien-
tada a servicios (SOA), la cual puede ser utilizada para encapsular la implemen-
tación de distintos componentes y así ocultar la heterogeneidad de los usuarios
finales (Al-Fuqaha y col. 2015). Por otra parte, los servicios deben adaptarse a
las condiciones cambiantes del sistema, las cuales implican movimiento o des-
activación de dispositivos o fallo de servicios. Un efectivo sistema SOA debe
minimizar las pérdidas frente a este tipo de problemas. Un ejemplo de esto es la
plataforma OSGi (Pung y col. 2004), la cual implementa una arquitectura diná-
mica y modular que permite desplegar un distinto tipo de aplicaciones mediante
el uso de software adaptable que puede modificarse en tiempo de ejecución. Otro
ejemplo, pero buscando una implementación IoT de esta arquitectura puede ser
encontrada en el software de desarrollo Apache Felix iPoJo (T. A. S. Foundation
2018, diciembre). Las implementaciones de SOA varían dependiendo del enfoque
que el proyecto busque para cumplir sus objetivos, sin embargo una constante
entre todos ellos es el encapsulamiento de comportamientos o funciones y su
exposición a otros subsistemas mediante métodos específicos.
Las integraciones de arquitecturas orientadas a servicios son necesarias de-
bido a las ventajas que ofrece la unión de las distintas tecnologías involucradas
en el IoT. De hecho en (Botta y col. 2016) se hace un listado de los nuevos
paradigmas hechos posibles gracias a la unión de tecnologías nube e IoT y de
sus características. Dichos paradigmas se pueden ver explicados en la tabla 3.1.
Como se puede apreciar, este proyecto de forma indirecta entra en algunas de
estas categorías, puesto que permite el acceso a información electrocardiográfi-
ca generada por sensores (SaaS), acceso a Base de datos de usuarios y señales
(BaaS) y sensado y actuación Domótica (SEaaS), todo esto de forma ubícua.
Y todo esto ocurre de forma incidental debido a los avances que las tecnolo-
gías web ofrecen en cuanto a la expansión de funcionalidades, específicamente
hablando, de la robustez que ofrecen las tecnologías PaaS de proveedores en la
nube (Google, Amazon, etc.) y la flexibilidad de los servidores Web (Django,
Express, etc.). Existen un gran número de paradigmas que surgen de la combi-
nación de redes de sensores y otras tecnologías, sin embargo también existe una
constante, que es la gran cantidad de datos generada por las redes de sensores.
Las redes de sensores generan grandes cantidades de datos, las cuales pueden ser
transportadas, analizadas y almacenadas de forma que el consumo de recursos
sea mínimo. ”Gracias al paradigma CloudIoT se pueden desplegar BSN en un
grupo de personas y almacenar, procesar y analizar grandes cantidades de datos
de manera escalable.” (Botta y col. 2016). Dicho lo anterior, es pertinente citar
uno de los principales proyectos que unen las redes de sensores con un enfoque
IoT. En dicho desarrollo proponen una arquitectura SaaS llamada BodyCloud
(Giancarlo Fortino, Parisi y col. 2014). Esta plataforma pretende ofrecer soporte
para aplicaciones especializadas las cuales generen grandes cantidades de datos,
que permitan a usuarios y aplicaciones interactuar y que provea un sistema de
toma de decisiones basadas en los datos generados. Este sistema gira en torno a
los siguientes componentes descentralizados: la parte corporal basada en SPINE
Android (G. Fortino y col. 2013), la cual obtiene datos de la red de sensores
y los almacena en la nube por medio de un smartphone. El componente cloud
29
XaaS(Acrónimo) X(Expansión) Descripción
Cosas como servicio Agregación y abstrac-
ción de recursos he-
terogéneos de acuerdo
a semánticas diseñadas
para ”cosas”
SaaS Sensado como servicio Provee acceso ubícuo a
información provenien-
te de sensores
SAaaA Sensado y actuación Permite lógica de con-
como servicio trol automática imple-
mentada en la nube
SEaaS Eventos de sensor co- Despacho de mensajes
mo servicio disparados por eventos
de sensores
SenaaS Sensor as a service Permite manejo ubícuo
de sensores remotos
DBaaS DataBase como servi- Permite administra-
cio ción ubícua de bases
de datos
DaaS Datos como servicio Provee acceso ubícuo a
cualquier tipo de datos
EaaS Ethernet como servicio Provee conectividad
ubícua de capa 2 a
dispositivos remotos
IPMaaS Manejo de polizas e Permite acceso ubícuo
identidad como servi- a funcionalidades de
cio manejo de polizas e
identidad
VSaaS Supervisión mediante Provee acceso ubícuo a
video como servicio grabaciones de video y
a análisis complejo rea-
lizado sobre dicho vi-
deo
30
está implementado en Google App Engine, el cual provee funciones de análisis,
almacenamiento de datos y visualización de información. El componente de aná-
lisis es el componente que soporta el desarrollo de aplicaciones BodyCloud. Al
igual que SPINE, BodyCloud ofrece abstracciones de programación enfocadas
en la creación de prototipos para aplicaciones BSN que se ayuden de entornos
Cloud. “Este sistema de naturaleza Software as a Service, es el primer acerca-
miento a ingeniería de software de uso general enfocado a BSN combinadas con
un entorno Cloud”.
Tecnologías auxiliares
Otras tecnologías que han visto una inclinación hacia su integración con sis-
temas IoT son las redes de sensores y actuadores inalámbricas (WSANs) (Akyil-
diz y Kasimoglu 2004) las cuales se encuentran implementadas principalmente
en entornos de manufactura pues esto permite la automatización de procesos y
control de materias primas. Sin embargo, su investigación no es relevante pa-
ra este trabajo debido a que dichas redes funcionan bajo entornos controlados
mediante tecnologías homogéneas que buscan la optimización de procesos. Y
aunque de igual manera que el proyecto aquí propuesto manejan redes de sen-
sores, actuadores y sistemas nube centralizados, sus propósitos y metodologías
distan en gran namera.
31
Capítulo 4
Metodología y Desarrollo
32
Figura 4.1: Arquitectura del sistema a desarrollar. Aunque en este capítulo aún
no se habla de las tecnologías específicas de cada nodo es preciso mencionarlas
para tener una idea clara del sistema y sus interacciones internas.
33
4.3. Bases de datos de señales fisiológicas
Como se mencionó en capítulos anteriores, las WSN, y por extensión las
BSN, pueden ser vistas como hardware con capacidades limitadas de cómputo
enfocado en la transmisión de datos hacia un punto específico o gateway. Se
determinó necesario utilizar una fuente de datos con amplio uso en la comuni-
dad científica para poder tener un mejor punto de comparación con trabajos
similares y que estuviese documentada o que proporcionara datos adicionales a
la señal misma. La elección fue PhysioBank(National Institute of General Me-
dical Sciences (NIGMS) y (NIBIB) 2018a, diciembre), las cuales cuentan con
una gran colección de registros de señales fisiológicas digitalizados. Los cuales
son accedidas a través de la plataforma PhysioNet(Goldberger y col. 2000), ba-
jo la licencia ODC Public Domain Dedication and Licence, la cual permite el
libre uso, modificación y distribución de los mismos sin mayor restricción. En
la plataforma PhysioNet se encuentra el paquete de software WFDB (Wave-
Form DataBase) (National Institute of General Medical Sciences (NIGMS) y
(NIBIB) 2018b, diciembre), el cual permite ser compilado y utilizada por otros
sistemas y lenguajes de programación. Esta biblioteca se encuentra publicada
bajo la licencia GNU Lesser General Public License versión 2, la cual permite
copiar, modificar y distribuir la librería siempre y cuando los trabajos derivados
también se encuentren bajo esta licencia.
La eleccion de la base de datos se realizo analizando varias de estas, la base
de datos de Detección de estrés en conductores de automóviles y el conjunto de
datos para el desarrollo de detectores de apnea basados en ECG . La primera
opción fue un fuerte candidato debido a que, como se mencionó previamente, el
trabajo del laboratorio de cómputo afectivo del MIT ha sido importante y un
referente para el desarrollo de los sistemas IoT y domóticos que se enfocan en
la interpretación de señales fisiológicas, sin embargo, la metodología que dicho
laboratorio propone a utilizar para la interpretación de la base de datos de estrés
en conductores tiene un bajo porcentaje de éxito de clasificación, además de el
hecho de que la clasificación está enfocada en detectar estados emocionales más
allá de fenómenos fisiológicos, lo cual deja un cierto umbral de incertidumbre
acerca de la subjetividad de la medición. Además, el hecho de que los datos re-
presentan un sector de la población muy específico: hombres de mediana edad.
La segunda opción, el conjunto de datos para el desarrollo de detectores de apnea
basados en ECG, esta opción pareció atractiva en primera instancia ya que el
conjunto de datos fue publicado como parte de un reto a la comunidad científica
para generar detectores confiables de apnea a partir de señales electrocardiográ-
ficas, esto garantizaba una gran variedad de metodologías a implementar para
la interpretación o clasificación del conjunto de datos. Sin embargo, muchas de
las metodologías propuestas tienen un porcentaje bajo de clasificación debido a
que su desarrollo tenía como objetivo resolver el reto de clasificación, más que
ofrecer un método óptimo de clasificación y dado que el objetivo de este proyec-
to no es optimizar ni mejorar alguna metodología de clasificación, el hecho de
implementar alguna con un porcentaje bajo de éxito implicaría tener un umbral
de incertidumbre en la clasificación de los datos independientemente de que su
34
transporte y manejo sea óptimo o al menos correcto.
Se eligió (Darouei y Ayatollahi 2010), la base de datos MIT-BIH de ritmo
sinusal normal (Center) 1990) y la base de datos de taquiarritmia ventricular de
la universidad Creighton (Nolle y Bowser 1992), en lo futuro referidas como las
bases nsrdb y cudb respectivamente. los cuales se pueden usara para clasificar de
tres fenómenos: ritmo sinusal normal, taquicardia ventricular y fibrilación ven-
tricular, además que ambas bases de datos son utilizadas en un amplio número
de aplicaciones, lo cual permite tener puntos de comparación entre el sistema
propuesto y dichas aplicaciones. Teniendo en cuenta la metodología seleccionada
y el fácil acceso y manejo de los datos que ofrece la plataforma PhysioBank el
siguiente paso fue seleccionar las tecnologías necesarias para lograr los objetivos
propuestos.
Dado que el primer módulo, la simulación de la red, es una implementa-
ción de software simplemente basta con elegir un lenguaje de programación con
amplio soporte y con capacidades de transmisión a través de protocolos de red
convencionales.
En cuanto al módulo Cloud, la combinación del protocolo HTTP y el for-
mato de intercambio de información JSON, basado en y altamente compatible
con Javascript, representan una combinación de tecnologías atractivas para el
envío de información dentro de los sistemas IoT. Además cabe mencionar un
aspecto importante de este módulo: el almacenamiento de la información. En
años recientes ha habido mucha discusión respecto a las diferencias que existen
entre los dos principales paradigmas en las bases de datos SQL y NoSQL. Las
características principales que se toman en consideración para sugerir uno de los
paradigmas son el crecimiento que tendrá la base de dato y la naturaleza de los
datos a almacenar. Este último punto es crítico en el sistema propuesto puesto
que, como ya se mencionó anteriormente, la naturaleza de los datos puede variar
entre distintas bases de datos del sistema PhysioBank.
Finalmente, para el módulo domótico que sirve como retroalimentación para
el usuario se realizo un dispositivo encargado de enviar un mensaje SMS según
el sistema lo considere adecuado. Esta desición del envío del sms debe surgir del
análisis realizado en el módulo cloud y transmitida hacia el módulo domótico
mediante una consulta a un servicio REST, lo cual nos indica que el módulo
domótico simplemente necesita cumplir con dos funciones: consultar al módulo
Cloud respecto a la información que debe enviar mediante peticiones REST y la
capacidad misma de enviar los mensajes SMS. Esta opción fue elegida entre otros
métodos de interacción domótica como iluminación, regulación de consumo de
energía, consulta de estado de dispositivos dentro del hogar, entre otros; debido
a que en el caso de prueba propuesto la retroalimentación del sistema tiene
una naturaleza urgente, además, como se puede ver en otros sistemas similares
(Luigi Atzori y col. 2010; G. Fortino y col. 2013).
35
4.4. Limitaciones del sistema
En este punto es pertinente mencionar las lilmitaciones instrinsecas del sis-
tema que surgen de la estructura del mismo o de sus componentes inherentes.
En primer instancia es necesario señalar que debido a las limitantes de integra-
ción de las tecnologías seleccionadas (servicios web para transferencia de datos,
almacenamiento en nube, interfaz gráfica para usuarios) es necesario contar con
una conexión a internet estable y constante para permitir el funcionamiento
correcto de la red de sensores, el servidor de clasificación y notificaciones, y la
página web de los usuarios. Siguiendo esta idea, tanto el almacenamiento como
el procesamiento de señales y datos de usuarios dependen enteramente de las
herramientas e infraestructura que ofrece Google. Si en algún momento los ser-
vicios de Google llegasen a fallar el sistema propuesto inmediatamente fallaría
de igual manera puesto que no se han propeusto mecanismos que garanticen la
disponibilidad del mismo. Como se mencionó previamente, una de las posibles
soluciones a estos problemas se podría ncontrar en tecnologías que no han si-
do incorporadas en el sistema, como M2M, sin embargo, dichas tecnologías no
aportan elementos al proyecto que ayuden a alcanzar las metas descritas en este
documento, por lo tanto se consideran innecesarias. Finalmente, es necesario
señalar que la seguridad en el sistema no ha sido reforzada más allá de las medi-
das que por defeco ofrecen las tecnologías involucradas, por lo tanto, el sistema
propuesto no cuenta con las medidas de seguridad que serían necesarias si se
buscara una implementación más allá de esta prueba de concepto.
36
Capítulo 5
37
5.2. Diseño de las capas
5.2.1. Capa:Red de sensores corporal
El objetivo de la red de sensores corporal simulada es funcionar como fuente
de datos y referente en cuanto a rendimiento y consumo de energía realiza. Dado
que los objetivos de este proyecto no incluyen el análisis de rendimiento inherente
al caso de prueba, es posible analizar los nodos a partir de la disposición de datos
a transmitir. Es decir, los nodos en esta red simulan simplemente su interacción
con otros nodos y el nodo de salida de información y dejan de lado los procesos
inherentes a la obtención de datos, en este caso señales electrocardiográficas,
debido a que dichos procesos suelen ser relevantes solamente para los nodos y
ningún otro módulo de los sugeridos en capítulos anteriores.
Esta simulación tiene como objetivo secundario arrojar información acerca
del rendimiento de una red de sensores utilizando protocolos de comunicación.
Para este fin se propuso la implementación de dos protocolos de distinta na-
turaleza: el protocolo Aloha ranurado (S-ALOHA) y un protocolo enfocado en
medición de energía de cada nodo de la red, en cada ranura temporal, al cual se
denomino protocolo de medición energética, este protocolo es una versión
ligeramente modificada del protocolo aloha ranurado. El primer protocolo es
Aloha ranurado(Roberts 1975) es un protocolo de acceso al medio para redes de
área local, el cual funciona con base en ranuras temporales, las cuales determi-
nan el tiempo en el que los nodos pueden transmitir. Cuando un nodo decide
transmitir debe esperar a que inicie el periodo permitido para ello y entonces
transmitir un paquete para solicitar el canal. Estos paquetes para solicitar el
canal deben ser transmitidos en un periodo de tiempo corto al inicio de cada
ranura de tiempo. Si dicho paquete para pedir el canal no ocasiona colisión en-
tonces el nodo de origen toma el canal para transmitir, si dicho paquete ocasiona
colisión los nodos que ocasionaron la colisión deciden esperar y reintentan dicha
transmisión en otra ranura temporal.
El diagrama de flujo de la figura 5.2 muestra el algoritmo de una implemen-
tación de software del protocolo Aloha ranurado.
El segundo protocolo es el protocolo de medición energética, un pro-
tocolo enfocado en la medición de parámetros como tiempo mínimo necesario
para transmisión total de nodos y energía total consumida en la red, los cuales
son los principales aspectos a considerar en cuanto a redes de sensores se refiere.
Este protocolo puede ser visto como una implementación de Aloha ranurado
modificado para poder predecir el consumo temporal y energético de la red bajo
distintos parámetros de ejecución.
En la figura 5.3 se aprecia el diagrama de flujo del algoritmo del protocolo
de medición energética. Como se puede apreciar el algoritmo es muy similar
al de aloha ranurado, sólo que este algoritmo adicionalmente toma en cuenta
la energía necesaria para transmisión y recepción de mensajes y así realizar
mediciones.
Es importante explicar el valor tao, el cual determina si un nodo puede
o no tomar la iniciativa para apartar el canal de comunicación y transmitir
38
Figura 5.2: Diagrama de flujo de la implementación del protocolo Aloha ranu-
rado.
39
Figura 5.3: Diagrama de flujo: implementación del protocolo de medición ener-
gética.
40
sus datos. Este valor ha sido propuesto como un valor decimal entre 0 y 1
para cada nodo que regule la competencia por el canal entre ellos. Si todos los
nodos tuviesen una probabilidad de 1, en cada ranura todos ellos intentarían
transmitir y existirían colisiones en todo momento, lo cual haría imposible el
funcionamiento de la red. De igual manera, es pertinente señalar que el rango de
nodos simulados, de cero a treinta, fue seleccionado debido a que la literatura
relativa a las WBAN (Movassaghi y col. 2014) señala que una WBAN puede
llegar a tener un número límite teórico de nodos de 256, sin embargo, debido a
las limitaciones tecnológicas de este tipo de redes (protocolos de acceso al medio,
arquitectura o técnicas de transmisión) el número máximo reportado ha sido 50
nodos, cada uno con un canal de transmisión ortogonal; un número máximo
regularmente reportado en las aplicaciones de WBAN es 20 nodos, por lo tanto,
para este proyecto se decidió hacer simulaciones de rendimiento con un número
superior a la media reportada y así tener un rango de datos que incluye un
valor regularmente utilizado y valores superiores a él. Otro aspecto importante
a señalar es el hecho de que se ha incluido un paso final en cada iteración de la
simulación que indica un ”ajuste por aplicación”, este ajuste es dependiente de la
aplicación, ya que el diseño del algoritmo pretende ser independiente del caso de
estudio. En este caso de estudio, en ese paso de la simulación se propone incluir
un retraso o periodo de descanso de la red para que la transmisión de datos
tenga una frecuencia similar a la del muestreo de la señal electrocardiográfica.
Finalmente, también se desarrolló una implementación del protocolo de Ac-
ceso múltiple con detección de portadora no persistente o CSMA-NP por sus
siglas en inglés (N. LOFCALI y M. Lundy 1989). Este protocolo fue desarrollado
con una estructura y metodología similar a aloha ranurado, sin embargo, no se
demostró su validez matemática, por lo cual su aplicación en el sistema queda
delimitada a un modo de operación adicional para la BSN.
41
Figura 5.4: Modelo entidad-relación.
42
Figura 5.5: Modelo entidad-relación generado a partir de los objetivos del pro-
yecto con cardinalidad entre entidades indicada.
Figura 5.6: Modelo entidad-relación generado a partir de los objetivos del pro-
yecto con atributos de entidades señalados.
43
Figura 5.7: Propuesta inicial de diagrama relacional con tablas de base de datos.
44
5.2.3. Proceso de Normalización de la Base de Datos
Respecto a la propiedad de atomicidad en la base de datos , por ejemplo,
una persona podría necesitar registrar más de un número telefónico o correo
electrónico para ser contactada, esto requiere un campo multivaluado para los
números telefónicos en la tabla persona, dividir este campo en una nueva tabla
donde haya sólo dos campos: teléfono o correo electrónico de contacto e iden-
tificador de persona, o limitar el número de registros de números telefónicos y
correo electrónico a uno por persona, siendo esta última opción la opción im-
plementada. Después de este paso la base de datos cumple con la forma normal
1. Después es necesario asegurarnos que no existen dependencias entre los datos
con campos que no sean una llave primaria, es decir, dependencia parcial. Todas
nuestras tablas por el momento cumplen con esta regla, por lo tanto podemos
afirmar que cumple con la segunda forma normal. Después, es necesario llevarla
a la tercera forma normal, para esto también se debe revisar que no existan
dependencias transitivas. Estas dependencias transitivas no se encuentran en la
base de datos, por lo tanto nuestra base de datos ya se encuentra en tercera
forma normal. Finalmente, para la cuarta forma normal es necesario revisar que
no hay dependencia multivaluada, es decir, que para una única llave primaria
no existen dos mismos valores en alguna columna. Un campo candidato a este
criterio sería tipo de acción en acción, ya que la relación entre tipos de acción
y acciones es de uno a muchos ya que distintas acciones pueden compartir el
mismo tipo pero una acción no puede tener más de un tipo. Dicho lo anterior,
es pertinente mover los tipos de acción a una tabla nueva. Finalmente nuestra
base de datos puede ser representada con el modelo relacional mostrado en la
figura 5.8.
45
Figura 5.8: Diagrama relacional normalizado.
46
personas calificadas para actuar en el momento. Dicho esto se propuso realizar
dos tipos de notificaciones: notificaciones por mensaje de texto para notificar
a las personas de confianza y una notificación por medio de una fuente de luz
( que alerta al familiar o persona designada , acerca de que se ha detectado
este episodio, esta alerta se activa en la casa del familiar, en adición al mensaje
SMS que también recibe indicándole del episodio) . Estas notificaciones están
representadas por los registros de la tabla Accion en la base de datos, las cuales
detallan el tipo de tarea que se debe realizar. Por lo tanto, podemos definir un
protocolo de acción para el sistema domótico:
1. Solicitar acción sin completarse
2. Descargar datos de acción
3. Determinar naturaleza de la acción
4. Obtener datos de la acción
5. Ejecutar acción
6. Si la acción fue exitosa reportar resultados en el registro de la base de
datos de dicha acción
7. Si la acción no fue exitosa, reintentar
En la figura 5.9 se describe el protocolo previo como un diagrama de flujo. Un
detalle que es aparente es el hecho de que no existe un sistema de protección
contra condición de carrera en cuanto a la ejecución de tareas por parte del
sistema domótico, es decir, si nuestro sistema de prueba tuviese dos dispositivos
que pudiesen ejecutar la misma tarea, ambos podrían consultar los datos de una
acción, considerarla como posible, ejecutarla, e intentar actualizar su estampa
de tiempo de completitud. Esto llevaría a la ejecución de la misma acción dos
veces. Debido a que el análisis de los problemas que el crecimiento del sistema
pudiese generar no se encuentra dentro de los objetivos del proyecto este aspecto
se deja como trabajo a futuro.
Dado que el caso de estudio requiere el uso de mensajes de texto y noti-
ficaciones por medio de luz, es evidente que se necesita de por lo menos dos
dispositivos: un transmisor GSM y un interruptor de corriente. Estos dos dis-
positivos pueden ser un transmisor GSM como la serie sim900 de la empresa
SIMCom (Amazon 2018, diciembre), mientras que para el interruptor de corrien-
te se propone utilizar un relevador entre una toma de corriente y un conector
de un foco.
Dado que el uso de de un integrado sim900 requiere control mediante co-
mandos AT y que el control de un relevador requiere de una señal constante,
regularmente de 5V, se propone utilizar un módulo Arduino Uno como contro-
lador para el sistema domótico.
El desarrollo se realiza: el módulo BSN representa la extracción de datos
mediante dispositivos de gama baja a través de un gateway hacia un sistema
cloud, el módulo cloud representa el análisis, procesamiento y almacenamiento
47
Figura 5.9: Protocolo de ejecución de tareas por parte del sistema domótico.
48
Figura 5.10: Arquitectura del primer prototipo de servidor web para módulo en
la nube. Como se puede apreciar la funcionalidad depende del tipo de petición
HTTP registrada en el servidor.
49
Figura 5.11: Gráfica que muestra los valores transmitidos por la red de sensores
al ejecutar una prueba de consumo de energía. En esta imagen se puede apreciar
uno de los primeros prototipos de la página web que opera como la capa de
presentación de datos al usuario.
50
igual manera los registros de la base de datos de ejemplos de electromiogramas
(EMGDB) contienen por lo menos la señal digitalizada de un electromiograma.
Otro registro importante de estas bases de datos son los registros de anota-
ciones, estos sirven para marcar puntos importantes en los registros de señales
digitalizadas o para ofrecer información adicional que sea importante para las
señales mismas. Estos registros se pueden obtener de la misma manera que los
registros de señales digitalizadas, mediante descarga directa o mediante el uso
de la función rdann de la librería wfdb. En la figura 5.12 podemos ver los subre-
gistros de uno de los registros de una señal de la base de datos MIT-BIH. Los
registros de anotaciones mismos contienen distintos tipos de información la cual
puede variar desde datos relativos a la digitalización de la señal misma (como
frecuencia de muestreo, errores en la muestra, etc.) hasta información relativa
al paciente que ha proporcionado la señal digitalizada(Goldberger y col. 2000).
Los archivos de anotaciones son importantes porque en el caso de las dos bases
de datos que utilizaremos indican los puntos exactos donde ocurre un pico R en
la señal ECG, así como los fenómenos presentes en algunos latidos específicos,
ya sea indicar si el latido representa un latido de escape de la unión ventricular,
una contracción auricular prematura, una taquicardia ventricular, entre otros.
Esta información es relevante para el segundo módulo del sistema, el cual re-
quiere entrenamiento de una red neuronal utilizando el tipo de latidos que se
desean detectar, son embargo, para el módulo de BSN simplemente se utilizarán
los registros de señal digitalizada.
En este punto, el principal problema con el que nos encontramos al tener un
desarrollo enfocado en JavaScript es el hecho de que el wrapper o intérprete de
la librería wfdb para ese lenguaje se encuentra a través de la librería ”WFDB
for node.js” (jeffplourde 2018b, febrero), esta librería es el único resultado en
los principales repositorios de paquetes y librerías (npm, yarn, bower y ringojs)
disponibles para dicho lenguaje, por lo tanto, es la única opción que se tiene
para manejar las señales provenientes desde la base de datos de PhysioNet. De
hecho, todos los resultados de estas búsquedas muestran que han sido subidos
a estos repositorios por el mismo usuario, autor de la librería, cuyos archivos
fuente se pueden encontrar en un repositorio de GitHub (jeffplourde 2018a, fe-
brero). Dentro de todos los repositorios uno puede encontrar la leyenda ”Sólo
datos numéricos pueden ser leídos (no anotaciones o algún otro tipo de datos),
con limitadas opciones para soportar otras opciones de lectura de señales de
WFDB” esto representa dos problemas. El primero es un problema de desa-
rrollo pues de esta manera no es posible utilizar las anotaciones de las señales
en las bases de datos seleccionadas y eso impide el aceeso directo a cada uno
de los latidos de la señal electrocardiográfica, un paso hacia la solución de este
problema sería desarrollar las interfaces necesarias entre el lenguaje en el que
fue desarrollado la librería base WFDB y javascript utilizando como base la
librería antes mencionada, sin embargo, esto implicaría comenzar por hacer in-
geniería inversa a dicha librería en primer lugar lo cual implica una carga de
trabajo mayor a la esperada. El segundo problema es el hecho de que el objetivo
de este proyecto es crear un proyecto que se encuentre libre de las limitaciones
tecnológicas que implicaban, hasta poco tiempo atrás, un impedimento de dis-
51
Figura 5.12: Datos adicionales presentes en registro de señal ECG de la base
de datos nsrdb. Estos datos aportan información adicional acerca de la señal
misma. En este caso específico podemos ver el campo ’comments’ con un valor
’32 M’, lo cual indica que esta señal ECG pertenece a una persona de sexo
masulino de 32 años de edad.
52
tinto índole en cuestiones de implementación y aunque Javascript sea uno de los
lenguajes que más creciemiento han registrado, la falta de estas funciones espe-
cíficas de esta librería implican una limitante tecnológica que dista del objetivo
de este proyecto. Dicho lo anterior, se decidió entonces cambiar de lenguaje base
para el proyecto y utilizar Python para el desarrollo del mismo. Esto, debido
a que es el segundo lenguaje más popular utilizado por gente que trabaja con
tecnología web y a que cuenta con un gran número de repositorios de librerías
y paquetes auxiliares, sin embargo, este cambio implicó un gran esfuerzo para
recrear algunas funcionalidades provistas por Javascript, además de un cambio
en la filosofía de desarrollo ya que Javascript puede crear servicios web REST
mediante el uso de librerías, de igual manera el manejo de sesiones se hace a
través de valores en las librerías utilizadas, mientras que python utiliza instan-
cias de clases dentro de determinadas librerías de determinados frameworks para
realizar la misma función. A partir de este punto en el desarrollo se redefinieron
las tecnologías utilizadas en los módulos: Detección de arritmias, red neuronal
y servidor web. Entonces se decidió por utilizar un framework popular para la
creación de sistemas web en el lenguaje Python, Django.
53
Figura 5.13: Código HTML generado por una etiqueta de token crsf. Este nú-
mero representa el número aleatorio generado para el usuario que ha iniciado
sesión después de habérsele añadido una sal igualmente aleatoria.
54
del sistema, la cual se ubica en ”saturn-enceladus.appspot.com/cuenta/login/”.
Como se mencionó en el capítulo anterior, la URL del sistema Saturno que
corresponde a ”.../cuenta/...” es manejada por el middleware de manejo de se-
siones de usuario de la arquitectura Django, por lo tanto la URL mencionada
inicialmente nos otorgará una cookie llamada ”csrftoken”, la cual al igual que
los tokens dentro de las formas HTML representa el número secreto asignado al
usuario después de habérsele añadido una sal aleatoria.
Estos tokens funcionan como credenciales para todo tipo de operaciones
realizadas dentro del sistema, por lo tanto, su uso por parte de la simulación de
la red de sensores es necesario. Tomando en cuenta que se necesita un token csrf
de un usuario con sesión iniciada y las cookies de sesión presentes para poder
realizar peticiones no seguras se proponen los siguientes pasos para realizar
peticiones desde el sistema domótico y la red de sensores.
1. Realizar petición GET a la URL de inicio de sesión
2. Extraer cookie ’csrftoken’ de las cookies obtenidas
55
Intervalo QRS
Intervalo PR
Intervalo PT
Los siguientes parámetros morfológicos:
56
Figura 5.14: Protocolo de clasificación de señales electrocardiográficas, este pro-
ceso asume que la red neuronal ya ha sido entrenada.
57
Figura 5.15: Diagrama de red neuronal para clasificación de arritmias propuesto
por (Darouei y Ayatollahi 2010).
58
Figura 5.16: Modelos Django que son mapeados a la base de datos. En este
diagrama los atributos de los modelos han sido expresados como tipos de dato
nativos de Python y Django.
Podemos ver que existe un traslape entre los campos que hemos propuesto para
nuestra tabla de usuarios y la provista por el sistema de seguridad de Django.
Otro detalle importante es el hecho de que los modelos de Django no incluyen
un campo ”id” como lo haría una tabla de base de datos convencional que utilice
el lenguaje SQL. Esto es porque los campos de llave primaria son generados de
forma automática y son administrados automáticamente por el servidor mismo.
En la figura 5.16 podemos ver el mismo diagrama de la figura 5.8 pero esta
vez en lugar de representar la persistencia de datos mediante tablas de base de
datos lo hace mediante los modelos Django utilizados.
Como se puede ver, los modelos Django pueden valerse de herramientas
como campos específicos para fechas y horas como ”DateTimeField” o llaves
foráneas como ”ForeignKey”, los cuales son resueltos a tipos de datos primitivos
de Python por parte del servidor.
59
Una vez que se tiene clara la implementación en modelos se prosiguió a crear
los mismos. Para esto se siguieron los siguientes pasos:
Declarar los modelos como instancias de la clase ”Model” del paquete
”django.db”
Ejecutar una migración de los modelos hacia la base de datos mediante
la instrucción ”python manage.py migrate enceladus”. La cual le indica al
servidor migrar los modelos de la aplicación enceladus a la base de datos.
Generar vistas para crear operaciones CRUD (Crear, consultar, actualizar
y destruir por sus siglas en inglés) sobre los modelos generados
Este proceso fue directo y no se encontraron mayores dificultades en la im-
plementación de la base de datos y los modelos que la representan.
60
Django Bootstrap permitiría mostrar de forma agradable a la vista información
al ususario, Django Pandas permitiría tener un modelo de datos listo para su
análisis, específicamente el análisis de las señales ECG generadas por el módulo
BSN, finalmente, Django REST nos permitiría configurar distintas respuestas
ante distintas peticiones a la misma dirección web, permitiendo que usuarios y
dispositivos se comunicaran con facilidad hacia el mismo sitio. Finalmente se
decidió por utilizar Django REST para tener mejor control sobre el manejo,
almacenamiento y presentación de la información, no sólo para usuarios finales
del sistema, sino también para dispositivos, específicamente, el módulo GSM.
Una vez decidido el framework el siguiente paso es crear un servidor web.
Para esto Django, y por extensión Django REST, provee una infraestructura
lista para ser desplegada de inmediato al ser instalado. Primero se instaló Djan-
go, seguido de Django REST y sus dependencias, de igual manera se creó un
entorno virtual mediante la herramienta virtualenv (Bicking 2018, septiembre)
para tener contenidas las dependencias del proyecto dentro de la estructura del
mismo y así facilitar su implementación según las medidas de google cloud. Se
eligió como plataforma de alojamiento y procesamiento a Google Cloud sobre
otras opciones debido a la extensa documentación que existe para desarrollado-
res en Python que desean realizar implementaciones en la misma. Además, dado
el avance en cuanto a tecnología y abstracciones de funcionalidad en servicios de
la nube, ya existe documentación que indica a los desarrolladores las similitudes
entre soluciones de distintas plataformas, esto vuelve la decisión de plataforma
una cuestión de especificidades en lugar de utilidades concretas (Google 2019b,
enero). Este uso de la plataforma Google Cloud
Una vez definidos los modelos base de nuestro proyecto es necesario hablar de
los serializadores provistos por Django REST. Los serializadores son funciones
que pueden convertir querysets de Django en objetos nativos de Python que
pueden ser representados en formato JSON o XML. Estos serializadores son
importantes para el proyecto pues nos pueden ayudar a presentar información en
formatos fáciles de procesar por las fuentes de datos y los actuadores domóticos.
Otro aspecto importante del servidor web es la autenticación, la cual nos per-
mite asociar un grupo de credenciales con alguna petición entrante, después los
mecanismos de permisos y regulación de acceso toman esta asociación y determi-
nan las acciones pertinentes. La autenticación es el primer código que se ejecuta
cuando una vista es solicitada y utiliza los elementos contenidos dentro del ob-
jeto ”request”, específicamente request.auth y request.user, para determinar el
tipo de usuario que ha hecho la petición. Esto lo hace al comparar los datos que
ha recibido en el objeto request con cada una de las clases predefinidas por el
paquete de seguridad de Django, si no logra encontrar datos algunos, por defec-
to se asigna un objeto de la clase django.contrib.auth.models.AnonymousUser
a request.user y None a request.auth. Si una petición es denegada puede ser
repondida con dos tipos de errores, HTTP 401 y HTTP 403.
Para lograr esto el framework seleccionado ofrece dos métodos: ”has_permission”
y ”has_object_permission”, los cuales regulan el acceso que tienen las peticio-
nes Web hacia la API. Cuando una petición web es dirigida hacia una vista
primero se revisa la lista de permisos, si no se cumplen los permisos de dicha
61
lista la respuesta inmediata será un error 403 o 401, acceso prohibido y acceso no
autorizado respectivamente, si se cumplen dichos permisos se procede a ejecutar
el cuerpo de la vista. Si las vistas interactúan con objetos de la base de datos
se ejecuta la lista de permisos de objeto, específicamente se ejecuta al mandar
llamar la función get_object(), sin embargo, por cuestiones de rendimiento no
se ejecutan sobre todos los resultados del queryset, lo cual exige un filtro previo
de los objetos sobre los que es permitido interactuar para cada usuario. Esto
nos lleva al siguiente punto, toda consulta puede ser ligada a un usuario dentro
del sistema mientras las credenciales de acceso se encuentren presentes duran-
te el intercambio de peticiones http. Cuando ocurre una petición primero son
analizadas las reglas a nivel de vista, es decir, sobre el dominio que la petición
buscar accesar, después, son analizadas las reglas de objeto, es decir, las reglas
que regulan el acceso a las instancias específicas de datos. Las reglas de objeto
sólo son evaluadas si las reglas de vista han sido aprobadas previamente. Este
comportamiento ocurre de maera automática al utilizar una estructura basada
en clases, como es el caso de este proyecto. Si se utilizara una estructura ba-
sada en funciones sería necesario hacer una evaluación específica mediante la
instrucción ”check_object_permissions”.
El framework ofrece una abstracción de acceso a los datos mediante la cual
engloba los comportamientos de vistas generales en un solo grupo de instruccio-
nes llamado ViewSet. Un ViewSet puede ser modificado para ofrecer distintas
reglas de acceso a los datos, desde filtrar los resultados antes de ser devueltos
en la respuesta Web, regular el acceso a distintos tipos de usuario, especificar
el formato de respuesta Web, entre otros. Las acciones definidas en los ViewSet
sólo son ejecutadas cuando el router o el módulo de direccionamiento manda a
llamar al método .as_view()"del ViewSet seleccionado.
Las acciones son los métodos de los ViewSets pueden ser vistos como los
métodos de una clase escrita en un lenguaje orientado a objetos como JAVA o
C++, sin embargo, estas acciones pueden ser mapeadas directamente a direc-
ciones URL que obtienen como respuesta la salida programada dentro de dicha
acción. Los argumentos adicionales que toman las acciones de los ViewSets pue-
den ayudar a configurar comportamiento adicional del sistema, sin embargo,
estos sólo son aplicables a la vista cuando se accesa directamente desde la URL,
es decir, hasta que se accesa a la URL específica el comportamiento programado
se ejecuta. Uno de los argumentos para las acciones mapeadas a URL es ’detail’,
el cual indica si la acción es aplicable a un solo objeto o a colecciones enteras.
Cuando se opera sobre una colección en la URL se acepta un parámetro "pk",
el cual representa el valor del identificador principal del objeto buscado. Uno
de estos argumentos Estas reglas simples de acceso fueron implementadas de la
siguiente manera:
Para los directorios de Personas, Dispositivos, Señales y Acciones se utilizó
la funcionalidad por defecto de las clases ModelViewSet, la cual permite ligar
plantillas html a respuestas http específicas. De esta manera podemos ligar la
creación y edición de registros a formularios genéricos o peticiones http directas
y así facilitar dichas funciones a los usuarios generales y a los dispositivos de
gama baja. Se decidió utilizar permisos específicos para controlar el acceso de
62
Figura 5.17: Captura de pantalla de la página de inicio de la página del servidor
web.
Figura 5.18: Misma vista que la figura 5.17, sin embargo, esta vez mostrando la
información desde una vista de administración.
todos los modelos de datos de la base de datos solamente a los usuarios que los
crearon o a los administradores del sistema. Se programaron los métodos list,
retrieve, create, update y destroy según la especificación de la documentación
de Django REST, sin embargo, se debieron hacer algunas modificaciones a la
forma en la que los datos son obtenidos en el método list, ya que existe un
error en la documentación que no ha sido corregido desde versiones anteriores
del framework (Eskimon 2018, noviembre). Finalmente, una vez resuelto dicho
problema se prosiguió a cambiar el aspecto gráfico de la presentación html para
los usuarios finales del sistema. Dajo que Django, y por extensión, Django REST,
utiliza por defecto las herramientas Bootstrap para definir estilos css y elementos
html se decidió simplemente definir clases nuevas en los documentos de estilo,
elegir una paleta de colores para el diseño de las plantillas html y una tipografía
que identifique la plataforma en general. En la figura 5.17 se puede ver la página
principal del sistema, en la 5.18 se puede apreciar la vista ’API’ de la misma
página y en la 5.19 su vista en formato JSON. Estas vistas se extienden para
directorios y registros específicos, por ejemplo, en las figuras 5.20, 5.21 y 5.22
63
Figura 5.19: Misma vista que la figura 5.17 pero mostrando la información como
un objeto JSON. Esta vez la página de inicio solamente muestra las direcciones
de los directorios mediante las urls donde se localizan.
Figura 5.20: Directorio Personas visto desde una plantilla HTML. Gracias a la
naturaleza iterativa de Vue es posible reutilizar componentes HTML mostrando
información de distintas personas mediante el mismo componente HTML.
podemos ver el directorio de personas desde tres tipos de vistas distintos. Como
se puede apreciar, aunque la dirección URL es la misma para los tres casos, la
información presentada es distinta. De igual manera, en las figuras 5.23, 5.24 y
5.25 podemos ver las tres vistas de un registro específico. Como se pudo apreciar
antes, estas tres vistas muestran la misma información, lo que las diferencia es
la forma en la que estilizan la información dependiendo de su propósito.
Finalmente, para permitir el rehuso de componentes HTML se implementó
el sistema de diseño y prototipado de páginas web Vue, acompañado de el sis-
tema de estilizado web Vuetify. Aunque no es una buena práctica de desarrollo
web, para la presentación de los datos la vista y el controlador de este modelo
de negocios se encuentran en los mismos componentes HTML. Para separar esta
funcionalidad entre las plantillas Django, escritas en Python, y los componen-
tes modulares de Vue, escritos en JavaScript, se tomó ventaja de las etiquetas
”verbatim”, las cuales le indican a las plantillas Django que no deben generar
contenido estático para determinadas regiones del código del servidor.
64
Figura 5.21: Misma vista que la figura 5.20, sin embargo, esta vez mostrando la
información desde una vista API.
Figura 5.22: Misma vista que la figura 5.20 pero mostrando la información como
un objeto JSON.
Figura 5.23: Vista detallada de un registro del directorio de persona. Esta misma
vista permite la edición de los campos de dicho registro.
Figura 5.24: Vista JSON de un objeto del directorio Personas. Aunque esta vista
es accesada desde la misma dirección URL que la figura 5.23 no provee métodos
de edición.
65
Figura 5.25: Vista API del registro de la figura 5.23. Esta vista ofrece métodos
de edición a dicho registro.
66
Figura 5.26: Diez muestras aleatorias superpuestas del registro 18177 de la base
de datos nsrdb. Como se puede apreciar, es una ventana de muestreo demasiado
corta.
67
Figura 5.27: Diez muestras aleatorias superpuestas del registro 18177 de la base
de datos nsrdb. Como se puede apreciar, esta ventana tiene el largo suficiente
para incluir información relevante.
Figura 5.28: Diez muestras aleatorias superpuestas del registro cu01 de la base
de datos cudb. Esta ventana no muestra los datos suficientes para hacer una
clasificación adecuada.
68
Figura 5.29: Diez muestras aleatorias superpuestas del registro cu01 de la base
de datos cudb. Como se puede apreciar, esta ventana tiene el largo suficiente
para incluir información relevante.
69
Figura 5.31: Inicio de señales P y Q y final de señales S, P y T indicado sobre
una señal que presenta ritmo sinusal normal.
PN
x(n) − X y(n) − Y
n=1
Rxy = qP 2 PN 2 (5.4)
N
n=1 x(n) − X n=1 y(n) − Y
70
Figura 5.32: Directorio con señales registradas. Con el uso del entorno Vue se
puede reutilizar el elemento HTML que muestra señales ECG.
71
Figura 5.33: Directorio de señales accesado desde dos diferentes tipos de vista, la
vista en formaton JSON y en versión API. Se puede apreciar que desde un punto
de vista lógico, ambas vistas despliegan una lista de datos llamada senal_list.
72
Figura 5.34: Representación JSON de un registro de acción en la base de datos.
que estas instancias de ejecución de crecimiento flexible son creadas con ayuda
de contenedores Docker. Estos contenedores son paquetes autocontenidos, au-
todependientes y transferibles que pueden ser ejecutados bajo distintos perfiles
de recursos.
Una vez desplegado el sistema pudo ser accedido en la dirección url: ”http://saturn-
enceladus.appspot.com”.
73
Figura 5.35: Mensaje recibido mediante el módulo GSM controlado a través de
la tablilla Arduino.
74
directorio ’Acciones’ en el servidor web desarrollado y enviarlos a través del
puerto serial hacia el dispositivo Arduino.
75
Capítulo 6
Pruebas y resultados
76
Figura 6.1: Comparación entre el rendimiento mostrado por la simulación del
protocolo Aloha ranurado (izquierda) y el rendimiento esperado por el mismo
protocolo a raíz de la solución de la cadena de Markov correspondiente (derecha).
77
Número de nodos Probabilidad de trans-
misión individual de
nodo
30 0.1
27 0.07
25 0.05
22 0.02
20 0.01
17 0.007
15 0.005
12 0.002
10 0.001
0,007 son las que arrojan valores con mayor rendimiento, el rendimiento total
de la red también aumenta según el número de nodos presentes en ella. Esto nos
indica que se debe encontrar un punto donde el gran número teórico de nodos
no suponga una limitante para la red.
Además, en las gráficas 6.2 y 6.3 el consumo energético de la red aumenta de
forma casi proporcional al número de nodos y de forma casi exponencial frente
a los valores de Tao. pero de igual manera, el tiempo de transmisión aumenta de
forma proporcional, lo cual nos habla de una relación directa entre el número de
nodos, la energía consumida por la red y el tiempo necesario para la transmisión
de datos.
Una vez demostrada la validez matemática de los protocolos utilizados en
la BSN simulada podemos hacer uso de ella como un módulo independiente, el
cual tendrá un comportamiento correcto y nos permitirá tener certitud de la
fiabilidad de su rendimiento.
78
Figura 6.2: Comparación entre el rendimiento mostrado por la simulación del
protocolo Aloha ranurado (izquierda) y el rendimiento esperado por el mismo
protocolo a raíz de la solución de la cadena de Markov correspondiente (derecha).
79
Figura 6.4: Datos obtenidos al consultar un directorio del sitio web, específi-
camente el directorio de acciones. Como se puede apreciar los datos son los
mismos, simplemente cambia la presentación de los mismos.
80
Figura 6.5: Cookies obtenidas por la red de sensores al iniciar sesión en el ser-
vidor Django mediante la ejecución de una petición POST con credenciales de
inicio de sesión adheridas. En este ejemplo las cookies ’csrftoken’ y ’sessionid’
se encuentran presentes y su contenido es dividido y analizado.
81
Figura 6.6: Fragmento de archivo con formato de valores separados por comas
que contiene las características extraídas de señales aleatorias que pertenecen a
las clases ritmo sinusal normal, firbrilación ventricular y taquicardia ventricular.
82
Figura 6.7: Resultado de una prueba de clasificación impreso en consola, esto
muestra que la clase está siendo correctamente instanciada y ejecutada.
Figura 6.8: Señal que presenta taquicardia (arriba) y el registro de acción gene-
rado a partir de su clasificación (abajo).
83
Figura 6.9: Señal que presenta fibrilación (arriba) y el registro de acción gene-
rado a partir de su clasificación (abajo). En este caso en específico, la señal no
necesita de una plantilla de texto para su ejecución, debido a que representa
una activación de alerta luminosa.
84
Figura 6.10: Respuesta de los directorios ante la creación de un nuevo registro.
Como se puede apreciar todos los directorios devuelven una respuesta HTTP
que contiene el objeto en formato JSON del registro recién generado.
85
Figura 6.11: Actualización de un dispositivo mediante plantilla HTML. En or-
den descendente, podemos ver primero el estado original del dispositivo desde
el directorio de Dispositivos, seguido de la vista detallada del registro mismo,
el cual cuenta con ’UUID’ y ’estado’ como datos editables siento ’Apagado’ su
estado original. Después, en la tercera casilla, el nuevo estado del dispositivo, es-
pecíficamente ’Encendido’. Finalmente, en la cuarta casilla, se aprecia el registro
modificado en el directorio de Dispositivos.
86
Figura 6.12: Eliminación de datos de una acción de prueba mediante vista API.
Como se puede apreciar Django provee un dialogo de advertencia que impide
borrar datos por error. De igual manera, después de la eliminación se recibe una
respuesta HTTP con código 204 el cual significa ’No hay contenido’.
87
Figura 6.13: Intento de acceso a datos de una cuenta ajena desde una cuenta
de usuario. En la primer figura, arriba, podemos apreciar los detalles de edición
de un registro de señal que son mostrados a la cuenta que creó dicho registro.
En la segunda imagen, abajo, podemos ver la respuesta HTTP del servidor, la
cual está compuesta por un código HTTP 404 el cuál indica que el contenido
solicitado ’No fue encontrado’.
88
Figura 6.14: Datos en formato JSON obtenidos al realizar una consulta al di-
rectorio de acciones después de haber realizado un inicio de sesión de forma
programática.
89
Figura 6.15: Datos de acción de prueba para envío de SMS (arriba), así como
el mensaje de texto recibido en el teléfono provisto (abajo).
Figura 6.16: Datos de registro de acción de prueba para envío de aviso por
luminosidad (arriba), así como el foco de prueba siendo encendido (abajo).
90
Datos \Método de en- Datos agregados en Datos agregados como
vío formato JSON forma HTML
Cookies csrftoken + Error CSRF Error CSRF
sessionid
Header X-CSRFToken Error CSRF Error 403. Acceso
+ csrmiddlewaretoken prohibído
en cuerpo de petición
91
Figura 6.17: Registro de señal generada en la base de datos junto con marca de
tiempo señalada. Esta señal presenta ritmo sinusal normal.
Figura 6.18: Registro de señal con ritmo sinusal normal generado en la base de
datos.
92
Figura 6.19: Directorio de acciones vacío después del registro de una señal con
ritmo sinusal normal.
93
Figura 6.22: Información consultada por el sistema domótico. Como se puede
apreciar esta información está condensada en un objeto JSON, el cual llega co-
mo texto plano al sistema domótico gracias a la plantilla JSON provista por el
entorno de desarrollo de Django REST. En esta imagen se aprecian dos tipos
de acciones siendo consultadas. Para esta prueba se utilizó el primer registro,
un registro de acción generado por la creación de una señal que presenta taqui-
cardia.
94
Figura 6.23: Mensaje de texto recibido en el número de teléfono celular re-
gistrado para una persona de confianza del usuario que registró la señal con
taquicardia.
95
Figura 6.24: Registro de señal que presenta fibrilación ventricular generado en
la base de datos.
96
Figura 6.27: Activación intermitente de de una fuente luminosa debido a la
detección de fibrilación ventricular.
97
Capítulo 7
Conclusiones
98
Las tecnologías utilizadas también nos pueden ofrecer información adicional
acerca de la dirección en la que la tecnología IoT se dirige: modularidad con
estrictos protocolos de comunicación. Por ejemplo, el servidor Django no se
comunica directamente con la plataforma Google Cloud. Este servidor debe
encontrarse dentro de un contenedor Docker, el cual se comunica únicamente
mediante un gateway de peticiones http entre el contenedor y la plataforma.
Finalmente, podemos concluir que los sistemas de monitoreo de salud pueden
beneficiarse al adoptar una arquitectura IoT pues esto permite un mejor manejo
de la información y una mayor capacidad de crecimiento para el sistema. Esto
hablando de crecimiento horizontal (al añadir dispositivos, usuarios o recursos) y
vertical (al poder añadir funcionalidad por medio de las tecnologías utilizadas)
del sistema ya que un enfoque web y distribuido permite un manejo de un
gran número de dispositivos y la adición de nuevas funcionalidades a través de
servicios web.
99
Capítulo 8
Trabajo a futuro
100
Bibliografía
Aazam, M., Khan, I., Alsaffar, A. A. & Huh, E. (2014). Cloud of Things: Inte-
grating Internet of Things and cloud computing and the issues involved.
En Proceedings of 2014 11th International Bhurban Conference on Applied
Sciences Technology (IBCAST) Islamabad, Pakistan, 14th - 18th January,
2014 (pp. 414-419). doi:10.1109/IBCAST.2014.6778179
Akkaya, K. & Younis, M. (2005). A survey on routing protocols for wireless
sensor networks. Ad Hoc Networks, 3 (3), 325-349. doi:https://doi.org/10.
1016/j.adhoc.2003.09.010
Akyildiz, I. F. & Kasimoglu, I. H. (2004). Wireless sensor and actor. We refer to
entities that can act on the network as actors They are sometimes referred
to as actuators in related literature. Networks: research challenges. Ad Hoc
Networks, 2 (4), 351-367. doi:https://doi.org/10.1016/j.adhoc.2004.04.003
Alliance, Z.-W. (2018, diciembre). Z-Wave Alliance. Recuperado desde https:
//z-wavealliance.org/
Alliance, Z. (2018, diciembre). Zigbee is the only complete loT solution, from
the mesh network to the universal language that allows smart objects to
work together. Recuperado desde https://www.zigbee.org/zigbee- for-
developers/zigbee-3-0/
Alnosayan, N., Lee, E., Alluhaidan, A., Chatterjee, S., Houston-Feenstra, L.,
Kagoda, M. & Dysinger, W. (2014). MyHeart: An intelligent mHealth
home monitoring system supporting heart failure self-care. En 2014 IEEE
16th International Conference on e-Health Networking, Applications and
Services (Healthcom) (pp. 311-316). doi:10.1109/HealthCom.2014.7001860
Amazon. (2018, diciembre). SIM900 Quad-band GSM GPRS Shield Develop-
ment Board For Arduino. Recuperado desde https://www.amazon.com/
SIM900-Quad-band-Shield-Development-Arduino/dp/B01M1SWXB1
Ashton, K. (2009). That ’Internet of Things’ Thing. RFiD Journal, 22, 97-114.
Atzori, L. [L.], Iera, A. & Morabito, G. (2014). From "smart objects"to "social
objects": The next evolutionary step of the internet of things. IEEE Com-
munications Magazine, 52 (1), 97-105. doi:10.1109/MCOM.2014.6710070
Atzori, L. [Luigi], Iera, A. & Morabito, G. (2010). The Internet of Things: A
Survey. Comput. Netw. 54 (15), 2787-2805. doi:10.1016/j.comnet.2010.05.
010
101
Atzori, L. [Luigi], Iera, A. & Morabito, G. (2017). Understanding the Internet of
Things: definition, potentials, and societal role of a fast evolving paradigm.
Ad Hoc Networks, 56, 122-140.
Audity. (2018, diciembre). Audity. Recuperado desde http://audity.mx/index.
php
Ben Hamida, S., Ben Hamida, E. & Ahmed, B. (2015). A New mHealth Com-
munication Framework for Use in Wearable WBANs and Mobile Techno-
logies. Sensors (Basel, Switzerland), 15, 3379-408. doi:10.3390/s150203379
Bicking, I. (2018, septiembre). Virtualenv. Recuperado desde ’https://virtualenv.
pypa.io/en/latest/’
Blanchon, B. (2018, noviembre). ArduinoJson. Recuperado desde ’https : / /
arduinojson.org/’
Borthakur, D. (2018, diciembre). HDFS Architecture Guide. Recuperado desde
https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
Botta, A., de Donato, W., Persico, V. & Pescapé, A. (2016). Integration of Cloud
computing and Internet of Things: A survey. Future Generation Computer
Systems, 56, 684-700. doi:https://doi.org/10.1016/j.future.2015.09.021
Bravo, C., Redondo, M. Á., Ortega, M. & Verdejo, M. F. (2006). Collaborative
environments for the learning of design: a model and a case study in
Domotics. Computers & Education, 46 (2), 152-173. doi:https://doi.org/
10.1016/j.compedu.2004.07.009
Bravo, J., Ortega, M. & Verdejo, F. (2000). Planning in problem solving: a case
study in domotics. En 30th Annual Frontiers in Education Conference.
Building on A Century of Progress in Engineering Education. Conference
Proceedings (IEEE Cat. No.00CH37135) (Vol. 1, T2D/11-T2D/16 vol.1).
doi:10.1109/FIE.2000.897612
Center), T. A. L. A. B. B. I. H. ( T. B. I. D. M. (1990). The MIT-BIH Normal
Sinus Rhythm Database. doi:10.13026/C2NK5R
Chavez-Santiago, R., Nolan, K. E., Holland, O., De Nardis, L., Ferro, J. M.,
Barroca, N., . . . Balasingham, I. (2012). Cognitive radio for medical body
area networks using ultra wideband. IEEE Wireless Communications,
19 (4), 74-81. doi:10.1109/MWC.2012.6272426
Chavez, A., Littman-Quinn, R., Ndlovu, K. & Kovarik, C. L. (2016). Using TV
white space spectrum to practise telemedicine: A promising technology to
enhance broadband internet connectivity within healthcare facilities in ru-
ral regions of developing countries. Journal of Telemedicine and Telecare,
22 (4), 260-263. PMID: 26199278. doi:10.1177/1357633X15595324. eprint:
https://doi.org/10.1177/1357633X15595324
Chen, M., Mao, S. & Liu, Y. (2014). Big data: A survey. Mobile Networks and
Applications, 19. doi:10.1007/s11036-013-0489-0
Clarke, C. (2018, julio). Django Pandas. Recuperado desde ’https : / / github .
com/chrisdev/django-pandas’
Cloudera, I. (2018, diciembre). Cloudera Data Science Workbench. Recupe-
rado desde https : / / www . cloudera . com / products / data - science - and -
engineering/data-science-workbench.html
102
Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks.
Commun. ACM, 13 (6), 377-387. doi:10.1145/362384.362685
Community, G. (2018, diciembre). Tiny Os. Recuperado desde https://github.
com/tinyos/tinyos-main
Consortium, O. (2018, diciembre). OpenIoT|Project. Recuperado desde http :
//www.openiot.eu/?page_id=70
Contiki. (2018, diciembre). Contiki: The Open Source OS for the Internet of
Things. Recuperado desde http://www.contiki-os.org/
Darouei, A. & Ayatollahi, A. (2010). Classification of Cardiac Arrhythmias
Using PNN Neural Network Based on ECG Feature Extraction. 25, 309-311.
Demirkol, I., Ersoy, C. & Alagoz, F. (2006). MAC protocols for wireless sen-
sor networks: a survey. IEEE Communications Magazine, 44 (4), 115-121.
doi:10.1109/MCOM.2006.1632658
Domingo, M. C. (2012). An overview of the Internet of Things for people with di-
sabilities. Journal of Network and Computer Applications, 35 (2), 584-596.
doi:https://doi.org/10.1016/j.jnca.2011.10.015
Domotics, A. (2018, diciembre). AM DOMOTICS. Recuperado desde http://
www.amdomotics.com/
Domotics, P. (2018, diciembre). PRIMEDOMOTICS. Recuperado desde https:
//primedomotics.com/
Doost-Mohammady, R. & Chowdhury, K. R. (2012). Transforming healthcare
and medical telemetry through cognitive radio networks. IEEE Wireless
Communications, 19 (4), 67-73. doi:10.1109/MWC.2012.6272425
Dylan, V. (2018, julio). Welcome to django-bootstrap3’s documentation! Recu-
perado desde ’https://django-bootstrap3.readthedocs.io/en/latest/’
Eclipse Foundation, I. (2018, diciembre). OPEN IOT CHALLENGE 5.0. Recu-
perado desde https://iot.eclipse.org/open-iot-challenge/
Eskimon. (2018, noviembre). TemplateHTMLRenderer - TypeError - context
must be a dict rather than ReturnList. #5236. Recuperado desde ’https:
//github.com/encode/django-rest-framework/issues/5236’
Force, I. E. T. (2018, diciembre). Compression Format for IPv6 Datagrams over
IEEE 802.15.4-Based Networks. Recuperado desde https://tools.ietf.org/
html/rfc6282
Fortino, G. [G.], Giannantonio, R., Gravina, R., Kuryloski, P. & Jafari, R.
(2013). Enabling Effective Programming and Flexible Management of Ef-
ficient Body Sensor Network Applications. IEEE Transactions on Human-
Machine Systems, 43 (1), 115-133. doi:10.1109/TSMCC.2012.2215852
Fortino, G. [Giancarlo], Di Fatta, G., Pathan, M. & Vasilakos, A. V. (2014).
Cloud-assisted body area networks: state-of-the-art and future challenges.
Wireless Networks, 20 (7), 1925-1938. doi:10.1007/s11276-014-0714-1
Fortino, G. [Giancarlo], Parisi, D., Pirrone, V. & Fatta, G. D. (2014). Body-
Cloud: A SaaS approach for community Body Sensor Networks. Future
Generation Computer Systems, 35, 62-79. Special Section: Integration of
Cloud Computing and Body Sensor Networks; Guest Editors: Giancarlo
Fortino and Mukaddim Pathan. doi:https://doi.org/10.1016/j.future.
2013.12.015
103
Foundation, D. S. (2018, agosto). django. Recuperado desde ’https : / / www .
djangoproject.com/’
Foundation, T. A. S. (2018, diciembre). Apache Felix iPOJO. Recuperado desde
http://felix.apache.org/documentation/subprojects/apache- felix- ipojo.
html
Frick, M. (2018, diciembre). ISense hardware. Recuperado desde https://github.
com/itm/shawn/wiki/ISense-hardware
Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M. & Ayyash, M.
(2015). Internet of Things: A Survey on Enabling Technologies, Proto-
cols, and Applications. IEEE Communications Surveys Tutorials, 17 (4),
2347-2376. doi:10.1109/COMST.2015.2444095
Gerosa, M., Cannata, A. & Taisch, M. (2009). Assessing the future of manufactu-
ring: the SOCRADES Technology Roadmap. IFAC Proceedings Volumes,
42 (4), 2125-2130. doi:https://doi.org/10.3182/20090603-3-RU-2001.0296
Gia, T. N., Jiang, M., Rahmani, A., Westerlund, T., Liljeberg, P. & Tenhu-
nen, H. (2015). Fog Computing in Healthcare Internet of Things: A Case
Study on ECG Feature Extraction. En 2015 IEEE International Conferen-
ce on Computer and Information Technology; Ubiquitous Computing and
Communications; Dependable, Autonomic and Secure Computing; Perva-
sive Intelligence and Computing (pp. 356-363). doi:10.1109/CIT/IUCC/
DASC/PICOM.2015.51
Goldberger, A. L., Amaral, L. A. N., Glass, L., Hausdorff, J. M., Ivanov, P. C.,
Mark, R. G., . . . Stanley, H. E. (2000). PhysioBank, PhysioToolkit, and
PhysioNet: Components of a New Research Resource for Complex Physio-
logic Signals. Circulation, 101 (23), e215-e220. Circulation Electronic Pa-
ges: http://circ.ahajournals.org/content/101/23/e215.full PMID:1085218;
doi: 10.1161/01.CIR.101.23.e215.
Google. (2018a, diciembre). Google Cloud. Recuperado desde https : / / cloud .
google.com/
Google. (2018b, noviembre). PYTHON EN GOOGLE CLOUD PLATFORM.
Recuperado desde https://cloud.google.com/python/
Google. (2019a, enero). Guía de inicio rápido para Python en el entorno flexible
de App Engine. Recuperado desde https : / / cloud . google . com / python /
getting-started/hello-world?hl=ES
Google. (2019b, enero). Map AWS services to Google Cloud Platform products.
Recuperado desde https://cloud.google.com/free/docs/map-aws-google-
cloud-platform
Goursaud, C. & Gorce, J.-M. (2015). Dedicated networks for IoT : PHY / MAC
state of the art and challenges. EAI endorsed transactions on Internet of
Things. doi:10.4108/eai.26-10-2015.150597
Gutiérrez, D., Toral, S., Barrero, F., Bessis, N. & Asimakopoulou, E. (2013).
The Role of Ad Hoc Networks in the Internet of Things: A Case Scenario
for Smart Environments. (Vol. 460, pp. 89-113). doi:10.1007/978-3-642-
34952-2_4
104
H., S. P. (2010). Consideraciones para la aplicación de la domótica desde la con-
cepción del diseño arquitectónico. Arquiteturarevista, 6, 63-75. Recuperado
desde https://www.redalyc.org/articulo.oa?id=193614471006
Hartman, F. (2018, diciembre). Open Source IoT Cloud. Recuperado desde
https://sites.google.com/site/opensourceiotcloud/
HILL, J. (2019, enero). The smart home: a glossary guide for the perplexed.
Recuperado desde https://www.t3.com/features/the-smart-home-guide
IEEE Standard for Information Technology - Telecommunications and Informa-
tion Exchange Between Systems - Local and Metropolitan Area Networks
Specific Requirements Part 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (LR-WPANs). (2003). IEEE Std 802.15.4-2003, 01 -670.
doi:10.1109/IEEESTD.2003.94389
Inc, T. S. (2018, diciembre). Statics Glossary. Recuperado desde http://www.
statsoft.com/textbook/statistics-glossary/p#Pearson%20Correlation
Inc., C. (2018, diciembre). CloudPlugs Connectiong Things. Recuperado desde
https://cloudplugs.com/iot-platform-overview/
Indrion. (2018, diciembre). IndriyaD P0 3A14. Recuperado desde http://www.
indrion.co.in/datasheet/Indriya_DP_03A14.pdf
Insteon. (2018, diciembre). Insteon: The Technology. Recuperado desde https:
//www.insteon.com/technology/
Instruments, T. (2018, diciembre). ISense hardware. Recuperado desde http://
www.ti.com/wireless-connectivity/certified-wireless-modules/overview/
overview.html
Jahn, M., Pramudianto, F. & Al-Akkad, A.-A. (2009). Hydra middleware for
developing pervasive systems: A case study in the e-health domain, 80-88.
jeffplourde. (2018a, febrero). wfdb file decoding for node.js. Recuperado desde
https://github.com/jeffplourde/wfdb
jeffplourde. (2018b, febrero). WFDB for node.js. Recuperado desde https : / /
www.npmjs.com/package/wfdb
KaaIoT Technologies, L. (2018, diciembre). KAAIOT. Recuperado desde https:
//www.kaaiot.io/
Kale, S. S. & Bhagwat, D. S. (2018). A Secured IoT Based Webcare Healthcare
Controlling System using BSN. En 2018 Second International Conference
on Inventive Communication and Computational Technologies (ICICCT)
(pp. 816-821). doi:10.1109/ICICCT.2018.8473248
Kambourakis, G., Klaoudatou, E. & Gritzalis, S. (2007). Securing Medical Sen-
sor Environments: The CodeBlue Framework Case. En The Second Inter-
national Conference on Availability, Reliability and Security (ARES’07)
(pp. 637-643). doi:10.1109/ARES.2007.135
Kinoma. (2018, diciembre). kinomajs. Recuperado desde https://github.com/
Kinoma/kinomajs
Lang, J.-P. (2018, diciembre). Nano-RK. Recuperado desde http://nanork.org/
projects/nanork/wiki
Li, S., Xu, L. D. & Zhao, S. (2015). The internet of things: a survey. Information
Systems Frontiers, 17 (2), 243-259. doi:10.1007/s10796-014-9492-7
105
libelium. (2018, diciembre). Waspmote overview. Recuperado desde http : / /
www.libelium.com/products/waspmote/overview/
Limited, A. (2018, diciembre). armbed. Recuperado desde https://www.mbed.
com/en/
Lisetti, C. L. & Nasoz, F. (2004). Using Noninvasive Wearable Computers to
Recognize Human Emotions from Physiological Signals. EURASIP Jour-
nal on Advances in Signal Processing, 2004 (11), 929414. doi:10 . 1155 /
S1110865704406192
Ltd, S. (2018, diciembre). Seafile. Recuperado desde https://www.seafile.com/
en/home/
Mainflux. (2018, diciembre). Mainflux. Recuperado desde https://www.mainflux.
com/
Mateos, F., Gonzalez, V. M., Poo, R., Garcia, M. & Olaiz, R. (2001). Design
and development of an automatic small-scale house for teaching domotics.
En 31st Annual Frontiers in Education Conference. Impact on Engineering
and Science Education. Conference Proceedings (Cat. No.01CH37193) (Vol. 1,
T3C-1). doi:10.1109/FIE.2001.963911
Metering, E. W. (2018, diciembre). WAVENIS RADIO. Recuperado desde https:
/ / www . elstermetering . com / en / rf - wavenis - end - points # sbox3408 =
sbox34080;sbox3405=sbox34050;sbox3402=sbox34020;sbox3399=sbox33990;
Microsoft. (2018, diciembre). Microsoft Azure. Recuperado desde https://azure.
microsoft.com/es-mx/
Miorandi, D., Sicari, S., Pellegrini, F. D. & Chlamtac, I. (2012). Internet of
things: Vision, applications and research challenges. Ad Hoc Networks,
10 (7), 1497-1516. doi:https://doi.org/10.1016/j.adhoc.2012.02.016
Miori, V. & Russo, D. (2014). Domotic Evolution towards the IoT. En 2014
28th International Conference on Advanced Information Networking and
Applications Workshops (pp. 809-814). doi:10.1109/WAINA.2014.128
Mitola, J. & Maguire, G. Q. (1999). Cognitive radio: making software radios
more personal. IEEE Personal Communications, 6 (4), 13-18. doi:10.1109/
98.788210
Movassaghi, S., Abolhasan, M., Lipman, J., Smith, D. & Jamalipour, A. (2014).
Wireless Body Area Networks: A Survey. IEEE Communications Surveys
Tutorials, 16 (3), 1658-1686. doi:10.1109/SURV.2013.121313.00064
N. LOFCALI, M. & M. Lundy, G. (1989). A Specification of a CSMA/CD
Protocol Using Systems of Communicating Machines.
Narayanan, R. P., Veedu Sarath, T. & Veetil Vineeth, V. (2016). Survey on Mo-
tes Used in Wireless Sensor Networks: Performance & Parametric Analy-
sis. Wireless Sensor Network, 8, 67-76. doi:10.4236/wsn.2016.84005
National Institute of General Medical Sciences (NIGMS), N. I. o. B. I. & (NI-
BIB), B. (2018a, diciembre). PhysioBank. Recuperado desde https : / /
www.physionet.org/physiobank/
National Institute of General Medical Sciences (NIGMS), N. I. o. B. I. & (NI-
BIB), B. (2018b, diciembre). The WFDB Software Package. Recuperado
desde https://www.physionet.org/physiotools/wfdb.shtml
106
Nolle, F. M. & Bowser, R. W. (1992). Creighton University Ventricular Tach-
yarrhythmia Database. doi:10.13026/C2X59M
Ocean, D. (2018, diciembre). Digital Ocean. Recuperado desde https://www.
digitalocean.com/
of Standards, N. I. & Technology. (2018, diciembre). The NIST Definition of
Cloud Computing. Recuperado desde https://www.nist.gov/publications/
nist-definition-cloud-computing
open-zb.net. (2018, diciembre). IEEE 802.15.4/ZigBee OPNET Simulation Mo-
del. Recuperado desde http://www.open-zb.net/wpan_simulator.php
Oracle. (2018, diciembre). VirtualBox. Recuperado desde https://www.virtualbox.
org/
Otto Mark, f. (2018, julio). Bootstrap. Recuperado desde ’https://getbootstrap.
com/’
Ovh. (2018, diciembre). OVH. Recuperado desde https://www.ovh.com/world/
es/cloud/
ownCloud GmbH. (2018, diciembre). Owncloud. Recuperado desde https : / /
owncloud.com/products/
Pang, Z. & Tian, J. (2014). Ecosystem-driven design of in-home terminals based
on open platform for the Internet-of-Things. En 16th International Con-
ference on Advanced Communication Technology (pp. 369-377). doi:10 .
1109/ICACT.2014.6779195
Patel, M. & Wang, J. (2010). Applications, challenges, and prospective in emer-
ging body area networking technologies. IEEE Wireless Communications,
17 (1), 80-88. doi:10.1109/MWC.2010.5416354
PRETZ, K. (2018, diciembre). The Next Evolution of the Internet. Recuperado
desde http://theinstitute.ieee.org/technology-topics/smart-technology/
the-next-evolution-of-the-internet
Pung, H. K., Gu, T. & Zhang, D. Q. (2004). Toward an OSGi-Based Infras-
tructure for Context-Aware Applications. IEEE Pervasive Computing, 3,
66-74. doi:10.1109/MPRV.2004.19
PyTorch. (2019, enero). PyTorch. Recuperado desde https://pytorch.org/
Raychaudhuri, D., Mandayam, N., B Evans, J., J Ewy, B., Seshan, S. & Steenkis-
te, P. (2006). CogNet–an architectural foundation for experimental cog-
nitive radio networks within the future Internet. doi:10 . 1145 / 1186699 .
1186707
Riaz, M., Attaullah, B. & A, M. (2018). Classification of Attacks on Wireless
Sensor Networks : A Survey. International Journal of Wireless and Mi-
crowave Technologies, 8, 15-39. doi:10.5815/ijwmt.2018.06.02
Rimal, B. P., Choi, E. & Lumb, I. (2009). A Taxonomy and Survey of Cloud
Computing Systems. En 2009 Fifth International Joint Conference on
INC, IMS and IDC (pp. 44-51). doi:10.1109/NCM.2009.218
Roberts, L. G. (1975). ALOHA Packet System with and Without Slots and
Capture. SIGCOMM Comput. Commun. Rev. 5 (2), 28-42. doi:10.1145/
1024916.1024920
107
Rouse, M. (2018, diciembre). IoT Agenda | RFID (radio frequency identifica-
tion). Recuperado desde https://internetofthingsagenda.techtarget.com/
definition/RFID-radio-frequency-identification
S.L., A. S. Y. S. (2018, diciembre). Telosb Sensors. Recuperado desde https:
//telosbsensors.wordpress.com/
Sajid, A., Abbas, H. & Saleem, K. (2016). Cloud-Assisted IoT-Based SCADA
Systems Security: A Review of the State of the Art and Future Challenges.
IEEE Access, 4, 1375-1384. doi:10.1109/ACCESS.2016.2549047
Samsung. (2018a, diciembre). Artik Cloud Services. Recuperado desde https:
//artik.cloud/
Samsung. (2018b, diciembre). ClouT. Recuperado desde http://clout-project.
eu/
Sanchez-Iborra, R. & Cano, M.-D. (2016). State of the Art in LP-WAN Solutions
for Industrial IoT Services. Sensors, 16 (5). doi:10.3390/s16050708
Seo, J. D. (2018, diciembre). probabilistic-neural-network-in-python. Recupera-
do desde https://github.com/JaeDukSeo/probabilistic- neural- network-
in-python
Services, A. W. (2018, diciembre). Amazon Web Services. Recuperado desde
https://aws.amazon.com/es/
Stenberg, D. (2018, febrero). curl. Recuperado desde https://curl.haxx.se/
Syed, A. R. & Yau, K. A. (2013). On Cognitive Radio-based Wireless Body Area
Networks for medical applications. En 2013 IEEE Symposium on Compu-
tational Intelligence in Healthcare and e-health (CICARE) (pp. 51-57).
doi:10.1109/CICARE.2013.6583068
Tan, W., Fan, Y., Ghoneim, A., Hossain, M. A. & Dustdar, S. (2016). From the
Service-Oriented Architecture to the Web API Economy. IEEE Internet
Computing, 20 (4), 64-68. doi:10.1109/MIC.2016.74
Tao, F., Cheng, Y., Xu, L. D., Zhang, L. & Li, B. H. (2014). CCIoT-CMfg: Cloud
Computing and Internet of Things-Based Cloud Manufacturing Service
System. IEEE Transactions on Industrial Informatics, 10 (2), 1435-1442.
doi:10.1109/TII.2014.2306383
Team, P. C. (2018, agosto). Python Data Analysis Library. Recuperado desde
’http://pandas.pydata.org/index.html’
Technology, C. M. (2018, diciembre). MICA2 Basic Kit (MOTE-KIT4x0). Recu-
perado desde http://www.cmt-gmbh.de/Produkte/WirelessSensorNetworks/
MICA2_%20Basic_Kit.html
Tom Christie, E. (2018, julio). Django REST framework. Recuperado desde
’https://www.django-rest-framework.org/’
Union, I. T. (2018, diciembre). A Universally Unique IDentifier (UUID) URN
Namespace. Recuperado desde https://www.ietf.org/rfc/rfc4122.txt
Visconti, P., Primiceri, P., Ferri, R., Pucciarelli, M. & Venere, E. (2017). An
Overview on State-of-art Energy Harvesting Techniques and Choice Cri-
teria: a WSN Node for Goods Transport and Storage Powered by a Smart
Solar-based EH System. International Journal of Renewable Energy Re-
search, 7, 1281-1295.
108
VMWare, I. (2018, diciembre). Workstation Pro. Recuperado desde https : / /
www.vmware.com/mx/products/workstation-pro.html
W3C. (2018, diciembre). Web Services Description Language (WSDL) Version
2.0 Part 1: Core Language. Recuperado desde https://www.w3.org/TR/
wsdl/
Wan, J., Zou, C., Ullah, S., Lai, C., Zhou, M. & Wang, X. (2013). Cloud-
enabled wireless body area networks for pervasive healthcare. IEEE Net-
work, 27 (5), 56-61. doi:10.1109/MNET.2013.6616116
Wang, J., Ghosh, M. & Challapali, K. (2011). Emerging cognitive radio appli-
cations: A survey. IEEE Communications Magazine, 49 (3), 74-81. doi:10.
1109/MCOM.2011.5723803
Yang Hao, R. F. (2008). Wireless body sensor networks for health-monitoring
applications. Physiological Measurement, 29 (11), R27. Recuperado desde
http://stacks.iop.org/0967-3334/29/i=11/a=R01
Zhang, M. & Sawchuk, A. A. (2009). A customizable framework of body area
sensor network for rehabilitation. En 2009 2nd International Symposium
on Applied Sciences in Biomedical and Communication Technologies (pp. 1-6).
doi:10.1109/ISABEL.2009.5373703
Zhang, Z. & Hu, X. (2013). ZigBee based wireless sensor networks and their
use in medical and health care domain. En 2013 Seventh International
Conference on Sensing Technology (ICST) (pp. 756-761). doi:10 . 1109 /
ICSensT.2013.6727754
Zuhra, F. T., Bakar, K. A., Ahmed, A. & Tunio, M. A. (2017). Routing protocols
in wireless body sensor networks: A comprehensive survey. Journal of
Network and Computer Applications, 99, 73-97. doi:https://doi.org/10.
1016/j.jnca.2017.10.002
109