Está en la página 1de 112

Sistema domótico utilizando una red de sensores

corporal

José Francisco Beltrán Chávez

8 de enero de 2020
Resumen

En este documento se describe el diseño e implementación de un sistema do-


mótico con un enfoque de Internet de las cosas (IoT por sus siglas en ingles),
utilizando una red de sensores corporal (BSN en inglés) para monitoreo de se-
ñales fisiológicas. El caso de estudio propuesto involucra el monitoreo de una
señal cardiaca para detección de anomalías obtenida a partir de una BSN uti-
lizada por una persona. La BSN se simuló usando cadenas de Markov con el
propósito de evaluar el desempeño y consumo de energía de dicha red. A la par,
el sistema domótico se diseñó con dos áreas de la Domótica en mente: la conec-
tividad y el bienestar. El monitoreo de la señal cardiaca se realiza a través de
conectividad inalámbrica usando servicios web hacia una entorno de cómputo
en la Nube. En donde se procesa la señal utilizando una red neuronal (percep-
tron) para detectar anomalías en la señal (e.g. una arritmia) Los datos de la
señal electrocardiográfica se obtuvieron de las bases de datos de la plataforma
Physionet. Si se identifica una anomalía en la señal electrocardiográfica, se dis-
para un evento que indica al sistema domótico realizar dos posibles tareas: envío
de un mensaje de texto a una persona desginada por el usuario, indicando el
estado detectado en la señal cardiaca y activar una alerta luminosa o sonora
en el entorno del usuario monitoreado. Este último evento está enfocado en el
bienestar provisto por el sistema domóticos pues impacta de forma directa en
el entorno del usuario. Se realizaron pruebas modulares y e integrales al siste-
ma, se comprobó el porcentaje de éxito de clasificación de la red neuronal, se
logró conectividad a través de un sistema de servicios web orientados a IoT y se
logró la activación del sistema domótico a partir de un eventos generados por
la red neuronal. Finalmente, se propuso como trabajo a futuro como analizar
otras señales fisiológicas, implementar otros protocolos de mensajes de la BSN
y una implementación física de la misma. La aportación de este trabajo es el
vinculo entre un sistema Domótico con una BSN gracias al uso de tecnologías de
desarrollo Web que en conjunto pueden ofrecer a los usuarios retroalimentación
directa con base en su información fisiológica.
Abstract

In this document is described the design of a domotic system with an Internet of


Things focus that uses a Body Sensor Network (BSN) to monitor physiological
signals. The proposed case of study involves monitoring of a cardiac signal, com-
ing from the BSN, in order to detect anomalies. The BSN was simulated with
help of a Markov chain and had the purpose of evaluating the throughput and
energy consumption of said BSN. At the same time, the domotic system revolved
around two of the main interests of Domotics: connectivity and well being. The
cardiac signal monitoring is done through web services located in a Cloud server
and accesed by wireless connectivity. In said server the signal is processed by
a Neural Network (a Perceptron) in order to detect specific anomalies (i.e. ar-
rhythmia). Electrocardiographic signals data was obtained from databases that
belong to the Physionet platform. If an anomaly is identified in an electrocar-
diographic signal an event is triggered, wich instructs the Domotic system to do
one of two possible tasks: Sending an SMS message to a person designated by
the monitored user stating the detected anomaly or activating an alert in the
environment of the monitored user, said alert being luminous or sonorous. This
last possible task of the Domotic system is specially related to the well being
of the users since it has a direct impact on their environment. Modular and
integral tests were made on the system, classification succes rates of the Neural
Network were determined, connectivity through an IoT oriented web services
architecture was achieved and Domotic actions were performed based on Neural
network generated events. Finally, future work is proposed, in wich the analysis
of other physiological signals, the implementation of other protocols on the BSN
and a physical implementation of a BSN is proposed. The mayor advancement
of this system is the link between BSN and Domotic technologies through the
use of Web development tools that as a whole can provide users direct input
based on their physiological data.
Índice general

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

2. Estado del arte 13


2.1. Redes de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Sistemas cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3. Big Data y aprendizaje de máquina . . . . . . . . . . . . . . . . . 16
2.4. Entornos o ambientes IoT . . . . . . . . . . . . . . . . . . . . . . 17
2.5. Tipos de Arquitecturas en IoT . . . . . . . . . . . . . . . . . . . 18
2.6. Domótica en entornos IoT . . . . . . . . . . . . . . . . . . . . . . 20
2.7. Comunicación máquina-a-máquina y su relación con IoT . . . . . 21
2.8. Entornos de IoT en la Salud . . . . . . . . . . . . . . . . . . . . . 23

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

8. Trabajo a futuro 100

2
Índice de figuras

1.1. Gráfica de las tecnologías que generaron expectativa en el año


2017 según la empresa Gartner. . . . . . . . . . . . . . . . . . . . 10

2.1. Ciclo de operación de un radio cognitivo convencional . . . . . . 22

3.1. Ejemplo de la estructura de un sistema considerado IoT . . . . . 26


3.2. Ejemplo de un sistema RFID. . . . . . . . . . . . . . . . . . . . . 27

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

5.1. Diagrama Arquitectural en entorno IoT con capas. . . . . . . . . 37


5.2. Diagrama de flujo de la implementación del protocolo Aloha ra-
nurado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3. Diagrama de flujo: implementación del protocolo de medición
energética. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.4. Modelo entidad-relación. . . . . . . . . . . . . . . . . . . . . . . . 42
5.5. Modelo entidad-relación generado a partir de los objetivos del
proyecto con cardinalidad entre entidades indicada. . . . . . . . . 43
5.6. Modelo entidad-relación generado a partir de los objetivos del
proyecto con atributos de entidades señalados. . . . . . . . . . . . 43
5.7. Propuesta inicial de diagrama relacional con tablas de base de
datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.8. Diagrama relacional normalizado. . . . . . . . . . . . . . . . . . . 46
5.9. Protocolo de ejecución de tareas por parte del sistema domótico. 48
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
5.11. Gráfica que muestra los valores transmitidos por la red de senso-
res 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

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

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
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
6.3. Comparación entre el tiempo necesario para la transmisión de
información por parte de todos los nodos medida en la simulación
del protocolo (izquierda) y en el modelo matemático (derecha). . 79
6.4. Datos obtenidos al consultar un directorio del sitio web, especí-
ficamente el directorio de acciones. Como se puede apreciar los
datos son los mismos, simplemente cambia la presentación de los
mismos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.5. Cookies obtenidas por la red de sensores al iniciar sesión en el
servidor 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
6.6. Fragmento de archivo con formato de valores separados por co-
mas que contiene las características extraídas de señales aleato-
rias que pertenecen a las clases ritmo sinusal normal, firbrilación
ventricular y taquicardia ventricular. . . . . . . . . . . . . . . . . 82

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

3.1. Paradigmas que surgen de la mezcla de tecnologías de Redes de


sensores inalámbricas e Internet de las cosas. Extraída de (Botta
y col. 2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.1. Parámetros de ejecución de la simulación del protocolo S-ALOHA.


Cada ejecución de la simulación es realizada con una combinación
de dos parámetros sacados de las columnas de esta tabla. . . . . 78
6.2. Pruebas de ejecución de métodos no seguros desde la red de sen-
sores hacia el servidor Django con diferentes parámetros de inicio,
valores de token csrf y formas de presentación de la información. 91

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.

1.3.1. Caso de estudio


El caso de estudio se desarrolla el monitoreo de señales cardiacas , identifi-
cación de una arritmia ( en el caso de detectarlas) cuando es detectada dicha
anomalía, se reacciona en el sistema domótico con el envío de un mensaje SMS
a medio y familiar, y en un casa habitación se dispara una alarma eléctrica
o sonora. Otros trabajos se ha dirigido para la interpretación de señales fisio-
lógicas (Giancarlo Fortino, Di Fatta y col. 2014) o usando enfoques similares
(Yang Hao 2008). Cabe mencionar que los proyectos analizados en estado del
arte, no tienen como prioridad enviar alertas o notificar anomalías durante el

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.4.2. Objetivos Particulares


Realizar la simulación de una red de sensores corporal que permita la
evaluación de desempeño de consumo energético de la misma.
Generar un sistema que administre la información obtenida por la red de
sensores corporal y se despliegue en una interfaz gráfica.
Diseñar una arquitectura de comunicación basada en servicios web que
sirva como comunicación entre un servidor web y el resto del sistema.
Diseñar un módulo de generación de mensajes SMS y de activación de
alarmas con comunicación al servidor de nube.
Procesar los datos obtenidos de la BSN usando redes neuronales para la
identificación de arritmias y taquicardia.

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

Estado del arte

Actualmente, uno de los retos que existen en entornos o ambientes IoT es


la obtención de direcciones URL hacia información detallada de dispositivos de
sensado y desde los dispositivos hacia la información misma. Otro reto impor-
tante es la caracterización de las redes de sensores y como la integración de los
nodos con el internet puede presentar problemas en la integración del sistema
(Luigi Atzori y col. 2010). Estos dos retos son centrales para el trabajo propues-
to en esta tesis puesto que los avances de la tecnología en recientes años han
provisto herramientas que permiten abordarlos. Aunado a los retos mencionados
previamente, es necesario mencionar una problemática fundamental presente en
entornos IoT, la cual es ofrecer una arquitectura que permita a dispositivos de
baja capacidad y con altas capacidades de conexión interactuar con tecnologías
de comunicación estándar, tales como los Servicios Web. Un enfoque que bus-
ca resolver dicho reto se encuentra en el envío de mensajes asíncronos usando
esquemas de tipo middleware. (Miorandi y col. 2012). Por ello, a diferencia de
los trabajos anteriores, en esta tesis, se ofrece una solución a esta problemáti-
ca conectando servicios web entre un modulo domótico y una red BSN usando
Computo en la Nube para tal efecto. Por otra parte, SoA(Service Oriented Ar-
chitecture) es aún un gran reto para IoT en donde los objetos ligados a servicios
pueden llegar a sufrir en cuestión de costo o rendimiento, además que la creación
automática de servicios a partir de requisitos de aplicaciones es aún un reto. (Li
y col. 2015). En contraste, en esta tesis se utiliza el paradigma de servicios JSON
para trabajar con los esquemas de comunicación.
El análisis IoT involucra diversas áreas de investigación y de tecnologías
que han visto un gran auge en los últimos años, como son la redes de senso-
res, las arquitecturas de comunicación, el computo en la nube, los servicios de
comunicación e incluso la Domótica.

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.

2.2. Sistemas cloud


Una vez analizada la primer generación de las tecnologías IoT, es necesario
revisar los avances hechos en la segunda generación representada por los siste-
mas cloud. Donde algunos autores han acuñado algunos términos para reflejar su
estrecha relación con el concepto IoT, como CloudIoT(Aazam y col. 2014; Botta
y col. 2016) o CCIoT(Tao y col. 2014). Google(Google 2018a, diciembre), Ama-
zon(Services 2018, diciembre) o Microsoft(Microsoft 2018, diciembre), los cuales
ofrecen servicios Cloud de forma plataforma como servicio (Paas), es decir, que
uno puede contratar sus servicios de cómputo y ejecutar sobre su plataforma

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).

