Gel de la page graphique SCADA : analyse des causes profondes et optimisation pour Foxboro I/A Series et Woodward EasyGen

Le problème : le poste de travail se fige uniquement lors de l’ouverture de certains affichages

Les opérateurs signalent que certains affichages SCADA mettent 15 à 30 secondes à s’ouvrir. Le curseur de la souris accuse un retard pendant le chargement. D’autres affichages s’ouvrent en 2 à 3 secondes. Le statut de communication du PLC reste sain. Aucun défaut réseau n’apparaît dans les diagnostics.

Ce schéma isole le problème au niveau de la couche graphique, et non de la couche de communication. L’affichage qui se fige contient des objets plus complexes que ceux qui se chargent rapidement. Sur la Foxboro I/A Series, le gestionnaire d’affichage gère l’initialisation des objets. Sur Woodward EasyGen, le runtime GraphWorX rend les graphiques basés sur SVG. Les deux plateformes peinent lorsqu’un seul affichage dépasse leur capacité de conception.

Cause 1 : trop d’objets d’animation en temps réel

Les symboles de rotation de pompe, le mouvement des convoyeurs, les animations de rotation des agitateurs et les indicateurs d’état couleur nécessitent tous des cycles de rafraîchissement continus. Chaque objet animé consomme un thread CPU pour le calcul du redessin. Lorsqu’un affichage contient plus de 40 objets d’animation actifs, le moteur de rendu est saturé.

Sur Foxboro I/A Series V7.0, le gestionnaire d’affichage alloue un thread de rendu par tranche de 10 objets d’animation. Avec 50 animations, le système exécute 5 threads de rendu simultanés plus le thread principal d’affichage. L’utilisation CPU grimpe à 85–100 % sur un seul cœur.

Sur Woodward EasyGen utilisant GraphWorX64, chaque animation de rotation déclenche un recalcul de transformation matricielle toutes les 100 ms. Une page d’aperçu du générateur avec 30 symboles tournants génère 300 opérations de transformation par seconde. Le seuil d’accélération GPU est de 25 transformations simultanées sans matériel graphique dédié.

Atténuation : Remplacez les animations de rotation par des indicateurs d’état couleur statiques. Utilisez un clignotement de fréquence 1 (0,5 s marche/arrêt) au lieu d’une rotation fluide pour le statut en marche. Cela réduit la charge CPU de 60 à 70 % par objet.

Cause 2 : rafale d’abonnements aux tags lors de l’initialisation de la page

Chaque élément graphique est lié à un ou plusieurs tags PLC. Lorsqu’un opérateur ouvre un affichage, le client SCADA envoie simultanément des requêtes d’abonnement pour tous les tags liés. Un affichage avec 800 références de tags déclenche 800 messages d’abonnement individuels en 200 ms.

Dans la Foxboro I/A Series, la station de travail applicative (AW) transmet les abonnements au processeur de contrôle (CP) via le Nodebus. Chaque abonnement nécessite une transaction Nodebus. Le Nodebus supporte un maximum de 500 transactions par seconde et par nœud. Un affichage de 800 tags dépasse cette limite lors du chargement initial.

Résultat : les 500 premiers tags se mettent à jour immédiatement. Les 300 tags restants sont mis en file d’attente et arrivent 1 à 3 secondes plus tard. Les opérateurs voient des mises à jour partielles où certaines valeurs semblent obsolètes.

Sur Woodward EasyGen, le client OPC UA s’abonne aux tags par lots de 100. Un affichage de 800 tags nécessite 8 cycles de lots. À 250 ms par cycle, l’initialisation complète prend au minimum 2 secondes avant tout rendu.

• Étape 1 : Comptez le nombre total de références de tags sur l’affichage problématique. Dans Foxboro Display Editor, utilisez Outils > Rapport de comptage des tags. Dans GraphWorX64, utilisez Édition > Rechercher > Toutes les variables liées.
• Étape 2 : Si le nombre dépasse 600, divisez l’affichage en deux sous-affichages reliés par des boutons de navigation. Visez un maximum de 400 tags par affichage.
• Étape 3 : Pour Foxboro I/A Series, augmentez la taille du tampon de transaction Nodebus de 256 par défaut à 512 dans les Propriétés système du CP > onglet Réseau.
• Étape 4 : Pour Woodward EasyGen, configurez le mode d’abonnement OPC UA sur ajout d’élément surveillé au lieu de création d’abonnement dans le fichier de configuration GraphWorX. Cela réutilise les sessions existantes.

Cause 3 : graphiques de tendance intégrés interrogeant les données historiques

De nombreux affichages intègrent des fenêtres de tendance en temps réel montrant les 60 dernières minutes de données de processus. À l’ouverture de l’affichage, chaque graphique de tendance interroge la base de données historienne pour peupler les données initiales. Trois graphiques de tendance sur un affichage génèrent trois requêtes historiques simultanées.

