La SETNE mise sur le superviseur Topkapi pour sa centrale thermique en Moselle

Les installations de la centrale thermique se décomposent en deux parties : la production proprement dite (brûleurs et générateurs) et l'approvisionnement. Le pilotage des équipements de production s'effectue par l'intermédiaire d'un SNCC (Système Numérique de Contrôle Commande). Le pilotage de la partie manutention / approvisionnement était jusqu'en 1994 assuré par un système à base de calculateurs SOLAR redondants.

La fiabilité du système est fondamentale, car la fourniture d'électricité à EDF est planifiée par contrat, et le non-respect des prévisions est soumis à de très lourdes pénalités. Face aux risques que faisait peser l'obsolescence du système SOLAR (disponibilité de pièces de rechanges, pertes de compétences), les responsables d'unité décidaient alors de mettre en place un système de supervision redondant sur ordinateurs PC sous Windows afin de s'appuyer sur un standard répandu et évolutif.

Sécuriser par redondance un système de supervision

Lorsque l'on souhaite sécuriser par redondance un système, on peut comme cela se fait encore bien souvent aujourd'hui se contenter de juxtaposer deux systèmes indépendants fonctionnant en parallèle. Cela consiste en pratique à installer deux postes serveurs indépendants pour le traitement des données. Les postes de conduite opérateurs, couramment appelés postes clients, s'adressent en temps normal au poste serveur principal, qui assure le traitement des données.

Voici ce qui se passe alors lorsque le poste principal subit une défaillance : 

• Il faut faire un certain nombre de manipulations sur les postes clients pour qu'ils s'adressent au serveur secondaire, et non plus au serveur principal.
• Les données du poste secondaire ne sont pas parfaitement à jour. Seules le sont les données issues des automates, mais pas celles propres à la supervision : informations d'acquittement du défaut, consignes internes (seuil de déclenchement d'une signalisation de défauts par exemple commandes de traitement local, etc.)
• Les données d'histoires ne sont pas parfaitement identiques puisque outre qu'elles ne contiennent pas toutes les informations internes à la supervision sur le poste secondaire, l'asynchronisme de la communication ou des horloges fait que les événements peuvent être datés avec des valeurs légèrement différentes.

Au retour au fonctionnement normal sur le serveur principal, on ne dispose pas des informations d'historique emmagasinées sur le poste secondaire pendant la période de défaillance. Les variables internes propres à la supervision ( le contexte) ne sont également pas restituées.

Il convient également de mentionner la difficulté à tenir à jour en parallèle deux systèmes identiques, car les modifications doivent le plus souvent être copiées ou recopiées manuellement d'un système à l'autre, ce qui génère très fréquemment des erreurs.

De tels systèmes, que l'on peut grosso-modo qualifier de redondance à froid, ont déjà l'énorme avantage de permettre de ne pas se retrouver complètement "dans le noir" en cas de défaillance du poste principal : on dispose d'un outil de secours pour "voir et agir" sur le procédé. Malheureusement, cela ne permet pas de garantir qu'on mènera toutes les opérations avec une parfaite connaissance de ce qui a été fait auparavant et la continuité des enregistrements (traçabilité) ne sera pas assurée correctement.

C'est ce qui a conduit les responsables à imposer des contraintes techniques fortes lors du renouvellement de 1994 :

• Mise en place de deux réseaux de communication redondants entre la supervision et les automates. Cheminement du câble nettement séparé ;
• Unicité des données : une seule source d'information valide à l'instant T sert à générer les données qui sont diffusées sur les composants redondants ;
• Unicité et complétude de la sauvegarde du contexte applicatif : états courants, consignes, acquittements tenus à jour en permanence sur les postes ;
• L'unicité du contexte ne doit pas conduire à déporter les variables de supervision dans l'automate : lorsqu'on assure l'unicité des variables en les plaçant dans les automates, les modifications de l'application de la supervision risquent d'induire des modifications des programmes automates, lesquels doivent alors être rechargés ce qui entraîne des arrêts de production.

