point d’entree provisoire des SI de dispatchings.

Mis en avant

Cet article est provisoire, il est néanmoins important car il permet d’accéder de façon rationnelle aux articles concernant les dispatchings. il est la structure d’aiguillage vers des articles terminés (accès libre) ou en cours d’élaboration (accès avec mot de passe) concernant les dispatchings de transport d’Edf puis de RTE. Continuer la lecture

Télécommande CGCT Système IV

Cet équipement « Système IV » de CGCT (Compagnie Générale de Constructions Téléphoniques) permet la transmission à distance d’informations binaires simples (ordre ou signalisation) entre deux points. Une armoire est disposée à chaque extrémité (Poste de commande -PC- et Poste asservi -PA- ) ; Les informations échangées entre chaque armoire se composent de mots de 4 bits et sont transmises à la vitesse de 50 bits par seconde. La sécurisation est assurée par « contrôle en retour », c’est à dire que le passage à l’étape suivante du processus (sélection du groupe, sélection de l’organe, commande, repos) est conditionnée par un retour d’information identique à l’information émise.

 

Voir le diagramme ci-dessous

Un tableau synoptique coté PC permet le passage des ordres et la visualisation des télésignalisations. Cet équipement permet ainsi l’exploitation d’un poste distant dans les mêmes conditions qu’un poste local et ce, avec une grande fiabilité.

  Description :
L’armoire de télécommande CGCT est équipée de cadres (paniers) comportant des

Bloc de relayage de Système IV de CGCT, .

relais électromécaniques fabriqués en très grande série, du même type type de ceux utilisés alors dans les auto-commutateurs téléphoniques.

Utilisation :
Jusqu’au début des années 1950, des agents sont présents dans tous les postes électriques HT/THT et effectuent les manœuvres nécessaires sur le réseau. A partir du milieu des années 1950, une politique progressive de suppression du personnel de gardiennage dans les petits et moyens postes est mise en place. Ces postes sont surveillés et manœuvrés à distance depuis des sites de postes plus importants à l’aide de systèmes de télécommandes et télésignalisations ou, simplement surveillés par des téléalarmes.
C’est à cette époque que les équipements CGCT Système IV sont devenus une référence pour la téléconduite d’installations distantes tant au Transport qu’à la Distribution. Ils seront progressivement déposés et remplacés dès la fin des années 1980, mais aujourd’hui encore un système de démonstration fonctionne parfaitement.

 

 

 

 

 

 

 

 

Génèse de la spécification HNZ

Connaissez-vous la norme HNZ ?

C’est ainsi qu’on appelle la norme, ou plutôt le groupe de normes HNZ 66-S-11 et suivantes, qui a vu le jour à EDF dans la fin des années 70 pour répondre au besoin d’interopérabilité des premiers systèmes informatisés alors en germe pour la téléconduite des réseaux électriques. Après une première version parue en 1978, la version publiée en 1982 est utilisée aujourd’hui encore sur de nombreux équipements de téléconduite.

Continuer la lecture

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

Architecture et matériels des SRC

L’architecture

Les différents serveurs sont implantés sur un réseau local doublé scindé en deux parties :

  • La partie située en zone de sécurité renforcée abrite :
  1. Les serveurs principaux, doublés,
  2. Le système de configuration des données,
  3. Des serveurs annexes ,
  4. La station d’administration,
  5. Les postes de travail situés dans l’enceinte du dispatching,
  6. Des imprimantes.
  • La partie située en zone de sécurité standard abrite :
  1.  Les autres postes de travail,
  2.  Des imprimantes.

Les 2 serveurs principaux sont reliés entre eux par une liaison à grande vitesse utilisée pour la synchronisation des machines. Ils sont reliés au réseau local ARTERE, sur lequel sont implantées les Stations Réseaux et par lesquelles vont transiter les flux de téléconduite.

 

Le SRC est relié au reste du monde (réseau de gestion Artère, RLAC(1)) par le biais de deux coupe-feu qui fonctionnent en redondance active.

Trois serveurs annexes abritent les fonctions avancées fournies par RTE/DMA, à savoir :

  •  Calculs de réseau temps réel (la chaîne cyclique),
  •  Calculs de réseau en mode étude,
  •  Réglage de la tension (pour Nantes uniquement).

