Les projets SNC et SRC

 

Le contexte à EDF : le Programme Téléconduite 2000

 

La fin du déploiement des SIRC marque la fin du déploiement du SDART. En 1990, lui succède un ambitieux programme de rénovation des dispatchings dont l’objectif est la mise en place d’un réglage entièrement automatique de la production d’électricité : le programme CASOAR(1), échelonné en 3 paliers.
Le début de la mise en œuvre du premier palier (2) à la Production Hydraulique montre que les travaux au niveau des automatismes des groupes sont lourds et délicats et vont nécessiter pour les plus anciens une rénovation prématurée. L’horizon pour la mise en place du réglage automatique de la production s’éloigne alors de façon indéterminée.

 

Fin 1994, le Programme Téléconduite 2000 se substitue au Programme CASOAR. Le réglage automatique de l’ensemble de la production est abandonné. Le but est désormais la rénovation des équipements de téléconduite du Système Production-Transport. Les équipements du palier SDART, lancé vingt ans auparavant, entrent en effet dans leur période d’obsolescence. Ils sont devenus difficiles à maintenir et ne permettent plus les évolutions indispensables.

Le Programme Téléconduite 2000 reprend à son compte des projets déjà lancés sous CASOAR et met en œuvre de façon coordonnée les nouveaux projets. La pièce centrale de ce programme est le projet ARTERE qui vise à remplacer le réseau de transmission des informations de téléconduite temps réel (TTR) par un réseau à valeur ajoutée s’appuyant sur un réseau X25 privé à commutation de paquets. L’accès à ce réseau s’effectue par le biais de Stations-Réseau implantées dans les Dispatchings, les PCG et les centrales. ARTERE est un réseau à valeur ajoutée : il permet notamment le groupage, la multi-diffusion et offre différents niveaux de service pour la transmission d’informations. Pour se connecter à ARTERE, un EA(3) doit intégrer une suite de logiciels appelée LCA(4) en savoir plus sur la Migration vers Téléconduite 2000

Schéma de principe du Réseau Artère

Le renouvellement du SCADA du Dispatching National (projet SNC)

La stratégie d’approvisionnement retenue pour le SNC sera la suivante :

  • Procéder par appel d’offre (l’échec du projet CRC n’incitait pas à poursuivre dans la voie d’un partenariat),
  • S’appuyer, autant que faire se peut, sur les produits des fournisseurs,
  • Garder EDF comme fournisseur des fonctions avancées réseau.

Le projet SNC démarre en 1995 par une étude détaillée des produits des principaux fournisseurs de SCADA. L’objectif est alors double :

  • S’assurer de la capacité des produits à répondre aux besoins du dispatching national,
  • Orienter la rédaction du cahier des charges pour minimiser les volumes de développement spécifique.

L’équipe de projet SNC, enchaîne en 1996 sur la conduite de l’appel d’offre qui comportera les étapes suivantes :

  • La rédaction du dossier de consultation : cahier des charges et contrats,
  • La préparation de la consultation : définition des critères d’attribution, de la méthode de dépouillement et de notation des offres,
  • La consultation, le dépouillement des offres et l’attribution du contrat.

Le cahier des charges présentait, par rapport à ce qui se pratiquait à l’époque, quelques nouveautés intéressantes :

  • Une séparation dans le texte entre les exigences contractuelles et ce qui tenait du commentaire ou de l’explication,
  • De nouvelles classes d’exigences apparaissaient comme :
  1. Les exigences de management, de qualité et de sécurité On y traitait par exemple les modes de communication entre le fournisseur et le client, le phasage du projet et les conditions de passage d’une phase à l’autre, les processus de recette, etc.
  2. Les exigences relatives à l’administration du système informatique.
  • Les fournitures d’EDF étaient répertoriées au même titre que celles du fournisseur.
 

A l’issue du dépouillement, le marché est attribué au mieux disant(5), la société Sema-Group(6). L’offre de Sema-Group était basée sur le produit ADACS déjà utilisé à EDF dans le contrôle commande des centrales nucléaires du palier N4 (Chooz et Civaux).

La réalisation démarre en 1997 et se termine en 2001 avec la prononciation de la recette de la version V1. Le SNC entre alors dans la phase dite d’exploitation sous contrôle, phase pendant laquelle le système précédent (SYSDIC) est maintenu apte à reprendre la conduite à tout moment. D’importantes difficultés de fonctionnement vont perturber cette période (problèmes de robustesse, découvertes d’anomalies importantes). Le doute sur la qualité du produit livré va s’installer et les audits vont s’enchaîner. Ils ne remettront pas en cause la conception du Système mais contraindront SEMA-Group à apporter les améliorations et corrections nécessaires. C’est seulement en juin 2004, soit trois ans après la date prévue, que la mise en service définitive du SNC sera prononcée.

Le renouvellement des SIRC : le projet SRC

Les études préliminaires du projet SRC (1996-1998)

Le noyau dur de l’équipe de projet est constitué en 1996. C’est une équipe mixte, constituée non seulement d’agents ayant participé à des projets mais aussi d’agents ayant exploité le réseau électrique. Cette équipe s’est impliquée à tirer les enseignements du passé et à mettre en pratique les règles de la gestion de projet édictées par le Département Contrôle Commande et celles issues de l’audit Gaussot.

L’équipe de projet SRC fin 1999 ; la fin du tunnel est encore loin

Les premières tâches auxquelles l’équipe de projet s’attelle sont :

  • Définir le contour du projet,
  • Proposer une stratégie de réalisation,
  • Définir le contour fonctionnel,
  • Définir les principes directeurs du projet.

Le contour du projet :
La tentation aurait pu être d’en profiter pour rénover d’autres outils que le SCADA comme le simulateur d’entraînement des dispatcheurs ou l’animateur de tableau synoptique, sachant que la plupart des fournisseurs de SCADA incluent dans leur offre de tels outils. La prudence conduira à se limiter au seul SCADA.

La stratégie de réalisation :
La direction d’EDF confirmait pour le SRC la politique du faire-faire retenue pour le SNC. Quant à la méthode d’achat, dans le contexte de l’Europe et pour un marché de cette importance, l’appel d’offre (Européen) s’imposait.
Par ailleurs, pour limiter les risques (et les coûts), les orientations suivantes étaient retenues :

  • Ne sélectionner que des fournisseurs ayant un produit sur étagère et l’expérience de ce type de réalisation,
  • Limiter au maximum les développements spécifiques,
  • Fournir nous-mêmes les fonctions n’ayant pas l’équivalent chez les fournisseurs et les intégrer avec les matériels et les interfaces programmatiques (API) du fournisseur. Seront concernés les calculs de réseau et le réglage de la tension.

Le contour fonctionnel
Etape fondamentale dans le projet, elle avait pour objectif de définir le juste besoin du dispatcheur tout en tenant compte des capacités des fournisseurs. La tâche en sera confiée à un groupe de travail composé de membres de l’équipe de projet et de représentants d’utilisateurs régionaux. Ce groupe s’appuiera sur l’analyse des produits des fournisseurs, sur un retour d’expérience poussé du SIRC, sur l’analyse de l’échec du CRC (notamment la simplification d’un certain nombre d’exigences) et sur les résultats de l’expérimentation CRC (pour la télécommande et la synthèse d’alarme) pour établir :

  • une liste de fonctions obligatoires,
  • une liste de fonctions optionnelles,
  • une fiche descriptive de chaque fonction destinée à servir de point de départ pour la rédaction du cahier des charges.

Les principes directeurs
La nécessité de définir des principes est apparue lorsque l’équipe de projet a commencé à réfléchir au déroulement du projet et à se poser des questions du type, qui fait quoi, quand et comment le fait-on. Ne pas se poser ces questions présentait

  • soit des risques de surcoût : obligation de commander au fournisseur des matériels ou des prestations supplémentaires,
  • soit le risque qu’EDF se retrouve sur le chemin critique du projet en devant réaliser des tâches qu’il n’avait pas prévues.

L’examen des différentes phases du projet va permettre de dégager des principes dans les domaines suivants :

  • Les essais et les recettes,
  • Les déploiements,
  • La migration,
  • La formation,
  • La maintenance des matériels.

Ces principes serviront de base pour la rédaction des exigences du cahier des charges relatives au plan de déroulement, aux fournitures (matérielles, logicielles et services) et à certains aspects techniques (réalisation d’un mode de fonctionnement passif du SRC par exemple). En savoir plus sur Les principes directeurs du projet SRC

 L’appel d’offre (1998-mi-2000)

Cette période couvre les étapes suivantes :

  • La rédaction du dossier de consultation
  • La sélection des fournisseurs,
  • L’élaboration du prix d’objectif,
  • La consultation en elle-même.

Les intervenants dans le projet sont convaincus que tout va se jouer avant la signature du contrat et que la réussite du projet est essentiellement tributaire de la qualité du cahier des charges et du choix du fournisseur. Tout sera donc mis en œuvre dans cette phase pour minimiser les risques d’aléas et garantir la qualité finale du produit.

La rédaction du dossier de consultation
Il s’agit de l’ensemble qui allait être envoyé aux soumissionnaires. il comportait :

  • Le cahier des charges (ensemble de Cahiers de Clauses Techniques Particulières ou CCTP)
  • Le règlement de la consultation : critères de notation des offres, critères d’attribution (mieux disant, moins disant), éléments attendus en réponse à la consultation,
  • Les contrats de réalisation et de maintenance.

Pour ces derniers documents, le projet bénéficiera de l’appui efficace de la Direction des Achats et du Service Juridique d’EDF.

Le projet SNC avait mis en évidence la difficulté de cette étape et c’est un processus de production véritablement industriel que l’équipe de projet SRC mettra en place. En savoir plus sur la rédaction du cahier des charges du SRC.

La sélection des fournisseurs
L’objectif de cette étape est d’attirer un nombre suffisant de fournisseurs pour obtenir une réelle mise en concurrence, tout en gardant un nombre raisonnable pour limiter le travail de dépouillement des offres. Le processus comporte 3 étapes :

 
  • L’appel à candidature qui se fait par une publication au JOUE(7),
  • L’examen d’aptitude a pour but de s’assurer que le fournisseur sera capable de réaliser le projet. Il s’appuie sur un questionnaire et un examen des produits du fournisseur,
  • Le passage de la liste longue à la liste courte lorsque le client estime qu’il y a trop de candidats. Cette étape ne sera pas nécessaire pour le SRC, la connexion à ARTERE en ayant rebuté certains.

L’élaboration du prix d’objectif
La démarche consiste à évaluer le coût total du projet (EDF + fournisseur) ainsi que des fourchettes hautes et basses pour les coûts fournisseur. Cela va permettre :

  • D’établir des prévisions budgétaires pluriannuelles,
  • De repérer des cas de dumping ou d’incompréhension de l’offre,
  • De déclarer une consultation infructueuse si les prix sont tous au-dessus de la fourchette haute.

La consultation
Fin 1998, la Direction du Programme Téléconduite 2000 estime que la réalisation du projet SNC est suffisamment avancée et donne son feu vert au lancement de la consultation. En guise d’étrennes, les soumissionnaires reçoivent donc 5 gros classeurs regroupant près de 3000 exigences. Un délai de 4 mois leur est accordé pour élaborer leur réponse. Pendant cette période, l’équipe de projet SRC répond aux questions des fournisseurs et prépare les grilles d’analyse et de notation pour le dépouillement.

 

Les offres sont reçues début mai 1999. Conformément à la procédure, les offres techniques sont analysées dans un premier temps, les offres commerciales restant sous scellés. Les manques et non conformités sont signalés aux fournisseurs et il leur est demandé de fournir une nouvelle version de leurs offres techniques et commerciales. Les nouvelles offres sont reçues en octobre 1999 et l’ouverture des offres commerciales peut enfin avoir lieu. C’est l’instant de vérité car le prix intervient de façon prépondérante dans la notation. Le mieux disant s’avère être la société THALES, avec son produit SCADAsoft(8). S’engage alors une phase de négociations avec THALES visant à choisir les options et finaliser les contrats de réalisation et de maintenance. Après un passage devant les différentes instances décisionnelles de RTE, les contrats de réalisation et de maintenance sont signés en juin 2000.
Il faut noter qu’entre-temps la mise en place de RTE s’accompagne d’une réorganisation de l’informatique et des télécommunications. Le projet SRC va se dérouler au sein d’une nouvelle unité le Centre National d’Ingénierie et d’Information (CN2I) chargé d’assurer le pilotage opérationnel de l’ingénierie et de l’exploitation des Télécommunications et du Système d’Information de RTE. De plus, les équipes en charge de la maintenance et du développement des fonctions avancées réseau et réglage de la tension quittent EDF/DER/SER pour rejoindre un département nouvellement créé à RTE, le Département Méthodes et Appui (DMA).

 La réalisation (mi-2000-mi-2005)

Le plan de déroulement du projet prévoyait 3 livraisons principales avec les recettes associées :

  • Un prototype appelé Mini-SCADA comportant un sous-ensemble des fonctions dans une architecture simplifié. Non destiné à être déployé, il devait constituer un point de visibilité intermédiaire et éviter un « noir » de 3 ans,
  • Le système de configuration des données déployable en 8 exemplaires (7 CIME+plate-forme de maintenance),
  • Le système principal déployable également en 8 exemplaires.

Le Mini-SCADA
Il sera livré dans les temps (16 mois). Néanmoins la qualité du logiciel sera jugée moyenne (beaucoup de bugs). Il aura au moins eu le mérite :

  • De roder les processus de validation des documents et des réceptions,
  • De valider le maquettage de l’IHM dans un contexte dynamique,
  • De se rassurer sur la capacité du fournisseur à réaliser certaines fonctions (par exemple la connexion à ARTERE).

Le système de configuration
Basé sur le progiciel ORACLE, son mode de réalisation, qui comportait une bonne part de paramétrage et de génération automatique de code, s’écartera quelque peu du classique cycle de réalisation en V. Cela conduira RTE à découvrir tardivement des non-adéquations au besoin et à commander des évolutions en cours de réalisation. Le premier configurateur sera mis en service sur le site pilote avec 8 mois de retard. Le déploiement sur les autres sites se déroulera sans histoire et le produit donnera, au final, satisfaction.

Le système principal
Sa réalisation sera loin d’être un long fleuve tranquille et pas moins de trois réceptions usine seront nécessaires pour obtenir un produit déployable sur site. Les difficultés rencontrées portaient sur des thèmes malheureusement classiques à savoir les performances, la robustesse (plantages) et le fonctionnement de la redondance. Le fournisseur sera conduit à mener :

  • Deux plans d’amélioration des performances incluant optimisation des codes et portage de l’application sur des matériels plus performants (passage du PA-RISC à la gamme Itanium),
  • Un plan robustesse : pour ce faire, il montera une plate-forme dédiée aux essais en endurance et développera un outil simulant les actions des opérateurs.

