3. 2 Interface d’exploitation de la base de données

moins un bloc soit associé à celle-ci, ce qui est pourtant contraint par le style. Là encore, le but est de donner de la flexibilité de développement : un utilisateur peut créer une IHM vide, et lui associer des blocs ultérieurement. Toutefois, l’outil doit garantir qu’au moment de la génération du code d’une IHMs, celle-ci représente l’état d’au moins un bloc (géré au niveau de l’interface d’exploitation, cf. section VI.3.2.1).

Figure VI. 10 : Interface principale

Cette partie de l’application implémente les contraintes formalisées par le style GTPM concernant les attributs associés aux blocs lors de leur création :

- le nom de responsable : l’application accède une base de données des ressources humaines pour vérifier que le nom choisi est existant. En outre, lorsque le nom de responsable associé à tous les équipements supervisés par le bloc en question est identique, elle impose que ce nom de responsable soit associé au bloc lui-même ; - le numéro de bâtiment : l’application accède à une base de données du

patrimoine pour vérifier que le numéro choisi est existant. Lorsque le numéro de bâtiment associé à tous les équipements supervisés par le bloc est identique, elle impose que ce numéro soit associé au bloc lui-même ;

- la catégorie : l’application accède à la base de configuration du système de supervision pour vérifier que les système/sous-système choisis sont existants.

Lorsque la catégorie associée à tous les équipements supervisés par le bloc est identique, elle impose que cette catégorie soit associée au bloc lui-même.

Par ailleurs la procédure d’exportation du code des IHMs en format XML (requête sur différentes tables et présentation du résultat de celle-ci en format XML) vérifie que ces IHMs affichent bien l’état d’au moins un bloc, et que tout les blocs représentent bien l’état d’au moins un équipement.

VI. 3. 2. 2 Gestion des équipements

L’interface d’exploitation de la base de données comporte un paquetage dédié à la gestion des équipements et des types d’équipements. Lorsqu’un bloc ou un type de bloc a été crée par un utilisateur via l’interface principale, celle-ci propose l’appel des procédures permettant respectivement l’association d’équipements ou de types d’équipements. L’utilisateur peut alors choisir d’associer au bloc/type de bloc un équipement/type d’équipement déjà existant dans la base de données SEAM, ou au contraire d’en crée un nouveau. La capture d’écran suivante (figure VI.11) représente la liste des types d’équipements associés au type de bloc « BlocTypeDemo » :

Figure VI. 11 : Association de types d’équipements

Ce paquetage possède en outre des procédures permettant l’accès et l’utilisation d’informations présentes dans des bases de données extérieures à SEAM, notamment la base de configuration et celle de GMAO (Gestion de Maintenance Assistée par Ordinateur) qui contient tous les équipements maintenus dans les processus à superviser.

Comme expliqué précédemment, après avoir crée un bloc, l’utilisateur peut spécifier les équipements que celui-ci doit superviser de deux manières différentes :

- il s’agit d’équipements existants dans la base de configuration : l’application permet de chercher et sélectionner les équipements de la base de données de configuration, et de les référencer dans celle de SEAM. Si l’utilisateur veut obtenir plus d’information (sous-équipements, informations sur les opérations de maintenance, état de l’installation, …) sur les équipements concernés, il a la possibilité d’accéder aux données de la base de GMAO ;

- il s’agit d’équipements non existants dans la base de configuration : l’application permet d’effectuer une requête d’intégration de nouvel équipement dans la base de configuration et d’utiliser une référence temporaire dans la base de SEAM. Cette référence sera automatiquement remplacée par la référence définitive quand l’intégration sera terminée.

La figure VI.12 représente un tableau de l’interface indiquant les équipements associés à un bloc « Bloc de demo ». Comme ce bloc est du type « BlocTypeDemo » on retrouve les trois types d’équipements définis figure VI.11 : AirComp1, AirComp2 et Disjoncteur. Les circuits d’air comprimé FDED-00010 et FDED-00014 et les valeurs

qu’ils rendent disponibles aux adresses 44833 et 43719 (références utilisées dans la base configuration) sont associées aux types d’équipements AirComp1 et AirComp2 et à leur type de valeur defautGeneral. Un nouvel équipement EMF007, fournissant trois valeurs, a été crée pour être associé au type d’équipement Disjoncteur. Les références utilisées dans le tableau pour cet équipement sont temporaires, elles seront mises à jour lorsque celui-ci sera intégré dans la base de configuration.

Figure VI. 12 : Association des équipements

