Arquitecturas IoT

La arquitectura tiene que cumplir ciertos requerimientos para que esta tecnología sea viable. Debe permitir que la tecnología sea distribuida, donde los objetos puedan interactuar entre ellos, escalable, flexible, robusta, eficiente y segura.

Requerimiento Arquitectura IoT

Requerimientos:

• Conectividad y comunicación
• Gestión y control de dispositivos
  • La posibilidad de desconectar un dispositivo robado
  • La habilidad de actualizar el software de un dispositivo
  • La actualización de credenciales de seguridad
  • Autorizar o denegar algunas capacidades del hardware remotamente
  • Localizar dispositivos perdidos
  • Limpiar información confidencial de un dispositivo robado
  • Reconfigurar parámetros de Wi-Fi, GPRS u otras redes remotamente.
• Recolección, análisis y actuación de los datos
• Escalabilidad
• Flexibilidad
• Alta disponibilidad
• Integración
• Seguridad
  • Riesgos inherentes de cualquier sistema de internet pero que los diseñadores IoT o de producto no tengan consciencia de ellos.
  • Riesgos específicos de los dispositivos IoT
  • Seguridad para cerciorarnos de que no se causan daños por, por ejemplo, por el mal uso de los actuadores.

Captación, análisis y actuación de la información: 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.

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.

Más información:

• https://programarfacil.com/podcast/arduino-wifi-proyectos-iot/
• https://www.chakray.com/5-requesitos-de-una-arquitectura-iot/

Modelo de Capas de Arquitectura IoT

Un modelo de IoT puede verse en este imagen.

En IoT se sigue una arquitectura por capas. Modelo de 7 capas de la arquitectura IoT:

La arquitectura describe la estructura de su solución de IoT, lo que incluye los aspectos físicos (esto es, las cosas) y los aspectos virtuales (como los servicios y los protocolos de comunicación). Adoptar una arquitectura con múltiples niveles le permite concentrarse en mejorar su comprensión acerca de cómo todos los aspectos más importantes de la arquitectura funcionan antes de que los integre dentro de su aplicación de IoT. Este enfoque modular le ayuda a gestionar la complejidad de las soluciones IoT.

Más información sobre arquitecturas IoT: https://www.ibm.com/developerworks/ssa/library/iot-lp201-iot-architectures/index.html

Este modelo de capas puede simplificarse para un modelo más sencillo. Arquitectura simple de tres capas:

O un modelo de 4 capas:

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

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

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)

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 MQTT y CoAP. 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 estandarización en el OASIS MQTT Technical Committee.

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

Capa de Agregación (Edge Computing)

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:

• El soporte de un servidor HTTP y/o un broker MQTT para hablar con los dispositivos.
• La agregación y combinación de comunicaciones de diferentes dispositivos y de enrutar las comunicaciones hacia un dispositivo especifico (posiblemente via un Gateway)
• 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

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.

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.

Componentes de la Arquitectura IoT

En términos sencillos, nuestra arquitectura de IoT contiene los siguientes componentes:

• Cosas equipadas con sensores para recoger datos y actuadores para realizar comandos recibidos desde la nube.
• Gateways para filtrar, preprocesar y mover datos a la nube y viceversa, – recibir comandos desde la nube.
• Pasarelas en nube (Cloud Gateways) para garantizar la transición de datos entre las pasarelas sobre el terreno y los servidores centrales de IoT.
• Procesadores de datos en tiempo real para distribuir los datos procedentes de los sensores entre los componentes de las soluciones de IoT pertinentes.
• Bases de Datos para almacenar todos los datos de valor definido e indefinido.
• Big Data Warehouse para la recogida de datos valiosos.
• Aplicaciones de control para enviar comandos a los actuadores.
• Machine Learning para generar los modelos que luego son utilizados por las aplicaciones de control.
• Aplicaciones de usuario que permiten a los usuarios monitorizar el control de sus cosas conectadas.
• Análisis de datos para el procesamiento manual de datos.

Más información sobre el modelo de capas de arquitectura IoT:

• Arquitecturas IoT por IBM: https://www.ibm.com/developerworks/ssa/library/iot-lp201-iot-architectures/index.html
• Buen resumen: https://www.scnsoft.com/blog/iot-architecture-in-a-nutshell-and-how-it-works
• Elementos IoT: https://www.iotcentral.io/blog/the-iot-architecture-at-the-edge
• White paper que explica las capas: https://www.zemsania.com/recursos-zemsania/whitepapers/DTS/arquitecturaIoT.pdf
• 4 stages IoT: https://techbeacon.com/4-stages-iot-architecture

Fases en la integración IoT

Fase 1: Conexión. En primer lugar, los objetos conectados en red con sensores inteligentes empiezan a enviar información sobre sí mismos y su entorno a su centro de comunicaciones central en la nube. Conectar cosas (darles sentido y abrirles una conexión a Internet para que puedan enviarles sus datos) representa el comienzo de la evolución del IoT. La mayoría de las plataformas de IoT se ganan la vida asegurándose de que sus cosas puedan hacerlo con seguridad.

Fase 2: Análisis y Visualización. A continuación, a medida que los datos de tus cosas se acumulan y tienes tantos que empiezas a llamarlos «grandes», agregas, exploras y empiezas a ejecutar análisis inteligentes en tus pilas de datos y visualizas los resultados en los dashboards. Esta es la segunda etapa en la evolución de IoT, cuando aprendes cosas nuevas importantes sobre tus sistemas de cosas conectadas.

Fase 3: Automatización. Ahora que has aprendido algo, empiezas a pensar en aplicar lo que has aprendido a tus procesos existentes, para que finalmente puedas cosechar los beneficios de IoT en su tercera gran etapa evolutiva: la automatización.

Más información:

• https://www.cloudmaitre.com/emerging-technologies/the-3-stages-of-evolution-of-iot-architecture
• https://blog.waylay.io/iot-platform-evolution/

Ejemplo de Fases en la Industria (IIoT)

Fase Inicial: Máquina sin acceso a la máquina (no hay comunicaciones)

Fase 1: Acceso remoto a la máquina. Conexión

Fase 2: Adquisición de datos, monitorización y notificaciones de alarmas

Fase 3: Advanced analytics, diagnóstico y reporting

Fase 4: Integración con SW corporativo

Fase 5: Automatización

Inicialmente se conecta la máquina a Internet o intranet. Mediante un gateway entre los buses de campo e internet mediante 3G, WiFi, ethernet, etc… De esta forma se visualiza remotamente lo que está pasando en la fábrica.

Luego se puede conectar a la nube con una solución como talk2M que se conecta mediante openVPN. Más información https://ewon.biz/es/cloud-services/talk2m

Talk2M tiene funcionalidades de HTTP e incluso aplicaciones externas podría acceder al Talk2M para coger dato mediante una API. Talk2M se podría implementar con una Raspberry Pi.

El gateway se conecta al PLC y captura datos de él mediante diversos protocolos para luego mandarlos a la nube y de una forma transparente sin tener que modificar parámetros al PLC. Simplemente leyendo del bus. Por ejemplo https://ewon.biz/products/ewon-flexy y con las tarjetas de conexión https://ewon.biz/ewon-product/flexy-extensions

En lugar de estos elementos puedo usar Arduino ¡CON ARDUINO TENGO TODO TIPO DE CONEXIONES!, además en Arduino se puede hacer un preprocesamiento de los datos.

Anuncio publicitario