La réception usine finira par être signée en juin 2005 avec 22 mois de retard.

Le déploiement (mi-2005-mi-2010)

Le site pilote (Lille)
Là encore le planning initial subira d’importants glissements. De nombreuses anomalies seront découvertes dans un contexte réel d’exploitation. La réception site, initialement monobloc, sera découpée en 3 parties, chacune associée à un lot de corrections (et d’évolutions pour la 3ème). Les conditions contractuelles de déploiement seront assouplies pour anticiper la découverte d’anomalies sur les autres sites. Du côté des dispatcheurs, l’acceptation de l’outil ne sera pas immédiate et la confiance dans l’outil mettra du temps à s’installer. Quelques adaptations de l’IHM seront mêmes nécessaires.
RTE rencontrera des difficultés pour migrer les applications aval (celles qui utilisent des données fournies par le SRC) en raison d’un changement des règles de nommage des ouvrages.
Au final, le début de l’exploitation sous contrôle glissera de juillet 2006 à novembre 2007 et durera 8 mois au lieu de 6, soit un décalage total de 18 mois. Le SIRC ne sera définitivement arrêté qu’en février 2009.

Déploiement sur les autres sites
Quelques difficultés seront rencontrées sur le deuxième site (Paris) en raison de la taille de la base de données, des particularités régionales (télécommande des turbines à combustion par exemple) et d’un mode d’utilisation différent de la gestion des alarmes. Ces difficultés seront surmontées et Paris passera en exploitation définitive le même mois que Lille. Pour les sites suivants le déploiement entrera en régime de croisière et les durées de la période d’exploitation sous contrôle ne cesseront de se réduire. Le dernier site (Nantes) sera mis en exploitation définitive l en juillet 2010

Le bilan du projet

En incluant la phase d’étude, il avait fallu 13 ans pour développer et déployer les SIRC, il en aura fallu 14 dans le cas du SRC et cela malgré une organisation et une méthodologie sans commune mesure.

Pourquoi tant de difficultés ?
La marche à franchir était manifestement trop haute pour le fournisseur et cela pour deux raisons principales :

  • Un volume de développement spécifique important (estimé à 50% de l’ensemble),
  • Un produit pas calibré pour la taille d’un dispatching français ; SCADAsoft n’avait été jusqu’à présent utilisé que pour contrôler des processus :
  1. Soit comportant beaucoup de données mais avec de longues constantes de temps (gaz, pétrole),
  2. Soit avec peu de données mais des constantes de temps courtes (transports, petits réseaux électriques),

         mais jamais avec de telles exigences de volume et de temps.
En outre, les études techniques se sont révélées insuffisantes. La réponse à l’appel d’offre comportait une pré-étude d’architecture et un dossier justificatif de performances. Pour des raisons de coût, RTE s’est contenté d’une mise à jour de ces études en phase de réalisation. Avec le recul, il apparaît que le sujet avait été traité de façon superficielle.
Enfin, le Mini-SCADA, insuffisamment ambitieux n’a pas joué son rôle de signal d’alarme, ce qui a reporté la détection des problèmes à la réception usine.

Mais alors, pourquoi s’en est-on sorti ?

C’est d’abord grâce à un contrat de réalisation en « béton » comportant un échéancier de paiement incitatif pour le fournisseur avec des échéances importantes calées sur les réceptions et une répartition des paiements tenant le fournisseur en haleine jusqu’à la fin.
C’est ensuite grâce à l’implication des Directions de RTE et Thales qui ont su concilier réalisme et fermeté dans le pilotage à haut niveau du projet, et adapter les moyens tant en nombre qu’en compétences. En savoir plus sur ce qui a plus ou moins bien marché dans le projet SRC

Parlons de l’outil SRC

La complexité et la difficulté de ce projet ne doivent pas nous faire oublier que son objectif était de fournir aux dispatcheurs un outil dont nous détaillons à présent les caractéristiques.

L’architecture et les matériels
Le SRC, même s’il intègre les derniers standards en matière de sécurité (coupe-feu, authentification des utilisateurs) présente une architecture des plus classiques pour un SCADA. Un serveur principal doublé abrite les fonctions critiques tandis que les autres fonctions sont réparties sur des serveurs non doublés. Le mécanisme de redondance employé sur le SRC est une redondance synchrone à chaud. Les deux machines sont connectées à ARTERE et reçoivent les mêmes flux de données de téléconduite. Elles effectuent les mêmes traitements en parallèle, mais seul le Maître a le droit d’émettre vers ARTERE. Ce mécanisme permet de garantir qu’en cas d’avarie matérielle, aucune perte d’acquisition ou d’action opérateur n’a lieu. Elle permet par ailleurs de rendre le mécanisme de redondance transparent du point de vue de l’opérateur.
Les serveurs sont fournis par Hewlett-Packard de même que les écrans qui cathodiques dans les premières livraisons ont vite été remplacés par des écrans plats. En savoir plus sur l’architecture et les matériels des SRC

Les fonctionnalités
Le principal changement pour le dispatcheur, c’est l’interface Windows, offrant la manipulation de fenêtres, les menus déroulants, les boites à cocher, les boutons radio, les saisies dans des listes limitatives, etc.

 

Autre avantage, Les fonctions avancées sont désormais accessibles depuis les écrans du SRC(9)
L’imagerie s’enrichit des images de cellule et des images de quart (ensemble d’images de poste). Lien vers « Imagerie typique des SCADA Electriques »
Côté fonctionnel, c’est bien entendu la télécommande qui constitue la principales nouveauté. La télécommande par ordre élémentaire, déjà présente sur le SIRC est complétée par :

  • La télécommande par ordre de fonction,
  • La télécommande à partir de listes d’ordres élaborées par le dispatcheur.

Complément à rajouter

 

L’administration
L’équipe projet avait fait un gros effort pour spécifier des fonctions d’administration garantissant une exploitation facile et fiable du SRC. Le résultat est plutôt mitigé. Malgré l’utilisation d’un progiciel d’administration, les opérations(10) restent complexes et étaient au début, la principale source d’indisponibilité soit par suite d’erreur humaine soit par suite d’un comportement non nominal du SRC.

Les dispatchings de repli

Afin d’augmenter la continuité de service et la fiabilité des systèmes de dispatching, en plus de la redondance à chaud offerte par le système, une redondance à froid (ou tiède) a été prévue à l’aide d’une troisième chaine située dans un lieu physiquement éloigné de dispatching principal et nommé dispatching de repli (DRR).
Leur objectif est de permettre :

  • une reprise de la conduite du système électrique avec des moyens minimaux et sous un délai de quelques heures,
  • la conduite du système électrique dans des conditions proches de la normale sous un délai de quelques jours.

Dans ce but, le DRR dispose de moyens techniques implantés à demeure. L’installation est conçue pour accueillir ultérieurement des équipements complémentaires en cas de repli prolongé.

Les équipements à demeure :

  • un point d’accès au réseau de téléconduite représenté par un CACQ à l’époque du palier SDART, des Stations Réseaux pour le palier ARTERE.
  • Un tableau synoptique réduit,
  • Un animateur de tableau synoptique,
  • Les équipements de téléphonie semblables à ceux du dispatching principal,
  • Un SCADA non doublé et sans les serveurs annexes (cas du SRC),
  • Deux postes opérateur complets.

Réseaux locaux et alimentations sont déjà en place pour compléter la configuration du SRC (postes opérateurs, serveurs annexes, système de configuration).

Les essais périodiques :
On ne peut garantir le bon fonctionnement d’un système dormant qu’en réalisant périodiquement des essais de passage en replis. Ces essais ne sont pas simples ; ils nécessitent des actions d’administration sur le réseau ARTERE, des commutations de voie, etc. Cette complexité est à l’origine de difficultés qui ont amené à durcir les procédures et à réfléchir à repenser la fonction de repli. Ainsi sera lancé en 2009 dans le cadre du projet « Exploitation 2010 » un chantier visant à étudier puis expérimenter d’autres solutions.

——————————————————————————————————————–

 

(1) Commande Automatique du Système Optimisé en Actif compte-tenu du Réseau :

 

(2) Remontée des informations nécessaires, des Centrales vers les Dispatching

Retour

 

(3) Equipement d’Application : tous les équipements ayant un rôle fonctionnel comme les SCADA

 

(4) Logiciel de connexion à ARTERE

Retour

 

(5) Fournisseur obtenant la meilleure note, cette note étant une combinaison d’une note technique et d’une note commerciale (prépondérante). Dans une attribution au moins disant, seul le prix de l’offre intervient.

 

(6) Société de Service en Informatique française, rachetée en 2001 par Schlumberger pour donner le groupe SchlumbergerSema. Ce dernier sera racheté par le groupe ATOS en 2004.

Retour

 

(7) Journal Officiel de l’Union Européenne

Retour

 

(8) Produit essentiellement utilisé dans la gestion des trains et des métros

Retour

 

(9) Utilisation du serveur X Exceed

Retour

 

(10) Par exemple, mise en service d’une nouvelle version de base de données ou de logiciel, sauvegardes, réinsertion de machines après arrêt pour maintenance, paramétrages des composants réseau, gestion des droits d’accès.

Retour

La rédaction du cahier des charges du SRC

Voici ce qui avait été mis en place afin de garantir une production de qualité :

Au niveau de la forme :

  • Un modèle Word uniforme est imposé pour la rédaction,
  • Le principe adopté au SNC de distinguer le commentaire de la spécification est repris et  poussé encore plus loin en décomposant chaque spécification en exigences élémentaires  comportant le moins d’ambigüité possible et numérotées dans le but de faciliter les échanges avec le fournisseur, les recettes et la gestion des modifications.
   SP/6/E 340 Pour tous les ouvrages (lignes et transformateurs), le SRC doit réaliser, de façon systématique, un calcul d’intensité à chaque extrémité disposant au moins d’une mesure de puissance active.

Figure 16 : exemple d’exigence du cahier des charges

     Dans l’exemple présenté ci-dessus :

  •  SP identifie le composant (ici le  « Système principal »),
  •  6 est le numéro du chapitre,
  • E réfère à une exigence de base (il pouvait y avoir des exigences en option repérées par la lettre O),
  • 340 est le numéro de l’exigence dans le chapitre. Les exigences étaient numérotées de 10 en 10, afin de permettre des adjonctions.

Au niveau de l’organisation :

  • Pour chaque domaine, les documents de référence en entrée sont définis ainsi qu’un double circuit de validation (interne au projet puis externe),
  Au niveau du contenu :
  • Les thèmes comme la configuration des données et l’administration des systèmes, sont traités avec la même profondeur que les traitements temps réel et spécifiés en fonction de l’état de l’art du moment,
  • Les exigences de dimensionnement, de performance et de disponibilité et les conditions dans lesquelles les tests seront menés sont finement spécifiées, l’objectif étant de s’assurer que le SRC gardera un fonctionnement nominal en toute circonstance y compris en cas d’incident réseau généralisé (1),
  • Les fournitures de toute nature (matériel, documentation, prestations) sont identifiées et quantifiées aussi bien pour le fournisseur que pour EDF,
  • Les exigences de management et de qualité sont élaborées d’après la norme ISO 9001 et le guide de conduite de projet du DCC. Un plan de déroulement décrit les phases du projet et les conditions de passage d’une phase à l’autre.
  • Des exigences de sécurité informatiques apparaissent visant à protéger le système contre les intrusions et à contrôler les intervenants.

La composition du cahier des charge envoyé au Soumissionnaires sera la suivante, composition qui sera d’ailleurs et on ne peut que s’en féliciter  reprise dans des projets ultérieurs :

  • CCTP exigences techniques
  • CCTP consistance et limites de fourniture
  • CCTP Dimensionnement, performances et sûreté des Systèmes
  • CCTP Configuration des données
  • CCTP Management, Qualité et Sécurité
  • CCTP Fonctionnement en mode actif/passif
  • CCTP Raccordement du SRC à Artère
  • CCTP Echanges avec l’extérieur
  • CCTP Fonctions d’administration
  • CCTP Contraintes
  • CCTP API fonctions avancées
  • CCTP Garantie
  • CCTP MCO
  • CCTP Réversibilité (en cas de reprise de la maintenance par un autre fournisseur)

_______________________________________________________________________

 
(1) Des déclenchements de ligne en cascade se traduisent par une avalanche de changements d’état de signalisations et par de grandes variations de mesure, ce qui sollicite fortement le SCADA. (recalcul de topologie, génération d’alarmes, rafraîchissement des images, etc.)

Les principes directeurs du projet SRC

Les principes directeurs du projet SRC

Le projet SRC a bénéficié, au cours de ses différentes phases, de la présence de personnes ayant joué des rôles clé dans les projets précédents (90-40, SIRC, CRC). Au-delà de la capitalisation au niveau de l’entreprise – qui reste toujours très faible et parcellaire, voire ignorée (les temps ont changé, les prédécesseurs étaient moins performants,…) – le vécu des personnes est un atout pour la construction d’une référence de travail.

L’examen des différentes phases du projet a donc permis de dégager des principes dans les domaines suivants :

Les essais et les recettes

Les projets précédents avaient permis d’identifier que c’était un point faible récurrent, conduisant à des déconvenues lors des installations sur site. Il est donc décidé :

  • Qu’une recette en plate-forme EDF sera intercalée entre la réception usine et la livraison sur site pilote,
  • Que la télécommande devra pouvoir être testée off-line. La solution retenue est de simuler la réaction du réseau de téléconduite avec le simulateur d’entraînement des dispatcheurs, ce qui impose de développer une connexion entre ce simulateur et le SRC.

Les déploiements :

C’est une phase du projet particulièrement compliquée à gérer puisqu’elle mobilise à la fois l’équipe de projet nationale et les ressources humaines régionales. Il est décidé :

 
  • Un déploiement qui soit dans une logique de difficultés croissantes. Commencer par un petit site avec peu de particularités favorise une première étape de fonctionnement et permet d’engranger du retour d’expérience pour des sites plus importants en taille. Par ailleurs, les évolutions des bases de données (modifications de la structure, récupération du passé) nécessaires pour l’optimisation du système sont une épreuve d’autant moins contraignante que la base est moins volumineuse. Il a donc été choisi de commencer par Lille, puis d’enchaîner avec un site ayant une grosse base de données (ce sera Paris).
  • D’anticiper le peuplement de la base de données de chaque site, ce qui revient à livrer sur site le système de configuration 16 mois avant la migration (1)!
  • De lisser les charges humaines de déploiement en imposant au fournisseur des contraintes dans l’établissement du planning de déploiement (ex : pas de formation ou de migration en juillet-août).
  • La migration : pour le besoin des recettes sur site, il apparaît nécessaire de pouvoir faire fonctionner en parallèle l’ancien et le nouveau système. Il est donc décidé de faire développer pour chacun d’eux un mode dit passif dans lequel le système est connecté au réseau de téléconduite, fonctionne normalement mais ne peut rien émettre (et en particulier des télécommandes).

 La formation :

