5 Widespread Pitfalls in UNS Design



The Unified Namespace (UNS) is right here to remain. In idea, it’s a single location that represents the real-time state of your manufacturing facility, utilizing open requirements. Evangelized by Walker Reynolds, President of 4.0 Options and the Board Chairman of Intellic Integration, the UNS is interesting as a result of it strikes on the core downside we’ve confronted in factories for many years: Gaining access to machine information is tough.

In follow, the UNS is usually an MQ Telemetry Transport (MQTT) dealer with an ISA-95 subject hierarchy (Web site/Space/Line) and edge functions to transform business protocols (e.g., OPC UA, Modbus, Ethernet/IP, SIMATIC STEP 7) to contextualized, human readable JSON payloads or Sparkplug B.

However UNS as an idea is broader than a single know-how. You might construct a UNS utilizing OPC UA, SQL, or many different know-how stacks. So why is MQTT so widespread?

MQTT is straightforward. It’s report by exception. It has a versatile subject hierarchy that’s simple to grasp, and it places little to no constraints on the information, making it very versatile.

These qualities make MQTT a wonderful selection for real-time machine information, however like all applied sciences, it has limitations. There are a handful of UNS design patterns we’ve seen that create challenges for MQTT, and different industrial information patterns that aren’t a perfect match. The aim of this text is to debate these in additional element in an effort to perceive the professionals and cons and make knowledgeable selections primarily based in your distinctive surroundings.

 1. Utilizing MQTT As a Tunnel

MQTT is designed to be 1:N or N:1, that means a single producer of knowledge can have many subscribers listening, or many producers can have a single subscriber listening. This design is nice for the UNS, however what if, for instance, you’re merely attempting to get information between your SCADA system and Snowflake? This use case is 1:1, a single producer and a subscriber.

There are some benefits that lead prospects down the trail of utilizing MQTT for these use instances.

  • Sooner or later, it’s possible you’ll want different functions to eat the information. MQTT simply permits this;
  • MQTT connects outbound from a safe community to an insecure community (e.g. DMZ) not requiring any open inbound firewall ports on the safe community (i.e. you don’t want to speak with IT).

However in the event you don’t have near-term plans to leverage the information in different functions, is it value adopting MQTT? In the event you’re spending loads of time customizing the information payload for the tip utility, it is likely to be an indication that you simply’re utilizing MQTT as a tunnel. That is much more obvious in the event you’ve adopted different applied sciences like Sparkplug B to allow the tunnel. Sparkplug B is a good enabling know-how between units and SCADA, but it surely creates integration challenges as you progress up the stack.

The hidden value of the tunnel resolution is the adoption of an MQTT Dealer, protocol converters, and the necessity to safe and help that stack. In software program improvement, we name this technical debt.

Possibly that is OK, however after I see this sample, my normal steering is to design an answer that may simply allow MQTT information entry if wanted, however to not require the know-how till you’re leveraging its advantages.

2. Publish, to Subscribe, to Publish (Repeat)

You usually see edge information that isn’t properly formatted for MQTT. It both exists in a proprietary format, or perhaps it isn’t contextualized sufficient. In these patterns, an utility sends uncooked information to a subject (e.g., /mytopic/uncooked) after which one other utility subscribes to the subject, transforms the information, and publishes on a separate subject (e.g., /mytopic/cleaned). This sample may proceed, with subscribing to the cleaned subject and publishing an combination subject, alarm matters, and so on. Rinse, wash, and repeat.

In the event you’ve ever been fishing and had your line tangle, that is how I image this sample. The dependencies between matters grow to be laborious to trace because the MQTT subject namespace turns into cluttered. This makes it laborious to determine and debug failures.

The existence of this sample isn’t inherently dangerous, however it could be an indication that you simply’d profit from doing extra information preparation on the edge earlier than publishing to MQTT.

3. Transactions By way of a UNS

Transactions are a standard information sample in manufacturing. The commonest instance of transactions are writes. For instance, it’s possible you’ll need to write set factors, clear an alarm, or another perform.

MQTT was developed within the 90s for the Oil and Fuel business, classically often known as SCADA or “Supervisory Management and Information Acquisition.” The important thing phrase is Supervisory. MQTT can publish to a subject as a strategy to difficulty a write, however provided that it’s a one-to-many protocol, there isn’t a strategy to simply get a write response. Sparkplug B does this with Command (CMD) messages, that are despatched on a singular subject, however to know if the write succeeded, you should monitor the information revealed by the gadget to see if a worth modified. This may occasionally work for Supervisory Management, however inside a manufacturing facility, it’s usually vital to know instantly if a write succeeds or fails to take corrective motion.


