Architecture d’un historien de données industrielles : collecte locale ou basée sur un serveur

Pourquoi l’architecture de l’historien est-elle importante ?

Les systèmes d’automatisation industrielle génèrent des flux continus de mesures, d’états de fonctionnement, d’alarmes et d’événements de production. Ces enregistrements aident les ingénieurs à analyser les défaillances, à vérifier les conditions du processus et à comprendre les performances des équipements.

Cependant, la collecte de données ne garantit pas automatiquement la création d’un historique complet ou exploitable. Les interruptions réseau, la maintenance des serveurs, le stockage limité et des paramètres de collecte inadaptés peuvent entraîner des lacunes.

Le choix entre un historien au niveau de la machine et un historien basé sur un serveur doit commencer par l’application prévue. Chaque architecture répond à des exigences différentes en matière de collecte, de conservation et d’analyse.

Un historien au niveau de la machine capture des informations détaillées à proximité des équipements de production. Un historien basé sur un serveur centralise les enregistrements de plusieurs sources et prend en charge des analyses plus étendues.

Qu’est-ce qu’un historien au niveau de la machine ?

Un historien au niveau de la machine collecte et stocke des données chronologiques à proximité d’une machine individuelle, d’une cellule de production ou d’un système de commande. Selon sa mise en œuvre, il peut obtenir des données auprès d’automates programmables industriels et de réseaux industriels compatibles. Parmi les sources de données courantes figurent des automates tels que le automate programmable ControlLogix Allen-Bradley 1756-L1 et le module d’automate programmable Siemens 6ES7214.

Cette configuration est utile lorsque les ingénieurs ont besoin d’enregistrements détaillés des événements entourant un arrêt, une panne d’équipement ou une séquence d’événements inattendue.

• Diagnostics des machines : Conservez certaines valeurs des automates autour des pannes et des interruptions de production.
• Traçabilité : Associez les mesures du processus aux cycles de production, aux lots ou aux produits individuels.
• Vérification du processus : Conservez les enregistrements permettant de vérifier si les conditions de fonctionnement respectaient les exigences définies.
• Collecte locale des données : Réduisez la dépendance à une communication continue avec un serveur d’historien distant.

La collecte locale peut améliorer la résilience en cas d’indisponibilité d’un serveur en amont ou d’une connexion réseau. Toutefois, cet avantage dépend de l’architecture réelle de l’historien et du stockage disponible.

Les ingénieurs doivent vérifier la capacité de conservation, les méthodes d’exportation des données, les performances de collecte et le comportement en cas de reprise. Le stockage local n’élimine pas tous les modes de défaillance possibles.

Qu’est-ce qu’un historien basé sur un serveur ?

Un historien basé sur un serveur collecte des données historiques provenant de plusieurs équipements de production et d’autres sources de données prises en charge. Il offre généralement des fonctionnalités plus étendues en matière de rapports, de tendances, de stockage et d’analyse.

Les ingénieurs d’usine peuvent comparer les performances des équipements, examiner les pertes de production récurrentes et corréler les mesures des processus entre différentes machines.

Les historiens centralisés prennent également en charge les applications qui combinent des enregistrements opérationnels avec des informations de fabrication ou d’entreprise. Cela peut aider à relier le comportement des processus aux calendriers de production, aux lots et aux résultats de qualité.

Cependant, le chemin de collecte introduit des dépendances supplémentaires. Les pannes réseau, la maintenance des serveurs, les problèmes d’interface et les limites de stockage peuvent interrompre la collecte de données. La connectivité côté terrain repose souvent sur des modules de communication Ethernet tels que le Yokogawa ALE111-S51, le Schneider 140NOE21100 ou le Foxboro FBM232 ; leur configuration et leur état sont donc importants pour les enregistrements.

Ne supposez pas que chaque historien met automatiquement les données en tampon en cas de panne. Vérifiez si le collecteur concerné prend en charge la mise en tampon, pendant combien de temps il conserve les enregistrements en attente et comment il gère la reprise.

En quoi les deux architectures diffèrent-elles ?

Il s'agit de tendances architecturales, et non de garanties universelles liées aux produits. Vérifiez le comportement de la plateforme choisie avant de finaliser une conception.

Comment choisir un historien adapté ?

À quelle question d'ingénierie les données doivent-elles répondre ?

Commencez par déterminer quelles décisions les données historiques doivent éclairer. L'analyse d'une défaillance peut nécessiter des enregistrements à haute résolution autour d'un événement bref. L'analyse de la production peut exiger une conservation plus longue et des données cohérentes provenant de plusieurs équipements.

Documentez les tags requis, les intervalles de collecte, les déclencheurs d'événements, la qualité des horodatages, la durée de conservation et les besoins en matière de rapports.

