Energy & Smart Grid

A parallel telemetry path that keeps operating when the grid 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.

The energy sector is undergoing its largest transformation in a century: decentralized generation, distributed energy resources, real-time grid balancing, and regulatory pressure on software supply-chain transparency. The data path connecting substations, DERs, smart meters, and control centers must remain predictable even when field conditions are not.

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 connectivity gaps and malfunctioning or compromised endpoints.

Market challenge

Energy operators and grid companies face compounding pressures:

• Grid decentralization: distributed energy resources (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 a growing endpoint population

Why traditional approaches break down

Legacy SCADA limitations

Runtime dependency problem

Dependency-heavy stacks 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

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

Supporting characteristics:

• Std-only core (zero third-party crates in Lite, twelve with TLS on Linux): few third-party components to patch across hundreds of remote substations
• 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: fits on constrained Linux field gateways beside substation RTUs
• 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:

Integrates with:

• SCADA platforms: grid-specific SCADA for transmission, distribution, and generation
• Energy protocols: DNP3 (native), Modbus (native); IEC 61850 via a third-party gateway publishing MQTT or Sparkplug B
• 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 grid sensors to control centers. RelayQ’s event-driven pub/sub replaces legacy polling, so operators see grid state as it is published, not minutes-old snapshots. Sparkplug B traffic with the wrong topic shape, namespace/version, or message type is rejected at ingress.

DER coordination and dispatch

Solar inverters, battery systems, and EV chargers publish generation/consumption data. RelayQ’s topic-level ACLs ensure DERs can only publish to their assigned topics. Dispatch commands toward DERs (curtailment, setpoints, reconnect) are opt-in, license-gated write-back. A misbehaving DER cannot impact other devices or the coordination system.

Substation automation

Protection relay status, breaker status, transformer telemetry, and environmental sensors report through RelayQ as a parallel telemetry copy. The system continues operating even when individual substations drop off the network.

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

EV chargers report session data, power delivery, faults, and availability. RelayQ handles 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

Compliance and certification readiness

RelayQ is not yet formally certified to these standards. It is designed with compliance readiness in mind; the engineering evidence maps 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, zero message loss (lab, x86_64, May 2026)
• ~580k msg/s QoS 0 throughput on a 2-core x86_64 lab laptop (~3,700 msg/s on a Raspberry Pi 3)
• Durability contract: an acknowledged QoS 1 message is written to disk before the acknowledgement, so a power loss after the acknowledgement does not lose it
• Under 10 MB on armv7: sized for substation-class Linux gateways

Expected operational improvements

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 Linux gateway alongside the existing RTU
2. Bridge legacy protocols: native DNP3 and Modbus, or a third-party IEC 61850 gateway publishing MQTT
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

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

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.