Industrial Automation

Prevent bad data — and prevent it from spreading

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

RelayQ ensures malformed, stale, or misbehaving data never impacts the rest of your system.

Industrial systems fail unpredictably

Devices disconnect. Sensors misbehave. Networks drop packets.

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

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.

No cascading failure. No system-wide stalls.

Failure remains contained — by design.

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.

At the same time, edge devices behave unpredictably — and traditional brokers do not isolate that risk.

Why this becomes expensive

When a runtime forwards invalid topic structures, stale sessions, or sequence errors, 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.

In many deployments, one misbehaving device can affect unrelated systems by saturating the runtime or introducing inconsistent state.

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

The business impact:

• Unplanned downtime from false alarms or missed alarms
• Engineering hours spent tracing data quality issues back to the messaging layer
• Audit cycles that stretch from weeks to months because of complex SBOMs
• Patch windows that disrupt production schedules

Why typical MQTT runtimes fall short

Most MQTT runtimes treat transport as neutral infrastructure. They forward messages, regardless of correctness or behavior.

In industrial environments, this means:

• Invalid data is trusted downstream
• Misbehaving devices impact unrelated systems
• Failure propagates across the pipeline

RelayQ enforces validation, isolation, and bounded behavior at ingress — where it matters.

How RelayQ addresses it

RelayQ changes how the system behaves under failure at ingress:

• Invalid or stale messages are rejected before entering the system
• Each client is isolated — one device cannot impact others
• Noisy devices are bounded and cannot stall the system
• Message state remains consistent across restarts
• 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. Failures in the RelayQ path never affect your control systems. Failures in your control systems never affect RelayQ.

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, Azure IoT Hub (via MQTT bridge)
• Monitoring: Prometheus + Grafana, Datadog, Zabbix

Real-world scenarios

Scenario 1: Sparkplug validation prevents false alarm

A temperature sensor crashes and restarts without sending NDEATH. The old Will message arrives after the new NBIRTH. Without validation, your SCADA host marks the sensor offline — triggering a false alarm and an operator response.

With RelayQ: the stale NDEATH is rejected at ingress. SCADA correctly shows the sensor online. No false alarm, no wasted operator time. The system remains consistent despite incorrect message sequencing.

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 critical alarm messages from other devices.

With RelayQ: per-client rate limiting caps the noisy device. Other devices continue publishing normally. The system continues operating under load without degradation. The issue is logged and flagged via Prometheus metrics.

Scenario 3: Faster IEC 62443 audit

Your customer’s security team requests the SBOM for every component in your OT network. For the MQTT runtime, you provide a one-line document. The review takes minutes instead of weeks. No transitive dependencies to chase, no OpenSSL CVE history to explain.

What data is exchanged — and why correctness matters

RelayQ validates data at ingress to ensure downstream systems operate on reliable state.

• Device birth/death certificates: establish trusted online/offline state.
• Telemetry metrics (temperature, pressure, vibration, counters): drive control logic and operational dashboards.
• Alarm/event messages: trigger human and automated responses quickly.
• Command/control messages: execute remote setpoints and actuation safely.

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.

Measured 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

Systems that behave predictably under failure — not just under ideal conditions.

Request evaluation access →