Simulateur multi-agent des déplacements

La plateforme de simulation Repast Simphony

Nous avons choisi la plateforme de la simulation Repast pour les raisons invoquées dans le chapitre 2. Dans ce qui suit, nous en donnons les éléments de base nécessaires à la compré-hension des développements que nous avons menés dans le cadre de ce travail. Trois notions importantes dans Repast Simphony sont : les contextes, les projections et comme tout simula-teur, l’ordonnancement.

Les contextes

Les contextes sont les concepts de base dans Repast Simphony. Un contexte fournit une structure de données pour organiser les agents autant pour la modélisation que pour l’implé-mentation. Concrètement, un contexte est une collection d’agents, mais un peu plus riche qu’une simple collection. Les contextes dans Repast sont hiérarchiquement imbriqués, chacun étant un conteneur de composants du modèle. Les composants du modèle peuvent être des simples ob-jets POJO 12, y compris d’autres contextes, mais on s’attend souvent à ce qu’ils soient des objets représentant des agents ayant un comportement. Chaque composant du modèle peut être présent dans de nombreux contextes selon les besoins du concepteur. Un composant du modèle, qui est présent dans un contexte, est également présent dans tous les contextes parents de ce contexte (l’inverse n’est évidemment pas vrai).
L’un des intérêts principaux des contextes est qu’ils servent comme support à des projections (voir plus bas). Les projections dans Repast sont des relations définies sur les membres d’un contexte. Par exemple, la projection Network stocke une relation du réseau ou d’un graphe entre les membres de son contexte. Les membres de ce contexte peuvent alors savoir à qui ils sont liés et qui sont liés à eux. De même, la projection Grid stocke un ensemble de coordonnées cartésiennes pour chaque membre du contexte. Les membres de ce contexte peuvent savoir où ils se trouvent dans la grille.
Les contextes sont également en charge des couches de données. Les couches de données représentent les données numériques qui peuvent être accessibles en utilisant un ensemble de coordonnées. Les couches de données permettent aux concepteurs de modèles de fournir des
12. Plain Old Java Object valeurs numériques avec lesquels leurs agents peuvent interagir.

Les projections

Alors que les contextes créent une collection pour organiser les agents, les projections im-posent une structure sur ces agents. En utilisant les seuls contextes, on ne peut écrire un modèle qui fournit plus qu’un simple conteneur pour les agents. Les projections permettent de créer une structure qui définit les relations, qu’elles soient spatiales, sémantiques, etc. Une projection est attachée à un contexte particulier et s’applique à tous les agents dans ce contexte. Un point important est à signaler ici : un objet doit exister dans un contexte avant d’être utilisé dans une projection. On peut appliquer autant de projections qu’on désire à un même contexte. On peut donc avoir un contexte qui contient une grille et deux espaces géographiques (deux manières de représenter un réseau de transport par exemple). Les agents peuvent obtenir une référence diverses projections à travers le contexte auquel ils appartiennent. Un agent peut faire ce qui suit (this se réfère à l’agent) :
Cette projection ne serait pas utile à moins qu’on « caste » la projection à une représentation plus spécifique (un Network par exemple).
En général, les projections sont créés en utilisant le mécanisme de trouver la Factory ainsi.
— Trouver la Factory
— Utiliser la Factory pour créer la projection Par exemple, pour créer une grille :
Chaque Factory crée une projection d’un type spécifique et nécessite le contexte auquel la projection est associée et le nom des projections ainsi que des arguments supplémentaires notamment pour le type de projection. Ces arguments supplémentaires ne sont pas définis ci-dessus (le paramètre params).

L’ordonnancement

L’ordonnancement est un composant clé de toute simulation. Il définit la manière avec la-quelle les actions des agents sont exécutés pendant la simulation. Il y a trois manières de tra-vailler avec l’ordonnanceur de Repast.

La plateforme de simulation Repast Simphony

Ordonnancer directement une action Pour ordonnancer directement une action dans Re-past, on récupère une référence vers un Schedule et on l’informe du moment où l’action doit être exécutée. Ci-après un exemple d’ajout d’une action au Schedule.

Ordonnancer avec les annotations

