Estructuras y transportes:elección de la mejor solución de conectividad IIoT
Construir una infraestructura de sistema distribuido en el panorama emergente de Internet de las cosas industrial (IIoT) de hoy puede ser una tarea abrumadora, por decir lo menos. Si es un desarrollador o arquitecto de sistemas, sabe que hay muchas herramientas y protocolos disponibles para usar para mover datos en su aplicación distribuida. Sin mencionar la posibilidad de crear su propia solución personalizada directamente en sockets TCP o UDP. ¿No sería fantástico si gran parte del trabajo que tenía que hacerse antes de poder tomar una decisión sobre su próxima infraestructura ya estuviera hecho por usted?
¿Sabes que? El trabajo se ha realizado y ahora está disponible para ayudarlo a tomar esa decisión. Debe preguntarse:"¿Quién hizo toda esta investigación y está sesgada por alguna empresa que busca vender su propia solución?" La buena noticia es que la investigación fue completada por un consorcio independiente, el Industrial Internet Consortium (IIC). Se llevó a cabo de manera imparcial y neutral con respecto al proveedor, y la información resultante ahora está disponible para usted.
Descargo de responsabilidad completo:Sí, trabajo para una empresa que proporciona una infraestructura para Internet industrial, pero de ninguna manera estoy diciendo que nuestra solución es la mejor solución. La verdadera respuesta a la pregunta "¿Cuál es la mejor solución?" es, "Depende".
La respuesta depende de lo que necesite de una solución de infraestructura:
- ¿Solo necesita enviar bytes de datos del punto A al punto B?
- ¿Necesita que los datos se entreguen de manera confiable?
- ¿Necesita algún conocimiento centrado en los datos para que la infraestructura pueda proporcionar algunas decisiones de entrega eficientes para una solución más inteligente?
- ¿Qué parte del manejo de datos desea transferir a la infraestructura?
Las respuestas a estas preguntas críticas, y muchas más, son las que investigo en este artículo. Al final de esta publicación, es de esperar que tenga la información que necesita para tomar una decisión informada sobre cuál es la mejor solución para su aplicación única.
Acerca del Consorcio de Internet Industrial (IIC)
La CII fue formada en 2014 por algunos actores muy importantes en el panorama de Internet industrial. Las empresas fundadoras (Cisco, Intel, AT&T, IBM y GE) se propusieron crear una organización centrada únicamente en las necesidades de las aplicaciones de Internet industrial. Ahora, el consorcio está formado por más de 250 empresas, tanto grandes como pequeñas. Los resultados de este consorcio incluyen un conjunto de documentos que describen las necesidades y las posibles soluciones para este tipo de aplicaciones de Internet industrial. El documento IIC Industrial Internet Connectivity Framework (IICF), un documento de orientación, es perfecto para ayudarlo a determinar la mejor solución para ejemplos basados en el mercado. Además de varios documentos, también han establecido bancos de pruebas que se utilizarán para demostrar la capacidad de varias tecnologías para cumplir con varios ejemplos del mercado del mundo real. La información sobre los documentos disponibles y los bancos de pruebas basados en el mercado se puede encontrar en el sitio web de la CII.
Entrega de datos:transportes y estructuras
Hay muchas soluciones disponibles en la actualidad para obtener datos entre aplicaciones. En el documento del IICF, estas soluciones se desglosan en dos categorías:transportes y marcos. Echemos un vistazo a estos dos tipos de soluciones de transferencia de datos para ver dónde encajan en la pila general de capas de conectividad. La Figura 1 a continuación muestra esta pila de conectividad.
Figura 1. Pila de marco de conectividad de la CII
Casi todos los que leen este documento han visto una pila de conectividad como esta, pero la pila de la IIC tiene una distinción clara:las capas de transporte y marco.
Por lo general, tendemos a agrupar todas las soluciones que ve en las categorías de transporte y marco juntas, pero hay una gran diferencia entre un transporte y un marco. Un transporte se utiliza para entregar datos desde el punto A al punto B, mientras que un marco básicamente aprovecha la capacidad de un transporte al tiempo que proporciona un sistema de tipos de datos para la interoperabilidad. En pocas palabras, cuando se usa solo un transporte, la aplicación debe formular los datos en un búfer genérico para entregarlos al transporte. Sin embargo, con un marco, la aplicación solo necesita transferir los datos al marco, y el marco se encargará de construir un búfer para que el transporte subyacente siga adelante y envíe sus datos. Trabajar a nivel de datos para una aplicación tiene muchos beneficios para las aplicaciones que brindan capacidades como el filtrado y el descubrimiento de contenido, mientras que si su aplicación solo usa algo en la capa de transporte, depende de la aplicación implementar el descubrimiento y el filtrado si es necesario. La Tabla 1 le brinda todas las capacidades que están disponibles en cada capa de transporte o marco.
Tabla 1. Capacidades de transporte y marco
¿Puede crear una aplicación de Internet industrial distribuida utilizando un transporte? Si. ¿Puede crear una aplicación de Internet industrial distribuida utilizando un marco? Si. ¿Es uno mejor que el otro? La verdadera respuesta es:"Depende". Depende de los requisitos de su aplicación en cuanto a qué solución se adapta mejor a su infraestructura. El resto de esta publicación pasará por varios de estos marcos y transportes para que pueda decidir cuál es la tecnología adecuada para su aplicación.
Transportes
Hay muchas soluciones disponibles en la actualidad para obtener datos entre aplicaciones. En el IICF, se denominan transportes que aprovechan las interfaces de socket IP estándar de UDP o TCP. Si su aplicación necesita una transferencia de datos confiable, entonces un desarrollador elegiría TCP por sus capacidades orientadas a la conexión y sus mecanismos confiables. Para una conexión más simple y una transferencia de datos no confiable, entonces se elegiría UDP por su facilidad de uso y entrega de multidifusión. Durante años, la mayoría de las aplicaciones de red utilizaron estas interfaces básicas para enviar y recibir datos. Todas las capacidades proporcionadas por los transportes de capa superior (enumeradas en la Tabla 1) tendrían que construirse directamente, dentro de la aplicación. Al observar los transportes de capa superior de DDS-RTPS, CoAP, MQTT, HTTP y OPC-UA Bin, realmente solo veremos los detalles para CoAP y MQTT. Los transportes DDS-RTPS, HTTP y OPC-UA Bin están básicamente vinculados directamente a los marcos por encima de ellos de DDS, Web Services y OPC-UA respectivamente. Las capacidades de estos transportes se discutirán como parte de la discusión marco que sigue.
MQTT
Echemos un vistazo al transporte de telemetría de Message Queue Server (MQTT). Nuevamente, MQTT se incluye aquí como un transporte porque no aplica ni implementa un modelo de datos para las aplicaciones. Solo proporciona un búfer en el que las aplicaciones deben formular sus datos para enviar y recibir. Su propósito principal para el que fue creado se enumera a la derecha en su nombre:Telemetría. Tener un dispositivo o aplicación en el campo se conecta y reporta datos a una nube de back-end o una ubicación de procesamiento fuera del sitio. Este transporte es ideal para cosas como una puerta de enlace de IoT doméstica o el administrador de un conjunto de dispositivos implementados. La arquitectura principal de MQTT está basada en intermediarios, como se puede ver en la Figura 2.
Figura 2. Arquitectura del agente de MQTTEn esta arquitectura, todos los clientes remotos envían sus datos al corredor de MQTT, y el corredor es responsable de enviar sus datos a cualquier cliente que haya solicitado esos datos. Esta arquitectura basada en intermediarios facilita el envío y la recepción de datos de una manera débilmente acoplada, pero no se presta para admitir aplicaciones industriales altamente deterministas y de baja latencia. Como transporte, MQTT tiene un lugar en el panorama general de las aplicaciones industriales distribuidas. La siguiente es una herramienta que puede usar para determinar si MQTT es algo que debe usar para su proyecto actual o próximo. Aquí hay cinco preguntas de "sí" o "no" para usted. Si su respuesta a tres o más de estas preguntas es "sí", entonces MQTT es la opción correcta para usted.
Preguntas MQTT
- ¿Considera su aplicación como una recopilación de datos?
- ¿Hay poca comunicación entre dispositivos?
- ¿No se tiene en cuenta la interoperabilidad?
- ¿Tiene muchos dispositivos pequeños?
- ¿Es el software un desafío menor?
MQTT es el único transporte enumerado en el documento IICF que no está realmente vinculado a un marco de capa superior. Esta es la razón por la que lo dividimos por separado como transporte. Ahora, echemos un vistazo a los marcos enumerados en el documento de la CII.
Marcos
Como se mencionó anteriormente, la diferencia distintiva entre un marco
Tecnología de Internet de las cosas
- Tres consideraciones fundamentales para elegir la mejor solución de seguimiento de activos
- Los beneficios de adaptar IIoT y soluciones de análisis de datos para EHS
- Perspectivas para el desarrollo de IoT industrial
- Hiperconvergencia e Internet de las cosas:Parte 1
- ¿El IoT y la computación en la nube son el futuro de los datos?
- El futuro de la integración de datos en 2022 y más allá
- Tendencias de IIoT y desafíos a seguir
- ¿La computación perimetral y el IIoT están cambiando la forma en que pensamos sobre los datos?
- IIoT y análisis predictivo
- Únase a la revolución de la banca abierta y las finanzas abiertas
- 5G y el desafío del crecimiento exponencial de datos