|

SETNE : centrale thermique 1 200 MW
|
La SETNE, filiale des
charbonnages de France (CDF) exploite la centrale thermique de
production d'énergie électrique Emile Huchet en Moselle, dans l'Est
de la France. D'une capacité de 1 200 MW électriques, soit
l'équivalent d'une tranche de centrale nucléaire, cette unité
utilise le charbon pulvérisé comme énergie primaire. |
Les installations 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.
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.
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 oeuvre : 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 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
mis en place devait permettre le fonctionnement en parallèle de
l'ancien et du nouveau système de supervision, 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é.
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, 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, la supervision de cette usine est parfaitement entretenue et en phase avec les 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). Un logiciel ne s'use pas comme un équipement mécanique, mais il vieillit terriblement vite …
|