In a previous column, I shared how Unified Namespace (UNS) is helping organizations streamline operations and improve efficiency by creating a single, standardized naming convention for all data points in a system.
In this column, I want to provide an example of UNS in a manufacturing context and expands on the challenges that organizations may face during UNS implementation.
Bottling plant application
For this example, let’s view UNS use in the context of a manufacturer’s bottling plant with a variety of machines—new and old—used in the production process.
Whether it’s filling, labelling or packaging, these machines often have their own protocols to communicate with each other, making it a challenge to synchronize day-to-day operations and collect valuable data. UNS helps address this issue by providing a unified naming convention for all systems in the factory, ensuring that all machines, equipment and other devices connectd for Internet of Things (IoT) applications have unique and consistent names, regardless of their vendor or protocol.
Each machine has a unique set of process variables, which must be standardized in UNS according to the adopted naming convention. At a minimum, each machine must publish its status (e.g., running/stopped/failed), and consumed/produced (bottle) count. These metrics will be used to visualize machine performance and to calculate overall equipment efficiency (OEE).
With UNS, any machine upgrades mean your OEE solution won’t need to be re-engineered, as replacements can be published to the same standardized namespace.
UNS challenges
Following are 10 specific challenges associate with UNS which users should be aware of:
Legacy hardware and software: MQTT is a critical building block for UNS. If your organization 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 their latest firmware/hardware releases. If some of your legacy equipment does not support MQTT, protocol conversion gateways can be used.
Organizational structures: Organizations operating across multiple departments, teams or locations may disagree on naming standards or hierarchy structures. UNS allows for the development of multiple namespaces. However, in the case of multi-site distributed enterprises, you will face data synchronization challenges. Multiple sites can operate their own MQTT brokers but must implement a data bridge to the central message broker.
Expertise and training requirements: Implementing UNS may require specialized engineering expertise that may not be available in-house, such as network architecture, data analytics and cyber security.
Sparkplug B limitations: Despite SparkplugB being designed to support a more robust UNS, there are certain drawbacks, such as —currently, not all participants of a UNS ecosystem can interpret SparkplugB messages correctly, depending 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 considered device-centric or gateway-centric, meaning 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 when the data producer published the message it will be missed, as the MQTT broker can retain only the last received message.
Handling of data history and transactional data: A historian is a consumer/subscriber of UNS, so historian tags will be aligned with the UNS structure and the same hierarchical asset filtering can be used. 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, operations technology 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. Additional coding is required to produce command acknowledgement by the device and repeated attempts by the command source.
Redundancy and availability: As an enterprise-wide single source of data truth, UNS must be 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 include performance metrics and system degradation alerts. Depending on the system size, you may have to consider broker clustering and load balancer technologies.
Data security: As a central component of an enterprise, UNS needs strict requirements on security mechanisms. The implementation must support granular access policies, including integrations with identity providers.
Sergey Koreshkov is a senior consultant at Nukon, a SAGE Group brand. SAGE is a certified member of the Control System Integrators Association (CSIA). For more information about SAGE, visit its profile on the Industrial Automation Exchange.
