Guide

Building Your First Unified Namespace

A practical implementation guide for structuring MQTT topic hierarchies using the ISA-95 model — covering topic design, Sparkplug B alignment, and the failure modes that break UNS deployments at scale.

Before you start — what you need

An MQTT broker: Mosquitto for testing; HiveMQ or EMQX for production (see note below)
A protocol translator connected to at least one data source: Ignition with Cirrus Link MQTT modules, Kepware with an MQTT client plug-in, or HighByte Intelligence Hub
Your facility's physical layout documented: site name, production areas, lines, cells, and individual device names
MQTT Explorer (free) for inspecting the topic tree
Write access to your MQTT broker configuration and read access to at least one PLC or data source

Broker note

Mosquitto is sufficient for testing and single-site pilots. A production UNS that serves as the enterprise-wide single source of truth requires a broker with distributed clustering and policy-based topic security. HiveMQ and EMQX are the two most common production choices. A UNS that outgrows its broker requires a migration that touches every consuming application — plan the upgrade before go-live, not after.

The problem this solves

Most IIoT deployments start the same way. An edge gateway connects to a PLC, data starts flowing, and someone publishes it to an MQTT broker under a topic like factory/machine1/temp or plant/data/sensor_42. This works for one machine. It breaks at ten. By the time a facility has fifty data sources publishing to an unstructured broker, the data is effectively unusable — topics are inconsistent, asset context is missing, and any analytics platform consuming the data has to maintain a separate mapping table just to know what it is looking at.

The Unified Namespace solves this by making the topic structure itself carry the asset context. When a message arrives at Acme/Chicago/Assembly/Line3/Cell2/Welder_A/Temperature, a consuming application knows exactly what it is looking at without a lookup table. The data is self-describing.

The ISA-95 topic hierarchy

ISA-95 defines a role-based equipment hierarchy for integrating enterprise and control systems. The standard's formal levels run from Enterprise down to Work Unit. In practice, the IIoT industry has converged on a six-level adaptation that maps cleanly onto MQTT topic paths:

Enterprise / Site / Area / Line / Cell / Device

This is not a verbatim ISA-95 specification — "Device" is not a formal ISA-95 level, and Line and Cell are parallel concepts in the standard rather than a strict hierarchy. It is the common adaptation that practitioners use, and it is what most UNS tooling and documentation assumes.

Applied to a real facility:

Acme /                          ← Enterprise (company name)
  Chicago /                     ← Site (facility location)
    Assembly /                  ← Area (production area or department)
      Line3 /                   ← Line (production line)
        Cell2 /                 ← Cell (work cell or machine group)
          Welder_A /            ← Device (individual asset)
            Status              ← Telemetry (dynamic — changes continuously)
            Temperature
            CycleCount
            FaultCode
            _attr/              ← Attributes (static — rarely changes)
              SerialNumber
              AssetID
              MaxRatedTemp

At the tag level, mature UNS architectures split tags into two subtypes. Telemetry covers dynamic data that changes continuously. Attributes cover static data that rarely changes. Keeping them separate prevents consuming applications from processing static data on every update cycle.

Telemetry (dynamic)

Status (running, faulted, idle)
Temperature
CycleCount
FaultCode
OEE, throughput, rejects

Attributes (static)

SerialNumber
AssetID
MaxRatedTemp
InstallDate
Manufacturer, Model

Case sensitivity

MQTT topics are case-sensitive. Line3 and line3 are two completely different topics to a broker. Pick a naming convention — CamelCase or underscores, consistent capitalization — before any data flows, and enforce it across every gateway and every engineer configuring the system.

Implementation steps

Step 1 Map your physical hierarchy before touching the broker

Write out your Enterprise, Site, Area, Line, Cell, and Device names in a spreadsheet before configuring anything. Decisions made here are hard to undo once data starts flowing. Use consistent naming: no spaces, no special characters, consistent capitalization throughout. This is your UNS schema — treat changes to it with the same discipline you would apply to a production database schema.

Step 2 Define your tag list per device

