About this Webinar

By now, most people who work in manufacturing and industrial organizations have heard about the Industrial Internet of Things (IIoT). However, many are wondering exactly how to take the existing technologies they have today and leverage new technologies to position themselves for IIoT tomorrow. One of the most crucial steps in building your own real-world IIoT solution is choosing the right messaging protocol. The low bandwidth, stateful awareness, and security of Message Queueing Telemetry Transport (MQTT) have made it the de facto standard protocol for IIoT architectures. In fact, MQTT was selected as the Top IoT messaging protocol in the Eclipse IoT Developer Survey for 2016.

In this webinar, Don Pearson and Travis Cox from Inductive Automation, and Arlen Nipper, the President/CTO of Cirrus Link Solutions and Co-Inventor of MQTT, will take you on a deeper dive into the components and infrastructure of an MQTT-based SCADA solution.

Watch to learn about:

• The essential elements of an IIoT architecture
• How to install an MQTT server and what happens after it's installed
• How to set up bidirectional communication between the SCADA platform and MQTT server
• The process variable tags that MQTT brings into the system
• And much more 

For our white paper on IIoT best practices, click here.

Webinar Transcript

00:00
Don: Good morning everyone. Welcome to today's webinar, "Design Like a Pro: Best Practices for IIoT." It's a really in-depth practical discussion of MQTT infrastructures. My name is Don Pearson with Inductive Automation. I'll serve as the moderator for today's webinar. And we have a couple of expert speakers who I'm just gonna introduce in a few minutes. Quick look at the agenda for this hour, start with a brief intro of Inductive Automation and our software, Ignition. I'll introduce our panelists, and they'll talk about the state of IIoT today. They'll talk about the challenges of implementing it.

00:39
Don: Then, we'll go into various aspects of using MQTT and IIoT infrastructures. Q&A, as I mentioned, will be at the end of the webinar. A little bit on company background, we started in 2003 and really, since day one, we've been an independent company. There's no outside investors. Really pleased that there are enterprises like many of those here represented around the world that have chosen Ignition for their HMI/SCADA, MES and IIoT needs. So far, we've actually had new installations in over 100 countries. But the Innovator Program, which is our go-to-market major focus, has over 1400 integrators doing that business across those countries.

01:21
Don: And since 2010, when we launched the Ignition platform, we've continued to experience explosive growth. The average annual growth rate here is exceeding 60% right now, and we just see... Well, actually, the theme of this year's conference is "Accelerate" and we're experiencing a lot of acceleration also and the challenges of keeping up with that here. If anybody wants more info, if you happen to be new to Inductive Automation, you can go to the "About Us" section on our site and you can get a look at the people, management background, etcetera, and some information that's put there by our founder, Steve Hechtman.

01:57
Don: Actually, we're used and trusted by thousands of companies. We got 41 of Fortune 100 using our software, as well as about a quarter of Fortune 500, almost any industry you can think of, oil and gas, water, wastewater, food and beverage, government, transportation, all sorts of packaging and many, many others. Software Ignition, first database-centric cross-platform, web-deployed industrial application platform for your HMI/SCADA and IIoT needs. This is not about Ignition today, but if you want more information, certainly you can download it. You can play around with it, it's fully functional, just six bullet points, it's web-based deployment. Unlimited licensing is certainly a very key thing of our business model, so it lets you use as many tags, clients, connections, devices as you want.

02:49
Don: Also, that happens to be very critical when you look at IIOT solutions, when you're talking about thousands of PCs, tens of thousands of sensors, you need something that's scalable, deployable. And also, it doesn't break the bank when you start scaling out like that because it's a server-based licensing. As security and stability, modular architecture makes it easily expandable and it's made for rapid development and deployment and has real-time control and monitoring.

03:19
Don: With that little snapshot introduction of our company and our software, our presenters today are Arlen Nipper and Travis Cox. Arlen Nipper has more than 37 years of SCADA experience, including SCADA system implementations for Fortune 100 Oil and Gas companies. He's currently president and chief technology officer of Cirrus Link Solutions and he just happens to be the co-inventor of MQTT. So, we're very pleased to have him here, not only for his current knowledge but his whole history of the evolution of MQTT as a transfer protocol, becoming the standard, if you will. He'll be talking a lot about that today, but Arlen, I gave you a brief scripted introduction, I'd like you to take a little more time and tell us a little more about your experience and your current role in industry.

04:06
Arlen: Thanks, Don, appreciate the chance to talk about MQTT again. Like you said, I've been pretty much in SCADA for 37 years, which I look back on and that's starting to seem like a long time. I did come out of college and went into the oil industry, working for Koch Oil for around eight years at the time that Koch was expanding. So, I actually got to do everything from run a Ditch Witch, to wire up the pumps, to programming the PLC, to putting in the phone lines, and just a lot of good experience in the actual industry. And then later, I co-founded a company called Arcom Control Systems that was an OEM computer manufacturing, so spent basically 25 years in industry, designing embedded computers for general use, specifically, still in the oil and gas segment.

05:06
Arlen: We made edge of network devices as we know them today. And at the time, that was for protocols like Modbus and Allen-Bradley and Westvac and things like that and we make protocol converters. We convert protocol A to B and then, we would convert B to C and then, C to X, Y, Z. And a lot of just infrastructure experience as the industry moved from running everything on four wire-dedicated phone lines with Bell 202 or Bell 212 technology all the way through the transition into a lot of usage and VSAT for wide-area SCADA, and then ultimately into a dominance of TCP/IP on most of that infrastructure.

