1.4.1 Interaction home-automate dans l’analyse diagnostique
L’interaction homme-automate est présentée dans l’analyse diagnostique comme une façon d’exploiter au fur et à mesure la connaissance de l’expert dans le processus de diagnostic. Nous allons revoir certains travaux existant.
Les travaux de (Ploix et Chazot [2006]) présentent une approche de diagnostic itératif qui permet de réaliser une modélisation structurelle au fur et à mesure dans le processus de diag-nostic. La décomposition du système dépend des résultats des tests à chaque itération. Cette approche permet d’exploiter au maximum l’expertise implicite et d’éviter les formalisations inutiles, il s’agit de la partie de la modélisation qui n’est pas exploitée dans l’analyse diag-nostique. En détail, le niveau structurel est exploité dans (Ploix et Chazot [2006]) parce qu’il est plus facile pour un expert de modéliser un système. Il décrit directement les composants impliqués dans le système et les connexions entre eux. Un processus de description itérative peut être mis en évidence, il commence par une description au niveau des macro-composants et selon les résultats du diagnostic, les parties où les défauts sont localisés sont décrites en détail. Pour expliciter au fur et à mesure l’expertise, on suppose que implicitement, un expert soit capable de :
– effectuer des tests de détection pour améliorer la localisation des défauts lorsque les diagnostics sont proposés par l’automate à une itération.
– formaliser la structure des parties du système qui sont testés. Il s’agit des composants et les connexions entre eux via des variables.
de détection et de les analyser de manière systématique afin d’en déduire toutes les fautes possibles. Un outil d’aide au diagnostic qui s’appelle SMARTlab a été présenté dans (Ploix et Chazot [2006]). SMARTlab permet de calculer tous les diagnostics minimaux à partir des symptômes et lister les diagnostics en un ordre de priorités. Dans SMARTlab, les tests négatifs sont utilisés pour calculer les diagnostics selon l’algorithme de Reiter (Reiter [1987]), qui formalise un raisonnement de diagnostic logique et permet de prendre en compte des défauts multiples. L’ordre des diagnostics est classé par la mesure contextuelle et la probabilité des modes. Ceci est présenté dans (Touaf et Ploix [2004a]) et est rappelé dans l’annexe A. Un exemple sur l’exploitation de SMARTlab est présenté dans (Ploix et Chazot [2006]).
Dans (Kleer et Williams [1987]; De Kleer et Williams [1992]), l’interaction homme-automate est présentée au niveau des mesures. Pour superviser un système industriel, certains capteurs peuvent être disponibles pour détecter les défauts. Pour localiser plus précisément, il faut avoir des mesures supplémentaires. Le problème proposé par de Kleer est de localiser un défaut avec un nombre de mesures minimal. La méthode proposée s’appuie sur la probabilité des défauts et la théorie de l’Entropie pour proposer les prochaines mesures au testeur.
Dans (Chittaro et Ranon [2004]), la procédure de diagnostic est quasiment automatique à partir du modèle du système et des observations. La suggestion des mesures n’est pas abordée dans son travail. L’interaction entre l’expert et l’automate a lieu au niveau du modèle téléolo-gique afin de déterminer la partie active ou inactive du système. Ceci permet de déterminer le contour du système à tester.
1.4.2 Positionnement de l’objectif d’interaction homme-automate dans
l’analyse diagnostique
Nous voyons que la plupart des travaux existant dans le domaine diagnostique sont présen-tés toujours avec l’hypothèse que le modèle du système est décrit complètement au préalable. Une autre piste de recherche qui est quasi nouvelle est présentée dans (Ploix et Chazot [2006]). Dans ce travail nous souhaitons suivre cette piste afin de résoudre des difficultés liées à la com-plexité des modèles. Nous considérons l’interaction homme-automate comme la seule façon permettant d’exploiter l’expertise qui ne peut pas être exprimée sous forme de modèle formel. Nous allons discuter ensuite les types d’interaction homme-automate dans l’analyse diagnos-tique en faisant le lien avec le modèle et l’approche de diagnostic que nous avons discuté précédemment. Au contraire de certaines approches présentées dans la littérature où les étapes de génération de symptômes et de diagnostic sont confondues, dans les problèmes que nous présentons, les trois étapes : modélisation du système, génération des symptômes et analyse diagnostique seront bien distinguées. Ensuite, nous étudierons l’interaction homme-automate suivant trois directions étudiées dans les chapitres 3,4 et5. (figure 1.9).
FIG. 1.9 – Trois types d’interaction homme-automate dans les problèmes de diagnostic itérac-tifs
FIS, l’interaction homme-automate se manifeste durant la tâche de modélisation et de détec-tion. L’opérateur décompose et teste le système selon différents niveaux d’abstraction, et puis il formalise les symptômes. Les diagnostics seront calculés à partir des symptômes obtenus. Cette approche est proposée pour les problèmes de diagnostic où le modèle de comportement du système peut être implicite. La réalisation des tests et la formulation des symptômes re-posent sur la connaissance implicite de l’expert. Un problème de diagnostic hors-ligne d’une voiture a été présenté dans (Giap et al. [2010b]).
Dans le deuxième problème de diagnostic itératif basé sur le modèle comportemental, l’interaction homme-automate se manifeste durant la tâche de modélisation. Ce problème concerne plus particulièrement les systèmes complexes, où le modèle du système est décrit partiellement et certaines parties seront affinées au fur et à mesure. En effet, l’analyse diagnos-tique pour un modèle complet détaillé n’est souvent pas réaliste parce qu’elle est trop longue et trop couteuse à établir. De plus, il n’est pas nécessaire d’aborder des modèles qui ne sont pas utilisés dans l’analyse diagnostique. Nous pouvons constater que les symptômes sont for-mulés par l’expert dans le premier problème tandis qu’on a besoin de l’automate dans la tâche de détection de symptômes dans ce deuxième problème. Pour cette raison, en plus des ou-tils du premier problème, les nouveaux ouou-tils seront conçus dans ce deuxième problème pour détecter automatiquement des symptômes à partir d’un modèle décrit à différents niveaux de
comportement.
Dans le dernier problème de diagnostic itératif basé sur la connaissance experte implicite, l’interaction homme-automate se manifeste durant la tâche de diagnostic. Dans ce problème, le modèle du système est construit au début mais il n’est pas complet. A l’aide des observations fournies, un ensemble de diagnostics peut être calculé mais cet ensemble est parfois trop im-portant pour être appréhendé par un expert. Par exemple dans un problème de diagnostic pour un réseau de pluviomètres, qui est présenté dans le projet Hydrodiag, 16 diagnostics différents sont trouvés avec 5 ou 6 défauts simultanément. L’intervention de l’opérateur dans l’étape de diagnostic est alors nécessaire. Les connaissances implicites (non-formalisé) de l’expert seront exploitées dans l’analyse des données collectées pour isoler des défauts.
Les deux premiers problèmes consistent à résoudre les difficultés liées à la complexité (la structure et le comportement). Le dernier consiste à résoudre les difficultés liées à l’exploita-tion des types de connaissance non-formulée par l’expert.