Méthodologie proposée pour élaboration du système d’aide au diagnostic

Un des buts recherchés lors de la conception du système d’aide au diagnostic et à la réparation est de capitaliser la connaissance experte d’un opérateur lors d’un dépannage et de la partager entre opérateurs afin d’améliorer la performance et l’efficacité des interventions du service de maintenance. On a pu constater à partir d’une étude comparative sur différents systèmes existants qu’il n’y a pas de méthodologie d’élaboration d’un cas typique du diagnostic. Dans la plupart des applications, un cas reflète et traduit l’expérience de diagnostic sans pour autant faire référence à un modèle.

En ce qui nous concerne, nous proposons une méthodologie pour pallier au manque d’expertise en la créant par des outils de sûreté de fonctionnement ce qui permet d’élaborer un cas de diagnostic. Nous modélisons l’expertise issue de ces outils d’analyse par des méthodes de représentation et de modélisation des connaissances issues du domaine d’ingénierie des connaissances. Nous utilisons plus particulièrement la technique d’ontologies qui permet à la fois de modéliser les connaissances du domaine et les concepts liés à la méthode de raisonnement qui manipule les connaissances du domaine. Ces ontologies participent à la mémoire d’entreprise crée pour le processus de maintenance.

Le but du système d’aide est d’établir un diagnostic en déterminant le composant défaillant et de proposer une action de réparation adéquate avec des informations supplémentaires pouvant être recherchées dans la mémoire d’entreprise. Il s’agit de pièces de rechange, d’outils nécessaires, de compétence requise de l’opérateur et de documentation technique appropriée.

Le système est centré sur l’équipement à maintenir, par un premier niveau de surveillance lié à l’équipement (la supervision des données mesurées à l’aide de capteurs) et un deuxième niveau élaborant le diagnostic de pannes et leur réparation. Ces deux niveaux serviront ensuite de support à deux autres niveaux concernant la gestion des ressources aussi bien humaines que techniques, et la gestion des politiques de maintenance [Rasovska et al., 2004].

Expertise

Analyse d’équipement Analyse de l’historique des pannes Décomposition

d’équipement

Analyse

fonctionnelle AM DEC Arbres de défaillances M odèle de

l’équipement

M odèle des défaillances M odèle du système d’aide au diagnostic et à la

réparation

Figure 4.9. Méthodologie proposée – expertise de l’équipement

La conception de notre système nécessite la modélisation cognitive des processus et des connaissances utilisées par l’opérateur lors de son activité. La modélisation des connaissances du domaine de maintenance suit la démarche employée par les experts du domaine en appliquant des méthodes d’analyse relatives à la sûreté de fonctionnement (cf. fig. 4.9). Le modèle se base sur l’analyse de l’équipement et l’analyse de l’historique des pannes.

L’analyse de l’équipement, grâce à un système de décomposition, aboutit à une modélisation hiérarchique de l’équipement complétée par l’analyse fonctionnelle qui détermine les fonctions assurées par l’équipement et ses composants.

L’analyse de l’historique des pannes se base sur la méthode AMDEC (Analyse des Modes de Défaillance, de leur Effets et de leur Criticité) et sur les arbres de défaillances qui identifient les défaillances possibles de l’équipement et ses composants. Ces méthodes font actuellement objet de la recherche et de développement des outils automatiques [Kimura et al. 2002], [Barkai, 1999] ce qui nous permet d’envisager la récupération automatique de l’expertise issue de ces outils sous forme directement exploitable par le système d’aide.

Modèle de données du système d’aide au diagnostic basé sur le RàPC

Les analyses nous permettent donc de créer un modèle du domaine qui est ensuite associé à un modèle de raisonnement. La méthode de raisonnement choisie pour notre système est le raisonnement à partir de cas. Cela signifie qu’une vue spécifique de modèle d’expertise est une base de cas exploitable par les différentes fonctions du raisonnement à partir de cas. Nous y identifions les descripteurs pertinents pour la représentation de cas, une structure appropriée de cas associée aux connaissances générales et exploitées dans les phases de remémoration et d’adaptation.

Figure 4.10. Modèle de données du système d’aide au diagnostic et à la réparation

Sur la figure 4.10 nous présentons le diagramme de classes UML décrivant, d’une part, l’équipement, sa décomposition et son fonctionnement et d’autre part, la structure du système d’aide au diagnostic et à la réparation basé sur le RàPC.

