Puis-je exécuter Zephyr aux côtés de MOS4 ?

Oui — de nombreux déploiements utilisent Zephyr sur un co-processeur (un MCU qui gère les interruptions CAN temps réel déterministes) et MOS4 sur le cœur applicatif. Zephyr assume la fonction noyau ; MOS4 gère les services, l’OTA et l’intégration de flotte au-dessus de la frontière noyau/userspace Linux.

MOS4 nécessite-t-il Linux ?

Oui. MOS4 est un runtime applicatif de classe Linux. La cible minimale est un processeur applicatif de classe modem qui exécute un noyau Linux. Pour les programmes MCU-only, Zephyr ou FreeRTOS sont le bon choix.

En quoi le niveau silicium diffère-t-il ?

Zephyr cible des composants de classe MCU (cœurs de microcontrôleurs 32 bits, RISC-V et équivalents). MOS4 démarre sur des processeurs applicatifs de classe modem capables d’exécuter Linux et monte jusqu’au matériel de classe IA. Ce sont des classes matérielles différentes avec des primitives OS différentes — les empreintes ne sont pas comparables.

Où Zephyr s’arrête-t-il et où MOS4 commence-t-il ?

À la frontière noyau/userspace sur un SoC de classe Linux. Zephyr ne fournit pas de superviseur de micro services, d’OTA flotte, de pile d’observabilité ou de stacks de protocoles véhicule au niveau applicatif — ce sont des primitives MOS4.

Quels sont les chiffres MOS4 sur silicium de classe modem ?

28,4 Mo de RSS en régime établi, 1,6 s jusqu’au premier service applicatif prêt, 200 ms de cold-start de composant sur le profil de référence de classe modem. Ce sont des chiffres absolus pour cette classe matérielle — pas une comparaison avec Zephyr, qui s’exécute sur une classe d’OS entièrement différente.

Quand Zephyr reste-t-il le bon choix ?

Pour les cœurs de microcontrôleurs 32 bits, les MCU RISC-V ou toute cible bare-metal ou RTOS. Dès que la latence ISR déterministe sub-milliseconde est la contrainte principale et qu’un noyau Linux n’est pas disponible ou nécessaire, Zephyr est la bonne réponse.

Comparatif

MOS4 vs Zephyr

L’axe de comparaison est la classe silicium, pas le nombre de fonctionnalités. Zephyr est un noyau temps réel de classe MCU. MOS4 est un runtime applicatif Linux embarqué. Là où Zephyr s’arrête, MOS4 commence.

Parler à l’ingénierie Lire l’architecture

Deux barres horizontales empilées : la barre basse MCU/Zephyr, la barre haute Linux/MOS4 — une pulsation ambrée traverse la frontière

Classe silicium

Domaines différents, silicium différent.

flowchart TB
  subgraph MOS4["MOS4 — runtime applicatif (SoC classe Linux)"]
    M1[Superviseur de composants · EventBus · OTA]
    M2[obdstacks-v2 · GNSS · modem · inférence IA]
    M3[Observabilité · mos-update · conteneurs]
  end
  subgraph Linux["Noyau Linux + userland"]
  end
  subgraph Zephyr["Zephyr — RTOS pour MCU"]
    Z1[Tâches · IPC · drivers · ordonnanceur temps réel]
  end
  MOS4 --> Linux
  Zephyr -."IPC co-processeur (SubscribeCanFrames)".-> MOS4

Modèle de coexistence : Zephyr sur le co-processeur MCU gère le travail temps réel déterministe (interruption CAN sub-milliseconde) ; MOS4 sur le cœur applicatif Linux reçoit les trames décodées via le service de streaming SubscribeCanFrames sur le lien inter-processeurs et gère les services, l’OTA flotte et l’observabilité.

Côte à côte

Comparaison des capacités.

Classe silicium Zephyr Classe MCU : cœurs de microcontrôleurs 32 bits, RISC-V et autres cibles bare-metal. Latence ISR sub-milliseconde. MOS4 Processeur applicatif de classe Linux (de classe modem à classe IA). Plancher minimal : processeur applicatif mono-cœur à 800 MHz ou plus, 256 Mo de RAM.

Système d’exploitation Zephyr Noyau RTOS : ordonnanceur temps réel, threading coopératif et préemptif, latence d’interruption déterministe. MOS4 Runtime applicatif de classe Linux au-dessus de la frontière noyau/userspace. Pas un noyau ; dépend du noyau Linux fourni par l’image.

