Effondrement des performances SCADA lors du changement de poste : diagnostic du pic de charge simultané sur GE HMI et Honeywell Experion

Le symptôme : le SCADA se fige uniquement lors du changement d’équipe

Les opérateurs signalent que le système SCADA devient non réactif pendant le changement de poste. Les pages graphiques se chargent lentement. La reconnaissance des alarmes prend 5 à 10 secondes. Les valeurs des tags se figent momentanément sur les affichages de tendance. Le PLC continue de fonctionner normalement. Les instruments de terrain affichent des valeurs correctes. Le gel se résout de lui-même après 15 à 20 minutes.

Ce schéma indique un pic de charge côté serveur, et non un problème de communication terrain. Les systèmes GE HMI Proficy iFIX et Honeywell Experion PKS rencontrent ce problème lorsque plusieurs événements se produisent simultanément à la limite de poste. Comprendre chaque événement aide à isoler la cause principale.

Cause racine 1 : redémarrage simultané des postes de travail et nouvelle souscription des tags

Lors du changement de poste, l’opérateur sortant ferme l’application SCADA. L’opérateur entrant la lance à nouveau. Sur GE HMI Proficy iFIX, chaque redémarrage de poste déclenche un téléchargement complet des souscriptions de tags depuis le serveur SCADA. Si 8 postes redémarrent dans une fenêtre de 2 minutes, le serveur traite 8 demandes de souscription simultanées.

Chaque souscription implique une requête à la base de données, une recherche de tags et la configuration du routage des données en temps réel. Le service GE Proficy Cim-Manager gère ces demandes. En cas de forte charge, la profondeur de la file d’attente dépasse la limite du tampon. Les nouvelles demandes de souscription attendent dans la file. Le délai se manifeste par un chargement lent des graphiques côté client.

Atténuation : Configurez les postes pour utiliser la reprise d’application au lieu d’un redémarrage complet. Dans Proficy iFIX, activez l’option Auto-Resume dans les propriétés de l’espace de travail iFIX. Cela réutilise les souscriptions de tags existantes au lieu de les reconstruire depuis zéro. Le temps de démarrage passe de 45 secondes à moins de 10 secondes.

Cause racine 2 : rafale de reconnaissance d’alarmes et tempête d’écriture en base de données

Lors de la passation, l’opérateur sortant reconnaît les alarmes accumulées. Un poste typique génère 200 à 400 événements d’alarme. Si 80 % restent non reconnus, l’opérateur entrant les confirme en lot. Chaque reconnaissance génère une transaction en base enregistrant le nom de l’opérateur, l’horodatage, l’ID de l’alarme et le commentaire.

Dans Honeywell Experion PKS, les événements d’alarme s’écrivent dans la base d’alarme (ADB). Chaque écriture nécessite une mise à jour de l’index. En cas de rafale, la file d’attente des mises à jour d’index croît plus vite que le débit d’E/S disque. Le serveur d’alarme Experion répond avec une latence accrue. Les pop-ups d’alarme apparaissent avec un délai de 3 à 5 secondes. Nos cartes modules contrôleurs Honeywell et composants système C300 sont conçus pour maintenir la stabilité dans ces conditions de charge.

Sur GE Proficy iFIX, les reconnaissances d’alarmes s’écrivent dans la base historique via l’SCU (System Configuration Utility). Si l’historien est sur le même serveur, la contention des E/S disque s’aggrave. Le Proficy Process Historian peut perdre des données durant cette période.

Atténuation : Activez la mise en attente des alarmes à faible priorité avant la fin du poste. Dans Experion PKS, configurez la fonction de mise en attente dans l’onglet Configuration des alarmes. Mettez en attente jusqu’à 50 % des alarmes non reconnues à faible priorité. Cela réduit la rafale de reconnaissances en éliminant les événements non critiques.

Cause racine 3 : génération automatique de rapports de poste et surcharge des requêtes

Les plateformes SCADA GE et Honeywell supportent la génération automatique de rapports à des horaires programmés. Les rapports de poste courants incluent totaux de production, résumés des arrêts, statistiques d’alarmes et consommation d’énergie. Ces rapports interrogent la base historique pour des milliers de points de données.