À quels endroits des données peuvent-elles être perdues sur le chemin de collecte ?

Cartographiez le chemin de collecte, de chaque contrôleur jusqu'à sa destination de stockage. Repérez les commutateurs réseau, les passerelles, les services de collecte, les serveurs et les autres composants susceptibles d'interrompre l'enregistrement.

Demandez-vous ce qui se passe lors d'une panne réseau, du redémarrage d'un serveur ou d'une maintenance planifiée. Vérifiez si les données restent mises en mémoire tampon localement et si le système peut combler les intervalles manquants après le rétablissement.

Quelle capacité de stockage faut-il prévoir ?

Estimez le stockage nécessaire en fonction du nombre de points, de la fréquence de collecte, de la taille des enregistrements, de la compression et de la durée de conservation requise. Tenez compte de la surcharge opérationnelle et prévoyez une marge de capacité appropriée.

Ne dimensionnez pas le stockage en vous fondant uniquement sur le nombre de tags. Deux systèmes ayant un nombre de tags identique peuvent générer des volumes de données différents selon leurs paramètres de collecte et le comportement du procédé.

Les horodatages sont-ils cohérents et bien compris ?

L'analyse historique devient moins fiable lorsque des enregistrements liés utilisent des horloges incohérentes ou des sources d'horodatage mal comprises. Examinez la synchronisation temporelle des contrôleurs, des collecteurs de données et des serveurs.

Déterminez si les horodatages correspondent à l'acquisition à la source, à la collecte ou à la réception par le serveur. Cette distinction est importante pour reconstituer l'ordre d'événements rapprochés.

La cybersécurité et la restauration sont-elles prises en compte ?

Examinez l'authentification, les contrôles d'accès, la segmentation du réseau, la gestion des correctifs, les procédures de sauvegarde et les tests de restauration. Un historien peut contenir des informations opérationnelles précieuses et doit bénéficier d'une protection adaptée.

Testez le processus réel de restauration. Une sauvegarde n'est utile que si les données et la configuration requises peuvent être restaurées dans des délais opérationnels acceptables.

Quand faut-il combiner collecte locale et centralisée ?

Certaines applications tirent parti des deux architectures. Un historien au niveau des machines peut conserver des enregistrements détaillés à proximité des équipements, tandis qu’un historien sur serveur regroupe les informations sélectionnées pour une analyse à l’échelle de l’usine.

Par exemple, une ligne de production reposant sur des contrôleurs tels que le module de contrôleur API GE Mark VIe IS400AEBMH3A peut nécessiter des enregistrements détaillés des événements pour diagnostiquer les pannes et des historiques de lots centralisés pour les contrôles qualité. Le stockage local et l’agrégation centralisée peuvent répondre ensemble à ces besoins.

Concevez soigneusement le mécanisme de transfert. Définissez quels enregistrements sont envoyés au système central, comment les horodatages sont préservés, comment les enregistrements en double sont traités et ce qui se passe en cas d’interruption de la communication.

Vérifiez également si les systèmes locaux et centraux conservent le même niveau de détail. L’agrégation ou la compression peut modifier les informations disponibles lors d’analyses ultérieures.

Que doit inclure une liste de contrôle pour la mise en service et la maintenance ?

• Vérifiez que les variables du contrôleur requises sont collectées.
• Comparez les valeurs de l’historien aux valeurs de référence fiables.
• Confirmez les intervalles de collecte et le comportement des déclencheurs d’événements.
• Vérifiez la synchronisation horaire des appareils concernés.
• Testez le comportement en cas d’interruption du réseau et lors du rétablissement.
• Examinez la capacité de stockage, les politiques de conservation et la rotation des archives.
• Vérifiez les contrôles d’accès, les sauvegardes et les procédures de restauration.
• Documentez les voies de collecte et les responsables de chaque composant.

Consignez les résultats des tests et les critères d’acceptation. Répétez les vérifications essentielles après toute modification importante du réseau, des contrôleurs ou de la configuration de l’historien.

Conclusion : faire des données historiques une ressource d’ingénierie fiable

Choisissez un historien de données industrielles en fonction des données que votre exploitation doit préserver et des décisions que ces données doivent étayer. La collecte locale est précieuse pour le diagnostic détaillé des machines, tandis que la collecte sur serveur facilite les rapports à plus grande échelle et l’analyse de plusieurs équipements. Combiner les deux peut offrir des avantages complémentaires, à condition de concevoir soigneusement le transfert, la conservation et la restauration. Avant la mise en œuvre, documentez les besoins en données, testez le comportement en cas de panne, vérifiez la qualité des horodatages et assurez-vous que les sauvegardes peuvent être restaurées. Ces étapes contribuent à faire des données historiques une ressource d’ingénierie fiable.