il est décidé :

  • que la formation des dispatcheurs aura lieu in situ, donc juste avant le début des opérations de migration, ce qui évitera des piqures de rappel en cas de décalage de la migration,
  •  que l’équipe nationale de projet formera, par site, des formateurs régionaux qui seront chargés de démultiplier leur formation,
  •  que la formation des agents tenant à jour la base de données et assurant l’administration des systèmes sera confiée au fournisseur (il en sera de même en phase de maintenance)

La maintenance des matériels :

le partage des responsabilités entre EDF et le fournisseur sont déjà définis à ce niveau, ce qui permet de dimensionner les lots de maintenance sur site.

Ces principes serviront de base pour la rédaction des exigences du cahier des charges relatives au plan de déroulement, aux fournitures (matérielles, logicielles et services) et à certains aspects techniques (réalisation d’un mode de fonctionnement passif du SRC par exemple).

 

_________________________________________________________________________

(1) On appelle migration l’ensemble des opérations à mener pour faire basculer la conduite de l’ancien vers le nouveau Système

retour

Le premier palier de dispatchings transport en france (1967-1988)

Cet ensemble d’articles présente la genèse des dispatchings de transport en France fin des années 1960, début des années 70.

Le contexte du projet

Le contexte d’exploitation du système électrique

Le développement important du réseau (en savoir plus), la mise en construction d’un parc de production de plus en plus centralisé, les exigences croissantes en matière de sûreté, de qualité et d’économie nécessitaient de mettre à disposition des dispatchings de plus en plus d’informations que l’on peut classer en deux catégories :

  • Les informations utilisées directement par les dispatcheurs en temps réel (télémesures, télésignalisations mais aussi informations obtenues par téléphone auprès du personnel des postes et centrales électriques),
  • Des informations supplémentaires utilisées pour élaborer
    o  les prévisions de consommation et les programmes de production (les traitements prévisionnels),
    o  les statistiques et la facturation des clients alimentés en THT/HT (les traitements a postériori).

Le premier type d’informations était acheminé depuis les postes et centrales par des équipements traditionnels basés sur l’analogique qui se sont révélés insuffisamment performants en terme de capacité, de précision et de disponibilité.
Quant au deuxième type, il faisait essentiellement l’objet d’une collecte manuelle puis d’un traitement sur machine à calculer qui n’était plus adapté au volume à traiter.

Le virage du numérique

Alors que la France des années soixante découvrait le rock’n’roll et le confort apporté par les débuts de l’électroménager grand public (en savoir plus), EDF, de façon novatrice a entamé le virage du numérique. En matière de système électrique, Il a porté sur deux volets, l’acheminement des informations au dispatching et les moyens de calculs, et s’est déroulé en 3 étapes :

    •  1961 : décision d’approvisionner un calculateur pour le dispatching national.
 

 Au début des années 60, les moyens de calcul dont disposait le dispatching national se réduisaient à une table à calcul à courant continu, utilisée pour des calculs de répartition de charge, les calculs de puissance de court-circuit et pour l’élaboration de plans optimaux de production (minimisation des pertes) (En savoir plus). Toutefois, le développement du réseau à 380 KV, l’arrivée de centrales de production à coûts marginaux (1) voisins  ont rapidement rendu ces moyens de calcul très insuffisants (en savoir plus).

 

La mise sur le marché des premiers ordinateurs à vocation scientifique, la naissance en France de compétences sur le développement de logiciels « temps réel », (au sein notamment de la CAE) ainsi que l’évolution prévisible des capacités de rapatriement des informations depuis les postes et les centrales (cf infra le projet « infos codées ») ont conduit la direction d’EDF à approuver la commande d’un premier ordinateur le 25 octobre 1961. Ce fût un CAE 510 (2) , construit par la Compagnie Européenne d’Automatisme Electronique (CAE) sous licence américaine .Il était livré sans système d’exploitation avec quasiment comme seul outillage un compilateur Fortran ! Il a été installée en 1963 au Dispatching national pour y accueillir les modèles de calcul développés par la Direction des Etudes et Recherches d’EDF (DER).

Un RW 530 grand frère du CAE  530.

on voit ici le pupitre et le lecteur perforateur de ruban papier et au deuxième plan les deux armoires du calculateur et celle du dérouleur de bande.

.

Il été remplacé ultérieurement par un CAE 90-80.

 

Il était prévu une montée en puissance de son utilisation en 3 étapes :
– Assurer la sécurité : implantation de calculs de réseaux (calculs de répartition, analyse de sécurité (impacts des déclenchements et calculs de courts-circuits (3)),

 

– Optimiser la production : implantation d’un modèle fournissant un plan de production des usines thermiques et hydrauliques pour le lendemain,
– Automatiser le réglage de la production : il s’agissait d’implanter l’algorithme du réglage secondaire fréquence-puissance (4) dans le calculateur

    • 1962 : lancement du projet « informations codées » (en savoir plus) dont l’objectif était le suivant :

 – Permettre le rapatriement en nombre au dispatching de télémesures avec une précision garantie de 1% et dans un délai de l’ordre de 10 secondes,
– Offrir à l’arrivée un format à la fois analogique pour présentation sur des enregistreurs (dont un certain nombre existaient) et numérique pour acquisition et traitements automatisés par un ordinateur.

 

L’offre de marché étant insuffisante, EDF a été conduite à faire réaliser des matériels sur la base de spécifications propres. Après la réalisation d’un prototype installé à Nantes en 1964, la fabrication en série a été lancée en 1965 et le déploiement s’est étalé de 1966 à 1971. La pièce maîtresse du dispositif était l’ERC (5) capable d’acquérir puis de transmettre toutes les 10 secondes 20 mesures ou 160 signalisations.

les ERC au poste des Tanneurs, site pilote, près de Nantes.

Les premiers à bénéficier de cette nouvelle technologie ont été les synoptiques qui outre les positions des organes de coupure pouvaient désormais afficher des valeurs de mesures sous forme de quartiles.

La salle du dispatching de Lille en 1962.

Il n’y a pas encore d’ordinateur, mais le tableau synoptique a pris de l’ampleur et les enregistreurs se sont multipliés.

    • Décision d’équiper tous les dispatchings en SCADA

 La mise à disposition aux dispatchings par le projet « infos codées » de mesures au format numérique a ouvert la voie à l’informatisation de tous les dispatchings. Décision fût donc prise vers 1964 d’équiper le dispatching national et les huit dispatchings régionaux d’un système informatique permettant l’acquisition des données en provenance du terrain, la présentation à l’opérateur de ces données, leur surveillance et la réalisation de post-traitements sur celles-ci ou des données introduites par ailleurs.

La réalisation

Les calculateurs retenus

Les calculateurs retenus ont été des calculateurs vendus par la CAE/CII de la série 90-XX. .

Dans son positionnement stratégique CAE s’était axé sur la réalisation de logiciels orientés temps réel à valeur ajoutée, Elle avait établi, à cet époque, que l’industrie des composants en France ne pouvait rivaliser avec celle des Etats-Unis, et que la construction de ses propres ordinateurs était trop risquée, alors que d’autre part, ses compétences en logiciels pointus était une opportunité à saisir, notamment avec le contrôle commande de la production thermique (classique et filière graphite gaz), les dispatchings et le domaine militaire. CAE/CII s’est donc associé avec Wooldridge dans un premier temps (RW530) puis avec SDS (Scientific Data System) dont elle a  commercialisé la gamme C 900.
Les calculateurs finalement retenus furent des C 90-10 (SDS 910) qui ont été remplacés par des C 90-40 (SDS 940) avec la particularité de disposer d’un C 90-80 au niveau du dispatching national.

Au fond sur la gauche l’imprimante ligne et des dérouleurs de bandes qui n’étaient pas ceux utilisés dans les dispatchings.

Les C 90-40 étaient des machines à circuits (faiblement) intégrés et à transistors répartis sur des cartes de petit format, elles-mêmes enfichées sur des fonds de paniers répartis dans plusieurs armoires. La mémoire était une mémoire à tores magnétiques. Les mots étaient de 24 bits, mais l’adressage n’était que sur 14 bits, ce qui donnait une capacité mémoire adressable de 16 Kmots (soit seulement 48 Koctets). La mémoire physique pouvait monter à 32 Kmots, les 16 Kmots supplémentaires pouvaient être utilisés, moyennant une astuce système, pour stocker des données mais ne pouvaient pas contenir d’instructions directement exécutables. (en savoir plus sur les 90-40)

L’architecture retenue

L’architecture retenue est maintenant classique pour les SCADA, à savoir deux calculateurs fonctionnant en permanence, avec reprise automatique des traitements temps réel par la seconde machine en cas de panne de la première. Cependant l’architecture n’était pas symétrique tant du point du vue matériel que logiciel. Une machine était réservée aux traitements temps réel et l’autre aux traitements différés. Ces traitements différés s’exécutaient hors ligne, ce qui signifiait que l’automaticité du secours n’était pas assurée lorsqu’ils étaient en cours. Il était alors nécessaire d’arrêter les traitements et de relancer la machine en mode temps réel. Il est à noter que les dispatchings de Brive et de Marseille ne disposaient au début, que d’une seule machine. Pour ces dispatchings, les traitements hors ligne nécessitaient donc l’arrêt du temps réel. Les dispatcheurs étaient alors amenés à conduire le réseau avec le synoptique, les enregistreurs, le téléphone et bien entendu le schéma de quart. (En savoir plus sur l’architecture).

Salle des calculateur de Lille en 1967. On peut voir sur la gauche un écran alphanumérique, puis à moitié cachée, une imprimante ligne, un perforateur de cartes le long du pilier, et au fond en arrière plan une autre imprimante ligne.

Sur la droite au premier plan, l’arrière d’une des consoles système, une unité de disque (3 MO pour mémoire), un peu plus loin la console système de l’autre calculateur tournée vers le lecteur perforateur de ruban papier et le pupitre. On voit les armoires des calculateus eux-mêmes complètement sur la droite.

Le développement

Le développement de ce premier palier fût mené de concert entre le fournisseur retenu (CAE/CII) et EDF. Plus de quarante ans plus tard, la réussite de ce développement nous laisse encore admiratifs. Envisager que l’on puisse faire tenir, OS compris, les fonctionnalités d’un vrai SCADA de base avec moins de 100 Koctets de RAM semble aussi impossible que l’existence de la « fourmi de 18 mètres avec un chapeau sur la tête » de Robert Desnos. La réussite s’est notamment appuyée sur :

  • la mise en œuvre de concepts simples mais efficaces servis par une excellente connaissance des capacités de la machine.
  • l’optimisation au niveau du bit pour les tables système, mais aussi pour les données utilisateur.
  • l’optimisation, pour les instructions déroulées dans le scheduler, faite au niveau du nombre de cycles machine et non du nombre d’instructions. (En savoir plus sur les schedulers).
  • l’optimisation des mouvements des bras de lecture du disque et donc des temps d’accès. La taille et l’emplacement des fichiers, y compris ceux contenant les exécutables des programmes, étaient gérés manuellement, les emplacements étant choisis pour que les mouvements des bras des disques soient minimisés (ainsi, par exemple, les programmes de récurrence minute, étaient positionnés non loin des stockages « minute » puis venaient les programmes de récurrence dix minutes et les fichiers correspondants et ainsi de suite).
  • une répartition judicieuse entre mémoire vive et disque, tant pour les programmes que pour les données.

L’exploit est d’autant plus grand que les tâches de production et de tests des logiciels étaient particulièrement lourdes et sans outillage d’aide (En savoir plus sur les développements du logiciel)

La gestion des données

En l’absence de Système de Gestion de la Base de Données et de Système de Gestion de Fichiers, tout était manuel.
Les cartes perforées constituaient le support initial des données de téléconduite et des données d’imagerie.  Un utilitaire permettait de lire ces cartes et de constituer des fichiers qui étaient ensuite versés sur disque.

Comme nous l’avons vu plus haut, la gestion des emplacements des fichiers sur disque était manuelle : un fichier correspondait à une localisation et un nombre défini de secteurs. Lire ou écrire un fichier consistait donc à lire ou écrire un nombre défini de secteurs à un emplacement défini sur le disque (numéro de tête, de cylindre et secteurs).
Ce travail nécessitait une grande méticulosité :

    •  La cohérence des données reposait entièrement sur les épaules des opérateurs de saisie,
    • Il en était de même pour la gestion des espaces disque : une erreur sur la taille d’un fichier et on allait écraser le fichier du voisin.

Le déploiement

Le déploiement aura lieu de 1967 à 1971.

A l’issue du développement initial et du déploiement ainsi que d’une formation adaptée, EDF reprendra rapidement la maintenance du logiciel (y compris celle du superviseur) qui sera répartie de façon originale entre les équipes des différents dispatchings (national et régionaux) pour la partie SCADA et Direction des Etudes et Recherches pour la partie modèles)

Les fonctionnalités offertes au dispatcheur

Les fonctionnalités de départ

Chaque dispatcheur disposait d’un poste de travail à 1 ou 2 écrans alphanumériques monochromes et d’un clavier alphanumérique complété par des touches de fonction, le tout lui permettant :

  • D’afficher des schémas de poste simplifiés (représenté à l’aide des caractères disponibles),
  • D’afficher des listes de mesures par poste,
  • De mettre en ou hors surveillance des mesures,
  • De modifier des états de télésignalisations réputés faux (fonction masquage),
  • De consulter la liste des alarmes et des dépassements de seuils.

La salle de dispatching de Nancy en 1971. Outre le synoptique de plus en plus imposant, et la présence d’un nombre réduit d’enregistreurs, on remarquera les postes de travail à deux écrans.

Les évolutions

