Multi-agent Design of a Trafﬁc-Flow Control...

Multi-agent Design of aTraffic-Flow Control System

A Project in Collaboration with AAII �

Tihomir GabricNicholas Howden

Emma NorlingGil Tidhar y

Liz Sonenberg

Technical Report 94/24

Department of Computer ScienceThe University of Melbourne

Parkville, Victoria 3052AUSTRALIA

Abstract

This technical report outlines a multi-agent oriented approach to improving traffic flowin city streets. The work was undertaken as a summer project between December1993 and February 1994. It was designed to be implemented using the DistributedMulti-Agent Reasoning System (dMARS) developed at the Australian ArtificialIntelligence Institute (AAII). The primary intention of this project was to test andevaluate the paradigm and its current implementation. This report describes thebackground and design of the traffic-flow control system. This system consists of twocommunicating sub-systems: the simulator, which simulates traffic flowing around asystem of roads and intersections; and the controller, which watches over the flow oftraffic and makes decisions about traffic-light state timings.

�The Australian Artificial Intelligence Institute.yWith AAII.

Contents

1 Introduction 3

2 Traffic-Flow Control: Problem Definition 42.1 Introduction � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 42.2 Traffic � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 4

2.2.1 Number of Vehicles � � � � � � � � � � � � � � � � � � � � � � � � � � 42.2.2 Density of Traffic � � � � � � � � � � � � � � � � � � � � � � � � � � � 42.2.3 Speed of Traffic � � � � � � � � � � � � � � � � � � � � � � � � � � � � 4

2.3 Roads � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 52.3.1 Priorities � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 52.3.2 Traffic Capacities � � � � � � � � � � � � � � � � � � � � � � � � � � � 52.3.3 Traffic Speeds � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 5

2.4 Action Areas � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 52.4.1 Traffic Lights � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 52.4.2 Direction of Lanes � � � � � � � � � � � � � � � � � � � � � � � � � � � 62.4.3 Speed Limits � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 6

2.5 Area to be Modeled � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 62.6 Other Considerations � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 6

3 Design of the Traffic-Flow Control System 83.1 Introduction � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 83.2 Outline of Design � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 83.3 Agents � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 8

3.3.1 Street Agent � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 93.3.2 Intersection Agent � � � � � � � � � � � � � � � � � � � � � � � � � � � 11

3.4 Future Expansions � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 143.4.1 Global Strategies � � � � � � � � � � � � � � � � � � � � � � � � � � � 14

3.5 Discussion � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 15

4 Traffic-Flow Control: Simulator Design 164.1 Introduction � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 164.2 An Intersection Agent � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 16

4.2.1 Intersections � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 164.2.2 Road Segments � � � � � � � � � � � � � � � � � � � � � � � � � � � � 174.2.3 Inter-agent Communications � � � � � � � � � � � � � � � � � � � � � � 184.2.4 Internal Data Structures � � � � � � � � � � � � � � � � � � � � � � � � 19

1

2 CONTENTS

4.2.5 An Example Run � � � � � � � � � � � � � � � � � � � � � � � � � � � 224.3 A Vehicle Source � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 234.4 A Vehicle Sink � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 234.5 External Communications � � � � � � � � � � � � � � � � � � � � � � � � � � � 24

5 Discussion 25

A System Street Plans 26

B System Intersection Plans 30

C Simulator Plans 36

Chapter 1

Introduction

In this document we describe the background and design of a traffic-flow control system, whosetask is to improve traffic flow in city streets. This system consists of two communicatingsub-systems; the simulator, which simulates traffic flowing around a system of roads andintersections; and the controller, which watches over the flow of traffic and makes decisionsabout traffic-light state timings. This report combines all of the documentation produced duringthe development of this traffic-flow control system. This was a summer student project, incollaboration with the Australian Artificial Intelligence Institute (AAII), undertaken betweenDecember 1993 and February 1994. Project supervisors were Gil Tidhar and Liz Sonenberg.The purpose of the project was to increase our understanding of AAII’s Distributed Multi-AgentReasoning System (dMARS), and to test and criticise its current implementation.

The traffic-flow control problem was chosen because it could be seen as a real worldapplication, and because it would utilise many of dMARS’ features. Some time was spentunderstanding and defining the problem, and chapter 2 is the problem definition documentproduced. We needed to limit the problem domain to an achievable level, due to timeconstraints, and there we outline which “real-life” properties are being modelled by our system.

The system and simulator designs were then produced and refined over a number of weeks.Chapter 3 discusses the principles and ideas behind the control agents, whose task is to improvetraffic flow in the simulated street network, and chapter 4 deals with the simulator’s design andimplementation.

Implementation began on all parts of the trafic-flow system but was hampered by dMARS’incomplete state at the time. Eventually, it was decided that the implementation would cease,and possibly be completed at a later date.

As the primary motivation for the project was to exercise the multi-agent system dMARS,a number of simplifying assumptions were made about trafic flow control. These assumptionshave not been tested from a traffic simulation perspective.�

Chapter 5 outlines what remains to be done to get the system working, and the appendiceslist the dMARS plans that were written.

�c.f., G. Russell et al, ‘Simulating Vehicular Traffic Flows using the Circal System,’ Technical ReportCIS-94-013, May 1994, School of Computer and Information Science, University of South Australia; R.J. Salter,Highway Traffic Analysis and Design, Macmillan, 1990.

3

Chapter 2

Traffic-Flow Control: Problem Definition

2.1 Introduction

