Le palier SIRC a vu les dispatchings entrer dans l’ère des mini-calculateurs (calculateurs intermédiaires en termes de puissance de processeur et de taille mémoire entre d’une part les gros systèmes tel IBM 370 et d’autre part les micros en phase d’émergence) et aura marqué par sa longévité la vie des systèmes de conduite du système électrique français

Le contexte à EDF

Au début des années 1970, le dispatcheur assurait la conduite du système électrique (gestion des flux d’énergie électrique, maîtrise de la tension et de la fréquence, équilibre production-consommation, sûreté du système dans son ensemble). Les agents du Transport, responsables de la sécurité des biens et des personnes, réalisaient les manœuvres des installations de conduite demandées par le dispatcheur, soit par télécommande depuis les PCG, soit directement dans le poste depuis un tableau de commande. Ils assuraient également, depuis le PCG, la surveillance du fonctionnement des matériels dans les postes (transformateurs, disjoncteurs, protections…) notamment à partir des alarmes reçues au PCG. La mise en place de nouveaux moyens de transmission de données des postes vers les dispatchings (systèmes IV et V,  ERC, en savoir plus) ainsi que la pénétration des calculateurs dans le milieu industriel ouvrirent de nouvelles perspectives d’exploitation plus proches des limites physiques des installations. Ainsi l’accélération des prises de décision par une appréhension globale et fiable de l’environnement électrique puis l’exécution des ordres du dispatcher sans intermédiaire humain devaient contribuer à l’amélioration de la sûreté du Système Electrique et à l’économie de moyens.

C’est dans ce contexte qu’un groupe de travail mixte SME, STE et DER intitulé « Automatisation des réseaux » a été créé pour réfléchir à l’évolution de la conduite des installations du Transport et aux moyens associés. Ce groupe de travail rendit ses conclusions en 1973. Il préconisait une centralisation au dispatching de la commande des installations et de la surveillance des matériels et proposait une architecture du Réseau de Téléconduite hiérarchisée (1) . Un plan de développement y était associé. Ainsi naquit le Schéma Directeur d’Aménagement du Réseau de Téléconduite, le SDART (en savoir plus). Au niveau régional, le Dispatching passait de simple centre de décision à un Centre Régional de Conduite incluant le diagnostic dans toutes ses composantes (y compris le matériel), l’analyse, la décision puis l’action. Le SDART actait que la prochaine génération de SCADA devrait pouvoir évoluer dans ce sens. Compte-tenu des incertitudes sur la possibilité de maintenir le palier actuel à base de CAE 9010/9040 au-delà de 1980, il positionnait le déploiement des nouveaux SCADA sur la période 1980-1982.

Le lancement du projet SIRC (Système Informatique Régional de Conduite)

Le renouvellement des SCADA régionaux, dans la perspective de la mise en place des Centres Régionaux de Conduite, prend le nom de projet SIRC (en savoir plus). Les études pour le renouvellement des SCADA démarrent en 1975. Un groupe de travail est missionné pour rédiger un cahier des charges en vue du lancement d’un appel d’offre. Il rassemble des représentants du SME, du Service du Transport et de la DER. Le cahier des charges aboutit en 1976 (« Présentation des spécifications techniques générale des SIRC« ). Il précisait bien que les futurs SCADA devaient permettre l’évolution des dispatchings régionaux vers les Centres Régionaux de Conduite et proposait un plan de déroulement en 2 étapes :

1.  mise en service des fonctions liées à la conduite du réseau,
2.  mise en service des fonctions de télécommande et de surveillance des installations.

EDF prévoyait d’intégrer dans le système les modèles de calcul de réseau développés par la DER. Nous citerons estimateur/appréciateur d’état (2) , calcul de sécurité en actif seul (3) , calcul de sécurité en alternatif, calcul des puissances de court-circuit. L’intégration d’autres modèles liés à la gestion de la production hydraulique était également mentionnée. La rédaction du cahier des charges est suivie d’une phase d’étude qui porte sur les matériels susceptibles d’accueillir l’application SIRC.

La réalisation

