Ignition Edge: Simplifying the Edge of the Network
How to Extend Your Network Without Extending Your Budget61 min video / 47 minute read View slides
About this Webinar
Inductive Automation introduces Ignition Edge, a new line of lightweight, limited, low-cost Ignition products designed specifically for embedding into field and OEM devices at the edge of the network. With Ignition Edge, it’s easier and more affordable than ever to extend Ignition all the way to the edge of your network.
In this webinar, you’ll learn how to use the three new Ignition Edge Products — Edge Panel, Edge Enterprise, and Edge MQTT — to create local HMIs with client fallback, synchronize data to a central enterprise server, publish field-device data through MQTT, and much more.
- How to use Edge to access data from PLCs and OPC-UA servers
- The flexibility Edge gives you to build scalable enterprise architectures
- How you can use Ignition and Edge MQTT together to build a complete end-to-end IIoT infrastructure
- How to prevent the loss of field data with local client fallback and store-and-forward functionality
Don: Welcome to our webinar, Ignition Edge: Simplifying the Edge of the Network. How to extend your network without extending your budget. My name is Don Pearson, I'll be moderating today's webinar. And we also have some experts here who will help build the new Ignition release, and I'll introduce them in just a minute. As far as today's agenda goes, we'll introduce you to Inductive Automation, for those of you who aren't familiar with us, and to the Ignition software platform. Then I'll introduce our three panelists, who will discuss the three new Ignition Edge products that we'll be releasing, and we'll do a short software demo. We'll also talk about seven ways that Ignition IIoT helps to realize IIoT benefits. Q&A will be held at the end of the webinar.
Don: As usual, a little bit of brief company background on Inductive Automation. It was founded in 2003. We really are very pleased that enterprises now, in well over 100 countries, have chosen Ignition for their HMI, SCADA, MES, and their IIoT needs and solutions. We have over 1400 integrators that have joined our integrator program. Ignition is being used and trusted by thousands of companies, including 44% of Fortune 100, and I think over a quarter of the Fortune 500 companies now are utilizing Ignition in one form or another in their organizations. If you want any more information on Inductive Automation, please just go to the About section on our website, and there's bios of staff and history and a whole bunch of stuff you can find out about Inductive Automation.
Don: Ignition, as I mentioned, is used in lots of companies and really leading companies, organizations in pretty much any industry that you can imagine, from oil and gas, water, wastewater, food and beverage, government, transportation, packaging. And really, the list goes on because it's a platform that can really be utilized just about in any way you want to utilize it. And part of the reason is 'cause the signature product, which is Ignition by Inductive Automation, is really the world's first truly universal industrial application platform for HMI, SCADA, MES and IIoT.
Don: For a variety of reasons, just some bullet points here. The unlimited licensing model, cross-platform compatibility, IT-standard technologies, scalable server-client architecture, it's IT... It's web-based, and it's web-managed, web-launched design on clients, modular configurability, and of course, rapid development and deployment. So, it has a lot of strengths to really make it appropriate for the variety of solutions it's being used for now.
Don: I'm joined by Colby Clegg, Arlen Nipper, and Travis Cox. Colby Clegg is one of the original designers of the Ignition software, and he continues to propel its advancement as the co-director of Software Engineering here at Inductive Automation. Arlen Nipper is president of Cirrus Link Solutions, a strategic third-party module partner of Inductive Automation. He has nearly 40 years of SCADA experience, and is the co-inventor of the MQTT message transport in conjunction with IBM. Travis Cox is the co-director of Sales Engineering at Inductive Automation. He's been with the company from the very early days. He's made great contributions, and a big impact in our training and support and sales departments. I'd like to welcome all of you, and thanks for contributing your expertise today to our discussion.
Don: Feedback from our user community has always been a pretty important part of the development of Ignition as a universal industrial application platform over the years. And recently, we've seen a growing need for edge computing solutions. In case you don't know or don't have a clear view, edge computing is when you build an architecture that has servers or other computing devices installed onto our next to plant floor field devices, so that you can process client data as close to the source as possible. Specifically, more and more of our users told us it would be very useful to extend limited Ignition functionality out to the edges of their networks.
Don: We've been working on an Ignition solution for the edge of the network and had several big goals we wanted to achieve with this initiative. First, it should be a solution that you deploy at the edge of the network where the data is coming from. It should enable polling that is as close to the device as possible, rather than polling from SCADA. It should give you the option to migrate legacy infrastructure to the MQTT protocol, so you can implement an industrial IIoT architecture. It should enable you to have an end-to-end solution for IIoT for those organizations that wanna pursue that technology. It should allow you to have local visibility to local HMIs. And it should allow you to embed Ignition onto hardware.
Don: That's why today we're coming out with our new line of lightweight, limited, low-cost Ignition products, Ignition Edge. There are three Ignition Edge products: Ignition Edge Panel, Ignition Edge Enterprise, and Ignition Edge MQTT by Cirrus Link Solutions. They're engineered and priced for using at the edge of the network, working in concert with centralized full Ignition gateways. Each Ignition Edge product has a different function, but they all have these features and benefits in common. All come with up to 500 tags, all are equipped with OPC-UA, along with Modbus, Siemens and Allen-Bradley-suited drivers for easy PLC connections. Other drivers supported by Ignition, such as DNP3, can be added on to Ignition Edge products for an additional cost. They all work on any version of Windows and on OSX, Linux and more, so you can install them on virtually any industrial device.
Don: With support for ARM processors, Ignition Edge can also run in the latest generation of efficient edge-of-network devices. All are engineered to work seamlessly in concert with the centralized Ignition gateway, and they guarantee performance on constrained devices because they do not have database access or gateway scripting. As we said, Edge features a limited range of features which support the design goal of providing the best performance on constrained embedded devices.
Don: Using Ignition and Ignition Edge together, you can build scalable and affordable enterprise-wide systems, you can use Ignition Edge Panel, Enterprise or MQTT on a single device, or mix and match them to create powerful solutions that are tailored just to the needs that you have or your customers have. It also should be plug-and-play. And last but not least, the Edge products are priced for using in bulk. They make it possible to extend Ignition to the edge of the network and build enterprise-wide systems without overextending your budget. Because if the project really is gonna break the bank, it's never gonna see the light of day. It's gonna get stuck in some CFOs in-basket or penny basket somewhere, and the projects won't ever occur.
Don: So, that's a little bit of a background and a look at Ignition Edge and the products released for starters. But really what I wanna do now is turn it over to our co-director of software engineering, Colby Clegg, to talk about Edge Panel and Edge Enterprise.
Colby: Great, thanks, Don. Each of the Edge products is unique and they offer a lot of options for combining features to create a large range of solutions for edge-of-network applications that can stand on their own or tie in to your Ignition enterprise architecture. The first Ignition Edge product that I wanna discuss today is Edge Panel, a solution for creating local HMIs for field devices. In some regard, it's not too fancy, it's an HMI product. But part of the theme today is going to be about how we can build a fully connected enterprise on top of the Ignition ecosystem, and Edge Panel is an important tool for that in that ecosystem. HMIs are usually the first line of visualization at the edge of production, and Ignition has always been an interesting solution for panel-based HMIs. Now with the Ignition Edge, we have a dedicated solution that offers robust features at a very attractive price point.
Colby: More than just local visualization and control, Ignition Edge Panel offers one remotely launched web client, in addition to the local client that is, one week of built-in history storage for local trending with no external database required and even alarming with one-way email notification. Here is one of the most basic architectures we can build where you put a standalone HMI at the edge of the network. The interesting point is that we now have a dedicated solution for this, with the wide range of functionality I just mentioned, at a very price point. When you combine that with the fact that Ignition Edge supports all sorts of platform architectures, including Arm, and it can run with a very small footprint with embedded Java, you can create some very cost-effective panel solutions.
Colby: But things get even more exciting when you consider that Edge Panel is a great solution for local client fallback set-ups. If you're new Ignition or haven't come across this topic before, Ignition clients are web-launched, meaning that they're launched off of the Ignition Gateway, perhaps remotely, usually remotely, and they run locally. Local client fallback is a feature where the client will automatically re-target to a local Ignition if the connection to the central gateway is severed. The idea is that the central server will host a much more comprehensive project, perhaps with data analysis that spans multiple remote Ignition systems. But in the case of network failure, the local operators must be able to maintain visualization and control of the system. Ignition Edge Panel is a perfect solution for this. Under normal circumstances, operators can use the features of the full-blown central Ignition Gateway. On failure, you can fall back to the limited Edge Panel that provides critical real-time control, one week of recent history, and alarms.
Colby: The next Ignition Edge product is Edge Enterprise, which unlocks Ignition's powerful gateway network services in Edge. It connects the Edge Gateway to a central Ignition Gateway, which can then access remote tags, remote alarm status, tag history, and so on, for very distributed architectures. Furthermore, the built-in one-week historian can automatically synchronize history efficiently to the central gateway for unlimited storage and analysis on that gateway. Additional features, such as remote backup, restoration management and centralized monitoring of performance and health metrics, are also available if you have the Ignition Enterprise Administration Module installed on the central gateway, that is Ignition Edge Enterprise acts as a licensed EAM agent.
Colby: Here's a diagram of an architecture that uses Edge Enterprise as an agent gateway and a hub-and-spoke set up with store-and-forward to the central gateway. Edge Enterprise offers local data buffering at the edge-of-network, and if the network connection fails, Ignition Edge Enterprise will continue to collect historical information for up to one week. When the connection is restored, the Edge Gateway will synchronize the data back to the central Ignition server to maintain data integrity. Along the same lines, we're able to manage the Edge projects from a central location. If we wanna make a change to what's being shown, we can modify the project at the central server and then synchronize that down to all of our Edge products.
Colby: As we have said a few times now, you can mix and match Edge products. Here we have the Edge Enterprise combined with Panel to create a similar architecture to what we saw with the local client fallback, but with the ability to synchronize history to the central gateway, monitor tag values and alarms from that gateway, and manage the projects remotely with the Enterprise Administration Module. Next, we're gonna look at how we can extend and utilize Edge to deliver a very powerful IIoT solution. For that, I'm gonna hand it back to Don.
Don: Thanks, Colby. However, before we actually end up discussing our next product, which is Ignition Edge MQTT, we wanna talk just briefly about the state of IIoT. Certainly IIoT industry 4.0, the various discussions, hype-writing, consortiums, alliances and stuff related to that sort of evolution have got a lot of companies thinking about IIoT. But really when you get down to the bottom line of implementation, hardly anyone really knows where do you really start and how do you progress. And it's causing some disillusionment about IIoT, and frankly, this often happens when you have a new technology. It sort of replays an established pattern that's so well-depicted by what is called the Gartner Hype Cycle, of which many you on this call may be familiar.
Don: On the vertical axis here on the Gartner Hype Cycle, it represents expectations, and the horizontal axis represents time, and is divided into five phases. The first phase is the technology trigger, the inception of the technology and early adopters. The second phase is the peak of inflated expectations where activity goes beyond the early adopters where media hype begins, reaches a peak, and then negative press begins. The third phase is the trough of disillusionment, where reality sets in. You really have about less than 5% adoption at that point, second-generation products are starting to come out. The fourth phase is the slope of enlightenment, where methodologies and best practices develop, third-generation products evolve, out-of-the-box product suites occur. And the fifth phase is called the plateau of productivity, where 20-30% of the potential audience has adopted innovation and it's pretty well-established.
Don: When you take away all of the hype that surrounds IIoT, you're left with something very simple, and what we believe is what you're left with is a new architecture. And really the architecture is based on the practice of decoupling applications from edge-of-network devices, as you see here in this diagram. It uses the MQTT, which is a publish-subscribe protocol. It's very lightweight, bi-directional, and enables message-oriented middleware architectures. If you look a little bit by contrast at a conventional system architecture, intelligent devices are connected to applications using poll response protocols. Any application can interact with any device. This coupled architecture leads to problems with security, device resources, network resources, bandwidth consumption, documentation, maintainability. It has a whole slew of difficulties that ensue from this kind of an architecture, which has evolved over time. And actually one of the biggest problems is over 90% of device data is left in the field because poll-response protocols are only programmed for a fixed data set.
Don: Look for a second again at the new architecture, where applications are decoupled from devices. Device data is published by exception to an MQTT broker, which is cloud-based or on-premise. The applications subscribe to the MQTT broker. Data is bi-directional. MQTT provides stateful awareness, so you know the state of the network connection at all times. This architecture provides a lot of things. It provides better security, better network utilization, a whole host of other benefits when you architect your systems in this fashion.
Don: Let's look back at the Hype Cycle again. Today IIoT hype is at a maximum, as we're all aware, and the negative press has already kicked in. Things are on a slippery slope down toward the trough of disillusion. But Inductive Automation and its IIoT solution, which you're hearing about today, are already into the plateau of productivity and we're there now. But we're actually delivering an actual IIoT solution, one that's based on open standards, and is proven in the real world, and it's proven today. And I'll say this next point tongue-in-cheek, with a little bit of humor and also a little bit of truth to it, but when you get right down to it, all that we're trying to do with Inductive Automation and the Ignition platform is keep you from suffering from that Gartner-predicted inevitable slide into the trough of disillusionment. The idea is to build a bridge. Ignition is a bridge straight across that chasm, straight over to the productivity plateau, where you can unleash innovative ideas, they can become a reality, and you can move forward on your initiatives now in a cost-effective and technologically effective way.
Don: So, just moving back to the architecture just for a second again, the promise of IIoT can be realized right now through this decoupled architecture, and that's what Ignition IIoT is really all about. But rather than say anything more in terms of the theory, I think I'd rather turn it over to someone who can go into more detail and depth and really understands this, to tell you about the third Ignition Edge product, Edge MQTT. Here's the co-inventor of MQTT, Arlen Nipper. Arlen, go ahead.
Arlen: Thanks, Don. The Ignition Edge MQTT product builds on the three Cirrus Link MQTT modules for Ignition that we released last year. These three MQTT modules added IIoT functionality to Ignition's existing HMI SCADA industrial platform functionality by allowing Ignition Gateway to be set up in the new MQTT architecture that Don just talked about. Now, we're targeting the Ignition MQTT architecture a step further by extending it to the edge of the network.
Arlen: Ignition Edge MQTT was developed by Cirrus Link Solutions. Cirrus Link is a third-party strategic module partner with Inductive Automation. Ignition Edge MQTT enables publication of field device data through the highly efficient MQTT protocol. It turns touch panels, client terminals or virtually any embedded compute field device into a lightweight MQTT-enabled Edge Gateway that works seamlessly with Ignition IIoT. It uses MQTT to transmit the data to any MQTT broker, or brokers, such as Chariot MQTT broker or the Ignition built-in MQTT distributor module.
Arlen: To me, really the Ignition Edge MQTT is exciting because I've been implementing MQTT infrastructures for the last 15 years. And when I meet with customers and companies, they're desperate to get into IIoT, but they don't really know where to start. "Where do I start implementing basically a new architecture?" Edge MQTT gives you that starting point for defining a problem, identifying it, and then just go out and start doing it to get a true IIoT architecture.
Arlen: Edge MQTT also provides a common set of tools and technologies across your HMI SCADA platform to edge-of-network. As Don said, there are 1400 integrators who are experienced with Ignition today, and this product will increase integrators' capabilities for OT requirements and to provide IIoT-centric architectures, which are in heavy demand. It's interesting to note here that the very same MQTT modules that everyone is already familiar with in the Ignition Gateway are the same modules that are used in the MQTT Edge platform. Until now, there's been a disconnect between technologies using HMI SCADA platforms and disparate legacy industrial protocols. But with Edge MQTT, information from intelligent operational equipment can not only provide mission-critical, real-time information for OT SCADA solutions, but a wealth of information for the mini-IIoT requirements that were previously left stranded in the field. Edge lets us migrate to a point where the Edge devices become the root authority or the single source of truth for tag information. So, human tag editing can be a thing of the past. We can finally stop talking about how to adopt IIoT within operational systems and just start doing it.
Arlen: Now, how does this all work together? Edge MQTT supports the Sparkplug Data Encoding Specification that Cirrus Link has open-sourced and made available to any other company and to OEMs implementing MQTT. Due to a huge amount of feedback from integrators and end users of the product, we initially introduced Sparkplug A. And now, as of Ignition 7.9.1, we've released Sparkplug B. And Sparkplug B lets us support native UDTs, datasets, historical data, tag properties, metadata file types, and more granular device management.
Arlen: What do these topologies start looking like with Ignition Edge MQTT? Here's an architecture we call Remote MQTT. You can use the Edge MQTT on any device, a touch panel, a rack mount server, or a client terminal into an Edge gateway. Edge MQTT converts the data from these connected PLCs and RTUs into MQTT information, and publishes it to your centralized MQTT infrastructure in a way that can easily be received by the MQTT engine module in the Ignition Gateway. But if you'll note, in this topology, even though Ignition is a very important data consumer, it's not the only data consumer. And now we have access from line-of-business applications that can subscribe to that same MQTT infrastructure. By adding a local HMI, we can take the remote MQTT Edge product and have a local client that will enable you not only to be publishing all of that information in real time to your MQTT servers, but also being able to view that information locally.
Arlen: As I mentioned, a lot of customers, we have a lot of brownfield installations. So, how do we take this technology and come up with a migration strategy? Because that's really what it's all about, is that 99% of the opportunities that any of us see going forward are not gonna be greenfield opportunities, but rather how can we provide tools for migration? In this animation, I've put together fairly typical legacy information. We've got an OPC UA server. It's polling in different protocols, PLCs, RTUs, flow computers. And this is all very good, this works. The thing is, this is a very good working, operational system. But also note that we're tying these devices directly to an application, so moving forward and trying to get other application access to that data becomes problematic.
Arlen: Let's go ahead and install the MQTT modules from the Ignition Gateway. With MQTT distributor, you get a small MQTT server that you can start testing with. MQTT Engine is the MQTT client that knows... On the one side, it knows what the SparkPlug information being published is. And on the other side, it knows how to convert that into native Ignition tags. And then on the flip side, MQTT transmission can take any tag that exists within Ignition, whether it's a memory tag or OPC tag or another MQTT-based tag, and they can republish that out to your MQTT broker infrastructure.
Arlen: If we start putting together a migration strategy, let's look at that tank-level transmitter in the upper left-hand corner. Even though that is a HART smart transmitter, and it's got hundreds of tags of information and metrics and asset information when it was last calibrated and multi-process variables, typically, out of those hundreds, we take one process variable, I.e., the 4-20 milliamp loop, and we tie it into a PLC, and then we pull the PLC to get that single value. But we've been working with Magnetrol, and Magnetrol has an edge-of-network device that lets us connect using the HART protocol, convert all of the tag information, and then be able to publish that to an MQTT server. Engine subscribes to that, and 500 tags worth of very valuable information all of a sudden show up natively within Ignition.
Arlen: You can see here, I can run these in parallel. I still have my safety critical for the 20-milliamp loop, but now I have access to all of the multi-process variables and all of the metrics and all the diagnostics available in smart HART-based sensors. I could decide that the digital signals are fine. I could migrate that out of being polled in natively MQTT. Elecsys manufactures a very interesting edge-of-network product that's able to provide terminal server reports. So, in a migration strategy, I could take an Elecsys edge-of-network gateway that implements MQTT, and I can continue polling with my OPC UA server, say Modbus or Allen-Bradley or Siemens protocol. But at the same time, I could start moving my polling locally in real time and then publish any PLC register that changed in my MQTT infrastructure. I can run in this mode until I'm very comfortable with MQTT, and then I could slowly phase that out.
Arlen: Hilscher communications make a very extensive line of what I would call factory floor protocol edge-of-network gateways, EtherNet/IP, ProfiNet, EtherCAT, CANbus, and they're able to attach in and watch the information that is already being polled within a factory environment. Take that EtherNet/IP or ProfiNet information, and publish it using the Sparkplug specification into MQTT, so that device might be able to migrate out. Opto 22 has implemented MQTT with their groov and their extensive line of optically isolated I/O, so that might let me replace a poll-response with the native publish-and-subscribe architecture.
Arlen: Moxa manufacture a complete line of network architecture and industrial I/O. Not only do they do the I/O, they do the cellular gateways and the Ethernet switches and the routers. And they are putting Sparkplug and all of their end devices, so that not only can I publish my real-time process variables, but I can start publishing network metrics. All of a sudden, now, either Ignition or other clients into my MQTT server can start seeing the network infrastructure in real time. And then, of course, the topic of this discussion today, now with the announcement of all of the Ignition Edge products, those literally become a migration strategy to take, move that polling out to the edges of the network, have my local HMI, if I want it, and be able to publish that information into my server infrastructure. And last but not least, B+B Advantech, their entire line of SmartWorx products are going to be implementing MQTT and be able to publish their real-time process variables and metric information.
Arlen: Basically what I've shown you here is you can start at any point within a conventional poll-response system, and with Ignition Gateway, you can start laying out your strategy to move from a legacy poll-response network, into a hybrid model, into a pure report by exception, publish-and-subscribe system. With that, Don, I'll hand it back over to you.
Don: Arlen, thank you very much. I think that really lays out a migration strategy that I think people can relate to with the brownfield world in which we all live. Now, you've gotten an overview of the three Ignition Edge products. Each one offers something unique, as you can see. Your organization might wanna move in the direction of IIoT, or your organization might not be looking at IIoT, but you still wanna bring your enterprise together and extend Ignition throughout the infrastructure more fully. Whether you want a solution for your local HMIs that's more powerful and standard touch panels like PanelView, or you want to embed Ignition, or you wanna publish field device data, or you want some combination of those capabilities, Ignition Edge has very practical solutions for you. Now, I wanna give you a chance to see this a little bit. I'm gonna turn it over to Travis to show a demo of the Ignition Edge products. With that, Travis Cox.
Travis: All right. Thank you, Don. I'll take you through a demonstration of Ignition Edge. I thought I'd first start with the installer, and then you guys can go and download 7.9.2. Currently, it's an RC, release candidate. It's on the website in the Early Access area, and will be a final release at some point soon. But I wanted to point out that Ignition Edge is inside of the normal installer that we have. It's a unified installer, and you can choose when you install, which product you would like to select, whether that's the full-fledged Ignition or the Ignition Edge.
Travis: I'm not gonna go through the full installation, but as we go through here, after I accept the agreement and choose my install location, you'll see that I now have the ability to choose Ignition full-fledged or Ignition Edge. And so if you choose Ignition Edge and go through the installation, then you will be presented with a web page, a gateway webpage that looks like this. This is the webpage for Ignition Edge. As you can see, very similar to Ignition, but clearly you are working with Ignition Edge. And this is our entry into Edge, so here we could actually go ahead and launch the project for Edge Panel. We wanna see as a run time locally as well as the one remote client, and we can go into the configuration to connect to devices and to get everything configured for Edge, where I want to log, where I want to... If I wanna synchronize information back to a central system for Enterprise, all that's in here. And, of course, we can launch a designer to do the bulk of all of our configuration.
Travis: I, on this particular instance of Edge, I have Edge Panel and I have Edge MQTT running here, but I could just as easily have Edge Enterprise logging information back to a central system. I could certainly launch the Edge project here, and you get that one project. Here is the Edge project. You can see in the top left the logo is the green check, so you know that you're working on the local address out there. This is just a simple HMI screen. You've probably seen this in our demo project before, but it illustrated the fact that I could have one remote client. I'm not on the same machine right now as the server, so the server is on a different machine here, and so I have the local client on that same machine, and I have this one client for Edge Panel, so very simple.
Travis: And you can see here that while I pull the tower, I am getting history because we are... Edge Panel has that one week of historical data buffering that we can view on screens. With Edge Enterprise, we can then synchronize information back to a central, as Colby was mentioning. It's important to note that I don't have to have the screen open to have a logging. It's logging even if I close the client, and we can go back and look at that one week of data.
Travis: Now, the same information that I have here is being published to a broker that happens to be in the cloud for MQTT. We have a server at iiot.inductiveautomation.com. All these tags here are configured to publish to that broker, and I am launching a project that is from that website, iiot.inductiveautomation.com, that's a tag dashboard project. And I'm seeing here, here's Ignition Edge, and the actual device, here's refrigeration, and all of those tags you can see they're changing here. They're publishing from my Edge Panel. So, we're utilizing both the Edge Panel and Edge MQTT to take advantage of those features there with Edge. A really simple demonstration here to show the uses of Edge, but very simple to get started with. It comes into our trial period, so anybody can download, fully configure all three of those products or any one of them individually, and really test out and use this to complete your enterprise architecture. With that, back to you, Don.
Don: Thanks, Travis. Thanks a lot for that demo. We're trying to give you a full picture of what the opportunity is here and what the product capabilities are, and also still leave enough time for Q&A, 'cause we have a pretty good queue of questions. Remind you again, it doesn't matter what, just type those questions in because we got Arlen, Colby and Travis here ready to answer them as we go forward. I really would just like to summarize the discussion about IIoT. There are really six ways that Ignition IIoT infrastructure, with Ignition Edge MQTT, can absolutely deliver on the promise of IIoT. First one, going back to the new architecture, decouple devices from applications. It can't be emphasized enough, stop connecting devices to applications with protocols. Instead connect devices to infrastructure so that applications, such as HMI SCADA host applications, can subscribe to an infrastructure of devices that are publishing interesting information.
Don: Secondly, provide a superior OT solution. If you take a look at that, really replacing brownfield SCADA systems cost millions of dollars, it's hard to justify incremental changes. IIoT solutions only work if they meet the needs of the operations folks first. Ignition is exponentially faster and more cost effective than any other SCADA solution, and the Ignition MQTT infrastructure offers exponential benefits at a cost really that doesn't break the bank. So, it solves that problem of making sure that you go OT, IT, OT first, solve the operational problem, and then with the operations folks knowing they've got a solution, it actually can go across the boards beyond that.
Don: Single source of truth. Arlen talked about this. Modbus, actually was released, what, 1978, but it is still the dominant SCADA protocol. Human workers have to edit every tag polled by Modbus, which is a tedious and error-prone process, for God's sake. If you convert from one SCADA system to another, every single tag has to be edited again. With IIoT, the device ultimately becomes the single source of truth. This saves thousands, if not tens of thousands, of man hours, and puts a lot more confidence in the data that you're getting from those devices as it moves throughout the enterprise.
Don: Plug-and-play. It's 2017, we're still implementing SCADA systems by tediously describing and configuring devices, protocols and registers. With IIoT devices and sensors, we should be able to dynamically join the overall infrastructure and provide a plug-and-play OT functionality.
Don: I think this is a pretty important one to a lot of people that eliminates cutovers. Most SCADA systems, they have to be deployed in one fell swoop to bring the current poll-response application down and bring the new version up. And if it doesn't work, you have to bring the old one back up and start all over again. We need the ability to run an OT application in test mode, in parallel, before cutting over. That's another promise of IIoT. Cutovers can be a thing of the past.
Don: It really accelerates innovation with its model of unlimited developer seats, tags, connections, etcetera. We're well aware of this at Inductive Automation. It's part of the business model that came from our CEO when he started out. We wanna unleash innovation, and that means you have to take an unlimited model. Innovation doesn't happen when technology is complex, expensive, and isn't readily available to the enterprise at large. Every other SCADA HMI platform, it charges an additional license cost for each developer seat. When you have unlimited tags, clients, device connections, developer seats, it makes Ignition the ideal platform to start IIoT projects. It eliminates those conventional barriers as the project scope ultimately will grow, which is inevitable. Just given the very nature of IIoT, the scope is gonna grow. And it also unlocks the promise that, in the IIoT-empowered enterprise, the technology can be accessible to anyone with a good idea, which allows systems to continually improve.
Don: There's been a lot of emphasis in our presentation today on IIoT, but I just wanna be clear that Ignition Edge is a lot more than just that. Whether or not you are personally interested in your organization to IIoT right now, Edge really is an opportunity to bring everything together into an integrated enterprise. If you're already using Ignition in your infrastructure, you can have Ignition HMIs as a solution for touch panels. Ignition could be embedded into devices. This is a very affordable way to extend Ignition out farther and wider through your network. With Ignition and Ignition Edge, we offer solutions from the edge all the way to the enterprise level. The Ignition Edge release candidate, it's available to download. It's on our website, inductiveautomation.com. The full version will be available soon. You can download it, you can start using it right away in trial mode, and just like Ignition, you can start developing easily and rapidly with Ignition Edge right away. So, I really, really encourage you to do that.
Don: Also, depending on where you are in your understanding of Ignition overall, you can try out the full Ignition platform for yourself at inductiveautomation.com, download in just three minutes, use it in trial mode for free for as long as you want. And as far as just your knowledge of Ignition, if you wanna learn more about it and the many things you can do with Ignition, we have a university, free training website, inductiveuniversity.com. Our online courses will guide you through all the steps to earning Ignition credentials. It really is easy to sign up and start learning Ignition at your own pace, no matter where you are in the world, so please take advantage of the 600 some videos that are there. And also for guys who are working as integrators and integration within industrial organizations, you can research whatever you want and just zero in on those videos that help you in whatever projects you're working on to get the solution you need and the information you need rapidly, so take advantage of Inductive University.
Don: With that, if you want a personalized demo of Ignition platform or Ignition Edge, call us. The contact information, we'll leave on the screen here for our sales team and our account executives to schedule that with our design engineers. With that, let's go to question number one. This one, I'll kick to Travis. I only see Ignition Edge for ARM 32-bit processors. Will there be releases for x86 and AMD64?
Travis: Yeah. The Edge product, as I showed earlier in the demo, you can install it from the regular Ignition installer, so it's a unified installer that includes a full version as well as Edge. You'll see the Windows, Linux and Mac OS 10 installers on the website. There's 32 and 64-bit. And because Edge will be embedded in a lot of devices, especially ARM devices, we have a specific ARM binary that's a zip file that you could download separately, as there's also zip files for the full version of Ignition. Everything you'll find is on the Downloads page.
Don: Fantastic. Next question, I'll throw it out and then you guys can decide who wants to answer. Can Ignition Panel run on Windows CE?
Travis: No. Windows CE does not run JRE, so we've never been able to run a client or the full Ignition there on that device. We have had customers that would create webpages and launch it on there, but really you're looking for getting devices that can have a Windows-embedded OS that you can install JRE on or...
Colby: Or Linux.
Travis: Or Linux, of course, yeah.
Don: Okay, great, thanks. We're gonna try and get to as many questions as we can here, so you guys just grab them as I say them. Are the Edge devices all pieces of hardware? Colby?
Colby: Okay. That might be a misconception that would be easy to understand when we talk about all these Edge devices. But, no, no, Ignition Edge is purely software. It's a version of Ignition. It's built on the same platform as Ignition, but there's just... We talk about devices a lot because we envision it being installed in an embedded situation where the role of the device is primarily to execute functionality of Ignition Edge. So, no, it's just software. It's just basically Ignition.
Don: Cool. I'm gonna throw in a question here for you, Arlen, 'cause I know a lot of work you've done, even conferences that you and Travis and I have been at, from the Automation Conference, the interest in embedding has gotten greater. Can you make a couple of comments, Arlen, about interest in embedding Edge with other third-party OEMs, and maybe a comment on which OEMs are embedding Edge at this point? And if Travis wants to chime, he can, too, but let me start with you, Arlen.
Arlen: Okay. Thanks, Don. Yes, we've had huge interest already. In the pre-announcement, we already have Ignition Edge running on some Opto 22 equipment. We have it running on some Hilscher equipment. I'm sure we'll have other equipment running it. And to the other question previously, to maybe eliminate some of the confusion, the ARM version of Edge will run quite happily on a Raspberry Pi, and that's an example of the types of edge-of-network devices we're targeting.
Don: Great. Thanks, I appreciate that. And here's another question, this one I'll throw to you, Travis. Are there limitations to the project design and the designer on Edge Panel?
Travis: As we mentioned here, there are limitations of Edge in general. For example, we have no database access, we have no gateway site scripting, and we have 500-tag limitation. But besides those restrictions, as far as... You only get one project with Edge, for Edge Panel, but everything you would have configured on a regular full Ignition, you could import into Edge, to Edge Panel. Really the only restrictions are the big restrictions of Edge. Everything you do inside that project is available. Scripting is available inside the client as well.
Don: Okay, cool. Hey, Arlen, you take this question. Where does the MQTT "cloud" actually exist?
Arlen: It can exist on-premise, it can exist in the cloud, and we have hybrid infrastructures as well. Again, a lot of the legacy approaches are, "I've gotta have my MQTT infrastructure on-premise," and it works quite well that way.
Don: Great. Thanks, Arlen. I'm gonna go fast 'cause there's a ton of questions here. What is the relationship between MQTT and OPC UA? When do I use which protocol? Arlen?
Arlen: Well, actually, the OPC UA Foundation just released their PubSub Part 14 spec, so I would encourage everybody to take a look at that. You'll see that MQTT is involved there, and we are actively working... Cirrus Link is working with the OPC UA Foundation on that. And I think really... Remember, MQTT was designed... When we originally designed it, it was designed to work on an aggregate baud rate of around 300 baud over VSAT systems. And we had to eliminate the polling, so that was really the reason it was invented. So, really I look at it... Factory floor typically is OPC UA, but we have a lot of customers wanting to move to MQTT. When you look at WAN-based SCADA, we're using cellular VSAT in water, wastewater, oil and gas. MQTT is much more efficient on the wire. It lets you send more data, and lets you send it quicker.
Colby: And I'll add to that, Arlen, in that, if you look at MQTT versus OPC UA, certainly MQTT, the actual specification, is much smaller, easier to implement. There's already a lot of tools out there, especially to implement like Raspberry Pi or Arduino boards. And a lot of people that are graduating college or they're in college are playing around with these technologies. OPC UA certainly has its footing on the plant floor. It's a little bit more complex as far as the protocol. I think OPC UA will have a footing there on the plant floor for a long time. Devices, a lot of PLCs are now supporting OPC UA natively. They have servers on board, like Siemens and Beckhoff and Bedrock Automation, and we can, of course, communicate to that directly, and other applications can be catered to that directly as well. I think, for the plant floor setting, OPC UA is perfect. For going to remote or remote locations that have constrained network or going to the cloud, I think MQTT is a really good approach for that versus OPC UA.
Don: That's great. This is kind of a related question, if anyone wants to elaborate on it. I'll just read it from John Bell here. He says, "Aren't many companies already using central OPC servers as a central gateway to process data pretty much in the same role as the MQTT broker in your diagram? And isn't publish-and-subscribe being added to OPC UA? If so, will MQTT provide much of an advantage in the future?" Arlen, what do you think?
Arlen: Well, again, he reiterated what I said. The PubSub spec did just come out, so it's just in its infancy. And really when I look at IT architectures... Although I agree 100% OPC UA server infrastructure is out there, but if I look at my migration to analytics and what people are wanting to do with machine learning and the ingest engines are out there, if you look at Microsoft or Oracle or IBM or Google Cloud Platform, they all offer ingest engines that support MQTT. So, it's going to be... I don't think we're trying to recommend one or the other. I think it's gonna be a very dynamic mix of tightly coupled OPC UA and then more loosely coupled MQTT architectures, and ultimately they may work all together in an overall OPC UA Foundation specification.
Don: Great. Thanks, Arlen. Travis, I think I'll throw this in your way. You mentioned a limit of 500 tags. Arlen is talking about hard data related to an analog signal. This is very interesting and powerful, but will I reach my point limit with one device?
Travis: Yeah, Arlen is talking about having 480 tags on the one HART transmitter. Certainly, Edge has a 500-tag limitation, so it would be perfectly coupled with that one device, but there are situations where that 500-tag limitation, you wanna have more than that. And so that's where we can go to the regular Ignition and look at the MQTT Transmission Module, where we have unlimited tags. And, of course, the full Ignition will also run these embedded devices, and has a binary farm as well. So, Edge is there for particular situations, and then we have the full Ignition for things outside of that.
Don: Cool. Colby, do you wanna add...
Colby: Yeah, that's great answering. I just thought I'd chime in and say that that was... Our philosophy on Edge was to deliver the widest range of functionality in which we could guarantee a certain performance capability on these constrained devices. We still have the full range of options available to us in terms of other Ignition modules and additions.
Arlen: And I'll just mention one last thing there very quickly. With transmission, you can configure it, depending on your edge-of-network device, to where only a few of the tags from the HART transmitter ended up in your Edge point count, but the other ones could still happily be published over MQTT to your centralized MQTT.
Don: Great, thanks. Okay. Next question. Can I use Ignition Edge alone, or does it need to be in conjunction with a gateway?
Travis: You can most certainly use Edge Panel on its own, the three products that makes most sense to use on its own, because it could be a local HMI, and again, you have the history and the alarming. Edge Enterprise is designed to work with a central Ignition Gateway. You can get to take advantage of the enterprise administration and the synchronizing of the historical data. And Edge MQTT obviously is going to publish data to a central MQTT broker, so that one is also designed to work with something centrally. While it's not Ignition, it can put it in data, the other applications can get access to it as well.
Don: Cool. Can a project developed on Edge be imported into an Ignition project?
Travis: Absolutely. Like I said, you can import the projects into Edge. However, if you were using database queries or if you were using gateway scripting, of course, those won't translate over, but everything else will.
Don: Cool. One thing... I think maybe I could throw this in your direction, Arlen. Can you talk at all about any projects where Ignition Edge is being used currently?
Arlen: Well, it was just released.
Don: Yeah, it's only been a half hour, right?
Arlen: Yeah, it's only been a half hour. Yes. We do have some early adopter customers for...
Don: Yeah, very early, very early.
Arlen: Very early. And as far as the other information, again, it all revolves around using MQTT with Sparkplug specification, and we definitely have that deployed in the field as well.
Don: That's great. That's good. We just got a couple of minutes, I'm looking for... Guys, we're choosing a couple more questions here. Edge can show one week of history, but can it look at the gateway tag history and see further back?
Travis: Edge cannot. But with the Enterprise, that central gateway... Like we've said a number of times, Edge can synchronize its history to the central gateway. And then the central gateway can use the gateway network to view the real-time tags or the alarms, and so on. And so the way we think about it is Edge providing data up towards higher levels of the Enterprise for longer term analysis. So, once Edge has sent the data to the central gateway, you can have any amount of data there, and that central gateway can look at it going back forever.
Don: Cool. I think you just answered this question, but how does Ignition Edge work with EAM?
Travis: In terms of base functionality, it's exactly the same as any Ignition agent. There are your standard other agent events such as getting alarms when the agent goes down or is disconnected, performance monitoring. And then all of the tasks such as collecting backups or centrally activating licenses and so on, all of those work exactly the same as the standard Ignition gateway.
Don: Yeah. Travis, you wanted to comment.
Travis: I wanna make one general comment about Ignition Edge. Obviously Ignition Edge is very similar to Ignition. And for those of you who know Ignition's modular approach, we still have modules for Ignition Edge, except for we pre-selected them for the particular products. And the only thing that you could add to Edge, just so we can clear it up here, is the extra drivers, like the Amran and DNP3 drivers or cell connectivity, but all the other modules of Ignition will not... You cannot add those to Edge. Edge is those three products and those restrictions, it's very specific.
Don: Great, thanks. We got time for just a couple more questions, but I wanna reiterate, because there's still tons in the queue here, we are gonna get an answer for everyone's question. We're trying to hit ones that may relate to a broad audience. Here's one, "How are tags defined in the tag count?" Bill Marks asked that question.
Colby: Yeah. A tag is defined as... Well, in terms of Ignition terms, it would be an expression, an OPC tag, or... UDT definitions don't count, folders don't count, but anything that is evaluating a value does count.
Travis: So, if you had one UDT instance, and the instance had 100 tags inside of it, it is 100 tags. It's not one. So, tags within... UDT instance acts like a folder, folders don't count, so OPC, memory expressions, SQL query tags all count. Client tags are not part of this. Client tags are part of the project, they're not part of the actual tag system.
Don: Great, thanks. What are the bandwidths and latency considerations that we should consider? Michael Dough with that question.
Travis: That's a general question. It depends on what you're looking at. If you're looking at Edge MQTT, MQTT is designed for... Be a lot easier, a lot lower bandwidth there. Arlen, you can comment in just a moment again on the satellite, what you designed it for. As far as Edge Enterprise, there is... The data that's being synchronized is going through Ignition's gateway network, and the gateway network is designed to also lower bandwidth. And we're sending the historical data to the central, which, of course, is gonna go into the database. And we can do the compression and things along the wire to bring the real-time data and historical data up to a central system. Edge Panel, of course, you're not talking about that and with the bandwidth, 'cause it will all be locally. But Edge MQTT and Enterprise, there are a lot of things built in to make that as efficient as possible. Arlen, maybe you want to comment on the MQTT real quick.
Don: Yeah. Arlen, as you comment on that, I'm also gonna ask you to make any final comments you want, 'cause we're wrapping up, but comment on what Travis just said, and then any final things you wanna say to our audience before we close down our webinar.
Arlen: Okay. Thanks, Don. No, the MQTT, again, just going back to what it was originally invented for, imagine having a 300-baud connection that's very unreliable, and it was built for networks that were... You could suffer rain fade in dial-up networks, suffer network losses, so it was really designed to be as light on the wire as possible. Since it does use a thing called continuous session awareness, then only data that changes is published. So, in a lot of cases, you're looking at a 80-90% reduction in the bandwidth of what you would have been using a poll response network for. So, from that standpoint, it's very efficient. With that, Don, again, all of this has been very exciting. Basically, MQTT enablement for Ignition has been out there for a little over a year now, and the amount of interest and demand that we're seeing in it is very exciting.
Don: That's great. I really appreciate your time today for participating in the webinar, too. And with that, I wanna ask either Colby or Travis, or both, if they have any final comments they wanna make to wrap up our webinar.
Travis: Yeah. I just wanna say that I'm co-director of sales engineering, and we work very closely with sales, so certainly if you guys have any questions, technical questions, you want a demonstration, please contact your salesperson here and we're happy to set that up. We also can talk about the architecture and how we can make all of that work with Ignition Edge and the full Ignition version, when they're applicable and when they're not. So, please just let us know, we're here to help.
Colby: That's great. Yeah, as a co-director of software engineering, I just wanna reiterate that Travis is a terrific resource for answering all the questions. [laughter] From our point of view, I'm excited about this product. It ended up being a little bit more work than I think my team expected because once we got going, we wanted to build the most streamlined and just purpose-specific product we could, and I think it turned out really well. But what I'm so excited about is the way that this continues to develop our architecture for delivering a comprehensive solution built on one fundamental base, which is Ignition, so from every level of the Enterprise. And now, the very edge-of-network, up through your central plant and regional servers, up to your enterprise level servers, and so I'm just very excited about the way we continue to push it out to each level.
Don: Thanks, Colby. Thanks, Colby, Travis, Arlen. And with that, we're at the conclusion of today's webinar. Please take advantage of us to any help we can be to you. We much appreciate your attention today. Have a great day.