Mendeley 20171002050541

Gestionando datos heterogéneos
provenientes de sensores para medir

la calidad del aire de Bogotá
Alexei Gabriel Ochoa Duarte
Universidad Nacional de Colombia

Facultad de Ingeniería.
Departamento de Ingeniería de Sistemas y Computación
Bogotá, Colombia
2017
Contenido III
Gestionando datos heterogéneos

provenientes de sensores para medir
la calidad del aire en Bogotá
Alexei Gabriel Ochoa Duarte
Tesis presentada como requisito parcial para optar al título de:

Magister en Ingeniería de sistemas y computación
Directora:
M.Sc. Libia Denisse Cangrejo Aljure
Codirectora:
Ph.D. Tatiana Delgado Fernández
Línea de Investigación:
Computación Aplicada, Sensor Web, Internet de las Cosas
Grupo de Investigación:
ANGeoSc
Universidad Nacional de Colombia

Facultad de Ingeniería.
Departamento de Ingeniería de Sistemas y Computación
Bogotá, Colombia
2017
Contenido V
“No es necesario conquistar el mundo, basta

con hacerlo de nuevo… Es necesario hacer
un mundo nuevo. Un mundo donde quepan
muchos mundos, donde quepan todos los
mundos... Yo soy como soy y tú eres como
eres, construyamos un mundo donde yo
pueda ser sin dejar de ser yo, donde tú
puedas ser sin dejar de ser tú, y donde ni yo
ni tú obliguemos al otro a ser como yo o
como tú.”
Subcomandante Insurgente Marcos

Contenido VII
Agradecimientos
Del mismo modo que en la dedicatoria uso una cita que plantea la necesidad de construir
un nuevo mundo en el que quepan todos los mundos posible, en los agradecimientos
quiero recordar la frase de Eduardo Galeano sobre la utopía en la que plantea que ésta
se encuentra en el horizonte y que sirve precisamente para caminar, pues esta idea
esencial e invisible a los ojos, como lo dice el Principito, es justamente el impulso que
nos hace ser mejores diariamente. Esto se debe ver expresado en el actuar cotidiano
para con la Universidad.
Desde mi punto de vista, una Universidad es mucho más que el conjunto que se
compone de una serie de personajes que la han transitado, un compendio de saberes
que se construyen desde los salones de clase, una serie de investigaciones y aportes a
la solución de problemas propios del país.
A mi manera de ver, la idea de universidad, es una utopía, es algo similar a la idea de

libertad de los zapatistas: “la libertad es como la mañana. Hay quienes esperan
dormidos a que llegue, pero hay quienes desvelan y caminan la noche para alcanzarla” y
día tras día debemos caminar y aportar en la construcción de una universidad en la que
no prime el capitalismo cognitivo, donde lo que importe realmente es el aprendizaje y no
la nota y en donde se utilice ese aprendizaje en la solución de problemas propios de la
comunidad.
Como planteó el Che Guevara, la Universidad se debe pintar de negro, de mulato, no

sólo entre los estudiantes, sino también entre los profesores y trabajadores; que se pinte
de obrero y de campesino, que se pinte de pueblo, porque la Universidad no es el
patrimonio de nadie y le pertenece al pueblo. Mediante la recuperación del sentido social
de las diferentes carreras no sólo de la Facultad sino de la Universidad en su conjunto se
mantendrá ese espíritu participativo, propositivo, crítico y transformador que la ha
caracterizado durante gran parte de su existencia.
La Universidad debe aprovechar que el país busca construir la paz, fomentando la

educación y las ganas de aprender y desarrollar alternativas que ofrezcan a la
comunidad la dignidad en cada uno de los aspectos de la vida. En este punto, y
recordando que como diría Eduardo Galeano: “somos lo que hacemos para cambiar lo
que somos”, este agradecimiento se transforma en una invitación a aportar, diariamente,
desde la experiencia de cada integrante de la Comunidad Universitaria y desde sus
posibilidades en la construcción cotidiana de una universidad que se acerque cada vez
más a la que soñamos.
Contenido IX
Resumen
El avance tecnológico y científico actual, ha impulsado el desarrollo de sistemas que
mejoren la calidad de vida de las personas, aportando bienestar a la comunidad
mediante el suministro de información relevante y pertinente para la toma de decisiones.
En el contexto tecnológico de Internet de las Cosas (IoT), estos sistemas suponen la
medición y el monitoreo de diversas variables del entorno.
La heterogeneidad propia de los datos capturados y los instrumentos de medición

utilizados, dificulta la interoperabilidad entre los diversos componentes de IoT. Tales
problemas han generado interés en el desarrollo de métodos y herramientas que
soporten la heterogeneidad de los datos de sensores, de las mediciones y de los
dispositivos de medición. Existen herramientas privadas que han resuelto algunos de
estos problemas de interoperabilidad pero restringen a los desarrolladores de proyectos
IoT a utilizar sensores de marcas específicas, limitando el uso generalizado en la
comunidad. Adicionalmente, se requiere resolver el reto de integrar protocolos diversos
en un mismo proyecto IoT.
Con el propósito de subsanar esas dificultades, se plantea una arquitectura basada en

redes de sensores y software inspirados en la cultura libre, que permita la comunicación
mediante protocolos diversos en un escenario de aplicación donde se monitorea la
calidad del aire para informar a los usuarios, y que mediante la generación de alertas
favorezca la toma de decisiones en su vida cotidiana, teniendo en cuenta los datos
provenientes de los sensores.
Palabras clave: Internet de las Cosas, Sensores, Interoperabilidad, Heterogeneidad,

Open source.
Resumen y Abstract X
Abstract
The current technological and scientific progress has promoted the development of
systems that improve people's quality of life, providing well-being to the community by the
supply of relevant information for decision-making. In the technological context of the
Internet of Things (IoT), these systems involve the measurement and monitoring of
various environmental variables.
The inherent heterogeneity of the captured data and the measurement instruments used
makes it difficult to interoperate between the various IoT components. Such problems
have generated interest in the development of methods and tools that support the
heterogeneity of sensor data, measurements and measurement devices. There are
private tools that have solved some of these interoperability issues but restrict IoT project
developers to use proprietary sensors, limiting widespread use in the community. In
addition, it is necessary to solve the challenge of integrating diverse protocols in the same
IoT project.
In order to overcome these difficulties, an architecture based on networks of sensors and

software inspired by the free culture is proposed, allowing communication through various
protocols in an application scenario where air quality is monitored to inform users, and
that through the generation of alerts favor the decision making in their daily lives, taking
into account the data coming from sensors..
Keywords: Internet of Things (IoT), Sensors, Interoperability, Heterogeneity, Open

source.
Contenido XI
Contenido
Pág.
Resumen IX
Lista de figuras XIII
Lista de tablas XIV
Lista de Símbolos y abreviaturas XV
Introducción 1
1. Planteamiento del problema 3

1.1 Preguntas de investigación 3
1.2 Objetivos 4
1.2.1 Objetivo general 4
1.2.2 Objetivos específicos 4
1.3 Alcance y limitaciones 5
1.3.1 Alcance 5
1.3.2 Limitaciones 5
2. Marco teórico 7
2.1 Sensores, redes de sensores, Internet de las Cosas y Sensor Web 7
2.2 Soluciones para la interoperabilidad 11
3. Metodología 17
4. Diseño e implementación 19
4.1 Componentes del sistema 21
4.1.1 Elementos de Hardware 21
4.1.2 Software utilizado en el sistema 25
4.2 Integración de los componentes de Hardware y Software del sistema 29
4.3 Configuración del sistema 29
4.3.1 Configuración inicial del hardware 29
b) Arduino UNO Wifi 1 y 2 34
4.3.2 Configuración del Software en la Raspberry Pi 3 36
4.4 Implementación del sistema 41
4.4.1 Módulo de registro de dispositivos y sensores 41
4.4.2 Módulo de mediciones, envío de datos por MQTT y generación de alertas
43
4.4.3 Módulo de visualización 45
XII
5. Pruebas y resultados 48
5.1 Pruebas 48
5.2 Resultados 48
6. Conclusiones, recomendaciones y trabajo futuro 49

6.1 Conclusiones 49
6.2 Recomendaciones y trabajo futuro 49
A. Anexo: Nombrar el anexo A de acuerdo con su contenido 51
B. Anexo: Nombrar el anexo B de acuerdo con su contenido 53
Bibliografía 55
XIII
Lista de figuras
Pág.
Figura 1: Estructura básica de una red de sensores....................................................7

Figura 2: Pirámide del conocimiento en el contexto de IoT..........................................8
Figura 3: Estructura básica de la Sensor Web.............................................................9
Figura 4: Capas e interacción entre ellas para la arquitectura de referencia.............20
Figura 5: Arquitectura solución..................................................................................29
XIV
Lista de tablas
Pág.
Tabla 1: Trabajos que usan la Sensor Web Enablement para la interoperabilidad......13

Tabla 2: Características de los sensores seleccionados..............................................21
Tabla 3: Características de los dispositivos utilizados..................................................22
Tabla 4: Comparación entre modelos Arduino.............................................................24
Tabla 5: Comparación entre modelos Raspberry Pi.....................................................25
Tabla 6: Características del software utilizado.............................................................26
Tabla 7: Características de las principales API utilizadas en el back-end....................27
Tabla 8: Características de las principales API utilizadas en el front-end.....................28
XV
Lista de Símbolos y abreviaturas

Esta sección incluye símbolos generales (con letras latinas y griegas), subíndices,
superíndices y abreviaturas (incluir sólo las clases de símbolos que se utilicen).
Símbolos con letras latinas

Símbolo Término Unidad SI Definición
m2
A Área
ver DIN ISO 9277
ABET Área interna del sólido
Ag Área transversal de la fase gaseosa m2 Ec. 3.2

As Área transversal de la carga a granel m2 Ec. 3.6
A Coeficiente 1 Tabla 3-1
Símbolos con letras griegas

Símbolo Término Unidad SI Definición
(wF,waf)(ABET)
α Factor de superficie
1
β Grado de formación del componente i
 Wandhafreibwinkel (Stahlblech) 1 Sección 3.2

1
 Porosidad de la partícula
Η mittlere Bettneigunswinkel (Stürzen) 1 Figura 3-1
Subíndices
Subíndice Término
Bm Materia orgánica
DR Dubinin-Radushkevich
E Experimental
XVI Contenido
Superíndices
Superíndice Término
N Exponente, potencia
Abreviaturas
Abreviatura Término
1.LT Primera ley de la termodinámica
DF Dimension fundamental
RFF Racimos de fruta fresca
Introducción
En la actualidad existe un interés creciente, por medir y monitorear numerosas variables
del entorno. Con el fin de proveer un mayor flujo de información, se hace necesaria la
interacción de sensores de última generación con diversos principios de funcionamiento,
para ofrecer mayores niveles de precisión, mayor eficiencia en el consumo de energía y
menores costos y la integración de sus mediciones. (Akyildiz et al, 2002; Razzaque et al
2016)
Los procesos de integración e interoperabilidad de la información generada por esta

clase de sensores tienen asociados importantes niveles de complejidad relacionados con
la heterogeneidad de los dispositivos, no sólo en sus principios de funcionamiento, sino
también en sus formatos, escalas y fuentes. (Perera et al, 2014). Hasta el momento, han
surgido múltiples esfuerzos orientados a la integración de dichas mediciones asociadas a
una gran diversidad de variables y protocolos. (Alaya et al, 2015; Asensio et al, 2014;
Bellavista et al, 2013; Jazayeri et al, 2015; Miorandi et al, 2012; Sicari et al, 2016; Wang
et al, 2015; Falocco et al, 2017; Jabbar et al, 2017; Sivarajah et al, 2017; Samara et al,
2016) Aunque en la revisión realizada, se evidencia la utilización de estándares, también
se revela su aplicación limitada al ámbito privado o en aplicaciones de dominio
específicas.
Adicionalmente, se identifica la necesidad de desarrollar arquitecturas y sistemas, que

sean desarrollados de manera comunitaria, favoreciendo la construcción colectiva del
conocimiento. (Blanco, et al, 2017) Por ello, la propuesta presentada en este artículo
enfatiza en el uso de herramientas de hardware y software libre, cuya filosofía de
creación otorga libertades básicas al usuario, para utilizar la herramienta con cualquier
propósito, estudiar su funcionamiento, con la posibilidad de modificarlo a conveniencia, y
además, contar con la disponibilidad de copias para distribuir de manera gratuita, o bien
con beneficios económicos.1 El uso de herramientas que adoptan esta filosofía fortalece
el trabajo colaborativo y facilita la solución de los problemas.
En este documento se presenta el desarrollo de un prototipo escalable de sistema de

medición y monitoreo de algunas variables ambientales relacionadas con la calidad del
aire. De esta manera, se puede contar con una serie de datos, que mediante un posterior
tratamiento se convertirán en información de gran utilidad para la toma de decisiones.
La estructura del presente documento, contempla un marco teórico que da sustento al

