Water & Wastewater

A data path that keeps water telemetry consistent when infrastructure doesn't. RelayQ keeps telemetry and status data consistent across connectivity loss and misbehaving field devices at pump stations, treatment plants, and remote sites.

A data path that keeps water telemetry consistent when infrastructure doesn’t

RelayQ is a deterministic edge runtime for industrial data systems that brings industrial equipment (Modbus, DNP3, OPC UA, BACnet/IP) and IoT sensors (MQTT, Sparkplug B) into one data path.

Water and wastewater utilities operate vast, geographically dispersed infrastructure, pump stations, treatment plants, reservoirs, and remote sensors, connected over unreliable links. The data path in these networks must remain predictable even when field conditions are not.

Water infrastructure fails in the field

Pump stations lose power. Remote sensors go offline. Communication links drop without warning.

In traditional systems, these failures propagate: a malfunctioning sensor can corrupt downstream data, a stalled connection can delay status updates, and inconsistent state spreads across control systems.

RelayQ is designed to contain these failures. Each device is isolated. Each connection is strictly bounded. A stalled device affects only its own data path.

Market challenge

Water operators face compounding pressures:

  • Aging SCADA infrastructure being modernized with IP-based telemetry
  • NIS2 and critical infrastructure directives expanding cybersecurity obligations
  • Remote sites with constrained hardware, intermittent connectivity, and infrequent maintenance windows
  • Increasing regulatory scrutiny on water quality data integrity

Why this becomes expensive

Dependency-heavy stacks require ongoing patch management across dozens of remote sites that are difficult to access. When a CVE drops in OpenSSL or a transitive dependency, every pump station and treatment plant needs attention.

Weak message validation means malformed sensor traffic can propagate into downstream systems before anyone notices the data is wrong.

How RelayQ addresses it

  • Connectivity loss does not corrupt system state
  • Misbehaving devices cannot impact others
  • Resource usage remains bounded across distributed sites
  • No slow or disconnected site can stall the system
  • An acknowledged QoS 1 message is written to disk before the acknowledgement, so a power loss after the acknowledgement does not lose it

Supporting characteristics:

  • Std-only core (zero third-party crates in Lite, twelve with TLS on Linux): a small patch burden across remote sites
  • Native Modbus RTU/TCP and DNP3: direct connection to PLCs and RTUs without external gateways
  • Sparkplug B ingress validation: topic shape, namespace/version, and message type are enforced at ingress; payload-level validation is not yet wired
  • One binary under 10 MB: deploys on Linux field gateways beside existing RTUs

Where RelayQ fits in the water architecture

RelayQ in a water and wastewater site, inserted beside the existing SCADA

Field devices publish telemetry into RelayQ. SCADA hosts, historians, and control platforms subscribe to the topics they need. RelayQ does not replace your control platform; it runs alongside it, containing failure and validating every message before delivery.

Integrates with:

  • SCADA platforms: water and wastewater SCADA for distribution and treatment
  • Field protocols: Modbus RTU/TCP (native), DNP3 (native)
  • Historians: OSIsoft PI, InfluxDB, TimescaleDB
  • Cloud platforms: AWS IoT Core (via MQTT bridge, validated); Azure IoT Hub via the bridge’s X.509 path only (unvalidated; no SAS-token support)
  • Monitoring: Prometheus + Grafana, utility NOC dashboards

What data is exchanged, and why correctness matters

  • Flow and pressure telemetry: drives hydraulic models and leak detection.
  • Water quality metrics (chlorine residual, turbidity, pH): supports regulatory reporting.
  • Pump and valve status: informs maintenance scheduling and operator visibility.
  • Event messages: inform operator response for overflow, contamination, or equipment failure.
  • Remote commands (pump start/stop, valve actuation): opt-in, license-gated write-back.

Corrupted or delayed water quality data can mask contamination events. Data integrity at the data path directly affects regulatory reporting and operator decisions.

Deployment options

TargetArchitectureDeployment
Pump station gatewayARMv7, ARM64Static binary on embedded Linux
Treatment plant serverx86_64Docker container or systemd service
Reservoir/tank siteARMv7Full build under 10 MB (or the smaller Lite build) on a solar-powered gateway
Central SCADA serverx86_64systemd service on Ubuntu/RHEL/Debian

All deployments are a single static binary, no runtime, no interpreter, no shared libraries required.

What teams gain

  • Faster isolation when sensors or stations misbehave
  • Reduced risk of bad data affecting regulatory reporting
  • Lower maintenance burden across geographically dispersed sites
  • Simpler compliance posture for critical infrastructure audits

Apply for a pilot →

Proof points are lab measurements on the stated hardware and build; results in your environment will differ. Method and full test evidence are shared with pilot customers.

Test it under failure, not in a demo.

One of your sites, one gateway, 30 days, with remote support from our engineers.

Apply for a pilot

Just want to test it first? Register for an access key to the Capped build: every feature, 10 connections, no time limit, no support.