Modélisation orientée objets du système d'informationdes Systèmes de Trafic Urbain : une approche multi-agents

Michelle Chabrol, David Sarramia

Université Blaise Pascal – Clermont-Ferrand IILIMOS.CNRS FRE 2239

63177 AUBIERE Cedex. FranceTél : (33) 04 73 40 77 72, Fax : (33) 04 73 40 74 44.

E-mail : sarramia@iris.univ-bpclermont.fr

RésuméLa conception, l'étude et la gestion des Systèmes de Trafic Urbain (STU) sont devenues de plusen plus difficiles et coûteuses car les configurations existantes sont multiples et complexes.Notre objectif est de proposer une méthodologie de modélisation et des outils de simulation pourl’aide à la décision. La complexité croissante des STU nécessite de concevoir un système dedécision dans lequel sont regroupées les connaissances et les règles de fonctionnement. Pourrésoudre les problèmes de structuration de la connaissance et des règles, nous proposons unevision conceptuelle de ces systèmes en utilisant la notion de centre de décision et une approchemulti-agents. La méthodologie proposée permet la construction de modèles de niveaux différentsautorisant une implémentation adaptée aux objectifs de l'étude.Mots clefs : Système d'information, Modèle générique orienté objets, Approche multi-agents,Modélisation, Système de Trafic Urbain.

AbstractDesign, study and management of Urban Traffic Systems (UTS) became increasingly difficultand expensive as existing configurations are multiple and complex. Our objective is to propose amodelling methodology and simulation tools for decision-making aid. The increasing complexityof UTS requires to conceive a decision system in which are gathered together knowledge andworking rules. To solve the knowledge and rules structuring problems, we propose a conceptualview of such systems using the decision-centre concept and a multi-agents approach. Theproposed methodology allows the construction of models at different levels of details, enablingan implementation adapted to the study aims.Keywords: information system, object oriented generic model, multi-agents approach,modelling, Urban Traffic System.

1 IntroductionUn Système de Trafic Urbain (STU) est composé d'un réseau, de règles de fonctionnement, d'unsystème de gestion et de contrôle, et d'entités empruntant le réseau. Le réseau est un ensembled'axes de communications et d'intersections. Les entités (les véhicules) parcourent le système enrespectant les règles de fonctionnement (code de la route). Le système de contrôle répercute surle réseau les données fournies par le système de gestion, par le biais d'afficheurs (feux,panneaux). Le système de gestion décide de la politique de trafic à appliquer (en calculant etmodifiant les plans de feux).Le but principal d'un STU est de permettre aux usagers de parcourir le réseau en un tempsraisonnable et avec un niveau de sécurité suffisant. Pour atteindre ce but, les gestionnairesdoivent résoudre des problèmes :• d'évaluation de la capacité d'une infrastructure pour une nouvelle implémentation ou sur une

structure existante,• de phasage des feux : tests, calculs et évaluation de cycles, allongement de la durée de vert...,• de routage qui consiste à évaluer et à calculer le trajet pour des véhicules ayant un routage

fixe (les bus) ou non,• de guidage qui correspond au calcul et à l'évaluation de trajets pour les véhicules particuliers

et les véhicules d'urgences en temps réel.La complexité des STU est en grande partie due à l'infrastructure du réseau urbain. Elle s'estcomplexifiée au fur et à mesure que le trafic a augmenté. Les systèmes de gestion associés sesont eux aussi complexifiés avec l'apparition des feux et de politiques de création des plans defeux de plus en plus réactives à l'état du système. Dès lors, l'étude de tels systèmes nécessite lamise en œuvre de modèles relativement complexes. La Figure 1 illustre cette complexité. Ellereprésente une place où circulent des voitures et des bus, qui empruntent tantôt des voiesréservées, tantôt des voies normales. La complexité de l'infrastructure de la place nécessite denombreux équipements (treize lignes de feux) pour la gestion du trafic.

Figure 1 : Exemple de STU.Nous proposons dans la section 2 un état de l'art sur les techniques de modélisation et desimulation utilisées dans le domaine des STU, en insistant sur les utilisations de l'approchemulti-agents. La section 3 présente la décomposition systémique des STU qui est utilisée dans laméthodologie proposée. La section 5 donne le modèle générique de connaissance orienté objets

construit à l'aide de cette méthodologie. Dans cette section, nous présentons et justifions laconstruction d'un modèle multi-agents sur la base du modèle objet. La section 6 présente unexemple d'utilisation sur un cas réel.

2 Etat de l'artNous présentons un état de l'art sur la modélisation des STU en deux parties. La première partieprésente les approches généralement utilisées. La deuxième partie concerne la modélisationmulti-agents.

