5 Widespread Pitfalls in UNS Design

(Summit-Artwork-Creations/Shutterstock)

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: Having access to machine information is difficult.

In apply, the UNS is commonly an MQ Telemetry Transport (MQTT) dealer with an ISA-95 subject hierarchy (Web site/Space/Line) and edge purposes to transform trade 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 expertise. You may construct a UNS utilizing OPC UA, SQL, or many different expertise stacks. So why is MQTT so widespread?

MQTT is straightforward. It’s report by exception. It has a versatile subject hierarchy that’s straightforward to know, 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 an excellent match. The aim of this text is to debate these in additional element with the intention 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, which 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 making an attempt 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 circumstances.

• Sooner or later, you might want different purposes to eat the information. MQTT simply allows 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 purposes, is it price adopting MQTT? For those who’re spending a whole lot of time customizing the information payload for the top software, it could be an indication that you just’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 expertise between units and SCADA, but it surely creates integration challenges as you progress up the stack.

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

Perhaps that is OK, however once I see this sample, my basic steering is to design an answer that may simply allow MQTT information entry if wanted, however to not require the expertise till you’re leveraging its advantages.

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

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

For those who’ve ever been fishing and had your line tangle, that is how I image this sample. The dependencies between subjects turn into arduous to trace because the MQTT subject namespace turns into cluttered. This makes it arduous to establish and debug failures.

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

3. Transactions By a UNS

Transactions are a typical information sample in manufacturing. The commonest instance of transactions are writes. For instance, you might wish to write set factors, clear an alarm, or another operate.

MQTT was developed within the 90s for the Oil and Fuel trade, 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 is no such thing as a strategy to simply get a write response. Sparkplug B does this with Command (CMD) messages, that are despatched on a novel subject, however to know if the write succeeded, you will need to monitor the information printed 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.

(Andrey-VP/Shutterstock)

There are some intelligent patterns to attempt to simulate transactions over MQTT. For instance, a typical sample is to difficulty a write on a subject with a novel 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 purchasers to know the protocol, and—worse—it rapidly pollutes the MQTT subject namespace by creating new subjects for every write.

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

For those who’re making an attempt to do writes by means of the MQTT Dealer, it could be an indication that you just’re misusing the expertise.

4. Massive Information Units

Factories have a whole lot of information. Methods like historians and SQL databases can simply develop to terabytes in measurement. There are a lot of use circumstances the place you might wish to transfer all or a few of this information between purposes.

In circumstances the place an MQTT Dealer is already out there within the expertise stack for real-time information, prospects could attempt to use it for historic workflows. MQTT is proscribed to 256MB message measurement, 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 occasionally.

The result’s an inefficient information change that would influence 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 measurement, it’s problematic. The dealer finally ends up storing and replicating the big message both in reminiscence or on disk.

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

5. Occasionally Used Information

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

(LeonidKos/Shutterstock)

If MQTT or Sparkplug B are the one information paths it’s important to the PLC, this information have to be configured and printed 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, may very well be difficult.

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

For those who’re pressured to publish information to MQTT that’s occasionally or by no means used, it could be an indication that you just want extra flexibility than what out-of-the-box MQTT supplies for these use circumstances.

Conclusion

MQTT is a key enabling expertise that has pushed UNS adoption. It’s a terrific answer for real-time machine information within the UNS, offering an open and versatile strategy to talk machine state and subscribe from many purposes.

However like all applied sciences, it has limitations. If a number of the examples supplied on this article resonate along with your structure, it doesn’t imply your structure is inherently incorrect, however you might wish to contemplate the professionals and cons of the strategy.

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

In regards to the Creator: Aron Semle is the Chief Expertise Officer of HighByte, targeted on guiding the corporate’s expertise and product technique by means of product growth, technical evangelism, and supporting buyer success. His areas of accountability embody analysis and growth and product growth and validation. Aron has greater than 15 years of expertise in industrial expertise. 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 Gadgets:

Learn how 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