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

La radio-téléphonie

La radio-téléphonie, ou plutôt les radiocommunications mobiles au sein d’EDF ont été très vite nécessaires après-guerre, tant pour des besoins des chantiers complexes ( réalisation des grands ouvrages hydrauliques ) que pour les opérations de maintenance lourde en matière de lignes électriques, mais aussi pour réaliser au sein de la direction de la distribution, les manœuvres d’exploitation en pleine nature, notamment en périodes de difficultés météorologiques.

Jusqu’au milieu des années 50

Par suite d’oppositions politiques et administratives, EDF ne peut cependant obtenir l’autorisation de créer des réseaux radio nationaux « privés » ; seules des utilisations exceptionnelles ou expérimentales ont été possibles.

En 1957

L’administration des PTT, accorde à EDF quelques canaux de trafic en alternat : la Direction d’EDF décide d’assurer une couverture radio nationale pour les besoins de la Distribution, mais utilisable par le Transport.

Au fil des années, cette couverture se met en place sous forme de réseaux comportant généralement un relais situé sur un « point haut ». Sa structure va évoluer en permanence en fonction des besoins, de la couverture, de l’attribution de canaux. Les réseaux radio vont progressivement être utilisés comme supports de télécommande, de téléalarme, de recherche de personnes d’astreinte…

Le matériel utilisé, « à tubes » au début, lourd, encombrant, gros consommateur d’énergie devient transistorisé, se miniaturise, s’allège et se fiabilise.

En 1974

Les réseaux comptent 15 000 mobiles et près de 500 relais, mais les besoins sont mal satisfaits, en particulier pour le Transport. L’administration fait pression pour qu’EDF optimise le spectre utilisé. Un nouveau réseau est mis à l’étude, appelé RAMAGE. A numérotation automatique, utilisable par toutes les Directions, il offre de nombreuses possibilités. C’est un réseau cellulaire à localisation automatique, avec voie sémaphore, optimisant l’utilisation du spectre.

Expérimenté en Normandie, au milieu des années 80, son déploiement s’annonce entre 1986 et 1991. Premier réseau « trunk », Ramage connait beaucoup de difficultés qui conduisent à l’arrêt du projet en février 1988, compte tenu de son coût et de son inadaptation aux télécommandes.

Dans les années 90

Le Transport a, sur une partie du territoire, développé un réseau sur des principes similaires, le RRS (Réseau Radio de Sécurité), malgré son coût d’exploitation élevé dû essentiellement aux liaisons fournies par France Telecom.

A partir des années 2000

Les réseaux GSM qui couvrent pratiquement tout le territoire avec une bonne qualité de service rendent les réseaux privés obsolètes. En cas de difficultés particulières, des liaisons satellites restent utilisables

Cette « saga » des réseaux radio à EDF, puis RTE pour le transport d’électricité, fait l’objet du chapitre 9 du livre « Les télécommunications au cœur du système électrique français 1946-2000 » et de suites à rédiger.

Il est intéressant de comprendre les besoins de communication, et les usages qui ont émergés avec le réseau radio-mobile. Ils préfigurent les usages d’aujourd’hui en terme de mobilité ou de nomadisme professionnel, et l’évolution fondamentale des gestes de travail en construction, en maintenance, en contrôle, dans les postes électriques comme sur les lignes du réseau électrique.

Ultérieurement les articles de cette rubrique donneront accès à ces sujets.

 

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

Radio Téléphone- ERA 623 CSF

Vue de face

Description :
Ce poste radiotéléphone portable fabriqué dans les années 70 par Thomson CSF se présente sous une forme d’un ensemble compact comportant un émetteur, un récepteur, un dispositif de réception d’appel sélectif et une batterie 12 volts. Cette présentation modulable, lui permet d’être installé dans un véhicule, la batterie 12 Volts  du véhicule assurant alors son alimentation. Il comprend en face avant les commutateurs permettant la sélection du canal de trafic, la sélection du numéro d’appel du correspondant (81 combinaisons possibles), ainsi que l’arrêt ou le réglage de la puissance du haut parleur. Ces mobiles fonctionnent en simplex, ce qui nécessite une commande d’émission (une « pédale ») associée au micro.
Le poste est destiné à être intégré dans un réseau permettant, à l’intérieur d’une zone à couvrir, d’établir des liaisons bilatérales entre un opérateur situé au siège d’une exploitation et un certain nombre de postes mobiles ou encore entre ces postes eux-mêmes. .La couverture d’une zone est assurée grâce à un ou plusieurs relais situés sur des points hauts judicieusement choisis.. Le fonctionnement général du réseau est le suivant (voir image des types de réseau, cas d’un réseau avec un relais ):

  • Au relais (duplex) tout ce qui est reçu par le récepteur (F1 par exemple) est réémis sur une fréquence différente (F2 ) éloignée de la fréquence de réception de 4,05 MHz afin d’éviter l’éblouissement“ du récepteur par l’émetteur
  • Ces réseaux fonctionnent en alternat et en réseau ouvert, c’est-à-dire que tout utilisateur d’un terminal couvert par un relais peut, s’il le souhaite, écouter tout ce qui est transmis par le relais ou se faire appeler par le siège d’exploitation ou un autre terminal grâce au dispositif d’appel sélectif
  • Le siège d’exploitation peut être doté d’un poste simplex couvert par le relais ou être configuré en duplex, relié au relais par une liaison hertzienne duplex 450 Mhz et à un autocommutateur téléphonique qui permet d’établir et recevoir des appels radio depuis un poste téléphonique abonné.
    Les canaux de trafic situés dans la bande 70/80 MHz sont espacés de 12,5 KHz ; un maximum de 14 canaux a été attribué à EDF par l’administration. La puissance d’émission (modulation de fréquence) est limitée à 10 Watts crête.
    Ces postes compacts, aux composants intégrés avaient une excellente fiabilité, un taux de panne très bas : MTBF de 20 000 heures (Mean Time Before Failure  – temps moyen entre pannes-)

