3. 1 Base de données

La base de données de l’outil SEAM est une base de données Oracle conçue à l’aide de l’outil Designer. Le schéma complet de cette base est fourni en Annexe 3. Afin de faciliter la description de sa structure, la présente section la découpe en cinq parties correspondant aux paragraphes suivants.

Les principaux symboles utilisés sur les schémas sont les suivants :

- le caractère # indique que le champ devant lequel il se trouve fait partie de la clé primaire de la table ;

- les caractères * ou … indiquent qu’il est obligatoire (*) ou non (…) de spécifier une valeur pour le champ devant lequel il se trouve ;

- l’icône indique que la valeur du champ devant lequel il se trouve est contrainte par une table de domaine ;

- les caractères A ou 789 indiquent le type des valeurs des champs devant lesquels ils se trouvent (A : chaîne de caractères – type Oracle Varchar2 ; 789 : numérique – type Oracle Number) ;

- les liens entre les tables représentent les clés étrangères.

VI. 3. 1. 1 Structure des blocs

La partie centrale de la base de données de SEAM gère les informations des blocs permettant la représentation de l’état d’équipements. Les tables correspondantes, fournissant notamment des données concernant l’aspect graphique des blocs (Cf. figure VI.4) et les équipements qu’ils supervisent (Cf. figure VI.5), sont les suivantes :

• GTPBLOCS : cette table contient les informations élémentaires relatives aux blocs : nom, description, catégorie, salle de contrôle responsable de sa

supervision, personne responsable, position géographique, adresse résultante (adresse où est lue la valeur résultante calculée à partir des états des équipements associés au bloc), type du bloc (Cf. section VI.3.1.2) …;

• GTPBLOCINFOTAGS : cette table contient les informations concernant les valeurs d’informations éventuellement associées aux blocs. Il s’agit de valeurs n’intervenant pas dans le calcul de l’état d’un bloc, mais fournies aux opérateurs des salles de contrôle à titre informatif (ex : mesure de tension, mesure de température). Ces valeurs d’informations correspondent à des propriétés (ou attributs) prédéfinis des objets graphiques du modélisateur GTPM (Cf. section VI.3.3) ;

• GTPPROPERTY : cette table donne la description des propriétés correspondant aux valeurs d’informations. Par exemple, un enregistrement de cette table peut spécifier qu’un bloc représentant l’état d’un système électrique possède une mesure de tension comme valeur d’information ;

• GTPPALETTE : cette table décrit les différents types graphiques que les blocs peuvent avoir. Un type graphique donne des dimensions par défaut et les valeurs d’informations associées (ex : un bloc étant de type graphique « mesure tension » aura les dimensions 200x50 et comportera une valeur d’information indiquant une mesure de tension). Cette table est utilisée pour créer la palette d’objets graphiques du modélisateur GTPM (Cf. section VI.3.3) ;

• GTPGTYPESINFOTAGS : il s’agit de la table d’association entre les propriétés (valeurs d’information) et les objets graphiques de la palette. Un objet graphique peut avoir n propriétés et une propriété peut être associée à n objets graphiques ;

Figure VI. 4 : Informations graphiques des blocs

• GTPEQUIP : cette table contient les informations concernant les équipements intervenant dans l’opération des accélérateurs de particules et pouvant être associés aux (supervisés par les) blocs ;

• GTPBLOCEQUIP : il s’agit de la table d’association entre les blocs et les équipements. Un bloc peut superviser n équipements et un équipement peut être supervisé par n blocs ;

• GTPTAG : cette table contient les informations concertant les valeurs rendues disponibles par les équipements.

Figures VI. 5 : Equipements supervisés

Les champs de la table GTPBLOCS correspondent à une partie des attributs des composants suivant le style StatusBloc du style GTPM. D’autres attributs (ex : polices de caractères) ne sont pas spécifiés explicitement dans la base de données, mais le sont au niveau du modélisateur GTPM (Cf. section VI.3.3.3) en fonction du type d’objet graphique choisi dans la table GTPPALETTE. De plus, les champs GRAPHICTYPELENGTH et GRAPHICTYPEHEIGHT de la table GTPPALETTE fixent les dimensions des blocs utilisables sur les IHMs, ce qui permet de satisfaire la contrainte du style spécifiant que la taille des blocs doit être uniforme.

Le style GTPM distingue trois styles de blocs (StatusBloc, MetaStatus, SystemStatus), mais ce n’est pas le cas de la base de données. La structure de la base spécifie que les blocs ne peuvent superviser que des équipements, et non pas d’autres blocs. Ceci est la caractéristique des StatusBloc. Toutefois les équipements de la table GTPEQUIP peuvent être des « équipements virtuels » correspondant à des blocs précédemment créés. Chaque bloc peut-être vu comme un équipement dont la valeur résultante est supervisée par d’autres blocs. La base de données permet donc la description des trois styles de blocs, et leur distinction est faite par son interface d’exploitation.