2.3. Big Data y aprendizaje de máquina


Grandes empresas ya tienen presencia de forma notable en el campo del Big
data, tales como Data Lakes de Amazon Web Services, Big Data Analytics So-
lutions de Google Cloud y Oracle Big Data Cloud de Oracle. En la actualidad el
Big Data se encuentra en una etapa de estabilidad y la investigación relativa a es-
te campo se enfoca mayormente en su integración como herramienta para algún
fin en lugar de desarrollo en el mismo (Chen y col. 2014). Por ejemplo, existen
herramientas de trabajo enfocadas para análisis de grandes cantidades de datos
como Cloudera Data Science Workbench (Cloudera 2018, diciembre) o Hadoop
HDFS (Borthakur 2018, diciembre) las cuales además proveen herramientas que
facilitan la implementación de algoritmos de aprendizaje de máquina.

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.

2.5. Tipos de Arquitecturas en IoT


En cuanto a arquitecturas se refiere, el IoT ha sido objeto de muchas pro-
puestas respecto al enfoque que estas deben tomar, entre dichos enfoques el
más sobresaliente es arquitectura orientada a servicios(SOA) (Luigi Atzori y col.
2017; Al-Fuqaha y col. 2015). Muchos autores mencionan un reducido número
de propuestas de arquitectura, las cuales son muy similares entre sí. Por citar
algunos ejemplos, la arquitectura propuesta por (Li y col. 2015) está compues-
ta de cuatro capas: sensado, red, servicio e interfaz, la segunda propuesta está
compuesta de tres capas: percepción, red y capa de servicios o de aplicación (Do-
mingo 2012), la tercer propuesta es una de las mencionadas por (Miori y Russo
2014), la cual de igual manera consiste en tres capas: aplicación, red y sensado.
Estas tres propuestas provienen de tres distintos enfoques, la primera es una ar-
quitectura general utilizada en la mayoría de los sistemas IoT con enfoque SOA,
la segunda es una arquitectura enfocada a apoyar a personas con discapacidades
por medio de la toma de métricas y uso de actuadores en su entorno, la última
arquitectura mencionada es una de las arquitecturas mostradas como modelo
para un sistema domótico completo. Este punto será analizado nuevamente en
el capítulo 4. Como se puede ver, las propuestas anteriores comparten muchas
similitudes en estructura, pero también lo hacen en funcionamiento. A continua-
ción se hace una lista de las características importantes de las implementaciones
de dichas capas de arquitectura. La capa de sensado, es regularmente una ca-
pa caracterizada por una WSN, una BSN o una combinación de ambas. Como
se mencionó en secciones anteriores, las tecnologías predominantes en esta capa
son nodos enfocados en optimización con protocolos a la medida. Un detalle que
es importante resaltar es el hecho del uso de identificadores únicos universales
(Union 2018, diciembre) sugeridos por algunos autores los cuales surgen como
propuesta ante el potencial que tienen los sistemas IoT de crecer especialmente
en esta capa de sensado. En la capa de red aparte de englobar la interconexión
de dispositivos también se puede programar la agregación de datos, así como
comportamientos de descubrimiento de dispositivos y despliegue, mantenimien-
to y programación de acciones y comportamientos entre dispositivos y servicios.
Esta capa algunos autores la separan de la anterior debido a que los comporta-
mientos antes mencionados suelen ser ejecutados por el gateway de la red. La
capa de servicios o middleware, es la que se encarga del reuso de recursos y pro-

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.

2.6. Domótica en entornos IoT


Un área que no suele ser considerada directamente como una tecnología clave
del IoT es la domótica. Esta área ha sido mayormente dominada por la industria
privada en los últimos años y suele ser presentada como una solución integral
por medio de productos de dichas empresas. No existe una definición formal
de lo que el término domótico representa, sin embargo, debido al considerable
periodo de tiempo que lleva en uso se puede extrapolar una definición completa
de lo que este término engloba (C. Bravo y col. 2006; J. Bravo y col. 2000;
H. 2010; HILL 2019, enero; Mateos y col. 2001). La domótica es un concepto,
proveniente de la mezcla de casa ”domus” y robótica, que involucra distintas
tecnologías, principalmente actuadores y electrodomésticos que tiene como fin
ofrecer comfort, seguridad y control de recursos al hogar de los usuarios de
dichos sistemas. Las soluciones puramente domóticas actualmente ofrecidas son
ofrecidas por grandes empresas las cuales ofrecen sistemas a través del esquema
arquitectura como servicio(ASAS). Estos servicios son robustos y tienen gran
escalabilidad en almacenamiento y rendimiento, sin embargo, dependen de una
cierta suma de dinero para poder recibir soporte especializado y además están
pensados para ofrecer soluciones generales a empresas, lo cual impide la adopción
de medidas a corto plazo para atender los retos que la comunidad científica
prevea. Como se mencionó en el capítulo anterior, al igual que con las redes
de sensores, hay muchos factores que determinan el protocolo a utilizar en una
aplicación de dispositivos de baja gama, desde las capacidades de transmisión
hasta la topología de la red. Se mencionó que los principales protocolos utilizados
en redes de sensores son ZigBee y 6LowPAN pero cabe añadir los protocolos Z-
Wave (Z.-W. Alliance 2018, diciembre), INSTEON (Insteon 2018, diciembre), y
Wavenis (Metering 2018, diciembre), los cuales, a diferencia de los mencionados
previamente, están diseñados y optimizados específicamente para aplicaciones
domóticas. En la primer sección de este capítulo, cuando se habla de redes
de sensores los sistemas tienden a considerar el ‘nodo principal’, gateway, o el
destino de los datos en la red de sensores como la fuente de datos de menor
gama en la jerarquía del sistema; es decir, los sistemas solamente consideran
al nodo principal dentro de su arquitectura, no a la red de sensores completa.
Esto ha sido abordado desde un punto de vista de redes de sensores y es en la
actualidad uno de los temas en investigación, sin embargo, no hay algún tema

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.

2.7. Comunicación máquina-a-máquina y su re-


lación con IoT
Uno de los retos que surgen del uso de dispositivos de baja gama que utilizan
interconexiones inalámbricas es la administración óptima del ancho de banda.
Este problema ha sido sujeto de estudio desde distintos puntos de vista, los
cuales abarcan, como se mencionó anteriormente, desde protocolos de acceso
al medio hasta hardware especializado. Laprincipal área de conocimiento que
aborda estos problemas es la de la tecnología máquina a máquina (Machine to
machine o M2M) la cual actúa como una de las tecnologías que permiten la
consolidación del IoT como plataforma autoconfigurable y relmente inteligente.
Sin embargo, su inclusión dentro del paradigma IoT incrementa uno de los
problemas inherentes del IoT: interoperabilidad entre soluciones heterogéneas
con características fijas de fabricante.
Uno de los principales avances en cuanto a la unión de tecnologías M2M y IoT
es el radio cognitivo, o cognitive radio, el cual representa un área de crecimiento
para redes que necesiten operar sin mantenimiento regular o que necesiten adap-
tarse en un lapso de tiempo relativamente corto. Cognitive Radio es un término
acuñado por Joseph Mitola (Mitola y Maguire 1999), el cual describe dispo-
sitivos que pueden adaptar su funcionamiento con base en las características
del entorno de radiofrecuencia en el que operan, así como aprender de previas
experiencias y planear futuras acciones acorde a ello. Según esta definición, un
dispositivo de radio cognitivo debe mostrar las siguientes características cog-
nitivas: auto conocimiento, inteligencia, aprendizaje, memoria, adaptabilidad y
eficiencia. Esta tecnología toma como base la tecnología de radio definido por
software, la cual se basa en la tecnología de radios digitales que definen sus
características de transmisión a partir de software. Y a su vez, la tecnología
de radio cognitivo sirve como la base para la tecnología de redes cognitivas
(Raychaudhuri y col. 2006), las cuales representan una extrapolación a nivel de
red de las funcionalidades modulares de un radio cognitivo. Como se mencionó
previamente, el factor definitivo que distingue el radio cognitivo es el factor de
aprendizaje. Este aprendizaje depende de ciertos componentes, específicamente
radio, sensores, base de datos de conocimiento, algoritmo de aprendizaje y motor
de razonamiento. Mediante estas herramientas el radio cognitivo primero realiza
un análisis y evaluación de su entorno y con base en ello decide la forma óptima
de acción, la cual depende de su rol en la red y puede ser de dos tipos: usuarios
primarios y usuarios secundarios. Los usuarios primarios son los usuarios bajo
licencia del canal y tienen prioridad de transmisión mientras que los usuarios
secundarios son usuarios que esperan a que los usuarios primarios desocupen el
canal para competir por él. Aunque el ciclo de operación de un radio cogniti-

21
Figura 2.1: Ciclo de operación de un radio cognitivo convencional

vo puede variar, generalmente todos siguen la misma secuencia, mostrada en la


2.1. Existen tres tipos diferentes de radios cognitivos: radios con funcionamiento
basado en póliza, radios cognitivos procedurales y radios cognitivos ontológicos.
Los radios que funcionan bajo póliza lo hacen bajo un conjunto estricto de re-
glas, las cuales priorizan a los usuarios principales y deben ser respetadas por
los usuarios secundarios. Este tipo de radios no suelen implementar las etapas
de razonamiento o aprendizaje. Los radios cognitivos procedurales utilizan al-
goritmos predefinidos diseñados para actuar de cierta forma cuando el canal se
encuentra en un determinado estado. Este tipo de radios tienen un rango limi-
tado de razonamiento y un casi nulo proceso de aprendizaje. Finalmente, los
radios cognitivos ontológicos utilizan lenguajes de programación más sofictica-
dos que les permiten implementar completamente las etapas de razonamiento y
aprendizaje mediante la abstracción de entidades y la relación entre estas.
En cuanto a las redes cognitivas estas se dividen en centralizada, donde una
entidad en la red dicta las reglas que se deben seguir dentro de la misma y
coordina los dispositivos dentro de la misma; y Ad-hoc donde, debido a la falta
de una entidad central reguladora, los dispositivos toman decisiones autónomas.
Esta tecnología ha sido aplicada en un gran número de campos, desde la
milicia hasta la planeación de ciudades. Siendo uno de estos campos la salud y
el monitoreo. En este campo se pueden ver diversos avances, donde de hecho
se crea un nuevo término para las redes médicas de área corporal o MBAN.
En la actualidad las aplicaciones de MBAN se apoyan en dos distintas bandas:
MedRadio y WMTS (Patel y Wang 2010). Y este hecho ha impulsado distintos
esfuerzos, por ejemplo el trabajo mostrado en (Doost-Mohammady y Chowd-
hury 2012) está enfocado en una red cognitiva que utiliza la banda WMTS para
hacer telemetría médica de usuarios mediante un enfoque prioritario a usuarios
primarios y soporte QoS para ambos tipos de usuario. Otro proyecto similar es
el proyecto “Kgolagano”, el cual utiliza los espacios de ruido blanco del espectro
televisivo para realizar telemedicina (Chavez y col. 2016). En menor escala se
encuentran otros esfuerzos, como los mostrados (Chavez-Santiago y col. 2012;
Doost-Mohammady y Chowdhury 2012; Syed y Yau 2013) donde los nodos de

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.

