Automotive & EV Edge

A data path that continues working when vehicles don’t

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.

The automotive industry is shifting toward software-defined vehicles, always-connected fleets, and distributed charging networks. Every one of these systems needs a data path that remains predictable even when the vehicle is not.

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.

Market challenge

Automotive and EV programs face a unique combination of pressures:

• Constrained hardware budgets: gateways have tight CPU, memory, and flash limits
• Cybersecurity regulation: UNECE R155/R156, ISO 21434, and OEM-specific requirements demand provable software security
• Unstable networks: vehicle telemetry crosses mobile networks that drop without warning
• Long platform lifecycles: vehicle software must be maintainable for the life of the program

Why heavy stacks break down in automotive

Unlike traditional MQTT broker stacks (large containers, JVM runtimes, hundreds of dependencies), RelayQ does not compete with application logic for scarce gateway resources, and it does not expand ISO 21434 threat analysis scope with a large dependency tree. More importantly, traditional stacks do not control how failures propagate across clients, sessions, and message state.

How RelayQ addresses automotive requirements

• Connectivity loss does not corrupt system state
• An acknowledged QoS 1 message is written to disk before the acknowledgement, so a power loss after the acknowledgement does not lose it
• Misbehaving clients cannot impact others
• Resource usage remains bounded under load
• No slow or failing client can stall the system

Supporting characteristics:

• One binary under 10 MB: fits on gateway-class hardware alongside application code
• Memory-safe (Rust): eliminates buffer overflows and use-after-free in the communication path
• Std-only core (zero third-party crates in Lite, twelve with TLS on Linux): a small threat analysis scope for ISO 21434 cybersecurity assessments

Where RelayQ fits in the vehicle architecture

RelayQ operates at three levels:

Integrates with:

• Vehicle platforms: Linux BSP; other in-vehicle platforms via a third-party gateway publishing MQTT or Sparkplug B
• Cloud services: AWS IoT Core (via MQTT bridge, validated); Azure IoT Hub via the bridge’s X.509 path only (unvalidated; no SAS-token support)
• In-vehicle buses (CAN and others): via a third-party gateway publishing MQTT or Sparkplug B
• Fleet platforms: any platform that consumes MQTT, or via a third-party gateway publishing MQTT

Automotive use cases

Connected vehicle telemetry

Stream diagnostics, battery state, thermal data, and driving behavior from vehicle to cloud. RelayQ buffers messages to disk during cellular dead zones and replays them when connectivity 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.

Secure OTA update channels

OTA coordination messages (update availability, download progress, installation status) flow through RelayQ. Default-deny ACL ensures only authorized backend services can publish to update topics. The std-only core gives the OTA channel itself a small attack surface.

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. Any command toward station equipment is opt-in, license-gated write-back.

Fleet data ingestion

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

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 (formal verification, fuzz testing, 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)
• Under 10 MB on armv7: runs on Raspberry Pi 3B/3B+ class hardware

Expected operational improvements

Deployment options

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:

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.

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.