ARQUITECTURA DE REFERENCIA EN EL …€¦ · Arquitectura ferencia n l nternet f hings unqu 2016 WhitePaper Índice ... Los protocolos, como HTTP, tienen un papel importante en muchos

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

Whi

tePa

per

ARQUITECTURA DE REFERENCIA EN EL INTERNET OF THINGSpor Adam Barberà BeltránSpecialist Consultor IoT en SUNQU


Whi

tePa

per

Índice

IntroducciónInternet of Things – Overview ¿Hay valor en una arquitectura de referencia para IoT? Requerimientos para una arquitectura de referencia Comunicaciones y conectividad Control y gestión de los dispositivos Captación, análisis y actuación de la información Escalabilidad SeguridadLa arquitectura Capa de dispositivos Capa de comunicaciones Capa de agregación/Bus Capa de procesamiento de eventos y analítica Capa de comunicaciones externas/clientes Device Management Control de acceso e identidadesConclusiones

347899

101111141516192021222324


Whi

tePa

per

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


Whi

tePa

per

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


Whi

tePa

per

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.

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

Whi

tePa

per


Whi

tePa

per

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


Whi

tePa

per

El siguiente esquema muestra los dos modos de conectividad más comunes.

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.


Whi

tePa

per

• 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 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


Whi

tePa

per

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 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?


Whi

tePa

per

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

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.


Whi

tePa

per

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


Whi

tePa

per

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.

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

Whi

tePa

per


Whi

tePa

per

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

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


Whi

tePa

per

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.

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


Whi

tePa

per

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:

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


Whi

tePa

per

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


Whi

tePa

per

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

Whi

tePa

per


Whi

tePa

per

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.

Whi

tePa

per


Whi

tePa

per

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


Whi

tePa

per

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.

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.


Whi

tePa

per

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

Whi

tePa

per


Whi

tePa

per

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


Whi

tePa

per

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


Whi

tePa

per

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


Whi

tePa

per

Documents

ARQUITECTURA DE REFERENCIA EN EL …€¦ · Arquitectura ferencia n l nternet f hings unqu 2016 WhitePaper Índice ... Los protocolos, como HTTP, tienen un papel importante en muchos