Télémétrie industrielle10 min de lecture

Télémétrie store-and-forward : concevoir pour la panne, pas pour la démo

Une connexion MQTT n'est pas une stratégie de persistance. L'historique machine exige un journal local et des règles de rejeu explicites.

Contrôleur Linux et stockage local dans l'armoire d'une pompe pendant une interruption réseau

À propos de l’auteur

Dr. Mehran Kiani-Oshtorjani

Ingénieur en logiciels industriels et simulation

Mehran Kiani-Oshtorjani est ingénieur mécanicien et développeur logiciel. Son travail couvre la simulation temps réel, les systèmes hydrauliques, le contrôle industriel et les logiciels connectés. Sa recherche doctorale à LUT University portait sur des méthodes de calcul efficaces pour les systèmes industriels temps réel.

Points clés pour l’ingénierie

  • La machine doit posséder durablement les données non envoyées.
  • Chaque enregistrement exige temps d'événement, séquence, version de schéma et ID stable.
  • Une file pleine est un état d'exploitation visible, pas une raison de supprimer en silence.

Le réseau transporte, il n'archive pas

Routeur, certificat, DNS, réseau mobile ou maintenance interrompent les liens. La commande reste locale et la télémétrie doit connaître précisément les observations non livrées.[1][4]

Une identité qui résiste au rejeu

ID machine, signal, valeur, qualité, temps d'événement, séquence, version de schéma et ID stable permettent de rejouer sans mentir sur le moment de mesure.[6][5]

  • Dédupliquer par séquence ou ID
  • Indiquer la qualité de l'horloge
  • Versionner le schéma
  • Transmettre les états périmé et hors ligne

Un journal local borné et transactionnel

Une base embarquée ou un journal append-only simplifie l'ordre, l'acquittement et la reprise après panne.[2][3]

ÉtatLocalCloudAction
En fileDurableInconnuRéessayer avec le même ID
En volDurableEn attenteRéessayer après délai
AcquittéDurableStockéCompactable
ExpiréSelon règleNon envoyéCompter la perte

Rejouer sans bloquer le présent

Réserver de la capacité aux états et alarmes actuels, puis vider l'historique par lots contrôlés.[1][5]

MQTT QoS 1 autorise les doublons. Le traitement logique exact exige des ID stables et une écriture idempotente.[1]

Décider avant que le stockage soit plein

Dimensionner selon la panne crédible, le débit, les frais d'écriture et la marge, puis définir une règle par classe de signal.[4]

  • Afficher âge, octets et pertes
  • Isoler le runtime des blocages disque
  • Spécifier la rétention
  • Tester la coupure de courant à chaque étape

Un essai de panne utile

  1. Couper l'uplink machine active
  2. Redémarrer le service puis couper l'alimentation
  3. Reconnecter après la panne maximale
  4. Vérifier temps, ordre et déduplication
  5. Préserver le direct pendant le rejeu
  6. Atteindre volontairement les limites

Questions fréquentes

MQTT QoS 1 suffit-il ?

Non. Il ne définit ni journal local, ni rétention, ni schéma, ni déduplication de bout en bout.

Faut-il un ordre global ?

En général, l'ordre par machine et flux suffit et évite le blocage entre signaux indépendants.

Quel volume local prévoir ?

Le calculer à partir de la panne maximale, du volume, des classes de rétention et d'une marge testée.

Sources et normes

  1. MQTT Version 5.0OASIS Open
  2. Write-Ahead LoggingSQLite
  3. Transaction control languageSQLite
  4. NIST SP 800-82 Rev. 3: Guide to Operational Technology SecurityNational Institute of Standards and Technology, September 2023
  5. Prometheus Remote-Write 2.0 specificationPrometheus
  6. RFC 3339: Date and Time on the InternetIETF

BootCtrl Engineering a vérifié pour la dernière fois les affirmations techniques et les liens sources le 26 juillet 2026. Les déclarations produit sont confrontées aux dépôts d’implémentation actuels ; les éléments de feuille de route ne sont pas présentés comme disponibles.

Tester la machine déconnectée

Nous pouvons définir limites, règles de rejeu et preuves.

Planifier un essai