2.8. Entornos de IoT en la Salud


El área principal de esta tesis, son las telecomunicaciones enfocadas en IoT,
pero su caso de estudio tiene aplicación médica y por lo tanto es necesario hacer
una revisión de los proyectos que utilicen BSN, entornos cloud y que se ubiquen
en un marco de referencia médico o relativo a la salud. Uno de los principa-
les estudios relacionados al propuesto en este documento es SPINE (G. Fortino
y col. 2013). El cual parte del hecho de que las BSN regularmente utilizan una
PC o un teléfono inteligente como gateway o salida de datos y por eso las apli-
caciones comunes de BSN suelen tener dos filosofías en mente: programación de
bajo nivel y middleware de propósito general. El acercamiento más común es
desarrollar en los nodos servicios específicos con la lógica de negocios, lo cual
vuelve la corrección de errores y el diagnóstico de problemas una tarea com-
plicada. Otro acercamiento es generar frameworks de propósito general para
redes de sensores. Estos frameworks consisten en una serie de servicios imple-
mentados a través de la red. Esto permite ocultar la complejidad de las capas
inferiores del sistema y acceder a sus funciones mediante servicios accesibles
a través del gateway de esta capa. El problema de esta filosofía es que al ser
compatible con muchas aplicaciones carece de abstracciones específicas para sis-
temas BSN o exigen demasiados recursos de los nodos como para que puedan
generarse aplicaciones BSN eficientes. Dicho lo anterior, surge un nuevo para-
digma a partir de la investigación en estos frameworks: desarrollar frameworks
de dominio específico. SPINE surge como solución a ello pues es una plataforma
de prototipado de aplicaciones BSN enfocada en proveer eficiencia del sistema,

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

3.1. Internet de las cosas


Como se mencionó en el primer capítulo, no existe una definición concreta
del concepto IoT acuñado por (Ashton 2009). Sin embargo existen distintas de-
finiciones que se han aceptado con el paso del tiempo, por ejemplo la ofrecida
por (PRETZ 2018, diciembre) que indica que el internet de las cosas es una
red inalámbrica donde las cosas están conectadas entre sí. Esta definición pa-
rece adecuada ya que uno de los principales objetivos del IoT suele ser obtener
información del entorno, de las cosas mismas. Esta tecnología, en conjunto, es
difícil de definir, sin embargo, como lo señalan (Luigi Atzori y col. 2017; Al-
Fuqaha y col. 2015; Li y col. 2015), existen tecnologías clave que nos pueden
ayudar a definir o a identificar esta clase de sistemas. Siendo estas tecnologías
las redes de sensores, los sistemas de cómputo cloud y Big Data. Cada una de
estas tecnologías puede verse como el punto de partida de desarrollo tecnológico
de determinados periodos temporales. Además, estas tecnologías ayudan a ses-
parar los sistemas en bloques funcionales enfocados en determinadas acciones.
Algunos autores separan estos bloques o capas dependiendo de su funcionalidad,
sin embargo, el concenso general coincide en las capas: sensado, red, servicios e
interfaz.
La red de sensado suele estar representada por alguna variante de BSN y
cumple la función de extraer datos de algún fenómeno y transmitirlos a
la siguiente capa. En esta capa el componente más importante es el nodo
BSN pues este se encarga de extraer información por medio de sensores y,
si es pertinente, realizar alguna acción simple con dicha información, ya
sea filtrado o rectificación, entre otras
La capa de red suele comenzar con el gateway de la BSN y representa la
forma en la que la información se dirigirá hacia su destino. En esta capa
los protocolos de red internos de la BSN y los protocolos de comunicación
hacia capas superiores son los componentes más importantes.

25
Figura 3.1: Ejemplo de la estructura de un sistema considerado IoT

La capa de servicios es la capa que se encarga de administrar la información


generada por la capa de sensado. Esta capa en la gran mayoría de los casos
suele estar representada por un servidor web que expone sus servicios
mediante servicios web, los cuales suelen ser accesados por el gateway de
la BSN. En esta capa se encuentra la lógica de negocio y suele encontrarse
también la persistencia de datos.
La capa de interfaz representa la interacción del sistema con otros agentes,
ya sean sistemas con capacidades de comunicación similares o usuarios
finales del sistema.
Cada una de estas capas puede abarcar un gran número de tecnologías y me-
todologías, lo cual, como lo menciona (Luigi Atzori y col. 2010) vuelve a esta
tecnología ”un paradigma con muchas visiones”. La 3.1 muestra un ejemplo ge-
neral de la arquitectura genérica propuesta para un sistema IoT. Aunque, el
concepto IoT se enfrenta actualmente a una serie de retos que la misma arqui-
tectura SOA presenta, por ejemplo la falta de adaptabilidad frente a cambios
constantes en el tamaño de los componentes del sistema, la falta de un estándar
para la descripción y creación de servicios y el hecho de que generalmente IoT
está desarrollado en tecnologías de información y comunicación tradicionales
lo cual limita adoptar nuevas tecnologías debido a la necesidad de retrocom-
patibilidad. Estos retos son inherentes a las tecnologías y filosofías mayormente
presentes en sistemas IoT, porlo tanto, es de vital importancia tenerlos en mente
al diseñar un sistema de dicha naturaleza. A continuación se ahonda en cada una
de las capas de los sistemas IoT y se detallan las tecnologías que las componen.

3.1.1. Capa de sensado


Esta capa, como se mencionó antes, está representada por métodos de ob-
tención de datos del entorno en algúna posición específica. Ya sea la obtención
de la posición exacta de una caja en un almacén o la medición de humedad en
una habitación, esta capa se encarga de obtener dichos parámetros y enviarlos

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.

3.1.2. Sistemas cloud


De acuerdo a la definición de (of Standards y Technology 2018, diciembre)
”El cómputo en la nube es un modelo que permite acceso a la red de forma ubi-
cua, conveniente y en demanda a un grupo compartido de recursos configurables
de cómputo (por ejemplo, redes, servidores, almacenamiento, aplicaciones, y ser-
vicios) el cual puede ser rápidamente provisto y liberado con el mínimo esfuerzo
de administración o interacción por parte del proveedor de servicios”. Dicha fuen-
te da un ejemplo de las capas de Cloud computing: hardware, infraestructura,
plataforma y aplicación. Cada una de estas capas funciona como un proveedor
de servicios para la capa superior a ella y como consumidor para la capa inferior.
Estas plataformas Cloud pueden ofrecer sus servicios como Software como ser-
vicio (SaaS), Plataforma como servicio (PaaS) e Infraestructura como servicio
(IaaS). Otro tipo de clasificación de los sistemas en la nube se basa en el tipo
de acceso que se tiene a ella. Ya sea privada, comunitaria, pública, híbrida o
cloud virtual privada (Rimal y col. 2009). Estas distintas clasificaciones surgen
a partir de las distintas necesidades de los sistemas que se apoyan en estructuras
de nube para cumplir con sus objetivos, y aunque dichas clasificaciones disten
mucho entre sí, todas ellas están enfocadas en el uso de servicios de distinta
naturaleza para lograr conectividad con otros sistemas.

Manejo de servicios en IoT


Un servicio es un conjunto de datos y comportamientos asociados para cum-
plir con una función específica o característica de algún dispositivo o porción
de un dispositivo. Inclusive algunos servicios pueden estar compuestos por otros
servicios. Para la creación e implementación de un servicio se suelen seguir los
siguientes pasos: crear plataformas de composición de servicios, abstraer las ca-
pacidades de comunicación y funciones del dispositivo y proveer un conjunto
común de servicios. De esta forma en IoT se pueden tener instancias de ob-
jetos virtuales y físicos interactuando mediante servicios en una arquitectura
orientada a servicios y consciente de contexto.

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

Cuadro 3.1: Paradigmas que surgen de la mezcla de tecnologías de Redes de


sensores inalámbricas e Internet de las cosas. Extraída de (Botta y col. 2016)

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.

3.2. Monitoreo de salud


Una de las formas de obtención de información de personas que ha tenido
gran auge en los últimos años ha sido la de las redes de sensores corporales. Este
campo ha sido ampliamente estudiado, al ser de carácter inalámbrico presenta
retos no sólo en el rendimiento y el transporte de datos a través de la red,
sino también en el acceso al medio y la conservación de energía tanto en la red
como en cada uno de los nodos. Las redes de sensores corporales (BSN, Body
Sensor Network) o bien redes de área corporal (BAN, Body Area Network),
las cuales se caracterizan como redes de sensores utilizadas en el cuerpo de los
usuarios principalmente para obtener datos fisiológicos de ellos. Por otra parte,
la Domótica se integra en esta tesis, con una BSN con el propósito de dotar
de inteligencia al proceso de deteccion de anomalias en una señal cardiaca, se
actue en consecuencia en el sistema domotica al ser detectada la anomalia. La
domotica ha sido abarcada en diversos trabajos que implican la transmisión e
interpretación de información proveniente de hogares o ubicaciones específicas
(Miori y Russo 2014), además que ha sido el punto focal de mercado de distintas
empresas de tecnología en la actualidad. Estas soluciones prefabricadas incluyen
distintos tipos de aplicación desde control de iluminación y ventilación hasta
monitoreo del hogar y cerraduras (Audity 2018, diciembre; A. Domotics 2018,
diciembre; P. Domotics 2018, diciembre).

31
Capítulo 4

Metodología y Desarrollo

4.1. Entorno IoT para BSN y Domótica


En esta tesis se desarrollará una metodología para que un sistema obtenga
señales fisiológicas de una persona, las analice y sea capaz de detectar anomalías
en la señal, y cuando esto ocurra, reaccione activando alguna acción en un
sistema domótico. El caso de estudio propuesto está enfocado en monitoreo de
electrocardiogramas para detección de arritmias y fibrilación ventricular.
La metodología de esta tesis es modular y está compuesta de los siguientes
módulos:
Capa de BSN, red de sensores corporal, la cual es configurable para poder
conocer a priori su desempeño energético.

Capa de Servicios Web.


Capa de Nube y Aprendizaje (Servidor Nube y Red neuronal).
Módulo domótico enfocado en retroalimentación hacia el usuario.
Se planea que la BSN tenga conexión directa a la nube para poder almacenar
y analizar los datos a través de servicios web. Estos servicios web serán acce-
sibles mediante una URL, donde los dispositivos de gama baja se comunicarán
y podrán enviar la información generada. La red de sensores será una simula-
ción basada en un modelo matemático que como función adicional permitirá
conocer y predecir su desempeño energético; gracias a este comportamiento se
podrá garantizar una generación de datos similar a la de una red WSN la cual
lea una señal ECG de una persona. El modulo de Nube y aprendizaje realiza-
rá un procesamiento de la señal obtenida para determinar la retroalimentación
adecuada hacia el usuario. Finalmente, el tercer módulo estará compuesto por
un módulo domótico o que interactúe de forma activa y ejecute las acciones de
retroalimentación determinadas por el módulo Nube, la cual podrá ser mediante
un mensaje SMS o una notificación luminosa. De igual manera, el servidor web

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.