Concernant la structure des IHMs spécifiée par le style GTPM, la base de donnée prévoit bien qu’un équipement puisse être supervisé par un nombre quelconque (0..n) de blocs (la clé primaire de la table d’association GTPBLOCEQUIP, étant l’identifiant du bloc combiné à l’identifiant de l’équipement). De même, un bloc peut superviser n équipements, mais la structure de la base n’impose pas qu’au moins un équipement soit associé à celui-ci, ce qui est pourtant contraint par le style. Ceci est laissé possible dans le but de donner de la flexibilité de développement : un utilisateur peut créer dans un premier temps un bloc (avec ses attributs), et lui associer un équipement plus tard.

Toutefois l’outil doit garantir qu’au moment de la génération du code tous les blocs des IHMs soient bien associés à au moins un équipement (géré au niveau de l’interface d’exploitation, cf. section VI.3.2.1).

Le style GTPM énonce une contrainte spécifiant que la salle de contrôle associée à un bloc (champ BLOCCTRLROOMID de ta table GTPBLOCS) doit bien correspondre à une salle de contrôle existante. Cette contrainte est implémentée par l’utilisation d’un

« domaine » de valeurs. La valeur affectée au champ BLOCCTRLROOMID ne peut être qu’une valeur prédéfinie dans la table de « domaine », c’est à dire aujourd’hui : TCR, PCR, MCR et QCR.

VI. 3. 1. 2 Types de blocs et règles

Le but de cette partie de la base de données est de définir des informations génériques pouvant être réutilisées par plusieurs blocs. Ceci s’applique notamment au niveau des règles permettant d’obtenir un état résultant à partir de l’état de plusieurs valeurs de plusieurs équipements. En effet, la logique de telles règles, parfois complexe, est souvent identique pour de nombreux blocs. La différence se situe uniquement au niveau des équipements sur lesquels s’applique la logique.