05:57
Arlen: So, a lot of experience there and then, along that path, I had an excellent opportunity to work with Andy Stanford-Clark of IBM, and we got together and took these two completely separate worlds of wide-area SCADA, expensive communications and IT-based infrastructure where bandwidth is basically free and unlimited and literally put those two worlds together, and this is about 18 years ago, and the outcome of that effort was what we know as MQTT today.

06:37
Arlen: For the first 10 years or so, it was pretty much relegated to IBM WebSphere-based products, but then a lot of activity and pushing it out into the industry. So that would include working with IBM and getting the Eclipse Paho group started up. Eclipse Foundation is an open software group that basically produces most of the IDE tools that the world uses today, and they also have an Internet of Things working group now, where most of the core MQTT technology's based. And there'll be references to that in this deck that people can go and see what's happening in the Eclipse Foundation as far as IoT in general, and IIoT specifically. So with that, I started Cirrus Link about... Or co-founded Cirrus Link about four years ago, and our focus really has been to take this wealth of knowledge that we had in doing one-off infrastructures and then working with Inductive Automation to make this a lot more available, as we have outreach programs to start getting to the actual equipment manufacturers and the excellent tooling that we get with Ignition for people to see this stuff working day one, and it's pretty exciting for me. So with that, Don, I'll turn it back over to you.

08:12
Don: Arlen, thanks, and I do appreciate you taking a little more time to put into context around the background and sort of how we got where we are, which bridges right into our other speaker today, is Travis Cox. He's Co-Director of Sales Engineering here at Inductive Automation. Travis started with the company in 2003. He filled an important role of leadership all throughout his time here as head of training, originally, head of support department, before his current role in sales engineering. He's an authority on the Ignition product who's helped really create hundreds of impassioned Ignition advocates who are driving the company's growth and driving the growth of their own companies. So Travis, I'm gonna give you also the opportunity to... That's my scripted intro, a little bit more of the intro of yourself from you.

08:55
Travis: Yeah, well, thanks Don. I'm really happy to be here to talk about this topic. I think it's a really timely and important topic to be looking at. Myself, I've been with the company since 2003, so 13 years now I've been in the industry. I was a complete pure science and IT background when I started. I learned... Came in and I found this industry and learned all about it and I'm really happy to now try leading the industry with the technologies that we're looking at here today. So I'm certainly an expert on the Ignition platform, which we're gonna talk a little bit about today, 'cause that'll be some of our examples, and always available for questions and demonstrations afterwards.

09:38
Don: Great, well, with that, I'm gonna turn over you Travis. So pick it up and begin us on to today's program.

09:43
Travis: All right, well, thanks Don. So today, we're here to discuss the best practices for IIoT. And for those of you who don't know what IIoT stands for, it stands for the Industrial Internet of Things. So you probably have heard about it, there's a lot of buzz about IIoT, or IoT in general, and what I mean by this is really, what is the best way to implement IIoT with what you have today, and how we can actually get some results from what we're implementing with this? So let's take a look at where things stand right now in regards to IIoT, and how we can build from there. The good news is that IIoT is here today. It's not just a dream, and it's not even a new idea. As Arlen was saying, he's MQTT and the things he's been doing have been around for 30 years. The capability for IIoT is also here already, so why has there been more talk than action? Well, largely this is because organizations have to figure out how to leverage new IIoT technologies while working with their legacy systems. The reality of the current technology landscape is that there are still hundreds of millions of proprietary legacy PLCs and devices out there. Those legacy devices are going to be around for probably the next 10-15 years at least.

11:03
Travis: So our first big picture tip is to plan a slow transition, because you'll probably be using proprietary devices for a while. If you have a SCADA system and you're polling, you can't just switch to a different process tomorrow, it'll be very difficult and very hard to get it working the exact same way. Instead, you should gradually build your new infrastructure in parallel. By making this a long-term effort, you allow yourself the time it takes to make sure your new process is working before you stop the old process, and the good news is what we're gonna show here today is a way of getting this architecture implemented today and allow you to have that transition. Now, an important step in that transition is choosing which messaging protocol to use when it comes to IIoT. The common protocols fall on two basic groups. There are the publish-and-subscribe protocols in which devices connect and publish data to a topic on an intermediary broker, and there are the client-server protocols, which are dependent on having the client connect to the server and make requests of it. So as you can see here, MQTT, AMQP, DDS, and XMPP are all publish-and-subscribe protocols, while OPC UA, HTTP and others are client server protocols.

12:21
Travis: So which type of protocol is the best, pub/sub, or client/server? In general, pub/sub protocols are more scalable because they decouple devices from applications, and this is a really important point. Rather than connecting applications directly to the devices, or to the systems, we are gonna connect it to infrastructure. We're gonna decouple that by having information being published to middleware and then information being subscribed from applications. They are more efficient because instead of requesting the same data over and over, they let you subscribe to just what you want, and multiple applications can subscribe to the same information because you have that middleware. So of those Pub/Sub messaging protocols, which one is the best? Well, from inductive automations research and from everything we've found, we recommend MQTT as the best choice for IIoT. MQTT is a protocol, but more than that, it's an architecture, and Arlen's actually gonna explain a lot more about MQTT in particular and how it works. Arlen, can you do that for us?