This chapter describes the problem to be tackled in the road traffic flow domain. A solutionto the problem described will be designed and implemented as part of a dMARS traffic flowsimulation. A number of factors associated with traffic flow will not be implemented, due totime constraints. They will, however, be considered when designing the solution, in order tomake later addition of these possible. Some of these factors we consider possible inclusionsare listed at the end of this chapter.

2.2 Traffic

In this section we outline some notions associated with what is typically described as “traffic”which we will attempt to model using the dMARS system.

2.2.1 Number of Vehicles

The number of vehicles in the system as a whole will depend on matters such as the capacityof the roads carrying the traffic, the time of day, and similar factors. This number will typicallyvary widely over different times of the day and days of the week, to model what occurs in thereal world.

2.2.2 Density of Traffic

This will mainly be a function of the number of vehicles and capacity of the roads. As above,this will vary considerably due to time of day and week, and will likely be highly directional atany given time. For example, the afternoon peak heads away from the CBD.

2.2.3 Speed of Traffic

The speed of vehicles along a road has a direct bearing upon the rate of traffic flow along thatroad. Not all cars move at the same speed or in the same manner; trucks accelerate very slowlywhile motorcyclists can accelerate extremely quickly.

4

2.3. ROADS 5

The speed of individual vehicles along a section of road depends upon a number of factors:weather, road condition, number of obstacles on the road, number of cars, the speeds of anyother cars, and so on. Actual speed is typically determined by drivers using a combination ofroad conditions and perceived safety, so can vary greatly and irrationally (for example, speedsare often higher at night even though seeing distance is poorest).

2.3 Roads

2.3.1 Priorities

Commonly, at any given intersection, one road will be more “major” than the other(s). Thisroad should be given priority at the intersection.

2.3.2 Traffic Capacities

This is a property of the individual road segments, since only a finite number of vehicles cantravel along a road at any given time. The maximum capacity of a segment is the number ofvehicles which can fit on the road in stationary “bumper-to-bumper” traffic.

2.3.3 Traffic Speeds

Different drivers behave differently under the same conditions, so there is often no one trafficspeed at which all vehicles travel. In general, the fewer vehicles there are in a road segment, thewider the range of speeds at which vehicles can travel. For our simulator to be realistic, someaccount needs to be taken of the effect of vehicle densities upon speed.

2.4 Action Areas

We use the phrase “action areas” to denote those parts of the system that may be subject toexternal control. They change the driving environment, and will be used to alter traffic flow.

2.4.1 Traffic Lights

Traffic lights have an enormous bearing on the flow of traffic, and are also easy to control for thepurposes of traffic flow management. They can be used to favour larger arterial roads or limitaccess to parts of a system straining under heavy loads. There are two aspects of their behaviorwhich may be varied for traffic control:

1. Frequency of ChangeThe time between red-red cycles for a given direction (the “cycle-time”).

2. Times for Each StateThe portion of the cycle-time that is allocated to a colour in a given direction.

As well as these items, we must also consider the “granularity” of the changes. That is, theminimum time between changes of individual colored lights at an intersection (for example,the period during which the amber light is lit). This need not be the same for all directions.

6 CHAPTER 2. TRAFFIC-FLOW CONTROL: PROBLEM DEFINITION

2.4.2 Direction of Lanes

The directions of certain lanes along some busy highways can be altered during peak times toimprove the traffic flow in a given direction.

2.4.3 Speed Limits

The maximum speeds of a section of road are generally not alterable, but for some roads thismay need to be done. A local example is the tallest bridge in Australia, the Westgate Bridge,�

which has a number of flashing lights warning of high winds and lowering the current speedlimit. The limit is lowered in relation to the strength of the wind.

2.5 Area to be Modeled

We intend to model a real area of Melbourne’s roads, as this way we can compare the results ofour simulations with the real life behavior of the area, and also hopefully use real Victorian RoadTraffic Authority (RTA) data for the traffic in the area. The physical location we will model willdepend upon what additional data is available.

2.6 Other Considerations

There are a number of other issues involved in the traffic flow problem which we will not beattempting to incorporate in our design, but will hopefully be relatively simple to include at alater stage if desired. Below is a brief list of some of these issues:

1. Priority trafficTraffic such as public transport (which often has its own lanes), and emergency vehicles.

2. Dangerous and other non-ordinary trafficOver-width and over-length vehicles or vehicles carrying dangerous substances aregenerally restricted to certain roads.

3. AreasIn many cases a section of the road system may be somehow connected to other facilities,be it by use or by proximity. It may be useful to model these areas as distinct and cohesiveentities.

4. ParkingParking can have a major affect on traffic flow, with on-street parking often varying inavailability during the day, causing variations in traffic flow, and off-street parking beinga major sink and source of traffic.

5. ObstructionsObstructions such as accidents, roadworks and natural disasters can have major effectsupon traffic flow.

�By design, the Westgate Bridge is only one meter taller than the Sydney Harbour Bridge!

2.6. OTHER CONSIDERATIONS 7

6. Air PollutionTraffic flow affects air pollution, and at a future time this may be considered whencontrolling traffic flow.

7. Weather ConditionsWeather conditions such as fog, heavy rain, ice, snow, etc can significantly alter the wayin which cars are driven. It may also make some sections of road unusable.

8. DetoursDetour signs may be introduced to inform vehicles of alternative routes in the case ofsome types of obstructions.

Chapter 3

Design of the Traffic-Flow Control System

3.1 Introduction

This chapter describes a detailed design to solve the road traffic flow problem using the dMARSagent oriented programming environment. It tackles the problem with a number of almostidentical agents which communicate only with their neighbours and therefore represents anemergent behavior approach. We discuss the outline of the design and then go into its partsin more detail. We finish with a discussion on the quality of the solution represented by thisdesign and the reasons for the design decisions made as well as some possible alternatives.