Les matériels et logiciels

  •  Serveurs principaux : HP ITANIUM RX2600 bi-pro, 16 GB de mémoire, OS HP UX 11,
  •  Autres serveurs : HP ITANIUM RX 1600, 3 GB de mémoire, OS HP UX 11,
  •  Postes de travail : PC HP sous Windows,
  •  Station d’administration : PC HP sous Windows et produit d’administration TNG,
  •  Système de configuration basé sur ORACLE.

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

(1) Réseau local d’aide à la conduite ; il abrite des applications dont certaines utilisent des données élaborées par le SRC.

Retour

Ce qui a plus ou moins bien marché dans le projet SRC

Ce qui a bien marché :

  •    L’organisation à RTE avec un projet national et un projet par région chargé de piloter le peuplement de la base de données, l’aménagement des locaux, la formation des dispatcheurs et la migration.
 
  •    La gestion des relations avec le fournisseur qui a été poussée à un haut niveau de formalisation et de mémorisation, condition sine qua non pour ne pas être asphyxié par le volume d’informations. Les échanges de toute nature (fiche d’anomalie, fiche de demande d’évolution, fiches questions/réponses, fournitures documentaires, PV, etc.) ont été gérés en configuration. Un gestionnaire de faits technique (1) , partagé avec le fournisseur, même été mis en place. Il ne sera pas de trop pour gérer les 7500 anomalies découvertes de 2003 à 2009. De plus, pendant les phases difficiles, les relations courantes entre les chefs de projet respectifs ont été complétées par des relations entre leurs managements respectifs et entre les directions de RTE et THALES.
  •     La gestion des données d’une façon générale :
  1. Le système de configuration, malgré un retard à la livraison, a donné satisfaction par la suite,
  2. Le volume de travail représenté par le peuplement initial de la base de données a été maîtrisé : la majeure partie des données alphanumériques du SIRC a pu être importée et le travail de constitution de l’imagerie a été réduit grâce à la génération automatique des images de poste et de cellule.
  • le formalisme du cahier des charges s’est révélé extrêmement efficace. La numérotation initiale de 10 en 10 a permis de gérer sans problème les adjonctions. La couverture des recettes en a été améliorée (lien tests-exigences). D’une façon générale la gestion des modifications en a été facilitée, ce qui a permis de tenir à jour le cahier des charges tout au long du projet et de le conserver en tant que référence contractuelle. On peut toutefois s’interroger sur le niveau de détail du dit cahier des charges, il a été un plus pour obtenir les fonctionnalités souhaitées, mais il a été consommateur en ressources RTE pour sa création et son suivi.
  • Les moyens d’essai fournis par RTE :
 
  1. L’utilisation du Simulateur d’entrainement des dispatcheurs (SIDERAL) en tant que simulateur de réseau électrique a permis de valider efficacement la fonction télécommande si bien qu’il n’y aura pas de mauvaises surprises sur site.
  2. La mise au point de la connexion à ARTERE, identifiée au départ comme un point délicat a été conduite sans difficulté grâce aux émulateurs fournis (EMC, EMA)(2) et à l’utilisation du réseau d’essai ARTERE pour les tests d’interfonctionnement.
  • La formation des dispatcheurs avec là encore l’utilisation du simulateur d’entrainement des dispatchers(SIDERAL) pour simuler le comportement du réseau électrique.

Ce qui a moins bien marché :

  • La réalisation du SCADA proprement dit. Le nombre très élevé d’anomalies laisse à penser que le fournisseur a préféré  présenter en recette des versions insuffisamment validées, plutôt que de risquer des pénalités pour retards. De plus le contrat ne prévoyait pas de tests d’endurance en usine (ils ont été ultérieurement ajoutés par voie d’avenant). Autant THALES parviendra à corriger rapidement les anomalies fonctionnelles, autant les anomalies liées à la conception du système seront particulièrement difficiles à corriger. Bien souvent, il sera nécessaire de mettre en place une instrumentation spécifique pour relever des traces et avancer dans l’analyse. Les problèmes les plus marquants ont été les suivants :
 
  1. Les performances,
  2. La robustesse,
  3. Des cas de désynchronisation du maître et de l’esclave,
  4. Des fuites mémoires (3),
  5. Des retards à l’affichage d’alarmes, des figeages d’écran,
  6. Des pertes de données opérateur lors de la mise en service d’une nouvelle base de données.

A l’exception des aspects performance et robustesse, tous ces problèmes ont été rencontrés sur le site pilote, ce qui montre que l’environnement de tests et la composition des plates-formes de tests n’étaient pas suffisamment représentatifs d’un site.

  • L’intégration des fonctions avancées dans les matériels de fournisseur. Là aussi, la découverte de nombreuses anomalies liées à la conception du système perturberont le déroulement de cette étape :
  1. Récurrence irrégulière ou arrêt intempestif de la chaîne cyclique,
  2. Mauvaise remontée dans le SRC des alarmes élaborées par la chaîne cyclique,
  3. Etc.
  • Le travail de paramétrage dans la base SRC et dans les bases propres aux calculs de réseau aura d’une façon générale été sous-estimé. Il sera amplifié par un changement des règles de nommage des ouvrages dans le SRC.

 

(1) Logiciel de suivi de problèmes permettant de suivre l’avancement de la résolution de ces problèmes. C’est CLEARQUEST qui a été utilisé sur le SRC.

Retour

 

(2) EMC : émulateur Casoar, EMA Emulateur ARTERE.

Retour

 

[3] Les process censés rendre la mémoire après utilisation ne le font pas, ce qui provoque au bout d’un certain temps de fonctionnement un épuisement de la mémoire disponible et une dégradation des performances par l’abus de swap.

Retour

Le passage du SIRC de mini 6 à DPS6 ou le paradoxe de la puissance et du temps de réponse.

Le contexte

La version mini 6 des SIRC s’avéra rapidement trop limitée en matière de puissance CPU (Même la charge de base était bien trop élevée) et en capacité mémoire vive. L’annonce de l’arrivée sur le marché du DPS6 qui permettait de desserrer une partie des contraintes mémoire et qui offrait une puissance de calcul deux fois supérieure, tout en assurant une compatibilité logicielle préservant les investissements logiciels a été vue comme providentielle.

Continuer la lecture

Le pupitre du C 90-40 et la façon de s’en servir…

Le pupitre du C 90-40  se présentait de la façon suivante :

Le démarrage du calculateur

 Le pupitre permettait la mise sous tension du calculateur par le bouton Marche

 

 Puis, il offrait le choix du périphérique d’amorçage (Bande, ruban, disque ou cartes) à l’aide de deux clés à deux positions et à retour à zéro automatique. Et c’était parti…

La mise au point de programmes

Lors de la mise au point on insérait dans le programme des instructions « HLT » qui figeaient le calculateur lorsqu’elles étaient exécutées. Cela était signalé au pupitre par l’allumage de la lampe éponyme

 
 Un coup d’œil au P counter (qui donnait l’emplacement mémoire en cours – 14 bits de droite –  et l’état de l’extension mémoire – deux bits de gauche – ). permettait de savoir moyennant un rapide calcul en octal la halte sur laquelle on était  
Le 90-40 étant sur iddle, on pouvait visualiser et modifier les registres et la mémoire à l’aide de la zone registres. La molette située à droite de la zone permettait la sélection du registre :
A et B accumulateur principal et extension
X index
C instruction en cours de décodage
Le contenu du registre était indiqué par des lampes vertes allumées (1) ou éteintes (0).
On pouvait modifier le contenu du registre affiché à l’aide des petits boutons bleus situés en dessous des lampes de visualisation. Le 25 ème bouton situé complètement à gauche permettait de remettre le registre à zéro.
Pour visualiser la mémoire, cela était un peu plus compliqué.
On positionnait la molette sur le registre C. On entrait l’instruction branchement inconditionnel (BRU de code 01) vers l’adresse souhaitée. Dans l’exemple ci-dessous nous avons pris l’adresse octale 022567  ce qui donne, comme il n’y a ni indexation, ni indirection, pour  la valeur du registre C:  00122567.