2.1 Les approchesLa modélisation et la simulation du trafic urbain ont débuté dans les années 50 [WILS74]. Troisapproches se sont dégagées [TRB96].La modélisation macroscopique considère le trafic comme un phénomène continu. Cettemodélisation a largement été utilisée car elle permet d'utiliser des principes et des modèlesphysiques éprouvés. Ainsi, des modèles dérivés de la dynamique des fluides [GREE35],[LIGH55] sont utilisés. La densité (ou concentration) K (en véhicules/mètre), le débit de trafic Q(en véhicules/seconde) et la vitesse du flot V (en mètres/seconde) utilisés vérifient la relationfondamentale Q = K.V. Les modèles continus tels que les modèles cinétiques [BUIS96],[PRIG71] peuvent aussi être employés. Les modèles macroscopiques sont utilisés lorsque l'étudepeut être réalisée à partir de données volumétriques de trafic et lorsque des résultats de ce typesont suffisants. Néanmoins, ce type de modèle ne permet pas l'analyse des mouvementsindividuels. Ils proposent une modélisation grossière du trafic et permettent d'obtenir rapidementdes résultats (ce qui en fait des modèles adaptés à des objectifs opérationnels à court terme).Cependant leur manque de précision peut poser problème.La modélisation microscopique permet d'étudier les interactions individuelles. Ces modèles (parexemple [BEN94], [KOSO91], [SIBL85]), dits basés entités, décrivent de façon précise lesinteractions entre véhicules. Parmi ces modèles, l’automate cellulaire [SIMO98], le modèle depoursuite décrivent les réactions d'un véhicule par rapport à la perception qu'il a de sonenvironnement, en particulier la façon dont il réagit par rapport aux mouvements des autresvéhicules. Ces modèles sont généralement dédiés à un objectif particulier (comme l'étude deschangements de voie sur une autoroute) mais peuvent être utilisés pour tout type d'étude car desvaleurs macroscopiques peuvent être calculées à partir de résultats microscopiques. Leurutilisation dans le cadre d'une étude portant sur des objectifs macroscopiques doit être réaliséeavec précautions : ils nécessitent une récolte de données importantes (et donc coûteuse) et sontcomplexes à mettre en œuvre. Par exemple, l'étude de l'usure du revêtement d'une autoroute nenécessite pas de modéliser les changements de voies de façon précise.Une approche moins fréquente est l'approche mesoscopique [DEPA96]. Elle utilise les véhiculesmais les considère sous forme de paquets. Leurs mouvements (les changements de file...) sontrégis par des modèles macroscopiques. Elle s'applique très bien lors d'études économiques oud'étude de motifs de déplacements.Quelle que soit l'approche utilisée, la simulation à événements discrets [NAGE94] ou continue[LEON89] est utilisée comme technique d'implémentation.Les outils actuels ne proposent pas d'approche permettant d'utiliser des modèles de typesdifférents pour étudier un même système. GETRAM [GRAU93] propose l'utilisationd'applications à des niveaux de détails différents dans un même environnement, sans proposer

une approche de modélisation associée. TRANSIMS [NAGE94] permet d'utiliser des modèles depoursuite ou une approche par les agents.

2.2 Les modèles multi-agentsL'approche multi-agents est principalement utilisée lorsque le système étudié est de grande tailleet composé d'entités qui interagissent fortement [BURM97]. Les STU possèdent les propriétéssuivantes :• une grande distribution spatiale,• un système de gestion et de contrôle complexe, basé sur la répartition des décisions et sur la

communication entre les différentes entités de gestion du système,• les véhicules possèdent un comportement individuel,• le comportement des entités influence largement l'état du système.En général, les modèles multi-agents sont utilisés, dans le domaine des STU, pour résoudre lesproblèmes associés à la gestion du trafic. Ils s'intéressent à l'analyse de la capacité desintersections, à l'aide à la conception géométrique des intersections, à la détermination des plansde feux optimaux ou proches de l'optimal [FERN99][LIa96], au guidage des véhicules[BAZZ99] et à la modélisation des flottes de transport routier [FISH93]. Le problème à traiterpar un modèle multi-agents peut être unique : coordonner des carrefours à feux entre eux pourque les véhicules aillent de leur origine à leur destination dans les meilleures conditions[EROL98].Les agents peuvent être répartis suivant les niveaux de planification retenus comme le montrentle tableau 1 et la figure 2.

TerminologieArticle

Haut niveau Niveau intermédiaire Bas niveau

[LIa96] Planification globale Planification de groupe Planification individuelle

[BURM97] Niveau coopératif Preneur de décision locale Contrôleur de feux

[FERN99] Décision globale Décision locale Décision individuelle

Tableau 1 : Niveaux par rapport aux décisions.

Figure 2 : Hiérarchie entre les agentsUne liaison peut être faite entre un modèle multi-agents et un modèle client-serveur permettantainsi de mettre en valeur les communications entre les différentes entités du système [LIb96]. Sides agents sont placés sur chaque véhicule, sur chaque intersection, sur chaque feu et sur chaque

rue, le tableau 2 donne les relations entraînant des communications entre les agents. Ces relationspermettent la définition et la conception des communications entre agents.

Agent Est client pour Est serveur pourVéhicule Agents véhicule et de planificationIntersection Informations provenant des agents rue Agents véhicule et de planificationFeu Phasage optimal Agents véhiculesRue Pour les autres agents

