Soluciones IIoT | 6 soluciones de comunicación de IoT industrial

Para decir que la tarea de seleccionar su IoT industrial ( IIoT ) la infraestructura de comunicaciones es una empresa muy compleja sería un eufemismo. La evaluación de la miríada de soluciones disponibles comercialmente requiere mucho tiempo y es costosa. Intente descargar y evaluar múltiples soluciones de cada tipo de infraestructura y rápidamente se encontrará en medio de un proyecto que a varios ingenieros les llevará unos buenos seis meses completar. Todos hemos estado allí y quiero ayudarlo a ahorrar un tiempo valioso.

El propósito de esta publicación es presentarle las populares soluciones de infraestructura IIoT que están disponibles comercialmente:AMQP, CoAP, DDS, RTI Connext DDS, MQTT y ZeroMQ, y destacar las capacidades de cada solución. Se aplicarán las siguientes seis áreas de evaluación:Arquitectura, Patrones de comunicación, Transportes, Tipo y filtrado de datos, Calidad de servicio y Seguridad.

Haga clic aquí para descargar la versión PDF imprimible.

1. Arquitectura

Dependiendo del patrón arquitectónico de una determinada infraestructura de comunicaciones, la conexión lógica (ilustrada en la Figura 1, a continuación) que utilizarán las aplicaciones para comunicarse con otras aplicaciones en toda la infraestructura varía. Las dos arquitecturas más básicas que se utilizan en las soluciones de middleware de hoy son (1) las arquitecturas punto a punto y (2) las arquitecturas estrella basadas en intermediarios.

1. Arquitecturas de igual a igual Permitir que las aplicaciones se comuniquen directamente entre sí sin tener que enviar datos a un elemento intermediario. Estas arquitecturas son intrínsecamente más eficientes en la entrega de datos, ya que solo las aplicaciones de envío y recepción gastan recursos de CPU para completar la transferencia. Por lo tanto, solo las aplicaciones que tienen los datos y las aplicaciones que necesitan los datos consumirán ciclos de CPU; por lo tanto, da como resultado una distribución eficiente del procesamiento en función de los requisitos de la aplicación. El otro beneficio de una arquitectura de igual a igual es que la entrega determinista de datos es mucho más alcanzable porque no hay un "intermediario" que maneje los datos entre las aplicaciones de productor y consumidor.

Figura 1. Diagramas arquitectónicos para los distintos protocolos de IoT.

2. Soluciones basadas en corredores requerir que todas las aplicaciones que están enviando datos transfieran los datos directamente al servidor del corredor, luego de lo cual se dará la vuelta y reenviará estos datos a las aplicaciones receptoras. El beneficio de esta arquitectura es que el intermediario gestiona toda la complejidad relacionada con el envío / recepción de datos. Por lo general, estas soluciones tienen herramientas integradas para ver exactamente qué rutas de datos están activas, quién envía datos y quién recibe datos. Las soluciones basadas en intermediarios introducen latencia en la entrega de datos y también presentan un único punto de falla, de modo que si el intermediario falla, todas las comunicaciones también fallan. Para resolver el problema del punto único de falla, la mayoría de estas implementaciones proporcionan servidores de intermediarios redundantes y de alta disponibilidad.

2. Patrones de comunicación

El soporte de patrones de comunicación es esencial para una infraestructura que puede utilizar durante todo el ciclo de vida de su proyecto o línea de productos. Es posible que el proyecto inicial solo requiera publicación / suscripción, pero los proyectos o productos posteriores pueden necesitar patrones adicionales como solicitud / respuesta o cola. En este aspecto, no todas las soluciones de IoT existentes disponibles en la actualidad pueden admitir todos los patrones necesarios que necesitará su proyecto. Para la tabla de comparación, identificamos los patrones más comunes que se utilizan en la actualidad y si cada solución de infraestructura proporciona ese patrón. Estos son los patrones más comunes que se utilizan en la actualidad:

