Is one front-end gateway with remote back-end gateways a valid Ignition design?
Yes. This is the scale-out pattern. One central Ignition gateway hosts the HMI projects, and back-end gateways at each remote network own the device connections. Users at every site point their Vision clients or Perspective sessions at the front end and see data from all plants. Vision and Perspective clients can connect to a gateway at any reachable IP address, so a user at a remote site does not need a local gateway to see the central screens.
Some terms first. In Ignition, every server running the platform is a gateway. The central server is the front-end gateway. The servers at the remote networks are back-end or I/O gateways. It makes no difference to the architecture whether a back end sits in the same rack or across a WAN. The distance changes only the link budget and the firewall rules. A single front end serving 50+ concurrent users spread across the globe is a normal deployment, provided the server has enough CPU and memory for the session load.
Which hops carry a client request in each approach?
Follow the packet. A client opens an HTTP/HTTPS session to one gateway, and that gateway resolves every tag binding on the screen. The design decision is where the gateway gets the value from.
| Approach | Client connects to | Front end to site link | Who opens the WAN connection | Firewall openings | Fit |
|---|---|---|---|---|---|
| A: Direct client per site | Each site's own gateway | None | Every remote client, to every site gateway | Inbound web port at every site, for every remote user | A few engineers who need site-level access |
| B: OPC UA subscription | Front end | OPC UA client on the front end, OPC UA server on each back end | Front end | Inbound OPC UA endpoint port at every remote site | Back ends that are not Ignition, or site policy that mandates OPC UA |
| C: Gateway Network with remote tag providers | Front end | Gateway Network connection, with a remote tag provider per back end on the front end | Either side. Usually each remote site dials out to the center. | One inbound rule at the central site when the remotes initiate | Ignition-to-Ignition scale-out |
In both B and C the PLC polling stays on the plant side of the WAN. The back-end driver scans the controllers at local-network latency. Only subscribed value changes cross the WAN. Do not configure device drivers on the front end to poll PLCs directly across the WAN. Scan traffic then travels at poll rate over a high-latency path, so scan classes stretch, request timeouts pile up, and every link blip faults the device connection.
Which approach should a multi-site front end use?
| Criterion | OPC UA (B) | Gateway Network (C) |
|---|---|---|
| Tag structure on front end | OPC items. You rebuild folders and UDTs as OPC tags on the front end. | The back-end tag provider is browsed as-is, with folders and UDT instances intact |
| History and alarms | Not carried. Configure them separately. | The remote provider can be set to expose back-end history and alarms |
| Connection direction | Front end is the client, so it must reach every site inbound | Can be initiated outbound from each remote site |
| Trust model | OPC UA certificate exchange on both ends, plus user credentials | Gateway Network certificate or approval, plus security zones and service security |
| Non-Ignition back end | Works | Requires Ignition on both ends |
Use C when every back end is Ignition. You get fewer inbound firewall holes, the tag structure is preserved, and one mechanism carries tags, history and alarms. Use B for any back end that only speaks OPC UA.
Keep A as a local fallback rather than the main path. The front end is a single point of failure for the HMI at every remote site. If a plant must keep operating through a WAN outage, host a local project on its back-end gateway and point the local operator stations there.
How do you build the Gateway Network link to each back end?
-
Test layer one first. Confirm there is a routed path between each remote network and the central server, whether over VPN, MPLS or another WAN. Ping first, then run a TCP test to the front end's Gateway Network port. Read the port from the Gateway Network settings page in the front end's web interface.
Test-NetConnection -ComputerName <front-end-host> -Port <gateway-network-port> - Give every gateway a unique system name. The Gateway Network identifies peers by name. Two back ends cloned from the same image with the same name will collide.
- Create the outgoing connection on each back end. Point it at the front-end host and Gateway Network port, with SSL enabled. Dialing out from the site means only the central firewall needs an inbound rule.
- Approve the connection on the front end. If the front end requires approval of incoming connections, accept each back end. Then confirm each link shows as connected on the Gateway Network status page.
- Add a remote tag provider on the front end for each back end. Select the remote gateway and the provider on it, and give each one a site-specific name. Set history and alarm access to match what the front-end screens need.
- Restrict writes. Set the remote provider's access level and the back end's service security so the front end can only write where operations require it. Viewing-only sites get read-only access.
-
Build the views once. Bind to paths such as
[SiteA]Area/Tag, and pass the provider name in as a view or template parameter. One screen can then serve every site. - Size the front end. Load the expected concurrent sessions and watch CPU, memory and thread counts on the gateway's performance and status pages before go-live.
If you use OPC UA (B) instead:
- Enable the OPC UA server on the back end and expose the required tag providers.
- Create an OPC UA connection on the front end using the back end's endpoint URL.
- Trust the certificates on both ends.
- Check that the endpoint address the back end advertises can be resolved and reached from the front end.
What fails on remote back-end links?
| Symptom | Mechanism | Check |
|---|---|---|
| Gateway Network connection never comes up | Port blocked, or the connection was created on the side that cannot reach the other | TCP test from the initiating gateway's host to the target port |
| Connection sits pending or faulted | Incoming connection not yet approved, or TLS certificate not trusted | Incoming connections list on the receiving gateway |
| OPC UA discovery succeeds, then the session fails | The back end advertises an internal hostname or IP that the front end cannot reach through NAT or DNS | Endpoint address in the back-end OPC UA server settings, and name resolution on the front end |
| Two sites flap or overwrite each other | Duplicate gateway system names | System name on each back end |
| Front-end tags show bad or stale quality while the back end is good | Remote provider disconnected, or pointing at the wrong provider name | Quality in the front-end tag browser compared with the back-end tag browser |
| Writes from screens are rejected | Remote provider is read-only, or back-end service security denies the write | Provider access level and security zone rules |
| Remote users see slow screens while tags are good | Client-to-front-end latency, or the front end is short on resources | Latency from the remote client subnet to the front end, and the gateway performance page |
How do you verify the data path end to end?
- On each back end, confirm every device connection is up and the local tags show good quality.
- On the front end, confirm the Gateway Network status page lists every back end as connected. For approach B, confirm every OPC UA connection shows as connected.
- Browse each remote tag provider from the front end. Watch a continuously changing tag, such as a counter or clock, on both the back end and the front end. The two values must track each other.
- Drop the WAN link to one site. Its tags on the front end must go bad quality while the other sites stay good. Restore the link and confirm the connection and tag quality recover without manual action.
- From a client on each remote network, open a session to the front end and display tags from every site on one screen.
- Write a value to a designated test tag, where writes are permitted, from a client at a different site. Read the value back at the back-end gateway and in the PLC.
FAQ
Why does my remote tag provider show bad quality when the back-end gateway looks fine?
The front end has lost its Gateway Network connection to that back end, or the remote provider references the wrong gateway or provider name. Check the Gateway Network status page first. Then compare the provider settings with the actual provider name on the back end.
Why does the OPC UA connection to a remote Ignition gateway fail after discovery?
The back end returns an endpoint address that is valid on its own LAN but not reachable from the front end, which is typical behind NAT. Set the advertised endpoint address to a name or IP the front end can reach, and confirm the certificates are trusted on both ends.
Why does the front-end gateway need approval before the Gateway Network link works?
Incoming Gateway Network connections can be configured to require manual approval, so an unknown gateway cannot attach and read or write tags. Approve each back end on the receiving gateway once. The link then comes up and stays up across reconnects.
Why does polling remote PLCs directly from the central gateway perform poorly?
Every poll request and response crosses the WAN at scan rate, so latency stretches the scan and link drops fault the devices. Put the driver on a back-end gateway at the plant, and send only subscribed value changes to the front end.
Can Vision or Perspective clients connect to an Ignition gateway at another site's IP address?
Yes. A client connects to any gateway it can reach over HTTP/HTTPS. For multi-site HMIs, point all users at the front end and feed it from the back ends through remote tag providers or OPC UA.