Tableau 2 : Relation de type Client-Serveur entre agents.Parmi les applications et implémentations existantes, COTSCS [LIa96] propose unedécomposition en trois parties séparant les fonctions de planification, des fonctions d'évaluationet des fonctions de calcul du coût.Le comportement qui est reproduit par l'agent véhicule est plus ou moins complexe. Parexemple, [LIb96] a simulé les comportements suivant : le déplacement le long d'une rue et dansune intersection, la traversée d'une intersection, le respect des distances de sécurité et lespriorités dans une intersection ainsi que les accidents.Certaines approches [FERN99][BAZZ99], ne s'intéressant qu'aux problèmes de gestion du trafic,utilisent un modèle du type automate cellulaire pour simuler l'écoulement du trafic. Cetteapproche a permis à [FERN99] de tester trois types de systèmes de gestion et de travailler sur descritères qualitatifs (temps moyen d'attente à l'intersection), ainsi que sur des critères d'efficacité(vitesse moyenne).Le domaine des transports se prête particulièrement bien à l'utilisation d'un modèle multi-agents.[BALB2000] utilise ainsi des agents pour améliorer les performances d'un système de transportde bus. Ils sont utilisés pour réalisés une optimisation "continue" de l'espacement entre les buspendant leur service.La coopération est une des propriétés des modèles multi-agents. TRAMAS [FERN99] utilisecette propriété pour fournir une aide à la conception des plans de feux. Il s'intéresse toutparticulièrement à la coopération entre plusieurs intersections se trouvant sur un même axe decirculation.

2.3 ConclusionL'approche multi-agents est utilisée car elle facilite l'implémentation : la même approche estconservée depuis l'analyse jusqu'à l'écriture du code. Actuellement, l'utilisation des modèlesmulti-agents se limite aux aspects de gestion du trafic, sans fournir un cadre général permettantd'aborder d'autres problèmes. Dans ce qui suit, nous proposons une méthodologie demodélisation, orientée objets, qui permet de prendre en compte tous les aspects des STU.L'approche multi-agents sera utilisée pour spécifier la partie décisionnelle des STU. Les apportsde cette approche seront discutés dans la section 5.

3 MéthodologieL'utilisation d'une approche orientée objets permet, dans le cadre d'une méthodologie, deconstruire un modèle générique de connaissance du domaine constitué par les STU. Il sera par lasuite possible de décrire n'importe quel STU. Ce modèle de connaissance sera à la base de laconstruction d'un environnement de modélisation et de simulation [GOUR91].

3.1 Analyse des STULes STU présentent des similitudes avec la classe des Systèmes Industriels de Production. Desétudes antérieures menées au LIMOS et qui se sont traduites, à titre d'exemple, par les thèses de[COM94][GOUJ97][LACO98][RUCH94] ont conduit à utiliser une décomposition en trois sous-systèmes correspondant à une vue conceptuelle du système complet, les trois sous-systèmescommuniquant entre eux (voir figure 3).Ainsi, nous procédons à une décomposition systémique sous la forme suivante :• le sous-système physique (SSP) décrit la topologie des voies de circulation (au sens large du

terme), leurs caractéristiques techniques, et les liens (simple ou complexe) qui permettantleur assemblage,

• le sous-système logique (SSL) contient la description des flux qui parcourent le système.Ceci est réalisé à l'aide de la notion de trajets et des contraintes associées à respecter (parexemple temporelle),

• le sous-système décisionnel (SSD), ou système de pilotage, contient les règles defonctionnement des STU. Ce sous-système est le plus complexe et le plus évolutif. Il est doncnécessaire de le structurer.

Figure 3 : Communications entre les trois sous-systèmes.Le SSD contient deux types de règles : les règles sur le trafic, les lois (juridiques) du système.Certaines décisions sont politiques et non dictées par des impératifs opérationnels. Par exemple,sous la pression de riverains excédés par le bruit, des modifications d'infrastructure et desmodifications du plan de circulation (détournement du trafic poids lourd) sont envisageables.Des solutions pour l'amélioration de l'écoulement, tel que le co-voiturage peuvent être testées enaccord avec la population, de façon à ce qu'elle participe à l'étude. Les règles sur le trafics'intéressent aux possibilités de gestion du système.Ces sous-systèmes permettent de rassembler et de structurer la connaissance du système complet.Le SSD décide des actions à effectuer sur les entités (objets) du SSP, qui en retour lui fournirason état courant (directement lié aux ordres fournis). Les échanges d'informations/décisions entreles sous-systèmes sont du type client/serveur. Ils conduisent au choix du trajet, aux actions àeffectuer (dépassement, accélération...).La modélisation d'un STU consiste donc à identifier le SSP, le SSD et le SSL et à structurer leSSD. La grande variété topologique et les problèmes engendrés par les STU nous incitent àadopter une démarche générique que nous présentons dans les sections suivantes

3.2 Processus de modélisationLe processus de modélisation que nous proposons est un schéma itératif constitué de quatreétapes (figure 4) :

• construction du modèle de connaissance,• conception du modèle d'action,• analyse de l'exécution,• interprétation des résultats.