13:29
Arlen: Thanks, Travis. So as I mentioned, MQTT is not new, it's been around for a long time. Andy Stanford-Clark is the IBM engineer that I worked with when we developed this. And as I note, we had completely separate worlds at that point in time. So I go back to the statement that, "In operations bandwidth is neither free nor unlimited, and in IT bandwidth is free and unlimited." And we had a challenge in front of us in that kinda the requirements that we had at the time for Phillips 66 was, whatever infrastructure we had to come up with had to work over 300 baud dial-up networks, so 300 baud running serial line IP. And for VSAT systems, we already really needed to eliminate the poll response of polling over the VSAT, because it was too expensive, and really VSATs don't lend themselves well to that. So as we started putting this together, we turned to taking aspects of what IT were already using, whether you call it SOA or enterprise service bus, these Publish and Subscribe architectures to decouple applications and apply that same thing to decoupling devices. Now, as Travis said, if there's only one key point that you take away from this presentation, it's the fact that when people ask this, "What is IIoT? Why is it different from what we used to call telemetry, what we used to call STATA, what we used to call DCS, what we used to call ICS?" and the difference is we are talking about connecting devices to infrastructure.

15:27
Arlen: And think about that for a minute. Even if you have a proto... Like an OPC UA server, you've got to set that up, and now you've got a protocol with, say Modbus, and that server is responsible for sending those Modbus polls and getting the response back, and then that goes into your operational application. And what we're talking about, one of the notions of the Internet of Things in general, is to make device information more available to the enterprise. So now as a Line of Business person, I'm sitting there looking, and I've just bought a brand new flow computer, and we've installed it out in the field. And operationally, I probably only need things like temperature and flow rate, those are the operational parameters that let me operate that pipeline safely. But from a Line of Business standpoint, my measurements department might wanna look at the last calibration information, what was the orifice plate size. The finance department definitely would like to take a look at the tickets and other interesting information, because basically that's the cash register on the pipeline. So now you've got this dilemma in that you're gonna have to go into operations and have them change the way that they're polling that flow computer to get information from the device into the operational system just to be handed off to a Line of Business application; operations may or may not wanna do that.

17:00
Arlen: So again, the important thing to realize here is that with MQTT architectures, we've basically flipped the connectivity 180 degrees. So instead of me having a host computer that connects out to 500 devices over 500 different networks and firewalls and all of the security risks, now we're talking about clients connecting inbound through a single port into an MQTT server. So let's go through some of the aspects of MQTT and how we take advantage of those. So the first thing is MQTT... And it's really interesting for me to watch, like I said, it was very in-the-background for more than a decade. But with the advent of IoT and people looking at new ways to do things, it's really interesting to see how it's exploded in just general applications. It's a very interesting survey, the Eclipse Foundation every year does a survey of all of the IoT developers, and for that equipment that's going to be manufactured in the future, if you're looking out, and if you're looking at, "What are people developing on today?" Over 80% have chosen MQTT as their real-time messaging transport. But the key point is, now it's becoming highly available. One of the examples that I give is that if I have the graduating class of computer science, computer engineers, in front of me today, and you said, "Okay, how many of you guys already intimately know OPC UA?" Not many people are gonna raise their hand.

18:54
Arlen: "How many know how Modbus works, or Allen-Bradley protocol or Siemens protocol?" there won't be any general knowledge of those industry-specific protocols. But ask them, "How many of you guys have a Raspberry Pi in your dorm room or an Arduino, and you've already downloaded MQTT and you're using it to turn your lights on and off?" And I'll bet over half or almost all of the audience would raise their hand, because we're getting that exposure, because people like playing with those sorts of technologies. So we're coming... It's a standard that's well known. We have a lot of general knowledge around MQTT. And it's already known in the IT world. So now we're being able to leverage our IT department along with our operations department, so we can have kind of that middle infrastructure where we can be talking about the same thing. And again, with what we're seeing and what you're going to see today at the upcoming ICC show, a lot of manufacturers are starting to embed MQTT natively on their equipment. So let's go through just a few things on why MQTT is perfect for IIoT. We'll go through the low bandwidth that it requires, we'll go through the security, and most importantly for most operational systems, we'll go through its stateful awareness.

20:22
Arlen: First and foremost, we had to design MQTT to work on very low bandwidth systems. Now, you look at that today, and before, I could have said that low bandwidth would save you money. And now we're looking at it from the standpoint that not only that, but if I can reduce the amount of bandwidth that I'm using today, both on factory floor as well as on lighter risk SCADA, if I can reduce that by 75%, 80%, 85%, then that gives me much more bandwidth to bring some of that other information that's being left stranded out in the field, and bring that into an enterprise. Most MQTT implementations that are in the field today, do use report by exception, and they eliminate the poll response that Travis was talking about previously. Now, MQTT doesn't dictate that you send everything report by exception, but as you can imagine, in most operational implementations, that's a much more efficient way to send your information. The other design decision that Andy and I had to struggle with, with MQTT was, do we put MQTT on top of UDP? Or do we build it on top of TCP? And we did make the decision. Ultimately, I believe it was the right decision to base MQTT on top of TCP/IP. So that means that now, we can un-leverage whatever security schemes the enterprise has dictated for TCP/IP networks, we leverage those for MQTT as well. Now, of course, in today's world, TLS is the most popular. Historically, we did use SSH, we would use SSH tunneling.