A l’aide de la clé « run-iddle-step » on faisait alors un pas (step). On pouvait alors vérifier dans le P counter que l’adresse désirée était bien atteinte et voir dans C le contenu de la mémoire désirée.
Le contenu de la mémoire 022567 est 00000007.

Pour modifier le contenu de la mémoire cela était encore un peu plus compliqué.
Toujours à l’aide de la molette, on affiche la registre A et on l’initialise à la valeur souhaitée pour la mémoire, puis on passe sur le registre C dans lequel on rentre l’instruction store A (STA code octal 35 ) qui permet de ranger le contenu du registre A à l’adresse indiquée dans le champ adresse. Puis on fait un pas (STEP) avec la clé « run – iddle – step ». le calculateur exécute alors l’instruction contenue dans le registre C et range à l’adresse mémoire souhaitée le contenu qui avait été rentré dans le registre A.

Et pour faire un patch mémoire…

Vous avez tous les ingrédients, il ne reste que la méthode.
Tout d’abord, dans le programme que l’on souhaite patcher,  il faut:
• Choisir à quel endroit du programme se fera le débranchement vers le patch.
• Noter l’instruction complète (opcode, adresse, index, indirection, extension mémoire…) qui figure à l’endroit où l’on va se débrancher.
• Trouver la première adresse mémoire disponible en fin de programme et la noter.
• Préparer sur papier, sauf à être très doué et chanceux, les codes de la séquence d’instructions à ajouter. Ne pas oublier que la première instruction doit être celle qui occupait la place où l’on mettra le débranchement et que la dernière doit être un retour vers le programme initial à l’endroit le plus judicieux. Il faut connaître l’adresse de départ du patch (notée soigneusement dans un point précédent) pour pouvoir éventuellement calculer les adresses de sauts dans le patch ou de mémoire auxiliaire de travail.
• Entrer la séquence précédente en mémoire selon le mode d’emploi vu plus haut, ce qui nécessite un certain temps et une certaine dextérité.
• Ecraser l’instruction à l’adresse choisie pour le point de débranchement par un branchement inconditionnel au début du patch (BRU  code 01)
• Tester le programme modifié.
• Si le patch a fonctionné, perforer le nouveau ruban (exécutable du programme) et, bien entendu, mettre à jour le paquet de cartes correspondant (source du programme).

En rédigeant cet article et, en feuilletant de la documentation de l’époque, j’ai été surpris de constater que je me souvenais encore des codes des instructions les plus utilisées, par contre je ne me souviens plus par cœur des tables d’addition en octal, l’âge, peut-être?

 

Pour ceux que le début de cet article n’a pas encore rebuté, ou pour les nostalgiques du 90-40, nous poursuivrons avec la suite de l’examen du pupitre.

La zone Canal

A l’aide de la molette à 8 positions située à gauche, on sélectionnait le périphérique souhaité dont on avait l’adresse sur les lampes de droite et un indicateur d’erreur.

l’overflow

L’indicateur indiquait l’occurrence d’un dépassement de capacité lors d’une opération arithmétique.

Les interruptions

L’indicateur indiquait si les interruptions étaient désactivées et la clé associée permettait d’inverser la situation.

La parité mémoire

L’indicateur indiquait la détection d’une erreur de parité en mémoire. La clé située en dessous permettait de lancer la poursuite du programme (non sans risque puisqu’une instruction ou une donnée utilisée avait été corrompue.).

Vous êtes arrivés à la fin, bravo ! Vous êtes probablement devenus, à cette occasion, un vrai pro du 90-40 mais, c’est bien dommage, il n’en existe plus….

Quelques anecdotes sur le développement du logiciel sur 90-40

Les cartes perforées.

Qui n’a pas connu, dans les années 70, les affres d’un paquet renversé lors des manipulations. Cartes qu’il fallait alors re-trier à l’aide du dernier listing disponible.

Ceci est une carte perforée. Chaque colonne porteuse de plusieurs perforations, est porteuse d’un code de caractère. Souvent les cartes comportaient en première ligne, en haut de la carte, l’impression du caractère correspondant à la colonne. Ce n’est pas le cas ici, remettre la carte au bon endroit passe de la gageure à l’exploit!

