ARQUITECTURA

DE REFERENCIA
EN EL
INTERNET OF THINGS
WhitePaper

por Adam Barberà Beltrán

Specialist Consultor IoT en SUNQU

1
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Índice

Introducción 3
Internet of Things – Overview 4
¿Hay valor en una arquitectura de referencia para IoT? 7
Requerimientos para una arquitectura de referencia 8
Comunicaciones y conectividad 9
Control y gestión de los dispositivos 9
Captación, análisis y actuación de la información 10
Escalabilidad 11
Seguridad 11
La arquitectura 14
WhitePaper

Capa de dispositivos 15
Capa de comunicaciones 16
Capa de agregación/Bus 19
Capa de procesamiento de eventos y analítica 20
Capa de comunicaciones externas/clientes 21
Device Management 22
Control de acceso e identidades 23
Conclusiones 24

2
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Introducción

IoT es un término que incluye diferentes categorías:

• Redes de sensores/actuadores inalámbricos

• Wearables conectados a internet
• Sistemas embedded low power
• Tracking con dispositivos RFID
• Smartphones que interactúan con el mundo real
• Dispositivos con Bluetooth conectados a Internet
• Smart homes
• Connected cars

Después de ver estos ejemplos, tenemos claro que no existe una única arquitectura
WhitePaper

que pueda ajustarse a todas las áreas y a sus requerimientos. Lo ideal sería una
arquitectura escalable y modular que pudiera suportar, añadir o quitar bloques
según las necesidades. Esta soportaría una gran variedad de casos de uso y de sus
requerimientos, lo cual supondría un punto de partida para crear soluciones IoT
con una buena base para un posterior desarrollo.

En este White Paper hablaremos de la llamada Arquitectura de Referencia, que tiene

en cuenta todos los aspectos relacionados (incluyendo el cloud y una arquitectura
server-side) que permiten:

• Monitorizar, gestionar, interactuar y procesar los datos de los dispositivos IoT

• El modelo de networking para comunicar con los dispositivos
• Los agentes y el código en los mismos dispositivos
• Los requerimientos sobre qué tipo de dispositivos son compatibles o soportan
esta arquitectura de referencia.

3
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 La arquitectura que proponemos es agnóstica a cualquier proveedor y/o
tecnología, aunque sí que está influenciada en gran parte por los mejores
proyectos y tecnologías Open Source. Además, proporcionamos un mapping de
esta arquitectura con las tecnologías que más usamos (WSO2 y RedHat) y que se
han implementado y probado en múltiples escenarios.

También exploramos nuevas áreas donde esta arquitectura podría ser extendida,
como también áreas dónde pronto veremos una gran inversión.

Internet of Things – Un Resumen

Cuando hablamos del Internet de las cosas (Internet of Things, IoT), nos referimos
a una serie de dispositivos y sistemas que interconectan los sensores y actuadores
WhitePaper

del mundo real a Internet para virtualizarlos. Esto incluye diferentes sistemas,
como:

• Coches conectados a Internet

• Wearables, incluyendo dispositivos de salud y fitness, relojes, y dispositivos
implantados en humanos.
• Medidores y objetos inertes en general, que se dotan de inteligencia
• Sistemas de automatización y control para inmuebles e iluminación
• Smartphones
• Redes de sensores inalámbricos que captan información del tiempo, barreras
anti-inundaciones, mareas y muchas otras aplicaciones.

4
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 El crecimiento en número y variedad de dispositivos que están captando datos ha
crecido exponencialmente en muy poco tiempo. Un estudio de Cisco1 estima que
el número de dispositivos conectados sobrepasó a la población total mundial en
2010, y que habrá 50 billones de dispositivos conectados en 2020.

Cuando hablamos de IoT, existen dos aspectos clave que solemos destacar: Los
propios dispositivos y la arquitectura server-side que los soporta. De hecho,
también podríamos decir que hay un tercer aspecto clave, y es que en muchos
casos habrá una Gateway de bajo consumo que realiza la colección de datos y que
se encuentra entre los dispositivos conectados y la red de Internet.

En ambos casos, los dispositivos probablemente tengan conexiones intermitentes

causados por factores como la conectividad GPRS, el consumo de batería,
interferencias de radio, o simplemente que se han desconectado.
WhitePaper

1
https:// www.cisco.com/web/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf

5
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Hay tres clases de dispositivos IoT:

• Los dispositivos más pequeños son los controladores embedded de 8 bits

System-On-Chip (SOC). Un buen ejemplo de este Open Source hardware es
Arduino. Por ejemplo: Arduino Uno platform, este tipo no suelen llevar sistema
operativo (SO).
• El siguiente nivel son los dispositivos con una arquitectura de 32 bits como los
chips de Atheros y ARM. Muchas veces incluyen pequeños routers domésticos y
derivados de estos. Normalmente estos dispositivos se basan en plataformas de
Linux embedded, como OpenWRT u otros sistemas operativos embedded. En
algunos casos, no corren ningún SO. Por ejemplo: Arduino Zero o Arduino Yun.
• Las plataformas IoT con más capacidad son los sistemas completos de 32 y 64
bits. Estos sistemas, como Raspberry Pi o BeagleBone, pueden correr varios
SO como Linux o Android. En muchos casos, estos son Smartphone o algún
WhitePaper

tipo de dispositivo basado en tecnologías móviles. Estos dispositivos pueden

comportarse como Gateways o puentes para dispositivos más pequeños. Por
ejemplo: un wearable que se conecta vía Bluetooth a un Smartphone o a una
Raspberry Pi, es típicamente un puente para conectarse a Internet.

La comunicación entre dispositivos e Internet o a una Gateway se basa en tres

modelos diferentes:

• Conexión Ethernet o WiFi con protocolos TCP o UDP.

• Bluetooth
• Near Field Communication (NFC)
• Zigbee u otras redes mesh de radio
• SRF y enlaces radio punto a punto
• UART o serial lines
• Bus cable SPI o I2C

6
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 El siguiente esquema muestra los dos modos de conectividad más comunes.
WhitePaper

En esta sección hemos hecho un resumen de los dispositivos y sistemas IoT. Con la
información que hemos proporcionado, podremos entender los requerimientos y
capacidades que se plantean más adelante.

¿Hay valor en una arquitectura de referencia para IoT?

A continuación detallamos las razones por las cuales consideramos positiva una
arquitectura de referencia para IoT:

• Los dispositivos IoT son completamente inertes. Necesitamos alguna vía para
interactuar con ellos, aunque muchas veces con obstáculos en el camino, como
firewalls, network address translation (NAT) y otros dispositivos, que nos dificultaran
esta interacción.

7
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 • Ya hay billones de dispositivos y crecen exponencialmente en número. Necesitamos
una arquitectura escalable. Además, estos dispositivos están activos las 24 horas
del día, por lo que necesitamos una alta disponibilidad que soporte el despliegue a
través de los data centers y que nos permita la recuperación de desastres (Disaster
Recovery).
• Puede que los dispositivos no tengan UI (User Interface) y se hayan diseñado para
un uso diario. Por lo tanto, necesitamos poder gestionar de manera automática las
actualizaciones y también controlarlos remotamente.
• Los dispositivos IoT, mayoritariamente, se usan para recolectar y analizar información
personal. Esto nos lleva a pensar en un modelo para controlar y gestionar la
identidad y el acceso a los dispositivos, incluyendo los datos que se publican y se
consumen.

Nuestro principal objetivo es proporcionar una arquitectura que soporta la integración

WhitePaper

entre sistemas y dispositivos. En la siguiente sección hablaremos en detallo de los

requerimientos y de las cuestiones específicas para ciertas categorías.

Requerimientos para una arquitectura de referencia

Hay ciertos requerimientos para IoT que se encuentran de forma específica en

