Le déplacement d’un agent

3.6 Le système multi-agent

3.6.1 Les agents

Notre simulateur est composé de 2 types d’agents (d’autres agents seront définis au cha-pitre suivant) : les agents véhicules (BusAgent) et les agents voyageurs (TravellerAgent) consti-tuent les éléments mobiles qui se déplacent sur le réseau. Le service de planification assure une fonction d’assistance aux agents voyageurs. Dans cette section, nous présentons les deux types d’agents ainsi que le service de planification.

Les agents véhicules (BusAgent)

Les BusAgent ne choisissent pas leur destination d’une manière autonome, mais obéissent à un tableau de marche. Chaque BusAgent, dès sa création, retrouve son chemin à partir de son tableau de marche. Comme explicité plus haut et en annexe A, un tableau de marche est composé d’une séquence de couples harrt, tempsi. Le BusAgent transforme ce chemin en une succession d’arcs. Ceci est fait par un accès à la définition du réseau de transport public à la recherche d’un arc de la même ligne que le bus qui relie les deux nœuds successifs du tableau de marche. Une fois tous les arcs du tableau de marche retrouvés, l’agent BusAgent retrouve les vitesses associées à ces arcs. La vitesse doit prendre en compte le fait que le bus doit s’arrêter pour que les voyageurs montent à bord. L’équation retenue, et qui est utilisée en général, est la suivante : si le bus visite deux arrêts successifs i et j aux instants t et t + 3, il s’arrête au niveau de i de t à t + 1 avant de démarrer. Un tiers du temps de déplacement entre deux arrêts est donc alloué à la montée et à la descente des voyageurs. Si, pour une raison ou une autre, la vitesse du bus ainsi calculée se révèle farfelue (e.g. 120km/h), le paramètre BusSpeedKmH défini plus haut est utilisé pour lisser les valeurs des temps de passage vers des quantités raisonnables.

Tant que le BusAgent n’est pas arrivé à destination, il se déplace à chaque pas de temps de la distance permise, suivant sa vitesse courante. S’il arrive à un arrêt, il déclenche un compteur d’arrêt à l’expiration duquel il va redémarrer. Durant ce temps, il fait descendre les agents

voyageurs inscrits dans la liste de descente, ensuite, il embarque ceux inscrits dans la liste d’attente de l’arrêt (figure 3.14). S’il a atteint sa destination, le BusAgent quitte la simulation. Le service de planification

Le service de planification répond aux requêtes de déplacement des agents voyageurs. Il est responsable du calcul du meilleur itinéraire pour ces agents voyageurs. La méthode de cal-cul des itinéraires est décrite dans la section 3.5.2. Le résultat du calcal-cul est constitué d’une alternance entre cheminement piétons et itinéraires en réseau de transport en commun. Un che-minement piéton est composé d’une séquence d’arcs du réseau piéton avec les temps de passage correspondants. Un itinéraire en transport en commun est quant à lui composé d’une séquence de couples hid_vehicle, itinéraire i, avec id_vehicle l’identifiant du véhicule à prendre et la partie correspondante de l’itinéraire.

Les agents voyageurs (TravelerAgent)

L’origine et destination de l’agent voyageur sont soit déduites depuis le modèle de dépla-cement s’il existe, soit choisies d’une manière aléatoire sinon. Ensuite, le voyageur reçoit un itinéraire composé d’une liste de coordonnées de la part du service de planification. Pour par-courir cet itinéraire, un agent voyageur alterne entre la marche, l’attente d’un véhicule et le déplacement à bord du véhicule jusqu’à arriver à destination. Quand il marche, l’agent voya-geur est autorisé à parcourir une distance égal à σpassager à chaque pas de temps. Quand il est à bord d’un véhicule, il délègue la responsabilité de son mouvement à l’agent véhicule qu’il emprunte.

