The Unified Namespace, Edge to Last Mile

This is a Tuesday in most plants today. Auto parts, steel, textile, pharma, FMCG — the acronyms change, the pain doesn’t. Six tools want the same data from the shop floor. Each pulls it through its own pipe, its own polling, its own units, its own clock skew. Six consumers, six numbers. None of them wrong. None of them agree.

The fix has been on the shelf for almost twenty years. It’s called the Unified Namespace, built on top of a standard plant engineers already know (ISA-95), and it looks like this:

Twenty years on the shelf isn’t because the idea is wrong. It’s because four things had to land in the same year, and only recently did:

• Edge compute small and cheap enough for one box per line, not one per plant. A decade ago this job needed a rack-mount industrial PC; today it’s an SBC in an enclosure that fits inside an existing control cabinet. The economics flipped from “one expensive box per plant” (which forces aggregation and clock skew) to “a small box per line” (which keeps the source of truth where the data is born).
• Open-source middleware that’s actually production-grade. Mosquitto, TimescaleDB, the s2opc OPC UA stack, structured lineage tools like fasten. A team shipping this in 2015 either bought enterprise licences or wrote half the middleware themselves. Today every piece is open-source, audited, and good enough to bet a CCTS audit on.
• Regulators who look at the trail. Ten years ago the auditor’s question was “are your meters calibrated.” Today CBAM, CCTS and PAT all demand traceable lineage from meter to reported figure. Audit-grade went from nice-to-have to the gate that decides whether you ship steel into Europe.
• The first wave of cloud-IoT failed at scale. Between 2018 and 2022, plant after plant tried to push every signal to a cloud-IoT platform and discovered the same set of breakage modes: WAN drops that orphaned dashboards mid-shift, bandwidth bills that ate the OEE savings, residency rules that conflicted with the cloud region, and OT teams that refused to trust a path crossing an inbound firewall. The post-mortem said the same thing every time: the data plane has to stay in the plant. UNS is the shape of “stays in the plant” that actually works for OT, IT, finance and the regulator at the same time.

All four are here. This post is about what changes the morning you put it in.

ISA-95 was always the answer. It just wasn’t runnable.

Every plant engineer has seen the ISA-95 pyramid and the Site → Area → Line → Device hierarchy below it. For thirty years that hierarchy lived inside asset registries and architecture slides. Nothing on the wire looked like it. Operators wrote topic names like plant_a_press_2_pressure and called the standard a document.

UNS makes the hierarchy the runtime. Every signal lives at an address that is its place in the plant. A new consumer doesn’t ask “which system do I plug into” or “what does this tag id mean.” It asks “what part of the plant do I care about?” The answer is an MQTT subscription. uns/pune/stamping/+/+/feed_pressure returns every press feed pressure on every line in the stamping shop. No glue code, no per-consumer adapter, no engineer-on-leave problem.

Where OPC UA fits (it pairs with UNS; it doesn’t compete)

Every plant engineer asks this within thirty seconds: “but we already have OPC UA — doesn’t that solve it?” The honest answer is no, and the reason is interesting. OPC UA and UNS sit at different layers and they work best paired.

OPC UA is excellent for talking to the machine. Its address space carries strong, vendor-standardised semantics: nameplate, ranges, units, alarm definitions, health. It is not built to pipe that data to twenty consumers across the plant. The client/server model gets unwieldy fast when the BI tool, the historian, the energy report and three dashboards all want the same value; you do not want each of them opening its own session against a PLC sized for two clients in 2009.

The pattern that works is OPC UA feeds UNS. The OPC UA server sits close to the device. The edge connector reads it, maps the address space into the ISA-95 topic tree, and republishes onto the UNS bus. Everyone else subscribes from there. Our OPC UA connector is built on top of the open s2opc stack (Apache 2.0, audited C), not a homegrown port — so the protocol side is a known quantity and the work is in mapping to ISA-95.

One sentence to remember: OPC UA is how you talk to the machine. UNS is how the plant talks to itself.

One bus on the edge, many subscribers

The real question isn’t whether to run a UNS. That was settled in slide decks a decade ago. The real question is where it lives. The cloud-first answer ships every signal to a managed broker. It works until the WAN burps, until the OT team refuses to open the firewall, until the energy regulator says the data has to stay in the country, until the bandwidth bill lands on the plant owner’s desk.

The edge-native answer puts the UNS bus on the edge node, on premises. The UNS doesn’t move data; it organises access to it. The tag stays where it was produced — meter, PLC register, local TimescaleDB. What moves is the shape each consumer needs. Cloud is a subscriber. So is the historian. So is the MES. So is the ERP. The plant manager keeps the master copy and decides what leaves the gate.

One signal, five shapes — the walkthrough

Take one tag: uns/pune/stamping/line-1/press-2/feed_pressure. The PLC scans the register every second. The connector wraps each reading in an envelope — value, unit (bar), quality flag, timestamp, source id, lineage id — and publishes once. From that single string of bytes, five different consumers pull five different shapes. The press is never read twice. The number never disagrees with itself.