prototipo, seguido de la descripción de la arquitectura planeada. Posteriormente, se
describen los componentes del sistema, la manera como se integran en el prototipo y los
resultados obtenidos. Finalmente se plantea una discusión y las conclusiones obtenidas
del desarrollo del prototipo.
En la intro, el autor presenta y señala la importancia, el origen (los antecedentes

teóricos y prácticos), los objetivos, los alcances, las limitaciones, la metodología
empleada, el significado que el estudio tiene en el avance del campo respectivo y
su aplicación en el área investigada. No debe confundirse con el resumen y se
recomienda que la introducción tenga una extensión de mínimo 2 páginas y
máximo de 4 páginas.
.
1
Filosofía del software libre. Recuperada de: https://www.gnu.org/philosophy/free-sw.es.html
1.Planteamiento del problema
La tendencia emergente de los sensores y redes de sensores basados en la Internet de
las Cosas ha provocado que se puedan hallar, acceder y controlar vía Web múltiples
tipos de sensores, instrumentos, dispositivos para imagen y repositorios de datos de
sensores (Chu & Buyya, 2007a). Esto implica que exista heterogeneidad entre los datos
que se pueden obtener, lo cual dificulta la integración de la información obtenida de
diversas fuentes. (Corcho & García-Castro, 2010).
En el contexto de este trabajo, con el objetivo de solventar el problema de la

heterogeneidad inherente a los sensores y sus mediciones, se plantea el desarrollo de
una aplicación, en el marco de la Internet de las Cosas (IoT), que integre datos
provenientes de diferentes fuentes y que permita la interoperabilidad y el acceso a los
mismos. Así, para alcanzar dicho objetivo, el trabajo se centrará en los datos de la
calidad del aire en Bogotá D.C., como caso de uso. Además, se utilizarán los
2
estándares fijados por el OGC para la Sensor Web Enablement (SWE) , en especial, la
SensorThings API3.
1.1 Preguntas de investigación

Ahora bien, surgen los siguientes interrogantes que deben ser tenidos en cuenta durante
la investigación:
2
Estándar ideado por el Open Geospatial Consortium (OGC) que comprende un conjunto de
especificaciones relacionadas con sensores, modelos de datos de sensor y servicios web de
sensor destinados a hacer accesibles los datos vía Web, facilitando su descubrimiento, acceso,
asignación de tareas, y gestión de eventos y alertas.
3
Estándar del OGC que proporciona un marco abierto y unificado, basado en la IoT, para conectar
y ofrecer interoperabilidad tanto sintáctica como semántica de las mediciones realizadas por
sensores.
 ¿Cómo solucionar el problema de la heterogeneidad de los sensores y sus
mediciones de cara a las necesidades de interoperabilidad?
 ¿Cuáles de los estándares existentes en OGC son los más pertinentes para este
desarrollo?
 ¿Cómo integrar los datos georreferenciados provenientes de los diversos
sensores en una aplicación sensible al contexto?
1.2 Objetivos
1.2.1 Objetivo general

Desarrollar una aplicación, en el marco de la Sensor Web y la Internet de las cosas, que
integre datos de diferentes fuentes y que permita la interoperabilidad y el acceso a los
mismos
1.2.2 Objetivos específicos

 Realizar búsquedas sistemáticas de bibliografía y artículos científicos sobre el
tema, que permitan identificar el estado del arte.
 Profundizar en el conocimiento de herramientas computacionales que permitan la

elaboración de aplicaciones que utilicen los conceptos y estándares
seleccionados..
 Precisar las capacidades mínimas de los sensores seleccionados como fuentes

de información.
 Recolectar datos procedentes de diversas fuentes sobre la calidad del aire en

Bogotá.
 Diseñar e implementar una aplicación, utilizando estándares de OGC y W3C, que

permita explotar los datos de calidad del aire en Bogotá.
 Dar a conocer y socializar los resultados parciales y finales de la investigación.

Capítulo 1 5
1.3 Alcance y limitaciones
1.3.1 Alcance
El prototipo que se plantea en este documento utiliza algunos sensores de variables
relacionadas con la calidad del aire, a saber, temperatura, humedad, densidad de polvo,
presión atmosférica y concentraciones de gases como el monóxido y el dióxido de
carbono, los óxidos de nitrógeno y el amoniaco en el aire.
Los sensores y dispositivos con los cuales se desarrolla el prototipo se basan en la

filosofía libre, lo cual otorga libertades básicas al usuario, para utilizar la herramienta con
cualquier propósito, estudiar su funcionamiento, con la posibilidad de modificarlo a
conveniencia, y además, contar con la disponibilidad de copias para distribuir de manera
gratuita, o bien con beneficios económicos.4
Las mediciones realizadas por el prototipo se hacen en un ambiente cerrado, donde se

conectan los dispositivos de manera fija y se realizan perturbaciones para observar
cambios en las variables en poco tiempo. El proceso de medición de las variables se
hace cada treinta segundos con el fin de obtener gran cantidad de datos en poco tiempo.
1.3.2 Limitaciones
El prototipo realiza las mediciones encontrándose estático en el lugar inicial desu
instalación.
Los dispositivos de medición se conectan a la red de área local y las mediciones son
almacenadas en una base de datos local que se comparte en una página web que se
encuentra dentro de la red local.
4
Filosofía del software libre. Recuperada de: https://www.gnu.org/philosophy/free-sw.es.html
2.Marco teórico
2.1 Sensores, redes de sensores, Internet de las

Cosas y Sensor Web
Un sensor es un dispositivo capaz de detectar la medida de una magnitud, llamada
variable de instrumentación, y convertirla en una señal eléctrica que puede ser
procesada, almacenada o transmitida de acuerdo a la finalidad definida por el usuario.
(Bröring et al., 2011)
En la actualidad, se utilizan sistemas de medición, instrumentados con múltiples

sensores interconectados, conocidos como redes de sensores, los cuales integran
avances en tecnología electrónica, de comunicación y de computación, que permiten
utilizar redes interconectadas de dispositivos de medición, buscando obtener mediciones
más precisas y distribuidas tanto espacial como temporalmente. (Cecílio & Furtado,
2014) En la Figura 1: Estructura básica de una red de sensores se puede observar la
estructura básica de una red de sensores.
Figura 1: Estructura básica de una red de sensores
Fuente: (Yinbiao et al., 2014)

Los nodos de sensores que se muestran en la Error: Reference source not found son el
componente central de una red de sensores y generalmente se componen de: un módulo
encargado de gestionar la energía para su funcionamiento, un sensor, un
microcontrolador y un transmisor inalámbrico. (Yinbiao et al., 2014)
Los avances tecnológicos han hecho posible el despliegue masivo de pequeños

dispositivos distribuidos, con características de bajo costo, bajo consumo de energía, y
con capacidad de procesamiento local y comunicación inalámbrica, lo cual ha propiciado
el desarrollo de un nuevo paradigma, llamado Internet of Things (IoT) (Atzori et al, 2010)
(Miorandi et al., 2012), en el cual existe una numerosa cantidad de dispositivos y objetos
físicos que se encuentran interconectados a Internet. (Rose Jaren, Eldridge Scott, 2015)
De esta manera, las redes de sensores se constituyen en una fuente de datos primaria
para IoT (Partynski & Koo, 2013)(Rezvan & Barekatain, 2015), dado que suministran una
cantidad voluminosa de datos provenientes de sensores diversos, no sólo en sus
principios de funcionamiento, sino también en las escalas de medición, la precisión con la
cual realizan la medición, los formatos y unidades de medida, entre otras
especificaciones.
Las mediciones provenientes de los sensores y redes de sensores de naturaleza

heterogénea deben ser interoperables (Ko et al., 2011) no sólo entre sí, sino también con
información adicional que las personas puedan proveer sobre las variables medidas
(Bakillah, Liang, Zipf, & Arsanjani, 2013). Es por ello que se ha desarrollado una escala,
que se observa en la Figura 2, que permite establecer una jerarquía del conocimiento en
el ámbito de la IoT.
Figura 2: Pirámide del conocimiento en el contexto de IoT
Fuente: (Barnaghi, Wang, Henson, & Taylor, 2012)

Marco teórico 9
En esta pirámide se observa que los datos provenientes de las redes de sensores
constituyen un insumo primordial para la información y el conocimiento que favorecen la
toma de decisiones para los usuarios.
Debido a la heterogeneidad existente en los sensores, que se puede apreciar en la

Figura 3, han surgido conceptos y estándares que buscan solventar las dificultades
asociadas a la integración e interoperabilidad de los datos provenientes de sensores y
redes de sensores.
Figura 3: Estructura básica de la Sensor Web
Fuente: Adaptada de (Botts, Percivall, Reed, & Davidson, 2008)
El primer concepto de Sensor Web, como medio para lograr la interoperabilidad de datos
provenientes de sensores, la establecía como un sistema de sensores inalámbricos,
intra-comunicados y distribuidos espacialmente, que pueden ser fácilmente desplegados
para monitorear y explorar nuevos ambientes. (Delin & Jackson, 2001)
Posteriormente, el Open Geospatial Consortium (OGC) definió este concepto como una
red de sensores y datos almacenados de sensores, que se pueden acceder vía web
usando protocolos de estándares e interfaces de programas de aplicación. (Percivall,
Reed, & Davidson, 2007)
Otros autores (Chu & Buyya, 2007b) establecen que la Sensor Web es una tendencia
emergente en la cual varios tipos de sensores, instrumentos, dispositivos para imagen y
repositorios de datos de sensores se pueden hallar, acceder y controlar vía la World
10 Marco teórico
Wide Web, lo cual hace que la Sensor Web actúe como un tipo especial de información
centrada en la red, para acopiar, modelar, almacenar, recuperar, compartir, manipular,
analizar y visualizar información y observaciones de fenómenos con sensores. (Sheth,
Henson, & Sahoo, 2008a)
Junto a estas definiciones, merece especial atención el desarrollo de una infraestructura

de información geoespacial abierta para Sensor Web, llamada GeoSWIFT (Geospatial
Sensor Web Information Fusion Technology) (Liang, Tao, & Croitoru, 2004), que sirve
como una puerta de enlace para integrar y fusionar las observaciones de sensores
espaciales heterogéneos. Con su trabajo pretenden que la integración de GeoSWIFT con
la Sensor Web permita la captura rápida por demanda de información con sensor y que
apoye la toma informada de decisiones. Además, en su trabajo resaltan la naturaleza de
la tecnología Sensor Web: interoperable, inteligente, escalable y de alta resolución.
Con la Sensor Web han surgido iniciativas que responden a la urgencia de contar con
estándares suficientes para hacer posible la interoperabilidad y transferencia de los datos
de sensor de diversas fuentes. Las principales iniciativas existentes, son la Sensor Web
Enablement (SWE), para direccionar los esfuerzos de estandarización en términos de
interoperabilidad sintáctica, y la Semantic Sensor Web (SSW), para proveer la
interoperabilidad semántica a sensores y datos.
La SWE define servicios que permiten un uso interoperable de los recursos de los
sensores facilitando su descubrimiento, acceso, asignación de tareas, y gestión de
eventos y alertas. Con la definición de interfaces de servicio estandarizadas, una
aplicación basada en servicios SWE, oculta la naturaleza heterogénea de la red de
sensores, tanto en aspectos de los componentes de hardware como en los de
comunicación. (Percivall & Reed, 2006) De esta manera, busca proveer un marco
interoperable de estándares para acceder y codificar los datos de sensor, describir los
metadatos de sensores, alertar con base en datos de mediciones con sensores y
controlarlos. (Gibbons, Karp, Nath, & Seshan, 2003)(Balazinska et al., 2007)
Los estándares propios de la SWE no proporcionan instalaciones para la extracción,

clasificación y razonamiento ofrecido por las tecnologías semánticas. Por tal razón surge
la Semantic Sensor Web (SSW). Esta iniciativa del W3C, se busca garantizar una gestión
Marco teórico 11
de la información de sensores de muy diversas fuentes, con mayor accesibilidad y

expresividad mediante su representación semántica, proporcionando mayor significado a
las observaciones de los sensores y además permitiendo el conocimiento de las
situaciones que los sensores observan. (Sheth et al, 2008)
Además, la introducción de semántica ofrece la oportunidad de ir hacia una etapa

posterior en la comprensión, gestión y uso de las fuentes de datos provenientes de
sensores (Corcho et al, 2010).
2.2 Soluciones para la interoperabilidad

La Sensor Web además de ser un buen diseño, ser de fácil implementación y
mantenimiento, también debe proveer, también, información relevante para los usuarios,
proveniente de información geográfica voluntaria. Este tipo de trabajo en la se evidencia
en propuestas como un sistema de observaciones de sensores basado en el
almacenamiento de datos por parte de los usuarios para el monitoreo de disponibilidad
de agua. (Jürrens, Bröring, & Jirka, 2009) o para el manejo de situaciones de crisis
(Schade, Luraschi, De Longueville, Cox, & Díaz, 2010).
En cuanto a aplicaciones que buscan el análisis de variables ambientales y manejo de