Les C 90-10, limités en termes d’acquisition de mesures, ont rapidement été remplacés par des C 90-40 dans les dispatchings régionaux sauf dans celui de Lille, qui disposait d’un réseau plus petit, et qui a gardé un C 90-10 en parallèle avec un nouveau C 90-40. Le dispatching national bénéficiera en parallèle avec le C 90-40 d’un C 90-80 pour toutes les applications scientifiques.
Compte tenu de leur durée de vie et des évolutions de l’exploitation du système électrique de nombreuses évolutions ont été développées ; nous ne retiendrons ici que quelques unes :

  •  Evolution du poste opérateur : Les écrans des dispatcheurs, furent remplacés par des écrans couleur semi-graphiques disposant d’une bibliothèque de symboles graphiques (écrans MP 1000). Ceci permettait d’afficher de véritables images de poste (schémas de poste renseignés avec les mesures de puissance actif/réactif, les mesures de tension et les positions des organes de coupure), et surtout de différencier par la couleur les niveaux de tensions et la gravité des alarmes.
  • Introduction de la télécommande sur le réseau de transport : Le dispatching de Lille qui avait à gérer de nombreux couplages et découplages des groupes des Houillères, tôt le matin et tard le soir a développé la possibilité de télécommander depuis les calculateurs temps réel quelques organes de coupures.
  • Introduction de la télécommande sur des moyens de la production hydraulique : Le dispatching de Toulouse a été amené à développer des automates pour gérer la production de quelques centrales des Pyrénées et notamment le délicat problème des démarrages dans les centrales comportant plusieurs groupes.
  • Introduction de modèles de calcul de réseau : analyse de sécurité dans l’approximation du courant continu :
    • Calcul de répartition. Il a pour objectif le calcul des transits sur les ouvrages à partir des injections aux nœuds électriques. Il a été développé en assembleur à cause des ressources limitées des calculateurs. Il a fonctionné de façon satisfaisante au niveau algorithme. Son fonctionnement effectif en exploitation s’est heurté au fait que trop de positions d’organes de coupure (disjoncteurs, sectionneurs) étaient manuelles et que la moindre erreur (erreur réelle ou décalage dans la mise à jour) de position entrainait des problèmes de convergence ou l’apparition de résultats faux.  L’effort de mise à jour en temps réel a longtemps été trop important pour que l’utilisation de ce nouvel outil soit régulière.
    • analyse de sécurité dans l’approximation du courant continu. Il s’agit d’un programme simulant tour à tour un certain nombre de déclenchements pour en évaluer les conséquences sur les transits dans les autres ouvrages. Le modèle utilisé dit dans « l’approximation du courant continu » traite très schématiquement les problèmes de chute de tension qui résultent des déclenchements.
    •  Appréciation d’état. Alors que le réseau THT (225 kV et 400 KV) avait un plan de télémesures convenable, les réseaux HT (63 KV et 90 kV) étaient faiblement télémesurés.  Pour palier cet état de fait, l’idée est venue de mettre en place un modèle qui donnerait une évaluation de la situation sur ces réseaux faiblement télémesurés.  Le principe de base était le suivant : on partait des prévisions de consommations sur les points de livraison et on effectuait un calcul de répartition. Ce calcul donnait des transits sur toutes les liaisons (lignes et transformateurs THT/HT). Là où il existait des mesures (notamment sur les transformateurs THT/HT), on comparait les résultats du calcul avec les mesures et on ventilait les écarts en fonction d’une notion de zone d’influence. Ceci donnait un nouveau point de départ pour les consommations et l’on itérait jusqu’à ce qu’un critère sur l’ensemble des écarts soit atteint.
La salle de dispatching de Lyon  en 1971. Le synoptique est encore plus imposant que celui de Nancy (CF supra).On remarquera les postes de travail à un seul écran.

Compte-tenu de leur durée de vie, les 90-40 ont été amenés à suivre les évolutions de leur environnement informatique, et à s’ouvrir à l’extérieur :

 
 
  • Le Système de Gestion Energétique Prévisionnel (SGEP) sera déployé de 1972 à 1975. Il reprendra à son compte une partie des travaux effectués sur la machine de traitement différé. Une passerelle, basée sur un Mitra 15, sera mise en place dans chaque dispatching pour permettre la transmission, du 90-40 vers le SGEP, des réalisations (CPRC et Photos) (6)
  • Des Calculateurs d’Acquisition (les CACQ), jouant le rôle de frontaux pour les 90-40, seront déployés de 1977 à 1981 dans le cadre du SDART (en savoir plus sur le SDART),
  • Le Réglage Secondaire de Tension (7) sera déployé de 1979 à 1984. Les 90-40 seront chargés d’acquérir la valeur du niveau de réglage et de le réémettre vers les centrales hydrauliques.

L’exploitation et la maintenance

La maintenance matérielle

Historiquement assurée par CAE, puis CII, CII-HB et BULL au gré des rachats et fusions, elle a été reprise dans les années 80 par les services télécom des CRTT qui ont dû former des technicien à des technologies, certes passionnantes, mais déjà obsolètes.. On trouvait encore à cette époque deux types de maintenance : la maintenance préventive et la maintenance corrective. Les mauvaises langues, fortes de quelques années d’expérience et qui plus est dotées d’un certain humour, aimaient à dire que la maintenance préventive c’était juste avant que la panne arrive et la corrective juste après.

La maintenance préventive consistait

  • à nettoyer les appareils (lecteurs, bandes, disques, télétypes, perforateur…)
  • à recaler les jeux divers dans tout ce qui était mécanique : lecteur de cartes, dérouleur de bandes, télétype, bras des disques… Dans ce dernier cas il fallait assurer la compatibilité des réglages entre les différentes unités pour pouvoir monter n’importe quel disque sur n’importe quelle unité.
  • à ré-étalonner toutes les valeurs des alimentations et plus particulièrement celles des mémoires à tores.

La maintenance corrective intervenait suite à incident pour trouver la panne et y remédier. Pour ce faire les techniciens disposaient de programmes de tests qui leur permettaient en général de trouver le sous-ensemble en panne. Ensuite c’était le règne de l’oscilloscope à déclenchement. La carte suspectée était mise au bout d’un prolongateur et à l’aide du schéma électronique de la carte, le mainteneur suivait la propagation des signaux en pas à pas. Un fois le composant en panne détecté, il était changé au fer à souder. Si cela peut sembler totalement archaïque au vu des méthodes actuelles, cela était l’occasion d’acquérir des connaissances sur le fonctionnement profond d’un ordinateur, connaissances qui furent utiles à un certain nombre d’entre nous pour les projets ultérieurs. Au fur et à mesure du temps, la récupération de pièces sur des calculateurs en fin de vie a permis d’alléger les tâches de réparations immédiates en jouant sur les stocks de cartes existant.

La maintenance logicielle et l’exploitation

La maintenance logicielle a été rapidement reprise en main par le Service des Mouvements d’Energie. Dans chaque région, une équipe traitement de l’information comportait aux alentours de quatre analystes-programmeurs et deux techniciens. Les techniciens s’occupaient principalement des tâches d’exploitation courantes : mise à jour des données, aide aux tâches de facturation, de statistiques… Les analystes outre le développement des programmes et leur insertion en exploitation, étaient en charge de la maintenance logicielle et intervenaient en et hors des périodes d’heures ouvrables en cas de pannes. Généralement, hors heures ouvrées, les dispatchers effectuaient le redémarrage du système (au moins un des calculateurs) à partir d’une procédure pré-établie et, en cas d’échec, ils faisaient appel aux analystes. Ceux-ci venaient redémarrer le système, éventuellement après une tentative à distance au téléphone (c’était notamment le cas à Paris compte tenu d’un éloignement plus grand des analystes). L’obsolescence du matériel et une exploitation du réseau plus tendue ont conduit certaines régions à mettre en place une astreinte informatique.

Cette organisation un peu atypique a rempli pleinement ses objectifs en permettant une maintenance évolutive proche de l’exploitant des dispatchings et une continuité du service offert grandement satisfaisante le tout en s’appuyant sur des matériels somme toute assez fragiles et fortement contraints en place et en puissance. Par ailleurs, le potentiel acquis tant au niveau informatique que fonctionnel a été un des piliers sur lequel le palier SIRC s’est appuyé pour sa réussite.

 

notes de bas de page
(1) Pour une centrale en fonctionnement, le coût marginal est le coût de production d’un kw/h supplémentaire.
retour

 

(2) Le CAE 510 est une adaptation pour le marché civil du RW 530 de la société Ramo-Wooldridge.
retour

 

(3) Calcul de court-circuit : calcul permettant de calculer la puissance amenée par le réseau lors d’un court-circuit franc et les chutes de tension dans les postes électriques qui en résultent. Une puissance de court circuit élevée permet une meilleure résistance du réseau aux perturbations (déséquilibre, flicker, creux de tension…) mais elle doit rester dans les limites du matériel (jeux de barres des postes, pouvoir de coupure des disjoncteurs…)
retour

 

(4) Mécanisme contribuant au respect de l’équilibre production-consommation. Il élabore et envoie toutes les 10 secondes aux centrales participant à ce réglage, un ordre de production : le niveau. Ce niveau est élaboré à partir des écarts entre la fréquence de consigne et la fréquence mesurée et les échanges programmés aux frontières et les échanges mesurés. Le niveau variait de -1 (insuffisance de production) à +1 (surproduction.)
retour

 

(5) Emetteur Récepteur Cyclique composé d’un système de captation/émission dans chaque poste et de récepteurs au dispatching
retour

 

(6) Courbes a posteriori de Réalisation de Charges : série de 48 moyennes ½ horaires pour des rubriques portant sur les différents types de production, la consommation et les échanges. Les photos sont des situations instantanées du réseau (TM + TS + topologie). Ces données sont ensuite agrégées au niveau France.
retour

 

(7)  Dispositif destiné à maintenir la tension à une valeur de consigne dans des postes appelés points pilote. Des régulateurs situés dans les dispatchings élaborent un ordre de production de réactif (le niveau de RST) qui est ensuite envoyé dans les centrales qui participent à ce réglage.
retour 

 

Présentation de la note Saumon

La note saumon est un document qui a structuré le travail sur les besoins en téléinformations et sur leur qualité. Cette note est très volumineuse (une centaine de pages environ), aussi, la présente démarche est-elle d’en faire une présentation plus digeste en alternant des extraits majeurs de la dite note et des présentations succinctes des parties moins denses.

Lire la suite

Spécifications Techniques Générales du SIRC – Novembre 1976

Cette note, écrite en 1976, indique les principales orientations des Spécifications Techniques Générales des Systèmes Informatiques de Conduite des Dispatchings Régionaux. Elle faisait preuve d’une grande anticipation fonctionnelle et de grandes ambitions. On peut considérer que la satisfaction quasi complète de ses attentes initiales aura pris une vingtaine d’années…..

 

 

 

 

PRESENTATION DES SPECIFICATIONS TECHNIQUES GENERALES

DES SYSTEMES INFORMATIQUES

REGIONAUX DE CONDUITE

(S.I.R.C.)

J. Masson novembre 1976

—————–


RESUME :

Cette note indique les principales orientations des Spécifications Techniques Générales des Systèmes Informatiques de Conduite des Dispatchings Régionaux.

 

Cette note a pour but de présenter les Spécifications Techniques Générales des Systèmes Informatiques Régionaux de Conduite (S.I.R.C.) qui remplaceront les calculateurs 90-10 et 90-40 actuellement en service dans les Dispatchings Régionaux. Ces futurs systèmes informatiques devront permettre l’évolution des Dispatchings Régionaux en Centres Régionaux de Conduite (C.R.C.) pour qu’ils puissent assurer, outre la conduite des réseaux, la télécommande et la surveillance du matériel.

Ces Spécifications Techniques Générales ont été définies par un groupe de travail composé comme suit :

Direction Production Transport :

. Service des Mouvements d’Energie :

Service Central M. BOTREL

C.I.M.E. Est M. GILLON

C.I.M.E.Nord et Paris M.MASSON (animateur)

C.I.M.E. Ouest M. GANDON

C.I.M.E. Sud-Est M. ADMET

C.I.M.E. Sud-Ouest M. LAMOTTE

 

. Service de la Production Hydraulique M. AMESTOY

 

. Service du Transport M. KOWAL

Direction des Etudes et Recherches :

 

. Service Etudes de Réseaux

 

. Service Informatique et Mathématiques Appliquées

La préparation des travaux du groupe de travail et la rédaction des spécifications ont été assurées par une équipe permanente attachée au C.I.M.E. Nord et Paris[1].

Les Spécifications Techniques Générales constituent tout à la fois le rapport d’un groupe de travail et un cahier des charges pour les équipes qui seront chargées du projet, celles du constructeur (ou de la société de service) et de l’E.D.F. Ce document comprend donc des éléments plus complets que ce qui serait strictement nécessaire aux soumissionnaires, notamment en ce qui concerne les programmes d’application.

Les Spécifications Techniques Générales ont été rédigées dans l’hypothèse d’un appel d’offres unique pour les sept dispatchings. Cet appel d’offres serait lancé dans des conditions qui restent à déterminer auprès de soumissionnaires qui pourraient être des constructeurs ou des sociétés de service.

Cette hypothèse de l’appel d’offres explique que sur certains points, des possibilités de choix aient été maintenues. C’est en particulier le cas de l’architecture du système que le groupe de travail, tout en manifestant sa préférence pour une solution à trois calculateurs, a laissé aux soumissionnaires le soin de définir.

Les Spécifications Techniques Générales devront être complétées lors du lancement de l’appel d’offres par un document précisant les limites de fournitures et par un dossier technique indiquant aux soumissionnaires les principaux renseignements à fournir et l’échéancier de réalisation des sept dispatchings.

Les Spécifications Techniques Générales ont été décomposées en huit chapitres intitulés :

– Introduction

 

– Liaisons entre systèmes informatiques

 

– Périphérie de restitution et de dialogue

 

– Programmes d’application

 

— Base de données

 

– Logiciel de base

 

– Qualité de service

 

– Architecture

Dans cette note de présentation, un résumé du contenu de ces chapitres est donné, mettant en évidence les orientations retenues.

Quelques indications chiffrées ne figurant pas dans les Spécifications Techniques Générales, mais résultant d’études préliminaires, sont fournies pour l’évaluation de la charge du système et l’architecture.

CHAPITRE 1 – INTRODUCTION

L’objet de cette introduction est de situer les futurs systèmes informatiques de conduite (S.I.R.C.), en s’appuyant sur les décisions d’orientation de la Direction Production Transport, du Service des Mouvements d’Energie et les conclusions du groupe de travail « C.R.C. ».

Nous définissons pour cela :

– la conduite des réseaux, c’est-à-dire du système de Production et de Transport d’E.D.F.

 

– l’organisation du Service des Mouvements d’Energie

 

– l’évolution des Dispatchings Régionaux en C.R.C. et les attributions de ceux-ci

 

– les moyens mis en œuvre pour permettre aux C.R.C. de remplir leur fonction

 

– le rôle du S.I.R.C.

Cette présentation du rôle et de l’environnement du S.I.R.C. nous amène à préciser plus particulièrement quelques points fondamentaux :

 

 

La distinction dans l’exploitation entre phase prévisionnelle et phase « temps réel »

– La phase prévisionnelle couvre une période allant depuis la prévision journalière (exploitation du lendemain) jusqu’à la prévision à moyen terme (examen de la situation du réseau dans plusieurs années). Les traitements correspondants sont assurés par le Système de Gestion Energétique Prévisionnelle (S.G.E.P.) et n’ont pas à être pris en compte, sauf exception,’ par le S.I.R.C.

 