ubicado en el módulo nube contendrá un repositorio de consulta de información


general, tanto del sistema mismo como de la información recolectada.
La arquitectura propuesta del sistema se puede ver de forma más detallada en
la figura 4.1. Esta figura incluye información adicional acerca de las tecnologías
que se implementaron en el desarrollo final para ofrecer mayor claridad respecto
a la naturaleza del sistema.

4.2. Red de Sensores Corporal. BSN


Para la BSN se propone realizar pruebas de conectividad y pruebas de rendi-
miento. Las pruebas de conectividad analizaron la forma en la que la BSN realizó
transacciones de información con otros nodos del sistema, específicamente con
el servidor en la nube y la forma en la que los datos generados deberían ser
presentados. Mientras que las pruebas de rendimiento analizaron la forma en
la que la BSN administra los recursos disponibles para su funcionamiento, esto
debido a la naturaleza de los dispositivos que componen las BSN. Para realizar
estas pruebas se analizaron el consumo energético y el throughput o rendimiento
de la BSN bajo distintos protocolos de acceso al medio. En el módulo cloud o
en la nube se realizaron pruebas de conectividad y de rendimiento. Las pruebas
de conectividad permitieron conocer los límites presentes en las interacciones
del sistema con agentes externos, a través de probar el acceso a los datos desde
distintos dispositivos de distintas naturalezas y capacidades y desde distintos
enfoques ofrecidos por el sistema, desde otras sesiones de usuario hasta roles de
usuario. Finalmente se realizaron pruebas integrales para corroborar el funcio-
namiento correcto del sistema bajo distintas condiciones de ejecución.

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

Diseño y Arquitectura del


sistema

5.1. Arquitectura para entorno IoT


el sistema tiene una arquitectura IoT dividida en cuatro capas: capa de red
de sensores corporales, capa de almacenamiento y procesamiento de datos (Ser-
vidor en la Nube), capa de interfaz y capa domótica. En la figura 5.1 podemos
ver los componentes de la arquitectura propuesta, su ubicación en las capas
propuestas y algunas mecanismos requeridos para su operación En la siguiente
sección se detalla el diseño para cada uno de los módulos que componen las
capas mencionadas y la forma de intercomunicar dichos componentes.

Figura 5.1: Diagrama Arquitectural en entorno IoT con capas.

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.

5.2.2. Capa: Servidor en la nube


En esta capa, primero es necesario identificar las principales entidades den-
tro del sistema. Para esto podemos partir de los objetivos, los cuales indican que
”el sistema obtendrá señales fisiológicas de los usuarios por medio de una red de
sensores”, de este objetivo podemos distinguir tres distintas entidades importan-
tes para el sistema: usuarios, dispositivos de extracción de señales y las señales
mismas.asi como actuadores domóticos y las acciones que los gobiernan. Enton-
ces es posible asumir que las entidades y relaciones que representan este sistema
pueden ser resumidas al diagrama mostrado en la figura 5.4. De esta manera
podemos ver que las relaciones de los datos en el sistema son generadas a partir
del usuario y que estas relaciones ocurren de forma ”un usuario a muchas enti-
dades”. Dicho lo anterior es necesario analizar la cardinalidad de las relaciones
entre dichas entidades. Esto puede ser de igual manera extraído de los objetivos
del proyecto, los cuales mencionan de forma singular al usuario mientras que
las acciones que ocurren en su entorno, los dispositivos que generan señales, las
señales mismas y las personas de contacto son mencionadas de forma plural. Es-
to nos habla de una relación üno a muchos"desde el usuario hacia las entidades

41
Figura 5.4: Modelo entidad-relación.

persona, dispositivo y acción, de igual manera, de dispositivo hacia señal. La fi-


gura 5.5 muestra el modelo entidad relación con la cardinalidad entre relaciones
indicada. Finalmente es necesario identificar las características de estas entida-
des. En primer lugar, la entidad usuario,simplemente necesita credenciales de
acceso ya que el sistema es independiente de los datos personales de la persona,
si el usuario así lo considera conveniente puede utilizar su nombre como nombre
de usuario. Después, la entidad persona tiene un mayor número de atributos,
esto debido a que los datos de contacto son importantes para poder atender las
emergencias que pudiesen ocurrir en el caso de estudio. Para ello, de la persona
se sugiere tener por lo menos registro de un correo electrónico y un número de
teléfono celular para recibir mensajes de texto. En el caso de los dispositivos nos
encontramos con una situación un poco más complicada, cuando un dispositi-
vo es desconectado del sistema ya sea por decisión o por algún desperfecto, el
sistema debe tener un registro de configuración o estado al que los dispositivos
puedan volver en caso de ser reiniciados. Este estado realmente depende del tipo
de dispositivo y de la tecnología que este utilice, por lo tanto este campo se de-
ja indicado para que su implementación dependa de cada dispositivo. Además,
para tener un registro robusto de dispositivos en el sistema se sugiere un campo
UUID que permita una identificación única para los mismos. Finalmente para
la entidad de señal se propone que además de los datos numéricos que repre-
sentan la señal misma se tenga un registro de los puntos de importancia en ella
y los valores generados por el algoritmo de extracción de características para
clasificación, así como una marca temporal que indique el momento en que esta
señal fue registrada. El diagrama de la figura 5.6 muestra las consideraciones
anteriormente mencionadas señaladas en el diagrama 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.

A partir de los diagramas entidad-relación previos se puede sugerir una base


de datos con de 5 tablas: Usuario, Persona, Dispositivo, Señal y acción. Adicio-
nalmente, es pertinente notar que el framework Django provee ciertas tablas de
base de datos como parte de su esquema de manejo de sesiones. Dichas tablas
son Users y Groups, las cuales se encargan del registro de usuarios en el sistema,
de la seguridad mantenida a través de sesiones y de los permisos otorgados para
el acceso a los datos. Para el sistema desarrollado se propuso utilizar la tabla
User propuesta por el sistema como la tabla Usuario propuesta en el diagrama
entidad-relación previo.
Ahora se tiene un diseño de base de datos como lo muestra la figura 5.7,
sin embargo, según lo indica (Codd 1970) es necesario hacer ciertos cambios
para normalizar la base de datos y así reducir la redundancia y aumentar la
integridad de los 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.

5.2.4. Detección de arritmias y taquicardias


Este proceso se realiza en la nube a través de un proceso clasificador de las
señales, el cual clasifica la señal en tres grupos: taquicardia, fibrilación o ritmo
sinusal normal. Se utilizo la técnica usando (Darouei y Ayatollahi 2010) para
garantizar un porcentaje de éxito de detección muy cercano al 100 % y debido
a su estructura puede ser implementada de forma modular. Dicha estructura
consiste en un algoritmo de extracción de características y una red neuronal
que clasifica dichas características. Dado que esta función del sistema es im-
plementada como un módulo, más que una capa específica basta simplemente
con definir su comportamiento en aislamiento y su implementación dentro del
sistema. Esta difinición se encuentra en secciones posteriores.

5.2.5. Sistema domótico


Como se mencionó previamente, el sistema domótico tiene principalmente la
función de notificar mediante distintos medios cuando se detecte una taquicardia
o una fibrilación en las señales electrocardiográficas extraídas del usuario. Estos
avisos están pensados para ser vistos por personas de confianza al usuario o por

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.

de la información generada por la BSN y el módulo domótico representa la


accion derivada de a deteccion de una anomalia detectada, durante el monitoreo.
A continuación se detalla el desarrollo de cada uno de estos módulos, sus medios
de comunicación con los demás módulos del sistema y los retos y complicaciones
que surgieron durante el desarrollo de los mismos.
Dado que el desarrollo comenzó teniendo ciertas tecnologías en mente y des-
pués esto tuvo que cambiar, se ha añadido una sección adicional a este capítulo
llamada Desarrollo preliminar, en la cual se detalla el desarrollo previo al cambio
mencionado.

5.3. Desarrollo preliminar


5.3.1. Modulo Cloud
Este Módulo debe ser accesible desde distintos dispositivos y debe permitir
acceder a datos específicos de entidades definidas. Para esto se propuso imple-
mentar un sistema donde las reglas de negocio se encuentren centralizadas, el
cual se ayude de una base de datos NoSQL y tenga un sistema de servicios web
tipo REST para interactuar con los demás módulos del sistema.
Se genero un sistema web con la estructura mostrada en la figura 5.10. Se
genero el servidor web dentro del cual se implementaron una serie de servicios
web del tipo REST los cuales filtran los resultados obtenidos y muestran res-
puestas específicas dependiendo del tipo de petición HTTP. Para realizar una
prueba del correcto funcionamiento del servidor se realizó un histograma de las
señales recibidas, el cual podía ser consultado mediante peticiones GET a una
URL específica, mientras que los datos debían ser mandados al servidor como
un objeto con formato JSON hacia ducha URL. En la figura 5.11 se observa
una captura de pantalla de la gráfica generada al consultar la URL con la grá-
fica de los datos recibidos por la red. Estos datos fueron enviados en cuanto

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.

un nodo agotaba toda su energía de transmisión y se podía considerar como


muerto, siendo el número de nodo y el tiempo de muerte los únicos parámetros
relevantes en dicha prueba. Esta gráfica muestra la capacidad del servidor Web
Express de generar gráficas y almacenar datos provenientes de la red de sensores
para su visualización. Como se observa el uso de la misma URL para distintas
operaciones fue un objetivo alcanzado, el cual servio como punto fundamental
del desarrollo.

5.3.2. Módulo de detección de arritmias y taquicardias


Como fuente de datos para el sistema, se seleccionaron as bases de datos de
taquiarritmia ventricular de la universidad de Creighton (Nolle y Bowser 1992)
y la base de datos MIT-BIH de ritmo sinusal normal (Center) 1990), en lo futuro
referidas como las bases nsrd y cudb respectivamente, según lo sugerido por la
metodología de detección de arritmias de (Darouei y Ayatollahi 2010). La forma
de accesar a los registros de dichas bases de datos es posible mediante distintos
métodos, principalmente mediante el acceso directo a la base de datos dentro
del sistema PhysioBank ATM y las descargas http que ofrece, o mediante la
función rdrecord que ofrece la librería wfdb. Los registros dentro de esta base
de datos regularmente contienen por lo menos un tipo de información que es la
señal misma que refleja el fenómeno analizado, es decir, los registro de la base de
datos nsrdb contiene por lo menos registros de una señal ECG digitalizada, de

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.

5.3.3. Capa domótica: Envío de mensaje SMS


Se utilizó la plataforma de prototipado Arduino, específicamente el modelo
Arduino UNO. Esta plataforma cuenta con un amplio soporte en cuanto a hard-
ware y software se refiere mediante el amplio número de librerías y ’shields’ o
módulos que pueden ser conectados a la tablilla principal para aumentar sus ca-
pacidades. Para cumplir los objetivos de este módulo se consiguieron dos shields:
el shield GPRS basado en el integrado SIM900 para el envío de mensajes SMS
y el shield wifi basado en el integrado ESP8266.

