Unified Namespace vs Historian: What Each One Keeps
Current Values From One Place, History You Can Audit
A unified namespace and a historian do different jobs, so most sites need both. The unified namespace publishes what the plant is doing now, in one structured tree that every system subscribes to. The historian keeps what the plant did, compressed and queryable for years. A broker holds only the latest value on each topic, so it cannot answer last month's production question. The decision that matters is the order you build them in and who owns the naming.
That answer is for the people who get asked this question: control systems engineers, OT and site IT leads, and the operations managers who sign off the architecture. It usually comes up when a site has tens of thousands of tags in a historian, a growing list of systems that want live data, and a vendor or integrator proposing a unified namespace as the fix.
Having worked on historian, PI System and MES projects for BHP, Rio Tinto and Senex Energy while employed by previous consulting firms, the pattern is familiar. (These companies are not Solve8 clients.) The trouble usually starts when the new layer is built before anyone has agreed what each asset is called.
Working out whether this fits your business? Book a free 30-minute review
What a Unified Namespace Actually Is
A unified namespace, or UNS, is a single place where every system publishes its current state and every other system reads it. In practice it is usually an MQTT broker with a topic tree that follows the plant's own hierarchy: enterprise, site, area, line or unit, then the asset and its measurements. ISA-95, published internationally as IEC 62264, is the usual reference for those levels.
MQTT itself is an open publish and subscribe protocol, standardised as ISO/IEC 20922. It does not define what a topic should be called or what a payload should contain. Sparkplug fills that gap for industrial use: it defines a topic structure, a payload format and session state, so a subscriber knows whether a device is online and what metrics it publishes. Sparkplug has been published as an international standard, ISO/IEC 20237 (ARC Advisory Group).
The appeal is easy to see. Without a UNS, every new consumer needs its own connection to the historian, the SCADA, the MES and the CMMS. With one, a new consumer subscribes to the tree and gets current values in a known structure.
What the broker does not do is keep history. MQTT can retain the last message on a topic, so a new subscriber sees the latest value straight away. It does not keep the value from an hour ago, let alone a year ago. Anything that needs history has to store it somewhere.
What a Historian Does That a Broker Does Not
A process historian such as the AVEVA PI System, AVEVA Historian, Canary or the Ignition historian exists to store time series well. Each of them handles jobs that a message broker was never designed for:
- Compressed storage of years of data for tens of thousands of tags, read back fast enough for a trend or a report.
- Store and forward: when the link between site and head office drops, collectors buffer locally and backfill once it returns, so the record has no gap.
- Time-weighted averages, totals and interpolated values over a period, which is what a shift report, a mass balance or an emissions calculation actually needs.
- Lab results and manual entries that arrive after the event, written back against the right timestamp.
- Asset context, which in the PI System is the Asset Framework tying raw tags to equipment and calculations.
These are the features your reporting depends on. A monthly production figure, a downtime report, a shutdown scope built from trends and the measurements behind a Safeguard Mechanism return all ask "what happened over this period". Only a store of history can answer that. Our guide to getting historian data into Power BI without a second historian covers how that reporting layer should read from it.
Side by Side: The Two Layers on One Site
What changes when a UNS is added beside the historian
| Metric | Historian only, point-to-point links | Historian plus unified namespace | Improvement |
|---|---|---|---|
| New system wants live values | New interface to each source | Subscribes to the topic tree | One connection |
| Asset names across systems | Each interface maps its own | One agreed tree everyone reads | Consistent |
| Last month's totals | Historian query | Still a historian query | Unchanged |
| Network outage between site and office | Collector buffers and backfills | Collector still buffers; broker holds latest value only | Historian still needed |
| Device online or offline | Inferred from stale values | Sparkplug state messages | Explicit |
The table shows the honest shape of the decision. A UNS improves how current values reach many consumers. It changes nothing about how history is stored or queried. If a proposal says the UNS replaces the historian, ask where last year's data will live and how it will be backfilled after an outage.
Where the Two Connect
The usual pattern puts the UNS between the sources and the consumers that need current state, while the historian keeps subscribing to the sources it already reads, or to the namespace itself.
Current state through the UNS, history in the historian
Two details decide whether this works.
The first is the edge gateway. It is where raw tag names become the names in the agreed tree. If that mapping is done once, in one place, every consumer sees the same asset names. If each integrator maps tags their own way, you have rebuilt the point-to-point problem inside a broker.
The second is the security boundary. A broker that accepts connections from both the control network and the business network is a path across the levels your Purdue model was meant to separate. For a site covered by the critical infrastructure risk management program rules under the Security of Critical Infrastructure Act 2018, that path needs to be designed, documented and monitored. Our post on CIRMP and AI for critical infrastructure covers what that obligation asks of OT data flows.
The Naming Standard Comes Before the Broker
The single biggest risk in a UNS project is publishing an inconsistent plant faster.
Consider a typical processing site with a long history of upgrades. Conveyor 3 is "CV03" in SCADA, "CONV-003" in the historian, a functional location code in the CMMS and "Conv 3 Main" in the MES. Each name was right for the system that chose it. A UNS forces one answer, and somebody has to decide what it is.
That decision is a data standard. It covers the hierarchy levels, how assets are named at each level, what each measurement is called, which units are used and who approves a change. Our guide to OT tag naming and data standards sets out what that standard needs to contain.
If your site already runs the PI System with a well-kept Asset Framework, much of that work exists. The AF hierarchy is often the best starting draft for the topic tree. Our article on PI AF templates that survive a plant change explains how to tell whether yours is in good enough shape to reuse.
Which One to Start With
Unified namespace, historian, or both?
If your monthly figures do not reconcile, a UNS will not fix them. That problem lives in how measurements are stored, summarised and balanced. Our guide to reconciling SCADA, historian and ERP production figures is the place to start.
If the problem is integration, where every new MES module, maintenance tool or analytics project pays for its own interface, a UNS is a strong answer. It is strongest once the naming standard is agreed and a single owner maintains the tree.
If you have no historian, or one that has reached end of support, start there. A UNS with nothing storing the record leaves your reporting with nothing to read. For the trade-offs between historian products, see our comparisons of the PI System and Ignition and of Canary and the PI System. Solve8 resells neither product.
What AI Projects Need From Each Layer
Much of the current interest in UNS comes from AI and analytics projects. Each one needs something different from the two layers.
A model that predicts a failure or classifies a delay is trained on history. It needs months or years of clean, time-aligned data with consistent asset names, which is a historian job. Once it is running, it needs live values to score, which a UNS supplies well. And the results it produces, such as a suggested delay reason or a maintenance flag, can be published back to the namespace for the MES or CMMS to pick up, with a person confirming before anything is recorded.
That last point matters. A model should read OT data and publish suggestions. It should not write setpoints or control values. Keeping AI on the read side of the boundary is the simplest control you have. Our post on AI delay classification in Ampla shows how that shadow-mode pattern works for one specific job.
When the model and the integration need to be built for your site rather than bought, that is the work our custom AI development service does, inside your own environment.
A Sensible Sequence for a Brownfield Site
Adding a unified namespace to a site with a historian
Start small and keep the old path running. Publish one plant area for one consumer that has a real need, such as an MES module or a maintenance dashboard. Run it beside the existing interface and compare values until they match. Only then retire the old link.
The historian keeps running throughout. Nothing in this sequence asks it to change, which is the point: the record your reporting and compliance depend on stays where it is while the new layer proves itself.
Questions to Ask Before You Sign a UNS Proposal
- Where will history live, and how is it backfilled after an outage?
- Who owns the naming standard, and who approves a change to the topic tree?
- Which existing interfaces will this retire, and when?
- How does the broker sit against our Purdue levels and our CIRMP obligations?
- Can anything that subscribes also write back to the control layer?
- What happens to the namespace when a plant area is modified or a tag is renamed?
A proposal that answers all six with specifics is worth considering. One that answers "the UNS replaces the historian" is not.
Common Questions
Does a unified namespace replace a historian?
No. A unified namespace carries current state between systems, and an MQTT broker keeps only the latest value on each topic. A historian stores compressed time series for years, backfills after outages and answers period queries. Most sites that adopt a UNS keep their historian as the system of record.
Can the PI System be part of a unified namespace?
Yes. The PI System can subscribe to a namespace to store its values, and its data can be published into one through an interface or gateway. A well-kept PI Asset Framework is often the best starting draft for the topic hierarchy.
What is Sparkplug and do we need it?
Sparkplug is a specification for using MQTT in industrial systems. It defines topic structure, payload format and device state, and it has been published as ISO/IEC 20237. Plain MQTT works without it, but you then have to define those conventions yourself and enforce them.
Is a unified namespace a security risk for OT?
It can be if the broker bridges the control and business networks without design. Treat it as a boundary system: place it deliberately against your Purdue levels, control who can publish and subscribe, keep consumers read-only toward the control layer and document it in your risk program.
How long does it take to add a UNS to an existing site?
The first area for one consumer can usually be live within a few months, as the sequence above shows. Most of that time goes on agreeing the naming standard and running beside the existing interface. Extending to the rest of the site is paced by how many interfaces you choose to retire.
Where does AI fit between the two?
Models train on history from the historian, score live values from the namespace and publish suggestions back for a person to confirm. Keeping AI on the read side of the control boundary is the simplest control a site has.
Get a Straight View on Your Plant Data Architecture
Bring your current interface list and the proposal on the table, if there is one. In a free 30-minute Microsoft Teams call we will go through it with you. You leave knowing whether a unified namespace fixes the problem you have, what has to be agreed first, and where your historian fits.
Book your free 30-minute plant data review
For the wider capability, see our work on industrial and manufacturing data and system integration, or start from the Solve8 home page for our AI consulting services across Australia.
Related Reading
- PI System Historian to Power BI Reporting - Reading historian data into reports without building a second historian.
- ISA-95 on a Site With No MES - Using the ISA-95 levels to structure plant data before an MES exists.
- OT Tag Naming and Data Standards - The naming standard a unified namespace depends on.
- SCADA, Historian and ERP Production Reconciliation - When the problem is figures that disagree, not integration.
- Ampla Support as a Managed Service - Keeping MES and plant systems supported after the project ends.
Sources: ARC Advisory Group, "Sparkplug Now an Official ISO/IEC Standard"; ISO/IEC 20922, Message Queuing Telemetry Transport (MQTT) v3.1.1; ISO/IEC 20237, Sparkplug specification; IEC 62264 (ISA-95), Enterprise-control system integration; Security of Critical Infrastructure Act 2018 (Cth) and the critical infrastructure risk management program rules.