Algorithme de diagnostic

Dans cette partie, nous allons détailler les outils théoriques et les techniques utilisées pour concevoir l’algorithme d’aide au diagnostic.

Standardisation du modèle en ajoutant des items virtuels (bloc (3) sur la figure 3.2) La première étape consiste à compléter les abstractions partielles par des items virtuels. Cette étape correspond au bloc (3) sur la figure 3.1. Le modèle structuro-fonctionnel donné par l’expert à chaque interaction peut ensuite être transformé complètement en un ensemble de propositions logiques.

Exemple 11. Prenons l’exemple du système modélisé par le graphe F/R représenté sur la figure 3.3. L’item I₄ de ce système n’est pas complétement décomposé. Par conséquent le mode virtuel IV₁= I₄\ {I₇, I₈} est ajouté.

ok (I₆) ↔ ok (I₂) ok (I2) ↔ ⊥(I5) ⊥(I₅) ↔ ok (I₁) ok (I₁) ↔ ok (I₃) ∧ ok (I₄) ok (I4) ↔ ok (I7) ∧ ok (I8) ∧ ok (IV1) avec IV₁= I₄\ {I₇, I₈} (3.3.1)

Recherche des explications des symptômes (bloc (4a) sur la figure 3.2)

La recherche des explications des symptômes consiste à remplacer les modes impliqués dans les symptômes formulés par l’expert. Ce remplacement s’appuie sur l’ensemble de pro-positions logiques entre les modes transformés du graphe F/R (présenté par le bloc 3). Cette étape de remplacement permet de remplacer tous les modes des fonctions dans les explications des symptômes par les modes des ressources à l’aide des propositions logiques résumées sur la figure 2.20, page 56. Le remplacement des fonctions par des ressources permet de calculer des diagnostics et de localiser des défauts au niveau des ressources qui est le but final du problème de diagnostic de panne.

Les relations d’abstraction ne sont pas exploitées dans cette étape. Elles seront exploitées plus tard de façon à garantir qu’un diagnostic ne comporte pas le mode d’un item-parent et celui de ses items enfant.

De façon générale, ce remplacement est effectué en écrivant les tests sous une forme nor-male disjonctive en fonction des modes de défaillances des éléments explicatifs.

Exemple 12. Revenons à l’exemple (11) avec le modèle du système représenté sur la figure (3.3). Supposons que l’expert effectue un test et formule un symptôme : >(T₁) → cfm (I₂). Une explication au niveau des ressources peut être trouvée en utilisant les propositions (3.3.1) :

Expl(>(T₁)) : cfm (I₃) ∨ cfm (I₄)

Gestion de la relation hiérarchique entre les items dans l’explication des symptômes (bloc 4b sur la figure 3.2)

L’analyse diagnostique pour un modèle qui est décrite à différents niveaux de décomposi-tion peut se ramener à un ensemble non-minimal de diagnostics. Cet ensemble est non minimal

parce qu’il existe des diagnostics qui peuvent être expliqués par les autres via des relations hiérarchiques entre les items. De plus, il peut exister dans cet ensemble des diagnostics qui comportent à la fois le mode d’un item parent et le mode d’un de ses items enfants. Ce sont des diagnostics non-minimaux. Un ensemble de diagnostics non-minimal sera difficile à appré-hender par l’opérateur. De plus, dans l’analyse diagnostique, il n’est pas nécessaire de détailler au niveau des sous-items qui n’apparaissent pas dans les tests.

Supposons que T_nest l’ensemble des explications de test (donné par le bloc 4a sur la figure 3.2) obtenu à l’étape n du processus de diagnostic, Modes(T_n) est l’ensemble de modes im-pliqués dans Tn. Pour assurer qu’il n’existe pas de relations hiérarchiques entre les modes impliqués dans un diagnostic, nous remplaçons des modes des items parent existant dans Modes(Tn) de façon récursive jusqu’à ce qu’il n’existe plus de relations hiérarchiques entre les modes dans Modes(T_n).

