Messaging that keeps the grid operating when conditions don’t
The energy sector is undergoing its largest transformation in a century: decentralized generation, millions of distributed energy resources, real-time grid balancing, and regulatory pressure on software supply-chain transparency. The messaging layer connecting substations, DERs, smart meters, and control centers must remain predictable even when field conditions are not.
RelayQ ensures telemetry, control, and coordination systems remain consistent across power events, connectivity loss, and misbehaving or compromised field devices.
Grid systems fail in unpredictable ways
Field sites lose power. Substations disconnect. Smart meters misbehave. Communication links drop across large geographic areas.
In traditional grid architectures, these failures propagate: a compromised device can flood the system, inconsistent state spreads, and operators lose visibility at precisely the wrong moment.
RelayQ is designed to contain these failures.
Each device is isolated. Each connection is strictly bounded. The system continues operating across power events, connectivity gaps, and malfunctioning or compromised endpoints.
No cascading failure. No system-wide disruption.
Failure remains contained, by design.
The system behaves predictably even when the grid does not.
Market challenge
Energy operators and grid companies face compounding pressures:
- Grid decentralization: millions of DERs (solar, batteries, EVs) require real-time coordination
- Critical infrastructure regulation: NIS2, CRA, NERC CIP, and IEC 62351 demand provable software security
- Legacy SCADA limitations: polling-based systems can’t keep pace with real-time grid dynamics
- Remote, harsh environments: substations and field assets operate with intermittent connectivity and limited maintenance access
- Scale: smart meters, EV chargers, and grid sensors generate high-frequency telemetry across millions of endpoints
At the same time, field devices behave unpredictably, and traditional messaging layers do not isolate these failures.
Why traditional approaches break down
Legacy SCADA limitations
| Legacy SCADA | Modern MQTT (RelayQ) |
|---|---|
| Polling-based (seconds to minutes) | Event-driven, real-time publish/subscribe |
| Point-to-point, siloed | Many-to-many, unified data fabric |
| Proprietary protocols | Open standard (MQTT 3.1.1) |
| Difficult to scale | Lightweight, scales to millions of endpoints |
| Limited visibility | Full observability via Prometheus metrics |
Broker dependency problem
Dependency-heavy brokers (200+ packages) create lifecycle burden that multiplies across hundreds of substations and field sites:
- Every CVE requires coordinated patching across remote, hard-to-access locations
- Complex SBOMs expand NIS2/NERC CIP audit scope
- Large container images don’t fit on constrained substation gateways
- Patch windows disrupt grid operations
More importantly, traditional systems do not control how failures propagate across substations, devices, and control systems.
How RelayQ addresses energy requirements
RelayQ enforces controlled behavior under real-world grid conditions:
- Power loss does not result in message loss
- Connectivity loss does not corrupt system state
- Misbehaving or compromised devices cannot impact others
- Resource usage remains bounded across thousands of endpoints
- The system remains predictable under load and failure conditions
- No slow, failing, or compromised device can stall the system
Supporting characteristics:
- Zero mandatory dependencies (std-only core; TLS optional): nothing to patch across hundreds of remote substations
- Sparkplug-aware validation: rejects malformed topics and out-of-sequence node/device lifecycle messages at ingress
- WAL persistence: messages survive power loss at unattended field sites
- ~4.6MB Full build (x86_64; ~3.6MB armv7): fits on constrained substation RTUs and field gateways
- Rate limiting + OOM guard: prevents compromised or malfunctioning meters from flooding the grid bus
- Default-deny ACL: segments DER traffic from control traffic from metering traffic
Where RelayQ fits in the energy architecture

