• Aucun résultat trouvé

3.5 La gestion du temps

3.5.5 Le probl` eme de la simultan´ eit´ e

La r´esolution de conflits semble ainsi ˆetre une question quasi incontournable, qu’elle soit r´esolue de fa¸con ”d´etourn´ee” par la cr´eation d’une liste des actions (al´eatoire ou par priorit´e) ou de mani`ere frontale en traitant les diff´erents conflits qui peuvent apparaˆıtre. C’est pourquoi, que le mod`ele utilise un mod`ele du temps discret ou un principe ´ev´enementiel, la v´eritable question qui se pose est celle de la repr´esentation de la simultan´eit´e des actions. Il suffit de consid´erer l’h´et´erog´en´eit´e des actions qui peuvent ˆetre mod´elis´ees dans une simulation multi- agents pour mesurer `a quel point cette tˆache n’est pas triviale. L’ind´ependance qui peut exister entre deux actions n’est parfois qu’apparente.

Mod´eliser la simultan´eit´e de deux ´ev´enements n’est bien sˆur pas l’apanage des seuls syst`emes multi-agents. Le probl`eme se pose dans les simulations classiques et ses cons´e- quences sont du mˆeme ordre : c’est-`a-dire la possibilit´e d’obtenir plusieurs ´etats du sys- t`eme diff´erents `a t + dt suivant l’ordonnancement du traitement des ´ev´enements `a l’instant t [Zeigler et al. , 2000]. Ce probl`eme a donc une traduction dans les formalismes classiques. Les approches que nous avons pr´esent´ees peuvent ainsi ˆetre rapproch´ees des deux principales solutions qui ont ´et´e propos´ees dans le cadre du formalisme DEVS. Dans ce formalisme, le pro- bl`eme se pose dans le cas des syst`emes compos´es (o`u la sortie d’un composant peut constituer l’entr´ee d’un autre) o`u plusieurs fonctions de transition peuvent ˆetre activ´ees en mˆeme temps du fait d’´ev´enements poss´edant la mˆeme date de r´ealisation. En effet, par d´efinition un com- posant atomique privil´egie la fonction de transition qui repr´esente l’influence des ´ev´enements externes (δext). De fait, l’ordre dans lequel sont activ´es les composants a une importance : la

transition interne d’un composant, δint, peut entraˆıner l’annulation de la transition interne

d’un autre par l’´emission d’un ´ev´enement sur son port d’entr´ee.

Dans ce contexte, on parle des collisions entre fonctions de transition. Du fait de cette ambigu¨ıt´e, la mod´elisation des syst`emes compos´es n´ecessite d’apporter une solution formelle et explicite `a ce probl`eme de mani`ere `a d´efinir une dynamique qui soit unique et contrˆol´ee. Dans la forme classique de DEVS, la solution `a ce probl`eme est formalis´ee par la d´efinition d’une fonction Select qui d´etermine, pour le syst`eme compos´e consid´er´e, l’ordre dans lequel ses composants en collision seront s´equentiellement activ´es. Autrement dit, les conflits sont ici r´esolus en amont par la constitution d’une liste ordonn´ee. Ce qui peut ˆetre rapproch´e des id´ees de brassage al´eatoire des agents ou de la d´efinition d’un ordre de priorit´e entre les actions/agents.

Cette premi`ere solution a cependant montr´e certaines limites qui ont pouss´e `a la r´eali- sation d’une extension du formalisme DEVS37. En effet, la s´erialisation de l’ex´ecution des composants ne refl`ete pas la situation `a laquelle il faut faire face et elle ne permet pas d’exploiter concr`etement et simplement le parall´elisme d’un syst`eme dans sa mod´elisation. Chow et Zeigler ont donc propos´e une extension du formalisme DEVS appel´ee Parallel DEVS [Chow & Zeigler, 1994]. Ces auteurs r´esument les objectifs et les raisons qui ont motiv´e cette extension de la mani`ere suivante :

37il est int´eressant de noter que cette extension est apparue plus de quinze ans apr`es la d´efinition de DEVS

“Collision Handling : The behavior of a collision must be controllable. Pre- defining a collision behavior is a limitation on the modeling capability that is not a necessary price to pay for parallelism.”

“Parallelism : The formalism must not use serialization function that pro- hibits possible concurrences. The parallelism among the internal transitions and simultaneous events must be fully exploited.”

On voit cette fois que la simultan´eit´e est trait´ee en tant que telle et qu’elle doit faire partie de la mod´elisation. La solution apport´ee par Parallel DEVS consiste ainsi `a traiter explici- tement la simultan´eit´e en permettant au mod´elisateur d’apporter une solution particuli`ere `a la gestion d’une collision. Pour cela, la d´efinition de la dynamique d’un composant est aug- ment´ee d’une fonction suppl´ementaire, δcon, the confluent transition function, qui est charg´ee

de traiter explicitement le cas o`u les deux autres fonctions de transition classiques peuvent ˆetre d´eclench´ees `a la mˆeme date. Cette fonction permet ainsi au mod´elisateur de donner une v´eritable s´emantique `a la r´esolution d’une collision et elle lui donne l’occasion de prendre en compte la simultan´eit´e en tant que telle. Il faut d’ailleurs noter que la fonction Select n’a ici plus aucune utilit´e et qu’elle est abandonn´ee dans Parallel DEVS. De plus, chaque composant peut recevoir non plus une seule entr´ee mais un ensemble d’´ev´enements simultan´ement, on parle d’un bag of inputs (idem pour les ´ev´enements en sortie).

A priori, les solutions utilis´ees dans le cadre de la simulation multi-agents qui utilisent des r´esolutions de conflits peuvent ˆetre rapproch´ees de cette solution formelle : au lieu de s´erialiser a priori les actions, on apporte une solution `a leur concurrence. Il existe cependant une diff´erence assez subtile entre ces deux approches. Dans Parallel DEVS, l’id´ee n’est pas fondamentalement de r´esoudre le probl`eme o`u deux ´etats du syst`eme seraient en conflit . Au contraire, grˆace `a la fonction δcon, le syst`eme poss`ede une dynamique clairement d´efinie qui

n’engendre aucun conflit : la r´eponse au probl`eme de la simultan´eit´e est apport´ee avant de calculer l’´etat suivant du syst`eme. De plus, la notion de bag of inputs/outputs formalise le fait que des ´ev´enements simultan´es constituent un tout dont les ´el´ements ne doivent pas ˆetre trait´es s´equentiellement. Bien sˆur, la d´efinition de δcon peut ˆetre fond´ee sur un principe similaire `a la

r´esolution de conflits, d’ailleurs il est tout `a fait possible de retrouver le comportement de la fonction Select. Mais l’id´ee n’est pas l`a et le but avou´e est bien de traiter la simultan´eit´e de mani`ere frontale.

A partir de l`a, on peut se demander pourquoi les mod`eles multi-agents n’ont pas int´egr´e des points de vue et des objectifs similaires `a ceux propos´es par Parallel DEVS, ne serait-ce qu’en regard de sa d´enomination. En effet, les mod`eles multi-agents en restent aujourd’hui `a la s´erialisation ou `a la r´esolution de conflits. En fait, les mod´elisations multi-agents utilisent toutes fondamentalement la mˆeme repr´esentation de l’action : par modification, directe ou indirecte, des variables de l’environnement : Σ d´efinissant l’ensemble des ´etats possibles du monde, l’action d’un agent est concr´etis´ee par la modification discr`ete de l’environnement d’un ´etat σ ∈ Σ `a un autre ´etat σ’. En d’autres termes, l’action d’un agent est souvent repr´esent´ee par un ´ev´enement du type modifier la variable d’´etat A avec la valeur x. Comme le souligne Ferber, ces repr´esentations classiques de l’action se prˆetent mal en l’´etat `a une impl´ementation simple et efficace de la concurrence. Elles confondent dans l’action ce qui est produit par les agents avec ce qui se produit effectivement :