Méthode et organisation

L’idée de lancer un appel d’offre pour la réalisation des logiciels applicatifs fût abandonnée au motif que le savoir faire en matière de conduite des réseaux faisait partie de la propriété industrielle d’EDF. Seuls les matériels seront approvisionnés de cette façon.

Les critères  coût et sécurité d’approvisionnement (notamment en privilégiant les sources françaises) ont été les paramètres déterminant dans le choix des matériels, au détriment de l’adéquation entre Système d’exploitation (OS) et exigences temps réel. Seront retenus :

• Mini 6 de la CII-HB pour les calculateurs.
• VG2100 de la société CIT-SINTRA  (4) pour le matériel de visualisation (contrôleurs et écrans) en savoir plus sur architecture et matériels des SIRC

EDF a ainsi pris à sa charge  le développement et l’intégration de tout le logiciel applicatif, c’est-à-dire :

• Les traitements temps réels (analyse primaire),
• Les post-traitements (analyse à postériori),
• Toute l’interface homme-machine (l’IHM),
• Les modèles de calculs de réseau qui seront intégrés dans un ensemble appelé «Analyse secondaire».
• Un logiciel graphique LGIVD  (5)  , développé par EDF/DER/IMA, qui est retenu pour  ses capacités à décrire les interactions dans les dialogues.

C’était donc un challenge ambitieux que s’était fixé EDF en se lançant dans la réalisation d’un système que seules des sociétés d’envergure internationale comme ABB, Westinghouse ou Général Electric proposaient sur le marché. Pour le relever, une organisation originale a été mise en place : à côté d’une équipe nationale de projet gréée avec un Chef de Projet et des responsables de domaine, les équipes informatiques des CIME ont contribué dans chacun des domaines à la réalisation des logiciels sous l’égide du Chef de Projet. Chaque CIME possédait en effet une Section Traitement de l’Information dont les ingénieurs assuraient l’exploitation et la maintenance des 9040. Ainsi chaque CIME a pu disposer à la mise en service du SIRC dans sa région, de personnes ayant une compétence significative du fonctionnement interne du système entraînant des capacités de diagnostic et de dépannage importantes. L’équipe nationale avait en charge le développement des logiciels communs ainsi que les modules d’IHM les plus importants. Elle était installée dans un appartement bourgeois (49 rue de Lisbonne, 8ème arrondissement de Paris, à deux pas de l’ensemble EDF Murat-Messine). Une plate-forme de développement et d’intégration y avait été montée. Chaque CIME était doté d’une console alphanumérique reliée à la machine de développement, permettant ainsi aux développeurs de saisir leur code et de le compiler. Les développeurs nationaux et régionaux avaient été envoyés en formation chez CII-HB en décembre 1978 pour se familiariser avec le système d’exploitation GCOS 6 mod 400 et acquérir la maîtrise de la programmation en assembleur. La réalisation pouvait alors commencer…

Le déroulement de la réalisation

A la fin des années 70, le cycle en V était déjà la règle pour les projets informatiques et c’est donc sur ces bases que la réalisation a commencé

