¿Qué son los mensajes DDATA y NDATA de Sparkplug?
Los certificados de nacimiento se llevan la atención, pero los mensajes DDATA y NDATA son donde vive la telemetría real. Después de que un dispositivo y un nodo se anunciaron, estos son los mensajes que llevan cada cambio de métrica posterior. Para un ingeniero que dimensiona un enlace o depura por qué un valor no se actualiza, entender los mensajes de datos es esencial. Esta página explica qué llevan DDATA y NDATA y cómo dependen del birth que los precedió.
DDATA y NDATA de Sparkplug en una línea: En Sparkplug B, DDATA y NDATA son los mensajes de datos continuos: DDATA lleva los cambios de valor de métricas de un dispositivo, y NDATA los del propio nodo de borde. Siguen a los certificados de nacimiento y, como esos births ya declararon todas las métricas, los mensajes de datos envían solo lo que cambió, identificando las métricas típicamente por alias y no por nombre para mantener pequeña la carga útil.
Los mensajes de datos dependen del birth que los precedió
Un mensaje DDATA o NDATA solo tiene significado en el contexto del birth que vino antes. El DBIRTH del dispositivo, y para el nodo su NBIRTH, declararon el conjunto completo de métricas con sus nombres, tipos de dato y alias. Un DDATA posterior no redeclara esa estructura; la referencia. Por eso un consumidor que recibe un DDATA antes de haber visto el birth correspondiente no puede interpretarlo, y por eso el protocolo es estricto con el orden de los births. El mensaje de datos es un delta contra un estado que el birth estableció.
La división entre DDATA y NDATA refleja la jerarquía de nodo y dispositivo. Un NDATA reporta cambios en métricas que pertenecen al propio nodo de borde, cosas como los diagnósticos o el estado de un gateway. Un DDATA reporta cambios en métricas de un dispositivo específico que cuelga de ese nodo de borde, direccionado dentro del espacio de tópicos del nodo. Es la misma distinción que recorre todo el modelo Sparkplug, explicada en la jerarquía de nodo de borde y dispositivo, y determina en qué tópico se publica cada cambio de datos.
Como los births llevan las definiciones completas de las métricas, los mensajes de datos pueden ser magros. Un DDATA típicamente identifica cada métrica cambiada por su alias numérico en lugar de repetir su nombre completo, e incluye una estampa de tiempo y el valor nuevo. Esa esbeltez es el argumento completo de eficiencia de Sparkplug frente al MQTT ingenuo: usted paga el costo de una descripción completa una vez en el birth, y después cada actualización de régimen es pequeña, que es lo que lo hace viable en un enlace celular medido.
Reporte por excepción y por qué los valores se quedan callados
Los mensajes de datos de Sparkplug se envían al cambio, una disciplina llamada reporte por excepción. Una métrica que no cambia no genera DDATA, así que el enlace lleva tráfico solo cuando el proceso realmente se mueve. Es eficiente, pero cambia cómo se razona sobre un valor callado. En un sistema sondeado, sin actualización significa que el sondeo falló; en Sparkplug, sin actualización significa legítimamente que el valor no ha cambiado, y distinguir ambos casos es una fuente común de confusión.
Exactamente por eso importa tanto el ciclo de vida de birth y death. Como una métrica sana pero sin cambios guarda silencio, no se puede usar el silencio de una métrica para inferir que el nodo está vivo. La vitalidad viene del ciclo de vida del nodo, de los certificados de nacimiento y defunción y del keepalive subyacente, no del flujo de datos. Un consumidor confía en que una métrica conserva su último valor reportado hasta que un DDATA nuevo lo cambie o un certificado de defunción invalide el estado del nodo completo. Confundir una métrica callada con un nodo muerto lleva a falsas alarmas.
Cuando esté depurando un valor que no se actualiza en una pantalla SCADA, el modelo de reporte por excepción le dice dónde mirar. Primero confirme que el nodo está vivo por su birth y por la ausencia de un death; si está vivo, puede que el valor simplemente no haya cambiado. Si sospecha que el consumidor perdió el hilo del estado, el remedio es un rebirth para que el nodo reemita su birth completo con los valores actuales y resincronice al consumidor. Para eso existe la petición de rebirth y por eso es la recuperación estándar cuando los datos y el estado se desalinearon.
Preguntas frecuentes
¿Cuál es la diferencia entre DDATA y DBIRTH?
DBIRTH es el certificado de nacimiento del dispositivo, enviado una vez cuando el dispositivo entra en línea, y declara el conjunto completo de métricas con sus nombres, tipos de dato y alias junto con los valores actuales. DDATA se envía repetidamente después y lleva solo las métricas que cambiaron, identificadas por lo general por alias y no por nombre. En corto: DBIRTH establece la estructura completa y la línea base; DDATA reporta cambios incrementales contra esa base, que es lo que mantiene pequeño el tráfico de régimen.
¿Por qué una métrica Sparkplug dejaría de enviar DDATA?
Casi siempre porque no ha cambiado. Sparkplug usa reporte por excepción, así que una métrica estable simplemente no genera mensajes de datos, y ese silencio es normal, no una falla. El valor que el consumidor conserva sigue siendo válido hasta que un DDATA nuevo lo actualice o el nodo emita un death. Si usted sospecha de verdad que el consumidor y el nodo perdieron la sincronía, la acción correcta es disparar un rebirth para que el nodo reemita su birth completo con los valores actuales y ambos extremos se resincronicen.
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.