RelayQ runs alongside your existing grid SCADA infrastructure, not inside it. Your brownfield control path (RTUs → Substation SCADA → Grid SCADA/EMS → Historian) remains untouched.
RelayQ reads from the same RTUs and IEDs via DNP3 and Modbus, providing a parallel telemetry path for cross-site visibility, DER coordination, predictive maintenance, and remote operations.
RelayQ operates at three levels:
| Role | Where it runs | What it does |
|---|---|---|
| Substation runtime | RTU or gateway (ARMv7/ARM64) | Reads sensor data via DNP3/Modbus, buffers during connectivity gaps |
| DER aggregation runtime | Edge server (ARM64) | Aggregates solar, battery, EV charger telemetry |
| Central platform | On-prem server (x86_64) | Aggregates substation and DER telemetry, bridges to remote operations |
Integrates with:
- SCADA platforms: grid-specific SCADA for transmission, distribution, and generation
- Energy protocols: IEC 61850 (via gateway), DNP3 (native), Modbus (native)
- DER management systems: solar inverter controllers, battery management, EV aggregators
- Smart metering: AMI head-end systems (via MQTT bridge)
- 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); any MQTT 3.1.1 endpoint (the bridge cannot negotiate MQTT 5.0 with an upstream)
- Analytics: InfluxDB, TimescaleDB, PI System, predictive maintenance platforms
- Monitoring: Prometheus + Grafana, utility NOC dashboards
Energy use cases
Smart grid real-time monitoring
Voltage, frequency, power flow, and fault indicators stream from thousands of grid sensors to control centers. RelayQ’s event-driven pub/sub replaces legacy polling, operators see grid state in real time, not minutes-old snapshots. Sparkplug validation rejects malformed topics and out-of-sequence lifecycle messages before they reach grid control logic. No data loss during power events or connectivity interruptions.
DER coordination and dispatch
Solar inverters, battery systems, and EV chargers publish generation/consumption data and receive dispatch commands (curtailment, setpoints, reconnect). RelayQ’s topic-level ACLs ensure DERs can only publish to their assigned topics and only receive commands from authorized aggregators. A misbehaving DER cannot impact other devices or the coordination system.
Substation automation
Protection relays, breaker status, transformer telemetry, and environmental sensors report through RelayQ. WAL persistence ensures no data loss during power events, critical for post-fault analysis and regulatory evidence. The system continues operating even when individual substations lose power.
Pipeline and remote asset monitoring
Oil and gas pipelines, remote pump stations, and offshore platforms publish pressure, flow, and vibration data over satellite or cellular links. RelayQ buffers messages to disk during connectivity gaps and replays them when backhaul resumes; the bridge’s connection-liveness detection and delivery guarantees are still being hardened, so treat this as buffered best-effort delivery today. No slow or disconnected remote site can stall the central ingestion pipeline.
EV charging network management
Thousands of EV chargers report session data, power delivery, faults, and availability. RelayQ handles high-frequency telemetry from geographically distributed chargers without requiring heavy infrastructure at each site. A misbehaving charger cannot impact other sessions or the fleet backend.
Security mapped to energy threats
| Energy threat | How RelayQ mitigates |
|---|---|
| Grid disruption via malicious control messages | Default-deny ACL, only authorized SCADA can publish to control topics |
| Compromised smart meter flooding the system | Per-client rate limiting caps message volume per device |
| Supply-chain attack on broker dependencies | Zero mandatory dependencies, std-only core, no async runtime, no OpenSSL |
| Substation gateway compromise | IP allowlist + mTLS, only known endpoints connect |
| Nation-state attack on grid communications | Minimal attack surface (std-only core, ~4.6MB Full build (x86_64; ~3.6MB armv7)) + audit logging for forensics |
| Data manipulation affecting grid balancing | Sparkplug validation rejects malformed topics and out-of-sequence lifecycle messages at ingress |
Compliance and certification readiness
| Standard | RelayQ positioning |
|---|---|
| IEC 62351 (Power systems security) | TLS 1.3, mTLS, role-based access control, audit logging |
| IEC 62443 (Industrial cybersecurity) | Zero-dependency SBOM, default-deny ACL, brute-force protection |
| NERC CIP (North America) | Minimal attack surface, access control, audit trail, incident-ready logging |
| NIS2 / CER (EU) | Supply-chain transparency, security-by-design, incident response readiness |
| IEC 61850 (Substations) | Complementary, RelayQ bridges IEC 61850 data to MQTT for wider distribution |
RelayQ is not yet formally certified to these standards. It is designed with compliance readiness in mind, the engineering evidence maps directly to audit requirements.
Proof points
- 6 million fuzz inputs, zero panics: codec hardened against malformed packets from any source
- 4,902 automated tests: traced to the protocol specifications, with per-requirement conformance reports
- Six 1-hour soak runs: sustained QoS 0/1/2 load with zero message loss (simulates grid-scale ingestion)
- ~580k msg/s QoS 0 throughput on a 2-core x86_64 lab laptop (~3,700 msg/s on a Raspberry Pi 3): high-frequency telemetry from thousands of endpoints
- WAL recovery after hard power cut: zero message loss across simulated substation power failures
- ~3.6MB Full build on ARMv7: sized for substation-class gateway hardware
Expected operational improvements
| Outcome | How |
|---|---|
| Reduced grid outage impact | Real-time fault detection replaces minutes-old polling data |
| Lower maintenance cost across remote sites | Zero mandatory dependencies = minimal patching across hundreds of substations |
| Faster regulatory compliance | One-line SBOM, audit logging, access control by design |
| Improved DER coordination | Real-time pub/sub enables faster dispatch and balancing response |
| Lower infrastructure cost at the edge | ~4.6MB Full build (x86_64; ~3.6MB armv7) runs on existing RTUs, no hardware upgrades |
| Better grid visibility | Event-driven telemetry + Prometheus metrics provide real-time operational dashboards |
Legacy integration
RelayQ does not require replacing existing SCADA or energy management systems. It deploys incrementally:
- Start at one substation: install on a single gateway alongside existing RTU
- Bridge legacy protocols: use IEC 61850-to-MQTT gateways, or native DNP3 and Modbus-to-MQTT translation
- Run in parallel: validate data quality without disrupting existing SCADA operations
- Expand gradually: add more substations and field sites as confidence builds
No big-bang migration. No vendor lock-in. RelayQ is a single binary you can deploy, test, and remove without side effects.
Deployment options
| Target | Architecture | Deployment |
|---|---|---|
| Substation gateway | ARMv7, ARM64 | Static binary on hardened Linux |
| Control center | x86_64 | Docker container or systemd service |
| DER aggregator | ARM64, x86_64 | Bare binary with WAL persistence |
| Remote site RTU | ARMv7 | ~3.6MB Full build (or ~1.0MB Lite) on constrained Linux |
All deployments are a single static binary, no runtime, no interpreter, no shared libraries required.
Systems that behave predictably under failure, not just under ideal conditions.
Proof points are lab measurements on the stated hardware and build, see the benchmarks page for method. Results in your environment will differ.
Ready to evaluate RelayQ?
Full-featured runtime. No credit card. Direct support.
Request Evaluation AccessNot ready to talk? Start with the evidence: conformance report · benchmarks