One housekeeping note before the shapes. When we say “subscribe,” we mean the conceptual model. The broker isn’t exposed inbound; the OT firewall stays shut. Mechanically each consumer gets an egress: a small process on the edge that takes a subscription and pushes the result outbound, on the schedule and in the shape that consumer needs. Conceptually subscribe, mechanically push.

MES — and for plants that don’t run one, Edge Analytics already covers the basics. For plants that have a proper MES, the MES egress filters uns/+/+/+/+/run_state, batches at the rate MES can absorb, and posts outbound. The MES doesn’t poll fourteen PLCs; it consumes one shape, from one source. For plants that don’t have a separate MES — and don’t want to add one — Edge Analytics already covers production tracking, OEE, quality and traceability at the line level today. Run/idle states, scrap counts, work-order context (pulled from SAP / Dynamics 365 / NetSuite), shift summaries, quality flags — all in the Analytics UI, no second tool to license. EdgeBits on its own is enough for most mid-market plants. The 6:47am argument about Press 2’s overnight count stops happening either way.

ERP is a two-way street, and the mechanism is ERP-agnostic. Outbound today, the REST egress posts production order confirmations and energy by cost centre to any ERP that speaks HTTP — Microsoft Dynamics 365 OData, NetSuite REST / SuiteTalk, Oracle Fusion, SAP S/4HANA OData. The SAP RFC / IDoc native egress (in flight) closes the SAP-specific loop with native types; for the rest, REST already is the native shape. Inbound, Analytics pulls business context back in — production orders, cost centres, quality specs, BOM. SAP is pre-mapped via OData today; Dynamics 365 and NetSuite reach the same Analytics import path with a one-time mapping config. That enrichment turns a raw OEE number into “OEE on Order 4509-A for cost centre PUNE-STAMP-01,” and finance gets the sentence they want for month-end close.

Historian — and most plants don’t need a separate one anymore. Every value, every quality flag, every timestamp. When the metallurgist asks “what was the coolant temperature curve at 04:13 on Tuesday,” somebody has to answer. For plants that already run AVEVA PI / Wonderware / FactoryTalk, we feed the historian they have (the PI Web API egress ships today; Wonderware and FactoryTalk land on the same shape next). For plants that don’t, Edge Analytics is the historian: its TimescaleDB store keeps 90 days at raw fidelity, 1 year of 15-minute aggregates, and 3 years of hourly rollups by default. The metallurgist’s question gets the same answer; the plant owner doesn’t pay for a second storage product.

BI gets aggregates already computed. Shift OEE, downtime by reason code, energy intensity. Computed at the edge from raw UNS data, pushed via REST or Sparkplug B to Grafana, Power BI, or our own Analytics product. Computed once, in the right place. Same number on every dashboard.

The regulator gets the trail that survives audit. CCTS asks for tCO₂e per tonne, traceable from meter to report. The lineage at every hop makes the verifier’s “prove it” a non-event. The steel-line emissions pipeline that runs this end-to-end is landing alongside the production-grade Modbus build right now.

Five consumers. Five shapes. One bus. Zero new wires into the plant.

Many lenses, one bus

Here is the move that turns architecture into a daily-operations advantage. Each consumer above is really a lens on the same underlying bus. Maintenance sees alarms, RUL, last-service date, technician on call. Production sees run/idle, scrap, work-order routing, shift handover. Finance sees rollups by cost centre, energy per tonne, monthly close. Three lenses, three departments, three apps — all looking at the same UNS, none duplicating data, none disagreeing about what the meter said.

The same idea scales sideways. The CCTS auditor coming on Friday gets a fourth lens: emission factors, normalisation, signed lineage. The ESG team next quarter gets a fifth: scope-2 grid carbon, water draw, waste-to-output. Each new lens is a subscription, not a project. The plant’s structure doesn’t change. Nobody re-wires Press 2.

It’s tempting to give every department its own UNS tree — maintenance has its tree, production has its tree, finance has its tree. It ends in governance arguments about which tree is authoritative. Multiple UNS trees create multiple versions of reality. A single bus with multiple lenses creates multiple perspectives on the same reality.

The bus is the truth. The lens is how each team sees it.

The four pieces that close the loop — Edge, Fleet, Analytics, fasten

The architecture above doesn’t come from one anonymous “platform.” It comes from four pieces, each doing one job:

