Energy & Smart Grid

Messaging that keeps the grid operating when conditions don't. RelayQ ensures telemetry, control, and coordination systems remain consistent across power events, connectivity loss, and misbehaving or compromised field devices.

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 SCADAModern MQTT (RelayQ)
Polling-based (seconds to minutes)Event-driven, real-time publish/subscribe
Point-to-point, siloedMany-to-many, unified data fabric
Proprietary protocolsOpen standard (MQTT 3.1.1)
Difficult to scaleLightweight, scales to millions of endpoints
Limited visibilityFull 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 in the energy grid 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:

RoleWhere it runsWhat it does
Substation runtimeRTU or gateway (ARMv7/ARM64)Reads sensor data via DNP3/Modbus, buffers during connectivity gaps
DER aggregation runtimeEdge server (ARM64)Aggregates solar, battery, EV charger telemetry
Central platformOn-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 threatHow RelayQ mitigates
Grid disruption via malicious control messagesDefault-deny ACL, only authorized SCADA can publish to control topics
Compromised smart meter flooding the systemPer-client rate limiting caps message volume per device
Supply-chain attack on broker dependenciesZero mandatory dependencies, std-only core, no async runtime, no OpenSSL
Substation gateway compromiseIP allowlist + mTLS, only known endpoints connect
Nation-state attack on grid communicationsMinimal attack surface (std-only core, ~4.6MB Full build (x86_64; ~3.6MB armv7)) + audit logging for forensics
Data manipulation affecting grid balancingSparkplug validation rejects malformed topics and out-of-sequence lifecycle messages at ingress

Compliance and certification readiness

StandardRelayQ 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

OutcomeHow
Reduced grid outage impactReal-time fault detection replaces minutes-old polling data
Lower maintenance cost across remote sitesZero mandatory dependencies = minimal patching across hundreds of substations
Faster regulatory complianceOne-line SBOM, audit logging, access control by design
Improved DER coordinationReal-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 visibilityEvent-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:

  1. Start at one substation: install on a single gateway alongside existing RTU
  2. Bridge legacy protocols: use IEC 61850-to-MQTT gateways, or native DNP3 and Modbus-to-MQTT translation
  3. Run in parallel: validate data quality without disrupting existing SCADA operations
  4. 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

TargetArchitectureDeployment
Substation gatewayARMv7, ARM64Static binary on hardened Linux
Control centerx86_64Docker container or systemd service
DER aggregatorARM64, x86_64Bare binary with WAL persistence
Remote site RTUARMv7~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.


Request evaluation access →

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 Access

Not ready to talk? Start with the evidence: conformance report · benchmarks