22:15
Arlen: So it's pretty much up to the enterprise, whatever security model they want to apply to the infrastructure. The other thing you have to realize, and again, imagine in a central MQTT server and thousands of devices are connecting into that MQTT server. So now you've got a single point of security management. So if you can imagine an MQTT server setting inside of a DMZ zone, now you've got a single point where you can control everything, both the applications connecting as well as the devices. The most important thing in understanding MQTT and understanding how reports by exception works is that they're historically, I've been in the industry long enough to know that they were all sort of reports by exception schemes. But the fact is, you have to have state, if you're going to have your devices on your edge of network devices publish information in the report by exception. So we'll go through that here in a bit more detail. So most of the implementations that I've looked at... A lot of people aren't aware of some of the more subtle aspects of MQTT. When we designed it, it already got what we call, "A last will and testament." And to properly implement SCADA, you've got to have this notion of being able, when you're an MQTT client, to register yourself and say, "Hey, if I would die, if I fell off the TCP/IP network, then I'd like for you to deliver my death certificate on my behalf."

24:04
Arlen: Now, what that means is, if you can imagine, again, thousands of MQTT nodes all connecting into an MQTT server. You're using the MQTT engine on Ignition, but you wanna know, "What is the actual state, within seconds, of all of these connected devices? Or did somebody cut a network cable?" And by using the last will and testament capability of MQTT, we're able to say, "This is the state of all of your devices, and we know your state for the rest of its life. It's either gonna be online and publishing information when it changes, or it's going to have to publish a death certificate, and then that data, in Ignition, will be shown as stale data." Now, a lot of this is covered in the spark plug specification that series link has publicly put out onto our GitHub site. This is one drawing, and this kind of goes through that state diagram where on the right side, it shows your device or your edge of the network node. In the center, it shows your MQTT server. And on the left side, it shows Ignition. And you can see from there that a device connects and it registers its state, if you will, it registers its last will and testament, and now Ignition and MQTT engine know that that device is online, and it will deliver information if and when it changes.

25:39
Arlen: Now, in bubble number four there, we had, let's say rain fade on a VSAT, or a cellular network went down. Well, in the time to live definition of that device, the MQTT server will publish the fact that that device is no longer available. And now of course, in Ignition, those tags are represented as stale data, and we know the state. When the device comes back online, he republishes his birth certificate. Now, the engine knows that that device is available, I've got all of the tags, and I've got all of the latest information. Interestingly enough, we've been talking about MQTT to customers, and this is... Under NDA, this is an anonymous quote, but it was... We all knew this in our heads, we alluded to it, but when he said, "Arlen, this is great," all of our engineers were talking about MQTT. They don't want direct API calls anymore. And I just wanna note that a lot of the operational technologies that filtered down to us from IT tend to be REST-based, and in my mind we've moved the polling problem from Modbus to REST. Because now, again, I can make a REST request, and I give the data back. But it's just like Modbus, is that, okay, I poll for the valve status, I know it, well, now I'm gonna have to poll again because I don't know it now, I'm gonna have to poll again. So we've moved the polling from the protocol into the polling of informational systems.

27:24
Arlen: But with MQTT, the beauty of this is you just subscribe to the topics that you want, and when that data changes, you get it. So I think a lot of our customers are really starting to get how this all goes together and how to take advantage of it. There are basically three ways to implement an MQTT infrastructure, we're gonna go through them very quickly here. We are seeing a lot of people in industry looking at MQTT and putting it on natively, but in the transition, you can use edge-of-network devices that communicate the native protocol, can take those register information locally, so now your polling has moved out right by the equipment, and then that converts it to MQTT and publishes it in. What Cirrus Link has done to try to really accelerate this is we documented, if you're gonna use MQTT in a real-time operational system, then this is how you should do it. We put that spark plug... It's called the spark plug specification, and there'll be resources here that you can get to, but we've got reference implementations running on Raspberry Pi's, and if you download Ignition and all of the components in trial mode, you can get all of that up and running and really do a deep dive on what's happening under the covers with MQTT. So with that, I'm gonna turn it back over to Travis, and he's gonna go through some of the architectures and the components that enable MQTT on Ignition.

29:00
Travis: All right, thanks, Arlen. So I wanna talk about the architecture here and the different pieces of the architecture, and then we're gonna go through an actual demonstration where we can show a system up and running live that demonstrates each one of these pieces. So this diagram you're seeing here on the screen shows the Ignition platform and it shows the Cirrus Link MQTT modules for Ignition, but we're gonna emphasize the three main components that we have on here. The first one is the edge-of-network device, as Arlen was just talking about, and that is to poll the legacy protocols of the PLCs and convert that to MQTT, or it could be, of course, a device that talks MQTT natively, but that's the edge, that's where the information is that's gonna be published up. The second part of this is the MQTT server, and often called a broker as well, that is going... All the information is gonna be published too. So that's the middleware that we're dealing with. On the diagram here, it shows the MQTT distributor module right there in the middle, and that is a module for Ignition that is an MQTT server. The last piece is the MQTT client, and that's the piece all the way to the right here which is illustrated as the MQTT engine module for Ignition, and that client is gonna subscribe to the interesting information from the MQTT server.