los dispositivos IoT y en los ecosistemas que los soportan. Por ejemplo, muchos
requerimientos vienen dados por las limitaciones del factor de forma y de la alimentación
de los dispositivos. Otros requerimientos vienen por la parte de la fabricación y su uso.
También hay, por supuesto, numerosas “Mejores Prácticas” para el server-side y la
conectividad a Internet que deben tenerse en cuenta.

Se pueden resumir los requerimientos en categorías clave:

• Comunicaciones y conectividad
• Gestión y control de dispositivos
• Captación, análisis y actuación de la información
• Escalabilidad
• Alta disponibilidad
• Análisis predictivo
• Integración

8
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Comunicaciones y conectividad

Los protocolos, como HTTP, tienen un papel importante en muchos dispositivos. Incluso
un microcontrolador de 8 bits puede crear un simple GET y/o POST. Pero el consumo de
HTTP y/u otros protocolos tradicionales de Internet pueden llegar a ser un problema por
dos razones principales. Para empezar, el tamaño del programa puede ser un problema
en dispositivos pequeños, además de que los mayores problemas acostumbran a ser de
consumo. Para poder cumplir las especificaciones necesarias necesitamos un protocolo
simple, pequeño y binario en el cual entraremos en detalle más adelante. También es
importante y necesario el poder cruzar los firewalls.

Además de lo mencionado, hay dispositivos que se conectan directamente y otros a

través de Gateway. Los dispositivos que usan Gateway como pasarela necesitan dos
protocolos: Uno para conectar el dispositivo a la Gateway y otro para conectarse de la
WhitePaper

Gateway al Cloud.

Obviamente, vemos que hay una necesidad en nuestra arquitectura para soportar el
bridging. Por ejemplo, deberíamos poder ofrecer un protocolo binario al dispositivo,
pero a la vez también permitir el acceso a una API basada en HTTP para controlar el
dispositivo y que pueda ser usada por terceros.

Control y gestión de los dispositivos

Hemos visto que la gestión activa de PCs, smartphones, y otros dispositivos ha llegado a
ser casi imprescindible, por lo que podemos pensar que a los dispositivos IoT les espera
la misma trayectoria. ¿Cuáles serían los requerimientos para la gestión de dispositivos
IoT?

9
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 La siguiente lista cubre algunos de los más deseados:

• La posibilidad de desconectar un dispositivo malicioso o robado

• La posibilidad de actualizar el software del dispositivo
• Actualizaciones de las credenciales de seguridad
• Habilitar o deshabilitar ciertas opciones de hardware
• Localizar un dispositivo perdido
• Eliminar la información de un dispositivo robado
• Re-configurar la configuración de red remotamente

La lista propuesta no es imperativa y también puede que cubra aspectos que en ciertos
dispositivos no sean necesarios o posibles.

Captación, análisis y actuación de la información

WhitePaper

Algunos dispositivos disponen de algún tipo de UI, pero en general los dispositivos IoT
se centran en ofrecer uno o más sensores, uno o más actuadores, o la combinación de
los dos. Los requerimientos de los sistemas son: poder captar datos de un gran número
de dispositivos, almacenarlos, analizarlos, y actuar sobre ellos.

La arquitectura de referencia se ha diseñado para poder gestionar un gran número de

dispositivos. Si estos dispositivos están constantemente enviando datos, esto genera
un volumen significativo de información. Este requerimiento se refiere a los sistemas
de almacenaje de información con una gran capacidad de escalabilidad, que soporta
diversos tipos y grandes volúmenes de datos.

Las acciones deberían ser en “casi tiempo real”, por lo que se requiere una gran
capacidad de análisis de la información en tiempo real, además de la habilidad de los
dispositivos de analizar y actuar en referencia a la información. En algunos casos será
simple, lógica embedded. Pero en dispositivos más potentes se pueden utilizar motores
de procesamiento para tratamiento de eventos y acciones.

10
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Escalabilidad

Cualquier arquitectura server-side es escalable y puede soportar millones de dispositivos