3.2 Outline of Design

There are two families of agents in this design; one family represents each road segment,and another represents each intersection. These agents are responsible for maintaining all ofthe information about their real-world counterparts and also for communicating with agentsrepresenting their geographical neighbours. The input into the system (from the real world orfrom a simulator) is the number of cars that are at each point within the system�. Each agenttherefore has only this information along with communications from its neighbours on whichto base its decisions about the control of traffic flow. The underlying idea is that with someexperimentation with the system, a set of rules for each type of agent can be developed thatproduce a desirable global effect. We will discuss the reasons that these design decisions weremade in section 3.5 at the end of this chapter.

3.3 Agents

There are two families of agents in this design. One to represent each direction of a road sectionand another to handle the traffic lights at each intersection. They are described in detail below.

�More complex information may be added later such as accidents, weather information, etc.

8

3.3. AGENTS 9

3.3.1 Street Agent

This agent family is responsible for the sections of road between intersections — one for eachdirection of each section.

Database Entries

1. PriorityThis may change at different hours of the day — it is an obvious place to allow for flowchanges at peak hour.

2. CapacityThis can change to incorporate on street parking. It could also be used to model accidentsand weather conditions.

3. Downstream Load PercentThis is a table of the percentages of this street’s load that it sends to each of its downstreamroads (calculated from a statistical history). For example:

Name PercentageRussell 5 0.76Collins 3 0.11Collins 4 0.13

4. Upstream LoadsThis is a table which holds the current loads which will be sent from streets furtherUpstream. These are received in messages from those streets and are used to calculatethis street’s load. For Example:

Name LoadRussell 3 34Bourke 3 5Bourke 4 11

5. Upstream SumThis is the sum of the loads appearing in the Upstream Loads table, multiplied by a factor(probably 0.5 is a good start). This will be added to this road’s load upon recalculation.

6. Prev Upstream SumThis is for the road to trigger a load recalculation. Whenever this differs significantlyfrom the current Upstream Sum then the load should be recalculated.

7. Car CountSimply the current number of cars that are waiting to cross the intersection and leave thisroad segment. It is updated upon receiving messages from the simulator.

8. Prev Car CountThis stores the number of cars on the road at the last time the load was calculated — itallows the street agent to decide when to recalculate the load.

10 CHAPTER 3. DESIGN OF THE TRAFFIC-FLOW CONTROL SYSTEM

9. Rate of FlowThis may be necessary for the road segment to differentiate between being loaded withcars that are moving and constantly being replaced, and being loaded with a stationarytraffic jam of cars (ie. for blockages and detour information)

Communications

These agents send their load to the street agents further along the line� to allow for moreaccurate load processing. They will obviously also receive this information from agents furtherUpstream from them — this is used in the calculation of their own load. When they are polledby ‘their’ intersection, they will also return a message showing their current load.

Hopefully this will lead to an effect of a “pressure build-up” when heavy traffic loads existacross several intersections. For example, a street knows that it has a certain number of carswhich translates to a certain load, but this could be changed by a message from the next streetup the line indicating that it has a heavy load. This would be incorporated into the street’s loadand given to the intersection agent when required. Greater attention would then need to be paidto relieving this build-up than if it had only been in the single block preceding the intersection.This local communication limits the scope that each agent needs to handle while still givingeach agent some sort of global information with which to make strategic decisions.

The simulator will also send a ‘blip’ for each car arriving to wait in a street and an ‘un-blip’for each car that leaves a street. These messages will need to be received and the relevantdatabase entries updated.

Plans

1. Add Car

� Upon receiving message from the simulator, increment Car Count in database.

� When count is significantly different (a percentage or a function of capacity ?) fromlast time load was calculated, then call Recalculate Load�.

2. Recalculate Load

� Recalculate the load of cars on the road.

� Update Prev Car Count in the database with the value of Car Count.

� Update Prev Upstream Sum in the database with the current value ofUpstream Sum.

� Call Send Load Downstream with new calculated load.

3. Receive Load Upstream

� Receive load from the upstream road and store in the Upstream Loads table in thedatabase.

�For example, they may send 15% of their load to the street agent which is right at the next intersection andthe other 85% to the agent straight ahead. These figures would be based on past statistics about how the traffic hasbehaved in the past.

�Not yet implemented

3.3. AGENTS 11

� If this information would change this road’s load significantly then call the planRecalculate Load.

4. Remove Car

� Upon receiving message from simulator, decrement Car Count in the database.

� When count is significantly different (perhaps taken as a percentage or a function ofcapacity) from last time load was calculated, then call Recalculate Load�.

5. Send Load Downstream

� Send load to all downstream roads in the Downstream Load Percent table in thedatabase. This is done using the Tell Send plan as we cannot have an action insideanother.

6. Send Load Intersection

� Receive message asking for load from intersection.

� Call the Recalculate Load plan.

� Send the load back to the intersection.

7. Tell Send

� Sends the load it is passed to the agent it is passed.

3.3.2 Intersection Agent

These agents are responsible for each intersection. They handle the control of the traffic throughthe traffic lights. Originally they will simply change the timing of the lights to allow the‘best’� traffic flow in only two directions (ie. no turning arrows — these could be incorporatedlater). The basis of the agent’s strategy is an algorithm which, given the loads of all incomingroads, decides whether to change out of its current state, and therefore, into the next one in apredetermined sequence. This sequence is implemented in the Change Lights plan and so canbe changed (or discarded altogether) very easily.