5.4. Capa o Módulo BSN


El módulo BSN tiene como finalidad servir como fuente de datos hacia el
módulo Cloud, además, dichos datos provienen de una de las bases de datos
almacenadas en el sistema en línea PhysioBank de PhysioNet.
La salida de datos de una BSN se simula con la transmisión de fragmentos
de señales digitalizadas de las bases de datos seleccionadas hacia un dispositivo
gateway, similar a la red propuesta por (G. Fortino y col. 2013). Dado que el
fin de esta red de sensores simulada es mandar la información tal y como se
obtiene al siguiente módulo del sistema se puede asertar que esta es una red de
sensores que no requiere de alguna función específica implementada más allá de
capacidades básicas de transmisión. Dicho lo anterior se propone implementar en
primera instancia un protocolo de acceso al medio simple como Aloha ranurado
(Roberts 1975) donde los nodos tienen una probabilidad fija de transmisión y
dependiendo de dicha probabilidad compiten por tener acceso al medio, al no
tenerlo entran en un periodo donde no intentan transmitir y después vuelven a
intentar la transmisión.

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.

De acuerdo a lo expuesto anteriormente los nodos del sistema utilizarán un


protocolo de acceso al medio Aloha ranurado mediante el cual competirán por
la transmisión de los datos hacia el nodo gateway o de salida de datos que ense-
guida hará la transmisión de dichos datos hacia el módulo cloud. Se desarrolló
un código en lenguaje c++ basado en el diagrama de flujo mostrado en la figura
5.2 ubicada en la página 39. A la par se desarrollaron dos protcolos más: el
protocolo de medición energética y una implementación del protocolo CSMA-
NP. Cabe mencionar que la transmisión hacia el módulo Cloud es realizada de
manera directa por parte del gateway, el cuál es representado mediante un hilo
de ejecución continua que toma los datos que recibe y los transmite de forma
inmediata hacia la capa cloud. Una vez definida la lógica del programa se prosi-
guió a la implementación, para la cual fue elegido el lenguaje de programación
C++. Para la La transmisión hacia el módulo Cloud se hizo con la ayuda de la
librería CURL, la cual es una librería enfocada en transmisión de datos a través
de URL que soporta un gran número de protocolos de comunicación. Específi-
camente se utilizó la implementación de la librería para C++, libcurl (Stenberg
2018, febrero).
Dado que los dispositivos que crean las señales no se comportan como na-
vegadores web convencionales es necesario hacer un análisis de los métodos de
seguridad implementados por Django REST Framework.
Al realizar peticiones HTTP consideradas ”no seguras” (POST, PUT y DE-
LETE) hacia los servidores Djagno se debe apegarse a la protección contra forja
de peticiones de sitios cruzados (CSRF). Este tipo de ataque se basa en inter-
ceptar las cookies de un sitio y utilizarlas para ejecutar formas en un servidor
bajo el supuesto de ser un usuario registrado en el sistema. De acuerdo a lo men-
cionado por la documentación de Django, para poder realizar peticiones consi-
deradas inseguras sin problemas de acceso uno debe utilizar el sistema de tokens
csrf provisto por el middleware del servidor. Estos tokens se basan en un número
aleatorio generado para cada usuario cuando inicia sesión, el cual nunca es utili-
zado más que para generar dichos tokens al añadir una ”sal” o número aleatorio.
Los tokens csrf son utilizados por el sistema en todas las formas HTML que se
encuentren en las vistas mismas del servidor, es decir, regularmente donde se
encuentre una etiqueta <form ...>...</form>también se encontrará una indica-
ción de incluir un token csrf mediante una etiqueta django { % csrf_token %}, la
cual se traduciría a una línea de código como la señalada en la figura 5.13. Otra
forma de obtener un token csrf es mediante visitar la URL de acceso de usuarios

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

3. Realizar una petición POST con credenciales de inicio adjuntando el token


csrf obtenido previamente
4. Guardar las cookies obtenidas de la petición previa y utilizarlas como
credenciales para futuras peticiones
A este protocolo le llamaremos el Protocolo de validación para peticiones
y será de vital importancia en capítulos posteriores.

5.5. Detección de arritmimias y fibrilación ven-


tricular
Este módulo puede ser definido como dos diferentes componentes que fun-
cionan de forma conjunta: un módulo de extracción de características y una
red neuronal multicapa. El método de extracción de características tiene como
fin obtener características temporales, energéticas y morfológicas las cuales son
después clasificadas mediante una red neuronal probabilística multicapa. Es-
te método consiste en dividir la señal electrocardiográfica en latidos y después
obtener los siguientes parámetros temporales:
Intervalo RR entre el latido actual y el que le precede, denotado por RR1
Intervalo RR entre el latido actual y el siguiente, denotado por RR2

Intervalo RR entre el latido anterior y el que le precede, denotado por


RR0
La razón entre RR1 y RR2
Intervalo PQ

55
Intervalo QRS
Intervalo PR
Intervalo PT
Los siguientes parámetros morfológicos:

Correlación cruzada entre el latido actual y el siguientes


Correlación cruzada entre el latido actual y el anterior
Y los siguiente parámetros energéticos:

Densidad espectral de energía


Energía de la señal obtenida a partir de la descomposición en cuatro niveles
de la wavelet Daubechies 6
Estos datos se obtienen a partir de una plantilla de 30 muestras que representan
cada latido. Esto es obtenido con 20 muestras después y 10 antes del punto R
del latido. Habiendo obtenido los datos anteriormente mencionados se genera un
arreglo de 1 por 12 elementos con las características generadas. Y este arreglo se
acomoda junto con más muestras para generar una matriz de entrenamiento para
la red neuronal. El diagrama de flujo de la figura 5.14 ilustra la implementación
propuesta para este módulo. Estas características son condensadas en arreglos
y después utilizadas para el entrenamiento de una red neuronal de dos capas, la
cual contiene una capa de base radial seguida de una capa de competencia. Dicha
red neuronal seráimplementada según el diseño descrito en (Darouei y Ayatollahi
2010). En la figura 5.15 podemos ver el diagrama de la red propuesto por dicho
trabajo. En la figura 5.15 ai I es el elemento i-ésimo de ai , R es el número de
elementos en el vector de entrada, Q es el número de pares entrada/salida que
es igual al número de neuronas en la primer capa y K es el número de clases
de los datos de entrada que es igual al número de neuronas en la segunda capa.
Dados los pasos descritos por el algoritmo de extracción de características de la
señal QRS sabemos que el número de características son 13 más una etiqueta de
clasificación, lo cual vuelve el vector de entrada un vector de largo 14. Además,
dado que el problema requiere una clasificación en tres categorías podemos ver
que K tiene un valor de 3. El resultado de la primer capa es calculado mediante la
ecuación 5.1, mientras que el resultado de la segunda capa es calculado mediante
la ecuación 5.2.
ai I = radbas(||IW1,1 − P ||biI) (5.1)
a2 = compet(LW2,1a1 ) (5.2)
Cabe señalar que este módulo deberá ser entrenado fuera de línea, es decir, el
aprendizaje de la red no ocurrirá durante la ejecución del sistema, esto debido
a que los procesos de aprendizaje de la red deberían estar ligados a cuentas
específicas de usuario, con cada usuario teniendo una instancia distinta de la
red neuronal presente en cada proceso de creación de una señal, esto aunado

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).

al hecho de que una implementación de tal algoritmo exigiría datos vastamente


diferentes entre sí para realizar una comprobación de la correcta clasificación
con datos distintos y esto es imposible debido a que los registros encontrados
en las bases de datos seleccionadas no cuentan con información adicional acerca
de los pacientes.

5.6. Servidor en la nube


Como se mencionó en capítulos anteriores, el sistema cloud cumple con tres
funciones específicas: presentación de datos a usuarios, persistencia de datos y
ejecución de decisiones con base en reglas de negocio.

5.6.1. Persistencia de datos


La implementación de las tablas de las bases de datos fue realizada mediante
la creación de modelos relacionales del servidor Django. Estos modelos tienen
muchas ventajas: traducen parámetros a atributos nativos de Python que pue-
den ser fácilmente serializables en distintos formatos de comunicación, permiten
instanciación en objetos Python de registros de la base de datos y permiten una
fácil documentabilidad.
La base de datos de la figura 5.8 en la página 46 fue traducida a los siguientes
modelos: Persona, Dispositivo, Accion, Senal y TipoAccion.
Como se puede ver, no se creó un modelo para usuarios, esto debido a
que Django provee modelos para usuarios basándose en su esquema de se-
guridad de sesiones. Esta clase de usuario se encuentra en el paquete ”djan-
go.contrib.auth.models”, y se llama User. Este modelo de usuario cuenta con los
siguientes campos: username, first_name, last_name, email, password, groups,
user_permissions, is_staff, is_active, is_superuser, last_login, date_joined.

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.

5.6.2. Servidor Web con reglas de negocio


Esto puede ser extrapolado a los siguientes requisitos funcionales: el sistema
debe poder mostrar datos importantes al usuario, el sistema debe poder almace-
nar los datos generados por el módulo BSN y el sistema debe poder tomar deci-
siones basado en la información del módulo BSN. Estas funcionalidades pueden
ser obtenidas a través del framework Django (D. S. Foundation 2018, agosto).
Para mostrar datos al usuario este framework cuenta con vistas o ”views”, los
cuales son funciones que determinan la respuesta adecuada a las peticiones que
lleguen al servidor en rutas determinadas. Para el almacenamiento de los datos
Django utiliza modelos o ”models” que representan instancias simples de datos
que generalmente son implementadas como una tabla en la base de datos. Para
la toma de desiciones las vistas nos ofrecen funcionalidad adicional dentro de las
vistas definidas por el servidor. Sin embargo, antes de continuar es pertinente
mencionar que Django no es un framework único pues existen distintas variantes
del mismo, cada una enfocada en proveer funcionalidades específicas. Por ejem-
plo, Django Bootstrap (Dylan 2018, julio) el cual está enfocado en ofrecer la
facilidad de desarrollo de interfaz y prototipado para usuarios de Boostrap (Ot-
to Mark 2018, julio) integrado con las vistas predeterminadas de Django para
tener sitios con diseño agradable a la vista de forma instantanea. Otro ejemplo
es Django pandas (Clarke 2018, julio) el cual ha sido diseñado para combinar
las estructuras de datos especializadas para análisis de datos de Pandas (Team
2018, agosto) con las vistas de modelos nativas de Django. Finalmente, existe
Django REST (Tom Christie 2018, julio) el cuál añade a las vistas de Django
la capacidad de ofrecer distintas respuestas a la misma dirección dependiendo
del tipo de contenido solicitado. Existen más variantes, cada una enfocada en
ampliar la funcionalidad de Django hacia distintas áreas, sin embargo, sola-
mente las tres mencionadas previamente pueden impactar de forma directa el
desarrollo del proyecto y por desgracia estas variantes de Django son mutua-
mente exclusivas debido a que su implementación implicó la modificación de los
componentes básicos de Django. Estas tres variantes podrían ayudar al desa-
rrollo del sistema debido a que cada una impacta el sistema de forma distinta,

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.

