5 Widespread Pitfalls in UNS Design

5 Widespread Pitfalls in UNS Design
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 drawback we’ve confronted in factories for many years: Gaining access to machine information is difficult.

In observe, the UNS is commonly an MQ Telemetry Transport (MQTT) dealer with an ISA-95 subject hierarchy (Website/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 possibly can construct a UNS utilizing OPC UA, SQL, or many different expertise stacks. So why is MQTT so widespread?

MQTT is easy. 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 info, making it very versatile.

These qualities make MQTT a wonderful alternative 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 so that you could perceive the professionals and cons and make knowledgeable selections primarily based in your distinctive atmosphere.

 1. Utilizing MQTT As a Tunnel

MQTT is designed to be 1:N or N:1, that means a single producer of information 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 instances.

  • Sooner or later, you could want different purposes to eat the info. 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 for those who don’t have near-term plans to leverage the info in different purposes, is it price adopting MQTT? If you happen to’re spending numerous time customizing the info payload for the top software, it is likely to be an indication that you just’re utilizing MQTT as a tunnel. That is much more obvious for those who’ve adopted different applied sciences like Sparkplug B to allow the tunnel. Sparkplug B is a good enabling expertise between gadgets and SCADA, but it surely creates integration challenges as you progress up the stack.

The hidden price 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 improvement, we name this technical debt.

Perhaps that is OK, however once I see this sample, my common 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 typically 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 software sends uncooked information to a subject (e.g., /mytopic/uncooked) after which one other software subscribes to the subject, transforms the info, and publishes on a separate subject (e.g., /mytopic/cleaned). This sample may proceed, with subscribing to the cleaned subject and publishing an mixture subject, alarm subjects, and so forth. Rinse, wash, and repeat.

If you happen to’ve ever been fishing and had your line tangle, that is how I image this sample. The dependencies between subjects turn out to be exhausting to trace because the MQTT subject namespace turns into cluttered. This makes it exhausting to determine and debug failures.

The existence of this sample isn’t inherently dangerous, 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 most typical instance of transactions are writes. For instance, you could wish to write set factors, clear an alarm, or another perform.

MQTT was developed within the 90s for the Oil and Gasoline trade, classically referred to as SCADA or “Supervisory Management and Information Acquisition.” The important thing phrase is Supervisory. MQTT can publish to a subject as a technique to concern a write, however on condition that it’s a one-to-many protocol, there isn’t a technique 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 need to monitor the info printed by the gadget to see if a price modified. This will work for Supervisory Management, however inside a manufacturing facility, it’s typically necessary to know instantly if a write succeeds or fails to take corrective motion.

(Andrey-VP/Shutterstock)

There are some intelligent patterns to try to simulate transactions over MQTT. For instance, a typical sample is to concern a write on a subject with a novel transaction ID (e.g., writes/txid/123). The consumer 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 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, that means you instantly know the standing of the write and may act accordingly.

If you happen to’re making an attempt to do writes by the MQTT Dealer, it is likely to be an indication that you just’re misusing the expertise.

4. Massive Information Units

Factories have numerous information. Techniques like historians and SQL databases can simply develop to terabytes in measurement. There are various use instances the place you could wish to transfer all or a few of this information between purposes.

In instances the place an MQTT Dealer is already obtainable within the expertise stack for real-time information, prospects could try to use it for historic workflows. MQTT is proscribed to 256MB message measurement, which, in equity, is fairly massive. However MQTT is optimized for small to mid-sized messages delivered in a short time, not for transferring massive payloads sometimes.

The result’s an inefficient information trade that might influence efficiency of extra time delicate, real-time information within the dealer.

That is made worse if publishers use the MQTT retained function. Retained is beneficial when a brand new consumer needs to know the newest publish on a subject, but when this publish is 200MB+ in measurement, it’s problematic. The dealer finally ends up storing and replicating the massive message both in reminiscence or on disk.

Typically, SQL, historian, and huge file information flows are higher suited to different applied sciences like REST, FTP, and so forth., and shouldn’t be tunneled by 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 numerous different information that’s wanted much less steadily, if in any respect. For instance, perhaps 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 generally, it’s diagnostic data that isn’t wanted in real-time.

(LeonidKos/Shutterstock)

If MQTT or Sparkplug B are the one information paths you must the PLC, this information have to be configured and printed repeatedly for it to be obtainable within the occasion it’s wanted. If it’s not, this can require somebody to reconfigure the info uncovered by the gadget, which relying on location and availability, may very well be difficult.

The basis reason for this drawback is that MQTT is report-by-exception and doesn’t have a technique to expose what subjects/information can be found or management what information is shipped to customers. Different protocols like OPC UA resolve this by exposing a browse interface and permitting shoppers to browse the info that’s obtainable, choose what they want, and decide how typically to eat it. This strategy is usually higher when information is required on-demand,

If you happen to’re compelled to publish information to MQTT that’s sometimes or by no means used, it is likely to be an indication that you just want extra flexibility than what out-of-the-box MQTT offers for these use instances.

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 technique to talk machine state and subscribe from many purposes.

However like all applied sciences, it has limitations. If a few of the examples supplied on this article resonate along with your structure, it doesn’t imply your structure is inherently unsuitable, however you could wish 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 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 Know-how Officer of HighByte, targeted on guiding the corporate’s expertise and product technique by product improvement, technical evangelism, and supporting buyer success. His areas of accountability embody analysis and improvement and product improvement 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 a wide range 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 pc engineering from the College of Maine, Orono.

Associated Objects:

How to Address Scale and Performance Needs in IoT

Assessing Your Options for Real-Time Message Buses

Why Event Meshes Should Be On Your IoT Radar

 

Leave a Reply

Your email address will not be published. Required fields are marked *