Solicitud/Respuesta versus Publicación/Suscripción, Parte 2: ¿Cuál usar?
Conozca los factores determinantes para seleccionar el modelo de comunicación industrial más adecuado.


Solicitud/Respuesta versus Publicación/Suscripción, Parte 2 ¿Cuál usar?

Conozca los factores determinantes para seleccionar el modelo de comunicación industrial más adecuado

 

En las comunicaciones industriales existen 2 modelos muy conocidos que son los de solicitud-respuesta y publicación-suscripción pero quizás no se tiene claro en qué situación se recomienda uno o el otro para poder seleccionar el más indicado para la aplicación. En el siguiente blog publicado originalmente por Jean Femia para Opto 22 comenta algunos factores determinantes para saber cuál modelo utilizar entre el modelo clásico de solicitud-respuesta y el nuevo modelo de publicación-suscripción. Al final del artículo encontrará el link a la publicación original. A continuación el artículo:

En la parte 1, conocimos dos modelos de comunicación para computadoras en una red: solicitud-respuesta y publicación-suscripción. Ahora echemos un vistazo a cuándo es posible que desee usar cada uno y por qué.

Solicitud-respuesta: probada y confiable

En una arquitectura de solicitud-respuesta, cada cliente abre una conexión directa a cada servidor, porque el cliente solicita datos directamente del servidor.

En la automatización, normalmente los clientes son PC y los servidores son PLC o PAC. Por tanto, cada PC abre una conexión directa a cada PLC o PAC del que necesita datos. Como el cliente no sabe cuándo pueden cambiar los datos, solicita datos a intervalos regulares.

Por lo tanto, los clientes de PC envían solicitudes repetitivamente a los servidores PLC y PAC (en automatización, tan rápido como varias veces por segundo) y los servidores responden repetidamente:

 P: ¿Cuál es el valor del sensor? A: 10

P: ¿Cuál es el valor del sensor? A: 10

P: ¿Cuál es el valor del sensor? A: 10

P: ¿Cuál es el valor del sensor? A: 10

P: ¿Cuál es el valor del sensor? A: 10

P: ¿Cuál es el valor del sensor? A: 9

P: ¿Cuál es el valor del sensor? A: 9

 Si su red es robusta y tiene pocos servidores, este modelo funciona muy bien. Siempre que el servidor tenga la capacidad de responder a las demandas del cliente y la red pueda manejar el volumen de tráfico, la solicitud-respuesta es un método de comunicación confiable y probado. Es particularmente útil para las comunicaciones a través de una red interna segura.

¿Qué pasa con el volumen de tráfico?

Sin embargo, si tiene varios servidores con varios clientes, el volumen de tráfico en un modelo de solicitud-respuesta puede convertirse rápidamente en un problema.

A continuación, verá cómo funciona esto. Cada cliente está conectado individualmente a cada servidor del que necesita solicitar datos, y cada conexión puede incluso abrirse, consultarse, responderse y cerrarse una y otra vez.

En nuestra analogía de camiones de la parte 1, verías tráfico de camiones sin parar (camiones vacíos, camiones llenos) en todas estas conexiones.


Por el contrario, una arquitectura pub-sub simplifica las comunicaciones. No se necesitan conexiones directas ni solicitudes repetitivas de datos.

La red de enlaces se reemplaza por un único enlace de cada dispositivo al broker (también llamado servidor). La conexión entre el cliente y el broker se mantiene abierta y es increíblemente ligera. Solo dos cosas viajan a través de esta conexión: datos modificados y un pequeño latido para que el corredor sepa que el cliente todavía está allí.

Hay menos carreteras y el tráfico de camiones se reduce.


Pub-sub: bueno para tráfico pesado y redes ligeras

Por lo tanto, un modelo pub-sub puede tener sentido si tiene muchos servidores y muchos clientes que necesitan compartir datos y servicios.

Dado que el broker es la cámara de compensación central de datos, los servidores individuales no tienen que esforzarse para atender a varios clientes, y los clientes no tienen que conectarse a varios servidores. Además, el tráfico de red se reduce en general, porque los datos se publican y envían informe por excepción (RBE), es decir, solo cuando los datos cambian, en lugar de a intervalos regulares.

Pub-sub también puede tener sentido cuando es difícil configurar una conexión directa entre un cliente y un servidor, o cuando la red tiene poco ancho de banda, es costosa o no es confiable, por ejemplo, al monitorear equipos en ubicaciones remotas.

