DESCRIPTION DES LOGICIELS

Le CML

Le CML (pour Centre de Maintenance des Logiciels) est le système qui gère les logiciels embarqués sur les différents automates, cartes Bailey et postes de conduite du site. Le CML actuellement en exploitation est le CML unifié (car il regroupe les usines UP2 et UP3).

Mission du CML

Le CML est destiné à gérer les logiciels participant au contrôle-commande des usines UP2 et UP3 de l'établissement COGEMA de la Hague :

• les cartes de régulation Bailey (MZR et MZJ),
• les postes de conduite centralisée Bailey (PCC),
• les automates April de type SMC 600 (SMC),
• les automates April série 1000 (ASM),
• les automates Schneider PREMIUM (TSX),
• l'architecture de conduite.

Il permet de garantir la qualité de la maintenance des logiciels embarqués grâce à la gestion de leur cycle de vie.

Le CML doit répondre à deux attentes contradictoires :

La sécurité et la disponibilité des procédés à court terme : il permet de modifier provisoirement la configuration d'un composant sans passer par les étapes du cycle de vie dans le cas d'interventions urgentes et ponctuelles : c'est l'activité de PATCH.

La maintenance des logiciels à plus long terme : but principal du CML, il permet de travailler de façon rigoureuse (en respectant le cycle de vie du logiciel) et intègre les règles standard de la gestion des logiciels.

Objectifs du CML

Le CML répond à cinq objectifs principaux :

disposer d'outils de supervision permettant de suivre chaque logiciel, avoir un cycle de vie standard : création, test, validation, exploitation, modification puis retour au test etc., maîtriser les changements de phase des logiciels ; les transitions entre chacune étant prédéfinies, vérifier la conformité des logiciels référencés sur le CML avec la version embarquée sur le composant en effectuant des VLE (Vérification des Logiciels Embarqués) régulières et en permettant aussi le déclenchement de VLE unitaires à la demande, disposer d'outils d'aide à la création et à la modification pour améliorer la qualité des interventions à effectuer sur les logiciels lors de leur cycle de vie.

L'objectif du CML est de maîtriser la configuration et la gestion du système ; que ce soit en développement ou en exploitation ; ainsi que de connaître l'état des différents composants du système et leur évolution (historique des modifications).

Cette maîtrise requiert le contrôle des logiciels embarqués de bout en bout de la chaîne de production, la configuration doit être connue à tout instant, ce qui implique des vérifications régulières.

Fonctions du CML

Cette maîtrise implique de centraliser la gestion des configurations ; le CML permet de retrouver n'importe quelle version d'un composant. Il permet aussi de gérer la configuration et le cycle de vie et d'effectuer des VLE. Il comprend aussi différents modules :

• supervision (active, passive ou restreinte) : permet d'effectuer toutes les opérations ayant trait au cycle de vie - création, transition entre phases - (supervision active), les VLE (supervisions active et passive) et toutes les opérations de surveillance comme l'affichage de l'historique ou des détails d'un composant, du suivi des opérations en cours, etc. (pour tous les types de supervision),
• OSCAR : permet de gérer la messagerie des automates SMC : informations et évolutions par le biais d'un système d'acquisition / restitution,
• MAP EDV,
• incohérence bailey,
• Ces deux derniers points seront abordés ci-après.

MAP EDV

MAP EDV (pour cartographie des éléments De Visualisation*) inventorie les variables d'un API (Automate Programmable Industriel) SMC600 pour animation sur un PCC.

But de MAP EDV

Le logiciel doit sortir sur l'écran, ou sur imprimante, la MAP EDV d'un automate SMC selon ce tableau, et pour chaque EDV :

Extrait de la MAP EDV d'un automate SMC 600

Les informations affichées à l'écran sont :

• le nom de l'atelier concerné,
• le nom de l'automate,
• le numéro de l'EDV,
• le type de l'EDV,
• le numéro de la CLIZ*,
• le numéro du concentrateur Bailey relié,
• le numéro de voie sur le concentrateur,
• pour chaque bit de l'EDV et en fonction de son type, le bit de commande, le bit de recopie, le bit de défaut et/ou le commentaire Edilog* tronqué,

Description d'un EDV

Un EDV est une information échangée entre une carte Bailey (ou un automate SMC via une CLIZ). L'EDV divise les informations en deux catégories :

• les BDB ou blocs de base qui sont des grandeurs variables telles des mesures ou des valeurs booléennes,
• les BDR ou blocs de renseignement qui sont des grandeurs modifiables mais constantes en exploitation telles des unités, des seuils ou des échelles. Les deux blocs sont codés sur 16 bits.

Il existe 10 types d'EDV en fonction du type de mesure que l'on désire effectuer. L'automate SMC utilise trois types d'EDV :

• type 8 : logique à trois états, constitué de trois BDB : états de commande, de recopie et d'alarme,
• type 9 : logique à deux états constitués de deux BDB : états de commande et de recopie,
• type 10 : valeur numérique sur un BDB.

MAP EDV d'un SMC

Un automate SMC peut contenir au maximum 4 CLIZ. Chaque CLIZ supporte 16 EDV et dispose de quatre mots pour adresser la table de description de la MAP EDV : adresse du début de la table, 0 si la table est en zone valeur, n° de la 1ère valeur de la table si elle est en zone valeur (sinon 0), statut dans l'octet de poids fort, numéro de voie sur le concentrateur dans l'octet de poids faible, checksum.

Principe de fonctionnement

Un dialogue utilisateur permet tout d'abord d'acquérir le nom de l'automate et de l'atelier. La création de la MAP EDV se déroule alors en trois phases :

phase 1 : on détermine la présence de la CLIZ,
on récupère dans le fichier .CAL l'adresse de la MAP EDV et le numéro de voie sur le concentrateur Bailey.

phase 2 : on extrait pour chaque CLIZ et pour chaque EDV de celle-ci les informations la concernant :

• type EDV,
• bits de commande ,
• bits de recopie ,
• bits de défaut ,
• libellé des bits de commande (extraits du fichier Edilog : .VAR), checksum de la MAP.

phase 3 : mise en forme du tableau et impression.

Incohérence Bailey

But d'Incohérence Bailey

Le module Incohérence Bailey doit effectuer sur l'ensemble du système Bailey3 une détection d'incohérences de différents types :

• vérifier la cohérence des unités, touches et légendes sur les PCC,
• vérifier la cohérence des attributs des EDV à l'aide de leurs codes et légendes,
• vérifier que les EDV déclarés sur les PCC existent bien sur les cartes,
• vérifier que tous les EDV déclarés sur les cartes existent sur les PCC,
• vérifier qu'il n'y a pas d'EDV inutiles.

Ces problèmes ne peuvent pas être résolus dans l'architecture Bailey mais seulement au niveau du CML ; c'est pourquoi ils ont fait l'objet d'un module.

Fonctions d'Incohérence Bailey

Le module Incohérence Bailey doit pouvoir :

• détecter les incohérences : effectuer une recherche systématique des incohérences dans le système Bailey d'un atelier donné,
• rechercher un EDV sur PCC à partir de son code système dans un atelier,
• rechercher un EDV sur PCC à partir de son libellé dans un atelier.

Il doit évidemment garder un historique des incohérences détectées pour permettre le comparer à un précédent fichier d'incohérences.

Retour à l'accueil.