Pour remplacer, il nous faut tout d’abord détecter l’existence des relations hiérarchiques. La détection des relations hiérarchiques entre mode(Ii) ∈ Modes(Tn) et mode(Ij) ∈ Modes(Tn) et le remplacement des modes parent sont réalisés à l’aide du graphe F/R présenté sur la figure 2.22, page 58. En principe, le graphe sur la figure 2.22 montre qu’il existe une relation hiérarchique entre deux items I_iet I_js’il existe un chemin constitué d’arcs entre eux (des arcs représentant des liens d’abstraction). Un chemin de I_ià I_jpermet de dire que I_iest le super-item de I_j. Il est facile de vérifier si un item I_iest le super-item d’un autre item I_jsur le graphe F/R. Nous déterminons tout d’abord les sous-items de Iidans ce graphe, noté par SubItems(Ii). Si Ij∈ SubItems(Ii) alors Ij est le sous-item de Ii. La détection des relations hiérarchiques est réalisée par la vérification de chaque paire de modes mode(Ii) et mode(Ij) dans l’ensemble Modes(T_n) pour chercher l’existence de chemins entre eux.

représentant des liens d’abstraction) tel que I_i∈ Path_{i j} et I_j∈ Path/ _{i j} (on ne remplace pas les modes de Ijpar les modes de ses items-enfant)

Tant que (∃mode(Ii) ∈ Modes(Tn), ∃mode(Ij) ∈ Modes(Tn) tel que Iiest le super-item de I_j) faire

[Déterminer Path_{i j}]

Tant que (∃mode(I_k) tel que I_k∈ Pathi j) faire

[Remplacer mode(I_k) par l’ensemble de modes enfants en ajoutant un item virtuel si la décomposition est partielle]

Fin Tq Fin Tq

ALG. 1: Gestion de la relation hiérarchique entre les items

Exemple 13. Supposons que nous ayons un système avec des relations hiérarchiques entre les items qui sont présentés sur la figure 3.4 (abstraction entre les fonctions ou les ressources). Supposons qu’il existe un ensemble des explications T des tests T tel que {ok(I₁), ok(I₇)} ∈ Modes(T ). Comme I₁est le super-item de I₇, le remplacement des modes parent nous donne :

¬ok(I1) ↔ ¬ok(I2) ∨ ¬ok(I3) ∨ ¬ok(V I1)

¬ok(I₃) ↔ ¬ok(I₆) ∨ ¬ok(I₇) ∨ ¬ok(V I₂) ^(3.3.2)

avec V I₁= I₁\ {I₂, I₃} et V I₂= I₃\ {I₆, I₇} La proposition (3.3.2) est réécrite :

¬ok(I1) ↔ ¬ok(I2) ∨ ¬ok(I₆) ∨ ¬ok(I7) ∨ ¬ok(V I2) ∨ ¬ok(V I1) (3.3.3)

Dans cet exemple, nous voyons que seulement les parties du système concernant les modes testés sont affinées dans l’analyse diagnostique. Le mode parent ok(I₂) n’est pas testé. Donc, il n’est pas nécessaire de le remplacer dans l’analyse diagnostique.

Durant l’analyse diagnostique avec décompositions itératives, la décomposition d’un item en un ensemble de sous-items peut conduire à un sous-item qui est discriminable avec certains autres items et non-discriminable avec certains autres. L’idée est que, dans l’analyse diagnos-tique, il ne faut pas analyser en détail les sous-items qui ne sont pas discriminables. Dans le processus de diagnostic, la table de signature sera mise à jour à chaque fois que des nouveaux

FIG. 3.4 – Calcul des diagnostics

tests sont ajoutés. Supposons que T_n: Modes(T_n) → T_n soit la table de signature obtenue à l’itération n dans un processus de diagnostic. Pour assurer la performance des diagnostics, Tn doit satisfaire deux conditions :

– Il n’existe pas de relations hiérarchiques entre les modes dans Modes(T_n). Cette condi-tion assure qu’il n’existe pas la relacondi-tion hiérarchique entre deux modes impliqués dans un diagnostic. Ceci a été discuté précédemment dans la partie de la gestion des relations hiérarchiques des items.

– Il ne faut pas analyser en détail les sous-items qui ne sont pas discriminables.

Calcul effectif des diagnostics (bloc (4c) sur la figure 3.2)