Ventajas específicas con MQTT / Sparkplug

El protocolo de transporte pub-sub MQTT se menciona con frecuencia para aplicaciones de Internet de las cosas (IoT). MQTT es un estándar OASIS y un estándar ISO. Para obtener más información sobre el protocolo, consulte mqtt.org


A menudo utilizado hoy en día para aplicaciones personales de Internet de las cosas, MQTT tiene una historia industrial. Fue inventado en 1999 para una aplicación de oleoductos y gasoductos en Oklahoma, para resolver problemas de comunicaciones costosas a través de líneas satelitales desde sitios remotos.

Sparkplug fue desarrollado más recientemente (la especificación fue lanzada en 2016) por Cirrus Link Solutions (propiedad de Arlen Nipper, uno de los co-inventores de MQTT). Su propósito era industrializar aún más MQTT: ayudar a que MQTT fuera adecuado para comunicaciones de misión crítica, así como también más fácil de implementar y administrar, agregando encapsulación binaria, estado y definición de tema.

 

Por supuesto, los problemas con las instalaciones remotas y las conexiones de red endebles o costosas no se limitan a la industria del petróleo y el gas. Para resolverlos, MQTT con Sparkplug ofrece tres ventajas adicionales sobre solicitud-respuesta:

  • Debido a que las cargas útiles se comprimen y los datos se mueven de manera eficiente, incluso los dispositivos remotos con conexiones irregulares o ancho de banda bajo pueden publicar o suscribirse a datos.
  • Los dispositivos que se desconectan pueden volver a conectarse con el broker, enviando o recibiendo datos actuales y también una cantidad específica de datos almacenados en búfer para ayudar a llenar el vacío.
  • Y para los editores de datos, una importante ventaja de seguridad: los datos se publican mediante una conexión saliente.

Este último punto es una consideración clave para configurar redes y enviar datos de forma segura sin exigir demasiada ayuda de un departamento de tecnología de la información (TI) corporativa. Todos los firewalls bloquean el tráfico entrante (por ejemplo, un cliente externo que solicita datos de un servidor interno). Pero normalmente permiten conexiones salientes a través de puertos TCP.

Debido a que los datos pub-sub se envían desde dispositivos y software utilizando solo comunicaciones salientes (al intermediario), estas comunicaciones no requieren una VPN ni un reenvío de puertos. Eso significa que a menudo puede mover datos donde los necesite sin requerir mucho tiempo o esfuerzo de TI.

Otra ventaja de seguridad significativa de la arquitectura MQTT es que toda la seguridad se gestiona en un solo lugar: el broker. Todas las listas de control de acceso (ACL), nombres de usuario / contraseñas y puertos se administran en el broker, que se puede colocar de forma segura en la red corporativa o en la nube. Los puertos, la autenticación de usuarios y las ACL nunca se administran en el lado del cliente. Eso significa menos vectores de ataque.

Empezando con MQTT / Sparkplug

Para utilizar MQTT / Sparkplug, deberá tener un broker MQTT compatible con Sparkplug. Puede ubicar al broker en sus instalaciones o en la nube.

Para la creación de prototipos, es posible que desee probar con un broker público. Sin embargo, una vez que haya decidido utilizar el protocolo, debe tener un broker seguro. Aquí hay un buen artículo que explica más sobre el uso de MQTT. Hay más información disponible en línea sobre el uso de MQTT y Sparkplug en su red.

Nuevos productos para facilitar la puesta en marcha

Obtener los datos de sus dispositivos industriales solía ser muy difícil, pero ahora es mucho más fácil: el sistema groov EPIC® de Opto 22 incluye Ignition Edge® o ignition completo de Inductive Automation®.

Ignition y Ignition Edge en groov EPIC incluyen el módulo de transmisión MQTT de Cirrus Link®, que admite la especificación de codificación de datos Sparkplug.


Publicado en español el 24 de Mayo del 2021.

Originalmente publicado el 27 de Febrero del 2018.

Fuente original: https://blog.opto22.com/optoblog/request-response-vs-pub-sub-part-2 

Compartir

Últimas publicaciones del blog

Your Dynamic Snippet will be displayed here... This message is displayed because you did not provided both a filter and a template to use.


Solicitud/Respuesta versus Publicación/Suscripción, Parte 1: ¿Cuál es la diferencia?
Conozca las características y diferencias de dos de los principales modelos de comunicación industrial.