MQTT topic design for factories: a unified namespace you can maintain

What a unified namespace is, and what it is not

A unified namespace (UNS) is an agreed, hierarchical naming structure in which every system publishes the current state of what it knows about the business, and every consumer looks for that state in one predictable place. It is most often implemented on an MQTT broker. It is a design discipline, not a product: a broker with inconsistent topic names is not a unified namespace, however modern the tooling.

A hierarchy that follows the plant

The most common structure follows the ISA-95 equipment hierarchy: enterprise, site, area, line (work center) and cell (work unit), followed by the asset and the thing being measured. A topic then reads like an address:

enterprise/site/area/line/cell/asset/metric
acme/istanbul/packaging/line1/filler/oee

The names above are placeholders. Use the vocabulary your organization already uses, and decide the number of levels once. Every level should answer a question a reader will actually ask: where is it, what is it, what is being measured.

Topic or payload?

The topic identifies what the message is about. The payload carries the data. Keep them apart:

• In the topic: stable identity such as site, line, asset and metric name.
• In the payload: the value, its unit, the timestamp and a quality indicator.

Putting changing values or timestamps into topic names creates an unbounded number of topics and makes subscriptions impossible. Follow these naming rules:

• Use lowercase letters, digits and hyphens or underscores; avoid spaces and special characters.
• Do not start a topic with /, which creates an empty first level.
• Remember that topics are case sensitive, so Line1 and line1 are different topics.
• Never publish to topics beginning with $; brokers reserve them (for example $SYS).
• Wildcards (+ and #) are for subscribing only, never for publishing.

Payload design

A small, consistent JSON object serves most needs:

{
  "value": 79.2,
  "unit": "%",
  "ts": "2026-10-03T09:15:00Z",
  "quality": "good"
}

Use UTC timestamps in ISO 8601 form, one schema per metric type and a version you can evolve. If you need a standard that also specifies device birth and death messages and state management, look at Sparkplug B, which defines a topic namespace and a binary payload for that purpose.

Retained messages and last will

Two MQTT features make a namespace feel like a live picture of the plant:

• Retained messages. The broker keeps the last retained message on each topic and delivers it immediately to new subscribers, so a dashboard that starts up sees current values at once instead of waiting for the next change. Publishing an empty retained message to a topic clears it.
• Last will and testament. A client registers a will message when it connects. If the client disappears without a clean disconnect, the broker publishes it. A common pattern is a retained online message on a status topic when the client connects, and a retained offline will message, so consumers can tell a silent signal from a dead producer.

Choose delivery guarantees deliberately: the trade-offs between QoS 0, 1 and 2 are explained in MQTT QoS levels for industrial messaging.

Anti-patterns to avoid

• Raw and modeled data on the same branch. Keep device-level tags (raw/…) apart from curated, contextualized data, so consumers know which they are reading.
• One-off names. Topics invented per project that nobody else can predict.
• Unbounded wildcard subscriptions. A subscription to # in production is a load test of your own system.
• No ownership. Every branch needs a named owner who decides what may be published there.

Governance is the real work

• Publish the naming convention and the payload schemas in one place, and treat them as part of your industrial data contract.
• Review new topics before they go live, the way you would review a new database table.
• Apply broker access control per branch: who may publish, who may subscribe.
• Plan for the broker itself: clustering, persistence and monitoring are covered in production-grade MQTT infrastructure.