Les modèles à pas de temps : simulation dirigée par l'horloge

Pour représenter l'évolution du temps, les simulations par horloge "discrétisent" le temps en "pas de temps" réguliers comme dans le cas des systèmes dynamiques discrets. Pour ce type de modèles, Δt est constant (on considère généralement que c'est une valeur entière égale à 1, par exemple Δt = 1 seconde, 1 jour, 1 an…). Les changements d’état ayant lieu durant l’intervalle ]t, t+Δt], une variable du système peut changer d'état toutes les Δt périodes. Entre les deux, elle est

112

censée rester constante. Par ailleurs, les entités sont supposées évoluer toutes en même temps et simultanément.

Les simulations par "pas de temps" peuvent être considérées comme un sous-type de simulation évènementielle où les tops d'horloge constitueraient les évènements. Mais, leurs mises en œuvre sont très différentes et bien plus aisées à réaliser. Elles proposent deux procédures d'activation des entités qu'on nomme approche synchrone et approche asynchrone⁵⁰.

5.3.2.1 Approche synchrone

On considère ici que d'un point de vue du temps réel, les agents évoluent tous simultanément. Du point de vue du temps virtuel, ils évoluent en parallèle. Les automates cellulaires (créés par Von Neumann et Ulam) constituent un bon exemple de déroulement synchrone. En effet, les cellules d'un réseau d'automates changent d'état toutes simultanément. Pour émuler une évolution synchrone d'un réseau d'automates, on passe fréquemment par un artifice informatique appelé double buffering [Travers, 1996] qui consiste en une mise à jour en deux passes de l’état des cellules. En effet, les automates cellulaires étant généralement exécutés sur des machines monoprocesseurs, l'algorithme doit simuler le traitement parallèle par l'intermédiaire d'une variable tampon (buffer). Lors du nouveau "pas de temps", l'ordonnanceur (aussi appelé scheduler) active séquentiellement toutes les cellules de l'automate qui exécutent alors leur fonction de transition. Chaque cellule change d'état en fonction de son état interne et en fonction de l'état de ses voisines. Mais bien sûr, il ne faut pas que le nouvel état soit immédiatement pris en compte dans le calcul de la fonction de transition d'une autre cellule. La fonction de transition doit s'opérer sur des états calculés et mémorisés au "pas de temps" précédent. Deux stratégies sont proposées. Pour chacune, un "pas de temps" est décomposé en deux phases:

- La plus répandue des stratégies consiste à stocker le résultat du calcul dans une variable tampon de la cellule. Lorsque toutes les cellules ont terminé cette première phase de calcul, l'ordonnanceur balaie à nouveau toutes les cellules du réseau pour demander à chacune de mettre à jour son nouvel état qui prend alors la valeur de l'état tampon.

- Une autre solution consiste à faire une copie du réseau (snapshot) en début de chaque "pas de temps" puis de faire calculer à chaque cellule sa fonction de transition en utilisant les valeurs des cellules clonées.

