How to implement a Unified Namespace: five phases from pilot line to plant

A Unified Namespace is rolled out in five phases: stand up the hub, pilot one line, move existing consumers onto the namespace, add history, and only then allow commands back to machines. New to the idea? Start with what a Unified Namespace is. The rules to write down first, from topic names to payloads, security and ownership, are in this article too.

From one pilot line to the whole plant

Most brownfield plants do not suffer one dramatic integration failure. They pay a steady "integration tax": every new consumer (historian, MES, ERP, analytics) gets its own connection to the same controllers, its own mapping and its own fragile dependency. With 3 consumers that is tolerable; with 30 it is not, because the number of point-to-point links grows with every producer times every consumer.

A Unified Namespace changes the topology: producers publish once to a shared, governed namespace, and consumers subscribe to the branches they need. The hard part is not the broker. It is moving a running plant onto that structure one step at a time, with the namespace rules agreed before the second line joins.

Before phase 1: what has to be decided

Three decisions shape every phase that follows. Here is the short version; the sections after this one turn them into written rules.

• The hierarchy. Most teams derive it from ISA-95: Enterprise / Site / Area / Line / Cell / Device, for example GearCo/Munich/Stamping/Line1/Press3/metrics/HydraulicPressure. Fix the levels and the spelling rules (Line1, not line-1 in one place and Linie_1 in another) before the pilot, and name an owner who approves changes, the way a database schema owner would.
• The payload contract. Value, timestamp from the source, quality and unit travel together. Plain JSON with a documented schema is often enough for a single-site pilot; Sparkplug B earns its complexity with multi-vendor, multi-site or third-party consumers. In Proxus, Sparkplug B is an outbound format: the namespace can be published as Sparkplug B to Sparkplug-aware consumers, and Proxus does not act as a Sparkplug host for other nodes' traffic.
• The bridge at the edge. Controllers speak Modbus TCP, EtherNet/IP, Siemens S7, Omron FINS and others, not MQTT. An Edge Gateway on the plant network reads them, maps raw addresses such as %MD400 to namespace paths, and buffers data while the link to the hub is down, sending it in order with the original timestamps when the link returns (store and forward). Check your controllers against the supported drivers before you plan the pilot.

Decide the scope before the structure

Before drawing a tree, answer three questions in writing.

What belongs in the namespace? Current operational state: process values, machine states, counts, alarms, the active order or recipe, maybe the shift. It is a poor place for bulk historical data, large files, or transactional records that already have a system of record (an ERP purchase order should stay in the ERP; its number can be published as context).

Who is the first consumer? A namespace designed for "everyone, eventually" is designed for nobody. Pick one consumer that will use it in the first months, for example an OEE dashboard or a maintenance system, and design for its needs first. The second and third consumers will show you what was missing.

Is the namespace the source of truth, or a view of it? For live values it is usually the freshest copy, but the PLC remains the authority. For context such as the current order, the authority is the MES or ERP. Write down which system is authoritative for each kind of data. When two systems disagree, this list decides who is right.

Design the hierarchy

Start from ISA-95, then stop adding levels

The ISA-95 equipment hierarchy (enterprise, site, area, line or process cell, unit or equipment) is the usual starting point, and for good reason: it is a standard, it maps to how plants are organized, and most people recognize it. Use it, but resist adding levels for things that are not physical locations.

A common mistake is to fold several dimensions into the path:

Acme/Izmir/Packaging/Line3/Filler/Production/Shift2/Order_44120/Count

Shift and order are not places. They change every few hours, and putting them in the path means the same physical value moves to a new topic every shift. Consumers that subscribed to the old path stop receiving data, and history is split across paths. Publish the shift and order as their own values, or as context fields in the payload, and keep the path stable:

Acme/Izmir/Packaging/Line3/Filler/Count
Acme/Izmir/Packaging/Line3/_context/Order
Acme/Izmir/Packaging/Line3/_context/Shift

Rule of thumb: a path segment should change only when equipment is physically moved, renamed or replaced.

Allow levels to be empty

