Les moyens de développements

Pour les développeurs qui avaient pratiqué les 9010/9040, les progrès étaient indéniables. Les consoles alphanumériques offraient un embryon d’interface homme-machine et surtout disposaient d’un éditeur de texte ligne à ligne (1) Il sera utilisé pour la saisie du code et des données.
Pour la mise au point des logiciels, GCOS 6 offrait la possibilité de lancer un programme en mode « Mise au point » (DEBUG) ; on pouvait alors positionner des points d’arrêt, et sur un point d’arrêt, dumper les registres et des zones mémoires.
Revers de la médaille, l’exploitation des dumps mémoire requerrait des connaissances systèmes approfondies et un dump complet représentait beaucoup de papier.

Les moyens de tests

En phase d’étude préalable, les tests de qualification de l’application SIRC n’avaient pas fait l’objet d’une réflexion approfondie, tant sur les méthodes que sur les moyens à mettre en œuvre. De ce fait, le projet a été confronté au problème dès la phase de tests unitaires puis en phase d’intégration. Faute d’anticipation, l’équipe de projet aura dû se contenter des outils existants ou développer, dans l’urgence, des outils sommaires.

Les tests unitaires

Les développeurs ne disposaient au départ ni d’une base de données (cf. supra), ni d’une interface graphique (la mise en parallèle des développements et les difficultés liées à la réalisation du logiciel graphique LGIVD), Ils ont dû, dans un premier temps, se contenter, en guise de données, de DATA dans les programmes et, en guise d’IHM, d’utilitaires qui restituaient les résultats. Devant la nécessité de disposer d’une base de données renseignée, l’équipe projet commença à développer des utilitaires pour créer et instancier les tables et fichiers nécessaires pour les mener à bien les tests.  Ces développements qui prendront de l’ampleur au fur et à mesure de l’avancement des tests, seront l’embryon du logiciel final de génération de la base de données des SIRC.

Les tests d’intégration

Pour valider les échanges avec la téléconduite, un CACQ fût installé en plate-forme. Ce CACQ pouvait être alimenté soit par un émulateur de réseau, soit directement par la téléconduite (il avait été rendu destinataire d’un modeste sous-ensemble des téléinformations de la région Normandie-Paris, qui correspondait à la mini-base de données). Cela limita notablement la portée des tests d’intégration pour ce qui concerne les tests à pleine charge et la validation des modèles de calcul de réseau.
Le nombre de postes opérateur de la plate-forme était un autre facteur limitatif ; il ne représentait pas le tiers de l’équipement d’un CIME.
C’est donc un SIRC testé dans des conditions très éloignées de celles d’une exploitation réelle en marche nominale (et encore plus de celles d’incidents réseau) qui fût installé à Nancy, ce qui entraina la découverte tardive de l’ampleur des problèmes de charge UC et de mémoire.

Il est à noter que pour la génération suivante des SCADA, la problématique des recettes sera prise en compte dès la phase d’étude préalable. Une politique de recette sera définie et les moyens d’essais disponibles ou à développer identifiés.

Les particularités logicielles

Les extensions systèmes

Les études de marché et de produits réalisées dans le but de choisir le matériel avaient bien identifié le fait que des développements complémentaires seraient nécessaires d’une part pour disposer de fonctions non disponibles dans GCOS 6 et d’autre part pour obtenir des performances acceptables. C’est donc sous le pilotage serré de l’équipe projet que des prestataires de BULL et de SODETEG TAI réaliseront les développements suivants :

• Le fonctionnement en système doublé (surveillance des machines, gestion des basculements et des échanges entre les calculateurs Maître et Esclave),
•  Plusieurs drivers : liaison inter calculateurs, liaison CACQ-SIRC, liaison avec l’horloge externe,
• Un système de gestion de fichiers en temps réel performant et adapté à la gestion des journaux de bord et des stockages, (il s’agissait en fait d’un jeu de primitives qui permettaient entre autres de gérer des fichiers dit circulaires à un ou 2 niveaux et des lectures/écritures de plusieurs articles/sous-articles à la fois),
• Une gestion de files d’attentes pour l’échange de messages courts entre programmes,
• Le contournement des protections mémoires pour que l’ensemble des applications puissent accéder aux tables  (2) (utilisation détournée de l’exception « reference to unavailable resource »). (complément à faire par PO)

L’optimisation des codes

Alors que de nos jours les giga-octets de mémoire vive et les téraoctets de mémoire de masse garnissent les gondoles des supermarchés, il est difficile d’imaginer qu’à la fin des années 1970, les informaticiens couraient encore après les bits ou les octets. C’est dans cet esprit de pénurie et dans l’objectif de garantir les performances que la conception puis le codage ont été réalisés.

La recherche de performance s’exercera dans 2 directions principales :

•  Minimiser les accès disques : c’est dans ce but qu’ont été créées les tables (cf. supra). Le système de gestion de fichiers spécifique y contribuera également en permettant de lire ou d’écrire plusieurs articles à la fois, ou de ne réécrire que la partie variable d’un fichier (exemple : les seuils pour lesquels le descriptif et l’état courant sont contenus dans un même fichier, mais dont seule la partie état courant est réécrite sur disque après traitement de la récurrence ad hoc). Enfin le nombre de chargements de modules en mémoire a été limité en rendant résidant les modules dont la récurrence est inférieure ou égale à 10 secondes et ceux qui sont les plus fréquemment appelés comme les modules d’acquisition de téléinformations.
• Minimiser la consommation de mémoire : Plutôt que de dimensionner la base de données pour couvrir l’ensemble des besoins des 7 CIME, un astucieux système de dimensionnement variable, ajusté à la taille de chacun des types d’ouvrage du réseau de chaque CIME, a été développé. Au prix d’une certaine complexité, Il va permettre de réduire la taille des fichiers et des tables et donc de minimiser l’encombrement en mémoire vive et sur disque  (3) . L’optimisation du remplissage des fichiers et des tables a également contribué à économiser la mémoire (on s’efforçait d’occuper les 16 bits d’un mot au détriment plus tard de l’évolutivité). L’écriture en assembleur de la plupart des modules résidants complètera ces mesures.

L’installation du SIRC sur le site pilote mit en évidence des problèmes de charge de l’Unité Centrale, et des manques de mémoire vive, ce qui enclencha de nouveaux travaux d’optimisation : réécritures de sous-programmes en assembleur et simplification des codes (ce fut notamment le cas pour LGIVD).
Ultérieurement d’autres travaux d’optimisation furent nécessaires, en particulier lorsque l’on constata  que le SIRC s’effondrait en cas d’incident réseau.

Le logiciel LGIVD

Le langage graphique a souffert de quelques maladies de jeunesse : outre la correction de bugs divers et variés, il a nécessité une optimisation approfondie pour pouvoir animer l’ensemble des PO d’un dispatching, soit en tout une vingtaine d’écrans. Une fois ces difficultés surmontées, il a rendu le service attendu et s’est même révélé efficace dans la construction d’automates de dialogue.

Fin de l’article