Les résultats à obtenir étaient très simples : MAP EDV devait se comporter comme défini dans le cahier des charges élaboré lors de sa création.
Il devait donc pouvoir extraire et afficher les libellés des bits de commande, imprimer une MAP EDV calculée et afficher les checksums.
Différentes améliorations étaient également possibles, comme, par exemple, l'abandon du fichier ‹ID_COMPOSANT›.VAR au profit du fichier ‹ID_COMPOSANT›.MNEMO car le fichier VAR était un reliquat de l'ancien système Edilog utilisé sur le site.
Pour parvenir à ce résultat, les sources de la version précédente de MAP EDV (Version intégrée au CML 2.0) étaient à disposition ; il n'était donc -a priori- pas nécessaire de repartir à zéro.
L'étude a été découpée en trois axes principaux : l'impression, les libellés, les améliorations diverses.
L'impression et les libellés étant les parties les plus importantes car quasiment indispensables au bon fonctionnement du logiciel, ou en tout cas indispensables à son exploitation correcte.
Les améliorations diverses sont, entre autres : la modification des pieds de page (mise à jour , suppression ou ajout d' informations), l'affichage des checksums, l'élargissement des libellés, etc.
Le travail a été principalement un debuggage de l'application déjà existante avant de commencer la mise à jour à proprement parler et les améliorations.
3.1) Le debuggage
Le travail a donc commencé par le debuggage de l'application existante.
Le planning prévoyait environ deux semaines pour étudier le programme existant et régler ses problèmes.
La démarche suivie était de remonter du résultat final (l'impression de la MAP EDV) vers le détail, soit les étapes suivantes : imprimer quelque chose, imprimer une MAP EDV prédéterminée (précalculée), calculer la MAP EDV à imprimer, calculer la MAP EDV et charger les checksums, puis imprimer le résultat.
3.2) Les améliorations
Une fois le debuggage terminé, des améliorations pouvaient êtres apportées.
Ces améliorations représentaient environ deux semaines sur le planning et étaient déterminées avec l'avis d'un automaticien travaillant sur les MAP EDV depuis leur conception (les MAP EDV des automates, et non le logiciel « MAP EDV »).
3.3) La documentation technique
Enfin, la dernière tâche à effectuer sur MAP EDV était la documentation technique : celle-ci avait été écrite en 1990 lors de la conception du logiciel et n'existait que sous forme papier.
Il fallait donc la corriger pour faire apparaître les corrections et changements du logiciel et aussi pour disposer d'une version électronique pour d'éventuelles modifications ultérieures.
3.4) Chronogramme
Cet extrait du planning retrace les étapes du travail sur MAP EDV : étude et debuggage du logiciel existant, mise en place des améliorations, test et écriture de la documentation technique.
4.1) Correction de l'existant
Le logiciel a été corrigé suivant le cahier des charges, soit : une MAP EDV peut être imprimée, les libellés apparaissent sur la MAP EDV.
De plus, certains bugs qui n'avaient pas été découverts auparavant ont été résolus : le logiciel est maintenant capable d'interpréter des adresses directes dans le programme automate (par exemple l'instruction « M24<-V3 » est comprise alors qu'auparavant seules les instructions immédiates de type « M24<-170 » pouvaient l'être), le logiciel vérifie aussi que les coupleurs initialisés soient bien des CLIZ et non d'autres coupleurs n'ayant rien à voir avec le système Bailey. Cela permet d'éviter des plantages dans le cas d'initialisions de type « M24<-V14,M23 » (indexation de la valeur de M24 sur M23, ce qui signifie « M24<-V(14 + M23) »).
4.2) Améliorations apportées
Lors du recodage du chargement des libellés, il a été décidé d'abandonner le fichier VAR Edilog au profit du fichier MNEMO plus récent. Cette modification a apporté quelques problèmes comme la confusion entre nom de variable et bit associé (le logiciel retrouvait parfois « [RT]A240[BZ] » plutôt que « [¶]A240[¶] » pendant la recherche de « A240 ») ; ce problème a été résolu.
Lors des tests d'impression, il a été remarqué que le libellé était parfois (souvent même) tronqué : sur certains ateliers la norme des commentaires n'est pas respectée. D'après cette norme (définie dans le standard UP3 chimie) le libellé ne doit utiliser que les 16 premiers caractères du libellé Edilog. Seulement cette norme date de la mise en service d'UP3 et est donc postérieure à la programmation de la plupart des automates du site, lesquels utilisent les 40 caractères prévus par le constructeur.
Il a donc été décidé d'élargir les tableaux afin de présenter la totalité du libellé.
Voici un extrait d'une MAP EDV avec un tableau de 40 caractères de long. On distingue des libellés à la norme (comme le bit numéro 6 où la description utile utilise 16 caractères [6313 VAL.GH 1054]) et des bits où la description utile ne commence vraiment qu'au vingtième caractère (comme le 9).
Divers bugs d'affichage ont aussi été corrigés, et les pieds de page mis à jour.
Le programme affiche aussi maintenant les checksums de chaque CLIZ : bien que présent dans le cahier des charges original, cet aspect avait été totalement oublié.
Dans le logiciel original, le calcul du checksum était fait, stocké dans une variable puis dans le fichier de résultats ; mais lors du rechargement du fichier, la valeur était rechargée et oubliée. De plus le résultat comparaison entre le checksum calculé et le checksum lu dans le programme automate était stocké dans la variable d'erreur, écrasée par chaque CLIZ suivante et par toutes les opérations affectant cette variable très utilisée. La dernière valeur était également stockée dans le fichier et rechargé dans la variable « rien », et inutilisée.
Le résultat de la comparaison des checksums est maintenant stocké dans une variable dédiée, stockée dans le fichier d'échange et relue pour être affiché dans un tableau récapitulatif (la variable est capable de stocker indépendamment les résultats des 4 checksums). Voici un exemple de ce tableau :
On peut y lire pour chaque CLIZ le checksum calculé et le résultat de la comparaison avec le checksum paramétré dans le programme automate.
4.3) Documentation
La documentation a été mise à jour.
4.4) Conclusion
Le cahier des charges a - a priori - été respecté mais le logiciel n'a pas pu être testé en conditions réelles car tous les outils nécessaires à l'élaboration et l'utilisation du produit final n'étaient pas à disposition : absence de l'outil de création de l'exécutable (avec le compilateur IFDL* par exemple), impossibilité d'utiliser l'outil en condition réelle : la machine n'est pas à disposition, le CML de test ne dispose pas des fichiers automate à jour, seul l'exploitant a accès au système.
Malgré cela la mise en place devrait être facile car les modifications apportées sont très profondes et ne touchent pas à la structure superficielle du programme.
La mise en place devrait se résumer à la copie des fichiers mis à jour et au remplacement de la fonction « main() » de test par celle d'origine, ainsi que la mise à jour de certains fichiers d'en-tête (fichiers « .H »).