La construction du modèle de connaissance comprend deux phases. La première phase, dited'analyse fonctionnelle et structurelle du domaine, permet la construction du modèle génériquede connaissance en utilisant la décomposition en trois sous-systèmes. Les objets de chaque sous-système et leurs communications sont modélisées, en utilisant deux des neuf diagrammes UML[CHAB2000], [BOOC99]. Le modèle de communication entre les trois sous-systèmes estimportant car il permet de décrire les interactions entre les objets des sous-systèmes du point devue des décisions.Dans la seconde phase, de spécification des entités du domaine et de leur fonctionnement, nousnous intéressons à la description, à l'aide d'UML, des comportements reproductibles d'unsystème à l'autre (par exemple le fonctionnement d'un système de gestion est exprimé à l'aided'un diagramme d'états-transitions).Ces deux phases sont réalisées selon une vue microscopique (qui est le niveau de détail le plusfin). Le modèle générique obtenu demeure cependant global du point de vue de la spécification.L'étape suivante de conception du modèle d'action procède selon deux phases d'analyse et despécification. L'analyse permet de replacer le modèle générique de connaissance par rapport autype d'application souhaitée. La méthodologie propose d'utiliser la simulation comme outild'évaluation des performances. Deux actions sont donc à réaliser : adapter les classes existanteset ajouter de nouvelles classes de gestion. Les classes existantes doivent être modifiées pour êtreimplémentées sous la forme de classes de simulation. Un attribut permettant d'identifier lesobjets instances de classe est ajouter à toutes les classes. La classe correspondant à la voie decirculation reçoit de nouveaux attributs tels qu'une liste pour stocker les véhicules qui l'utilisent.Des classes dédiées doivent être ajoutées pour permettre la "simulation" du modèle générique deconnaissance. Des structures de données telles que les graphes, les listes ainsi que les méthodesassociées sont rajoutées au modèle de base. La spécification des différentes classes présentesdans le modèle générique de connaissance est réalisée selon différents formalismes. Cesformalismes (équations aux dérivées partielles-EDP, automate cellulaire… ) permettent defournir plusieurs vues de chaque classe. Ils correspondent à des modélisations envisageables (ouabstractions) pour le domaine étudié, permettant de prendre en compte différents niveaux dedétails. Certains formalismes, telles les EDP, permettent de créer des spécifications génériques.Il est alors nécessaire de préciser la technique de résolution, l'algorithme de parcours, la fonctionreliant les variables (dans le cas de modèles macroscopiques) pour obtenir des modèlesdirectement utilisables. Il nous sera ainsi possible de spécifier les parties d'un même systèmeavec des formalismes différents, autorisant ainsi une modélisation multiple des STU.L'implémentation est réalisée en utilisant des langages de programmation, de simulation ou dessolveurs mathématiques.L'analyse de l'exécution est constituée d'une phase de vérification-validation du modèle, etd'une phase d'évaluation des performances. Cette dernière est réalisée par rapport aux critèreschoisis.

L'interprétation des résultats entraîne des modifications sur le système réel ou sur le modèle.

Figure 4 : Processus de modélisation.

4 Modèle générique des STUNous détaillons dans cette partie un extrait du modèle générique de connaissance construit pourla classe des STU. Une description complète du modèle générique de connaissance est donnéedans [CHAB2000]. Cet extrait concerne le système d'information (SI) des STU, c'est-à-dire lesous-système décisionnel.

4.1 Modèle générique orienté objetsLe SSD des STU à la charge de contrôler et de gérer le système. Compte tenu de la complexitétoujours croissante des STU, leur SSD n'a cessé d'évoluer et de se complexifier. Il possède unestructure hiérarchique et décentralisée. Classiquement, un SSD est composé des élémentssuivants (voir figure 5)• d'un poste central d'exploitation assurant la coordination d'ensemble,• d'un réseau de transmission, permettant d'envoyer des commandes (plan de feux) et de

recevoir des informations sur l'état du système,• de coordinateurs de zones, maillons intermédiaires qui assurent une coordination locale de

groupes de carrefours.La coordination d'ensemble est généralement réalisée depuis le poste central d'exploitation. Latendance actuelle est à la construction de coordinateurs locaux prenant en charge une partie dusystème (en général, une intersection) : ce sont les carrefours intelligents.Des capteurs et des détecteurs permettent d'obtenir l'état courant qui est ensuite fourni au postecentral d'exploitation. Les capteurs sont disposés sur le réseau, les détecteurs traduisent leursinformations électriques sous la forme d'une densité, d'un débit… Des contrôleurs de carrefourassurent le déroulement des plans de feux en cours et la gestion des transmissions avec le postecentral d'exploitation.

Le poste central d'exploitation gère le STU. Il possède des fonctionnalités de recueil et destockage des informations provenant du réseau. Il gère une bibliothèque de plans de feux, etpossède un algorithme lui permettant de choisir à tout moment le bon plan de feux. Il est capablede fonctionner en mode dégradé. Le nombre de feux à gérer étant conséquent, des frontaux sontgénéralement employés pour servir de tampons entre le réseau et le poste central. Dans ce cas, ilsassurent la transmission entre le réseau et le poste central, calculent les plans de feux transitoires(lors d'un changement de plan de feux) et vérifient l'état des différents contrôleurs.Cet équipement est conçu de façon modulaire, chaque module pouvant assurer la gestion deplusieurs carrefours.

Figure 5 : Schéma de principe d'un système de décision de STU.La modélisation proposée utilise la notion de centre de décision [GOUJ97], noté CDD. Uncentre de décision modélise une entité du système apte à prendre des décisions et à contrôlerd'autres entités. Un centre de décision peut être local, global ou composé d'un ensemble decentres de décision qui coopèrent. Ceci permet de modéliser un processus décisionnelhiérarchique et décentralisé. Un centre de décision peut gérer une ligne de feux. Une ligne defeux correspond à l'ensemble des feux d'un carrefour qui fonctionne à l'identique, tout en étantaffecté à des flux de circulation différents. Le centre de décision assure plusieurs fonctions degestion et de prise de décisions. Il doit appliquer les plans de circulation, envoyer et/ou modifierles plans de feux et contrôler l'ensemble du système. Comme le montre la figure 6, cettemodélisation permet d'exprimer le caractère hiérarchique et décentralisé de la prise de décision.