•  La phase de conception a mobilisé l’équipe nationale de projet qui a spécifié les différents traitements à réaliser, leur récurrence et les a réparti en modules qui ont été ensuite attribués aux CIME. Bien que le Mini 6 marquait, par rapport au 9040, un progrès significatif en matière de capacité mémoire et de vitesse de calcul, les concepteurs, dans la lignée de ceux du 9040, ont eu soin de minimiser les ressources utilisées et d’optimiser les performances. Nous verrons plus loin que cela ne s’avèrera malheureusement pas suffisant. en savoir plus sur le développement des logiciels SIRC
•  La phase de codage et de tests unitaires marquait l’entrée en lice des analystes programmeurs régionaux. En l’absence de base de données et de système de gestion de fichiers, les développeurs ont dû dans un premier temps se contenter de données réseau définies en « DATA » dans les programmes.  Ultérieurement, l’équipe de projet a construit les tables et les fichiers pour une petite partie du réseau (dénommée mini-base de données). Le développeur pouvait alors lancer à distance l’exécution de son module et consulter les résultats directement dans les fichiers et les tables. Dans cette période, des moyens de tests sont installés sur la plate-forme pour simuler la connexion du SIRC à la téléconduite. Un CACQ a d’abord été installé pour la mise au point de la liaison CACQ-SIRC puis un émulateur de réseau qui simulait l’alimentation du CACQ en informations.
•  La phase d’intégration marqua un nouveau palier. Chaque module a été intégré dans la gestion des tâches temps réel. A partir de cette étape, les essais à distance devenaient délicats et les développeurs régionaux furent conviés à venir terminer leur mise au point en plate-forme. Ce fût l’occasion de constater l’effervescence qui y régnait en permanence. Les conflits de ressources étaient fréquents entre ceux qui travaillaient sur le configurateur de données, les ingénieurs système, ceux qui développaient l’IHM et enfin ceux qui intégraient les modèles d’analyse de réseau. Situation aggravée par le fait que les essais étaient parfois destructifs et, qu’à chaque fois, de longues minutes étaient nécessaires pour relancer la machine. Il est à noter que les premières intégrations ont commencé par les tâches d’analyse primaire et que l’absence des tâches de visualisation a amené à développer et à intégrer de nombreux utilitaires pour visualiser les schémas de postes, la topologie nodale, les alarmes, introduire des seuils…

En 1982, le Directeur de Projet, considérant que les moyens disponibles en plate-forme ne permettaient pas d’aller plus loin dans les tests d’intégration (et en particulier pour les modèles de calcul de réseau qui nécessitent une acquisition complète et cohérente des informations) prit la décision de poursuivre l’intégration sur le site pilote. La phase de recette en plate-forme (appelée communément recette usine) fût ainsi largement occultée.

 Intégration et déploiement sur le site pilote. Le choix du site pilote s’était porté sur Nancy pour au moins trois raisons :

• une taille du réseau représentative,
• il n’était pas nécessaire de livrer les fonctions liées à la gestion fine de l’hydraulique
• la motivation de la direction du CIME ainsi que l’implication du personnel.

Les premiers tests de fonctionnement en temps réel, avec une acquisition nominale des téléinformations et l’ensemble des postes opérateur mirent en évidence de graves défauts qui n’avaient pas été vus en plate-forme :

•  La charge du calculateur maître était trop élevée en régime établi (elle dépassait les 50%),
•  Par moments la mémoire vive était saturée, ce qui empêchait le chargement de tâches,
•  Les temps de réponse sur appel d’image étaient mauvais, voire désastreux sur des appels simultanés d’opérateurs,
•  Le système ne tenait pas une nuit sans se planter (mais néanmoins, il basculait et redémarrait tout seul, ce qui aura permis de mieux assimiler la subtile nuance entre disponibilité et robustesse…),
•  Les contrôleurs graphiques étaient également l’objet de plantages fréquents.

Force est de constater que le SIRC était loin d’être apte à prendre la relève du 9040. Vont alors s’ensuivre deux longues années de mise au point et d’optimisation sur site qui ont fortement mobilisé l’équipe nationale de projet et les différents acteurs régionaux (analystes et gestionnaires de la base de données). Les efforts ont fini par payer et la mise en service opérationnel du SIRC à Nancy a été prononcée en 1984, ouvrant de ce fait la porte au déploiement.

Le chef du Service Etude de Nancy au premier plan à gauche avec la section Traitement de l’Information A droite un Mini-6

