Messaging that continues working when vehicles don’t
The automotive industry is shifting toward software-defined vehicles, always-connected fleets, and distributed charging networks. Every one of these systems needs a messaging layer that remains predictable even when systems are not.
RelayQ ensures telemetry, control, and update channels remain consistent even when connectivity drops, systems restart, or devices misbehave.
Automotive systems fail in the field
Vehicles lose connectivity. ECUs restart. Cellular links drop without warning.
In traditional messaging systems, these disruptions propagate: state becomes inconsistent, messages are lost or delayed, and systems behave unpredictably.
RelayQ is designed to contain these failures.
Each connection is isolated. Each client is strictly bounded. The system continues operating across restarts, connectivity gaps, and misbehaving components.
No cascading failure. No system-wide stalls.
Failure remains contained — by design, not by chance.
The system behaves predictably even when the environment does not.
Market challenge
Automotive and EV programs face a unique combination of pressures:
- Constrained hardware budgets — ECUs and gateways have tight CPU, memory, and flash limits
- Cybersecurity regulation — UNECE R155/R156, ISO 21434, and OEM-specific requirements demand provable software security
- Fleet-scale reliability — millions of vehicles generating telemetry over unstable mobile networks
- Long platform lifecycles — vehicle software must be maintainable for 10–15 years
At the same time, vehicles operate in unstable conditions — network interruptions, power cycles, and misbehaving components are routine. Traditional messaging layers do not isolate these failures.
Why traditional brokers break down in automotive
Heavy broker stacks (200MB+ containers, JVM runtimes, hundreds of dependencies) create problems at every level:
- On the vehicle: compete with application logic for scarce compute resources
- In security review: large dependency trees expand ISO 21434 threat analysis scope
- Over time: dependency maintenance compounds across long vehicle program timelines
- At scale: resource-hungry brokers increase per-vehicle cloud and edge infrastructure cost
More importantly, they do not control how failures propagate across clients, sessions, and message state.
How RelayQ addresses automotive requirements
RelayQ enforces controlled behavior under real-world conditions:
- Connectivity loss does not corrupt system state
- ECU restarts do not result in data loss
- Misbehaving clients cannot impact others
- Resource usage remains bounded under load
- The system remains predictable across long-running deployments
- No slow or failing client can stall the system
Supporting characteristics:
- <1MB binary — fits on gateway-class ECUs alongside application code
- Memory-safe (Rust) — eliminates buffer overflows and use-after-free, reducing ASIL-related software risk
- Zero dependencies (non-TLS) — minimal threat analysis scope for ISO 21434 cybersecurity assessments
- WAL persistence — survives ignition cycles and power loss without message loss
- <50ms startup — ready before vehicle systems finish initializing
Where RelayQ fits in the vehicle architecture
RelayQ operates as a single execution boundary, ensuring consistent system state across telemetry ingestion, buffering, and delivery — even across restarts and connectivity gaps.
RelayQ operates at three levels:
| Role | Where it runs | What it does |
|---|---|---|
| In-vehicle edge runtime | Gateway ECU (ARM64/ARMv7) | Aggregates CAN-to-MQTT telemetry, buffers during connectivity gaps |
| Charging station runtime | Station controller (ARM64) | Manages session data, coordinates with fleet backend |
| Fleet ingestion runtime | Edge server or cloud entry point (x86_64) | Validates and routes fleet telemetry at scale |
Integrates with:
- Vehicle platforms: QNX, Linux BSP, AUTOSAR Adaptive (via POSIX)
- Edge compute: NVIDIA Jetson, NXP S32G, Renesas R-Car
- Cloud services: AWS IoT Core, Azure IoT Hub, Google Cloud IoT (via MQTT bridge)
- Protocols: CAN bus (via gateway adapter), SOME/IP (via translation layer)
- Fleet platforms: Geotab, Samsara, custom fleet management systems
Automotive use cases
Connected vehicle telemetry
Stream diagnostics, battery state, thermal data, and driving behavior from vehicle to cloud. RelayQ buffers messages during cellular dead zones and delivers them when connectivity resumes. No data loss across tunnels, parking garages, or rural coverage gaps. The system continues operating regardless of network state.
Secure OTA update channels
OTA coordination messages (update availability, download progress, installation commands) flow through RelayQ. Default-deny ACL ensures only authorized backend services can publish update commands. Zero-dependency architecture means the OTA channel itself has minimal attack surface. Message state remains consistent across interrupted update sessions.
EV charging session management
Charging stations exchange session data (start/stop, power delivery, faults, billing events) with fleet backends. RelayQ’s small footprint fits on station controllers without competing with the charging application for resources. A misbehaving station cannot impact other sessions or the fleet backend.
Fleet-scale data ingestion
Millions of vehicles publishing telemetry simultaneously. RelayQ’s thread-per-client model provides predictable per-vehicle latency without the jitter of async runtimes. No slow or disconnected vehicle can stall the ingestion pipeline.
Security mapped to automotive threats
| Automotive threat | How RelayQ mitigates |
|---|---|
| Remote vehicle compromise via malicious MQTT messages | Default-deny ACL — only authorized topics per client |
| Supply-chain attack on broker dependencies | Zero dependencies — nothing to compromise |
| OTA pipeline manipulation | Topic-level access control separates update channels from telemetry |
| ECU resource exhaustion (DoS) | Rate limiting + OOM guard prevent resource starvation |
| Credential theft / replay | SHA-256 hashing + mTLS with certificate pinning |
| Man-in-the-middle on cellular link | TLS 1.3 via rustls — memory-safe, no OpenSSL CVE exposure |
Compliance and certification readiness
| Standard | RelayQ positioning |
|---|---|
| ISO 21434 (Cybersecurity) | Zero-dependency SBOM simplifies threat analysis and risk assessment |
| UNECE R155 (Cyber regulation) | Minimal attack surface, audit logging, access control by design |
| ISO 26262 (Functional safety) | Memory-safe language eliminates undefined behavior; deterministic runtime supports ASIL argumentation |
| ASPICE | Traceable test coverage (1,837+ protocol tests), formal verification evidence |
| AUTOSAR Adaptive | POSIX-compatible deployment on Adaptive platforms |
RelayQ is not yet formally certified to these standards. It is designed with certification readiness in mind — the engineering evidence (formal verification, fuzz testing, 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 (simulates fleet-scale ingestion)
- <1MB binary on ARM64 — validated on Raspberry Pi CM4 and NXP i.MX8 class hardware
- <50ms cold start — measured on automotive-grade ARM platforms
Measured operational improvements
| Outcome | How |
|---|---|
| Lower per-vehicle software cost | <1MB binary runs on existing gateway hardware — no overprovisioning |
| Faster cybersecurity approval | One-line SBOM, zero transitive dependencies to analyze |
| Reduced fleet downtime risk | WAL persistence + fast restart = no message loss across power cycles |
| Simpler long-term maintenance | No dependency update treadmill over 10–15 year vehicle lifecycle |
| Lower cloud infrastructure cost | Efficient resource usage means fewer runtime instances at fleet scale |
Deployment options
| Target | Architecture | Deployment |
|---|---|---|
| In-vehicle gateway | ARM64, ARMv7 | Static binary on QNX or Linux BSP |
| Charging station controller | ARM64 | Docker on edge compute module |
| Fleet management edge | x86_64 | systemd service on ruggedized hardware |
| EV supply equipment | ARMv7 | <1MB binary on embedded Linux |
All deployments are a single static binary — no runtime, no interpreter, no shared libraries required.
RelayQ vs full IoT platforms
RelayQ is not a full IoT platform. It is the deterministic runtime that sits underneath your vehicle systems:
| Capability | Full IoT platforms | RelayQ |
|---|---|---|
| Device management | ✅ | ❌ (use your fleet platform) |
| Analytics / dashboards | ✅ | ❌ (use Grafana, your cloud) |
| MQTT broker | ✅ | ✅ |
| Zero dependencies | ❌ | ✅ |
| <1MB edge deployment | ❌ | ✅ |
| Formal verification | ❌ | ✅ |
| Fits on vehicle ECU | ❌ | ✅ |
RelayQ complements your existing stack — it handles ingestion, processing, and delivery within a single runtime, while your fleet systems handle device management, analytics, and business logic.
Systems that behave predictably under failure — not just under ideal conditions.
Ready to evaluate RelayQ?
Full-featured runtime. No credit card. Direct support.
Request Evaluation Access