MOS4 vs Geotab & CalAmp

Topologie cloud

Chemin de données de bout en bout.

Le chemin cloud recommandé d’un device MOS4 vers votre ingress cloud : micro service sur device → mos-communication-gateway → segment optimisé MD21 → cloud-connect → micro service de forwarding MQTT → votre ingress cloud sur MQTT standard. Le segment MD21 gère le multiplexage, le piggyback, la compression et l’encodage ASN.1 — optimisation de bande passante invisible pour votre couche applicative et matérielle sur les liens cellulaires mesurés.

flowchart LR
  subgraph Dev["Sur le device"]
    micro service[Micro service client] --> GW[mos-communication-gateway]
  end
  GW -->|segment optimisé MD21| CC[cloud-connect]
  CC -->|micro service de forwarding MQTT| CI[Ingress cloud client]
  subgraph CC["cloud-connect Munic"]
    MQ[micro service mqtt-fwd]
  end

Protocoles véhicule

16 protocoles dans un stack déclaratif.

Les définitions de stack sont des fichiers de données JSON DSL validés au moment du LoadStack. Les changements de protocole sont des éditions de fichier, pas des releases firmware.

FAQ

Les questions qu’on nous pose le plus.

• MOS4 peut-il lire la même télémétrie que Geotab ou CalAmp ?

  Oui — et plus. obdstacks-v2 couvre OBD-II ainsi que les PIDs et DTCs privés constructeurs que les devices fermés bornent typiquement. La lecture et l’effacement de DTC sont disponibles sur la pile de protocoles supportée. Tout ce qui est lisible sur le bus est lisible depuis un composant MOS4.

• Où vont mes données ?

  Vos données vont où vous les configurez. Le chemin cloud est : micro service sur device → mos-communication-gateway → MD21 → cloud-connect → micro service de forwarding MQTT → votre ingress cloud sur MQTT standard. Le segment MD21 gère le multiplexage, le piggyback, la compression et l’encodage ASN.1 — optimisation de bande passante invisible pour votre application mais matérielle sur les liens cellulaires mesurés.

• Puis-je écrire de la logique d’automatisation sans Rust ?

  Oui. Le MOS Event Processor (MEP) évalue des policies YAML déclaratives — Trigger, Condition, Action — contre l’état du device et les signaux véhicule sans Rust ni code compilé. Les règles rechargent à chaud sans flash firmware. Tout langage de conteneur atteint aussi tout composant via le bridge MQTT : un conteneur Python parle MQTT, qui proxifie via le bridge RPC vers tout appel de service obdstacks-v2.

• Puis-je réutiliser mon outillage de diagnostic existant ?

  Oui. obdstacks-v2 implémente l’API passthrough SAE J2534 04.04 sur JSON/Protobuf. Les outils de diagnostic et flashers d’ECU OEM existants basés PC peuvent atteindre le bus véhicule via la même passerelle embarquée qui gère la télématique continue.

• Comment fonctionne l’OTA ?

  mos-update gère le téléchargement, la vérification SHA-256, la validation Ed25519, l’application delta, le commit partition A/B et le rollback automatique via bootcount sans intervention opérateur en cas d’échec. Les limites de retry et de reboot persistent entre les cycles d’alimentation. Hooks d’automatisation par programme disponibles sur demande.

• Quand un device SaaS fermé reste-t-il le bon choix ?

  Quand l’exploitation de flotte a besoin d’un flux OBD-II et GPS clé en main sans implication ingénierie. MOS4 est la bonne réponse quand le programme a besoin de logique embarquée custom, de protocoles véhicule additionnels, de souveraineté des données ou d’inférence IA embarquée.