Dans la Foxboro I/A Series, l’Historien (basé sur Informix ou SQL) sert les requêtes de tendance via l’API AIM Historian. Une tendance de 60 minutes avec un intervalle d’échantillonnage de 5 secondes retourne 720 points de données par courbe. Un graphique à 4 courbes récupère 2 880 points. Trois graphiques récupèrent 8 640 points au total. Le temps d’exécution de la requête varie de 3 à 8 secondes selon l’état des index de la base.

Pendant l’exécution de la requête, le thread d’affichage est bloqué en attente des données. L’opérateur voit un écran figé jusqu’à la réception complète des données de tendance.

• Étape 1 : Identifiez les objets de tendance intégrés sur l’affichage lent. Notez la plage temporelle et l’intervalle d’échantillonnage de chacun.
• Étape 2 : Réduisez la plage temporelle initiale de 60 minutes à 15 minutes. Cela réduit les points de données par courbe de 720 à 180, diminuant le temps de requête de 75 %.
• Étape 3 : Activez le chargement différé des données de tendance. Configurez les tendances pour peupler les données 2 secondes après l’ouverture de l’affichage, pas pendant l’initialisation. Sur Foxboro, réglez la propriété InitialLoadDelay de l’objet Tendance à 2000 ms.
• Étape 4 : Limitez le nombre de courbes par graphique à 4 maximum. Utilisez plusieurs graphiques si plus de variables doivent être suivies.

Cause 4 : images d’arrière-plan haute résolution consommant la mémoire

Les graphiques de processus utilisent souvent des schémas P&ID scannés comme arrière-plans. Un scan P&ID typique à 300 DPI pour une grande zone de processus produit des fichiers image de 8 à 15 Mo au format PNG. Lorsqu’ils sont chargés dans l’affichage SCADA, le bitmap non compressé occupe 50 à 80 Mo de RAM.

Le gestionnaire d’affichage Foxboro I/A Series met en cache les images d’arrière-plan en mémoire partagée. La taille de cache par défaut est de 128 Mo. Deux affichages avec des arrière-plans de 12 Mo chacun consomment 24 Mo en cache plus 48 Mo en copie de travail = 72 Mo au total. L’ouverture d’un troisième affichage force l’éviction du cache et le rechargement, provoquant une pause visible.

Woodward EasyGen GraphWorX64 stocke les arrière-plans sous forme de chaînes encodées en base64 dans le fichier GDFX de l’affichage. Un arrière-plan de 10 Mo augmente la taille du fichier GDFX de 13 Mo (surcharge base64). L’analyse de cette chaîne ajoute 1,5 à 2 secondes au temps de chargement de l’affichage.

• Étape 1 : Vérifiez la taille des fichiers d’image d’arrière-plan dans le répertoire du projet SCADA. Signalez toute image dépassant 2 Mo.
• Étape 2 : Réexportez les arrière-plans à 96 DPI avec compression JPEG (qualité 85 %). Cela réduit un PNG de 10 Mo à un JPEG de 400 à 600 Ko avec une perte visuelle minimale.
• Étape 3 : Sur Foxboro I/A Series, augmentez la taille du cache du gestionnaire d’affichage à 256 Mo via la variable d’environnement AW DISPLAY_CACHE_SIZE=262144.
• Étape 4 : Pour Woodward EasyGen, convertissez les images d’arrière-plan en mode référence externe au lieu d’intégration. Utilisez ImageSource=File chemin plutôt que ImageSource=Embedded.

Conclusion et conseils d’action

Le gel des pages graphiques SCADA résulte de quatre demandes de ressources qui se chevauchent. Premièrement, un nombre excessif d’objets d’animation surcharge le thread de rendu CPU. Deuxièmement, les rafales d’abonnements aux tags dépassent la capacité de transaction du bus de communication. Troisièmement, les graphiques de tendance intégrés bloquent le thread d’affichage lors des requêtes historiques. Quatrièmement, les arrière-plans haute résolution épuisent le cache mémoire.

Pour les systèmes Foxboro I/A Series, priorisez l’augmentation du tampon de transaction Nodebus à 512, réglez le délai de chargement différé des tendances à 2 secondes, étendez le cache d’affichage à 256 Mo et limitez les affichages à 600 tags maximum. Pour les systèmes Woodward EasyGen, remplacez les animations de rotation par des indicateurs d’état couleur, utilisez le mode de réutilisation des éléments surveillés OPC UA et convertissez les arrière-plans intégrés en références de fichiers externes.

Auditez tous les affichages dont le temps de chargement dépasse 8 secondes. Documentez les métriques avant et après dans votre GMAO. Visez un temps de chargement maximal de 5 secondes pour tout affichage sur un poste de travail standard (Intel i5, 8 Go RAM, graphique intégré).