Le CRC 1985 – 1995

Préambule

 

L’objectif premier du projet CRC était de réaliser la mise en service des Centres Régionaux de Conduite comme cela était la cible dans le SDART de 1973.

 

Compte tenu des difficultés et délais important pour la réalisation des SIRC, la décision a été prise de s’appuyer sur un produit du marché et l’industriel retenu fût CEGELEC.

 

L’idée de base était de réaliser un système de dispatchings à la pointe de la technique :

 

  • EDF apportait ses compétences au niveau exploitation et le financement des évolutions nécessaires au produit de base pour atteindre le niveau d’excellence visé.

 

  • CEGELEC réalisait le CRC, le vendait et donc assurait une maintenance mutualisée entre plusieurs clients, ce qui devait se traduire par une modération des coûts et une pérennité de la maintenance.

 

Les spécifications

 

Pour ce qui est des fonctions classiques d’un SCADA, l’accent a surtout été mis sur :

 

  • L’homogénéité des dialogues, des symboles, des couleurs.
  • La minimisation des « clic » lors des dialogues
  • L’adaptation du contenu des images au contexte
  • La définition d’images adaptées aux situations d’exploitation (habituelles et exceptionnelles)
  • La volumétrie des téléinformations : la volonté de pouvoir estimer l’état du réseau et la nécessité de disposer de nombreuses informations pour les contrôles de la télécommande ont amené une explosion du nombre de téléinformations à acquérir et traiter
  • Une génération des données internes le plus automatique possible
  • Le basculement de calculateurs sans perte d’informations

 

Par ailleurs deux grandes nouveautés ont été introduites :

 

  • La télécommande par listes et ordres de fonction avec surveillance des conditions de manœuvres (prévention des manœuvres de sectionneurs en charge, prises en compte des informations sur le matériel et sur la captation et transmission des informations, surveillance des modifications de topologie non attendues…)

 

  • La synthèse d’alarmes par intelligence artificielle. Moyennant une temporisation limitée, le système identifiait la nature des défauts électriques en prenant en compte les informations reçues, leur chronologie et les données fines concernant les plans de protections et les réglages des automates.

 

L’environnement du CRC

 

L’arrivée du CRC a été le déclencheur pour un travail en profondeur sur la normalisation des informations du terrain. (En plus d’un vaste travail au niveau des fileries, on citera par exemple l’identification des glutes voire leur disparition, la mise à nveau de différentielles de barres, l’appellation des jeux de barres et des tronçons et sections associés, etc. ).

 

Cela a aussi été le lancement de réflexions sur le partage de l’activité de commande sur les postes, sur les délégations de conduite, sur les actions à entreprendre par les dispatchers en cas de survenue d’informations sur les matériels.

 

La réalisation

 

La réalisation a été menée par CEGELEC.

 

Elle s’est heurtée à plusieurs points durs :

 

  • Le fonctionnement en bi-calculateur pour permettre la reprise à chaud en cas de panne
  • Le volume de code pour réaliser des fonctions a priori relativement standards
  • La durée de réalisation bien plus longue que prévue qui a induit la nécessité d’effectuer des évolutions fonctionnelles pour répondre aux besoins de la conduite et la nécessité de préparer le raccordement au réseau ARTERE alors même que le système n’était pas stabilisé.

 

 

Par contre, les deux fonctionnalités nouvelles les plus complexes (télécommande et synthèse d’alarmes) ont fonctionné de façon satisfaisante lors de l’expérimentation de saint Quentin :

 

  • Concernant la synthèse d’alarmes, dans l’immense majorité des cas le diagnostic était le bon, dans un certain nombre de cas, qui en fait étaient complexes, le système a indiqué qu’il ne savait pas conclure. Aucun diagnostic erroné n’a été proposé. Néanmoins il est apparu que le nombre de fois pour lequel la synthèse d’alarme aurait pu accélérer la reprise de service par le dispatcher est resté très faible. Par ailleurs la fragilité du système à la qualité des données de type contrôle électrique était importante.

 

  • Concernant la télécommande, les fonctionnalités ont été jugées d’un apport significatif pour la sûreté mais le parti-pris de vouloir traiter la grande majorité des cas rencontrés sur le réseau a amener à complexifier l’interface homme machine pour les cas les plus fréquents ce qui a écarté la fonction de son optimum.

 

 L’impact sur l’exploitation du réseau

 

L’impact sur l’exploitation du réseau et sur les relations entre exploitants a fait l’objet de nombreuses études : Gestion du partage de l’activité de commande, gestion des retraits de la conduite des réseaux, manœuvres pour l’entretien périodique des ouvrages, situations d’incidents réseaux, situations de secours. Il en a découlé des évolutions des règles générales d’exploitation et la mise en place de formation pour les agents de groupement et pour les dispatchers

 

L’arrêt du projet

 

La dérive des délais, celles des coûts, l’évolution des matériels support, le changement de politique e industrielle de CEGELEC suite au rachat d’une entreprise américaine spécialisée dans les dispatchings ont amené EDF et CEGELEC à décider d’un commun accord d’arrêter le projet informatique.

 

Si le développement informatique a été perdu, le projet aura néanmoins permis un travail important de normalisation sur le terrain et un retour d’expérience riche sur les impacts de l’exploitation en Centre Régional de Conduite sur les règles d’exploitation et sur le partage fin des rôles entre groupements de postes et dispatchings.

 

 

Fermer
Saisissez le numéro de l'œuvre
1
2
3
4
5
6
7
8
9
0
Accéder