30:15
Travis: Now, that could be Ignition, it could be any other line of business application, as Arlen was mentioning earlier. So in these three main pieces, this is the infrastructure we're dealing with. And so instead of having a SCADA system like Ignition talk directly to the PLC, it's gonna go to the MQTT server, and we can have lots of edge-of-network devices publishing its information up to that MQTT server. So this decoupling of intelligent devices from any direct connection to one consumer application is really the key principle here that we're dealing with. I think it's a key principle of IIoT in general. So, we look at these pieces individually, the first, of course, is the edge-of-network device, and there are three approaches to utilizing an edge-of-network device. Arlen alluded to this, but first is an edge gateway that bridges legacy devices to MQTT. And so that could be... There's a lot of IIoT gateways out there that talk to PLC protocols natively, such as ALEXUS ready gates and MOXA, and then EMB, Smart Works, and a whole bunch of others make these gateways that bridge from legacy protocols to MQTT. The second is, a lot of new devices, as Arlen and... Cirrus Link and Inductive Automation are working with a lot of car manufacturers to build MQTT on the actual device so it can natively speak that, in which case it would really be plug and play when you wanna get those devices.

31:51
Travis: And the third is if you don't have a hardware but you do have OPC servers and you want to get that information into this infrastructure, Ignition has a module called the MQTT transmission module, which talks... It was made by Cirrus Link, and that talks to OPC UA servers, it polls the devices, and can publish that information to an MQTT server. So the edge gateway here, being able to do this, you can really think of it as a combination of routers, network box, terminal servers, and network arbitrators. Like all of those devices, edge gateways are used for dealing with existing infrastructure. The edge gateway is a big part of the answer to the question of, who we can take, what we have now, transition into new technology, and also be able to add more technology later in the future. So it's a critical piece to work with legacy devices. As a general best practice for these edge gateways, you should make sure that you have edge gateway that can publish through cellular or satellite or have multiple ways to publish that information. The idea is that these devices... You don't want a single point of failure, it's gonna be publishing up to that MQTT server, you wanna have redundancies through all of that, which is multiple MQTT servers as well as multiple channels to publish that information.

33:18
Travis: So like I said, the MQTT transmission module for Ignition allows us to take OPC UA data and bring that into MQTT. And we're actually gonna demonstrate this module here today, so you can see it, but it allows us to bridge these tags and it could be any tagnition that we can publish up. So we'll look at that in more detail as we do the demonstration. Now, the second piece is the MQTT server, and often called a broker. MQTT servers in general, enable MQTT clients to securely connect devices, publish data and subscribe to data. As a side note, servers are sometimes... Like I said, are referred to as brokers. Now different companies make their own brands of MQTT servers. Amazon has an MQTT server called AWS IoT. Microsoft Azure has an MQTT server called the Azure IoT Hub. Serious Link has an MQTT server called Chariot broker. In Ignition, there is the MQTT distributor module, which is also made by Cirrus Link. And there's also a high MQ, Cloud MQTT, Red Hat AMQ, and Vern MQ, and potentially many others are out there. The idea of MQTT is an open standard. There are lots of options for each one of those pieces of the architecture.

34:33
Travis: Now, the distributor module that we have for Ignition is a small self-contained MQTT server, it's inside the Ignition platform, so it can give you a complete architecture on-premise, and will allow you to really take advantage of this message-oriented middleware solution. So it's designed to simplify and speed up the process of getting a complete infrastructure up and going. Now, the third piece here is the MQTT client. So we talked about the edge and the server, now let's look at subscribing to that data and bringing that information into an application. So basically, all these clients do, like the MQTT engine module for Ignition, they connect to the server, they can subscribe to one or more topics or information, and so they can see that and be able to work that in the application. MQTT is two-way, and that the client can write a command which can actually be sent all the way down to the device, allowing you to securely write to the PLC. Of course, there are security and various things put in place so that we can protect what's there, as we'll talk about more later. So the engine module for Ignition really is a key component that enables Ignition to act as a nano MQTT citizen, and like we said earlier, it allows you to communicate bidirectionally, and it's a very secure solution to be able to access all these devices.

35:57
Travis: And it doesn't have to be just Ignition that can subscribe to data, like I said, there are a lot of business applications, CRMs, ERPs, and many others can work with that same data in the middleware and the MQTT server. So with that, I would like to demonstrate the whole infrastructure, so you can see how this works. Now, the first thing you wanna do when you set up an infrastructure is get an MQTT server in place. And so for me, I have installed Ignition here on my local machine, so it's on this PC that I'm on right now, and I'm gonna make it an MQTT server, and I do that by simply installing, if I go to my modules, just going out here installing the MQTT distributor module for Ignition. Like we said, you could have another MQTT server, it could be the ones we listed on that page, but to get up and running very quickly, we can use the one inside of Ignition. So now that I have that, if I go over here to my MQTT distributor settings, I can configure ports and I can make sure TLS is configured, I can set up the access control lists and users and passwords and really get the server configured, but now that it's installed, I now have an MQTT server and in my network here, at the IP address or the host name of the server.

37:15
Travis: Now, the next piece that we wanna get in place is... For Ignition, I wanna start seeing that data, so in order to see the data, I need the MQTT engine module. So for that, we're gonna go to the modules again, then we come down the bottom and install the MQTT engine module, and this allows us to subscribe to all of the information within that server. So once I have it installed, we have to specify to this engine which servers we wanna connect up to. So we go over here to MQTT engine settings, I now have the ability to connect to one or many MQTT servers. MQTT is very highly available as you can connect to multiple and have a lot of redundancy built in, so I already... It already added one entry in here, which is connecting to myself on the local machine, but if it was a different IP address, I can go on there and I can edit that and change it. So in a sense, right now I'm ready to go, I can start seeing information inside this MQTT server. So, if I go to my...

