L’absence de résultats de la part des requêtes ne veut pas dire qu’il n’est pas possible de tirer de conclusion sur ce travail. En effet, il a été possible de voir que l’existence d’un chemin pour un
seul critère est facilement vérifiable, mais que l’implication reste compliquée à vérifier (temps de réponse trop long). Cette complexité vient de la part non-déterministe du modèle, ce qui est appelé aléatoire dans les modèles numériques classiques. En effet, comme dit précédemment, la partie non- déterministe permet par l’utilisation des requêtes d’intégrer toutes les possibilités au cours d’une seule simulation.
Contrairement aux requêtes portant sur l’existence avec un seul critère, celles avec les deux critères ont été plus compliquées à vérifier. Le temps de réponse et le nombre d’états testés étaient bien supérieurs à ce qui était nécessaire pour les requêtes à un critère. Certaines, les plus restrictives sur les critères d’évolutions, n’ont d’ailleurs pu être résolues par Uppaal, par manque de mémoire disponible. Ce point montre que ces nouvelles approches en modélisation sont encore en développement. L’un des enjeux et de réussir à réduire la taille de l’espace de recherche pour Uppaal, qui dépend du produit du nombre de localisation de chaque automate par le nombre de liaisons possible pour chaque état du système. En ce qui concerne les liaisons, le problème se pose essentiellement lors du tirage aléatoire d’une valeur dans un intervalle, comme cela a été évoqué précédemment. Pour les automates, un des objectifs seraient de réduire le nombre d’automates, notamment en travaillant sur la dispersion, qui représente plus de la moitié des automates. Même si ces automates sont relativement de petites tailles, leur nombre joue de façon importante sur l’exploration des évolutions.
Conclusion
Après avoir vu les forces et les faiblesses de la modélisation qualitative, et plus particulièrement des automates temporisés, nous avons vu qu’il est possible de représenter des agro-écosystèmes à l’aide de ces approches qualitatives. La représentation de la compartimentation d’un paysage, mais également les flux de population en son sein ont été réalisées pour la première fois et permettent une simplifi- cation des populations représentées en ne s’intéressant pas à leurs fluctuations mineures. Il est donc possible de modéliser les évolutions spatiales par un modèle qualitatif sans pour autant trop dégrader le processus de représentation.
L’absence de résultats du de vue des critères d’évolution a permis de montrer qu’il était encore né- cessaire de développer des outils plus performants en lien avec les automates temporisés, et qu’il est nécessaire de réfléchier à la compléxité d’un modèle lors de sa réalisation. En effet, plus un modèle sera complexe, plus les simulations nécessiteront des moyens importants. Il est donc nécessaire de faire des compromis entre l’exactitude du modèle et les moyens à disposition.
Il serait donc intéresser de pouvoir comparer les résultats entre approche numérique et approche quali- tative, en comparant leurs forces et leurs faiblesses grâces aux résultats. Cela nécessite cependant des outils plus performants que ceux existants déjà pour des applications réelles.
Références
[1] Alexandre David, Tobias Amnell, and Martin Stigge. Uppaal Small Tutorial.
[2] Rajeev Alur. Timed Automata. In Nicolas Halbwachs and Doron Peled, editors, Computer Aided Verification, number 1633 in Lecture Notes in Computer Science, pages 8–22. Springer Berlin Heidelberg, 1999.
[3] Gerd Behrmann, Re David, and Kim G. Larsen. A tutorial on uppaal. pages 200–236. Springer, 2004.
[4] Patricia Bouyer. Weighted Timed Automata : Model-Checking and Games. Electronic Notes in Theoretical Computer Science, 158 :3–17, May 2006.
[5] Patricia Bouyer and François Laroussinie. Model Checking Timed Automata. In Stephan Merz and Nicolas Navet, editors, Modeling and Verification of Real-Time Systems, pages 111–140. ISTE, 2008.
[6] Bert Bredeweg and Paulo Salles. Qualitative models of ecological systems — Editorial intro- duction. Ecological Informatics, 4(5–6) :261–262, November 2009.
[7] European comission. Quantitative versus qualitative methods, 2005.
[8] Marie-Odile Cordier, Christine Largouët, and Yulong Zhao. Model-Checking an Ecosystem Model for Decision-Aid. In IEEE 26th International Conference on Tools with Artificial Intelli- gence, Limassol, Cyprus, November 2014.
[9] Jeffrey M. Dambacher, Hiram W. Li, and Philippe A. Rossignol. Qualitative predictions in model ecosystems. Ecological Modelling, 161(1–2) :79–93, March 2003.
[10] Christine Largouët, Marie-Odile Cordier, Yves-Marie Bozec, Yulong Zhao, and Guy Fontenelle. Use of timed automata and model-checking to explore scenarios on ecosystem models. Environ- mental Modelling & Software, 30 :123–138, April 2012.
[11] F. Laroussinie, N. Markey, and Ph. Schnoebelen. Efficient timed model checking for discrete- time systems. Theoretical Computer Science, 353(1–3) :249–271, March 2006.
[12] Andre Botequilha Leitao, Joseph Miller, Jack Ahern, and Kevin McGarigal. Measuring Land- scapes : A Planner’s Handbook. Island Press.
[13] J. D. Murray, editor. Mathematical Biology, volume 18 of Interdisciplinary Applied Mathema- tics. Springer-Verlag, New York, 1993.
[14] Louise Trave-Massuyes, Liliana Ironi, and Philippe Dague. Mathematical Foundations of Qua- litative Reasoning. AI Magazine, 24(4) :91, December 2003.
[15] Louise Travé-Massuyès, Francesc Prats, Mónica Sánchez, and Núria Agell. Relative and ab- solute order-of-magnitude models unified. Annals of Mathematics and Artificial Intelligence, 45(3-4) :323–341, December 2005.
[16] Shengsheng Wang and Dayou Liu. Knowledge representation and reasoning for qualitative spa- tial change. Knowledge-Based Systems, 30 :161–171, June 2012.
[17] Yulong Zhao. Modélisation qualitative des agro-écosystèmes et aide à leur gestion par utilisation d’outils de model-checking. phdthesis, Université Rennes 1, January 2014.
[18] Yulong Zhao, Christine Largouët, and Marie-Odile Cordier. EcoMata : Un logiciel d’aide à la décision pour améliorer la gestion des écosystèmes. Ingénierie des Systèmes d’Information, 16(3) :85–111, 2011.
Annexe 1
|Définitions formelles des automates tem-
porisés
Définition d’un automate temporisé : un automate temporel est un n-uplet hL, L0, ∑, X, Inv, Ei, [2], [5] où :
— L : ensemble de localisations
— L0⊆ L : ensemble de localisations initiales — ∑ : ensemble d’actions
— X : ensemble d’horloges
— Inv : ensemble des conditions d’invariances de chaque état
— E ⊆ L × ∑ ×2X× φ (X) × L : un ensemble de transitions entre états, avec φ (X) l’ensemble des contraintes temporelles.
Les contraintes pouvant s’appliquer sont celles liées à des comparaisons relatives. On note ν l’inter- prétation d’une horloge de X. Elle assigne à chaque horloge une valeur (rationnelle, entière ou réelle selon les automates). On dit que ν satisfait une contrainte temporelle ϕ ∈ φ si et seulement si ϕ est estimée vrai si elle est en accord avec les valeurs données par ν.
Définition d’un système de transition On modélise le système à l’aide de graphiques de transitions entre états. Un système de transition est un n-uplet hL, L0, ∑, →i, avec :
— L : un ensemble d’états
— L0⊆ L, un ensemble d’états initiaux — ∑ : un ensemble d’événements
— E ⊆ Q × ∑ ×Q : un ensemble de transitions. Un changement hs, a, ϕ, λ , s0i est une transition de s à s’, sur un événement a. ϕ est une contrainte temporelle sur X et λ ⊆ X donne l’ensemble des horloges à remettre à zéro.
On note SAle système de transition associé à l’automate A
Définition d’une transition dans SA On définit une transition hl, a, l0i de →, allant de la l’état l
à l0, par l’événement a. On peut également l’écrire l −→ la 0. Un système complexe peut être défini
comme un produit de système de transition. On définit un automate temporisé A en l’associant avec un système de transition SA. Un état de SAest une paire (s, ν) où s est une localisation de A, et ν est
une horloge de X qui satisfait les invariants Inv(s). Il existe deux types deux transitions dans SA:
— une transition due à un écoulement de temps où la localisation de bouge pas. ∀δ> 0, (s, ν)−→δ (s, ν + δ ) si ∀0 > δ0> δ , ν + δ satisfait les invariants Inv(s)
— une transition due à un changement de localisation, où le temps ne change pas, mais certaines horloges peuvent êtres réinitialisées. Pour un état (s, ν) et un changement hs, a, ϕ, λ , s0i tel que ν satisfait ϕ , (s, ν )−→ (sa 0, ν[λ := 0]). ν[λ := 0]) signifie que ν(x) = 0 si x ∈ λ . De façon plus simple, si λ est l’ensemble des horloges de X qui sont réinitialisées suite à la transition. Un seul type des deux types de transitions évoquées peut se dérouler à un même instant, même si plusieurs transitions d’un même type peuvent se dérouler en même temps. Par exemple, toutes les horloges incrémentent en même temps, avec le principe qu’elles s’écoulent à la même vitesse. (Si une horloge augmente d’une seconde, alors toutes les autres horloges augmentent aussi d’une seconde). Sinon, plusieurs évolutions de localisations entre plusieurs automates peuvent aussi avoir lieu à un même instant (du point de vue temporel).
Définition d’un Produit synchronisé On définit par Produit synchronisé le produit de deux au- tomates temporisés [2]. Soient A1 = hL1, L01, ∑1, X1, Inv1, E1i et A2= hL2, L02, ∑2, X2, Inv2, E2i deux
automates temporisés, avec deux ensembles d’horloges disjoints X1∩ X2= /0. Alors le produit A1kA2
est un automate temporisé hL1× L2, L01× L02, ∑1∪ ∑2, X1∪ X2, Inv, Ei, où Inv(s1, s2) = Inv(s1) ∧ Inv(s2)
et les horloges sont définies par :
— for a ∈ ∑1∩ ∑2, ∀hs1, a, ϕ1, lambda1, s01i ∈ ∑1 et ∀hs2, a, ϕ2, lambda2, s02i ∈ ∑2 , E contient
h(s1, s2), a, ϕ1∧ ϕ2, λ1∪ λ2, (s01, s02)i
— Si a ∈ ∑1\ ∑2, ∀hs, a, ϕ, λ , s0i ∈ E1et ∀ ∈ L2, alors E contient h(s,t), a, ϕ, λ , (s0,t)i
— Si a ∈ ∑2\ ∑1, ∀hs, a, ϕ, λ , s0i ∈ E2et ∀ ∈ L1, alors E contient h(t, s), a, ϕ, λ , (t, s0)i
Annexe 2
|
Utilisation d’Uppaal
Uppaal 4.0 est un outil développé par les universités d’Uppsala (Suède) et d’Aalborf (Danemark) [1], [3] (D’où le nom qui est la fusion du début des deux noms). Il permet la synthèse d’automates tempori- sés et la synchronisation entre plusieurs d’entre eux. Pour cela, il s’appuie sur les définitions évoquées précédemment sur un (ou plusieurs) modèle(s) et le(les) système(s) de transition(s) associé(s). Une fois les automates créés, il permet d’utiliser des outils de model-checking pour tester certaines condi- tions sur les événements possibles au cours de simulation.
On distingue donc deux parties :une première de création des automates et leurs synchronisations (Figure 14), accompagnée de la vérification des syntaxes et de la possibilité de tester l’évolution du système ; une seconde pour le model-checking permettant de tester les contraintes désirée Nous allons rapidement évoquer ces deux parties et leur mode de fonctionnement propre.
FIGURE14 – Interface d’Uppaal pour les automates
En ce qui concerne les créateurs d’automates, elle utilise des templates qui correspondent aux auto- mates. Pour chaque template, on définit deux types d’objets principaux :
— Location : il s’agit des localisations du systèmes. Il est possible :
initial : localisation à partir de laquelle le template sera lancé pour les simulations.
urgent : quand une telle localisation est atteinte, le temps ne peut plus s’écouler tant que l’automate reste dans cet état. Il est cependant possible que d’autres automates évoluent avant que cette localisation ne soit quittée.
commited : un peu comme l’état urgent, le temps reste bloqué tant que l’automate reste à cette localisation. Cependant, seules d’autres automates étant aussi sur des localisations committedpeuvent évoluer, il est plus restrictif que l’état urgent. On limite donc l’évolution à certains cas précis (qu’on peut qualifier de prioritaires).
Pour chaque localisation on peut également établir les invariants, conditions qui quand elles sont ne respectées pas, obligent l’évolution du système.
— Edge : ils permettent les transitions entre les états du système selon les contraintes établies dessus. On distingue quatre éléments pour chaque liaison :
select : Permet d’attribuer une valeur aléatoire à une variable.
guard : Ensemble des conditions à vérifier pour que cette transition ait lieu
Synchr : permet la synchronisation entre deux ou plus automates pour des évolutions simul- tanées. Pour cela, il faut créer une action (a) avec un émetteur(a !) et un receveur(a ?) ou plusieurs (selon la nature de la synchronisation).
Update : lors du passage de par cette liaison, elle permet de modifier les valeurs de certaines variables (comme la mise à zéro des horloges par exemple)
A partir de ces outils, on peut créer un ou plusieurs automates, avec des variables propres à chaque automate ou globales. On a donc une forme de "super-automate" qui s’occupe de gérer tous les autres automates (les templates) et de les faire communiquer entre eux.
A l’aide de l’onglet simulation, il est possible de tester le "super-automate" créé (avec une vérification de la syntaxe préalable). Cela permet de tester les évolutions que peut prendre le modèle à partir des contraintes qu’il possède et vérifier que certaines évolutions existent bien. On peut y choisir soi- même les évolutions possibles, ou bien laisser le logiciel générer aléatoirement un chemin en suivant l’évolution au fur et à mesure. Enfin, à l’aide du dernier onglet, il est possible d’y réaliser du model- checking à l’aide de requête TCTL. Une grammaire adaptée y est développée mais elle permet toutes les requêtes classiques de ce genre de logique.
Il existe plusieurs extensions à Uppaal pour des besoins spécifiques qui n’existent pas forcément dans la version d’origine. C’est le cas d’Uppaal-Tiga qui permet de générer des automates de façon auto- matique à partir de modèles, ce qui évite de devoir tous les créer manuellement, ce qui peut être assez coûteux en terme de temps. C’est notamment ce qui a été utilisé dans les deux exemples développés ci-dessous, comme lien entre les interfaces développés et Uppaal.
Annexe 3
|
Paramétrage du modèle
Pour permettre le lancement des simulations, il est nécessaire de réaliser le paramétrage du modèle. L’ensemble des variables qui doivent être paramétrer sont présentées ici, à l’exception de celles qui ne peuvent être modifiées, comme les horloges, et les chan. Pour les vecteur et les tableaux multi- dimensionnels, les éléments entre parenthèses indiquent la taille de la dimension correspondante. De plus, la plupart de ces variables sont les mêmes quelque soit la dynamique pa
N : nombre d’éléments dans le paysage à l’état initial
PP(N) : état de la population de prédateur pour les N éléments à l’état initial
pp(N) : état de la population de proie pour les N éléments (pour les matrices, la population est existante mais doit être définie) à l’état initial
TS(N) : Indique l’occupation du sol pour les éléments du paysage à l’état initial
RC(N) : Indique la rotation culturale en cours si c’est une culture, ou l’occupation du sol sinon, à l’état initial
RCObj(N) : dynamique paysagère que l’on souhaite tester (objectif final pour l’état du paysage). Cette variable est différente pour chaque dynamique.
NbRotation : nombre de rotation culturale possible dans le paysage NbCult(NbRotation) : nombre de culture pour chaque rotation
RotRec(NbRotatio)(NbCult) : Date de récolte de chaque culture dans chaque rotation RotSem(NbRotation)(NbCult) : Date de semis de chaque culture dans chaque rotation TempsRot(NbRotation) : temps total de chaque rotation culturale
GP(liaison)(TS)(pp) : indique le temps pour les changements d’états des prédateurs selon l’évo- lution, l’occupation du sol et l’état de la population de proie
Gp(liaison)(TS)(pp) : indique le temps pour les changements d’états des proies selon l’évolution, l’occupation du sol et l’état de la population de prédateur
TabPrior(TSi)(PPi)(TSj)(PPj) : Priorité sur les migrations selon les occupations du sol et les
états des populations entre les deux élément i et j qui cont contigus.
VitPrior(TSi)(PPi)(TSj)(PPj) : Vitesse de migration selon les occupations du sol et les états des
populations entre les deux élément i et j qui cont contigus.
Diffusion(ppe)(ppr)(dist) : probabilité qu’il y ait une dispersion de proie selon la population
émettrice (ppe), réceptrice (ppr) et la distance entre les deux éléments.
Annexe 4
|
Fonction de gestion des rotations cultu-
rales
A partir de deux fonctions réalisées sous Uppaal, à l’aide d’un language s’approchant du C++, les dates de cultures et de semis prévues pour certaines rotations peuvent être récupérées pour gérer l’alternance programmée des cultures. A noter que le temps total de rotation doit correspondre à un écoulement d’années entières, et donc inclure les temps de jachère.
Recherche des dates de semi : Test
/ / F o n c t i o n p o u r d e t e r m i n e r d e b u t de R e c o l t e i n t D e b C u l t ( i n t Temps , i n t R o t a t i o n , i n t RotSem [ N b R o t a t i o n ] [ N b C u l t ] , i n t TempsRot [ N b R o t a t i o n ] , i n t N b C u l t ) { i n t i = 0 ; i n t t p s =Temps ; / / H o r l o g e G l o b a l e du s y s t e m e s a u v e g a r d e e i n t D a t e D e b u t =TempsRot [ R o t a t i o n ] ; i n t a j o u t = 0 ; / / On va r e v e n i r d a n s un i n t e r v a l l e de t e m p s / / c o r r e s p o n d a n t a c e l u i de l a r o t a t i o n w h i l e ( TempsRot [ R o t a t i o n ] <= t p s ) { t p s = t p s −TempsRot [ R o t a t i o n ] ; a j o u t = a j o u t + 1 ; } / / On va c h e r c h e r q u e l l e c u l t u r e on va s e m e r w h i l e ( i < N b C u l t ) { i f ( t p s <=RotSem [ R o t a t i o n ] [ i ] ) { D a t e D e b u t =RotSem [ R o t a t i o n ] [ i ] ; i = N b C u l t ; } i = i + 1 ; } D a t e D e b u t = D a t e D e b u t + a j o u t * TempsRot [ R o t a t i o n ] ; r e t u r n D a t e D e b u t ; } VI
Recherche des dates de récolte : On a semé un champ, on recherche la date de récolte qui lui est attribuée pour établir les contraintes temporelles nécessaires. Ci-dessous se trouve le code utilisable pour cela. / / F o n c t i o n p o u r d e t e r m i n e r f i n de R e c o l t e i n t F i n C u l t ( i n t Temps , i n t R o t a t i o n , i n t RotRec [ N b R o t a t i o n ] [ N b C u l t ] , i n t TempsRot [ N b R o t a t i o n ] , i n t N b C u l t ) { i n t i = 0 ; i n t t p s =Temps ; i n t D a t e R e c =TempsRot [ R o t a t i o n ] ; i n t a j o u t = 0 ; / / On va r e v e n i r d a n s un i n t e r v a l de t e m p s / / c o r r e s p o n d a n t[U+FFFD]c e l u i de l a r o t a t i o n w h i l e ( TempsRot [ R o t a t i o n ] <= t p s ) { t p s = t p s −TempsRot [ R o t a t i o n ] ; a j o u t = a j o u t + 1 ; } / / On va c h e r c h e r q u e l l e c u l t u r e on va r[U+FFFD]colter w h i l e ( i < N b C u l t ) { i f ( t p s <= RotRec [ R o t a t i o n ] [ i ] ) { D a t e R e c = RotRec [ R o t a t i o n ] [ i ] ; i = N b C u l t ; } i = i + 1 ; } D a t e R e c = D a t e R e c + a j o u t * TempsRot [ R o t a t i o n ] ; r e t u r n D a t e R e c ; } VII
Annexe 5
|
Règles pour les Migrations
Règles pour qu’une migration soit possible :
1. Il n’est pas possible d’atteindre les états High et Normal dans une matrice 2. Pas de migration quand les deux populations sont à l’état Extinct ou High
3. Excepté pour la matrice, il faut deux niveaux de différence sur les états de population pour qu’il y ait une migration pour deux mêmes occupations du sol.
4. L’occupation des cultures est prioritaire sur toutes les autres. Il peut y avoir diffusion à partir du moment où la population de culture est au moins un niveau en dessous d’une population avec une autre occupation du sol.
5. L’occupation du sol nu est équivalente à celle de l’habitat semi-naturel d’un point de vue des migrations. Une migration HSN-HSN est équivalente à une migration Sol Nu-HSN
6. La migration d’une culture vers un sol nu ou HSN peut se faire s’il y au moins deux niveaux de populations de plus pour la population sur culture.
7. Entre deux matrices, la diffusion peut avoir lieu si les niveaux sont différents E/L donne L/E pour simuler le déplacement à travers les matrices.
8. Diffusion vers la matrice seulement quand on est à l’état High
Règles de Priorité entre les migrations :
1. On cherche à avoir les populations les plus élévés sur les cultures 2. Les diffusions inter-cultures sont toujours prioritaires
3. Plus l’écart entre populations est important, plus la migration est prioritaire 4. Même priorité entre Sol nu et HSN pour de même situation de population
5. La matrice diffuce vers l’extérieur facilement, mais il est difficile d’y faire venir des individus 6. Les diffusions inter-matrices ne se font que quand aucune autre n’est possible
Annexe 6
|Ensemble des Synchronisations présentes
dans le système
Liste des chan : Un chan est une communication entre un émetteur, et un seul récepteur. L’émetteur ne peut réaliser sa transition s’il n’y a pas de récepteur
Pest : Action des Pesticides qui a forcément un impact sur les populations de proes
Semaison : Le champ vient d’être semé, ce qui induit un changement dans l’occupation du sol DiffB : émis par un automate de migration d’un automate de prédateur, pour lui faire baisser son
niveau de population.
DiffH : émis par un automate de migration d’un automate de prédateur, pour lui faire augmenter son niveau de population.
Liste des Broadcasts : A la différence des chan simples, les broadcasts chan peuvent émettre à plusieurs récepteurs à partir d’une seule émission, mais aussi évoluer sans qu’il y ait de récepteur. L’évolution de l’émetteur n’est donc pas entravé par l’absence de récepteur.
Recolte : Indique que la récolte a été effectué, il y a évolution du terrain Terrain : Indique qu’il y a eu récolte/semis,
Evol : Indique une évolution de la population de prédateurs
Vent : Indique une dispersion aléatoire par le vent (phénomène aléatoire)
PriorP : Indique la présence d’une priorité dans les migrations, pouvant arrêter des migrations moins priorités
Diffr : Indique qu’un automate de proie va devoir faire évoluer son état de population suite à une dispersion de proie
Les broadcasts sur les évolutions de population : Ces chan indiquent des évolutions sur les ni- veaux de populations des espèces. Ils sont tous basés sur une même règle de construction, et sont tous codés à l’aide de trois lettres :
— la première indique si l’émetteur est un prédateur, avec un P majuscule, ou une proie, avec un p minuscule.
— La seconde indique le niveau où se trouvait précédemment l’espèce, (h pour high, n pour normal, l pour low et e pour extinct).
— La troisième et dernière indique à quel état se trouve désormais l’espèce concernée. En voici la liste complète : Pnl, Pln, Pnh, Phn, Ple, pnl, pln, pnh, phn, ple.
Annexe 7
|
Définition des critères Paysagers
Cette annexe présente l’ensemble des indicateurs des dynamiques paysagères pour les caractériser. Ces indicateurs sont spécifiques à des paysages de type lattice. Certains critères sont servis pour ca- ractériser plusieurs occupations du sol. Ils sont repérés de la manière suivante :
— .Env : le critère indique en trois exemplaies, un pour toutes les occupations du sol, un pour les cultures et un pour les HSN.
— .Spe : le critère ne peut caractériser qu’une occupation du sol à la fois. Il existe donc deux fois, une pour les cultures et une autre pour les HSN.
Dist : Distance au paysage de référence, c’est-à-dire le nombre d’éléments ayant des occupations du sol qui différent. Ses valeurs sont entières, situées entre 0 et une Valeur seuille fixée Proportion : Pourcentage de culture sur le paysage, la quantité de matrice étant fixe car elles sont