One operations team manages more than 70 power plants across the country: 50+ PV sites, 10+ battery storage sites, and 10 small hydro stations. The network at each site is small: one 4G router, a few unmanaged switches, 7 to 15 IP cameras, and one or two data loggers and PLCs. The sites are remote, with 4G as the only available connection.

This setup ran for years without major incidents — until the company decided to add a second-level SCADA system and send data from every site's data loggers and PLCs to an external server. Four problems surfaced at once:

• SIM cards kept running out of data, with no way to tell which device was consuming it;
• Cameras and OT equipment shared the same network segment, with no isolation;
• Data would travel over the public internet to the server, and plaintext transmission was not acceptable;
• With 70+ sites, configuring routers one site visit at a time was unaffordable.

These four problems map exactly to the four decisions involved in deploying an industrial wireless router.

Step 1: Segment the Network First

VLANs are the first task, not the last. Put cameras on one VLAN, PLCs and data loggers on another, and reserve a separate VLAN for the SCADA link. It may feel like overkill at first, but it pays off the day you need to trace traffic or isolate a security incident. In most traffic anomalies, the culprit turns out to be a camera or NVR quietly syncing to the cloud in the background — with proper segmentation, the suspect is obvious at a glance.

A router that can manage 2–3 VLANs is enough; hand the rest to a managed switch via trunk. Letting one cellular router do everything usually means every function gets compromised. Keeping the router focused on WAN, VPN, and the cellular side is a more reliable division of labor.

Step 2: Decide How the Protocols Travel

Modbus TCP, OPC UA, and MQTT are the usual suspects between PLCs, data loggers, and servers. One distinction matters here: will the data simply pass through the router to the server, or does it need protocol conversion (say, serial Modbus RTU to MQTT)? The former is a router's job; the latter is a gateway's job. Get this straight before selecting hardware.

For sites that only need pass-through, check two things when choosing a router: it supports Modbus TCP / MQTT data pass-through, and a serial port is a plus — it lets older data loggers (RS232/RS485) connect directly, eliminating a separate converter.

Step 3: Use a VPN Tunnel — Never Let Data Travel Naked

Data moving from the public 4G network into a server needs an encrypted tunnel. OpenVPN or IPsec is the standard approach: the router acts as a client and initiates the connection to the central server, so no public IP is needed at the site, and DDNS handles the addressing. On the SCADA server side, only a single VPN port is exposed; every field device stays hidden behind the tunnel.

This tunnel doubles as the remote maintenance path. Engineers can reach the field network over the VPN to debug PLCs, instead of relying on port forwarding — a practice that leaves devices directly exposed to the public internet.

Step 4: Make Traffic and Devices Visible

Once sites multiply, two things must be done remotely: traffic monitoring and device management.

For traffic, the router needs per-device or per-segment statistics with threshold alerts — automatic email or SMS notifications as usage approaches the cap, rather than discovering the problem when the carrier suspends the SIM. In the power plant case above, most data overruns traced back to background cloud syncs on a camera or NVR; with per-segment traffic data, that kind of issue can be located the same day.

For devices, 70+ sites and hundreds of routers make per-unit web logins unrealistic. A unified remote management platform allows remote configuration, reboots, and firmware upgrades, with real-time alerts for offline devices, weak signal, and traffic overruns. For teams that won't buy a separate network management system, the router vendor's built-in platform is the practical answer.

Turning It Into a Spec Checklist

With this framework, an industrial wireless router check comes down to five items:

• Cellular standard: most industrial sensors send only a few KB per hour, so 4G Cat4 is enough; consider 5G only with video backhaul or expansion plans;

• WAN failover: for sites with fiber, choose a model with automatic wired-plus-cellular switching;

• VPN capability: full OpenVPN / IPsec support, ideally with one-click .ovpn config import;

• Interfaces: count Ethernet ports against on-site devices; keep a serial port for legacy equipment;

• Environmental resilience: in outdoor cabinets, wide temperature range, a hardware watchdog, and EMC protection are the baseline.

For the plant operator above, the deployment could split like this: at remote 4G-only sites, roll out compact 4G industrial routers in volume — for example, the USR-G806w, a Qualcomm-based router with 3 Ethernet ports and enhanced Wi-Fi, supporting OpenVPN / IPsec / GRE, connecting as a client to three different OpenVPN servers simultaneously, DIN-rail mounted, with wide-temperature operation and dual watchdogs for unattended sites; at sites with heavy bandwidth demands or wired-plus-5G dual links, use a 5G multi-port router like the USR-G816 — its built-in serial port connects data loggers directly, it supports automatic WAN failover, and it pushes real-time alerts for traffic overruns, offline devices, and weak signal.

Connecting PLC data to a remote SCADA system isn't about buying a "more advanced" router. It's about taking the link apart: segment the network, get the protocols right, encrypt the transport, and keep everything remotely manageable. Get all four right, and an ordinary industrial wireless router can support centralized monitoring across dozens of sites. Miss one, and even the most expensive device will fail you some night when nobody's watching.