Digital strategy
The Unified Namespace:
more than a broker
A structured approach to connecting every system in your industrial enterprise - not a product you buy. Producers publish once; any authorised consumer subscribes.
The core idea
A UNS is a real-time single source of truth for your industrial business.
The MQTT broker is one component of the UNS, not the UNS itself. Buying a broker does not give you a Unified Namespace any more than buying bricks gives you a house. The value is in the approach and the data structure around it: a shared, organised view of the business that any authorised system or person can reach in real time.
Walker Reynolds, who popularised the concept, described it as living “everywhere and nowhere”. It is a real-time single source of truth - a place where producers publish their data once and any authorised consumer subscribes to what it needs, from PLC to ERP to analytics platform.
What is the problem?
→How UNS solves it
- ✗Every new app needs its own connection to every source→✓Publish once; any consumer subscribes, no new integration needed✗Every new app needs its own connection to every source→✓Publish once; any consumer subscribes, no new integration needed
- ✗Changing a source means updating every consumer individually→✓Consumers are decoupled; change the source once✗Changing a source means updating every consumer individually→✓Consumers are decoupled; change the source once
- ✗Current state scattered across dozens of disconnected systems→✓One real-time view of the business, always current✗Current state scattered across dozens of disconnected systems→✓One real-time view of the business, always current
- ✗OT-to-IT data requires custom translation for each use case→✓Data in shared context; any system reads it directly✗OT-to-IT data requires custom translation for each use case→✓Data in shared context; any system reads it directly
Why it is more than just a broker
Data storage and data operations
The broker holds a real-time snapshot - it is not a database. For long-term storage you still need a historian or data lake to collect and retain values over time. On top of that, not all brokers include data operations such as calculations, aggregations, or transformations - those typically require additional tooling alongside the UNS.
Data quality: gold in, gold out
Gold in, gold out - but equally, garbage in, garbage out. The most important foundation is a good data model. Your ERP or CMMS is a solid starting point. Do not get pinned down trying to fix every inconsistency before you begin - do the data validation your use cases actually need, and keep the scope tied to the problem you are solving.
Network segmentation and cybersecurity
The Purdue model, IEC 62443 zones and conduits, and NIS2 compliance all remain in force. Flattening data access raises the security stakes, it does not lower them.
ISA-95 and direct control-layer connections
ISA-95 remains the structural foundation. For availability-critical loops, the direct SCADA/DCS-to-PLC connection typically stays. The UNS runs alongside it.
How did we get here
ISA-95 is the international standard that describes how to structure and connect the systems inside an industrial company - from sensors and PLCs on the factory floor up to ERP in the boardroom. Published in the early 2000s, it became the universal reference model for organising OT and IT together.
It organises the enterprise into a clear hierarchy where each layer operates on its own time horizon and communicates mainly with the level directly above and below it. That discipline kept scope clean and systems manageable. The layered architecture maps directly onto the Purdue network segmentation model: traffic between zones is limited and controlled via defined conduits, which constrains the blast radius of any cyber incident. ISA-95 and the Purdue model together remain the cybersecurity foundation for most OT environments today - and become more important, not less, as IT and OT converge.
The spaghettification problem
Over time, plants added layer upon layer of new tools: MES, historians, visualisation platforms, reporting solutions, advanced process control, and more. Each new tool was wired directly to the systems it needed data from. The result is a growing web of point-to-point connections - “spaghettification”. On top of that, suppliers increasingly deploy their own edge devices to read out machine data, each with its own interface, credentials, and network footprint. Every new link adds load, maintenance cost, and a potential cyber exposure.
What spaghettification creates
Duplicate pipelines
Multiple tools pull the same source in different formats, creating redundant load.
Data silos
Each tool holds its own copy with its own context - no shared truth.
Diverging reports
Dashboards and KPIs calculated from different copies produce different answers.
Uncontrolled cyber exposure
Supplier edge devices multiply entry points with little governance or oversight.
Integration maintenance burden
IT and OT teams spend time keeping connections alive instead of delivering value.
The Unified Namespace as the answer
Instead of every system connecting to every other system, each participant connects once to the broker: publish the data you have, subscribe to the data you need. The broker holds the latest value for every topic in real time. Adding a new consumer no longer requires a new integration - it requires a subscription.
The UNS is the structured namespace around the broker. Any authorised system or person - from PLC to ERP to an analytics platform - can reach the data it needs through one common, contextualised structure.
Note: ISA-95 is not replaced. Critical point-to-point connections such as PLC to SCADA/DCS are kept for availability and determinism - the control path stays direct, the data path becomes shared. ISA-95 and the UNS coexist.
The typical adoption roadmap
The industrial data platform around the broker encompasses the full IT and OT capability landscape: data acquisition from PLCs and sensors, operational systems such as SCADA and MES, storage in historians and data lakes, visualisation, analytics, and the AI models that are increasingly embedded in the OT environment. The broker bridges and organises the data flow between them.
Each phase below expands into practical guidance from the field. Start small, prove value, then scale - no big bang.
1. Value Assessment - know the size of the prize
- Never start a project without knowing the size of the prize. Not knowing your success measure is the number one cause of failed transformations.
- Treat every factory as a black box. The inputs are always the same: people (salaries), materials, assets and utilities. Value is hidden in how much of those inputs you convert into sellable product versus waste, downtime and rework.
- Look at the full picture and distrust the easy “we can’t win anything here” answer. “OEE is already 95%” - yes, but the line still stops 12 hours a day. There is always something to gain; the job is to find where.
- Quantify in money, not percentages. A CFO does not act on “5% OEE”; they act on “400k a year”. Convert every opportunity into euros before you rank it.
- Separate hard savings (cash that hits the P&L) from soft savings (freed capacity, risk avoided). Hard savings fund the project; soft savings justify it.
- Size the budget against the prize. Rule of thumb: maximum all-in budget = 3 to 5x the annual value. A 100k EUR/year saving means the project should never exceed roughly 300-500k EUR all-in.
- Define the use cases explicitly. What do you want to improve, and how will you know it worked? This list becomes the contract for the whole programme.
- Borrow from Lean. A value stream map is the fastest way to surface the significant opportunities and avoid optimising things that don’t matter.
- Name an owner for the benefit. If no one owns the P&L line that improves, the saving will not be realised, no matter how good the technology is.
2. Standardise - fix the foundation before you automate it
- Work across three dimensions at once: people, process and technology. A gap in any one will stall the other two.
- Standardise your definitions first. One agreed definition per KPI, one set of quality specifications. If you don’t have them, start there - a UNS will faithfully distribute inconsistent data to everyone at once.
- Standardise units, time and sampling too. Same unit of measure, same timezone, same sampling logic. Mismatches here cause the hardest bugs to find later.
- Standardise the organisation, not just the data. Clear RACI per role. If the OT team owns the PLCs and keeps production running, the solution must let automation engineers be the only ones who modify PLCs.
- Start with a solid as-is mapping. What is already in place, where the pain points are, and which point-to-point connections are fragile or underperforming.
- Profile your OT install base. Which PLC types must you talk to? This drives connector choice and effort more than any vendor demo will.
- Decide which future capabilities matter. Will you exchange data with external vendors? Do you already integrate with MES? Design for where you are going, not only where you are.
- Classify the data you need to exchange. Pure telemetry is fine on MQTT (consider Sparkplug B for structure); guaranteed-delivery transactions are often better served by AMQP. Get this wrong and you rebuild the backbone later.
- Standardise what the value cases touch; leave the rest until a use case needs it.
3. Gap-Fit - best of breed, no big bang
- Assess the landscape component by component: what must be replaced, what can be added, what stays. The whole point of a UNS is modularity - no big bang. Anchor every decision to the value you are trying to deliver.
- Do not force one vendor into every box. Combine best-of-breed solutions. The broker is what makes best-of-breed affordable, because it decouples the pieces.
- Fewer interfaces is a benefit, not the only criterion. A suite that ticks several boxes can still be the wrong fit. Weigh interface reduction against fit, openness and lock-in.
- A practical scoring shortlist per module: open-standards support (MQTT, OPC UA, Sparkplug B), native version control and backup, security (segmentation, authentication, audit), scalability, total cost of ownership, vendor viability, and fit to your RACI.
- Make the target architecture compliant with ISA-95 and the Purdue model from day one. Cybersecurity is a design input, not a later add-on.
- Insist on native version control and backup. It is not a nice-to-have - it makes patch handling, rollback and audit dramatically easier.
- Apply the naming convention pragmatically. Often there is no right answer, only a choice - make it and move on.
- Build data validation into roles and responsibilities. The automation engineer verifies the tag is mapped correctly; the domain expert confirms the value is correct from a process point of view. Two checks, two owners.
- Use the HMI as your spec. Start from screenshots of the HMI/SCADA, have domain experts mark which data points they want, and write the target tag name straight onto the screenshot.
4. Value-Delivering Pilots - now the clock is ticking
- This is the phase that decides whether the programme succeeds. Once the system is selected and the basics are in place, the clock starts: have you actually delivered benefit yet?
- Start with small use cases. Small and proven beats big and theoretical.
- Every use case counts. A licence cost avoided, energy saved, time saved on a trial run - log all of it. Value accumulates from many small wins, not one heroic one.
- Keep a benefits register. A SharePoint or shared Excel where every use case is documented with baseline, mechanism, owner, euro value and validation status. Document as you go.
- Get finance to co-sign. Self-reported savings get discounted heavily and quietly. A number validated by finance sticks, and it compounds your credibility for the next increment.
- Start with energy. It is easy to meter, easy to quantify, and the baseline is rarely disputed.
- Choose pilots that are repeatable, not just easy. A win you cannot roll out teaches you nothing about scale.
- Most use cases fall into two clusters: Detect & React - shorten the time to notice and respond to a problem; and Analyze & Standardize - understand the standard well enough to attack the problem at the root.
- The underlying mechanism is time. Value leaks the entire time the loop is open - detect, analyse, decide, act. The purpose of the UNS is to compress that loop.
5. Roll Out the Basics - where the UNS earns its keep
- This is where the UNS pays off. Because every line and site shares the same standard and architecture, proven use cases roll out far faster than the first one did.
- The magic of scale: save 10% across 10 production lines and you have effectively earned one production line for free. That is the sentence to put in front of your CFO.
- Spend roughly 60-70% of effort scaling what already works and 30-40% on new innovation. Resist the urge to keep inventing while proven value sits un-deployed.
- Template everything. Dashboards, models and connectors built once should deploy in hours, not weeks. If a rollout still takes weeks per site, your model is not yet standard enough.
- Govern against drift. As scope grows, standards must be actively enforced or you slowly re-create the spaghetti you removed. A small centre of excellence and a written playbook are cheap insurance.
Data model
A naming convention is not just a technical detail - it is what makes the UNS useful at scale. A well-designed data model builds a standardised representation of factory reality: which assets exist, where they sit in the hierarchy, and what data points they expose.
The industry term is digital twin, but in practice what most organisations build first is a digital shadow: a read-only, real-time reflection of physical reality, not yet a full bidirectional model. That is already enough to unlock significant value.
ISA-95 remains the structural foundation here. Anchor the naming convention on the site / area / line / cell hierarchy you already use in ERP or your maintenance system, then extend it with OT sensor conventions.
Why it matters in practice
- +Reports and dashboards built once work across all lines and sites that follow the same model
- +Deployment speed shifts from weeks or months per site to hours or minutes once the model is proven
- +New consumers (analytics, AI, external tools) subscribe to well-named topics without custom mapping work
- +Focus on the use cases you are delivering - clean up only the data those use cases need, not everything at once
Naming convention in practice - a worked example
- Don’t reinvent the wheel. You almost certainly already have a convention in your CMMS or SAP - start from that and keep it pragmatic.
- In practice you will run a dual naming convention:
- Device name - identifies the tag in the source device, used by the OT communication layer so every tag can be traced back to its source. Ownership sits with the OT team.
- Broker name - follows the asset structure (the ISA-95 hierarchy) and is what consumers see in the UNS.
- A good combined pattern:
OTInterfaceName.DeviceTagname.ISA95Tagname - The ISA-95 tag follows the standard levels: Enterprise / Site / Area / Line / Equipment / Tag. The Tag itself is standardised as Type.Description.Attribute:
- Type - the kind of measurement: T = temperature, P = pressure, F = flow, L = level, S = speed, W = weight.
- Description - what is being measured: e.g. Product, MotorOil, Steam.
- Attribute - the role of the value: PV = process value, SP = setpoint, RC = recipe target, CMD = command, ST = status, ALM = alarm.
- Worked example:
- Source-side tag:
EdgeDevice1.PLC1_PLCTag.BE01_CM_L01_MX01_T_Product_PV - Broker / UNS path:
BE01/CM/L01/MX01/T/Product/PV(Site / Area / Line / Equipment / Type / Description / Attribute)
- Source-side tag:
- The OT communication layer strips the source tag name and maps it to the UNS path. This mapping can and should be automated, so engineers maintain it in one place rather than by hand.
- PackML can offer some structure, but in practice the standard is limited for day-to-day tagging. Take what helps and don’t force the rest.
- Keep it pragmatic. Apply the standard strictly where it drives value (anything reports, analytics or AI will consume) and allow tolerance elsewhere.
Scope evolution
A UNS can start at a single production line or a single site. As use cases are proven and the naming convention matures, scope expands: multiple sites, integration with a group ERP solution, and eventually a cloud layer for cross-site analytics and reporting.
It is normal for more than one namespace or model to coexist while the approach develops. The guiding principle is to integrate rather than rip and replace, and to let proven use cases drive the next increment.
External data sharing
Today many IoT vendors arrive with their own interface device to read out machine data. Each device adds a new network connection, new credentials, and a new cybersecurity exposure to manage. Multiplied across vendors, this becomes a governance headache.
A cloud UNS layer solves this: you publish the data you choose to share on your own cloud broker and grant your suppliers access - bidirectional if needed. You control what is exposed and to whom. Suppliers can offer managed versions of this as well, but it is an important building block to design for from the start.
What to keep in mind
ISA-95 stays
A UNS builds on ISA-95 rather than replacing it. It removes the rigid layer-by-layer data flow but uses the ISA-95 hierarchy as the backbone of its naming convention. ERP, MES, SCADA and PLCs all remain in place.
Roughly 80% organisational, 20% technology
The hard part of a UNS is not the broker. It is defining a naming convention that will hold, aligning teams across IT and OT, and governing how the namespace evolves. Technology is the smaller share of the effort.
Cybersecurity: the stakes rise, not fall
Flattening data access does not reduce security obligations. The Purdue network zoning and the IEC 62443 zones-and-conduits model continue to apply. As more systems gain connectivity and AI models enter the OT landscape, the governance and security bar rises further. Enterprise requirements such as ISO 27001 and the NIS2 directive remain in scope.