Figure 6 : Diagramme de classes du sous-système décisionnel.

5 Modèle multi-agentsAprès quelques rappels sur les agents que nous utilisons, nous montrons comment unemodélisation multi-agents complète la modélisation proposée. Cette approche sera développée enprécisant quelques aspects de notre modèle multi-agents. Nous insisterons sur la structure internedes agents utilisés, et sur leur placement.

5.1 Rappels sur les agentsUn agent peut être considéré comme une entité physique ou abstraite capable d'agir par elle-même dans le monde environnant dont il a une représentation partielle [FERB95]. Desinformations parviennent à l'agent qui utilise sa base de connaissance pour appliquer au mieuxune de ses méthodes de résolutions pour résoudre le problème qui lui est posé. Son choixeffectué, il avertit les autres agents pour qu'ils puissent en prendre compte dans leurcomportement futur. Un agent interprète ainsi les événements qui surviennent dans sonenvironnement, communique avec les autres agents, agit selon un comportement propre etpossède des capacités d'action sur son environnement.Dans certains modèles multi-agents, un ensemble d'agents peut posséder un même objectifcommun. Ces agents forment alors une société. Il faut définir le comportement propre à chaquesociété pour les agents qui en font partie.Les communications entre agents peuvent s'effectuer selon différents protocoles. Nous avonschoisi d'utiliser la technique des tableaux noirs. Les agents renseignent et accèdent aux tableauxnoirs en exclusion mutuelle. Les tableaux noirs sont différents selon qu'un agent communiqueavec ses subordonnés ou avec des agents de la même société. L'utilisation des tableaux noirsnous semble pertinente car :• ils autorisent une représentation distribuée des communications entre agents. Ils autorisent

une grande souplesse dans le développement du système, car les communications sont

représentées de façon indépendante, elles peuvent être facilement modifiées sans remettre encause celles existantes.

• ils permettent une représentation explicite des informations échangées. Le modèle destableaux noirs offre une structure commune, au sein de laquelle se construit progressivementla solution du problème pour lequel on a implanté le système multi-agents.

• ils favorisent la mise en place de raisonnements opportunistes. Les décisions d'un agent sontinfluencées par le contenu des tableaux noirs auxquels il a accès et qui l'informent de lasolution en cours de construction. La prochaine décision prise est déterminée en cours derésolution, à un instant donné et ne peut être déterminée a priori. Lorsqu'un agent dépose unedonnée dans un tableau noir, il ne connaît pas toujours les agents qui vont exploiter cesdonnées. Ceci est à opposer aux communications directes par envoi de messages.

• ils permettent une architecture souple. Les tableaux noirs constituent un puissant outil dedéveloppement en raison de l'indépendance des constituants. L'ajout ou la suppression detableaux noirs ne remet pas en cause l'architecture du modèle multi-agents construit.

5.2 Les centres de décisions et les agentsL'approche orientée objets permet de décrire précisément le SSP et le SSL des STU, et demodéliser le SSD. Cependant, une telle modélisation ne permet pas d'exprimer lescommunications entre les centres de décision de façon simple et complète.L'approche orientée objet permet de décrire la hiérarchie des composants du SSD. Modéliser lescommunications entre ces composants correspond à modéliser le processus décisionnel. Il estdonc important de posséder une approche permettant d'expliciter précisément et clairement cetaspect. La classe centre de décision doit posséder toutes les primitives pour traiter tous lesévénements possibles et les communications entre deux classes du SSD doivent être précisées.Dans les deux cas, se posent des problèmes de résolution d'appel. Les objets d'une classe doiventêtre capables de déterminer qui à envoyé le message pour savoir quelle méthode lancer. S'il nesait pas résoudre l'appel, il devra passer le message à son supérieur. Cette résolution se poursuitjusqu'à l'objet poste central d'exploitation. La réponse devra suivre le cheminement inverse. Laspécification des communications va nécessiter l'implantation d'une nouvelle classe d'objet,indépendante des STU, dédiée à la gestion des communications entre objets du SSD. Nousobtenons donc un modèle, à la complexité structurelle identique à celle d'un modèle multi-agents, sans en posséder les avantages.Le processus décisionnel, et la structure physique du SSD possèdent des caractéristiques quijustifient une approche multi-agents. Le fonctionnement du SSD est centralisé (il existe un postecentral de commandes) et décentralisé (chaque coordinateur de zones peut décider par lui-mêmedes règles de gestion à appliquer). Il possède également une distribution spatiale forte (lesystème de gestion est délocalisé dans tout le réseau). A cela, s'ajoutent les évolutions actuelles(guidage des véhicules, carrefour intelligent…) pour lesquelles l'approche multi-agents sera utile.Cette approche est donc avantageuse du point de vue de la description des communications etpour le passage au modèle d'action.

5.3 Modèle dynamique d'un agentUn agent réagit par rapport aux événements locaux à son environnement, déclencheurs de sesdifférents processus. Ces événements sont soit des décisions provenant du SSD soit unchangement d'état d'un objet du SSP (changement de couleur d'un feu, panne d'un feu…). Ces

événements extérieurs entraînent des événements internes au fonctionnement de l'agent. Unagent possède deux états :• il est au repos, lorsqu'il est en attente d'un événement déclenchant,• il est actif, lorsqu'un événement déclenchant survient. Il procède alors à ses différentes

