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
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
| Target | Architecture | Deployment |
|---|---|---|
| Pump station gateway | ARMv7, ARM64 | Static binary on embedded Linux |
| Treatment plant server | x86_64 | Docker container or systemd service |
| Reservoir/tank site | ARMv7 | Full build under 10 MB (or the smaller Lite build) on a solar-powered gateway |
| Central SCADA server | x86_64 | systemd 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
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 pilotJust want to test it first? Register for an access key to the Capped build: every feature, 10 connections, no time limit, no support.