– La phase « temps réel » comprend les interventions immédiates et un examen prévisionnel du réseau dans le cadre de la journée (fonctions « temps réel- étendu »). Les traitements correspondants doivent être assurés par le S.I.R.C.

La disponibilité exigée pour les fonctions assurées par le S.I.R.C.

 

Nous avons regroupé les tâches à assurer par le S.I.R.C. dans quatre classes :

A) Les fonctions d’acquisition, de télécommande et de visualisation Ces fonctions permettent d’avoir une connaissance « brute » de l’état du réseau (télésignalisations et télémesures) et d’intervenir sur celui-ci.

Ces traitements sont indispensables et le taux de disponibilité requis doit être tel que la défaillance soit inférieure à une heure par an.

Il n’est pas acceptable, en effet, d’être privé plus longtemps et plus souvent de toute information et de toute possibilité d’action sur le réseau. Le taux de disponibilité doit donc atteindre 99,99 %.

B) Les fonctions d’analyse primaire et d’analyse secondaire en temps réel Il s’agit-là des fonctions permettant d’acquérir une connaissance approfondie de l’état du réseau et de le surveiller.

Une disponibilité élevée est toujours nécessaire puisque cette classe comprend des fonctions qui indiquent l’état réel du réseau. On peut néanmoins considérer qu’un taux de disponibilité de 99,90 % est acceptable soit une défaillance d’une dizaines d’heures par an.

C) L’analyse secondaire en temps réel étendu

Il s’agit des calculs pouvant porter sur des données issues du temps réel et sur des hypothèses prévisionnelles dans le cadre de la journée. Il est demandé, pour cette classe, un taux de disponibilité de 97 %.

D) Les fonctions de type « Centre de Calcul » pour lesquelles la disponibilité doit être supérieure à 90 %.

Les moyens matériels et logiciels devront satisfaire ces exigences étant entendu que les taux indic ne ne concernent que le S.I.R.C. , l’environnement informatique (CACQ) et technique (climatisation, alimentation) ayant une disponibilité adaptée à ces exigences.

 

Les étapes de mise en œuvre

Compte tenu des échéanciers, la mise en œuvre des fonctions devra être assurée en deux étapes :

1) Mise en service de toutes les fonctions liées à la conduite des réseaux Cette étape doit être accomplie dès la mise en service du S.I.R.C. dans le premier dispatching rénové (deuxième semestre 1979).

2) Mise en service des fonctions de télécommande et de surveillance des installations à partir de 1982.

 

CHAPITRE 2 – LIAISONS ENTRE SYS TEMES INFORMATIQUES

 

Ces liaisons permettent de réaliser les tâches d’acquisition de données et d’émission d’ordres ou d’informations. Les calculateurs du S.I.R.C. devront échanger des informations avec :

– les CACQ

– le terminal du S.G.E.P.

– le processeur chargé de l’animation du tableau synoptique. Il est demandé que le raccordement du S.I.R.C. à d’autres systèmes soit aisément réalisable.

Les liaisons entre les différents calculateurs du S.I.R.C. dépendent de l’architecture choisie et seront traitées par ailleurs.

Liaisons CACQ – S.I.R.C.

C’est par elle que transitent toutes les informations « Temps Réel » issues du réseau, les ordres de téléaction (téléréglage, télécommande, etc..), les échanges avec le SYSDIC et les autres S.I.R.C.

