Unified Namespace vs Historian: What Each One Keeps

A unified namespace and a historian do different jobs, so most industrial sites need both. The unified namespace (UNS) publishes what the plant is doing now, in one structured tree every system subscribes to. The historian keeps what the plant did, compressed and queryable for years. A broker holds only the latest value per topic, so it cannot answer last month's production question.

The decisions that matter are the order you build them in and who owns the naming.

This guide is for control systems engineers, OT and site IT leads, and the operations managers who sign off the architecture. The question 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.

What is a unified namespace?

A unified namespace 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 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 contains. 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 it publishes. Sparkplug has been published as 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, SCADA, MES and 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 immediately. 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 does a historian do 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 handles jobs 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 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, mass balance or emissions calculation 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.

Your reporting depends on these features. 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 historian data in Power BI without a second historian covers how reporting should read from it.

Unified namespace vs historian: how do they compare on one site?

	Historian only, point-to-point links	Historian plus unified namespace	Impact
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 do the unified namespace and historian 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.

1. 1Controllers and SCADAPLCs, DCS and SCADA publish values
2. 2Edge gatewayMaps tags to the agreed tree, buffers on outage
3. 3Unified namespaceBroker holds current state by asset
4. 4HistorianSubscribes and stores the record
5. 5Reporting and AIHistory from the historian, live values from the UNS

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.

Why does the naming standard come before the broker?

The single biggest risk in a UNS project is publishing an inconsistent plant faster.

For example, consider a 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 the 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.

Should you start with a unified namespace or a historian?

What is the problem you are actually trying to fix?

• Reports disagree or history has gapsFix the historian and reconciliation first
• Many systems need the same live valuesUnified namespace, after the naming standard
• Every new project builds its own interfaceNaming standard first, then a UNS
• No historian, or one at end of supportHistorian first; add a UNS later

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 at 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. We resell neither product.

What do AI projects need from each layer?

Much of the current interest in UNS comes from AI and analytics projects, and each layer supplies something different.

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 running, it needs live values to score, which a UNS supplies well. The results it produces, such as a suggested delay reason or 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 the model runs alongside the team for one specific job before anyone relies on it.

What is a sensible sequence for a brownfield site?

1. Weeks 1-3Inventory and namingList sources, consumers and interfaces; agree the hierarchy and naming standard
2. Weeks 4-6One area, one consumerPublish one plant area to the broker for one real consumer
3. Weeks 7-10Run beside the old interfaceCompare values from the UNS with the historian and existing links
4. Weeks 11-14Retire one interfaceSwitch the consumer to the UNS once values match; document the security boundary
5. AfterExtend by areaAdd areas and consumers; the historian remains the system of record

Start small and keep the old path running. Publish one plant area for one consumer with 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.

What should you ask before signing a UNS proposal?

1. Where will history live, and how is it backfilled after an outage?
2. Who owns the naming standard, and who approves a change to the topic tree?
3. Which existing interfaces will this retire, and when?
4. How does the broker sit against our Purdue levels and our CIRMP obligations?
5. Can anything that subscribes also write back to the control layer?
6. 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.

Across our consultants' careers, historian, PI System and MES work in BHP, Rio Tinto and Senex Energy environments has shown the same pattern: trouble starts when the new layer is built before anyone agrees what each asset is called.

How Solve8 can help

Our consultants and engineers review plant data architecture, write the naming standard and build the integration and models for your site through our system integration and custom AI development services, with everything running on your infrastructure. See our mining, energy and manufacturing data work, or contact us with your interface list and any proposal on the table.