¿Qué es OPC UA PubSub vs cliente-servidor?
OPC UA nació como un protocolo de solicitud y respuesta: un cliente se conecta a un servidor, abre una sesión y se suscribe a los tags que quiere, y el servidor le manda actualizaciones por esa conexión. Ese modelo cliente-servidor es excelente para una conversación controlada punto a punto, pero no reparte datos de forma natural hacia muchos consumidores ni empuja telemetría hacia la nube. Para atender eso, OPC UA ganó un segundo modelo de comunicación, PubSub, que publica mensajes a muchos suscriptores a la vez sin una sesión por consumidor, ya sea directamente sobre la red o a través de un broker de mensajes como MQTT. Esta guía contrasta los dos modelos, explica dónde encaja cada uno y muestra cómo PubSub deja fluir los datos de OPC UA hacia tuberías de nube basadas en MQTT.
OPC UA PubSub vs cliente-servidor en una línea: OPC UA define dos modelos de comunicación. El modelo cliente-servidor es solicitud y respuesta: un cliente establece una sesión con un servidor, crea suscripciones con elementos monitoreados y recibe actualizaciones por esa conexión dedicada, lo que conviene al acceso controlado punto a punto. El modelo PubSub es publicación y suscripción: un publicador envía mensajes, codificados como UADP o JSON, a muchos suscriptores a la vez, ya sea directamente por UDP o a través de un broker de mensajes como MQTT, sin sesión por consumidor. Cliente-servidor encaja con el acceso interactivo y la configuración donde el cliente necesita navegar y leer bajo demanda, mientras que PubSub encaja con la distribución de telemetría uno a muchos, desacoplada y amigable con la nube.
El modelo cliente-servidor: sesiones, suscripciones, elementos monitoreados
En el modelo cliente-servidor, la comunicación es una conversación directa entre un cliente y un servidor. El cliente se conecta al servidor, establece una sesión segura y luego navega el espacio de direcciones del servidor para encontrar los nodos que le interesan. Para recibir datos continuos, crea una suscripción y le agrega elementos monitoreados, uno por variable que quiere vigilar, diciéndole al servidor con qué frecuencia muestrear cada una y cuánto debe cambiar un valor antes de reportarse. El servidor envía entonces notificaciones de cambio de datos al cliente por la sesión cada vez que los valores monitoreados cumplen esos criterios. El intercambio completo es con estado y está atado a la conexión de ese único cliente.
Las fortalezas de este modelo son el control y la interactividad. Como cliente y servidor mantienen una sesión, el cliente puede hacer mucho más que recibir valores: puede navegar el espacio de direcciones completo para descubrir qué hay disponible, leer y escribir nodos bajo demanda, llamar métodos y ajustar sus suscripciones sobre la marcha. La seguridad se negocia por sesión, así que el acceso está autenticado y cifrado para esa conexión específica. Esto hace a cliente-servidor ideal para herramientas que necesitan explorar e interactuar con un servidor - software de ingeniería, una HMI configurándose, un cliente leyendo tags específicos cuando se le pide - donde la riqueza de la interacción importa más que difundir a muchos consumidores.
La limitación es que todo es por conexión. Cada cliente que quiere datos abre su propia sesión y mantiene sus propias suscripciones, así que servir a muchos consumidores significa muchas sesiones, cada una consumiendo recursos del servidor. No hay una forma integrada de publicar un flujo que muchos consumidores independientes reciban, y el cliente tiene que poder alcanzar y conectarse directamente al servidor, lo que es incómodo a través de fronteras de red y hacia la nube. Para el acceso interactivo uno a uno esto es exactamente lo correcto, pero para distribuir la misma telemetría a muchos destinos, o empujarla hacia afuera a través de firewalls hacia un servicio de nube, el diseño de sesión por cliente se vuelve una restricción y no una ventaja.
El modelo PubSub: UADP, JSON, UDP y MQTT
PubSub desacopla publicadores de suscriptores para que los datos fluyan uno a muchos sin una sesión por consumidor. Un publicador empaqueta los valores que quiere enviar en un mensaje de dataset y lo publica, y cualquier número de suscriptores puede recibir ese mensaje, sin que ninguno necesite una conexión individual al publicador. El publicador no sabe ni le importa quién escucha; simplemente publica, y los suscriptores simplemente reciben. Esta es una forma fundamentalmente distinta de cliente-servidor: en lugar de consumidores jalando datos por sus propias sesiones, la fuente empuja mensajes que muchos consumidores pueden recoger, que es lo que vuelve a PubSub apto para difundir telemetría ampliamente.
PubSub viene en dos sabores de transporte que convienen a situaciones distintas. La forma sin broker publica mensajes directamente en la red, típicamente como UADP - una codificación binaria compacta - enviada por UDP, a menudo multicast, para que muchos suscriptores en la misma red reciban los datos con muy baja latencia y sin intermediario. Esto conviene a la distribución rápida, local, de controlador a controlador o a nivel de campo. La forma con broker publica los mensajes a un broker de mensajes, notablemente MQTT, codificando la carga como UADP o como JSON; el broker entrega entonces los mensajes a los suscriptores que se hayan suscrito a los tópicos relevantes. La forma con broker cambia un poco de inmediatez por el alcance, el almacenamiento temporal y la flexibilidad que un broker provee.
La elección de codificación sigue al transporte y al consumidor. UADP es compacta y eficiente, bien pareada con la distribución consciente del ancho de banda o de alta tasa, y es la elección natural sobre UDP. JSON es más verbosa pero legible y trivialmente consumible por software ordinario, servicios de nube y herramientas web, lo que la vuelve atractiva cuando los suscriptores son sistemas de TI y no dispositivos industriales. Publicar datos OPC UA como JSON sobre MQTT, por ejemplo, produce mensajes que una tubería estándar de ingestión en la nube puede leer sin código específico de OPC UA. Esta flexibilidad de codificación y transporte es gran parte de por qué PubSub se describe como amigable con la nube, porque deja a OPC UA encontrarse con los consumidores en los términos que esos consumidores ya entienden.
Cuándo encaja cada uno y cómo PubSub puentea hacia tuberías MQTT
Elegir entre los dos se reduce a la forma del flujo de datos. Cliente-servidor encaja cuando un consumidor necesita interactuar con un servidor - navegar su estructura, leer o escribir nodos específicos, llamar métodos o afinar suscripciones - y cuando la relación es esencialmente un cliente con un servidor. Es el modelo correcto para herramientas de ingeniería, para una HMI jalando valores específicos y para cualquier caso donde el descubrimiento y el acceso bajo demanda importan. PubSub encaja cuando la misma telemetría debe llegar a muchos consumidores, cuando publicador y suscriptor deben desacoplarse para que ninguno dependa de la presencia del otro, y cuando los datos tienen que viajar hacia afuera a la nube, que es precisamente el problema de distribución de telemetría que cliente-servidor maneja con torpeza.
Los dos no son tanto rivales como complementos, y muchos sistemas usan ambos: cliente-servidor para configuración y acceso interactivo, PubSub para el flujo de telemetría uno a muchos de alto volumen. Un dispositivo puede exponer una interfaz cliente-servidor completa para que un ingeniero lo navegue y configure, mientras publica simultáneamente sus valores en vivo vía PubSub a un broker para que todos los demás los consuman. Entender qué modelo conviene a qué trabajo evita el error de forzar a uno a hacer el trabajo del otro, como abrir una sesión por consumidor de nube cuando un solo flujo publicado los serviría a todos, o intentar navegar y configurar sobre un feed PubSub de dispara-y-olvida.
El puenteo hacia tuberías MQTT es donde PubSub se vuelve especialmente valioso para el monitoreo en la nube, porque deja a los datos de OPC UA entrar al mismo mundo basado en MQTT donde ya vive tanta telemetría moderna. Cuando OPC UA PubSub publica a un broker MQTT, sus mensajes se sientan junto a todos los demás tópicos MQTT, y cualquier consumidor que pueda suscribirse a MQTT puede recibirlos, incluido un servicio de ingestión en la nube que no sabe nada de sesiones OPC UA. Una plataforma SCADA en la nube como Merobix, que ingiere desde MQTT, puede por lo tanto recibir datos OPC UA a través del broker igual que recibe la telemetría de cualquier otro publicador, decodificar las cargas UADP o JSON y almacenarlas. Para las operaciones de campo, esto significa que las fuentes OPC UA pueden alimentar una plataforma de nube por MQTT estándar sin que cada consumidor mantenga su propia sesión de cliente OPC UA, que es el camino desacoplado y amigable con la nube que PubSub fue diseñado para habilitar.
Preguntas frecuentes
¿Cuál es la diferencia entre OPC UA cliente-servidor y PubSub?
Cliente-servidor es una conversación con estado de solicitud y respuesta: un cliente abre una sesión con un servidor, crea suscripciones con elementos monitoreados y recibe actualizaciones por esa conexión dedicada, lo que conviene a navegar, leer, escribir y al acceso interactivo de un cliente a la vez. PubSub es publicación y suscripción: un publicador envía mensajes a muchos suscriptores a la vez sin sesión por consumidor, directamente por UDP o a través de un broker como MQTT, lo que conviene a la distribución de telemetría uno a muchos y a la entrega en la nube. Cliente-servidor sobresale en interacción y control; PubSub sobresale en distribución de datos desacoplada y escalable.
¿Qué son UADP y JSON en OPC UA PubSub?
Son las dos codificaciones que PubSub puede usar para sus mensajes. UADP es una codificación binaria compacta, eficiente para distribución consciente del ancho de banda o de alta tasa y la elección natural al publicar directamente por UDP. JSON es más verbosa pero legible y de fácil consumo para software ordinario, servicios de nube y herramientas web, lo que la vuelve atractiva cuando los suscriptores son sistemas de TI y no dispositivos industriales. Publicar como JSON sobre MQTT, por ejemplo, produce mensajes que una tubería estándar de ingestión en la nube puede leer sin código específico de OPC UA.
¿Cómo se conecta OPC UA PubSub a una tubería MQTT?
En su forma con broker, PubSub publica sus mensajes a un broker de mensajes, y MQTT es una elección común, codificando la carga como UADP o JSON en tópicos MQTT. Una vez que los datos OPC UA están en el broker, se sientan junto a todos los demás tópicos MQTT, así que cualquier consumidor que pueda suscribirse a MQTT puede recibirlos, incluido un servicio de ingestión en la nube que no sabe nada de sesiones OPC UA. Esto deja a las fuentes OPC UA alimentar tuberías de nube por MQTT estándar sin que cada consumidor mantenga su propia conexión de cliente OPC UA, que es el flujo desacoplado y amigable con la nube para el que PubSub fue diseñado.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.