Ask any SCADA or OT manager responsible for a distributed network of pumping stations how often their team discovers a gap in the historian, and the answer is rarely reassuring. Data loss at remote sites is one of the most persistent, least discussed problems in water and wastewater telemetry. It rarely makes headlines the way a cyber incident does, yet it quietly erodes the reliability of the reporting utilities depend on for compliance, energy optimization, and asset management.
The reason is structural. Remote pumping stations sit at the end of communication links utilities do not fully control - shared cellular networks, radio paths affected by terrain, leased lines with limited redundancy. Traditional SCADA assumes a link available on demand. When it isn't, the data disappears with it.
The Challenge: When Communications Fail
Outages are not an edge case - they are a recurring operating condition. A lift station can lose its cellular or radio link due to equipment failure or a carrier-side outage; restoring it can take anywhere from hours to over a week at harder-to-reach sites. Every reading during that window - flow, level, pressure, pump status - is lost unless it was stored locally.
A second, subtler scenario is network congestion: pumping stations increasingly share commercial 4G/LTE infrastructure with the public, and during peak demand the same cell tower serving residential traffic deprioritizes or drops telemetry intermittently. This produces irregular data loss that is often misread as a sensor fault rather than a capacity issue.
Both share the same root cause: a polling architecture has no memory. If the host can't reach the device at the moment it asks, that point is gone. Across dozens or hundreds of stations, the cumulative effect on reporting completeness and data integrity is significant.
Technologies and Best Practice
Store-and-forward at the edge. The most effective change is buffering data locally at the field gateway or RTU, independent of uplink availability. When the connection returns, buffered data backfills the historian in correct time sequence - turning a week-long outage into delayed delivery rather than a permanent gap.
Report-by-exception (RBE). Classical polling asks every device for every point on a fixed cycle regardless of change, wasting bandwidth and adding latency. MQTT-based RBE publishes a value only when it changes beyond a deadband. Sparkplug B, the open specification hosted by the Eclipse Foundation, adds a defined topic namespace, compact payload, and session-state model (birth/death certificates) on top of MQTT. Per the Eclipse Foundation, properly implemented RBE reduces bandwidth consumption by roughly 80–95% versus continuous polling, while giving the host positive confirmation of device online/offline state. [1][2]
Protocol selection. OPC UA remains strong for wired, plant-level integration, with a rich information model and built-in security. It is comparatively heavier over constrained wireless links, which is why MQTT/Sparkplug B - designed from the outset for real-time SCADA over unreliable, bandwidth-limited networks - is the more common pattern for wide-area telemetry. [2] Practical rule: OPC UA where wired and unmetered; MQTT/Sparkplug B where wireless and metered.
Protocol conversion for legacy PLCs. Few utilities can justify replacing functioning PLCs to modernize telemetry. Edge gateways like Red Lion FlexEdge can read a PLC's native tag database directly (e.g., importing an Allen-Bradley L5K export over EtherNet/IP) or support legacy serial protocols like DF1 or DH-485 - allowing a 15–20-year-old PLC to integrate without a control system replacement.
Redundant communications. For critical or hard-to-access sites, automatic failover between primary and secondary paths (dual-carrier cellular, radio, satellite) further reduces exposure. Combined with edge buffering, the goal shifts from preventing every outage to guaranteeing no data is permanently lost.
Security by design. Expanded remote connectivity expands the attack surface. The 2021 Oldsmar, Florida incident - where an attacker used a remote access tool to attempt to alter chemical dosing - remains a widely cited reminder that remote access must be deliberately architected. [3] IEC 62443 provides the lifecycle framework (zones, conduits, security levels) for securing SCADA systems in geographically dispersed operations like water networks. [4] For EU utilities, the NIS2 Directive (EU 2022/2555) classifies drinking water and wastewater as essential-entity sectors, with mandatory risk management and incident reporting (24-hour initial notice, 72-hour report, one-month final report). [5]
Conclusions
Data loss at remote pumping stations is an architectural problem, not a hardware one. Polling-based SCADA was never designed to tolerate the intermittent, sometimes extended, communication interruptions that come with cellular- and radio-connected remote assets. Local buffering, report-by-exception messaging, and protocol conversion that respects the installed PLC base close that gap without wholesale infrastructure replacement - layered with a security posture aligned to IEC 62443 and, where applicable, NIS2. For teams under pressure to modernize while controlling capital spend, that combination is a practical path forward, not a future aspiration.
________________________________________________________________________________________________________________________________
References
1. Eclipse Foundation, "Sparkplug," projects.eclipse.org: https://projects.eclipse.org/projects/iot.sparkplug
2. Eclipse Foundation, "The Sparkplug Specification," sparkplug.eclipse.org: https://sparkplug.eclipse.org/specification/
3. 2021 Oldsmar, FL water treatment facility remote-access incident (widely reported by CISA and industry cybersecurity analyses)
4. IEC, "IEC 62443" series overview: https://www.iec.ch/taxonomy/term/778 (origin: ISA99 committee)
5. European Union, Directive (EU) 2022/2555 (NIS2): https://www.enisa.europa.eu/taxonomy/term/528