5.6.3. Algoritmo de detección de arritmias y taquicardias


El desarrollo de esta capa se baso en la biblioteca wfdb-python para python
pero hubo diversas problemáticas de configuración por lo cual se opto por por
utilizar Anaconda, una plataforma de python enfocada en ofrecer herramientas
matemáticas y de procesamiento de datos.
Se procedió a programar el algoritmo de detección de arritmias y taquicar-
dias basado en (Darouei y Ayatollahi 2010) y de acuerdo a lo señalado por el
diagrama de flujo de la figura 5.14 que se encuentra en la página 57. con las
siguientes observaciones: ’Para cada latido se obtiene una plantilla de 30 mues-
tras. Con 10 muestras antes del pico R y 20 después. Cada pico R es ubicado
en la posición que lo indiquen las anotaciones de la señal” lo cual en primer
instancia representa un problema. Esto se debe a que las bases de datos nsrdb
y cudb fueron digitalizadas a 128Hz y 250Hz respectivamente. Si se toma un
periodo de 30 muestras de alguna señal de dichas bases de datos tendríamos un
periodo de 0.23s y 0.12s respectivamente, lo cual no es suficiente tiempo para
obtener una muestra representativa ya que en promedio un latido humano tiene
una duración de 0,86s. Para obtener esta duración se cambiaron los límites pro-
puestos, de 10 muestras previas y 20 posteriores a 21 anteriores y 32 posteriores
para la base de datos nsrdb y 225 anteriores y 130 posteriores para la base de
datos cudb. En la figura 5.26 se observan 10 muestras aleatorias superpuestas
del registro ’18177’ de la base de datos nsrdb. Estas muestras han sido obte-
nidas de acuerdo a la primer ventana de muestreo con 30 muestras de largo.
Como se puede apreciar, esta ventana de muestreo de la señal no es lo suficien-
temente grande como para incluir información necesaria para la ejecución de
este algoritmo de detección, por ejemplo, no incluye las señales P o T, las cuales
son necesarias para, por lo menos, extraer las características temporales de la
señal. En la figura 5.27 podemos ver las mismas 10 muestras tomadas con la

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.

ventana de muestreo propuesta con 54 muestras de largo. Como se observa, con


esta ventana de muestreo ya se aprecian las señales P y T dentro de la señal
muestreada. Esta nueva ventana propuesta fue basada en el tiempo promedio
de un latido cardiaco humano. En las figuras 5.28 y 5.29 podemos ver, de igual
manera, la comparación entre las ventanas de muestreo sugerida y propuesta
respectivamente pero para las señales de la base de datos cudb.
Una vez ajustadas las ventanas de muestreo para cada señal se procedió a
obtener las características temporales. Primero se obtuvieron las señales P, Q,
R, S y T, esto se puede apreciar en la figura 5.30. Después se obtuvieron datos
adicionales para calcular los intervalos PQ, QRS, PR y PT; dichos datos son
el inicio de la señal P, el inicio de la señal Q, el final de la señal S, el final
de la señal P y el final de la señal T Estas señales se muestran correctamente
detectadas e indicadas en la figura 5.31. Una vez obtenidos estos puntos de
interés se prosiguió a obtener los periodos temporales pertinentes.
En este punto, es pertinente mencionar que el uso de la correlación entre
señales mediante la fórmula 5.3 es una versión ligeramente modificada de la
fórmula para calcular el coeficiente de correlación de Pearson (Inc 2018, diciem-
bre), el cual se muestra en la fórmula 5.4 y fue usado en la implementación del
algoritmo de detección.
PN  
n=1 x(n) − X
Rxy = qP 2 PN  (5.3)
N  
n=1 x(n) − X n=1 y(n) − Y

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.

Figura 5.30: Señales P, Q, R, S y T detectadas en un latido de ritmo sinusal


normal.

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

Después, se utilizó el algoritmo de detección para obtener los vectores de


datos necesarios para entrenar la red neuronal. Como se mencionó previamen-
te, estos vectores fueron almacenados en un archivo csv y normalizados para
su procesamiento durante el entrenamiento de la red neuronal, la cual es de
tipo probabilístico (Darouei y Ayatollahi 2010) . Dicha red neuronal fue imple-
mentada utilizando como base la estructura de red propuesta por (Seo 2018,
diciembre), aunque de primera instancia se realizaron pruebas con una red del
tipo perceptron. Además,se tuvieron que hacer algunos cambios respecto a di-
cha implementación debido a que fue creada con la versión 2.7 de python y la
versión utilizada para el desarrollo fue 3.7. Además se realizaron pruebas con la
librería PyTorch (PyTorch 2019, enero) para tener una implementación segura
dentro del servidor web.
Una vez entrenada la red neuronal y programado el algoritmo de detección
se prosiguió a incluirlos dentro del sistema de nube. Esta inclusión se hizo en
el ViewSet que representa los objetos señal. Aquí, se sobreescribió el método
’create’ y de la secuencia de datos se extrajo el atributo ’valores’, este atributo
es utilizado para ser analizado por el algoritmo de detección y después ser anali-
zado por la red neuronal. Dicho atributo contiene las muestras obtenidas de los
registros de las bases de datos nsrdb y cudb. Tras ser analizado el latido, al algo-
ritmo de análisis regresa una lista con los parámetros datellados anteriormente
para después utilizar estos parámetros como entrada para la red neuronal. Una
vez hecha la clasificación por parte de la red neuronal se le asigna una etiqueta
al latido basándose en el resultado arrojado por la red neuronal y se añade el

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.

registro a la base de datos.


Una vez guardada la señal en la base de datos esta puede ser vista en el
directorio ’Señales’ por el mismo usuario que la creó o por un administrador del
sistema. Una vez guardada la señal en la base de datos esta puede ser vista en
el directorio ’Señales’ por el mismo usuario que la creó o por un administrador
del sistema. En la figura 5.32 podemos ver el directorio de señales del usuario
con algunas señales registradas.
En la figura 5.33 podemos ver el directorio de señales al ser vista por un
navegador en modo API y el mismo directorio condensado en un formato JSON.

5.6.4. Despliegue en Servidor de la Nube


Una vez realizadas las pruebas de acceso y de permisos dentro del servidor
web de forma local se prosiguió a alojar el proyecto dentro de Google Cloud.
Existen distintas configuraciones y opciones de alojamiento en la plataforma
(Google 2018b, noviembre): App Engine está enfocado en el despligue de apli-
caciones de pequeña escala con un número relativamente pequeño de recursos
necesarios. Para este proyecto se utilizará App Engine, ya que el proyecto se
enfoca demostrar funcionalidad y características de implementación en lugar de
escalabilidad o límites de cómputo. Para poder alojar una aplicación mediante
la tecnología App Engine, hasta el momento de creación de este documento, es
necesario contar con los siguientes elementos: Python 2.7 ó 3.7, una aplicación
en la consola de Google Cloud Platform asociada al perfil personal del usuario y
el grupo de herramientas gcloud. Después de haber creado la aplicación ”saturn”
en la consola de Google Cloud se procedió a ejecutar
Se creó una instancia de base de datos PostGreSQL versión 9.6 según lo
ofrecido por la api de Google Cloud.

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.

Mediante el uso de la herramienta virtualenv, se encapsula el código del


proyecto y sus dependencias. Esto permite tener un proyecto que puede ser
trasladado entre distintas plataformas y mantener un comportamiento uniforme
y estable entre ellas. La implementación de virtualenv fue necesaria para poder
alojar el servidor web dentro de el sistema de alojamiento flexible de App Engine.
Finalmente, se realiza el despliegue de aplicaciones Django en un entorno
flexible de ejecución (Google 2019a, enero). Dichos pasos pueden ser resumidos
de la forma siguiente:
1. Configurar entorno de desarrollo y generar archivos de dependencias
2. Descargar herramientas de desarrollo de Google y configurarlas con las
credenciales de usuario de la cuenta de usuario del desarrollador
3. Crear contenedor para alojar contenido del servidor
4. Concentrar archivos estáticos y alojarlos en el servidor
5. Crear un archivo descriptivo del proyecto en formato .yaml
6. Especificar una interfaz de comunicación del servidor web (WSGI)
7. Desplegar aplicación
La interfaz de comunicación del servidor web seleccionada fue una instancia de
la bioblioteca waitress, la cual en encarga de enrutar las peticiones llegadas de a
los servidores de App engine hacia el sistema Django. Un detalle importante , es

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”.

5.7. Módulo domótico


Como se mencionó en el capítulo 4, este módulo cumple la función de un
actuador domótico al interactuar con el usuario mediante el envío de mensa-
jes SMS a partir de un modulo GSM. El cual esta dividido en dos distintos
componentes: un componente que se conecte a los servicios REST de la capa
cloud y consulte las acciones junto con los datos adicionales de las mismas y un
componente que se encargue de ejecutar dichas acciones. Se les llamó módulo
de obtención de tareas y módulo de ejecución de tareas. Para esto se propuso
utilizar la estructura de objetos JSON mostrada en la figura 5.34, la cual se
propuso interpretar mediante la librería (Blanchon 2018, noviembre). Como se
puede apreciar, es simplemente un mapeo de los datos de un registro de acción
en la base de datos a un objeto JSON.
Para el módulo de obtención de tareas se propuso utilizar el módulo ESP8266
para realizar consultas del tipo REST hacia los servicios CRUD generador por
los ModelViewSet de Django Rest. Para el módulo de ejecución de tareas se
propuso utilizar el módulo de transmisión GSM GPRS basado en el integrado
SIM900 (Amazon 2018, diciembre). También se propuso que ambos módulos
fuesen coordinados mediante un circuito Arduino. Primero se hicieron pruebas
de conexión entre el circuito Arduino y el shield GSM. De acuerdo a distintas
fuentes, el shield seleccionado no necesitaba una fuente de alimentación externa,
sin embargo, distintas pruebas mostraron que de hecho la necesita. Para esto
se consiguió un adaptador de corriente de corriente alterna que ofrece de salida
5v a 2A de corriente directa. Además, se consiguió una tarjeta SIM de una de
las compañías telefónicas de mayor presencia en el país desde la cual mandar
los mensajes. En la figura 5.35 se muestra una captura de pantalla de uno de
los mensajes recibidos en un teléfono celular. Después se hicieron pruebas con
el módulo de obtención de tareas. Se conectó el shield Wi-Fi con el dispositivo
Arduino por medio del puerto serial, sin embargo las pruebas fueron inconclusas.
Debido a restricciones en el desarrollo se propuso cambiar este módulo por un
módulo de software programado en C encargado de descargar los datos del

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

6.1. Red de sensores corporal