L’équipement se décompose en sous-équipements sous une forme arborescente [Rasovska et al., 2004]. A chaque équipement sont associées deux classes InterneFunctionType et ExterneFunctionType spécifiant le fonctionnement de celui-ci. La première classe représente le type de l’équipement (MechanicFunction, HydrolicFunction etc.) et concerne le fonctionnement interne. La deuxième classe est caractérisée par la hiérarchie des fonctions -fonction principale (MainFunction), secondaires (SecondFunction) et les contraintes (ConstraintFunction). De plus, une défaillance donnée (Failure) est associée à un équipement. Dans les arbres de défaillances, une panne est caractérisée et décrite par un symptôme causé par une autre défaillance appelée origine.

Le modèle du système de RàPC décrit par la classe DecisionModel. Le raisonnement à partir de cas stocke les cas (Case) dans la base de cas (CaseBase). Le cas est composé de deux parties différentes, à savoir la description du cas (CaseDescription) et sa solution (CaseSolution). La description est associée à la classe CharacteristicSet comportant les variables (Variable) caractérisant le symptôme de la défaillance (Symptom). Pour retrouver les cas similaires dans la base de cas nous associons à l’ensemble des variables les mesures de similarité (SimilarityMeasurement) qui sont basées sur la distance et du poids associé (Weight). Le diagnostic consiste à identifier les variables décrivant le symptôme permettant ainsi d’identifier l’origine de la panne et de déterminer l’action à entreprendre (RepairAction) et la documentation

nouveaux cas nous introduisons la classe des règles d’adaptation. Chacune des classes de ces diagrammes peut être instanciée afin de créer des objets et par conséquent des cas. Un cas est représenté par une instanciation du diagramme de classes [Ruet, 2002].

L’intégration de notre système dans la plateforme générique permet une acquisition des données relativement facile et efficace. Le système récupère le maximum d’informations et de données automatiquement en renvoyant les requêtes automatisées à d’autres systèmes et bases de connaissances.

L’algorithme du système d’aide au diagnostic basé sur le RàPC

Les systèmes de RàPC modélisent et adoptent le raisonnement d’un être humain basé sur la remémoration des expériences précédentes. Cette manipulation des connaissances a été traduite dans un cycle de RàPC et a été adaptée à des systèmes de gestion des connaissances [Watson, 2001]. Nous avons traduit ce cycle en formalisme UML dans un diagramme de séquence décrivant les différentes étapes du système d’aide au diagnostic et à la réparation (cf. fig. 4.11). Ce diagramme permet de modéliser l’exploitation des connaissances par un système informatique [Rasovska et al., 2004b]. Après avoir reçu une demande d’intervention de la part de l’opérateur de production, le technicien de maintenance sollicite l’aide du système. Il envoie l’ordre de travail (WorkOrder) avec le premier symptôme identifié par l’opérateur de production. A partir de ce premier diagnostic, le processus du raisonnement à partir de cas crée le questionnaire (ensemble de questions fermées rempli par sélection de la bonne réponse par l’opérateur de maintenance). Les réponses serviront à la description d’un nouveau problème qui représente la première phase du cycle du système de RàPC (l’élaboration).

La deuxième étape, la recherche de cas similaires, prendra appui sur les mesures de similarité. Ces similarités sont calculées pour les origines du symptôme décrit dans la phase précédente et seront utilisées pour retrouver les cas similaires dans la base de cas. La réutilisation de la solution du cas similaire se fera soit en adoptant la solution du cas retrouvé soit en adaptant la solution du cas au nouveau cas ce qui correspond à la phase d’adaptation. Ensuite, l’opérateur de maintenance effectue la procédure donnée dans la solution. Une fois la procédure complétée, l’opérateur rend le rapport d’intervention qui indique la réussite ou non de la procédure. Si la procédure est satisfaisante, ce nouveau cas doit être introduit dans la base de cas. Dans le cas contraire, une autre solution basée sur un cas moins similaire que le précédent est proposée jusqu’au dernier cas dans la liste des cas similaires. L’opérateur face à une solution fausse proposée par le système peut appliquer sa propre solution. Dans ce cas, la solution doit être décrite dans le rapport d’intervention et ensuite enregistrée dans la base de cas. Les modifications dans la base de cas peuvent être effectuées seulement sous le contrôle d’un expert.

Figure 4.11. Le diagnostic

Operation Argument Type Argument Type Result <<processus>> CBR diagnose WorkOrder In void

createQuestionForm WorkOrder In QuestionForm

elaboration QuestionForm In WorkOrder In Description

bestCase Case

adaptSolution Case In Description In Action

BaseCase findSimilarCases Description In List Of Case

store Case In

MaintenanceOperator fillQuestionForm QuestionForm In/Out

checkSolution Description In Action In Case Or Boolean

noSolution

Tableau 4.1. Liste des opérations