Comparatif

MOS4 vs AGL & Apex.OS

AGL et Apex.OS sont des runtimes classe SDV bâtis autour de programmes de consortium et de partenariat. MOS4 couvre la même classe de problème en produit standard — évaluation sous conversation ingénierie directe, sans passer par un groupe de travail.

Porte de consortium AGL/Apex fermée avec une clé dans la serrure ; à côté, un chemin produit standard MOS4 ouvert avec une flèche ambrée qui passe à travers

Chemin d’adoption

Programme de consortium vs produit standard.

Le chemin consortium exige adhésion ou accord partenaire, une plateforme de référence et un programme de production. Le chemin produit standard fait passer une évaluation sous licence, livre un device pilote et déploie sur l’échelle matérielle MOS4.

flowchart LR
  subgraph Cons["Chemin consortium / partenaire"]
    O1[Adhésion ou accord partenaire] --> O2[Plateforme de référence] --> O3[Programme de production]
  end
  subgraph T2["Chemin produit standard"]
    T1[Évaluation sous licence] --> T2x[Device pilote] --> T3[Déploiement sur l’échelle matérielle]
  end

Côte à côte

Comparaison des capacités.

Audience cible AGL / Apex.OS Consortia OEM, programmes IVI Tier-1, écosystème de partenaires Apex.OS. MOS4 Fournisseurs Tier-2, exploitants de flotte, constructeurs de machines agricoles et off-highway.
Modèle d’adoption AGL / Apex.OS Adhésion au consortium AGL ou accord partenaire Apex.OS requis pour accéder au stack complet. MOS4 Évaluation produit standard sous licence directe. Pas de barrière de consortium.
Contrats de service AGL / Apex.OS AGL : descripteurs de service D-Bus + protobuf. Apex.OS : interfaces de cycle de vie ROS2 en C++. MOS4 89 fichiers .proto dans mos-interfaces définissent chaque frontière de service, vérifiés par buf lint et cargo build en CI.
Écriture de composants AGL / Apex.OS AGL : descripteur de service D-Bus + boilerplate par service. Apex.OS : implémentation de cycle de vie de nœud ROS2. MOS4 Déclarez les interfaces en proto, annotez une struct Rust avec #[component], implémentez le trait généré. Un micro service minimal fait moins de 30 lignes de Rust.
Protocoles véhicule AGL / Apex.OS AGL cible les stacks IVI OEM (principalement Ethernet SDV). Apex.OS ne fournit pas de stacks de protocoles OBD. MOS4 obdstacks-v2 : 16 protocoles (CAN, CAN-FD, DoIP, UDS, J1939, ISOBUS, KWP, J1850, GMLAN, CANopen, Modbus) via des fichiers de stack JSON déclaratifs, chargeables à chaud au runtime.
OTA flotte AGL / Apex.OS AGL délègue l’OTA à des mécanismes spécifiques au vendeur. Apex.OS ne fournit pas de chemin OTA flotte. MOS4 mos-update : paquets delta signés Ed25519, partitions A/B, rollback automatique via bootcount. OTA par cohortes et canary via le compagnon cloud Munic.
Plage matérielle AGL / Apex.OS Plateformes de référence OEM — typiquement SoC classe compute ou classe IA. MOS4 Classe modem (28,4 Mo de RSS en régime établi, 1,6 s jusqu’au premier service applicatif prêt) jusqu’à classe compute et classe IA. Même workflow bundle.toml sur toute l’échelle.
Hébergement ROS2 AGL / Apex.OS Apex.OS est une distribution ROS2 durcie pour les programmes ASIL-B+. MOS4 mos-ros2 héberge les nœuds rclcpp/rclpy sans modification dans un conteneur MCM. Le bridge relaie les topics DDS comme événements EventBus typés. Parlez à l’ingénierie pour la qualification AGV/robotique.

Source — AGL depuis automotivelinux.org ; Apex.OS depuis apex.ai; MOS4 depuis /fr/architecture.

Ce que MOS4 ajoute

Largeur de plateforme pour les programmes Tier-2 et flotte.

Six scénarios de production, un seul code base.

La même plateforme MOS4 supporte les déploiements passerelle IoT, agriculture (137 fonctionnalités), dashcam, dongle OBD, C4Max et Ekko Drive sans forks de code par scénario. AGL et Apex.OS sont orientés vers les programmes d’unités de tête OEM et d’autonomie ; MOS4 couvre l’espace flotte-télématique, off-highway et aftermarket.

Observabilité comme propriété du framework.

Chaque composant MOS4 émet automatiquement des histogrammes de temps de réponse, des compteurs d’erreurs et des événements de cycle de vie via ObservabilityRegistry. L’export OpenTelemetry OTLP et la propagation W3C Trace Context sont inclus dans le framework, pas ajoutés par service.

Périmètre de sûreté — énoncé honnêtement.

MOS4 n’est pas certifié ASIL aujourd’hui. Les programmes qui ont besoin de nœuds ROS2 certifiés ASIL-B+ conservent Apex.OS pour ce périmètre ; MOS4 couvre les couches flotte, OTA et protocoles véhicule autour. Alignement sûreté par programme — parlez à l’ingénierie.

FAQ

Les questions qu’on nous pose le plus.

  • MOS4 est-il dans la même classe de problème qu’AGL ?

    Oui — même classe software-defined-vehicle. AGL vise les programmes IVI OEM via un modèle de consortium. MOS4 se livre comme produit standard pour l’audience Tier-2 flotte et off-highway afin que les programmes plus petits puissent l’adopter sans groupe de travail multi-OEM.

  • Comment MOS4 se compare-t-il à Apex.OS pour les applications d’autonomie ?

    Apex.OS est une distribution ROS2 durcie. MOS4 héberge les nœuds ROS2 existants dans son superviseur — sans modification du code rclcpp/rclpy — et ajoute autour les protocoles véhicule, l’OTA flotte et l’observabilité. Les programmes qui ont besoin de ROS2 certifié conservent Apex.OS pour ce périmètre ; MOS4 couvre les couches flotte et protocoles véhicule.

  • MOS4 peut-il tourner aux côtés d’un stack AGL ou Apex.OS ?

    Le modèle de coexistence est disponible pour discussion ingénierie. Il n’y a pas de déploiement de référence publié de MOS4 aux côtés d’AGL. Parlez à l’ingénierie pour évaluer la topologie pour votre programme.

  • Et le logiciel réservé aux consortia ?

    MOS4 n’exige pas d’adhésion à un consortium. Le produit, le SDK et la bibliothèque d’interfaces de 63 protos sont accessibles à tout client dans le cadre d’une évaluation standard.

  • MOS4 est-il classe SDV ?

    Oui — même classe software-defined-vehicle. La différence est le chemin d’adoption : évaluation sous licence standard avec une conversation ingénierie directe, pas un programme de consortium.

  • Quelle est la plage matérielle ?

    MOS4 s’exécute depuis des processeurs applicatifs de classe modem capables d’exécuter Linux (~28 Mo de RSS en régime établi, 1,6 s jusqu’au premier service applicatif prêt) jusqu’au matériel de classe compute et de classe IA. Le même workflow bundle.toml + cargo distro generate produit les binaires pour chaque palier.

Même classe SDV, chemin produit standard.

Un appel de 30 minutes avec l’ingénierie. Nous adapterons l’échelle matérielle MOS4 à votre programme.

Vous construisez sur MOS4 ?

Une réponse de l'équipe d'ingénierie, ~24 h. Pas de pitch, pas de NDA.

Parler à l'équipe