Not every site has areas, and not every machine belongs to a cell. Decide whether an empty level is skipped (shorter path) or filled with a placeholder. Both work; mixing them does not. Skipping is easier to read, but it means a wildcard such as +/+/+/Count matches different depths at different sites. Placeholders keep the depth constant, which makes wildcards predictable, at the cost of paths like Acme/Izmir/_none/Line3.

In Proxus, each device carries its place as five optional levels (enterprise, site, area, process cell, equipment module), and empty levels are left out of the topic. That is a reasonable choice, but it is why the MQTT documentation warns that a five-+ wildcard only matches devices with all five levels set.

Separate categories under the device

Under each device or machine node, separate the kinds of data. A minimal split:

Proxus publishes telemetry/<tag> for values and state/_status and state/_lastSeen for the device's state, with the state topics retained. The exact names matter less than the fact that every publisher uses the same ones.

Version the root

Put a version segment at the root (v1/...) from day one. It costs four characters. When you need to change the structure in a way that would break consumers, you can publish v2/... alongside v1/... for a migration period instead of breaking everyone at once. Proxus topics start with v1/ for this reason.

Write the naming rules

Naming disputes are the most common reason a UNS loses credibility. Line1, line_1, L1 and Linie1 in the same tree mean every consumer needs a lookup table, which is exactly the problem the namespace was supposed to remove. Write the rules down before the second site joins.

A short rule set that holds up:

• Allowed characters: letters, digits, _ and -. No spaces, no / inside a name, no + or # (they are MQTT wildcards), no $ at the start (reserved for broker system topics).
• Case: pick one convention and keep it. MQTT topics are case-sensitive: Line1 and line1 are two different topics.
• Language: one language for structural names, even in a multilingual company. Display names can be translated in the user interface; topic names should not be.
• Units do not go in names. Temperature, not Temperature_C. The unit belongs in the payload, where it can be read by a program.
• Names describe what, not where it came from. Speed, not DB40_DBD12. The PLC address is metadata for the people who maintain the connection.
• Reserved prefixes: decide on a prefix (such as _) for system-generated topics so they never collide with tag names.

Enforce the character rule mechanically. Proxus, for example, replaces every character outside letters, digits, _ and - with _, so Lyon Foods Plant becomes Lyon_Foods_Plant and case is kept. Whatever your platform does, document it, because consumers need to know that the name they see in the UI is not always the exact topic segment.

Define the payload contract

The topic tells you where a value belongs. The payload tells you what it is. A consumer should be able to process a message without asking anyone, which means every message on a telemetry topic should carry the same fields.

A practical minimum:

{
  "ts": "2026-10-16T08:14:22.410Z",
  "value": 72.4,
  "dataType": "Double",
  "unit": "°C",
  "quality": "Good"
}

Timestamp. Use UTC, ISO 8601, with milliseconds. Write down which time it is: when the sensor measured it, when the PLC stored it, or when the gateway read it. These can differ by seconds on a polled connection, and for event sequencing that matters. Proxus uses the time the gateway read the value.

Value and type. Publish the value in its natural JSON type (number, boolean, string) and state the type explicitly. A consumer that receives 1 cannot tell whether it is an integer count or a boolean that a PLC stored as a word.

Unit. Carry it in every message, or in a retained metadata topic per tag. Having it in every message costs a few bytes and saves a class of errors.

Quality. Decide what a consumer sees when a read fails. There are two honest options: publish the message with a Bad quality and no trustworthy value, or publish nothing and let the state topic show that the device is offline. The dishonest option is to publish the last good value again with a fresh timestamp. Proxus takes the second option on its telemetry topics: values that could not be read are not published there, and the device page shows the read errors.

Context. Repeating the full place (enterprise, site, area) in every payload makes messages larger, but it lets a consumer that stored messages without topics still know where they came from. Many teams publish a slim payload on per-tag topics and a richer summary message per device. Proxus does this with a _summary topic that holds the latest value of every tag of a device, and an option to add a context object to each tag message.