Cependant, pour gagner du temps et économiser du papier, il arrivait pour des modifications supposées simples de ne pas éditer de listing à chaque passage.

La remise en ordre du paquet devenait alors plus problématique…

De plus le risque de mauvaise manipulation n’était pas si rare que cela, car la capacité du bac du lecteur de cartes était plus faible que la taille des paquets des programmes. Le désir d’aller vite de l’analyste et le côté facétieux des paquets de cartes, toujours prompts à se répandre sur le support où on les avait délicatement posés ou l’intervention supposée de Trolls , pouvait mener à de fastidieux exercices de tri.

Paris 1974 : Exercice de frappe sur perfo-vérif. Au deuxième plan on voit le calculateur C2 (scientifique) avec son pupitre ses dérouleurs de bandes et le lecteur perfo de ruban papier. On remarquera, en partie caché derrière la poignée de la porte, le lecteur de cartes initial. Les Trolls ne sont pas visibles.

Pour éviter ce type de travail trop fastidieux, chacun avait sa (ou ses) méthode(s).

  • Numéroter les cartes, en prenant soin de ménager des trous dans la numérotation, pour les adjonctions futures (exemple numéroter de 10 en10 au départ), ce qui ralentissait la saisie puisque les numéros étaient attribués et tapés « à la main » et qui s’oubliait au fur et à mesure que l’on s’éloignait du dernier incident.
  • Barrer, sur la tranche, le paquet de cartes d’un trait de feutre oblique, ce qui permettait en cas d’accident de faire un premier classement grossier limitant les recherches pour interclassement à un nombre de cartes plus réduit.
  • Passer les cartes par petits paquets en les entourant d’un élastique…

Au-delà des maladresses de manipulations des cartes, le lecteur de cartes jouait aussi son rôle de trouble-fête. Alors que les derniers lecteurs étaient relativement fiables grâce à des systèmes de soufflerie pour décoller les cartes les unes des autres en entrée et un système d’aspiration pour les présenter au système de lecture, les premiers lecteurs étaient entièrement mécaniques. Une lame, de l’épaisseur d’une carte, dotée d’un mouvement alternatif poussait, dans un fracas important et des vibrations impressionnantes, la carte dans une fente calibrée pour laisser passer une carte mais pas deux. Un spécialiste réglait régulièrement cette épaisseur. Mais, les cartes perforées, sensibles à l’humidité ou à une certaine détérioration après plusieurs passages pouvaient dépasser l’épaisseur requise… Il s’en suivait un bourrage nécessitant de retaper les cartes détériorées et de reprendre à zéro le processus de lecture, après appel de la maintenance, heureusement sur place, pour recaler la hauteur de la fente.

A l’inverse la lecture simultanée de deux cartes « minces » donnait des résultats plus divers (erreur du lecteur, ligne de programme correspondant à la superposition de trous des deux cartes totalement aléatoire, non significative et générant une erreur à la compilation ou à l’assemblage…).

Une autre facétie de ce lecteur, plus subtile, m’avait fait perdre un temps non négligeable. Le chariot de réception des cartes en sortie du lecteur a eu un point dur, ce qui fait qu’au lieu de descendre régulièrement à l’arrivée de chaque carte supplémentaire il était resté légèrement bloqué un temps limité qui avait suffi à ce que les cartes se mélangent après le passage dans le lecteur. Le phénomène ayant eu lieu après lecture des cartes, le programme produit a fonctionné correctement. Suite à une demande du dispatching lors de la présentation du logiciel, je dus faire une modification mineure de changement de la logique de l’affichage d’un symbole. La modification effectuée rapidement, j’ai relancé la chaîne de production de l’exécutable et ai constaté avec surprise que le programme ne fonctionnait plus correctement. J’ai donc effectué une relecture fouillée du code nouveau et n’ai rien trouvé d’anormal. Je suis donc passé à la mise en place de traces autour de la modification sans aucun résultat. Ne comprenant plus pourquoi cela ne fonctionnait plus j’ai repris le processus habituel de débogage de l’ensemble du code et me suis donc aperçu de la présence de cartes permutées. Avec l’aide de la maintenance locale le problème a enfin pu être identifié et réparé. Mais, en sachant, que le processus de production d’un programme prenait environ une heure à chaque passage, il est aisé de comprendre comment un simple point dur a pu faire perdre plus d’une journée pour une modification simpliste.