Les annotations sont des métadonnées qui peuvent être associées aux classes, méthodes ou attributs qui sont disponibles pendant l’exécution pour donner au système plus d’informations. Pour Repast, les annotations sont utilisées entre autres pour associer des informations d’ordon-nancement aux méthodes.
Ici la méthode move est ordonnancée à partir du tick 1, elle s’exécute tous les deux ticks, et a une priorité de 2. Cela signifie que si une autre action de priorité inférieur (1 par exemple) est ordonnancée, move sera exécutée avant elle. L’usage des annotations est le plus simple lorsque les paramètres d’ordonnancement sont connues lors de la compilation. Les arguments des annotations sont similaires aux propriétés d’un objet ScheduleParameters. La plupart du temps, les objets avec annotations sont automatiquement ajoutés au schedule.

Ordonnancer avec le Watcher

Les Watchers ou observateurs sont conçus pour être utilisés pour l’ordonnancement dyna-mique où un workflow typique est bien compris par le concepteur du modèle. Un observateur permet à un agent d’être notifié d’un changement d’état dans un autre agent et planifier un événement de se produire à la suite. Le watcher est mis en place en utilisant une annotation. Mais au lieu d’utiliser les temps statiques pour les paramètres de planification, l’utilisateur spé-cifie une requête définissant les agents à observer et une requête définissant une condition de déclenchement qui doivent être remplies pour exécuter l’action.
L’annotation @Watch avant la méthode indique à Repast Simphony d’observer les autres objets pour ordonnancer la méthode move(). Ici, l’agent voyageur voudrait mettre à jour sa position à chaque fois que son bus change de position. Le premier paramètre de l’annotation est le watcheeClassName. Il définit le type d’agents que cet agent va surveiller. Le second argument, watcheeFieldName, définit l’attribut à surveiller. Cela signifie qu’il y a une variable dans la classe busAgent, dont nous voulons surveiller les changements. Quand elle change, cet agent sera notifié. L’argument whenToTrigger spécifie s’il faut exécuter l’action immédiatement (avant que les autres actions planifiées à cette instant ne soient exécutées) ou d’attendre jusqu’au prochain tick. Enfin, le scheduleTriggerPriority permet de définir l’ordre d’exécution de cette action.

Le simulateur

Dans cette section, nous décrivons le système multi-agent pour la simulation de l’impact de l’information de voyageurs. Il ne s’agit pas du même simulateur développé pour la plate-forme MMT mais d’une version adaptée pour qu’elle s’exécute sur un réseau de transport en commun. Comme nous le verrons dans le chapitre suivant, nous l’avons également enrichi avec des dispositifs d’information de voyageurs, autant au niveau des arrêts qu’avec de l’information personnalisée. Dans ce qui suit, nous donnons une description générale du simulateur, qui sera détaillée dans la suite de ce chapitre et dans le chapitre suivant.
La Figure 3.6 présente le système multi-agent de la simulation, les agents qui le composent, l’environnement ainsi que les interactions entre agents. Les agents qui se déplacent sur le ré-seau de transport sont les agents voyageurs et les agents véhicules. Les agents voyageurs se décomposent en deux types : des agents connectés (à une source d’information temps-réel de l’opérateur de transport) et les agents non connectés. Le troisième type d’agent évoluant dans le réseau, mais sans se déplacer, est l’agent d’information locale. Il est responsable de la diffusion des informations sur les perturbations au niveau des arrêts du réseau. La plateforme offre un service de planification pour les voyageurs connectés, assurant le suivi de leurs voyages, en se fondant sur une représentation spatiotemporelle du réseau de transport.
Le simulateur représente des passagers, des véhicules de transport public et de moyens d’information à un niveau microscopique et simule leurs mouvements dynamiques. A cette fin, le simulateur a besoin de certains types de données et quelques paramètres additionnels.

Données et paramètres

Le workflow de la Figure 3.7 détaille une exécution de simulation et structure le reste de la présentation. La simulation démarre avec le chargement des paramètres (durée de la simu-lation, nombre d’agents de chaque type, les vitesses par défaut de chaque type d’agent, etc.). Le programme principal crée les graphes logiques (décrits dans la section 3.5.2) et lance l’or-donnanceur. L’ordonnanceur est responsable de la synchronisation de l’exécution des agents à chaque tick de temps simulé. Nous avons défini un ordonnanceur qui lance les agents sur tous les cœurs disponibles (cf. la section3.4.2 qui suit). Une fois lancé, chaque agent exécute une méthode step. Le comportement de chaque type d’agent est décrit en section 3.6. Enfin, quand la durée de simulation est atteinte, les résultats sont collectés et la simulation se termine.