• Aucun résultat trouvé

Probl´ ematique

La s´election d’un unique ´etat estim´e parmi les candidats `a chaque ´etape discr`ete peut parfois mener `a des incoh´erences entre la trajectoire d’´etats estim´es et la s´equence d’obser-vations re¸cue, on parle alors de sc´enario d’impasse. Le ph´enom`ene de l’impasse est illustr´e ici et l’impasse sera d´efinie dans le chapitre suivant.

Exemple 7 (Sc´enario d’impasse dans l’estimation). On reprend s0, ∆ et Γ des exemples 2 et 4. On consid`ere que l’observation o1= moveengine est re¸cue. Conform´ement `a l’exemple pr´ec´edent, en appliquant Γ, on s´electionne donc l’´etat estim´e ˆs1 = s01 = moveengine. On

estime donc qu’une faute affecte le moteur.

Cependant, il est possible que pour la s´equence d’observations (o0, o1), le syst`eme ai ´evolu´e dans l’´etat s1 = move engine fengine fmove puis revienne dans l’´etat initial `a l’´etape suivante en produisant l’observation o2 = o0 = move engine. Lorsque l’estimateur essaye de g´en´erer les candidats pour o2 et son ´etat pr´ec´edent s01, il est impossible de trouver une affectation de fengine et fmove satisfaisant ∆.

Il existe une s´equence d’´etats estim´es pour la s´equence d’observations (o0, o1, o2) : c’est

la s´equence (s0, ˆs1). Cependant, il n’y a pas de s´equence d’´etats estim´es pour la s´equence d’observations (o0, o1, o2), l’estimateur rencontre une impasse dans l’estimation et perd la

coh´erence avec le mod`ele comportemental du syst`eme. On appelle un tel ph´enom`ene un sc´enario d’impasse.

´

Etape i oi si ˆsi

0 move engine fengine fmove fengine fmove

1 move engine fengine fmove fengine fmove

2 move engine fengine fmove /

Figure 3.3 – Sc´enario d’impasse illustr´e dans l’exemple 7. Les colonnes si et ˆsirepr´esentent respectivement les ´etats du syst`eme et les ´etats estim´es pour l’´etape i. On omet les variables de O dans les deux derni`eres colonnes car celles-ci sont identiques `a celles de la colonne oi, et on ne repr´esente que les variables estim´es de E.

Le ph´enom`ene de l’impasse ne touche pas forc´ement tous les mod`eles d´efinis avec le formalisme (s0,∆, Γ). Dans cet exemple, la situation d’impasse pourrait ˆetre ´elimin´ee en changeant l’ordre ou les conditions des pr´ef´erences.

Exemple 8 (Mod`ele d’estimation sans impasse). Pour le mod`ele (s0,∆) de l’exemple 2, il est possible de construire un mod`ele de pr´ef´erences qui ne rencontre pas d’impasse. Par exemple en inversant l’ordre des pr´ef´erences de l’exemple 4, on obtient alors le mod`ele Γ0 suivant :

Γ0= ¬engine : fengine≺ fengine 1) pre fmove: fmove≺ fmove 2)

!

En partant de l’´etat initial s0 et en recevant l’observation o1 = moveengine, on

ob-tient toujours les mˆeme candidats de l’exemple 3. Cependant, l’´etat estim´e sera diff´erent puisque les pr´ef´erences ne sont pas ´evalu´ees dans le mˆeme ordre. Puisque engine est vraie, la premi`ere pr´ef´erence (γ1) ´elimine les candidats dans lesquels la faute fengine est pr´esente. Il ne reste alors que l’´etat s1 = moveenginefenginefmove qui sera donc l’´etat unique estim´e. Or si le syst`eme re¸coit ensuite l’observation o2 = o0= moveengine comme dans l’exemple 7, il existe des candidats pour l’´etat pr´ec´edent s1 et l’observation o2. L’´etat unique estim´e sera alors s0 (le seul candidat dans ce cas pr´ecis). Il existe donc une s´equence d’´etats estim´es