desastres, el proyecto europeo OSIRIS (Open architecture for Smart and Interoperable
networks in Risk management based on In-situ Sensors) estudia los incendios forestales,
la contaminación del aire, la detección de incendios en edificaciones, la contaminación
del agua y los riesgos de inundación. (Jirka, Bröring, & Stasch, 2009a) Éste proyecto
ofrece también mecanismos para la búsqueda de sensores, el uso de relaciones
semánticas y la recolección de metadatos de los sensores. (Jirka, Bröring, & Stasch,
2009b)
Como la Sensor Web permite el encuentro, el acceso y el control vía Internet de

diferentes tipos de sensores, instrumentos de medición, dispositivos de imágenes y
repositorios de datos, se han diseñado arquitecturas como la OSWA (Open Sensor Web
Architecture) (Chu & Buyya, 2007b) que proporciona servicios adicionales al proceso de
recolección de información, permitiendo que la Sensor Web sea escalable y obteniendo
un buen rendimiento en la implementación.
12 Marco teórico
Cabe resaltar el proceso metodológico para el desarrollo de aplicaciones de la Sensor

Web utilizando Software libre. Mediante la utilización de este tipo de software y su
integración con los estándares definidos por el OGC, se facilita el desarrollo de
aplicaciones a más bajo costo (Bröring & Jürrens, 2009). De igual manera, se han
propuesto enfoques para la búsqueda de datos y servicios dentro de la Sensor Web
mediante aplicaciones móviles utilizando software libre. Estos servicios deben cumplir
algunos requerimientos tales como eficiencia del recurso y los contextos espacial,
temporal y temático, para que la arquitectura sea exitosa. Su prototipo va dirigido al
monitoreo de la calidad del aire (Foerster, Nüst, Bröring, & Jirka, 2012).
Se ha desarrollado un prototipo de aplicación web que utiliza la Sensor Web Semántica

para ofrecer soporte a las decisiones ambientales y el manejo de emergencias por
inundaciones utilizando software libre, lo cual hace que sea adecuada para personas que
toman decisiones pero que no tienen altos recursos presupuestales y deben ofrecer una
respuesta rápida (Gray et al., 2011).
A continuación, en la Tabla 1, se muestran algunas aplicaciones basadas en la Sensor

Web con el fin de lograr la interoperabilidad de datos provenientes de sensores.
Tabla 1: Trabajos que usan la Sensor Web Enablement para la interoperabilidad

Servicios
Trabajo Dominio (Tema) implementados Aplicaciones
Manejo de desastres Protección de las líneas eléctricas de los incendios

AFIS 2.0 naturales SOS, SAS, WNS forestales
CEOS CalVAL Manejo de desastres

Satellite Sensors naturales SOS Inundaciones
CSIRO Hydrological
Sensor Web Hidrología SOS Meteorología, Inundaciones
Modelamiento Monitoreo de exposición humana a polución y

EO2HEAVEN ambiental SOS detección temprana de infecciones
Manejo de riesgos y Apoyo a administradores de eventos de crisis de

ESS crisis SOS, SPS, SES duración anormal
SOS, WNS, SES, SIR, Calidad del aire, calidad del agua, y calidad del agua
GENESIS Estudios ambientales SOR en las zonas costeras
Servicio orientado al usuario que permite compartir

GeoCENS Varios dominios SOS, SPS datos de sensores biológicos y geocientíficos
GITEWS Manejo de desastres SOS Sistema de advertencia temprana de Tsunamis

Marco teórico 13
naturales
Servicios orientados a la comunidad para monitoreo

H2.0 Hidrología SOS,SES,WNS del suministro de agua en el Este de Africa
Human Sensor Web Hidrología SOS Abastecimiento y saneamiento de agua
Asignación automática en tiempo real de variables

interpolación de ambientales críticas, usando estadística espacial,
observaciones en intercambio de datos y herramientas de visualización
INTAMAP tiempo real SOS vía Web
Oceans IE Oceanografía SOS Estudios del océano
OOSTETHYS Oceanografía SOS Proyecto comunitario para observación oceanográfica
Administración de SOS, SAS, SPS, SES, Incendios forestales, riesgos industriales,

OSIRIS riesgos WNS, SIR, SOR contaminación de agua y de aire
PEGELONLINE Hidrología SOS Nivel de agua
Q2O Oceanografía SOS Estudio de olas, corrientes, oxígeno diluído
Sensors Anywhere Administración de

(S@NY) riesgos SAS, SOS, SPS Monitoreo de la calidad del aire
UNCERTWEB –
Project Modelado Web SOS Manejo de incertidumbre
Series de tiempo para supervisar el almacenamiento

Wupperverband Hidrología SOS, SAS, SPS de agua
El paradigma de Internet de las Cosas (IoT) ha proporcionado nuevas herramientas,

arquitecturas y servicios que pretenden mejorar la interoperabilidad de los datos
provenientes de sensores heterogéneos. (Guinard, Trifa, Karnouskos, Spiess, & Savio,
2010)(Kortuem, Kawsar, Fitton, & Sundramoorthy, 2010)(Castillejo, Martinez, Lopez, &
Rubio, 2013)
Un ejemplo donde las tecnologías de detección juegan un papel importante lo constituyen

las ciudades inteligentes, que usan los sensores como componente crucial de los
sistemas de control (control de la contaminación ambiental, control de humedad y de
radiación atmosférica, control o alerta temprana de inundaciones, etc.) (Hancke, de Silva,
& Hancke, 2013). En las ciudades inteligentes y los hogares inteligentes, se ha planteado
el uso de un modelo de sensores como servicio, que consta de cuatro etapas: (i)
sensores y propietarios de sensores; (ii) editores de sensores (SPs); (iii) proveedores de
servicios ampliados (ESP); y (iv) consumidores de datos de sensores. De esta manera,
los costos se reducen, se hace una implementación basada en la nube, se favorece la
14 Marco teórico
reutilización y el intercambio de datos (Perera, Zaslavsky, Christen, & Georgakopoulos,

2014b) (Perera, Zaslavsky, Liu, et al., 2014).
Se han identificado retos para la integración de datos provenientes de redes de sensores,

en el marco de la IoT (Miorandi et al., 2012; Partynski & Koo, 2013) (Partynski & Koo,
2013)(Gubbi, Buyya, & Marusic, 2013), en cuanto a tres ejes principales: Seguridad
(acceso no autorizado, negación del servicio), Hardware (suministro de energía,
procesamiento) y Software (algoritmos, automatización de las redes) (Partynski & Koo,
2013).
Existen diseños funcionales e implementaciones de plataformas que pueden utilizarse

para una amplia gama de aplicaciones IoT. Para ello es importante tener en cuenta
requisitos como el costo, la cantidad de sensores, la velocidad de despliegue, la vida útil,
el mantenimiento, la calidad del servicio (Lazarescu, 2013). Algunas aplicaciones utilizan
herramientas basadas en la filosofía libre para la implementación de sus soluciones para
los problemas derivados de la heterogeneidad de los sensores. (Sim, 2016) En esta
propuesta se utiliza una tarjeta Arduino que se integra con un servicio SOS con el fin de
proveer un sistema de bajo costo para la medición de la temperatura y humedad del aire.
También, existe una propuesta llamada SEnviro, basada en el uso de hardware y
estándares abiertos, que ha sido probada en mediciones ambientales en un campus
universitario, y que busca como trabajo futuro, soportar conectividad Bluetooth y
mediante el uso de redes móviles. (Trilles et al., 2015).
A medida que surgen nuevas características en la IoT, se requieren tecnologías

interoperables orientadas a servicios para compartir datos del mundo real entre
dispositivos heterogéneos que integren y fusionen los datos provenientes de diversas
fuentes (Wang et al., 2015). Para abordar estos problemas, se requiere el desarrollo de
arquitecturas que puedan servir de guía para el desarrollo de la fusión de la información
de IoT, es por eso que existen propuestas orientadas a servicios distribuidos para esta
tarea. De esta forma, cada fabricante proporciona servicios para sus propios productos, y
los nodos de datos mantienen la información recopilada por ellos mismos (Zhu, Dhelim,
Zhou, Yang, & Ning, 2016). También, existen propuestas de arquitecturas que establecen
los componentes de las capas IoT de la siguiente manera: 1) sensores y actuadores, 2)
Marco teórico 15
puertas de enlace, 3) servidores de borde y de contexto, y 4) aplicaciones (Cardozo,

Yamin, Xavier, et al., 2016).
Uno de los protocolos utilizados para el envío y recepción de datos provenientes de

sensores en el marco de IoT es el MQTT (Message Queue Telemetry Transport) que
consiste en un protocolo de mensajería de publicación/suscripción extremadamente
ligero (Špeh & Heđ, 2016), que permite la comunicación Machine to machine (M2M). En
este protocolo existe un controlador central, llamado broker, que envía, filtra y prioriza las
solicitudes que llegan de los nodos subscriptores. (Tantitharanukul, Osathanunkul,
Hantrakul, Pramokchon, & Khoenkaw, 2017b)
Los mensajes enviados por los sensores o sistemas embebidos mediante este protocolo
deben definir dos elementos que incluyen mensaje y topic para el MQTT broker. El
mensaje, es una cadena de caracteres que contiene los datos a compartir con los
subscriptores al topic, mientras que este último es otra cadena que permite filtrar y decidir
quiénes pueden recibir el mensaje, mediante subscripción. (Špeh & Heđ, 2016)
De esta manera, se pueden integrar datos provenientes de diversas fuentes, que envían
sus mensajes a los topics correctos, ayudando así a la solución de los problemas
causados por la heterogeneidad de las fuentes de datos. Además, este protocolo es
eficiente para gestionar datos a un bajo costo y se integra fácilmente con sistemas
basados en software y hardware libre, teniendo una gran amplia gama de aplicaciones
que van desde la domótica hasta las ciudades inteligentes. (Kodali & Mahesh, 2016; Sim,
2016; Tantitharanukul, Osathanunkul, Hantrakul, Pramokchon, & Khoenkaw, 2017a)
3.Metodología
Se deben incluir tantos capítulos como se requieran; sin embargo, se recomienda que la
tesis o trabajo de investigación tenga un mínimo 3 capítulos y máximo de 6 capítulos
(incluyendo las conclusiones)
4.Diseño e implementación
Para el planteamiento de la arquitectura del sistema, además de tener en cuenta los
dispositivos a utilizar, se ha tomado como base la propuesta de arquitectura en capas
para aplicaciones IoT (Cardozo, et al, 2016), que establece un diseño cuyos
componentes base son: 1) sensores y actuadores, 2) puertas de enlace, 3) servidores de
borde y de contexto, y 4) aplicaciones.
La arquitectura desarrollada en la Figura 4 presenta como componentes de Hardware los

sensores, la tarjeta de desarrollo que permite integrar las mediciones y la interfaz de
comunicaciones; como componentes de Software los diferentes programas, aplicaciones
y APIs que integran los datos en Internet y permiten interactuar con otras aplicaciones.
De igual manera, teniendo como referencia la arquitectura base (Cardozo, Yamin, &
Souza, 2016), se plantea la siguiente descripción de cada una de las capas que
componen el sistema:
A. Capa física y de acceso a la red: en esta capa se encuentran los dispositivos

sensores y la tarjeta de desarrollo en la cual se integran las mediciones
realizadas. Estos dispositivos se encargan de hacer las mediciones, suministrar
la energía al sistema y ser el enlace con la interfaz de comunicaciones,
mediante el programa cargado en la tarjeta.
B. Capa de red: es la encargada de establecer la comunicación entre los datos

medidos y el servidor Web de la siguiente capa. Consta de un módulo de
conexión que facilita la transferencia de los datos a la red, un protocolo de
comunicaciones y un lenguaje de intercambio que facilita la transferencia de
datos.
C. Capa de transporte: se encarga de interconectar las mediciones recibidas por el
servidor back-end5 con el resto de Internet. Consta de una plataforma en la que
se implementa una base de datos, donde se almacenan los mensajes recibidos,
y un servidor Web embebido en una plataforma de integración en el que se
elabora una API REST6 capaz de relacionarse con la base de datos, permitiendo
o negando el acceso y la manipulación de los datos recibidos en el lenguaje de
intercambio utilizado. También, se encarga de implementar un servidor desde el
que se atienden las solicitudes realizadas por la capa de aplicación.
D. Capa de aplicación: en esta capa se encuentran los clientes front-end7 que se

comunican con el servidor de la capa de transporte, mostrando así, de manera
cómoda para los usuarios, los resultados que se obtienen de las solicitudes
realizadas al servidor.
Figura 4: Capas e interacción entre ellas para la arquitectura de referencia
En la figura anterior se observan la estructura del sistema y la manera como fluyen los
datos y la información en el sistema a través de cada una de las capas descritas con
anterioridad.
5
Parte de una aplicación web que se encarga de gestionar las bases de datos, hacer las
validaciones necesarias, especificar las rutas de navegación y montar un servidor desde el que se
atienden las solicitudes de los clientes.
6
Enfoque de desarrollo de proyectos y servicios basados en la Web. Es un estándar eficiente para
la creación de interfaces de desarrollo de aplicaciones API en Internet que se basa en el uso del
protocolo HTPP para interactuar con diversidad de formatos de datos.
7
Parte de una aplicación web encargada de implementar las vistas e interfaces con las que
interactuará el usuario final. Para el desarrollo de esta capa se usan principalmente tecnologías
propias de un navegador Web.
4.1 Componentes del sistema
4.1.1 Elementos de Hardware
A continuación se describen los dispositivos físicos que se usan para este sistema,
clasificándolos como sensores, tarjetas de desarrollo, dispositivos de comunicación y
plataforma de integración.
 Sensores
