TOPL Blog

Discussion – Aurora arterial modeling

2008-07-25T15:01:00.000-07:00

Issues:

1. An arterial model should provide the following:

a) Travel times

b) Delay

c) Stops

d) Volumes

e) Queues

f ) Cycle failure

g) Oversaturation

2. An arterial model should have control settings for coordinating ramps and arterials.

3. Can our arterial model be used for trip assignment?

a) What demand format (e.g. in form of O-D tables, turning ratios, etc) does the model accept?

4. Can the model be calibrated with counts/turning movements?

Outcomes (regarding point 1 above):

1. Travel time should refer to actual travel time, instead of instantaneous one.

2. Individual travel time for each vehicle can be determined by cumulative traffic curves.

3. Delay is determined as the difference between the actual travel time and the free-flow travel time. The free flow travel time of a link is defined as the time taken by a vehicle traveling through at free flow speed. The free flow speed of arterials is taken as 25 mph – 30 mph.

4. There is some discussion on the definition of ‘zero delay’. It is raised that ‘zero delay’ may be meaningless as all vehicles will definitely incur some delay on arterial. It is suggested that ‘zero delay’ should refer to the minimum delay that we can get in the arterial network.

5. The number of stops is generally defined as the number of times found that a vehicle is travelling less than a predefined speed threshold (typically 5 mph).

6. In macroscopic model (like Aurora), the number of stops can be approximated by the number of vehicles queued up during a red phase.

7. Cycle failure refers to the situation when vehicles arrived during the red phase of a cycle cannot be completely discharged by the end of green.

8. Oversaturation refers to the situation when a vehicle cannot proceed to the downstream even when the signal is green due to the spilling back of downstream queue to the local intersection.

9. Oversaturation can be detected in Aurora-CTM by checking when the ‘third term’ in the cell transmission rule dominates.

10. There are a number of different definitions for the terms ‘Cycle failure’ and ‘oversaturation’ in the literature. Some of them refer these two terms to the same thing. We shall follow the definitions adopted in Highway Capacity Manual.

Freeway capacity - a stochastic concept

2008-05-25T15:55:00.000-07:00

Hi all,

That's the paper on stochastic capacity that Pravin mentioned last Friday:

"Reliability of freeway traffic flow: a stochastic concept of capacity" -

by Werner Brilon, justin Geisterfeldt and Matthias Regler in the proceedings of the 16th International symposium on Transportation and Traffic Theory (ISTTT), pp. 125 -144.

The paper stated that the freeway capacities are different under flowing and congested traffic conditions. To address this, the authors considered the freeway capacity to be a random variable instead of a constant...

I can let you have a copy of the paper if you are interested.

In fact Xiao-yun and I have been studying this area (freeway capacity variations), I may give a brief presentation on some findings/literature review in the future if you wish...

O-D estimation

2008-04-29T22:50:00.000-07:00

I found a paper on O-D estimation called:

'Statistical inference for time-varying origin-destination matrices'

