Railway & Transportation

A non-vital telemetry path that keeps operating under failure conditions

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.

Railway networks are among the most demanding environments for communication software: geographically distributed, subject to harsh conditions, and expected to operate for decades. The telemetry path connecting trains, trackside infrastructure, and operations centers must remain predictable even when field conditions are not. RelayQ carries a non-vital telemetry copy of signalling status and never sits in the path to interlocking logic. It is not a safety-rated component.

Railway systems fail in the field

Trackside equipment loses power. Communication links drop between train and operations center. Onboard systems restart during operation.

In traditional messaging systems, these failures propagate: state becomes inconsistent, delayed or malformed messages reach downstream systems, and unrelated components are affected by a single fault.

RelayQ is designed to contain these failures. Each device is isolated. Each connection is strictly bounded. The system continues operating across restarts, connectivity gaps, and misbehaving components.

Market challenge

Rail operators and system integrators face a unique combination of pressures:

• Multi-decade platform lifecycles: every software component becomes a long-term maintenance obligation
• Harsh field environments: power interruptions, vibration, temperature extremes, and intermittent connectivity are routine
• Regulatory compliance: EN 50128, EN 50129, IEC 62278 (RAMS), and emerging cybersecurity directives (NIS2, CER)
• Legacy integration: decades-old signalling and SCADA systems must coexist with modern IoT infrastructure

Why dependency-heavy stacks break down in rail

Unlike traditional MQTT broker stacks, RelayQ does not carry a long-tail dependency maintenance risk across multi-decade service contracts, fits on constrained trackside and onboard hardware, and keeps the SBOM small enough that it does not expand sustainment cost year after year. More importantly, traditional stacks do not control how failures propagate across trackside, onboard, and operations systems.

How RelayQ addresses railway 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 devices cannot impact others
• Resource usage remains bounded across distributed systems
• No slow or failing component 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 maintain over the platform lifetime
• Deterministic behavior: thread-per-client model with no garbage collector, no async jitter
• One binary under 10 MB: fits on constrained trackside Linux controllers and onboard gateways
• Sparkplug B ingress validation: topic shape, namespace/version, and message type are enforced at ingress; payload-level validation is not yet wired
• Memory-safe (Rust): eliminates buffer overflows in the telemetry path

Where RelayQ fits in the railway architecture

RelayQ runs alongside your existing rail SCADA and signalling infrastructure, not inside it. Your control path (trackside equipment → interlocking → Rail SCADA → Historian) remains untouched; RelayQ never sits in the path to interlocking logic.

RelayQ receives a non-vital telemetry copy from trackside sensors and onboard systems, providing a parallel path for fleet analytics, predictive maintenance, and cross-depot visibility.

RelayQ operates at three levels:

Integrates with:

• Signalling status: non-vital telemetry copy from axle counters, track circuits, and point machines, via a third-party gateway publishing MQTT or Sparkplug B
• Train control (CBTC, ETCS): non-vital telemetry copies only, via a third-party gateway publishing MQTT
• SCADA platforms: rail-specific SCADA for traction power, station systems
• Communication networks: GSM-R, LTE-R, FRMCS backhaul (as application-layer runtime)
• Historians and analytics: InfluxDB, TimescaleDB, predictive maintenance platforms
• Legacy systems: serial-to-MQTT gateways for older trackside equipment

Railway use cases

Signalling status telemetry

Track circuits, axle counters, and point machines report to the interlocking as they do today. A non-vital copy of that status reaches RelayQ for maintenance analytics and operations visibility. Default-deny ACLs ensure only authorized trackside devices publish to those topics. A misbehaving device cannot affect unrelated telemetry. RelayQ never sits in the path to interlocking logic.

Rolling stock health monitoring

Onboard sensors stream brake condition, door status, HVAC performance, and traction diagnostics to maintenance systems. RelayQ buffers messages to disk during tunnel transits and 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, not a zero-data-loss guarantee.

Station infrastructure monitoring

Platform screen doors, escalators, CCTV systems, and environmental sensors publish status via MQTT. RelayQ’s rate limiting prevents a malfunctioning sensor from flooding the bus and delaying status messages from other station systems.

Predictive maintenance data pipelines

Vibration, temperature, and wear data from wheels, bogies, and track components feeds machine learning models for predictive maintenance. RelayQ keeps data integrity at ingress, since corrupted inputs produce unreliable predictions.

Train-to-ground telemetry

Position, speed, and operational status flow from train to operations center as telemetry. RelayQ’s deterministic latency and persistence give consistent delivery across high-mobility, intermittent-connectivity environments. No disconnected train can stall the central ingestion pipeline.

Security mapped to railway threats

Compliance and certification readiness

RelayQ is not yet formally certified to these standards and is not a safety-rated component. It is designed with certification readiness in mind; the engineering evidence (Kani proof harnesses, Loom concurrency models, fuzz testing, 4,902 spec-traceable tests) maps to certification objectives.

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)
• 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: runs on Raspberry Pi 3B/3B+ class hardware

Expected operational improvements

Legacy integration

RelayQ does not require replacing existing signalling or SCADA infrastructure. It deploys incrementally:

1. Start at the edge: install on one trackside cabinet or onboard gateway
2. Bridge legacy systems: use serial-to-MQTT or Modbus-to-MQTT gateways for older equipment
3. Validate alongside existing infrastructure: run in parallel without disrupting operations
4. Expand gradually: add more nodes 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.