Los sensores a utilizar en el prototipo, se han seleccionado teniendo en cuenta la
heterogeneidad propia de ellos en cuanto a sus principios de funcionamiento, variables
de medida, señales de salida, entre otros aspectos. Una breve descripción de los
sensores y sus características se muestra en la Tabla 2.
Tabla 2: Características de los sensores seleccionados.
Sensor Variables Unidade Precisió Principio de Voltaje de Señal de Foto

de medida s de n funcionamien funcionamien salida
medida to to
MQ78 Concentraci ppm Depende Resistivo PWM Análoga

ón CO de la alternante
resistenci entre 1.4V y
a de 5V
carga
MQ1359 Concentraci ppm Depende Resistivo 5V Análoga

ón CO2, de la
NOx, NH3 resistenci
a de
carga
DHT1110 Temperatura °C y % ±2°C y NTC y 5V Digital

y humedad ±5% Resistivo calibrada
DHT2211 Temperatura °C y % ±0.5°C y Capacitivo 5V Digital

y humedad ±2% calibrada
8
MQ7 Semiconductor sensor for carbon monoxide. Su URL es:
http://eph.ccs.miami.edu/precise/GasSensorSpecs/CO.pdf
9
MQ135 Gas sensor- Technical data. Su URL es:
https://www.olimex.com/Products/Components/Sensors/SNS-MQ135/resources/SNS-MQ135.pdf
10 .
DHT11 Humidity & Temperature Sensor Datasheet. Su URL es:
http://www.micropik.com/PDF/dht11.pdf
11
DHT22 Humidity & Temperature Sensor Datasheet. Su URL es:
https://www.sparkfun.com/datasheets/Sensors/Temperature/DHT22.pdf
BMP18012 Presión y hPa y °C ± hPa y Piezo-resistivo 3.3V Interfaz
temperatura ±0.1°C I2C
GP2Y1010AU0 Densidad de mg/m³ ±0.1 Óptico 5V Análoga

F13 polvo mg/m³
GPS Neo-6M14 Posición Latitud y ± 3m Satelital 3.3 - 5V Digital sin

geográfica longitud calibrar
(m)
 Tarjetas de desarrollo, módulos de comunicaciones y plataformas de integración

Aquí se relaciona el uso de tecnologías basadas en la filosofía libre, con la intención de
permitir un trabajo colaborativo entre usuarios que favorezca el proceso de diseño e
implementación del prototipo planteado. Estas tecnologías se describen en la Tabla 3.
Tabla 3: Características de los dispositivos utilizados
Tarjeta de desarrollo Módulo de comunicaciones Plataforma de integración

Dispositivo Arduino15 ESP826616 Raspberry Pi17
seleccionado
Características Esta tarjeta funciona como Una vez realizada la conexión Mini computador de placa
relevantes el nodo de la red de con la red Wifi, el módulo es reducida y de bajo costo,
sensores que permite capaz de enviar información que se ha diseñado para
centralizar y procesar las proveniente de los sensores facilitar el aprendizaje y la
mediciones realizadas por hacia una dirección IP y puerto educación en las ciencias
los sensores descritos que sean establecidos. de la computación, creado
anteriormente. Además, por la Raspberry Pi
poseerá la capacidad de Foundation.
conectarse a internet para
enviar y recibir información
relevante para el sistema.
12
BMP 180 Digital pressure sensor. Datasheet. Su URl es: https://cdn-
shop.adafruit.com/datasheets/BST-BMP180-DS000-09.pdf
13
GP2Y1010AU0F Compact Optical Dust Sensor Datasheet. Su URL es: https://cdn-
shop.adafruit.com/datasheets/BST-BMP180-DS000-09.pdf
14
GPS Neo 6-M Datasheet. Su URL es: https://www.u-
blox.com/sites/default/files/products/documents/NEO-6_DataSheet_(GPS.G6-HW-09005).pdf
15
Compañía italiana, que funciona bajo filosofa libre. Produce tarjetas de desarrollo que utilizan
microcontroladores y entornos de desarrollo (IDE).
16
Módulo de comunicaciones que prove soporte Wifi y es compatible con las tarjetas de desarrollo
Arduino.
17
Página Web oficial de Raspberry Pi Foundation. https://www.raspberrypi.org/
Interfaz de Arduino IDE, basado en Comandos AT18 especiales Soporta sistema operativo
programación lenguaje C. para comunicación con Linux específico para la
módems e interfaces de tarjeta, llamado Raspbian19.
telecomunicaciones.
Selección de los De acuerdo a la Tabla 4 Teniendo en cuenta la
dispositivo información de la Tabla 5
De acuerdo a las tablas 1 y 2, se observa la heterogeneidad inherente a los sensores y

dispositivos de hardware que son utilizados a lo largo del desarrollo, y los cuales se
integran y se hacen interoperables a partir de la propuesta esbozada en este artículo.
a) Selección de la tarjeta Arduino

Arduino presenta una gran variedad de tarjetas de desarrollo, basadas en
microcontroladores, que vienen acompañadas de un entorno de desarrollo agradable y
cómodo, así como de un lenguaje de programación sencillo y completo.
A continuación, la Tabla 4 se muestra una tabla que permite comparar las

especificaciones técnicas de diversos modelos de tarjetas Arduino.
Tabla 4: Comparación entre modelos Arduino

Modelo Voltaje de Voltaje de Flash SRAM I/O Pines UART Características
operación alimentación (KB) (KB) digitales analógicos especiales
/ PWM (I/O)
Uno 5V 7 – 12 V 32 2 14/6 6/0 1 -
Pro 5V 5 – 12 V 32 2 14/6 6/0 1 -
Pro Mini 5V 3.35 – 12 V 32 2 14/6 6/0 1 -
Leonardo 5V 7 – 12 V 32 2.5 20/7 12/0 1 -
Micro 5V 5V 32 2.5 20/7 12/0 1 -
Mega 5V 7 – 12 V 256 8 54/15 16/0 4 -
Mega 5V 7 – 12 V 256 8 54/15 16/0 4 -
ADK
Due 3.3 V 7 – 12 V 512 96 54/12 12/2 4 -
Ethernet 5V 7 – 12 V 32 2 14/4 6/0 - -
Lilypad 3.3 V 2.7 – 5.5 V 32 2 9/4 4/0 - -
Esplora 5V 5V 32 2.5 N/A N/A - -
Nano 5V 7 – 12 V 32 2 22/6 8/0 1 -
Uno Wifi 5V 7 – 12 V 32 2 14/6 6/0 1 Cuenta con un
módulo
ESP8266
integrado, y
soporta el
protocolo MQTT.
101 3.3 V 7 – 12 V 196 24 14/4 6/0 1 Bluetooth de
(tolera 5 V baja energía,
en pines acelerómetro de
18
Lenguaje estándar abierto de comandos para configurar y parametrizar módems. Fue creado
por la compañía Hayes Communications. La siguiente URL muestra un instructivo para su uso:
http://www.electronicaestudio.com/docs/ISTD-034.pdf
19
Distribución Linux, basada en Debian, específica para la Raspberry Pi. Se encuentra disponible
en https://www.raspberrypi.org/downloads/raspbian/
I/O) 6 ejes,
giroscopio,
microcontrolador
Intel Curie
Yún 5V 5V 32 2.5 20/7 12/12 1 Conexiones
Ethernet y Wifi,
lector de tarjetas
micro SD
Zero 3.3 V (no 7 – 12 V 256 32 20/18 6/1 2 -
tolera otros
voltajes)
Fuente: Adaptación de ¿Cuál Arduino Comprar? Disponible en:

http://5hertz.com/tutoriales/?p=571#1.QAC y revisión de la página web oficial de Arduino.
Se ha optado por usar tarjetas Arduino UNO Wifi y Arduino UNO, que cuenta con
entradas análogas para los sensores, salidas digitales, comunicación serial y
comunicación Wifi mediante el módulo ESP8266.
Estas tarjetas funcionan como nodos de la red de sensores que permite centralizar y
procesar las mediciones realizadas por los sensores descritos anteriormente. Además,
poseerán la capacidad de conectarse a internet para enviar y recibir información
relevante para el sistema.
b) Selección de la Raspberry Pi
Para continuar con el uso de tecnologías basadas en la filosofía libre, se utilizará un mini
computador de placa reducida de bajo costo, que se ha diseñado para facilitar la
enseñanza y el aprendizaje de las ciencias de la computación, creado por la Raspberry
Pi Foundation.
A continuación, en la Tabla 5, se pueden apreciar las especificaciones de diversos

modelos de tarjetas Raspberry Pi.
Tabla 5: Comparación entre modelos Raspberry Pi

Modelo RAM USB Video Audio Boot Red Consumo Alimentación
Model A 256 MB 1 RCA, Jack, SD - 300 mA Micro USB/
HDMI HDMI 1.5 W GPIO
5V
Model A+ 256 MB 1 Jack, Jack, Micro SD - 400 mA Micro USB/
HDMI HDMI 2W GPIO
5V
Model B 512 MB 2 RCA, Jack, SD Ethernet 700 mA Micro USB/
5V
Model B+ 512 MB 4 Jack, Jack, Micro SD Ethernet 500 mA Micro USB/
5V
2 Model B 1 GB 4 Jack, Jack, Micro SD Ethernet 800 mA Micro USB/
HDMI HDMI 4W GPIO
5V
Zero 512 MB 1 micro Mini Mini Micro SD - 160 mA Micro USB/
5V
3 Model B 1 GB 4 Jack, Jack, Micro SD Ethernet, 2.5 A Micro USB/
HDMI HDMI Wifi, 12.5 W GPIO
Bluetotth 5V
Fuente: Comohacer.eu. Disponible en:

http://comohacer.eu/wp-content/uploads/comparativa-raspberry-pi.png
La Raspberry seleccionada, es la Raspberry Pi 3 Model B, puesto que cuenta con mayor

capacidad de procesamiento y además conexión Wifi y Bluetooth integradas.
4.1.2 Software utilizado en el sistema

Con el fin de hacer interoperables las mediciones de los sensores descritos en el
apartado anterior, se hace necesario el uso de un protocolo de comunicaciones que
permite recibir datos de diversas fuentes simultáneamente.
Uno de los protocolos utilizados para el envío y recepción de datos provenientes de

sensores en el marco de IoT es el MQTT (Message Queue Telemetry Transport) que
consiste en un protocolo de mensajería de publicación/suscripción extremadamente
ligero (Špeh et al, 2016) , que permite la comunicación Machine to machine (M2M). En
este protocolo existe un controlador central, llamado broker, que envía, filtra y prioriza las
solicitudes que llegan de los nodos subscriptores. (Tantitharanukul et al, 2017)
Los mensajes enviados por los sensores o sistemas embebidos mediante este
protocolo deben definir dos elementos que incluyen mensaje y topic para el MQTT
broker. El mensaje, es una cadena de caracteres que contiene los datos a compartir con
los subscriptores al topic, mientras que este último es otra cadena que permite filtrar y
decidir quiénes pueden recibir el mensaje, mediante subscripción.(Špeh et al, 2016)
De esta manera, se pueden integrar datos provenientes de diversas fuentes, que

envían sus mensajes a los topics correctos, ayudando así a la solución de los problemas
causados por la heterogeneidad de las fuentes de datos. Además, este protocolo es
eficiente para gestionar datos a un bajo costo y se integra fácilmente con sistemas
basados en software y hardware libre, teniendo una gran amplia gama de aplicaciones
que van desde la domótica hasta las ciudades inteligentes. (Kodali & Soratkal, 2016;
Kodali & Mahesh, 2016)
Con el fin de que la Raspberry tenga acceso a los datos, pueda manipularlos y
visualizarlos, se hace necesaria la instalación de algunos programas que se muestran en
la Tabla 6.
Tabla 6: Características del software utilizado