Une question s’est posée à ce niveau. Qui doit vérifier la compatibilité entre un agent voya-geur et un agent véhicule ? Intuitivement, c’est le voyavoya-geur qui vérifie que le véhicule arrivé à l’arrêt dans lequel il est positionné l’emmène bien à sa destination (i.e. le prochain point de correspondance) ou pas. Néanmoins, dans le cadre du simulateur, la question se pose différem-ment. Si nous définissons une durée de simulation trop petite, de telle manière qu’un véhicule a le temps de s’arrêter au niveau d’un arrêt et de redémarrer dans un même pas de temps, l’agent voyageur n’aura jamais la main pour vérifier s’il doit prendre le véhicule ou pas. Pour cette raison, nous procédons de la manière suivante pour faire correspondre les voyageurs et les véhicules de transport public.

Dès qu’un agent voyageur arrive à un arrêt pour attendre un véhicule de transport public, il s’ajoute dans une liste prévue à cet effet dans les attributs de l’arrêt et il met son propre statut à « en attente d’un véhicule ». C’est l’agent véhicule qui, en arrivant au niveau de l’arrêt en question vérifie la liste des agents voyageurs en attente et vérifie qu’il les emmène bien à leur prochaine destination. Si tel est le cas, il se charge de leur changement de coordonnées (i.e. leur déplacement) jusqu’au prochain point de correspondance. Durant ce temps, les agents voyageurs concernés ont un statut égal à « à bord ». Ainsi, les agents voyageurs passent par une succession d’états :

1. soit ils marchent vers leur prochain arrêt, 2. soit ils attendent un véhicule,

4. soit ils sont arrivés à destination et dans ce cas ils quittent la simulation.

La figure 3.14 illustre le diagramme d’activité du déplacement de l’agent voyageur et son interaction avec l’agent véhicule.

L’usage de l’ordonnanceur parallèle fait que l’exécution des agents risquent d’interférer, et qu’ils risquent d’accéder d’une manière concurrente à la projection mainGeography. Pour éviter que l’exécution aboutisse à un état incohérent de la simulation, nous avons recours à deux procédures :

1. l’accès à mainGeography est systématiquement synchronisé.

2. les actions des agents véhicules sont ordonnancées avec une priorité plus grande que celle des agents voyageurs.

3.6.2 Packages

Les packages public_transport.agent et common.agents contiennent respectivement les agents de transport public (principalement BusAgent) et les agents piétons (principalement Travelle-rAgent).

Le package common.environment.generated.network contient les classes générées à partir du XSD de définition des réseaux (avec l’Api JAXB). Le package common.environment.generated. timetable contient les classes générées à partir du XSD de définition des tableaux de marche des véhicules de transport en commun. Les packages public transport.environment, road trans-port.environment et common.environment contiennent les classes définissant l’environnement des réseaux, respectivement de transport public, des piétons et de transport multimodal. Ils contiennent les définitions de Road, Junction, Link, Stop, Edge, etc. et toutes les classes né-cessaires au déplacement dans la géographie. Le package common.main contient la classe principale qui initialise la simulation. Dans Repast, il s’agit d’une classe qui implémente re-past.simphony.dataLoader. ContextBuilder, et qui définit une méthode build qui renvoie le contexte principale de la simulation, contenant tous les agents et tous les objets géographiques créés ini-tialement. Les autres packages sont assez classiques : common.exceptions pour les exceptions et common.util pour les fonctionnalités utilitaires manipulées dans la simulation, se présen-tant généralement sous la forme de méthodes de classe. Le package common.main.schedulers contient la classe qui sert à paralléliser l’exécution des agents.

3.7 Optimisations

Nous avons rencontré un grand nombre de problèmes pendant le développement du simu-lateur de déplacements. Beaucoup de ces problèmes étaient liés à de mauvaises performances, relatives à l’usage de la mémoire ainsi qu’aux temps d’exécution. Nous avons également dû faire face à des erreurs dans les données manipulées, que nous avons dû corriger quasi-manuellement.

3.7.1 Des données erronées ou manquantes

Les données géographiques en entrée dans le simulateur nous avaient été fournies par Tisséo SMTC, via la plateforme ClaireSiti. Ces données ne sont pas destinées à la base pour faire une