Le ruban perforé.

A la fin de chaque assemblage ou compilation on sortait un ruban perforé représentant le module objet correspondant à la source traitée. Puis on rentrait dans le lecteur les différents modules objets et la table des symboles dont on souhaitait faire l’édition de lien et on produisait un exécutable dont on perforait l’image.

L’image n’est pas d’un dispatching, mais elle conforte le fait que nous n’étions pas les seuls à avoir des problèmes à gérer le ruban papier!

Malgré l’expérience, deux perturbations majeures pouvait affecter le développeur.

  • La mauvaise (ou l’absence d’) estimation de la longueur restante de ruban. En général, et en application des lois de Murphy,  c’est quelques secondes avant la fin de la perforation souhaitée que le ruban s’avérait trop court, obligeant à reprendre le processus depuis le début….
  • Le déchirement. Une fois le ruban entièrement perforé, celui-ci gisait sur le sol. Il fallait le récupérer, le placer sur un enrouleur, afin de pouvoir le ranger soigneusement ou de pouvoir le réutiliser dans la suite du processus. Lors de la phase d’enroulement, il arrivait que le ruban se tournant sur lui-même fasse un nœud et se déchire en arrivant sur l’enrouleur. Plus fréquent encore était le pied du développeur posé malencontreusement sur le ruban qui se vengeait en cassant. Deux écoles pour y remédier : recommencer la production du ruban abimé ou se lancer dans un recollage du ruban et la reconstitution des perforations abimées par la déchirure à l’aide d’un appareil  rustique ad hoc.

Le développement du logiciel sur C 90-40

Le développement initial

Nous n’avons pas retrouvé suffisamment d’informations sur les développements initiaux pour compléter les informations de l’article principal, aussi nous focaliserons nous sur les développements complémentaires qui ont émaillé toute la longue vie des C 90-40.

Il est à noter qu’en dehors du développement de modèles de calcul de réseau effectué par la Direction des Etudes et Recherches, les autres développements ont été effectués par les équipes régionales avec très ponctuellement un soutien externe de CII.

Les développements ultérieurs

Le besoin

Les besoins étaient issus des exploitants du système électrique ou de la partie informatique. Dans les deux cas le besoin pouvait présenter un caractère local, mutuel ou national. Dans tous les cas, une information mutuelle et réciproque était mise en place et permettait le partage des bonnes pratiques et des bonnes idées.

L’analyse

Une fois le besoin globalement exprimé, venait une phase d’analyse qui au-delà de la simple analyse du logiciel concerné, comportait un volet important sur l’impact sur les ressources mémoire vive (place, cartographie mémoire), ressources disque (place, cartographie disque), sur les ressources CPU. Compte tenu de l’optimisation poussée des ressources, l’ajout d’un simple marqueur tenant sur un bit, pouvait amener à des chamboulements des implantations, voire à une reprise globale de la cartographie disque ou mémoire, ce qui était toujours une opération très risquée, car elle impactait tous les sources des programmes, mais aussi éventuellement les performances en jouant sur les temps d’accès au disque.

Pour les programmes au cœur du système comme le scheduler, l’optimisation allait jusqu’à comparer le nombre global de temps de cycles machine de séquences réalisant le même objectif, mais avec des codages différents.

Le codage

Quasiment toutes les tâches tournant en temps réel étaient écrites en assembleur. Les autres, de moindre récurrence, étaient écrites en Fortran II temps réel, qui permettait d’inclure des séquences d’instructions assembleur. Il nous souvient que les temps globaux (analyse, codage, tests, intégration) pour la production d’un programme en assembleur étaient de l’ordre de 15% supérieurs à ceux de la production en Fortran. Par contre la maintenance évolutive ultérieure était beaucoup plus laborieuse en assembleur qu’en Fortran.

La production

Saisie
Après écriture sur papier du code, la saisie, que ce soit en assembleur ou en Fortran, se traduisait par la perforation sur cartes, à raison d’une ligne de code par carte, sur un perforateur de cartes disposant d’un clavier de type machine à écrire, et sans aucun écran.. La perforation se faisant en direct, toute faute de frappe signifiait une nouvelle frappe complète de la carte, ce qui amenait à être méticuleux dans la préparation et la frappe.