Broker MQTT Base de datos Lenguaje de Lenguaje para el
intercambio de desarrollo Web
datos
Herramienta Mosquitto20 MongoDB21 JSON22 NodeJS23
Características Permite realizar los Base de datos NoSQL Formato de texto Los datos
relevantes procesos de (Not Only SQL) que bastante ligero que almacenados en la
publicación / permiten un enfoque es de fácil lectura y Base de datos, deben
suscripción en la hacia la gestión de escritura tanto para ser accedidos por
Raspberry. datos y el diseño de los humanos como herramientas que
Se puede integrar base de datos de para las máquinas, permitan su
con sensores de baja utilidad para conjuntos siendo tratamiento,
potencia o de datos distribuidos, independiente del visualización y
dispositivos móviles como los provenientes lenguaje que lo conexión con diversas
como teléfonos, mini de los sensores. genere. aplicaciones.
computadores como Guarda las estructuras De manera general Entorno de ejecución
la Raspberry o de datos en documentos un documento basado en JavaScript,
microcontroladores similares a JSON, JSON se estructura que se conecta con la
como Arduino facilitando la integración mediante la base de datos y
de los datos en utilización de una permite hacer el
aplicaciones de manera lista ordenada de tratamiento y la
rápida. parejas implementación de
Organiza sus bases de nombre/valor. servicios y
datos en colecciones, y aplicaciones web.
dentro de ellas se
insertan documentos en
los que se tiene un
identificador y un valor
asignado para esta
variable, soportando así
consultas dinámicas
más eficientes que en
otros sistemas de bases
de datos.
20
Sitio web de Mosquitto. Su URL es: https://mosquitto.org/
21
Página web de MongoDB. Su URL es: https://www.mongodb.com/
22
Acrónimo de JavaScript-Object Notation, es un formato de texto ligero para el intercambio de
datos.
23
Página web de NodeJS. Su URL es: https://nodejs.org/es/. Este entorno de ejecución posee un
ecosistema de librerías de código abierto muy amplio.
 Interfaces de programación de aplicaciones (API)
Como NodeJS tiene una amplia variedad de librerías disponibles para programar, se
establecen dos interfaces que permiten aumentar la interoperabilidad de los datos
provenientes de los sensores y la generación de alertas de acuerdo a las mediciones. A
continuación, la Tabla 7, presenta la descripción de las principales interfaces utilizadas en
el servidor.
Tabla 7: Características de las principales API utilizadas en el back-end
Nombre Aporte al sistema

24
Express Infraestructura de aplicaciones web para Node.js que ofrece un conjunto de características para las
aplicaciones web y móviles. Cuenta con gran variedad de métodos HTTP y un middleware que facilita la
creación de aplicaciones.
Socket.io25 Librería de NodeJS que permite crear aplicaciones en tiempo real para casi todos los navegadores y
dispositivos móviles, utilizando diferentes mecanismos y protocolos de transporte.
JADE26 Motor de plantillas de alto rendimiento, implementado con JavaScript para nodeJS y navegadores. Permite
realizar documentos HTML para optimizar las rutas en las aplicaciones web.
Handlebar Motor de plantillas, parecido a JADE, que es utilizado para la creación de plantillas de tablas y gráficas.
s27
Chartjs28 Generador de gráficos, basado en JavaScript que simplifica la labor de elaborar diagramas y figuras
basadas en datos.
 Herramientas para la visualización
Las aplicaciones realizadas con NodeJS pueden ser accedidas mediante un navegador
Web, accediendo a la dirección IP donde se encuentra alojado el servicio, esto sin
importar si se trata de un PC, un portátil, una Tablet, un Smartphone u otra clase de
dispositivo.
El diseño front-end del cliente se basa en la interactividad y la respuesta de las

aplicaciones a las solicitudes del usuario final. Para esto, se utilizan algunas técnicas,
lenguajes y APIs que se describen en la Tabla 8.
Tabla 8: Características de las principales API utilizadas en el front-end
24
Página web de Express. Su URL es: http://expressjs.com/
25
Página web de Socket.io. Su URL es: https://socket.io/
26
Página web de JADE. Su URL es https://www.npmjs.com/package/jade
27
Página web de Handlebars. Su URL es https://github.com/ericf/express-handlebars
28
Página web de ChartJs. Su URL es http://www.chartjs.org/
AJAX29 Técnica de desarrollo web que es utilizada para la creación de aplicaciones interactivas que son ejecutadas por
el cliente, al tiempo que se mantiene una comunicación asíncrona con el servidor.
JQuery30 Librería amplia y versátil de JavaScript que funciona en gran variedad de navegadores y hace que las
peticiones AJAX y la manipulación de documentos HTML se haga de manera más sencilla.
CSS31 Lenguaje que se utiliza para describir el estilo de un documento HTML. Con este lenguaje se diseña el estilo de
los diferentes componentes de una página web.
HTML32 Lenguaje estándar a cargo del W3C33 que define la estructura básica y el código necesario para definir el
contenido de un sitio Web.
4.2 Integración de los componentes de Hardware y

Software del sistema
En la sección anterior se han definido diversas tecnologías que se integran en el
desarrollo del prototipo de sistema IoT para la medición de calidad del aire.
A continuación, en la Figura 5, se muestra la arquitectura solución utilizada para el

prototipo. En esta figura se observan los diferentes componentes del sistema y se puede
apreciar la manera en la que interactúan para el correcto funcionamiento del prototipo.
29
Acrónimo de Asynchronous JavaScript And XML.
30
Página web de JADE. Su URL es https://www.npmjs.com/package/jade
31
Acrónimo de Hoja de estilos en Cascada. Es una tecnología utilizada junto con JavaScript y
HTML para el desarrollo de aplicaciones web.
32
Acrónimo de Lenguaje de Marcado para Hipertextos. Se usa para crear la representación visual
de una página web.
33
Consorcio internacional que define estándares y recomendaciones para el crecimiento de la
World Wide Web a nivel mundial
Figura 5: Arquitectura solución
4.3 Configuración del sistema
4.3.1 Configuración inicial del hardware

Inicialmente, se utiliza una tarjeta Arduino UNO para probar cada uno de los sensores
que se utilizarán en el proyecto.
Para tal fin, se realizan montajes simples y se utilizan programas sencillos que son
cargados en la tarjeta, con el fin de mostrar los valores de las mediciones realizadas por
cada sensor.
Para probar los sensores, se hace necesario crear unos pequeños programas en el
entorno de desarrollo de Arduino que permitan visualizar los datos tomados en el puerto
serial.
También, se hace necesario descargar algunas librerías de Arduino para el correcto

funcionamiento de los sensores enunciados anteriormente.
Librería Sensor que la usa Enlace para descargar
SimpleDHT DHT11 y DHT22 https://github.com/winlinvip/SimpleDHT
SFE_BMP180 BMP180 https://github.com/LowPowerLab/SFE_BMP180
TinyGPSPlus GPS Neo-6m https://github.com/mikalhart/TinyGPSPlus
 Configuración de cada sensor

Para probar los sensores, se hace necesario crear unos pequeños programas en el
entorno de desarrollo de Arduino que permitan visualizar los datos tomados en el puerto
serial.
También, es importante descargar algunas librerías de Arduino para el correcto

funcionamiento de los sensores enunciados anteriormente.
a) Sensores DHT11 y DHT22

Estos sensores constan de tres terminales, de las cuales una es la salida digital del
sensor y las otras dos son la alimentación del mismo (5V y GND).
El DHT11 funciona para mediciones de temperatura entre 0 y 50ºC, ofreciendo una

precisión de ±2ºC. En cuanto a la humedad relativa, su rango de funcionamiento es de 20
a 90% de humedad en el aire, con una precisión de ±5%. Sin embargo, estas
condiciones pueden variar de acuerdo a la temperatura de operación del sensor.
Por su parte el DHT22 funciona para mediciones de temperatura entre -40 y 80ºC,
ofreciendo una precisión de ±0.5ºC. En cuanto a la humedad relativa, su rango de
funcionamiento es de 0 a 100% de humedad en el aire, con una precisión de ±2%. Sin
embargo, al igual que con el DHT11, estas condiciones pueden variar de acuerdo a la
temperatura de operación del sensor.
Ambos sensores incluyen un componente de medida de humedad que funciona de

manera resistiva, y un termistor NTC para la medida de temperatura. Las señales de
medición se conectan con un microcontrolador que las digitaliza en 8 bits para dar una
medición digital de las variables.
En la librería descargada SimpleDHT se encuentran ejemplos de la utilización de cada

uno de los sensores.
b) Sensores MQ7 y MQ135

Estos sensores análogos son sensibles a diferentes gases ambientales como: Monóxido
de Carbono (CO) (MQ7) y Dióxido de carbono (CO2), Óxidos de nitrógeno (NOx) y
Amoniaco (NH3) (MQ135).
Estos sensores, constan de cuatro terminales, una de ellas es una salida análoga, otra es
una salida digital y las demás se usan para alimentación del dispositivo (5V y GND).
El MQ7 es capaz de medir la concentración de (CO) en el aire en un rango de 10 a

10000 ppm, con una sensibilidad de ±3%.
Dependiendo de los valores de las resistencias de carga, el MQ135 puede medir gases
como el dióxido de carbono, el metano, entre otros.
Para la correcta utilización de estos sensores, se hace necesario realizar una calibración
consistente en conectarlo a una fuente de alimentación durante 24 horas continuas y
posteriormente ajustar las resistencias de carga para realizar la medición.
Además, se requiere utilizar el conversor Análogo – Digital con que cuenta el

microcontrolador de la tarjeta, para obtener una lectura digital de la concentración de los
gases en el aire.
c) Sensor BMP180
Este sensor digital, funciona con un voltaje de 3.3V y es capaz de medir presión
atmosférica con una precisión de 0.12 hPa en condiciones normales. Para estas
mediciones usa un principio piezo-resistivo.
En cuanto a la medición de temperatura, el componente sensor se basa en el principio
resistivo, llegando a obtener mediciones de una precisión alrededor de los 0.5°C.
La señal de salida del sensor utiliza el bus de comunicación I2C (Interfaz de 2 cables)
que se conectan a las entradas análogas A4 y A5 de la tarjeta Arduino para su
funcionamiento.
Teniendo en cuenta que se ha descargado la librería SFE_BMP180 y que en ella se
encuentran ejemplos de funcionamiento, se carga el programa
SFE_BMP180_example.ino con el fin de hacer las pruebas.
d) Sensor GP2Y1010AU0F
Este sensor, se basa en el principio óptico para su funcionamiento. Internamente tiene un
LED infrarrojo que se conecta a una de las salidas digitales de la Arduino y que por
medio de principios ópticos es capaz de medir la densidad de polvo presente en el aire.
Su estructura básica consta de 6 terminales (2 para la alimentación del sensor 5V y GND,
otros 2 para la alimentación del LED y los otros 2 para la conexión de un condensador y
la salida del sensor).
La señal proveniente del sensor es análoga, por lo cual debe hacerse un proceso de
calibración del sensor para obtener las mediciones.
De acuerdo con su datasheet, este sensor es capaz de medir concentraciones de hasta

0.1mg/m³.
e) Sensor GPS Neo-6m

Este sensor de ubicación geográfica consta de 4 terminales, 2 de ellos para alimentación
(5V y GND) y los otros 2 para comunicación serial (Tx y Rx) utilizada para enviar los
datos de posicionamiento provenientes de los satélites.
La señal de salida del sensor es conectada a un puerto serial de la tarjeta Arduino con el
fin de recibir la comunicación para que el programa cargado en la tarjeta tenga acceso a
las variables de latitud y longitud.
El sistema GPS incorporado en este sensor presenta dificultades para el posicionamiento
cuando se prueba en interiores, haciendo necesario que se ubique cerca de las
ventanas. Por otra parte, en espacios abiertos el sensor presenta un mejor rendimiento.
Para la conexión del sensor carga el código a la Arduino que proviene de los ejemplos de
la librería TinyGPS++.
 Configuración de los dispositivos de medición
Después de haber probado cada uno de los sensores, se procede a hacer la conexión de
cada uno de ellos a los dispositivos correspondientes, de acuerdo a la siguiente
distribución:
Protocolo de
Tarjeta Arduino Sensores conectados Programa cargado en la tarjeta
comunicación
UNO Wifi MQ7, BMP180y DHT11 MQTT

CO_DHT11_BMP_MQTT.ino
UNO Wifi 2 MQ135, GP2Y1010AU0Fy DHT22 MQTT CO2_DHT22_Polvo_MQTT.ino
StandardFirmdatadisponible en la
UNO GPS Neo-6m Comunicación serial
librería Firmdata
a) Arduino UNO
Esta tarjeta de desarrollo tiene conectado únicamente el GPS y se comunicará con
la Raspberry Pi 3 mediante la comunicación serial propia del cable USB.
La tarjeta Arduino es programada con el sketch StandardFirmdata disponible en la
librería Firmdata del Arduino IDE. Se utiliza este programa para que esta tarjeta se
comunique con la Raspberry mediante un código escrito en NodeJS que utiliza Jhonny-
five para adquirir los datos y hacer su procesamiento.
Esta tarjeta únicamente envía el dato inicial de posicionamiento del sistema, pues se
supone que éste se encuentra fijo.
5. Arduino UNO Wifi 1 y 2
Estas tarjetas deben ser configuradas para que su conexión a internet se efectúe
automáticamente a la red. A continuación y antes de continuar con la configuración, es
importante que la tarjeta se encuentre con el Firmware actualizado. Posteriormente, se
configura la conexión MQTT de la tarjeta.
Es importante resaltar que estas tarjetas tienen internamente un módulo ESP8266 que
les permite conectarse a internet. Además, tienen una interfaz de
configuración MQTT que permite utilizar máximo 3 tópicos para el envío y recepción de
mensajes.
Los tópicos utilizados contienen el nombre del dispositivo central y del sensor en
cuestión. Un ejemplo de tópico es: arduinoUNOWifi/MQ7.
Los mensajes enviados por los sensores se encuentran en el lenguaje de