Supposons par exemple que dix blocs « Etat_18kV » soient utilisés pour indiquer l’état résultant de dix couples (Barre18kV ; disjoncteur). Il n’est pas nécessaire de définir dix règles (Etat_18kV_1 = f(Barre18kV_1 ; disjoncteur_1) ; Etat_18kV_2 = f(Barre18kV_2 ; disjoncteur_2) ; …), mais une seule règle générique suffit (Etat_18kV = f(Barre18kV ; disjoncteur). Un utilisateur voulant insérer un nouveau bloc dans la base n’est alors pas obligé de créer systématiquement une nouvelle règle. Il lui suffit de préciser le type de bloc associé (correspondant à un type de règle) et d’affecter des équipements réels aux variables utilisées dans la logique de la règle.

Dans ce contexte les tables utilisées sont les suivantes (Cf. figure VI.6) :

• GTPBLOCTYPES : cette table contient les informations élémentaires relatives aux types de blocs : nom, description, catégorie, salle de contrôle responsable de sa supervision, personne responsable, position géographique. Certains de ces champs (descriptions, commentaires) peuvent ne pas être remplis ;

• GTPEQUIPTYPES : cette table contient les informations concernant les types d’équipements pouvant être associés aux types de blocs (ex :

« disjoncteur18kV »). Notons que les équipements de la table GTPEQUIP sont associés aux types d’équipements de cette table ;

• GTPBTYPESETYPES : il s’agit de la table d’association entre les types de blocs et les types d’équipements. Un type de bloc peut superviser n types d’équipements et un type d’équipement peut être supervisé par n types de blocs.

Chacune de ces associations possède un nom (ex : « disjoncteur ») et un identifiant ;

• GTPTAGTYPES : cette table contient les informations concernant les types de valeurs existants ;

• GTPETYPESTTYPES : il s’agit de la table d’association entre les types d’équipements et les types de valeurs. Un type d’équipement peut être associé n types de valeurs et un type de valeur peut être associé à n types d’équipements.

Par exemple, l’équipement de type « disjoncteur18kV » peut fournir des valeurs de type « position » (ouvert/fermé) et « défaut » (vrai/faux) ;

• GTPBLOCTYPETAGS : il s’agit d’une table d’association entre les types de valeurs et les associations type de bloc/type d’équipement (table GTPBTYPESETYPES). Elle permet par exemple de spécifier que l’association

« disjoncteur » (utilisant le type d’équipement « disjoncteur18kV ») ne possède qu’une valeur de type « position » (ouvert/fermé). Cette association est notée

« disjoncteur.position » ;

• GTPRULES : cette table contient les informations concernant les règles associées aux types de blocs (ex : bloc vert si disjoncteur.position = « fermé ») ;

• GTPTAGRULES : cette table indique quelles associations (ex :

« disjoncteur.position ») sont utilisées dans la logique de quelle règle ;

• GTPTAGBTYPETAGS : il s’agit de la table d’association entre les données de la table GTPBLOCTYPETAGS et les valeurs rendues disponibles par les équipements physiques (table GTPTAG). Elle permet de spécifier par exemple que pour un bloc « Etat_18kV_bâtiment1 » l’association « disjoncteur.position » sera associée à la valeur physique « disjoncteur18kV_001_pos ».

Figure VI. 6 : Types de blocs et règles

Parmi les contraintes du style GTPM, cette partie de la base implémente celle spécifiant que l’état résultant des règles doit être standard. En effet, la valeur affectée au champ STATEID de la table GTPRULES (valeur résultante du bloc quand la règle associée est vérifiée), ne peut être qu’une valeur prédéfinie dans la table de « domaine », c’est à dire un entier compris entre 0 et 3 associé aux états « arrêt », « opérationnel »,

« avertissement », et « faute ».

La valeur du champ TAGTYPEID de la table GTPTAGTYPES est, elle aussi, contrainte par les valeurs de la table de « domaine ». Ces valeurs correspondent aux seuls types de données qui peuvent être supervisés par les blocs, c’est à dire : chaîne de caractères, flottant, entier ou booléen.

VI. 3. 1. 3 Liens de dépendances

Les liens de dépendances permettent d’indiquer si le fonctionnement des équipements associés à un bloc est dépendant du fonctionnement des équipements associés à un autre bloc. Une seule table est dédiée à leur description (Cf. figure VI.7) :

• GTPBLOCLNK : cette table indique si un bloc « aval » est dépendant d’un bloc

« amont ».

Figure VI. 7 : Liens de dépendances

Cette partie de la base implémente la contrainte du style GTPM spécifiant qu’il ne peut exister deux relations de dépendance identiques. Les champs BLOCIDIN et BLOCIDOUT de la table GTPBLOCLINK formant une clé primaire, il n’est pas possible que deux dépendances aient les mêmes blocs « amont » et « aval ».

VI. 3. 1. 4 Documentation

A chaque bloc peuvent être associés des liens de documentation permettant aux opérateurs des salles de contrôle d’obtenir toute l’information nécessaire au redémarrage des équipements relatifs. Une seule table est dédiée aux liens de documentation (Cf.

figure VI.8) :

• GTPBLOCDOC : cette table contient les informations concernant les liens vers des fichiers de documentation : une description, une adresse (ex : URL), ainsi qu’un identifiant indiquant le programme devant être utilisé pour ouvrir le fichier.

Figure VI. 8 : Documentation

VI. 3. 1. 5 IHMs

Les IHMs de supervision sont des zones graphiques sur lesquelles sont affichés les blocs et leurs liens de dépendance. Celles-ci sont gérées par les tables suivantes (Cf.

figure VI.9)¹ :

• GTPFCTLOCATION : cette table contient les informations (noms et dimensions) de toutes les IHMs construites dans le contexte du projet GTPM ;

• GTPBLOCLOCATION : il s’agit de la table d’association entre les blocs et les IHMs. Un bloc peut être affiché sur n IHMs et une IHM peut afficher n blocs.

Cette table d’association spécifie les dimensions et positions des blocs sur les IHMs. En effet, un même bloc peut avoir des dimensions et positions différentes selon l’IHM sur laquelle il se trouve.

Figure VI. 9 : IHMs

Les champs de la table GTPFCTLOCATION correspondent aux attributs du composite « IHM spécifique » du diagramme présenté figure IV.8. Les champs XPOSITION, YPOSITION, BLOCLENGTH et BLOCHEIGHT correspondent aux attributs d’un bloc sur une IHM spécifique. En effet, un même bloc peut être représenté sur plusieurs IHMs avec des dimensions et positions différentes. Il est à noter que les champs BLOCLENGTH et BLOCHEIGHT prennent par défaut les valeurs correspondant au type graphique utilisé par le bloc (champs GRAPHICTYPELENGTH et GRAPHICTYPEHEIGHT de la table GTPPALETTE, cf. section VI.3.1.1). L’utilisateur peut modifier ces valeurs en cas de besoin spécifique.

Concernant la structure des IHMs spécifiée par le style GTPM, la base de données prévoit bien qu’un bloc puisse être représenté sur un nombre quelconque (0..n) d’IHMs.

De même, une IHM peut contenir n blocs, mais la structure de la base n’impose pas qu’au

1 La figure représente également la table GTPBLOCS, déjà présentée en VI.3.1.1, figure VI.3

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).