Table of Contents
1. Introduction
Transitioning from a single Ignition gateway to a multi-gateway architecture is a significant step towards improving system performance and reliability. This guide walks through the process of migrating your setup to a robust front-end and back-end gateway configuration. The single gateway setup works well in small, low-traffic environments, but continuing to add more devices and clients to the gateway will eventually overload its resources and lead to a degradation in performance. The solution is to split the Central gateway’s tasks between two dedicated gateways. In this scaled-out setup, one gateway handles visualisation and client communications while the other deals with PLC and device communications and the two are connected via a gateway network.
Inductive Automation’s detailed guide on this topic can be found here. Our aim in this complimentary guide is to provide context by performing migration on an actual project. The project we’ll be using is Inductive Automation’s DBS Task Management Application, and we chose it for two reasons. Firstly, all certified SIs are familiar with the project and will therefore find it easier to follow along with the screenshots, configs and project properties. Secondly, the project contains all the features – Windows, Templates, Named Queries, Scripts, Alarm Pipelines, Reporting, etc – necessary to demonstrate the key points to consider when scaling out an Ignition gateway.
Before running migration in a live environment, it is advisable to first try it out in a controlled test environment. To this end, we’ve created a separate guide that demonstrates how to use Vagrant to quickly spin up a Virtual Linux environment consisting of an admin server and two remote servers that act as hosts for the two “states“ we’ll be dealing in this guide. The first state is the initial setup with one Central gateway connected to devices and clients as shown below.
Figure 1: Before migration – single central gateway handling both UI and IO communications.
In the final state, the Central gateway is replaced with Frontend and Backend gateways that form part of an Ignition gateway network, as shown below.
Figure 2: After migration – central gateway replaced with frontend and backend gateways that are connected through a gateway network.
This guide begins with a discussion on how the existing Central gateway is to be repurposed. Sections 2, 3, and 4 highlight the configurations and actions to be performed on each gateway, beginning with the Central gateway, then the Backend, and finally the Frontend gateway. We conclude with a migration success test and mention possible next actions.
2. Repurpose Existing Gateway
Single-gateway architectures fall into three categories: frontend-heavy, backend-heavy, or evenly distributed. For an evenly distributed gateway setup, the Central gateway can be repurposed as either a Frontend or Backend. For a frontend-heavy gateway, the best approach would be to repurpose the Central gateway as the Frontend. In our case, the load is somewhat evenly balanced, so we decided to reuse the Central gateway as a Backend gateway.
3. Configure Central Gateway
On the Central Gateway, we’ll start by generating an export of project properties, tags and device instruction files. We will then discuss how the modules will be split between the two gateways.
3.1 Export Project Properties
Open the Central gateway’s Designer and export Named Queries, Project Scripts, Reports, Templates and Windows.
3.2 Export Tags and Instruction files
While still on the Central gateway, the designer creates an export of tags in the default tag provider.
In the gateway’s web interface, export instruction files for all devices connected to the gateway.
3.3 Module Distribution
The screenshots below summarise how the Central gateway’s module will be split between the two gateways. Vision, Reporting and Symbol Factory modules are moved to the front-end.
OPC-UA, Alarm Notification and Tag Historian modules remain in the Back-end.
4. Configure Backend
The Central gateway is repurposed as the Backend. This means that the Backend will maintain the following:
- Gateway Connections: Devices and Database,
- Project Properties: Alarm Notification Pipeline
- Gateway Configurations: Users and Roles, On Call Roster and Email Profile.
All that remains to be done in the Backend is to configure its gateway network connections to the Frontend and Edge gateways.
5. Configure Frontend
In the frontend gateway, we will create Users and Roles, connect the gateway to a database, set up a remote tag provider pointing to the backend gateway and import project properties from the original gateway.
5.1 Setup User Sources
Create a User Source with users and roles as they appear in the Central Gateway.
5.2 Configure Frontend Database Connection
The frontend displays information pulled from the database and responds to some user actions by running queries against a database. For these reasons, the Frontend needs a connection to the database that replicates the original gateway’s database connection.
5.3 Setup Remote Tag Provider
Use the gateway network between the backend and frontend to set up a remote tag provider on the frontend and point it at the default tag provider on the backend gateway.
Once the gateway connection to the Backend has been validated, both the tags and UDTs defined in the original project should be accessible to the frontend gateway’s project.
5.4 Import Project Properties
Import Scripts, Named Queries, Windows, Templates and Reports into the Frontend gateway using the designer.
6. Migration Success Test
The ultimate measure of the success of a migration is user experience. When done properly, the user of the application shouldn’t be aware whether the application they are interacting with is served up from the Central gateway or from the Frontend gateway; the experience should be exactly the same. This means that all Windows in the scaled-out system should display all graphics as they appear in the original project, and data used to fuel those graphics must be present as well. Here’s a side-by-side comparison of the project deployed from the Central gateway and the project served up by the Frontend gateway:
The Overview Window showing UserB’s tasks on all machines
Equipment Schedule Windows with identical charts and entries.
The Routine Schedule tabulates all tasks across all machines for all users.
The Machine Tasks Overhead display shows identical records.
Preview of the report in both projects.
7. Conclusion
This guide walked through how to scale an Ignition gateway by splitting its modules, configurations, and project properties across two gateways, and wrapped up with a migration success test.
Useful Resources
- Inductive Automation’s Scale-out Architecture Guide
- A Guide on Using Vagrant to setup a Test Environment
- Github Repos of Test Environment, Initial Setup and Final Setup.
- Videos of and Test Environment