intercambio JSON, que facilita su entendimiento tanto poe los humanos como por las
máquinas.
En cada una de estas tarjetas se conectan 3 sensores, con el fin de utilizar un

tópico MQTT por cada uno de ellos.
Esquema de conexión para los sensores MQ7, DHT11 y BMP180.

Esquema de conexión para los sensores MQ135, DHT22 y GP2Y1010AU0F.
Las mediciones de cada uno de los sensores son enviadas por el protocolo MQTT hacia
el bróker cada 30 segundos. Sin embargo, este tiempo puede ser modificado fácilmente
al cambiar el valor del delay en los códigos Arduino
5.1.1 Configuración del Software en la Raspberry Pi 3
 Disposiciones iniciales
Para comenzar a usar la tarjeta, es importante descarga el sistema operativo. En este

caso, utilizamos Raspbian, un sistema operativo basado en Debian que le da
la Raspberry la posibilidad de instalar software que se utilizará para el desarrollo,
tanto back-end como front-end de la aplicación web.
El sitio web oficial de Raspberry ofrece un enlace para descargar la última versión
de Raspbian Stretch. Esta versión del sistema operativo se descargará en una
tarjeta micro SD clase 10 que será el disco duro del mini computador.
Después de tener el sistema operativo cargado en la Raspberry se procede a hacer la

instalación de las herramientas básicas para el desarrollo de la aplicación. Para ello se
abre una terminal en la que se escribirán los siguientes comandos:
curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -

sudo apt-get update && sudo apt-get upgrade
sudo apt-get install nodejs npm
sudo apt-get install git
Con esas líneas de código, se realiza una actualización de los repositorios de

la Raspberry e instalamos NodeJS, su gestor de paquetes npm y el controlador de
versiones git.
La instalación de la base de datos MongoDB y el broker MQTT Mosquitto se realizan con

los siguientes comandos.

sudo apt-get install mongodb-server
sudo service mongod start
wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
sudo wget http://repo.mosquitto.org/debian/mosquitto-jessie.list
sudo -i
sudo apt-get install mosquitto
sudo apt-get install mosquitto-clients
De esta manera, la Raspberry cuenta con el software necesario para la implementación

del sistema.
MongoDB se inicia automáticamente al entrar al sistema operativo. Por el

contrario Mosquitto necesita ser configurado para iniciarse al acceder al sistema,
mediante un script.
En este momento, al revisar las versiones de cada uno de los programas instalados
mediante los siguientes comandos, se observa .
mosquitto -v
npm -v
node -v
git --version
mongo --version
Con la finalidad de acceder siempre a la Raspberry mediante la misma dirección, se
configura una IP estática, modificando el archivo /etc/dhcpcd.conf
 Herramientas y módulos a instalar
a) Redis
Es un motor de base de datos en memoria que se basa en el almacenamiento de

tablas hash (clave/valor) que puede ser utilizado para la implementación de bases de
datos persistentes.
Esta base de datos, complementa el servicio ofrecido por MongoDB en el módulo de

registro de dispositivos y sensores.
Se hace necesario realizar la instalación de este gestor como un programa aparte.

Cuando ya se encuentra instalado este gestor de bases de datos, puede ser probado
mediante el comando redis-cli a lo cual debe responder 127.0.0.1:6379>
b) Módulos de NodeJS
A lo largo del desarrollo de los módulos que componen del software embebido en
la Raspberry se utiliza una serie de módulos que se resumen en la siguiente tabla.
Módulo Aporte al sistema
Infraestructura de aplicaciones web NodeJS que proporciona un conjunto sólido de características para las
Express aplicaciones web y móviles. Cuenta con gran variedad de métodos HTTP y un middleware que facilita la
creación de aplicaciones
Librería de NodeJS que permite crear aplicaciones en tiempo real para casi todos los navegadores y
Socket.io
dispositivos móviles, utilizando diferentes mecanismos y protocolos de transporte
_Framework: de programación de código abierto utilizado para aplicaciones de robótica e IoT, que permite
Jhonny-five
escribir programas para Arduino y Raspberry
Motor de plantillas de alto rendimiento, implementado con JavaScript para NodeJS y navegadores. Permite
JADE
realizar documentos HTML para optimizar las rutas en las aplicaciones web
Handlebars Motor de plantillas, parecido a JADE, que es utilizado para la creación de plantillas de tablas y gráficas.
Módulo Aporte al sistema
Generador de gráficos, basado en JavaScript que simplifica la labor de elaborar diagramas y figuras
Chart.js
basadas en datos
Redis Módulo NodeJS que permite conectar las aplicaciones con las bases de datos de redis
Express- Módulo que habilita la utilización de mensajes emergentes en el navegador, que pueden ser configurados
flash como error, información o éxito
Librería que cuenta con diversidad de algoritmos para el cifrado de los datos. Se utiliza para cifrar las
Crypto contraseñas antes de ser guardadas en la base de datos. También, es usada para descifrar los datos
cuando es requerido
Módulo que habilita la conexión de la aplicación con MongoDB y que además permite la creación de
Mongoose
modelos para la base de datos
Express-
Se encarga de gestionar las sesiones abiertas al crear usuarios y hacer login
session
Serve-
favicon Habilita la utilización de un archivo .ico que se usará como icono en el navegador donde se carga la
aplicación
Morgan Habilita que se muestren en consola cada una de las solicitudes GET y POST de la API REST
Body-parser Permite que la aplicación tome datos desde formularios y cuadros que interactúan con el usuario
Cookie-
Gestiona las cookies que se crean en cada sesión de usuario
parser
Path Habilita que la aplicación pueda utilizar rutas de archivos
Method-
Permite la sobreescritura de métodos. Es útil para la implemenatción de los métodos PUT de la API REST
override
Connect-
Habilita la conexión con las bases de datos redis
redis
Express-
Al ser configurado, permite que la aplicación envíe correos electrónicos
mailer
MQTT Gestiona la comunicación vía MQTT de la aplicación, habilita la conexión con Mosquitto
Habilita la comunicación de la aplicación con las bases de datos de MongoDB. La principal diferencia
Mongodb
con Mongoose es que MongoDB no permite la creación de modelos de datos
Moment Facilita el uso y maniṕulación de datos propios de la variable tiempo

Todos estos módulos de NodeJS son instalados en la carpeta requerida mediante el
comando npm install nombre_modulo --save donde cada nombre de módulo se escribe
en minúsculas.
c) APIs y lenguajes utilizados para el front-end

Las aplicaciones realizadas con NodeJS pueden ser accedidas mediante un
navegador Web, mediante la conexión con la dirección IP donde se encuentra alojado el
servicio, esto sin importar si se trata de un PC, un portátil, una Tablet, un Smartphone u
otra clase de dispositivo.
El diseño front-end del cliente se basa en la interactividad y la respuesta de las

aplicaciones a las solicitudes del usuario final. Para esto, se utilizan algunas técnicas,
lenguajes y API's que se describen en la siguiente tabla.
Técnica de desarrollo web que es utilizada para la creación de aplicaciones interactivas que son ejecutadas
AJAX
por el cliente. mientras se mantiene una comunicación asíncrona con el servidor
Librería amplia y versátil de JavaScript que funciona en gran variedad de navegadores y hace que las
JQery
peticiones AJAX y la manipulación de documentos HTML se haga de manera más sencilla
Lenguaje estándar a cargo del W3C que define la estructura básica y el código necesario para definir el
HTML
contenido de un sitio Web
Lenguaje que se utiliza para describir el estilo de un documento HTML. Con este lenguaje se diseña el estilo
CSS
de los diferentes componentes de una página web.
Bootstrap Framework para HTML, CSS y JavaScript muy popular para el desarrollo de sitios web interactivos y móviles
Las APIs y Frameworks utilizados no se descargan localmente, sino que son cargados
mediante los CDN (redes de entrega de contenidos, que básicamente son redes de
computadores que tienen copias de datos en varios puntos de la red, permitiendo que los
usuarios accedan rápidamente a los datos) directamente en la capa front-end del cliente.
5.2 Implementación del sistema
El desarrollo del sistema IoT se basa en tres módulos que se encuentran programados
en NodeJS y ejecutan aplicaciones web directamente en la Raspberry Pi.
5.2.1 Módulo de registro de dispositivos y sensores

Consiste en una aplicación que utiliza NodeJS, Express, Socket.io y otras API con el fin
de realizar el modelo de la base de datos y hacer el registro de los sensores y
dispositivos que se utilizan en el prototipo. Esta aplicación tiene una interfaz gráfica que
facilita al usuario la realización del registro y actualización de los datos de sensores.
Además, se encarga de hacer las validaciones necesarias para el usuario.
La estructura básica de este módulo consta de 6 carpetas y 4 archivos que se explican a

continuación:
 Carpetas
A continuación se enuncian los nombres de las carpetas existentes en este módulo,

enunciando su contenido y su aporte al funcionamiento del módulo.
Carpeta Contenido y aporte al módulo
archivo favicon.ico y carpetas css, img y js* que sirven para dar estilo a la página Web que se carga del lado del
Public
cliente
node_mo variedad de carpetas de instalación de los módulos que se requieren para ejecutar el archivo
dules principal app.js que se encuentra en la raíz del módulo
archivos .jade** que se distribuyen en diferentes carpetas y son los encargados de la renderización de la página
Views
en sus diferentes rutas
archivos user.js, devices.js y sensors.js*** que modelan la base de datos de MongoDB donde se almacenarán
Models
los valores de las mediciones realizadas por los sensores
contiene los
archivos gps.js, metadata.js,properties.js, datastream.js, featureOfInterest.js, observation.js, observedProperties
App
.jsroutes_app.js y routes_sensor.js**** que se encargan de la configuración de variables y rutas que se cargan
en el archivo app.js
en su interior se encuentran los

Middlewar archivos session.js, find_device.js, find_sensor.js, device_permission.js y sensor_permission.js***** que
es permiten controlan el acceso a la aplicación y habilitan las operaciones de acceso y modificación de dispositivos
y sensores
[*]: El archivo favicon.ico es una imagen que carga en la parte superior izquierda del navegador al carga la aplicación. La
carpeta css contiene una hoja de estilos para la página. Por su parte, la carpeta img contiene algunas imágenes que se
cargan en las diferentes vistas de la aplicación. Finalmente, la carpeta js contiene el archivo client.js que se encarga de
manejar el tiempo real de la aplicación en cuanto a la conexión de usuarios y actualización de dispositivos y sensores.
[**]: Estas plantillas son las encargadas de renderizar las diferentes URL que se cargan en las rutas de la aplicación.
[***]: Estos archivos son los mismos del módulo de mediciones, envío de datos por MQTT y generación de alertas
[****]: El archivo gps.js se encarga de obtener los datos de latitud y longitud del sistema mediante el uso de johnny-five y
crear una colección en la base de datos para la posición geográfica de los dispositivos. Los metadatos de los sensores son
asignados mediante el archivo metadata.js. De igual manera, las propiedades de los dispositivos son asignadas mediante
el archivo properties.js. Por su parte, los archivos routes_app.js y routes_sensor.js se encargan de las rutas y los
algoritmos para hacer operaciones CRUD con los dispositivos y sensores respectivamente. Adicionalmente, los
archivos datastream.js, featureOfInterest.js, observation.js y observedProperties.js se encargan de modelar la base de
datos de acuerdo a la especificación del estándar Sensorthing del OGC.
[***** ]: Estos archivos se encargan de gestionar las sesiones, las búsquedas de dispositivos y sensores y los permisos
para edición de los mismos.
 Archivos
Los archivos que se encuentran en la carpeta raíz de este módulo se explican a

continuación:
Archivo Contenido y aporte al módulo
archivo que contiene metadatos del módulo, como el nombre del autor, la licencia, palabras clave, y las
package.json
dependencias de módulos necesarias para la ejecución del archivo principal app.js, entre otras cosas
package- archivo complementario del package.json que facilita la instalación de las mismas versiones de los módulos
lock.json utilizados en el proyecto cuando se ejecuta un npm install
archivo que configura el uso de socket.io para la conexión y actuialización de la base de datos en tiempo
realtime.json
real
app.js archivo principal ejecutable cuando se aplica el comando node app.jsdentro de la carpeta del módulo
a) app.js
La estructura del archivo contiene los require de los diferentes módulos a utilizar, la
configuración básica de algunos de ellos
como mongoose, express, socket.io, jade, express-flash, crypto, express-mailer, entre
otros. Adicionalmente se hace require de otros archivos .js que se encuentran en la
estructura del proyecto.
También posee funciones como encrypt(text) y decrypt(text) que se usan para cifrar y
descifrar la contraseña del correo electrónico, tanto del usuario como del administrador
del sistema.
Además, se establecen las rutas que seguirá la aplicación para la creación, lectura,
edición y eliminación de usuarios, dispositivos y sensores.
5.2.2 Módulo de mediciones, envío de datos por MQTT y

generación de alertas
Es el encargado de la comunicación MQTT entre las tarjetas Arduino y la Raspberry. No
cuenta con interfaz gráfica, pero implementa un sistema de alertas en caso de que las
mediciones excedan valores determinados por el usuario.
continuación:
 Carpetas

