The co-founder of Cirrus Link Solutions, Arlen Nipper has worked in the embedded computing space for going on 38 years. Through most of that time his focus has been on infrastructure solutions and embedded computers that do communications protocol conversion. He focuses on technologies such as MQTT protocol that let businesses put data to work faster and smarter, thus helping those businesses make decisions that are better informed because they’re based on real-time access to critical information. We talked with him recently about MQTT’s potential role in the subset of manufacturing called “packaging.” MQTT, by the way, is the acronym for Message Queue Telemetry Transport, a proven machine-to-machine data transfer protocol that is quickly becoming the leading messaging protocol for the Industrial Internet of Things. Among the specialties that Cirrus Link offers are MQTT Modules that can be added to the Ignition platform from Inductive Automation, which empowers companies to set up their own IIoT solution on a secure MQTT Message-Oriented Middleware (MOM) infrastructure.
What kind of issues are you seeing out there?
For 35 or 40 years now, we've been taking intelligent devices, and the very first thing that we do is we put a protocol on them, and then we connect them to an application. Then we’re stuck.
Innovation stops. So we run like that for four or five years, then we tend to rip it all out and put it all back in again, making this same mistake: "I'm going to connect this device to this application, and I'm going to connect this other device to this other application." The problem with such an approach is that if you want anything else from that device then you're going to have to go through the application. You're either going to have to rewrite the application or you're going to have to modify something that's off the shelf to where you end up with a one-off system implementation that nobody can support anymore. I’ve been in so many system implementations where someone points to a box sitting in the corner somewhere and they say “Arlen, we don’t know what that thing does, but we can’t take it out because if we do then this thing over here will quit working.”
Can you describe a food or beverage application that has caught your attention recently?
I’ve been working with a manufacturer in the dairy industry who has been very aggressive in making data readily available to executives throughout the organization by way of Ignition dashboards. But they’re having to stitch it together by programming the Ignition OPC-UA software to poll for all that additional information. There’s nothing wrong with that, it’s working fine. But they’re going to reach a point where they can’t poll fast enough for all of the information that they want. Wouldn’t it be better if their packaging machines, for example, could just publish all of the information and then they could have multiple instances of Ignition subscribing to subsets and super-sets of the information that they need?
How about applications outside of the packaging space?
I visited a car maker recently and I assumed that the majority of their data was going to be coming from PLCs that are watching robots on the factory floor and things like that. But in fact, almost half their data comes from torque tools. When a car is assembled the torque applied to the nut attaching your seat to the frame is known and is controlled by the MES system. Even though at the manufacturing cells they have PLCs and they have Ignition and they’re sitting there polling, MES can see that information. What this car maker wants to do, the architecture they ultimately want to come up with, is they want every device in the plant publishing information into the central real-time messaging broker. Then the plant operations systems can subscribe to that information in real time, and so can the MES, and so can all of their prognostic systems. So the idea is a one-to-many data relationship.
Help me understand what exactly do you mean when you use when you say “subscribe to.”
The way that MQTT works is that it publishes process information. In other words, it publishes data, whether that’s pressures or temperatures or bar code readers or the flow rate of yogurt into a container, and it publishes that on a topic. The topic spaces hierarchically. So whether it’s a car maker or a dairy company, that could be the plant name, the factory floor location, the machine name, the device name, and the process variable name. It takes that piece of information and then publishes it on that topic. Then here's where it gets cool. You de-couple the device from any one application. Let's say I'm watching a liquid filling machine and the guy that made the machine knows all this interesting information and is publishing it on Topic A. Now I can have Ignition connect into that. The data is flowing in, nobody's looking at it because we de-coupled it. Now I put in my Ignition system and all of a sudden it goes, "Oh, I see all of the MQTT data, which section do you want to look at?" Now we're really into the IIoT enablement phase of an OT (Operational Technology) infrastructure being able to connect to IT infrastructure. An IBM Bluemix infrastructure could plug into the same MQTT Server and watch that information. Microsoft Azure IoT Hub could plug into the infrastructure. AWS IoT could plug into the infrastructure. Red Hat AM-Q could plug into the infrastructure. What you've created is this data flow "namespace" with this big bubble in the middle (that's why it's called middleware) where all of your devices are connecting to infrastructure INSTEAD of applications. Now I can unplug my Ignition system that's watching the machines and nothing breaks. I can unplug it and plug it into somewhere else.
How would you summarize the business benefits that these CPG companies like Procter and Gamble or General Mills can gain from MQTT?
As things are now, they’re leaving data stranded. There are too many architectures, which results in confusion, not to mention the fact that it’s very difficult to maintain. I’ve been in so many meetings where the operational folks are on one side of the conference room table and IT is on the other side and they’re both talking and nobody knows what they’re talking about. I think if you start taking what we’ve done operationally with Inductive Automation and what we’ve brought to the table from an IT perspective, you can make a lot of progress. Where can I get into MQTT on the IT side? Every message-oriented middleware vendor has it, including Red Hat, Microsoft, IBM, AWSIOT, MuleSoft, and Oracle. Now if I can get my plant floor and my packaging equipment to at least start participating at the edge of the IT so that when I have a meeting now at least the IT, the OT guys, have some common ground. I think that’s huge.
