A Unified Namespace (UNS) pilot can be technically impressive, High-Tech, and yet still fail to answer the question that matters: can the manufacturer scale this approach properly? Connecting a broker, publishing machine tags and building a dashboard may demonstrate connectivity… that already existed 20 years ago. It does not, by itself, prove that the proposed data architecture is understandable, governable or useful across the entire organisation, on all sites.
A useful pilot starts with a decision, based on real validated and prioritized needs from the shopfloor, and not a shopping list of technologies. It should make one important uncertainty visible and produce evidence that stakeholders can evaluate together.
Start with real operational questions that address the top 3 biggest pains
Choose problems with a clear owner and a practical consequence. Perhaps maintenance cannot reliably identify when a machine is stopped, or two applications disagree about the status of a production order, or a site might be down and we rely on other sites to compensate. Describe the questions that generate anxiety up until the top management, and express in operational language, before discussing topics, payloads, protocols and technologies.
A good pilot question would ask whether one contextualised equipment-state event can be made available consistently to a maintenance dashboard and a production application, with an agreed definition and known latency. This is narrower, and more testable, than “implement a UNS for the factory”. We will see in a later article “How to find scientifically your best issue to solve”.
Define what the pilot includes and what it excludes
Select a limited set of assets that represents the diversity of your ecosystem, identify the source systems and the consumers. Detail the information that will be exchanged (name, type, protocols and size, …), the frequency at which it changes, the expected quality and the people responsible for its meaning. Make assumptions and exclusions explicit, including enterprise-wide rollout, full historical migration, every PLC on the site or production-critical automation changes.
The boundary should also reflect operational constraints. A pilot that touches live equipment needs a suitable safety and cybersecurity review. When possible, a controlled Lab environment allows teams to challenge the architecture without making the production floor a testing ground.
Model meaning before multiplying messages
A namespace is not useful simply because it has a tidy basic hierarchy. Participants must agree what represents an asset, production order, status or event. Specify identifiers, timestamps, units, source provenance, quality indicators and relationships where relevant. Document all events, such as what happens when a device is offline, a value becomes stale or a name changes.
Beyond the basic, but needed, “UNS-hierarchy”, this is where “ontology modelling” and “Knowledge Graph” techniques become valuable, firstly to encourage teams to describe entities and relationships explicitly rather than assume that every application interprets a topic name in the same way, and secondly to create a large cross-functional dataset where Artificial Intelligence could find its way to the sought values and yet “understands” precisely the vital context. The right level of modelling depends on the use case, and we recommend a version 1 to be very light to contribute to pedagogy and enforce the Change Management; the pilot should test whether added structure delivers a practical benefit; this phase is sometimes called PoV: Proof of Value.
Choose success criteria that support a decision
A pilot needs more than ‘data arrived’. Measure whether intended consumers can find and interpret the information, whether the same event is represented consistently, and whether ownership and access rules are workable. Record latency and reliability against the use case, not against arbitrary targets. On the “People” (HR) side, ensure everyone involved has understood both the approach, and recognizes the added values.
Include non-standard and failure scenarios. What happens if the source stops publishing, a payload changes, an application reconnects or a user lacks permission? A design that works only in a perfect demonstration is not yet evidence for production deployment. That’s why we strongly advise that the Pilot phase is performed in a real production environment, yet isolated from the mass production, to ensure that the experimentation will not affect the production.
Make the pilot a shared learning exercise
Operations, OT, IT, cyber, data teams and business sponsors may each see a different risk. Use the pilot to create a common picture of the proposed architecture, its limits and its dependencies. Compare alternatives where the decision is genuinely open. Keep a decision log that distinguishes what was demonstrated from what remains an assumption.
At the end, the team should have tangible outputs including a documented use case, a bounded architecture, an agreed information model, test evidence, unresolved risks and a recommendation to refine, expand, pause or stop. Stopping a weak idea early can be a successful pilot outcome.
De-risk the next step with FactoVia Lab
FactoVia Lab provides a controlled setting to explore industrial data flows, challenge theoretical designs and align stakeholders before a new facility is built or an existing one is modernised. The objective is not to showcase technology for its own sake. It is to reduce uncertainty while changes are still manageable and turn a technical experiment into an informed business decision.
