Vehicle and industrial-IoT communication, declared as data files.

The declarative model

Four bullets — one engine.

Every Multi Stacks deployment, vehicle bus or industrial IoT, is declared as four moving parts. Periodic strategy ships out of the box; advanced sequences emerge by composing with MSP (the signal-processing engine) and MEP (the event-processor).

Protocol coverage

16 protocol families in one unified API.

Modbus ASCII is experimental — not claimed for production use. ISOBUS is read-only acquisition; VT display authoring is not supported.

Worked example · industrial IoT (Modbus)

Polling a PLC over Modbus RTU.

Same four bullets, different protocol. A factory genset controller exposes input registers; one Modbus stack polls them at 1 Hz, decodes them as named signals, and broadcasts an event when a threshold is crossed.

{
  "device_id": "Genset-01",
  "transport": "modbus_rtu",
  "slave_id": 7,
  "commands": [
    {
      "name": "coolant_temp_c",
      "function": "read_input_registers",
      "address": 30001,
      "count": 1,
      "period_ms": 1000,
      "decode": "A / 10"
    },
    {
      "name": "fuel_level_pct",
      "function": "read_input_registers",
      "address": 30002,
      "count": 1,
      "period_ms": 1000,
      "decode": "A"
    }
  ],
  "broadcast": { "on_threshold": "fuel_level_pct < 10", "emit": "low_fuel" }
}

Multi-stack mode

N stacks · one set of physical interfaces.

Each stack runs with an independent lifecycle and export path on the same physical interfaces. Multiple stacks sharing a bus do not require a scheduler — the unified protocol API arbitrates access and enforces isolation.

flowchart TD
  S1[Stack A — OBD-II JSON<br/>passenger PIDs]
  S2[Stack B — J1939 JSON<br/>truck PGNs]
  S3[Stack C — Modbus JSON<br/>RS-485 sensors]
  V[Unified protocol API<br/>arbitration · lifecycles]
  S1 --> V
  S2 --> V
  S3 --> V
  V --> Iface1[CAN0]
  V --> Iface2[CAN1]
  V --> Iface3[RS-485]
  S1 -->|export| MQ1[MQTT topic A]
  S2 -->|export| MQ2[MQTT topic B]
  S3 -->|export| MEP[Policy engine]

Capabilities

What ships out of the box.

22 CI-validated default stacks, production-grade DTC handling, J2534-2 passthrough, and built-in circuit-breaker resilience — all available without writing a scheduler or managing bus arbitration manually.

Identification + OE stack push

The right stack for every vehicle, automatically.

Before any polling begins, the runtime identifies the vehicle and selects the appropriate OE stack to load. The pushed OE stack standardises the data — naming, format, units, and frequency — across OE DTCs, dashboard telemetry, and other OE data surfaces.

This identification process is autonomous — the device resolves the correct stack locally from the identification result, with no cloud round-trip required for routine operation. The cloud pushes the OE stack definition once; the device applies it on every connection.

Customers can extend the stack catalogue with their own stacks — bought, IP-owned, or reverse-engineered — using their own identification logic. Custom stacks are scoped to their fleet only; they coexist alongside the default OE stacks without conflict.

For cloud-driven remote diagnostics — where a human or AI is the master rather than the device — see our engineering team about the remote diagnostics surface.

Where this fits

One pillar of the operations layer.

Remote diagnostics is one of five pillars in the operations layer — together with observability, safety, OTA, and lifecycle. Read the full set at /platform/operations.

Language support

Six languages for stack extensions.

Customers can extend stack behaviour — custom identification logic, signal transforms, and action handlers — using any of six languages. Lua 5.4 is the lowest-floor scripting option: no Rust toolchain required.

See the full SDK and developer tooling →

FAQ

Frequently asked questions

• Is Multi Stacks the same as OBDStacks?

  Yes. OBDStacks is the legacy name; Multi Stacks is the canonical name as of 2026-05-05. The same engine, the same JSON stack format, the same default-stacks/ catalogue.

• How many protocols does the runtime support simultaneously?

  Up to 16 protocol families share one unified protocol API. Multiple stacks run concurrently with independent lifecycles and export paths on the same physical interfaces.

• What is a declarative stack?

  A stack is a JSON data file specifying ECUs (Electronic Control Units), Commands, Actions, Exports, Conditions, and Expressions. Updating a PID (parameter ID), changing a sampling period, or adjusting a response policy is a JSON edit and a commit — not a firmware release.

• Does Modbus ASCII work in production?

  Modbus ASCII is an experimental feature — do not rely on it for production deployments. Modbus RTU (RS-485) and Modbus TCP/MBAP are both production-ready.

• Can I test a stack without real ECU hardware?

  Yes. The MOS4 ECU simulator runs one or more virtual ECUs on a software CAN interface and responds to UDS, OBD-II, and ISO-TP with configurable signal strategies. CI pipelines run full regression suites with no physical bench.

• What does DTC support cover?

  DTC reading and clearing across the supported stack — via OBD-II service 03/04 or UDS diagnostic information services.

• How does Multi Stacks compose with MSP and MEP?

  A Multi Stacks "Strategy" is periodic out of the box. For signal-driven sequences, an MSP graph publishes a trigger and Multi Stacks sends the corresponding request. For event-driven sequences, an MEP rule fires on a named event and runs a Multi Stacks action. Both compositions stay declarative.