Middleware Framework IoT para elDesarrollo de Aplicaciones deSistemas de Control en Red
Leonardo Enrique Castellanos Acuna
Trabajo de grado presentado como requisito parcial para optar al tıtulo de:
Magıster en Ingenierıa - Enfasis Sistemas y Computacion
Director:
Ph.D. Jose Luis Villa Ramirez
Lınea de Investigacion:
Internet de las Cosas
Universidad Tecnologica de Bolıvar
Facultad de Ingenierıa
Cartagena, Colombia
2018
Agradecimientos
Agradezco principalmente a Dios por permitirme culminar con exito esta etapa de mi vida.
Ademas quiero expresar mi gratitud con las siguientes personas:
A mi familia, especialmente a mi madre por la excelente educacion, sobre todo en valores que
me ha brindado, por su apoyo incondicional y por estar siempre a mi lado en los momentos
mas importantes.
Al profesor Jose Luis, Ph. D., director de este trabajo, educador y amigo. Muchısimas gracias
por su valioso esfuerzo y dedicacion permanente en la realizacion de este trabajo de grado.
Finalmente, a todos los amigos, profesores, que fueron parte de este enriquecedor y grandioso
proceso.
v
Resumen
Internet de las Cosas (IoT, por sus siglas en ingles) ofrece a los usuarios interconectar ob-
jetos fısicos heterogeneos creando una malla de dispositivos produciendo informacion que
posibilita la creacion de un gran numero de aplicaciones y servicios.
El desarrollo de IoT en los ultimos anos se ha acelerado y las investigaciones de los Sistemas
de Control en Red (Networked Control System, NCS) juegan un rol clave en esta area. En
general para el control de IoT la captura y procesamiento de los datos son muy importantes.
Por consiguiente, si las aplicaciones IoT manejan una estructura de control se hace necesario
un buen tratamiento de los datos; donde su buen desarrollo tendra un gran impacto en la
calidad de servicio y escalabilidad de las soluciones.
Este proyecto plantea un framework que permitirıa lograr implementaciones especıficas de
middleware mitigando la ineficiencia en la gestion de los recursos (Hardware y software),
agilizar el despliegue de las aplicaciones y aumentar la escalabilidad de las soluciones.
Palabras clave: Internet de las Cosas, Sistemas de Control en Red, IIoT, Middleware,
Framework, Arquitectura de Referencia, Interoperabilidad, Escalabilidad.
Abstract
Internet of Things (IoT) allows to users interconnect heterogeneous physical objects which
create a mesh of devices producing information to develop a large number of applications
and services.
IoT development has grown up last years, and the Networked Controls Systems’ researches
play a key role in this area. Generally, information processing is important for IoT con-
trol. Therefore, if IoT applications handle a control structure then is necessary a good data
treatment, where the development will have a huge impact on service quality and solutions’
scalability.
This work aims to develop a framework which allows create specific implementations of
Middleware to mitigate the gap on resource management (Hardware and software), to speed
up the applications deployment and to increase solutions scalability.
Keywords: Internet of things, Networked Control System, Middleware, Framework,
Reference architecture, Interoperability, Scalability.
Contenido
Agradecimientos III
Resumen V
Lista de figuras 1
1 Descripcion del Proyecto 2
1.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Contexto y Descripcion del Problema . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Aportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Hipotesis de Investigacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Pregunta de Investigacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6.2 Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.7 Metodologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.8 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Internet de las Cosas Industrial: Marco Teorico y Estado del Arte 7
2.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Internet de las Cosas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Internet de las Cosas Industrial . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 RAMI 4.0 (Reference Architecture Model Industrie 4.0) . . . . . . . . 10
2.3.2 IIRA (Industrial Internet Reference Architecture) . . . . . . . . . . . 11
2.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Middlewares y Frameworks IoT: Marco Teorico y Estado del Arte 17
3.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Middlewares IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1 Recopilacion de requerimientos . . . . . . . . . . . . . . . . . . . . . 18
3.3 Frameworks IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1 Recopilacion de requerimientos . . . . . . . . . . . . . . . . . . . . . 20
3.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Contenido vii
4 Middleware Framework IoT Propuesto 23
4.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Diseno de los Modulos del Sistema . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 Nivel de Borde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.2 Nivel de plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3 Nivel Empresarial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Seleccion de la herramienta software . . . . . . . . . . . . . . . . . . . . . . . 25
4.4 Implementacion de los Modulos del Sistema . . . . . . . . . . . . . . . . . . 26
4.4.1 Modulo de Persitencia . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.2 API REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4.3 API MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Evaluacion y Validacion del Middleware Framework 34
5.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2 Diseno e implementacion de la aplicacion IoT . . . . . . . . . . . . . . . . . 34
5.3 Evaluacion de la Solucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6 Conclusiones y Trabajos Futuros 43
6.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2 Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Bibliografıa 46
Lista de Figuras
2-1. RAMI 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2-2. Puntos de Vista IIRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2-3. Dominios Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2-4. Patron arquitectural de 3 niveles. . . . . . . . . . . . . . . . . . . . . . . . . 14
2-5. Patron arquitectural de administracion y conectividad de borde mediada por
gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2-6. Patron arquitectural de DATABUS en capas. . . . . . . . . . . . . . . . . . . 15
4-1. Arquitectura de MIOT Framework. . . . . . . . . . . . . . . . . . . . . . . . 24
4-2. Diagarama entidad relacion del sistema. . . . . . . . . . . . . . . . . . . . . 27
5-1. Aplicacion IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5-2. Aplicacion IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5-3. Aplicacion IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5-4. Evaluacion Caracterıstica Funcionalidad . . . . . . . . . . . . . . . . . . . . 39
5-5. Evaluacion Caracterıstica Fiabilidad . . . . . . . . . . . . . . . . . . . . . . 40
5-6. Evaluacion Caracterıstica Usabilidad . . . . . . . . . . . . . . . . . . . . . . 40
5-7. Evaluacion Caracterıstica Mantenibilidad . . . . . . . . . . . . . . . . . . . . 41
5-8. Evaluacion Caracterıstica Portabilidad . . . . . . . . . . . . . . . . . . . . . 42
5-9. Resultado Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1 Descripcion del Proyecto
1.1. Introduccion
Internet de las Cosas (IoT, por sus siglas en ingles) ofrece a los usuarios interconectar ob-
jetos fısicos heterogeneos creando una malla de dispositivos produciendo informacion que
posibilita la creacion de un gran numero de aplicaciones y servicios.
En la actualidad, la industria es uno de los ambitos de aplicacion que busca adoptar la tec-
nologıa de IoT. Alta interoperabilidad, tiempo real o sistemas de control inalambricos, son
algunos de los multiples beneficios que puede otorgar IoT a este sector.
1.2. Contexto y Descripcion del Problema
Internet de las Cosas (IoT) es considerada la nueva era de la comunicacion despues del
computador, internet y las redes de comunicaciones moviles. IoT es un paradigma de comu-
nicacion que visualiza que, en un futuro cercano, los objetos de la vida diaria esten equipados
con microcontroladores, transceptores digitales y por un conjunto de protocolos que les per-
mitira comunicarse entre sı y con los usuarios, convirtiendose en parte integral de Internet.
IoT ofrece numerosas oportunidades y potenciales casos de uso en diferentes campos como
agricultura, industria, salud, educacion, entre otros. Sin embargo, requiere de un manejo
desafiante de los diversos componentes heterogeneos que componen una aplicacion IoT para
lograr una integracion perfecta con el mundo fısico y el virtual. Ademas, disenar una capa
de comunicacion que cumpla con los requerimientos de bajo acoplamiento, robustez, versa-
tilidad, flexibilidad y seguridad al mismo se convierte en una tarea difıcil.
Por otra parte en la ultima decada la tecnologıa de redes ha sido ampliamente desarrollada.
Recientemente la tecnologıa en red ha jugado un papel clave en el desarrollo de los sistemas
de control. El tipo de sistema de control en el que un lazo de control es cerrado a traves de un
canal de comunicacion se conoce como Sistema de Control en Red (Networked Control Sys-
tem, NCS). Existen dos tipos de configuraciones generales para un NCS: Estructura directa
y estructura jerarquica. El NCS en estructura directa se compone por un controlador y un
1.3 Aportes 3
sistema remoto que contiene una planta fısica, sensores y actuadores; mientras que un NCS
con estructura jerarquica consiste en un controlador principal y un sistema de lazo cerrado
remoto. El uso de una estructura u otra esta basada en los requerimientos de la aplicacion
y las preferencias del disenador.
El desarrollo de IoT en los ultimos anos se ha acelerado y las investigaciones de los NCS jue-
gan un rol clave en esta area. En general para el control de IoT la captura y procesamiento
de los datos son muy importantes. Tal como se menciono anteriormente, con el desarro-
llo de IoT se espera que una gran cantidad de dispositivos esten conectados entre sı, por
consiguiente la cantidad de datos a capturar y procesar crecera enormemente. Los sistemas
de control deben manejar toda esa gran cantidad de datos provenientes de los dispositivos.
En este caso, los requerimientos de gran calidad y tiempo real no podran ser garantizados
con las soluciones de control en red tradicionales, debido a que la gran cantidad de datos
y dispositivos en el sistema de control aumenta la complejidad al momento de administrar
y desplegar soluciones al desarrollador de aplicaciones, lo que a su vez tambien genera una
baja interoperabilidad, escalabilidad y flexibilidad.
En este orden de ideas, en el marco de IoT es evidente que existe un problema de administra-
cion de dispositivos y aplicaciones heterogeneas. Especıficamente cuando estas aplicaciones
manejan una estructura de control se hace necesario una buen tratamiento de los datos;
donde su buen desarrollo tendra un gran impacto en la calidad de servicio y escalabilidad de
las soluciones. Este proyecto plantea un framework que permitirıa lograr implementaciones
especıficas de middleware mitigando la ineficiencia en la gestion de los recursos (Hardware
y software), agilizar el despliegue de las aplicaciones y aumentar la escalabilidad de las so-
luciones.
De acuerdo con lo anterior, por medio de este trabajo, se ha propuesto disenar e implementar
un middleware framework que posibilite crear un entorno interoperable para la construccion
de aplicaciones IoT de control en red.
1.3. Aportes
IoT es un paradigma que se ideo en los anos noventa, sin embargo, solo en los utimos anos se
ve un aumento en el numero de investigaciones en este campo. Especificamente, los estudios
de IoT en el area de control en red no son numerosos. Por lo que se puede afirmar que este
trabajo constituye un acercamiento importante en el tema.
Este trabajo busca crear una herramienta que permita al desarrollador generar un entorno
interoperable y escalable para aplicaciones de control jerarquico. Ası mismo, se presenta una
aplicacion IoT estandarizada que permite validar la aplicabilidad de la herramienta y puede
4 1 Descripcion del Proyecto
ser usada como guıa para futuros desarrollos.
1.4. Hipotesis de Investigacion
A traves del diseno e implementacion de un middleware framework es posible facilitar la
construccion y la gestion de aplicaciones IoT bajo una estructura de control en el marco de
Internet de las Cosas, debido a que se proporciona un ambiente interoperable y escalable.
1.5. Pregunta de Investigacion
En las secciones anteriores se describe el problema de investigacion, por lo que se procede a
formular la siguiente pregunta de investigacion:
1. ¿Como se pueden mejorar las herramientas de software que permiten la construccion de
un ambiente interoperable y escalable, para la construccion y gestion de aplicaciones de
control en el marco de Internet de las Cosas?
Esta pregunta engloba el problema que pretende resolver este trabajo.
1.6. Objetivos
1.6.1. General
Disenar e implementar un middleware framework IoT para la administracion e integracion
de dispositivos y aplicaciones de control, que provea gestion de la informacion, escalabilidad
y un facil despliegue.
1.6.2. Especıficos
1. Disenar la estructura del middleware framework bajo una arquitectura de software que
permita cumplir con los requerimientos del mismo.
2. Seleccionar la herramienta software con la que sera implementado el middleware frame-
work, teniendo en cuenta facilidades de uso, acceso y estandarizacion.
3. Disenar e implementar los modulos que constituyen la arquitectura del sistema e imple-
mentarlos como una plataforma orientada a soportar protocolos de comunicacion para
IoT.
4. Desarrollar una aplicacion de control basada en dispositivos y tecnologıas de IoT.
1.7 Metodologıa 5
5. Evaluar el middleware framework propuesto, basado en una metodologıa de evaluacion
de arquitecturas de software con el fin de validar su utilidad.
1.7. Metodologıa
La presente investigacion estara guiada por un horizonte metodologico que consta de las
siguientes fases:
Fase 1: Caracterizacion de Middlewares en IoT.
El objetivo de esta fase basicamente es cotejar las caracterısticas de los Middlewares en
IoT, tales como la arquitectura, requerimientos de servicio, requerimientos arquitectonicos,
flexibilidad en el despliegue, interoperabilidad, etc. Se pretende realizar una revision de los
estandares y diversos tipos de requerimientos basados en soluciones existentes; lo anterior se
hace con el fin de fijar las bases del diseno y desarrollo de la solucion propuesta.
Fase 2: Caracterizacion de Frameworks en IoT.
En este apartado se busca recopilar las caracterısticas de los Frameworks en IoT, tales como
paradigma de programacion, robustez, escalabilidad, abstraccion de la programacion, etc.
Por medio de la identificacion y analisis de dichas caracterısticas se busca determinar el
diseno del framework que permita agilizar el desarrollo y despliegue de middlewares para
aplicaciones de control para IoT.
Fase 3: Seleccion del software para el desarrollo de la plataforma.
El objetivo de esta fase es la seleccion del software, tecnologıas, plataforma o lenguaje de
programacion que permita la creacion y el soporte de la solucion que se propone. Se escogera
el que permita un buen soporte de los protocolos de comunicacion para IoT y que propor-
cione flexibilidad en el desarrollo del middleware framework.
Fase 4: Estructura de los modulos del sistema.
En este apartado se busca disenar la estructura base de los modulos que conforman la arqui-
tectura de la solucion, caracterizando los componentes de los mismos. Esta estructura busca
definir el modelo de comunicacion de los servicios, y se basa en la caracterizacion hecha en
las dos primeras fases y el software seleccionado en la fase anterior. Se pretende que el diseno
que se implemente utilizado proporcione un mejor entorno para la integracion de dispositivos
y aplicaciones IoT.
Fase 5: Desarrollo de los modulos del sistema .
Aquı se trabajara todo lo referente a la elaboracion de los modulos del Sistema. Se tendra
en cuenta que la implementacion (composicion y funcionamiento) de los modulos deba ir
6 1 Descripcion del Proyecto
acorde a la estructura manejada en la fase anterior y deba perfilarse como un middleware
framework basado en IoT. Esta fase comprende las siguientes actividades:
Desarrollar los servicios que soporten la conexion bajo los protocolos de comunicacion para
IoT.
Desarrollo del mecanismo de conexion entre los modulos que forman el middleware.
Desarrollo del mecanismo de administracion y gestion de dispositivos y aplicaciones.
Fase 6: Evaluacion de la solucion.
En este aparte se realizaran las siguientes actividades:
Identificar el dominio de la aplicacion del estudio de caso.
Implementar y desplegar una aplicacion IoT que trabaje bajo una estructura de control
jerarquica.
Seleccionar una metodologıa de evaluacion de arquitecturas de software.
Realizar la evaluacion con la metodologıa seleccionada.
Analizar los resultados y emitir reportes.
Fase 7: Documentacion
Elaboracion de manual de usuario y el documento de trabajo de grado.
1.8. Conclusiones
Es innegable el potencial de Internet de las Cosas, debido a que permite crear aplicaciones
de la vida diaria de manera efectiva y a un bajo costo. La industria busca aprovechar al
maximo sus potencialidades y para ello se han realizado esfuerzos en la estandarizacion de
sus usos. Otro de los desafıos que presenta Intenet de las Cosas es la baja interoperabilidad
y escalabilidad que se presenta a la hora de usar sus tecnologıas. Este trabajo esta enfo-
cado en reducir esa brecha, disenando e implementando una herramienta de software para
ello. El resto del documento esta organizado ası: en el Capıtulo 2 se define el concepto de
Internet de las Cosas y se profundiza en su uso en el campo industrial; en el Capıtulo 3 se
realiza una caracterizacion de los Middlewares y Frameworks IoT, con el fın de recopilar los
requerimientos de estos; en el Capıtulo 4 se presenta el diseno de los modulos del sistema,
cuya implementacion se describira en el Capıtulo 5; por ultimo en el Capıtulo 6 aparecen los
resultados de la evaluacion de la solucion.
2 Internet de las Cosas Industrial: Marco
Teorico y Estado del Arte
2.1. Introduccion
Internet de las cosas es un paradigma de la computacion que busca crear redes inteligentes
basadas en microcontroladores y microprocesadores, con el fin de crear aplicaciones que
mejoren la calidad de vida de las personas. En este capıtulo se define el concepto de Internet
de las Cosas y se profundiza en su uso en el campo industrial. Ademas se describen dos
arquitecturas de referencia para la implementacion de sistemas y aplicaciones en el marco
de Intenet de las cosas.
2.2. Internet de las Cosas
El termino Internet de las Cosas fue popularizado por el trabajo realizado en 1999, por el
Centro Auto-ID del MIT (Massachusetts Institute of Technology), en el que se empezo a
disenar una infraestructura basada en RFID [Mattern and Floerkemeier, 2010]. Sin embar-
go, solo en los ultimos anos el uso de Internet de las Cosas se ha propagado en diferentes
contextos.
IoT ofrece a los usuarios interconectar objetos fısicos heterogeneos creando una malla de
dispositivos produciendo informacion que posibilita la creacion de un gran numero de apli-
caciones y servicios. Esta es la idea principal detras del concepto de IoT, tener una red
mundial de objetos interconectados que pueden ser accedidos remotamente a traves de una
direccion global que posibilita compartir recursos entre ellos.
Desde el punto de vista tecnico IoT es un paradigma que necesita la integracion de varias
tecnologıas para ser una realidad: M2M, computacion en la nube, Big data, protocolos de
comunicacion y red de sensores inalambricos. Al integrar estas tecnologıas presentan algunas
caracterısticas y requerimientos [Zhou et al., 2013]:
1. Administracion y manejo de la informacion: Las cosas (dispositivos) generan una gran
cantidad de datos que necesitan ser almacenados y administrados.
8 2 Internet de las Cosas Industrial: Marco Teorico y Estado del Arte
2. Interfaces basadas en la web: Las cosas (dispositivos) requieren de esto para intercambiar
datos e integrar distintas aplicaciones.
3. Interoperabilidad: Los dispositivos son heterogeneos sin embargo deben tener la capacidad
de comunicarse entre sı.
4. Tiempo real: las aplicaciones basadas en IoT pueden se clasificadas de tiempo real y de
no tiempo real.
5. Aplicaciones diversas: IoT puede ofrecer sus servicios a una gran cantidad de aplicaciones
en numerosos dominios y ambientes.
6. Red dinamica: IoT integrara muchos dispositivos heterogeneos. Los dispositivos pueden
ser conectados o desconectados en cualquier momento.
7. Todo como servicio (Everything-as-a-service, XaaS): entre mas dispositivos esten conecta-
dos, el numero de aplicaciones creceran tambien. Estos servicios estaran disponibles para
ser usados y reusados.
8. Seguridad: IoT necesita accesibilidad y conectividad global, lo cual significa que cualquiera
puede accederlo en cualquier momento y en cualquier lugar. Esto incrementa tremenda-
mente el rango de ataques para las aplicaciones y redes IoT.
9. Privacidad: Cualquier aplicacion IoT que no cumpla con los requerimientos de privacidad
puede ser prohibida por la ley debido a que viola la privacidad de los ciudadanos.
Las tecnologıas de comunicacion para IoT permiten conectar dispositivos heterogeneos y
crear servicios especıficos. La herramienta que permite dicha comunicacion se le conoce
como protocolo. En IoT se han implementado varios protocolos de acuerdo a los diferentes
estandares.[Al-Fuqaha et al., 2015] presenta un listado de los mas relevantes:
HyperText Transfer Protocol (HTTP): Es el protocolo de transferencia de informacion
mas usado en Internet. Entre las arquitecturas de desarrollo basadas en este protocolo
se encuentra REST (REpresentational State Transfer). REST permite intercambiar datos
entre clientes y servidores sobre HTTP de una forma sencilla. REST permite implementar
una arquitectura sin estado, es decir que una accion sobre un recurso no depende de
ninguna otra accion. REST es ampliamente usado en aplicaciones web y moviles. Permite
a los clientes y servidores exponer y consumir servicios web tal como SOAP (Simple
Object Access Protocol) pero en una forma mas sencilla usando URIs (Uniform Resource
Identifiers) como sustantivo y los metodos HTTP get, post, put y delete como verbos. Y
por ultimo, REST no requiere XML para intercambiar mensajes; generalmente hace uso
del formato JSON.
2.2 Internet de las Cosas 9
Constrained Application Protocol (CoAP): CoAP define un protocolo de transferencia web
basado en REST para implementar funcionalidades de HTTP. Sin embargo, a diferencia
de REST, CoAP esta atado a UDP (no a TCP) por defecto lo cual lo hace mas modifica-
ble para las aplicaciones IoT. Adicionalmente, CoAP modifica algunas funcionalidades de
HTTP para conocer los requerimientos IoT tales como bajo consumo de energıa y opera-
ciones en presencia de enlaces ruidosos. CoAP tiene como objetivo permitir que pequenos
dispositivos de bajo consumo y bajas capacidades de computacion y comunicacion utilicen
interacciones RESTful.
Message Queue Telemetry Transport (MQTT): MQTT es un protocolo de mensaje que fue
introducido por Andy Stanford-Clark de IBM y Arlen Nipper de Arcom (ahora EURO-
TECH) en 1999. MQTT tiene como objetivo conectar dispositivos embebidos y redes con
aplicaciones y middleware. La operacion de conexion usa un mecanismo de enrutamiento
(uno a uno, uno a muchos, muchos a muchos) y permite que MQTT sea un protocolo
de conexion optimo para IoT. MQTT consiste en tres componentes basicos: Suscriptor,
publicador y broker. Un dispositivo se registra como suscriptor para topicos especıficos
en orden de ser informado por el broker cuando los publicadores publican el topico de
interes. El publicador actua como el generador del dato de interes. Luego, el publicador
transmite la informacion a las entidades interesadas (suscriptores) a traves del broker.
Adicionalmente, el broker posibilita la seguridad con el chequeo de la autorizacion de los
publicadores y suscriptores.
Extensible Messaging and Presence Protocol (XMPP): Es un estandar de mensajeo ins-
tantaneo de IETF que es usado para chats multiples, llamadas de voz y video, y tele-
presencia. XMPP fue desarrollado por la comunidad Open Source Jabber para soportar
un protocolo de mensajes abierto, seguro, libre de spam y descentralizado. XMPP permi-
te a los usuarios comunicarse entre sı, enviando mensajes instantaneos sin importar que
sistema operativo usen.
Advance Message Queuing Protocol (AMQP): Es un protocolo de la capa de aplicacion
para Internet de las Cosas enfocado en un ambiente orientado a mensajes. Las comunica-
ciones son manejadas por dos componentes principales: Intercambios y colas de mensajes.
Los intercambios son usados para realizar el enrutamiento de los mensajes a las colas
apropiadas. El enrutamiento entre intercambios y las colas de mensajes se basan en al-
gunas reglas y condiciones predefinidas. Los mensajes pueden ser almacenados en colas
de mensajes y entonces ser enviados a los receptores. Mas alla de esto AMQP tambien
soporta el modelo de comunicacion publicar/suscribir.
Las potencialidades ofrecidas por IoT permiten el desarrollo de un gran numero de aplica-
ciones.Estas aplicaciones pretenden mejorar la calidad de vida de las personas y son des-
plegadas en diferentes entornos: Salud, Agricultura, Transporte, Industria, entre otros. En
10 2 Internet de las Cosas Industrial: Marco Teorico y Estado del Arte
el caso particular de la Industria, surge un nuevo concepto conocido como Internet de las
Cosas Industrial, el cual muchos catalogan como la cuarta revolucion industrial.
2.3. Internet de las Cosas Industrial
El Internet de las Cosas Industrial (IIoT, por sus siglas en ingles) hace referencia a la apli-
cacion de Internet de las Cosas a traves de diferentes industrias tales como manufactura,
logıstica, transporte, energıa, entre otros. Los sensores y actuadores se estan convirtiendo
cada vez mas poderosos, menos costosos y mas pequenos, lo que posibilita su uso en tareas
de control, automatizacion, monitoreo y mantenimiento [Sadiku et al., 2017].
Las aplicaciones IoT se han basado en implementaciones de software fragmentadas para ca-
sos de usos y sistemas especıficos. Por tal motivo recientemente han surgido iniciativas para
crear arquitecturas de referencias con el objetivo de crear estandares a la hora de elaborar
soluciones basadas en Internet de las Cosas, especialmente en el contexto industrial.
Existen 2 arquitecturas de referencias destacadas: IIRA (Industrial Internet Reference Archi-
tecture) [IIC, 2017] RAMI 4.0 (Reference Architecture Model Industrie 4.0) [Hankel and Rexroth, 2015].
Estas arquitecturas de referencia estan basadas en aspectos funcionales de IoT aplicados a
la Industria.
2.3.1. RAMI 4.0 (Reference Architecture Model Industrie 4.0)
RAMI 4.0 es una arquitectura de referencia que consiste en un sistema de coordenadas tri-
dimensional que describe todos los aspectos cruciales de la Industria 4.0 (Ver Figura 2-1).
El eje de los “niveles de jerarquıa” describe a IEC 62264, las series de estandares inter-
nacionales para industrias de tecnologıa de informacion y sistemas de control. Este nivel
representa la ubicacion de las funciones y responsabilidades dentro de las fabricas o plantas.
RAMI 4.0 expande el estandar IEC62264 agregando el “Producto” y el “Mundo conectado”.
El eje “ciclo de vida y flujo de valor” esta relacionado con los productos. Este eje se basa en
el estandar IEC 62890 para el manejo de ciclo de vida, en donde ademas hace una distin-
cion entre “tipos” e “instancias” (Un tipo se convierte en una instancia cuando el diseno y
prototipo ha sido completado, y el producto ha sido elaborado).
El eje de “capas” representa la descomposicion de una maquina en sus propiedades estructu-
rada capa por capas, por ejemplo el mapeo virtual de una maquina) [Hankel and Rexroth, 2015].
Esto corresponde al enfoque de la tecnologıa de la informacion de agrupar proyectos com-
plejos en sub-unidades manejables.
2.3 Internet de las Cosas Industrial 11
Figura 2-1: RAMI 4.0
2.3.2. IIRA (Industrial Internet Reference Architecture)
IIRA ha sido desarrollada por el consorcio de Internet Industrial (Fundado por AT&T, Cis-
co, General Electric, IBM e Intel) y esta basada en el estandar ISO/IEC/IEEE 42010:2011.
IIRA presenta IIFA (Industrial Internet Framework Architecture), un framework que define
la arquitectura de un sistema en el marco de Internet Industrial.
IIRA identifica las preocupaciones arquitecturales comunmente encontradas en los sistemas
en el marco de IIoT y las clasifica en puntos de vista (Viewpoints) junto con sus interesados
(Stakeholders).IIRA define 4 puntos de vista (Ver Figura 2-2): Negocio, Uso, Funcional e
Implementacion.
El punto de vista de negocio atiende las preocupaciones de los interesados respecto a la vision
de negocio, retorno de inversion esperado, costo del mantenimiento a la hora de establecer
un sistema en el marco de IIoT, en su contexto.
El punto de vista de uso maneja las preocupaciones del uso esperado del sistema. Este pun-
to de vista describe las actividades que coordinan varias unidades de trabajo sobre varios
componentes del sistema.
El punto de vista funcional descompone un tıpico sistema en el marco de IIoT en un conjunto
de dominios funcionales (ver Figura 2-4), describiendo sus requerimientos y caracterısticas.
12 2 Internet de las Cosas Industrial: Marco Teorico y Estado del Arte
Figura 2-2: Puntos de Vista IIRA
A continuacion se definen los cinco dominios funcionales:
1. Dominio de control: Este dominio representa el conjunto de funciones que son desarrolla-
das para sistemas de control industrial tales como realizar lecturas de datos con sensores
y acciones de control con actuadores.
2. Dominio de operacion: El dominio de operacion tiene como objetivo monitorear y opti-
mizar tareas en el sistema.
3. Dominio de informacion: Este dominio esta relacionado con el manejo y almacenamiento
de los datos recolectados por los diferentes dominios.
4. Dominio de aplicacion: El dominio de aplicacion permite la interaccion del sistema con
aplicaciones y usuarios.
5. Dominio de negocio: Este dominio soporta procesos de negocios y actividades de proce-
dimiento tales como manejo de relaciones con el cliente (CRM) y sistemas de ejecucion
de manufactura.
Por ultimo, el punto de vista de implementacion se enfoca en la representacion tecnica
de un sistema en el marco de IIoT, las tecnologıas y los componentes requeridos para la
implementacion del sistema. Ademas se detallan 3 patrones arquitecturales que permiten la
implementacion de estos sistemas. A continuacion se describen los tres patrones:
2.3 Internet de las Cosas Industrial 13
Figura 2-3: Dominios Funcionales
1. Patron arcquitectural de tres niveles.
Este patron combina la mayorıa de los componentes de los dominios funcionales se com-
pone de el nivel de borde (Edge Layer), el nivel de plataforma (Platform Layer) y el nivel
empresarial (Enterprise Layer).
El nivel de borde recolecta la informacion a traves de los nodos de borde, usando la red
de proximidad. La capa de plataforma recibe, procesa y almacena la informacion recibida
del nivel de borde, y sirve de intermediaria entre el nivel de borde y el nivel empresarial.
Por ultimo, la capa empresarial implemeta aplicaciones de dominio especıfico, sistema de
soporte de decisiones y provee interfaces para el usuario final.
2. Patron arquitectural de administracion y conectividad de borde mediada por gateway.
Este patron comprende una solucion de conectividad local para el borde de un sistema
bajo el marco de IIoT, en el que un gateway sirve como puente entre una LAN y una
WAN. El gateway sirve como punto final de la WAN y a su vez recopila informacion que
llegan de los nodos ubicados en la red local. La principal ventaja de este patron es la baja
complejidad a la hora de implementarlo.
3. Patron arquitectural de DATABUS en capas.
Un DATABUS es un espacio de logica conectado que implementa un conjunto de esquemas
comunes y se comunica usando ese conjunto de esquemas entre los puntos finales. Cada
capa de este patron implementa un modelo de datos comun, permitiendo comunicaciones
interoperables entre cada una de ellas.
14 2 Internet de las Cosas Industrial: Marco Teorico y Estado del Arte
Figura 2-4: Patron arquitectural de 3 niveles.
Figura 2-5: Patron arquitectural de administracion y conectividad de borde mediada por
gateway.
2.3 Internet de las Cosas Industrial 15
Figura 2-6: Patron arquitectural de DATABUS en capas.
16 2 Internet de las Cosas Industrial: Marco Teorico y Estado del Arte
2.4. Conclusiones
En este capıtulo se define el concepto de Internet de las Cosas y sus caracterısticas. Se
profundiza sobre el uso de este paradigma en el campo industrial, definiendo el termino
Internet de las Cosas Industrial, adicionalmente se presentan RAMI 4.0 e IIRA, 2 esfuerzos
importantes en la busqueda de estandarizacion del diseno e implementacion de sistemas y
aplicaciones en el marco de IoT. Este trabajo selecciona una de las arquitecturas de referencia
presentadas y se utiliza como base para la construccion de la solucion propuesta.
3 Middlewares y Frameworks IoT: Marco
Teorico y Estado del Arte
3.1. Introduccion
Un Middleware se puede definir de manera generica como una herramienta que permite la
interaccion y comunicacion entre varias entidades, ya sean hardware o software. Esta capaci-
dad puede ser utilizada para interconectar dispositivos y alicaciones en el marco de Internet
de las Cosas. Sin embargo, su implmentacion puede tornarse dıficil para el desarrollador de
aplicaciones debido a la complejidad que implica su desarrollo. Es por ello que este trabajo
propone la elaboracion de un Framework que permita implementar de manera practica un
Middleware, de acuerdo a los requerimientos especıficos del problema.
3.2. Middlewares IoT
Un middleware es un software framework ejecutandose entre una aplicacion y otra platafor-
ma. Un middleware puede proveer una abstraccion de los sistemas para el desarrollador de
aplicaciones de tal forma que pueda desarrollar una aplicacion facilmente. En este orden de
ideas, una aplicacion distribuida puede ser desarrollada mas rapidamente y de una forma
mas confiable [Bemporad et al., 2010]. [Razzaque et al., 2016] presenta diferentes enfoques
en los que un Middleware IoT puede ser desarrollado:
Basado en eventos: En este tipo de middleware, los componentes, las aplicaciones y todos
los demas participantes interactuan a traves de eventos. Cada evento tiene un conjunto
de parametros cuyos valores describen los cambios de estados de quien los produjo.
Orientado a servicios: La computacion orientada a servicios permite construir software y
aplicaciones en forma de servicios, funciones sin estados que reciben peticiones median-
te una interfaz bien definida. Algunas de las ventajas de este tipo de middleware son
neutralidad de tecnologıa, bajo acoplamiento, reusabilidad y descubrimiento de servicios.
Orientado a maquinas virtuales: Provee soporte para un ambiente de ejecucion seguro para
los usuarios haciendo uso de la virtualizacion. Las aplicaciones son divididas en pequenos
18 3 Middlewares y Frameworks IoT: Marco Teorico y Estado del Arte
modulos separados, los cuales son separados y distribuidos a traves de la red. Cada nodo
en la red es representado por una maquina virtual.
Basado en agentes: En este caso las aplicaciones son divididas en programas modulares
para facilitar la inyeccion y la distribucion a traves de la red usando agentes moviles.
Tupla-espacio: En este tipo de middleware, cada miembro de la infraestructura mantiene
una estructura tupla-espacio local. Una tupla-espacio es un repositorio de datos que puede
ser accedido concurrentemente. Todas las tupla-espacio forman una tupla-espacio federada
sobre un gateway. Las aplicaciones se comunican escribiendo en la tupla-espacio federada
y cada dispositivo lee la tupla-espacio que requiere en cada situacion.
Orientado a base de datos: En este enfoque una red de sensores es vista como un sistema
de base de datos relacional. Una aplicacion puede consultar la base de datos realizando
consultas en esta.
Cada enfoque tiene ventajas y desventajas, y su seleccion depende de las caracterısticas que
el desarrollador requiere implementar. [Zhiliang et al., 2011] presenta un Middleware en el
que combina las caracterısticas de la computacion orientada a servicios y los sistemas mul-
tiagentes, con el objetivo de convertir una red IoT heterogenea en una red IoT homogenea.
[Teixeira et al., 2011] describe los desafıos de implementar Middlewares IoT y propone un
solucion desde el enfoque de la arquitectura orientada en servicio en el que se abstrae una
“cosa” como un servicio de software que tambien tiene un lado fısico (Medir y/o actuar).
IoT@Work es presentado por [Gusmeroli et al., 2012], un middleware basado en eventos que
permite patrones de comunicacion uno a muchos y muchos a muchos. Las funcionalidades
de este middleware fueron implementadas para ser usadas dentro y fuera de una planta in-
dustrial.
[Boman et al., 2014] propone un middleware IoT donde los datos recolectados desde los
sensores no solo pueden ser monitoreados en tiempo real, sino tambien automaticamente
convertido en informacion accionable por un interpretador de informacion basado en valores
de triggers o en condiciones preestablecidas por el usuario. Esta solucion brinda informacion
contextual acerca de los dispositivos fısicos y permite que las aplicaciones IoT sean desarro-
lladas en un contexto de alto nivel independiente a las propiedades fısicas de bajo nivel de
los sensores.
3.2.1. Recopilacion de requerimientos
[Razzaque et al., 2016] define los requerimientos basicos que un Middleware debe tener bajo
el marco de IoT:
3.3 Frameworks IoT 19
Descubrimiento de recursos: Debe posibilitar el descubrimiento de recursos y este deberıa
ser automatizado.
Administracion de los recursos: Se espera una aceptable calidad de servicio para todas
las aplicaciones y en un ambiente donde los recursos impactan la calidad de servicio.
Como IoT es importante que las aplicaciones puedan tener un servicio que administre esos
recursos.
Manejo de eventos: Debe proveer analisis en tiempo real de la informacion.
Manejo de la informacion: Debe proveer adquisicion, procesamiento y almacenamiento de
la informacion.
Administracion del codigo: Desplegar codigo en un ambiente IoT es desafiante, y deberıa
ser directamente soportado por el middleware.
Abstraccion de la programacion: Para el desarrollador de aplicaciones o servicios, las in-
terfaces de programacion de alto nivel necesitan aislar el desarrollo de las aplicaciones o
servicios de las operaciones que se proveen en la capa baja de la infraestructura heterogenea
de IoT.
Escalable: Un middleware IoT necesita ser escalable para manejar el crecimiento de la red
IoT.
Confiable: Deberıa proveer una alta tolerancia a fallos.
Interoperable: Debe trabajar con dispositivos, tecnologıas y aplicaciones heterogeneas, sin
que el programador realice un esfuerzo adicional.
3.3. Frameworks IoT
Un framework es una abstraccion de un software que provee funcionalidades genericas que
pueden ser modificadas para crear aplicaciones especıficas. En el marco de IoT los Frame-
works han sido orientados a dominios de aplicacion especıficos.
[Jin et al., 2014] y [Theodoridis et al., 2013] proponen Frameworks para la realizacion de
Ciudades Inteligentes a traves de Internet de las cosas. [Jin et al., 2014] se enfocan en cons-
truir un framework de tres capas para informacion urbana generica que permite una eficiente
recoleccion de datos. [Theodoridis et al., 2013] presentan un framework de tres capas basado
en servicios, este framework fue evaluado en SmartSantander [Hernandez-Munoz and Munoz, 2013],
un proyecto que intenta construir una ciudad que soporte la experimentacion de tecnologıas
IoT.
20 3 Middlewares y Frameworks IoT: Marco Teorico y Estado del Arte
En el campo de seguridad [Seitz et al., 2013] proponen un framework que maneja control de
autorizacion y de acceso, en el contexto de sistemas interconectados que consisten de disposi-
tivos restringidos de recursos no directamente operados por humanos. El framework maneja
el estandar de control de acceso XACML. [Babar et al., 2011] provee una exhaustiva vista
de la seguridad embebida para sistemas IoT y propone una metodologıa hardware/software
que puede ayudar a los disenadores y desarrolladores a desplegar dispositivos mas seguros.
[Ray, 2014] presenta H3IoT, un framework basado en IoT para el monitoreo de salud a per-
sonas de edad avanzada en el hogar. Es un framework de 5 capas el cual maneja diferentes
protocolos y dispositivos.
En el campo de la industria [Liu et al., 2013] propone un framework que auto-aprende para
detectar fallas de sensores, para monitoreo industrial con IoT. Este framework usa hilos para
el proceso de aprendizaje basado en informacion de los sensores.
Los Middleware Frameworks por su parte combinan arquitecturas bien disenadas con he-
rramientas utiles y promueve el desarrollo de aplicaciones con interfaces estandarizadas y
personalizables. [Baliga, 2005] presenta Etherware, un middleware framework desarrollado
especıficamente para el dominio de aplicaciones de control en red. Su modelo de programacion
es orientado a mensajes y los diferentes componentes intercambian mensajes e interactuan
directamente con Etherware. Una aplicacion de control en red puede ser desarrollada con
este middleware framework si soporta el desarrollo de aplicaciones basadas en componentes.
[Valente and Martins, 2010] presenta el diseno e implementacion de MufFIN, un middleware
framework bajo una arquitectura orientada a servicios donde los servicios representan fun-
cionalidades de redes de sensores y proveen una forma dinamica para que aplicaciones de
alto nivel puedan interactuar con dispositivos con hardware heterogeneo. Este framework
fue elaborado siguiendo el estandar Sensor Web Enablement (SWE).
[Katole et al., 2015] propone un Middleware framework orientado a servicios en el que se
construyen M2M APIs para permitir la comunicacion de dispositivos de dispositivos de una
forma unificada.
3.3.1. Recopilacion de requerimientos
IoT es un paradigma que necesita la integracion de varias tecnologıas para ser una realidad:
M2M, computacion en la nube, Big data, protocolos de comunicacion y red de sensores
inalambricos. Al integrar estas tecnologıas presentan algunas caracterısticas y requerimientos
[Zhou et al., 2013]:
Administracion y manejo de la informacion: Las cosas (dispositivos) generan una gran
3.3 Frameworks IoT 21
cantidad de datos que necesitan ser almacenados y administrados.
Interfaces basadas en la web: Las cosas (dispositivos) requieren de esto para intercambiar
datos e integrar distintas aplicaciones.
Interoperabilidad: Los dispositivos son heterogeneos sin embargo deben tener la capacidad
de comunicarse entre sı.
Tiempo real: las aplicaciones basadas en IoT pueden se clasificadas de tiempo real y de
no tiempo real.
Aplicaciones diversas: IoT puede ofrecer sus servicios a una gran cantidad de aplicaciones
en numerosos dominios y ambientes.
Red dinamica: IoT integrara muchos dispositivos heterogeneos. Los dispositivos pueden
ser conectados o desconectados en cualquier momento.
Todo como servicio (Everything-as-a-service, XaaS): Entre mas dispositivos esten conecta-
dos, el numero de aplicaciones creceran tambien. Estos servicios estaran disponibles para
ser usados y reusados.
Seguridad: IoT necesita accesibilidad y conectividad global, lo cual significa que cualquiera
puede accederlo en cualquier momento y en cualquier lugar. Esto incrementa tremenda-
mente el rango de ataques para las aplicaciones y redes IoT.
Privacidad: Cualquier aplicacion IoT que no cumpla con los requerimientos de privacidad
puede ser prohibida por la ley debido a que viola la privacidad de los ciudadanos.
Las APIs construidas en los Frameworks IoT tambien deben cumplir con los siguientes
requerimientos [Katole et al., 2015]:
Comunicacion: El sistema debe suportar la comunicacion autonoma, periodica y basada
en eventos. Los dispositivos deben ser monitoreados de manera remota y en tiempo real.
La comunicacion debe ser segura y confiable. El sistema debe permitir el traslado de los
dispositivos sin generar grandes cambios en la aplicacion.
Control de dispositivos: Debe proveer la gestion de los dispositivos de manera remota tal
como desactivacion o activacion.
Abstraccion de la programacion: Debe proveer funcionalidades genericas y faciles de mo-
dificar para el desarrollador final.
Notificacion de fallas de comunicacion: Es indispensable tener herramientas que informen
acerca de fallas de comunicacion.
22 3 Middlewares y Frameworks IoT: Marco Teorico y Estado del Arte
3.4. Conclusiones
En este capıtulo se realiza la caracterizacion de Middlewares y Frameworks en el marco de
Internet de las Cosas. Se presentan los tipos de Middleware existentes y los trabajos mas
relevantes encontrados en la lieteratura. Se destaca los middleware orientados a servicios,
los cuales permiten una construccion modular, lo que permite tener un bajo acoplamiento y
neutralidad de tecnologıa.
Los frameworks IoT, por su parte, son implementados dependiendo del campo en que se
utilice. Adicionalmente, se define el termino Middleware Framework, los cuales permiten la
construccion de aplicaciones con arquitecturas estandarizadas y personalizables. La recopi-
lacion de los requerimientos que se realiza en este capıtulo seran utilizados como base para
el desarrollo de la solucion propuesta.
4 Middleware Framework IoT Propuesto
4.1. Introduccion
MIOT Framework (Middleware IoT Framework), es el nombre que recibe la herramienta
software propuesta. MIOT tiene como objetivo ofrecer al desarrollador de aplicaciones la
posibilidad de construir un Middleware a la medida en el marco de Internet de las Cosas. Su
desarrollo se basa en una de las arquitecturas de referencia descritas en el Capıtulo 2, con el
fin de obtener una herramienta estandarizada para el uso en Internet de las Cosas Industrial.
4.2. Diseno de los Modulos del Sistema
MIOT se construye siguiendo lo descrito en IIRA, debido a que es una arquitectura de refe-
rencia mejor estructurada y flexible, ademas, se adapta de mejor manera a los requerimientos
del problema planteado. Adicionalmente, IIRA trabaja bajo el enfoque de Internet Indus-
trial, cuya dinamica plantea el uso de sensores y actuadores bajo un ambiente industrial, lo
cual esta directamente relacionado con la integracion de Internet de las Cosas y los Sistemas
de Control en Red (NCS).
El diseno se basa en el Punto de Vista Funcional y de Implementacion de IIFA. Lqs activi-
dades de Puntos de Vista de Negocio y de Uso no se tienen en cuenta en el diseno, debido a
que estos Puntos de Vista estan relacionados con la monetizacion del negocio y la asignacion
de tareas en los equipos de trabajo, y son actividades que no estan fuertemente relacionadas
con el aspecto tecnico. Ası mismo, los Dominios de Operacion y Negocio del Punto de Vista
Funcional no hacen parte del diseno, debido a que la monetizacion del negocio y la optimi-
zacion de procesos dependeran del uso especıfico que se le de al Sistema.
El Middleware Framework propuesto busca que el desarrollador de aplicaciones posea una
herramienta practica y flexible que le permita la elaboracion de un Middleware interoperable
y escalable bajo el marco de Internet de las Cosas. El tipo de Middleware que se implementa
con la herramienta es Orientado a Servicios, puesto que este enfoque permite tener neutra-
lidad de tecnologıa, bajo acoplamiento y reusabilidad; aspectos claves a la hora de elaborar
un sistema Interoperable y escalable.
24 4 Middleware Framework IoT Propuesto
Figura 4-1: Arquitectura de MIOT Framework.
Se selecciona el Patron de Arquitectura de 3 Niveles descrito en el Punto de Vista de Im-
plementacion, en vista de que provee una representacion clara de la integracion de los Do-
minios Funcionales. Nuevamente se resalta que el trabajo se enfocara especıficamente en los
Dominios Funcionales de Control, Informacion y Aplicacion. A continuacion se describe el
Middleware Framework a partir del Patron de Arquitectura seleccionado (Ver Figura 4-1).
4.2.1. Nivel de Borde
Este nivel es el encargado de recopilar la informacion de los nodos y de hacer uso de los
actuadores. La implementacion de este nivel varıa dependiendo del caso de uso. Uno de
los problemas que se presentan en este borde es la baja interoperabilidad a causa de la
heterogeneidad tanto en hardware como en software de los dispositivos. Para contrarrestar
este desafıo se disenan dos API, una bajo el protocolo REST y otra bajo el protocolo MQTT.
Con la implementacion de estas API se permite abarcar un gran numero de dispositivos
sin importar su hardware o software. Se selecciona el protocolo MQTT porque tiene una
gran aceptacion en la comunidad de desarrolladores de aplicaciones IoT y esta enfocado
en convertirse en el protocolo estandar de este paradigma. Por otra parte, se selecciona el
protocolo REST, puesto que en la actualidad es el protocolo mas usado a la hora de construir
servicios Web, ademas multiples dispositivos proveen conectividad a traves de el.
4.2.2. Nivel de plataforma
Este nivel sirve como puente entre el Nivel de Borde y el Nivel Empresarial. En el recae la
responsabilidad de almacenar y dar el tratamiento adecuado a los datos que llegan desde los
4.3 Seleccion de la herramienta software 25
otros bordes. Este nivel recolecta la informacion a partir de las API descritas anteriormente;
la estructura de dicha informacion varıa dependiendo de la API que se usa, por lo que se
hace necesario dar un tratamiento a esa informacion. Para ello se disena el Modulo de
Ingestion y Persistencia, el cual recolecta toda la informacion y la almacena en una base
de datos relacional, haciendola accesible para los dos protocolos. El Middleware Framework
propuesto no esta atado a un motor de base de datos, con el objetivo de hacerlo flexible y facil
de usar por el desarrollador de aplicaciones (En el seccion tal se detalla este aspecto). Vale
agregar, que la herramienta propuesta provee un modulo de distribucion de la informacion
de un protocolo a otro, por lo que el desarrollador de aplicaciones no debe ocuparse de esta
funcionalidad.
4.2.3. Nivel Empresarial
Este nivel se compone de un portal en el que el usuario puede realizar operaciones de logica y
control sobre el sistema. La construccion del portal web depende del caso de uso y puede ser
implementado bajo cualquier tecnologıa web, puesto que la API REST provee este atributo.
4.3. Seleccion de la herramienta software
El objetivo principal de este trabajo es proporcionar un Middleware Framework que permita
interoperabilidad entre dispositivos heterogeneos tanto en hardware como en software para
aplicaciones IIoT. Ademas de lo anterior es indispensable que sea escalable y permita rea-
lizar implementaciones especıficas, de acuerdo a los requerimientos del problema. Se decide
trabajar bajo el lenguaje de programacion JAVA, debido a que permite elaborar sistemas
escalables, facil de mantener y ademas en el se han desarrollado las herramientas que posi-
bilitan el desarrollo de la solucion propuesta. Las herramientas de software seleccionadas se
describen a continuacion:
1. Maven: Maven es una herramienta que puede ser usada para construir y manejar cualquier
proyecto basado en java. Tiene como objetivo hacer el proceso de construccion de software
mas sencillo, proveer un sistema de construccion uniforme y permitir el uso de buenas
practicas de desarrollo [Project, 2018].
2. Spring: Es una plataforma JAVA que provee una infraestructura integral para desarrollar
aplicaciones JAVA. Una aplicacion JAVA tıpicamente consiste de objetos que colaboran
entre sı para formar dicha aplicacion. Por consiguiente, estos objetos crean dependencias
entre ellos. Spring proporciona mecanismos para que la aplicacion tenga un bajo acopla-
miento y una baja cohesion. Ademas, permite el uso de patrones de diseno promoviendo
26 4 Middleware Framework IoT Propuesto
buenas practicas de desarrollo. Por otra parte, contiene cerca de 20 modulos con funcio-
nalidades para el acceso e integracion de datos, desarrollo web, evaluacion, entre otros
[Framework, 2018b].
3. Hibernate: Es una solucion de mapeo relacional de datos de codigo abierto para aplicacio-
nes JAVA. Hibernate provee facilidades de consultas y recuperacion de datos que reducen
significativamente el tiempo de desarrollo. Hibernate permite desarrollar clase persistentes
siguiendo un idioma orientado a objetos (incluyendo asociacion, herencia, polimorfismo,
composicion y colecciones). Adicionalmente, permite expresar consultas en su propia ex-
tension portable de SQL (HQL) o en SQL nativo. Por ultimo, permite la creacion de
esquemas y conexiones con bases de datos de una forma agil [Framework, 2018a].
4. Mosquitto: Es un broker MQTT v3.1 de codigo abierto desarrollado por Roger Light. Per-
mite la creacion de un entorno para desarrollar las funcionalidades del protocolo MQTT
[Mosquitto, 2018].
5. Paho: Es un esfuerzo de la fundacion Eclipse para implementar MQTT en cualquier
lenguaje de programacion. Es codigo abierto y esta orientado a potenciar las aplicaciones
IoT, posibilitando la implementacion de clientes MQTT [Paho, 2018].
6. Jersey: Es un framework Java de codigo abierto que permite la contruccion de servicios
web RESTFUL implementando la API JAX-RS [Jersey, 2017].
4.4. Implementacion de los Modulos del Sistema
La implementacion se realiza tomando como base Maven y Spring. Maven permite estructurar
y gestionar de una forma organizada los modulos del sistema y sus dependencias. Spring,
por su parte, permite hacer uso de la inyeccion de dependencias lo cual permite crear un
bajo acoplamiento y una baja cohesion. Haciendo uso de estos dos frameworks el Middleware
Framework adquiere escalabilidad y flexibilidad, debido a que se le pueden agregar nuevas
funcionalidades causando menos traumatismos en las funcionalidades existentes.
4.4.1. Modulo de Persitencia
Una vez establecida la estructura basica de MIOT se procede a la elaboracion del Modulo
de persistencia del Nivel de Informacion y para ello se parte de las siguientes consignas:
1. Un usuario puede desplegar a aplicaciones.
2. Una aplicacion puede hacer uso de d dispositivos.
3. Un dispositivo puede hacer uso de s sensores y ac actuadores.
4.4 Implementacion de los Modulos del Sistema 27
Figura 4-2: Diagarama entidad relacion del sistema.
4. Un sensor puede generar sk valores.
5. Un actuador puede recibir ack valores.
Teniendo en cuenta las consignas anteriores se disena el esquema de la base de datos (Ver
Figura 4-2). Vale agregar que cada aplicacion, dispositivo, sensor y actuador poseen un token
unico que los identifica. Se hace uso de Hibernate para realizar el mapeo de la base de datos,
ademas se aprovecha la habilidad de Hibernate para crear bases de datos a partir de las cla-
ses; en otras palabras el desarrollador de aplicaciones no necesita implementar directamente
la base de datos sobre el motor de su preferencia. MIOT permite la generacion del esquema
inmediatamente se ejecute la implementacion, para ello solo debe definir los parametros de
conexion en el archivo de configuracion hibernate.cfg.xml.
4.4.2. API REST
La API REST se construye haciendo uso del Framework Jersey y contiene los servicios web
que proveen las funcionalidades basicas de MIOT. A continuacion se describen los recursos:
28 4 Middleware Framework IoT Propuesto
Prefijo URI: miot/webapi/*
USUARIOS:
GET
users/{userName}
Usado para obtener un usuario a partir de su nombre de usuario.
users
Usado para obtener la lista de usuarios existentes.
POST
users
Usado para crear un nuevo usuario.
Ejemplo:
URI: miot/webapi/users
Body:
content-type: application/json
{
"userName":"user",
"firstName":"userF",
"lastName":"userL",
"password":"userP"
}
APLICACIONES:
GET
users/{userName}/apps/{tokenApp}
Usado para obtener una aplicacion de un usuario a partir de su token.
users/{userName}/apps
Usado para obtener la lista de aplicaciones de un usuario.
POST
4.4 Implementacion de los Modulos del Sistema 29
users/{userName}/apps
Usado para crear una nueva aplicacion.
Ejemplo:
URI: miot/webapi/users/user/apps
Body:
content-type: application/json
{
"applicationName":"Test application"
}
DISPOSITIVOS:
GET
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}
Usado para obtener un dispositivo de una aplicacion a partir de su token.
users/{userName}/apps/{tokenApp}/devices
Usado para obtener la lista de dispositivos de una aplicacion.
POST
users/{userName}/apps/{tokenApp}/devices
Usado para crear un nuevo dispositivo.
Ejemplo:
URI: miot/webapi/users/user/apps/1cae0355b3754888be199d3ba805eb32/devices
Body:
content-type: application/json
{
"deviceName":"Device 1"
}
SENSORES:
GET
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/sensors/{sensorToken}
30 4 Middleware Framework IoT Propuesto
Usado para obtener un sensor de un dispositivo a partir de su token.
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/sensors
Usado para obtener la lista de sensores de un dispositivo.
POST
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/sensors
Usado para crear un nuevo sensor.
Ejemplo:
URI: miot/webapi/users/user/apps/1cae0355b3754888be199d3ba805eb32/devices/
c74eaf0129254ea4a484c8f76bc16ad0/sensors
Body:
content-type: application/json
{
"sensorName":"Temperature"
}
ACTUADORES:
GET
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/actuators/{actuatorToken}
Usado para obtener un actuador de un dispositivo a partir de su token.
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/actuators
Usado para obtener la lista de actuadores de un dispositivo.
POST
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/actuators
Usado para crear un nuevo actuador.
Ejemplo:
URI: miot/webapi/users/user/apps/1cae0355b3754888be199d3ba805eb32/devices/
c74eaf0129254ea4a484c8f76bc16ad0/actuators
Body:
content-type: application/json
{
"sensorName":"Actuator 1"
}
4.4 Implementacion de los Modulos del Sistema 31
VALORES DE SENSORES:
GET
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/sensors/{sensorToken}/sv
Usado para obtener el ultimo valor leıdo por el sensor.
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/sensors/{sensorToken}/sv/list
Usado para obtener la lista de valores leıdos por el sensor.
POST
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/sensors/{sensorToken}/sv
Usado para enviar un valor del sensor.
Ejemplo:
URI: miot/webapi/users/user/apps/1cae0355b3754888be199d3ba805eb32/devices/
c74eaf0129254ea4a484c8f76bc16ad0/sensors/ba935c5e2e194962be7af9c8777390dd/sv
Body:
content-type: application/json
{
"value":10
}
VALORES DE ACTUADORES:
GET
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/actuators/{actuatorToken}/av
Usado para obtener el ultimo valor enviado al actuador.
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/actuators/{actuatorToken}/av/list
Usado para obtener la lista de valores enviados al actuador.
POST
users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/actuators/{actuatorToken}/av
Usado para enviar un valor del actuador.
Ejemplo:
32 4 Middleware Framework IoT Propuesto
URI: miot/webapi/users/user/apps/1cae0355b3754888be199d3ba805eb32/devices/
c74eaf0129254ea4a484c8f76bc16ad0/actuators/ba935c5e2e194962be7af9c8777390dd/av
Body:
content-type: application/json
{
"value":10
}
4.4.3. API MQTT
Para el correcto funcionamiento de MQTT es necesario preparar y configurar un broker, tam-
bien conocido como servidor. Todos los nodos MQTT se suscriben y publican en los topicos
haciendo conexion con el broker. Para que MIOT pueda adquirir y procesar los mensajes de
los dispositivos es necesario que este se suscriba a un topico general del broker.
Se prepara y configura el broker Mosquitto el cual es de codigo abierto y permite trabajar
con la version 3.1 de MQTT. Sin embargo, MIOT no esta atado al uso de Mosquitto, por
consiguiente el desarrollador de aplicaciones puede utilizar el broker de su preferencia.
Para establecer la comunicacion con el broker es necesario establecer los parametros de con-
figuracion en el archivo application.properties. Es crucial la definicion del topico, que por
defecto se define como miot/v1, esto quiere decir que MIOT se suscribira y publicara a todos
los topicos que inicien con miot/v1.
MIOT necesita procesar los mensajes a traves del protocolo MQTT y para ello se implemen-
tan 2 clientes MQTT, un publicador y un suscriptor. Estos clientes se implementan haciendo
uso de PAHO. Por otra parte, los nodos deben enviar los mensajes haciendo uso del mismo
broker al que esta conectado MIOT y utilizar el prefijo miot/v1.
El topico al que se debe publicar el valor del sensor de un nodo, debe tener la siguiente
estructura: miot/v1/{userName}/{tokenApp}/{tokenDevice} /s/{tokenSensor}.
Ademas, el mensaje debe seguir la siguiente estructura:
“{message}”.
Para la subscripcion al sensor de un nodo, se debe utilizar un topico con la siguiente estruc-
tura: miot/v1/{userName}/{tokenApp}/{tokenDevice} /s/{tokenSensor}/v.
Del mismo modo, el topico al que se debe publicar el valor del actuador de un nodo, debe tener
la siguiente estructura: miot/v1/{userName}/{tokenApp} /{tokenDevice}/a/{tokenActuator}.
Ademas, el mensaje debe seguir la siguiente estructura:
4.5 Conclusiones 33
“{message}”.
Para la subscripcion al actuador de un nodo, se debe utilizar un topico con la siguiente estruc-
tura: miot/v1/{userName}/{tokenApp}/{tokenDevice} /a/{tokenSensor}/v.
Es necesario que los mensajes sigan la estructura mencionada debido a que los mensajes
MQTT no proveen la informacion del publicador original. Una vez el suscriptor de MIOT
identifica a quien va dirigido el mensaje, hace uso del Modulo de Persistencia, para que
alamacene el mensaje y tambien pueda ser accedido por el protocolo REST.
El publicador por su parte es utilizado por el protocolo REST. Cuando se envıa un valor
de un sensor o actuador haciendo uso del protocolo REST, se hace uso del publicador para
enviar los mensajes al broker y ası el mensaje sea accedido por los nodos conectados por el
protocolo MQTT.
4.5. Conclusiones
En este capıtulo se presenta el diseno y la implementacion de MIOT Framework, el cual se
construye tomando como base la IIFA de IIRA. En otras palabras MIOT es una herramienta
estandarizada que permite implementar Middlewares a la medida en el marco de Internet
de las Cosas Industrial. En su nucleo provee 2 API que facilitan la comunicacion entre
dispositivos y aplicaciones heterorogeneas, creando un ambiente interoperable y de gran
escalabilidad. Los protocolos seleccionados estan llamados a ser el estandar de aplicaciones
web (REST) y de Internet de las Cosas (MQTT). Adicionalmente, su modulo de persistencia
permite un despliegue practico sobre el motor de bases de datos relacional que el desarrollador
prefiera. A este trabajo se le anexa una guıa de usuario, con el fin de reducir la curva de
aprendizaje del desarrollador de aplicaciones. Con este capıtulo se cumplen los objetivos
especıficos 1, 2 y 3.
5 Evaluacion y Validacion del
Middleware Framework
5.1. Introduccion
El Middleware Framework desarrollado en este trabajo se valida implementando una apli-
cacion IoT haciendo uso de el. Esta aplicacion busca servir de guıa para los desarrolladores
de aplicaciones a la hora de hacer uso de la herramienta, y ademas es un arquetipo a la
hora de elaborar sistemas bajo IIRA. Adicionalmente, MIOT es evaluado haciendo uso de
una metodologıa de evaluacion de software, lo que permite corroborar si es una herramienta
fıable y estandarizada.
5.2. Diseno e implementacion de la aplicacion IoT
Para validar el uso de MIOT se elabora una aplicacion IoT. Se decide desarrollar una apli-
cacion de uso general en la que se hace uso de las funcionalidades de MIOT, que a su vez
servira como guıa para elaborar otras aplicaciones en contextos especıficos.
La aplicacion se construye siguiendo IIRA, con el fin de tener una aplicacion estandarizada
(Ver Figura 5-1). En el Dominio de Control se encuentran los dispositivos de medicion y
atuacion. Se seleccionan la tarjeta de desarrollo Raspberry Pi 2 Model B (RPI) y el disposi-
tivo NODE MCU. La tarjeta Raspberry Pi 2 Model B se utiliza para medir la temperatura
de su nucleo y enviar dichas mediciones a MIOT haciendo uso de las API REST y MQTT.
La tarjeta NodeMCU por su parte realiza una actuacion que depende de la temperatura
del nucleo de una de las RPI. Vale agregar que estos dispositivos se comunican de manera
inalambrica.
El dominio de informacion esta compuesto por MIOT, el cual hace uso del motor de base
de datos MySQL para su modulo de persistencia y Mosquitto como su broker. Con esto se
comprueba que MIOT puede trabajar con motores de bases de datos relacionales e integrarse
a un broker MQTT.
Por ultimo, se elabora una aplicacion web utilizando Spring Boot (Framework para el desa-
5.3 Evaluacion de la Solucion 35
Figura 5-1: Aplicacion IoT
rrollo de aplicaciones web con el lenguaje JAVA), que permite evidenciar que MIOT permite
la integracion tanto de dispositivos como de aplicaciones. La Figura 5-2 muestra las lecturas
realizadas desde la RPI, que hace uso del protocolo MQTT, desde la aplicacion, esto demues-
tra que los datos enviados desde los clientes MQTT se almacenan correctamente y pueden
ser accedidos mediente la API REST. Por otra parte, la Figura 5-3 muestra un modulo de
la aplicacion Web donde se puede enviar comandos directamente al actuador. Este ultimo
modulo evidencia que MIOT puede realizar actuaciones sobre clientes MQTT haciendo uso
del protocolo REST.
5.3. Evaluacion de la Solucion
Para la evaluacion de MIOT se hace uso del estandar internacional ISO/IEC 9126, el cual
define un modelo general de calidad para productos de software. Este modelo se basa en 6
caracterısticas: Funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad y porta-
bilidad. Estas caracterısticas se definen en detalle a continuacion:
Funcionalidad
Esta caracterıstica esta relacionada con la capacidad del software de proveer y cumplir las
funciones necesarias para cumplir una tarea especıfica. Esta caracterıstica se descompone en
las siguientes subcaracterısticas:
1. Idoneidad: Es la capacidad del software de proveer las funciones adecuadas para cumplir
tareas especıficas dados por el usuario.
36 5 Evaluacion y Validacion del Middleware Framework
Figura 5-2: Aplicacion IoT
Figura 5-3: Aplicacion IoT
5.3 Evaluacion de la Solucion 37
2. Interoperabilidad: Es la capacidad del software de interactuar con una o mas entidades.
3. Exactitud: Es la capacidad del software de entregar resultados de una tarea de manera
precisa.
4. Seguridad: Es la capacidad del software de proveer proteccion a la informacion y no
permitir que usuarios o sistemas no autorizados accedan a ella.
Fiabilidad
Esta caracterıstica esta relacionada con la capacidad del software de garantizar un nivel
de rendimiento especıfico bajo ciertas condiciones. Esta caracterıstica se descompone en las
siguientes subcaracterısticas:
1. Madurez: Es la capacidad del software de evitar fallas cuando encuentra errores.
2. Tolerancia a fallos: Es la capacidad del software de mantener la operacion en caso de
errores.
3. Facilidad de recuperacion: Es la capacidad del software de recuperar su funcionamiento
en caso de errores.
Usabilidad
Esta caracterıstica esta relacionada con la capacidad del software de ser utilizado de una
forma facil. Esta caracterıstica se descompone en las siguientes subcaracterısticas:
1. Comprension: Es la capacidad que tiene el software de permitir al usuario de entender la
forma de usarlo en tareas especıficas.
2. Aprendizaje: Es la capacidad que tiene el software de permitir al usuario aprender su uso.
3. Operatividad: Es la capacidad que tiene el software de permitir ser usado por el usuario.
Eficiencia
Esta caracterıstica esta relacionada con el rendimiento del software ante ciertas condiciones.
Esta caracterıstica se descompone en las siguientes subcaracterısticas:
1. Tiempo de uso: Es la capacidad del software de cumplir con los tiempos de respuesta.
2. Utilizacion de recursos: Es la capacidad del software de trabajar con ciertos recursos bajo
ciertas condiciones.
38 5 Evaluacion y Validacion del Middleware Framework
Mantenibilidad
Esta caracterıstica esta relacionada con la capacidad del software de ser modificado. Esta
caracterıstica se descompone en las siguientes subcaracterısticas:
1. Facilidad de analisis: Es la forma en que el software permite realizar analisis de causas de
errores.
2. Facilidad de cambio: Es la capacidad del software de permitir ser modificado.
3. Facilidad de prueba: Es la capacidad del software de permitir realizar pruebas de las
modificaciones sin poner en riesgo su funcionamiento.
Portabilidad
Esta caracterıstica esta relacionada con la capacidad del software de ser adaptado a diferentes
ambientes. Esta caracterıstica se descompone en las siguientes subcaracterısticas:
1. Instalacion: Es la capacidad del software de ser instalado en un entorno especıfico.
2. Ajustes: Es la capacidad que tiene el software de permitir cambios de entorno.
3. Adaptacion al cambio: Es la capacidad que tiene el software de ser reemplazado por otro
para cumplir con las mismas tareas.
Para la evaluacion de MIOT no se tiene en cuenta la caracterıstica eficiencia, puesto que
depende de la infraestructura donde se implemente. Ademas se define que cada subcarac-
terıstica puede obtener un puntaje entre 0 y 3, donde 0 significa que no cumple con la
subcaracterıstica, 1 significa que cumple en un nivel bajo la subcaracterıstica, 2 cumple sig-
nifica medianamente con la subcaracterıstica y 3 significa que cumple completamente con
la subcaracterıstica. Por otra parte, para la calificacion final se tiene en cuenta el siguiente
criterio de evaluacion:
Deficiente: 0 a 30 %
Insuficiente: 31 a 50 %
Aceptable: 51 a 70 %
Sobresaliente: 71 a 90 %
Excelente: 91 a 100 %
5.3 Evaluacion de la Solucion 39
Figura 5-4: Evaluacion Caracterıstica Funcionalidad
La primera caracterıstica en evaluar fue la Funcionalidad, en esta evaluacion vale resaltar el
resultado de Interoperabilidad, MIOT ofrece 2 API que permiten la integracion de diversos
dispositivos heterogeneos tanto en hardware o software, ademas de aplicaciones web de di-
versas tecnologıas (Ver Figura 5-4).
En cuanto a la Fiabilidad se requiere mejorar el aspecto de madurez, esta subcaracterıstica
requiere de un trabajo complejo en el marco de IoT, debido a que no solo se debe reportar
fallas del sistema sino tambien posibles fallas en los dispositivos (Ver Figura 5-5).
MIOT provee la documentacion necesaria para su puesta en marcha, ademas esta construido
bajo la IIFA, el cual provee una estructuracion sencilla de los modulos del sistema. Otro
aspecto clave, es la configuracion basada en archivos, el desarrollador no necesita introdu-
cirse en el codigo fuente para definir los parametros de conexion. Todas las herramientas
utilizadas son de codigo abierto, lo cual facilita el aprendizaje del usuario. Sin embargo es
necesario que este posea un conocimiento mınimo de los protocolos REST y MQTT.Por lo
anterior, se obtiene un resultado sobresaliente en la caracterıstica Usabilidad (Ver Figura
5-6).
El Middleware Framework presentado en este trabajo esta construido bajo un lenguaje de
programacion con una comunidad enorme, ademas trabaja en multiples sistemas operati-
vos. El uso de Spring y Maven, permiten tener una herramienta bien estructurada y con
40 5 Evaluacion y Validacion del Middleware Framework
Figura 5-5: Evaluacion Caracterıstica Fiabilidad
Figura 5-6: Evaluacion Caracterıstica Usabilidad
5.4 Conclusiones 41
Figura 5-7: Evaluacion Caracterıstica Mantenibilidad
un bajo acoplamiento entre sus modulos. Esto ultimo posibilita la integracion sencilla de
nuevas funcionalidades sin afectar el funcionamiento del sistema. Por ultimo, su instalacion
es sencilla ya que su configuracion se hace a traves de un par de archivos. Por consiguiente,
el Middleware Framework propuesto obtiene una calificacion ideal en las caracterısticas de
Mantenibilidad y Portabilidad (Ver Figuras 5-7 y 5-8).
Por ultimo se hace un balance general de la evaluacion, y se obtiene que MIOT cumple de
manera sobresaliente con los requisitos de calidad del estandar ISO/IEC 9126.
5.4. Conclusiones
En este capıtulo se presentan los resultados de la validacion y la evaluacion de la solucion
propuesta. En primer lugar se presenta el diseno e implementacion de un aplicacion IoT
bajo el marco de IIRA, esto es un aporte fundamental a los desarrolladores de aplicaciones
que desean construir aplicaciones estandarizadas, puesto que la creacion y divulgacion de
arquitecturas de referencias en el marco de IoT se encuentra en desarrollo. La aplicacion
implementada corrobora la integracion de dispositivos y aplicaciones heterogeneas, ademas
de su facil integracion al sistema. En otras palabras, se obtiene un ambiente interoperable y
escalable.
Asimismo, se realiza la evaluacion del Middleware Framework haciendo uso del estandar
ISO/IEC 9126, cuyo realizacion arroja que MIOT cumple con sus requisitos de calidad de
forma sobresaliente.
42 5 Evaluacion y Validacion del Middleware Framework
Figura 5-8: Evaluacion Caracterıstica Portabilidad
Figura 5-9: Resultado Final
6 Conclusiones y Trabajos Futuros
6.1. Conclusiones
Internet de las Cosas es un paradigma novedoso que permite la creacion de aplicaciones que
tienen como objetivo mejorar la calidad de vida de las personas. Estas aplicacione pueden
ser desplegadas en distintos campos, este trabajo se enfoca en las aplicaciones de control en
red, las cuales juegan un rol importante en la integracion de IoT y la industria. Para que
estas aplicaciones puedan ser desplegadas de manera correcta se necesita de la integracion de
diversas tecnologıas, dispositivos y aplicaciones web. Esto obliga al desarrollador de aplica-
ciones a tener conocimientos y a redoblar sus esfuerzos en construir los mecanismos para que
logren integrarse, descuidando su labor principal, desarrollar la aplicacion IoT. Esto ultimo
se agrava cuando el numero de dispositivos y aplicaciones incrementa.
En este trabajo se presento a MIOT Framework, una herramienta software que provee me-
canismos para la gestion e integracion de dispositivos y aplicaciones heterogeneas. Para su
construccion se recopilaron los requerimientos que debe cumplir bajo el marco de Internet
de las Cosas. Para el cumplimiento de estos requerimientos se presentan dos arquitecturas
de referencias: RAMI 4.0 e IIRA. Estas arquitecturas de referencia son 2 de los esfuerzos
mas relevantes en la elaboracion de arquitecturas que permitan la implementacion de siste-
mas IoT estandarizados. Estas arquitecturas de referencia estan en una etapa de desarrollo
temprana, por lo que su utilizacion y divulgacion en este trabajo es un aporte significativo a
la comunidad de desarrolladores IoT. Para disenar la estructura del Middleware Framework
se selecciona IIRA, debido a que provee una documentacion mas elaborada y presenta IIFA,
un arquitectura de referencia para la construccion de Frameworks.
Una vez seleccionada la arquitectura que sirve como base para la estructura del middleware
framework, se elaboran los modulos del sistema que la componen, estos modulos se disenan
siguiendo lo presentado en IIFA, especıficamente en el Punto de Vista Funcional y de Im-
plementacion. Se decide desarrollar una arquitectura de 3 niveles, puesto que permite una
integracion modular de las diversas tecnologıas y una implementacion orientada a servicios.
Uno de los requerimientos a cumplir es la gestion y la administracion de la informacion,
para ello se disena un modulo de persistencia que permite realizar esta tarea. Otro de los
requerimientos fundamentales es facilitar la interconexion de diferentes dispositivos hete-
rogeneos, por consiguiente se disenan 2 API, una REST y una MQTT. Todo con el fın de
44 6 Conclusiones y Trabajos Futuros
ampliar la gama de dispositivos que se pueden integrar, sin importar su hardware o software.
Para la implementacion de estos modulos se seleccionan un conjunto de heramientas software
que trabajan bajo el lenguaje de programacion JAVA. JAVA es un lenguaje de programacion
que trabaja en multiples sistemas operativos, ademas su comunidad ha desarrollado un con-
junto de herramientas que permiten implementar la solucion propuesta. Se utiliza Spring y
Maven como herramientas para gestionar el sistema y proveer un ambiente modular, Jersey
es utilizado para la implmentacion de la API REST, PAHO posibilita el uso del protocolo
MQTT en el sistema, y por ultimo Hibernate juega un rol de vital importancia para proveer
las herramientas de persistencia y que evitan una dependencia de un motor de bases de datos
en especıfico.
Una vez implementado el sistema, se procede a realizar su validacion creando una aplicacion
IoT haciendo uso de las funcionalidades de MIOT Framework. Para la aplicacion IoT se
hace uso de dispositivos de diferentes caracterısticas, los cuales hacen uso de las API im-
plementadas para su conexion al sistema. Se elabora una aplicacion web que tambien hace
uso de la API REST. Esto permite verificar que MIOT provee las herramientas para inter-
conectar dispositivos y aplicaciones de una forma agil y practica; en otras palabras permite
el despliegue de un ambiente interoperable donde los dispositivos no se ven restringidos por
su software o hardware. Por otra parte, se integra el sistema a una base de datos relacional
(MySQL), permitiendo la persistencia y gestion de la informacion.
Por ultimo, se evalua la solucion haciendo uso del estandar ISO/IEC 9126 con el objetivo
de verificar si cumple con sus requisitos de calidad. De esta evaluacion vale resaltar los
resultados obenidos en las caracterısticas Funcionalidad y Portabilidad, puesto que estan
estrechamente realacionadas con la interoperabilidad y la escalabilidad. MIOT Framework
permite la interconexion de dispositivos y aplicaciones al proveer 2 API bajo los protocolo
REST y MQTT. Por otra parte, la arquitectura orientada a servicios y la estructuracion
modular del sistema permiten que mas funcionalidades puedan ser integradas sin afectar su
funcionamiento. Ademas, MIOT puede ser desplegado y configurado facilmente, puesto que
su inicializacion se hace a traves de archivos de configuracion, lo que evita que el desarrollador
de aplicaciones deba revisar el codigo fuente para su puesta en marcha.
Sin lugar a dudas queda un camino largo que recorrer en el ambito de Internet de las Cosas,
puesto que es un paradigma con un auge reciente. Este trabajo tiene como aporte principal
una herramienta que permite desplegar un ambiente interoperable y escalable especıficamente
en aplicaciones de control en red. Ademas presenta el uso de arquitecturas de referencia y
su implementacion, sirviendo como arquetipo para la comunidad IoT.
6.2 Trabajo Futuro 45
6.2. Trabajo Futuro
Como trabajos futuros se proponen:
Validar MIOT implementando aplicaciones que tengan como objetivo estabilizar ciertos
fenomenos. Esto con el fın de evaluar su rendimiento, en aplicaciones donde el tiempo real
juega un papel crucial.
Extender el sistema haciendo uso de los dominios funcionales que no se utilizaron en este
trabajo. Con el objetivo de corroborar el uso total de IIFA.
Integrar mas protocolos de comunicacion que pueden ser usados por dispositivos IoT, tales
como CoAP o AMQP.
La seguridad en IoT es una lınea de investigacion extensa, por lo que se sugiere mejorar
este aspecto en MIOT, puesto que solo provee los mecanismos basicos de seguridad.
Bibliografıa
[Al-Fuqaha et al., 2015] Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M., and
Ayyash, M. (2015). Internet of things: A survey on enabling technologies, protocols, and
applications. IEEE Communications Surveys and Tutorials, pages 2347–2376.
[Babar et al., 2011] Babar, S., Stango, A., Prasad, N., Sen, J., and Prasad, R. (2011). Pro-
posed embedded security framework for internet of things (iot). Wireless Communication,
Vehicular Technology, Information Theory and Aerospace and Electronic Systems Tech-
nology (Wireless VITAE), pages 1–5.
[Baliga, 2005] Baliga, G. B. (2005). A middleware framework for networked control systems.
Tesis de doctorado, University of Illinois.
[Bemporad et al., 2010] Bemporad, A., Hemmels, M., and Johansson, M. (2010). Networked
control systems. Berlin : Springer, 406.
[Boman et al., 2014] Boman, J., Taylor, J., and Ngu, A. H. (2014). Flexible iot middle-
ware for integration of things and applications. Collaborative Computing: Networking,
Applications and Worksharing (CollaborateCom)), pages 481–488.
[Framework, 2018a] Framework, H. (2018a). http://hibernate.org/.
[Framework, 2018b] Framework, S. (2018b). https://spring.io/.
[Gusmeroli et al., 2012] Gusmeroli, S., Piccione, S., and Rotondi, D. (2012). Iot@ work au-
tomation middleware system design and architecture. Emerging Technologies and Factory
Automation (ETFA), pages 1–8.
[Hankel and Rexroth, 2015] Hankel, M. and Rexroth, B. (2015). The reference architectural
model industrie 4.0 (rami 4.0).
[Hernandez-Munoz and Munoz, 2013] Hernandez-Munoz, J. M. and Munoz, L. (2013). Iot@
work automation middleware system design and architecture. The Future Internet As-
sembly, pages 361–362.
[IIC, 2017] IIC, I. I. C. (2017). The industrial internet of things volume g1: Reference
architecture. Technical report.
Bibliografıa 47
[Jersey, 2017] Jersey, P. (2017). https://jersey.github.io/.
[Jin et al., 2014] Jin, J., Gubbi, J., Marusic, S., and Palaniswami, M. (2014). An information
framework for creating a smart city through internet of things. Internet of Things Journal,
pages 112–121.
[Katole et al., 2015] Katole, B., Suresh, V., Gosavi, G., Kudale, A., Thakare, G., Yendarga-
ye, G., and Kumar, C. P. (2015). The integrated middleware framework for heterogeneous
internet of things (iot). intelligence 4.
[Liu et al., 2013] Liu, Y., Yang, Y., Lv, X., and Wang, L. (2013). A self-learning sensor fault
detection framework for industry monitoring iot. Mathematical problems in engineering.
[Mattern and Floerkemeier, 2010] Mattern, F. and Floerkemeier, C. (2010). From the inter-
net of computers to the internet of things. From active data management to event-based
systems and more, pages 242–259.
[Mosquitto, 2018] Mosquitto, E. (2018). https://mosquitto.org/.
[Paho, 2018] Paho, E. (2018). https://www.eclipse.org/paho/.
[Project, 2018] Project, A. M. (2018). https://maven.apache.org/.
[Ray, 2014] Ray, P. P. (2014). Home health hub internet of things (h 3 iot):an architectural
framework for monitoring health of elderly people. Science Engineering and Management
Research (ICSEMR), pages 1–3.
[Razzaque et al., 2016] Razzaque, M. A., Milojevic-Jevric, M., Palade, A., and Clarke, S.
(2016). Middleware for internet of things: a survey. IEEE Internet of Things Journal,
pages 70–95.
[Sadiku et al., 2017] Sadiku, M. N., Wang, Y., Cui, S., and Musa, S. M. (2017). Industrial in-
ternet of things. International Journal of Advances in Scientific Research and Engineering
(IJASRE).
[Seitz et al., 2013] Seitz, L., Selander, G., and Gehrmann, C. (2013). Authorization fra-
mework for the internet-of-things. World of Wireless, Mobile and Multimedia Networks
(WoWMoM), pages 1–6.
[Teixeira et al., 2011] Teixeira, T., Hachem, S., Issarny, V., and Georgantas, N. (2011). Ser-
vice oriented middleware for the internet of things: A perspective. European Conference
on a Service-Based Internet, pages 220–229.
[Theodoridis et al., 2013] Theodoridis, E., Mylonas, G., and Chatzigiannakis, I. (2013). De-
veloping an iot smart city framework. Information, intelligence, systems and applications
(IISA)), pages 1–6.
48 Bibliografıa
[Valente and Martins, 2010] Valente, B. and Martins, F. (2010). A middleware framework
for the internet of things. Third International Conference on Advances in Future Internet,
pages 139–144.
[Zhiliang et al., 2011] Zhiliang, W., Yi, Y., Lu, W., and Wei, W. (2011). A soa based iot com-
munication middleware. Mechatronic science, electric engineering and computer (MEC),
pages 2555–2558.
[Zhou et al., 2013] Zhou, J., Leppanen, T., Harjula, E., Ylianttila, M., Ojala, T., Yu, C.,
Jin, H., and Yang, L. T. (2013). Cloudthings: A common architecture for integrating the
internet of things with cloud computing. Computer Supported Cooperative Work in Design
(CSCWD)), pages 651–657.