by Martin Hazelton, which is currently in press in Transportation Research Part B. The paper investigates the estimation method of "day-to-day" OD matrix using link count data (different Kwon and Varaiya's approach which used 'fastrak tagging data'). The O-D matrix is parameterized and determined using a Bayesian appraoch. The core idea of their underlying Bayesian appraoch is quite similar to the 'matching alogrithm' (the 'f' and 'g' things ..) that Pravin presented last Friday.

Although we are more interested in 'within-day' O-D, it may still be useful to see what we may learn from their work.

You can download the paper from the journal website or I can send you a copy if you are interested.

Aurora RNM - trip assignment

2008-04-25T15:31:00.000-07:00

Hi all,

I have spent some time studying implementing trip assignment module to Aurora. I have also studied the current software architecture of Aurora for this purpose. I have summarized some notes, including the modifications (see Part C) that I would suggest to do.

Please comment and let me know if there is anything you would like me to elaborate...

I will also upload some numerical calculations to the Aurora Blog later ...

A. Use of trip assignment in Aurora:

1. Interaction between travel demand and traffic condition

-E.g. choice between freeway and arterial

- No congestion -> everyone goes for freeway

- Freeway congested -> Someone may choose to take arterial

- Question: what is the proportion of flow on freeway/arterial?

- Some numerical calculations will be given later …

2. Estimate demand changes with respect to control policies (e.g. ramp metering, toll, traffic information provision etc..)

B. Assignment principles (travel demand model):

1. ‘ad-hoc’

- e.g. assign traffic to the shortest path at the current time interval

2. Deterministic user equilibrium (DUE)

- Ideal (actual)

- Instantaneous

3. Stochastic user equilibrium (SUE)

4. Stochastic ‘learning’ process / Dynamic game

- Evolution of drivers’ behavior as a result of ‘learning’

- system gradually would converge to some steady state (a Nash equilibrium) if there is no ‘disruption’ to the system …

Methods 1, 2, and 3 have been studied and used in the literature.

Personally I would buy Method 4. It seems to be more ‘statistically’ oriented. PeMS should be useful for calibrating or validating this.

C. Things need to be added to current Aurora RNM:

1. Split ratio profile over time

- the split ratios also supposed to be ‘state-dependent’

2. Data storage for

- flow on different paths;

- flow heading to different destination;

- different kind of vehicles (e.g. HOV vs LOV; Trucks vs autos).

3. Path travel time calculation

The path travel time in Aurora is currently calculated in an ‘instantaneous’ fashion: In other words, it is assumed that the travel time along the whole path does not vary after the driver enters the path. This doesn’t seem to be realistic ..

TransModeler

2008-04-17T22:26:00.000-07:00

Hi all,

TransModeler is a network simulation and operation tool equipped with GIS interface. TransModeler's a very impressive software package overall and it covers almost everything. I try to make a summary based on my understanding:

1. It can simulate a netork with different degrees of fidelity: microscopic, mesoscopic, and macroscopic:

a. Microscopic model captures the movements of each individual vehicle using kinematics (like the one in Paramics) ;

b. Mesocopic model uses speed-density relationship to describe the traffic state (like DynaSmart which we discussed before);

c. Marcoscopic model adopts the volume-delay relationship (like the one in the so-called 'static' model).

2. TransModel can be used for:

a. Intersection control (including pretimed, actuated, and actuated coordination. For the actuated controller, I believe that they are using a 'microcopic' appraoch (similar to Paramics) with detectors defined on the network);

b. Freeway traffic management (the design and simulation of HOV and HOT lane. TransModeler can also simualte the 'lane-changing effect);

c. Traffic demand analysis (O-D estimation, static and dynamic traffic assignments. The traffic assignments can be calculated according to different principles: shortest path assignment, stochastic shortest path assignment; user equilibrium assignment, stochastic user equilibrium assignment based on multinomial logic discrete choice model);

d. Transit simulation.

3. The software, of course, is equipped with easy-to-use GUI.

I wish the information will be useful to our future discussion and development.

Dynamic traffic assignment

2008-04-15T20:04:00.000-07:00

Hi Alex,

I have started building an assignment solver for Aurora RNM. At this preliminary stage, I constructed a simple network with two parallel links (as attached in the email):

Link 1001: origin link
Link 1002: one of the parallel links connecting nodes 1 and 2
Link 1003: one of the parallel links connecting nodes 1 and 2
Link 1004: destination link

The demand profile can be seen in the xml file.

The network is uncongested, which can be verified by seeing no delay on any link in it after simulation. I have the following problems:

1. Since the network is uncongested, I don't understand why the inflow to link 1002 from the origin link 1001 is distorted.

2. How can I split some flow from the origin to route 2 (i.e. via Link 1003). Currently all the flow from the origin is flowing on route 1 (i.e. Link 1002).

Please advise. Please let me know if you want more information from me.

Andy

P.S. For other people, please let me know if you want to have the config file of the 2-link network that we discussed above...

TOD signal plan - Lomita network

2008-04-05T14:08:00.000-07:00

Hi all,

I have updated the Lomita network config file (lomita_network.xml) for the Time-of-Day (TOD) signal controller. The file was put in the "config" folder. What I have done includes:

1. The simulation horizon was extended to 24 hours;

2. There are three timing plans used in the network, which are scheduled as follows:
00:00 - 06:00: Plan 1
06:00 - 10:00: Plan 2
10:00 - 16:00: Plan 3
16:00 - 20:00: Plan 2
20:00 - 24:00: Plan 1

The timing plan is set based on real signal data. Please let me know if you want to have the details of the timing plan.

3. The demand profile is
00:00 - 03:00: 0 vph
03:00 - 04:00: 100 vph
04:00 - 05:00: 200 vph
05:00 - 06:00: 250 vph
06:00 - 07:00: 500 vph
07:00 - 08:00: 1000 vph
08:00 - 10:00: 500 vph
10:00 - 12:00: 250 vph
12:00 - 15:00: 200 vph
15:00 - 16:00: 500 vph
16:00 - 17:00: 1000 vph
17:00 - 18:00: 500 vph
18:00 - 20:00: 200 vph
20:00 - 21:00: 100 vph
21:00 - 24:00: 0 vph

Please feel free to try and comment.

Aurora RNM - Actuated signal controller

2008-04-04T15:57:00.000-07:00

Andy's proposed actuated signal controller:
http://path.berkeley.edu/topl/docs.html

Gabriel's comment:

On the detector model, I dont think that headway = 1/flow is the right macroscopic variable for generating stochastic vehicle actuations. This is because a small flow could generate large headways, in freeflow, or small headways in congestion. It is argued in the attached note that the"smeared occupancy" lambda is what we want.

See http://path.berkeley.edu/topl/docs.html for Gabriel's detector model.

Andy's comment on Gabriel's idea:

1. I am still trying to understand 'lamda'. One quick observation is that the 'dimension' doesn't match: 'lamda' is dimensionless, while it is supposed to be the expect number of vehicles (instead of occupancy).

2. When it's congested and there are a lot of vehicles on the road, you will get a small spacing between successive vehicles since spacing is the reciprocal of density (Equation 2 in my note).

However, it appears to me that it doesn't necessarily imply you are going to have frequent actuations by detectors installed on the road.

It is because the headway of vehicles (and hence actuations) is going to be pretty long as well since the vehicles are moving slowly (speed is low in congested state..) and it takes longer time for them to reach the detector..

Next Phase of Aurora Development

2008-04-03T18:17:00.000-07:00

The Aurora research and development in the next phase of TOPL will address the following issues.

1. Support for complex link state.
Currently the state of the link is defined by the vehicle density, it is a scalar value. We would like to define the state as a vector of densities marked by vehicle types. The types of vehicles may be HOV-enabled, trucks, or ordinary vehicles. Vector-state will also allow us to approach the DTA problem, as in the DTA setting vehicles are characterized by the OD pairs.

2. Analysis module of Aurora.
Properly organized database that stores the simulation results is a key factor in the effective performance analysis of road networks. This module may include

actual travel time computation for the specified routes;
bottleneck identification;
analysis of stochastic demands and capacities.

3. New control algorithms for the ramps and arterials.
These include

system-wide ramp metering algorithms such as SWARM 1;
signal control with adaptive rate and coordinated signals on arterials; and
coordinated arterial signals and ramp metering.

4. Road network configuration management.
Proper organization and maintenance of configuration files will separate the network geometry from the event scenarios and demand profiles. This will allow to keep rarely updated and frequently updated configuration portions apart. The other goal is to simplify the process of building complex networks using the existing configuration files for their sub-networks.