Middleware Framework IoT para el Desarrollo de ...biblioteca.utb.edu.co/notas/tesis/0073343.pdf ·...

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


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.


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:


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.


Figura 2-4: Patron arquitectural de 3 niveles.

Figura 2-5: Patron arquitectural de administracion y conectividad de borde mediada por

gateway.


Figura 2-6: Patron arquitectural de DATABUS en capas.


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.


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.


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


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:


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


users/{userName}/apps

Usado para crear una nueva aplicacion.

Ejemplo:

URI: miot/webapi/users/user/apps

Body:


{

"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:


{

"deviceName":"Device 1"

}

SENSORES:

GET

users/{userName}/apps/{tokenApp}/devices/{tokenDevice}/sensors/{sensorToken}


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:


{

"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:


c74eaf0129254ea4a484c8f76bc16ad0/actuators

Body:


{

"sensorName":"Actuator 1"

}


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:


c74eaf0129254ea4a484c8f76bc16ad0/sensors/ba935c5e2e194962be7af9c8777390dd/sv

Body:


{

"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:



c74eaf0129254ea4a484c8f76bc16ad0/actuators/ba935c5e2e194962be7af9c8777390dd/av

Body:


{

"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




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.


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 %


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


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.


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.

Middleware Framework IoT para el Desarrollo de ...biblioteca.utb.edu.co/notas/tesis/0073343.pdf ·...

Documents

Transcript of Middleware Framework IoT para el Desarrollo de ...biblioteca.utb.edu.co/notas/tesis/0073343.pdf ·...