enviando, recibiendo y actuando constantemente con los datos. Pero por otro lado,
muchas de estas arquitecturas vienen con un precio muy elevado, tanto en hardware
como en software y complejidad. Uno de los requerimientos más importantes es la
capacidad de soportar la escalabilidad desde pequeños despliegues hasta volúmenes
masivos de dispositivos, por eso la flexibilidad de la escalabilidad y la habilidad de
desplegarla en una infraestructura Cloud son esenciales.

Seguridad

La seguridad es uno de los aspectos más importantes en IoT. Los dispositivos están
WhitePaper

constantemente captando información personal y, por su naturaleza, llevando el mundo

real a Internet y vice-versa. Esto nos lleva a percibir tres categorías de riesgos entorno
la seguridad:

• Riesgos propios de Internet, aunque los diseñadores del producto no sean

conscientes de ello.
• Riesgos específicos de los dispositivos IoT.
• Seguridad para asegurar que no se causa ningún daño, como por ejemplo el mal
uso de actuadores.
La primera categoría incluye cosas tan simples como cerrar los puertos del dispositivo,
mientras que la segunda categoría incluye problemática relacionada con el hardware.
Un ejemplo de brecha de seguridad podría ser la problemática relacionada con los
dispositivos pequeños, ya que en ocasiones no soportan una encriptación asimétrica.
Algunos ejemplos más específicos son la capacidad de alguien de atacar el propio
hardware para entender su seguridad.

Siguiendo con los ejemplos, podemos hablar del famoso caso de los investigadores de
una universidad que, con ingeniería inversa, consiguieron romper la Mifare Classic RFID
card solution2. Los ataques de ingeniería inversa son un problema comparados con
soluciones basadas puramente en web dónde a menudo no hay código al que atacar.

11
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Dos temas importantes sobre la seguridad en IoT son la gestión de la identidad y el
acceso. La identidad es un problema con el que a veces encontramos implementacio-
nes muy pobres. Por ejemplo, el uso de usuario/contraseña codificado en base64 con
dispositivos y machine-to-machine (M2M) es un error muy común. Idealmente, esto
debería ser reemplazado por token gestionados como los proporcionados por OAuth/
OAuth23.
WhitePaper

2
https:// www.cisco.com/web/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf

12
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Otro tema común es el hard-coding de las reglas de control de acceso en el código
del cliente o el servidor. Un enfoque más flexible y potente es la utilización de modelos
como “Attribute Based Access Control” (Contro de acceso basado en atributos) y “Policy
Based Access Control” (Control de acceso en políticas). Los mejores modelos, en
referencia al enfoque anterior, son los que proporciona XACML standard4. Estos eliminan
las decisiones sobre el control de acceso de la lógica hard-coded y la externalizan en
políticas, que se traducen en lo siguiente:

• Decisiones acertadas y apropiadas

• Potencialmente contextualizadas, como localización, uso de la red o día y/u hora
• El control de acceso puede ser auditado
• Las políticas pueden ser actualizadas o cambiadas, incluso dinámicamente, sin
necesidad de recodificar y/o modificar los dispositivos
WhitePaper

Nuestros requerimientos de seguridad deben soportar:

• Encriptación en los dispositivos, que son potencialmente capaces

• Un model de identidad basado en tokens y no usuario/password
• La gestión de claves y tokens de la manera más fluida remotamente posible
• Políticas y control de accesos a los sistemas basados en XACML

Esto concluye los requerimientos que hemos identificado para la arquitectura de

referencia. Aunque, por supuesto, cualquier otra arquitectura podría añadir más
requerimientos. Algunos ya se han contemplado y otros puede que requieran otros
componentes. De todos modos, nuestro diseño de una arquitectura modular soporta
múltiples extensiones que encajarían con la demanda.

3 http://oauth.net/
4 https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

13
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 La arquitectura

Esta arquitectura tiene diversos componentes. Las capas se pueden identificar como
tecnologías específicas, y plantearemos opciones para identificar cada componente.
También veremos capas que afectan tanto horizontal como verticalmente, como la
gestión de acceso e identidad.
WhitePaper