Langages Zephyr C, C++, Rust limité via les bindings Zephyr Rust. MOS4 Micro services Rust natifs. Les conteneurs OCI hébergent Python, Rust, Go, C, C++ et des nœuds ROS2.

Superviseur applicatif Zephyr Ordonnanceur de tâches noyau. Pas de superviseur de micro services au niveau applicatif. MOS4 MOS4 : démarrage ordonné par dépendances, on_start/on_stop/hot-swap, watchdog par composant, EventBus inter-processus.

Protocoles véhicule Zephyr BSP par carte. API driver CAN disponible. Les piles de protocoles au niveau applicatif requièrent des bibliothèques tierces ou une implémentation custom. MOS4 obdstacks-v2 : 16 protocoles (CAN, CAN-FD, DoIP, UDS, J1939, ISOBUS, et plus) dans un seul runtime via des fichiers de stack JSON déclaratifs.

OTA flotte Zephyr MCUmgr ou SUIT pour les mises à jour firmware MCU. Pas de service 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.

Observabilité Zephyr Sous-système de logging. Pas de pile d’observabilité au niveau flotte. MOS4 Métriques Prometheus par composant, export OpenTelemetry OTLP, batching d’erreurs structurées mos-sentry. Pile Grafana/OTLP opérée par le client.

Traitement du signal Zephyr Filtrage en ISR en C. Implémentation par projet. MOS4 MSP : moteur de graphe de flux de données configuré en YAML, 226 graphes sur 21 domaines véhicule. Validation hors device avec la CLI msp-run et des entrées CSV. Pas de recompilation Rust pour couvrir un nouveau domaine.

Source — colonne Zephyr depuis zephyrproject.org ; MOS4 depuis /fr/architecture.

Note : les empreintes RAM et flash ne sont pas comparées ci-dessus. Zephyr et MOS4 s’exécutent sur des classes silicium différentes avec des primitives OS différentes. Comparer les empreintes serait le mauvais axe.

FAQ

Les questions qu’on nous pose le plus.

Puis-je exécuter Zephyr aux côtés de MOS4 ?

Oui — de nombreux déploiements utilisent Zephyr sur un co-processeur (un MCU qui gère les interruptions CAN temps réel déterministes) et MOS4 sur le cœur applicatif. Zephyr assume la fonction noyau ; MOS4 gère les services, l’OTA et l’intégration de flotte au-dessus de la frontière noyau/userspace Linux.
MOS4 nécessite-t-il Linux ?

Oui. MOS4 est un runtime applicatif de classe Linux. La cible minimale est un processeur applicatif de classe modem qui exécute un noyau Linux. Pour les programmes MCU-only, Zephyr ou FreeRTOS sont le bon choix.
En quoi le niveau silicium diffère-t-il ?

Zephyr cible des composants de classe MCU (cœurs de microcontrôleurs 32 bits, RISC-V et équivalents). MOS4 démarre sur des processeurs applicatifs de classe modem capables d’exécuter Linux et monte jusqu’au matériel de classe IA. Ce sont des classes matérielles différentes avec des primitives OS différentes — les empreintes ne sont pas comparables.
Où Zephyr s’arrête-t-il et où MOS4 commence-t-il ?

À la frontière noyau/userspace sur un SoC de classe Linux. Zephyr ne fournit pas de superviseur de micro services, d’OTA flotte, de pile d’observabilité ou de stacks de protocoles véhicule au niveau applicatif — ce sont des primitives MOS4.
Quels sont les chiffres MOS4 sur silicium de classe modem ?

28,4 Mo de RSS en régime établi, 1,6 s jusqu’au premier service applicatif prêt, 200 ms de cold-start de composant sur le profil de référence de classe modem. Ce sont des chiffres absolus pour cette classe matérielle — pas une comparaison avec Zephyr, qui s’exécute sur une classe d’OS entièrement différente.
Quand Zephyr reste-t-il le bon choix ?

Pour les cœurs de microcontrôleurs 32 bits, les MCU RISC-V ou toute cible bare-metal ou RTOS. Dès que la latence ISR déterministe sub-milliseconde est la contrainte principale et qu’un noyau Linux n’est pas disponible ou nécessaire, Zephyr est la bonne réponse.

Décidez d’abord la classe silicium.

Un appel de 30 minutes avec l’ingénierie. Nous dimensionnons le SoC ensemble — classe MCU, classe modem Linux, classe compute ou classe IA.

Parler à l’ingénierie Glossaire