Platform · Remote Diagnostic

Most platforms read the vehicle. MOS4 reads it and talks back.

Open a live session from the cloud over a signed TLS tunnel. Read, reset, reconfigure, attest and reflash. Same UDS (ISO 14229) / J1939 / ISOBUS / Modbus / SAE J2534 passthrough engine that drives autonomous telematics — different mode of operation.

What it does in the field

Five jobs the OS handles without a wrench.

For the subset of field failures that do not need a workshop, the OS opens a signed session, drives the bus, completes the action, closes. Saves a tow, a dealer visit, or the cost of dispatching a technician.

OEM · warranty operations

ECU reset over the air

Vehicle stalls on the highway. The remote server opens a signed session, resets the wedged ECU (Electronic Control Unit), closes. Driver continues. No tow truck, no dealer visit.

Saves: Saves one truck roll plus the dealer-bay slot.

EV maker · battery certification

Live-monitor certification

Drive the battery through a charge / discharge cycle while reading live cell telemetry over UDS. The certificate is issued from the same audit log.

Saves: Removes the dedicated bench step from the certification path.

Roadside service · operator

Drive-or-tow triage

Roadside call. The remote server reads ECU state, decides whether the vehicle can reach the next garage on its own or needs a tow. Dispatch matches the diagnosis.

Saves: Removes the unnecessary tow when the vehicle can self-recover.

Fleet inspector · third-party

Inspector mutualisation

City restricts heavy-truck entry but requires inspection. Errand operators connect a device on the truck; one technician inspects many vehicles from an office.

Saves: One technician covers a fleet — the on-site-inspector OPEX line collapses.

OEM · workshop network

J2534 passthrough to a remote bench

A dealer-tool session runs on a workshop laptop; the same gateway carries the SAE J2534 passthrough live to the vehicle bus. The vehicle stays in the field; the tool stays at the bench.

Saves: Removes the physical dispatch — the dealer tool reaches the bus through MOS4.

The wedge

Autonomous vs interactive — same bus, different decider.

Autonomous

Multi Stacks

The device decides what to ask the bus, on a schedule, against a standardised stack. The cloud receives structured signal data. Best for fleet-wide telemetry, predictive maintenance, ELD, compliance reporting.

See Multi Stacks →

Interactive

Remote Diagnostic

The cloud opens a session and drives the bus live. A bot or an operator reads ECU state, resets DTCs (Diagnostic Trouble Codes), pushes calibrations, attests and reflashes firmware, then closes the session. Best for stalled-truck recovery, ECU reset, OEM diagnostic session, workshop remote-assist.

See the session lifecycle ↓

Session lifecycle

Open. Drive. Close.

Sequence diagram. Cloud bot sends StartTunnel through the remote server. Device returns a signed Connected acknowledgement. In a loop, the cloud sends diagnostic requests over UDS, J1939, ISOBUS, or Modbus; the device pulls the message and drives the vehicle ECU; the ECU responds; the device publishes the response back through the remote server to the cloud. When done, the cloud sends StopTunnel; the device acknowledges and drains the connection.

sequenceDiagram
  participant Cloud as Cloud bot
  participant Server as Remote server
  participant Device as MOS4 device
  participant ECU as Vehicle ECU
  Cloud->>Server: StartTunnel(config)
  Server->>Device: deliver StartTunnel
  Device->>Server: Connected (signed ack)
  loop session
    Cloud->>Server: Diagnostic request (UDS/J1939/ISOBUS/Modbus)
    Server->>Device: pull message
    Device->>ECU: drive bus
    ECU-->>Device: response
    Device->>Server: publish response
    Server->>Cloud: deliver response
  end
  Cloud->>Server: StopTunnel
  Server->>Device: deliver StopTunnel
  Device->>Server: AckStop + drain
Cloud → StartTunnel → device → ECU → response → cloud → StopTunnel. One end-to-end tunnel per request.

One end-to-end tunnel per StartTunnel request. The session opens, drives the bus, completes the action, closes. TLS mutual authentication on the diagnostic tunnel. Per-action signed authorisation for any state-changing call.

What the bot can do

Four action classes. Each with its own safety boundary.

Read

Live UDS / J1939 / ISOBUS / Modbus reads, ECU fault-code dumps, parameter snapshots, frame captures.

Safety: Read-only path is unconditional. No write side-effects.

Reset

Clear DTCs, soft-reset ECU, reset learnt adaption values.

Safety: Per-action signed authorisation. Audit log records actor, time, action, target ECU.

Reconfigure

Push a calibration block, write to non-volatile storage, swap a feature flag at the ECU level.

Safety: Multi-party authorisation where the protocol requires it (UDS security-access). Rollback path mandatory.

Reflash

Push a new ECU firmware over the UDS programming session.

Safety: Attestation + signature verification on the device side before the bus session opens. Boot-count-based revert on failed reflash. Safety interlocks are not override-able from the Remote Diagnostic surface.

Why this matters

A truck roll becomes a packet.

For the subset of field failures that don't need a wrench — a wedged ECU, an out-of-spec calibration, a missed parameter — Remote Diagnostic resolves the call without dispatching a technician. The platform doesn't replace the workshop. It removes the workshop from the loop when the loop doesn't need the workshop.

52 micro services Remote Diagnostic and Multi Stacks share the same engine and bus surface.

Reference architecture

Cloud → tunnel → orchestrator → engine → bus.

Reference architecture flow. Cloud bot or operator initiates a signed TLS tunnel to the remote server. The tunnel feeds the Remote Diagnostic session orchestrator. The orchestrator gates every state-changing action behind per-action signed authorisation, multi-party where required. The gate hands off to the same engine that drives Multi Stacks — UDS, J1939, ISOBUS, Modbus, J2534-passthru. The engine talks to the vehicle bus. Every action is recorded in an audit log with per-action provenance, and the audit log is replayed back to the cloud.

flowchart LR
  Cloud[Cloud bot or operator] --> Tunnel[Signed TLS tunnel<br/>to the remote server]
  Tunnel --> Orch[RD session orchestrator<br/>Idle &lt;-&gt; InSession lifecycle]
  Orch --> Gate[Per-action signed authorisation<br/>multi-party where required]
  Gate --> Eng[Same engine as Multi Stacks<br/>UDS / J1939 / ISOBUS / Modbus / J2534-passthru]
  Eng --> Bus[Vehicle bus]
  Eng --> Audit[Audit log<br/>per-action provenance]
  Audit --> Cloud
Cloud → signed TLS tunnel → session orchestrator → per-action gate → shared engine → vehicle bus + audit log → cloud

Building on MOS4?

One reply from engineering, ~24h. No deck, no NDA.

Talk to engineering