Le déploiement généralisé. Même si le système mis en service à Nancy donnait satisfaction, la marge obtenue par les travaux d’optimisation fut jugée insuffisante pour couvrir la durée de vie du système, d’autant plus que la mémoire était déjà à sa configuration maximale (2 MO). Par ailleurs, les DPS6, successeurs des Mini 6, étaient disponibles et présentaient un double avantage : ils fonctionnaient avec le même système d’exploitation et offraient des capacités mémoire bien supérieures. Le portage de l’application SIRC sur DPS6 fût alors décidé et une nouvelle stratégie de déploiement fût définie : terminer les déploiements engagés avec des Mini-6, puis après validation de l’application migrée sur DPS6, poursuivre le déploiement avec des DPS6. Une fois tous les SIRC en service, les sites équipés de Mini 6 migreront sur DPS6. Entre-temps, il faut signaler début 1986 le déménagement de l’équipe nationale de Projet au 29, rue Jean Bonal à la Garenne-Colombes (92) dans des locaux mieux adaptés à leur activité (faux plancher, climatisation) et plus vastes puisqu’il fallait désormais gérer deux plates-formes. Sur le papier, la migration de l’application SIRC sur DPS6 ne présentait pas de difficulté importante. Pourtant l’opération prit environ un an. Le déploiement s’est ensuite poursuivi sans encombre.

Le dernier SIRC mis en service aura été celui de Nantes en 1988. Les maintenances corrective et évolutive prendront ensuite le relais. Sur la durée de vie des SIRC, des milliers d’anomalies auront été corrigées et la disponibilité qui était médiocre au départ a été fortement améliorée : on sera passé ainsi en moyenne de 2H d’indisponibilité fortuite  (6)  par mois à moins d’une 1/2H.

Le bilan du projet

En incluant la phase d’études, il aura fallu 13 ans pour mener à bien la mise place de la deuxième génération de SCADA dans tous les dispatchings. Rappelons qu’il s’agissait de la première étape vers la mise en place des Centres Régionaux de Conduite. Dans sa version initiale, le SIRC ne comportait qu’une fonction de télécommande simplifiée qui s’appliquait à une liste d’ouvrages définie en configuration. Il restait à généraliser cette fonction de télécommande et à développer les fonctions de surveillance des installations. Au départ du projet SIRC, personne ne s’imaginait que la marche à franchir pour la première étape serait aussi haute. Cela a tenu à plusieurs choses :

•  Conçu au départ pour des accueillir des applications transactionnelles ou pour servir de serveur de communication à de grands systèmes, le Mini-6 n’était pas la machine idéale pour développer un SCADA. Le choix des intégrateurs se portait plutôt à cette époque sur les PDP 11 de DEC ou la gamme 32 bits de SEL. Des développements complémentaires au cœur même du système se sont avérés nécessaires.
•  Aucun outil n’était fourni pour gérer les données (le SGBD Oracle venait à peine de naître). Il a donc fallu développer « ex nihilo » un configurateur de données, ce qui avait été totalement négligé dans la phase d’études.
•  Il fallut intégrer des logiciels qui n’avaient été que peu ou prou éprouvés en temps réel : LGIVD et les modèles de calcul de réseau dont la sensibilité à la cohérence des données était mal connue,
•  Certains traitements qui semblaient marginaux au départ se sont avérés compliqués. C’est notamment le cas des traitements au démarrage du système qu’il a fallu différencier selon le type de démarrage : premier démarrage, démarrage standard, et cerise sur la gâteau, démarrage après modification de la base de données sans perte des informations introduites par le dispatcheur (valeurs de seuil par exemple).

Le volume des développements correspondants au projet SIRC sera chiffré à une grosse centaine d’hommes-ans. A cela il faut ajouter :

•  le déploiement qui mobilisera plusieurs personnes pendant 4 ans,
•  les tâches régionales qui incluent la préparation des locaux, le peuplement de la base de données, les recettes, la formation.

Aurait-on pu faire mieux ?

 Sans aucun doute, à la lumière de l’expérience acquise depuis  et de l’état de l’art actuel.

C’est particulièrement vrai pour les phases de recette : d’une part la configuration de la plate-forme de développement n’était pas représentative de celle d’un site et d’autre part la formalisation et la profondeur des recettes était insuffisante. Une plate-forme suffisamment gréée en postes opérateurs et en acquisition de données aurait évité de découvrir sur le site pilote les problèmes de performance et de fiabilité et de constater que le SIRC s’effondrait au premier incident réseau sérieux. Quoiqu’il en soit, les faiblesses méthodologiques furent compensées par l’engagement et les compétences mixtes (informatique et métier) des équipes de réalisation nationales et régionales. Au final le choix du Mini 6 ne s’avérera pas si mauvais que cela. Ses capacités d’adressage et son architecture hard et soft lui permettront d’absorber pendant 25 ans toutes les nouvelles fonctionnalités et extensions du réseau et d’entrer dans l’ère de la virtualisation. Le résultat  n’a finalement rien eu à envier aux SCADA du commerce. La conception générale, en particulier, ne sera jamais remise en question.