Ainsi, quelle que soit la stratégie d'exécution choisie, l'ordre séquentiel d'activation de chaque cellule n'a pas d'influence sur les résultats de simulation. Ici, chaque entité (cellule) ne modifie que son propre état. Mais dans le cas d'un SMA, il est souvent possible que des entités veuillent modifier l'état d'une autre entité (l'environnement, un autre agent, etc.). Nous verrons plus loin que ce cas de figure nécessite souvent des résolutions de conflits dans le cas de modifications concurrentes ou conflictuelles.

Selon la classification de Zeigler, ces modèles appartiennent à la famille des modèles DTSS (Discrete Time System Specification). De façon plus formelle, la spécification d'une DTSS est:

DTSS =< X; Y; S; ; ; c > où :

X est l'ensemble des valeurs possibles sur les ports d'entrée,

Y est l'ensemble des valeurs possibles sur les ports de sortie,

S est l'ensemble des états du système,

 est la fonction de transition (interne et/ou externe), δ: S x X→ S

50

Dans la littérature, l'approche asynchrone fait souvent référence à l'approche à évènements discrets. Nous préférons garder ce terme pour les simulations par horloge qui, contrairement aux automates cellulaires, activent les entités de façon séquentielle.

113

 est la fonction de sortie (Moore, Mealy ou sans mémoire)

c est une constante employée pour spécifier la base temporelle (Δt).

Pour spécifier la fonction de transition d'un automate cellulaire, Zeigler défini deux fonctions: –δ, la fonction de transition qui permet de calculer le nouvel état interne S' d'une entité en

fonction de son état courant (S) et d'un ensemble d'inputs (X). Dans le cas des automates cellulaires, c'est une fonction de transition externe dont l'ensemble X correspond à l'état des voisins (visibles sur leurs ports de sortie).

–λ, la fonction de sortie qui peut être calculée selon trois procédés :

-le type Moore, sans entrée : l'output d'une entité n'est calculé qu'en fonction de son état interne S. λ: S→Y

-le type Mealy : l'output d'une entité est calculé en fonction de son état interne S et d'un ensemble d'inputs X. λ: S x X→Y

-le type sans mémoire FNSS (que l'on peut considérer comme un cas particulier du type de Mealy) : l'output d'une entité n'est calculé qu'en fonction d'un ensemble d'inputs

X. λ: X→Y

Classiquement, les automates cellulaires utilisent une fonction de sortie λ de type Moore pour laquelle l'output est égal à l'état interne (calculé par la fonction de transition δ):

λ: S→Y avecY=S.

En d'autres termes, pour cette deuxième fonction, l'état "visible" d'une cellule devient l'état interne stocké en mémoire tampon. La majorité des simulations multi-agents utilisent les fonctions de type Moore et de type Mealy et nous reviendrons sur l'importance de discerner ces fonctions. Dans le cas d'un réseau d'automates, ce système est appelé multiDTSS (a multi-component DTSS model). Un simulateur DTSS se décrit alors de la façon suivante :

Cette figure présente un diagramme d'activité d'un pas de temps de l'ordonnanceur synchrone. On peut également utiliser un diagramme de séquence pour expliquer le déroulement d'un pas de temps. Il a l'avantage de présenter différentes entités du système et des échanges de messages.

incrémentation du temps t←t+1

application de la fonction de sortie λ à toutes les cellules application de la fonction

de transition δ à toutes les cellules incrémentation du temps

t←t+1

application de la fonction de sortie λ à toutes les cellules application de la fonction

de transition δ à toutes les cellules

Figure 5-15 : Diagramme d'activité d'un pas de temps d'un simulateur DTSS. Le cas d'un ordonnanceur synchrone implique deux phases : une phase de calcul de la fonction de transition et une de mise à jour des variables de sortie.

114 : OrdonnanceurSynchrone : Cellule incrémentation du temps t t+1 * fonction de transition δ * fonction de sortie λ Qbuffer← δ(X) Q ← Qbuffer SD: Main Step : OrdonnanceurSynchrone : Cellule incrémentation du temps t t+1 * fonction de transition δ * fonction de sortie λ Qbuffer← δ(X) Q ← Qbuffer Q ← Qbuffer SD: Main Step SD: Main Step

Figure 5-16 : Diagramme de séquence d'un pas de temps d'un ordonnanceur synchrone d'automate cellulaire. 5.3.2.2 Approche asynchrone

Dans l'approche asynchrone, d'un point de vue du temps réel, les agents sont censés évoluer simultanément. A chaque "pas de temps", tous les agents doivent avoir été activés une fois et une seule (on parle dans ce cas d'activation n-asynchrone). Dans leur grande majorité, les SMA utilisent ce principe pour activer les entités des modèles car la mise en œuvre de l'approche asynchrone est simple et aisée comme le montre la figure suivante :

SD: Main Step :OrdonnanceurAsynchrone : Agent incrémentation du temps t ← t+1 * step SD: Main Step :OrdonnanceurAsynchrone : Agent incrémentation du temps t ← t+1 * step SD: Main Step :OrdonnanceurAsynchrone : Agent incrémentation du temps t ← t+1 * step

Figure 5-17 : Diagramme de séquence d'un pas de temps d'un ordonnanceur asynchrone. L'astérisque placé devant le "step" signifie en UML que l'appel de méthode est effectué sur toutes les instances d'Agent. Cette représentation ne montre pas quelles sont ces instances, ni dans quel ordre elles sont activées. De mon point de vue, ceci constitue une faiblesse.

A chaque itération, tous les individus sont activés un par un, de façon séquentielle. Aussi, contrairement à l'approche synchrone, on ne peut pas considérer que les agents évoluent effectivement en parallèle. En observant une simulation de ce type, on peut peut-être le croire. Mais ceci est dû à la rapidité d'exécution de leurs activités. Dans le détail, il n'en est rien : les agents agissent séquentiellement. De plus, chacun met à jour son état visible directement pendant son activation. Ainsi, à un instant donné pris au cours d'un "pas de temps", certains agents ont déjà changé d'état quand d'autres n'ont pas encore été activés. Souvent, en s'inspirant des systèmes dynamiques discrets (cf. équation (2)), les simulations par "pas de temps" sont formalisées de la façon suivante : une fonction F permet de calculer l'état du système au temps t + 1 à partir de son état à l'instant t. Si on note t l'état du système au temps t, on trouve :

)

(

F

 



115

Or cette formalisation s'avère être fausse dans le cas d'une gestion asynchrone ! Pour passer de t à

t+1, le système a subi une suite de modifications dues à l'activation séquentielle des agents et à la mise à jour en une seule passe de leur nouvel état.

En reprenant le formalisme DTSS décrit page 115, on considère dans ce cas de gestion asynchrone que la fonction de sortie λ utilisée au niveau du sous-modèle d'agent est de type Mealy :

λ: S x X→Y

Pour rappel, X est l'ensemble des valeurs possibles sur les ports d'entrée, Y est l'ensemble des valeurs possibles sur les ports de sortie, S est l'ensemble des états du système et  est la fonction de sortie. Ici, l'output d'un agent est calculé immédiatement en fonction de son état interne S et d'un ensemble d'inputs X. La fonction de sortie qui permet de calculer le nouvel état visible de l'agent, utilise directement des données sur ses ports en entrée, c'est-à-dire qu'elle utilise des informations internes (S) et externes (X) à l'agent pour calculer immédiatement son nouvel état. Ce changement d'état est immédiatement perçu par les autres entités du système. Ainsi le principal problème de l'approche par horloge relève de la cohérence des différentes perceptions que les agents ont du monde :

Le monde perçu par différents agents à un même instant t de la simulation n’est pas identique. En effet, un agent perçoit à t un monde qui a été modifié par les agents qui ont agi avant lui. En d’autres termes, la perception d’un agent peut potentiellement s’appuyer sur des variables qui devraient être estampillées à t + dt. Et ce, alors que les agents sont supposés agir de manière concurrente à cet instant. Ainsi le dernier agent peut avoir une vue du monde totalement différente du premier alors que l’état de celui-ci est censé toujours être donné pour l’instant t. L’action d’un agent, qui est en principe déduite de sa perception du monde, est en fait directement liée à sa position dans la liste d’activation et par conséquent aux actions effectuées auparavant par les autres agents. [Michel 2004]

Il faut donc garder à l'esprit que ce type de gestion du temps peut dans certains cas avoir des effets non négligeables sur les résultats de simulation. Comme nous le verrons ultérieurement sur des exemples concrets, les impacts sur le comportement d'un modèle peuvent être importants. En effet, dans le cas d'utilisation de ressources par exemple, le premier agent activé prend rapidement l'avantage sur les autres agents : il se sert toujours le premier ! Pour essayer de remédier à ce problème, la technique la plus employée consiste à mélanger aléatoirement l'ordre d’exécution des agents à chaque "pas de temps". Statistiquement, on rétablit ainsi un partage en évitant de donner l'avantage systématiquement aux mêmes agents. C’est par exemple la méthode utilisée dans [Epstein & Axtell, 1996].