Retransmission hors ligne des passerelles industrielles : capacité, ordre et doublons
Le tampon hors ligne d’une passerelle industrielle doit être défini comme un contrat de conservation durable : quelles mesures sont acceptées, combien peuvent être gardées, quand un enregistrement peut être supprimé et comment le destinataire traite la retransmission. Le rétablissement du réseau ne prouve pas que l’historique est arrivé intact. La réception doit rapprocher les identifiants entre acquisition, stockage local et application finale.
Cet article traite de la télémétrie stockée puis retransmise. Le choix et la commutation des liaisons relèvent du guide de réception du basculement Ethernet, Wi-Fi et cellulaire existant. Les commandes et actions d’actionneurs exigent leur propre politique d’expiration et d’exécution ; rejouer aveuglément une ancienne commande peut être dangereux. Les calculs ci-dessous sont des exemples de dimensionnement, pas des performances revendiquées pour une passerelle.
Définir à partir de quel point les données sont protégées
Tracez le parcours de la lecture du capteur à l’enregistrement validé durablement sur le serveur. Une valeur présente seulement en RAM peut disparaître à la coupure. Un envoi socket réussi ne garantit aucune conservation durable à destination. Définissez « accepté par la passerelle » comme un point de durabilité locale documenté et « livré » comme un point d’acquittement documenté du destinataire.
Pour un capteur interrogé, une panne d’alimentation avant l’enregistrement durable de sa réponse peut encore faire perdre l’observation. Si le produit doit protéger les données avant ce point, la source doit disposer de son propre historique ou d’une séquence conservée, ou d’un autre mécanisme de récupération. Énoncez cette limite d’acquisition au lieu de promettre zéro perte sur un intervalle non observable.
Un contrat pratique associe une transmission au moins une fois à un destinataire idempotent : des répétitions sont possibles, mais une identité stable produit un seul enregistrement métier validé. Un acquittement MQTT QoS est un acquittement protocolaire ; il ne prouve pas à lui seul qu’une transaction de base de données en aval est terminée. MQTT 5.0 définit la QoS et l’ordre au sein du protocole. La livraison de bout en bout exige encore un accord applicatif, notamment après défaillance du broker ou du consommateur.
Dimensionner pour la coupure et le trafic au retour
Partez du nombre d’enregistrements par seconde, de la taille maximale prise en charge, de la coupure maximale et d’une marge mesurée pour les surcoûts de stockage. Incluez identifiants, horodatages, encapsulation, index, journaux, espace temporaire de compactage et politique de rétention. La capacité nominale d’une puce flash n’est pas le quota utilisable de la file.
raw_backlog_bytes = input_records_per_second
* outage_seconds
* stored_record_bytes
planned_queue_bytes = raw_backlog_bytes * overhead_and_headroom_factor
recovery_seconds = backlog_records
/ (durably_acknowledged_records_per_second - input_rate)À titre d’exemple, avec 20 enregistrements/s, 256 octets par enregistrement et huit heures de coupure, le retard brut représente 147 456 000 octets, soit environ 140,6 MiB. Un facteur provisoire de deux donne 281,3 MiB. Un quota de 320 MiB laisse une certaine marge, mais doit être vérifié avec le format réel et les charges utiles les plus défavorables. La réserve du système de fichiers, les journaux système et l’espace de travail OTA nécessitent leurs propres budgets.
Cette coupure produit 576 000 enregistrements. Si le destinataire accepte durablement 80 enregistrements/s tandis que les nouvelles données continuent à 20 enregistrements/s, la résorption nette est de 60 enregistrements/s et le rattrapage prend 9 600 secondes, soit deux heures quarante. Si le débit soutenu d’acquittement ne dépasse pas le débit d’acquisition, le retard ne se résorbe jamais. Mesurez le trajet complet TLS, broker, base de données et limitations de débit plutôt que d’extrapoler la bande passante Ethernet.
Choisir explicitement l’ordre et l’identité des enregistrements
Utilisez une identité stable, par exemple identifiant de source, génération du flux et séquence monotone. Conservez-la à chaque tentative. Définissez la création et la persistance des générations pour qu’un redémarrage ou une réinitialisation d’usine ne réutilise pas des identités encore présentes chez le destinataire. Les identifiants de paquets MQTT ne conviennent pas comme identifiants applicatifs de longue durée.
Stockez séparément l’heure de mesure à la source lorsqu’elle est disponible, l’heure d’acquisition de la passerelle et la qualité de l’horodatage. Une passerelle peut démarrer sans heure civile fiable ; une synchronisation ultérieure ne doit pas réécrire l’ordre historique des séquences. Utilisez un temps écoulé monotone pour les échéances locales. Le backend doit distinguer les anciens échantillons arrivés tardivement des mesures récentes.
L’ordre importe généralement à l’intérieur d’un flux de capteur, pas entre tous les capteurs. Un ordre global peut laisser une destination défaillante bloquer des sources indépendantes. Décidez si les données récentes attendent derrière l’historique, utilisent une voie réservée ou partagent un ordonnanceur pondéré. Avec plusieurs voies, transmettez les séquences et laissez le destinataire traiter le désordre autorisé. « Dernière valeur » et « historique complet » peuvent nécessiter des circuits de consommation différents.
Valider localement et supprimer seulement après l’acquittement convenu
Utilisez un journal à ajout ou une base transactionnelle avec vérifications d’intégrité et analyse de récupération. Les validations groupées peuvent réduire les écritures, mais le groupe non encore validé reste dans la fenêtre de perte. Si le produit accepte les données avant synchronisation, documentez cette fenêtre. Testez le système de fichiers, la flash, le pilote et le circuit d’alimentation réels ; une synchronisation logicielle ne corrige pas un stockage qui ne la respecte pas.
SQLite constitue une option Linux, pas une obligation pour les passerelles à microcontrôleur. Sa documentation de validation atomique explique les hypothèses des transactions. En mode WAL, le paramètre synchronous modifie la durabilité à la coupure : NORMAL peut perdre des transactions récemment validées, tandis que FULL ajoute une synchronisation par transaction. Choisissez et vérifiez délibérément la durabilité, et incluez l’espace WAL et des points de contrôle dans le quota.
L’esquisse suivante illustre un acquittement applicatif. L’implémentation doit ajouter authentification, lots limités, gestion des défaillances et contrainte d’unicité durable chez le destinataire :
gateway:
persist(record_id, payload) before marking locally accepted
send(record_id, payload)
receiver transaction:
insert record if record_id is absent
verify duplicate IDs refer to the same content
commit
receiver:
acknowledge(record_id) after the durable commit
gateway:
persist acknowledgement, then reclaim the queued recordSi le serveur a validé mais que son acquittement se perd, la passerelle renvoie la même identité. Si l’alimentation tombe après l’acquittement mais avant la suppression locale, elle peut recommencer. Le destinataire doit tolérer les deux situations. Ne supprimez pas toutes les séquences inférieures au plus grand numéro observé sans avoir établi un préfixe contigu effectivement validé ; sinon, les trous liés à l’arrivée désordonnée seraient perdus.
Rendre visible le comportement à saturation
Choisissez une politique de débordement approuvée : cesser d’accepter, exercer une contre-pression lorsque la source le permet, supprimer les plus anciens, supprimer les plus récents ou agréger des données désignées. Chaque produit appelle son choix. Enregistrez un compteur de pertes et la plage de séquences ou de temps affectée ; l’écrasement silencieux rend le rapprochement ultérieur impossible. Réservez assez de métadonnées pour signaler le débordement même lorsque la file est pleine.
Ne séparez les événements urgents de la télémétrie périodique que si le contrat de priorité l’autorise. Bornez les délais de reprise et ajoutez une dispersion aléatoire entre appareils pour qu’un site reconnecté ne submerge pas le serveur. Imposez un budget de retransmission qui préserve les échéances d’acquisition, la réactivité de l’interface locale et le trafic normal. La conservation des informations de déduplication côté destinataire doit couvrir tout l’horizon de reprise autorisé, y compris des sauvegardes restaurables susceptibles de réintroduire d’anciens enregistrements.
Rapprocher les identités pendant la réception
| Défaillance injectée | Preuves | Condition de réception proposée |
|---|---|---|
| Coupure équivalente à huit heures à pleine charge d’entrée | Identifiants générés, acceptés localement et en attente ; octets réels | Tous les enregistrements acceptés conservés dans le quota et la durée annoncés |
| Coupures pendant ajout, synchronisation et traitement d’acquittement | Registre externe de source et file récupérée | Chaque identité acceptée durablement récupérée ou déjà validée chez le destinataire |
| Perte de l’acquittement applicatif après validation serveur | Identifiants de transport répétés et lignes serveur | Nouvelle tentative ; un enregistrement métier par identité, conflits de contenu signalés |
| Reconnexion pendant la poursuite de l’acquisition | Pente du retard, latence d’ingestion et charge CPU/stockage | Résorption nette positive ; budgets de données récentes et d’acquisition respectés |
| File pleine, échecs d’écriture ou stockage en lecture seule | État de défaut, plages perdues et comportement au redémarrage | Politique d’erreur approuvée ; aucune fausse acceptation durable silencieuse |
| Correction de l’heure et redémarrage | Identité, génération, séquence et qualité temporelle | Pas de réutilisation d’identité ; ordre autorisé du flux préservé |
Gardez un registre indépendant de la source sur le banc ; la seule file de la passerelle ne peut révéler les pertes avant mise en attente. Comparez les ensembles d’identifiants acceptés et validés, puis vérifiez empreintes des charges utiles, unités et ordre requis par flux. Distinguez répétitions de transport et doublons dans les lignes applicatives. Indiquez le remplissage maximal, l’âge du plus ancien enregistrement, le débit de retransmission et les pertes non résolues.
Définir le tampon avec l’application réelle
Le service de connectivité des appareils d’Obeita peut aider à définir les limites entre collecte et messages serveur. Le projet livré d’acquisition STM32 et de connexion MQTT traite explicitement le stockage hors ligne comme un périmètre complémentaire exigeant une capacité de rétention et une politique de retransmission convenues. Ce cas est pertinent, sans prouver une endurance ou une capacité particulière du tampon.
Fournissez protocole source, exemples de charges utiles, débit d’acquisition maximal, exigence de coupure, matériel de stockage et comportement d’acquittement du serveur. Le livrable doit comprendre modèle de dimensionnement, schéma d’identité, politique de débordement, hypothèses de durabilité et modèle de rapport de rapprochement avant d’accepter une exigence « aucune perte de données ».
