OS Linux industriel · lignée plateforme à plus de 4 M d’unités

L’OS nativement IA pour véhicules connectés, machines et appareils. Éprouvé sur le terrain. Entièrement programmable.

MOS4 livre une télématique full-stack, une vision IA edge, du Remote Diagnostic et un runtime programmable — sur un seul OS Linux qui passe de la classe modem à la classe IA. La ligne plateforme Munic qui le porte est déployée en production depuis 2012 et tourne aujourd’hui sur plus de 4 M d’unités. MOS4 est l’OS de nouvelle génération sur cette lignée.

rss 28.4 mo
démarrage 1.6 s
1 cœur · 5% overhead
sbom: cyclonedx
cra: prêt
28.4 Mo mémoire en régime permanent (RSS) profil de référence classe modem — Resident Set Size au repos
1.6 s temps prêt au démarrage profil de référence classe modem — temps jusqu’au premier micro service supervisé prêt
<5% CPU / 10 Mo budget conteneur surcoût d’exécution par micro service — profil de référence SDK
180 fonctionnalités plateforme surfaces de service déclarées dans l’OS
jusqu’à ~100 TOPS silicium classe IA jusqu’à ~100 TOPS sur le tier classe IA

Les métriques étiquetées « profil de référence classe modem » sont mesurées sur un appareil de production classe modem représentatif. RSS (Resident Set Size) en régime permanent au repos ; temps prêt au démarrage = temps entre la remise du noyau et la première réponse d’un micro service supervisé à un appel de service. Budget conteneur = surcoût d’exécution par micro service selon le profil de référence SDK.

Tiers silicium

MOS4 fonctionne sur trois tiers matériels — classe modem (unités connectées basse consommation), classe compute (passerelles edge plus puissantes) et classe IA (inférence NPU sur appareil, jusqu’à ~100 TOPS) — tous sur le même build OS, sans branche par tier.

Tiers matériels →

Six capacités · un OS

Ce qui est livré dans la boîte.

OS Linux industriel · télématique full-stack · prête pour l’IA edge · Remote Diagnostic intégré · entièrement programmable dans tous les langages · sur une lignée plateforme éprouvée sur plus de 4 M d’unités. Choisissez la capacité à vérifier en premier.

OS industriel — sécurisé par conception 01 / 06

Un OS Linux industriel. Sécurisé par construction. Sûr par supervision.

Secure Boot signé, OTA A/B signé avec rollback automatique, key store adossé à un TEE, SBOM CycloneDX et gate CVE à chaque commit. Watchdogs et contrats de ressources par service. Prêt pour le CRA.

Une image OS unique et curatée sur les trois tiers matériels — alternative de qualité production à Yocto, AGL, Linux brut ou ROS2 amateur. Sécurité et sûreté fonctionnelle ne sont pas des ajouts : la chaîne Secure Boot ancre la racine de confiance ; l’OTA attest-and-revert élimine la classe d’échec « image cassée en champ » ; le blocage CVE et le gating de licences tournent à chaque commit, sur chaque micro service. Côté sûreté — limites cgroup supervisées, ordre de démarrage déterministe, détection d’anomalies via OpenTelemetry. Le mapping article par article du CRA est livré avec le pack de conformité.

Sécurité + sûreté →
Télématique 02 / 06

Télématique véhicule connecté full-stack.

Moteur de communication autonome. Dual APN. eUICC Consumer + eUICC M2M. WiFi AP. 2G → 5G + LPWA.

UDS, J1939, ISOBUS, OBD-II, Modbus, CAN-FD — vingt-deux stacks de production. ELD-ready. La couche cellulaire charge à l’exécution les bibliothèques constructeur de modem — prendre en charge un nouveau modem est un changement de configuration, pas une recompilation. Voir le frontend télématique de production au-dessus de MOS4 : ekkofleet.com.

Voir Multi Stacks →
IA edge 03 / 06

Prête pour l’IA edge — déclarez-la en TOML.

Caméra, GPU et NPU partagent la mémoire. Aucune copie pixel CPU. Jusqu’à ~100 TOPS.

Déclarez le pipeline en TOML ; livrez un modèle ONNX ou TFLite. Munic ré-entraîne, quantise, valide et déploie OTA le modèle unifié. Charge DMS + ADAS complète (5 modèles) plus encodage H.265 sur un appareil classe 10 TOPS.

Voir AI Funnel →
Remote Diagnostic 04 / 06

La plupart des plateformes lisent le véhicule. MOS4 le lit et lui répond.

Un bot côté cloud pilote le bus en direct. Lire · Réinitialiser · Reconfigurer · Reflasher.

Même moteur que la télématique autonome — mode d’opération différent. Tunnel TLS signé, autorisation par action, reflash attest-and-revert. Pour le sous-ensemble des défaillances terrain qui n’exigent pas une clé à molette, un déplacement devient un paquet.

Voir Remote Diagnostic →
Programmable 05 / 06

Entièrement programmable — tous les langages.

Configuration. Moteurs no-code. SDK complet en Python, Rust, C, C++, Go.

Trois surfaces de programmation, choisies par fonctionnalité. Configuration (TOML) pour les product managers. Moteurs no-code (traitement du signal, politiques machines à états, communications véhicule, IA edge) pour les ingénieurs embarqués. SDK complet là où c’est nécessaire. Le seul hôte industrialisé de classe ROS2 qui tourne sur matériel classe modem — les nœuds ROS2 embarquent via le pattern sidecar. Mélangez les surfaces dans la même flotte.

Voir le SDK →
Lignée éprouvée sur le terrain 06 / 06

Sur une lignée plateforme éprouvée sur plus de 4 M d’unités.

MOS4 est l’OS de nouvelle génération sur la ligne plateforme Munic. La lignée porte des déploiements de 2012 à aujourd’hui — véhicules particuliers, flottes, opérations aéroportuaires, agriculture, automatisation industrielle.

La ligne plateforme Munic tourne sur plus de 4 M d’unités chez un assureur automobile connecté nord-américain (depuis 2012), un programme télématique MVNO (depuis 2020), une association d’automobilistes européenne de 21 M de membres (depuis 2022), plusieurs programmes flotte OEM européens sous NDA, et des OEM spécialisés en véhicules de performance, opérations aéroportuaires, off-highway et automatisation industrielle. MOS4 hérite des protocoles, des partenaires et de l’architecture éprouvée — et y ajoute le modèle micro services supervisés, l’OTA A/B et le pack de conformité de niveau CRA. Frontend télématique à l’état de l’art au-dessus : ekkofleet.com.

Voir les preuves →
Prêt à l’emploi, ensemble

Un seul client MQTT pilote les quatre moteurs no-code — MSP, MEP, Multi Stacks et AI Funnel — depuis un seul processus. Pas de chaîne d’outils Rust, pas de SDK par moteur, pas de glue personnalisée.

Voir les exemples MQTT des quatre moteurs →

Le pipeline

Quatre moteurs · une plateforme.

Chaque produit MOS4 exécute le même pipeline à quatre moteurs : décodage bus et IoT, traitement du signal, politique machine à états, et IA edge déclarative — puis diverge vers le runtime sur appareil et le cloud Munic dans le même cycle OTA.

Pipeline à quatre moteurs. Les entrées bus véhicule et IoT industriel (CAN, CAN-FD, J1939, Modbus) alimentent Multi Stacks ; les entrées capteurs (caméra, IMU, GNSS) alimentent les graphes MSP de traitement du signal. Les signaux décodés Multi Stacks alimentent aussi MSP. Les sorties MSP alimentent MEP, le moteur de politique machine à états (primitives T·C·A en interne). Les sorties MEP alimentent AI Funnel, le moteur d’IA edge déclarative. AI Funnel diverge vers deux destinations dans le même cycle OTA : un runtime NPU/GPU/CPU sur appareil, et le cloud Munic pour ré-entraînement et livraison OTA.

flowchart LR
  Bus[CAN · CAN-FD · J1939 · Modbus] --> MS[Multi Stacks]
  Sensors[Camera · IMU · GNSS] --> MSP[MSP graphs]
  MS --> MSP
  MSP --> MEP[MEP — state-machine policy]
  MEP --> AI[AI Funnel]
  AI --> RT[On-device NPU / GPU / CPU runtime]
  AI --> Cloud[Munic cloud — OTA + retrain]
  class AI ai-node
  class RT ai-node
Bus + capteurs → Multi Stacks → MSP → MEP → AI Funnel. Quatre moteurs, deux destinations : runtime sur appareil et cloud Munic partagent le même cycle OTA.

Avant / après — même OS, saut de génération.

métrique Génération précédente MOS4 (référence classe modem)
temps prêt au démarrage ~90 s 1.6 s
mémoire en régime permanent (RSS) ~60 Mo 28.4 Mo
micro service minimal — Rust écrit par l’utilisateur n/a < 30 lignes

AI Funnel

Déclarez votre IA. Munic la déploie.

Les clients fournissent un graphe TOML plus un modèle ONNX/TFLite et un dataset COCO. Caméra, GPU et NPU partagent la mémoire directement — le CPU ne copie jamais les pixels. Exécutez plusieurs modèles simultanément avec encodage H.265 sur un appareil classe 10 TOPS.

IA · couche intelligence
— STEP 01

Le client fournit

Un graphe TOML, des modèles ONNX/TFLite, un dataset COCO et un conteneur de logique métier optionnel.

