Deterministic edge runtime for industrial data
One faulty device shouldn't take down your entire operation.
A flow meter locks up at one pump station. Today, the shared gateway queue backs up, SCADA goes stale across the site, and the historian has a gap you explain later. With RelayQ, that one station is flagged and every other reading keeps arriving.
- Fewer unplanned stops: a faulty device stays a local problem
- A complete data record through outages and restarts
- One component to license, patch and audit instead of four
- Runs on hardware you already own
RelayQ is a deterministic edge runtime that contains failures and replaces the protocol gateway, MQTT broker, integration layer and cloud connector. It sits between field devices and your SCADA, historian or cloud, isolates every device, and runs on hardware you already own.
Now selecting pilot sites for the v3.0 release.
Lab measurements on the current release candidate. Your results will differ, and the pilot is how you find out.
What “deterministic” means here: RelayQ responds the same documented way to each failure: a slow device, a malformed client, a restart, a power cut. It describes failure behavior, not a hard real-time timing guarantee.
What it means for your role
Plant / Operations
A stalled device stays a local problem, not a line-wide stop. Data keeps reaching the historian through outages, so the record has no gaps to explain.
CTO / Security / Compliance
One signed binary with a std-only core (no third-party crates in Lite, twelve with TLS on Linux): one thing to license, patch and put in front of an auditor, with an SBOM you can actually read.
OT / Platform Engineer
Native Modbus, DNP3, OPC UA and BACnet/IP ingestion alongside MQTT and Sparkplug B. Deploys beside existing SCADA without changing control logic.
Why edge stacks fail
A typical edge stack is four separate products between the field and the cloud, each with its own firmware, dependencies and update cycle.
Failures cascade.
One slow device backs up the pipeline for everything else.
Dependencies can't be audited.
Hundreds of transitive packages sit behind every component.
Cost compounds.
Four things to license, patch and keep compatible before a message reaches the cloud.
What RelayQ does
RelayQ sits between your field devices and your SCADA, historian or cloud, on hardware you already own.
Modbus, DNP3, OPC UA and BACnet/IP from PLCs and meters. MQTT and Sparkplug B from sensors and gateways. One data path for both.
Contains failures.
A slow or faulty device affects only itself.
Keeps data through outages.
Data is buffered locally and delivered when the link returns.
Replaces four components with one.
Protocol gateway, MQTT broker, integration layer and cloud connector in a single signed binary.
Works with what you have.
Modbus, DNP3, OPC UA, BACnet/IP, MQTT and Sparkplug B, on hardware you already own.
Runs without the cloud.
On-premise, with local rules and history, including air-gapped sites.
Built to be audited.
Signed releases and a tamper-evident audit log.
Designed around failure
What we test against
The behaviour on this page is exercised in the lab on every release candidate, not described from a design document. RelayQ is routinely tested under:
Device power loss
Mains cut to the node mid-run, then restored, with the data record compared before and after.
Network interruptions
Upstream link dropped and restored while devices keep publishing; buffered data is delivered when the link returns.
Process restarts
Runtime stopped and restarted with live sessions and queued messages, checked for loss and duplication.
Malformed protocol traffic
Fuzzed Modbus, DNP3, MQTT and Sparkplug B input that must be rejected without affecting other clients.
Slow and misbehaving clients
A client that stops reading or floods the runtime must not create back-pressure for anyone else.
Long-duration soak
Multi-hour runs under sustained load with memory, loss and journal counters watched throughout.
Full architecture and test evidence are shared with accepted pilot customers, and the pilot repeats these tests on your site.
Why RelayQ is different
The same job, done by a different kind of component.
| Conventional edge stack | RelayQ |
|---|---|
| Four separate products between the field and the cloud | One runtime, one config file |
| Shared pipeline: one stalled device backs up the rest | Each device isolated, failures contained |
| Multiple vendors, update cycles and support contracts | One signed binary, one upgrade path |
| Hundreds of transitive packages to audit | Std-only core: no third-party crates in the Lite build |
| Undocumented behaviour when something misbehaves | Documented response to each failure, tested every release |
The pilot
Prove it on one site in 30 days.
A pilot is one of your sites, one gateway and 30 days, running beside your existing system. Your team installs it with remote support from our engineers. No site visit is needed: RelayQ is one binary and one config file. Nothing in your control logic changes.
- 1
Scoping call.
We agree the site, the devices and what success looks like.
- 2
Install.
Your team installs RelayQ beside your existing SCADA, on hardware you already have, with our engineers on a call.
- 3
Run and test.
Real devices and real faults: pull the power, drop the network, compare the data record. We review the results with you remotely.
- 4
Written report.
You receive the results against the agreed success criteria.
- What you get
- One day of remote engineering support and the written report at no charge, plus a pilot license valid for up to 90 days.
- What we ask
- A real site, a named technical contact who can install and run it, the pilot's logs and metrics for the report, and honest feedback.
- Terms
- One pilot per customer. Support beyond the free day is billed on a time-and-materials basis under the pilot agreement. Further pilots or sites are covered by a separate agreement.
Who we're looking for
- Energy, water and industrial sites with mixed equipment: PLCs and meters on Modbus, DNP3, OPC UA or BACnet, plus MQTT sensors
- Sites that lose data or stop a line when one device or link fails
- System integrators with a client site in mind
- Edge hardware makers who want to embed a runtime in their product
Not a fit: Clusters beyond two nodes, cloud SaaS or multi-tenant hosting.
Test it under failure, not in a demo.
Tell us about your site and equipment. If it looks like a fit, we reply within one business day to set up a scoping call.
Developed by Precocity Research, Auckland, New Zealand. Founded by Zahir Alward.