Introduction des Tests

Nous traitons ici le cas o`u certains observables ne remontent pas spontan´ement mais correspondent `a des tests `a d´eclencher (ou `a des requˆetes `a ex´ecuter). Dans ce cas, certains observables de <sub>O</sub> sont ´etiquet´es comme des tests (i.e. appartiennent `a T). Nous tenons compte ainsi de la pr´esence des nœuds _Tqui permettent d’ajouter des observables lors du d´eroulement de notre algorithme.

6.5.1 Proposition initiale pour le lancement des Tests

L’id´ee initiale ´etait de reproduire la mˆeme d´emarche que l’algorithme de base (dans les sections 6.2et6.3 ) et `a chaque fois qu’une hypoth`ese traite un nœud de test, le test associ´e sera ex´ecut´e. Les hypoth`eses qui sont closes `a ce stade seront revues en ´eclaircissement du r´esultat du test.

En effet, deux processus s´epar´es sont utilis´es : le premier pour l’ex´ecution du diagnostiqueur et un deuxi`eme pour le lancement des tests. Le d´eroulement de l’algorithme est donc le suivant :

– Commencer le processus de diagnostic par le d´eveloppement des hypoth`eses.

– Une fois qu’une hypoth`ese a besoin d’un r´esultat de test, arrˆeter le processus de diagnostic en cours :

1. Lancer le test d’abord ;

2. Ensuite, l’hypoth`ese qui a lanc´e le test ainsi que les hypoth`eses sup-pos´ees closes `a ce stade sont r´einitialis´ees et ins´er´ees de nouveau dans

6.5. Introduction des Tests 85

l’ensemble des hypoth`eses `a traiter. La r´einitialisation consiste `a rame-ner l’hypoth`ese `a son ´etat initial avec ses ensembles initiaux de nœuds innocents et coupables.

De cette mani`ere, les hypoth`eses seront retrait´ees en prenant en consid´eration les r´esultats des tests.

6.5.2 Solution am´ elior´ ee pour un diagnostic insuffisant

En regardant le d´eroulement de cette impl´ementation de l’algorithme, nous nous sommes aper¸cus que les hypoth`eses ne prennent en consid´eration que le r´esultat des tests qui apparaissent dans l’ensemble des nœuds coupables ou innocents. Ce r´esultat n’est bien ´evidemment pas satisfaisant puisqu’on aura des cas o`u l’hypoth`ese peut ˆetre close mais elle ne permet pas d’expliquer toutes les observations (les alarmes d´eclench´ees et les nœuds tests estim´es coupables). Un cas pr´esent´e dans la Figure 6.1 peut donc avoir lieu. Les hypoth`eses (partie gauche du graphe) sont closes alors que toutes les observations n’ont pas ´et´e expliqu´ees.

Client Barring in HSS

Alarm unknown IMPU in AS IMPU unknown

in AS

AS no synchronizaton

IMPU barring in AS Client barring in

AS

Resynchro-nization AS

Test of client barring Client No payment

Figure 6.1 – Exemple d’un diagnostic insuffisant

Cette premi`ere approche d’int´egration des tests dans le d´eroulement de

l’algo-86 Chapitre 6. L’Algorithme de Diagnostic de base

rithme pr´esente ainsi les deux probl`emes suivants :

– Le manque d’optimisation en traitant plusieurs fois une mˆeme hypoth`ese si elle ´etait consid´er´ee close `a un moment et qu’ensuite, plusieurs tests sont lanc´es.

– La possibilit´e de retenir des diagnostics partiels qui ne permettent pas d’ex-pliquer tous les observables.

Afin de pallier ces probl`emes, une solution ´etait de faire une s´eparation entre le processus de d´eveloppement des hypoth`eses et celui du lancement des tests. D`es que le processus de d´eveloppement des hypoth`eses est termin´e, le processus de lancement de tous les tests peut commencer. Il n’y aura donc pas d’interruption du diagnostiqueur pour ex´ecuter les tests. La proc´edure5, ci-dessous, d´ecrit le processus de calcul de l’ensemble D⁰ de diagnostic consistant avec les tests.

Proc´edure 5 Calcul de l’ensemble D⁰ de diagnostic consistant avec les tests Pr´e-requis : D : l’ensemble de diagnostic `a traiter ; _T : l’ensemble des tests

disponibles.

1: D⁰₌∅, D⁰ : l’ensemble du diagnostic consistant avec les tests

2: pour tout D∈ D faire

3: T ← T ∪_(T∩Sb(D)) 4: fin pour

5: ex´ecuter les tests dans T

T_I : l’ensemble des tests de r´esultat Innocent T_G : l’ensemble des tests de r´esultatGuilty