There are some intelligent patterns to attempt to simulate transactions over MQTT. For instance, a standard sample is to difficulty a write on a subject with a singular transaction ID (e.g., writes/txid/123). The shopper then subscribes to a different subject with the identical distinctive ID to get the response (e.g., writes/response/txid/123). It’s intelligent, but it surely’s not a real transaction, it requires each shoppers to grasp the protocol, and—worse—it shortly pollutes the MQTT subject namespace by creating new matters for every write.

REST or OPC UA are higher fitted to request/response interactions. They are often synchronous, that means you instantly know the standing of the write and might act accordingly.

In the event you’re attempting to do writes by way of the MQTT Dealer, it is likely to be an indication that you simply’re misusing the know-how.

4. Massive Information Units

Factories have loads of information. Methods like historians and SQL databases can simply develop to terabytes in dimension. There are numerous use instances the place it’s possible you’ll need to transfer all or a few of this information between functions.

In instances the place an MQTT Dealer is already out there within the know-how stack for real-time information, prospects might attempt to use it for historic workflows. MQTT is proscribed to 256MB message dimension, which, in equity, is fairly giant. However MQTT is optimized for small to mid-sized messages delivered in a short time, not for shifting giant payloads sometimes.

The result’s an inefficient information change that would affect efficiency of extra time delicate, real-time information within the dealer.

That is made worse if publishers use the MQTT retained characteristic. Retained is helpful when a brand new shopper needs to know the latest publish on a subject, but when this publish is 200MB+ in dimension, it’s problematic. The dealer finally ends up storing and replicating the big message both in reminiscence or on disk.

Most often, SQL, historian, and enormous file information flows are higher fitted to different applied sciences like REST, FTP, and so on., and shouldn’t be tunneled by way of MQTT.

5. Occasionally Used Information

Some information in a PLC is required in close to real-time, updating each second or quicker. However there’s loads of different information that’s wanted much less continuously, if in any respect. For instance, perhaps the PLC has registers that maintain debug details about the final batch that was processed. This info is useful within the case of an error, however usually, it’s diagnostic info that isn’t wanted in real-time.


If MQTT or Sparkplug B are the one information paths it’s important to the PLC, this information have to be configured and revealed constantly for it to be out there within the occasion it’s wanted. If it’s not, it will require somebody to reconfigure the information uncovered by the gadget, which relying on location and availability, might be difficult.

The basis reason behind this downside is that MQTT is report-by-exception and doesn’t have a strategy to expose what matters/information can be found or management what information is distributed to customers. Different protocols like OPC UA clear up this by exposing a browse interface and permitting shoppers to browse the information that’s out there, choose what they want, and decide how usually to eat it. This strategy is usually higher when information is required on-demand,

In the event you’re pressured to publish information to MQTT that’s sometimes or by no means used, it is likely to be an indication that you simply want extra flexibility than what out-of-the-box MQTT supplies for these use instances.


MQTT is a key enabling know-how that has pushed UNS adoption. It’s an important resolution for real-time machine information within the UNS, offering an open and versatile strategy to talk machine state and subscribe from many functions.

However like all applied sciences, it has limitations. If a few of the examples offered on this article resonate together with your structure, it doesn’t imply your structure is inherently improper, however it’s possible you’ll need to think about the professionals and cons of the strategy.

At HighByte, we’re protocol and vendor agnostic. We imagine that though MQTT is a key enabler for real-time machine information within the UNS, the UNS is broader than a single know-how and encompasses all information patterns discovered within the manufacturing facility. However extra on that in a future article.

In regards to the Writer: Aron Semle is the Chief Know-how Officer of HighByte, centered on guiding the corporate’s know-how and product technique by way of product improvement, technical evangelism, and supporting buyer success. His areas of accountability embrace analysis and improvement and product improvement and validation. Aron has greater than 15 years of expertise in industrial know-how. He beforehand labored at Kepware and PTC from 2008 till 2018 in quite a lot of roles together with software program engineer, product supervisor, R&D lead, and director of options administration, serving to to form the corporate’s technique within the manufacturing operations market. Aron has a bachelor’s diploma in laptop engineering from the College of Maine, Orono.

Associated Objects:

Methods to Handle Scale and Efficiency Wants in IoT

Assessing Your Choices for Actual-Time Message Buses

Why Occasion Meshes Ought to Be On Your IoT Radar