Utilisation :
Dès la fin des années 50, EDF s’est efforcé d’assurer pour ses équipes d’intervention des Centres de distribution, une couverture du territoire national grâce à des réseaux élémentaires indépendants comportant chacun un, voire plusieurs relais. .
Au total près de 500 relais et près de 15000 postes mobiles dont une grande partie de MF 623 CSF ont été utilisés.Il n’existait pas alors de réseau radiotéléphonique public couvrant le territoire national.
Le poste MF 623 a aussi été utilisé dans une présentation et un usage différents par la gendarmerie et par d’autres utilisateurs.

Prêt à l’emploi

Vue arrière

 

 

Téléimprimeur SAGEM TX35

Le téléimprimeur TX 35

Description
Le téléimprimeur ressemble à une grosse machine à écrire avec un clavier, une imprimante, un écran de visualisation, un petit clavier à droite et à gauche du clavier dactylographique ainsi qu’une unité de disque souple. ( Anglais : floppy disk).

Cet appareil permet la transmission de messages écrits entre deux téléimprimeurs mis en communication par un circuit de transmission, établi par un réseau commuté (réseau Telex des PTT ou réseau privé). Le code de transmission est le code CCITT N°2.
L’écran de visualisation et la mémoire électronique centrale permettent un traitement de texte simple qui facilite la préparation des messages et leur envoi.

Caractéristiques techniques
Le TX 35 est équipé d’un micro processeur, d’une mémoire centrale, d’un disque souple (100 000 caractères) , d’une imprimante à aiguilles et d’un écran qui visualise 20 lignes de texte plus 2 lignes de service. Les petits claviers à droite et à gauche du clavier dactylographique servent respectivement à la gestion de l’écran et à la gestion de l’appareil.
Le téléimprimeur utilise le code CCITT N°2 , code à 5 bits qui permet d’envoyer au correspondant 57 signes significatifs (lettres majuscules de l’alphabet, chiffres, ponctuation, espace, interlignes) sur des lignes de 69 caractères. Le terminal utilise des caractères de service (appels, établissement des communications). La rapidité de modulation est de 50 bauds ce qui au final se traduit par un débit maximal de 6,66 caractères par seconde
L’imprimante imprime en noir les messages émis et reçus sur un rouleau de papier de largeur 210 ou 216 mm ; trois types d’écriture permettent de différentier les utilisations : écriture inclinée vers la gauche pour un message préparé localement, inclinée vers la droite pour les messages émis, et droite pour les messages reçus. La réception et l’impression d’un message sont indépendantes de la préparation d’un message au clavier et à l’écran.
Les messages sont préparés à l’aide de l’écran en mémoire centrale. A la fin de la préparation ils sont stockés sur le disque et disparaissent de la mémoire si les données d’acheminement ne sont pas complétées. Si elles le sont les messages restent en mémoire jusqu’à la prise en charge par l’automate d’acheminement. Les messages émis sont effacés de la mémoire. Les messages reçus sont systématiquement archivés sur le disque.

Chaque téléimprimeur a un indicatif qui l’identifie. L’émission d’indicatif est déclenchée par le réseau du côté du demandeur et du demandé lors du début de toute communication et une confirmation de l’indicatif du demandé peut être déclenchée en fin de transmission par le demandeur ; on dispose ainsi sur les messages imprimés côté demandeur et côté demandé de la confirmation de l’identité des correspondants. Une information d’horodatage est transmise par le réseau à la fois vers le demandeur et le demandé. L’authenticité de la transmission est ainsi garantie.
Le TX 35 est mis sur le marché par Sagem à la fin des années 1980

Utilisation
Cet appareil a été utilisé dans un réseau télégraphique privé, dit de commandement, mis en service à EDF en 1968 et desservant les grands services. EDF a abandonné son réseau télégraphique privé à EDF en 1996 alors qu’il était dépassé par les télécopieurs et les nouvelles messageries informatiques interpersonnelles.

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.

architecture du palier C 90-40