6.1.1. Verificación de validez matemática
Dado que la red de sensores corporal fue creada a partir de un algoritmo de
simulación que depende de una probabilidad fija y de un número aleatorio con
distribución normal, este sistema puede ser modelado como una cadena de Mar-
kov mediante la cual puede ser calculado su rendimiento a partir de un modelo
matemático. El resolver esta cadena de Markov mediante un método similar
a Gauss-Seidel nos permite verificar el comportamiento de nuestra simulación
frente a su contraparte matemática y de esta forma comprobar que el funcio-
namiento de la red es igual, en cuanto a rendimiento, a una implementación
física.
Estos modelos matemáticos son generados para ambos protocolos: el proto-
colo Aloha ranurado y el protocolo de medición energética, las ecuaciones 6.1 y
6.2 representan los modelos matemáticos de dichos protocolos respectivamente.
N N
X 1 1X 1
S= = (6.1)
i=0
iτ (1 − τ )i−1 τ i=0 i(1 − τ )i−1

Donde S representa el rendimiento, N el número de nodos y τ la probabilidad


de transmisión.
N i  
X X i j 1
E= Etx + (i − 1) ∗ Er x τ (1 − τ )i−j ∗ jEtx + (i − j)Erx ∗
i=1 j=0
j iτ (1 − τ )i−1
(6.2)
Donde E representa el consumo energético, N el número de nodos, τ la proba-
bilidad de transmisión, Etx representa la energía de transmisión de un nodo y
Erx la energía de recepción de un nodo.
Se compararon los datos de rendimiento obtenidos de la simulación de la
red de sensores y del modelo matemático. Esto se hizo mediante ejecutar tan-

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).

to la simulación del protocolo como el modelo matemático con parámetros de


operación similares. Dichos parámetros de operación son el número de nodos
presentes en la red de sensores y la probabilidad de transmisión de cada uno de
ellos. Como se mencionó en el capítulo previo, el número de nodos fue determi-
nado en un rango de 0 a 30 debido al número máximo reportado en aplicaciones
de WBAN que es 20. Además, se determinó que la probabilidad de transmisión
tuviese un rango de 0,001 a 0,1 debido a que cambios que distan en órdenes de
magnitud en dichas probabilidades ofrecen un mayor rango de información en
los resultados.
Como se puede apreciar en la figura 6.1 los protocolos simulados que se en-
cargan de enviar señales electrocardiográficas hacia el sistema en la nube tienen
un comportamiento correcto que simula fielmente el comportamiento de la co-
municación dentro de una aplicación real de una red de sensores que implemente
dichos protocolos.
Como se puede apreciar en la figura 6.1 la gráfica muestra un valor máximo
de 0,2862 donde 30 nodos transmiten con una probabilidad de competencia por
el canal de 0,007 en cada iteración de la simulación. Esto quiere decir cuando
se tiene una red con 30 nodos cada uno con una probabilidad de transmisión de
0,007 el rendimiento total (numero de transmisiones exitosas en un determinado
tiempo) o throughput de 0,2862 transmisiones exitosas sobre ciclos de operación,
donde cada ciclo de operación dependerá de la plataforma de implementación.
Cabe señalar que las probabilidades de transmisión, mostradas en la tabla 6.1,
tienen una naturaleza logarítmica, por lo tanto la gráfica de la figura 6.1 tiene un
ajuste en el eje de las probabilidades de transmisión para mostrar una curva que
permita una mejor lectura. De dicha figura es pertinente señalar que, aunque
sí es posible determinar que las probabilidades de transmisión cercanas al valor

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

Cuadro 6.1: Parámetros de ejecución de la simulación del protocolo S-ALOHA.


Cada ejecución de la simulación es realizada con una combinación de dos pará-
metros sacados de las columnas de esta tabla.

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.

6.1.2. Pruebas de conectividad hacia módulo en la nube


Para la conexión hacia el módulo en la nube se propuso utilizar la librería
CURL y las transferencias de datos mediante peticiones HTTP.
Para esto primero se realizó una prueba de conexión simple. Una petición
GET desde un fragmento de código escrito en C++ que utiliza la librería cURL.
Dicha prueba fue exitosa, en la figura 6.4 podemos ver que la respuesta del
servidor es la misma que cuando es realizada mediante un navegador web. De
este resultado podemos afrimar que la conexión es estable.
Después, utilizando el protocolo de inicio de sesión para peticiones HTTP
definido en el capítulo anterior se procedió a realizar pruebas con distintos tipos
de peticiones HTTP en distintos directorios del servidor web para comprobar
los permisos de acceso de las cuentas de usuario.

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).

Figura 6.3: Comparación entre el tiempo necesario para la transmisión de in-


formación por parte de todos los nodos medida en la simulación del protocolo
(izquierda) y en el modelo matemático (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.

Dado que la primer prueba fue exitosa, se prosiguió a programar el protoco-


lo de validación para peticiones especificado en el capítulo 5. Cabe recordar
los pasos que este protocolo propuesto sugiere:
1. Realizar petición GET a la URL de inicio de sesión
2. Extraer cookie ’csrftoken’ de las cookies obtenidas
3. Realizar una petición POST con credenciales de inicio adjuntando el token
csrf obtenido previamente
4. Guardar las cookies obtenidas de la petición previa y utilizarlas como
credenciales para futuras peticiones
En la figura 6.5 podemos ver como la red neuronal inicia sesión y obtiene
dos cookies por parte del servidor Django: ’sessionid’ la cual asigna un id de
sesión al dueño de esta cookie y ’csrftoken’ que representa el número secreto del
usuario en dicha sesión con una sal aleatoria añadida.
Una vez logrado el correcto inicio de sesión se prosiguió a hacer una prueba
de creación de registros mediante una petición POST. Sin embargo en este
punto el desarrollo se vio interrumpido debido a un problema. Aún siguien
la recomendación de la documentación oficial y las sugerencias de usuarios de
foros de tecnología fue imposible lograr la creación de datos mediante peticiones
deltipo POST. Esto debido a que aún proporcionando las credenciales correctas
de incio de sesión la respuesta del servidor siempre fue "403 Forbidden", esto
impidió el avance del desarrollo en este aspecto del sistema.

6.2. Extracción de características y red neuro-


nal
El módulo de clasificación fueimplementado de acuerdo a lo mencionado en
el capítulo previo: un módulo de extracción de características y una red neuro-
nal multicapa. En primer instancia el diagrama de extracción de características
fue modelado como lo indica la figura 5.14, a partir del cual se generó un ar-
chivo con formato de valores separados por comas, con extensión ’.csv’, el cual

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.

contiene, como lo señala el trabajo de (Darouei y Ayatollahi 2010), 54 muestras


de latidos de ritmo sinusal normal, 30 de taquicardia ventricular y 30 de fibri-
lación ventricular. En la figura 6.6 podemos ver un extracto del mismo archivo.
Como se puede apreciar, los valores generados por el algoritmo de detección
no se encuentran normalizados, por eso, como lo sugiere el trabajo menciona-
do anteriormente, fueron sometidos a un proceso de normalización antes de ser
entregados a la red neuronal para su entrenamiento. A este algoritmo simple-
mente se le hicieron pruebas de funcionamiento básico. Se comprobó que los
valores generados se encontraran entre el rango de 0 a 1 o muy cercanos y que
todos y cada uno de los latidos analizados contara con un vector completo de
características. Una vez comprobado el comportamiento correcto, mediante la
correcta generación del archivo con formato csv, se prosiguió a desarrollar la red
neuronal.
La red neuronal primero fue desarrollada como un perceptron de dos capas
que clasificaba las señales en dos grupos: señales nsr y señales no nsr. Esta prue-
ba se hizo con la finalidad de crear un primer acercamiento a la clasificación de
señales extraídas de PhysioNet y para probar la integración de una red neuro-
nal junto con el resto del sistema. En la figura ?? se puede ver la estructura
de esta red neuronal. A esta red neuronal se le realizaron dos tipos de prue-
bas, de clasificación para comprobar el porcentaje de clasificación de las señales
y de integración para determinar su correcto comportamiento con los demás
componentes del sistema.

6.2.1. Pruebas de éxito de clasificación


Como se mencionó en el capítulo anterior, a partir de el conjunto de da-
tos clasificado se extrajo el 80 % para el entrenamiento de la red y se dejó el
20 % restante para hacer pruebas de probabilidad de éxito. Al igual que el en-
trenamiento, las pruebas de éxito no se realizaron en línea, sino en un entorno
de ejecución local. Los resultados mostraron un éxito de 100 % en detección de
ritmo sinusal normal y un 80 % de éxito en detección de taquicardia y fibrilación.

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).

Es probable que el bajo porcentaje de detección se deba al reducido número


de muestras con las que se contó para la detección de taquicardia.

6.2.2. Pruebas de instanciación de red neuronal


Después se realizaron pruebas de instanciación, para esto se introdujo una
línea de código que imprimiera el resultado de la red neuronal en cuanto esta
fuese ejecutada. Como lo muestra la figura 6.7

6.2.3. Pruebas de generación de acciones


Finalmente, se hizo una prueba de creación de acciones donde a partir del
resultado obtenido de una clasificación se propuso crear una acción correspon-
diente. Primero se creó una señal con taquicardia y después una señal con fibrila-
ción. El resultado fue comprobado mediante un listado de las acciones generadas.
Como se puede ver en las figuras 6.8 y 6.9 la red neuronal, en conjunto con el
sistema en la nube, puede crear correctamente registros de acciones dependiendo
de la clasificación generada.

6.3. Sistema en la nube


Las pruebas del sistema en la nube se basaron en la comprobación de ope-
raciones CRUD (Creación, Consulta, Actualización y Eliminación) dentro de
cada uno de los directorios, y en comprobaciones de acceso a objetos que a los

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.

usuarios no les pertenecen. Las pruebas de seguridad no se realizaron debido a


que Django ya ofrece medidas de seguridad robustas ante los principales ataques
que este tipo de sistemas pueden recibir:
Ataque con código cruzado entre sitios
Forja de peticiones cruzadas entre sitios
Inyección SQL
Intercepción de datos adicionales de peticiones
Entre otros

6.3.1. Pruebas de comportamiento de operaciones CRUD


Debido a la naturaleza de los directorios y las vistas que Django ofrece fue
posible crear registros mediante las vistas API. De hecho, debido al error deta-
llado en la sección previa, dichas vistas API y las plantillas HTML se volvieron
el único punto de entrada de datos del sistema. A pesar de lo anterior, se pro-
cedió a realizar pruebas de métodos CRUD en cada uno de los directorios. En
la figura 6.10 podemos ver el resultado de la creación de un registro en el direc-
torio de señales. Dado que este comportamiento es general por estar replicado
en las vistas de datos del servidor, es suficiente con comprobar cada una de las

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.

funciones CRUD en un directorio para determinar que se comporta demanera


similar en el resto de ellos.
Una vez comprobado el correcto funcionamiento de los métodos de creación
se procedió a comprobar los métodos de actualización de datos. En la figura
6.11 podemos ver una actualización de datos realizada satisfactoriamente sobre
un registro del directorio Dispositivos.
Finalmente se probó la capacidad de eliminación de uno de los directorios.
Esto se hizo mediante la vista de API de un registro de Accion. En la figura
6.12 podemos ver el dialogo de advertencia provisto por Django, así como la
respuesta del servidor posterior a la eliminación de un registro. Después de
las pruebas anteriores podemos concluir que el funcionamiento CRUD de los
directorios funciona correctamente.

