ArchitectureIndustrials

Unified namespace in manufacturing: an architecture for machine, MES and ERP data

A unified namespace is a shared, event-driven hierarchy, usually hosted on an MQTT broker and organized by the ISA-95 equipment model, where each system publishes its current state once and any authorized consumer subscribes. Combined with OPC UA at the machine and Sparkplug B for session state, it replaces the web of point-to-point links that slows every new analytics or AI project. It is not a historian, a data model on its own or a reason to relax network segmentation.

Reviewed 7 min read

On this page
  1. Why point-to-point plant integrations stall AI projects
  2. ISA-95 levels and where each plant system sits
  3. What the Purdue model still gets right about a unified namespace
  4. OPC UA, MQTT with Sparkplug B and plain MQTT side by side
  5. Producers and consumers around a plant namespace broker
  6. Brownfield decisions for mixed-vendor plants
  7. Contextualizing data and serving AI from the namespace
  8. How unified namespace programs fail and the controls that prevent it
  9. Bringing mixed PLC brands into one namespace
  10. Questions and answers
  11. Sources

Why point-to-point plant integrations stall AI projects

In most brownfield plants, every consumer of machine data has its own link: the MES polls a line controller, a quality system reads a vision station, an energy dashboard queries a meter gateway and a data team copies historian exports. Each new AI use case adds another interface, another owner and another place where tag names lose their meaning.

The cost shows up when a PLC program changes and three systems break, or when a model trained on one line cannot be reused on its twin because the signals are named differently. A shared namespace attacks both problems: producers publish once in an agreed structure, and consumers subscribe without negotiating a new interface each time.

ISA-95 levels and where each plant system sits

ISA-95, also published as IEC 62264, describes five levels from the physical process to business planning1. Security architectures usually add an industrial DMZ between operations and enterprise.

Level 4: business planning01Industrial DMZ02Level 3: operations03Level 2: supervisory04Level 1: control05Level 0: process06
  1. Level 4: business planning

    ERP, supply planning and finance; orders and material masters originate here.

  2. Industrial DMZ

    Brokers, replicas and jump hosts that let enterprise systems reach plant data without direct paths.

  3. Level 3: operations

    MES, quality, maintenance and scheduling systems that run the plant shift by shift.

  4. Level 2: supervisory

    SCADA, HMIs and line controllers that monitor and supervise the process.

  5. Level 1: control

    PLCs and controllers executing logic in real time.

  6. Level 0: process

    Sensors, drives, actuators and the machines themselves.

Conceptual stack combining ISA-95 levels with a DMZ, top to bottom. It is a reference, not a description of any particular plant.

What the Purdue model still gets right about a unified namespace

Critics of the Purdue model say data should not climb one level at a time. That is a fair complaint about data flow, but the model also organizes security. NIST SP 800-82 Rev. 3 suggests organizing OT network segmentation with an industry model such as the Purdue model, ISA-95 levels or a three-tier IIoT architecture, and grouping systems into security zones6.

So a namespace does not flatten the network. A practical pattern runs a broker inside the operations zone and bridges a filtered, read-only branch to a broker in the DMZ for enterprise and cloud consumers. In ISA/IEC 62443 terms, each broker belongs to a zone and each bridge is a conduit with its own controls5.

OPC UA, MQTT with Sparkplug B and plain MQTT side by side

CriterionOPC UA client-serverMQTT with Sparkplug BPlain MQTT with custom JSON
Information modelRich, typed, browsable object models2Defined metric payload, lighter than OPC UAWhatever each publisher chooses
Communication patternClient connects to each server; PubSub also existsPublish-subscribe through a brokerPublish-subscribe through a broker3
Knowing data is staleSession and status codes per valueBirth and death certificates per node and device4Not defined; must be designed
Scaling to many consumersEach client adds load on the serverBroker fans out to any number of subscribersBroker fans out, but payloads vary
Best fitMachine-level access and modern equipmentPlant-wide state distributionSmall, single-team prototypes
Main weaknessPoint-to-point growth if used everywhereLess expressive model; needs naming governanceSchema drift and no state awareness

Many plants use both standards: an edge gateway reads machines over OPC UA and publishes into the namespace with Sparkplug B.

Producers and consumers around a plant namespace broker

machine stateorder contextall valuesfeaturespredictionsfiltered, via DMZ01Namespace broker02Edge gateways03MES04Historian05AI services06ERP connector
  1. Namespace broker

    MQTT broker holding the current state of the plant, organized by site, area, line and cell.

  2. Edge gateways

    Read PLCs over OPC UA or native drivers, add context and publish with Sparkplug B.

  3. MES

    Publishes orders, product and batch context; subscribes to machine states and counts.

  4. Historian

    Subscribes to everything worth keeping and stores it as time series.

  5. AI services

    Subscribe to features, publish predictions and alerts back under a defined branch.

  6. ERP connector

    Reaches a filtered copy through the DMZ bridge, never the control zone directly.