En considérant les défauts multiples dans un système, un diagnostic est donc une conjonc-tion de modes de défaut telle qu’elle peut satisfaire toutes les explicaconjonc-tions des symptômes. Dans chaque diagnostic, le mode de défaillance de chaque composant défectueux est pris en compte. Autrement dit, étant donné un ensemble de tests inconsistants, la recherche d’un diag-nostic consiste à rechercher une conjonction de modes qui vérifie l’expression suivante :

^ T_i∈T

Expl(>(T_i)) (3.3.4)

T est l’ensemble de tests inconsistants.

Ces diagnostics sont recherchés en utilisant l’algorithme de l’arbre HS de Reiter présenté dans l’annexe A.

remarque 1. Expl(>(T_i)) dans la proposition 3.3.4 est une disjonction logique de modes et est considérée comme un conflit dans la construction de l’arbre HS. En réalité, il peut exister à la fois les OUs et les ETs logiques dans Expl(>(Ti)). Dans ce cas, pour appliquer HS-Tree au calcul de diagnostic, la proposition 3.3.4 peut être transformée en forme normale conjonctive représentée par

Chaque clause (mode(I_m.1) ∨ · · · ∨ mode(I_m.n)) est une disjonction de modes et est consi-dérée comme un conflit dans la construction de l’arbre HS.

Théoriquement, nous pouvons transformer la proposition 3.3.4 en forme de la propostion 3.3.5 s’il existe à la fois des OUs et des ETs dans Expl(>(Ti)). Pourtant, cette transformation peut causer des difficultés concernant l’explosion de combinaison dans les calculs. Comme ceci n’est pas le but du travail présenté dans ce manuscrit, nous supposons dans ce travail que Expl(>(T_i)) soit toujours une disjonction de modes. Le traitement du cas où il existe à la fois des OUs et des ETs dans Expl(>(T_i)) sera une perspective à développer.

Les tests consistants sont intégrés comme nous le présenterons dans la suite. Prise en compte des tests consistants

L’analyse des tests consistants permet d’identifier la liste des fonctions et des ressources en bon fonctionnement, et donc la liste des modes qui ne peuvent pas être présents dans un diagnostic. Cet ensemble est appelé ensemble des modes impossibles et nous notons Eimp l’ensemble de ces modes.

L’idée est que, dans la tâche du calcul des diagnostics par l’algorithme de l’arbre HS (an-nexe A),si un mode impossible est détecté (par la comparaison entre le mode considéré et ensemble des modes impossibles), la construction du diagnostic en cours est arrêtée car elle conduira à un diagnostic impossible. L’ensemble de modes impossibles E_impest ainsi géré dans la construction de l’arbre HS de la façon suivante : Si un conflit S est étiqueté à un noeud n sur l’arbre HS (voir en détail la méthode de construction de l’arbre HS à partir de l’ensemble de conflits dans l’annexe A), les branches descendantes seront étiquetées par les éléments impli-qués dans S. Supposons que mode_j(I) est étiqueté à une branche. Si mode_j(I) ∈ E_imp, alors la branche est fermée car mode_j(I) ne sera pas un diagnostic et il est exonéré.

L’intégration de la gestion des modes non possibles permet de réduire la taille de l’arbre HS.

Classement des diagnostics (bloc (4d) sur la figure 3.2) Les diagnostics trouvés par l’algorithme pourront donc :

– soit être classés en fonction de la mesure de coïncidence, qui présente l’avantage d’être simple à évaluer, mais qui repose sur la structure des tests et non sur la fiabilité des éléments du système,

– soit être classés en fonction de leur probabilité, qui prend en compte la fiabilité du sys-tème, mais nécessite plus d’information de la part de l’expert.

Ceci peut être consulté en détail dans l’annexe A.

3.3.3 Conclusion

Nous avons proposé dans cette section 3.3 l’ensemble des tâches de l’automate pour ré-soudre le problème formulé par l’expert à chaque itération dans le processus de diagnostic via le modèle FIS (résumé par la section 3.2). Ces tâches sont résumées sur la figure 3.2, page 70. Elles correspondent aux blocs (3) et (4) sur la figure 3.1, page 67.