6: pour tout D∈ D faire

7: siT_I ∩Sb(D) =∅ alors

8: D⁰← D⁰∪ {D} (D est consistant avec les tests)

9: fin si

10: fin pour

11: renvoyer D⁰

Deux nouveaux ensembles de nœuds ont ´et´e ajout´es afin d’assurer cette s´ e-paration de processus : Un ensemble de nœuds suppos´es innocents et Un ensemble de nœuds suppos´es coupables.

6.5. Introduction des Tests 87

Ces deux ensembles ne peuvent contenir que des observables. Un nœud de test est ins´er´e dans l’ensemble des nœuds suppos´es innocents si par propagation, l’hypo-th`ese suppose que ce nœud estInnocent. Un nœud de test est ins´er´e dans l’ensemble des nœuds suppos´es coupables si par propagation, l’hypoth`ese suppose que ce nœud est Guilty.

L’ensemble des nœuds suppos´es innocents doit aussi contenir pour chaque hy-poth`ese tous les observables qui ne sont ni innocents, ni coupables, ni suppos´es coupables par cette hypoth`ese. Ainsi, chaque hypoth`ese sera au courant du d´ eclen-chement d’une alarme et du changement d’´etat d’un nœud de test. En proc´edant ainsi, on contourne le probl`eme d’avoir des diagnostics partiels.

En se basant sur ces nouveaux ensembles, nous pouvons suivre la mˆeme d´ e-marche que pour l’algorithme de base. Nous nous trouvons `a la fin avec un ensemble d’hypoth`eses closes. Parmi ces hypoth`eses, il y a celles qui ont ´et´e d´evelopp´ees avec une supposition sur l’´etat de ces nœuds observables.

Ensuite, il est possible de commencer le processus de lancement des tests. C’est l’existence d’un nœud_Tdans l’ensemble des nœuds suppos´es innocents ou des nœuds suppos´es coupables d’une certaine hypoth`ese qui provoque le lancement du test.

L’´etat d’un observable doit ˆetre communiqu´e `a l’ensemble des hypoth`eses. Ainsi, nous associons un historique `a chaque nœud observable dans lequel sont marqu´es les intervalles de temps pendant lesquels le nœud est coupable ou innocent. Un mˆeme test ne sera ex´ecut´e qu’une seule fois mˆeme s’il a ´et´e suppos´e innocent (ou coupable) par plusieurs hypoth`eses.

D`es que nous disposons du r´esultat d’un test, nous devons aussi propager l’´etat du nœud correspondant tout au long du graphe causal. Cette propagation peut induire des inconsistances de certaines hypoth`eses qui seront ´elimin´ees du r´esultat du diagnostic. Nous nous retrouvons au final avec un diagnostic permettant d’ex-pliquer tous les observables d’une entit´e du syst`eme autonome. En revanche, les observables d’autres entit´es peuvent avoir un ´etat qui permet de changer le r´esultat du diagnostic. C’est ainsi qu’un algorithme distribu´e (pr´esent´e dans le Chapitre 7) a ´et´e con¸cu.

88 Chapitre 6. L’Algorithme de Diagnostic de base

6.5.3 Politiques de lancement des Tests

La politique de choix du test peut s’appuyer sur le coˆut induit par le test (en terme de d´elai, de ressource informatique, etc.). Nous proposons trois politiques de lancement des Tests pour bien optimiser le processus de diagnostic par rapport `a diff´erentes conditions :

– Lancer tous lesTests avant le processus de diagnostic : cette politique s’ap-plique au cas o`u nous connaissons tous les ´etats des nœuds dans le syst`eme.

– Lancer lesTests avecun ensemble de nœuds suppos´es innocentsetun ensemble de nœuds suppos´es coupables: cette politique s’applique au cas de la distribution, si un diagnostiqueur local«A» ne connaˆıt pas tous les

´etats du nœud du syst`eme, mais a besoin de connaˆıtre l’´etat du nœud d’un autre diagnostiqueur «B», en mˆeme temps, si «B» n’a pas encore fini son processus de diagnostic,«A»peut d’abord supposer le nœud dont il a besoin innocent ou coupable, puis l’ajouter dans son hypoth`ese. Pour cette politique, il faut bien consid´erer le coˆut (des intervalles de temps et des ressources) avant de l’utiliser.

– Lancer tous les Tests d`es l’ach`evement du diagnostic : cette politique per-met de juger si les hypoth`eses du diagnostic sont inconsistantes ou pas, afin d’´eliminer certains r´esultats de diagnostic.

Le d´eveloppement d’un algorithme peut alors passer par le choix des tests `a ex´ecuter.