activités.Lorsqu'il est en activité, il utilise un algorithme de résolution pour effectuer une des cinqactivités dont l’enchaînement est présenté par la figure 7.

Figure 7 : Diagramme d'activité d'un agent.• récolte des données de son environnement, par rapport à l’événement qui l’a réveillé.• analyse des données : il décide si son action est nécessaire ou non.• activité d’action : il va par exemple calculer un nouveau plan de feux. Les résultats ainsi

obtenus doivent être transmis à d'autres agents, et/ou aux entités contrôlées par cet agent.• l’activité de communication permet à l'agent d'écrire dans les tableaux noirs auxquels il a

accès (pour communiquer avec d'autres agents) et de fournir des données aux entités qu'il

contrôle. Par exemple, s'il décide de ne pas agir, il informera les tableaux noirscorrespondants de sa mise au repos.

• l'activité d'analyse des conséquences est effectuée s'il a déclenché son activité d'action.Cette analyse permet de mettre à jour les données internes de l'agent pour qu'il puissecontinuer son évolution : il met à jour sa base concernant ses actions et les conséquencesassociées. Ceci lui évite de prendre deux fois la même mauvaise décision sur un mêmecontexte.

5.4 Structuration du SSDLa structuration du SSD peut s'envisager de façon hiérarchique et/ou décentralisée.Une structure hiérarchique permet de réduire la quantité d'informations échangées entre lesdifférents agents, mais rend plus difficile la notion de coopération. Elle facilite l'implantation descommunications mais réduit l'autonomie de décision des agents.Une structure décentralisée augmente l'autonomie des agents et la flexibilité du système multi-agents utilisé. Néanmoins, son implantation est plus complexe car le nombre de liens à construirepour permettre les communications locales et globales est important.Cependant, compte tenu des remarques précédentes sur les STU, une approche mixtehiérarchique décentralisée est adaptée (voir figure 8).

Figure 8 : Structure du modèle multi-agents.Les communications entre agents sont réalisées par l'écriture et la lecture dans les tableaux noirs.Un agent a accès à deux types de tableaux noirs :• les tableaux noirs du même niveau lui permettant de communiquer avec les agents situés au

même niveau dans le processus décisionnel. L'agent peut donc appliquer des règles locales entirant partie des informations qu'il récolte dans ces tableaux noirs.

• les tableaux noirs de niveau supérieur lui permettant de communiquer avec les agents situés àdes niveaux hiérarchiques plus élevés. Cela permet de propager des informations dans tout lesystème.

Il est nécessaire de préciser la communication entre les agents, la figure 8 ne présente en effetque la structure générale du modèle multi-agents. Les communications entre agents se déroulentà deux niveaux : dans une même société d'agents, et entre agents de niveaux différents. Undiagramme de collaboration UML (figure 9) permet d'exprimer la façon dont les agentscommuniquent entre eux, quel que soit leur niveau. Les agents d'une même société (d'un même

rang hiérarchique) peuvent communiquer entre eux via un tableau noir. Les communicationsentre différents niveaux hiérarchiques sont également réalisées via un tableau noir. Cependant,les agents peuvent consulter et écrire dans les tableaux noirs pour lesquels ils sont autorisés.

Figure 9 : Communications inter et intra sociétés.La figure 9 permet de préciser qu'un agent local peut communiquer directement avec l'agentCDD global s'il ne fait pas partie d'une zone contrôlée par un agent CDD Groupe. Ceci permet deprendre en compte l'hétérogénéité des systèmes réels dans lesquels un système de gestion localpeut être simple ou complexe.

5.5 Placement et objectifs des agentsNous devons préciser à quelles entités nous devons associer les agents et l'objectif de chaqueagent.En utilisant le modèle de classe du SSD (figure 9) comme base du modèle multi-agents, nousobtenons la figure 10 qui propose d'associer un agent à toute entité décisionnelle. Cela restecohérent avec la définition d'un agent puisque une entité de ce type a comme objectif demaintenir le système dans un état fluide.Chaque agent possède un objectif propre qui lui permet de participer à la résolution d'unproblème plus complexe. Il faut donc déterminer l'objectif de chaque agent.Le rôle de l'agent CDD global est de coordonner l'ensemble des autres agents pour que l'état dusystème reste stable. Grâce aux informations que les agents CDD locaux et les capteurs luifournissent, il connaît l'état actuel. Cet agent possède la connaissance sur le système. Il est apte àchoisir de modifier tel ou tel plan de feux pour améliorer le fonctionnement du système. Il est leseul agent à connaître les corrélations entre les différents plans de feux. Son rôle est doncd'assurer un contrôle global sur le système par le choix d'un ensemble de plans de feuxcompatiblesL'agent CDD local ne possède qu'une connaissance très limitée du système puisqu'il gère un ouplusieurs carrefours. Son rôle est d'assurer l'écoulement du trafic pour la partie du système qu'ilcontrôle. Il doit le faire en respectant le plan de feux fournit par le CDD global. Il peut cependantallonger ou raccourcir certaines phases de ce plan sans en avertir le CDD global. Il effectue uneamélioration locale par rapport à une solution globale. Ceci est rendu possible par la définitionmême des plans de feux dans lesquels sont définies des marges de sécurité. Ces marges

permettent par exemple d'assurer que le carrefour sera vide avant le passage à une nouvellephase.

Figure 10 : Placement des agents par rapport au SSD.