Les informations échangées peuvent être du type « urgent » (données du temps réel), le CACQ est alors le calculateur « frontal » du S.I.R.C., ou du type « différé » (données binaires échangées entre régions, le CACQ est alors un commutateur de messages.

Un principe semblable à celui de la liaison CACQ – SYSDIC, a étéretenu. Une description détaillée de cette liaison est donnée dans une note établie par le Service du Transport et jointe en annexe au chapitre 2.

C’est une liaison de transmission série Full-Duplex doublée. La vitesse de transfert est de l’ordre de 50 000 bits/seconde.

La procédure de transmission (l’organisation logique des transmissions) est de type HDLC (High Level Data Link Control) en cours de normalisation à E.D.F. Le logiciel correspondant devrait donc pouvoir être fourni par E.D.F.

Les informations sont groupées en blocs homogènes de données du même type (TS ou TM ou TC). Chaque bloc est caractérisé par un code fonction qui annonce la nature des informations qu’il contient. Ils sont précédés d’en-têtes de transmission qui permettent de les aiguiller convenablement.

Les échanges sont déclenchés soit périodiquement (300 ou 500 ms), soit lorsque la zone correspondant à un type de données est pleine. La taille des messages est actuellement limitée à 128 octets mais la possibilité de la faire varier doit être prise en compte.

A la réception, un ordre de priorité a été retenu pour les blocs :

 

– données arythmiques (TS)

 

– données cycliques (TM)

 

– données « binaires »

Les données « individuelles » TS ou TM se présenteront sous la forme d’un groupe d’octets comprenant l’adresse nationale d’une part, la valeur d’autre part.(Une description de l’adressage national est donnée en annexe au chapitre 2).

Les données « binaires » ont une présentation différente, elles comportent un identificateur propre à chaque donnée et qui n’est accessible qu’au logiciel du S.I.R.C. destinataire.

 

Liaisons S.I.R.C. – S.G.E.P.

 

C’est par cette liaison que transitent, d’une part, certains résultats d’exploitation nécessaires à la mise à jour de la base de données du S.G.E.P., d’autre part, certaines prévisions, résultats des modèles du S.G.E.P.

Pour cette liaison un principe identique à celui de la liaison CACA – S.I.R.C. est retenu. Dans la mesure du possible, les messages seront présentés sous la même forme que les données « binaires » issues du CACQ.

 

 

Liaison S.I.R.C. – Processeur de synoptique

Le principe a été retenu d’animer les futurs tableaux synoptiques par l’intermédiaire d’un processeur relié aux CACQ et au S.I.R.C. en vue de séparer les fonctions par nature et de faciliter la spécificité du tableau synoptique dans chaque dispatching.

L’introduction d’un processeur dont le logiciel serait adapté à chaque région permet de préserver l’homogénéité du logiciel du S.I.R.C. puisque l’animation du synoptique se ramène à un transfert d’informations. Le S.I.R.C. émettra des informations d’état ou de mesures et recevra du processeur des acquits et des demandes de contrôle général.

Il faut d’ailleurs rappeler qu’un processeur est d’ores et déjà envisagé par le Service du Transport pour transmettre sur les tableaux synoptiques actuels, dès 1977, les informations qui seront gérées par les CACQ sans transiter par les équipements classiques. Il serait souhaitable d’étudier l’animation des futurs synoptiques en liaison avec cette étude.

La liaison S.I.R.C. – processeur de synoptique sera une liaison téléinformatique bidirectionnelle dont les caractéristiques restent à définir mais qui pourra être choisie identique aux précédentes par souci d’homogénéité.

CHAPITRE 3 – PERIPHERIE DE RESTITUTION ET DE DIALOGUE

Dans ce chapitre, les caractéristiques souhaitées pour la périphérie de restitution et de dialogue sont examinées.

Système de visualisation

 

Ce système a été étudié plus particulièrement car il apporte aux dispatchers les informations en temps réel et leur permet d’agir sur le réseau par l’intermédiaire de la télécommande.

Pour répondre aux besoins définis, le matériel est tout d’abord examiné puis le logiciel et enfin les types de dialogue homme-machine sont envisagés.

Dans la définition du logiciel désiré, il est indiqué non seulement celui qui devra être fourni par le constructeur, mais aussi celui qui est à la charge d’E.D.F.

 

Matériel

Le choix se porte sur des écrans graphiques, polychromes à balayage cavalier, avec au minimum trois couleurs aisément discernables. Les écrans pourront être rectangulaires ou circulaires. La diagonale (ou le diamètre) de leur surface utile ne devra pas être inférieure à 45 cm.

Ce type d’écran semble être le seul qui garantisse une définition de l’image suffisante pour afficher des zones électriques importantes. Le matériel vidéo semi-graphique permet un choix de couleurs plus important mais les possibilités de définition de l’image sont plus réduites.

Les dispositifs de commande de ces écrans seront constitués par un clavier alphanumérique universel et par un dispositif de désignation sur l’écran qui sera un photostyle (light pen).

Tous les écrans seront de même nature et possèderont les mêmes caractéristiques techniques. Un poste de travail complet comprendra trois écrans. La désignation à l’aide d’un photostyle devra pouvoir s’effectuer sur deux des trois écrans, le troisième n’étant pas un écran de dialogue mais uniquement d’affichage. C’est le fait d’avoir à utiliser le même dispositif pour deux écrans différents qui conduit à préférer le photostyle à la « boule roulante ».

La perte d’un écran ne devra pas empêcher une marche dégradée d’un poste de travail avec un seul écran de dialogue, l’autre étant utilisé en affichage.

Des postes de travail partiels à un ou deux écrans pourront être installés pour certaines tâches d’études.

 

Logiciel

Les images temps réel devront être affichées avec un temps de réponse inférieur à la seconde. Ceci exclut la possibilité de générer dynamiquement en temps réel l’ensemble des images mises à la disposition des exploitants.

La phase temps réel devra donc être précédée par une phase « centre de calcul », et les besoins en logiciel correspondront à ces deux types de travaux.

 

La phase temps réel peut être réalisée à l’aide des programmes suivants

. Moniteur graphique temps réel. Il assure la gestion des échanges entre les calculateurs pilotes (S.I.R.C.) et les unités de traitement du système de visualisation.

 

. Traitement des interactions. Activé par le moniteur graphique, il s’agit d’un automate constitué de données à deux niveaux :

 

. pour chaque image, un tableau donne la liste des entités désignables.

 

. pour chaque état de l’automate, un tableau donne la liste de tous les types d’actions possibles.

– Programme de composition des images, qui prépare l’image à afficher.

– Programme de rafraîchissement.

 

Le moniteur graphique temps réel devra être fourni par le constructeur mais les trois autres programmes seront réalisés par E.D.F.

La phase « centre de calcul » nécessite que le constructeur fournisse un certain nombre d’outils généraux que l’on peut répartir en quatre classes :

 

– génération de codes graphiques

 

– outils de mise au point

 

– traducteur (ou désassembleur)

 

– outils de test.

 

. Dialogue homme machine

La sélection des images sera fondée sur le principe de la recherche hiérarchisée.

Une image « répertoire » permettra d’initialiser cette recherche. La progression dans l’arborescence des images se fera par désignations successives. Cette image « répertoire » pourra être obtenue soit à partir d’autres images de l’arborescence, soit à l’aide d’une touche (notamment lors de l’initialisation d’un écran).

La procédure d’appel d’une image sera la suivante :

 

— désignation sur l’image d’un marqueur ou d’un libellé

 

— validation de la demande par touche incorporée au photostyle.

L’image apparaissant alors contiendra l’information désirée ou comportera une série de marqueurs ou de libellés permettant de progresser dans l’arborescence.

Les images seront composées de deux types de zones :

 

— la zone utile

 

— les zones de service réservées aux marqueurs de progression dans l’arborescence et aux libellés de paramètres.

 

 

On distinguera trois types d’affichage :

Affichage temps réel sur demande du dispatcher, qui comprend l’affichage sur trame topologique d’une zone, d’un poste, d’une vallée ou d’une usine hydraulique et l’affichage par listes, tableaux et courbes. I1 s’effectue sur les deux écrans accessibles au photostyle.

Affichage temps réel aléatoire qui concerne la visualisation de tous les évènements aléatoires qui doivent être portés à la connaissance du dispatcher. Il s’effectue sur le troisième écran du poste de travail.

Affichage d’étude. Pour la visualisation des résultats d’études et pour l’introduction des hypothèses, il est souhaitable de disposer de moyens de dialogue semblables à ceux utilisés pour le temps réel. Ceci nous conduit donc à rechercher pour les fonctions d’études un système de visualisation comparable à celui retenu dans l’affichage temps réel à la demande du dispatcher. Il est possible de spécialiser un écran graphique pour les fonctions d’études ou d’utiliser un des écrans du temps réel, à condition de dissocier clairement les fonctions d’affichage temps réel et études.

Pour l’organisation du dialogue homme – machine, nous avons retenu essentiellement la désignation par photostyle. Bien entendu, il est toujours possible de remplacer un libellé désignable par une touche pour éviter des désignations trop fréquentes. Il est possible qu’habitués à la désignation par touches, certains exploitants souhaitent son maintien. Il faut alors remarquer que le nombre et la complexité des ouvrages et des fonctions désignables interdit l’utilisation exclusive des touches, et que par conséquent, l’emploi de deux modes de désignation introduit une difficulté supplémentaire dans le dialogue homme-machine.

Périphérie de restitution sur papier

Plusieurs dispositifs de restitution sur papier sont à envisager :

 

 

Dispositif de recopie sur papier

 

Un dispositif permettant de reproduire sur papier l’image présente sur chacun des écrans d’un poste est demandé. Si un tel dispositif (hard copy) ne peut être raccordé directement ou indirectement sur le système de visualisation, un traceur de courbes sera utilisé.

Imprimantes rapides

 

Deux imprimantes rapides dont la vitesse pourra être comprise entre 600 et 900 lignes par minute sont nécessaires. L’une située au niveau du dispatching permettra la restitution d’informations selon les besoins des exploitants, l’autre sera utilisée au centre de calcul.

. Machines à écrire

Ces dispositifs servent au contrôle de l’état de chaque calculateur et pourront être utilisés en entrée et en sortie. Elles peuvent éventuellement être remplacées par des ensembles « console alphanumérique – imprimante lente »

CHAPITRE 4 – PROGRAMMES D’APPLICATION

Dans ce chapitre sont décrits les principes des programmes d’application mis en œuvre par le S.I.R.C.

Certains de ces programmes ne seront intégrés dans le logiciel d’application qu’en deuxième étape lors de l’évolution des dispatchings en C.R.C., la surveillance et la télécommande du matériel devenant alors effectives.

Tous ces programmes sont à la charge d’E.D.F., et si à ce stade des Spécifications Techniques l’analyse reste assez générale, des éléments permettant une évaluation de la charge et l’étude des spécifications détaillées sont fournis.

C’est ainsi que pour chaque programme d’application on donne :

– le mode et la fréquence d’activation, les modèles les plus prioritaires étant signalés

– la nature des données en entrée

– le traitement mis en œuvre et des indications sur les algorithmes

– l’utilisation des résultats

– les caractéristiques, c’est-à-dire essentiellement le nombre approximatif d’instructions déroulées ou des résultats extrapolés de bancs d’essais (bench mark) pour les modèles les plus complexes.

Dans cette note de présentation des Spécifications Techniques, seul le rôle de chaque programme et ses particularités seront indiqués. TRAITEMENTS D’ACQUISITION ET DE REGLAGE

Ces traitements constituent la base de l’ensemble du système temps réel puisqu’ils assurent le rafraîchissement de la base de données et permettent à l’exploitant de suivre l’évolution du réseau.

Cinq tâches peuvent être distinguées pour lesquelles bien entendu le taux de disponibilité le plus élevé est demandé (99,99 %)•

Acquisition des télémesures

Ce programme range dans les tables résidentes les télémesures brutes qui sont envoyées au S.I.R.C. par le calculateur d’acquisition. Ces télémesures sont utilisées ensuite pour renseigner les images temps réel

Acquisition des télésignalisations

 

Ce programme met à jour les tables d’état des télésignalisations et les listes chronologiques correspondantes. Les changements d’état sont systématiquement signalés sur l’écran d’alarme.

Topologie nodale

 

Ce programme détermine le schéma électrique du réseau et il établit pour chaque nœud électrique la liste des départs et des injections raccordés. Ce programme est préparatoire à toute analyse secondaire et il permet de plus de détecter les réseaux séparés.

 

Traitement du niveau fréquence-puissance

Le niveau est transmis à la région par le SYSDIC. Le S.I.R.C. effectue les traitements relatifs au niveau fréquence-puissance portant sur :

 

– la diversification

 

– l’affectation des niveaux diversifiés aux groupes en réglage

 

– le calcul à partir de ces niveaux de la charge active pour les usines hydrauliques de première intervention qui sont en réglage, en suivant le programme de marche de ces usines

 

– l’émission du niveau (pour les groupes thermiques) ou de la télécommande de puissance active (pour les groupes hydrauliques télécommandés).

 

 

Téléréglage secondaire de la tension

Ce programme doit pouvoir élaborer pour chaque groupe un ordre de participation au réglage de tension qui doit lui permettre de maintenir le niveau de tension souhaité dans la zone sur laquelle il est raccordé. Ce réglage s’effectue soit par consigne de production de réactif pour les groupes thermiques, soit directement par consigne de tension pour les groupes hydrauliques.

 

 

TELECOMMANDE

La possibilité généralisée de transmettre des ordres aux organes de coupure, aux automates du réseau et à certaines usines sera une des caractéristiques nouvelles des futurs dispatchings.

Cette évolution sera progressive et interviendra dans une seconde étape lorsque les dispatchings régionaux se transformeront en Centres Régionaux de Conduite. Cependant, les Spécifications Techniques Générales doivent en tenir compte au niveau d’une analyse globale.

Cette évolution s’accompagnera de la disparition du gardiennage des postes ; aussi la fonction « Télécommande » doit-elle bénéficier du taux de disponibilité le plus élevé.

Les traitements associés à cette fonction se situent à deux niveaux :

– l’analyse de l’ordre de télécommande permet de contrôler et de prendre en compte une demande du dispatcher,

– la gestion d’une télécommande contrôle la réalisation effective des ordres.

Ces traitements découlent d’une note globale sur l’organisation de la télécommande, jointe en annexe.

Organisation de la télécommande

Les ordres de télécommande sont transmis au calculateur par l’intermédiaire d’un écran de visualisation et des moyens de dialogue associés. La télécommande est possible depuis une image de zone, de poste ou d’usine.

 

L’opérateur sélectionne successivement la fonction, le ou les ouvrages ou organes concernés, et l’ordre de télécommande choisi à l’aide du photostyle. Certains choix pourront être effectués à l’aide de touches sans remettre fondamentalement en cause les options prises.

Après analyse de l’ordre de télécommande et si aucun problème n’est détecté, la position finale des organes désignés sera représentée dans une couleur différente de celle du schéma. L’ensemble des organes à manœuvrer pour la réalisation de l’ordre sera caractérisé par un clignotement. Le dispatcher devra confirmer sa demande en appuyant sur une touche « CONFIRMATION ». Le programme de gestion de la télécommande est alors activé.

Cette organisation est générale mais sa mise en œuvre varie suivant la nature des ouvrages télécommandés.

Analyse d’un ordre de télécommande sur le réseau de transport

La télécommande pourra s’effectuer au niveau d’un organe (ordre élémentaire) ou au niveau de plusieurs organes ou d’ouvrages (ordre de fonction

Il convient également de distinguer les manœuvres pour la réalisation d’un schéma d’exploitation et celles en vue d’une consignation.

Pour la réalisation d’un schéma d’exploitation :

 

– les ordres élémentaires comprennent : OUVERTURE ET FERMETURE

– les ordres de fonction : CONNEXION, DECONNEXION, MISE HORS TENSION, SCHEMA.

Pour les manœuvres en vue d’une consignation, on distinguera :

– les ordres élémentaires : OUVERTURE ET ALIENATION

FERMETURE ET ALIENATION

DESALIENATION

– l’ordre de fonction : RETRAIT.

Analyse d’un ordre de télécommande d’usine hydraulique

Deux modes de commande sont prévus, qui permettent d’assurer la conduite des usines :

– l’action programmée qui est normalement utilisée. Les programmes sont transmis au S.I.R.C. depuis le S.G.E.P. Ils peuvent être modifiés par le dispatcher dans le cadre du « temps réel étendu » à l’aide du système de visualisation et de dialogue.

– l’action immédiate qui permet au dispatcher d’agir en temps réel sur les groupes.

Remarque : La télécommande des automates d’exploitation peut se ramener au niveau de l’analyse de l’ordre, soit à un ordre élémentaire sur le réseau de transport (EN ou HORS service), soit à une action immédiate sur une usine hydraulique (envoi d’une télévaleur de consigne TVC).

La télécommande des turbines à gaz peut également se ramener à un des cas précédemment traités.

Gestion de la télécommande en cours

-Ce programme contrôle l’exécution séquentielle d’une liste d’ordres élémentaires.

Il concerne :

– dans les postes, les télécommandes d’organes

 

– dans les usines hydrauliques (ou turbines à gaz), les télécommandes d’organes ou de types de fonctionnement.

 

ANALYSE PRIMAIRE

L’analyse primaire utilise les données brutes du temps réel pour effectuer des traitements simples.

Ces fonctions, moins vitales que l’acquisition et la télécommande, ne doivent cependant pas être indisponibles plus d’une dizaine d’heures par an (99,90%). Les programmes correspondants devront être mis en service dès la mise en place du S.I.R.C.

Contrôles logiques

La validité technique des traitements effectués par le système informatique et leur crédibilité aux yeux des exploitants reposent sur la qualité des téléinformations reçues. Ce programme effectue au niveau du S.I.R.C. un contrôle complémentaire aux tests de validité effectués au niveau des CACQ.

Ces contrôles se composent de tests de Boucherot par postes, par nœuds, de contrôles de cohérence entre les télémesures et les télésignalisations, associées à un même départ et de contrôles en actif sur les lignes télé-mesurées aux deux extrémités.

Surveillance des dépassements de seuils

Un certain nombre de termes mesurés ou calculés sont périodiquement comparés à des valeurs limites dont le dépassement marque l’apparition d’une contrainte d’exploitation.

Trois programmes, de récurrences différentes, assurent cette fonction qui pour l’exploitant est unique.

Traitement « 10 secondes » : Le passage par zéro de tous les groupes de production télémesurés est surveillé et, pour un certain nombre d’ouvrages choisis par le dispatcher, les télémesures sont comparées aux seuils fixés.

Traitement « minute ». Ce programme effectue :

– un contrôle systématique par rapport à l’IMAP (Intensité maximale admissible en permanence).

. un contrôle systématique des télémesures de tension pour chaque poste par rapport à une fourchette qui lui est propre.

. des contrôles à la demande, portant sur des termes calculés (sommes de puissances actives et réactives, gradients de mesures, intensités).

Traitement semi-horaire

 

Les programmes prévisionnels des groupes et les bilans prévisionnels des consommations sont comparés aux charges et bilans mesurés.

 

Bilans et stockages

 

La conservation de différentes grandeurs à pour but :

 

– de permettre l’étude ultérieure de situations particulières (incidents

– de faire des bilans énergétiques.

Plusieurs stockages peuvent être distingués :

 

– des stockages « 10 secondes » portant sur l’ensemble des télémesures

 

– des stockages « 10 minutes » portant sur des moyennes de mesures

 

– des stockages « 30 minutes » ou à la demande portant sur des situations complètes (mesures et topologie)

 

– des stockages aléatoires concernant les changements d’état.

Intensités

Les contraintes d’exploitation sont surtout liées aux intensités sur les liaisons alors que le plan de téléinformations propose principalement des mesures de transits actifs ou réactifs. Il est donc nécessaire de calculer les intensités.

Télécomptages

Les comptages d’énergie relevés pour les lignes d’échange avec l’étranger sont collectés en vue de leur utilisation en secours par le SYSDIC.

ECHANGE D’INFORMATIONS ELABOREES

Des échanges d’informations élaborées doivent être effectués avec différents systèmes informatiques en dehors des fonctions d’acquisition et de réglage.

Le rôle des programmes utilisateurs décrits ici se trouve donc limité :

.- en réception, à l’identification du type des informations reçues avant de les transmettre sous une forme utilisable aux programmes utilisateurs

– en émission, à l’extraction des informations de la base de données et à leur mise en forme par le destinataire final.

Traitement des messages S.G.E.P.

Ce traitement prépare les messages à émettre du S.I.R.C. vers le S.G.E.P. ou utilise les informations reçues.

Traitement des messages’ binaires »

Ce traitement gère les échanges de données binaires entre deux S.I.R.C. de régions différentes ou entre un S.I.R.C. et le SYSDIC, à travers le réseau T.T.R.

Mise à jour du synoptique

Systématiquement, un certain nombre d’informations issues de la base de données temps réel sont communiquées au processeur d’animation du synoptique pour affichage.

ANALYSE SECONDAIRE TEMPS REEL

L’analyse secondaire utilise les résultats de l’analyse primaire et met en jeu des modèles mathématiques complexes.

Les modèles correspondants seront mis en service dès la première étape, et devront bénéficier d’une disponibilité comparable à celle de l’analyse primaire.

Estimation d’état

Ce modèle, rend, cohérentes entre elle, les télémesures de l’ensemble du réseau, calcule les injecteurs équivalents et complète l’épuration des erreurs de téléinformations. Ce modèle ne sera appliqué qu’au réseau THT car il nécessite une forte redondance dans les télémesures.

Appréciation d’état

 

Ce modèle permet d’apprécier l’état des réseaux HT qui sont faiblement télémesurés.

 

Trois traitements permettent de suivre l’évolution de ces réseaux :

. Le calcul de base complet tient compte des modifications de topologie et d’injections.

 

. Un calcul de base simplifié est suffisant lorsque la topologie reste figée, quelles que soient les variations des injections.

 

. Un calcul partiel est possible lorsque la topologie reste figée, pour tenir compte du glissement des consommations, en supposant que les consommations finales sont homothétiques des consommations initiales.

Deux modèles de calculs sont décrits, l’un est en exploitation au C.I.M.E. Ouest, l’autre est proposé par la D.E.R. Le choix entre ces .deux modèles sera effectué au niveau de l’analyse détaillée en fonction des performances respectives.

Les modèles d’estimation et d’appréciation d’état sont chainés et s’exécutent toutes les minutes s’il n’y a pas eu de changement de topologie et tous les quarts d’heure dans le cas contraire où ils sont alors suivis du calcul de sécurité.

 

Calcul de sécurité en courant continu

 

Ce modèle a pour objet la détection des dépassements potentiels de seuils consécutifs au déclenchement d’ouvrages de production et de transport.

Le nombre des ouvrages sur lesquels porte-un déclenchement est limité

à cent pour des raisons de temps de traitement. Ces ouvrages seront introduits selon deux modes distincts :

 

— par le dispatcher

 

— de façon automatique, en prenant comme critère la charge relative des liaisons.

Ces calculs systématiques ne s’effectueront qu’en actif afin que le temps de traitement ne soit pas prohibitif. Le dispatcher a la possibilité de demander des analyses de sécurité en actif et réactif.

Calculs des réseaux équivalents

Les calculs de sécurité dans la mesure où ils simulent des déclenchements s’appuient sur une représentation des réseaux extérieurs aux réseaux de calcul. Ils permettent ainsi de tenir compte de la part des reports de charge supportée par les réseaux extérieurs, Chaque région doit donc calculer les impédances équivalentes à des parties de son réseau pour envoi au SYSDIC ou pour ses calculs de sécurité.

Estimation des apports-et des productions hydrauliques

Le but de ce programme est d’évaluer en temps réel les apports hydrauliques sur les différents réservoirs ainsi que les productions au fil de l’eau.

Suivant les données disponibles et les grandeurs à évaluer, l’un ou l’autre des modèles suivants est activé

– L’estimation des apports et des productions de fil à partir de-grandeurs témoins. Ce modèle, basé sur une formule de corrélation statistique entre la grandeur estimée et les valeurs témoins est particulièrement destiné à l’estimation des apports et des productions sur les usines de fil.

 

– Le calcul des apports à partir de télémesures de cotes et de puissance. Ce modèle, basé sur un calcul rigoureux, nécessite la connaissance d’un certain nombre de télémesures ; il ne peut être utilisé que pour les usines suffisamment .télémesurées.

ANALYSE SECONDAIRE EN TEMPS REEL ETENDU

Cette analyse en temps réel étendu permet de préparer l’exploitation. Elle va depuis le temps réel jusqu’au lendemain, soit une période qui peut s’étendre jusqu’à 36 heures.

Ces .études-mettent en jeu des modèles- complexes dont les durées de traitement sont de l’ordre de plusieurs minutes.

Déconnectés du temps réel immédiat, ces traitements sont activés à la demande ou périodiquement (mais avec une récurrence faible). De ce fait, le taux de disponibilité exigé est moindre que pour les traitements systématiques du temps réel, et un taux de 97 % semble suffisant.

Tous ces modèles seront en service dès la première étape de la réalisation des S.I.R.C.

Calcul de sécurité en alternatif

Ce modèle permet au dispatcher de simuler diverses situations d’exploitation à partir d’un réseau de base qui peut être le réseau THT ou l’un des réseaux HT de la région. Ce calcul effectué en alternatif s’appuie sur des données filtrées par l’estimation d’état ou l’appréciation d’état. Dans le cas où de telles données ne sont pas disponibles pour le réseau que veut étudier le dispatcher, il faut reprendre un calcul d’estimation d’état préalablement au calcul de répartition.

Calcul des puissances de court circuit

Ce calcul porte sur le réseau temps réel éventuellement modifié par le dispatcher ou sur une situation passée. La puissance de court circuit est calculée dans le cas du défaut triphasé symétrique.

Ajustement hydraulique en temps réel étendu

Le but de ce programme est d’optimiser le placement à l’intérieur d’une même journée, d’une production hydraulique supplémentaire non prévue par le « P4 » journalier. Ce programme n’existe pas à l’heure actuelle.

Evaluation des prévisions d’apports et de productions hydrauliques

Le but de ce modèle est d’évaluer plusieurs heures à l’avance la quantité et l’évolution des apports sur une région donnée.

La connaissance de ces apports permet, en effet, aux régions hydrauliques de transmettre au Dispatching Central leurs prévisions de production. Ce dernier peut ainsi gérer au mieux le parc de production thermique.

Ajustement- hydraulique journalier P4

Le but de ce modèle est d’établir les programmes journaliers de production de chaque usine hydraulique par points demi-horaires pour les deux jours à venir. Du domaine prévisionnel, il est normalement effectué sur le S.G.E.P. mais doit pouvoir être assuré sur le S.I.R.C. en secours.

Il existe actuellement deux modèles sensiblement différents pour réaliser cette fonction, aux C.I.M.E. Sud-Est et Sud-Ouest, mais pour l’intégration dans le S.I.R.C., un programme unique devra être réalisé.

Prévisions de consommation

La connaissance des prévisions de consommation permet d’ajuster les programmes d’exploitation au niveau du temps réel étendu et de surveiller la consommation effective en temps réel.

Les prévisions issues du S.G.E.P. sont ainsi affinées dans chaque région par l’utilisation des tout derniers résultats enregistrés en temps réel et par une meilleure connaissance des paramètres mis en jeu dans cette prévision (température, aléa particulier).

Au gré de la région, ce modèle pourra s’appliquer à des bilans par zone ou par type de consommation.

Simulation de situations d’exploitation

Cette fonction a pour but d’assurer la formation et le perfectionnement du dispatcher, en lui demandant de faire face à des évènements simulés, le plus près possible des conditions réelles d’exploitation.

Au niveau des Spécifications Techniques Générales, cette fonction est décrite de manière non exhaustive.

Le principe consiste à exécuter un calcul de répartition prenant en compte les modifications de topologie et d’injections introduites par l’opérateur ; ce calcul lui indique immédiatement les répercussions de ses décisions sur la charge des ouvrages dont il assure la conduite fictive.

ANALYSE A POSTERIORI

Dans cette rubrique, ce sont plus des notions générales que des programme: qui sont décrites car l’étude fonctionnelle de l’analyse a posteriori est encore en développement.

Les fonctions correspondantes ont pour but la visualisation ou l’édition de documents permettant à l’exploitant de connaître et d’analyser le fonctionnement passé du réseau et du système de téléinformations.

Ces fonctions peuvent avoir un caractère de temps réel étendu ou un caractère statistique :

 

Dans le premier cas, elles se déroulent sous temps réel et sont déclenchées par l’exploitant ;

Dans le second, elles se déroulent hors temps réel et sans perturber celui-ci (les programmes correspondants sont alors écrits en langage évolué).

Les données utilisées sont les informations périodiques ou aléatoires stockées sur disque ou sur bande magnétique (suivant leur ancienneté).

Les sorties se font sur écran ou imprimante.

La liste des fonctions décrites essaie de cerner les besoins actuels et futurs des exploitants, mais n’a pas de caractère limitatif, de nouveaux besoins en la matière pouvant toujours apparaître en cours d’exploitation.

On peut distinguer :

a) Les fonctions d’analyse du fonctionnement du réseau qui se décomposent en :

 

– fonctions accessibles au dispatcher comprenant la visualisation et l’affichage

 

. de situations instantanées

 

. d’évolution de termes

 

. d’évènements aléatoires

 

. de comparaison de réalisations aux prévisions

 

– fonctions accessibles hors temps réel, utilisant essentiellement les restitutions sur papier, et portant principalement sur :

 

. l’analyse des incidents

 

. les bilans

 

. les statistiques

 

 

b) Les fonctions d’analyse du fonctionnement des télétransmissions, venant en complément des statistiques effectuées sur les CACQ et comprenant :

 

– les anomalies des téléinformations

– les anomalies de la télécommande.

CONCLUSION,

Dans les Spécifications Techniques Générales sont fournis, pour chaque programme, les résultats de bancs d’essais ou une évaluation du nombre d’instructions déroulées lors de l’exécution. Ces éléments doivent permettre aux soumissionnaires de calculer la charge du système. Ils sont regroupés dans des tableaux joints en annexe au chapitre « Programmes d’application ».

 

Nous avons également effectué dans une étude préliminaire, un calcul de la charge avec des MITRA 125 en prenant 3 µs comme temps moyen d’instruction et en extrapolant les résultats de bancs d’essais (Ces données ne sont bien entendu pas communiquées dans les Spécifications Techniques Générales).

Le tableau ci-dessous indique par classe de fonctions le taux d’occupation moyen ainsi calculé.

Classe Fonctions Traitementssystématiques Charge complémentairede pointe
A Acquisition, visualisation, télécommande

14 %

10%

B Analyse primaire

2 %

3,8 %

Analyse secondaireen temps réel

14 %

38 %

C Analyse secondaireen temps réel étendu

11%

La charge complémentaire de pointe correspond aux traitements à effectuer lorsqu’une avalanche de changements d’état se produit. Nous constatons que l’analyse secondaire en temps réel avec changement de topologie introduit une charge très importante pour l’unité centrale.

CHAPITRE 5 – BASE DE DONNEES.

Evaluation des grandeurs caractéristiques du réseau

Les nouveaux systèmes informatiques régionaux doivent être conçus pour aborder l’année 1990.

Compte tenu de l’évolution actuellement constatée, il a semblé possible d’utiliser l’étude du plan à long terme à l’horizon 1985, pour déterminer les dimensions des réseaux à prendre en compte.

Quelques règles simples ont fourni le plan des téléinformations correspondant. Ce plan par son caractère systématique et exhaustif, conduit probablement à un léger surdimensionnement. Cette « marge de sécurité » reste nécessaire au niveau des Spécifications Techniques Générales.

Le tableau ci-dessous donne la récapitulation du nombre des grandeurs caractéristiques.

 

GRANDEURS CARACTERISTIQUES DES RESEAUX (Horizon 1985)

Site Nombre de postes Nombre liaisons NombreCellules NombreGroupes Nombre. consommations NombreTM Nombre TS
THT HT Coupure Alarme Surveil-lance
THT HT Physique THT HT
Lille 110 200

170

200

130

1660

25

100

210

850

5000

5400

13000

Lion 150 500

500

280

700

4600

500

50

500

1300

13800

15200

23500

Marseille 100 300

300

180

400

2700

150

20

350

800

8000

8900

20000

Nancy 150 520

550

290

850

4670

88

30

780

1300

13500

14000

35600

Nantes 130 420

430

315

650

4820

50

40

840

1700

15000

15000

34600

Paris 200 300

440

460

440

4600

50

200

700

1800

13800

15400

33200

Toulouse 100 600

615

200

550

3050

575

10

500

1400

7000

12000

25500

 

Evaluation de la base de données

Trois types de données peuvent être distingués :

– les données fixes

– les informations temps réel, images de l’état actuel du réseau

– les stockages qui permettent la reconstitution a posteriori de l’état du réseau.

Le tableau ci-dessous récapitule le volume en kilo-octets pour chaque type de données.

LILLE LYON MARSEILLE NANCY NANTES PARIS TOULOUSE
Données temps réel 37 84 57 100 98 95 74
Stockage 9073 19917 12281 19788 19142 21913 13354
Données fixes 3053 4133 3375 4178 3929 3806 4085

L’examen des volumes des bases de données montre que pour cinq dispatchings, les tailles sont comparables. La valeur maximale, environ 25 millions d’octets, est compatible avec les possibilités technologiques actuelles puisqu’il existe des disques de 50 millions d’octets.

CHAPITRE 6 – LOGICIEL DE BASE

Le logiciel de base d’un ordinateur est l’ensemble des outils logiciels qui permettent d’utiliser une installation informatique.

Il sera fourni par le constructeur, le soumissionnaire ou E.D.F., suivant des conditions définies dans le document « Limite de fourniture du matériel et du logiciel » joint à l’appel d’offres.

D’une manière générale, il est demandé aux soumissionnaires d’utiliser au maximum le logiciel du catalogue du constructeur, à l’exception toutefois du logiciel de reconfiguration qui devrait vraisemblablement être spécifique.

Dans le cas des programmes figurant au catalogue du constructeur, les soumissionnaires transmettront les caractéristiques principales. Pour le logiciel spécial, un document détaillé devra être fourni comprenant principes et réalisations.

Dans les deux cas, l’accent sera mis sur la maintenabilité des programmes. Ce logiciel comprend :

Le système d’exploitation temps réel qui peut être décomposé en quatre sous systèmes relatifs à :

 

. la gestion des programmes qui comprend

 

  • le programme de gestion des ressources chargé de gérer au mieux les ressources du système dans le cadre de l’utilisation du moniteur « multitâches ».

 

  • les demandes d’exécution de programmes. L’exécution d’un programme peut être demandée par l’intermédiaire d’interruptions, par un autre programme, par un « programme horloge ».

 

  • les priorités et les modes d’exécution des programmes.

. le traitement des entrées-sorties qui comprend

 

  • les handlers qui exécutent les entrées-sorties au niveau élémentaire et qui sont spécifiques de chaque périphérique

 

  • la gestion des entrées-sorties, c’est-à-dire des files d’attente.

 

  • les commandes d’entrées-sorties depuis les programmes utilisateurs.

 

. la gestion de l’heure

Le système doit pouvoir acquérir l’heure depuis une horloge externe, et en cas de panne de celle-ci, utiliser l’horloge interne.

. la détection des pannes et la reconfiguration

Le logiciel devra répondre aux exigences définies au paragraphe §4 (Architecture : surveillance commande et reconfiguration).

. la génération du système

Le système d’exploitation sera livré sur cartes interprétées et sur bandes magnétiques, ainsi que le système de génération. Diverses modifications devront être possibles sans régénération de l’ensemble du système.

. un système de traitement par lots

Un moniteur d’exécution de traitement par lots devra être fourni.

 

 

La production de programmes et de langages

 

L’écriture des programmes d’application ainsi que leur mise au point étant à la charge des équipes d’E.D.F., celles-ci devront disposer d’un logiciel leur permettant de s’acquitter de cette tâche.

 

Ce logiciel comprend :

 

. un assembleur et un macro-assembleur

 

. un compilateur FORTRAN IV temps réel, un macro-générateur et une documentation technique sur les autres langages évolués.

 

 

. un éditeur de liens et un chargeur.

 

 

Programmes de gestion de fichiers

Un certain nombre d’exigences sont formulées auprès des soumissionnaires Elles reposent en particulier sur le principe que le processus de génération et de modification de fichiers devra être tel que l’exploitant soit assuré d’avoir dans tous les cas un système parfaitement opérationnel et fiable. C’est à dire que les créations et les modifications de fichiers pourront s’effectuer à l’aide d’un éditeur de textes simple d’emploi, ce qui permettra de pouvoir associer exploitants du réseau et informaticiens à la mise à jour.

Elles se feront par cartes perforées ou par console et les informations à introduire présenteront peu de redondance.

Par contre les fichiers générés sur disques temps réel pourront comporter des redondances de façon à accélérer les traitements sous temps réel.

 

Logiciel d’aide à la programmation

L’évolution permanente des programmes d’application conduit à inclure tous les éléments nécessaires à un développement « on line » de ce logiciel. Ces opérations se feront au niveau de priorité le plus bas de la machine et ne devront pas risquer de perturber l’exploitation temps réel

 

Ce logiciel comprendra notamment des programmes :

. de gestion des modules permettant d’introduire des modifications au niveau des langages source et binaire.

. de test et d’élimination des erreurs afin de pouvoir mettre au point les programmesd’application sûr dés copies de la base de données.

 

 

Programmes de service et de test, permettant notamment la visualisation d’informations en mémoire et sur disques, le changement de supports pour les données ainsi que l’établissement de diagnostic pour les pannes.

 

 

Simulateur d’aide au démarrage.

 

Ce système, en cours de réalisation pour le SYSDIC, au service IMA de la DER, pourra être utilisé pour les S.I.R.C. Son rôle sera triple :

 

– aider à la mise au point du système

 

– évaluer les performances

 

– valider le dialogue opérateur – machine.

CHAPITRE 7 – QUALITE DE SERVICE

La qualité de service du système informatique ne peut être simplement perçue à travers la disponibilité de chaque classe de fonctions. Il faut également tenir compte des divers fonctionnements en mode dégradé. Au cours de ce chapitre, ceux-ci sont précisés en ne prenant pas en compte des critères purement informatiques mais en se plaçant du point de vue de l’exploitant.

Pour l’étude de la qualité de service, nous distinguons à l’intérieur d’une même classe de fonctions :

Les fonctions essentielles :

Ce sont celles qui déterminent la disponibilité de la classe.

Les f onctions rattachées

 

Elles sont étroitement liées aux précédentes et, de ce fait, rattachés à la même classe, mais leur disponibilité propre n’aurait pas besoin d’être aussi élevées que celle requise pour les fonctions essentielles auxquelles elles sont rattachées.

 

 

Cette séparation de fonctions nous amène à considérer deux types de périphériques :

– les périphériques indispensables : ce sont ceux sans lesquels les fonctions essentielles d’une classe ne peuvent plus être assurées.

 

– les autres périphériques dont la perte permet néanmoins une exploitation en mode dégradé.

En conséquence, nous entendons par :

panne : une situation dans laquelle les fonctions essentielles du calculateur ou du système ne peuvent plus être assurées.

mode dégradé : une situation dans laquelle certaines fonctions ne peuvent être assurées mais qui néanmoins permet une exploitation du système.

Un classement de la périphérie de chaque classe de fonctions, selon l’un des deux types précédemment définis, est fourni dans ce chapitre.

 

Les pannes et modes dégradés des différents équipements du S.I.R.C., puis la répercussion des pannes sur le fonctionnement du système sont successivement étudiés, de manière détaillée.

La configuration minimale du système après panne est définie. Elle correspond au mode le plus dégradé compatible avec l’exploitation et comprend :

– un calculateur et un disque associé

 

– le système minimal de visualisation : un poste à deux écrans

 

– une liaison avec le CACQ.

Les reconfigurations nécessaires devront être commandées automatiquement, les opérations manuelles devant toujours être possibles et prioritaires par rapport aux autres.

Les exigences en matière de disponibilité pour chaque classe de fonctions ont été définies par ailleurs, mais dans ce chapitre des précisions sont apportées sur les critères de calcul du taux de disponibilité, sur l’incidence des reconfigurations et sur la perturbation de l’exploitation qui en découle

Enfin, les demandes concernant la maintenabilité des matériels et des logiciels sont précisées. Il est exigé qu’E.D.F. puisse disposer des approvisionnements en pièces détachées et du support technique pour la mise à niveau des éléments du système pendant une période de quinze ans. La formation des équipes d’E.D.F. est également évoquée.

CHAPITRE 8 – ARCHITECTURE

Au cours de ce chapitre, les diverses contraintes imposées au matériel informatique sont définies et des exemples d’architecture proposés, mais le choix de celle-ci est laissé aux soumissionnaires.

 

 

. Principes de base

 

Certaines règles générales de conception dont les soumissionnaires devront tenir compte sont précisées, concernant :

– l’adaptabilité du système

 

– le choix des matériels

 

– les problèmes liés à la reconfiguration

 

– la disponibilité

 

 

. Description du système d’un S.I.R.C.

Un rappel sur la périphérie associée à chaque classe de fonction, les liaisons des calculateurs S.I.R.C. entre eux et les liaisons avec d’autres systèmes informatiques est effectué. En ce qui concerne les liaisons entre les calculateurs du S.I.R.C., nous précisons qu’elles pourront être réalisées soit par liaisons inter-calculateurs, soit par disques commutables.

 

 

. . Eléments de choix

 

Pour l’architecture, le choix du nombre de calculateurs dépend de la répartition des fonctions en classes auxquelles des taux de disponibilité

à atteindre sont imposés et de la charge dé celles-ci sur chaque calculateur.

Une pré-étude réalisée en liaison avec le service IMA permet de citer deux exemples d’architecture possible:

– un système à deux calculateurs avec secours simple

 

– un système à trois calculateurs avec secours double des fonctions les plus importantes.

Architecture à deux calculateurs

En situation normale la répartition des classes suivantes est adoptée

 

  • le calculateur 1 assure les fonctions A, B, C

 

  • le calculateur 2 assure les fonctions D.

Dans cette hypothèse, avec des calculateurs industriels, le taux d’occupation est trop important et il faut utiliser des calculateurs à 32 bits par mot ou multi-format. (Il est cependant à noter que le gain de performance entre un calculateur CII.HB 7740 et un MITRA 125 n’est pas, d’après les résultats de bancs d’essais, très important).

On obtient alors un taux de disponibilité :

 

. pour les fonctions A, B et C de 99,88 %

 

. pour les fonctions D de 93,6 %

Le prix du matériel, consoles graphiques exclues, peut être évalué grossièrement dans le cas du 7740 à : 7300 kF.

 

 

– Architecture à trois calculateurs

Elle doit pouvoir être réalisée avec des calculateurs industriels .MITRA 125 par exemple).

