MQTT Topic Naming for OEE: One Pattern for Every Line

Key takeaways

• Name topics from the plant down: site, area, line, machine, then the value.
• Use stable IDs, not display names, in lower case and without spaces.
• Plain MQTT lets you choose the tree. Sparkplug B fixes its own form, with your hierarchy inside the IDs.
• Keep the timestamp in the message, stamped at the source, not in the topic.
• Publish changes only, so the broker carries events instead of noise.

MQTT moves plant data as messages on named topics. For OEE, the topic name is how every later system finds a machine's state and counts. Pick one pattern from the plant down, use it on every line, and never rename a topic once data flows on it.

Fabrico, OEE and light MES software with AI cameras, logs downtime automatically from the machine signal, however that signal travels. How data reaches Fabrico on your network is agreed with Fabrico's technical team. This guide covers the vendor-neutral naming side.

Why does MQTT topic naming matter for OEE?

• Subscribers filter by topic. A good tree lets one subscription collect every filler in a site.
• Reports join on names. Line and machine IDs in topics must match those in the shift calendar.
• History follows the topic. Rename a topic and last month's data seems to belong to a different machine.

An MQTT broker does not check names for you. Whatever pattern the first gateway uses becomes the plant's pattern, so decide it before the first line goes live.

Which pattern should OEE topics follow?

Most plants follow the ISA-95 levels, which also shape the idea of a unified namespace: one shared tree for the whole site. Edge gateways often build exactly that tree from PLC data.

So the filler's state on line 4 lives at plant2/packaging/line4/filler/state. Our guide to the unified namespace covers the wider idea.

Which rules keep topic names clean?

• Lower case only. MQTT topics are case-sensitive, so Line4 and line4 are two different topics.
• No spaces and no special characters. Use letters, digits and the underscore.
• Never use + or # in a name. They are the wildcards subscribers use.
• Do not start with a slash or with $. Topics starting with $ are kept for the broker's own use.
• Use IDs that never change. "filler" stays "filler" when the machine is replaced.
• Keep units out of the name. Put the unit in the message or in the tag list, so a topic does not change when a unit does.
• Write the pattern down on one page, and give it to every integrator before they connect a gateway.

Plain MQTT or Sparkplug B?

With plain MQTT you design the whole tree yourself, as above. Sparkplug B adds a fixed topic form, a payload format and session state. Its topics follow spBv1.0/group_id/message_type/edge_node_id/device_id, and the namespace must be spBv1.0.

In Sparkplug, your plant hierarchy goes into the IDs. The group could be plant2_packaging, the edge node line4_gw and the device filler. The values travel as metrics inside the message, not as separate topics. Our guide to Sparkplug B explains its birth and death messages.

Worked example: topics for one line

Sample line (illustrative numbers, not a customer). Line 4 has three machines: a filler, a capper and a labeller. Each publishes five values: state, total_count, reject_count, fault_code and sku. That is 3 x 5 = 15 topics.

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

One subscription to plant2/packaging/+/+/state collects the state of every machine in packaging. The + wildcard matches exactly one level.

Now the volume. Polling all 15 values every second sends 15 x 3,600 = 54,000 messages an hour.

Instead, publish states, faults and SKUs only when they change, around 100 messages an hour. Send the two counters on each machine every 10 seconds: 3 x 2 x 360 = 2,160 messages. That is roughly 2,260 messages an hour, about 96% fewer.

Which naming mistakes cause trouble later?

• Display names in topics, such as "Filler (new)", which change when someone edits a screen.
• Renaming a line after a layout change, so its history splits in two.
• Mixed languages or spellings across plants, so a group report cannot join them.
• One giant topic carrying the whole plant in one message, which nobody can filter.
• No timestamp in the message, so events get the time they arrived instead of the time they happened.

Publishing changes only is the idea behind report by exception. Our article on report by exception vs polling covers it, and MQTT in manufacturing covers the protocol.

Where does Fabrico fit?

Fabrico is a computer vision enabled Manufacturing Performance Platform. OEE and light MES come first, on one set of line and machine names.

• Automatic downtime logging from the machine signal.
• The operator confirms the reason in one tap, because a topic carries a state, not a cause.
• OEE live by line and shift, with every loss priced in money.
• One view across plants, which only works when names line up.

It is the OEE layer of a light MES. You start on one line, with a baseline and a decision date agreed in advance. There is no free plan and there are no tiers: each plant gets a quote.

Frequently asked questions

What is an MQTT topic naming convention?

It is the plant's fixed rule for how topics are built, such as site, area, line, machine and value, in that order. Every gateway follows it. That way any system can find a machine's data by name, and a report can join lines and plants without manual mapping.

Should MQTT topics follow ISA-95?

For OEE it is a sensible choice. The ISA-95 levels of site, area, line and machine match how plants are run and reported. Most unified namespace designs use that order. What matters most is choosing one pattern and using it everywhere.

What is the Sparkplug B topic format?

Sparkplug B topics follow spBv1.0, then the group ID, the message type, the edge node ID and the device ID. The namespace part must be spBv1.0. Your plant hierarchy goes into the group, node and device IDs, and the values travel as metrics in the message.

How do MQTT wildcards work?

Subscribers can use two wildcards. A plus sign matches exactly one level, so plant2/packaging/+/filler/state matches the filler on every packaging line. A hash sign matches all remaining levels, so plant2/# matches everything in that site.

Should the timestamp go in the topic or the message?

In the message. Topics name where data comes from; they should not change with every event. Stamp each event with the PLC or gateway clock at the moment it happens. Put that time in the payload, so a delayed message keeps its real time.

Bring your topic tree to a demo

Bring your plant's line list. We will show one line's stops and counts, named the way your plant runs.

Request a demo · Contact us