Nomenclatura de topics MQTT para OEE: un patrón para cada línea

Puntos clave

• Nombre los topics desde la planta hacia abajo: site, area, line, machine, luego el valor.
• Use IDs estables, no nombres para mostrar, en minúsculas y sin espacios.
• El MQTT simple le permite elegir el árbol. Sparkplug B fija su propio formato, colocando su jerarquía dentro de los IDs.
• Mantenga la marca temporal en el mensaje, sellada en la fuente, no en el topic.
• Publique solo cambios, de modo que el broker transporte eventos en lugar de ruido.

MQTT mueve los datos de planta como mensajes en topics nombrados. Para OEE, el nombre del topic es la forma en que cualquier sistema posterior encuentra el estado de una máquina y los contadores. Escoja un patrón desde la planta hacia abajo, úselo en cada línea, y nunca renombre un topic una vez que fluye información por él.

Fabrico, software de OEE y light MES con cámaras IA, registra el tiempo de inactividad automáticamente a partir de la señal de la máquina, sea cual sea la vía de ese señal. Cómo llegan los datos a Fabrico en su red se acuerda con el equipo técnico de Fabrico. Esta guía cubre el lado de nomenclatura neutral al proveedor.

¿Por qué importa el nombrado de topics MQTT para OEE?

• Los suscriptores filtran por topic. Un buen árbol permite que una suscripción recoja cada filler en un sitio.
• Los informes se unen por nombres. Los IDs de línea y máquina en los topics deben coincidir con los del calendario de turnos.
• La historia sigue al topic. Renombrar un topic hace que los datos del mes pasado parezcan pertenecer a otra máquina.

Un broker MQTT no comprueba los nombres por usted. El patrón que use la primera gateway se convierte en el patrón de la planta, así que decídalo antes de que la primera línea esté en producción.

¿Qué patrón deben seguir los topics OEE?

La mayoría de plantas siguen los niveles ISA-95, que también configuran la idea de un namespace unificado: un árbol compartido para todo el sitio. Las gateways de borde suelen construir exactamente ese árbol a partir de datos PLC.

Así, el estado del filler en la línea 4 reside en plant2/packaging/line4/filler/state. Nuestra guía sobre el unified namespace cubre la idea más amplia.

¿Qué reglas mantienen los nombres de topics limpios?

• Sólo minúsculas. Los topics MQTT distinguen mayúsculas, así que Line4 y line4 son dos topics diferentes.
• No espacios ni caracteres especiales. Use letras, dígitos y el guion bajo.
• Nunca use + o # en un nombre. Son los comodines que usan los suscriptores.
• No empiece con una barra o con $. Los topics que empiezan con $ están reservados para uso del broker.
• Use IDs que nunca cambien. "filler" sigue siendo "filler" cuando se reemplaza la máquina.
• Deje las unidades fuera del nombre. Ponga la unidad en el mensaje o en la lista de tags, para que un topic no cambie si cambia la unidad.
• Escriba el patrón en una página y entréguelo a cada integrador antes de que conecten una gateway.

¿Plain MQTT o Sparkplug B?

Con plain MQTT diseña todo el árbol usted mismo, como arriba. Sparkplug B añade una forma de topic fija, un formato de payload y estado de sesión. Sus topics siguen spBv1.0/group_id/message_type/edge_node_id/device_id, y la parte del namespace debe ser spBv1.0.

En Sparkplug, su jerarquía de planta entra en los IDs. El grupo podría ser plant2_packaging, el edge node line4_gw y el device filler. Los valores viajan como métricas dentro del mensaje, no como topics separados. Nuestra guía de Sparkplug B explica sus mensajes de birth y death.

Ejemplo práctico: topics para una línea

Línea de ejemplo (números ilustrativos, no un cliente). La línea 4 tiene tres máquinas: un filler, un capper y un labeller. Cada una publica cinco valores: state, total_count, reject_count, fault_code y sku. Eso es 3 x 5 = 15 topics.

