Conception d’une matrice de diagnostic interactive

=µ(test_i) (5.2.2) Dans la communauté bridge DX-FID, l’hypothèse d’exonération n’est pas prise en compte. Les diagnostics est donc calculés à partir des propositions logiques^Vmode_i∈ Modes(test_i) où

µ(test_i) = 0. Une fois qu’un ensemble de diagnostics possibles est obtenu, la question posée est comment retirer au fur et à mesure les diagnostics qui sont les moins probables et localiser les défauts le plus rapidement possible. Nous parlons donc de l’interaction homme-automate dans la phase de diagnostic qui est présenté par (1) sur la figure 5.1. Pour la localisation de défauts sur un réseau de pluviomètres que nous avons évoquées dans la section 5.1, l’opérateur ne fait pas des mesures mais qu’il estime directement les défauts de capteurs en observant le hyétogramme de pluie des capteurs. Une rétro-analyse (2) est aussi considérée pour corriger les erreurs de seuil au niveau des tests automatiques. Durant l’interaction (1), le rôle de l’au-tomate est de guider l’opérateur pour localiser les défauts le plus rapidement possible. Pour ce but, la mesure de coïncidence et la probabilité des défauts sont exploitées. Elles peuvent être consultées en détail dans l’annexe A de ce manuscrit.

En se basant sur ce principe, nous avons proposé dans le cadre du projet Hydrodiag la conception d’une matrice de diagnostic interactive pour exploiter l’expertise implicite et pour guider l’expert durant le processus de diagnostic.

5.2.1 Conception d’une matrice de diagnostic interactive

Pour résoudre le problème, nous nous sommes orientés vers une solution d’accompagne-ment de l’expert pour l’établissed’accompagne-ment d’un diagnostic. L’idée est que seule une partie de la connaissance de l’expert peut être formalisée sous la forme de tests automatiques. Il y a d’une part le système d’aide au diagnostic avec des modèles mathématiques précis, avec des outils de raisonnement exacts capables d’appréhender la complexité sans difficulté, et de l’autre, un expert avec une connaissance tacite complémentaire qui lui permet souvent de déterminer si un capteur est défaillant ou pas en regardant son hyétogramme et ceux de ses voisins alors que le système d’aide ne peut pas le détecter.

La procédure consiste à exploiter les résultats des tests automatiques et les modes de dé-faut préalablement sélectionnés par un expert, pour lui présenter des informations judicieuses qui lui permettront, en se basant sur une connaissance implicite, de sélectionner de nouveaux modes de défaut. Néanmoins, pour que cela fonctionne, il faut offrir une certaine liberté de

d’analyse diagnostique

choix à l’expert car il est difficile de prédire où il aura le plus de facilité à conclure. Dans ce but, un outil d’aide au diagnostic est conçu pour guider l’expert durant le processus de diagnostic.

Avant de présenter l’outil d’aide au diagnostic, nous présentons en détail les travaux exis-tant dans Nguyen [2005], c’est un cas d’étude intéressant pour le contexte interaction homme-automate.

Cas d’étude

Nous allons détailler maintenant comment se formule le problème de détection de défaut sur un réseau de pluviomètres. Le problème posé consiste à mettre au point un outil d’aide au diagnostic pour déterminer les défauts d’un réseau de capteurs répartis sur le bassin versant de l’Ouémé de 47536km² au Bénin. 46 pluviomètres à godets, qui basculent à chaque fois que 5mm d’eau ont été reçus, sont disponibles. Leurs coordonnées latitude et longitude sont connues. Les capteurs sont répartis sur le bassin de l’Ouémé conformément à la figure 5.2.

FIG. 5.2 – Observatoire OHHVO du bassin de l’Ouémé au bénin et réseau de capteurs

