4 Reasons Why You Should Adopt MQTT in Unified Namespace
Adopting MQTT in a unified namespace offers a multitude of benefits that can revolutionize how we connect and communicate in the digital world.
Join the DZone community and get the full member experience.
Join For FreeMQTT technology is always a first choice regarding how to build a UNS. Readers unfamiliar with MQTT might be curious why it always appears with UNS in IIoT 4.0 solutions. This episode will walk you through why MQTT is the best partner for building UNS.
What Is MQTT?
Before entering the world of UNS, it is important to have a basic knowledge of MQTT.
MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe-based messaging protocol. It was created in 1991 by Andy Stanford-Clark (IBM) and Arlen Nipper (Eurotech) to connect oil pipelines over unreliable satellite networks. Thus, since day 1, MQTT has been designed to provide efficient connectivity for resource-constrained devices and low-bandwidth, high-latency, or unreliable networks. Now, it has become the de-facto standard of the IoT industry.
Why Adopt MQTT in UNS?
In our last episode, we learned a common tongue of UNS definition: It is about reflecting your business to the digital infrastructure. To create an effective UNS, it is crucial to have a technology stack that can efficiently connect numerous manufacturing devices and unify the whole business from the physical to the digital world.
This is exactly why MQTT plays a pivotal role in UNS. MQTT broker is commonly used as a digital infrastructure for managing fragmented connections and connecting distributed devices in other industries (such as IoV ), and so is in IIoT. Here are the reasons why you should adopt MQTT in UNS.
MQTT Is Lightweight and Scalable
UNS requires a data hub as a single source of truth to connect all of your manufacturing pieces, including PLC, SCADA, MES, and ERP. The amount of real-time data is huge. Usually, data hub faces thousands or even millions of concurrent connections in large-scale solutions.
MQTT has very low overhead and bandwidth consumption thanks to its binary format. This lightweight design minimizes the size of messages and reduces network traffic. This feature perfectly matches UNS and IIoT.
Business owners need to focus more on the operation, not tangling with the expansion of infrastructure resources to support a fast-growing business. This is why the scalability of UNS matters. In the MQTT architecture, some brokers provide superb scalability that can support millions of messages per second, such as EMQX.
MQTT Connects Everything
MQTT may be a newcomer in the world of IIoT, but it has gained immense popularity. This is because MQTT constitutes the greatest common subset of the old IIoT technology, making it an ideal tool for connecting all the components of your existing system without causing any damage.
Because there is no such technology and products that fit all cases, you cannot build a UNS by OPC UA alone or depend on one protocol solely, especially when you bring the cloud into consideration. UNS must combine different technologies together, and MQTT is that adapter and coordinator to unify them in one namespace.
Many data convention tools and protocol proxy software exist in the open-source world, such as Neuron, ignition, and PLC4X. You can connect OPC UA to MQTT, the same story with Modbus and Ethercat.
In IIoT 3.0, companies that execute digital transformation must move data through different layers of traditional systems, such as MES, ERP, CRM, and WMS. This results in a complex connectivity problem called “data spaghetti.”
With the MQTT broker sitting in the middle, facilitating information exchange, UNS moves data in an efficient manner. This is one of the key reasons why we need MQTT to build UNS.
MQTT Is Secure
In the context of UNS, PLCs don't need to report polling requests from unknown sources. It only establishes one long-stand connection to a safe broker, which is known to the whole system and is the only data hub that everything needs to talk to.
MQTT broker not only decouples the inputs and outputs of IIoT 4.0 but also takes over the responsibility of securing the connectivity of fragmented devices and systems. Thanks to the rich security features of MQTT, it is fully competent to act as an isolation data hub for your manufacturing lines, preventing any malformed data from penetrating into fragile PLCs. In this way, UNS shifts the security burden to the broker and manages it in a unified place.
MQTT Enables Event-Driven Architecture
For IIoT 4.0, data is primarily generated by devices, not people. Most of the time, PLC readings don’t change; there is no point in transmitting redundant data to UNS and overwhelming your network.
However, once the value of registers changes, it is essential to report it to ERP/MES or cloud immediately to extract the maximum value since the liquidity and marginal value of information decreases along with time. This is called “report by exception“.
Therefore, an event-driven technology such as MQTT is important to implement UNS. MQTT brokers are aware of client state changes. This awareness is enabled with SparkPlugB and the MQTT Last Will features. With Last Will and SparkPlugB, MQTT only communicates changes and ensures stale data is not delivered to subscribing clients.
MQTT Topic as Metadata of UNS
UNS is the digital reflection of business in the physical world. It is driven by reality, not the other way around. We need the sublime context of generated data to convert it into information, such as the location of the site and which line and cell PLC belongs to. Fortunately, the Pub/Sub messaging model of MQTT provides an easy way of mapping the context of PLC into the digital world.
UNS with MQTT enables users to browse all the namespaces and features. And the real-time status of every data tag.
The MQTT topic is well-defined as follows:
namespace/group_id/message_type/edge_node_id/[device_id]
From OSISoft AF
MQTT Topics have a hierarchical organization and could be easily imagined as a folder structure. By adding your namespace of each level as a topic, we can build a tree view on top of MQTT.
When subscribers consume data from the topic “Enterprise A/Site A/Area A/Process Cell A/Bio Reactor,” it automatically knows where the data originates and takes necessary action upon it. And they could use wildcards to subscribe to multiple data points at the same time.
MQTT could help you define metadata that assures consistency and accuracy across different systems in UNS.
OPC UA: Alternative to MQTT for Building UNS
Precisely speaking, MQTT is the best partner for building UNS. However, it is not compulsory. Therefore, you could build the UNS with other protocols, such as OPC UA and HTTP, or even plain Modbus + TCP/UDP. Among many options, OPC UA remains a popular methodology for IIoT due to the strong commercial backup and the standard's longevity.
However, it is not one or the other case; the best approach is to combine the advantages from both sides by bridging them together or using OPC UA via the MQTT approach.
The General Architecture of Building UNS With MQTT
Theoretically, UNS is a global namespace that unifies all namespaces of your business. Each factory, each site, and each PLC is a stand-alone namespace.
UNS is to take technology across the business and structure it in a way you can navigate. Thus, all other solutions could be built on top of it to their best effort. MQTT is responsible for connecting fragmented technologies from OT, CT, and the IT world and seamlessly integrates them together.
Conclusion
In this blog, we discussed the significance of MQTT within UNS and why MQTT is the data pump of all IT systems. Adopting MQTT in a unified namespace offers a multitude of benefits that can revolutionize how we connect and communicate in the digital world. Organizations can streamline their data flow, create more responsive and connected systems, and unlock new opportunities for innovation and growth.
In the upcoming episode, we will explore the innovative contributions of EMQ to UNS regarding MQTT.
Published at DZone with permission of Weihong Zhang. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments