Alexandre Bonhomme

Philippe Mathieu
email: philippe.mathieu@univ-lille1.fr

Sébastien Picault

A versatile description framework for modeling behaviors in traffic simulations

Keywords: Multi-Agent Simulation, GIS, Road Traffic, Traffic Generator, Decision Support System

Microscopic simulations of road traffic are a typical application domain for Multi-Agent Systems. Indeed, the individual-based approach allows to take into account the diversity of behaviors so as to consider real situations. More recently, geographical databases provide environmental information under open formats, which offers the opportunity to design agent-based traffic simulators which can be continuously informed of changes in traffic conditions. The use of such data, together with the adaptability of MAS, allows the realization of decision support systems that are able to integrate environmental and behavioral modifications in a direct way, and compare various scenarios built from different hypotheses in terms of actors, behaviors, environment and flows. We describe here a modeling approach and a comprehensive process which lead to the development of such a tool.

I. INTRODUCTION

Traffic simulation is a domain where the individual-based approach proved very early its benefits [START_REF] Espié | Microscopic traffic simulation and driver behaviour modelling: the ARCHISIM project[END_REF], [START_REF] Champion | Traffic generation with the SCANeR TM simulator: towards a multi-agent architecture[END_REF], especially to evaluate the impact of individual decisions on the macroscopic state of road traffic or, more recently, on the capacity to integrate a statistical variability in norm violation by drivers [START_REF] Lacroix | Formalizing the construction of populations in multi-agent simulations[END_REF].

One major difficulty in designing a traffic simulator is the diversity of goals: flux study, binnacle ergonomics, local effect of roads planning modifications on drivers behavior... Concerned space and time scales varies considerably and leads in general to ad hoc models (i.e. designed for a particular usage) which are hard to revise. In fact, in a domain like transportation, this multiplicity of goals and scales might rather be taken into account as a general context for the design of the simulation tool, in order to answer really different questions with a homogeneous platform composed of easily modifiable models from explicit knowledge. Thus, it is possible to build a library of behavioral models that could be reused in different contexts and for different purposes, selected according to simulation hypotheses and usage scenarios.

Furthermore, in order to ensure maximum reliability in simulation results, it is necessary to configure the environ-ment and agent behaviors on the basis of real data. Regarding agent behavior, we have already proposed methods in this direction for transports [START_REF] Lacroix | Formalizing the construction of populations in multi-agent simulations[END_REF] and others domains [START_REF] Mathieu | From real purchase to realistic populations of simulated customers[END_REF]. We are going to show here that behaviors can be coupled with an environment built from cartographic data, and parameterized by (or compared with) road flux information.

In the following, we present in particular TrafficGen, an experimental traffic simulator that we have developed as proof of concept for assessing our approach. It does not aim currently at competing in performance or in quality with professional, specialized tools like ArchiSim, SCANeR II or Synchro Studio, but rather at determining how to build a decision support tool which allows a simple continuous update of data, as well as an easy revision of models and comparison of scenarios.

This article is organized as follows. First, we give an overview of available open data, their sources and structures. Then we consider the state of the art in traffic simulation, and discuss the workflow we define for acquiring, filtering, structuring data, integrating them in TrafficGen and finally analyzing the simulation outputs. We also explain how to build a multi-agent model which is modular, easily extensible and reviewable. We illustrate our approach on a simple experiment, before concluding about the perspectives of this work.

II. STATE OF THE ART A. Simulation platforms

There is a large diversity of traffic simulators based on multi-agents systems or cellular automata. However, most of these applications are commercially oriented and exposes only very few design details. We can especially name Synchro Studio 1 with SimTraffic, Aimsun 2 , PTV Vissim 3 , Paramics 4 or also TransModeler 5 .

On the fringes of those systems we also find corporate software like ArchiSim [START_REF] Espié | Microscopic traffic simulation and driver behaviour modelling: the ARCHISIM project[END_REF], SCANeR II [START_REF] Champion | Traffic generation with the SCANeR TM simulator: towards a multi-agent architecture[END_REF] or Megaffic [START_REF] Osogami | IBM Mega Traffic Simulator[END_REF] which are based on the multi-agent paradigm [START_REF] Chen | A review of the applications of agent technology in traffic and transportation systems[END_REF], [START_REF] Bazzan | A review on agent-based technology for traffic and transportation[END_REF]. Nevertheless, these tools are dedicated to specific issues of IFSTTAR (the French research institute on transport), Renault and IBM, such as targeted studies about drivers psychology, the vehicle cabin ergonomics or else massive microscopic simulations. Their architectures are custom built (in terms of infrastructure software and hardware), behaviors are specialized and hardly extensible. Similarly, the DIVAs [START_REF] Al-Zinati | DIVAs 4.0: A multi-agent based simulation framework[END_REF] framework (initiative of the University of Texas at Dallas) is more centered on agent vision problems.

Finally, some open source alternatives exist, such as MAT-Sim [START_REF] Raney | An improved framework for largescale multi-agent simulations of travel behavior[END_REF], SUMO [START_REF] Krajzewicz | Recent development and applications of SUMO -Simulation of Urban MObility[END_REF] or MITSIMLab [START_REF] Yang | Simulation laboratory for evaluating dynamic traffic management systems[END_REF]. Only MATSim and SUMO are based on a multi-agent system. Both allow the usage of geographical data (GIS). They also have the advantage to simulate a large number of vehicles, at the price of a poor flexibility of the simulation mechanisms. Vehicles own only a small number of behaviors, reducible to a carfollowing model and the lane changing feature. Such simple and naive behaviors are also provided in the multipurpose platform GAMA [START_REF] Taillandier | GAMA: A simulation platform that integrates geographical information data, agent-based modeling and multi-scale control[END_REF]. In all cases, the revision and extension of the behavioral model is the main issue.

B. Behavioral models

In most traffic simulators, modeling efforts essentially focus on vehicles which are in general the only agents in the system. All the traffic complexity is modeled through the perception, cognition, actions capabilities of those agents only and through their behaviors and interactions. Morevover, the majority of modeling works try to address issues in multiple areas: perception (e.g. active perception [START_REF] Bourgois | Towards contextual goal-oriented perception for pedestrian simulation[END_REF], virtual lanes [START_REF] Bonte | Virtual lanes interest for motorcycles simulation[END_REF], vision cones [START_REF] Kuiper | Agent vision in multi-agent based simulation systems[END_REF]), drivers psychology [START_REF] Mandiau | Behaviour based on decision matrices for a coordination between agents in a urban traffic simulation[END_REF], their report to standards [START_REF] Lacroix | Generating various and consistent behaviors in simulations[END_REF], [START_REF] Doniec | A behavioral multi-agent model for road traffic simulation[END_REF] or also the usage of game theory to manage conflicts in crossroads [START_REF] Mandiau | Behaviour based on decision matrices for a coordination between agents in a urban traffic simulation[END_REF].

Though the majority of these models have been subject to separate validations, the combinations of their underlying assumptions obviously raise serious evaluation issues. An accurate psychological model of drivers does not guarantee indeed that the population of simulated vehicles is more realistic at the macroscopic level. To design a tool which allows to test and compare various scenarios or assumptions, the problem is not to choose and implement one particular psychological theory or another one, but rather to permit the user to: 1) access explicitly (and intelligibly) the behavioral models that reflect these assumptions, 2) choose those to use in a scenario, 3) redesign easily the experiment, without having to rewrite any line of code.

Before explaining how we implement this approach in Traf-ficGen, we have to present the issue of retrieving information for the simulation.

III. OPEN FORMAT DATA

For some time, the increasing number of initiatives aimed at providing geographical data in different open formats, provides an opportunity for, on the one hand, building on-the-fly, up-to-date multi-agent environments for traffic simulation and, on the other hand, reproducing real-time traffic state in a simulation (or compare the outputs of a particular hypothesis to the real situation). We present in this section some of these formats and their usage.

A. Cartographic data

During the last fifteen years there has been a lot of new cartographic and routing online services. Among them, the OpenStreetMap project (OSM6 ), created in 2004 at the University College, London, is a participatory initiative based on users contributions (like Wikipedia). Elements listed in OpenStreetMap are extremely diversified (details and functions of building, speed limits, tourist information, etc.) and the data format is open.

We can also mention OpenDrive7 , which is an open format developed by private companies in 2005 (VIRES Simulationstechnologie GmbH). This format focuses more specifically on road features (geometry of the pavement, slopes, elevation, nature of the coating, etc.) and was developed in order to standardize the simulation of vehicle prototypes on test circuits.

B. Flow information

Besides this cartographic information, a simulation must be able to take into account realistic vehicles flows. Though it is possible to use flow generators (e.g. MNTG [START_REF] Mokbel | MNTG: An extensible web-based traffic generator[END_REF]) which generate vehicles with scripted routes from a map, real traffic data is obviously a better way either to calibrate the flows of simulated vehicles or to validate simulation ouputs. The availability of such data is currently increasing both at national and urban scales.

For instance the French National Traffic Information Centre ("Bison Futé") provides freely and in real time (every 6 min.) data about the main highways of the national road network and the main cities 8 . Those data use the Datex II format 9 (i.e. European exchange format for road traffic information), which indicates events (car crash, traffic jam, etc.) but also traffic indicators for each measure point of the network: flow rate (number of vehicles per period of measure), occupancy rate (ratio between total vehicles length on a section and length of this section) and mean vehicles speed. These informations allow to recreate a population of simulated vehicles, which owns similar characteristics.

Likewise, most of big cities have static measurement systems: e.g. in France, SIREDO 10 based on magnetic loops under the road, which provides information every 15 min (flow, mean speed, etc.) or each hour (occupancy rate). In addition, punctual measurements with pneumatic tubes may often complement this information.

C. Road infrastructure creation

A road can be represented as a sequence of nodes knowing their possible predecessors or successors. Vehicles move along a straight line from a node to the next one and get the next possibles routes when they arrive on a node. In TrafficGen, vehicles have a logical position on the axial line of the road: the visualization of the road or the position of vehicles on his lane are only a graphic representation as shown on figure 1.

v1 v2 v3 (a)
v1 [START_REF] Lacroix | Formalizing the construction of populations in multi-agent simulations[END_REF] v2 [START_REF] Espié | Microscopic traffic simulation and driver behaviour modelling: the ARCHISIM project[END_REF] v3 [START_REF] Champion | Traffic generation with the SCANeR TM simulator: towards a multi-agent architecture[END_REF] (b) Thus, the initialization of the simulation environment involves to read nodes and ways from a database, so as to instantiate them and build the graph defining the road network topology. Yet, some nodes are just an inflection point in the road (only one possible output), while others are more complex junctions which bring several directions (i.e. crossroads) and imply that the vehicles make a choice. Moreover, GIS data (i.e. OpenStreetMap or OpenDRIVE) provide indications on road infrastructure which have to be reified in the simulation (e.g. traffic signals, stops, etc.) to enhance the realism of vehicles behaviors. More generally, the capability of integrating other road network elements (e.g. pedestrian, cycles, bus lanes, tram lines, etc.) implies to associate GIS elements with corresponding entities situated in the environment. Finally, in order to test scenarios the simulation needs to include vehicles generation points (able to reproduce flows from real data) and measurement tools.

Considering the large diversity of these entities and the need to extend them according to modeling issues and goals, we advocate a clear separation between declarative and procedural model aspects, but also an approach where all entities are handled homogeneously. Therefore, we use the interaction-oriented approach "IODA" [START_REF] Kubera | Everything can be agent![END_REF], [START_REF]IODA: An interaction-oriented approach for multiagent based simulations[END_REF] which states that every entity is an agent and that every behavior must be defined as a generic rule between agents (called an interaction). This leads to the design of separate, reusable agents and interactions libraries, which are processed by a generic simulation engine. Concretely, the agents used in TrafficGen are described below (we present the modeling of their behavior in the next section). A dictionary ensures the correspondence between GIS elements and agents.

Nodes have other nodes as acquaintances; they are connected by links representing ways, endowed themselves with attributes (e.g. number of lanes, one-way or two-way, speed limits, etc.).

Vehicles have a desired speed (which they try to reach) and an instant speed they adapt depending on the situation. They also compute a mobile average speed (over the last simulation cycles). As shown on figure 1, all vehicles move along the road axis (i.e. a link between two nodes) and are logically affected to a lane. The vehicle perception is customizable; by default each vehicle has a vision cone in the front and another one in the back. At each node, it chooses a destination node and memorizes where it comes from. It is also possible to specialize vehicles into "subspecies" with different perception or action capabilities (e.g. cars, cycles...).

Crossroads are created when a node owns more than two acquaintances. They manage the access to lanes to avoid or detect collisions. Different possibilities have been proposed to do this [START_REF] Mandiau | Behaviour based on decision matrices for a coordination between agents in a urban traffic simulation[END_REF], [START_REF] Tlig | Cooperative behaviors for the self-regulation of autonomous vehicles in space sharing conflicts[END_REF]; as a rough default behavior, we use a semaphore to control the access to each lane. Yet, in the IODA approach the crossroad agent does not own the regulatory mechanisms: instead, they are expressed through rules (interactions), so that different mechanisms from the literature can be implemented as well and assigned to the crossroads afterwards.

Traffic signals and others road signs are created from GIS information (when available) and reified into agents belonging to a specific family.

Generators are in charge of vehicles creation at a rate, and with characteristics, which reflect either real data or probability laws.

Probes measure and save characteristics of passing vehicles. They can be customized so as to inspect features that are considered relevant in each simulation scenario.

Event managers of several kinds allow to extend the actions that can be performed over vehicles or other agents according to specific scenarios; especially, speed reducers can impose temporary speed limits to all vehicles within a circular perimeter.

The last three agents families are obviously not part of GIS data. Generators and probes can be placed on real measurement points (to generate realistic vehicles flows compare the simulated flows with real data) or on arbitrary nodes for experimentation. Event managers can be put everywhere without node constraints: they can be used to evaluate the impact of emergency measures, such as the local speed reduction policy in response to pollution peeks for instance.

IV. BEHAVIORAL MODEL Traffic simulations involve complex vehicle behaviors. Part of this complexity, especially everything in relation with the way drivers get information in their environment, can nevertheless be delegated to agents which reify road devices (crossroads, traffic signs, lights, etc.), as suggested by Gibson in his affordance theory [START_REF] Gibson | The Ecological Approach to Visual Perception[END_REF]. Indeed, our goal is not to reproduce a psychologically realistic model of the driver, but to ensure that vehicles move in a manner consistent with knowledge and observations, and yet to maintain their diversity.

Aiming at developing tools to help decision, it is important to allow the user to build scenarios, revise them easily, compare them and evaluate their outcomes. For example: It is 10 am at Paris, 80% of drivers are elderly person, 20% are dynamic executives and arrive on the ring road at a rate of 50 vehicles/min. A pollution alert is triggered on Paris inner centre. What would be the result on the traffic density in main avenues entries of a speed limitation to 50 km/h on the ring road ?

To take into account so many aspects (the subnetwork to study, the individual specifications of vehicles, their input flow), the simulator architecture must allow modular associations of various agents families to different generic behaviors.

Our proposition is to use the matrix representation of the IODA approach [START_REF]IODA: An interaction-oriented approach for multiagent based simulations[END_REF] wherein we indicate which interactions can be performed between each pair of families of agents (Table I). For example, when a vehicle A (source) perceives a vehicle B (target), it may overtake, decelerate or execute an emergency braking depending on their speeds and the distance between them. If we write a "naive" algorithm (Table II) for the decisionmaking between these three behaviors, we observe the interweaving of several distinct concepts. It brings together the definition of actions to perform with a complex decision process. We can also observe that the notion of priority between behaviors is not explicitly specified. This causes a lack of modularity in the behaviors. In fact, a mere attempt to modify the priority of an interaction requires to change the order of the "if" cascades so as to take into account execution conditions and the distance between agents.

On the contrary, within the IODA approach, our example leads to define the appropriate associations in the interaction matrix (Table III) and three independent interactions (Table IV). This representation makes a clear separation between the definition of actions and their conditions through interactions. It also allows an explicit scheduling of behaviors (through priorities) and a "distance guard" made explicit in the interaction matrix. These interactions specify behaviors as conditions/actions rules (like in STRIPS) by using abstract primitives (Table IV). These primitives can lead to a different implementation in each agent family, depending on its structure and capabilities. Thanks to this approach, a revision of the model almost consists in modifying the interactions assigned to agents families in the matrix, together with their priorities and their distance guards. This approach facilitates the revision of the models. Moreover, the separation of knowledge relative to entities and their behavior, allows to change the model even during the simulation simply by modifying the interaction matrix. Furthermore, interactions (as generic rules) can be reused in various contexts. INTERACTION Overtake TRIGGER target:in-front? target:same-direction? target:same-lane? target:too-close? target:too-slow? CONDITION not-in-crossroad? not-road-end? has-left-lane? left-lane-free? ACTIONS save-target-overtaking go-to-left forward END

INTERACTION EmergencyBrake

TRIGGER target:in-front? target:same-direction? target:same-lane? target:emergency-distance? CONDITION not-in-crossroad? not-road-end? ACTIONS emergency-braking END

INTERACTION DecelerateAvoidCar

TRIGGER in-front? target:same-direction? target:same-lane? target:too-close? CONDITION not-in-crossroad? not-stopped? not-road-end? ACTIONS decelerate forward END V. THE TrafficGen PLATFORM As a proof of concept, we have developed an experimental tool named TrafficGen, based on the IODA extension 11for the NetLogo multi-agent platform. NetLogo [START_REF] Wilensky | Netlogo[END_REF] also provides a native GIS extension and a third-party SQL extension 12 . We first tested the capacity of this platform to import maps from various contexts (e.g. figures 2, 6 and 7), then implemented "basic" behaviors like collision-free and overtaking models (figure 7).

A. OpenStreetMap

In this part, we focus on the OSM format, explaining how we build a road network in simulation from OSM data. Our approach can though easily be transposed to other transport networks as shown in section V-B.

OSM Data are structured as an XML file composed of three levels of elements. Nodes (<node>) are points of interest on the map, identified by an ID and GPS coordinates. Like all OSM elements they can encapsulate key/value tags (<tag k="..." v="..." />) giving complementary information. Ways (<way>) are nodes sequences (<nd ref="..." />) which can represent as well an open curve (e.g. a street) or a polygon. Ways also own tags (e.g. one-way road, number of lanes, roundabout, etc.). Relations (<relation>) are logical entities involving nodes and ways (<member type="node|way" ref="..." role="..." />) with particular roles (e.g. subway lines are made of ways which connect nodes, and of special nodes which are the stations). Each relation can also be endowed with specific tags.

As we can see, this information is low-level and loosely structured. Yet, the tags system allows to associate various information to an element, such as: speed limitation, cycles lane, public lights, etc. But in the case of road networks the most important tag is keyed by highway; the associated value indicates the nature of the corresponding element (i.e. the type of road: primary, secondary, residential...).

To build a road network from an OSM file, the data have to be filtered to keep only relevant information about the network structure. Lots of tools can be used (e.g. Osmosis 13 , JOSM14 , Merkaartor15 ) to maintain or exclude nodes and ways depending on their tags (i.e. here we are looking for highway tags). Then, we recommend to inject data into a "true" database, to facilitate access to OSM elements properties (i.e. tags values). PostgreSQL and the PostGIS extension are particularly adapted to handle this. A tool like osm2pgsql 16 makes this operation in one command line.

B. OpenDRIVE and other transport networks

In order to demonstrate the strength of our solution facing different data formats, we applied it also to the OpenDRIVE format. The OpenDRIVE format is composed of three distinct parts: roads, controllers (i.e. traffic lights and dynamic speed limitations) and junctions (e.g. crossroad, roundabout, etc.), which are represented by the road, controller and junctions markers. Unfortunately, there is no simple way to parse the OpenDRIVE format, so we have developed a dedicated plug-in (not described here) to load the data into our simulator.

For now we have focused on roads implementation. Roads are composed of three layers, which allow different detail levels. Here we only address the first layer (the whole specification can be found on the OpenDRIVE website 17 ), which is dedicated to road geometry. The layer is composed of a set of roads (i.e. road markers), each one owning a list of sections with a specific geometry (i.e. geometry markers). In OpenDRIVE 1.3 four types of geometries can be use: straight lines (line), curves (arc), spirals (spiral) and third degree polynomials (poly3). The differences are mainly in the curvature coefficient which are respectively zero, nonzero constant and linear, as shown on figure 3.

In this format, each geometry only has one coordinate (usually a starting point), a length and information about the curvature. Thus, nodes agents must be extrapolated according to the geometries. Nodes are then connected to build ways (Figure 4). Noteworthy, this format has a major advantage over a solution like OSM, in the point of view of multi-scale simulations [START_REF] Picault | An interaction-oriented model for multi-scale simulation[END_REF], since the interpolation level can be tuned to the desired scale.

We have also applied our method to other transport networks. For example, we used OpenStreetMap to get data from various french subway networks (e.g. subway of Lyon on figure 5). In order to complete the network creation, required agents have been mapped to OSM elements (i.e. trains, stations, etc.), additional interactions have been defined (possibly by using existing interaction primitives), and the corresponding interaction matrix has been written.

C. Experimental example

To illustrate our approach, we show a simple experiment based on the map of the city centre of Lille (figure 2) wherein a measure point gives the travel time (relative to an upstream point) and density (i.e. number of vehicles per period of 100 simulation cycles) of observed vehicles (figure 8). These are created by a generator agent with a random interval following a Poisson law (with parameter λ = 5 cycles) and a speed dictated by a normal law (with a mean speed of 90 km/h and a standard deviation of 10 km/h).

At simulation cycle 1500, a speed limitation to 50 km/h is imposed by a speed reducer agent in a perimeter of 800 m around the measurement point. As we can see on the figure 8a, the limitation increases progressively the travel time of vehicles, but this one does not stabilize, which indicates the formation of a traffic jam. The density plot (figure 8b) confirms this observation: after a small diminution (due to the slowing of cars before the measure point) the density increases considerably.

To realize this kind of experimentation, we only have to place a generator, a probe, and an event manager in the study environment. The behaviors than we have implemented in TrafficGen are profusely cited in the literature and most of them are already experimentally validated. Thus we mainly have to validate the integration of data flow (ongoing work) and the reproduction of an agent population from these global information. We plan to join national information (e.g. Bison Futé) with information from the urban communities, by using techniques developed by Champion et al. [START_REF] Mandiau | Behaviour based on decision matrices for a coordination between agents in a urban traffic simulation[END_REF] or Lacroix et al. [START_REF] Lacroix | Formalizing the construction of populations in multi-agent simulations[END_REF].

VI. CONCLUSION AND PERSPECTIVES

Simulators are currently recognized as essential tools for decision making. Transport in general, and traffic road in particular, are more and more studied, both at a macroscopic level (flow equations, aggregate variables, etc.) and at the microscopic level (individual-based approach). These last years the amount of online real data increased constantly. In this article we have proposed a modular and highly tunable integration method of these data into an intelligible, easily revisable behavioral model for multiagent simulation. In addition, our approach is extensible to other transport networks (e.g. trams, bus, subways, cycles, pedestrians, etc.) with little coding effort, and to other data formats such as OpenDRIVE.

