Extracting Causality Graph from Ecosystem Simulation

Extracting Causality Graph from Ecosystem Simulation

•

Advisors: S. Tixeuil, J. Gignoux

•

Prerequisite: Graphs, Dynamic Graphs, Java Programming

•

Interdisciplinar

(CS/Ecology)

Formal Methods for Mobile Robots

•

Advisors: S. Tixeuil, N. Sznajder

•

Prerequisite: Coq proof assistant, Model-checking, mobile robots (ANET),

probabilistic algorithms

•

PhD funding

sp´ecification quel que soit le comportement de l’environnement au cours de l’ex´ecution.

Un contrˆoleur distribu´e est un syst`eme compos´e de contrˆoleurs locaux, un pour chacun des processus qui forment le syst`eme distribu´e, chaque contrˆoleur local ´etant synchronis´e avec son processus associ´e. Cette synchronisation restreint ainsi l’ensemble des actions locales possibles. Dans le contexte r´eparti, il ne s’agit ´evidemment pas de construire un contrˆoleur centralis´e qui aurait une vue globale. Les travaux de [PR90] ont montr´e que le probl`eme ´etait ind´ecidable en g´en´eral. Par ailleurs le probl`eme de synth`ese param´etr´ee se ram`ene `a celui de la synth`ese distribu´ee [JB12] et est donc ind´ecidable.

3 Contributions

3.1 V´ erification d’algorithmes de robots

Dans ce travail, nous nous sommes int´eress´es `a un mod`ele de processus que l’on ap- pellera par la suite robot, qui a ´et´e introduit par Suzuki et Yamashita [SY99]. Ce mod`ele a un comportement synchrone et est appel´e SYm (ou ATOM), il a ´et´e am´elior´e par Prencipe [Pre00] afin de prendre en compte un comportement asynchrone plus r´ealiste pour des syst`emes distribu´es. Ce nouveau mod`ele porte le nom de CORDA.

Les robots fonctionnent selon un cycle compos´e de trois phases : Look, Compute et Move. Quand un robot ex´ecute la premi`ere phase, il examine l’environnement qui l’entoure et s’inscrit dans un rep`ere constitu´e par l’ensemble des autres robots. Dans la deuxi`eme phase, il calcule un futur mouvement en fonction de sa position relative aux autres robots, et enfin il met en œuvre le mouvement calcul´e dans la derni`ere phase.

Les algorithmes sont d’autant plus complexes que les capacit´es des robots y sont fortement restreintes :

– Les robots sont tous anonymes et identiques : ils vont tous ex´ecuter le mˆeme algo- rithme. Durant cette execution, ils ne pourront pas di↵´erencier les autres robots les uns des autres.

– Ils sont amn´esiques : ils ne peuvent se souvenir de leurs actions pr´ec´edentes.

– Ils ne peuvent pas communiquer entre eux directement (par messages ou variables partag´ees).

– Ils n’ont aucun sens de l’orientation : les robots ne peuvent se rep´erer dans l’espace que par leur position relative aux autres robots.

Afin de v´erifier les algorithmes de robots, nous proposons une mod´elisation propre `a ces algorithmes. On mod´elise tout d’abord les robots selon leur comportement, chacun d’entre eux sera donc mod´elis´e par l’automate de la figure 1. Le mod`ele peut ˆetre r´eduit

Ready to look

Ready to compute

Ready to move

Look Compute

Move

Figure 1 – Automate d’un robot

3

en combinant les phases Look et Compute afin d’obtenir une phase LC.

On construit de la mˆeme mani`ere, pour chaque ordonnanceur, un mod`ele qui, une fois synchronis´e avec l’ensemble des robots Rob, permet d’obtenir un syst`eme synchrone ou asynchrone. Les deux types d’ordonnanceurs sont pr´esent´es dans la figure 2.

Move Done

LC Done

Q

i2Rob

LCi

Q

i2Rob

Move_i

(a) SYm mod`ele

Act Done

Sched chosen

Choose Sched

Q

i2Sched

Act_i

(b) ASYNC mod`ele

Figure 2 – Automates des ordonnanceurs

On note LC

(respectivement Move

), la phase LC (resp. Move ) du i

robot. Et on note Q

i2Sched

LC

(respectiveement Q

i2Sched

Move

) la synchronisation des actions LC

(respectivement Move

) des robots pr´esents dans un sous esemble Sched ✓ Rob .

Afin de v´erifier les algorithmes de robots, nous avons cr´e´e un g´en´erateur de mod`eles qui, sur un anneau, et quelle que soit la tˆache `a e↵ectuer, prend en entr´ee la taille de l’anneau, le nombre de robots, le mod`ele d’ex´ecution du syst`eme et un algorithme `a v´erifier sous la forme de transitions gard´ees.

Le mod`ele du syst`eme est alors l’automate qui r´esulte de la synchronisation entre un des ordonnanceurs, les automates des robots, et l’ensemble des positions que peuvent occuper les robots sur le graphe (aussi appel´e configuration).

Grˆace `a cette mod´elisation nous avons pu v´erifier par model checking plusieurs ins- tances de deux algorithmes d’exploration d’un anneau : AlgoMin [BMPT10] et Floc- chini [FIPS07].

Ces algorithmes fonctionnent de mani`ere similaire : tout d’abord, on cherche `a at- teindre depuis n’importe quelle configuration (ensemble des positions des robots sur le graphe) un sous-ensemble stable de configurations pr´ed´efinies par l’algorithme. Une fois ce sous-ensemble de configurations atteint, l’algorithme r´ealise l’exploration en restant dans ce sous-ensemble de configurations.

Chaque algorithme d´efinit des classes de configurations disjointes `a partir desquelles le calcul par lequel le robot connait son futur mouvement est donn´e.

Pour chaque algorithme nous avons tout d’abord v´erifi´e par model-checking que les robots atteignaient bien ce sous-ensemble de configurations puis qu’`a partir de ce sous- ensemble tous les nœuds du graphe ´etaient bien visit´es.

3.1.1 AlgoMin

L’objectif de cet algorithme est de r´ealiser une exploration perp´etuelle et exclusive avec trois robots quelle que soit la taille de l’anneau. : tous les nœuds doivent ˆetre visit´es

4