Database Entries

1. Current StateSimply stores the current state of the lights. It is used to decide on the changes necessaryto move to a new state in the Change Lights plan. It is simply a list consisting of the letters”r” and ”g” showing the state of each set of lights with the northern-most lights being thefirst position and continuing clockwise (see figure 3.1).

�Not yet implemented�There needs to be more discussion about what comprises an optimal solution to this problem


5

4

3

21

N

Figure 3.1: Traffic Light Numbering

2. Poll TimeThis is simply the time interval after which the intersection agent will poll the incomingroads and calculate whether it should change out of its current state. A good starting valuewould be something around ten seconds.

3. Poll CountCounts the number of polls that have occurred while in this traffic light state. This allowsthe agent to calculate whether or not it should change state based on how long it hasbeen in the current state. That is, the time since the last change will be (Poll Time *Poll Count).

4. Street LoadsThis is a table of the incoming streets, their order in the Current State list, whether it isthe load going straight or turning and their respective loads. These are the streets that theintersection polls to calculate its strategy about the timing of state changes. When theloads of these streets are received they are put into this table. For example:

List Number Agent Name Direction Load1 Russell 4 straight 342 Collins 3 straight 673 Russell 5 straight 434 Collins 4 straight 75

5. Light StatesThis is a table showing all the possible states, the order in which these states are usuallycycled through, and the current priority of each of these states.

State Number State Priority1 rgrg 772 grgr 142

6. Number StatesThis contains the number of states in the Light States table.

3.3. AGENTS 13

Communication

These agents will communicate with incoming street agents, the simulator, and maycommunicate with neighbouring intersection agents�. They will poll the incoming street agentsfor load information which they will use to calculate state changes for the intersection’s trafficlights. This will occur every Poll Time seconds, so obviously changes can only occur with thisgranularity.

Plans

1. Change Lights

� Call the Change State plan with the current state and the next state.

� Set Poll Count to zero in the database.

2. Change State

� Call the Calculate Intermediate State plan.

� Change lights to this intermediate state� and call the Notify Simulator plan.

� Wait for a given time (say, three seconds).

� Change lights from the Current State to the next state in the sequence.

� Call the Notify Simulator plan.

3. Poll Streets

� For every street in the Street Loads table database entry, call Poll Street.

� For each state in Light States table, call Calculate Combined Load.

� Increment Poll Count in the database.

� This will happen every Poll Time seconds until the lights change�.

4. Poll Street

� Ask this street for its load.

� Store returned information in Street Loads database.

5. Calculate Combined LoadThis plan and Calculate Combined Load0 recursively calculate the loads. The existingplans need to be amended to only add in the loads of the streets which are green for eachstate. The changing of the database in the success condition also needs to be checked, asit may lead to an assert being done on every recursive call — very wasteful.

� Add the load on each street that has a green light in the given state.

�If we manage (or even decide) to implement agreement of changes between intersections then thiscommunication will be necessary — see Future Expansions (section 3.4) below.

�In the real world.�This still needs to be implemented.


� Incorporate some function of the time since last change (Poll Time * Poll Count).

� Store total in Light States table entry.

6. Decide Change State

� Calculate whether to change out of the current state based on priorities inLight States.

� If change should occur then call Change Lights.

3.4 Future Expansions

3.4.1 Global Strategies

It may seem ridiculous to discuss global strategies when we are taking an emergent behaviorapproach with localized communication, but we believe that an understanding of the desiredbehavior of the system is necessary before one can adequately design the system’s localizedparts (ie. the street and intersection agents). Obviously the simplest strategy is to regulate thetiming given to each cross street taking into account the respective loads, and this is probablythe best way to begin the implementation. The following discussion will hopefully be usefulif (or when) we change this strategy into something more advanced. The implementationof these strategies (coordination of the changes of lights) is not intuitive with the emergentbehavior approach we have chosen — it would require some sort of agreement to be reachedwith neighbouring intersections before any state changes were made. This is certainly possible,but it would be difficult and it is hard to comment on its effectiveness.

If we were to implement these types of strategies we believe we would need to cope withthree different scenarios:

1. Heavy Traffic Loads

2. Medium Traffic Loads

3. Light Traffic Loads

These three scenarios are sufficiently different that the system should respond differently to eachone. We discuss each in detail below.

In these discussions we use the terms entrance and exit ends of a road stretch. Theserepresent the ends of a stretch of road (which may contain one or more intersections andtherefore one or more road sections) by which cars enter and leave respectively. It is thereforeobvious that any entrance is also an exit in the opposite direction. We will discuss only a singledirection here for reasons of simplification. This is an important point as it may occur that onedirection is heavily loaded and the other lightly loaded; as one set of lights must control bothdirections a single strategy must be decided upon�. Probably the simplest method is to use astrategy which will help the most cars (ie. give preference to the heavily-loaded direction). Youwill notice that some of the particular strategies outlined below will perform favourably withuneven loading in the two directions.

�These complications may mean that implementing these global strategies with the type of system we havediscussed will be impossible

3.5. DISCUSSION 15

Heavy Traffic Loads

Because the roads are heavily loaded, cars are bound to encounter a queue of cars at the nextintersection very soon after leaving the one they are waiting at. This means that making a lightgreen in the middle of the stretch of loaded road is almost useless. The obvious solution is tobegin making lights green at the exit from the stretch first, then hopefully when cars are allowedto go, they haven’t got a blockage in front of them.

Medium Traffic Loads

This seems to be the situation in which lights on a stretch of road should be synchronized to gogreen simultaneously. This means that traffic taking off from one light will not be slowed bythe traffic only just starting off from the next light.