archivos user.js, devices.js y sensors.js* que modelan la base de datos de MongoDB donde se almacenarán los
Models
valores de las mediciones realizadas por los sensores
node_module variedad de carpetas de instalación de los módulos que se requieren para ejecutar el archivo principal app.js que se
s encuentra en la raíz del módulo
archivo email.jade** que constituye la plantilla de los correos electrónicos envíados como alertas cuando las
Views
mediciones salen de los límites establecidos por el usuario
[*]: Estos archivos son los mismos del módulo de registro de dispositivos y sensores
[**]: El correo electrónico enviado por la aplicación contiene en su cuerpo una cadena de caracteres con los valores del
archivo .JSON recibido de los sensores.
 Archivos

continuación:
package.json
a) app.js
configuración básica de algunos de ellos como express-mailer.
También posee 4 funciones (un par de ellas, encrypt(text) y decrypt(text) se usan para
cifrar y descifrar la contraseña del correo electrónico que se usa para enviar las alertas,
otra función generateAlert(key,valores) se encarga de hacer la comparación de los
valores medidos por cada sensor con los límites que establece el usuario dentro de la
función y hacer el llamado correspondiente a sendMail(sub,data,key), que se encarga de
enviar el correo electrónico con la alerta requerida).
Adicionalmente, en la estructura del archivo se realiza la suscripción de la aplicación a

los tópicos MQTT definidos en la configuración de las Arduino UNO Wifi, lo cual permite
recibir los mensajes enviados por ellas. A continuación, realiza la conexión con la base de
datos MongoDB y luego de verificar si es necesario o no generar una alerta, se encarga
de insertar las nuevas mediciones en la base de datos establecida para cada sensor.
5.2.3 Módulo de visualización

Su tarea consiste en hacer peticiones a la base de datos, hacer algunas
transformaciones de los mismos para organizarlos en un formato que mediante la
comunicación con ChartJS proporcione al usuario la visualización del estado de las
variables medidas por los sensores de manera gráfica.

continuación:
 Carpetas

archivo favicon.ico y carpetas css, img y js* que sirven para dar estilo a la página Web que se carga del
public
lado del cliente
variedad de carpetas de instalación de los módulos que se requieren para ejecutar el archivo
node_modules
principal app.js que se encuentra en la raíz del módulo
archivos chart.handlebars, view.handlebars** que son cargados en los archivos disponibles dentro de la
Views carpeta layouts : main.handlebars y main2.handlebars***, que constituyen las plantillas para la realización
de las gráficas (en tiempo real e históricas respectivamente) de las mediciones realizadas
[*]: El archivo favicon.ico es una imagen que carga en la parte superior izquierda del navegador al carga la aplicación. La
carppeta css contiene una hoja de estilos para la página. Por su parte, la carpeta img contiene algunas imágenes que se
cargan en las diferentes vistas de la aplicación. Finalmente, la carpeta js contiene dos
archivos: AirChart.js y AirChart2.js que se encargan de recuperar los datos de las mediciones de la URL en la que se
almacenan en el archivo app.js, configurar las gráficas de cada sensor, hacer las peticiones AJAX necesarias y actualizar
la página usando socket.io para el manejo de Websockets.
[**]: Archivos que permiten cargar la vista de cada una de las gráficas y una página donde se pueden ver las mediciones
recuperadas de la base de datos de MongoDB en formato JSON
[***]: Estas plantillas son las encargadas de renderizar las URL donde se cargan las gráficas de las mediciones de los
sensores. Ambos archivos usan el script moment.js para la configuración del eje temporal.
 Archivos

continuación:
package.json
a) app.js
configuración básica de algunos de ellos como mongodb, express, socket.io, handlebars,
y chart.js.
También posee 7 funciones de la forma getDataXXX(responseObject) que se encargan

de recuperar los datos de la base de datos de MongoDB y convertirlos en un
archivo .json. Es importante aclarar que XXX se reemplaza por el nombre del sensor en
cada función.
Además, se establecen las rutas que seguirá la aplicación para publicar los datos
recuperados desde la base de datos y el intervalo de actualización de la
página web usando Websockets.
6.Pruebas y resultados
6.1 Pruebas
6.2 Resultados
7.Conclusiones, recomendaciones y trabajo
futuro
7.1 Conclusiones
Las conclusiones constituyen un capítulo independiente y presentan, en forma lógica, los
resultados del trabajo. Las conclusiones deben ser la respuesta a los objetivos o
propósitos planteados. Se deben titular con la palabra conclusiones en el mismo formato
de los títulos de los capítulos anteriores (Títulos primer nivel), precedida por el numeral
correspondiente (según la presente plantilla).
Las conclusiones deben contemplar las perspectivas de la investigación, las cuales son
sugerencias, proyecciones o alternativas que se presentan para modificar, cambiar o
incidir sobre una situación específica o una problemática encontrada. Pueden
presentarse como un texto con características argumentativas, resultado de una reflexión
acerca del trabajo de investigación.
7.2 Recomendaciones y trabajo futuro

Se presentan como una serie de aspectos que se podrían realizar en un futuro para
emprender investigaciones similares o fortalecer la investigación realizada.
A. Anexo: Nombrar el anexo A de
acuerdo con su contenido
Los Anexos son documentos o elementos que complementan el cuerpo del trabajo y que
se relacionan, directa o indirectamente, con la investigación, tales como acetatos, cd,
normas, etc. Los anexos deben ir numerados con letras y usando el estilo “Título
anexos”.
B. Anexo: Nombrar el anexo B de
acuerdo con su contenido
A final del documento es opcional incluir índices o glosarios. Éstos son listas detalladas y
especializadas de los términos, nombres, autores, temas, etc., que aparecen en el
trabajo. Sirven para facilitar su localización en el texto. Los índices pueden ser
alfabéticos, cronológicos, numéricos, analíticos, entre otros. Luego de cada palabra,
término, etc., se pone coma y el número de la página donde aparece esta información.
Bibliografía
Akyildiz, I. F., Su, W., Sankarasubramaniam, Y., & Cayirci, E. (2002). Wireless sensor
networks: a survey. Computer Networks, 38(4), 393–422. https://doi.org/10.1016/S1389-
1286(01)00302-4
Alaya, M. Ben, Medjiah, S., Monteil, T., & Drira, K. (2015). Toward semantic
interoperability in oneM2M architecture. In IEEE Communications Magazine (Vol. 53, pp.
35–41). https://doi.org/10.1109/MCOM.2015.7355582
Asensio, Á., Marco, Á., Blasco, R., & Casas, R. (2014). Protocol and architecture to bring
things into internet of things. International Journal of Distributed Sensor Networks, 2014.
https://doi.org/10.1155/2014/158252
Atzori, L., Iera, A., & Morabito, G. (2010). The Internet of Things: A survey. Computer
Networks, 54(15), 2787–2805. https://doi.org/10.1016/j.comnet.2010.05.010
Bakillah, M., Liang, S., Zipf, A., & Arsanjani, J. (2013). Semantic Interoperability of Sensor
Data with Volunteered Geographic Information: A Unified Model. ISPRS International
Journal of Geo-Information, 2, 766–796. https://doi.org/10.3390/ijgi2030766
Balazinska, M., Deshpande, A., Franklin, M. J., Gibbons, P. B., Gray, J., Hansen, M., …
Tao, V. (2007). Data Management in the Worldwide Sensor Web. IEEE Pervasive
Computing, 6(2), 30–40. https://doi.org/10.1109/MPRV.2007.27
Barnaghi, P., Wang, W., Henson, C., & Taylor, K. (2012). Semantics for the Internet of
Things: early progress and back to the future. International Journal on Semantic Web and
Information Systems, 8(1), 1–21. https://doi.org/10.4018/jswis.2012010101
Bellavista, P., Cardone, G., Corradi, A., & Foschini, L. (2013). Convergence of MANET
and WSN in IoT urban scenarios. IEEE Sensors Journal, 13(10), 3558–3567.
https://doi.org/10.1109/JSEN.2013.2272099
Blanco, T., Casas, R., Manchado-Pérez, E., Asensio, Á., & López-Pérez, J. M. (2017).
From the islands of knowledge to a shared understanding: interdisciplinarity and
technology literacy for innovation in smart electronic product design. International Journal
of Technology and Design Education, 27(2), 329–362. https://doi.org/10.1007/s10798-
015-9347-7
Botts, M., Percivall, G., Reed, C., & Davidson, J. (2008). OGC® sensor web enablement:
Overview and high level architecture. GeoSensor Networks, (May 2008), 713–723.
Retrieved from http://www.springerlink.com/index/ux1224j76264g8j4.pdf
Bröring, A., Echterhoff, J., Jirka, S., Simonis, I., Everding, T., Stasch, C., … Lemmens, R.
(2011). New generation Sensor Web Enablement. Sensors (Basel, Switzerland) (Vol. 11).
https://doi.org/10.3390/s110302652
Bröring, A., & Jürrens, E. (2009). Development of sensor web applications with open
source software. First Open Source GIS UK Conference, (Simonis). Retrieved from
http://arnebroering.de/OSGIS_2009_FullPaper_broering_jirka_juerrens_stasch.pdf
Cardozo, A., Yamin, A., & Souza, R. (2016). An Architecture Proposal to Distributed
Sensing in Internet of Things.
Cardozo, A., Yamin, A., Xavier, L., Souza, R., Lopes, J., & Geyer, C. (2016). An
architecture proposal to distributed sensing in Internet of Things. In 2016 1st Symposium
on Instrumentation Systems, Circuits and Transducers, INSCIT 2016 - Proceedings (pp.
67–72). https://doi.org/10.1109/INSCIT.2016.7598208
Castillejo, P., Martinez, J.-F., Lopez, L., & Rubio, G. (2013). An Internet of Things
Approach for Managing Smart Services Provided by Wearable Devices. International
Journal of Distributed Sensor Networks, 2013. https://doi.org/10.1155/2013/190813
Cecílio, J., & Furtado, P. (2014). Wireless Sensors in Heterogeneous Networked
Systems. Wireless Sensors in Heterogeneous Networked Systems, 2, 39–59.
https://doi.org/10.1007/978-3-319-09280-5_4
Chu, X., & Buyya, R. (2007a). Service oriented sensor web. Sensor Networks and
Configuration. Retrieved from http://www.springerlink.com/index/up0443720u348x53.pdf
Chu, X., & Buyya, R. (2007b). Service oriented sensor web. Sensor Networks and
Configuration. Retrieved from http://www.springerlink.com/index/up0443720u348x53.pdf
Corcho, O., & García-Castro, R. (2010). Five challenges for the semantic sensor web.
Semantic Web, 1, 121–125. https://doi.org/10.3233/SW-2010-0005
Delin, K., & Jackson, S. (2001). The sensor web: a new instrument concept. Proceedings
of SPIE’s Symposium …, (January), 20–26. Retrieved from
http://sensorwaresystems.com/historical/resources/sensorweb-concept.pdf
Falocco, S., Larsson, J., & Nandi, S. (2017). A (likely) X-ray jet from NGC6217 observed
by XMM-Newton, 11(August), 1–11. https://doi.org/10.1093/mnras/stx2168
Bibliografía 57
Foerster, T., Nüst, D., Bröring, A., & Jirka, S. (2012). Discovering the sensor web through
mobile applications. Advances in Location-Based Services, Lecture Notes in
Geoinformation and Cartography. Retrieved from
http://www.springerlink.com/index/NH8327200WX75622.pdf
Gibbons, P. B., Karp, B., Nath, S., & Seshan, S. (2003). IrisNet: An architecture for a
worldwide sensor web. IEEE Pervasive Computing, 2(4), 22–33.
https://doi.org/10.1109/MPRV.2003.1251166
Gray, A. J. G., Sadler, J., Kit, O., Kyzirakos, K., Karpathiotakis, M., Calbimonte, J.-P., …
Gómez-Pérez, A. (2011). A semantic sensor web for environmental decision support
applications. Sensors (Basel, Switzerland), 11(9), 8855–87.
https://doi.org/10.3390/s110908855
Gubbi, J., Buyya, R., & Marusic, S. (2013). Internet of Things ( IoT ): A Vision ,
Architectural Elements , and Future Directions. Future Generation Computer Systems,
29(7), 1645–1660. https://doi.org/10.1016/j.future.2013.01.010
Guinard, D., Trifa, V., Karnouskos, S., Spiess, P., & Savio, D. (2010). Interacting with the
SOA-based internet of things: Discovery, query, selection, and on-demand provisioning of
web services. IEEE Transactions on Services Computing, 3(3), 223–235.
https://doi.org/10.1109/TSC.2010.3
Hancke, G. P., de Silva, B. de C., & Hancke, G. P. (2013). The role of advanced sensing
in smart cities. Sensors (Switzerland), 13(1), 393–425.
https://doi.org/10.3390/s130100393
Jabbar, W. A., Ismail, M., Nordin, R., & Arif, S. (2017). Power-efficient routing schemes for
MANETs: a survey and open issues. Wireless Networks (Vol. 23). Springer US.
https://doi.org/10.1007/s11276-016-1263-6
Jazayeri, M. A., Liang, S. H. L., & Huang, C. Y. (2015). Implementation and evaluation of
four interoperable open standards for the internet of things. Sensors (Switzerland), 15(9).
https://doi.org/10.3390/s150924343
Jirka, S., Bröring, A., & Stasch, C. (2009a). Applying OGC Sensor Web Enablement to
risk monitoring and disaster management. GSDI 11 World Conference Spatial Data
Infrastructure Convergence: Building SDI Bridges to Address Global Challenges.
Retrieved from http://ifgiweb.uni-muenster.de/~arneb/Paper - Applying OGC Sensor Web
Enablement to Risk Monitoring and Disaster Management.pdf
Jirka, S., Bröring, A., & Stasch, C. (2009b). Discovery mechanisms for the sensor web.
58 Título de la tesis o trabajo de investigación
Sensors (Basel, Switzerland), 9(4), 2661–81. https://doi.org/10.3390/s90402661