38:14
Arlen: Travis, Enable your commands.

38:21
Travis: I'm gonna come back to that Arlen.

38:22
Arlen: Okay, okay.

38:23
Travis: So, I have a designer here now. So without configuring anything inside of Ignition, if I go to my tag database and go to all my providers, I have the MQTT engine. And you'll see there is an edge nodes folder already. If I go in there, I already have stuff... Information being published to this MQTT server, so what I already have here, and you're not seeing, it's on my desk, is an ALEXUS ready gate product that is an edge gateway that is talking to a Mycologist PLC, it's pulling it through its native protocol and publishing the information up here to this MQTT server, and that's already... Was already set up and to publish here, so as soon as I installed the module, data was starting to come in, so here it is, I'm getting the information. I'm also getting information about the metrics of the device, if it's online, information about its birth counts and death counts, and its metrics that we can look at, and I'm also getting metrics on the actual edge gateway itself, which is the ALEXUS ready gate product, 'cause it can actually talk to multiple different PLCs. So a lot of information as soon as we connect up to it, and I can now go to a screen in Ignition and we can just start dragging this information on the screen, and to start building out an application to start looking at that data.

39:43
Travis: I didn't have to do anything as far as connecting it to the actual devices directly, we're just subscribing to the information. Now, I can do the exact same thing with connecting another Ignition server, or OPC UA, bringing that, bridging that to MQTT. So if you don't have an actual edge gateway device or a device that talks to MQTT natively, well what we can do is we can install Ignition, which I have here in another server, I have it on this 10.20.7.127 server within my network, and I've already installed... If I go to my modules, I've already installed the MQTT transmission module that bridges OPC UA to MQTT. If I go over here, I'm connected to... If I go to OPC connections, the Ignition is an OPC UA server, I can also connect or many other OPC servers. And in Ignition, I've got connections to a control logics PLC, a Mycologist PLC and a simulator. So with that, I've already configured some tags. If I go in here, I'm calling this edge gateway 002, and I've got three devices, I've already got tags in here... This is the designer for that particular server, and I wanna publish all this data to my central MQTT server, so all I've gotta do is simply install the MQTT transmission, which is installed, I'm gonna point it to that MQTT server, one or potentially multiple of these.

41:11
Travis: So I'm gonna call this MQTT server and the URL is this one, and I'm using a password to get access to it, and that should be it, if I can type these in there correctly and create the MQTT distributors where I'm gonna connect up to, gotta specify the type, and go and create the server, just by doing that, now we can start publishing that information up to the MQTT server. So again, now that I have that set up, if I go back to the designer here where I was looking at edge gateway 001, that ALEXUS ready gate product, if I refresh, now, without doing anything on the central server, I now have 002, in that, I got my devices and also all the metrics for the devices, and I've got my Mycologist, there's all the tags, I've got the control logics, its tags, everything is now publishing its information up. So now you've seen the two different systems, how we can easily get data to Ignition, of course, now we can view that information, go on a history alarming, all this fun stuff to the information that's being published up automatically for us. Now as Arlen was mentioning earlier, MQTT is bidirectional, so I can actually go into the engine and I can allow outbound tag writes, commands that are being outbound, and allow that to actually happen here. So I go back to my designer, so in just a moment now, here we go, the tags are connected again.

42:45
Travis: What I'm gonna do is actually bring two designers over here, so you can see them side by side, here is the actual server that's publishing the data, so this is the one that's connected to the actual devices, so if I go down here, look at N712, for example, it's a zero. If I go over here and look at the same tag in N712, of course, I'm gonna enable myself to rewrite, go and put a value of one, enter, and I wanna see that information being written down to that PLC as a one, showing the bidirectional nature of MQTT. Now, certainly there's a lot more we can set up as far as access control lists and others that allow us to really get access to this, but imagine this scenario... In fact, don't even imagine it, just imagine how it can be used in your case, 'cause it's a reality here, that you go get a new device that talks MQTT natively, you plug it into your network, if you have the infrastructure in place, it is automatically available within your environment. There's nothing to configure. You have legacy stuff. Sure, we can connect these things with Edge gateways, a little bit of work to then enable yourself to have this infrastructure that reduces bandwidth, is more secure, and protects the PLCs within our network. And so with this, this is why we wanted to do this webinar to really have you understand the architecture behind IIoT, so you can see what's possible there. Arlen, do you have anything to add or comment on from the demonstration here?

44:13
Arlen: Well, I can. I know that I waited for 16 years for a product like Ignition to come along, so I could actually do this. Because everything that you just did, Travis, I had to do on a whiteboard for 15 years, and I had said, "Please trust me, this does work, and it's fast and it's sufficient, it's highly available and scalable" but now you can actually see it. But the interesting thing here is that everything that Travis is watching here, if you could plug another MQTT client into that MQTT server that he's talking to and get access to the same real-time information, so now we've already set it up, but it's OT led. That's one of the notions we hadn't brought out is that what we're talking about is that I'm... As an enterprise, we keep getting stopped at the door because we can't go in as IT and say, "Oh, could you please use this infrastructure because we wanna be IIoT based?" We've got to show customers working operational SCADA systems that are better than what they had, and if we can do that, now, we've opened the door for IIoT enablement.