La répartition en situation normale peut être :

. Calculateur 1 : A et une partie de B (analyse primaire)

 

. Calculateur 2 : le reste de B et C

 

. Calculateur 3 : D.

. Les charges (CH) et les taux de disponibilité (TD) suivants sont obtenus :

. pour les fonctions assurées par 1 CH=30 % TD = 99,9998 %

 

. pour les fonctions assurées par 2 CH= 63 % TD = 99,98 %

 

. pour les fonctions assurées par 3 CH faible TD = 95,37 %

.

Ces charges ne prennent pas en compte le système d’exploitation temps réel (10 à 20 % de charge supplémentaire).

 

Le coût peut être estimé, consoles graphiques exclues, à 2 235 kF environ.

Les résultats de cette pré-étude (charge, disponibilité) né figurent pas dans la note mais les deux architectures sont proposées comme exemples aux soumissionnaires qui devront justifier leur choix.

Le groupe de travail a marqué sa préférence pour une solution à trois calculateurs.

En effet, dans la solution à deux calculateurs, pour que les fonctions de la classe A aient la disponibilité requise, il semble indispensable de prévoir un système simplifié d’entrée-sortie relié au CACQ système rustique ») permettant la visualisation de certaines informations et l’envoi d’ordres élémentaires de télécommande.

