The Unified Namespace: how to get started

About the trainer

Bram is a digital strategy consultant and interim director with over 15 years of experience in digital transformation - ranging from predictive modelling and advanced process control to enterprise digital transformations with a strong focus on manufacturing. He has started and led data-platform and Factory-of-the-Future initiatives across industrial sites, working across the full stack from shopfloor sensors to boardroom business cases.

More about Bram: bram.vangenabet.com →

Why this training

UNS in 90 seconds

• ✓A UNS is a real-time single source of truth for your industrial business - a snapshot of the full manufacturing enterprise at any given moment, provisioned by the publishers and available to be consumed anywhere. The MQTT broker is one component of it, not the whole thing. Buying a broker does not give you a UNS any more than buying bricks gives you a house.
• ✓Producers publish once; any authorised consumer subscribes to what it needs, from PLC to ERP to analytics. Adding a consumer becomes a subscription, not a new integration.
• ✓It does not replace ISA-95. The control path stays direct (PLC to SCADA/DCS); the data path becomes shared. The Purdue model and IEC 62443 remain the cybersecurity backbone; ISA-95 is the integration backbone.

The problem it solves

As more and more systems were added at the interface between IT and OT, the number of point-to-point connections kept growing. Each new system had to be wired directly into the others. At the base sits the PLC / SCADA / HMI layer, with an MES interfacing on top of it, a historian capturing process data, and increasingly a set of separate IoT interfaces running alongside.

Over time this produces a dense web of direct links, each one needing to be built, monitored and maintained. This is what is often called spaghettification: as the number of interconnections grows, so does the load on every connected system, while changes become harder to make and overall maintainability suffers.

• ✗Duplicate pipelines and redundant load
• ✗Data silos with no shared truth
• ✗Diverging reports from different copies
• ✗Uncontrolled cyber exposure
• ✗Growing integration maintenance burden

The roadmap

Start small. Prove value. Then scale. No big bang. The rest of this training walks each phase in order. Use the bar at the top to jump to any phase.

This diagram outlines a pragmatic approach to implementing a Unified Namespace, highlighting the main steps and phases involved.

The trap

Most failed transformations did not fail on technology. They failed because nobody agreed, up front, what success looked like or what it was worth. If you cannot say what the prize is in money, you cannot size the effort, defend the budget, or prove the win at the end.

If you draw a black box around any factory, you will almost always find the same elements that cost money: people, materials, energy, and assets.

For people and assets, time is the factor that matters. We pay people by the hour and we invest in assets, so whenever they are not being used productively, they cost us money. This is typically captured through OEE and line performance targets. The key is to look at performance on a full 24-hour basis, so that losses are not hidden or simply shifted from one bucket to another.

For materials, the logic is straightforward: you buy raw materials to make products. Here too it pays to look at the full picture, comparing what comes in against what leaves as valuable, sellable product. This is typically tracked as material usage variance.

Energy works the same way: look at the totals that go in.

The principle throughout is the black box: measure the total amount that goes into the factory to understand the real size of the prize.

Across almost every use case, value is lost in the same pattern. Over time a deviation appears, but it takes time to even notice it (the detection latency). It does not matter which value driver is involved: for as long as the problem goes unidentified, value keeps leaking away and fresh losses keep being produced.

Once you know there is a problem, it takes more time to work out what is causing it (the analysis latency). After that comes discussion and the time needed to reach a decision (the decision latency), which can be considerable in large organisations. And once the decision is made, it still has to be put into action, costing time again (the action latency).

The whole value promise of Industry 4.0, and of a Unified Namespace more broadly, is to collapse the time of each of these steps.

It starts with better connected sensors and a clearer picture of what is actually happening. This is one of the hardest parts of the manufacturing environment, because we often do not even have the sensors needed to measure the true reality of the factory. Once the data and sensors are in place, real-time dashboarding can show operators the right status, provided the right standards are defined to measure against.

The next step is where big data analytics and machine learning come in. With broader, better-quality data, you can move from spotting problems to analysing their root causes.

Finally, the decision-making itself can be optimised through closed-loop control, effectively automating the decision. This should be done step by step. A sensible starting point is operator validation before any action is taken: the operator must always be able to step in and take control, much like an autopilot. From there the system first guides the operator and shortens the decision, and closed-loop control can then compress the full cycle even further. Not everything can run closed-loop today, but this is exactly where AGVs and robotics will play an increasingly important role in the future.

Field guidance

• ✓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.
• ✓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/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/year saving means the project should never exceed roughly €300–500k all-in.
• ✓If the exact value is hard to estimate - and it always is - work with ranges: a realistic worst-case and a realistic best-case. Alternatively, define the 1% value: what is it worth if we improve by just 1%? Both approaches are far better than having nothing quantified, and they give a solid basis for budget conversations and expectation management later on.
• ✓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 of the full process is the fastest way to surface the significant opportunities and avoid optimising things that do not 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.