— STEP 02

Le cloud Munic effectue

Ré-entraînement, quantisation, validation, benchmarking, packaging et déploiement OTA du modèle de triage unifié.

— STEP 03

Exécution sur l’appareil

Recadrage et redimensionnement GPU, inférence NPU, mémoire partagée de bout en bout. Aucun pixel ne transite par le CPU.

Diagramme de convergence : trois flux d’entrée convergent sur un losange de décision amber — le modèle de triage IA sur appareil

Remote Diagnostic

Un déplacement devient un paquet.

Le cloud ouvre une session signée, pilote le bus, complète l’action, ferme. Pour le sous-ensemble des défaillances terrain qui n’exigent pas d’atelier. Même moteur UDS / J1939 / ISOBUS / Modbus / J2534-passthru que la télématique autonome — mode d’opération différent.

OEM · garantie

Réinitialisation ECU à distance

Réinitialiser un ECU (Electronic Control Unit) bloqué depuis le cloud. Le conducteur continue. Pas de dépanneuse, pas de visite chez le concessionnaire.

Constructeur VE

Certification en supervision directe

Lire la télémétrie cellule en direct pendant un cycle de charge / décharge. Certificat issu du même journal d’audit.

Assistance routière

Triage rouler-ou-remorquer

Lire l’état de l’ECU. Décider si le véhicule peut atteindre le prochain garage ou s’il faut le remorquer.

Inspecteur de flotte

Mutualisation des inspecteurs

Des opérateurs se connectent sur le véhicule ; un technicien inspecte plusieurs véhicules depuis un bureau.

Sortie cloud

Maillage GraphQL comme point d’entrée client.

Le chemin cloud de bout en bout : micro service en conteneur → pont MQTT → passerelle de communication → cloud-connect → micro service cloud → maillage GraphQL → application client.

Silhouette de serveur cloud cyan à gauche connectée par des flux de données brillants à trois véhicules à droite (berline, camion, pelleteuse) — topologie télématique sur fond blueprint sombre

Topologie sortie cloud — micro service vers maillage GraphQL

flowchart LR
    A[Micro service in container] --> B[MQTT bridge]
    B --> C[Communication gateway]
    C --> D[cloud-connect]
    D --> E[cloud micro service]
    E --> F[GraphQL mesh]
    F --> G[Customer app]

Référence passerelle GraphQL publique : gateway.munic.io/services/graphql_gateway/docs/

Runtime de conteneurs

Hot-swap. Pas de redémarrage.

Apportez votre nœud. Remplacez un micro service sans redémarrer l’appareil. Conteneurs isolés en processus avec limites de ressources imposées. SDK first-class en Python, Rust, C, C++, Go. Tout langage qui parle MQTT embarque.

Conteneurs isolés en processus

Limites de ressources comme contrat, pas au mieux. Runtime crun production sur cgroups v2.

Apportez votre nœud

Nœuds Python · Rust · C · C++ · Go existants intégrés sans modification. Aucun changement de code pour rouler sur le bus typé.

Tout langage parlant MQTT

Au-dessus de la couche SDK, tout client publie et s’abonne — sans dépendance au langage.

Alternative runtime ROS2

Une passerelle sidecar ROS2 first-class fait le pont entre les graphes DDS et MOS4. Les nœuds ROS2 existants embarquent — le seul hôte industrialisé de classe ROS2 sur matériel classe modem.

SDLC · CI · conformité

Contrats de service typés. SBOM à chaque version.

Chaque micro service publie son contrat. Chaque version livre un SBOM CycloneDX, un scan CVE, des binaires signés et une surface OpenTelemetry. Prêt pour le CRA — mapping article par article dans le pack de conformité.

SBOM CycloneDX nomenclature logicielle, à chaque version
Versions signées binaires signés, journal d’audit par version
Gate CVE scan des dépendances, à chaque commit
Analyse statique patterns de code sécurisé imposés
OpenTelemetry surface d’observabilité, à chaque micro service
CRA article par article EU Cyber Resilience Act, mappé
Opérations

La couche jour 2 est dans la boîte.

Observabilité, sûreté, OTA, contrôle à distance, cycle de vie. Cinq capacités, une plateforme, chaque appareil.

Explorer la couche opérations →
CRA-prêt

CRA-prêt. Dès le premier jour. À chaque version.

Mapping CRA article par article, SBOM, pipeline de sécurité, processus PSIRT.

Lire la conformité →

Construire sur MOS4.

Commencez par le catalogue de services — déclarez les capacités dont vous avez besoin, dimensionnées par tier silicium. L’ingénierie est à un clic dès qu’une conversation d’adéquation est utile.

Vous construisez sur MOS4 ?

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

Parler à l'équipe