For each device in your hierarchy, list every data point you intend to publish and classify each as telemetry or attribute. Group telemetry tags by function: Status (running, faulted, idle), Performance (cyclecount, OEE, throughput), Quality (rejects, rework), Maintenance (temperature, vibration, runtime hours). This becomes your UNS data dictionary — the authoritative reference for what the namespace contains and what each tag means.

Step 3 Configure your protocol translator to publish to the correct topics

In Ignition with Cirrus Link MQTT Transmission, map each tag to its full ISA-95 path in the topic configuration. In Kepware with an MQTT client plug-in, set the topic string in the channel or device configuration. In HighByte, topic mapping is handled in the data flow configuration.

The broker enforces nothing — your translator is solely responsible for publishing to the correct path. If the translator publishes to the wrong path, the broker accepts it without complaint and your namespace becomes inconsistent.

Step 4 Align Sparkplug B with your UNS (if applicable)

Sparkplug B provides robust device state management via Birth and Death certificates, compressed protobuf payloads, and sequence numbering. It is worth using. However, Sparkplug B has a rigid, unalterable topic specification:

spBv1.0 / [GroupID] / [MessageType] / [EdgeNodeID] / [DeviceID]

This format does not match the ISA-95 hierarchy built in Steps 1 to 3. If you publish raw Sparkplug B topics to your broker, your topic tree will be structured around edge node IDs rather than physical asset locations, breaking the UNS model. Do not attempt to add custom subtopics to a Sparkplug B path — the specification does not permit it.

The resolution depends on your tooling. In Ignition with Cirrus Link MQTT Transmission, use the Custom Namespace feature to map Sparkplug payloads so they resolve into your ISA-95 topic paths rather than the default Sparkplug header structure. In HighByte, configure the Intelligence Hub to consume raw or Sparkplug-encoded data from your edge sources and re-publish into your clean ISA-95 paths. Sparkplug handles state management and payload encoding under the hood; your UNS topic tree stays clean and physical-hierarchy-aligned.

Step 5 Verify with MQTT Explorer before connecting analytics

Connect MQTT Explorer to your broker and review the full topic tree with all gateways publishing simultaneously. Look for:

Inconsistent naming for the same asset across different gateways (Welder_A vs WelderA vs welder-a)
Missing hierarchy levels — data publishing directly to Chicago/Welder_A without Area, Line, and Cell levels
Sparkplug topics appearing in the raw spBv1.0/ namespace instead of mapped ISA-95 paths
Retained messages from test sessions cluttering the topic tree

Fix every discrepancy before connecting any analytics platform or historian. Downstream consumers build data models from the topic structure they discover at connection time. A consumer that connects to a malformed namespace will build a malformed model.

Where this breaks

Naming convention drift

Two engineers configure edge gateways independently and use different conventions for the same physical asset — Line3/Cell2/Welder_A from one gateway, line_3/cell_2/welderA from another. The broker accepts both without complaint. The result is two fragmented logical twins for a single physical asset publishing to different topic paths. Any analytics platform consuming the UNS builds separate models for what it believes are two different assets. The physical Welder A has no coherent digital representation. Catch this in Step 5 before any consuming application connects.

Sparkplug B birth certificate failures

If the edge node does not publish a correct Birth Certificate on reconnect after a restart, consuming applications may continue showing last known values rather than flagging the device as offline. Verify that your MQTT client is configured to publish a Last Will and Testament (Death Certificate) on unexpected disconnect and a Birth Certificate on every reconnect. Test this explicitly by restarting the edge gateway while a consumer is connected and confirming the consumer detects the offline state.

Late-stage hierarchy renaming

Once an analytics platform, dashboard, or historian is consuming from a UNS path, renaming that path breaks every downstream consumer. Treat the hierarchy as a production schema — changes require a migration plan that accounts for every consuming application, not a quick find-and-replace in the translator configuration.

Mosquitto in production

Mosquitto works for pilots and single-site deployments. At enterprise scale with multiple sites publishing simultaneously, the lack of clustering and topic-level access control becomes a hard constraint. Plan the broker upgrade before the UNS reaches production scale. Migrating broker infrastructure after analytics consumers are connected is a significantly more disruptive project than upgrading before go-live.

Related: Where the IIoT market is heading covers how UNS adoption is reshaping the vendor landscape. The vendor index connectivity section covers the platforms referenced in this guide.