( ˆs0, ˆs1, ˆs2) en utilisant Γ0 qui permet une estimation de la s´equence d’observations (o0, o1, o2)

avec :

— ˆs0 = s0 — ˆs1 = s1 — ˆs2 = s0

Cependant, d`es lors que l’on s’int´eresse `a des syst`emes plus complexes, il devient difficile de d´etecter ces sc´enarios d’impasse et encore plus de les r´esoudre. Il est donc souhaitable d’ˆetre capable, `a partir de la description d’un syst`eme et de sa strat´egie d’estimation, de d´etecter la possibilit´e de rencontrer un sc´enario d’impasse dans l’estimation.

efinition 29 (Fonction estimateur). Pour un estimateur, on d´efinit une fonction par-tielle estimSeq qui prend en entr´ee une s´equence d’observations et qui retourne la s´equence d’estimation lorsque celle-ci existe. Formellement pour une s´equence d’observations seqObs ∈

Lobs(∆), estimSeq : O → S est d´efinie telle que :

estimSeq =

(

s0, ˆs1, ˆs2, .., ˆsn) tel que ∀i ∈ 1..n, ˆsi= estim(ˆsi−1, obs(seqObs(i))) ind´efinie sinon (impasse)

)

Les probl´ematiques de ce document s’articulent autour du probl`eme de l’impasse. Dans le chapitre 4, la possibilit´e de d´etecter un sc´enario d’impasse dans l’estimation est ´etudi´ee.

`

A partir d’un sc´enario d’impasse, on cherche `a blˆamer certaines des pr´ef´erences dans le chapitre 5. Enfin, le chapitre 6 explore la possibilit´e de construire des estimateurs sans sc´enario d’impasse `a partir des sp´ecifications d’un syst`eme.

Deuxi`eme partie

Chapitre 4

etection d’un sc´enario d’impasse

Dans le chapitre pr´ec´edent, un formalisme permettant de r´ealiser l’estimation `a ´etat unique des syst`emes `a ´ev`enements discrets a ´et´e pr´esent´e. Cependant, l’estimation `a ´etat unique est sujette `a certaines limites, notamment les impasses dans l’estimation, comme illustr´e pr´ec´edemment.

Certaines approches de la litt´erature proposent des processus d’estimation incr´ementale et des m´ecanismes permettant la gestion des impasses. [Grastien et al., 2005] propose de remettre `a z´ero le processus d’estimation lorsque pendant l’ex´ecution la trajectoire d’´etats estim´es n’est plus coh´erente avec la dynamique du syst`eme. Ce m´ecanisme a cependant pour inconv´enient de perdre momentan´ement la coh´erence avec la dynamique du syst`eme. Les auteurs de [Kurien and Nayak, 2000] proposent un retour en arri`ere dans la s´equence et reviennent sur un choix de transition pour retrouver la coh´erence. Ces m´ecanismes ne sont pas envisageables dans notre approche car coˆuteux en terme de temps de calcul et ce n’est pas souhaitable lorsqu’on traite d’architectures autonomes souvent limit´ees en ressources. Ce ph´enom`ene peut toutefois ˆetre att´enu´e, notamment en certifiant une fenˆetre (un nombre d’´etats) sur laquelle on peut revenir en arri`ere [Su et al., 2014]. Cependant, le module de planification aura certainement envisag´e des actions, bas´ees sur les pr´ec´edentes estimations, sur lesquelles un retour en arri`ere est souvent impossible. De mˆeme, autoriser l’estimateur `

a franchir des transitions qui ne font pas partie du mod`ele peut poser des probl`emes par rapport au module de planification. C’est pourquoi dans notre approche on interdit le pro-cessus de retour en arri`ere sur les ´etats estim´es, afin de garantir une estimation toujours coh´erente au fil du temps et peu coˆuteuse en terme de calcul, ce qui est impossible lorsque l’estimateur risque de rencontrer des impasses.