Light Traffic Loads

In this situation it would be good if the lights were synchronized so that cars get a clear run alongthe stretch of road. For example, if a car was stopped at the entrance, when it got a green lightall the lights in front of it should be green by the time the car gets to them. Therefore lights atthe entrance should go green first and the change should propagate along the road stretch at anappropriate speed. It should be obvious that this would lead to the cars in the opposite directiongetting the treatment for a heavy load (which may be an advantage at peak hour times).

3.5 Discussion

This design had the advantage that in its most basic form it was readily understandable andtherefore implementable within our time constraints. It does not require an in-depth knowledgeof the global systematic strategies of traffic flow, although this may be an advantage in laterrefinement. As a system it would be easily expanded because of its modular design, and anyexpansions would only incur linearly growing costs in terms of communications and no drop inresponse time.

The quality of the solution is hard to judge at this stage, partly because we haven’tadequately defined what a quality solution would be, and also because the very nature of anemergent behavior system means that its behavior is relatively unpredictable at the design stage.

Chapter 4

Traffic-Flow Control: Simulator Design

4.1 Introduction

In this chapter, we describe in detail the design of the traffic flow simulator. Intersections andtraffic lights will be modeled using dMARS agents, and road sections will be just a part of theseagents.

Much of this chapter is not relevant to those wishing only to use the simulator as a model ofthe real world. For them, the only part which will be of interest is section 4.5, where we outlinethe interface between the simulator and the controlling agents.

The only external control available is to specify changes to the state of the traffic lights.The simulator also sends out a message whenever a car moves into or out-of a road segment.No other interaction occurs between the simulator and the outside world.

Using dMARS agents for the implementation has the effect of simplifying the code required.It also has efficiency advantages over a UNIX process-based implementation, since contextswitching within a dMARS agent is much more efficient than context switching entire UNIXprocesses.

4.2 An Intersection Agent

4.2.1 Intersections

Every intersection is being modeled as an agent. The intersection agent will handle trafficflowing into it from any neighbouring upstream intersection agents, and pass vehicles on todownstream agents. The way in which it passes them down is governed by a number of factors:

� The current state of the traffic lights, that is, the colors currently being shown in everydirection,

� The number of cars wishing to turn off into other streets (the proportion of the total flowwishing to turn off is determined within each intersection agent),

� The ability of any downstream road segments to take up the vehicles, and

� The amount of time it takes for a vehicle to cross the intersection.

16

4.2. AN INTERSECTION AGENT 17

40 cars23 sec

80

2

16

35 cars18 sec

22 cars10 sec

55 cars33 sec

R

G

G

R

Signal state forthat direction

Number ofcars waitingto enter

Intersectionagent

Roadsegment

3 sec

Road segmentcapacity and traveltime to nextintersection

Currentintersectioncrossing time

12

5

42

11

Number of carstravelling in thisdirection

Figure 4.1: The information with which the intersection agent operates.

For realism, the amount of time it takes for a vehicle to cross an intersection should varyover time. When an intersection has just changed state to green for a given direction, the frontvehicles take a while to accelerate and cross the intersection. The cars behind take less time,since they have already started moving by the time the others have passed through. To simulatethis behaviour, the intersection agent must be able to realistically alter the period of time it takesa vehicle to cross the intersection. It should be set to the highest value at the moment a light turnsgreen, then quickly decay to a shorter period of time.

4.2.2 Road Segments

Each agent is responsible for the half of the road segment leading away from the intersection�.Since the intersection agent knows the capacities of these segments, and the number of carscurrently traveling along them, it can easily decide how many more cars can be accepted fromthe upstream agents. Figure 4.1 outlines the information used by an intersection agent, andfigure 4.2 shows the agents’ responsibility for any downstream road segments.

�Because this program is being written in Australia, all our figures will assume that vehicles drive on theleft-hand side of the road. The simulator agents don’t depend upon this information, they only need the identitiesof the downstream agents. The simulator can be used anywhere in the world.

18 CHAPTER 4. TRAFFIC-FLOW CONTROL: SIMULATOR DESIGN

Agent 1 Agent 2

Inter−agentcommunications

Figure 4.2: Overview of the flow of information between any pair of adjacent intersectionagents.

The intersection agents are also responsible for simulating the traveling time for vehiclesmoving along those stretches of road. In particular, the specific time periods involved are:

� The amount of time that it takes a vehicle to travel along a segment to the next downstreamintersection, and

� The amount of time it takes for a vehicle to cross the intersection (see section 4.2.1 abovefor more on how this value is manipulated).

4.2.3 Inter-agent Communications

In this section, we discuss the information passed between any pair of neighbouring intersectionagents. (Details of the interaction between the simulator agents and the controller agents isdiscussed in section 4.5.) A typical layout of a pair of agents is given in figure 4.2, showingthe flow of vehicles and information. The circled portion of the diagram is discussed in detailhere.

There are two types of messages exchanged between neighbouring intersection agents:

� sensor_trip $from (sent from Agent 2 to Agent 1)indicating that there is now another car waiting at the entrance to the downstreamintersection agent (coming from the agent given in the variable $from), and

� car_entered $from (sent from Agent 1 to Agent 2)which is sent back to an upstream agent indicating that the car has been accepted and isnow moving along a road segment.


35 cars18 sec

Intersectionagent

3 secG

SWNumber ofvehicles in thesegment

Current signal statefor this direction

Number ofvehicles waitingto enter from thisdirection

Current intersectioncrossing time

Figure 4.3: The data structures used within the intersection agents to control the flow of vehiclesalong road segments.

