¿Qué son bdSeq y seq en Sparkplug?
Sparkplug lleva dos contadores distintos que la gente confunde constantemente: seq, que ordena los mensajes dentro de una sesión, y bdSeq, que empareja cada birth con su death correcto. Tenerlos claros es esencial para entender por qué un nodo reemite un rebirth o por qué se ignora un last will obsoleto. Para el ingeniero que depura la confusión de sesiones después de un enlace intermitente, esta página explica qué hace cada contador y por qué existen los dos.
bdSeq y seq de Sparkplug en una línea: Sparkplug usa dos contadores. El número seq avanza con cada mensaje de una sesión, para que un consumidor detecte un mensaje perdido o fuera de orden y pida un rebirth. El bdSeq, el número de secuencia birth-death, se fija en cada NBIRTH y en su NDEATH correspondiente, para que el consumidor confirme que un death pertenece a la sesión actual e ignore un last will obsoleto de una sesión vieja.
seq: ordenar los mensajes dentro de una sesión
El número seq es un contador pequeño que se incrementa con cada mensaje Sparkplug de un nodo de borde dentro de una sesión, y da la vuelta al llegar a su máximo. El NBIRTH arranca la secuencia, y cada mensaje de datos o de comando siguiente lleva el valor que sigue. Su trabajo es detectar huecos: un consumidor que sigue el seq puede darse cuenta si un mensaje se perdió o llegó fuera de orden, porque los números saltarían o retrocederían. Es el mismo mecanismo descrito junto al alias de métrica y número de secuencia.
La detección de huecos importa precisamente porque Sparkplug reporta por excepción. Como el consumidor confía en un flujo de actualizaciones al cambio y conserva los últimos valores conocidos entre una y otra, un mensaje de datos perdido en silencio lo dejaría con un valor equivocado sin manera de notarlo. El seq rodante le da la manera de notarlo: una ruptura en la secuencia significa que pudo perder un cambio, así que su estado en caché podría estar obsoleto. La respuesta correcta del consumidor no es adivinar, sino pedir al nodo que resincronice.
Esa resincronización es el rebirth. Cuando un consumidor detecta un hueco de seq, o pierde por cualquier motivo la confianza en su estado, emite una petición de rebirth, y el nodo responde reemitiendo su birth completo con los valores actuales y un arranque de secuencia fresco. Así que seq no es solo un diagnóstico; es el disparador de la ruta de recuperación que mantiene correcta la imagen del consumidor pese a un enlace con pérdidas. Sin él, el estado del reporte por excepción podría desviarse sin ser detectado.
bdSeq: atar cada birth a su death correcto
El contador bdSeq resuelve un problema distinto y más sutil: emparejar un death con el birth al que de verdad pertenece. Recuerde que el NDEATH se registra como el last will de MQTT del nodo, así que se compone al momento de conectar y el broker lo retiene hasta que la conexión cae. Ahora imagine un nodo que conecta, se desconecta de forma abrupta y reconecta. El broker todavía puede disparar el will de la conexión anterior después de que el nodo ya regresó. Sin una forma de distinguirlo, un consumidor podría recibir un death de un nodo que en realidad está vivo.
bdSeq evita esa confusión. Cada vez que el nodo conecta, elige un valor de bdSeq y lo coloca tanto en el NBIRTH que envía como en el NDEATH que registra como will de esa misma conexión. Cuando un consumidor recibe un death, revisa el bdSeq: si coincide con el birth de la sesión que considera activa, el death es real y el nodo se fue. Si el bdSeq pertenece a una sesión vieja que un birth más nuevo ya reemplazó, el death es obsoleto y el consumidor lo ignora. El emparejamiento birth-death es lo que hace confiable al will a través de las reconexiones.
Por eso no hay que confundir bdSeq con seq, aunque ambos sean números en mensajes Sparkplug. seq vive dentro de una sesión y ordena sus mensajes; bdSeq identifica a qué sesión pertenece un birth o un death. Un enlace intermitente estresa a los dos: puede tirar mensajes, cosa que seq atrapa, y puede dejar wills obsoletos encolados en el broker, cosa que bdSeq neutraliza. Depurar un nodo que parece morir y revivir de forma errática casi siempre se reduce a leer bien estos dos contadores, y se relaciona de cerca con diagnosticar un nodo que se cae de línea.
Preguntas frecuentes
¿Cuál es la diferencia entre seq y bdSeq en Sparkplug?
El número seq se incrementa con cada mensaje dentro de una misma sesión, para que un consumidor detecte un mensaje perdido o fuera de orden y pida un rebirth. El bdSeq, o secuencia birth-death, se elige una vez por conexión y se coloca tanto en el NBIRTH como en el NDEATH correspondiente, para que el consumidor confirme que un death pertenece a la sesión que considera activa. En corto: seq ordena los mensajes dentro de una sesión; bdSeq identifica a qué sesión pertenece un birth o un death.
¿Por qué bdSeq evita que un death obsoleto confunda al consumidor?
Como el NDEATH es un last will registrado al conectar, el broker puede disparar un will viejo después de que el nodo ya reconectó. Al estampar el mismo bdSeq en el birth y en su will correspondiente, el nodo le permite al consumidor revisar si un death entrante pertenece a la sesión actual o a una anterior. Si el death lleva un bdSeq desactualizado que un birth más nuevo ya reemplazó, el consumidor lo reconoce como obsoleto y lo ignora, y así un nodo que en realidad está vivo no se marca muerto por error.
Fuentes y lecturas
Referencias primarias de los organismos de normas y reguladores que definen este tema:
- Sparkplug Specification - Eclipse Foundation
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.