La première étape d’une procédure de diagnostic automatisée est généralement la concep-tion de tests de détecconcep-tion. Pour tester les pluviomètres, un simple outil exploitant la redondance matérielle (comparaison de données de capteurs mesurant une grandeur proche) est utilisé en recherchant des pluviomètres corrélés deux à deux. A l’aide du retour d’expérience des hydro-logues, les corrélations calculées au niveau de chaque mois des couples de capteurs séparés spatialement par une distance moins de 10km sont testés ¹ : cela caractérise la validité du

FIG. 5.3 – Position des capteurs et tests réalisés sur le bassin de l’Ouémé

Pour établir des seuils de décision au niveau des corrélations, nous disposons de tableaux identifiant l’état de chacun des capteurs pour chaque période de deux semaines (voir figure 5.4).

La figure 5.5 montre comment choisir un seuil sachant que la validité indique qu’il ne faut considérer que les capteurs distants de moins de 10km. Il faut d’une part minimiser le nombre de non détection tout en interdisant strictement les fausses alarmes qui sont critiques pour une analyse diagnostique logique car les diagnostics obtenus seraient erronés alors qu’une non-détection n’engendrerait que des diagnostics moins détaillés (certains modes de défaut pourraient ne pas apparaître). Plus concrètement, sur la figure 5.5, il faut qu’il existe un mini-mum de ’x’ rouges, qui indiquent des résidus de tests de corrélation jugés inconsistants par un expert, en dessous du seuil et qu’il n’existe aucun ’+’ vert, qui indiquent des résidus de tests de corrélation jugés consistants par un expert, au dessus du seuil. Au passage, on constate que de nombreux états défaillants s’apparentent à des états normaux : tous les modes de défaut ne se manifestent pas en permanence. L’analyse de la figure 5.5 permet d’obtenir une fonction seuil linéaire en fonction de la distance telle que tous les points qui représentent des tests normaux sont au dessous de celle-ci. Cette fonction seuil est représentée par une droite sur la figure 5.5 Nous avons alors appliqué un algorithme d’analyse diagnostique en pensant être en passe de résoudre le problème. Or, pour les huit périodes mensuelles étudiées (de mars à octobre car en dehors de cette période, il ne pleut pas sur ce bassin), nous avons obtenu de 13 à 32 diagnos-tics possibles pour chacun des 8 mois de l’année 2002, sachant qu’un diagnostic comporte au minimum 4 capteurs simultanément défaillants. Par exemple, pour le mois d’août 2002, nous avons obtenu 16 diagnostics :

d’analyse diagnostique

FIG. 5.4 – Une partie de l’expertise sur le fonctionnement des pluviomètres

diagnosis #0 (Formal:100.0%, Contextual:88.63636363636364%, A priori:0.010000000000000004%) Component d643 (gangamou) is faulty

and component d626 (dapefougou) is faulty and component d614 (adiangdia) is faulty and component d647 (parakou_2) is faulty ______________________________

diagnosis #1 (Formal:100.0%, Contextual:88.63636363636364%, A priori:0.010000000000000004%) Component d643 (gangamou) is faulty

and component d626 (dapefougou) is faulty and component d632 (adiangdia_oues) is faulty and component d647 (parakou_2) is faulty ______________________________

...

______________________________

FIG. 5.5 – Seuils de détection

Component d639 (kolokonde) is faulty and component d611 (donga) is faulty and component d644 (gountia) is faulty and component d645 (koko-sika) is faulty and component d632 (adiangdia_oues) is faulty and component d636 (parakou) is faulty

Ces résultats induisent de nombreuses questions : comment un expert est-il capable d’ex-ploiter de tels résultats ? Dans quelle direction partir ? Peut-on réellement parler d’aide au diagnostic ici ? Plutôt que d’essayer de déterminer lequel de ces diagnostics est correct, n’est-il pas plus simple pour un expert d’analyser directement les 25 hyétogrammes comme n’est-il le faisait jusque là ?

Pour proposer un outil d’aide au diagnostic utile à ce type de contextes, il va falloir s’ap-puyer sur un nouveau paradigme que nous avons déjà étudié à travers d’autres types de pro-blèmes : l’aide au diagnostic interactive.