Topkapi, la solution adéquate pour ce système de supervision

Le choix du système de supervision s'est alors orienté vers le logiciel Topkapi d'AREAL, qui répondait aux exigences techniques tout en offrant des principes très simples pour la mise en œuvre : 

• configuration centralisée depuis un seul poste ;
• répartition des traitements entre différents postes serveurs qui se secourent mutuellement ;
• paramétrage de la redondance se limitant à déclarer pour chaque automate en poste de traitement principal et secondaire.

Tout le reste de l'application se paramètre comme une application normale monoposte ;

• fusion automatique des données historiques et de contexte au retour à la marche normale ;
• basculement automatique des postes de conduite vers le serveur actif (pour l'opérateur le changement de serveur est parfaitement transparent).

 
Contrairement à ce que l'on aurait tendance à penser, le surcoût d'une redondance à chaud respectant ces principes est très limité par rapport à une redondance à froid décrite plus haut. Dans les deux cas en effet, l'essentiel du surcoût par rapport à une solution non redondante provient de la nécessité d'installer un second poste de supervision. On a ainsi pu constater dans des applications récentes qu'il était plus économique d'installer une redondance à chaud qu'utiliser un système monoposte à base de PC sécurisé en technologie RAIDS. La maintenance des systèmes est elle-même facilitée du fait que l'application de supervision est vue comme unique et qu'il n'y a pas à administrer deux instances miroir d'une application classique.

Un autre aspect important du projet tient au fait que le système de supervision mis en place devait permettre le fonctionnement en parallèle de l'ancien et de ce nouveau système, le logiciel Topkapi venant se placer en "espion" sur le réseau de communication existant. Cette technique, bien maîtrisée par AREAL, est également utilisée pour des projets de moindre importance; les phases probatoires de test peuvent ainsi se dérouler en toute sérénité.

Un système de supervision évolutif et pérenne 

L'ensemble mis en place à l'origine à la Centrale Emile Huchet comportait 9 postes de conduite Topkapi sous Windows (PC avec processeurs 486), 13 automates, 8 000 variables. Il a ensuite évolué de façon régulière. Il est désormais composé de 16 postes ; le protocole Ethway sur Ethernet a été choisi en remplacement de Modbus pour équiper le réseau redondant d'automates ; un réseau en fibre optique a été installé sur ce site industriel étendu (environ 2 km x 2 km) et électriquement très perturbé. Ce réseau redondant, permet de faire transiter sur un même support les données automates et les liaisons inter PC, mais aussi d'effectuer de manière centralisée la programmation des automates et la configuration des postes Topkapi (notion d'application unique avec traitement réparti et redondant).

Toutes les opérations sont maintenant supervisées depuis la salle de contrôle, y compris les installations mises en service depuis 1994 : séchage des cendres et Unité de Préparation de Produits Composés (UPPC). Cette dernière unité permet de valoriser les cendres de combustion (capacité de 800 tonnes/jour) pour la préparation de ciment, produits routiers, amendements calcaires pour l'agriculture, et d'autres produits. Dans cette installation, le logiciel Topkapi pilote les équipements de mélange, pesage, stockage et expédition. Des applicatifs spécifiques ont été réalisés pour répondre aux besoins particuliers propres aux recettes et aux expéditions : l'ouverture de Topkapi lui permet de recevoir très facilement la greffe de traitements complémentaires.

Aujourd'hui, le système de supervision de cette usine est parfaitement entretenu et en phase avec d’autres systèmes récents. On aurait parfois tendance à l'oublier, mais il ne suffit pas toujours de choisir un logiciel qui marche à un instant donné ; il faut tenir compte des coûts ultérieurs de maintenance ('cost of ownership') et de la capacité à évoluer sans remettre en cause les investissements antérieurs (compatibilité ascendante).