Q: What is message queuing telemetry transport (MQTT), and why did you and Andy Stanford-Clark of IBM develop it?
Nipper: MQTT is a publish/subscribe protocol that allows edge-of-network devices to publish information to a broker. The broker can then forward messages to any client that has subscribed for a particular type of information. It’s a very efficient way to communicate, as it uses very little bandwidth. That’s one reason it’s being rapidly adopted for the Industrial Internet of Things (IIoT). It’s even used by Facebook, Amazon, IBM and many others. But for this discussion, we’ll focus on industrial uses.
When we created MQTT, I had already been in the SCADA (supervisory control and data acquisition) industry for 20 years. I started with Koch Industries, and I worked for them for eight years in their oil refinery and pipeline business. I had built SCADA systems for pipelines, for tank farm inventory systems and more. I had a lot of experience with industrial poll/response protocols. When AT&T was deregulated in the mid-90s, it was very disruptive for our industry. Most of the infrastructure in the United States had been using multidrop phone lines from AT&T. Then, the VSAT (very small aperture terminal) satellite communication vendors came in and started filling that gap. But what they had were proprietary transport protocols over their VSAT systems. So, we had a double problem: we had these poll/response protocols, and we had to convert them to use proprietary transport protocols.
Meanwhile, Phillips 66 was one of the first companies to get a TCP/IP-based (Transmission Control Protocol/Internet Protocol) SCADA system. But they wanted more information, and they wanted it faster, over a fairly bandwidth-limited network. So, we looked at it and realized the report-by-exception protocols that we had been doing — that were proprietary — were very similar to message-oriented middleware. With my 20 years in SCADA and Andy coming from a message-oriented middleware-centric infrastructure from IBM, we got together and in six months, we took the best of both, morphed them together and what came out of that effort was MQTT.
Q:What is MQTT’s key benefits for manufacturers and process industries in general?
Nipper: With MQTT, we’re applying modern IT technology to industrial control systems. The primary advantage is that we’re connecting devices to infrastructure, not to applications. Because if you look at any migration problem, any siloed data problem, it’s because you’ve gone out and taken an application, bought a piece of equipment, and then tightly coupled that piece of equipment to that application with a protocol. On day one, life is great. But on day two, or week two, or year two, when you want that information to go to another application, or maybe to several applications, you suddenly have a problem. MQTT lets you decouple devices from applications.
Q: What are some typical uses of this technology in an industrial processing setting?
Nipper: The ecosystem that we’re putting together with Cirrus Link Solutions and Inductive Automation addresses both greenfield and brownfield opportunities. So, it works well with new systems, and also when you already have existing infrastructure and equipment in place. One typical use case would be wanting to get more information from a progammable logic controller (PLC). For example, there are edge-of-network gateways on the market today that will talk to a legacy protocol, bring that data in and then publish the resulting process variable information using MQTT. Within that infrastructure, we also have devices that natively implement MQTT, which eliminates the need for a gateway altogether. So, we’re putting together a wide array of industrial OEMs at the sensor level, at the gateway level, and even applications. For example, OSIsoft, having a new MQTT Sparkplug connector, can now plug directly into an MQTT infrastructure.
Q: More specifically, how is MQTT being used in the oil and gas industry?
Nipper: Since MQTT was originally invented for real-time liquid pipeline control systems, that’s where we’ve seen the most use. It’s been used in those applications for over 20 years now. We see it everywhere from edge-of-network gateways all the way back to MQTT-enabled SCADA systems. We see it in SCADA/HMI (human machine interface), in MES (manufacturing execution systems), in how you put data into data historians, into ERP (Enterprise Resource Planning) systems, and into electronic flow measurement systems. We see it in oil and gas as a way to optimize bandwidth, decouple the data and to end up with a better real-time control system than what people had with the legacy poll/response protocols.
Q: What are some recent developments with MQTT and what is its role in the future of IIoT?
Nipper: In this market four or five years ago, there was a lot of talk about MQTT and how you would use it in SCADA, DCS (distributed control systems) and telemetry systems — but everybody was picking their own way of doing it. MQTT is very straightforward, very easy to implement, and it lets you publish anything you want, on any topic. You can publish a picture or a Facebook message. You can publish wanting your garage door to open and close. But no one in the industry had said, "Wait a minute. For this sector, we need to define some standards so we can all work in an interoperable manner." So, two years ago, Cirrus Link worked with Inductive Automation and OEMs in this space to create and define a specification called Sparkplug. Sparkplug doesn’t change MQTT, but it does say, ‘Here’s the way to use MQTT in the best manner for SCADA systems.’ So, we defined something that made sense for the industrial sector, staying with the original intent of MQTT to keep it lean and mean. We defined a binary transport for process control variables to keep everything efficient. And last but not least, we defined this thing within MQTT called ‘state.’ It maintains stateful session awareness. Because without state and without the knowledge of the TCP/IP connections to your end devices, you can’t do SCADA. So, that’s probably the most exciting development. And around that, you’ve got this whole ecosystem of companies that are doing real things today with IIoT.
Editor’s note: This Q&A was facilitated by Jim Meyers of Inductive Automation.
