Industrial Automation

Prevent bad data, and prevent it from spreading

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.

Modern factories connect PLCs, SCADA hosts, historians, and edge gateways over MQTT and field protocols. But most teams still treat the runtime as neutral transport, even when malformed traffic, misbehaving devices, or cascading failures can silently corrupt operations.

Industrial systems fail unpredictably

Devices disconnect. Sensors misbehave. Networks drop packets.

In most industrial deployments, these failures propagate: a single misbehaving device can flood the runtime, corrupt state, or delay messages from other devices.

RelayQ is designed to contain these failures. Each device is isolated. Each client is strictly bounded. The system continues operating even when parts of it do not.

Market challenge

Industrial operators are under pressure from three directions at once:

• Legacy infrastructure and modern edge systems must coexist.
• Uptime targets are tighter, while plant complexity keeps rising.
• IEC 62443 and customer audits demand clearer software risk control.

Why this becomes expensive

When a runtime forwards invalid topic structures or stale sessions, your SCADA layer sees bad data as if it were valid. Teams then spend time debugging symptoms in dashboards and control logic, instead of preventing the problem at ingress.

Dependency-heavy software stacks increase SBOM reviews, patch windows, and change-management overhead across OT environments that already move slowly by design.

Why a stacked gateway, messaging and integration layer falls short

A protocol gateway, a separate messaging layer, and an integration layer each treat transport as neutral infrastructure. They forward messages regardless of correctness or behavior, so invalid data is trusted downstream, misbehaving devices impact unrelated systems, and failure propagates across the pipeline.

RelayQ enforces validation, isolation, and bounded behavior at ingress, in one runtime, where it matters.

How RelayQ addresses it

• Sparkplug B traffic with the wrong topic shape, namespace/version, or message type is rejected at ingress (payload-level validation is not yet wired)
• Each client is isolated, one device cannot impact others
• Noisy devices are bounded and cannot 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
• The runtime stays small, auditable, and predictable

Where RelayQ fits in your IIoT architecture

RelayQ runs alongside your existing SCADA infrastructure, not inside it. Your brownfield control path (PLCs → SCADA → Historian) remains untouched.

RelayQ reads from the same PLCs and edge gateways via Modbus, OPC UA, or MQTT, providing a parallel telemetry path for cross-site visibility, cloud analytics, and remote operations. RelayQ runs alongside your control systems; a stalled device affects only its own data path.

Integrates with:

• SCADA platforms: Ignition, FactoryTalk, WinCC, AVEVA
• Historians: OSIsoft PI, InfluxDB, TimescaleDB
• Edge gateways: Advantech, Moxa, Hilscher, Raspberry Pi
• Cloud integration: 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, Datadog, Zabbix

Real-world scenarios

Scenario 1: Sparkplug validation stops malformed traffic at ingress

A misconfigured edge node publishes Sparkplug messages under the wrong namespace version and with an unknown message type. Without validation, your SCADA host receives traffic it cannot interpret and either discards it silently or raises spurious data-quality flags.

With RelayQ: topic shape, namespace/version, and message type are enforced at ingress, and the malformed traffic is rejected before it enters the system. SCADA sees only well-formed Sparkplug B traffic. The rejection is counted and visible in metrics, so the misconfiguration is found at the source.

Scenario 2: Noisy device doesn’t flood the bus

A misconfigured vibration sensor publishes 10,000 messages per second instead of 10. Without rate limiting, it saturates the runtime and delays messages from other devices.

With RelayQ: per-client rate limiting caps the noisy device. Other devices continue publishing normally. The issue is logged and flagged via Prometheus metrics.

Scenario 3: A shorter IEC 62443 SBOM review

Your customer’s security team requests the SBOM for every component in your OT network. For RelayQ, the non-TLS build has no third-party crates; the TLS build adds rustls. No transitive dependency tree to chase, no OpenSSL CVE history to explain.

What data is exchanged, and why correctness matters

• Device birth/death certificates: establish online/offline state.
• Telemetry metrics (temperature, pressure, vibration, counters): drive operational dashboards and analytics.
• Event messages: inform human and automated responses.
• Command/control messages (remote setpoints, actuation): opt-in, license-gated write-back.

Invalid telemetry or stale session state can create false decisions in SCADA and quality systems. Data validation at ingress reduces downstream operational risk.

Deployment options

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

Expected operational improvements

What teams gain

• Fewer telemetry integrity incidents reaching SCADA
• Faster incident isolation when devices misbehave
• Lower long-term maintenance burden in regulated OT fleets
• More confidence during compliance and customer 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.