The trap

The trap: automating before the foundations are in place. Technology applied to a broken process does not fix the process, it just makes you faster at doing the wrong thing. Get the people and the process right first, then let technology accelerate them.

Standardization is critical, and the way to get it right is to look at every project across three dimensions: people, process, and technology.

People. You need the right team to deliver a successful transformation. That means a clear RACI and well-defined responsibilities for each team member, so there is a shared blueprint of how the organisation should work and who does what throughout the project.

Process. This is probably the most important dimension. If you automate systems without a clearly defined process, you simply create automated chaos: technology that is faster at making the wrong decisions and reinforcing the wrong way of working. A digital transformation is the right moment to step back, define the operating model, and optimise the way you work before locking it into systems.

Technology. Technology belongs on equal footing with the other two. You need clarity on people and process first, but if you leave technology out entirely you fall back on manual operational excellence, the way of the past, where you never leverage what data can do today and value keeps leaking away through the same latency loop described earlier. The priority today is connected detection and sensors, which is where most of the investment needs to go. Factories have historically underinvested here, even though the technology itself is now advancing fast. Once that data is in place, you can tap into the power of AI for fast predictive modelling. The aim is a proper, structured representation of process, product, and people: live process and product data on the lines, and the knowledge of your people captured in a structured way.

When all three dimensions come together, the people-process-technology triangle puts you in the sweet spot: sustainably creating value far faster than before, and building a real competitive advantage.

Throughout, keep part one in the back of your mind: what is the value we are chasing? If you do not know the total size of the prize, you cannot size the investment. Technically almost everything is possible, but it has to generate a payback. Knowing the prize defines a realistic path to excellence, and it works both ways: it stops you over-investing where there is no return, and it stops you under-investing and leaving value on the table.

A UNS implementation needs a cross-functional team. Each role brings a distinct lens - and gaps in the team show up as gaps in the platform. No single role can substitute for another: the domain expert who knows the process cannot replace the OT engineer who owns the PLC, and vice versa.

Practical learnings from the field

• ✓Standardise your definitions first. One agreed definition per KPI, one set of quality specifications. 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 what the value cases touch; leave the rest until a use case needs it. Attempting to clean everything before starting is how projects stall before they deliver anything.
• ✓Build trust in the new definition. When you replace a local number with a standard one, be transparent about how it is calculated and show the components. Where it helps, display the old number alongside the new one so people can see exactly what changed and watch the two converge. Align with senior leadership early too: if a KPI feeds bonuses or pay, an unmanaged change becomes a major obstacle to adoption.

Deep dive

Standardizing technology starts with a clear picture of your data landscape - both the current as-is state and the future to-be state you want to reach. A good mapping of where you are today and where you want to go is the foundation for every decision that follows.

The diagram below shows what a data landscape typically looks like, with its main building blocks. Each block represents a set of capabilities to consider. You will rarely fill every block at once, and you do not need to: one of the major strengths of a UNS approach is that it is modular. You can keep what already works today and fill only the blanks that matter now.

Block by block

Every transformation ultimately succeeds or fails on how well the organisation manages change - not on the technology it selects. This course does not go deep on change management: it is a discipline rich enough to deserve a dedicated training in its own right, and one with deep roots in Lean thinking. The Lean principles that underpin operational excellence - eliminating waste, building flow, engaging the people closest to the work - apply just as directly to the human side of a digital transformation as they do to a production line.

What is worth calling out here is that the technical and methodological phases in this roadmap will stall without the organisational side working in parallel. A few frameworks are worth knowing. Kotter’s 8-step model is the long-established reference. A more recent and, in our view, particularly useful framework is the Six Batteries of Change from Vlerick Business School - built on four years of research across more than 300 organisations - which maps out exactly which organisational dimensions have to be active for a transformation to stick.

The model maps two kinds of energy - rational and emotional - across three levels of the organisation: the top, the middle, and the shop floor. That gives six batteries, and the central insight is simple: all six need to be charged, because a flat battery anywhere drains the others.

• ✓Clear strategic direction (rational, top) - a sharp, well-understood strategy that gives the change a clear destination and rationale.
• ✓Ambitious top team (emotional, top) - united, inspiring leadership that supplies the drive and credibility to power change from the top.
• ✓Powerful management infrastructure (rational, middle) - the structures and systems that turn strategy into something that can be managed and tracked.
• ✓Healthy culture (emotional, middle) - an open, collaborative environment where new ideas are welcomed rather than suppressed.
• ✓Action planning & implementation (rational, shop floor) - disciplined project management that translates strategy into delivered results. One of the hardest batteries for most organisations.
• ✓Strong connection with employees (emotional, shop floor) - genuine engagement with the people doing the work, building the commitment that carries change through on the front line.

Source: Six Batteries of Change, Vlerick Business School (P. De Prins, G. Letens, K. Verweire, 2017).