Note that for every sensor_trip sent forward, there should be a correspondingcar_entered sent back, to ensure correct book-keeping.

4.2.4 Internal Data Structures

In this section we outline the data structures needed for the various parts of an intersection agent.Figure 4.3 shows part of an intersection, labeled with the various counters and database entriesused at the indicated points.

The messages received from neighbouring agents (section 4.2.3) and controlling agentsoutside the simulator (section 4.5) are used to modify some of these database entries. Othersare modified using various time-out mechanisms. Specifically:

� As has been mentioned in section 4.2.1, the intersection crossing time is modified usinga time-out mechanism initiated whenever any of the lights turn green. For simplicity wehave assumed that this travel time is identical for all directions. The crossing period isused to simulate the acceleration of traffic when lights change from red to green. It willdecay quickly to a one-second traversal time.

� The signal state is modified whenever the controller agent sends a message requestingthere be a change of color.

� The W counter keeps track of the number of vehicles that are waiting to enter fromthe indicated direction. It is incremented every time the intersection agent receives asensor_trip message, and decremented every time one of the vehicles enters a roadsegment. Decrementing also requires that this agent sends a car_entered messageback to the upstream agent.

� The S counter keeps a count of the number of vehicles that are traveling along a roadsegment. We must ensure this counter never exceeds the segment’s capacity.


These data structures are stored in the intersection agent’s private database. We outline belowthe extensional databases used by the agent, listing the names of the relation, their fields, andany aliases we have used for the relation.

Upstream Agent Names

Upstream Agent Name relates the upstream intersection agent’s name with the correspondingincoming direction identifier. The direction identifier is the key field.

Upstream Agent Namesupstream agentIncoming Direction Id Agent Name

I dir id a name

Aliases: upstream

Downstream Agent Names

Much like the predicate above, Downstream Agent Names relates the downstream agent’s nameto its direction identifier. The direction identifier is the key field.

Downstream Agent Namesdownstream agentOutgoing Direction Id Agent Name

O dir id a name

Aliases: downstream

Incoming Segment Controller Agent

This relates the agents needed to be notified of vehicle movements to direction identifiers. Thedirection identifier is the key field.

Incoming Segment Controller Agentcontroller agent IIncoming Direction Id Controller Agent Name

I dir id a name

Aliases: (none)

Outgoing Segment Controller Agent

This relates the agents needed to be notified of vehicle movements to direction identifiers. Thedirection identifier is the key field.


Outgoing Segment Controller Agentcontroller agent OOutgoing Direction Id Controller Agent Name

O dir id a name

Aliases: (none)

Outgoing Segment Vehicle Distribution

This relation is used to distribute incoming vehicles to the outgoing segments. Any incomingvehicle accepted from direction I dir id will be randomly sent to any of the downstreamagents based on the probabilities listed. I dir id is the key field.

Outgoing Segment Vehicle Distributionvehicle distributionIncoming Direction Id Outgoing Direction Probability List

I dir id O dir prs

Aliases: distribution

Outgoing Segment Limits

This relates the outgoing segment identifiers to the particular road segment’s physical limits.The key field is O dir id.

Outgoing Segment Limitsoutgoing segment limitsOutgoing Direction Id Segment Capacity Travel Time

O dir id cap time

Aliases: limit

Traffic Light States

This relation is used to store the current state of the traffic lights for all incoming directions.

Traffic Light Statestraffic light statesIncoming Direction Id Traffic Light Color

I dir id color

Aliases: traffic light


Incoming Vehicle Counter

This relation is used to store the number of vehicles waiting to enter from all incomingdirections. I dir id is the key field.

Incoming Vehicle Counterincoming cntrIncoming Direction Id Waiting counter

I dir id w

Aliases: i cntr

Outgoing Vehicle Counter

This relation is used to store the number of vehicles traveling along the road segments leadingfrom the intersection. O dir id is the key field.

Outgoing Vehicle Counteroutgoing cntrOutgoing Direction Id Segment counter

O dir id S

Aliases: o cntr

Intersection Traversal Time

This relation is used to store the time required for a vehicle to cross the intersection. There is nokey field since there can only ever be one entry stored within - the current traversal time period.

Intersection Traversal Timetraversal time

Traversal delaydelay

Aliases: (none)

4.2.5 An Example Run

In this section, we outline a sample set of interactions between intersection agents (set upmuch like figure 4.2), focusing on the events occurring as an individual car moves through anintersection. This is taken from the point of view of a typical intersection (such as the one infigure 4.3). Assuming a car wishes to enter from an upstream road segment:

1. The upstream agent sends a sensor_trip to the agent, indicating that a car is waitingto enter the intersection.

2. The W counter for that direction is incremented.

4.3. A VEHICLE SOURCE 23

3. If:

� the light is green for this direction,

� there is room in the chosen downstream road segment, and

� the waiting period (intersection crossing time) has expired since a vehicle was lastsent down from this direction,

we can send a car_entered message back to the upstream agent and decrement theW counter.

4. We increment the S counter for the chosen direction, schedule a message to be sent tothe appropriate downstream intersection agent in 18 seconds time (the segment traversaltime), and re-schedule another waiting period timeout to allow another car to cross theintersection.

5. When the 18 seconds have expired, this agent will send a sensor_trip to thedownstream intersection agent.

6. Eventually the downstream agent will send this agent a car_entered message. Wecan now decrement S for that direction, as the vehicle has just entered the downstreamintersection.

4.3 A Vehicle Source