• Publicar / Suscribirse :Una aplicación (suscriptor) solicita datos 1 vez y luego todas las actualizaciones subsiguientes de los datos se “envían” al suscriptor. No es necesario solicitar actualizaciones de datos continuamente.
• Solicitud / Respuesta / RPC ( Llamada a procedimiento remoto ):Una aplicación solicitante envía solicitudes y una aplicación contestadora responde a la solicitud.
• Cola ( o punto a punto ):Los datos se envían a un servidor que mantendrá la información en una cola. Luego, los datos pueden extraerse de la cola o enviarse a los consumidores. A diferencia de Publicar / Suscribir, cada dato se distribuye a una sola aplicación receptora.
• Uno a muchos :Posibilidad de que muchas aplicaciones receptoras obtengan los mismos datos de una sola fuente.
• Muchos a uno :Capacidad para recibir datos de muchas fuentes en una sola aplicación de consumo.

3. Transportes y rutas / puentes

La mayoría de las soluciones de middleware de comunicación admiten TCP como protocolo de comunicación principal. El uso de TCP le brinda una entrega confiable de datos mediante el mecanismo de confiabilidad incorporado inherente a TCP. Esto puede ser ideal para flujos de datos específicos que requieren confiabilidad, pero es excesivo y agrega una sobrecarga innecesaria a los datos de sensores simples que no requieren una entrega confiable. Algunas de las soluciones de IoT como ZeroMQ y DDS también admiten otros transportes, como la memoria compartida. Un transporte a destacar es el uso del transporte UDP para DDS. Debido a que la implementación de confiabilidad está integrada en DDS, no requiere un transporte confiable debajo. Esto permite que las aplicaciones seleccionen qué flujos de datos son de entrega confiable y qué flujos requieren el mejor esfuerzo.

El enrutamiento de datos entre transportes y a través de la WAN es algo que todas estas soluciones brindan de una forma u otra. En el mundo actual, donde los sistemas empresariales, que aprovechan las tecnologías ESB y Web, también deben acceder a algunos de los datos en tiempo real, es esencial que el middleware de comunicaciones también admita la conexión a estas tecnologías. Debido a esto, verá el enrutamiento y el puenteo como un componente central para el middleware del sistema distribuido.

4. Tipo de datos y filtrado

La forma en que se encapsulan y representan los datos en el cable también es exclusivo de la infraestructura dada. Algunas soluciones solo envían bytes de datos sin procesar, y depende de la aplicación serializar y deserializar los datos. Otros solo envían datos de texto / cadena para que la información se pueda representar en formato XML o JSON. Este escenario es muy común en las tecnologías web de hoy, pero puede ser muy ineficiente porque con cada envío de datos, el paquete también contiene la descripción de los datos, lo que a veces hace que el tamaño del paquete sea más de 3 veces mayor que su tamaño original. Los tamaños de paquete más grandes aumentan el uso del ancho de banda y aumentan el uso de la CPU tanto en el lado de envío como en el de recepción de la transferencia. Ponga un corredor en medio de eso y ahora también duplicará la cantidad de paquetes en el cable.

Otras soluciones, como DDS, permiten el uso de datos fuertemente tipados que el middleware serializa y deserializa de forma única. El esquema se envía por separado, lo que no es el caso de XML o JSON, por lo que no paga una multa por mensaje (o muestra). Esto también se vuelve muy importante para filtrar aspectos. Supongamos que está configurando un solo editor con muchos suscriptores. Algunos de los suscriptores pueden querer todos los datos, pero algunos de los suscriptores solo querrán una parte de los datos. Sin tener una solución de datos fuertemente tipada, sus aplicaciones tendrán que administrar toda esta funcionalidad de filtrado, que es aún más código que debe escribir. Con soluciones como DDS donde el tipo de información está fuertemente definido, el middleware puede administrar todo el filtrado por usted. Menos código =desarrolladores más felices :). De hecho, RTI Connext DDS tiene una funcionalidad adicional para proporcionar este filtrado en el lado del escritor de la transferencia de datos, lo que resulta en un menor uso de ancho de banda en el cable y menos procesamiento de CPU en aplicaciones que no necesitan que los datos se filtren.

5. Calidad de servicio

No todos los datos son iguales. ¿Qué significa esto? Bueno, algunos datos en una aplicación distribuida en tiempo real están transmitiendo datos de

[1] [2] 下一页