L’architecture initiale du système basée sur les CAE C 90 xx  était une architecture doublée.
Toutefois les deux calculateurs, lorsqu’ils existaient – il n’y eu qu’un seul calculateur à Brive jusqu’à la disparition du site et Marseille a fonctionné très longtemps avec un seul calculateur – étaient différents.
S’ils possédaient un certain nombre de périphériques communs (partagés ou identiques) tels que disques rapides, console système, lecteur et perforateur de rubans, accès télécom, système de visualisation, imprimante ligne, centrale de sons d’alarme, le C1 prioritairement réservé au temps réel ne comportait pas de dérouleurs de bandes, pas de lecteur de cartes, pas de table traçante…
Le C2 dit « calculateur scientifique », en dehors des périodes où il servait de secours automatique au C1, était utilisé pour le développement et la mise au point de programmes, pour des travaux statistiques, pour la facturation des clients nationaux (raccordés en haute et très haute tension)…

Insérer schéma config

En fonctionnement temps réel complet à deux calculateurs, le calculateur secours reprenait la main en cas de détection de panne du principal (absence de réarmement d’un watchdog). Lors de cette reprise, un certain nombre d’actions opérateurs pouvaient avoir été perdues, le processus de synchronisation entre les deux calculateurs n’étant globalement effectué que toutes les demi-heures.
Pour des raisons économiques et ou d’opportunité matérielle, il arrivait que les deux calculateurs soient encore plus différents. A Lille, il y avait un 90-10 et un 90-40, ce qui, malgré une certaine compatibilité des machines, amenait à des versions logicielles aménagées. A Paris, le C1 disposait de 32 Kmots de mémoire vive et le C2 uniquement de 24 Kmots. Un certain nombre de données se trouvaient donc à une certaine adresse en mémoire basse (C2) et à une adresse translatée de 16 Kmots – en mémoire haute – (C1). Selon que l’on exécutait le programme sur le C1 ou le C2, un test permettait d’armer ou non l’extension, ce qui permettait de disposer du même code sur les deux machines et d’un espace supplémentaire en mémoire basse (la seule ou l’on pouvait mettre les instructions) pour exécuter des tâches gourmandes en ressources et jugées moins indispensables à l’exploitation du réseau électrique d’alors (calcul de répartition par exemple) sur le C1.

Compte tenu de la durée de vie du système, des détails de l’architecture ont évolué, mais ses principes sont restés les mêmes.

Les évolutions les plus marquantes ont porté sur  :

  •  Le système de visualisation. Les premiers écrans étaient des écrans alphanumériques monochromes permettant d’afficher des listes ou des pseudo-représentations de postes électriques à l’aide de quelques caractères disponibles (*, – etc).

images écrn llille

Paris a disposé assez tôt d’écrans graphiques monochromes à balayage cavalier permettant notamment l’affichage de schémas de postes. Puis l’apparition de consoles semi graphiques couleurs a révolutionné le look du système moyennant de nombreux développements, dans un univers contraint en place et en puissance, pour ajouter les données nécessaires aux nouveaux tracés et aux informations de couleurs.

  • Les communications. Les calculateurs étaient raccordés initialement aux ERC, l’arrivée des CACQ s’est traduite par de nombreuses modifications au niveau des protocoles de communication, mais aussi sur la logique même de traitement. Les ERC émettaient toutes les informations en mode cyclique 10 secondes, le CACQ qui les a remplacés n’envoyait les télésignalisations que sur changements d’états. De plus lors des redémarrages, il fallait désormais effectuer une vérification globale de toutes les signalisations (contrôle général). Les calculateurs temps réel ont également eu à communiquer informatiquement avec le monde des prévisionnistes et des statisticiens, alors que les premières communications se faisaient par listing papier ou par telex (*). D’autant qu’il nous en souvienne ces modifications importantes dans un système vieillissant et contraint furent globalement une réussite sans que cela ne surprenne grand monde….
    (*) Pour envoyer de façon journalière et « automatique » le programme de marche aux centrales thermiques, on générait une bande telex depuis le calculateur scientifique du dispatching, puis ce ruban était envoyé via un telex classique. Comme il n’y avait pas de perforateur de ruban telex sur nos 90 40, on se servait du perforateur de ruban du 90 40. Mais les codes telex étaient à cinq trous et ceux du calculateur à huit trous. Une ingénieuse pièce métallique placé sur le perforateur permettait de caler le ruban telex d’un côté du perforateur et un travail de conversion de code avait permis de d’éditer les codes ordinateur correspondants aux codes telex souhaités.
  • Le remplacement des machines à écrire qui assuraient les logs d’exploitation. Les machines de type ASR furent remplacées par des machines à boule. Bien que ceci apparaisse comme une évolution de bien peu d’importance, elle a donné pas mal de fil à retordre aux développeurs de l’époque. Le pilotage de ces machines était, en effet, effectué directement au niveau du calculateur central. Il a donc fallu pour effectuer les modifications se replonger dans du vrai temps réel avec gestion des interruptions, et des temps d’attente de la frappe des caractères. Le retour chariot ou le changement de couleur du ruban encreur n’ayant pas le même temps de réponse que la frappe d’un simple caractère…