JSON or Sparkplug B. JSON is easy to read, easy to debug and supported by everything. Sparkplug B adds a defined session model (birth and death messages), typed metrics and compact Protocol Buffers payloads. Choose Sparkplug B when several vendors' systems must interoperate without a custom contract, or when bandwidth is constrained; choose JSON when you control both ends and value readability. You can offer both: Proxus publishes JSON by default and can publish Sparkplug B instead on a gateway's broker, and it can send Sparkplug B to outbound consumers. It does not ingest Sparkplug B from other nodes.

Make state explicit

A namespace is useful only if a consumer can tell the difference between "the value is 0" and "we have not heard from this machine for an hour."

Three mechanisms cover most of this:

1. Retained status topics. A retained state/_status message with Online or Offline means a consumer that connects later learns the status at once, without waiting for the next change.
2. Last-seen time. A retained state/_lastSeen with the time of the latest reading lets a consumer decide for itself whether a value is stale. Different consumers have different tolerances: a dashboard may accept a minute, an alarm rule may not.
3. Last Will and Testament. An MQTT client can register a message that the broker publishes if the client disconnects without saying goodbye. Use it for publishers that connect directly to the broker, so their status flips to offline when they vanish.

Never retain telemetry and events by default. A retained alarm is replayed to every new subscriber as if it just happened.

Plan for more than one broker

In a single plant, one broker is simple. Across several sites, you have to decide where the namespace physically lives.

• One central broker. Every site publishes to it. Simple to reason about, but every site depends on the WAN for its own namespace, and the central broker sees all traffic.
• A broker per site, bridged. Each site has its own broker; a bridge forwards selected branches to a central broker. Sites keep working when the WAN is down. The cost is bridge configuration and the risk of loops or duplicated branches.
• A broker per gateway. Each edge gateway runs a broker for the devices it reads. Local consumers connect to it directly, and the central view is assembled elsewhere.

Proxus follows the third pattern: each gateway runs its own MQTT broker and publishes only its own devices, while every value also travels to the hub over a separate, buffered message server. The hub is where history, dashboards and the UNS Explorer show the whole plant; Unified Namespace in Proxus shows that view. Whichever pattern you choose, write down which broker is authoritative for which branch, so two publishers never fight over the same topic.

Secure the namespace

A namespace that anyone on the network can read is a map of your plant and its current state. Treat it accordingly.

• Encrypt the transport. Use MQTT over TLS (port 8883 by convention) and have clients verify the broker certificate against a CA you control. Keep the plain port only for devices that cannot do TLS, and close it when you can.
• Authenticate every client. No anonymous connections in production. Prefer one credential per system over a shared password, so you can revoke one consumer without touching the others.
• Limit what each identity can see. Broker-level access control lists (ACLs) differ widely between brokers; some support per-topic rules, some do not. Know what yours supports. In Proxus, the gateway's broker accepts the gateway's master token or a device's own token and has no per-topic rights, so the master token should go only to trusted systems. Per-branch visibility is enforced in the platform instead: UNS permissions allow or deny a path for a role, and they apply to people, integrations and AI clients alike.
• Separate reading from writing. Publishing a value into the namespace and writing a setpoint to a machine are different acts. Do not let a topic in the namespace become an unaudited path to a controller. If writes are needed, give them their own command model, authorization, validation and audit trail.

Assign ownership

Every branch of the tree needs an owner who approves changes to it. In practice:

Treat a structural change like a database schema migration: write it down, announce it to consumers before it happens, run old and new in parallel when you can, and remove the old path only when no consumer still uses it.

The five phases

Building a Unified Namespace is a sequence of small, reversible steps, not a rip-and-replace weekend project. Each phase below leaves the plant running and gives the next one something to build on.

Test it like a product

A namespace is infrastructure that other systems depend on. Test it as such.

• Contract tests. A small script that subscribes to v1/# for an hour and reports every topic that breaks a naming rule, every payload with a missing field and every unexpected type change. Run it after every change.
• Stale-data test. Disconnect a device on purpose. Check that its status changes, that its last-seen time stops, and that no consumer keeps showing the old value as current.
• Outage test. Cut the link between a site and the centre. Check what local consumers still see, what the central view shows, and whether data from the outage arrives afterwards with its original timestamps. How data flows describes what Proxus does in this case.
• Consumer onboarding test. Give the namespace documentation to someone who has never seen it and ask them to subscribe to all temperatures of one line. If they need to ask a question, the documentation or the structure has a gap.

