Ignition Edge has come a long way since it was first introduced. There are now five different versions of Ignition Edge, which give it the flexibility for almost any situation. With exciting things coming down the pipe like Sepasoft’s OEE Edge, it is a great time to look into Edge solutions if you haven’t already.

Following the order of Ignition Edge packages on the Inductive Automation site, let’s dive into an overview of each option, discuss when and why you would want to use it, and help you decide if Ignition Edge is right for your project.

Ignition Edge IIoT

Ignition Edge IIoT (Industrial Internet of Things) is the very definition of a typical edge device. It is built to leverage the MQTT protocol to get data from the field back to a central gateway in the most efficient manner possible. Edge IIoT comes with the communication drivers for all of the major PLC manufacturers, as well as Modbus, and DNP3. It is quite possibly the most cost-effective route to get DNP3 data into a SCADA system on the market.

To further support Edge architecture, Ignition Edge IIoT supports Store and Forward, so you can still get data even if your network connectivity is intermittent. Data will be stored locally at the Edge level, then pushed to the main systems when connectivity is established.

You should use Ignition Edge IIoT if you need to get data from PLCs into an MQTT Broker or a central gateway, but don’t need to have a local operator interface at the Edge location. This can even be useful for facilities with multiple buildings, or if you simply want to have machine level store and forward capability for the most robust high availability data collection system possible.

Ignition Edge Panel

Ignition Edge Panel is the best choice if you want local machine control. It gives you the capability to build an HMI using Vision or Perspective, includes trending capabilities, and can even be used for local client fallback for a high availability system. At Corso Systems, we typically use Ignition Edge Panel for machine control, then we set up the Edge Gateway to act as a tag provider to the main gateway. Then, we configure failover to the Edge gateway in the event of a network outage. This approach reduces the overall system complexity and makes it relatively easy to recover from a network outage without manual intervention to sync data with the main gateway.

Edge Panel gives you alarm notifications via email out of the box. This is handy as a low cost solution for remote alarm monitoring. This is all configurable via the gateway, and gives you the ability to send alerts based on priority without having to manage alarm notification pipelines.

This flavor of Edge still allows you to communicate with all of the PLCs and devices on your plant floor. If you need to use MQTT, you can add in Ignition Edge IIoT for a full suite of protocols.

Finally, Edge Panel provides a week of built-in historical data tracking so you can build trend screens for your HMI, as well as keep a week of data on hand in case you need a backup of it for any reason.

You should use Edge Panel if you want to have an HMI, or if you need to replace a Panelview Plus or other machine mounted HMI device. Ignition Edge Panel also gives you the week of historical data backup as a failsafe for a mission critical system. Also keep in mind that you can use Edge Panel for local client fallback, allowing you to operate your equipment even if you have no network connections to the panel. This is great for remote locations without a reliable signal to control the system remotely.

Ignition Edge Compute

Ignition Edge Compute is the first release to expand beyond the initial scope of Ignition Edge as a platform. It lets you use the built-in web server in the Ignition gateway to build APIs and webpages in Ignition, as well as communicate with PLCs and other industrial devices.

If you are at all familiar with the WebDev module in a standard Ignition deployment, this is the same as on an Edge license. It lets you use the built-in scripting functionality in Ignition, and expose data to other web services.

You should use Ignition Edge Compute if you need to get your machine data into other systems in a particular format via an API, or if you would like to build basic dashboards or displays using the web server to host a page. It will also allow you to query other web services, so if you needed to send data to a PLC from an SAP web services call without getting into a full-blown MES system, this would be a great approach.

Ignition Edge Compute is also the only way to access to Gateway scripts with an Edge license, something you have to work around using client scripts in other Edge versions.

Ignition Edge Sync Services

Ignition Edge Sync Services gets data from our PLCs and field devices into other Ignition gateways as a remote provider. This includes tag data, historical data and alarming.

This platform also includes a week of store and forward buffering for historical data similar to Edge Panel.

You should use Edge Sync Services if you have an existing Ignition system and simply need to get data into it from a remote site. Edge Sync Services also works well on a machine where you don’t need local control but want to take advantage of a robust architecture with tag providers as close to the machine as possible in the event of network outages. For example, if you have an OEM piece of equipment with a non-Ignition HMI, and you want to get the data into an Ignition gateway for dashboards and trending purposes without replacing the existing HMI.

Ignition Edge EAM

Ignition Edge EAM is more of an add-on to any of the other Edge configurations. It lets you set up the Edge Gateway as an EAM Agent you can manage form an EAM Controller gateway to publish tag changes, project changes, take automated backups, handle fail-over, etc.

You should absolutely use Edge EAM if you have a central gateway so you can configure projects and manage changes from the master gateway. If you are using Ignition Edge Panel for stand-alone control or something where you aren’t using EAM on a master gateway there isn’t a need for this.

If you are using a master gateway and Edge gateways, or multiple standard gateways on your system, and aren’t using EAM, you should look into it, since it is one of the most worthwhile investments you can make in an Ignition system with multiple gateways.

With Our Edge Powers Combined…

There are many use cases for using only one type of Edge architecture on a system:

• OEM equipment with Edge Panel

• A remote site with no control but data requirements using Edge Sync Services

• Any number of use cases for Edge IIoT

With more complex requirements, you can still build a functional solution with Edge by combining multiple gateways. For example if you have a piece of OEM equipment and you want to push data from the gateway into an API at the business level for tracking production runs and quality metrics. In this case, add Edge Compute to Edge Panel and you can control the machine locally, push data into any system you want, and have a fully featured system capable of interacting with your overall business systems.

Maybe you want MQTT Data on a gateway and also want to use the gateway as a remote tag provider for your master gateway - then combine Edge IIoT and Edge Sync Services.

Wrapping Up

Ignition Edge has come a long way from its humble beginnings. It provides a lot of options to build a fault-tolerant distributed architecture capable of interacting with just about anything your business throws at it. In cases where you don’t need a full gateway, Edge is a viable alternative. In cases where you have a full gateway, Ignition Edge can add value to the system with minimal investment.

Need help with Ignition Edge to expand your horizons? Contact Corso Systems!