Las capas son:

• Comunicaciones externas – Portal web, dashboard y APIs

• Procesamiento y analítica de datos
• Agregación / Bus – ESB y message bróker
• Comunicaciones – MQTT/HTTP/XMPP/CoAP/AMQP, etc.
• Dispositivos

Las capas transversales son las siguientes:

• Device Manager
• Control de acceso e identidades

14
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Capa de dispositivos

La capa inferior de la arquitectura es la de dispositivos. Hay varios tipos de dispositivos,

pero para que se consideren dispositivos IoT deben tener algún tipo de comunicación,
directa o indirecta, que lo enlaza con Internet. Algunos ejemplos de conexión directa
son:

• Arduino con conexión Ethernet

• Arduino Yun con conexión WiFi
• Raspberry Pi conectado vía Ethernet o WiFi
• Intel Galileo conectada vía Ethernet o WiFi

Por otro lado, algunos ejemplos de conexión indirecta:

WhitePaper

• Dispositivos ZigBee conectados vía una Gateway

• Dispositivos Bluetooth o Bluetooth low energy conectados vía smartphones
• Dispositivos que se comunican con una Raspberry Pi vía low power radios.

En ambos casos hay muchos más ejemplos, aunque no se utilicen de forma frecuente.
Cada dispositivo necesita una identidad, la cual puede ser una de las siguientes:

• Un identificador único (Unique identifier, UUID) grabado en el dispositivo (típicamente

parte del System-on-Chip, o proporcionado por un segundo chip)
• Un UUID proporcionado por un subsistema radio (por ejemplo: identificador
Bluetooth, dirección MAC del WiFi)
• Un token refresh/bearer OAuth2 (puede ser un complemento a los dos anteriores)
• Un identificador guardado en memoria no volátil como una EEPROM

Para la arquitectura de referencia recomendamos que cada dispositivo tenga un

UUID (preferiblemente un ID proporcionado por el hardware core que no pueda ser
modificado), y que incluya un token refresh y bearer OAuth2 guardado en la EEPROM.

Las especificaciones están basadas en HTTP y, como comentaremos en la sección de

comunicaciones, la arquitectura también soporta los flujos sobre MQTT.

15
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Capa de comunicaciones

La capa de comunicaciones soporta la conectividad de los dispositivos. Hay múltiples

protocolos para la comunicación entre los dispositivos y el Cloud. Los tres protocolos
más conocidos y usados son:

• HTTP/HTTP (y RESTful sobre ellos)

• MQTT 3.1/3.1.1
• Constrained application protocol (CoAP)

Vamos a hacer una pequeña mención a estos protocolos.

HTTP es muy conocido y hay muchas librerías que lo soportan. Dado que es un protocolo
simple basado en texto, muchos dispositivos pequeños como los controladores de 8
WhitePaper

bits lo pueden soportar parcialmente (por ejemplo, sólo recursos como POST o GET).
Por otro lado, dispositivos con más capacidad como los de 32 bits, pueden utilizar
librerías con un cliente completo de HTTP, el cual puede implementar todo el protocolo.

Hay algunos protocolos optimizados para el uso en IoT, como MQTT5 y CoAP6. MQTT
fue inventado en 1999 para resolver los problemas en los sistemas embedded y
SCADA. Ha habido varias iteraciones pero la versión actual (v3.1.1) está bajo estandari-
zación en el OASIS MQTT Technical Committee7. MQTT es un sistema de mensajería
publish-subscription basado en un modelo bróker. El protocolo tiene una pequeña
cabecera (2 bytes por mensaje), y fue diseñado para trabajar en conexiones pobres y
con cortes intermitentes.

MQTT fue diseñado para correr sobre TCP. Además, existe MQTT-SN (Sensor networks)
una especificación diseñada para redes basadas en ZigBee.