6 Etude de cas : la place DelilleNous présentons la conception du modèle de simulation de la place Delille de Clermont-Ferrand(voir Figure 1). Cette place est un sous-système urbain typique qui peut être vu comme unsystème. Plusieurs grands axes se rencontrent et partent de cette place, et de nombreux capteurset feux (treize lignes de feux) sont présents. Les objectifs de l'étude sont de tester lecomportement du système de pilotage dans des conditions normales de fonctionnement et en casde panne. L'étude de la signalisation disposée en cas de pannes est le second but de l'étude. Elledoit permettre l'écoulement d'une charge quasi maximale dans une situation exceptionnelle.L'étude de la place est décomposée en deux phases avec la modélisation de la partie sud puis dela partie nord. Le modèle de connaissance puis le modèle d'action sont construits pour ces deuxparties puis réunis. Les données utilisées proviennent des services techniques de la mairie, enparticulier la matrice origine-destination. Dans le système réel, trois cycles existent pour unejournée : un de 9h à 11h et 14h à 15h, un de 19h à 21h et 13h à 14h, un de 11h à 13h et 17h à19h. La simulation (voir tableau 3) nous donne le temps moyen de résidence pour les véhiculeset le nombre de véhicules par voies où QiUj est la voie j du tronçon i.Le modèle de simulation construit est microscopique car les valeurs à déterminer sont le nombrede véhicules présent dans la place et leur position. Dans ce cas, seul un modèle microscopique

convient. Les centres de décision sont présents sur chaque jonction de la place pour permettre degérer les lignes de feux et de respecter le code de la route. Compte tenu de la configuration dusystème de gestion de la place, le modèle comprend un agent global, treize agents locaux gérantles lignes de feux. Le système étudié ne contient pas de politique dynamique de modification desplans de feux. Les agents locaux demandent à l'agent global un nouveau plan de feux lorsque lapériode d'utilisation du plan actuel est terminée.L'analyse des résultats montre que certains tronçons ne sont pas affectés par la panne du systèmede pilotage. Ailleurs, un phénomène de remontée de file est visible. Deux trajets de A à B et de Cà D (voir figure 11) demeurent fluides pendant certaines périodes. Ceci est dû à la variation de lademande pendant la journée. De plus, certains tronçons ne sont plus utilisés pendant la durée dela panne.Pour obtenir des résultats plus généraux tels que le temps moyen de parcours, on utilise lesformules suivantes :

Où ui =1 si le véhicule utilise une voie réservée,STi le temps moyen de présence pour la voie i,R représente une voie privée, par exemple pour les bus,

Temps de trajetmoyen par

période

Temps de trajetmoyen par

périodeVoies7h-9h 7h-9h

panne

Différence Voies7h-9h 7h-9h

panne

Différence

QU8V1 302 13 -289 QU19V1 26 26 0 QU4V1 100 6 -94 QU16V2 353 355 2 QU3V3 67 1 -66 QU15V2 996 40 -956 QU3V1 1158 49 -1109 QU14V1 174 2 -172 QU21V2 125 4 -121 QU13V3 386 12 -374 QU20V2 745 343 -402 QU13V2 421 14 -407 QU1V3 285 19 286 QU12V1 1456 59 -1397 QU19V2 324 329 5

Tableau 3 : Résultats pour les périodes 7h-9h normal et 7h-9h avec panneSupposons qu'une voiture emprunte le trajet 1-2-3 (1,2,3 étant des voies) alors :

Pour un bus, si les voies 1 et 3 sont réservées, alors :

( )� =+= n

i iRiivéhicule STuSTTT 1*

STSTSTTT car 321++=

STSTSTTT RRcar 321++=

Cela a permis aux services techniques de tester leurs politiques de gestion et d'évaluer l'impactd'une panne du système de gestion. La propagation des encombrements étant connue, lespanneaux permettant la gestion du trafic dans ce cas sont plus simples à déterminer, ceci avec unniveau de sécurité élevé.

Figure 11 : Résultats de simulations.