• plant2/packaging/line4/filler/state
• plant2/packaging/line4/capper/fault_code
• plant2/packaging/line4/labeller/total_count

Una suscripción a plant2/packaging/+/+/state recoge el estado de cada máquina en packaging. El comodín + coincide exactamente con un nivel.

Ahora el volumen. Polling de los 15 valores cada segundo envía 15 x 3,600 = 54,000 mensajes por hora.

En lugar de eso, publique estados, fallos y SKUs solo cuando cambien, alrededor de 100 mensajes por hora. Envíe los dos contadores de cada máquina cada 10 segundos: 3 x 2 x 360 = 2,160 mensajes. Eso son aproximadamente 2,260 mensajes por hora, alrededor de 96% menos.

¿Qué errores de nomenclatura causan problemas después?

• Nombres para mostrar en los topics, como "Filler (new)", que cambian cuando alguien edita una pantalla.
• Renombrar una línea tras un cambio de layout, de modo que su historial se divide en dos.
• Mezcla de idiomas o escrituras entre plantas, de modo que un informe de grupo no puede unirlas.
• Un topic gigante que lleva toda la planta en un solo mensaje, que nadie puede filtrar.
• No hay timestamp en el mensaje, de modo que los eventos obtienen la hora de llegada en lugar de la hora en que ocurrieron.

Publicar solo cambios es la idea detrás de report by exception. Nuestro artículo sobre report by exception vs polling lo cubre, y MQTT in manufacturing cubre el protocolo.

¿Dónde encaja Fabrico?

Fabrico es una Manufacturing Performance Platform habilitada con visión por ordenador. OEE y light MES vienen primero, sobre un conjunto único de nombres de líneas y máquinas.

• Registro automático del tiempo de inactividad a partir de la señal de la máquina.
• El operario confirma la razón con un solo toque, porque un topic lleva un estado, no una causa.
• OEE en vivo por línea y turno, con cada pérdida valorada en dinero.
• Una vista única entre plantas, que solo funciona cuando los nombres coinciden.

Es la capa OEE de un light MES. Empiezas en una línea, con una línea base y una fecha de decisión acordada de antemano. No hay plan gratuito y no hay niveles: cada planta recibe una cotización.

Preguntas frecuentes

¿Qué es una convención de nombres de topics MQTT?

Es la regla fija de la planta sobre cómo se construyen los topics, como site, area, line, machine y value, en ese orden. Cada gateway la sigue. Así cualquier sistema puede encontrar los datos de una máquina por nombre, y un informe puede unir líneas y plantas sin mapeo manual.

¿Deben los topics MQTT seguir ISA-95?

Para OEE es una elección sensata. Los niveles ISA-95 de site, area, line y machine coinciden con la forma en que las plantas se gestionan y reportan. La mayoría de diseños de unified namespace usan ese orden. Lo más importante es elegir un patrón y usarlo en todas partes.

¿Cuál es el formato de topic de Sparkplug B?

Los topics Sparkplug B siguen spBv1.0, luego el group ID, el message type, el edge node ID y el device ID. La parte del namespace debe ser spBv1.0. Su jerarquía de planta entra en los IDs de group, node y device, y los valores viajan como métricas en el mensaje.

¿Cómo funcionan los comodines MQTT?

Los suscriptores pueden usar dos comodines. Un signo más coincide exactamente con un nivel, así que plant2/packaging/+/filler/state coincide con el filler en cada línea de packaging. Un signo almohadilla coincide con todos los niveles restantes, así que plant2/# coincide con todo en ese sitio.

¿Debe ir el timestamp en el topic o en el mensaje?

En el mensaje. Los topics indican de dónde vienen los datos; no deben cambiar con cada evento. Selle cada evento con el reloj del PLC o del gateway en el momento en que ocurre. Ponga esa hora en el payload, para que un mensaje retrasado conserve su hora real.

Traiga su árbol de topics a una demo

Traiga la lista de líneas de su planta. Mostraremos las paradas y contadores de una línea, nombrados según cómo funcione su planta.

Request a demo · Contact us