6.3.2. Prueba de acceso


Dado que las URL son disponibles para todos los usuarios, un usuario fácil-
mente podría intentar acceder a URLs con identificadores numéricos aleatorios.
Para esto se ha implementado un filtro por sesión de acceso a los datos en to-
dos los directorios, para comprobar esta funcionalidad se procedió a crear una
persona desde una cuenta de usuario y después se intentó acceder a la URL de
esa persona desde otra cuenta de usuario, la figura 6.13 muestra el resultado
obtenido. Dado que el mismo mecanismo de filtrado por usuario está presente
en todos los directorios es seguro asumir que el comportamiento es el mismo en
ellos y la seguridad de acceso se mantiene.

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.

6.4. Sistema domótico


Las pruebas al sistema domótico fueron enfocadas en las dos principales fun-
cionalidades de este sistema: envío de mensajes SMS y aviso mediante activación
de fuente luminosa. Además, parte importante de este sistema es la obtención
de la información de las acciones generadas por la clasificación de las señales,
por lo tanto es necesario también hacer pruebas de comunicación con el sistema
en la nube.
En el capítulo anterior se detalló el desarrollo de la conexión entre el sistema
domótico y el módulo en la nube y se mostró el protocolo propuesto para la
consulta y confirmación de acciones. Sin embargo, como lo mostraron las pruebas
de comunicación de la simulación de la red de sensores, la confirmación de la
ejecución de las acciones resulta imposible, por lo tanto simplemente se hizo
una prueba de obtención de acciones. Como se puede ver en la figura 6.14 la
obtención de acciones fue exitosa por parte del código de conexión.
Seguido de la prueba anterior se realizaron dos pruebas por separado. Pri-
mero la prueba de envío de un mensaje SMS a partir de la información obtenida
de una acción del módulo en la nube. Para esta prueba en el sistema en la nube
se creó una acción de envío de mensaje con los datos de contacto de una persona
de prueba. En la figura 6.15 podemos ver la acción creada específicamente para
esta prueba y el mensaje recibido de ejecutar el código del sistema domótico bajo
condiciones normales. Además, podemos apreciar el mensaje de texto recibido
en el número de prueba que se encuentra en la acción de prueba.
Finalmente, se realizó una prueba de activación del módulo de aviso por
luminosidad. Para ello se repitió la prueba realizada para el módulo de envío
de mensajes, pero esta vez el registro de acción por realizar fue ajustado para
indicar una acción de aviso por luminosidad. En la figura 6.16 podemos ver la
acción registrada en el sistema y el foco utilizado para los avisos por luminosidad
siendo encendido. En este punto es pertinente mencionar que el siguiente paso
en las dos pruebas previas sería confirmar la ejecución de la acción mediante el
envío de una petición HTTP UPDATE hacia la URL de cada una de las acciones
consultadas y actualizar el campo ”completada” con un valor de tiempo ”date-
time.now()”. Para hacer una comprobación de este paso se haría una prueba de
dichas acciones, pero como se demostró en las pruebas de conexión al módulo en
la nube realizadas en la red de sensores parece ser que los métodos no seguros
de conexión no permiten el acceso aunque exista una sesión iniciada. En la tabla

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

Cuadro 6.2: Pruebas de ejecución de métodos no seguros desde la red de sensores


hacia el servidor Django con diferentes parámetros de inicio, valores de token
csrf y formas de presentación de la información.

6.2 podemos apreciar las pruebas de creación de registros mediante el método


POST. Estas pruebas muestran que aunque se cuenta con el token CSRF del
inicio de sesión, es necesario obtener un segundo token csrf para incluir con los
datos, sin embargo, este segundo token no puede ser extraído mediante métodos
de ”scrapping” o análisis de componentes HTML.

6.5. Pruebas integrales


Las pruebas integrales estuvieron centradas en los objetivos del proyecto:
Debe ocurrir una comunicación entres tecnologías específicas: una red de
sensores simulada y un sistema domótico.
La información generada por la red de sensores debe ser clasificada y con
base en dicha calificación disparar acciones en el sistema Domótico.
Para esto se propusieron tres pruebas que demostraron la conexión exitosa de
todos los componentes del sistema, cada una enfocada en los tres tipos de in-
formación que se planea detectar.
Cabe recordar de las pruebas de conectividad de la BSN que la transmisión
de datos desde la BSN hacia el servidor en la nube fue imposible. Por lo tanto
los datos que se mencionan a continuación fueron generados desde las vistas
API de los directorios respectivos con base en los datos generados por la BSN.
De igual manera, una vez ejecutada la acción debida por el sistema domótico no
hay forma de confirmar la ejecución de dicha acción mediante la actualización
de su registro en la base de datos, por lo tanto las imágenes de las pruebas
están acompañadas de marcas de tiempo que permiten comprobar el tiempo
que tarda el sistema en conjunto en llevar a cabo dichas acciones en cada estapa
del mismo.
La primer prueba consistió en enviar una señal que representara un latido de
ritmo sinusal normal. El resultado esperado es la generación de un registro de la
señal en el directorio de Señales del usuario. Como se puede apreciar en la figura
6.17, la generación de la señal desde la BSN tiene una marca de tiempo. Esta
marca de tiempo es utilizada para medir el tiempo de respuesta del sistema en

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.

este caso de prueba. Dadas las limitaciones mencionadas anteriormente, la señal


fue creada mediante la vista API del sistema, en la figura 6.18 podemos ver el
registro de señal generado y en la figura 6.19 podemos ver el directorio de Ac-
ciones que se encuentra vacío. La segunda prueba tuvo una naturaleza similar:
demostrar el comportamiento del sistema en general frente a la generación de
una señal con taquicardia. De igual manera se generó una señal, pero esta vez
fue una de las señales marcadas como señal que presenta taquicardia. De igual
manera dicha señal fue creada mediante la vista API del directorio de señales
6.20, después de la detección de la taquicardia el sistema generó una acción en
el directorio de acciones 6.21, la cual fue consultada por el sistema domótico
6.22 y con base en las reglas del mismo sistema envió un mensaje de texto, el
cual se puede ver en la figura 6.23.
La tercer y final prueba de igual manera pretende demostrar el comporta-
miento del sistema cuando se presenta un caso de fibrilación. De igual manera se
creó un registro de señal que se encuentra clasificada como fibrilación ventricular
6.24, después se puede apreciar la acción generada en el directorio de Acciones
6.25. Dicha acción es consultada de forma automática por el sistema domótico
6.26 y procesada de la forma determinada, es decir la activación intermitente

92
Figura 6.19: Directorio de acciones vacío después del registro de una señal con
ritmo sinusal normal.

Figura 6.20: Registro de señal que presenta taquicardia generado en la base de


datos.

Figura 6.21: Registro de acción generado después de la detección de una señal


que presenta taquicardia.

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.

de una notificación luminosa 6.27.

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.

Figura 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.

Figura 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 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 fibrilación.

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

Aunque las tecnologías IoT se encuentren en un auge constante, las metodo-


logías para interpretación de señales fisiológicas complejas es aún un área de la
ciencia donde hay muchas oportunidades de crecimiento, de hecho, los estudios
basados en información fisiológica obtenida de physionet y enfocadas en generar
datos similares son abundantes entre la comunidad científica. Este proyecto de
forma indirecta representa una parte de este avance constante en el área de las
señales fisiológicas pues ofrece un sistema de recolección, análisis e interpreta-
ción de dicha información. Además, este sistema ofrece un sistema que permite
asociar información fisiológica con acciones domóticas mediante el uso de publi-
cación de mensajes, los cuales especifican el tipo de acción a ser ejecutada y así
permiten autonomía a los sistemas domóticos.
Otro aspecto importante de notar es el avance que los sistemas IoT han te-
nido en cuanto a arquitecturas y diseño se refiere. Ya que si muchos trabajos
opinan que los desarrollos con arquitecturas optimizadas tiene ofrecen un mejor
rendimiento, también es cierto que la mayoría de desarrollos optan por arqui-
tecturas modulares con enfoques generales, pues esto permite crecimiento del
sistema por medio de la agregación de servicios e intercomunicación de sistemas
permitidas por las tecnologías actuales. Uno de los retos a futuro de los sistemas
IoT enfocados al monitoreo de la salud es la integración de módulos domóticos
junto con WSN o BSN dentro de los mismos canales de comunicación, ya que
ambas tecnologías suelen coexistir en el entorno de los pacientes monitoreados
pero, fuera de tecnologías de industria privada, casi no existen proyectos que
busquen unificar estas dos tecnologías. Otro de estos retos es la falta de están-
dares para la seguridad en las transmisiones de los dispositivos de gama baja, ya
que, aunque existen esfuerzos por asegurar esta capa de los sistemas IoT existen
vulnerabilidades que las tecnologías actuales no pueden evitar tener. Aunado
a esto, la heterogeneidad de las tecnologías involucradas en los sistemas IoT
aumenta el número de posibles ataques que estos sistemas pueden recibir, desde
suplantación en el consumo de servicios M2M o inyección SQL en las interfaces
de usuario hasta captación de paquetes en las capas middleware y suplantación
de nodos en la BSN.

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

En cuanto a trabajo a futuro se proponen distintos avances con base en lo


aprendido en el desarrollo del sistema. En primer lugar queda como trabajo a
futuro la implementación de un método de Big Data sobre la información gene-
rada, esto debido al hecho de que la información dentro de las bases de datos
nsrdb y cudb no es rica en detalles adicionales que permitan extrapolar infor-
mación adicional y tiene un tamaño muy reducido respecto a los conjuntos de
datos regularmente utilizados para Big Data. Además, un aspecto no explorado
fue la comunicación M2M entre sistemas en la nube, ya que, si bien las vistas
API proveen información vital donde los datos y sus acciones son mostradas en
la misma vista, es posible ver que esto requiere de pruebas y ajustes futuros que
permitan una mejor comunicación entre tecnologías de nube.
Se puede explorar también aumento en la modularidad del sistema ya que
de momento el sistema de detección y clasificación de arritmias es inherente al
proceso de creación de señales, por lo tanto no puede ser invocado por otras
instancias directamente, lo cual impide la implementación de distintos métodos
de análisis. Otro trabajo a futuro se enfoca los protocolos de acceso al medio
utilizados, los cuales no toman en cuenta la implementación de un sistema do-
mótico ni los dispositivos en él. Diseñar un protocolo que tome en cuenta el flujo
de información saliente de la red por parte de los nodos de la BSN y el flujo de
información entrante hacia los dispositivos domóticos, esto permitiría una opti-
mización en el uso de recursos y en la transmisión de la información. Finalmente,
se propone la implementación de un rango más amplio de dispositivos de baja
gama para realizar conexiones hacia el módulo Cloud, así como la descripción
de acciones más detalladas para los actuadores que permitan la interconexión
con electrodomésticos inteligentes. Esto permitiría un diseño más robusto de
una capa de middleware, sin dejar de lado la retroalimentación domótica del
sistema hacia el usuario.

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

También podría gustarte