Si le moteur de génération de rapports s’exécute sur le serveur SCADA, il concurrence les ressources CPU et disque avec les opérations en temps réel. Une requête typique de rapport de poste sur GE Proficy Process Historian prend 8 à 12 secondes. Pendant ce temps, la capacité du serveur SCADA pour les mises à jour de tags et le traitement des alarmes est réduite.

Dans Honeywell Experion PKS, la station de rapports génère les rapports via le serveur de rapports Experion. Si la station de rapports partage le même serveur que le serveur d’application Experion, la charge des requêtes dégrade la performance en temps réel. Le moniteur de santé du serveur affiche une utilisation CPU atteignant 85 à 95 % pendant la génération des rapports.

Atténuation : Planifiez les rapports de poste pour qu’ils s’exécutent 10 minutes après le changement de poste, pas à l’heure exacte de la passation. Cela découple la requête de rapport de la rafale de reconnaissance d’alarmes. Vérifiez la planification dans l’Experion Report Designer ou le planificateur de rapports Proficy Process Historian.

Procédure de diagnostic étape par étape

Lorsque le gel se produit, collectez immédiatement les données de diagnostic. Ne pas attendre le poste suivant.

• Étape 1 : Ouvrez le Gestionnaire des tâches Windows sur le serveur SCADA. Enregistrez l’utilisation CPU, la mémoire utilisée et la longueur de la file d’attente disque. Identifiez si le goulot d’étranglement est le CPU, la RAM ou les E/S disque.
• Étape 2 : Consultez le Visualiseur d’événements Windows pour les échecs d’écriture en base ou les délais d’attente de service. Recherchez l’ID d’événement 833 (latence base de données dépassée) dans les journaux Experion ou l’ID 4096 dans les journaux Proficy iFIX.
• Étape 3 : Vérifiez le nombre de souscriptions de tags SCADA. Dans Experion PKS, utilisez le Station Manager pour afficher les statistiques de souscriptions actives. Dans GE Proficy iFIX, utilisez l’écran Diagnostics système pour vérifier la profondeur de la file Cim-Manager.
• Étape 4 : Examinez le journal des alarmes pour le motif de rafale. Comptez le nombre de reconnaissances d’alarmes dans une fenêtre de 5 minutes autour du changement de poste. Si le nombre dépasse 50 par minute, la tempête d’écriture en base est la cause dominante.
• Étape 5 : Vérifiez la planification de génération des rapports. Recherchez les rapports configurés pour démarrer à l’heure du changement de poste. Décalez l’heure de début de 10 à 15 minutes pour réduire le chevauchement.

Conclusion et conseils d’action

L’effondrement des performances SCADA au changement de poste résulte de trois événements simultanés. Premièrement, les postes redémarrent et se réabonnent à tous les tags en même temps. Deuxièmement, les opérateurs reconnaissent en lot les alarmes accumulées, générant une tempête d’écriture en base. Troisièmement, les rapports automatiques de poste interrogent la base historique en période de charge maximale.

Sur GE HMI Proficy iFIX, activez Auto-Resume pour éliminer la reconstruction complète des souscriptions. Sur Honeywell Experion PKS, activez la mise en attente des alarmes et replanifiez les rapports 10 minutes après le changement de poste. Les deux plateformes bénéficient du déplacement de la base historique vers un serveur dédié. Cela sépare le traitement temps réel des tags des charges de requêtes de rapports. Des modules E/S Honeywell fiables garantissent l’intégrité des données terrain même lors des pics de charge côté serveur.

Documentez les résultats du diagnostic dans le GMAO de l’usine. Créez une procédure de performance au changement de poste qui répartit les trois événements de charge sur une fenêtre de 30 minutes. Surveillez les résultats pendant deux semaines. Si l’utilisation CPU dépasse encore 80 % lors du changement de poste, envisagez une mise à niveau du serveur SCADA ou l’ajout d’un second serveur pour répartir la charge.