MOS4 vs Geotab & CalAmp

Cloud topology

End-to-end data path.

The recommended cloud path from a MOS4 device to your cloud ingress: micro service on device → mos-communication-gateway → MD21 optimised leg → cloud-connect → MQTT forwarding micro service → your cloud ingress over standard MQTT. The MD21 leg handles multiplexing, piggyback, compression, and ASN.1-based encoding — bandwidth optimisation that is invisible to your application layer and material on metered cellular links.

flowchart LR
  subgraph Dev["On device"]
    micro service[Customer micro service] --> GW[mos-communication-gateway]
  end
  GW -->|MD21 optimised leg| CC[cloud-connect]
  CC -->|MQTT forward micro service| CI[Customer cloud ingress]
  subgraph CC["Munic cloud-connect"]
    MQ[mqtt-fwd micro service]
  end

Vehicle protocols

16 protocols in a declarative stack.

Stack definitions are JSON DSL data files validated at LoadStack time. Protocol changes are file edits, not firmware releases.

FAQ

The questions we hear most.

• Can MOS4 read the same telemetry as Geotab or CalAmp?

  Yes — and more. obdstacks-v2 covers OBD-II plus the manufacturer-private PIDs and DTCs that closed devices typically gate. DTC reading and clearing are available across the supported protocol stack. Anything readable on the bus is readable from a MOS4 component.

• Where does my data go?

  Your data goes where you configure it. The cloud path is: micro service on device → mos-communication-gateway → MD21 → cloud-connect → MQTT forwarding micro service → your cloud ingress over standard MQTT. The MD21 leg handles multiplexing, piggyback, compression, and ASN.1-based encoding — bandwidth optimisation that is invisible to your application but material on metered cellular links.

• Can I write automation logic without Rust?

  Yes. The MOS Event Processor (MEP) evaluates declarative YAML policies — Trigger, Condition, Action — against device state and vehicle signals without any Rust or compiled code. Rules hot-reload without a firmware flash. Any container language also reaches any component via the MQTT bridge: a Python container speaks MQTT, which proxies through the RPC bridge to any obdstacks-v2 service call.

• Can I reuse existing diagnostic tooling?

  Yes. obdstacks-v2 implements the SAE J2534 04.04 passthrough API over JSON/Protobuf. Existing PC-based OEM diagnostic scan tools and ECU flashers can reach the vehicle bus through the same embedded gateway that handles continuous telematics.

• How does OTA work?

  mos-update handles download, SHA-256 verify, Ed25519 validate, delta apply, A/B partition commit, and automatic rollback via bootcount without operator intervention on failure. Retry and reboot limits persist across power cycles. Per-programme automation hooks available on request.

• When is a closed SaaS device still the right choice?

  When fleet operations need a turnkey OBD-II and GPS feed with zero engineering involvement. MOS4 is the right answer when the programme needs custom on-device logic, additional vehicle protocols, data sovereignty, or on-device AI inference.