The naming convention sits at the intersection of process and technology - it requires a process decision (what hierarchy makes sense for your operations) and a technical implementation (how the mapping layer enforces it). It deserves its own attention: getting it right before pilots begin saves significant rework later, and getting it wrong is one of the most common reasons a UNS becomes unmaintainable at scale.

This is the part practitioners most often get wrong. You almost certainly already have a convention in your CMMS or SAP - start from that and keep it pragmatic.

In practice a full UNS data landscape requires a dual naming convention. Machines speak in device tags - raw identifiers owned by the OT team that trace back to a specific PLC or sensor. People and systems think in business context - a hierarchy that follows the ISA-95 asset structure. If you collapse these two into one, you either lose traceability (the OT side suffers) or you force business consumers to parse raw PLC tags (the IT side suffers). Keeping them separate and mapping between them - automatically where possible - is the pattern that scales.

Now that we have defined our standards for People, Process, and Technology, and set out the naming convention and the change management strategy, we can move on to the most rewarding part: selecting the components that will fill in the solution. The guidance below focuses on the implementation side, working from the technology layer upward. There are far too many providers to cover individually, so rather than reviewing products, the aim here is to share a practical method and a few names worth considering.

Field guidance

• ✓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 delivering.
• ✓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, TCO, 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 makes patch handling, rollback and audit dramatically easier, and it is the difference between a maintainable platform and a fragile one.
• ✓Build data validation into roles and responsibilities. The automation engineer verifies the tag is mapped correctly; the domain expert confirms the value 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.

Deep dive: HMI as your specification

Tendering methodology

The right way to approach this is a structured tendering process:

1. Start from your value drivers. Be clear about what you are trying to achieve.
2. Translate them into clear functional requirements for each block.
3. Build a short list of candidate vendors per block.
4. Send out an RFI (request for information) and let vendors respond. This alone usually filters out several candidates.
5. Invite the rest to a short demo. One-hour sessions across a single day work well; you can screen six to nine vendors in a day if you keep them tight and to the point.
6. Use the results to sketch a few prototype landscapes that tick all the boxes.
7. For each candidate landscape, forecast the total cost of ownership. Do not forget hosting, licensing, serviceability, and the level of service the vendor can realistically provide. Vendor size matters too: a large multinational has very different needs from a one or two site producer, and the fit should match.

The choices are rarely clear-cut because capabilities overlap heavily and there is seldom a genuinely bad option. The goal is to find what fits the culture and size of the company, while checking the right criteria up front so the design does not create problems later. The design and selection phase is one of the most important in the whole journey. Template checklists will be made available to support this.

Vendor landscape - some players worth considering

The following are examples to consider, not recommendations or a formal review. The vendor landscape is rich enough to deserve its own dedicated training. These are names that, in our experience, all have credentials worth including in a shortlist.

This list is not exhaustive - there are certainly strong names missing. An open question worth raising: what vendors do you work with or consider in your environment?

Value is won through two complementary loops. The first is Detect & React: shortening the time between a problem appearing and an operator acting on it. The second is Analyze & Standardize: understanding what drives performance well enough to eliminate the problem at the root and lock the improvement into a new standard. Together these loops feed each other - better detection leads to better analysis, and better standards raise the baseline from which the next problem is detected.

The UNS is what accelerates both loops: better-connected data means faster detection, faster analysis, and faster deployment of the new standard. Every pilot should be designed to shorten one or both loops and prove that compression in euros.

Inspired by the Efeso infinity loop in WCOM™.

The trap

The platform is selected and the basics are in place. From here, every week without a delivered benefit erodes credibility and budget. This is the fun part and the hard part: turning capability into proven value with small, real use cases.

Field guidance

• ✓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.

In practice, value from a UNS programme accumulates from many small contributions. Each individual win may seem modest, but tracked together they create awareness, build the business case for continued investment, and - critically - reveal which use cases are repeatable enough to scale across lines and sites. A benefits register that is maintained as you go is the difference between a programme that earns its keep and one that quietly runs out of budget and mandate.

The trap

The first use case is slow and expensive - that is normal. The mistake is treating every subsequent rollout the same way, or letting the standard drift as you scale until the spaghetti grows back. Scale is where discipline pays off or unravels.

Field guidance

• ✓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.
• ✓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 to 70% of effort scaling what already works and 30 to 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.

Scope evolution: the tiered UNS

A UNS can start at a single line or site, then expand: multiple sites, group ERP integration, and eventually a cloud tier for cross-site analytics. It is normal for more than one namespace to coexist while the approach matures. Integrate rather than rip and replace, and let proven use cases drive the next increment.

The cloud tier also solves external data sharing: publish what you choose to share on your own cloud broker and grant suppliers access, instead of letting every IoT vendor put an outbound edge device on your shopfloor. The floor stays inbound-only; the attack surface does not grow with every integration.

Pulling it together

Q&A / open discussion

An open working session, not a quiz. A few seed questions to get the room talking.

Resources