In order to manage
the increasing demands placed on the surface transportation system, intelligent
transportation systems (ITS) are being developed to improve the efficiency,
safety, and predictability of travel. A significant limitation of current ITS
deployments are that they operate in a reactive mode. It is widely believed that a predictive capability must be
developed in order to fully realize the promise of ITS.
The Federal Highway
Administration (FHWA) recognized this and initiated the Dynamic Traffic
Assignment (DTA) research program in 1994. DTA systems provide predictive
traffic information to ITS sub-systems to help generate proactive,
network-wide, coordinated guidance and control strategies. They also generate
travel information for pre-trip planning (i.e., travel mode, departure time,
and route) and other traffic information and guidance to travelers for en-route
diversion. To date, two DTA systems have been developed in the FHWA program,
DYNASMART by the University of Texas, and DynaMIT by the Massachusetts
Institute of Technology.
DynaMIT integrates
a detailed network traffic model with models of traveler behavior. Through
combining information from historical databases with real-time inputs from
field installations (e.g., surveillance data and control logic of traffic
signals, ramp meters, and toll booths), DynaMIT generates estimates of future
traffic conditions. Beyond simulation-based evaluation, DynaMIT has been
investigated in Irvine, CA and is currently being evaluated in Los Angeles, CA.
Before proceeding
with wide-scale field implementation of DTA, it is necessary to consider its
performance in predicting traffic information for transportation management
center (TMC) application. The purpose of this project is to gain this
experience through a TMC testing in Hampton Roads, VA.
The Phase I
project evaluated the performance of the DynaMIT-R program for traffic
estimation and prediction for normal, bad weather, and incident conditions. The
evaluation was done off-line and both off-peak and peak traffic conditions were
considered. In addition, the functionality of variable message sign (VMS) was
evaluated via a hypothetical incident on Hampton Roads Bridge Tunnel.
Supply parameters
used in the DynaMIT-R program were calibrated using observed speed and volume
data and supplemented by the Highway Capacity Manual (HCM 2000), while
historical OD demand was calibrated using traffic sensor counts. Upon the
completion of supply and demand calibrations, evaluation scenarios were
developed and implemented.
As expected, the
results indicated that estimation and prediction errors were larger for peak
conditions. However, the prediction errors were not much worse than the
estimation errors, and were fairly comparable for all the scenarios considered.
Also, in all the scenarios it was observed that for both the estimation counts
and prediction counts, the root mean square normalized (RMSN) errors
corresponding to 5 minute estimation interval were relatively higher when
compared to those of 10 minute and 15 minute estimation intervals.
It was also found
that the performance under bad weather conditions (mostly upper limit values of
the error range) was slightly worse than those of normal and incident days. It
is understandable as traffic flows under bad weather conditions would be less
stable than those of normal conditions.
In all the
scenarios, it was observed that longer prediction intervals show smaller errors
than those of shorter prediction intervals. This is because longer intervals
tend to mitigate errors due to aggregation. More critically, a longer
prediction horizon implies that a larger fraction of each trip¨s travel times
are known with greater accuracy. In fact, the trips of a greater percentage of
vehicles are also better represented. As a result, driver route choices are
more realistic and accurate with longer prediction intervals.
From the Scenario
results, it was concluded that DynaMIT predicted traffic conditions for the
scenarios studied in this project fairly well and was also capable of providing guidance
to the users of the surface transportation system with the use of VMS
functionality.
Based on the
results of Phase I (off-line evaluation of DynaMIT), this document focuses on conducting an
online evaluation of DynaMIT¨s
estimation and prediction capabilities in Hampton Roads, Virginia. In addition, this
report also summarizes the results of DynaMIT recalibration, online integration
of DynaMIT with traffic sensor and incident data, online integration feedback
from Hampton Roads Smart Traffic Center Staff, and online evaluation scenario
and its evaluations. The report would provide recommendations for practical use
and future enhancements.
Based on the
above objectives, following tasks are implemented.
，
DynaMIT recalibration and analysis
，
Online integration of DynaMIT with traffic and incident
data
，
Online integration feedback from Hampton Roads Smart
Traffic Center Staff
，
Development of online evaluation scenario
，
Online evaluations
2. NETWORK AND DATA
2.1
Network Description
The Phase II
network is identical to that of the Phase I study. The network composed of
three freeways segments: I-64 between Bay Avenue and the Virginia Beach -
Chesapeake City Limits, I-564 between Terminal Boulevard and I-64, and I-264
between Broad Creek and Rosemont Road. This 19-mile segment contains 12
interchanges. The current Hampton Roads Traffic Management Center coverage area
is shown with bold line along I-64, I-564 and I-264 in Figure 1. In order to
test DynaMIT¨s capability of providing guidance to the travelers, the network
has been extended to provide an alternate route to the final destination for
the network of TMC coverage Area. Hence the study network, which mainly
comprised of three freeway sections, mentioned above, has been extended by
adding entire I-664 and I-64 that forms the outer loop as shown in Figure 1.
Figure 1. Network in Hampton Roads, VA
The resources for
network building and detailed information on network coding are described in the
Phase I report (Park et al, 2004). Figures 2 and 3 show the snapshots of the coded network in
DynaMIT. Figure 3 shows the structure at the I-64/I-264 interchange, the
busiest area in the network.
Figure 2. Snapshot of Hampton Roads Network for DynaMIT
Figure 3. Detailed snapshot of I-64/I-264
Interchange
The details of the
Hampton Roads network coded in DynaMIT are as follows:
There exist two types of nodes in
the network: Exit/Entry and Centroid nodes. Exit/Entry nodes are the points
where on- or off-ramp intersects with mainline freeway and the beginning and
endpoint of each freeway corridor. The total number of exit/entry nodes is 120.
Centroid nodes are the load or unload points where traffic flows either enter
or depart freeway system. They can be represented as origins and destinations.
In total there are 81centroid nodes (40 origins and 41 destinations) in the
network. In addition, there are 678 links in total; 565 freeway links and 113
ramp links. Reversible high occupancy vehicle (RHOV) Freeway mainline is coded
as bi-directional such that the network can easily handle both morning and
afternoon peak periods.
The creation of segments was the
key step for DynaMIT network coding. The use of the aerial photomap enabled the
team to locate exact points of geometry changes. The 678 links were further
divided into 1008 segments to model changes in link section geometry and to
avoid extremely long segments. The total number of traffic sensor stations
coded in the network was 227, including 6 Traffic Management System (TMS)
permanent count stations which use the expanded network and 205 stations in the
TMC coverage area. Since RHOV lanes were coded as bi-directional in the
network, the 16 stations on these links were also coded twice to represent the
two directions.
2.2
Data Description
For the purpose of
calibration and evaluation of DynaMIT in Phase II, traffic counts and speed
data obtained from the traffic sensor stations were needed. Traffic counts were
needed to represent the field conditions for both demand calibration and
evaluation. But for the case of supply parameter calibration, in addition to
the traffic count data, speed data was also needed to establish flow-speed
relationship. Hence for supply parameter calibration, out of the total 205
traffic sensor stations in the coverage area, only data from the 56 stations configured
with double loop detectors was used to ensure accurate speed measures.
Additionally, in
order to measure the performance of DynaMIT, traffic data including travel
times collected on June 15 and 16, 2005 were used in the evaluation and
analysis. The need and description
of the data for supply parameter calibration has been explained in detail in
the Phase I final report (Park et al., 2004).
2.2.1
Data Issues
Two significant
data issues were identified; (i) not all detectors provide good data continuously
over the entire evaluation period and (ii) some of the detector data, even
though they passed the state-of-the-art data screening techniques, were often
unrealistic. These issues were considered during the DynaMIT evaluation. For
example, partially missing data were imputed, and data quality (e.g., percent
of good data) was considered during OD estimation by adjusting Varcov values.
2.2.2
Data
Requirements for Demand Calibration
The main
requirement for the data needed for demand calibration was that the traffic
counts should be available at an aggregation interval of 5-minute for the
entire day. Since the quality of
the calibration efforts is largely dependent on the data quality of the days
used, a preliminary analysis for the data quality was done for the months of
September and October 2004.
The following
screening tests updated from Smith and Turochy (2000) were used for extracting
the good data points.
Test 1: Volume, speed
and occupancy readings should be non-negative.
Test 2: Occupancy
maximum threshold is 95%.
Test 3: Volume
maximum threshold is 3100 vehicles per hour per lane.
Test 4: When speed
equals zero, volume should not be greater than zero.
Test 5: The average
equivalent vehicle length (AEVL) should be greater than 2.7 meters and less
than 18 meters.
It is noted that
for single loop detectors, since no speed data can be obtained from the field,
Test 4 was not considered for them. Figure 4 shows the data quality for
September and October 2004. It can be observed that the average percentage of
good data is about 15%.
Figure 4. Data quality for September and October 2004
Also, in order to
achieve relatively quick convergence and stable historical OD flows, only data
corresponding to normal conditions, which neither have major crashes/incidents
nor bad weather, were considered.
This is because the use of incident conditions would require accurate
information on incident location, duration and capacity reduction; and
inaccurate incident information could lead to oscillations of OD flows during
calibration. The use of bad weather days would require the use of supply
parameters calibrated for bad weather conditions, which are different from
those of normal days. Thus, if days used for OD estimations were mixed with
normal and bad weather days, the convergence of OD flows would be quite slow.
By taking into
account for the above mentioned criteria, four days that were fairly normal
conditions were selected for demand calibration. Further investigation of the
data obtained for the four selected days showed the following challenges:
Traffic counts data
from some sensors were not reliable because they were found to be giving same
values for any time of the day. Such sensors were identified and removed during
the calibration. An important point here is that the data points from these
sensors were not detected as bad during the screening tests and hence they were
manually screened out. In addition, detector data by each station occasionally
showed missing traffic counts for some detectors. To overcome this, it was
decided to compute lane utilization factors for all the stations by time of the
day. The importance of computing such lane utilization factors is described in
the next section.
2.2.3
Computation of lane utilization factors
The aggregation
procedure for traffic counts at the station level involved adding up traffic
counts obtained from the working detectors and then, if some detector data were
missing, inflating it to the total number of detectors at a station. This
procedure assumes equal lane utilization factors to all lanes, which may
not be the case as it depends on traffic and geometric characteristics of the
sections of the subject freeway. In this particular case of Hampton Roads area,
there are a number of sections where the right most lane or the auxiliary lane
carries very low volumes or very high volumes depending on the distance to
adjacent interchange and flow characteristics. Therefore, if equal lane
distribution were assumed for the stations with missing detectors, the traffic
counts on these lanes would be highly overestimated or underestimated. The
following a hypothetical example illustrates these cases.
Consider a five
lane section of a mainline freeway where detectors are located on all the lanes
and the right most auxiliary lane was rarely used. This can be observed from
the second row of Table 1 that shows the actual lane utilization factors
obtained from historical data. Assume that for a time interval of 1 minute, the
following traffic counts were obtained for each lane as shown in the
third row of Table 1. If no extrapolation were done for lanes 4 and 5 with
detector counts, the total volume observed at the station would be 85 vehicles.
If an extrapolation were performed for lanes 4 and 5 with an assumption of
equal lane utilization, then the volumes for each of the lanes 4 and 5 would be
calculated as (20+30+35)/3 = 28.33. Therefore, total volume at the station
would be 142.
Table 1. Lane
Utilization Factors Example
On the other hand,
if lane utilization factors were used for computing the traffic counts for
lanes 4 and 5, they would be 10 and 5, respectively as shown in the last row.
This would make the total traffic counts at the station to be 100 vehicles per
minute. As can be observed from the two approaches, the total traffic counts
obtained from equal lane distribution assumption was overestimated by about 40%
which is considerably high. Therefore, it was decided to pursue computation of
lane utilization factors for each station by time of day such that better
quality traffic counts can be used in the evaluation. The following steps were
included in this process of estimating lane utilization factors:
In order to classify lane
utilization patterns by time of day, two factors were considered: one was the
high occupancy vehicle (HOV) hours and the other was traffic flow itself. The
reversible HOV is being operated in the morning from 6 AM to 8 PM and in the
afternoon from 4 PM to 6 PM. Therefore, consideration on HOV hours led to the
division of intervals into the following five time periods as shown in Table 2.
Table
2. Time of day period by HOV
hours
Then, these time
intervals were further divided into small durations of homogeneous time
intervals from the plots of variations in traffic counts by time of day. Figure 5 shows the plots of mainline
traffic counts of several stations by time of day for three days. Table 3 shows
final time intervals selected for lane utilization factor computations.
Table 3.
Final set of Time Periods within a day
|
Interval Number
|
Time Interval
(hours)
|
|
1
|
0 - 100
|
|
2
|
100 - 400
|
|
3
|
400 - 600
|
|
4
|
600 - 800
|
|
5
|
800 - 1100
|
|
6
|
1100 - 1300
|
|
7
|
1300 - 1600
|
|
8
|
1600 - 1800
|
|
9
|
1800 - 2000
|
|
10
|
2000 - 2300
|
|
11
|
2300 - 2400
|
Figure 5-1. Plots
of variation of traffic volumes by day (I-64)
Figure 5-2. Plots
of variation of traffic volumes by day (I-264)
Computation of lane
utilization factors for the stations where traffic counts were available for
all the detectors and for all the time intervals of the day was
straightforward. However, for stations where some detectors were not working
properly, 15 minute traffic counts by each lane for each time of day interval
shown in Table 3 were taken from the surveillance cameras in the Hampton Roads
area.
After computing the
lane utilization factors, they were used in the data extraction and
manipulation process for the four days that were selected for demand
calibration.
3. INTEGRATION OF DYNAMIT WITH ONLINE DATA
Many off-line field
evaluations of DTA prototypes including DynaMIT have been conducted both on
hypothetical and real networks. These off-line evaluations are excellent
alternatives for testing the capabilities and exploring the potential of their
usage in traffic management systems. But, they are only preliminary tests in
the evaluation process. Conducting an online evaluation can give a more
comprehensive understanding of the implementation and reliability issues. It
entails a deeper understanding and exploration of the functioning of the DTA
subsystem within the overall framework comprising of various systems in a
traffic management center (TMC). It can also be considered as an intermediate
step towards achieving full-scale deployment of a DTA system in a TMC. Thus, a
first step towards achieving this goal is the integration of DTA system with a
traffic management center.
The requirements
for the integration of DynaMIT with a TMC are as follows. The first requirement is a higher level
requirement describing the characteristics of the integration architecture as a
whole. The next requirement is defined specifically for each subsystem that is
envisioned to be part of online functioning of DynaMIT. These subsystems are
traffic surveillance, incident management, and information dissemination
subsystems. Although most of these requirements are fairly generic and can be
applicable for many TMCs, some level of customization may be needed depending
on the complexity of the present architecture in various TMCs.
3.1.1 Traffic Surveillance Integration
Requirements
A traffic
surveillance subsystem is an important element in a TMC that captures the
real-world traffic conditions from the field. For DynaMIT, this real-world sensor
data is the main source of information for the traffic conditions on the
network. Integration of this surveillance system ensures automatic input of
real-time traffic information into DynaMIT. Therefore, this section describes
the needed capabilities and the requirements to be met of such an interface
between surveillance subsystem and DynaMIT.
，
There exist different data sources within a TMC. Hence,
the interface shall be able to process data simultaneously from these various
sources in real-time.
，
It shall map the identification numbers of sensors on
the field with those coded in the network used by DynaMIT.
，
Depending on the estimation interval selected for
running DynaMIT, the time interval at which the sensor counts should be
obtained and aggregated will also vary. The estimation interval should be the
same as that of the time interval for aggregation of sensor counts. Therefore,
the interface shall be flexible such that the aggregation interval can be
changed.
，
The frequency or the time at which new set of traffic
data are obtained shall be equal to that of the estimation interval.
，
Along with traffic data, a measure of reliability of
the data obtained for that interval shall also be given for each station. This
helps in identifying bad stations which collect traffic data that is of very
low data quality and therefore helps in giving appropriate weights to these
stations during the online OD estimation and prediction process.
，
The interface should be able to convert the data
obtained from different sources into DynaMIT input format and only transmit the
data that is relevant for running DynaMIT.
3.1.2 Incident
management Interface requirements
The first step in
using DynaMIT for the incident management process is the detection of an
incident. Incident detection can be a fairly non-uniform process where in the
information about an incident can be obtained from various sources such as
surveillance cameras, drivers, moving patrols, etc. The scope of this interface
is limited to provision of the necessary inputs needed by DynaMIT for
simulating the incident conditions after obtaining the information about the
incident. Following are the requirements that are needed for such an interface:
，
After the detection of an incident, this interface
shall allow the functionality of mapping the location of the incident by
providing an interactive user interface where the operator can select the
particular segment on the network.
，
After the selection of the segment, the interface
should prompt the operator to enter the parameters needed for input in DynaMIT.
These parameters are start time of the incident, estimated end time of the incident, and
the available capacity on the segment in terms of fraction or percentage of the
original capacity.
，
Once the operator enters the required parameters, the
interface shall save the information to a text file that is in DynaMIT input
format. It shall also write the identification number of the segment that is
selected in the first step into the file.
，
Once the information about a new incident is entered,
the interface shall append the incident to the previous incidents in the file.
It shall also provide the functionality of removing the previous incidents.
3.1.3 Information Dissemination Interface
Requirements
After completing the estimation and
prediction for a time interval, DynaMIT can generate an output of the predicted
information. The type of the predicted information largely depends on the type
of decisions that the operators at a traffic management center intend to make
with the use of DynaMIT. It also depends on the type of information that is
intended to be provided to the drivers in the field.
The scope of these requirements for the
information dissemination interface is limited to the provision of the
information of predicted travel times to the operators in a traffic management
center. Following are the requirements that can be envisioned for such an
interface:
，
The interface shall provide the functionality of
selection of origin and destination of the path for which predicted travel
times are desired.
，
After the selection of origins and destinations, the
interface shall generate a text file, the format of which shall meet the
requirements of the DynaMIT input format.
，
The output of the predicted information from DynaMIT
shall contain predicted travel times for every five minutes or a user defined
unit (minimum of 1-minute) of the prediction interval.
，
The interface shall display and refresh the predicted
travel times after every five minutes for the selected origins and destinations.
This information shall be obtained from the output file created by DynaMIT.
In order to
consider DynaMIT for online implementation, the first step in the process was
to integrate DynaMIT with a real time database for providing the necessary
inputs to DynaMIT, thereby facilitating it to run continuously. These necessary
inputs are 5 minute sensor data and its corresponding data quality. In addition
to these inputs, this integration was also aimed at continuous monitoring of
the database for alerting the operator when a new incident is detected.
The approach
followed for performing this task of integration mainly involved connecting the
DynaMIT server to the Oracle database in the Smart Travel Laboratory (STL) via
a Java Based Database Connection (JDBC). After the connection was established,
a set of programs were developed for extracting the required sensor input and
data quality information every 5 minutes and displaying incident information as
soon as the database is updated with a new incident. The approaches followed
for achieving the integration of sensor and incident information is described
in detail in the following sections.
3.2.1 Sensor Data
3.2.1.1 Data
Flow
Figure 6 shows a
flowchart describing the current process of sensor data flow from Hampton Roads
Smart Traffic Center (HRSTC) to the database in the Smart Travel Lab (STL).
Research Report
No. UVACTS-15-11-71