Les fonctionnalités offertes au dispatcheur

Chaque dispatcheur disposait d’un poste de travail à 3 écrans. Les deux premiers étaient utilisés pour l’affichage et le dialogue, le troisième étant réservé à l’affichage des alarmes. La configuration d’un CIME comportait également des postes de travail sans écran d’alarme à un ou deux écrans de dialogue, destinés à la préparation de la conduite, au retour d’expérience, à la validation des téléinformations et des bases de données.

 Poste de travail du dispatcheur avec les deux écrans de dialogue du SIRC. L’écran dédié aux alarmes, situé sur la droite n’est pas visible

Les fonctions initialement disponibles :

• Consultation de l’état temps réel du réseau sur des images de poste, de zone (représentation nodale d’un ensemble de postes), de vallée (représentation des retenues et des usines d’une vallée) ou sur une ossature quelconque configurée en base de donnée (image générale), en savoir plus sur l’imagerie typique des SCADA 
•  Consultation des stockages sous forme de courbes, de tableaux de nombres ou même sur des images de poste (cas des stockages demi-horaires),
•  Consultation des journaux de bord,
•  Dialogues permettant de mettre en ou hors surveillances des mesures, de modifier des seuils de surveillance, d’imposer des valeurs ou des états à des téléinformations (fonction de masquage),
•  Lancement et suivi du déroulement d’une télécommande (accès limité à une liste de télécommandes définies en configuration),

 Les fonctions développées par la suite

 Amenés à fonctionner pendant plus de 20 ans (ce qui est exceptionnel pour une application informatique), les SIRC ont été sollicités pour contribuer à régler les problèmes d’exploitation du système électrique rencontrés sur la période et s’adapter à l’évolution de l’exploitation. De nouvelles et importantes fonctions (certaines ont même été développées en mode projet), ont été mises à disposition du dispatcheur. Nous citerons (en savoir plus sur les évolutions logicielles du SIRC)

•  Un automate logiciel commandant le blocage des régleurs en charge des transformateurs THT/HT sur critère de baisse de tension,
•  Un automate logiciel commandant l’enclenchement ou le déclenchement des moyens de compensation d’énergie réactive (la C3R), le but étant de maintenir la tension dans une plage déterminée en des points particuliers du réseau appelés points pilote. Cet automate ne sera installé qu’à Nantes.
•  L’hydraulique temps réel étendu. Ce package offrait la surveillance de l’exécution du programme de marche des centrales hydrauliques. Un mode étude permettait de simuler le fonctionnement d’une vallée sur la base d’un programme de marche prévisionnel des centrales.
•  L’extension de la fonction télécommande : le projet EXTEL. L’abandon du projet CRC en 1993 (lien vers l’article CRC en construction) a repoussé aux calendes grecques la mise en place des Centres Régionaux de Conduite et a relancé l’intérêt de développer une véritable fonction télécommande sur le SIRC. Cela a permis, outre les gains sur l’exploitation, de valoriser les travaux de rénovation de filerie effectués dans le cadre du projet CRC. Le mode projet fût choisi en raison des impacts multiples sur la doctrine d’exploitation et les organisations. Le projet n’a pas rencontré de difficultés particulières et le déploiement s’est achevé en 1998. Avec EXTEL les dispatcheurs pouvaient télécommander les organes de coupure et les automates depuis les images de poste. Le logiciel effectuait systématiquement des contrôles avant émission de l’ordre, contrôles visant à s’assurer de l’état du matériel, de l’environnement et de la licité de la manœuvre.
•  La synthèse d’alarmes : comme pour EXTEL, le développement de cette fonctionnalité a été une conséquence de l’abandon du CRC. Les résultats encourageants de l’expérimentation CRC au Dispatching de Normandie Paris ont conduit RTE à décider d’implémenter dans les SIRC une synthèse d’alarme restreinte portant sur les cycles disjoncteurs. Elle a été développée conformément aux principes mis en œuvre dans le CRC.

