Railway & Transportation

Messaging that keeps rail systems operating under failure conditions

Railway networks are among the most demanding environments for communication software: geographically distributed, safety-critical, subject to harsh conditions, and expected to operate for decades. The messaging layer connecting trains, trackside infrastructure, and control centers must remain predictable even when field conditions are not.

RelayQ ensures telemetry, signaling support, and control data remain consistent across power cycles, connectivity loss, and misbehaving trackside or onboard systems.

Railway systems fail in the field

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

In traditional messaging systems, these failures propagate: state becomes inconsistent, delayed or malformed messages reach control 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 power cycles, connectivity gaps, and misbehaving components.

No cascading failure. No system-wide disruption.

Failure remains contained — by design.

The system behaves predictably even when the railway environment does not.

Market challenge

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

• Safety above all — messaging failures in signaling or train control can endanger passengers
• 20–30 year 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 signaling and SCADA systems must coexist with modern IoT infrastructure

At the same time, trackside and onboard systems behave unpredictably — and traditional messaging layers do not isolate these failures.

Why traditional brokers break down in rail

• Dependency-heavy stacks create long-tail maintenance risk across 20+ year service contracts
• Large container images (200MB+) don’t fit on constrained trackside or onboard hardware
• No ingress validation means malformed messages can propagate to safety-adjacent systems
• Slow startup and weak persistence turn routine power cycles into service instability
• Complex SBOMs expand certification scope and sustainment cost year after year

More importantly, traditional brokers do not control how failures propagate across trackside, onboard, and control systems.

How RelayQ addresses railway requirements

RelayQ enforces controlled behavior under real-world railway conditions:

• Power cycles do not result in data loss
• Connectivity loss does not corrupt system state
• Misbehaving devices cannot impact others
• Resource usage remains bounded across distributed systems
• The system remains predictable under load and failure conditions
• No slow or failing component can stall the system

Supporting characteristics:

• Zero dependencies (non-TLS) — nothing to maintain, patch, or re-certify over 20+ years
• WAL persistence — messages survive power loss at trackside cabinets and onboard systems
• <50ms cold start — ready before train systems finish initializing after power cycle
• Deterministic behavior — thread-per-client model with no garbage collector, no async jitter
• <1MB binary — fits on constrained trackside controllers and onboard gateways
• Sparkplug-aware validation — prevents malformed telemetry from reaching control systems
• Memory-safe (Rust) — eliminates buffer overflows in a safety-adjacent communication path

Where RelayQ fits in the railway architecture

RelayQ runs alongside your existing rail SCADA and signaling infrastructure — not inside it. Your brownfield control path (trackside equipment → interlocking → Rail SCADA → Historian) remains untouched.

RelayQ reads from the same trackside sensors and onboard systems, providing a parallel telemetry path for fleet analytics, predictive maintenance, and cross-depot visibility.

RelayQ operates at three levels:

Integrates with:

• Signaling systems: interlocking controllers, axle counters, track circuits
• Train control: CBTC, ETCS data feeds (via protocol gateway)
• 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

Signaling system telemetry

Track circuits, axle counters, and point machines report status to interlocking controllers. RelayQ validates message integrity at ingress — preventing malformed or stale data from reaching safety-critical decision logic. Default-deny ACLs ensure only authorized trackside devices can publish to signaling topics. A misbehaving device cannot affect unrelated signaling components.

Rolling stock health monitoring

Onboard sensors stream brake condition, door status, HVAC performance, and traction diagnostics to maintenance systems. RelayQ buffers messages during tunnel transits and connectivity gaps, delivering them when backhaul resumes. No data loss across connectivity gaps. The system continues operating regardless of network state.

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 critical alarm messages from other station systems. No slow device can delay critical alerts.

Predictive maintenance data pipelines

Vibration, temperature, and wear data from wheels, bogies, and track components feeds machine learning models for predictive maintenance. RelayQ ensures data integrity at the messaging layer — corrupted inputs produce unreliable predictions. Message state remains consistent across restarts and power events.

Train-to-ground communication

Real-time position, speed, and operational status flows from train to control center. RelayQ’s deterministic latency and persistence ensure consistent delivery even 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. It is designed with certification readiness in mind — the engineering evidence (formal verification, fuzz testing, 1,837+ spec-traceable tests) maps directly to certification objectives.

Proof points

• 6 million fuzz inputs, zero panics — codec hardened against malformed packets from any source
• 1,837+ protocol tests — full MQTT 3.1.1 conformance with spec traceability
• 6-hour soak test — sustained QoS 0/1/2 load with zero message loss
• <50ms cold start on ARM64 — validated on railway-grade ARM platforms
• WAL recovery after hard power cut — zero message loss across simulated power failures
• <1MB binary — fits alongside application code on constrained trackside controllers

Measured operational improvements

Legacy integration

RelayQ does not require replacing existing signaling 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.

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

Request evaluation access →