A chaque programme ou sous programme correspondait un paquet de cartes qui était la référence de base pour les modifications ultérieures et qu’il fallait donc conserver dans son intégrité. (Quelques anecdotes sur le développement du logiciel )

Assemblage ou compilation
Une fois la saisie terminée, les cartes étaient placées dans le lecteur perforateur et une commande depuis la console système (une télétype de type KSR, petite merveille de mécanique et de tringlerie puis de type ASR) lançait la lecture des cartes puis l’assemblage ou la compilation. Il en sortait un ruban binaire dont l’adresse d’implantation pouvait être fixe ou translatable. Si le programme comportait des sous-programmes, l’opération devait être répétée à l’identique pour chacun d’eux.

Pour un logiciel écrit en FORTRAN, le mode opératoire était légèrement différent de celui utilisé pour l’assembleur. Comme le compilateur FORTRAN ne tenait pas en mémoire, le dérouleur de bande était utilisé comme mémoire auxiliaire et la compilation s’effectuait en plusieurs passes.

Comme dans les temps actuels, assembleur et compilateur détectaient les erreurs de syntaxe, mais de façon beaucoup moins performante.

Edition de liens
Une autre commande lançait l’édition de liens ; il fallait alors lire les différents rubans obtenus dans l’étape précédente ainsi que la table des symboles qui permettait de faire le lien entre les références externes du programme (routines système, adresses physiques des données résidentes en mémoire, adresses des fichiers, etc). L’édition de lien se terminait par la production de l’exécutable sur un ruban perforé à partir d’un lecteur perforateur de ruban. Une fois la perforation terminée, le rouleau obtenu qui pouvait atteindre une taille importante, devait être remonté sur le lecteur perforateur. Une dernière commande lançait la lecture du ruban perforé et l’installation de l’exécutable sur disque. La lecture du ruban perforé s’accompagnait d’un contrôle de parité. Il suffisait alors d’une seule erreur de perforation pour que l’opération échoue. Dans ce cas, le ruban partait à la poubelle et il fallait recommencer.

La mise au point
La mise au point était laborieuse en l’absence d’outils de débogage et de plateforme de tests.
La procédure consistait à d’abord à lancer le programme dans un environnement figé sur le calculateur scientifique, puis une fois les limites de cette méthode atteinte, de passer, après avoir obtenu l’accord du dispatching, sur la machine fonctionnant en temps réel tout en gardant celle utilisée en secours avec la version ancienne, au cas où…
En cas de problème, dans les deux cas cités ci-dessus, le mode opératoire consistait tout d’abord à ajouter des traces (impression papier ou écriture dans un espace mémoire dédié à cet effet). L’ajout de traces pouvant modifier le fonctionnement du programme (décaler un écrasement en mémoire par exemple et le rendre non détectable), la deuxième méthode consistait à insérer dans le programme des instructions « HLT » (halte). Le calculateur s’arrêtait. On pouvait alors, en actionnant une clé, faire fonctionner le calculateur en pas à pas et consulter au pupitre les registres de calcul matérialisés par 24 lampes (parmi les registres on pouvait visualiser selon la position d’une molette, le registre C contenant l’instruction en cours de décodage, les registres A (accumulateur principal), B (extension de l’accumulateur), X (registre d’index), P (compteur qui indiquait l’emplacement mémoire de l’instruction en cours)).

A l’aide de l’accessibilité à ces registres on pouvait visualiser des zones mémoire, faire des patches en mémoire (en savoir plus). Cette méthode amenait les ingénieurs qui maîtrisaient cette technique à connaître par cœur les codes (en octal ) des instructions les plus courantes et à savoir effectuer avec une certaine dextérité les opérations courantes en base huit pour recalculer les emplacements mémoire visés.

Pendant tout ce temps les dispatcheurs devaient se contenter du synoptique, des enregistreurs et du téléphone….

Maigre consolation, les dumps mémoire étaient de taille raisonnable et relativement facile à décrypter en l’absence de structures systèmes complexes.