IT, OT & prepping legacy systems for digital transformation

You don't have to eat the whole elephant.

"There is too much noise the the market right now as to exactly what IIoT is," surmises Arlen Nipper, co-developer of the MQTT protocol and president and CTO of Cirrus Link Solutions. "And a lot of customers that I talk to don't know where to get started with IT/OT convergence. I recommend picking a problem and diving in. You don't have to eat the whole elephant." 

With four decades’ experience in SCADA and telemetry systems, Arlen Nipper was suited to be the expert source for the recent Smart Industry webinar ready to go quote graphic"Marrying IT & OT:  Equipping Legacy Infrastructure for the IIoT."

Smart Industry: Why is there still a huge gap between existing OT systems and available Industrial Internet of Things technologies? 

Arlen: Problem #1 is the fact that we are still doing OT in the very same way as we did when I first started in the industry in 1978. In 1978 I went to work for Koch Oil and had the opportunity to work on a brand new SCADA system they were installing on a new pipeline. We had a host SCADA system that was polling brand new Modicon PLC’s using Modbus. We’re still doing that today.

The notion of poll/response protocols at the central core of OT infrastructure MUST change. The very existence of poll/response protocols will need to disappear. Poll/response protocols dictate that we connect “devices” to “applications”. On day one that solves a problem, but then any future changes become harder and harder until customers get to a point were all innovation simply stops.  

Smart Industry: Is there anything around the notion of IIoT that we can say is actually different than legacy SCADA/DCS/ICS/etc.

Arlen: Yes! The Internet of People only began to grow exponentially when HTTP became standardized and freely available.

MQTT is in a position to do that. MQTT has been in existence since 1998 and is becoming the dominant transport protocol in the IoT world. But it was invented for mission critical, real-time, SCADA systems. Now we’re seeing it being applied to the solutions set it was actually invented for.

There is a wealth of information now available for the MQTT messaging transport. Here are some resources:

Using MQTT and available Message Oriented Middleware infrastructure, we can now start connecting Devices to Infrastructure and start to “decouple” intelligent devices from applications so that we can access more of the valuable information without having to run it through existing legacy SCADA/DCS applications. 

Smart Industry: What is one simple way end users can start taking advantage of this technology in their existing SCADA/DCS/ICS infrastructures? Must they rip and replace? 

Arlen: Cirrus Link just released an MQTT specification called “Sparkplug” that is an open guide for “how” to use MQTT in SCADA and real-time solutions. In addition to this specification we released working reference implementations on our public Github site written in Java, C, Python, Javascript, and Node Red tooling on node.js. All of these reference implementations are working examples and work in conjunction with the Inductive Automation Software Industrial Application Framework (Ignition). All reference examples run (as is) on a Raspberry Pi board and we’ve already had customers take these examples and port them to their own hardware. (Sparkplug MQTT Topic Namespace and Payload Specification and Reference Code)

Smart Industry: Why is HART transmitter data not being utilized? What's the fix for this? 

Arlen: With all of the ranting that I just did about poll/response protocols, I fully understand the evolution of HART and why it is constrained to 4-20ma instrumentations (in large part). But it goes back to my premise about connecting devices to applications instead of to infrastructure. For the HART gateway devices that are out there in the market, they still talk “a protocol.” The Emerson, Rosemounts, etc. gateway products along with PLCs that talk HART all connected to the Legacy Control System. The Legacy Control System usually does not care about the additional data from a HART transmitter i.e. it’s is probably happy with the Primary Process Variable that is coming in over the 4-20ma loop, anyway. 

So we need a way to decouple that HART protocol from any one consuming application and just let a Gateway device publish all (or a large portion) of the HART database into the middleware infrastructure. Now other lines of business are VERY interested in the Secondary, Tertiary, Quaternary process variables. They are interested in the HART device asset information, the calibration information, the configuration-change information. 

The reason HART-device information is not being utilized is that no one has provided a solution that makes this information available to the enterprise. To date it’s been constrained in the legacy control-system applications that were not interested in the data, so they didn’t get it. 

What we have worked on with Magnetrol is applying all of the aspects that I listed above to publish the Magnetrol HART Smart transmitter information into an MQTT Server infrastructure. From there we are building out various dashboard views, historical SQL database inserts, and overall CLOUD accessibility to the information.

Learn more about this and all of the Smart Industry Transformative Insights webinars here. 

bigger

 

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments