Practical IIoT Solutions for Manufacturing

About this Webinar

Many manufacturers want to bring the benefits of the Industrial Internet of Things into their enterprise, but practical challenges and concerns around cost, maintenance, security, IT infrastructure, and data connectivity often stop IIoT projects in their tracks. Fortunately, there are proven ways to build cost-effective enterprise IIoT applications – the key is to build on an industrial application platform that integrates easily with other solutions. 

In this webinar, Travis Cox from Inductive Automation, Arlen Nipper from Cirrus Link Solutions, and Tom Hechtman from Sepasoft present a variety of IIoT architectures utilizing the Ignition platform and the MQTT protocol that can supercharge your applications, get your enterprise more connected, and help you do more with your data.

Learn About Affordable Ways to:

• Integrate MQTT with MES/OEE
• Use MQTT modules and devices with Ignition Edge to collect data from remote sites into a central control system
• Obtain and leverage higher-level analytics such as AI, machine learning, and business intelligence
• Bring self-learning technology into your manufacturing plant
• And more!

Webinar Transcript

0:00-7:40
(The presenter, Travis Cox, briefly introduces Inductive Automation, Ignition software, Sepasoft, and Cirrus Link Solutions, and the panelists, Arlen Nipper and Tom Hechtman.)

Where and How to Implement IIoT
7:41
Travis: All right. Well, thank you Arlen and thank you Tom for being a part of the webinar here today. I'm glad we have such knowledgeable and experienced presenters here to talk about IIoT, because it really is an important subject. By now, most everyone has heard about the Industrial Internet of Things and they know that it promises the ability to get far more data at far greater speeds, and in far more efficient ways than what we can do today. But, there are still a lot of manufacturers who don't understand exactly how they should implement IIoT, or specifically where. The three of us have a lot of experience and hopefully we can shed some light on those questions here today with these real case studies.

8:24
Travis: Now, it's one thing to talk about the benefits of IIoT but when you get into the details of making it happen, you run into a number of practical challenges and concerns. These obstacles often slow down IIoT projects, especially at the beginning because you're looking at the entire project, and they can be stopped altogether. Some of these common obstacles are extremely high costs, especially when trying to convert a legacy or older infrastructure into a new infrastructure, maintenance challenges, security issues, a lack of IT infrastructure, legacy devices that are still in use, we call “brownfield,” no effective way to move data to a central location, separate control networks, and there are many other obstacles.

9:09
Travis: So, Arlen and Tom, I know you guys have a lot of experience with working with customers on these obstacles and how we can overcome them. Are there any other obstacles you would add to the list or any comments on what we have here? Tom?

9:23
Tom: Yeah, I think the brownfield devices, and actually we see a lot of recording values on paper or spreadsheets, that type of thing. They just don't have the connectivity to the devices in the field and the controls network is incomplete. Having a cost-effective way to address that is a major concern to people. Another concern I think, is security in this day and age. Exposing that information out in a secure manner is another major concern.

10:00
Travis: And Arlen?

10:03
Arlen: Well, Travis, I think the primary when you hit the nail on the head is the scope of the project. I like to say, you can't eat the elephant in one sitting, but you can eat it in small bites. I think with the technology that we've got with Ignition Edge, with MQTT technologies, it lets us put together migration strategies with customers and we try to engage by saying, ‘Let's just solve one problem. Ignition's cost-effective, it's not going to cost the ... It's going to be very cost-effective, let's just fix that problem.’ But, being able to put together a strategy that says, ‘this is going to scale from this one solution across the enterprise,’ and show how we can do that in a cost-effective way. I think one of the use cases that I'm going to go through is going to show that very prevalently.

10:58
Travis: All right. Despite all of these obstacles, our goal here today is to show you that there are proven ways to build cost-effective enterprise IIoT applications. Today, we're going to look at three different architectures which are all based on actual use cases from actual customers. We're going to show you what these systems were like previously, what the problem was that we're trying to solve, and of course, what they look like today. By moving to new architectures, these companies got more power out of their applications, got their enterprises more connected, and were able to do a lot more with that data. And what all these solutions have in common is that they utilized the Ignition platform, and the MQTT protocol. In particular, the Sparkplug specification, that is the conduit, the glue that puts it all together.

MQTT and Other Common Elements
11:45
Travis: For those of you who may not be that familiar with MQTT, I want to talk just quickly about the benefits. MQTT is the protocol that we use to build IoT solutions in Ignition. So, why do we use MQTT? Why has it become the de facto standard messaging protocol for IoT? It's really all because of the protocol itself and the benefits of that protocol. Now Arlen, I'd say here that you are definitely the most qualified person to talk about the benefits of MQTT as you are the co-inventor of that. So can you give us a little overview of MQTT and the benefits here?

12:19
Arlen: Sure Travis, thanks. As I mentioned previously, MQTT was developed for mission-critical real time pipeline control systems, and we had a lot of requirements that we had to meet. We knew that we wanted to eliminate polling, and we were using basically aggregate of about 200 to 300 baud at each booster station that Phillips 66 had. So, the first thing is that MQTT had to be super-efficient. So, first thing is a very low bandwidth.

12:55
Arlen: The second thing we knew is that if we're going to control a pipeline system, we need to have state-awareness. No control engineer is going to let me put in an unstateful protocol that he might send the valve command, it might go open or might not go open. You can imagine ... So, Phillips 66 have been using MQTT on their 14,000 miles of pipeline and so for 20 years now they've known the state of 5,000 Allen-Bradley PLCs, 1,200 flow computers, 500 truck terminal systems and tank farm inventory systems, and they've known the state of those devices in real time.

13:36
Arlen: Then, one of the things that we were talking about that Tom mentioned is security. Actually, again, I'll note that in 1998, there wasn't near the concern of cyber security or people hacking into systems. But, I think the huge advantage is that we built MQTT on top of TCP/IP, and we did not implement any security scheme in the actual messaging transport. Had we done that in 1998, you probably wouldn't even have heard of MQTT today. But because it's built on top of TCP/IP, we get to leverage the latest security that your IT organization wants to apply to your TCP/IP network.

14:20
Arlen: Then lastly, what's really become a very compelling with the Sparkplug specification in conjunction with MQTT is the fact that now we can start talking about the edge of network devices, the actual native devices being a single source of truth for all of our tags. That's very important and again, we'll go through that in the use case that I've got.

14:47
Travis: All right, so MQTT here really is an important part of these solutions that we're going to talk about. By leveraging the MQTT protocol on the Ignition platform, we can be a complete citizen of being able to publish data from PLCs, to be able to be the broker, the middleware piece, and the consumer of that data. So, we have the ability to be all parts of that.

15:11
Travis: Now, I'll also note that there are a big ecosystem of partners that are supporting MQTT natively on their devices from IO that's out there to edge gateways that are doing conversions and more. MQTT has been widely adopted and is the de facto standard. And by leveraging that on these different kinds of devices, whether again, it's specific hardware or with the Ignition platform, we can push the polling of these legacy devices out to the edge of the network rather than trying to pull over the WAN or over the cloud. We push it close to the devices possible, and then we can make that data instantly accessible to the entire enterprise without training bandwidth because we're publishing the data by exception and we're pushing that data up. As Arlen said, the single source of truth is very, very important.

16:06
Travis: Let's talk a little bit about why we should decouple applications from devices. When you've got PLCs and intelligent devices coupled to applications through proprietary protocols, it's a complicated setup because there are applications that all the applications are able to interact with any connected device. And when you have multiple applications that need the data, you either need to connect to the PLC directly, or we start turning SCADA into middleware, which isn't necessarily the right approach.

16:35
Travis: That leads to a lot of problems with resources, networks, security, redundancy is poor, it's hard to maintain, most of your data gets stuck out in the field. It's just not an optimal architecture solution. But if you have an open MQTT-enabled architecture, your applications are decoupled from endpoint devices connecting through a broker in the middle. It's a cleaner, simpler setup. The data is bi-directional and stateful, so you're able to trust the data that you're getting from those edge devices.

17:06
Travis: This type of architecture is more secure, it has better network utilization and it has a lot of other benefits, as Arlen mentioned earlier. Imagine a scenario where all of your PLCs and devices were simply just publishing the data to a broker, and many applications could consume that without having to know who that end device was, what their IP address, or what those tags were there. It's auto-discovered, they automatically pop into the applications.

17:34
Travis: Another thing that these three solutions we're going to talk about have in common is that they make it possible to affordably leverage data from multiple sites. If, for example, you have 10 remote sites and you wanted to get OEE downtime for those sites, it would be very expensive to install a full OEE solution for each one of them. But, if you had a way to bring data from your other sites up to a central system, that would be much more practical. We're going to show you architectures that allow you to do this in a cost-effective way. That's really the key here, is to be able to start as Arlen said, taking bites out of the elephant and getting ROI as you go along, and being able to slowly migrate over to a complete IoT infrastructure.

18:17
Travis: Another common element you'll see in both these use cases is edge gateways. Edge gateways are devices that help you bridge your legacy or brownfield devices to MQTT and they're very important in these different brownfield scenarios. There are a lot of legacy devices out there with proprietary protocols. We need to push the polling out to the edge of the network and get that data transfer to MQTT and published up by exception, so they could take advantage of that information. By adding even a few edge gateways or even just one, you could add a lot of value to your existing architecture. And, you can add edge gateways at other sites to enable complete solutions for OEE and other applications. The solutions we'll show you here all use Ignition Edge, but there are other edge gateways as I mentioned out there.

19:03
Travis: Another great advantage of the Ignition platform is that the MES modules and MQTT modules are tightly integrated. Both Sepasoft and Cirrus Link have modified their modules so that they work together to help capture and share more data. Tom, I know you've recently worked with Arlen and Cirrus Link on this and using the Ignition platform, your modules are able to integrate very nicely together. Can you explain a little more about what you guys did?

19:30
Tom: Yeah. With OEE and in other MES tasks in general, it's vital to collect accurate data without any gaps. By gaps, what I mean is if there's an interruption in communication and then that communication comes back up, do you have missing data for the time that communications was down or does that get filled in? If you don't have that accurate data, you're kind of running your production in blind mode. Basically, garbage-in will produce garbage-out and your return on investment of installing OEE or MES won't be recognized.

20:13
Tom: The same with Ignition platform and being able to use that and the Cirrus Link is, now we can solve that problem. We worked with Cirrus Link to do that. Cirrus Link has a historical store-and-forward mode that if there is an interruption in communication anywhere along the way, that gets stored and then when the connection comes back up, all that historical data is passed to us and then we fill in the gaps and we have the accurate data. Thanks, Travis.

20:52
Travis: All right, thank you, Tom. I know we'll get to see an example of that here soon when you look at your use case there for a manufacturing customer. So, let's get into the real crux of today's webinar and that is the three IIoT use cases that we want to cover. First, we're going to have Arlen talk about companies that are trying to get into and participate in Industry 4.0. How do we get started? What's the current landscape look like? And, what are the ways that we can get quick wins? Then, I'm going to talk about OEMs that are providing services to remotely troubleshoot their machines as a service to their customers. And then, Tom is going to talk about a corporate MES application that again, leverages that MQTT protocol. First and foremost, over to you, Arlen, to talk about companies who are wanting to get into Industry 4.0.

Use Case 1: Companies Getting into Industry 4.0
21:44
Arlen: Okay, thank you, Travis. For this customer use case, we've been working with this customer for approximately three years now. We worked with the executive that was basically in charge of taking this company into Industry 4.0. It was a very large manufacturing company with plants around the world. The problem was, they had a very tightly coupled architecture and they figured that 80% to 90% of the machine data that they really needed for things like machine learning and analytics was being stranded out in the field. So, we worked with them, we put together a migration strategy.
 

22:29
What we had to start with was very typical in that it was a manufacturing plant and they had all of these specialty machines, whether the machine was intelligent itself or whether it had a PLC connected to it, it was connected to a very rigid polling engine. Again, the problem with protocols in and of themselves are is that when you have a poll response protocol, there is an application that has to send the poll, it has to parse the response and once it's parsed that response, it kind of owns that data so it's kind of hard to share.

23:04
Arlen: Well, then that went to an operational SCADA system and that was tightly coupled to an MES system. But as you can see in this topology, it's very, very difficult to break those pieces apart. So with this tightly coupled architecture, register-based tags had no context. Let me explain that a little bit more, is that very simply, if one of those machines had a Modbus PLC on it, that's great. Protocol A is Modbus, we bring a Modbus register in, it comes into operations, and now what do we have on our screen? We've got Modbus register 40,012 and it's a value of 36.

23:42
Arlen: Well, 36. What is that? Is that 36 feet? Is that 36 degrees °C? Is that 36 gallons? So, what do we do on every SCADA system that from a legacy standpoint, we have to double-click on that tag when we edit it, and we give it context. We say, ‘Oh, well, that's a raw value, 04095 and we need to scale of zero to 100 somethings, and those somethings are going to be in degrees C. And here's the upper alarm limit, the lower alarm limit and the engineering range.’ That's all context that we add to that tag manually.

24:21
Arlen: Now that operational SCADA system knows about that tag until it may change in the field. Then we've got to go over to the MES system and do the same thing. Now, the goal and the vision here was to be able to start leveraging things like machine learning on premise, was to leverage cloud services and to leverage the investment that their analytics team already had in things like Kafka feeding their Hadoop and Spark visualizations. Over the last three years, what that's migrated to is this type of an architecture.
 

24:56
Arlen: In the solution, what we've got is those machines are still there. Those machines are very expensive, and no way are they going to go out and replace all those machines. But, what's happened is that we've put our edge devices like Ignition Edge, and the company also developed some edge-of-network devices for very proprietary machines and they implemented MQTT Sparkplug as well using the Tahu specification. Notice now that the machines are publishing information into an MQTT infrastructure.

25:33
Arlen: Now we're starting to see the advantages of decoupling in that Ignition is still a primary SCADA system, but now anybody else can come in and subscribe to the same tags that are being published in real time. So, Kafka being an MQTT creature in and of itself can subscribe to any or all of the tags that might be published off these machines. Now with some of the Cloud Injector Modules that Cirrus Link have developed to run on Ignition, we can take tags that are arriving in real time and publish them to either Azure IoT Hub and or into Kinesis.

26:14
Arlen: Now, in this particular use case, the customer streamed high fidelity data into Amazon's SageMaker product. If you're not familiar with SageMaker, it's a very, very sophisticated tool. As you can imagine, Amazon's been doing this for a long time. What it creates is a Lambda that is the machine learning model of what SageMaker has learned, and then you can deploy that Lambda on Amazon Cloud. But, you still have to have the bandwidth and the cost of using that.

26:45
Arlen: So, a new technology that Amazon has come out with Greengrass Core, very analogous to the Azure Edge from Microsoft, Greengrass Core can run that Lambdas that's been developed on premise. Now we've got kind of a closed loop cycle in high fidelity machine learning creating a Lambda with that being downloaded back into Amazon Greengrass. Then of course, we've got the Sepasoft modules that are already integrated in as well for MES, OEE, and Track & Trace. From an Industry 4.0 standpoint, the customer is not looking for new technology just because it's new technology, but the ability to reduce waste and efficiencies by an order of magnitude.

27:37
Arlen: Now, also remote factories now with just dropping in Ignition Edge, and so I want to go back to that point that Travis was making, is that for a few thousand dollars, a best in class embedded edge-of-network device and Ignition Edge, now a remote factory that might just have a few machines can start publishing information securely into the same infrastructure and start taking advantage of the machine learning and all the sophistication that they've got in the solution that they've got deployed today.

28:14
Arlen: Now, the final thing there is that from that remote factory, the unique thing about MQTT, as Travis was saying, is a remote originated connection. That means that remote factory doesn't have to have any ports open to any of these machines that are publishing information. That also means that for connections to Azure IoT Hub and to Amazon Kinesis, those are outbound connections as well. So from a security model standpoint, from a performance standpoint with high availability and redundancy, this has become a very, very good solution for a slow migration from legacy poll-response to much more modern event-based architecture, one machine at a time. With that, Travis, I'll hand it back over to you.

Use Case 2: OEMs Providing Services to Remotely Troubleshoot Machines
29:04
Travis: All right, thank you. Let's take a look at our second use case here, and that is OEMs that are providing services to remotely troubleshoot machines. I'm going to be covering this one here. To first introduce the problem, in that we had an OEM who manufactures the machine, of course that they sell to customers. The machining has a PLC onboard. It's all ready to go, and of course the customer integrate that in their plant floor.

29:35
Travis: Now oftentimes, what would happen is that the customer is responsible at that point going forward for troubleshooting and for integrating that machine into all their systems, their SCADA systems and whatnot. A lot of times, the customers lack deep expertise to really troubleshoot machines well, to understand when particular things go wrong and how to address those.

29:57
Travis: Now, the OEM, of course, knows how to do that. They're experts on their machines, but have had a huge challenge in being able to do that remotely. Often they would have to send technicians out on sites and once they send a technician out on site, that means we lost production and we lost money in that. Or, the customer would send export data that they collect in their SCADA system to a CSV sent to the OEM. Where the OEM is going to try at that point to sift through that data, understand what had actually happened.

30:32
Travis: It has historically been a very challenging thing for OEMs to really provide a good service to their customers and augmenting, being a part of really diagnosing and troubleshooting and finding issues before they actually happen.
 

30:50
We've seen many OEMs who tried to do this in the old way. The old way would be from their cloud infrastructure or corporate infrastructure, they would create VPN connections to all the separate customers and that required that at the customer site, they had a VPN router that was installed, or had to work with IT to get that set up. And of course, that would be different from Customer A to Customer B.

31:17
Travis: With that, then they would have a system that would connect to the PLC at the customer location on their machine by knowing its IP address, and then defining all the tags and polling those tags, especially polling it over the WAN which has a lot of issues, especially when there's high latency. There's a lot of bandwidth considerations. It's slow, all this is slow. It's hard to maintain, it's not scalable. It's tough for the OEM to do this for all of their customers because it requires a huge infrastructure for them and a lot of these kinds of connections, so this typically wasn't done. They may have done it here and there, but it's not a service that they would typically just straight-up offer. It was a case-by-case basis.
 

32:03
Travis: By finding MQTT and leveraging MQTT, this OEM was able to actually achieve their dream of being able to remotely troubleshoot and remotely diagnose these machines. What they would do is with the machine that has a PLC there, they would also put an embedded PC with Ignition Edge to pull that PLC locally. Then it would already be pre-configured to connect up to their MQTT server in the cloud. So, that edge would be connecting up. There's no connections down to the customer whatsoever. The customer's data is being pushed up securely to the cloud here.

32:43
Travis: Those Ignition Edges are pulling all those tags from the devices, pushing up to their MQTT server in the cloud in real time. They're getting the real time granular data, that they are then of course, using Ignition as a system to receive that data, historize it and be able to go through that information and provide a real service to their customers.

33:07
Travis: Here, the real difference is that they don't have to have any connections to their customers whatsoever because the data is being published up by exception, and the single source of truth of the tags are at the customer location on that edge gateway. So, they don't have to even know. Those tags are just automatically discovered and published up and they can start taking advantage of that information.

33:34
Travis: They've been able to drastically increase performance and to be able to help customers be a part of that process to know what's going on with their machines in real time and this is something that we see in the consumer space a lot. We buy a refrigerator now and the refrigerator is connected up to that company's cloud infrastructure and we get push notifications when it's getting too hot, or we get push notifications when we run out of a particular food inside the refrigerator.

34:06
Travis: This concept is very widely known and done in IoT. Your car is connected, everything's connected. The idea here is that now these machines that you're buying can be connected, and you can leverage the expertise and skills of the OEMs to help make everything in your plant more effective.

Use Case 3: Corporate MES
34:27
Travis: Let's now take a look at the last use case here, the third use case which is going to be provided by Tom, looking at a corporate MES solution. Tom?

34:38
Tom: Thanks, Travis. This was a large company and they're running OEE across many locations and really putting in a server at each site just wasn't that practical for OEE. It wasn't that practical because, do you put in redundant servers in case the server on the site goes down, do you have a fail over? What about the databases and the backup of the databases and how to handle a disaster recovery? Basically, the cost to implement goes way up. It's just not really the paradigm moving forward. There are situations where you need to have servers out on the plant floor for critical MES applications. But for something like OEE where it's more passive and not critical, it's just not as practical.

35:34
Tom: We needed to have a centrally located server and also, the connection to the controller. Now if you put a centrally located server on and you're connecting to your field devices, now all of the stuff that Arlen and Travis have been talking about where you've got polling going on and the bandwidth and all that kind of thing is a problem. And if you lose that connection to one of those devices, now you've got the gap in your data that I talked about previously. We needed to have a solution here that addressed these issues of putting the server in a central location.
 

36:21
Tom: This is the old way. They had GE devices out there. They're talking to their machines. And as Arlen said, it doesn't make sense to spend a lot of money replacing your devices out there on the machines. You have to reintegrate it, reprogram, and all those things that it's just not practical. It would require polling to those devices to the central location and like I mentioned, if you have gaps in communication, then if this is a timeline here, you're going to have gaps in your timeline and not get accurate data.

36:57
Tom: Remote factory again, you're going to be polling each device in that remote factory or maybe you put a concentrator in there. I've actually seen some companies try to solve the gap problem and the remote factory problem. but it's an incredible amount of hours to develop. It usually involves purchasing a data broker PLC that handles all the data communications, having strict standards that they need to follow. Every time they add a machine, it's pretty involved so the maintenance of it long-term is expensive, plus the initial investment was expensive versus a more plug-and-play, out-of-the-box solution.
 

37:45
Tom: Looking at what the solution is, Arlen was talking about Sparkplug there. So, putting in a device here that you have Sparkplug on each of these devices. The remote factory is running an edge of network device like Travis talked about there. These all report by exception when the value changes. They get pushed up to the MQTT servers and that then gets communicated to Ignition and the OEE Module in this case. Now our gaps are filled in, we're getting all of our data.

38:21
Tom: So, if we have a failure from machine one anywhere along this link to Ignition, it will store it and then when the connection comes back up, it will pass that through. There's actually kind of like a contract, this machine with Ignition, that separate contact from this machine to Ignition. It verifies that the value got through and if it didn't get through, it's going to store it and pass it to us later on. That totally solves our issue or the problem we were trying to solve of having the gaps in the data.

39:01
Tom: Now I'm going to show a quick demo, a real simple demo. It will just demonstrate this concept so you get a little better idea of what we're talking about. On my local machine here, I'm moving it around, I have a ... This is going to represent the field device or the PLC and an Edge Gateway that's doing the polling with the PLC and then when there's a value change, it will push it up to the MQTT server. Than that will then be read over on Ignition here where MQTT engine's running, and then we have it into our OEE Module.

39:45
Tom: The best way to show this I think is ... And you can see the IP address. This one over here is actually up in the Amazon Cloud. We're running the OEE and the Amazon Cloud, and then this one's just on my local, on the left side is on my local system. The best way to show this I think is just showing a timing chart, it will show downtime events and a downtime table. Starting up here, and I'll put in the downtime reason, code 100. I think that's an infeed jam or something like that. We see that show up in our downtime table here, and it shows up into our timing chart. We see code 100 there in feed 1 jam, and I'll reset that.

40:37
Tom: That's all fine and good, but now I want to simulate an outage. I can't unplug my network cable because you won't see my screen anymore so instead, what I'm going to do is turn off the MQTT server in the Amazon Cloud here, so it's not going to accept any more values. This field device and this Edge Gateway, when it’s value changes, it's going to want a response from that server. Well, I shut it down so it's not going to get the response and it's going to store it.

41:12
Tom: We can immediately see that we're offline. Even though it's report by exception, we know it's offline right away. Now I'm going to put a different code in there, a couple different codes here. We can see it's not updating now, because we're offline. Normally, this would be a gap in our data, a couple there. You can see that that charts even updated, and the last data it had was, it was running so that's what it shows. Now I'm going to re-enable it, the server. Go back here.

41:57
Tom: I went back online and then we'll give it a minute, and there's our data. The two different codes, the 120 I typed in and the 130, it shows up in our downtime table. That's a real simplified example. We're just doing machine state and some counts here, but you really can have what product code you're running, am I in production? Complete control down here and up in the Amazon Cloud, or wherever your central server is can just be passive and collecting that data and being able to show it was zero gaps and getting accurate data. With that, back to you, Travis.

Recap & Closing Discussion
42:39
Travis: All right. Well, thank you, Tom. Let's quickly recap the main takeaways from the three solutions that we've presented here today. First, you can decouple intelligent devices from applications with Ignition, in particular with MQTT. With that protocol and the Ignition Edge or, again, if devices support MQTT natively, that allows that to decouple and to have that information being sent up securely, published by exception to leverage all the benefits there.

43:13
Travis: We can bridge these old and new technologies by using Edge Gateways and it could be very cost-effective to simply put one of these in place. As we've kind of said a couple of times you could put an embedded PC or VM that runs Ignition Edge with unlimited tags talking to all the controllers, publishing information up, and now you can start taking advantage of it. For MES or for analytics, getting the information to the cloud, whatever it might be, you could start getting some wins off that data with not a whole lot of investment.

43:46
Travis: MQTT Ignition architectures allow you to leverage that data and read those resources efficiently across multiple locations, multiple sites. The tight integration you saw with MES and MQTT modules eliminate the problem of data gaps and make the solutions simple and out of the box, and it's really important. MQTT being plug-and-play, it's all self-learning. That technology makes expanding your system easy and saves vast amounts of time. You don't have to know what those devices are, what tags exist, they automatically show up and if there's UDT definitions or structures, they show up automatically as well.

44:20
Travis: Imagine that MES solution that Tom just showed, where you did that proof of concept for one location and then after you're done, you got to roll it out to 90 other locations. How hard is that rollout going to be? With MQTT and the plug-and-play nature of all this, with just putting the Edge Gateway at the site, you could roll it out extremely fast. These solutions offer a practical migration strategy for your existing resources. By putting the Edge Gateway in to leverage that data, you're in the first step of transforming to that new architecture. And, they allow you to leverage these analytics and machine learning systems that Azure and AWS have. That helps us with turning our data into better information, increasing performance and better decision-making.

45:12
Travis: To summarize here, to wrap up the presentation, I want to ask Arlen and Tom if they have any closing comments about building these practical IoT solutions. Tom, we'll start with you.

45:23
Tom: Yeah, you can kind of think of it as ... Travis, you’re mentioning multiple things besides MES that are communicating with these devices. It's almost like competing for connections to the device itself and some of these devices are smaller, they can't handle all of those connections. So, you either have to upgrade that device to handle more connections or you use an alternative solution and MQTT does that very nicely. Then also, just implementing MES for an enterprise across multiple sites can be challenging and costly, but MQTT really helps simplify that implementation and keep the cost down.

46:05
Travis: Thank you, Arlen?

46:07
Arlen: Yeah, Travis. Well, I think what we saw here as the common denominator around all of this, and it’s really, that's one of the concepts of MQTT that are kind of hard to wrap your head around, especially if you've been doing SCADA for a long time. We've got this mindset that, oh, it's a PLC, therefore we must poll, therefore we have a poll-response protocol. Whereas what we're showing here is that if you can think of the decoupling advantages of MQTT where you're publishing information that anybody in the enterprise might be interested in, to Tom's point. MES is interested in some of it, operations are interested in it.

46:48
Arlen: We do a lot in oil and gas where a flow computer is a very schizophrenic device where operations wants all the real time data, but billing wants all of the ticket data. This can be replicated across many different industries as far as what the advantages of being able to use Ignition as a platform, a tool if you will, it's your Swiss Army knife for all this cool MQTT technology, and then being able to leverage the cloud solutions, if you will. I mean, if you think about Google Cloud Platform as your IoT hub, AWS IoT, IBM Watson, SAP Leonardo, the common denominator across all of those cloud services is that they leverage MQTT technologies. With that, back to you, Travis.

46:49-1:00:52
(The speakers answer listeners’ questions for the remainder of the webinar; to listen to the Q&A, please refer to the webinar video at the top of the page.)