The vehicle source will generate vehicles for the simulator, and pass them on to downstreamagents. It may be used with various sources of information, such as input files outlining numbersand times of cars desired or real-life load information, or can internally generate random flowsof vehicles.

Such a program is available for dMARS; an agent is not needed for this task. A non-existentagent name is given as a return address in the (sensor_trip $from) message.�

4.4 A Vehicle Sink

The job of a vehicle sink is to be an unlimited sponge of vehicles. It can be considered the edgeof our simple simulated “flat world”, where everything reaching the edge just falls over, neverto be seen again.

As far as any upstream intersection agent is concerned, a vehicle sink should respond likeany other intersection agent. It will differ in that it never halts the flow of vehicles entering; it’saction is to respond immediately to every sensor_tripmessage sent with acar_enteredmessage.

Only one such agent is needed for the entire simulator; sensor_trip messages arealways sent with return addresses, so any number of agents can have this one “sink” agent as a“downstream intersection”.

�This relies on the fact that the dMARS communication manager will ignore messages sent to non-existentagents. If the manager were to cause a fatal error on this event, a real agent would be needed to harmlessly absorbthese redundant messages.


4.5 External Communications

In this section we discuss the content and form of the communications sent between intersectionagents and the external agents controlling the intersection. (See section 4.2.3 for discussion ofthe communications internal to the simulator).

The only control any external agents can exercise over the intersection is to change thecurrent state of the traffic lights. There is no verification of the identity of an agent requestingtraffic light state changes; they are taken on faith.

The form of the message to change traffic lights is:

� (change traffic lights $list of states)where $list of states is a list of colors. The order followed is clockwise fromNorth; so the first element in the list is for the first incoming direction found whentraveling clockwise from North, the second element is for the second light, and so on.The terms contained in the list are simply either “r” or “g”.

If the list is shorter than the actual number of lights, those not addressed remain in theirprevious states.

The form of the messages sent out from the simulator agent whenever a vehicle passes out-ofor in-to a segment is:

� (car entered), and

� (car exited).

Note that this assumes controller agents are monitoring vehicles moving between road segmentsrather than into intersections. Although the messages look like the messages used for simulatorinter-agent communications (from section 4.2.3), their purpose is different.

Chapter 5

Discussion

It is unfortunate that we were unable to run our system. The problems were the incompletestate of dMARS, which made it hard to test our code, and the limited time we had in which toimplement the system. There were also some things we needed to decide before we could finishthe project:

� We intended to have a number of controllers, implementing different types of controlstrategy, and evaluating their effectiveness. Initially, two strategies were proposed; theemergent-behavior approach (which we did implement), and the hierarchical-controlapproach (which we did not).

We would like to have had both represented; time and conflicting needs halted this lineof research.

� The competitive nature of the above strategies required performance monitoring metricsand criteria to be decided. Also, a realistic performance monitoring system is needed toevaluate any solution we did implement. We currently have not decided how this is to bedone.

25

Appendix A

System Street Plans

Figure A.1: Add Car

26

27

Figure A.2: Recalculate Load

Figure A.3: Receive Load Upstream

28 APPENDIX A. SYSTEM STREET PLANS

Figure A.4: Remove Car

Figure A.5: Send Load Downstream

29

Figure A.6: Send Load Intersection

Figure A.7: Tell Send

Appendix B

System Intersection Plans

Figure B.1: Change Lights

30

31

Figure B.2: Change State

Figure B.3: Calculate Combined Loads

32 APPENDIX B. SYSTEM INTERSECTION PLANS

Figure B.4: Calculate Combined Loads0

Figure B.5: Decide Change State

33

Figure B.6: Calculate Intermediate State

Figure B.7: Calculate Intermediate State0

34 APPENDIX B. SYSTEM INTERSECTION PLANS

Figure B.8: Notify Simulator

Figure B.9: Poll Streets

35

Figure B.10: Poll Street

Appendix C

Simulator Plans

INVOCATION(*add-fact (monitor_segment $o_dir_id))

CONTEXT(and (*fact (downstream $o_dir_id $downstream_agent)) (*fact (controller_agent_O $o_dir_id $controller_agent)) (*fact (limit $o_dir_id $capacity $travel_time)))

PROPERTIES((priority 10))

(* (tell (car_entered) $controller_agent))

START

(^ (elapsed $travel_time))

P1

END1

(* (tell (sensor_trip (agent-name)) $downstream_agent))

P3

Figure C.1: The plan: monitor segment. Initiated whenever a vehicle enters a downstreamsegment. It takes care of one vehicle’s traversal; its timing and notification of downstreamsegments.

36

37

INVOCATION(*add-fact (monitor_incoming $i_dir_id))

CONTEXT(and (*fact (controller_agent_I $i_dir_id $controller_agent)) (*fact (distribution $i_dir_id $probabilities)) (*fact (upstream_agent $i_dir_id $upstream_agent)))


(? (traffic_light $i_dir_id g))otherwise

START

(! (nonzero_i_cntr $i_dir_id))

otherwise

P1

END1

(! (select_direction $probablilties $destination))

P2

(! (increment_o_cntr $destination))

otherwise

P3

(! (decrement_i_cntr $i_dir_id))

P4

(* (tell (car_exited) $controller_agent))

P5

(^ (elapsed $delay))

P6

(* (=> (monitor_segment $destination)))

P7

(? (traversal_time $delay))

P8

(* (tell (car_entered (agent_name)) $upstream_agent))

P9

Figure C.2: The plan: monitor incoming. Initiated when a light turns green for a givendirection, and takes care of intersection traversal timeouts for individual vehicles.

38 APPENDIX C. SIMULATOR PLANS