CoAP es un protocolo del IETF (Internet Engineering Task Force8) que se ha diseñado
para proporcionar aplicaciones RESTful modeladas en la semántica de HTTP, pero más
pequeño y binario a diferencia del basado en texto. CoAP es un enfoque tradicional de
cliente-servidor en comparación al de brokers, diseñado para correr sobre UDP.

16
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Para la arquitectura de referencia hemos optado para seleccionar MQTT como principal
protocolo de comunicación contemplando HTTP como opción alternativa.
Las principales razones para haber seleccionado MQTT y no CoAP son:

• Mejor adopción y una amplia selección de librerías que soportan MQTT

• Puente simple para los sistemas existentes de colección y procesamiento de eventos
• Conectividad más simple sobre firewalls y redes NAT

De todos modos, los dos protocolos tienen fortalezas (y debilidades) específicas y por
eso puede que haya situaciones donde CoAP podría ser el mejor candidato y puedan
ser intercambiados.
Para soportar MQTT necesitamos un MQTT bróker en la arquitectura y las librerías
para el dispositivo. Hablaremos de esto mas adelante en referencia a seguridad y
escalabilidad.
WhitePaper

Un aspecto importante a tener en cuenta de los dispositivos IoT no es solamente el poder

enviar datos al Cloud/Servidor, sino también el poder comunicarse con el dispositivo, en
definitiva la bidireccionalidad. Este es uno de los beneficios de MQTT: es un modelo
brokered, el cliente abre una conexión de salida al bróker, aunque el dispositivo esté
actuando como Publisher o subscriber. Esto normalmente evita los problemas con los
firewalls porque funciona detrás de ellos o vía NAT.

En el caso de que la comunicación principal se base en HTTP, la solución tradicional

para enviar información al dispositivo seria HTTP Polling. Esto es ineficiente y tiene un
coste elevado en aspectos de tráfico y/o energía. Una manera más novedosa de hacerlo
sería con el protocolo WebSocket, que permite crear una conexión HTTP completa
bidireccional. Esto actúa de canal socket (parecido al canal típico TCP) entre el servidor
y el cliente. Una vez establecido, ya es trabajo del sistema escoger un protocolo para
hacer un túnel sobre la conexión.

5 http://mqtt.org/ 6 http://tools.ietf.org/html/draft-ietf-core-coap-18 7 https://www.oasis-open.org/committees/mqtt/

8 https://www.ietf.org/

17
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Una vez más, para la arquitectura de referencia, recomendamos usar como protocolo
MQTT con WebSockets. En algunos casos, MQTT sobre WebSockets será la única
opción. En estos casos es aún más firewall-friendly que la especificación MQTT
base, así como el soporte de los puros browser/JavaScript clients utilizando el mismo
protocolo.

Hay que tener en cuenta que mientras haya algún tipo de soporte para WebSockets
en pequeños controladores, como Arduino, la combinación de código de red, HTTP y
WebSockets, utilizará la mayoría del código disponible en un típico Arduino de 8 bits.
Por lo tanto, recomendamos que se utilicen WebSockets solo en dispositivos de 32 bits.
WhitePaper

18
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Capa de agregación/Bus

Una capa importante de la arquitectura es la que agrega y hace de bróker de

comunicaciones. Hay tres principales razones por las cuales es importante:

1. El soporte de un servidor HTTP y/o un broker MQTT para hablar con los dispositivos.
2. La agregación y combinación de comunicaciones de diferentes dispositivos y de
enrutar las comunicaciones hacia un dispositivo especifico (posiblemente via un
Gateway)
3. La habilidad de hacer un puente y transformar diferentes protocolos. Por ejemplo:
ofrecer APIs basadas en HTTP que interceden un mensaje MQTT que va a un
dispositivo.

Esta capa proporciona las anteriores capacidades mencionadas así como la adaptación
WhitePaper

en protocolos legacy. La capa del bus puede proporcionar correlaciones y mapeos

simples de diferentes modelos de correlación (por ejemplo; mapear el ID del dispositivo
con el ID del propietario de este o viceversa).

