Server Migration Latency Concerns - Justified?

Ignition
, ,
1

Hoping someone can offer feedback here...
Background:

  • The company I work for is running an Ignition Gateway (v7.9) on a site-local server.
  • This server contains the custom SCADA we wrote in Ignition, and also contains the SQL Server database where all of the data collected by the system lives (in addition to configuration tables for the SCADA and other tangential data tables).
  • Our SCADA connects to about ~30 PLCs local to the site (all Allen-Bradley ControlLogix/CompactLogix)
  • The SCADA is reading about 20-50 tags from each system (part counters, system status flags, process variables, etc. - basically the things we need for our custom OEE and SPC dashboards).
  • At any time during the day there are 100-150 client PCs connected to the Gateway running various projects that display dashboards using this data (most PCs are local to the site).

Our company's IT wants to move this SCADA server to a remote data center about 1000 miles away. Since we are collect all the data from local PCs and the data consumers are almost exclusively gateway clients, the idea of moving the server this far away has us concerned about latency.
I'm not an IT expert, but the idea of pushing this data out of 30 PLCs, travel 1000 miles to a data center, only to essentially bounced back 1000 miles to 100-150 clients seems ill advised. But again, I'm not an expert.

Before I escalate the issue with my company's IT I'd like to know that I'm not crazy (or that I am).

Can any one offer any input? Does this sound like a bad idea or am I worried about nothing?

Thanks!

2

Bad idea.

PLCs are indeed latency sensitive.

You should at the bare minimum have an on-site server for PLC (OPC UA) drivers.

7.9 is also end of life June 2022 so don't rely on IA support if things go skew-whiff.

FWIW I moved a 79 to AWS, but as we were getting 95% of data from RTUs (NOT PLCs) over 4G, latency was zero concern.

3 Likes
3

Polling PLCs from anywhere but the local network is probably a bad idea.

You might be able to split this into two gateways, one “IO” gateway doing the polling local to the PLCs, and another remote that uses OPC, Remote Tag Providers, or MQTT to consume the tags from the IO gateway.

I’m not sure why you’d do that, though.

1 Like
4

Let me chime in: this is an extremely bad idea. For the above reasons.

It also goes against U.S. government cybersecurity recommendations that OT servers and databases stay on the plant floor LAN.

Don't do it.

2 Likes