Though the quality of open data is questionable [START_REF] Girres | Quality assessment of the french OpenStreetMap dataset[END_REF], their usage facilitates the realization of a traffic simulation by providing free data which are continuously updated. The IODA approach pushes the designer to elaborate behavioral models in an incremental process, separating the structure and ability of agents from abstract behavioral rules, which make the models easy to extend or change. All elements of the road infrastructure likely to participate in the behavior of the system are in fact modeled and implemented by agents, and the behaviors of agents are based on generic rules (the interactions). These properties allow a large flexibility in the achievement and testing of scenarios which can cover a wide range of characteristics, from the road network choice to the study of agents behavior details.

Our ongoing work focuses on the acquisition of flow information in these various networks, which are most of the time less standardized than those of road networks and are often provided as schedule grids. Nevertheless, the generalization of our approach should facilitate the design of simulation "on demand" to answer to relatively various scenarios.

Figure 1 .

 1 Figure 1. (a) Road section with three lanes having one vehicle per lane. (b) TrafficGen representation: crosses are nodes, each arrow is the speed vector of a vehicle agent, the number between brackets is the vehicle lane.

Figure 2 .

 2 Figure 2. Part of the city center of Lille (France) loaded in TrafficGen.

Figure 3 .

 3 Figure 3. Extract of the OpenDRIVE specification illustrating the different geometries. The curve above the geometrical aspect of each geometry according to the curvature coefficient (graph below).

Figure 4 .

 4 Figure 4. An OpenDRIVE file loaded in TrafficGen

Figure 5 .

 5 Figure 5. A simulation of the subway of Lyon (France) in TrafficGen.

Figure 6 .

 6 Figure 6. The 1 University campus in TrafficGen.

Figure 7 .

 7 Figure 7. Traffic on French highway A23 in TrafficGen.

Figure 8 .

 8 Figure 8. Evolution of travel time (a) and density (b) (number of vehicles per 100 ticks) of observed vehicles. At simulation cycle 1500 a speed limitation is placed in a radius of 800 m around the measure point, creating a traffic jam.

Table III REPRESENTATION

 III OF AVAILABLE CARS/CARS INTERACTIONS TABLE I IN IODA-NETLOGO. THE FIELDS REPRESENT THE FOLLOWING ITEMS RESPECTIVELY: THE TYPE OF SOURCE AGENT (E.G. C A R S ); THE NAME OF THE INTERACTION (E.G. OV E R T A K E ); THE PRIORITY OF THE INTERACTION (E.G. 30); THE TYPE OF THE TARGET AGENT (E.G. C A R S ); THE DISTANCE GUARD (E.G. 10)

	cars	Overtake	30	cars	10
	cars	EmergencyBrake	20	cars	5
	cars	DecelerateAvoidCar	10	cars	10

Table IV IMPLEMENTATION

 IV OF THE INTERACTIONS DEFINED IN TABLE III. THE TRIGGER DESCRIBES MOTIVATIONS TO PERFORM THE INTERACTION, THE CONDITION EXPRESSES PREREQUISITES OF ACTIONS AND THE ACTIONS ARE RUN IN SEQUENCE.

http://wwww.openstreetmap.org

http://www.opendrive.org

http://diffusion-numerique.info-routiere.gouv.fr

http://www.datex2.eu

for Système Informatisé de REcueil de DOnnées: http://www. transport-intelligent.net/produits-services/article/siredo

http://www.lifl.fr/SMAC/projects/ioda/ioda for netlogo/

https://code.google.com/p/netlogo-sql/

http://wiki.openstreetmap.org/wiki/Osmosis

http://wiki.openstreetmap.org/wiki/Josm

http://wiki.openstreetmap.org/wiki/Merkaartor

http://wiki.openstreetmap.org/wiki/Osm2pgsql

http://www.opendrive.org/docs/OpenDRIVEFormatSpecRev1.3D.pdf