Finalmente, la capa de agregación/bus necesita desarrollar dos roles de seguridad

claves. Debe ser capaz de actuar como un recurso de servidor OAuth2 (validando el
portador de tokens y asociando los recursos de acceso). También debería ser capaz
de actuar como policy enforcement point (PEP) para las políticas de acceso. En este
modelo, el bus hace peticiones a la capa que gestiona las identidades y los accesos
para validar las peticiones. La capa de gestión de acceso e identidad actúa como policy
decision point (PDP). La capa del bus implementa los resultados de las peticiones al
PDP para permitir o denegar el acceso de los recursos.

19
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Capa de procesamiento de eventos y analítica

Esta capa coge los eventos del bus y proporciona la posibilidad de procesarlos y
actuar sobre estos. Una capacidad esencial es la de guardar los datos en BBDD. Hay
tres posibles maneras de hacerlo. 1) El modelo tradicional, el cual sería una aplicación
server-side (por ejemplo, podría ser una aplicación JAX-RS respaldada por una base
de datos; aun así, hay otras dos posibilidades donde podemos soportar planteamientos
más ágiles). 2) Usar una plataforma de big data analytics, ya que es cloud y escalable
y, además, soporta tecnologías como Apache Hadoop para proporcionar soluciones
altamente escalables de mapreduce analytics para poder tratar la información que
proviene de los dispositivos. 3) Por otro lado, otra manera es el procesamiento de
eventos complejos para soportar actividades de casi tiempo real y acciones basadas en
la información de los dispositivos y del sistema.
WhitePaper

Nuestra recomendación es seguir las siguientes directrices:

• Alta escalabilidad, almacenaje de datos basado en columnas para guardar eventos

• Map-reduce para el procesamiento de datos orientados a batch de largo recorrido.
• Procesamiento de eventos complejos para el procesado en memoria y la actuación
en casi tiempo real. Acciones automáticas basadas en la actividad de los dispositivos
y los sistemas.
• Además, esta capa permite aplicaciones de procesamiento tradicionales, como
Java Beans, JAX-RS logic, message-driven beans, o alternativas como node.js, PHP,
Ruby o Python.

20
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Capa de comunicaciones externas/clientes

La arquitectura de referencia debe proporcionar alguna vía de comunicación para

aquellos dispositivos que son externos al sistema. A continuación se describen tres
líneas a tener en cuenta. Primero, debemos poder crear portales y front ends web
para interactuar con los dispositivos y con la capa de procesamiento de eventos. A
continuación, debemos ser capaces de crear dashboards para mostrar las analíticas y
los eventos. Finalmente, necesitamos interactuar con los sistemas que se encuentran
fuera de nuestra red basándonos en comunicaciones machine-to-machine (M2M) y el
uso de APIs. Estas deben estar controladas y gestionadas, y para ello podemos utilizar
el sistema de API management.

El principal consejo para construir un front end web es utilizar una arquitectura front
end modular, como por ejemplo un portal, que permite composiciones de UIs (user
WhitePaper

interface) simples y rápidas. Por supuesto, no nos olvidamos de que la arquitectura

soporte tecnologías web server-side, como Java Servlets/JSP, PHP, Python, Ruby, etc.
Nuestra recomendación es utilizar Java framework y el servidor web Apache Tomcat.

El dashboard es un sistema reutilizable focalizado en crear gráficos y otro tipo de

visualización de datos que provienen de los dispositivos y de la capa de procesado de
eventos.

La capa de API management proporciona tres principales funciones:

• Proporciona un portal enfocado a los developers, donde pueden encontrar, explorar

y subscribirse a las APIs del sistema. También se contempla la publicación para
crear, versionar y gestionar las APIs disponibles.
• Una Gateway que gestiona es acceso a las APIs, realizando control de acceso (para
peticiones externas) además de regular el uso según las políticas definidas. También
realiza routing y balanceo de cargas.
• Esta Gateway publica la información en la capa de analítica donde se guarda y se
procesa, además de proporcionar insights del uso las APIs.