INVOCATION(*goal (!(select_direction $probabilities $result)))

(* (@= @hd (first @tl)))

P1

(* (@= @tl (rest @tl)))

P2

(* (@= @cumulative_prob (+ @hd @cumulative_prob)))

P3

(* (= $random (erand48 666)))

START

(* (@= @cumulative_prob 0))

P4

otherwise(? (isempty @tl))

P5

(* (:= $result @pos))

P6

END1

otherwise

(? (<= $random @cumulative_prob))

P7

(* (@= @pos 1))

P8

(* (@= @tl $probabilities))

P9

CONTEXTT


(* (@= @pos (+ 1 @pos)))

P10

Figure C.3: The plan: select direction. This takes a probability distribution and selectsa direction based on a random number and the distribution.

39

INVOCATION(*goal (!(decrement_o_cntr $o_dir_id)))

CONTEXTT


(* (=> (o_cntr $o_dir_id (- $s 1))))

P2

(? (> $s 0)) otherwise

P4

NIL

P5

END2

(? (o_cntr $o_dir_id $s))

START

END3

Figure C.4: The plan: decrement o cntr. Decrements an outgoing segment counter. Itshigh priority ensures it is atomically executed (never pre-empted).

INVOCATION(*goal (!(increment_o_cntr $o_dir_id)))

CONTEXT(*fact (limit $o_dir_id $limit $time))


(* (=> (o_cntr $o_dir_id (+ $s 1))))

P2

(? (< $s $limit)) otherwise

P4

NIL

P5

END2

(? (o_cntr $o_dir_id $s))

START

END3

Figure C.5: The plan: increment o cntr. Increments an outgoing segment counter. (Thisis atomic also.)


INVOCATION(*goal (!(decrement_i_cntr $i_dir_id)))

CONTEXTT


(* (=> (i_cntr $i_dir_id (- $w 1))))

P2

(? (> $w 0)) otherwise

P4

NIL

P5

END2END3

(? (i_cntr $i_dir_id $w))

START

Figure C.6: The plan: decrement i cntr. Decrements an incoming segment counter.(Atomic)

INVOCATION(*goal (!(increment_i_cntr $i_dir_id)))

CONTEXTT


(* (=> (i_cntr $i_dir_id (+ $w 1))))

P2


START

END1

Figure C.7: The plan: increment i cntr. Increments an incoming segment counter.(Atomic)

41

INVOCATION(*goal (!(nonzero_i_cntr $i_dir_id)))

CONTEXTT


(? (> $w 0))

P4


START

END1

Figure C.8: The plan: nonzero i cntr. Atomically test if an incoming segment counter isnon-zero.

INVOCATION(*goal (!(change_lights $i_dir_id $states

CONTEXT(*fact (isempty $states))


Figure C.9: The plan: change lights ma[]. Changes traffic lights: the plan when the listof states is empty.


INVOCATION(*goal (! (change_lights $i_dir_id $states)))

CONTEXT(*fact (~ (isempty $states)))


(* (:= $x (first $states)))

START

(* (:= $xs (rest $states)))

P1

(* (:= $nextid (+ $i_dir_id 1)))

P2

(* (=> (traffic_light $i_dir_id $x)))

P3

(! (change_lights $next_id $xs))

P4

END1

Figure C.10: The plan: change lights (x:xs). Changes traffic lights: the plan when thelist of states is non-empty. Recurses through the list, updating the appropriate database entries.

43

INVOCATION(*told (change_traffic_lights $states) told $_)

CONTEXTT


(* (=> (traversal_time 3)))

START

(! (change_lights 1 $states))

P1

END1

Figure C.11: The plan: told change traffic lights. Catches the ‘told’ message fromthe controller agent, spawns the intersection delay decay plan, and the plan to recursively changethe traffic light database.

INVOCATION(*add-fact (traffic_light $i_dir_id $color))

CONTEXT(*fact (== $color g))


EFFECTS( (=> (monitor_incoming $i_dir_id)) )

Figure C.12: The plan: spawn direction monitor. This notices that a traffic light hasturned green, and spawns a direction monitor plan to watch over that direction.


INVOCATION(*add-fact (traversal_time $delay))

CONTEXT(*fact (> $delay 1))


(^ (elapsed 1))

START

END1

(* (=> (traversal_time (- $delay 1))))

P1

Figure C.13: The plan: traversal time decay. Decays the intersection traversal timeslowly to one second.

INVOCATION(*told (sensor_trip $from) told $_)

CONTEXT(*fact (upstream $i_dir_id $from))


(! (increment_i_cntr $i_dir_id))

START

END1

Figure C.14: The plan: told sensor trip. Catches the message sent when upstreamintersection agents tell this one that there is now another car waiting to enter the intersection.Increments the appropriate counter.

45

INVOCATION(*told (car_entered $to) told $_)

CONTEXT(*fact (downstream $o_dir_id $to))


(! (decrement_o_cntr $o_dir_id))

START

END1

Figure C.15: The plan: told car entered. Catches the message sent when downstreamintersection agents tell this one that another car has entered the downstream intersection.Decrements the appropriate counter.

CONTEXTT

INVOCATION(*told (sensor_trip $from) told $_)


(* (tell (car_entered (agent_name)) $from))

START

END1

Figure C.16: The plan: respond to sensor trip. This is the only plan in the Sink agentfamily. It will echo back a car entered message for every sensor trip message sent to it.It just keeps the intersections’ counters sensible.

Multi-agent Design of a Trafﬁc-Flow Control...

Documents

Transcript of Multi-agent Design of a Trafﬁc-Flow Control...