¿Qué es solicitud/respuesta en MQTT con un response topic?
MQTT está hecho para publicación/suscripción unidireccional, pero los sistemas de control reales necesitan hacer una pregunta y obtener una respuesta: un comando de escritura que devuelva éxito o falla. MQTT 5 vuelve ese patrón de primera clase con dos propiedades: response topic y correlation data. Para un ingeniero cableando escrituras de operador, convierten los esquemas de respuesta improvisados en un estándar. Esta página explica cómo funciona el patrón y dónde encaja en los flujos de control.
Patrón solicitud/respuesta de MQTT en una línea: El patrón de solicitud/respuesta de MQTT usa dos propiedades de MQTT 5. El solicitante incluye un response topic, que le dice al que responde dónde publicar su respuesta, y correlation data, un token opaco que el que responde repite para que el solicitante pueda emparejar la respuesta con la solicitud original. Esto permite a un cliente enviar un comando y recibir de forma confiable la respuesta correspondiente sobre un protocolo pub/sub inherentemente unidireccional.
Cómo trabajan juntos response topic y correlation data
La propiedad response topic la fija el solicitante en su PUBLISH de solicitud. Lleva el nombre del tópico en el que el solicitante espera la respuesta, así que el que responde no tiene que saber de antemano a dónde enviar su contestación; la solicitud se lo dice. El solicitante se suscribe primero a ese tópico de respuesta y luego publica la solicitud. El que responde procesa la solicitud y publica su resultado en el response topic nombrado en ella. Esta es la pieza que le da a pub/sub un camino de regreso sin cablear en duro el ruteo de respuestas.
Correlation data es la segunda mitad, y resuelve el emparejamiento en lugar del ruteo. Es un token binario opaco que el solicitante adjunta a la solicitud; el que responde debe copiarlo, sin cambios, en la respuesta. Cuando varias solicitudes están en vuelo sobre el mismo tópico de respuesta, el solicitante usa el correlation data para emparejar cada respuesta entrante con la solicitud específica que contesta. Sin él, un cliente que emitió tres comandos no podría saber cuál de tres respuestas pertenece a cuál comando. Es funcionalmente un identificador de correlación, familiar para quien haya construido request/reply sobre mensajería.
Juntas, las dos propiedades convierten un patrón que la gente solía armar a mano en una convención soportada. Antes de MQTT 5, los ingenieros construían solicitud/respuesta inventando sus propios campos de tópico de respuesta e id de solicitud dentro de la carga, y cada sistema lo hacía diferente. Estandarizarlas como propiedades del protocolo significa que un respondedor puede implementar el patrón genéricamente, y se compone con otras características de MQTT 5 como las user properties para contexto adicional en la solicitud.
Dónde encaja el patrón en los flujos de control
El uso de control obvio es una escritura de operador que necesita confirmación. Un operador cambia un setpoint desde una HMI en la nube; la solicitud lleva el valor nuevo y un response topic; el dispositivo de borde lo aplica y responde en ese tópico con éxito, una razón de falla o el valor aceptado. El correlation data ata la confirmación a la escritura exacta que el operador emitió, así que la HMI puede mostrar un resultado definitivo en lugar de asumir con optimismo que la escritura aterrizó. Ese ciclo de confirmación es lo que vuelve confiables las escrituras remotas.
Hay una relación importante con Sparkplug. Sparkplug define su propio canal de comandos mediante los comandos DCMD y NCMD para escribir métricas, así que un sistema Sparkplug puro típicamente usa ese mecanismo en lugar de las propiedades genéricas de solicitud/respuesta. El patrón de solicitud/respuesta de MQTT 5 está más en casa en diseños de MQTT plano, o para operaciones del plano de control que quedan fuera del modelo de métricas de Sparkplug, como pedirle a un gateway que reporte su versión de firmware o dispare un diagnóstico.
Unas cuantas precauciones mantienen seguro el patrón. El solicitante debe aplicar un timeout, porque una respuesta puede no llegar nunca si el respondedor está fuera de línea, y no debe bloquearse esperando para siempre. Los tópicos de respuesta deben elegirse de modo que las respuestas no las vean por accidente clientes que no deberían verlas, porque una respuesta puede llevar datos sensibles de resultado. Y el correlation data debe ser genuinamente único por solicitud pendiente, o dos solicitudes concurrentes podrían confundirse. Manejado con esas disciplinas, solicitud/respuesta da a los flujos de control una forma limpia y estándar.
Preguntas frecuentes
¿El que responde necesita conocer el tópico de respuesta de antemano?
No, y ese es el punto de la propiedad response topic. El solicitante incluye el tópico donde quiere la respuesta dentro del propio mensaje de solicitud, así que el que responde simplemente lee la propiedad response topic y publica su contestación ahí. Esto desacopla al respondedor de cualquier ruteo de respuestas cableado en duro y deja que cada solicitante elija su propio tópico de respuesta, que es lo que hace funcionar el patrón genéricamente entre muchos solicitantes y un solo respondedor sin acuerdo previo de nombres de tópicos.
¿Debo usar solicitud/respuesta de MQTT o comandos de Sparkplug para las escrituras?
Depende de su stack. En un sistema Sparkplug B, las escrituras a métricas van por los mensajes de comando DCMD y NCMD definidos, que encajan con el modelo Sparkplug y su conjunto de métricas definido en el birth, así que normalmente usaría esos en lugar de las propiedades genéricas de solicitud/respuesta. El patrón de solicitud/respuesta de MQTT 5 conviene en diseños de MQTT plano, o para operaciones del plano de control fuera del modelo de métricas de Sparkplug, como consultar un gateway o disparar un diagnóstico, donde las propiedades estándar de response topic y correlation data le dan un canal de respuesta limpio.
Fuentes y lecturas
Referencias primarias de los organismos de normas y reguladores que definen este tema:
- MQTT Version 5.0 Specification - OASIS
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.