Plateforme · Connectivité
Du modem au cloud, typé tout du long.
Tous les grands modems 2G–5G + LPWA, backend WiFi détecté à l'exécution, rôle central BLE, serveur et client DHCP par interface, liaison cloud multi-protocole, et un résolveur DNS SRV minimal — chaque couche typée, observable et pilotée par config.
Métriques clés
Les chiffres qui dimensionnent la pile.
Cellulaire
Tous les grands modems — axé capacités.
Tous les grands modèles de modem, 2G → 5G + LPWA
La pile modem charge les bibliothèques fournisseur à l'exécution. La couverture comprend 2G, 3G, 4G LTE, 5G, Cat-M1 (LTE-M) et NB-IoT — IPv4 et IPv6. Ajouter un nouveau module cellulaire est un échange de bibliothèque plus une mise à jour de config — pas de recompilation de micro service.
eUICC Consumer + eUICC M2M dans les boîtiers scellés
Gestion de profil eUICC GSMA SGP.22 v2.2 : téléchargement, activation, désactivation, suppression et récupération — sans micro service de gestion eUICC séparé. Compilé conditionnellement — n'ajoute aucune surcharge sur les builds à SIM physique. Le même binaire est livré aux deux variantes matérielles.
Routage IP et NAT
Le routage IP, NAT/MASQUERADE et le transfert IP sont gérés par le micro service modem
via RoutingService — pas un micro service séparé.
Gestion thermique logicielle
Pour les modules sans zones thermiques au niveau firmware, polling côté hôte avec actions graduées : log → réduction MTU → radio off → arrêt.
WiFi
WiFi — double backend, un seul binaire.
Le micro service WiFi lit l'arbre de périphériques au démarrage et sélectionne le backend sans
aucun indicateur de compilation. Les modes AP et STA basculent à l'exécution via SetMode .
| Backend | Modes | Bandes de fréquence | ScanNetworks |
|---|---|---|---|
| AP+STA double bande | AP + STA | 2,4 GHz + 5 GHz | Oui |
| AP+STA 2,4 GHz | AP + STA | 2,4 GHz | Non pris en charge |
Sur les plateformes où WiFi et BT partagent un rail d'alimentation radio, le micro service Bluetooth s'abonne aux événements d'alimentation et suspend/reprend l'adaptateur BT automatiquement. Les consommateurs BLE n'ont pas besoin de connaître la coexistence WiFi.
Auto-guérison à 3 niveaux
Escalade : L1 redémarrage logiciel → L2 cycle radio rfkill → L3 redémarrage complet du micro service. Quand L3 est épuisé, le micro service arrête de nourrir le watchdog MOS, déclenchant la récupération par le superviseur.
WifiService à 7 méthodes
SetMode, GetStatus, GetConnectedStations, StreamEvents, GetConfig, UpdateConfig, ScanNetworks — tous typés sur le plan de transport MOS4.
Reconfiguration à l'exécution
UpdateConfig reconfigure un AP en fonctionnement sans stop/restart. SetMode bascule AP↔STA à l'exécution. Configuration no-code via politique
TOML. Voir les moteurs no-code pour la politique de connectivité
pilotée par TOML.
Bluetooth
Bluetooth — rôle central BLE, multi-puce.
Toutes les grandes familles Bluetooth
Famille de puce détectée automatiquement depuis l'arbre de périphériques au démarrage. Plusieurs familles Bluetooth prises en charge — intégrées compute-class et variantes co-processeur famille Wi-Fi. BT Classic et BLE tous deux disponibles.
Wake-on-BT (co-processeur famille Wi-Fi)
Sur les puces co-processeur famille Wi-Fi, l'entrée en veille bascule vers un mode BLE interne. Une écriture BLE sur la caractéristique de réveil déclenche la broche wake ; l'hôte reçoit un événement de réveil sur le bus d'événements — pas de polling requis.
DHCP
Serveur et client DHCP par interface.
Les instances serveur et client DHCP s'exécutent indépendamment sur n'importe quel nombre d'interfaces réseau simultanément — serveur AP WiFi, client Ethernet amont et interface de diagnostic sur le même device en même temps.
Rôle par interface
Attribuer un rôle serveur ou client indépendamment par interface. L'interface AP WiFi exécute un serveur DHCP ; l'interface Ethernet amont exécute un client ; l'interface de diagnostic dessert son propre pool de baux — tous simultanément.
8 méthodes RPC
Surface API typée complète : démarrage/arrêt serveur et client, mise à jour de la config serveur, interrogation de l'état des baux et streaming d'événements — tous accessibles sans commandes shell ni redémarrages de fichier config.
Reconfiguration à l'exécution + persistance des baux
UpdateServerConfig reconfigure un serveur DHCP en fonctionnement sans stop/restart.
L'état des baux persiste à travers les redémarrages de micro service via le service de base
de données.
Liaison cloud
Liaison cloud multi-protocole.
La passerelle de communication sélectionne et achemine les données de tracking vers un ou plusieurs protocoles cloud simultanément. MDI21, MQTT TR50, MQTT Munic et MQTT générique sont tous disponibles — les politiques de routage par piste déterminent quel protocole transporte chaque flux de données.
Protocole binaire MDI21
L'encodage ASN.1 UPER minimise la taille du payload sur les forfaits cellulaires contraints. Les horodatages relatifs et les identifiants de message compacts compriment les en-têtes par paquet. Les politiques d'enregistrement par champ (OnChange, Periodic, PeriodicOnChange, Manual) calibrent les compromis bande passante/batterie. TCP/TLS persistant avec retry soutenu par PDM à la déconnexion.
MQTT TR50
Livraison JSON de schéma TR50 de niveau production via MQTT vers des plateformes cloud compatibles TR50. Configuré avec les autres protocoles via la table de routage ; l'accusé de réception est suivi par protocole afin qu'une retry ne cible que le protocole qui n'a pas encore confirmé.
MQTT Munic
Livraison de niveau production sur le schéma de sujet Munic via MQTT vers les déploiements de plateforme cloud Munic. Partage la même infrastructure de routage par piste et de retry que tous les autres protocoles.
MQTT générique
MQTT générique de niveau production — tout client MQTT standard atteint les services MOS4 via le broker MQTT in-process, sans adoption du SDK requise. Les payloads JSON sont transcodés à l'entrée ; un catalogue de services retained permet aux clients de découvrir les services disponibles à la connexion. Voir SDK pour le pattern d'intégration développeur.
Les protocoles sont acheminés par identifiant de piste. Une piste peut se ventiler vers plusieurs protocoles simultanément ; la retransmission ne cible que les protocoles qui n'ont pas encore accusé réception. Voir le catalogue complet pour le micro service passerelle de communication.
DNS
Résolveur SRV minimal.
Un résolveur DNS léger gère les enregistrements SRV (RFC 2782) avec suivi A/AAAA. Il lit /etc/resolv.conf à chaque appel — ainsi les changements de serveur de noms
issus du renouvellement DHCP ou du démarrage du modem sont pris en compte sans redémarrage de processus.
Pendant le démarrage du modem, avant qu'un serveur de noms soit configuré, le résolveur retourne une erreur typée afin que les appelants implémentent une logique de retry correcte plutôt que d'échouer silencieusement. L'implémentation est intentionnellement minimale — aucune dépendance ICU/IDNA — ce qui maintient l'empreinte binaire faible sur le matériel modem-class.
Pont MQTT
Broker MQTT in-process — tout client standard atteint MOS4.
Un broker MQTT s'exécute in-process — pas de processus externe. Transcode JSON vers le format d'appel typé à l'entrée. Tout client Python, Go, C ou C embarqué peut appeler tout service MOS4 sans adopter le SDK MOS4 ni les fichiers .proto.
Broker embarqué
S'exécute in-process. Pas de processus broker externe. Pas de dépendance d'infrastructure supplémentaire.
Découverte de services
Publie un catalogue de services retained à la connexion. Les clients énumèrent les services disponibles sans configuration hors bande.
Tous types d'appel de service
Achemine vers les appels unaires, les appels server-streaming et les abonnements event bus. Double type de contenu : JSON et binaire typé sur le même espace de noms de sujets. Voir SDK pour des exemples de client.
FAQ
Questions fréquentes
-
L'outillage MQTT existant fonctionne-t-il avec les services MOS4 ?
Oui. MOS4 embarque un broker MQTT in-process — pas de processus externe. Il transcode les payloads JSON vers le format typé à l'entrée et achemine vers tout service MOS4 comme un appel unaire, un appel server-streaming ou un abonnement event-bus. Tout client MQTT standard fonctionne sans adopter le SDK MOS4.
-
Quels standards cellulaires sont pris en charge ?
Tous les grands standards cellulaires — 2G, 3G, 4G LTE, 5G, Cat-M1 (LTE-M) et NB-IoT — sont pris en charge via des bibliothèques fournisseur chargées à l'exécution. Ajouter un nouveau module cellulaire nécessite une bibliothèque fournisseur correspondante et une mise à jour de config — pas de recompilation de micro service.
-
Comment fonctionne la sélection du backend WiFi ?
Le micro service WiFi lit l'arbre de périphériques au démarrage et sélectionne le chemin hostapd double bande ou le chemin esp-control 2,4 GHz sans aucun indicateur de compilation. Le même binaire s'exécute sur les deux variantes matérielles.
-
L'eSIM est-elle prise en charge dans les boîtiers scellés ?
Oui. La pile modem implémente la gestion de profil eUICC (GSMA SGP.22 v2.2 Consumer ; GSMA SGP.02 M2M) pour le téléchargement, l'activation, la désactivation, la suppression et la récupération de profil eUICC. Compilé conditionnellement — n'ajoute aucune surcharge sur les builds à SIM physique.
-
Comment fonctionne la détection de puce BLE ?
Le micro service Bluetooth détecte automatiquement la famille de puce depuis l'arbre de périphériques au démarrage. Plusieurs familles Bluetooth sont prises en charge — puces intégrées compute-class et variantes co-processeur famille Wi-Fi — sans recompilation.
-
Quelle version MQTT utilise le broker in-process ?
La version MQTT n'est pas divulguée publiquement. Le broker présente une surface MQTT standard — tout client MQTT standard se connecte sans adoption du SDK.
Apportez votre plan de connectivité de flotte.
L'équipe technique parcourra la sélection de modem, la coexistence WiFi, la sélection du protocole de liaison cloud et l'intégration du pont MQTT pour votre matériel cible.