Los alias de métricas de Sparkplug permiten a un edge node sustituir nombres de métrica largos como Line2/Filler/Motor/CurrentAmps por un entero pequeño en cada mensaje DATA. En esta guía aprenderás cómo funciona la correspondencia de alias entre los mensajes BIRTH y DATA, cuándo compensa la complejidad adicional de los alias y cómo localizar y corregir alias que no coinciden cuando los valores decodificados de repente parecen incorrectos.
Por qué los nombres de métrica salen caros
Los payloads Sparkplug B son Protobuf, que ya es compacto. Los números se codifican como varints, las marcas de tiempo son enteros de 64 bits y no hay signos de puntuación de JSON. La única parte de un payload que Protobuf no puede encoger es una cadena, y los nombres de métrica son cadenas.
Las convenciones de nomenclatura industriales hacen que esas cadenas sean largas. Una ruta de tag copiada del navegador de tags de un PLC o un SCADA suele incluir el área, la máquina, el subsistema y la señal: Packaging/Line2/Filler/Infeed/Motor1/Current. Cuando un mensaje DDATA informa de un único valor modificado, ese nombre de 45 caracteres puede ocupar varias veces más que el valor y la marca de tiempo juntos.
En una red de planta cableada esto rara vez importa. En enlaces celulares, satelitales, radio con licencia o redes compartidas saturadas, importa mucho. Cada byte se paga, ya sea en dinero o en latencia. Los alias de métricas de Sparkplug son la respuesta de la especificación: enviar el nombre una vez y después referirse a él por un número.
Cómo funcionan los alias de métricas de Sparkplug
El mecanismo tiene tres reglas.
- En el NBIRTH (para las métricas de nivel de nodo) o el DBIRTH (para las métricas de dispositivo), cada métrica se envía con su
namey con unalias, un entero sin signo de 64 bits. - En los mensajes NDATA, DDATA, NCMD y DCMD posteriores, la métrica se envía solo con el
alias. El camponamese omite. - Los alias deben ser únicos dentro del ámbito de un edge node. Dos métricas del mismo edge node, aunque pertenezcan a dispositivos distintos, no pueden compartir alias.
Una aplicación host primaria o cualquier otro consumidor construye una tabla de búsqueda al recibir el BIRTH. A partir de ahí, cada métrica DATA que llega con un alias se resuelve de nuevo a su nombre completo mediante esa tabla.
Esta es la misma métrica en ambos tipos de mensaje, mostrada como la estructura Protobuf decodificada:
DBIRTH spBv1.0/plant1/DBIRTH/edge-07/filler-02
metric { name: "Infeed/Motor1/Current" alias: 12 datatype: Float float_value: 4.81 }
metric { name: "Infeed/Motor1/Running" alias: 13 datatype: Boolean boolean_value: true }
DDATA spBv1.0/plant1/DDATA/edge-07/filler-02
metric { alias: 12 datatype: Float float_value: 4.93 timestamp: 1792137600123 }
La métrica del DDATA no lleva ningún nombre. Sin el DBIRTH, un consumidor tiene un float y el número 12, y nada más.
Lo que los alias no cambian
Los alias solo sustituyen el nombre. El tipo de datos, el valor, la marca de tiempo, las propiedades de calidad y los metadatos funcionan exactamente igual. Los topics tampoco cambian: estos alias no tienen nada que ver con los topic aliases de MQTT 5, que acortan la cadena del topic a nivel de protocolo. Ambos pueden coexistir, pero son funciones independientes definidas por especificaciones distintas. Si quieres la versión a nivel de MQTT, consulta la sección sobre topic aliases de nuestra guía de funciones de MQTT 5.
Nombres frente a alias: ventajas e inconvenientes
| Aspecto | Nombres en cada mensaje DATA | Alias de métricas de Sparkplug |
|---|---|---|
| Tamaño del payload | Crece con la longitud del nombre | Pequeño y prácticamente constante por métrica |
| Facilidad de depuración | Cualquier mensaje capturado se describe a sí mismo | DATA no tiene sentido sin su BIRTH |
| Suscriptores tardíos | Pueden decodificar de inmediato | Deben esperar o solicitar un rebirth |
| Complejidad del consumidor | Sencilla | Debe mantener una tabla de alias por edge node |
| Riesgo de errores silenciosos | Bajo | Una tabla desactualizada asigna valores a la métrica equivocada |
| Uso ideal | LAN cableada, pocos tags | Enlaces de pago por consumo o limitados, muchos tags |
La fila del riesgo es la que importa. Un nombre erróneo salta a la vista. Un alias erróneo no: el consumidor escribe tranquilamente la corriente de un motor en un tag de temperatura, y el número parece plausible.
El ciclo de vida de los alias en la práctica
Los alias solo son válidos durante la vida de un único BIRTH. Entender cuándo termina esa vida evita la mayoría de los fallos.
- El NBIRTH lo reinicia todo. Cuando un edge node publica un nuevo NBIRTH, todas las tablas de alias de ese nodo se descartan y se reconstruyen a partir del nuevo NBIRTH y de los DBIRTH que le siguen. Un edge node puede asignar números de alias distintos tras un rebirth, así que un consumidor nunca debe conservar alias en caché entre births.
- El NDEATH invalida la tabla. Cuando el broker publica el mensaje will NDEATH del edge node, los consumidores deben marcar como obsoletas las métricas del nodo y dejar de confiar en la tabla de alias hasta el siguiente NBIRTH.
- Un DBIRTH puede añadir métricas de dispositivo. Un dispositivo puede hacer su propio rebirth, y los alias de sus métricas deben seguir siendo únicos en todo el edge node.
- Las solicitudes de rebirth recuperan el estado perdido. Un host que ve un alias que no conoce debe enviar un NCMD con la métrica
Node Control/Rebirtha true en lugar de adivinar. Nuestro artículo sobre el rebirth de Sparkplug explica ese flujo en detalle.
El número de secuencia también ayuda. Cada mensaje Sparkplug de un edge node lleva un seq de 0 a 255 que vuelve a empezar. Si un consumidor detecta un salto, puede que se haya perdido un BIRTH y debe solicitar un rebirth antes de volver a confiar en los alias. Las reglas de los mensajes BIRTH y DEATH se explican en certificados birth y death de Sparkplug.
Decodificar datos con alias en Python
El siguiente script se suscribe a todo el tráfico Sparkplug de un grupo, construye tablas de alias a partir de los mensajes NBIRTH y DBIRTH y resuelve las métricas DATA de vuelta a sus nombres. Usa sparkplug_b_pb2.py, el módulo Protobuf generado del proyecto Eclipse Tahu; cópialo junto al script e instala las dependencias con pip install paho-mqtt protobuf.
import paho.mqtt.client as mqtt
import sparkplug_b_pb2
BROKER = "broker.connectmq.com"
GROUP = "demo-7f3k2" # use your own unique group ID on the public broker
alias_tables = {} # edge_node_id -> {alias: name}
def on_connect(client, userdata, flags, reason_code, properties):
print("connected:", reason_code)
client.subscribe(f"spBv1.0/{GROUP}/#", qos=0)
def on_message(client, userdata, msg):
parts = msg.topic.split("/")
if len(parts) < 4:
return
msg_type, edge_node = parts[2], parts[3]
device = parts[4] if len(parts) > 4 else None
payload = sparkplug_b_pb2.Payload()
payload.ParseFromString(msg.payload)
if msg_type == "NBIRTH":
alias_tables[edge_node] = {} # a new NBIRTH resets all aliases
if msg_type in ("NBIRTH", "DBIRTH"):
table = alias_tables.setdefault(edge_node, {})
for m in payload.metrics:
if m.HasField("alias"):
if m.alias in table and table[m.alias] != m.name:
print(f"WARNING duplicate alias {m.alias} on {edge_node}")
table[m.alias] = m.name
print(f"{msg_type} {edge_node}/{device or ''}: {len(alias_tables[edge_node])} aliases")
return
if msg_type == "NDEATH":
alias_tables.pop(edge_node, None)
print(f"NDEATH {edge_node}: alias table cleared")
return
if msg_type in ("NDATA", "DDATA"):
table = alias_tables.get(edge_node)
for m in payload.metrics:
name = m.name
if not name and m.HasField("alias"):
if table is None or m.alias not in table:
print(f"UNKNOWN alias {m.alias} from {edge_node}, request a rebirth")
continue
name = table[m.alias]
value = getattr(m, m.WhichOneof("value")) if m.WhichOneof("value") else None
print(f"{edge_node}/{device or ''} {name} = {value} (seq {payload.seq})")
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="alias-decoder-7f3k2")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.loop_forever()
Para generar tráfico de prueba con alias, combínalo con el publicador de nuestro tutorial del simulador de edge node Sparkplug B. Ambos scripts funcionan con el servidor MQTT público gratuito de broker.connectmq.com. Recuerda que el servidor público es legible por cualquiera y está pensado solo para pruebas y prototipos, así que usa un group ID aleatorio y no publiques nunca datos reales de planta.
Depurar alias que no coinciden
La mayoría de los problemas con alias responden a unos pocos patrones. Usa esta checklist cuando los valores decodificados parezcan incorrectos.
- El consumidor arrancó después del BIRTH. En Sparkplug los mensajes BIRTH no son retained, así que un consumidor que se conecta más tarde solo ve DATA con alias. La solución es una solicitud de rebirth o una aplicación host primaria que provoque rebirths automáticamente.
- Caché desactualizada tras un rebirth. Si un consumidor mantiene su tabla antigua tras un nuevo NBIRTH, los valores acaban en nombres equivocados. Reinicia la tabla en cada NBIRTH, como hace el script anterior.
- Alias duplicados entre dispositivos. Algunas configuraciones edge numeran los alias por dispositivo empezando en 1. Dos dispositivos reclaman entonces el alias 1, lo que viola la regla de unicidad y corrompe cualquier consumidor que indexe las tablas por edge node.
- Alias cero tratado como ausente. En Protobuf, un campo con su valor por defecto puede ser indistinguible de un campo ausente según cómo lo compruebe el código. Empezar los alias en 1 evita toda una categoría de fallos.
- Mezcla de nombres y alias. Una métrica DATA puede incluir legalmente nombre y alias. Los consumidores deben dar preferencia al nombre cuando esté presente, y los edge nodes deben ser coherentes.
- Varios publicadores con el mismo edge node ID. Dos gateways configurados con el mismo grupo y edge node ID sobrescriben mutuamente sus births. El síntoma son alias que cambian de significado.
La inspección visual agiliza el proceso. ConnectMQ decodifica payloads Sparkplug B, en Protobuf o JSON, de modo que en el explorador de topics en vivo del portal puedes abrir el BIRTH y los mensajes DATA en paralelo y comprobar que el alias 12 es realmente la métrica que esperas. ConnectMQ también puede republicar datos Sparkplug B en topics ISA-95 legibles, por ejemplo spBv1.0/factory1/DDATA/line1/cnc1 en connectmq/factory1/production/line1/cnc1/telemetry, lo que ofrece a los consumidores que no usan Sparkplug una vía que no depende en absoluto de tablas de alias.
¿Cuándo conviene activar los alias?
Los alias son opcionales. Actívalos cuando el enlace entre el edge y el broker sea de pago por consumo o limitado, cuando haya muchos tags con nombres largos o cuando un único gateway publique muchas métricas a un ritmo alto. Mantén los nombres completos cuando estés creando prototipos, cuando muchos consumidores ligeros se suscriban directamente sin un host primario o cuando la facilidad de depuración importe más que los bytes.
Un camino intermedio funciona bien para muchos equipos: desarrollar y poner en marcha con nombres, medir el tamaño de los payloads con una carga realista y activar los alias solo en las plantas cuyos enlaces lo necesiten, como una explotación minera remota en el norte de Chile o un pozo con backhaul satelital. Como los alias se negocian por completo dentro del BIRTH, los consumidores que implementan correctamente la búsqueda no necesitan ningún cambio de configuración cuando activas la opción.
Para entender mejor dónde encaja Sparkplug en una arquitectura de planta, nuestra guía de MQTT para IoT industrial ofrece la visión general, y el artículo sobre el payload Sparkplug B explica cada campo que has visto en la salida decodificada anterior. La definición oficial del comportamiento de los alias es la especificación Eclipse Sparkplug.
Prueba los alias de Sparkplug en ConnectMQ
Ejecutar edge nodes y aplicaciones host contra un broker que controlas es la forma más rápida de validar la gestión de alias antes de que llegue a producción. ConnectMQ es un broker MQTT gestionado con MQTT 3.1.1 y 5.0, TLS en el puerto 8883 y decodificación de Sparkplug B integrada en el portal. Crea un broker en el plan Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y apunta tu edge node a él con el nombre de usuario, la contraseña y el client ID generados.
Preguntas frecuentes
¿Los alias de métricas de Sparkplug son obligatorios?
No. Los alias son opcionales en Sparkplug B. Un edge node puede enviar los nombres completos de las métricas en cada mensaje DATA, y los consumidores deben gestionar ambas formas.
¿Pueden cambiar los números de alias entre births?
Sí. Los alias solo son válidos hasta el siguiente NBIRTH de ese edge node. Los consumidores deben reconstruir sus tablas en cada NBIRTH y nunca conservar alias entre sesiones.
¿Qué debe hacer un host con un alias desconocido?
No debe adivinar. La respuesta correcta es enviar un NCMD con Node Control/Rebirth a true para que el edge node vuelva a publicar sus mensajes BIRTH y la correspondencia completa de alias.
¿Los alias de Sparkplug son lo mismo que los topic aliases de MQTT 5?
No. Los alias de métricas de Sparkplug sustituyen los nombres de las métricas dentro del payload, mientras que los topic aliases de MQTT 5 sustituyen la cadena del topic a nivel de protocolo. Son independientes y pueden usarse juntos.
