Ignition Edge - Taking it to the Edge

As Ignition evolves, the landscape for smaller gateways has changed. In the past, there’s been a focus on single or reduced client licenses for small systems. While these situations still exist, with an Ignition Edge package they are much less common. With hardware companies participating in Ignition On-Board program, Ignition Edge is becoming even more prevalent. This raises a few questions, many of which we will answer in this post. Be sure to review all the details in the Ignition Edge documentation.

1. Panel vs. MQTT vs. Enterprise

The first question people usually have is which package should they use. It can be helpful to think of each Ignition Edge license as a module. If you want to have an HMI client, you want Edge Panel. If you want to sync data to a central gateway, or handle anything you would normally be handled by the Enterprise Administration Module, then you will want Edge Enterprise. If you want to use Ignition Edge as part of an MQTT strategy, choose Edge MQTT. You can mix and match to get the functionality you need. As an example, Edge Panel plus Edge Enterprise is great for local failover at the machine level—including store and forward capability. Adding MQTT would give you the ability to use this gateway as part of an overall MQTT architecture.

2. Can I use Ignition Edge in a large facility?

Yes. You don't need to have a distributed architecture (like an oil field) to use Ignition Edge licensing. A common use case is installing Ignition Edge at each machine with an HMI on the plant floor. In this situation we’ll usually set it up a with Edge Panel, Edge Enterprise, and use the Ignition Edge license for local fallback. If the network goes down and both redundant gateways are unavailable—but you still need to run your plant—this installation would have you covered. Looking to use Ignition Edge as part of a Digital Transformation? Read our post about data migration, and the process of moving to new systems for digital transformation.

3. What about the limitations of Ignition Edge?

Ignition Edge does have limitations compared to a full Ignition gateway. But, we haven't found anything to be a show stopper. However, even if your use case might require something that may be a limitation, we have found that there are workarounds in the built-in system functions for just about anything. Most times it makes more sense (in terms of cost) to use a full Igntion gateway as part of the architecture instead of writing and maintaining custom code. But, people make interesting decisions sometimes.

Here are the major limitations and how they may apply:

• Single Project: Not a big issue, if you are using an Ignition Edge License, you are not looking to run an entire facility with it. Since there will only be one project, the limitation of only being able to run one project won’t be a limitation.

• Database Access: This limitation can be a bit of a hurdle depending on your use case. If you absolutely must have database access, you can most easily use the built-in system.net functions to call an external webserver that can handle inserting records into a database. Most systems we’ve worked with which require database access are okay to run in a limited mode if they are running on Ignition Edge licenses in the first place. They will still get a week of historical tag data, and by using the Enterprise license, it can sync with the main gateway, so the most important data will be available.

• Scripting: Gateway level scripts simply don't exist in Ignition Edge. If you have them, you can simply move everything into a Client level script and be on your way. We advocate not using tag event scripts anyway, so the transition should be easy when moving from a full gateway to the Ignition Edge mindset.

• OPC-UA: The built-in Ignition OPC-UA Server is only capable of acting as a client in Ignition Edge. Similar to the single project model, this will usually not be an issue if you are working with Edge gateways in the first place.

4. Where would I use an Ignition Edge gateway?

Our most common use case is to run Ignition Edge as a cost effective way to keep a plant running when things go absolutely haywire. We also see it a lot in heavily distributed architectures which are leveraging MQTT. Ignition Edge takes the best of what Ignition has to offer and bundles it at a palatable price point. It’s also flexible enough to meet the demands of most applications.

Another common task for Edge is to use the Edge gateway to push data into a master gateway. This is helpful when the Edge gateway is at a remote site with limited connectivity. You can store the data locally, push it up to the main gateway when you have service, and go back offline until you can get connected again. This is great for remote pump stations for a water treatment facility for example.

Are you considering using Ignition Edge for your company’s project? Contact us, we can help!