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.


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

En el mundo de las comunicaciones industriales es muy común escuchar gran diversidad de términos como “solicitud”, “respuesta”, “cliente”, “servidor”, “publicación” y “suscripción” pero en muchas ocasiones no se tiene claridad al respecto o se utilizan de forma errónea. En el siguiente blog publicado originalmente por Jean Femia para Opto 22 se establecen las principales características y diferencias 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:

Todos sabemos que las computadoras y otros dispositivos electrónicos (impresoras, enrutadores, computadoras portátiles, teléfonos inteligentes y más) están conectados en red para que puedan intercambiar información.

Pero, ¿cómo llega esa información a donde se supone que debe ir?

¿Cómo llega una hoja de cálculo a la impresora, un video de YouTube a su teléfono inteligente o, lo que es más importante para los ingenieros de automatización, un valor de un sensor llega a su HMI?

Echemos un vistazo a un par de modelos para la comunicación en red, y luego, en la parte 2, los compararemos para ver cuál podría ser mejor en ciertos escenarios. Los dos que veremos son solicitud-respuesta y publicación-suscripción.

Solicitud y respuesta

El modelo típico de las computadoras que se comunican en una red es solicitud-respuesta. En el modelo de solicitud-respuesta, una computadora o software cliente solicita datos o servicios, y una computadora o software servidor responde a la solicitud proporcionando los datos o el servicio.

Por ejemplo, cuando envía una hoja de cálculo a la impresora, su programa de hoja de cálculo es el cliente. Su solicitud de servicios de impresión va al servidor de impresión de su empresa, que responde a la solicitud y asigna recursos para las impresoras en la red. El servidor de impresión maneja todas las solicitudes de impresión de los clientes, asegurándose de que su hoja de cálculo y los trabajos de impresión de sus compañeros de trabajo se completen de manera ordenada.

Cuando quiere ver ese video de YouTube en su teléfono inteligente, su navegador web o aplicación de YouTube es el cliente, solicitando el video a través de ese gigante de redes, Internet. El servidor web de YouTube recibe la solicitud y responde proporcionándole la página de video, junto con los otros millones de páginas de video que van a otros millones de espectadores en todo el mundo.

En la automatización, el cliente suele ser una PC y el servidor es un PLC o PAC. La aplicación HMI de su PC solicita datos del PLC o PAC para mostrarlos en el monitor.

Puede imaginar una solicitud-respuesta como un cliente que envía un camión vacío para que se llene de datos. El servidor responde poniendo los datos en el camión y devolviéndolos.

Publicar y suscribir

Una forma diferente de que los dispositivos se comuniquen en una red se llama publicación-suscripción o pub-sub. En una arquitectura pub-sub, una fuente central llamada broker (a veces también llamada servidor) recibe y distribuye todos los datos. Los clientes de Pub-sub pueden publicar datos en el broker o suscribirse para obtener datos de él, o ambos.

Los clientes que publican datos los envían sólo cuando los datos cambian (informe por excepción o RBE). Los clientes que se suscriben a los datos los reciben automáticamente del broker / servidor, pero nuevamente, solo cuando cambia.

El broker no almacena datos; simplemente lo traslada de los publicadores a los suscriptores. Cuando los datos provienen de un publicador, el broker los envía de inmediato a cualquier cliente suscrito a esos datos.

En nuestra analogía de camiones, no hay camiones vacíos. Un cliente que publica datos envía un camión completo al corredor. El corredor ve entrar el camión pero no lo descarga; simplemente lo enruta intacto a un suscriptor (clonando el camión si hay más de un suscriptor).

En el diagrama siguiente, el cliente de la izquierda publica datos a los que se suscriben los clientes de la derecha. Además, el cliente de la parte inferior derecha también publica los datos que necesitan otros clientes que no se muestran.

 

MQTT: un protocolo pub-sub


MQTT es un protocolo de transporte bastante conocido que utiliza la arquitectura pub-sub. MQTT es extremadamente liviano: casi no ocupa espacio en un dispositivo, por lo que incluso dispositivos pequeños con muy poca potencia informática pueden usarlo.

MQTT define el camión y las rutas. Pero no define cómo se empaqueta o desempaqueta la carga (los datos). Ahí es donde entra Sparkplug.

MQTT con Sparkplug


La especificación de cliente de MQTT abierto llamada Sparkplug proporciona un formato de mensajería apropiado para uso industrial.

Sparkplug codifica la carga útil de datos: define cómo se empaquetan los datos en el camión antes de que los envíe el editor y cómo se descomprimen en el suscriptor.

Los datos enviados a través de MQTT con Sparkplug están comprimidos y son eficientes. Los camiones MQTT que se han empaquetado con la definición de Sparkplug también deben desempaquetarse con Sparkplug, por lo que tanto los editores como los suscriptores deben usarlo para que se entreguen los datos.

MQTT con Sparkplug también proporciona una forma eficiente de rastrear el estado de los clientes y asegurarse de que los clientes con una conexión débil aún puedan entregar y recibir datos.

  • Si el cliente se desconecta (rompe su conexión con el corredor), el broker envía un "certificado de defunción" a los clientes suscritos a esos datos.
  • Cuando el cliente vuelve a estar en línea (restablece la conexión), el broker emite un "certificado de nacimiento" con el estado actual de todas las etiquetas de datos.

También se puede enviar una cierta cantidad de datos perdidos, según la configuración del cliente.

Comparando solicitud-respuesta y pub-sub

Debido a que estos dos modelos de comunicación de red funcionan de manera diferente, algunas aplicaciones son más adecuadas para uno u otro modelo.

En la parte 2, veremos algunas diferencias clave y cuándo puede elegir usar cada una. Sugerencia: uno de estos puede ser más adecuado para aplicaciones industriales de Internet de las cosas (IIoT).

 

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

Originalmente publicado el 8 de Febrero del 2018.

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

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.

5 Funciones Principales de un SCADA
Las funciones de un SCADA van en busca de una transformación digital.