DU RAPPORT D’INTERVENTION A L’EXPERIENCE FORMALISEE

Pour la formalisation du vocabulaire du domaine et des informations caractérisant les expériences passées, plusieurs plates-formes et outils de mise en œuvre des GCs ont été proposées dans la littérature (Baget et al., 2008), permettant de définir un support ontologique ( ) et de construire les GCs associés.

Nous avons choisi la plate-forme CoGui pour cette mise en œuvre : CoGui editor8 _{(Figure IV.5),}

développé en langage Java, est un outil libre basé sur les graphes qui permet de construire et de manipuler des structures visuelles intuitives avec des capacités de raisonnement par projection (par exemple des requêtes sur les graphes). Essentiellement, la plateforme CoGui permet de construire un support (!", !#) et un ensemble de GCs représentant les assertions, souvent appelées « faits ». Dans notre contexte REx-ECD, ces « faits » sont dénommés « expériences » (stockées dans la base

d’expériences), et « règles » (stockées dans la base de règles).

Figure IV.5. Interface de l’outil CoGui editor

Paula Andrea Potes Ruiz

100

IV.3.3.1 Définition du support dans les GCs

Les composants d’une ontologie au niveau conceptuel (vocabulaire du domaine) sont représentés à l’aide de la plateforme CoGui dans un modèle général simplifié pour chaque cas d’application considéré dans le domaine de la maintenance.

Pour le cas d’application # 1, nous illustrons sur la Figure IV.6 et la Figure IV.7 la hiérarchie réduite des types de concepts ( !) et la hiérarchie des types de relations ( ") respectivement, décrivant les informations issues des interventions de maintenance sur les ponts roulants. Chacune de ces hiérarchies, présentées dans deux interfaces différentes, permet de construire et de modifier les graphes dans CoGui.

Les hiérarchies ! et " fournissent donc le support (#), qui est la base de la représentation des connaissances dans la base de REx-ECD. Dans nos cas d’application, # permet essentiellement de modéliser les équipements et de contextualiser et décrire d’une façon plus intuitive les interventions de maintenance, tout en tenant compte des trois principaux éléments clés qui définissent une expérience (section II.3.2.1) : le contexte, l’analyse et la solution.

Figure IV.6. Visualisation d’une partie de la hiérarchie des types de concepts (TC) modélisées dans CoGui (Cas # 1)

Pour la représentation des expériences à partir de ! (Figure IV.6), nous avons défini la partie « contexte » qui décrit la situation générale dans laquelle s’est produit l’événement déclencheur sur le pont roulant (incluant par exemple l’ordre de travail, la localisation fonctionnelle de l’équipement concerné, la zone de défaut, le technicien concerné) ; la partie « analyse » expose la cause principale du problème ou l’intervention ; finalement, la « solution » décrit principalement le type

d’intervention associé et les actions qui ont été effectuées pour résoudre le problème spécifique (i.e.

les activités de maintenance menées).

Contrairement à !, " exprime les relations fondamentales des ontologies qui seront utilisées pour représenter les GCs dans les trois cas d’application. Dans la Figure IV.7, nous représentons des relations génériques comme la relation « temporelle » (i.e. avant, après, en parallèle), la relation « spatiale » (i.e. dans, dehors), la relation « logique » (i.e. implique, et), la relation "usuelle" (i.e. objet,

attribut, agent, concerne, etc.) (Breuker, 2013), ainsi que d’autres relations spécifiques à notre étude

comme la « relation d'expérience » (i.e. nécessite, génère) ou « élément de ». Ces relations permettent donc de relier les différents types de concepts liés à la représentation des expériences passées et des nouvelles connaissances extraites.

Figure IV.7. Hiérarchie des types de relation (TR) modélisées dans CoGui

IV.3.3.2 Formalisation des expériences Modèle générique d’une expérience

A partir d’un support (#) défini pour chaque cas d’application, nous avons proposé un graphe conceptuel du modèle générique pour représenter chaque expérience à partir des informations disponibles dans chaque cas.

Pour le cas # 1, nous proposons sur la Figure IV.8 un modèle structuré permettant de représenter les expériences, incluant les attributs les plus significatifs sélectionnés pour décrire une intervention.

Paula Andrea Potes Ruiz

102

Ce modèle doit être adapté aux autres cas d’application, notamment en fonction des caractéristiques des informations disponibles et des restrictions de chaque contexte d’application.

Figure IV.8. Modèle générique d’une expérience (Cas # 1)

Le graphe conceptuel de la figure peut se lire de la manière suivante : une expérience concerne un

contexte, une analyse et une solution (les trois sous-graphes de la Figure IV.8). Le contexte est décrit

par un ordre de travail concernant un technicien et un poste de travail. Cet ordre a comme objet un

équipement (avec certaines caractéristiques spécifiques et localisé dans une zone déterminée) qui a

eu une défaillance. Cette situation nécessite une analyse afin de trouver la cause principale du problème. Une fois la cause déterminée, une solution va être générée incluant le type d’intervention à effectuer, les actions correspondantes et le type de pointage.

Formalisation des expériences à l’aide des GCs

Une fois le modèle générique évalué et validé par l’expert du domaine, nous passons à la représentation de chacune des expériences contenues dans le fichier Excel. Poursuivant le premier cas application, nous prenons comme exemple ici les événements survenus sur les ponts roulants, qui sont la base de chaque expérience dans ce contexte.

En fonction du modèle générique prédéfini et du support ( ), le GC de la Figure IV.9 est construit, représentant les informations portant sur une intervention réalisée. Le graphe de la Figure IV.9 peut être interprété de la façon suivante : dans l’expérience !", le contexte #" nécessite une analyse $",

Figure IV.9. Illustration d’une intervention du cas #1

Par exemple, le contexte ! est décrit par l’ordre de travail n° 698188 pour l’équipement Pont2. Nous

distinguons ici l’objet de l’action de maintenance, la zone de défaut (le mouvement de translation) et des données supplémentaires utilisées pour mieux décrire le contexte de l’événement (nom du technicien, poste, date, caractéristique de l’équipement, …). Pour la description de l’analyse "_!, nous décrivons la cause principale de l’intervention (dans ce cas, il s’agissait d’une demande d’assistance pour l’équipement). Finalement, la description de la solution concerne le type d’intervention effectuée, le type de pointage et les actions réalisées (ici, une assistance technique de type « correctif - CO » consistant en un réalignement de l’instrument). La durée de cette intervention a été de 2 heures.

Ces expériences formalisées sont ensuite stockées dans la base d’expériences contenue dans la base de REx-ECD pour une réutilisation future.

Paula Andrea Potes Ruiz

104