¿Qué es una aplicación anfitriona primaria de Sparkplug?

Volver al glosario

El consumidor que los nodos de borde realmente vigilan

MQTT desacopla a los publicadores de los suscriptores mediante un broker, lo cual es poderoso pero tiene un punto ciego: un publicador no tiene forma inherente de saber si alguien está recibiendo lo que envía. Un nodo de borde puede mantener una conexión sana al broker y seguir publicando, y aun así la aplicación consumidora pudo haberse caído, perder su conexión o reiniciarse, en cuyo caso los datos del nodo se están entregando a nadie. Para un sistema de control esa es una ambigüedad inaceptable: un nodo que cree que todo va bien mientras sus datos no llegan a ningún lado.

La aplicación anfitriona primaria es la respuesta de Sparkplug. Es el anfitrión consumidor específico - normalmente la plataforma SCADA o IIoT que ingiere los datos - designado como aquel cuya presencia importa. En lugar de que cada nodo de borde intente rastrear a todo consumidor posible, la arquitectura nomina un anfitrión primario, le da un identificador conocido, y deja que los nodos de borde vigilen solo a esa entidad. Cuando el anfitrión primario está conectado, los nodos saben que sus datos tienen un destino vivo; cuando está desconectado, saben que no.

Esto convierte la conectividad de extremo a extremo, de algo que un nodo solo puede suponer, en algo que puede verificar de verdad. La distinción que se traza es entre alcanzar el broker y alcanzar al consumidor. Alcanzar el broker significa que el enlace del nodo está en pie. Saber que el anfitrión primario está conectado significa que toda la ruta desde el nodo hasta el consumidor está intacta. Sparkplug hace explícita y observable la segunda condición, de modo que la sensación de estar conectado que tiene un nodo refleje el estado real del canal de datos y no solo su propio enlace local.

El tópico STATE y el nacimiento y la muerte del propio anfitrión

El anfitrión primario anuncia su estado en un tópico STATE que lleva su identificador de anfitrión, y cada nodo de borde interesado se suscribe a él. Cuando la aplicación anfitriona primaria se conecta y establece su sesión, publica un estado conectado en su tópico STATE, avisando a todos los nodos vigilantes que el consumidor está presente y listo. Esta es la contraparte del lado del anfitrión al nacimiento de un nodo de borde: así como un nodo anuncia su llegada, el anfitrión primario anuncia su llegada a los nodos que dependen de él.

Es crucial que el anfitrión primario registre un mensaje STATE desconectado como su testamento (Last Will) MQTT al conectarse, de modo que si se desconecta de forma abrupta, el broker publique el estado desconectado en su nombre. Es el mismo mecanismo de testamento que los nodos de borde usan para sus mensajes de muerte, aplicado al anfitrión. Ya sea que el anfitrión primario se apague de forma limpia y publique su propio estado desconectado, o que caiga de la red y el broker lo publique, los nodos de borde vigilantes aprenden de forma confiable que el consumidor se desconectó. No hay escenario en el que el anfitrión se desvanezca en silencio y deje a los nodos creyendo falsamente que sigue ahí.

Esta simetría - el anfitrión tiene un nacimiento y una muerte igual que los nodos - es lo que hace coherente el modelo de sesión de Sparkplug desde ambos extremos. Los nodos de borde se anuncian al anfitrión mediante sus nacimientos y muertes, y el anfitrión primario se anuncia a los nodos mediante su tópico STATE. Ambos lados usan la función de testamento del broker para que las desconexiones abruptas igual se anuncien. El resultado es una red donde cada participante que importa tiene una forma explícita, respaldada por el broker, de decir si está presente, en lugar de dejar que alguien lo adivine por el silencio.

Perder al anfitrión primario dispara el almacenamiento local

El beneficio práctico de vigilar al anfitrión primario es lo que ocurre cuando desaparece. Cuando un nodo de borde ve que el STATE del anfitrión primario pasa a desconectado, concluye que sus datos ya no tienen un destino vivo aunque su propia conexión al broker esté bien. En lugar de seguir publicando hacia un vacío donde las lecturas se perderían, un nodo de borde bien diseñado comienza el almacenamiento local (store-and-forward): guarda sus mediciones localmente, reteniendo los datos históricos hasta que el anfitrión primario regrese. Esta es la idea clave: es la pérdida del anfitrión, no la pérdida del broker, lo que debe disparar el almacenamiento, porque un nodo puede estar perfectamente conectado al broker mientras el consumidor está caído.

Cuando el anfitrión primario regresa y republica un STATE conectado, los nodos de borde vigilantes reconocen que el destino está vivo de nuevo. En ese punto pueden vaciar sus datos almacenados hacia adelante, entregando las lecturas que se acumularon durante la interrupción para que el histórico del anfitrión no tenga un hueco inexplicado. Combinado con que el nodo restablezca su nacimiento para que el anfitrión tenga un modelo fresco y completo, esto permite que el sistema sane de forma limpia tras una caída del anfitrión: el operador ve un registro continuo en lugar de un agujero donde el consumidor estuvo caído.

Precisamente por esto importa el concepto de anfitrión primario para el SCADA en la nube sobre enlaces de campo poco confiables. Una plataforma en la nube como Merobix, actuando como aplicación anfitriona primaria, publica su propio STATE, de modo que los nodos de borde remotos en plataformas de pozos y estaciones de compresión sepan exactamente si el consumidor en la nube es alcanzable. Si la conectividad a la nube cae, los dispositivos de campo almacenan sus mediciones localmente y las reenvían cuando la plataforma regresa, así que un enlace de retorno intermitente no significa histórico perdido: el hueco se llena en cuanto el anfitrión primario vuelve a estar en línea. Vigilar al anfitrión y no solo al broker es lo que hace que ese almacenamiento se dispare correctamente, y es la diferencia entre un despliegue de campo resiliente y uno que descarta datos en silencio cada vez que el consumidor en la nube parpadea.

Preguntas frecuentes