Le chapitre pr´ec´edent pr´esentait le processus d’estimation en ligne utilis´e dans ce do-cument. Dans ce chapitre, on s’int´eresse `a la v´erification hors-ligne de propri´et´es pour un syst`eme et son estimateur. On ´etudie ici `a la possibilit´e de d´etecter les sc´enarios d’impasse lors de la phase de conception de l’estimateur.

Pour cela on formalise dans un premier temps le ph´enom`ene de l’impasse pour un syst`eme et son estimateur. Ensuite, on s’int´eresse `a la v´erification de la pr´esence de sc´enario d’impasse `a partir des sp´ecifications d’un syst`eme et de son estimateur. La m´ethode utilis´ee s’inspire des approches de type Twin-Plant [Jiang et al., 2001], [Cimatti et al., 2003], [Pencole, 2005] une m´ethode permettant `a l’origine de v´erifier la diagnosticabilit´e d’un syst`eme. On adapte cette m´ethode afin de pouvoir simuler l’ex´ecution d’un syst`eme et de son estimateur et d´etecter un ou plusieurs sc´enarios d’impasse s’ils existent. Cette m´ethode formelle est, lors d’une premi`ere approche, encod´ee en Electrum, un outil de model-checking adapt´e pour des syst`emes `a dynamique `a la fois complexe et temporelle. La deuxi`eme ap-proche consiste `a simuler l’ex´ecution du syst`eme par l’interm´ediaire de requˆetes it´eratives en SAT puis de tenter de g´en´erer des s´equences d’estimations avec un solver MAX-SAT. Chaque approche est accompagn´ee d’exp´erimentations.

4.1 Formalisation de l’impasse

On s’int´eresse dans un premier temps `a la formalisation du ph´enom`ene de l’impasse entre un syst`eme et son estimateur. On propose une d´efinition pour les sc´enarios d’im-passe. Un estimateur est en situation d’impasse lorsque celui-ci ne peut plus fournir une estimation coh´erente par rapport au mod`ele comportemental du syst`eme et la s´equence d’ob-servations re¸cue. Plus g´en´eralement, on consid`ere un sc´enario d’impasse lorsqu’il existe une s´equence d’´etats estim´es pour laquelle il n’existe aucune continuation possible par rapport `

a la s´equence d’observations re¸cue.

efinition 30 (Impasse). Un mod`ele d’estimation (s0, ∆, Γ) rencontre une impasse pour une s´equence d’observations (o0, o1, o2, . . . , ok) avec k > 1 si et seulement si :

1. il existe une s´equence d’´etats estim´es pour (o0, . . . , ok−1), et

2. il n’existe aucune s´equence d’´etats estim´es pour (o0, . . . , ok)

Remarque. Il ne peut y avoir d’impasse `a ˆs1 car on suppose que l’estimateur est correcte-ment initialis´e `a s0.

Dans l’exemple 7 vu en fin de chapitre pr´ec´edent, le sc´enario d’impasse peut ˆetre ´elimin´e simplement en inversant l’ordre des pr´ef´erences. Il existe d’autres mani`eres de modifier Γ afin d’´eviter les impasses, par exemple en modifiant les conditions de certaines pr´ef´erences. Cette probl´ematique sera trait´ee dans le chapitre suivant.

On s’int´eresse dans ce chapitre `a la recherche de sc´enarios d’impasse dans les mod`eles d’estimation en amont de leur d´eploiement afin d’anticiper ces situations avant qu’elles ne surviennent en mission. On peut ainsi valider le bon fonctionnement d’un estimateur si celui-ci n’est pas sujet aux sc´enarios d’impasse ou dans le cas contraire modifier les contraintes du mod`ele ou les pr´ef´erences de l’estimateur. Les deux prochaines sections pr´esentent deux approches qui permettent la d´etection hors ligne d’un sc´enario d’impasse dans l’estimation.