A checklist before you call it done

• The hierarchy is written down, with an example path for every level and the rule for empty levels.
• The naming rules are written down and enforced by a tool, not by memory.
• Every telemetry payload carries time, value, type, unit and quality, and the meaning of the time is documented.
• Status and last-seen topics are retained; telemetry and events are not.
• The transport uses TLS, every client has its own credential, and you know what your broker can and cannot restrict per topic.
• Every branch has an owner, and structural changes follow a written process.
• At least two different consumers use the namespace without their own connection to the machines.

When this may not be suitable

• Lower-frequency telemetry may not justify full distributed complexity.
• Small single-line plants may prefer simpler architectures first.
• Strict legacy constraints may require phased adoption.
• Safety-critical closed-loop control should remain in PLC/Safety PLC layers.

Observed performance depends on workload shape, node capacity, and deployment design.

Frequently Asked Questions

How long does a UNS deployment take?

There is no honest universal duration. A pilot on a single production line (a few PLCs and the critical tags only) is bounded by namespace design, network and security approvals, gateway configuration and validation with the people who will use the data. Multi-site rollouts depend on protocol diversity, change windows and IT/OT governance maturity. Estimate from your own inventory.

Can I run UNS and SCADA simultaneously?

Yes, and you should during transition. The UNS does not require decommissioning your existing SCADA. It supplements it. Your SCADA simply becomes another consumer (subscriber) of the UNS data, as described in SCADA and Unified Namespace.

What happens to the UNS when the internet goes down?

A properly architected UNS is not internet-dependent for local operations. Edge Gateways continue publishing to a local or on-premise MQTT Broker. Cloud subscribers lose real-time visibility, but the Store and Forward mechanism ensures data-loss risk minimization. When connectivity resumes, buffered data replays chronologically.

How many MQTT topics can a Broker handle?

Broker and downstream capacity must be tested with the intended topic count, connection count, payload size, quality of service, retained state, persistence, clustering, and failure model. Start with critical tags, measure the complete path, and expand incrementally.

Is UNS suitable for brownfield (legacy) factories?

Absolutely - brownfield is the primary use case. Edge Gateways exist precisely to bridge controller protocols (Modbus TCP, Siemens S7, Omron FINS, EtherNet/IP) to MQTT without touching the existing PLC programs. See the protocol reference for what Proxus supports.

Conclusion

The original Automation Pyramid still matters for control boundaries, but it is often not the best structure for broad enterprise data distribution.

The Unified Namespace is best understood as a practical pattern for decoupling producers from consumers, reducing repeated integration work, and making operational context easier to reuse across systems.

Whether you are retrofitting one line or planning a multi-site rollout, the central discipline remains the same: connect once, govern the namespace carefully, and let multiple consumers reuse the same operational context.

References

1. ISA-95 (IEC 62264) - International standard for enterprise-control system integration that defines the hierarchical model used for UNS topic design. ISA-95 Overview
2. Eclipse Sparkplug Specification - The open specification for MQTT-based interoperability in industrial IoT, defining Birth/Death certificates and ProtoBuf payloads. Eclipse Sparkplug
3. MQTT v5.0 OASIS Standard - The protocol standard governing publish-subscribe messaging used as the UNS transport layer. OASIS MQTT
4. Purdue Enterprise Reference Architecture (PERA) - The original network segmentation model that the UNS topology aims to flatten for data access while preserving for security. Purdue Model Overview
5. Walker Reynolds, "Unified Namespace" Concept - Industry-recognized practitioner who formalized the UNS concept for modern IIoT architectures.
6. IEC 62541 (OPC UA) - Complementary standard for machine-to-machine communication; relevant when comparing polling (OPC UA) vs. report-by-exception (MQTT) in UNS architectures. OPC Foundation

To map these phases against your own plant, book a demo and bring your list of sites, lines and the systems that need the data.