Référence
Glossaire
Définitions courtes du vocabulaire MOS4. Chaque entrée renvoie à la page canonique qui l’explique en détail.
- Micro service
- L’unité de déploiement de MOS4. Un crate Rust autonome annoté avec #[component], déclarant les interfaces protobuf qu’il fournit et requiert, accompagné d’un schéma de configuration (mos.toml) et de son propre pipeline CI. Chaque dépôt supervisé de l’écosystème MOS4 est un micro service.
- Sur le site, les micro services sont aussi désignés comme des composants au sein d’un OS à composants distribués. 52 micro services sont livrés dans le catalogue de production.
- Micro services → Catalogue →
- MCM
- MOS Container Manager — le moteur OCI léger qui exécute le code client aux côtés des micro services. Le runtime de production est crun avec application des ressources via cgroups v2. Quatre profils de montage : SHELL, PYTHON, NATIVE, STATIC.
- Substitution au niveau système : une mise à jour CPython 3.12 se propage à tous les conteneurs Python client via un seul incrément de digest dans system-layers.toml. Enveloppe de budget du conteneur : moins de 5 % CPU/RAM et environ 10 Mo de RSS.
- SDK → Micro services →
- MSP
- Morpheus Signal Processing — un moteur de traitement du signal temps réel basé sur des graphes pour la télémétrie véhicule. Les nœuds sont câblés par des arêtes dans des fichiers .msp.yml ; 226 graphes répartis sur 21 domaines véhicule sont livrés prêts à l’emploi.
- Les graphes s’exécutent sur un runtime async Tokio ciblant le matériel classe modem. Ajouter un nouveau domaine véhicule ne demande qu’un fichier YAML — pas de recompilation Rust. 124 kernels dans l’éditeur visuel.
- Moteurs no-code → Automobile →
- MEP
- MOS Event Processor — un moteur Trigger → Condition → Action configuré en YAML. Les déclencheurs sont des changements de clé en base, des événements nommés provenant de l’EventBus, ou des planifications cron (UTC). Les conditions sont évaluées avant le déclenchement de l’action.
- Les actions peuvent appeler n’importe quel micro service MOS4 (écrire une clé, émettre un événement, effectuer un appel de service). Hot reload : les nouvelles politiques sont validées et permutées avec drainage en vol des règles — aucun redémarrage de processus requis. Pool parallèle de workers de règles avec détection de conflits. Cadre produit : du point de vue du product owner, MEP exécute des politiques en machine à états sur l’appareil. La machine à états *est* la politique YAML — il n’y a pas de runtime de machine à états séparé. La primitive T·C·A est la vue ingénierie du même artefact.
- Moteurs no-code → Page MEP →
- EventBus
- Le canal interne de distribution d’événements nommés de MOS4. Les composants publient des événements par nom ; les déclencheurs MEP et le forwarding de topics DDS mos-ros2 consomment depuis l’EventBus. S’écrit en un seul mot avec E majuscule et B majuscule.
- Ce n’est pas une file de messages — les événements sont éphémères et nommés. Pas de rétention, pas de replay.
- Moteurs no-code → Micro services →
- Multi Stacks
- Le moteur canonique no-code de communication véhicule et IoT industriel. Couvre CAN, CAN-FD, ISO-TP, DoIP, K-Line, UDS, J1939, J1587/J1708, J1850 VPW/PWM, ISOBUS, Modbus RTU/TCP et CANopen — même moteur, même DSL JSON, même catalogue de piles par défaut.
- Modèle déclaratif — quatre points : (1) Protocole — quel transport et quel framing (CAN, J1939, UDS, ISOBUS, Modbus, …). (2) Question + Réponse — quelle commande/PID/PGN/registre envoyer et comment décoder la réponse. (3) Broadcast — gestion des messages en lecture seule et non sollicités (sniffing passif, décodage événementiel sans requête). (4) Stratégie — quelles séquences exécuter et quand ; périodique en sortie de boîte, avancé via composition avec MSP (déclencheurs pilotés par signal) ou MEP (séquences pilotées par événement). 22 piles par défaut prêtes pour la production validées à chaque push CI.
- Page Multi Stacks → Automobile →
- AI pipeline
- Le pipeline IA on-device utilise mos-roi-shader et mos-ai-runtime. Les clients déclarent un modèle ONNX/TFLite et configurent le pipeline en TOML. mos-roi-shader extrait les régions d’intérêt via le GPU (wgpu/Vulkan) et produit des dmabufs de tenseurs prêts pour le NPU. mos-ai-runtime pilote l’inférence NPU. Aucun octet de pixel ne traverse le CPU dans le chemin d’inférence — l’invariant dma-buf tient de bout en bout.
- La conversion automatique ONNX vers TFLite est disponible. Configuré en TOML ; déployé en OTA. Le silicium classe IA atteint jusqu’à environ 100 TOPS (famille QCS).
- Page AI Funnel → Vision →
- ROI Shader
- Un processus GPU (wgpu/Vulkan) qui extrait les régions d’intérêt des frames caméra et produit des dmabufs de tenseurs prêts pour le NPU. Importe des frames dmabuf depuis mos-camera-capture, exporte des topics de tenseurs consommés par mos-ai-runtime.
- Aucune donnée pixel ne traverse le CPU : le CPU pilote le command buffer GPU, pas le pipeline pixel. Sur la variante classe IA MIPI-CSI : ROI Vulkan portable. Sur la variante classe IA avec pont sérialiseur : zero-copy dmabuf vers NPU via la mémoire GPU partagée.
- Vision → AI Funnel →
- MD21
- Protocole de télémétrie breveté Munic. Protocole binaire ASN.1 UPER-encodé sur TCP/TLS pour la communication bidirectionnelle entre appareil IoT et serveur. Utilisé par mos-communication-gateway et mos-update (comme canal de commande OTA).
- Plus efficace en bande passante que les protocoles alternatifs pour la télémétrie dense sur des liens cellulaires facturés — via multiplexage, piggyback, compression et encodage ASN.1.
- Connectivité → Catalogue →
- classe modem
- Niveau le plus bas de l’échelle silicium MOS4 — typiquement un SoC monocœur avec modem cellulaire. Exécute MOS4 avec un seul graphe de traitement du signal à 28,4 Mo de RSS en régime établi et 1,6 s de boot avant que la première application soit prête.
- Minimum : processeur applicatif monocœur, environ 800 MHz, 256 Mo de RAM.
- Niveaux matériel → munic.io →
- classe compute
- Niveau intermédiaire de l’échelle silicium MOS4 — ajoute la capture multi-caméras, le moteur de politiques en machine à états MEP (T·C·A sous le capot) et le moteur de communication Multi Stacks à 16 protocoles au-dessus de la base classe modem.
- Un seul OS — pas de branche par niveau. Munic porte ; l’OEM choisit le niveau selon le produit.
- Niveaux matériel → Multi Stacks →
- classe IA
- Niveau supérieur de l’échelle silicium MOS4 — ajoute l’inférence NPU, le shader ROI (Vulkan) et le pipeline IA on-device complet. Référence : jusqu’à environ 100 TOPS sur le niveau classe IA.
- Variante MIPI-CSI : inférence NPU TFLite via délégué du fournisseur de silicium. Variante avec pont sérialiseur : zero-copy dmabuf vers NPU via mémoire GPU partagée.
- Niveaux matériel → AI Funnel →
- start_level
- Priorité de registre — valeur numérique de 0 à 10 qui détermine l’ordre dans lequel les micro services sont démarrés par le superviseur MOS4. Les valeurs plus basses démarrent en premier. À ne pas confondre avec les couches L0–L7 du diagramme d’architecture, qui sont un modèle mental de la structure plateforme.
- L0–L7 est la convention du diagramme d’architecture (matériel en L0, application en L7). start_level 0–10 est le champ d’ordonnancement du registre runtime. Ce sont deux concepts distincts.
- Architecture → Micro services →
- CRA-ready
- Conformité alignée avec le Cyber Resilience Act de l’UE (applicable à partir de 2027). MOS4 livre un mapping CRA article par article (Annexe I §1, §2, Art. 13, Art. 14), un SBOM CycloneDX, cargo audit / geiger / deny, semgrep et un processus PSIRT public à chaque release.
- UNECE R155/R156 : aligné en interne. Évaluation formelle par programme. L’OEM ne documente que sa couche applicative.
- Conformité → Pour la posture de conformité →
- SBOM (CycloneDX)
- Software Bill of Materials au format CycloneDX — inventaire lisible par machine de chaque dépendance d’une release. Exigé par le CRA de l’UE et livré avec chaque release MOS4. Téléchargeable depuis le portail client.
- Généré par cargo cyclonedx à chaque commit sur l’ensemble des 52 micro services. L’arbitrage CVE via cargo audit est bloquant ; la publication du SBOM est informationnelle.
- Conformité → Whitepapers →
- proto interface
- Un fichier .proto définissant le contrat typé de service-call entre micro services. Le repo mos-interfaces contient 89 fichiers .proto couvrant des services dans les domaines connectivité, positionnement, vision, alimentation et données.
- Chaque micro service importe depuis ce registre unique partagé. Pas de négociation de format fil par repo. mos-codegen génère des stubs typés pour chaque SDK de langage à partir de ces fichiers .proto.
- Architecture → Micro services →
- Autonomie en site privé
- Opération de véhicule autonome en site contrôlé — ferme, aérodrome, mine, carrière, manutention portuaire, terrain de golf, dépôt. Exclut par conception l’opération sur la voie publique. MOS4 supporte le runtime, les nœuds ROS2 hébergés, le bus machine, le silicium de perception, la télémétrie et le remote care ; le client livre l’application d’autonomie.
- Pas d’homologation NHTSA. Pas de dépendance à une carte HD. Pas de pile d’autonomie L4 fournie. L’OEM possède la perception, la planification, le contrôle et le safety case pour la machine intégrée.
- Véhicules autonomes → AI Vision →
- AI Cam (boîtier OEM)
- Boîtier caméra mono-optique à installation fixe avec inférence IA on-device, marqué par l’OEM, fonctionnant sur la plateforme MOS4. Utilisé pour l’inspection industrielle, le périmètre, l’anti-vol retail et la vision opérateur sur engins lourds. Distinct d’une dashcam, qui est embarquée véhicule et bi-optique.
- Caméras IA → AI Vision →
- Dashcam (OEM)
- Caméra embarquée bi-optique avec ADAS, DMS et anonymisation RGPD en direct sur le runtime MOS4. L’une des trois formes de déploiement de la pile vidéo MOS4 — aux côtés du boîtier caméra OEM et du réseau multi-caméras de flotte.
- Caméras IA → AI Vision →
- Remote Care
- Capacité intégrée de l’OS MOS4 couvrant la reconfiguration à chaud et la remédiation distante signée. Câblée dans chaque appareil. Pertinente pour tout programme où une immobilisation coûte plus cher que l’appareil.
- Deux niveaux de remédiation : reconfigurer à distance (hot-reload MSP / MEP / géorepérage, environ dix secondes de bout en bout) et remédier à distance (OTA A/B signé, reboot distant, re-flash distant). Chaque action est signée, conditionnée et journalisée en audit. Pour les sessions ECU interactives — lire, réinitialiser, pousser des calibrations, attester et reflasher — voir Remote Diagnostic. Distinct d’ekkofleet, le SaaS de flotte clé en main qui utilise MOS4 comme plateforme.
- Page Remote Care → Page Remote Diagnostic → Couche Opérations →
- Remote Diagnostic
- Session de diagnostic interactive pilotée depuis le cloud sur le même moteur que la télémétrie autonome. Le cloud ouvre une session, pilote le bus du véhicule, lit l’état des ECU, réinitialise les DTC, pousse des calibrations, atteste et reflashe le firmware, puis ferme.
- Le mode d’opération compte : Multi Stacks est autonome (l’appareil décide quoi demander, le cloud reçoit), Remote Diagnostic est interactif (le cloud décide, l’appareil actionne). Mêmes protocoles (UDS, J1939, ISOBUS, Modbus, J2534-passthru), même bus physique. Les verrouillages de sécurité ne sont pas contournables depuis la surface Remote Diagnostic ; le reflash est signé et attesté ; un revert basé sur le bootcount restaure le firmware précédent en cas d’échec de reflash. Chaque action modifiant l’état porte une autorisation signée par action et une entrée d’audit log.
- Page Remote Diagnostic → Multi Stacks (contrepartie autonome) →
- Uplink de télémétrie
- Le chemin de données appareil-vers-cloud sécurisé par MD21. Signé, attesté et partagé par tous les produits MOS4. Sous-tend Remote Care et toute couche SaaS de flotte posée au-dessus de MOS4.
- MD21 est breveté Munic ; face à MQTT5 / SOTA, il livre une consommation de données plus faible et des garanties d’attestation plus fortes. Le pont traduit les événements EventBus depuis et vers MQTT pour les clients dont le back-end est déjà façonné MQTT.
- Connectivité → Remote Care →
- OBD-II
- On-Board Diagnostics II (SAE J1979) — l’interface de diagnostic standardisée imposée sur les voitures particulières vendues en Amérique du Nord depuis 1996 et dans l’UE depuis 2001. Définit un connecteur DLC 16 broches, un ensemble de PID (Parameter Identifiers) standard et les cinq protocoles de transport (ISO 9141-2, SAE J1850 VPW/PWM, CAN ISO 15765-4, KWP2000).
- Multi Stacks → Preuves →
- UDS
- Unified Diagnostic Services (ISO 14229) — la norme internationale pour les sessions de diagnostic au niveau ECU. Définit les services de lecture/écriture de records de données, de réinitialisation d’ECU, d’exécution de routines et de flashage du firmware. Utilisé par MOS4 Remote Diagnostic et Multi Stacks.
- Multi Stacks → Remote Diagnostic →
- J1939
- SAE J1939 — le protocole réseau pour véhicules lourds bâti sur CAN. Utilise les Parameter Group Numbers (PGN) et Suspect Parameter Numbers (SPN) pour adresser les ECU moteur, transmission et essieu sur camions, autobus et engins off-highway.
- Multi Stacks → Automobile →
- PGN
- Parameter Group Number — l’unité d’adressage J1939 qui identifie un groupe d’éléments de données liés (par exemple, régime moteur, température de liquide de refroidissement). Chaque PGN se mappe à un ou plusieurs SPN.
- Multi Stacks →
- SPN
- Suspect Parameter Number — l’identifiant individuel de signal au sein d’un PGN J1939 (par exemple, SPN 190 = régime moteur en RPM). Multi Stacks décode les SPN via la pile JSON déclarative.
- Multi Stacks →
- ISOBUS
- ISO 11783 — le protocole réseau de machinerie agricole bâti sur CAN. Utilisé pour la communication outil-tracteur (semoirs, pulvérisateurs, moissonneuses). MOS4 lit les données ISOBUS en mode lecture seule via Multi Stacks.
- Multi Stacks → Automobile →
- J2534
- SAE J2534 PassThru — l’API standard qui permet à une application PC de communiquer avec les ECU du véhicule via un appareil pass-through connecté au bus véhicule. MOS4 Remote Diagnostic implémente le mode J2534-passthru pour le flashage et la calibration d’ECU pilotés depuis le cloud.
- Remote Diagnostic →
- DTC
- Diagnostic Trouble Code — un code à cinq caractères (par exemple P0300) stocké dans un ECU lorsqu’un défaut est détecté. MOS4 lit, journalise et peut réinitialiser à distance les DTC via les piles UDS et OBD-II.
- Multi Stacks → Remote Diagnostic →
- ECU
- Electronic Control Unit — un calculateur embarqué gérant un système véhicule spécifique (moteur, transmission, freins, carrosserie). MOS4 communique avec les ECU via CAN/UDS/J1939 et peut les reflasher à distance via OTA signé.
- Multi Stacks → Remote Diagnostic →
- SAE J1850
- SAE J1850 — un protocole de transport OBD-II hérité (VPW à 10,4 kbps, PWM à 41,6 kbps) utilisé sur les véhicules nord-américains avant que CAN ne devienne obligatoire. Supporté dans Multi Stacks pour couvrir le parc plus ancien.
- Multi Stacks →
- PID
- Parameter Identifier — l’équivalent OBD-II d’une adresse de donnée. Les PID Mode 01 rapportent les valeurs capteur en direct (par exemple, PID 0C = régime moteur). Les piles déclaratives Multi Stacks référencent les PID par numéro et les décodent en signaux nommés.
- Multi Stacks →
- MQTT
- Message Queuing Telemetry Transport — un protocole publish/subscribe léger très utilisé dans l’IoT. MOS4 inclut un broker MQTT in-process pour que les services client puissent publier et s’abonner sans broker externe. L’uplink de télémétrie utilise MD21, pas MQTT, pour le transport appareil-vers-cloud.
- Connectivité →
- eUICC
- Embedded Universal Integrated Circuit Card — un SIM soudé, programmable à distance, qui permet de basculer de profil over-the-air sans échange physique de SIM. Couvert par deux normes GSMA : SGP.22 (Consumer) pour les appareils avec interaction utilisateur, et SGP.02 (M2M) pour les déploiements flotte et embarqués gérés par l’opérateur réseau.
- Connectivité → Niveaux matériel →
- GSMA SGP.22
- La norme GSMA de gestion de profil eUICC Consumer — encadre le provisioning SIM à distance pour les appareils grand public où l’utilisateur final contrôle la sélection de profil. Également appelée eUICC Consumer.
- Connectivité →
- GSMA SGP.02
- La norme GSMA de gestion de profil eUICC M2M — encadre le provisioning SIM à distance pour les déploiements machine-to-machine et flotte gérés par un opérateur ou une entreprise. Également appelée eUICC M2M.
- Connectivité →
- LPWA
- Low-Power Wide-Area network — une classe de technologies sans fil (NB-IoT, LTE-M, LoRaWAN) conçues pour des appareils IoT alimentés sur batterie qui envoient de petits payloads peu fréquemment sur de longues distances. Les micro services de connectivité MOS4 prennent en charge les modems LPWA aux côtés du cellulaire standard.
- Connectivité →
- GNSS
- Global Navigation Satellite System — la famille des systèmes de positionnement par satellite (GPS, GLONASS, Galileo, BeiDou). MOS4 inclut des micro services GNSS dédiés pour la position, la vitesse, le cap et le temps.
- Niveaux matériel → Preuves →
- ESF
- External Sensor Fusion — une fonctionnalité de récepteur GNSS qui fusionne les mesures satellite avec les données d’un capteur inertiel (accéléromètre, gyroscope) pour maintenir la précision de position lors des coupures satellite (tunnels, canyons urbains). MOS4 expose les données ESF via les micro services GNSS.
- Niveaux matériel →
- RTK
- Real-Time Kinematic GNSS — une technique de correction différentielle qui atteint une précision de positionnement centimétrique en comparant les mesures de phase de porteuse avec une station de référence. Utilisé dans les déploiements MOS4 pour l’agriculture de précision et la planification de trajectoire des véhicules autonomes.
- Véhicules autonomes → Niveaux matériel →
- ELD
- Electronic Logging Device (FMCSA 49 CFR Part 395) — un appareil imposé par un mandat fédéral américain qui enregistre les heures de service du conducteur en lisant les données moteur depuis l’ECU du véhicule. MOS4 inclut un micro service conforme ELD qui gère la journalisation des heures de service via J1939/OBD-II.
- Multi Stacks → Automobile →
- OTA
- Over-The-Air firmware update — la capacité de livrer des mises à jour logicielles signées sur un appareil sans accès physique. MOS4 livre un système OTA A/B signé avec revert basé sur le bootcount et re-flash distant, couvert par Remote Care.
- Remote Care → Couche Opérations →
- LCV
- Light Commercial Vehicle — le segment couvrant les fourgonnettes, pick-ups et petits camions (typiquement moins de 3,5 t de PTAC). Un segment de marché primaire pour les déploiements télématiques MOS4.
- Automobile →
- CRA
- EU Cyber Resilience Act — règlement européen horizontal qui applique des exigences obligatoires de cybersécurité aux produits comportant des éléments numériques, effectif en 2027. MOS4 livre un SBOM aligné CRA, la chaîne d’outils cargo audit/geiger/deny, l’analyse statique semgrep et un processus PSIRT public.
- Conformité → CRA-ready →
- SBOM
- Software Bill of Materials — un inventaire lisible par machine de chaque dépendance logicielle d’une release. MOS4 génère un SBOM CycloneDX à chaque commit sur tous les micro services. Exigé par le CRA de l’UE ; téléchargeable depuis le portail client.
- Conformité → SBOM (CycloneDX) →
- CycloneDX
- Une norme SBOM ouverte (OWASP) qui définit un format XML/JSON lisible par machine pour les inventaires de composants logiciels. MOS4 utilise cargo cyclonedx pour générer des SBOM CycloneDX à chaque release.
- Conformité → SBOM (CycloneDX) →
- PSIRT
- Product Security Incident Response Team — la fonction organisationnelle qui reçoit, trie et divulgue publiquement les vulnérabilités de sécurité. MOS4 opère un processus PSIRT public dans le cadre de sa posture de sécurité alignée CRA.
- Conformité →
- SAST
- Static Application Security Testing — analyse automatisée du code source à la recherche de vulnérabilités de sécurité sans exécution du programme. La CI MOS4 exécute les règles semgrep SAST à chaque commit, avec blocage du merge en cas de violation.
- Conformité →
- NPU
- Neural Processing Unit — un bloc silicium dédié optimisé pour les opérations matricielles utilisées dans l’inférence de réseaux de neurones. Le matériel classe IA de MOS4 expose le NPU au micro service mos-ai-runtime via un chemin dmabuf zero-copy depuis le shader ROI GPU.
- AI Funnel → Niveaux matériel →
- TOPS
- Tera Operations Per Second — l’unité utilisée pour évaluer le débit d’inférence d’un NPU. Le matériel classe IA dans MOS4 atteint jusqu’à environ 100 TOPS sur le niveau supérieur.
- Niveaux matériel → AI Funnel →
- ADAS
- Advanced Driver-Assistance Systems — la classe des fonctions de sécurité embarquées (alerte de franchissement de ligne, alerte de collision frontale, détection d’angle mort) délivrées par l’inférence vision on-device. MOS4 supporte le déploiement de modèles ADAS via le pipeline IA on-device.
- AI Vision → Caméras IA →
- DMS
- Driver Monitoring System — un système de sécurité basé sur la vision qui détecte la distraction, la fatigue ou l’absence du conducteur. Déployé en modèle ONNX/TFLite sur le matériel classe IA MOS4 via le pipeline IA on-device.
- AI Vision → Caméras IA →
- GMSL2
- Gigabit Multimedia Serial Link 2 — un standard d’interface caméra sérialiseur/désérialiseur capable de transporter de la vidéo haute résolution sur un unique câble coaxial ou paire torsadée blindée. Utilisé sur le matériel classe IA MOS4 pour les installations multi-caméras en flotte.
- AI Vision → Niveaux matériel →
- MIPI-CSI
- MIPI Camera Serial Interface — l’interface caméra courte distance standard utilisée sur les SoC embarqués. MOS4 supporte la capture caméra MIPI-CSI sur matériel classe IA, alimentant les frames dans le shader ROI GPU et le pipeline d’inférence NPU.
- AI Vision → Niveaux matériel →
- RAG
- Retrieval-Augmented Generation — une architecture IA qui augmente un modèle de langage avec une étape de récupération sur un corpus documentaire, afin que les réponses soient ancrées dans le contenu récupéré plutôt que dans les seuls poids du modèle. Utilisé dans les interfaces conversationnelles on-device de MOS4.
- AI Funnel →
- STT
- Speech-To-Text — la conversion d’audio parlé en transcription texte. MOS4 exécute des modèles STT on-device via le runtime IA pour les interfaces de commande vocale et l’interaction conducteur.
- AI Funnel →
- TTS
- Text-To-Speech — la conversion de texte en audio de parole synthétisé. Utilisé dans les interfaces conversationnelles on-device MOS4 pour le retour vocal aux opérateurs.
- AI Funnel →
- WER
- Word Error Rate — la métrique standard pour évaluer la précision de la reconnaissance vocale, calculée comme (substitutions + insertions + suppressions) / nombre de mots de référence. Plus bas, mieux c’est.
- AI Funnel →
- ROS2
- Robot Operating System 2 — un framework middleware open-source de robotique fournissant une communication publish/subscribe, l’abstraction matérielle et l’outillage pour les systèmes autonomes. MOS4 héberge des nœuds ROS2 via mos-ros2, en pontant les topics DDS vers l’EventBus MOS4.
- Véhicules autonomes →
- SDLC
- Software Development Life Cycle — le processus structuré couvrant les exigences, la conception, l’implémentation, la vérification et la maintenance. La CI MOS4 applique des gardes de sécurité et de qualité à chaque étape du SDLC via le template partagé ci-gamma.
- Conformité →
- JTBD
- Jobs To Be Done — un cadre de pensée produit qui formule les besoins utilisateur comme les « jobs » qu’une personne cherche à accomplir dans un contexte donné. Utilisé en interne chez Munic pour cadrer les fonctionnalités plateforme.
Référence de priorité de registre
start_level 0–10 : ordre de démarrage du registre.
start_level est un champ de priorité de registre, pas une étiquette de couche d’architecture. La pile d’architecture utilise L0–L7 comme modèle mental — ce sont des conventions distinctes.
| Plage de niveau | Rôle | Exemples de micro services |
|---|---|---|
| 0–2 | Abstraction matérielle et BSP | modem, alimentation, capteurs |
| 3–4 | Services plateforme | OTA, configuration, observabilité |
| 5–6 | Moteurs de domaine | Multi Stacks, MSP, MEP, runtime IA |
| 7–8 | Couche applicative | micro services client, conteneurs |
| 9–10 | Services à liaison tardive | add-ons optionnels |