Il est à noter que la contrainte du style GTPM spécifiant que les blocs ne doivent être associés qu’à des données dont ils supportent le type, est implémentée à ce niveau de l’interface. L’utilisateur spécifie les types de données supportés lors de la création du type de bloc, et, lorsqu’il crée un bloc suivant ce type de bloc, il ne peut lui associer que des équipements ayant des valeurs de type supporté. Dans l’exemple de la figure précédente, l’application vérifie que les valeurs ayant les références 44833 et 43719 sont bien de type booléen, comme c’est requis par le type de bloc « BlocTypeDemo ».

VI. 3. 2. 3 Gestion des règles

Le paquetage de gestion des règles permet à l’utilisateur de créer des règles génériques (associées aux types de blocs). Lorsque l’utilisateur a défini un type de bloc, l’interface lui propose de spécifier une règle pour chaque état possible (arrêt, opérationnel, avertissement et faute). Cette spécification est effectuée via l’interface d’édition d’équation présentée figure VI.13. Il est à noter que le style formel ne spécifie pas de contraintes concernant le format des règles. L’interface présentée ici a été construite pour fournir des règles respectant le format défini par le moteur d’exécution de règles, qui fait partie du système de contrôle et de supervision du CERN.

Figure VI. 13 : Edition des règles génériques

Ce paquetage possède une procédure affichant les règles génériques spécifiées pour les différents états d’un type de bloc, et permettant d’en ajouter ou supprimer si nécessaire.

Une autre procédure permet d’instancier les règles génériques associées à un type de bloc avec les valeurs correspondant à un bloc suivant ce type. La règle générique présentée figure VI.13 est associée au type de bloc « BlocTypeDemo », et la règle instanciée pour le bloc « Bloc de demo » s’obtient par le remplacement de ses variables par les valeurs associées figure VI.12 :

- AirComp1.defautGeneral est remplacé par la référence 44833 ; - AirComp2.defautGeneral est remplacé par la référence 43719 ; - Disjoncteur.Defaut est remplacé par la référence 900205 ; - Disjoncteur.Mesure est remplacé par la référence 900206 ; - Disjoncteur.ouvertFerme est remplacé par la référence 900207.

Par ailleurs, si des règles génériques ont été définies pour plusieurs états du type de bloc, celles-ci sont concaténées pour ne former qu’une règle par bloc. En effet, le moteur de règles du système de supervision impose le format suivant :

AdresseRésultat = Règle1[valeur renvoyée si Règle1 vraie], Règle2[valeur renvoyée si Règle2 vraie], …, RègleN[valeur renvoyée si RègleN vraie]

Par exemple, deux règles génériques ont été définies pour le type de bloc

« BlocTypeDemo » (une pour l’état « opérationnel » correspondant à la valeur résultante 0, et une pour l’état « faute » correspondant à la valeur résultante 3), la règle instanciée pour le bloc « Bloc de demo » est donc la suivante :

Figure VI. 14 : Génération des règles des blocs

Ainsi, si les valeurs lues aux adresses 44833 et 43719 sont « false », et si la valeur lue à l’adresse 900206 est supérieure ou égale à 17000, la valeur renvoyée à l’adresse 90258 (Result tag) sera 0. Par contre, si l’une des valeurs lues aux adresses 44833, 43719 ou 900205 est « vraie », la valeur renvoyée à l’adresse 90258 sera 3.

VI. 3. 2. 4 Gestion des IHMs

Ce paquetage inclut des procédures permettant de : - créer une nouvelle IHM ;

- modifier ou supprimer une IHM existante ;

- d’associer un bloc à une IHM (en spécifiant les coordonnées du bloc sur l’IHM) ; - de modifier les coordonnées d’un bloc sur une IHM ;

- de rechercher toutes les IHMs contenant un bloc donnée.

La procédure de création d’IHM initialise ses dimensions (largeur et hauteur) avec des valeurs standard afin de respecter la contrainte d’uniformité graphique spécifiée par le style GTPM.

VI. 3. 2. 5 Gestion des dépendances

Le paquetage gérant les dépendances entre les blocs ne comporte que quelques procédures (il n’implémente pas de contrainte du style GTPM). Celles-ci permettent à l’utilisateur de :

- rechercher dans la table GTPBLOCLNK les dépendances existantes pour un bloc donné ;

- créer une nouvelle dépendance entre deux blocs ; - supprimer une dépendance existante.

VI. 3. 2. 6 Gestion de la documentation

Le paquetage gérant la documentation des blocs possède de procédures permettant à l’utilisateur de :

- rechercher dans la table GTPBLOCDOC les liens de documentation associés à un bloc donné ;

- créer un nouveau lien de documentation pour un bloc ; - modifier un lien de documentation ;

- supprimer un lien de documentation existant.