21
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Device Management

El Device management (DM) está formado por dos componentes. Un sistema

server-side (el device manager) que comunica con los dispositivos a través de varios
protocolos y proporciona el control de los dispositivos individualmente o en su conjunto.
También gestiona remotamente el despliegue de software y aplicaciones sobre los
dispositivos. Puede bloquear y/o formatear el dispositivo si fuera necesario. El device
manager funciona conjuntamente con los device management agents. Hay diferentes
agentes para diferentes tipos de plataformas y dispositivos.

El device manager también debe mantener la lista de IDs de los dispositivos mapeadas
con las IDs de los propietarios de estos. También trabaja con la capa de gestión de
accesos e identidades para controlar el acceso a los dispositivos (por ejemplo, quién
puede gestionar el dispositivo a parte de su propietario, qué control tiene el usuario vs el
WhitePaper

administrador, etc).

Hay tres niveles de dispositivos: No gestionado (non-managed, NM), semi gestionado

(semi-managed, SM) y completamente gestionado (fully managed, FM).

Los FM son aquellos que utilizan un agente DM completo. Estos soportan:

• Administrar el software del dispositivo

• Habilitar/deshabilitar features del dispositivo (por ejemplo, la cámara, hardware, etc).
• Gestión de controles e identificadores de seguridad
• Monitorización del estado del dispositivo
• Trazabilidad de la posición del dispositivo cuando sea posible
• Bloquear o borrar el dispositivo

Los dispositivos no gestionados pueden comunicarse con toda la red, pero no tienen
ningún agente involucrado. Esto incluye dispositivos de 8 bits en los cuales las reservas
son muy pequeñas para soportar el agente. El device manager pude guardar la
información de la disponibilidad y la localización del dispositivo cuando esté disponible.

Los semi gestionados son los que implementan alguna parte del DM, como por ejemplo
control, pero no software de administración.

22
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Control de acceso e identidades

La última capa es la de administración de acceso e identidades. Esta debe proporcionar

los siguientes servicios:

• Expedición y validación de tokens OAuth2

• Otros servicios de identidades incluyendo SAML2 SSO y OpenID Connect para
identificar peticiones entrantes de la capa web
• XACML PDP
• Directorio de usuarios (por ejemplo, LDAP)
• Políticas de administración para el control de accesos

La capa de identidades puede tener otros requerimientos específicos para otro tipo de
instancias de administración. En esta sección hemos descrito los componentes más
WhitePaper

relevantes de la arquitectura como también decisiones específicas que hemos tomado

sobre ciertas tecnologías. Estas decisiones vienen motivadas por los requerimientos
específicos de las arquitecturas IoT incluyendo las mejores prácticas para construir
arquitecturas de internet ágilmente, mantenibles y escalables. Sin duda, hay otras
opciones, pero esta arquitectura de referencia se basa en experiencias conocidas que
han resultado exitosas en proyectos reales de IoT en los cuales hemos trabajado.

23
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
 Conclusiones

En este Whitepaper hemos comentado los siguientes puntos:

• Nuestra definición de IoT

• Por qué tiene valor una arquitectura de referencia
• Los requerimientos de la arquitectura
• La instanciación de la arquitectura de referencia y cómo esta cumple con los
requerimientos

El universo IoT está evolucionando exponencialmente, y por eso esperamos que

las tecnologías propuestas en este paper lo hagan en sincronía con este universo.
No obstante, a pesar de la naturaleza emergente de este universo, este paper y
la arquitectura de referencia están basados en proyectos reales que soportan las
WhitePaper

necesidades del IoT.

Esperamos que sea útil, efectiva y fácilmente desplegable. Próximamente, habrá nuevas
release de papers relacionados con IoT y su ecosistema.

24
Arquitectura de referencia en el Internet of Things | Sunqu | 2016
WhitePaper

25
Arquitectura de referencia en el Internet of Things | Sunqu | 2016