Les autres fonctionnalités du SIRC

 L’analyse a postériori

 Elle consistait en :

•  Un ensemble d’éditions journalières exploitant les journaux de bord des calculateurs (changements d’état de télésignalisations, télécommandes effectuées, dépassements de seuils, anomalies sur les Téléinformations, etc.). Ces éditions étaient utilisées par le personnel chargé de la gestion des données et du retour d’expérience.
•  Des traitements à récurrence mensuelle visant à effectuer les décomptes sur les lignes d’échange avec l’étranger et qui s’appuyaient sur des télécomptages et des télémesures spécifiques de classe 0,2 dites TM SPI,
•  Des agrégations mensuelles voir annuelles à destination du Service des Statistiques d’EDF

Les besoins d’exploiter les données stockées dans le SIRC pour le retour d’expérience n’ont cessé de croitre dans le temps et la durée de conservation des historiques dans le SIRC s’est vite révélée insuffisante (12 jours pour les moyennes ½ horaires). C’est pourquoi a été mis en place un serveur de stockage long-terme (le SLT) permettant de conserver et d’exploiter les archives du SIRC sur plusieurs années. De nombreuses applications ont été développées aussi bien à l’usage du Système que du Transport (exemple : l’application VISUALAPOS permettait de reconstituer l’état du réseau sur une image de poste à une date donnée).

L’analyse secondaire

 La dure réalité du terrain a contraint EDF à réduire ses ambitions en matière de calculs de réseau (plan de télémesures incomplet, charge de travail pour la correction des valeurs et états  erronés). Les dispatcheurs  dans un premier temps se sont contenté d’une chaine cyclique comportant :

•  un estimateur d’état sur la HTB (modèle reconstituant un plan de télémesures cohérent tout en éliminant les télémesures repérées comme erronées)
•  un calcul de sécurité en actif seul (simulation du déclenchement d’une liste d’ouvrages un par un, avec détection des contraintes et génération d’alarmes).

Ultérieurement, la chaîne cyclique a été complétée par un calcul de PCC et un mode étude a été mis en place permettant de réaliser des simulations sur une situation de réseau archivée. Mais il a fallu attendre la mise en place de la fonction avancée ASR (Analyse de Sécurité Réseau) sur des stations de travail dédiées pour atteindre les objectifs que s’était initialement fixés EDF.

La gestion des données

Quelque peu occultée dans les études préliminaires du projet SIRC, la gestion des données a pris toute son importance quand il s’est agi d’implanter les modèles de calcul de réseau puis la fonction télécommande d’EXTEL. Le logiciel de génération de la base de données du SIRC, bien que rustique, comparé à l’état de l’art aujourd’hui, s’est montré néanmoins suffisamment évolutif et fiable pour répondre aux exigences des nouveaux développements.

Les principales caractéristiques

Une organisation hiérarchique des données (site, poste, etc.) Une interface opérateur accessible depuis une console alphanumérique et constituée de menus et sous-menus, Un seul utilisateur à la fois, Génération automatique des images de poste (fonctionnalité en général non disponible dans les produits du commerce).

Mise en œuvre

La génération d’une nouvelle base s’effectuait hors ligne, en deux passes. La première passe contrôlait la cohérence (existence, unicité) et rangeait les données dans des fichiers intermédiaires. La deuxième passe générait à partir des fichiers intermédiaires les fichiers utilisés pour le temps réel. Contrairement aux SGBD actuels, l’objectif était de générer des ensembles de données (fichiers ou tables) les plus compacts possibles en vue de leur utilisation la plus efficace. Certaines données étaient donc dupliquées dans plusieurs ensembles différents, la cohérence étant vérifiée au moment de la deuxième passe. Mettre en service une nouvelle base de données consistait à recopier hors-ligne les fichiers temps réel sur les disques temps réel de la machine esclave puis à la redémarrer en mode Maître. Opération qui devait être réitérée sur le deuxième système.