45:30
Travis: Do you make a quick comment here on the bytes received and transmitted, just to talk about that for a second?

0:45:38
Arlen: Well, first of all, right now you can see that the bytes transmitted aren't moving, but yet you're pulling that... But yet you can see how quickly the information is updating. So right now where you're at, right now, Travis, you have state. You know that the state of transmission on the other end of that connection is up, and you're going to trust that it's publishing real-time information, so your bytes transmitted is not moving but your bytes-received is going up every time a data and point changes in the field.

46:12
Travis: Thanks, Arlen. Hopefully, you guys can all download Ignition and install these modules and really see this architecture in action, bridging your legacies you knew. And at our conference, I'm gonna mention again, at ICC 2016, we're gonna be having a lot of hardware vendors there who are building MQTT and the spark plug specification into a device to really make this an open, interoperable, and plug-and play system. Arlen, back to you for the migration strategy.

46:42
Arlen: I think everybody on the call probably fully realizes that every time we take devices and connect them to applications and we get a whole infrastructure built up, we build yourself into a corner, we get into a catch-22 situation where, oh, there may be the latest and greatest PLC available, and I really wanna use it, but it doesn't talk my protocol, so I need to upgrade my SCADA host, but I can't do that until I upgrade the other PLCs. And we get into a very, either a complex topology or nobody knows how the system works anymore. And so what we do is, again, you showed the ALEXUS director. And so this is for actual pipeline companies that we work with on a migration strategy, is we don't have them eat the elephant in one bite. And so what we do is we put an ALEXUS director out there and use its terminal server, terminal client capabilities, and its ability to be a cellular TCP/IP endpoint, a VSAT IP endpoint, or an Ethernet IP endpoint, and we go ahead and connect to its internal terminal server and we keep the poll response going just like it has been. But in parallel to that, then we start enabling the local polling engine to start polling for real-time information in parallel.

48:10
Arlen: Now, what that allows us to do then is, we can have a production system sitting over here that's still using all the conventional poll responses, and we can have a test and dev system that's starting to peel back the ability to do devices using MQTT. And then once everything has been checked out and everybody's comfortable with this whole concept, then we slowly cut that single site over and then we go to the next site. So at no point in time do you have any operational risk, but what you're doing is setting yourself up so that ultimately once you end up with a pure message-oriented middleware SCADA system, now you've basically got a plug and play SCADA system. Do you wanna evaluate a new SCADA host system? Plug it in. You have a new leak detection program? Plug it in, or unplug it, but with topologies today and infrastructure today, that's the problem. When you connect devices to applications, things are serialized to where we can't unplug it. If we unplug this, things break.

49:28
Arlen: Also, then, transitioning into that, we are, but both Cirrus Link and Inductive are trying to do as much open source and best practices as we can. The MQTT is an international standard now, so here's a link to the latest Oasis version. It's also an IEEE spec now as well. Here's the link to the Eclipse Foundation resources, Paho and Kura resources. And of course, like I said, we have... The latest spark plug spec is running on a Raspberry Pi. This is the link to our GitHub site, and if you're interested in reading much more in depth on how MQTT is used in real-time SCADA, then that spark plug spec is a very good document to start with. It's also got reference implementation code and Java, Python, JavaScript, and a Node-RED implementation. So really, again, anybody on this call is interested, this is a good way to dive straight into MQTT infrastructure. And with that, Don, I'll hand it back over to you.

50:49
Don: Arlen, Travis, thank you guys really very much. A quick wrap-up, because we've got some Q&A here, we might run a couple minutes over because we've got a lot of great questions in the queue right now. A couple of things, obviously, here's the summary. Transition slowly, choose MQTT as your IIoT messaging protocol, use stateful awareness MQTT, make sure that the edge gateways are redundant. If you offer Ignition's IIoT solution, use the MQTT transmission, distributor, and engine modules. And whichever MQTT solutions you use, it's best to leverage open-source development and data encoding for that. If you're new, I mentioned this at the beginning, but if you're new to Ignition, download it, try it, it's the most direct way to look at it for yourself. You can also call us, there will be a number at the end, we'll set up a demo, we'll do whatever we need to do to make sure that you get a chance to improve your understanding of Ignition. Let's bridge into Q&A now, if you're cool on that. You guys got a lot on the lineup. Travis?

51:51
Travis: There was one question in particular, where can we get these modules? And for Ignition in particular. So if you go to InductiveAutomation.com, go to the Downloads area, you can download and install Ignition, of course. The installer is up at the top. At the very bottom of the page, you'll find the MQTT modules, the distributor engine and the transmission module, and you can play around with these, all self-contained. Of course, if you want different MQTT servers or brokers, there are, as we listed all of them out there. You can go to those websites and find more about that as well. And you can visit... Also, you can visit Arlen's website for Cirrus Link. Arlen, it's cirrus-link.com?

52:37
Arlen: Yup.

52:38
Travis: So, you can find out more information just in general about the whole solution as well as the Edge Gateways and more information in that regard. So, I wanted to mention that here briefly. I have up here some information on contacting our account executives if you wanna have a demonstration on this. With that being said, we're gonna go into it, address as many possible questions as we can here.

