— Pourquoi MOS4
Une plateforme, six décisions transmissibles.
MOS4 est un OS Linux embarqué distribué à base de micro services pour véhicules connectés, machines et IoT — choisi par les programmes qui ont besoin d'un SBOM CRA-ready, de secure boot avec runtime supervisé, du support silicium AI-class, d'un seul OS sur les tiers silicium, et d'un SDK six langages. La page ci-dessous répartit les réponses sur les six surfaces de décision — conformité, sûr-et-sécurisé, économie, narratif, ingénierie, disponibilité — afin que chaque section soit transmise au collègue qui en a la responsabilité.
Ce qu'un dossier d'évaluation fournisseur attend du fournisseur d'OS.
Le règlement européen sur la cyber-résilience s'applique à partir de 2027. MOS4 est livré avec un SBOM CycloneDX, un PSIRT public et un mappage CRA article par article, pour que les équipes juridique et sécurité puissent inclure le dossier de conformité dans un dossier d'évaluation fournisseur.
SBOM CycloneDX à chaque version
Nomenclature lisible par machine — téléchargeable depuis le portail client pour inclusion dans les dossiers de preuves d'achat. cargo cyclonedx s'exécute à chaque commit sur les 52 micro services.
PSIRT + divulgation coordonnée
Adresse publique security@munic.io, accusé de réception sous 5 jours ouvrés, CVE suivis par version. Objectifs de correction internes : 7 / 30 / 90 jours selon la gravité ; SLA contractuels par programme.
Mappage CRA article par article
Annexe I §1, §2, Art. 13, Art. 14 — chaque exigence mappée à l'artefact MOS4 qui la satisfait. L'équipe en charge du dossier de conformité ne documente que la couche applicative.
OTA signé + gestion par cohortes
Paquets delta signés Ed25519, partitions A/B, retour arrière automatique via bootcount. OTA par cohortes et canary via le cloud Munic.
Hygiène OSS + LTS
Les dépendances OSS sont auditées pour licences contaminantes (LGPLv3 et équivalents nettoyés avant intégration). cargo audit + cargo deny + semgrep s'exécutent à chaque commit pour détecter les CVE dans les dépendances OSS. Un engagement LTS offre aux programmes une base stable sur des cycles de production pluriannuels.
Sécurité et sûreté appartiennent à l'OS.
La paperasse compliance (#01) est en aval de la posture engineering. Sécurité et sûreté fonctionnelle sont des propriétés plateforme chez MOS4 : imposées en CI à la build, par le superviseur au démarrage, et par le contrat de ressources à l'exécution. Les mêmes contrôles tournent à chaque commit, chaque release, chaque micro service.
Secure Boot + key store ancré TEE
Racine de confiance ancrée dans le matériel. Chaîne de démarrage signée sur le silicium supporté. Clés stockées dans un Trusted Execution Environment — jamais exposées à la couche applicative.
OTA A/B signé avec rollback automatique
Partitions A/B avec images cryptographiquement signées. Échec → attest-and-revert, supprimant la classe d'échec « image cassée en champ ». Anti-rollback imposé.
Runtime supervisé avec contrats de ressources
Chaque micro service tourne dans un conteneur avec limites cgroup CPU/mémoire/IO imposées au démarrage. Watchdog avec redémarrage automatique sur heartbeats manqués. Un service qui dérive ne peut affamer l'appareil.
Démarrage déterministe, contrats typés
L'ordre de démarrage dérive d'un graphe de dépendances déclaré ; le registre refuse à la compilation un graphe mal ordonné. Contrats protobuf typés attrapent la dérive d'interface à la compilation — aucune classe de race-condition, aucun break silencieux en champ.
Observabilité à l'échelle de la flotte
Traces, métriques et logs structurés de chaque service sur une surface OpenTelemetry unifiée. Compteurs de restart, codes de sortie, latence et advisories CVE remontent au dashboard avant de se propager.
Un OS sur toute l'échelle silicium.
MOS4 fonctionne des SoC modem-class jusqu'au silicium AI-class sur un seul OS. Munic assure le portage ; le programme choisit le niveau silicium par produit. Aucune équipe BSP interne requise. Chemins de migration documentés depuis RTOS, Linux générique, Android Automotive et ROS2 sur Linux complet.
Échelle des tiers silicium. Le même OS MOS4 couvre trois classes de silicium. Modem-class — moins de 5% overhead, RSS 28.4 Mo en régime permanent, démarrage 1.6 s premier-app-prêt. Compute-class — capture multi-caméra, isolation par conteneurs. AI-class — jusqu'à environ 100 TOPS NPU sur silicium AI-class, compatible binaire sur tout le tier AI-class. Munic porte l'OS sur la famille ; l'OEM choisit le tier par produit.
flowchart LR M[modem-class<br/>RSS 28.4 Mo · boot 1.6 s<br/>moins de 5% overhead] C[compute-class<br/>multi-caméra · conteneurs] A[AI-class<br/>jusqu'à ~100 TOPS NPU<br/>eUICC Consumer + eUICC M2M] M --> C --> A M -. un seul OS .-> C C -. un seul OS .-> A class A ai-node
28.4 Mo RSS · 1.6 s démarrage · <5% overhead
Référence silicium modem-class. RSS en régime permanent et démarrage premier-app-prêt sur un appareil de production modem-class représentatif. La même image passe à un silicium AI-class sans branche distincte.
Pas de licence outillage par ingénieur
Multi Stacks + Diagnostic à distance remplace l'outillage atelier par siège par un modèle par appareil, à l'échelle de la flotte.
Matrice de migration incluse
Chemins documentés depuis RTOS monolithique, Linux générique, Android Automotive et ROS2 sur Linux complet — le générateur de bundle Cargo mos-distro et les profils par cible couvrent les cibles embarquées les plus courantes.
Variantes matérielles, code inchangé
La gamme silicium va d'une base modem-class sans NPU ni GPU jusqu'au silicium AI-class (~100 TOPS). Le même ensemble binaire fonctionne sur toute la famille — pas de portage, ni ré-entraînement, ni revalidation au passage à un niveau supérieur ou inférieur. Gamme de coût de production par volume : voir munic.io pour les SKU et les tiers.
Livrer des capacités, pas des promesses marketing.
Le pipeline IA sur appareil est entièrement disponible. Caméra, GPU et NPU partagent la mémoire directement — le CPU ne copie jamais les pixels. Exécutez une charge DMS + ADAS complète (5 modèles) et l'encodage H.265 sur un appareil 10-TOPS-class. Configuré en TOML ; déployé via le même canal OTA que le code.
Pipeline caméra-vers-NPU en mémoire partagée
Caméra, GPU et NPU partagent la mémoire directement — le CPU ne copie jamais les pixels. Il orchestre mais ne touche pas aux pixels. Configuré en TOML ; déployé par OTA.
Vision : multi-caméra, recadrage GPU, anonymisation RGPD en direct
Cinq entrées caméra (MIPI-CSI, GMSL2, USB UVC, RTSP/ONVIF, WebRTC). L'anonymisation RGPD en direct (flou visages et plaques) est contrôlée par un interrupteur de politique au démarrage, avant qu'un seul frame ne quitte le pipeline.
Déploiements de référence derrière chaque affirmation
Véhicules de performance, opérations aéroportuaires, agriculture, machines off-highway. Les clients sont sous NDA mais les secteurs, capacités et standards ne le sont pas.
Stack IA complet chez un seul fournisseur — un SLA de la caméra au LLM jusqu'au journal d'audit
L'IA vision et l'IA language s'exécutent sur le même appareil sous un SLA plateforme unique. Inférence caméra-vers-NPU, LLM on-device avec RAG refuse-preferred, et manifeste d'audit par réponse — un seul fournisseur, un canal OTA, un contrat de support.
IA offline-first — RAG, LLM et voix s'exécutent on-device par défaut ; le cloud est opt-in
La plateforme language s'exécute entièrement on-device par défaut. L'accès cloud nécessite une configuration explicite à trois portes indépendantes. Aucune dépendance de connectivité pour l'inférence principale.
Python, Rust, C, C++, Go — tous sur la même plateforme.
La re-formation est l'un des coûts cachés les plus importants d'un programme embarqué. MOS4 conserve les langages que l'équipe utilise déjà sur la même plateforme. MQTT, Prometheus, TOML et schémas typés sont en première classe. Les nœuds ROS2 (rclcpp/rclpy) s'exécutent sans modification dans un conteneur MCM via le pattern sidecar.
Cinq langages, un moteur de conteneurs OCI
Python, Rust, C, C++ et Go fonctionnent côte à côte sous enforcement cgroups v2 (runtime de production crun). Les nœuds ROS2 s'ajoutent via le pattern sidecar. Les nœuds existants s'intègrent ; les nouveaux adoptent les interfaces protobuf typées. Exigences de qualification AGV/robotique : contactez l'ingénierie.
Moteurs no-code pour les logiques écrites par des experts domaine
MSP : 226 graphes de traitement du signal sur 21 domaines véhicule, configurés en YAML, sans recompilation Rust par domaine. MEP : moteur de politique machine à états (T·C·A sous le capot), rechargement à chaud, pool de workers parallèles. Multi Stacks : communication véhicule et IoT industriel, 16 familles de protocoles de façon déclarative. AI Funnel : IA edge déclarative — graphe TOML en entrée, OTA en sortie.
SDLC adapté à un programme industriel
cargo test, e2e distro, cargo bench, cargo grcov (couverture), cargo audit + geiger + deny (sécurité), semgrep (analyse statique), cargo cyclonedx (SBOM) — à chaque commit, via le template partagé ci-gamma.
Observable par conception
Métriques Prometheus, export OpenTelemetry OTLP, propagation W3C Trace Context, logs structurés — automatiques pour chaque appel de service enregistré via ctx.observer(). Mêmes conventions que celles déjà opérées par l'équipe cloud.
Comparer MOS4 aux alternatives
Diagnostic à distance, reconfiguration à chaud, remédiation signée — sur chaque appareil.
La disponibilité ne se gagne pas sur les démos IA. Elle se gagne dans les moments où quelque chose tourne mal. MOS4 livre la surface qui transforme un déplacement technique en paquet : diagnostic à distance signé, reconfiguration à chaud sans OTA, remédiation A/B avec retour arrière automatique, et une couche de détection de défaut MSP qui signale la panne avant qu'elle n'arrête la machine.
Diagnostiquer à distance — pas de déplacement technique pour une lecture d'actionneur
Arbre de défauts UDS, J1939, ISOBUS complet depuis le cloud. Lecture de signaux en direct via Multi Stacks. Récupération de logs en direct (plage TAI64 + filtre grep, streamé compressé). Pas de SSH, pas de SCP, pas d'outillage embarqué côté appareil.
Reconfigurer à distance — pousser un nouveau graphe, une nouvelle politique, une nouvelle carte
Échange de graphe MSP, mise à jour de machine à états MEP, recartographie de geofence, refresh de scénario Multi Stacks — rechargés à chaud sans OTA. ~10 s entre fin d'édition et premier appel de service réussi. Rotation de fichiers A/B persistant la configuration au reboot ; retour à la configuration précédente en un appel signé.
Remédier à distance — OTA A/B signé, reboot à distance, re-flash à distance
Paquets delta signés Ed25519, partitions A/B, retour arrière automatique basé sur bootcount au boot raté. Redémarrage de processus à distance et reboot SoC à distance via la chaîne de supervision watchdog. Re-flash à distance avec attestation cryptographique. Les interlocks de sécurité ne sont pas désactivables depuis la surface de remédiation.
Couche prédictive — détecter la panne avant qu'elle n'arrête la machine
Le graphe de signal MSP passe la télémétrie au travers d'un modèle de détection de défaut sur l'appareil. Le cloud agrège les signatures sur la flotte ; AI Funnel ré-entraîne et OTA le modèle de détection mis à jour. Pas de release firmware, pas de fenêtre de flash sur toute la flotte — chaque appareil reçoit le détecteur amélioré.
Porte d'action signée + journal d'audit par action
Chaque action distante passe par une porte d'action signée. Autorisation multi-partie disponible pour les actions sensibles. Journal d'audit par action sur l'EventBus : acteur, action, cible, horodatage, résultat. Rétention glissante de six mois, exploitable comme preuve pour une revue alignée CRA.
Matrice d'adéquation
Secteur × capacité.
Trouvez votre secteur, parcourez votre colonne, auto-qualifiez-vous. Chaque cellule résume la capacité pour ce secteur.
| Capability | Automobile | Machines | Camions & VUL | Passerelle IoT | Vidéo & IA de flotte |
|---|---|---|---|---|---|
| Multi Stacks · Diagnostic à distance | CAN, CAN-FD, DoIP | ISOBUS, J1939 | HD-OBD, J1708, J1587 | Modbus, RS485 | — |
| AI Funnel · IA edge déclarative | Modèles OEM-spécifiques | Détection culture / actif | Score conducteur | Triage anomalie | Ré-entraînement multi-cam |
| Vision · ROI shader · ADAS+DMS | DMS, boîte noire | Alertes opérateur | Dashcam + DMS | — | Anonymisation RGPD |
| CRA · SBOM · pipeline de sécurité | core | core | core | core | core |
| Niveau matériel | compute · AI-class | compute-class | compute-class | modem · compute | AI-class |
| Langages : Python · Rust · C · C++ · Go | les cinq | C / C++ / Rust | C / C++ / Rust | Python / Rust | Python / C++ |
FAQ
Questions fréquentes
-
À qui s'adresse la page Pourquoi MOS4 ?
La page est organisée par surface de décision — conformité, économie, narratif, ingénierie, disponibilité — pour que chaque section puisse être transmise au collègue qui en a la responsabilité.
-
Comment MOS4 répond-il au Cyber Resilience Act européen ?
Le CRA s'applique à partir de 2027. MOS4 est livré avec un SBOM CycloneDX, un PSIRT public à security@munic.io et un mappage CRA article par article couvrant Annexe I §1, §2, Art. 13 et Art. 14.
-
Sur quels niveaux silicium MOS4 fonctionne-t-il ?
Un seul OS couvre les niveaux modem-class, compute-class et AI-class. La référence modem-class est 28.4 Mo RSS en régime permanent, démarrage 1.6 s, moins de 5 % d'overhead. Munic assure le portage ; le programme choisit le niveau par produit.
-
Quels langages tournent sur MOS4 ?
Python, Rust, C, C++ et Go fonctionnent côte à côte sous isolation par conteneurs avec cgroups v2. Les nœuds ROS2 s'ajoutent via le pattern sidecar. Les nœuds existants s'intègrent ; les nouveaux adoptent les interfaces protobuf typées.
-
Comment MOS4 gère-t-il l'IA edge ?
Caméra, GPU et NPU partagent la mémoire directement — le CPU ne copie jamais les pixels. Exécutez une charge DMS + ADAS complète (5 modèles) et l'encodage H.265 sur un appareil 10-TOPS-class avec de la marge CPU pour le code applicatif. Voir /fr/platform/ai-vision pour les détails.
-
Quels volumes de programmes MOS4 cible-t-il ?
MOS4 cible les programmes de petit et moyen volume — 10 000 à 300 000 unités — sur les secteurs automobile, machines, camions et VUL, passerelle IoT, vidéo et IA de flotte.
-
Comment fonctionne l'OTA par cohortes et canary ?
Partitions A/B, paquets delta signés et retour arrière automatique. La gestion des cohortes et canary est assurée côté serveur via le cloud Munic.
Nouveau dans le vocabulaire MOS4 ? Le glossaire couvre MCM container, dma-buf, ci-gamma, J1939 et plus encore.
Transmettez cette surface de décision au collègue qui en a la responsabilité.
Un appel, un artefact, chaque interface et chaque contrat sur la table.