— Plateforme / Architecture
La pile MOS4.
MOS4 est un OS à micro services distribué sur Linux : 8 couches architecturales, 52 micro services de production, 89 interfaces proto, hot-swap en 10 secondes. Interfaces définies en proto, ordonnancement de démarrage imposé par le registre, hot-swap — propriétés du framework, pas de l'application.
Modèle micro service
Une déclaration, toute la surface de service.
Chaque micro service déclare des provided_interfaces et required_interfaces définis en proto. L'étape de génération de code écrit toute la surface de service : trait serveur, proxy, client direct, test double fake, module métriques et suite de tests de conformité — depuis une seule déclaration. L'auteur écrit les hooks de cycle de vie et la logique métier — rien d'autre.
Une seule étape de génération de code
build_api::generate_component_code(dir, out_dir) dans build.rs pilote : parsing proto → trait serveur → proxy → client direct → fake → module métriques
→ suite de tests de conformité. Un micro service minimal tient en moins de 30 lignes de Rust.
Ordonnancement imposé par le registre
start_level 0–10 est la priorité numérique dans le registre — distinct du modèle
mental d'architecture L0–L7. Le registre construit un graphe de dépendances et l'applique au
démarrage ; aucun micro service ne peut appeler une interface requise avant que son fournisseur
ne soit enregistré.
Hot-swap au niveau du framework
Quand un nouveau processus s'enregistre avec un component.id existant, le registre
demande un state-dump à l'ancienne instance, l'arrête, injecte l'état sérialisé dans le nouveau
et démarre le remplaçant. De la fin de compilation au premier appel de service réussi sur un
vrai appareil : 10 secondes.
Parcourir le catalogue complet de micro services — 52 services, 89 fichiers proto.
Runtime supervisé
Trois couches de supervision, zéro boilerplate.
Le framework surveille chaque micro service avec des checkpoints de tâches, des pings de santé de processus et une intégration au watchdog matériel. L'action corrective — redémarrage, reboot ou reset matériel — s'escalade automatiquement sans configuration par service.
Watchdog
Les micro services déclarent des checkpoints de tâches nommés avec des timeouts dans la
macro
#[component]. Le framework surveille trois couches : checkpoints de tâches,
pings de santé de processus entre master et slave, et le chemin d'escalade matérielle
Linux /dev/watchdog. Checkpoint manqué → Dégradé → redémarrage → reboot →
reset matériel.
Sentry
Suivi centralisé des incidents sur tous les micro services. Pendant la fenêtre de grâce de démarrage du registre, les erreurs de classe cascade sont bloquées — une gate cascade Sentry empêche le bruit de démarrage de contaminer le journal d'incidents. Les opérateurs peuvent régler la période de grâce ou désactiver la gate entièrement.
Observabilité
Le framework émet des histogrammes par RPC, des compteurs d'erreurs, la durée de vie des
services et des traces d'événements de cycle de vie pour chaque appel de service
enregistré — automatiquement via ObservabilityRegistry. La propagation W3C
Trace Context est incluse ; aucun contrat d'instrumentation par service n'est requis.
Dashboards, OTA, contrôle à distance, cycle de vie — surface d'observabilité complète sur /fr/platform/operations.
Registre + transport
Transport sélectionné par URL de endpoint.
Le registre master détient la découverte de services et l'ordonnancement au démarrage. Le mode de transport — mémoire, Unix socket, mémoire partagée, TCP, QUIC, WebSocket — est sélectionné par schéma URI au moment de la configuration du bundle. Le mode direct contourne la sérialisation pour les appelants dans le même processus. Le code de service est aveugle au transport.
| Environnement | Transport | Encodage |
|---|---|---|
| Service-à-service même puce | iceoryx2 SHM + dmabuf | zéro-copie |
| Plan caméra / vision | Passage fd SCM_RIGHTS | handle dmabuf |
| Pont ROS2 | iceoryx2 DDS | protobuf / DDS |
| Cross-host / TCP | TCP / Unix sockets / QUIC | zstd / LZ4 / gzip |
| Clients WebSocket | WebSocket | zstd / gzip |
TCP, Unix sockets, mémoire partagée, QUIC, WebSocket, named pipes et ring buffers implémentent tous la même interface de transport. Pas de compilation conditionnelle dans le code de service. La compression on-wire (zstd, LZ4, Snappy, gzip) se négocie par connexion. Circuit breaker et retry sont intégrés au registre.
Deux modes de transport. Mode 1 : échange de données service-à-service sur la même puce, via mémoire partagée avec handles de frames pour le handoff zéro-copie. Mode 2 : pont ROS2 — les nœuds rclcpp et rclpy publient des topics DDS ; le transport de frames les traduit vers le bus MOS4, livrant des événements typés aux micro services MOS4.
flowchart LR
subgraph S1["Service-à-service même puce"]
A[Micro service A] -->|mémoire partagée + handle frame| B[Micro service B]
end
subgraph S2["Pont ROS2 via le transport de frames"]
R[nœud rclcpp / rclpy] -->|topic DDS| F[Transport de frames]
F -->|bus MOS4| C[Micro service MOS4]
end Les 4 moteurs, un seul runtime
Une plateforme pour les quatre moteurs no-code et N conteneurs.
Le superviseur, le registre, l'EventBus et le broker MQTT in-process sont une infrastructure partagée. MSP, MEP, Multi Stacks et AI Funnel consomment les mêmes primitives — et chaque conteneur client aussi, dans l'un des cinq langages pris en charge.
Plateforme partagée
- · Superviseur — démarrage, arrêt, redémarrage, hot-swap
- · Registre — interfaces typées, semver, graphe de dépendances
- · EventBus — distribution d'événements nommés
- · Broker MQTT in-process — tout conteneur atteint tout service
Moteurs et conteneurs, côte à côte
- · MSP — graphes de traitement du signal continu
- · MEP — politiques machine à états (T·C·A sous le capot)
- · Multi Stacks — communications véhicule et IoT industriel
- · AI Funnel — IA edge déclarative
- · N conteneurs — Python · Rust · C · C++ · Go (sidecar ROS2)
Chaque moteur no-code est documenté en profondeur sur /fr/platform/no-code.
Glossaire
Nom public vers terme technique.
| Terme | Ce que c'est |
|---|---|
| Micro service | Unité d'exécution de MOS4. Crate Rust, macro #[component], interfaces proto. |
| MCM | MOS Container Manager — moteur de conteneurs léger avec isolation des ressources imposée. |
| MD21 | Protocole de télémétrie Munic (ASN.1 UPER), optimisé pour la bande passante. |
| MSP | MOS Signal Processing — moteur de graphes YAML pour les flux de données domaine véhicule. |
| MEP | MOS Event Processor — moteur de politique machine à états. Chaque règle est une primitive Déclencheur / Condition / Action ; l'ensemble de règles composé est la machine à états. Rechargement à chaud. |
| iceoryx2 | IPC zéro-copie. Deux modes : SHM + dmabuf même puce, DDS complet pour le pont ROS2. |
Les étiquettes du diagramme de pile (L0–L7) sont un modèle mental de regroupement par couche.
La priorité dans le registre utilise un start_level numérique 0–10 — échelle différente,
objectif différent.
Sortie cloud
Micro service vers maillage GraphQL — de bout en bout.
Micro service en conteneur
Le code applicatif ou un micro service plateforme publie des événements typés.
Pont MQTT
N'importe quel client MQTT standard — pas d'adoption de SDK nécessaire.
Passerelle de communication
Uplink MD21 : encodage ASN.1 UPER, optimisé pour la bande passante.
cloud-connect
Relais cloud Munic — exécute le multiplexage, le piggybacking, la compression.
Maillage GraphQL
Point d'entrée client. Référence publique : gateway.munic.io
Le maillage GraphQL est le point d'entrée client — côté cloud, pas côté appareil. Le endpoint de référence public est le portail de documentation développeur.
Déverrouillage développeur
Pont RPC — appelez n'importe quel micro service depuis le cloud.
Le pont RPC expose tout service MOS4 enregistré sur le canal applications.rpc. Accepte du JSON avec itfname, call et payload. Pas de code de protocole ni de câblage au-delà de l'interface du micro service et du service côté cloud.
Déboguer et débloquer
Appelez n'importe quel micro service — y compris les conteneurs — depuis le cloud pour inspecter l'état, déclencher une action ponctuelle ou débloquer une situation rare sur un appareil distant.
Flux hybrides pilotés par IA
Un agent IA ou une couche d'automatisation cloud peut piloter l'appareil via API —
interroger les capteurs, déclencher des actionneurs, charger une nouvelle politique — avec ListServices() retournant le catalogue de services en direct à l'exécution.
RoutingService fait partie de la pile modem, ce n'est pas un micro service séparé. La vue SDK-développeur de la même primitive RPC se trouve sur /fr/platform/sdk.
Comparez MOS4 aux autres approches OS embarqué et plateforme sur la vue comparative.