53:01
Don: Yeah, and as Travis is doing that, I'll be sort of monitoring the questions but just know that if we don't get to all the questions, we're gonna spend a few more minutes here 'cause there's some great questions. The account execs will follow up and make sure we bridge an answer from Arlen or Travis or get your question answered one way or another. So, that's why this contact information I think is important too. So, with that, let's just start and say, I'm guessing you already have Gateways for Modbus and DNP3?

53:27
Travis: So, certainly the ALEXUS ready gate product or director we were talking about here that I'm using, that's the one I'm using in the example here. That one has over 200 protocols built into it, it is all self-contained in one hardware, you can go to the ALEXUS website to find more about that product. There are other IoT gateways as well. We're gonna be showcasing a lot of these at the conference, it's the ICC 2016.

53:52
Don: Great, that answers your question too, Gavin, about what Gateway is being used right now by Travis. So, we're gonna go pretty fast here. In terms of this one, I'm gonna throw your direction on, will the Node-RED implementation work on any device that supports Node-RED or is it only for Raspberry Pi?

54:15
Arlen: It's already running on about half a dozen different platforms. From your laptop to any embedded system that will run Node-RED, and has a network connection.

54:26
Don: Good, okay, great. I'm just gonna go through these fast with the time we have left, so thank you for the succinct but complete answers. Is there a role for MQTT in cloud-based storage? Arlen, why don't you comment on that.

54:40
Arlen: Oh, absolutely, I mean, that's the beauty of the system. Think of your MQTT servers running in the cloud, and then you have a small agent, and I'll speak to this because I know it. You have a small MQTT client that subscribes to a subset or a super set of your data flowing through MQTT, you grab it and you push it into DynamoDB or any no-SQL database or SQL database that you have. So, yes, that is opening the window to analytics and big data. But I'll go back to my point, if you can't provide the operational solution first, you never get the opportunity to do that in the first place.

55:20
Don: That's great, thank you, Arlen. So, here's one, I just wanna say it's a good question, from Nathan here. When can we expect an IIoT section on the Inductive University? For those who don't know, we have Inductive University, there's over 600 videos. We share the knowledge, it's 100% free. Available anywhere in the world, 24 by 7. When can we expect that Travis?

55:41
Travis: Well so, we are working with Cirrus Link and we will hope to have a good section for IIoT available. I don't know exactly when but we're shooting for as fast as we possibly can.

55:53
Don: So, we will keep you abreast of that. You know how committed we are to the university and to knowledge sharing. So, sorry we can't give you an exact date right now. Next question, when you say a legacy device, you mean a device that doesn't have MQTT protocol built in, correct?

56:09
Travis: Yes, so legacy devices that obviously don't speak MQTT, they have their own proprietary protocols and that's the poll response protocols that we need some Edge Gateway to talk to that, to then translate that to MQTT so we can work with it.

56:25
Don: Good question here. Do you see a vendor like Rockwell providing MQTT support for their device or are they still sort of stuck with their own fieldbus protocols? So, I'm throwing that your direction, Arlen, give your thoughts.

56:42
Arlen: I believe they will. There's a lot of interest. You've seen Schneider has a MQTT blog out there. I think a lot of the vendors are looking at it. And also, if you go to the OASIS website for MQTT protocol, you'll see all of the companies that were part of the OASIS standardization effort, and most of those I've seen are coming out with MQTT-based products.

57:13
Don: Great, thanks Arlen. So, do you see... Next question, do you see MQTT as a competitive slash replacement for OPC UA? Travis, we've worked a lot with OPC UA, why don't you just give your thoughts on this one?

57:29
Travis: I see MQTT as a infrastructure change, so not necessarily a competitor, it's a completely different type of thing. And OPC UA will still be very important when looking at legacy devices and getting that to be bridged to infrastructure to something like MQTT. So, in a sense it's a competitor but you will need both of them in a lot of implementations.

57:49
Don: Sure. So, I would say overall, maybe we'll take one or two more questions but I'm gonna just ask... Maybe better now. Arlen, if you wanna make any final statements as we wrap up, we ran a few minutes over, but a lot of people stayed with us 'cause I think they really wanted to get to the questions. We will follow up and finish all your questions, but any wrap-up from you, Arlen, and then I'll ask Travis the same question. If you don't, that's fine, but Arlen?

58:17
Arlen: No, really appreciate the opportunity. As everyone can tell, I'm pretty passionate about making MQTT do what it was originally intended to do 18 years ago. And again, everybody, my email address is on there, anybody has any questions, please feel free to get a hold of me.

58:39
Don: Thanks Arlen. Travis, wrap up from you?

58:42
Travis: So, again, my name is Travis Cox, and my email address here is Travis@InductiveAutomation.com, you can... Any of the account executives, you can reach me through them. I'm here, if you guys want any demonstrations on any part of this with the Ignition and the MQTT modules, please reach out. Any questions whatsoever on the product or just the architecture in general, please let us know. And as well as Arlen, I'm sure would be happy to help. So, our lines are open and please come visit ICC 2016, I'm telling you it's gonna be the most exciting conference with what's actually... With everything that's transpiring with IIoT.

59:21
Don: I hope the passion that we have here is coming across. We look forward to seeing you at ICC but more than that, even just as a wrap-up, we really are committed to knowledge sharing. Take us to task on that, follow-up as you need to. As you start playing with the New Start Learning, and we'll do everything we possibly can from both Cirrus Link and Inductive Automation to try and assist in any migration, any projects, anything you need for your own benefit. With that, I appreciate your time today, have a great rest of your day and we are concluded.