Elle nous semble présenter par rapport au système à 3 calculateurs, plusieurs inconvénients.

Elle accroît le coût de l’ensemble et entraîne des modifications de logiciel dans les CACQ. D’autre part, l’utilisation de ce dispositif sera plus difficile que celle du système normal et ne se fera que quelques heures par an.

Par contre, le système à trois calculateurs garantit un dialogue homme-machine identique dans toutes les situations (sauf bien entendu en cas de panne des trois calculateurs). La charge indiquée précédemment peut paraître élevée, mais elle a été calculée dans l’hypothèse la plus contraignante du point de vue du nombre de téléinformations. De plus, on peut penser que l’hypothèse retenue d’un temps moyen d’instruction égal à 3 µs est pessimiste. Ce système à trois calculateurs implique cependant une complexité accrue du logiciel qui pourra être toutefois simplifiée en acceptant une reconfiguration manuelle en cas de défaillance de deux calculateurs.

 

. . Surveillance, commande et reconfiguration

Pour atteindre les objectifs de disponibilité demandés, les soumissionnaires devront prévoir un système de reconfiguration. Deux possibilités existent :

 

Centralisé

Un dispositif centralise toutes les informations sur l’état du système détermine la stratégie à adopter et envoie les ordres de reconfiguration.

 

Réparti

Chaque calculateur reçoit les informations du système et élabore une stratégie en tenant compte de sa situation propre.

Dans ces deux cas, la reconfiguration devra être soit automatique (dans le cas de panne du système), soit manuelle, mais pouvant être réalisée simplement par le dispatcher. Afin de pouvoir commander ce deuxième type de reconfiguration, l’exploitant devra donc être informé de l’état du système. Cette information lui sera communiquée par l’intermédiaire :

. de la machine de commande

. du système de visualisation

. d’un synoptique de commande et de contrôle.

Il sera également procédé à l’établissement de statistiques sur les incidents afin de pouvoir déterminer les points critiques du système.

Les méthodes de détection des pannes sont essentielles pour la réalisation des commutations appropriées. Il est donc demandé aux soumissionnaires de les préciser pour :

. l’alimentation électrique

 

. l’unité centrale

 

. l’autocontrôle

 

. la mémoire

 

. les entrées-sorties

 

. la panne d’un programme ‘application. .

 

.

 

CONCLUSION

. Il est demandé aux soumissionnaires de sélectionner une architecture comportant 2 ou 3 calculateurs à 16 ou 32 bits par mot ou multi-formats, de définir l’option et le matériel retenus pour la reconfiguration et d’évaluer la disponibilité des classes ainsi que la charge en pointe et en moyenne.

Ils devront également fournir le coût du système en indiquant :

– d’une part, son coût de base ;

– d’autre part, le surcroît de coût entraîné par chaque option ou par

– périphérique supplémentaire.



[1] L’équipe était composée d’Alain Hérault, Gérard Ducheler et Pascal Ordoquy. Elle a servi d’embryon pour l’équipe SIRC qui a piloté la réalisation. (Ajout lors de la mise en forme de la note)

Le Poste de Commande Hydraulique ( PCH ) de Lyon

Dès 1960, les unités régionales (GRPH) du Service de la Production Hydraulique, avec les services des Télécommunications des unités régionales du Transport, mettent en oeuvre la coordination de plusieurs centrales depuis un poste de commande situé dans la centrale importante de la vallée ou depuis un dispatching. Dans les dispatchings, des tableaux centralisés sont mis en place :

  • télécommande de la station de transfert d’énergie par pompage du lac blanc et du lac noir depuis le dispatching de Nancy,
  • télécommande des centrales d’Orlu, l’Hospitalet, Mérens et Portillon depuis le dispatching de Toulouse,
  • télécommande des centrales de La Bathie, La Coche et Randens depuis le dispatching de Lyon

Au cours de la période 1975 à 1985 de développement de l’automatisation de la conduite du Système Electrique dans le cadre du SDART, le Service des Mouvements d’Energie souhaite développer la commande depuis ses centres de conduite des groupes des centrales de lac et des stations de transfert d’énergie par pompage (STEP) afin de renforcer l’optimisation de la gestion de l’eau, et la réactivité des variations de production.

Il s’agit de :

– la STEP de Revin depuis le dispatching de Nancy,

– des 14 centrales de lac et des STEP des Alpes du nord depuis le Poste de Commande Hydraulique (PCH) de Lyon installé dans le Dispatching de Lyon.

Les équipements mis en œuvre sont identiques à ceux utilisés sur le réseau de transport : un calculateur Mitra 15 au PCH, doublé pour assurer la continuité de service, et des équipements de téléconduite ETC 50 pour les liaisons entre le PCH et les centrales hydrauliques.

Vers le PCH convergent ou transitent, les informations issues ou destinées

– aux centrales hydrauliques :

  • Mesures de niveau de la retenue
  • Alarme centrale,
  • Seuils de fréquence.

– aux groupes hydrauliques :

  • Mesure de puissance active
  • Mesure de puissance réactive,
  • Mesure de tension
  • Indisponibilité du groupe,
  • Groupe en commande locale,
  • Commande de démarrage en turbine,
  • Commande de démarrage en pompe,
  • Commande d’arrêt,
  • Commande de marche synchrone,
  • Consigne de puissance active,
  • Consigne de tension,
  • Niveau de réglage fréquence-puissance,
  • Commande de retour à 50 Hz

Les niveaux de réglage fréquence-puissance et de réglage secondaire de tension, automatisés, sont reçus du CACQ . Les commandes et les consignes sont transmises directement par le personnel du dispatching régional au dispatcheur du PCH pour manœuvrer.

structure du PCH de Lyon

Parallèlement à la mise en œuvre des postes de commande hydraulique par le Service des télécommunications pour les centrales de lac, le Service de la Production Hydraulique développe, avec des matériels différents, des Postes Hydrauliques de Vallée (PHV) pour les centrales d’éclusée et les centrales au fil de l’eau.

Avec la création de RTE et la séparation de celui-ci des autres activités d’EDF, c’est à dire à partir de l’An 2000, les PCH et PHV sont regroupés par EDF dans des Centres de Conduite Hydraulique à Toulouse, Lyon, Sainte Tulle et Kembs.

La conduite d’une usine hydraulique depuis un dispatching, à partir d’un calculateur MITRA15, est présentée dans cette vidéo : Depuis le pupitre de commande, choix du groupe, de sa puissance, contrôle de l’exécution.

 

Présentation du SDART

Mis en avant

Le Schéma Directeur de l’Automatisation du Réseau de Transport ( SDART ) élaboré dans le début des années 1970, représente le premier projet de développement d’une infrastructure de télécommunications et d’informatique industrielle pour répondre aux objectifs de sûreté du système électrique, de rapidité des reprises de service après incident, notamment avec le déploiement du réseau de grand transport 400kV lié au plan de construction du parc nucléaire.

Il a été élaboré par un groupe de travail “Automatisation du Réseau” réunissant des compétences de la Direction des Études et Recherches, du Service des Mouvements d’Energie et du Service du Transport, d’Electricité de France (EDF).

Les principes directeurs

Il s’agit de regrouper au niveau du dispatching régional (7 dispatchings régionaux et un dispatching national ) les fonctions de décision, puis à terme, d’exécution des actions de conduite du réseau dans les postes électriques. Au niveau régional, le dispatching reçoit ainsi les informations nécessaires pour cette conduite du réseau : les téléinformations (ou télésignalisations ) d’état des organes ou d’alarme, et les télémesures. Le dispatching n’est pas seulement un centre de décision, il devient à terme un site de conduite du réseau (Centre Régional de Conduite – CRC -). En fait si l’infrastructure générale prévue pour cette conduite est réalisée dans les temps, le CRC n’aboutira pas dans les temps prévus et la télécommande des postes depuis les dispatchings sera mise en place avec le projet EXTEL à la fin des années 90 sur les outils informatiques existants des dispatchings (évolution des SIRC ).

Le SDART généralise la notion de Groupements de Postes, plus d’une centaine, équipés de Pupitres de Commandes Groupées (PCG). Il définit une chaîne continue de circulation des téléinformations depuis les postes HT jusqu’aux Dispatchings en passant par les PCG.

L’architecture du SDART

L’architecture de l’ensemble découle naturellement du concept d’organisation centralisée de l’exploitation du réseau électrique au niveau régional. Vers les PCG convergent ou transitent les informations (télésignalisations et télémesures) issues ou destinées aux postes asservis (PA), transmises par les équipements de téléconduite (PC, parfois nommés TCD) TLC11, ou ETC 50, qui vont se substituer progressivement aux matériels électromécaniques anciens ( Systèmes IV de CGCT ).

Au siège du PCG, sont sélectionnées et diffusées les informations intéressant le dispatching régional. C’est le rôle de l’ensemble de traitement (EDT), nouvel équipement qui collecte, concentre et restitue également sur une imprimante locale les événements issus des postes asservis via les équipements de téléconduite.

Au dispatching régional les calculateurs d’acquisition (CACQ) reçoivent et stockent les informations de l’ensemble des PCG de la région et les aiguillent vers les calculateurs de traitement et le synoptique local, mais aussi, pour certaines, vers le dispatching national ou vers les dispatchings régionaux voisins.

Sur le plan national, les sept calculateurs d’acquisition (CACQ) situés dans les dispatchings régionaux, avec le système informatique du dispatching national et les liaisons de transmission associées, constituent le réseau dit « de transmission en temps réel » (TTR).

Ce schéma est une révolution par rapport aux dispositions précédentes en faisant du site du groupement de postes, où apparait l’EDT (Ensemble de Traitement) un point de concentration des informations acquises au niveau des postes, avec retransmission vers le dispatching régional, lui-même point de passage vers le dispatching national.

La technologie associée fait largement appel aux techniques informatiques (microprocesseurs pour les téléconduites, mini-ordinateurs pour les EDT de PCG).

Méthode d’action

Le plan de développement prévoit une politique de déploiement coordonnée entre la mise en œuvre des équipements et les études afin d’aboutir à une organisation centralisée de la conduite du réseau électrique à l’horizon des années 1980- 1982. Au plan technique, il s’inscrit dans une perspective de palier technique. Pour l’exploitant, ce plan maintient la continuité dans le mode d’exploitation des postes, en réduisant les disparités dues à l’utilisation d’équipements différents. Ainsi, l’opérateur du PCG, commande de la même manière les postes asservis équipés d’un système de télécommande, de téléconduite ou avec un calculateur. Pour minimiser l’investissement, l’utilisation des équipements existants jusqu’à leur obsolescence est préconisée. C’est ainsi que sont maintenus dans un premier temps grâce à des adaptations les télécommandes Système IV du Transport existantes entre PCG et PA et les équipements “Informations codées » entre PA et les Dispatchings Enfin, la cohérence avec les plans de développement propres à d’autres services d’EDF, tels que ceux des services des Mouvements d’énergie ou de la Production hydraulique est prise en compte.

Le budget prévisionnel

La méthode d’évaluation détaillée s’appuie en matière de coûts sur des expérimentations conduites en particulier au CRTT Paris. Elle aboutit à une enveloppe financière globale de 230 MF (1973) n’intégrant pas les dépenses propres à l’installation des CRC aux sièges des dispatchings régionaux.