Liens avec lES autres equipements de téléconduite

De 1986 à 1988, le Service du Transport, dans un souci de cohérence, a développé un Configurateur Généralisé destiné à accueillir toutes les données de téléconduite d’une région. Ces données sont ensuite extraites sélectivement et transmises aux différents configurateurs de la chaine de téléconduite (PC, EDT, CACQ). Au départ, le SIRC ne faisait pas partie des bénéficiaires. Ultérieurement il utilisera une extraction du CACQ (IF CACQ) comme source des strictes données de téléconduite, puis une extraction du configurateur des PEXI  (le SYCOET) comme source des données descriptives des postes.

L’exploitation et la maintenance.

Les tâches d’exploitation ont été assurées par les Sections Traitement de l’Information de chaque CIME. Cela consistait à effectuer des sauvegardes, mettre en service de nouvelles versions de bases de données ou de nouvelles versions de logiciel, lancer des travaux d’analyse a posteriori, restaurer le service après un incident, analyser les disfonctionnements et rédiger des fiches d’anomalie. Il faut noter que les tâches d’exploitation étaient assez lourdes. Du fait du système de dimensionnement propre à chaque région, toute installation de nouvelle version du logiciel nécessitait une compilation sur place. Les sauvegardes prenaient du temps (il fallait 9 bandes pour sauvegarder un disque 300 MO) et le traitement des anomalies chronophage. Heureusement, l’éditeur de texte permettait d’élaborer des fichiers de commande et d’enchaîner les opérations (un peu l’équivalent du JCL (Job Control Language) sur IBM. La maintenance logicielle a été jusqu’à la fin assurée par une équipe nationale, dans la continuité du projet. Elle disposera d’une plate-forme installée d’abord à Saint-Denis Pleyel dans les locaux de l’unité informatique du Transport  puis dans les locaux de l’UTI à St-Ouen pour déménager enfin à la Tour Marchand en périphérie de La Défense. Cette équipe assurait également la formation à l’exploitation des SIRC. Comme pour les 9040, la maintenance matérielle sera confiée aux équipes Télécommunication des CRTT, celles-ci gardant la possibilité de faire appel à l’expertise des fournisseurs. Les difficultés se situeront essentiellement au niveau des matériels graphiques : La durée de vie des tubes ne dépassait pas un an (les couleurs pâlissaient et devenaient non significatives pour le dispatcher à cause de la dégradation des phosphores), la THT des tubes présentait l’inconvénient d’être bruyante, difficilement réglable et surtout fragile. Fort heureusement, tous ces matériels seront remplacés avant terme (lien vers le doc Les matériels et logiciels du SIRC)

Notes de bas de page

(1) Ensemble des matériels et liaisons utilisées pour acheminer les informations des postes vers les PCG puis les dispatchings et pour transmettre les commandes dans l’autre sens. retour

(2) Modèles de calcul déterminant toutes les grandeurs électriques d’un réseau à partir des télémesures existantes. retour

(3) Modèle de calcul simulant le déclenchement successif des ouvrages du réseau, ici dans l’approximation du courant continu. retour

(4) Compagnie Internationale des Téléphones-Société Industrielle des Nouvelles Techniques Radioélectriques. Deviendra SINTRA ALCATEL en 1982 puis sera rachetée par Thomson CSF en 1986.
retour

(5) Langage Graphique Industriel de Visualisation et de Dialogue.
retour

(6) En opposition aux indisponibilités programmées comme la mise en service d’une nouvelle base de données ou d’une nouvelle version de logiciel. Les plantages de l’application, fréquents au début, provoquaient soit un redémarrage complet du calculateur Maître, soit un basculement du temps réel sur le calculateur Esclave qui pour passer Maître devait exécuter un redémarrage complet. L’opération prenait 6 mn.
retour