Jürrens, E., Bröring, A., & Jirka, S. (2009). A human sensor web for water availability
monitoring. Proceedings of OneSpace. Retrieved from
http://onespace.ace.ed.ac.uk/2009/docs/onespace2009_submission_2.pdf
Ko, J., Eriksson, J., Tsiftes, N., Dawson-Haggerty, S., Vasseur, J.-P. P., Durvy, M., …
Culler, D. (2011). Beyond Interoperability: Pushing the Performance of Sensornet IP
Stacks. Proceedings of the ACM Conference on Networked Embedded Sensor Systems,
ACM SenSys 2011, 1–11. https://doi.org/10.1145/2070942.2070944
Kodali, R. K., & Mahesh, K. S. (2016). A low cost implementation of MQTT using
ESP8266. 2016 2nd International Conference on Contemporary Computing and
Informatics (IC3I), 404–408.
Kodali, R. K., & Soratkal, S. (2016). MQTT based Home Automation System Using
ESP8266. 2016 IEEE Region 10 Humanitarian Technology Conference (R10-HTC).
Kortuem, G., Kawsar, F., Fitton, D., & Sundramoorthy, V. (2010). Smart objects as building
blocks for the Internet of things. Internet Computing, IEEE, 14(1), 44–51.
https://doi.org/10.1109/MIC.2009.143
Lazarescu, M. T. (2013). Design of a WSN platform for long-term environmental
monitoring for IoT applications. IEEE Journal on Emerging and Selected Topics in Circuits
and Systems, 3(1), 45–54. https://doi.org/10.1109/JETCAS.2013.2243032
Liang, S., Tao, V., & Croitoru, A. (2004). Sensor Web and GeoSWIFT-An Open Geospatial
Sensing Service. International Society for Photogrammetry and Remote Sensing XXth
Congress. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/summary?
doi=10.1.1.184.4291
Miorandi, D., Sicari, S., De Pellegrini, F., & Chlamtac, I. (2012). Internet of things: Vision,
applications and research challenges. Ad Hoc Networks, 10(7), 1497–1516.
https://doi.org/10.1016/j.adhoc.2012.02.016
Partynski, D., & Koo, S. G. M. (2013). Integration of Smart Sensor Networks into Internet
of Things: Challenges and Applications. 2013 IEEE International Conference on Green
Computing and Communications and IEEE Internet of Things and IEEE Cyber, Physical
and Social Computing, 1162–1167. https://doi.org/10.1109/GreenCom-iThings-
CPSCom.2013.202
Percivall, G., & Reed, C. (2006). OGC ® Sensor Web Enablement Standards. Sensors &
Transducers.
Percivall, G., Reed, C., & Davidson, J. (2007). Open Geospatial Consortium Inc . OGC
Bibliografía 59
White Paper OGC ® Sensor Web Enablement : Overview And High Level Architecture .
Open GIS ® White Paper. OGC 07-165, (December), 1–14.
Perera, C., Zaslavsky, A., Christen, P., & Georgakopoulos, D. (2014a). Context Aware
Computing for The Internet of Things. IEEE Communications Surveys & Tutorials, 16(1),
414–454. https://doi.org/10.1109/SURV.2013.042313.00197 T4 - A Survey M4 - Citavi
Perera, C., Zaslavsky, A., Christen, P., & Georgakopoulos, D. (2014b). Sensing as a
service model for smart cities supported by Internet of Things. European Transactions on
Telecommunications, 25(3), 294–307. https://doi.org/10.1002/ett
Perera, C., Zaslavsky, A., Liu, C. H., Compton, M., Christen, P., & Georgakopoulos, D.
(2014). Sensor search techniques for sensing as a service architecture for the internet of
things. IEEE Sensors Journal, 14(2), 406–420.
https://doi.org/10.1109/JSEN.2013.2282292
Razzaque, M. A., Milojevic-Jevric, M., Palade, A., & Cla, S. (2016). Middleware for
internet of things: A survey. IEEE Internet of Things Journal, 3(1), 70–95.
https://doi.org/10.1109/JIOT.2015.2498900
Rezvan, M., & Barekatain, M. (2015). The Sensors Are Innovative in Internet of Things.
Lecture Notes of the Institute for Computer Sciences, Social Informatics and
Telecommunications Engineering, 146, 191–196. https://doi.org/10.1007/978-3-319-
18802-7
Rose Jaren, Eldridge Scott, C. L. (2015). The internet of things: an overview -
Understanding the issues and challenges of a more connected world. The Internet
Society (ISOC), (October). https://doi.org/10.5480/1536-5026-34.1.63
Samara, K., & Hosseini, H. (2016). Aware Diffusion: A Semi-Holistic Routing Protocol for
Wireless Sensor Networks. Wireless Sensor Network, 8(3), 37–49.
https://doi.org/10.4236/wsn.2016.83004
Schade, S., Luraschi, G., De Longueville, B., Cox, S., & Díaz, L. (2010). Citizens as
sensors for crisis events: Sensor Web Enablement for volunteered Geographic
Information. In WebMGS.
Sheth, A., Henson, C., & Sahoo, S. S. (2008a). Semantic Sensor Web. IEEE Internet
Computing, 12(4), 78–83. https://doi.org/10.1109/MIC.2008.87
Sheth, A., Henson, C., & Sahoo, S. S. (2008b). Semantic Sensor Web. IEEE Internet
Computing, 12(4), 78–83. https://doi.org/10.1109/MIC.2008.87
Sicari, S., Rizzardi, A., Miorandi, D., Cappiello, C., & Coen-Porisini, A. (2016). A secure
60 Título de la tesis o trabajo de investigación
and quality-aware prototypical architecture for the Internet of Things. Information

Systems, 58. https://doi.org/10.1016/j.is.2016.02.003
Sim, N. A. V. (2016). A Low Cost Automated Data Acquisition System for Urban Sites
Temperature and Humidity Monitoring Based in Internet of Things. In 2016 1st
International Symposium on Instrumentation Systems, Circuits and Transducers (INSCIT).
Sivarajah, U., Kamal, M. M., Irani, Z., & Weerakkody, V. (2017). Critical analysis of Big
Data challenges and analytical methods. Journal of Business Research, 70, 263–286.
https://doi.org/10.1016/j.jbusres.2016.08.001
Špeh, I., & Heđ, I. (2016). A Web - Based IoT Solution for Monitoring Data Using MQTT
Protocol. 2016 International Conference on Smart Systems and Technologies (SST),
249–253. https://doi.org/10.1109/SST.2016.7765668
Tantitharanukul, N., Osathanunkul, K., Hantrakul, K., Pramokchon, P., & Khoenkaw, P.
(2017a). MQTT-Topic naming criteria of open data for smart cities. 20th International
Computer Science and Engineering Conference: Smart Ubiquitos Computing and
Knowledge, ICSEC 2016, 1–6. https://doi.org/10.1109/ICSEC.2016.7859892
Tantitharanukul, N., Osathanunkul, K., Hantrakul, K., Pramokchon, P., & Khoenkaw, P.
(2017b). MQTT-Topics Management System for Sharing of Open Data. 2017 International
Conference on Digital Arts, Media and Technology (ICDAMT), 1–4.
Trilles, S., Luján, A., Belmonte, Ó., Montoliu, R., Torres-Sospedra, J., & Huerta, J. (2015).
SEnviro: A sensorized platform proposal using open hardware and open standards.
Sensors (Switzerland), 15(3), 5555–5582. https://doi.org/10.3390/s150305555
Wang, F., Hu, L., Zhou, J., Hu, J., & Zhao, K. (2015). A semantics-based approach to
multi-source heterogeneous information fusion in the internet of things. Soft Computing,
21(8), 2005–2013. https://doi.org/10.1007/s00500-015-1899-7
Yinbiao, S., Lee, K., Lanctot, P., Juanbin, F., Hao, H., Chow, B., … Qui, W. (2014).
Internet of Things: Wireless Sensor Networks. Internation Electronic Commision,
(December), 1–78.
Zhu, T., Dhelim, S., Zhou, Z., Yang, S., & Ning, H. (2016). An architecture for aggregating
information from distributed data nodes for industrial internet of things. Computers &
Electrical Engineering, 0, 1–13. https://doi.org/10.1016/j.compeleceng.2016.08.018

Mendeley 20171002050541

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Mendeley 20171002050541

Încărcat de

Drepturi de autor:

Formate disponibile

Gestionando datos heterogéneos

provenientes de sensores para medir

Alexei Gabriel Ochoa Duarte

Universidad Nacional de Colombia

Gestionando datos heterogéneos

Alexei Gabriel Ochoa Duarte

Tesis presentada como requisito parcial para optar al título de:

Universidad Nacional de Colombia

“No es necesario conquistar el mundo, basta

Subcomandante Insurgente Marcos

A mi manera de ver, la idea de universidad, es una utopía, es algo similar a la idea de

Como planteó el Che Guevara, la Universidad se debe pintar de negro, de mulato, no

La Universidad debe aprovechar que el país busca construir la paz, fomentando la

La heterogeneidad propia de los datos capturados y los instrumentos de medición

Con el propósito de subsanar esas dificultades, se plantea una arquitectura basada en

Palabras clave: Internet de las Cosas, Sensores, Interoperabilidad, Heterogeneidad,

In order to overcome these difficulties, an architecture based on networks of sensors and

Keywords: Internet of Things (IoT), Sensors, Interoperability, Heterogeneity, Open

Lista de figuras XIII

Lista de tablas XIV

Lista de Símbolos y abreviaturas XV

1. Planteamiento del problema 3

6. Conclusiones, recomendaciones y trabajo futuro 49

A. Anexo: Nombrar el anexo A de acuerdo con su contenido 51

B. Anexo: Nombrar el anexo B de acuerdo con su contenido 53

Figura 1: Estructura básica de una red de sensores....................................................7

Tabla 1: Trabajos que usan la Sensor Web Enablement para la interoperabilidad......13

Lista de Símbolos y abreviaturas

Símbolos con letras latinas

Ag Área transversal de la fase gaseosa m2 Ec. 3.2

Símbolos con letras griegas

 Wandhafreibwinkel (Stahlblech) 1 Sección 3.2

Η mittlere Bettneigunswinkel (Stürzen) 1 Figura 3-1

Los procesos de integración e interoperabilidad de la información generada por esta

Adicionalmente, se identifica la necesidad de desarrollar arquitecturas y sistemas, que

En este documento se presenta el desarrollo de un prototipo escalable de sistema de

La estructura del presente documento, contempla un marco teórico que da sustento al

En la intro, el autor presenta y señala la importancia, el origen (los antecedentes

En el contexto de este trabajo, con el objetivo de solventar el problema de la

1.1 Preguntas de investigación

1.2.1 Objetivo general

1.2.2 Objetivos específicos

 Profundizar en el conocimiento de herramientas computacionales que permitan la

 Precisar las capacidades mínimas de los sensores seleccionados como fuentes

 Recolectar datos procedentes de diversas fuentes sobre la calidad del aire en

 Diseñar e implementar una aplicación, utilizando estándares de OGC y W3C, que

 Dar a conocer y socializar los resultados parciales y finales de la investigación.

1.3 Alcance y limitaciones

Los sensores y dispositivos con los cuales se desarrolla el prototipo se basan en la

Las mediciones realizadas por el prototipo se hacen en un ambiente cerrado, donde se

2.1 Sensores, redes de sensores, Internet de las

En la actualidad, se utilizan sistemas de medición, instrumentados con múltiples

Figura 1: Estructura básica de una red de sensores

Fuente: (Yinbiao et al., 2014)

Los avances tecnológicos han hecho posible el despliegue masivo de pequeños

Las mediciones provenientes de los sensores y redes de sensores de naturaleza

Figura 2: Pirámide del conocimiento en el contexto de IoT

Fuente: (Barnaghi, Wang, Henson, & Taylor, 2012)

Debido a la heterogeneidad existente en los sensores, que se puede apreciar en la

Figura 3: Estructura básica de la Sensor Web

Fuente: Adaptada de (Botts, Percivall, Reed, & Davidson, 2008)

Junto a estas definiciones, merece especial atención el desarrollo de una infraestructura

Los estándares propios de la SWE no proporcionan instalaciones para la extracción,