• Edge. The node on the plant floor. Connectors, UNS bus, functions, rule engine, buffer, egress. The single source of truth for plant data, on premises.
• Fleet (Edge Manager). The control plane across plants. Register a node with a claim code, push pipeline templates, monitor health, manage ISA-95 topology from one screen across every site. Outbound HTTPS only; no inbound port into any plant.
• Analytics (Edge Analytics). The data plane — OEE per line, tag explorer, data quality monitor, energy reports, CCTS-ready aggregates, production tracking, quality and traceability. The TimescaleDB store doubles as the historian for most plants, and the Analytics features already cover what a basic MES does (production tracking, OEE, quality, traceability). Two licences nobody pays for. EdgeBits on its own is enough for most mid-market plants; a separate MES or historian is a choice, not a requirement.
• fasten. The lineage layer that signs every hop across all three — meter to envelope to UNS to egress to whichever consumer reads it. The reason CCTS, ISO 50001, finance audits and the verifier’s “prove it” turn into non-events.

The plant manager’s morning problem isn’t solved by one of those four. It’s solved by all four, in this order, on the same bus.

When you want an answer, not a screen

Two pains that come up every week, both solved on the same bus, neither of them needing a buyer to be ready for “AI” before they get the value.

Pain 1: rules, where the plant already lives. Most of what a plant needs from its data is a rule. “If feed pressure on Press 2 is below 130 for five minutes, raise a maintenance ticket.” “If energy per tonne crosses a threshold, ping the boiler engineer.” “If the night-shift count diverges from the panel by more than 1%, flag for review.” A typical plant has hundreds of these. The rule engine ships today: rules read from the UNS, write alerts back to it, and the same egresses fan the alert out to MES, email, WhatsApp, or a dashboard. Nothing magical, just one place to write them and one place they all run.

Pain 2: the question that isn’t a rule — “why did Press 2 drop yield on Tuesday?” Today that takes two hours across three systems, and the plant manager doesn’t have an OT engineer to spare on Wednesday. The UNS structure makes this kind of question answerable in plain English — “which line used more energy last week?” or “why did shift B burn more on line 3?” — by walking the topic hierarchy, pulling the relevant tags, and returning the answer with the lineage attached. The architecture supports it now; the question box that surfaces it inside the Analytics UI (and the query API that exposes the same capability to external tools) is in flight, not shipping yet. When it lands, the plant owner who isn’t ready to buy “AI” still gets a query interface that saves their OT engineer a morning.

And the 3am call that was a false alarm. Today: a cloud-based detector loses one heartbeat, decides a press has stopped, maintenance lead drives in at 3am to find it humming. After three of those, nobody picks up. On the edge node, the detector sees the actual signal — not a network blip — and only raises a call when the press is really misbehaving. Whether the detector is a hand-written rule or a small learned model, the bus doesn’t care; the result goes back onto UNS as a new tag and every other consumer reads it the same way.

The objections we hear, and what we actually say back

Five objections come up almost every meeting. None unreasonable. Here’s the answer, and where we admit a trade-off.

1. “Our PLCs are twenty years old. No greenfield budget.” UNS doesn’t need greenfield. The connector reads the same PLC on the same Modbus, S7 or EtherNet/IP wire, on the same scan cycle. We do this every install — the first UNS-shaped value in the bus arrives an hour after a Raspberry Pi gets plugged in. Where a plant does have a modern OPC UA server, our s2opc-based connector reads it the same way. The UNS layer above is identical.

2. “MQTT isn’t deterministic enough for our control loop.” Correct, and UNS isn’t a control loop. Control stays in the PLC, in PROFINET / EtherCAT / Modbus, in microseconds, where it belongs. UNS is the observability and distribution layer one level above. Nothing on the bus drives an actuator on a critical loop.

3. “Security — open topics, anyone can subscribe.” The broker isn’t open. Edge brokers run topic ACLs per service, mTLS between every component, and the broker is not exposed inbound. The only path out of the plant is the outbound-only HTTPS poll from edge-sync to Edge Manager. In practice this is tighter than a cloud-first UNS, because no part of the data path crosses an inbound firewall hole.

4. “Vendor lock-in.” Everything underneath is open: MQTT, ISA-95, JSON envelope. The topic strings are yours. If a plant owner ever wants to move the broker to another vendor, the topics survive and the consumers don’t notice. If it ever comes to leaving us, we’ll write the export script for you.

5. “We’ll just build it ourselves.” You can. A first UNS on a Raspberry Pi and Mosquitto goes up in a weekend, and that’s a good way to feel what UNS does. The expense arrives in year two: quality flags, store-and-forward through a WAN outage, multi-site identity, RBAC, audit lineage a regulator accepts, the OPC UA upgrade when one plant gets a new line, the dashboard for people who can’t use the broker CLI. The reason buyers eventually pay for a platform isn’t the broker. It’s the everything-around-the-broker that nobody puts in the weekend version.

What the plant manager wakes up to instead

6:47am, same office. The night shift in-charge has a printout. It says Press 2 made 414 parts. MES says 414. ERP says 414. The historian says 414. CCTS reporting is queued for Friday with the meter reading, the emission factor, the normalisation step and the signed lineage already attached. The OT engineer is on leave; the answer to “why did Press 2 drop yield on Tuesday” comes back in minutes with the topic path included. The morning meeting picks a decision instead of a source.