FIABILITÉ DES DONNÉES INDUSTRIELLES
Store&Forward industriel pour une transmission fiable des données
Grâce à Store&Forward industriel, vNode conserve les données industrielles en edge lorsque la connexion amont n’est pas disponible. Au lieu de perdre les nouveaux enregistrements lors d’une interruption MQTT, WAN ou du système central, vNode met en buffer localement les données prises en charge, puis transmet les enregistrements en attente au retour de la connectivité. La durée de rétention et les possibilités de récupération dépendent de l’architecture configurée, du stockage local et du fonctionnement documenté de chaque module.
Coupure réseau : que se passe-t-il ?
vNode continue à acquérir les données, les stocke localement et les retransmet automatiquement dès le rétablissement de la connexion.
1 Collecter
L’acquisition PLC/OT continue.
! Perte de connexion
Le broker, le WAN ou le nœud Central est indisponible.
2 Stocker localement
Les enregistrements en attente restent en edge.
Reconnecter et retransmettre
Les données en attente sont transmises selon le flux configuré.
Connexion rétablie
vNode retransmet automatiquement les données stockées dans l’ordre documenté tout en poursuivant la publication en temps réel.
DÉFINITION
Qu’est-ce que Store&Forward dans l’IoT industriel ?
Store&Forward repose sur un buffer persistant en edge : la passerelle conserve sur un stockage local les nouveaux enregistrements industriels lorsque la destination amont configurée est indisponible, puis les retransmet dès le retour de la connexion. Ce mécanisme diffère d’une simple tentative de renvoi, qui ne persiste pas nécessairement les données générées pendant la coupure, et d’une file volatile en mémoire, susceptible d’être perdue après un redémarrage ou une panne électrique.
ARCHITECTURE
Que se passe-t-il si le réseau ou le MQTT broker tombe ?
Fonctionnement normal
vNode acquiert les données industrielles et les envoie à la destination configurée.
Défaillance détectée
Le WAN, le broker, le nœud Central ou la destination devient indisponible.
Stockage
Les nouveaux enregistrements sont conservés localement selon Store&Forward et l’espace disponible.
Acquisition continue
La collecte OT se poursuit indépendamment de la destination indisponible, dans les limites du système.
Reconnexion
vNode détecte le retour de disponibilité de la destination.
Retransmission du backlog
Les enregistrements du buffer sont transmis dans l’ordre documenté, tandis que l’acquisition temps réel se poursuit.
Rattrapage terminé
Le backlog est résorbé et la transmission normale en temps réel reprend.
Connectez l’OT à l’IT
Fiable. Sécurisé. Flexible.
PLC / OT
Sources de données industrielles.
industrielles
vNode Edge
Traite. Met en buffer. Supervise. Transmet.
traitées
IT / Cloud
Publie vers les systèmes de l’entreprise.
À NE PAS CONFONDRE
MQTT Store&Forward vs MQTT QoS
MQTT QoS définit la sémantique de livraison des messages au cours d’une session MQTT. Store&Forward répond à une autre question : que deviennent les nouveaux enregistrements industriels lorsque le flux vers la destination est indisponible ?
QoS
Contrôle la sémantique de livraison des messages entre pairs MQTT.
Store&Forward
Conserve localement la télémétrie en attente pendant l’interruption, puis la retransmet.
Architecture de production
Combine souvent un MQTT QoS adapté et un buffer persistant en edge à capacité bornée.
COMPORTEMENT ET LIMITES
Buffer, dimensionnement et architecture
Consultez également la solution OT/IT Reverse Connection pour le modèle complémentaire de connexions initiées depuis l’OT.
Les enregistrements en attente sont conservés dans un buffer local persistant. Le comportement au redémarrage ou après coupure électrique ainsi que la capacité dépendent du module et de sa version.
Les enregistrements sont retransmis avec leur timestamp d’origine dans l’ordre documenté. Les doublons dépendent de la destination : vérifier les garanties exactly-once ou at-least-once.
Dimensionnez le stockage : événements/seconde × octets/événement × durée de coupure × marge. Exemple : ~185 événements/s × 250 octets × 24 h ≈ 4,0 Go avant overhead. La limite vient du disque, et non d’une licence illimitée de tags.
Un nœud vNode distant poursuit l’acquisition et le buffering OT durant la coupure du lien avec Central et retransmet le backlog à la reconnexion.
Les données en attente peuvent être envoyées vers des MQTT brokers et AWS ou Azure si le flux configuré le prend en charge.
SQL et les historians peuvent également être des destinations : vérifier la sémantique de buffering selon les modules et versions.
Le buffer local complète les architectures segmentées outbound-only en dissociant l’acquisition OT de la disponibilité IT/cloud.
OBSERVABILITÉ
Supervision du buffer
Surveillez les métriques suivantes pour le flux configuré. Vérifiez celles exposées par l’UI/API de la version vNode utilisée ; si une métrique manque, prévoyez-la comme amélioration de supervision.
Profondeur de file
Nombre d’enregistrements en attente dans le buffer local.
Âge du plus ancien enregistrement
Durée d’accumulation du backlog.
Stockage disponible
Marge de capacité restante dans le buffer local.
Débit de retransmission
Vitesse de résorption du backlog après reconnexion.
Retard de rattrapage
Temps estimé avant résorption complète du buffer.
CAS CLIENT
Parc éolien au Sénégal et centre de contrôle au Royaume-Uni
Le cas de fiabilité publié par vNode présente un nœud distant sur le parc éolien de Taiba N’Diaye, qui collecte les données d’une sous-station et les stocke localement lorsque la liaison avec le centre de contrôle au Royaume-Uni est indisponible. Cette architecture illustre Store&Forward dans un déploiement industriel distribué réel : il s’agit d’un cas documenté, pas d’une garantie universelle.
Testez les pannes, pas seulement le fonctionnement nominal
Déconnectez le MQTT broker ou le WAN, poursuivez l’acquisition des données industrielles, reconnectez et mesurez précisément la récupération du backlog.
Questions fréquentes
Qu’est-ce que Store&Forward dans une passerelle industrielle ?
Il s’agit d’un buffer persistant en edge qui conserve les nouveaux enregistrements industriels lorsque la destination est indisponible et les retransmet à la reconnexion.
Comment fonctionne MQTT Store&Forward ?
La passerelle continue d’acquérir les données OT pendant une coupure MQTT, stocke les enregistrements et les retransmet au broker dans l’ordre documenté.
MQTT QoS et Store&Forward sont-ils équivalents ?
Non. MQTT QoS gère la livraison des messages MQTT ; Store&Forward conserve les nouvelles données produites pendant l’indisponibilité du flux.
Que deviennent les données PLC lors d’une coupure Internet ?
Avec Store&Forward configuré, le nœud edge poursuit l’acquisition des données prises en charge et les conserve localement jusqu’au retour de la destination, dans les limites prévues.
vNode stocke-t-il sur disque ou seulement en mémoire ?
Store&Forward repose sur un stockage local persistant plutôt que sur une simple file volatile. Vérifiez le mécanisme exact selon le module et la version.
Pendant combien de temps les données peuvent-elles être stockées ?
Cela dépend du débit d’événements, de la taille moyenne des payloads, de la durée de coupure et du stockage disponible ; la rétention n’est pas illimitée.
Les timestamps d’origine sont-ils conservés ?
Les enregistrements sont destinés à être retransmis avec leur timestamp d’acquisition initial ; à confirmer pour chaque flux.
Dans quel ordre les données sont-elles retransmises ?
Dans l’ordre documenté pour le flux configuré, pendant que l’acquisition en temps réel se poursuit en parallèle.
Que se passe-t-il si le disque est plein ?
Aucun buffer n’est illimité. Le comportement dépend de la capacité et du module ; dimensionnez le système pour les scénarios prévus.
Store&Forward résiste-t-il à un redémarrage ou à une coupure électrique ?
Le stockage persistant peut limiter les lacunes, mais une garantie inconditionnelle de zéro perte devrait couvrir les pannes de disque, la saturation, les écritures interrompues et la destination.
Est-ce compatible avec AWS et Azure ?
Si le flux vNode le permet, les enregistrements stockés peuvent être envoyés vers AWS ou Azure à la reconnexion ; vérifiez les destinations prises en charge.
Peut-on superviser le buffer et la récupération ?
Suivez la profondeur de file, l’âge des enregistrements, l’espace restant, le débit et le retard de rattrapage ; vérifiez leur disponibilité dans l’UI/API.