In part 1 of this two-part series, we explored how Unified Namespace (UNS) is a powerful solution that can help organisations streamline their operations and improve efficiency by creating a single, standardised naming convention for all data points in a system.
In this blog, we’ll look at a real-world example of UNS, illustrating how this digital transformation game-changer can be implemented in a manufacturing context, and highlighting some of the challenges that organisations may face when implementing UNS.
Learn more about the basics of UNS in Part 1: Unified Namespace Part 1: A digital transformation must-have.
A real-world application of Unified Namespace
To better illustrate UNS in action, let’s look at how it might look in the context of the manufacturing environment of a bottling plant. In many bottling plants today (digital or paper-based), we see a variety of machines – both new and old – involved in various stages of the production process.
Whether it’s filling, labelling, or packaging – machines at each step often have their own protocols to communicate with each other, making it a challenge to synchronise day-to-day operations and collect valuable data to improve efficiency. Unified Namespace helps address this issue by providing a unified naming convention for all systems in the factory (read more about this in part 1), ensuring that all machines, equipment, and other IoT devices have unique and consistent names, regardless of their vendor or protocol.
Consider this scenario:
In our bottling plant, let’s call the filling machine from vendor A, "Filling_A", and the labelling machine from vendor B, "Labelling_B". Utilising UNS, despite their differences, these machines can communicate seamlessly, as their names are recognised and translated into the appropriate protocol by the system.
Each machine has a unique set of process variables. Those variables must be standardised in UNS according to the adopted naming convention. As a minimum, each machine must publish its status (e.g. running/stopped/failed), and consumed/produced (bottle) count. The mentioned metrics will be used to visualise machine performance and to calculate Overall Equipment Efficiency (OEE). Implementation of OEE metrics is a significant tool in the hands of plant performance management. Capturing additional metrics like motor speed, product conditions, temperature, etc. unlocks other use cases, such as predictive maintenance and advanced performance tuning.
Thanks to UNS, if any machines are replaced by a newer model or even a different vendor, you won’t need to re-engineer your OEE solution. Replacement machines can publish to the same standardised namespace. Expansion of the plant also is not going to be a problem. Commissioning of a new line will automatically update data in UNS and can be included in OEE calculations.
What are the challenges?
As with any step change, implementing UNS may come with some challenges, which vary from one organisation to another. Here are some potential hurdles to consider before implementing a UNS:
Legacy hardware and software
MQTT is a critical building block for UNS. If your organisation is using legacy hardware and software that does not support MQTT, additional effort is required to integrate devices and data into a UNS. All major vendors have implemented support for MQTT protocol in the latest firmware/hardware releases. To overcome this obstacle, protocol conversion gateways can be utilised.
Complex organisational structure
Organisations that operate across multiple departments, teams, or locations may face challenges in agreeing on the naming standard or hierarchy structure. Mergers and acquisitions are a perfect example of when different organisations must align. It is important to understand that UNS allows you to develop multiple namespaces, each adapted to specific organisational needs. However, in the case of multi-site distributed enterprises, you are going to face data synchronisation challenges. Multiple sites can operate their own MQTT brokers but must implement a data bridge to the central message broker.
Resistance to change
Human factors can pose challenges when implementing UNS. Employees may be used to working with specific devices or systems and may be resistant to changing the way they work. There may be cultural or organisational barriers to change that need to be addressed before integrating new devices and technologies into your data processes. Training and support are vital to effectively use the UNS.
Expertise and training requirements
Implementing UNS may require specialised engineering expertise that may not be available in-house. Organisations may need to hire additional staff or consultants and invest in training existing staff to develop the necessary expertise in areas such as network architecture, data analytics, and cyber security for a successful Unified Namespace implementation.
Sparkplug B limitations
Despite SparkplugB being designed to support a more robust UNS (refer to Part 1), there are certain drawbacks:
- Currently, not all participants of the UNS ecosystem can interpret SparkplugB messages correctly, which depends on the use of message compression functionality. To ensure the message is understood by subscribers, the system must support decoding and encoding of different payloads.
- Also, the SparkplugB standard is “device-centric” or “gateway-centric”, which means that all messages from this publisher are sent to a single MQTT topic. The actual variable name is included in the payload instead of publishing to a dedicated topic.
MQTT broker limitations
If a client application was offline at the time when the data producer published the message it will be missed as the MQTT broker can retain only the last received message. This leads us to the next big question:
How do we handle data history and transactional data?
From Part 1, we know that a historian is a consumer/subscriber of UNS. As such, the historian tags will be aligned with the UNS structure, and we can use the same hierarchical asset filtering. Transactional data may need to be published to the UNS in the form of JSON objects and some custom integration will be required here to implement a query-like interface.
In the future, we expect to see further development of a UNS technology stack where the MQTT broker(s) are complemented by GraphQL database or GraphQL-based integrations. The latter technology enables the execution of queries against our database(s) and for us to subscribe to changes.
Asynchronous communications
Historically OT protocols have been synchronous. If a “write-setpoint” command did not trigger an exception, you could be sure it was received by a PLC. The adoption of UNS changes this paradigm. Now you publish to a broker, not an end-device. Hence, additional coding is required to produce command acknowledgement by the device and repeated attempts by the command source.
Redundancy and high availability
With UNS becoming an enterprise-wide single source of truth and high criticality system, it must be reliable and dependable. For a Systems Engineer, such requirements can be translated as mandatory high-availability of MQTT brokers and communication channels redundancy.
Monitoring and management
A UNS implementation must implement performance metrics and system degradation alerts. Depending on the system size, you may have to consider broker clustering and load balancer technologies.
Data security
The UNS being a central component of an enterprise also imposes strict requirements on security mechanisms. For example, we would not want a compromised device to publish to a “maintenance request” topic or subscribe to a “customer orders” namespace. The implementation must support granular access policies, including integrations with identity providers.
Be sure to try before you buy
Subject matter experts can implement a proof-of-concept using cloud infrastructure and site gateways. This is the easiest way to test, promote, and demonstrate UNS benefits across your organisation without needing to commit to implementation or significantly invest. Even with a proof-of-concept, it’s possible to gain real-time information on asset operation and performance and make it available to any authorised person from any location.
A single source of truth to maximise efficiency
Unified Namespace can be a game-changer for organisations looking to streamline their operations and improve efficiency. We’ve seen what it might look like out on the factory floor, and the compelling benefits that implementing consistent naming conventions across systems and applications could have for an organisation.
Through UNS, they can create a single source of truth for data across machines, equipment, and processes – allowing for seamless integration and connectivity across disparate systems. By enabling different systems to communicate, organisations can more easily overcome the challenges posed by diverse protocols, standards, and technologies – and be better positioned to adopt new Industry 4.0 technologies.
However, we’ve also seen how implementing UNS may come with some challenges, which organisations need to consider before committing to implementation.
Get started with Unified Namespace today
With careful planning, proper training, and support from subject matter experts, organisations can successfully implement UNS and unlock its many benefits.
Get in touch with Nukon today to discuss how we can support your UNS integration and advance your digital transformation journey.
Contact
