Industrial IoT Integration for Water Utility SCADA
Water utilities run decades-old RTUs, Modicon and Allen-Bradley PLCs, and DNP3 outstations that cannot simply be replaced under a regulatory asset base. We sit our IoT gateways alongside that estate, speaking its native protocols upstream into your historian and cloud while adding the redundant links and alarm-escalation logic the legacy SCADA never had.
Challenges specific to Water Utilities
Legacy RTUs cannot be replaced wholesale
Pumping stations and chlorination sites run 15-to-25-year-old RTUs and PLCs inside the regulated asset base, so a single forced rip-and-replace is neither funded nor permitted, and any IoT layer must coexist with them in place.
DNP3 outstations time out on poor links
Master-to-outstation DNP3 polling over marginal cellular or radio backhaul drops integrity polls, so the SCADA master marks remote sites comms-failed and operators lose visibility of live reservoir and pump status for hours.
Historian and SCADA tags drift apart
When a new IoT broker is bolted on beside the existing SCADA, the two acquire the same point at different rates and scaling, so trends in the historian disagree with the operator HMI and nobody trusts either number.
Critical alarms never reach on-call staff
A high-high reservoir level or low chlorine residual raises a banner on an unmanned control-room screen at 3am, but with no escalation path the event sits unacknowledged until the morning shift, well past the regulatory response window.
Single backhaul link strands whole districts
A district metering area depends on one cellular APN or one leased line, so when that single path fails every outstation behind it goes dark at once and the utility loses an entire zone of telemetry with no automatic failover.
How GizanTech solves them
- In-place RTU and PLC tie-in. Our gateway connects to existing RTUs and PLCs over their live serial or Ethernet ports as a passive client, mirroring registers and DNP3 points without changing the master configuration, so the legacy SCADA keeps running untouched alongside the new IoT path.
- DNP3 and Modbus protocol bridging. We terminate DNP3 (serial and TCP) and Modbus from outstations at the gateway, normalise scaling and quality flags, and re-publish as MQTT or OPC UA, with local store-and-forward so a dropped integrity poll backfills instead of registering a comms fail.
- Unified historian and SCADA tag model. We define one canonical tag dictionary with agreed scaling, deadbands, and timestamps, feeding both the historian and SCADA from the same gateway acquisition, so HMI values and historian trends reconcile to the same engineering source.
- Tiered alarm escalation with acknowledgement. Critical events run a time-based escalation tree, paging on-call staff by SMS, voice, and app push and re-escalating to the next tier until acknowledged, with the full chain logged for regulatory evidence of response time.
- Redundant dual-WAN comms with failover. Each gateway carries primary plus diverse backup bearers (for example dual-SIM cellular with a private LTE or satellite fallback) and fails over sub-minute on link loss, so no single district backhaul outage blacks out a zone of telemetry.
| Integration point | Integration approach | Standard / protocol | Failure mode prevented |
|---|---|---|---|
| Existing RTU / PLC tie-in | Passive client mirrors live registers; master config untouched | Modbus RTU/TCP, EtherNet/IP, serial DNP3 | Forced rip-and-replace of regulated legacy outstations |
| Field protocol bridging | Terminate and normalise at gateway, re-publish northbound | DNP3 (serial + TCP) to MQTT / OPC UA | Dropped integrity polls falsely flagging sites comms-failed |
| Historian / SCADA acquisition | Single canonical tag model feeds both HMI and historian | OPC UA, IEC 60870-5-104, agreed deadbands | Historian trends disagreeing with operator HMI values |
| Alarm escalation | Time-tiered tree, re-escalate until acknowledged | SMS / voice / push, acknowledgement audit log | Critical 3am alarms sitting unread past response window |
| Redundant comms | Dual-bearer gateway, sub-minute automatic failover | Dual-SIM cellular + private LTE / satellite backup | One backhaul link stranding an entire district at once |
Go deeper
Industrial IoT Development for other industries
Frequently asked questions
Do we have to replace our existing SCADA and RTUs to add IoT?
No. Our gateways attach to your existing RTUs, PLCs, and DNP3 outstations as a passive client and bridge their data upward, so the legacy SCADA master keeps operating unchanged while the new historian and cloud layer run in parallel.
How do you stop the historian and the operator HMI from disagreeing?
We acquire each point once through the gateway against a single canonical tag dictionary, with one agreed scaling, deadband, and timestamp source feeding both the SCADA HMI and the historian, so the two never drift apart on the same physical measurement.
Can the integration prove alarm response times for the regulator?
Yes. The escalation engine logs every notification, retry, and acknowledgement with timestamps, so you have an auditable chain showing when a critical event was raised, who was paged, and exactly when it was acknowledged, which is what regulators ask for.
What happens to remote sites when the main backhaul link fails?
Each gateway runs primary plus diverse backup bearers and fails over automatically in under a minute, while store-and-forward buffers data locally during the switch, so a single cellular or leased-line outage does not black out a whole district of telemetry.
Does adding an IoT path increase the cyber-attack surface on our OT network?
We deploy the gateway in a segmented DMZ with an outbound-only, authenticated path to the cloud, so the legacy control network is never directly exposed; field protocol bridging is one-way northbound by default and reviewed against your OT security policy.