7 ConclusionL'approche méthodologique présentée propose une structuration du SSD par les agents pourcompléter la modélisation orientée objets. Le processus décisionnel et les communicationsassociées sont mieux décrites. L'utilisation de l'approche multi-agents permet de hiérarchiser laprise de décision (et donc de l'information) dans le système, de répartir la puissance des outils derésolution, d'autoriser la validation du processus décisionnel, de favoriser la collaboration et lacoopération des entités de décision. Les communications et les connexions entre agents sontsystématisées par le biais de la méthodologie présentée. L'approche a été utilisée sur plusieursexemples significatifs (tel que celui présenté dans l'article) et d'autres problèmes sont en coursd'étude.

8 Bibliographie[BEN94] Ben-Akiva, M.E, Koutsopoulos, H. and Mukundan, A. 1994 A dynamic traffic

model system for ATMS/ATIS operation. IVHS Journal.. 2. 1-19. MITTNS.[BALB2000] Balbo, F. et Scemama,G. 2000. Modélisation d'une perturbation sur un réseau de

transport : le modèle incident. XVIIIème Congrès INFORSID, Lyon, pp 210-228.[BAZZ99] Bazzan, C., Wahle, J., et Klügl, F. 1999. Agents in Traffic Modelling - from

Reactive to Social Behaviour. Publié dans les actes de The 23th Annual German

Conference on Artificial Intelligence in Königswinter (Germany), édité parW.Burgard, A.B. Cremers et T. Chrsitaller, Springer Berlin.

[BOOC99] Booch, G. Rumgaugh, and Jacobson, Y. The UML user Guide. Addisson Wesley1999.

[BUIS96] Buisson C., Lebacque J.P., Lesort J.B., and Mongeot H., 1996. The STRADAdynamic assignment model. Third annual world congress on intelligent transportsystems, Orlando. Floride.

[BURM97] Burmeister, B. and Doormann, J. and Matylis, G. 1997 Agent-Oriented TrafficSimulation. Special Issue : Multi-Agent Systems Simulation, vol 14, n° 2,pp 79-86, 1997.

[CHAB2000] Chabrol M. and Sarramia D., 2000. Object oriented methodology based on UMLfor urban traffic system modeling. In Third International Conference on theUnified Modeling Language (UML2OOO), volume 1939 of LNCS, p. 425-439.Springer-Verlag.

[COM94] Combes, C., 1994. Méthodologie de modélisation orientée objets des systèmeshospitaliers. Doctorat en informatique, Université de Clermont-Ferrand II

[DEPA96] De Palma, A. and Marchal, F. and Nesterov, Y., 1996. METROPOLIS : a modularsystem for dynamic traffic simulations.

[EROL98] Erol, K. , Levy, R. and Wenthwroth, J. 1998. Application of Agent technology totraffic simulation. http://www.tfhrc.gov/advanc/agent.html.

[FERB95] Ferber, J. 1995 Les systèmes multi-agents : vers une intelligence collective.InterEdition.

[FERN99] Fernandes, J.M., Oliveira, E. 1999 TraMas : traffic control through behaviour-based Multi-agent system. In PAAM99 - The Practical Application of IntelligentAgents and Multi-Agents, London.

[FISH93] Fisher, H. and Kuhn, N., 1993. A DAI approach to modeling the transportationdomain. Deutsched Forschungszentrum für Künstliche Intelligenz GmbH.Research Report RR-93-25.

[FISH95] Fishwick, P., 1995. Simulation model design and execution : building digitalworlds. Prentice Hall, Englewood Cliffs, New Jersey.

[GOUJ97] Goujon, J.Y., 1997. Un environnement de modélisation multi-agents pour laspécification et l'évaluation des performances des systèmes industriels deproduction. Doctorat en informatique, Université de Clermont-Ferrand II.

[GOUR91] Gourgand M. and Kellert P., 1991. Conception d'un environnement demodélisation des systèmes de production. Troisième congrès international deGénie Industriel, Tours.

[GRAU93] Grau R. and Barcelo J., 1993. The design of Getram: a generic environment fortraffic analysis and modeling. Technical Report DR 93/02, Departamento deEstadistica e Investigacion Operativa. Facultad de Informatica. UniversitaPolitecnica de Cataluna.

[GREE35] Greenshield, B.D. 1935 A study of traffic capacity. Proceedings of the HighwayResearch Board. Vol 14, pp 448-477.

[KOSO91] Kosonen,I. and Pursula, M. 1991 A simulation tool for traffic control planning.IEEE Conference Publication Number 320. Third international Conference onRoad Traffic Control. vol 320 pp 72-76.

[LACO98] Lacomme, P. ,1998. Optimisation des systèmes de production : méthodesstochastiques et approches multi-agents. Doctorat en informatique. UniversitéClermont-Ferrand II.

[LEON89] Leonard D., Grower P., and Taylor N., 1989. CONTRAM: structure of the model.Technical Report 178, TRRL.

[LI96a] Li, M. et al ,1996 A Cooperative Intelligent System for Urban Traffic Problems.Tiré de 1996 IEEE Symp. on Intelligent Control, et Rapport Interne N°822,Department of Artificial Intelligence, University of Edinburgh.

[LI96b] Li, M., Chong,KW; Chan,S.Y.; Hallam,J.C. ,1996. Agent-Oriented Urban TrafficControl Simulation. Research Paper n° 827. Department of Artificial Intelligence,University of Edinburgh, publié dans les actes de the 1st Annual InternationalConference on Industrial Engineering Application and Practice, Houston, Texas,USA.

[LIGH55] Lighthill, M.J., and Whitham, G.B. 1955. On kinematic waves II : a theory oftraffic flow on long crowded roads. Proc. R. Soc. (Lond), Ser A., 229). 1178 pp317-345.

[NAGE94] Nagel K. and Scheilcher A., 1994. Microscopic traffic modelling on parallel highperformance computers. Parallel Computing, (20) p. 125-146.

[PRIG71] Prigogine I. and Herman R., 1971. Kinetic Theory of Vehicular Traffic. AmericanElsevier Publishing CO., New-York.

[RUCH94] Ruch, S., 1994. Un environnement de modélisation multi-domaine des systèmes àflux discrets. Doctorat en informatique. Université Clermont-Ferrand II.

[SIBL85] Sibley, S. W., 1985. NETSIM for microcomputers - simulates microscopic trafficflow on urban streets. Public Roads.. Pp 49.

[SIMO98] Simon, P.M. and Nagel, K., 1998. Simplified cellular automaton model for citytraffic. PHYSICAL REVIEW E, vol 58, n°2 pp 1286-1295.

[TRB96] Traffic flow theory : A Monograph. Transportation Research Board, TRB185,1996.

[WILS74] Wilson, A.G., 1974. Urban and regional models in geography and planning. J.Wiley and Sons, London.