Plateforme
La couche opérations.
Cinq capacités dont une flotte a besoin après le premier appareil livré — et ce qu'il faut pour maintenir cette flotte en vie sur le terrain. Intégré à la plateforme ; pas un ajout, pas un module tiers, pas le problème du client.
Pilier 1
Observabilité
Métriques, traces et snapshots par micro service en temps réel — compatibles Prometheus et OpenTelemetry nativement.
Métriques automatiques par micro service
Timing RPC, compteurs de requêtes et d'erreurs, débit, événements lifecycle, statut, uptime — aucun code d'instrumentation requis.
Push de métriques personnalisées + score de santé
Tout micro service pousse des métriques personnalisées et un score de santé 0.0–1.0 via l'API observer en-processus.
Snapshot cloud périodique
Un micro service reporter dédié envoie des enregistrements par composant et par processus (CPU, mémoire, descripteurs de fichiers, threads, uptime, chaîne de santé), avec un flush forcé à l'idle, au stop et à l'arrêt d'urgence.
Scrape Prometheus des conteneurs
Le endpoint de métriques de chaque conteneur en cours d'exécution alimente le pipeline de supervision via le moteur de conteneurs léger.
Propagation W3C Trace Context
Traçage distribué entre micro services et processus — aucune modification du code applicatif requise.
Pull distant force-sync
Le cloud ou les outils tirent un snapshot immédiat à la demande, avec limitation de débit.
Pourquoi c'est important. Un appareil de flotte avec une centaine de micro services indépendants émet un ensemble de métriques compatibles Prometheus en quelques minutes après le démarrage ; l'équipe cloud utilise ses tableaux de bord existants.
Comment le registre et l'observer s'intègrent dans l'architecture de la plateforme →
Pilier 2
Sûreté
Quatre niveaux de supervision et une chaîne d'escalade déterministe. Une tâche bloquée, un processus bloqué ou un noyau bloqué ne peut pas faire perdre l'appareil.
Flux de supervision watchdog. Une tâche de micro service pette son checkpoint HealthMonitor en-processus ; les pings de processus alimentent le micro service de politique watchdog parallèlement au HealthMonitor ; la politique émet avertir, redémarrer ou arrêt d'urgence vers le registre, et pette le watchdog matériel Linux ; en cas de blocage, le matériel force un redémarrage système.
graph TD
A[Tâche micro service] -->|petter checkpoint| B[HealthMonitor en-processus]
C[Pings processus] --> D[Micro service politique watchdog]
B --> D
D -->|avertir / redémarrer / arrêt urgence| E[Registre]
D -->|petter| F[Linux /dev/watchdog]
F -->|reset matériel si blocage| G[Redémarrage système] Niveau 1 — HealthMonitor en-processus
Chaque micro service déclare des checkpoints nommés et les pette depuis sa boucle de tâche.
Niveau 2 — Pings de processus
Les processus maître et esclave échangent des pings de santé ; l'état dégradé remonte à la politique.
Niveau 3 — Micro service de politique watchdog
Boucle autonome de 30 secondes, compteur de violations par composant, échelle d'action déterministe : avertir → redémarrer → arrêt d'urgence.
Niveau 4 — Watchdog matériel Linux
Timer petté à intervalle fixe ; si la pile logicielle se bloque, le matériel force un reset.
Hook lifecycle arrêt d'urgence
Chaque micro service dispose d'une courte fenêtre de nettoyage avant le redémarrage. Hooks appelés depuis le registre, pas depuis l'application.
Agrégation des problèmes
Les problèmes identiques sont agrégés en lots classifiés périodiques ou en rafale avant envoi — il est impossible de noyer le cloud sous des doublons.
Arbitre énergétique
Tout micro service peut maintenir un jeton pour différer une transition d'alimentation jusqu'à ce que ce soit sûr ; le moteur attend jusqu'à un timeout configurable que les jetons soient libérés.
Pourquoi c'est important. La chaîne d'escalade est auditable, testable sur banc et fonctionne sans intervention opérateur. Une panne sur le terrain à l'échelle d'une flotte coûte plus que la plateforme elle-même.
Pilier 3
Mises à jour over-the-air
Partitions A/B, paquets delta signés, rollback automatique. Pure Rust, aucun daemon externe, fonctionne sur du matériel modem-class.
Slots rootfs A/B + compteur de boot
Un échec de boot revient au slot précédent sans intervention opérateur.
Paquets delta
Découpage défini par le contenu, déduplication sur plusieurs arbres sources, compression zstd dimensionnée pour les cibles modem-class.
Chaîne cryptographique
Manifeste signé vérifié avant toute écriture flash ; chiffrement optionnel du payload ; contrôles d'intégrité par fichier et de l'image complète.
Compteurs de réessais et de redémarrages persistants
Limite de réessais par fichier, limite de réessais par mise à jour, limite de redémarrages par mise à jour — survit aux coupures de courant, empêche les boucles de redémarrage infinies sur les mises à jour défaillantes.
Deux points d'entrée de transport
Canal de commande cloud et appel direct au micro service.
Deux binaires depuis une seule bibliothèque
Un générateur côté hôte et un applicateur sur l'appareil ; les changements de format se propagent atomiquement.
Pourquoi c'est important. Livrer un firmware, c'est la partie facile ; le rollback sans déplacement physique, c'est la partie difficile.
Faites un rollout OTA avec nous, de bout en bout.
Pilier 4
Contrôle à distance
Un seul canal adresse chaque micro service sur l'appareil. Signaux en direct, journaux en direct, sessions de diagnostic en direct.
Interfaces micro service appelables depuis le cloud
Toute interface de micro service enregistrée est appelable depuis le cloud ou depuis les outils, passthrough JSON ou protobuf, requête de catalogue runtime, erreurs JSON-RPC 2.0, statistiques de latence par appel optionnelles.
Récupération distante de journaux
Filtre par plage de timestamps TAI64 et motif grep/sed, chunks compressés en streaming. Sans SSH, sans SCP, sans outillage côté appareil.
Snapshot d'observabilité à la demande
Tirer un snapshot immédiat avant d'émettre une commande ou une mise à jour, avec limitation de débit.
Surface de protocole véhicule via Multi Stacks
Lecture en direct de tout signal CAN, CAN-FD, DoIP, ISOBUS, J1939, J1708, J1850, J1587, HD-OBD, Modbus, RS-485 en tant que sujet de micro service.
Pourquoi c'est important. Le workflow après-vente est praticable parce que chaque appareil de la flotte expose la même surface de contrôle à distance.
Pilier 5
Cycle de vie
Chaque changement d'état est délibéré. Les redémarrages sont expliqués, les idles sont surchargeables, les mises à jour runtime se déploient sur toute la flotte sans modification du code client.
Registres raison-de-boot + raison-de-réveil
Exposés à chaque micro service (HardReset, SoftReset, WatchdogReset, Ignition, Alarm, RTC, CAN). L'outillage terrain et la surface cloud les lisent pour diagnostiquer chaque redémarrage.
Override-next-idle
Le registre peut substituer le prochain idle naturel par un redémarrage ou un arrêt contrôlé — aucun redémarrage surprise sur le terrain.
Garde uptime maximum
Modèle de redémarrage à deux seuils ciblant la fragmentation de l'allocateur sur les appareils à longue durée de fonctionnement ; la limite douce redémarre au prochain idle, la limite dure force le redémarrage, le garde-boucle brise les cycles redémarrage-idle.
Couches système
Couches runtime partagées épinglées par l'opérateur. Une mise à jour runtime pour toute la flotte est un simple changement de digest dans la config opérateur ; les conteneurs applicatifs client ne sont ni reconstruits ni resoumis.
Configuration des événements de réveil
Masque de réveil configurable (allumage, alarme, RTC) pour que l'appareil dorme pour économiser l'énergie et se réveille sur les bons signaux sur les plateformes qui le supportent.
Pourquoi c'est important. Les opérations de flotte portent rarement sur des défaillances catastrophiques ; elles portent sur des réponses cohérentes à « pourquoi cet appareil a-t-il redémarré la nuit dernière ? » et « comment déployer un correctif de sécurité runtime sur dix mille conteneurs client sans toucher au code client ? » .
Capacité transversale
Remote Care — la vue uptime de la flotte
Les cinq piliers ci-dessus correspondent à la structure de la couche opérations par préoccupation. La même surface, vue de bout en bout comme remédiation, est la page Remote Care — construite pour l'audience ops flotte qui raisonne en immobilisations évitées, pas en piliers.
Quand l'appareil se bloque, vous n'envoyez pas un technicien. Vous envoyez un paquet.
Remote Care est la vue transversale de la couche opérations — trois niveaux de remédiation (diagnostiquer, reconfigurer, remédier), une couche prédictive sur l'appareil, et un journal d'audit sur chaque action. Capacité OS intégrée ; pas un SaaS séparé.
Catalogue
Les sept fiches catalogue derrière la couche
Chaque affirmation ci-dessus correspond à un micro service. Explorez le catalogue pour les interfaces, les specs sources et les points d'intégration.
Architecture de la plateforme — comment le registre et le cycle de vie s'articulent →
Sûreté
Watchdog
Micro service de politique de supervision à quatre niveaux. Boucle autonome de 30 secondes ; escalade déterministe ; intégration du watchdog matériel.
Observabilité
Observer
Reporter de snapshot cloud périodique. Enregistrements par composant et par processus ; flush forcé aux transitions lifecycle ; RPC force-sync.
Sûreté
Sentry
Agrégation des problèmes sur tous les micro services. Porte de cascade au démarrage ; classification périodique ou en rafale ; déduplication avant envoi.
Contrôle à distance
Logs
Récupération distante de journaux. Plage de timestamps TAI64 + filtre grep/sed ; chunks compressés en streaming ; sans SSH, sans SCP.
OTA
Update
OTA à partitions A/B. Paquets delta signés ; découpage défini par le contenu ; chaîne cryptographique ; compteurs de réessais et de rollback.
Cycle de vie
Containers
Moteur de conteneurs léger. Substitution de couches système ; scrape Prometheus par conteneur ; isolation des ressources cgroups v2.
Sûreté + Cycle de vie
Power
Arbitre énergétique ; garde uptime maximum ; configuration des événements de réveil ; override-next-idle ; registres de raison de boot et de réveil.
Questions
Les cinq questions que posent les intégrateurs
Ce qui revient sur chaque appel de découverte technique.
-
Est-ce un rebranding de la conformité, de l'observabilité et de l'OTA ?
Non. La conformité, l'observabilité et l'OTA restent leurs propres pages et concepts. La couche opérations est le chapeau — ce que la plateforme offre à une flotte dès le deuxième jour — et renvoie vers chacune de ces pages pour les détails.
-
Dois-je utiliser chaque pilier ?
Non. Chaque pilier est indépendant. Une équipe peut livrer avec uniquement la supervision sûreté et la chaîne OTA le premier jour, puis activer le contrôle à distance et le snapshot d'observabilité lorsque le back-end cloud est prêt.
-
Cela m'enferme-t-il dans les services cloud hébergés par Munic ?
Non. Le snapshot d'observabilité est compatible Prometheus et OpenTelemetry ; la chaîne OTA fonctionne avec tout endpoint HTTP, HTTPS ou SFTP ; la surface de contrôle à distance parle un schéma JSON documenté. Les back-ends cloud sont interchangeables.
-
En quoi est-ce différent d'exécuter Prometheus + Grafana + un service OTA personnalisé dans des conteneurs ?
Ce n'est pas une pile différente. Ce sont les mêmes protocoles, prépackagés, avec le glue côté appareil déjà en place : intégration du watchdog matériel, flux de partition A/B, vérification de paquets signés, snapshots flushés au lifecycle, escalade déterministe. Le bring-up est ce qui est livré.
-
Comment gardez-vous la page honnête au fil de l'évolution de la plateforme ?
Chaque affirmation sur cette page renvoie à la doc du micro service source ; la CI échoue sur les citations sources périmées ou manquantes. Le catalogue de micro services est la vérité canonique ; cette page en est un index navigable.
Opérez votre flotte sur MOS4.
Un appel découverte de 30 minutes avec l'ingénierie — parcourez votre ligne de coût J+2 et voyez quels piliers la réduisent le plus.