Conceptual hub pattern for one site. Real deployments add redundancy, per-zone brokers and access control on every topic branch.

Brownfield decisions for mixed-vendor plants

  • If

    Most controllers expose OPC UA servers or can through vendor modules.

    Then

    Read them with edge gateways over OPC UA and publish into the namespace.

    You keep each vendor's model at the edge without making every consumer an OPC UA client.

  • If

    Older controllers speak only proprietary or serial protocols.

    Then

    Add protocol converters at the edge and map tags to the namespace there.

    Replacing working controllers to gain a protocol is rarely justified.

  • If

    The MES already runs an integration bus that teams rely on.

    Then

    Bridge it to the namespace rather than duplicating its interfaces.

    Two competing sources of truth are worse than one imperfect one.

  • If

    There is a single consumer and a single use case.

    Then

    A direct, well-documented integration may be enough for now.

    A namespace pays back as consumers multiply, not on day one.

Contextualizing data and serving AI from the namespace

Raw tags become useful when the edge adds context: the asset they belong to, engineering units, the current order and product, and whether the machine is running, idle or in changeover. Doing this once at the gateway is what lets the same model run on two identical lines.

The namespace carries the present, so pair it with systems for the past. A historian stores time series, a feature pipeline subscribes to the branches a model needs, and training runs centrally on that history. Inference that must react within a machine cycle, such as vision inspection, runs on edge hardware beside the line; slower predictions can run centrally. Either way, publish results back with the model version so the MES, the CMMS and people can see where a prediction came from. For twin modeling standards, see digital twins.

How unified namespace programs fail and the controls that prevent it

Topic sprawl

Early signalTeams publish under their own naming and duplicates appear.

MitigationOwn the topic hierarchy centrally and review new branches like schema changes.

Treating the broker as a historian

Early signalConsumers ask for last week's values from retained messages.

MitigationRoute history to a historian and keep the broker for current state.

A single broker as a single point of failure

Early signalMaintenance on one server stops every consumer.

MitigationCluster the broker and let edge gateways buffer and resend.

Write paths into control

Early signalEnterprise or cloud systems can publish commands that gateways act on.

MitigationDefault to read-only; allow writes only through an approved, limited path per use case.

Bringing mixed PLC brands into one namespace

Questions and answers

Is a unified namespace a product we can buy?

No. It is an architecture pattern built from a broker, edge gateways, a naming scheme and governance. Several vendors sell brokers, gateways or platforms that support the pattern, but the topic hierarchy, ownership rules and access controls are design decisions your plant has to make and maintain.

Does a unified namespace replace our historian or MES?

No. The historian remains the system of record for time series and the MES remains the system that runs orders and genealogy. The namespace connects them and gives new consumers one place to subscribe. Plants that try to make the broker do a historian's or MES's job usually end up rebuilding those functions badly.

Should we choose OPC UA or MQTT for a new plant?

Most plants end up using both. OPC UA suits machine-level access, where its typed information models describe equipment in detail. MQTT with Sparkplug B suits distributing state across the plant to many consumers. Sparkplug 3.0 has been published as ISO/IEC 20237, which helps when you need interoperable state handling from several vendors4.

How do we keep a unified namespace secure in an OT network?

Place brokers in defined security zones, bridge only filtered branches outward, authenticate every client, use per-topic access control and keep writes into control disabled unless a use case is approved. Apply the same change management to topic structures and bridges as to any other OT network change.

Sources

  1. ISA-95 Standard: Enterprise-Control System Integration — International Society of Automation · checked 10 October 2026
  2. Unified Architecture (OPC UA) — OPC Foundation · checked 10 October 2026
  3. MQTT Version 5.0, OASIS Standard — OASIS · checked 10 October 2026
  4. The Eclipse Foundation Announces Sparkplug as an International Standard — Eclipse Foundation · checked 10 October 2026
  5. ISA/IEC 62443 Series of Standards — International Society of Automation · checked 10 October 2026
  6. NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security — National Institute of Standards and Technology · checked 10 October 2026

More in Industrials

Back to Industrials

Next step

Review your plant data architecture before the next integration

Send a sketch of your controllers, MES, historian and network zones, plus the next use case you want to support. We will suggest where a namespace would help and what to keep as it is.

Share your architecture