ISSN 1055- 1425
April 2004
This work was performed as part of the California PATH Program of the
University of California, in cooperation with the State of California Business,
Transportation, and Housing Agency, Department of Transportation; and the
United States Department of Transportation, Federal Highway Administration.
The contents of this report reflect the views of the authors who are responsible
for the facts and the accuracy of the data presented herein. The contents do not
necessarily reflect the official views or policies of the State of California. This
report does not constitute a standard, specification, or regulation.
Final Report for Task Order 4307
CALIFORNIA PATH PROGRAM
INSTITUTE OF TRANSPORTATION STUDIES
UNIVERSITY OF CALIFORNIA, BERKELEY
Automatic Diagnostics of Loop Detectors
and the Data Collection System in the
Berkeley Highway Lab
UCB- ITS- PRR- 2004- 13
California PATH Research Report
Adolf May, Benjamin Coifman
Randall Cayford, Greg Merritt
CALIFORNIA PARTNERS FOR ADVANCED TRANSIT AND HIGHWAYS
Automated Diagnostics of Loop Detectors and the Data
Collection System in the Berkeley Highway Laboratory
Adolf May
University of California, Berkeley
Benjamin Coifman
Ohio State University
Randall Cayford
University of California, Berkeley
Greg Merritt
University of California, Berkeley
ii
iii
Preface and Acknowledgments
The BHL team would like to acknowledge the support given by Caltrans during this past year
and particularly to a number of Caltrans staff members in District 04 and Headquarters who have
attended project advisory meetings, and provided advice and guidance thorough the life of the
project.
The I- 80 freeway detectors within the study section of the BHL detector project have been
installed and are maintained by Caltrans. Caltrans has cooperated by permitting the detector
signals to be transmitted to the Berkeley campus for research prior to their being forwarded to
District 04 as part of their district- wide detector system.
The following Caltrans staff persons have attended project advisory meetings, and provided
advice and guidance during the life of the project. They include:
Vic Barbarick Adrian Levy
Alan Chow Joe Palen
Sean Coughlin Charles Price
Jim Durkee Ron Slade
Hector Garcia Martha Styer
Lester Lee Bill Wald
Kai Leung
Special appreciation is extended to Alan Chow, Joe, Palen, Charles Price, and Martha Styer who
have served as principal advisors to the project.
iv
v
Abstract
This document is the final report for the 2003 Berkeley Highway Laboratory ( BHL) project that
is part of the University of California’s PATH program and supported by the California
Department of Transportation ( Caltrans). The primary objectives of this project have been to
maintain, improve, and conduct research on the BHL detector system.
This report contains seven chapters that describe the work undertaken and the results of each task
of the project. The first chapter introduces the project, provides a project background, and a site
description. The next five chapters describe the various tasks of the project including task
objective, process followed, and results. The last chapter contains a summary of major
accomplishments and identifies future research directions.
KEY WORDS: Data Communication, Freeways, Real Time Information, Sensors, System
Engineering, Traffic Surveillance, Vehicle Detectors
vi
vii
Executive Summary
A two- level, nine diagnostic scheme has been developed including dynamic diagnostics
based on speed and vehicle composition. The scheme is now operational on a continuous basis
and has been incorporated into the BHL Web site for ready access of results by team members
and Caltrans representatives.
Detector deficiencies have been identified as well as specific ways of refining diagnostics
in the future.
A new component, the system monitor, was developed and deployed. If there is a
significant change in the operational status in any other system component, an automated email
notification is sent to BHL operators. A system status Web page has been deployed to show
real- time system status.
A comparative cost- effectiveness evaluation was undertaken for the BHL- type detector
system and the standard District 04 detector system. Criteria were established for selection of a
pilot freeway facility, and a pilot freeway facility was selected with guidance from Caltrans. The
evaluation determined that the total hardware and development costs to convert any or all of the
TMS in District 4 to transmitting detector event data to the TMC could be on the order of
$ 300,000 in one- time conversion costs and could provide conventional aggregate data of
comparable quality to what is provided by the existing monitoring system.
The BHL detector system and the data link to District 04 have been continuously
maintained.
The BHL detector data has been provided to researchers upon request. This has resulted
in the use of BHL data for additional traffic research beyond the scope of this project.
The BHL Web site has been significantly improved and expanded to include information
about the BHL detector system, provide access to current and historical traffic data, report on
system monitoring and detector diagnostic results, and give highlights of BHL- related research.
viii
ix
Table of Contents
1. INTRODUCT ION ................................................................................................................ ........................................... 1
2. DETECTOR DIAGNOST ICS ............................................................................................................................... ....... 5
2.1 HIGHLIGHTS OF 2002 RESEARCH ON DETECTOR DIAGNOSTICS................................................................................ 5
2.2 2003 RESEARCH ON DETECTOR DIAGNOSTICS TESTS ............................................................................................... 6
2.3 2003 RESEARCH ON DETECTOR DIAGNOSTICS WEB SITE ......................................................................................... 9
2.4 ASSESSMENT OF CURRENT I- 80 DETECTORS ........................................................................................................... 11
2.5 ANTICIPATED FUTURE RESEARCH ON DETECTOR DIAGNOSTICS............................................................................ 18
3. DEVELOP AND DEPLOY SYSTEM DIAG NOST ICS .......................................................................................... 22
3.1 IMPLEMENTATION OF ERROR RECOVERY MECHANISMS ......................................................................................... 22
3.2 IMPLEMENTATION OF SELF DIAGNOSIS SYSTEMS IN EACH COMPONENT ............................................................... 23
3.3 IMPLEMENTATION OF A SYSTEM MONITORING AND ALERT COMPONENT.............................................................. 23
3.4 EVALUATION OF SYSTEM DIAGNOSTICS .................................................................................................................. 23
4. BENEFIT AND COST ANALYSIS OF TRANSMI TTING DETECTOR EVENT DATA................................ 29
4.1 BENEFITS OF TRANSMITTING DETECTOR EVENT DATA .......................................................................................... 29
4.2 COST OF CONVENTIONAL TRAFFIC MONITORING.................................................................................................... 31
4.3 COSTS OF TRANSMITTING AND INTEGRATING DETECTOR EVENT DATA ................................................................ 33
4.4 CASE STUDY.......................................................................................................................... ................................... 36
4.5 SUMMARY ............................................................................................................................... ................................. 38
5. SYSTEM OPERATIONS........................................................................................................... .................................. 40
5.1 TASK 4: MAINTENANCE OF THE DATA LINK TO CALTRANS DISTRICT ................................................................... 40
5.2. TASK 5: MAINTENANCE OF THE LOOP DETECTOR BASED SURVEILLANCE SYSTEM .............................................. 40
5.3 TASK 6: GENERATION AND ARCHIVING OF SUMMARY DATA................................................................................. 40
5.4 TASK 7: DISTRIBUTION OF LOOP DETECTOR DATA................................................................................................. 44
6. BHL WEB SITE ............................................................................................................................... ............................ 46
6.1 ABOUT THE BERKELEY HIGHWAY LABORATORY.................................................................................................... 46
6.2 CURRENT TRAFFIC DATA ............................................................................................................................... ......... 46
6.3 HISTORICAL TRAFFIC DATA ............................................................................................................................... ..... 46
6.4 SYSTEM MONITORING RESULTS ............................................................................................................................... 51
6.5 DETECTOR DIAGNOSTICS RESULTS........................................................................................................................ . 51
6.6 DETECTOR DATA ............................................................................................................................... ...................... 51
6.7 BHL- RELATED RESEARCH....................................................................................................................... ............... 51
7. CONCL USION ............................................................................................................................... .............................. 56
7.1 SUMMARY OF MAJOR ACCOMPLISHMENTS.............................................................................................................. 56
7.2 FUTURE RESEARCH DIRECTIONS .............................................................................................................................. 57
x
xi
List of Figures
Figure 1- 1 Location map of the BHL detector system 2
Figure 1- 2 Flow chart of the BHL detector system and its connection to the District 4 Traffic
Management Center and the state- wide performance monitoring system 3
Figure 2.1 System- Wide Web site Display of Diagnostic Tests Results 10
Figure 2.2 Station Web site Display of Diagnostic Tests Results 12
Figure 2.3 Individual Detector Web site Display of Diagnostic Tests Results 13
Figure 2.4 Station 1 through 4 Detector Diagnostic Test Failures 14
Figure 2.5 Station 5 through 8 Detector Diagnostic Test Failures 16
Figure 2.6 Summary of Level One Detector Diagnostic Test Failures 17
Figure 2.7 Summary of Level Two Detector Diagnostic Test Failures 19
Figure 2.8 Summary of Individual Detector Diagnostics Performance. 20
Figure 3- 1 BHL System Component Diagram 25
Figure 3- 2 BHL System Status Web Page 26
Figure 3- 3 Detailed BHL System Status Web Page 27
Figure 4- 1 Table of estimated initial and on- going conventional detector station costs. 32
Figure 5- 1 Daily summary images 42
Figure 5- 2 One vehicle passing over a dual loop detector 43
Figure 6- 1 BHL Web site home page 47
Figure 6- 2 About the Berkeley Highway Laboratory 48
Figure 6- 3 Current traffic data – 30s. aggregate data by station 49
Figure 6- 4 Current traffic data – travel times 50
Figure 6- 5 Historical traffic data – speed 52
Figure 6- 6 Historical traffic data – density contour map 53
Figure 6- 7 Detector data 54
Figure 6- 8 Research projects 55
xii
1
1. Introduction
This document is the final report for the 2003 Berkeley Highway Laboratory ( BHL) project that
is part of the University of California’s PATH program and supported by the California
Department of Transportation ( Caltrans). The primary objective of this project has been to
continue to maintain, enhance, and conduct research on the Berkeley Highway Laboratory
detector system.
The BHL detector system is located along I- 80 in the East Bay portion of the San Francisco Bay
Area and lies between the Powell Street interchange and the Gilman Street interchange. Figure
1- 1 is a location map of the BHL detector system that consists of eight detector stations in each
direction over this 2.7- mile study section of I- 80. The detector stations are approximately one-third
of a mile apart and each station includes a pair of detectors in each lane of its 10 to 12
lanes. Each of the 164 detectors in the system is interrogated every 1/ 60 of a second as to
whether a vehicle is occupying the loop detector and this microscopic information has been
archived continuously during the duration of this project.
The BHL detector system is part of the Caltrans’ District 04 detector system that in turn is
included in the state- wide performance monitoring system ( PEMS). Figure 1- 2 is a flow chart
that includes the elements of the BHL detector system ( on the left) and its connection to the
District 04 Traffic Management Center and the state- wide performance monitoring system ( on
the right). The remaining portions of this report will deal with the BHL activities as shown on
the left- side of this illustration and its important connection to the District 04 Traffic
Management Center.
An important element of this BHL project has been its coordinated team effort, its close working
relationship with Caltrans, and quarterly reporting to the PATH program. The project began in
February 2003 and at the end of about every three months ( April, August, and December)
advisory meetings have been held with Caltrans. At each of these intervals, team meetings have
been held to exchange team member accomplishments, preparing for advisory meeting with
Caltrans, inspecting field sites, meeting with Caltrans representatives, and developing plans for
the next quarter’s efforts. Additional meetings were held as required between team members and
with Caltrans staff, and Caltrans staff was informed whenever significant detector problems were
encountered.
The project was originally divided into eight principal tasks and about mid- way into the project a
ninth task was added. Because of the late start of this ninth task, it will be reported in a separate
report at a later date. The remaining portions of this report will address the originally eight
principal tasks. Each task is briefly described in the following paragraphs and reference is made
to specific chapters in this report that cover each task in greater detail.
The first task was to undertake research to enhance the previously developed detector
diagnostics, to implement the enhanced diagnostics, to incorporate the results of the diagnostics
into the BHL Web site, and to make an assessment of the detector diagnostics and status of
detectors. This task is described in Chapter 2 of this report.
2
Figure 1- 1 Location map of the BHL detector system
3
Figure 1- 2 Flow chart of the BHL detector system and its connection to the District 4 Traffic
Management Center and the state- wide performance monitoring system
The second task was to undertake research in order to develop a multi- level system- wide
monitoring scheme for the BHL detector system, to implement the monitoring scheme, to
4
incorporate the results of the monitoring scheme into the BHL Web site, and to make an
assessment of the detector system. This task is described in Chapter 3 of this report.
The third task was to undertake a comparative cost- effectiveness evaluation for the BHL- type
detector system and the standard District 04 detector system. The subtasks of this task included
the establishment of criteria for selecting a pilot freeway facility, the selection of the pilot
freeway facility with guidance from Caltrans, a quantitative comparison of costs, qualitative
comparison of benefits, and reporting of results in a cost- effective manner. This task is
described in Chapter 4 of this report.
The remaining five tasks are integrated into Chapter 5 of this report because of their close
relationship. Task 4 was to maintain the data link to District 04, Task 5 was to maintain the
detector system, Task 6 was to generate and archive detector data, Task 7 was to distribute BHL
detector data to others, and Task 8 was to assemble the final report.
An additional chapter is included, Chapter 6, to describe the BHL Web site that has been
significantly improved and expanded. The Web site includes information about the BHL
detector system, provides access to current traffic data, provides access to historical traffic data,
reports on system monitoring results, reports on detector diagnostics results, provides for future
distribute of detector data, and gives highlights of BHL- related research.
The final chapter, Chapter 7, is divided into two parts. The first part summarizes the major
accomplishments of this year’s project both in terms of the immediate and longer- term
consequences. The second part describes future research directions with particular focus on next
year’s project.
5
2. Detector Diagnostics
Research on detector diagnostics has been underway since 2002 as part of the Berkeley Highway
Laboratory ( BHL) Project. The work undertaken in 2002 was reported in a PATH research
report UCB- ITS- PRR- 2003- 17 entitled “ Loop Detector Data Collection and Travel Time
Measurement in the Berkeley Highway Laboratory” and dated April 2003. Highlights of this
previous work will be presented first and then the most recent research on detector diagnostics
undertaken in 2003 will be described. The next two sections of this chapter will describe the
implementation of the detector diagnostic tests results within the BHL Web site and the
assessment of current I- 80 detectors using the BHL Web site. The final section of this chapter
identifies anticipated further work next year on detector diagnostics as part of the continuing
BHL research effort.
2.1 Highlights of 2002 Research on Detector Diagnostics
The April 2003 BHL final report contained two chapters dealing with detector diagnostics:
develop online detector diagnostics and implementing detector diagnostics. The executive
summary of this report contain the following two paragraphs.
“ Research of alternative detector diagnostic tests has been undertaken. Its major short- term and
longer- term accomplishments include the development and refinement of several single- and
dual- loop detector data validation tests.
An initial set of detector diagnostics has been implemented into the BHL detector system. This
has resulted in a set of four single- loop and one dual- loop tests that are run continuously against
the incoming data stream from every station”.
The five implemented diagnostic tests are briefly described in the following five paragraphs.
The activity test looks for activity at each single loop detector in a 15- minute interval and if there
is no signal transition, the detector fails this test. All detectors passed this test in the final
evaluation period except for three defective detectors.
The minimum on- time test looks at the length of the on- times for the last 100 vehicles to cross
the detector. If more than 3.5% of the vehicles generate on- times shorter than 7/ 60ths of a
second, the detector fails this test. All detectors passed this test in the final evaluation period
except for three defective detectors. There was some concern that the threshold value was too
lax and that the value should be increased and/ or the threshold value made adjustable based upon
on- line speed measurement.
The maximum on- time test looks at the length of the on- times for the last 100 vehicles to cross
the detector. If more than 3.5% of the vehicles generate on- times greater than 700/ 60ths of a
second, the detector fails this test. All detectors passed this test in the final evaluation period
except for three defective detectors. There was some concern that the threshold value was too
6
lax and that the value should be decreased and/ or the threshold value made adjustable based
upon on- line speed measurement and vehicle length distributions.
The mode on- time test sorts the lengths of the on- times for the last 1000 vehicles to cross the
detector. The times are sorted into bins of 1/ 60th of a second width and the mode of the
distribution is calculated. If the mode of the distribution is greater than 16/ 60ths of a second or
less than 10/ 16ths of a second, the detector fails this test. The test was only applicable under
free- flow conditions and even then gave unpredictable results. Further research is needed.
The dual loop on- time difference test compares the average on- times for each pair of detectors
for the last 1000 vehicles that cross the upstream and downstream detectors. If more than 5% of
the vehicles have on- time differences greater than 3.5/ 60ths of a second, the detector fails this
test. The test was only applicable under free- flow conditions and further research is needed.
The final chapter of the April 2003 final report contained a section on future research directions
and included the following paragraph:
“ The first task ( for further research) will be to continue to work toward an automated
detector diagnostics and real- time data validation. The goal of next year’s project will be
to extend and enhance the current detector diagnostics, and to begin to diagnose causes
and possible solutions when detector problems are identified. Beyond next year’s
project, means of substituting available data for missing data due to detector difficulties
should receive attention.”
2.2 2003 Research on Detector Diagnostics Tests
This portion of the research effort began with the previously developed detector diagnostics with
particular attention given to limitations, deficiencies, and opportunities for enhancement.
Several avenues of research were investigated including:
• Grouping diagnostic tests into two levels: critical functioning tests and qualitative
tests
• Moving the previously developed activity, minimum on- time, and maximum on- time
to the first level of tests
• Adding minimum off- time and maximum off- time tests to the second level of tests
• Converting the minimum on- time, maximum on- time, and maximum off- time to
dynamic tests in which the threshold value was adjusted to traffic conditions such as
speed and vehicle length.
• Attempt to improve the accuracy and robustness of the on- time mode time and the
dual- loop on- time difference test.
• Developing a Web site in which the results of these tests are continuously displayed
in an effective manner
As the research progress, an implementation plan evolved for each of the detector diagnostics
and the Web site display of test results. Each diagnostic was carefully reviewed, and in some
7
cases modified, and predicted results were monitored periodically during the duration of the
project. Particular attention was given to the problem of balancing between:
• Predicting that the detector passes the tests when in fact the detector data is not good
• Predicting that the detector fails the tests when in fact the detector data is good.
The final implementation plan is presented in the following paragraphs and comments added as
to special circumstances.
For each detector in each lane at a directional station, there are nine specific diagnostics that are
applied to the stream of detector signals it receives. The nine specific diagnostics that have been
implemented, three at the upper level ( critical functioning tests) and six at the lower level
( qualitative tests), and each test and its criteria for failing the test are described below.
Activity Test – If the detector signal has not changed state in the last 15 minutes, the test fails.
The intent of this upper level diagnostic is to insure that the detector meets its minimum critical
functioning level. If it does not, it is reported as failed. Experience with this diagnostic has
deemed it to be successful, and this test has not changed during the current project.
Minimum On- Time – If 5% or more of the on- times in a sample of 100 vehicles are less than
8/ 60 seconds, the test fails. The only possible problem recognized would be the situation when a
relative large platoon of short- length vehicles ( i. e., motorcycles) at high speeds would pass over
the detector. The intent of this upper level diagnostic is to insure that the detector meets the
minimum critical functioning level. If it does not, it is reported as failed. The changes in this
diagnostic test were to increase the threshold value from 7/ 60 seconds to 8/ 60 seconds and the
percentage of sample failures from 3.5% to 5%.
Maximum On- Time – If 5% or more of the on- times in a sample of 100 vehicles are greater
than 600/ 60 seconds, the test fails. The only possible problem recognized would be the situation
when a relative large cluster of long- length vehicles ( i. e., long trucks) at low speed would pass
over the detector. The intent of this upper level diagnostic is to insure that the detector meets the
minimum critical functioning level. If it does not, it is reported as failed. The changes in this
diagnostic were to decrease the threshold value from 700/ 60 seconds to 600/ 60 seconds and the
percentage of sample failures from 3.5% to 5%.
Mode On- Time – If mode on- times of 1000 vehicles are less than 10/ 60 seconds or greater that
16/ 60 seconds, the test fails. This test is a longer- term test that compares the measured on- times
of individual vehicles against the on- times of typical length vehicles. The test is only valid when
applied under free- flow conditions. The version of this test developed under the earlier project
frequently produced unpredictable results. This was primarily due to inadequate determination
of free- flow versus congested- flow conditions. Improvements to the free- flow determination
method were made and have resulted in a much more stable and useful diagnostic during free-flow
conditions. The intent of this lower level diagnostic test is to provide a warning when a
detector is suspected of poor performance. The only change in this diagnostic has been to
improve the determination of free- flow conditions.
8
Dynamic Minimum On- Time – This diagnostic is one of the new diagnostics and is the same as
the minimum on- time diagnostic described earlier except the threshold value is a variable
depending on on- line calculated speed. The test fails if 5% or more of the on- times in a sample
of 100 vehicles are less than the calculated minimum acceptable on- time threshold value. The
equation for the minimum acceptable on- time is
Min on- time ( 1/ 60 secs) = [( vl + dl)/( sp)][ 3600/ 88]
Where:
vl = average vehicle length ( assumed 20 feet)
dl = detector zone length ( assumed 6 feet)
sp = calculated average speed ( mph)
The intent of this lower level diagnostic test is to provide a warning when a detector is suspected
of poor performance.
Dynamic Maximum On- Time – This diagnostic is one of the new diagnostics and is the same
as the maximum on- time diagnostic described earlier except the threshold value is a variable
depending on on- line calculated speed and whether it is designated as a truck- use lane or not.
The test fails if 10% or more of the on- times in a sample of 100 vehicles are less than the
calculated minimum acceptable on- time threshold value. The equation for the maximum
acceptable on- time is
Max on- time ( 1/ 60 secs) = [( vl + dl)/( sp)][ 3600/ 88]
Where vl + dl is assumed to be 30 feet for predominant passenger vehicle lanes
and 66 feet for other lanes)
vl = vehicle length ( assumed to be 24 feet for predominant
passenger vehicle lanes and 60 feet for truck use lanes)
dl = detector zone length ( assumed 6 feet)
sp = calculated average speed ( mph)
Experience with this diagnostic test resulted in changing the original 5% value to 10% to reduce
the number of false calls. The intent of this lower level diagnostic test is to provide a warning
when a detector is suspected of poor performance.
Minimum Off- Time – This is one of the new diagnostics. If 5% or more of the off- times in a
sample of 100 vehicles are less than 25/ 60 seconds, the test fails. Car- following rules under
capacity conditions were first modeled to select this threshold value. It was found that the
threshold value was essentially independent of speed and primarily limited to maintaining a
minimum safe headway. Initially a threshold value closer to 60/ 60 seconds was used. However
field experimentation indicated that a much lower threshold value of 25/ 60ths of a second was a
more appropriate threshold value which is currently implemented. The intent of this lower level
diagnostic test is to provide a warning when a detector is suspected of poor performance.
9
Dynamic Maximum Off- Time – This is one of the new diagnostics. If 5% or more of the off-times
in a sample of 100 vehicles are greater than a threshold value which is a variable
depending on the calculated average time headway, the test fails. The equation for maximum
acceptable off- time is
Max off- time ( 1/ 60 secs) = ( t)( Tbar)( 60)
Where:
T = 3 ( representing 3 standard deviations)
Tbar = average time headway ( seconds per vehicle)
60 = conversion from seconds to 1/ 60 secs
The intent of this lower level diagnostic test is to provide a warning when a detector is suspected
of poor performance.
Dual Detector On- Time Difference – This test compares the on- times of the upstream detector
with the on- times of the immediate downstream detector for each pair of detectors in the BHL
system. If 5% of the on- time difference of 1000 vehicles are not between +/- 3.5/ 60 seconds, the
test fails. Under congested conditions, normal traffic can result in very large differences in on-times
between detectors so this test is restricted to free- flow conditions. The version developed
under the previous project used an overly simplistic method of determining free- flow conditions
that resulted in unpredictable results and large numbers of false failures. The free- flow
determination method was revised and the new test is much improved. The intent of this lower
level diagnostic test is to provide a warning when a detector is suspected of poor performance.
The only changes in this diagnostic have been to increase the percentage of failures from 3.5% to
5% and to improve the determination of free- flow conditions.
2.3 2003 Research on Detector Diagnostics Web site
An important accomplishment of the 2003 research was the development of a new BHL Web
site. The BHL Web site includes many features that will be presented later in more detail. One
of the features is the continuous displaying of the results of the detector diagnostics tests in
graphical form. The current BHL Web site ( http:// www. its. berkeley. edu/ bhl) provides an
instantaneous reporting of detector diagnostic results in a hierarchic three- level scheme: system-wide,
by station, and by individual lane detector.
The system- wide display reports one of three states for each directional station:
• a green state indicates that the directional station passes all diagnostic tests for all of
its lanes for all of its detectors;
• a yellow state indicates that it failed at least one lower- level qualitative test; and
• a red state indicates that it failed at least one upper- level critical functioning test.
Figure 2.1 contains an example of the system- wide display.
10
Figure 2.1 System- Wide Web site Display of Diagnostic Tests Results
11
The station display is similar to the system- wide display ( i. e., three states: green, yellow, and
red) but reports for its upstream and downstream detectors in each of its lanes. There are sets of
sixteen ( 16) such station displays; one for each directional station. Figure 2.2 contains an
example of a station display.
The individual lane detector display reports on each individual detector ( upstream and
downstream) and in each lane of each directional station. There are either eight or ten individual
sets of detector diagnostics for each directional station ( two detectors in either four or five lanes).
There are sixteen such displays. Figure 2.3 contains an example of a station display containing
individual detector displays.
2.4 Assessment of Current I- 80 Detectors
A comprehensive evaluation was undertaken of all 164 detectors in the BHL system using the
finalized version of the implemented complete set of diagnostic tests several times during the
past several months. The purposes of these evaluations were initially undertaken to improve the
diagnostics while the last evaluation was to assess the final version of the set of diagnostics and
to begin to diagnose causes and possible solutions when detector problems are identified. The
purpose of this section of this chapter is to highlight the results of the final evaluation of this set
of tests in order to assess the detector diagnostics and also to assess the performance of
individual detectors.
The detector diagnostic results of the final evaluation were captured from the Web site in the late
morning of Monday, October 27, 2003. The system diagnostics indicated that all system
components were operating correctly and all operations were normal. The percent occupancy
contour maps indicated that normal traffic operations were encountered ( primarily green with a
little yellow) except at station 8 in the eastbound direction at Powell Street that was in the red
state ( indicating congestion) most of the time. Hard copies of the system diagnostics and the
percent occupancy contour maps were obtained.
Hard copies of the detailed loop diagnostic results for each of the 16 directional station were
obtained and analyzed. The results were summarized in several different ways and are presented
and discussed in the following paragraphs.
Figure 2.4 contains a set of four tables that summarize the diagnostic test failures for all 80
detectors at stations 1 through 4 in both the eastbound and westbound directions. The four tables
from top to bottom are for the following groups of detectors: eastbound upstream, eastbound
downstream, westbound upstream, and westbound downstream. The vertical columns represent
individual detectors ( a total of 20 in each table) and the horizontal rows represent individual
diagnostics ( a total of 8 or 9) for a total of 160 or 180 cells in each table. Note that the dual
detector on- time diagnostic test requires information from pairs of detectors. An entry in the
table of “ 1” indicates that a specific detector failed a specific diagnostic test. A blank entry
indicated that the specific detector passed the specific diagnostic test. There are a total of 680
cells ( 240 level one cells and 440 level two cells) in the four tables of Figure 2.4.
12
Figure 2.2 Station Web site Display of Diagnostic Tests Results
13
Figure 2.3 Individual Detector Web site Display of Diagnostic Tests Results
26
Figure 3- 2 BHL System Status Web Page
27
Figure 3- 3 Detailed BHL System Status Web Page
28
need to be restarted by BHL staff. This has shortened the time particular software modules are
non- functional by a very large amount. Previously, problems occurring on the weekends or on
holidays resulted in multiple day outages. Now, most outages are on the order of minutes.
The automated notification system has also greatly improved system maintenance tasks.
The primary benefit is that monitoring the system has changed from an occasional manual check
requiring staff to pull data from the system to a continuously monitored system where data about
changes in system operation are pushed out to operators automatically. Previously, staff would
check the BHL at most a few times a day and often far less depending on work loads. Now, staff
are notified within two minutes of a problem occuring. There may be additional delay as staff
may not check their mail for several minutes more, but the time between occurence of a problem
and its detection has shortened from hours to minutes.
A second, unexpected, benefit of the automated notification system is that the email
notifications now provide a historical record of system operation. This has been beneficial in
identifying trends in system operations and in providing insight into variability within the
system. For example, the original monitoring system indicated an error when any lane of a
station had no traffic within the last 30 seconds. However, it frequently happens that a particular
lane will not have traffic for over a minute in the early morning hours. The current system waits
for no traffic for 120 seconds before indicating an error condition. Information about the
operation of the Verizon CDPD network has also been collected through the automated
notification system. Network drop- outs where the CDPD modems lose connection with the
Verizon network are fairly common. These show up in the BHL monitoring system as each
station is tested for connectivity every 2 minutes. This information was of great benefit for
convincing Verizon that their network had a problem in June, 2003. The BHL monitoring
information allowed us to quickly determine that the problem was Verizon’s network equipment
and not the BHL equipment.
The system diagnostic and monitoring components of the BHL have resulted in a much
more easily maintained system. The system requires much less operator intervention and reduced
staff time to keep the system running at a higher level than previously. The automated
notification system provides continuous monitoring of problems and an efficient use of staff
resources by freeing staff from routine checking of the system. In addition, the collection of
email notifications provides a valuable record of system operation over the past year.
29
4. Benefit and Cost Analysis of Transmitting Detector Event Data
This chapter reviews the benefits of transmitting detector event data, i. e., the individual
vehicle actuations. Then, to place the analysis in context, it reviews the costs of conventional
traffic monitoring, the additional costs needed to transmit detector event data ( i. e., the individual
vehicle actuations) and integrate these data with the existing ATMS servers by replacing portions
of the existing data collection system to allow it to collection and processing of the detector
event data. Finally, a case study is presented integrating these sections by examining a corridor
in Caltrans District 4. This study specifically examines the costs and benefits of adding detector
stations to the existing Berkeley Highway Lab.
4.1 Benefits of Transmitting Detector Event Data
The benefits of transmitting event data are only realized in the benefits of the specific
applications that use the data. These applications range from the most time sensitive, e. g.,
incident detection, to the least time sensitive, e. g., land use planning. Placing precise numbers
on the value of these applications is difficult at best; quantifying the specific contribution of the
detector data adds another layer of complication. However, the goal of this report is not to
convince the reader that traffic monitoring is beneficial. Caltrans and other operating agencies
have already recognized that the ability to respond to measured conditions justifies the
investment in the conventional surveillance infrastructure.
Conventional traffic monitoring aggregates the event data to fixed period samples of
flow, velocity and occupancy before transmitting the data to the Transportation Management
Center ( TMC). The sampling period is typically on the order of 30 sec or 5 min. This relatively
coarse aggregation can obscure features of interest and is vulnerable to noise. Both of these
factors delay the identification of resolvable events, the former due to the need to wait until the
end of a given sample period and the latter due to the need to wait for multiple sample periods to
exclude transient errors. The Nyquist sampling criteria, from basic signal processing, dictates
that one can only resolve features that last two sampling periods and the need to tolerate noise in
the measurements further reduces the response time.
Transmitting the detector event data centrally to the TMC promises to allow better
diagnostics, enable a quicker response time to incidents, and improve the quality of the data. It is
envisioned that for most existing applications, the event data will be aggregated after reception at
the TMC. But the nature of the aggregation can be tailored to the needs of the applications.
Many of these tasks could be deployed in the field controller, but others cannot because they
combine detector event data from multiple locations. Perhaps more importantly, it should be
easier to update the aggregation algorithm on a centralized server than it is to update it on
hundreds of field controllers.
The first improvements will come from improved detector validation tests. The detector
event data allow the use of microscopic validation tests. The fidelity available from individual
vehicle measurements is considerably greater than that which is available from aggregate
measurements of flow, velocity and occupancy. For example, one or two anomalous vehicle
measurements may not be detectable in the aggregate measures even though they could cause a
significant error in the aggregate measure. If such errors are apparent in an aggregate measure, it
may not be clear if it the problem is manifest on all vehicles or only a portion of the population.
Members of our group have led the development of microscopic detector validation tests and
30
these tests have been used to find non- functional or marginal roadway detectors, identified non-compliant
detector sensors that have been accepted by Caltrans, and have enabled the elimination
of some common crosstalk problems in the field [ 1- 3]. One would expect the diagnostics to
identify previously unknown problems and improve the diagnosis of known problems. These
tests can lead to improved data quality in two ways, first, allowing Caltrans technicians and
engineers to focus their resources on the true problems. Second, providing a means to " clean"
the data by identifying or even eliminating errors as they are found. When the errors cannot be
eliminated, the detector event data will allow for improved response, e. g., interpolating from
adjacent lanes, stations, or time samples in the given lane. This point will be important even
with fully functional detectors since the occasional transient error will still be expected, e. g., due
to a vehicle changing lanes over the detectors. Finally, by moving most of the data processing
out of the field and to the TMC, it may be possible to migrate to a less expensive field controller.
With improved performance from the detectors in the field due to focused maintenance
and reduced transient errors through filtering in the TMC, the conventional aggregated detector
data will improve -- an important outcome in itself. But as the data become more accurate, the
various applications can also reduce the time delay necessary to differentiate noise from real
events, e. g., it may presently take three or four samples at present to verify that an apparent
reduction in speed is not simply a phantom event due to a detection error and this could be
reduced to one or two samples with cleaner data. Inevitably new problems may emerge in the
aggregate data, and the log of event data will allow for more detailed diagnosis immediately,
rather than dealing only with cumbersome aggregate data or deploying dedicated data loggers in
an attempt to catch a potentially transient event data in the field. In any event, the response will
come quicker than presently feasible and if the solution necessitates a revision to the controller
algorithm, it can be corrected centrally rather than deploying crews to visit every controller
cabinet. Perhaps a more common scenario is simply the desire to improve the controller
algorithm based on additional knowledge. It has already been shown that fixed period averaging
is not the optimal aggregation technique for several measures. For example, [ 4] has shown that
the accuracy of velocity estimation from single loop detectors can approach that of
measurements from dual loop detectors by calculating the median vehicle on- time during a
sample, rather than the conventional estimate based on flow and occupancy ( i. e., mean vehicle
on- time). Meanwhile, [ 5] has shown that dual loop detectors can be used to estimate travel time
during congestion with high precision. The key to the methodology is tracking changes in
velocity as they pass over the dual loop detector and then integrating the information using a
variable sampling period in such a way to approximate the conditions experienced by a traveler
on the link. The widespread availability of detector event data will allow for much more rapid
algorithm development and further gains are to be expected. Naturally, these improvements will
likely be incorporated in the aggregation algorithms and again, they can be deployed much
quicker on the central server compared to sending crews to visit every controller cabinet.
Even with more rapid development, the best aggregation technique for one application
may not be optimal for another application. Fortunately, the detector event data can be
aggregated in many different ways at the same time. Thus, the TMC could run multiple
aggregation algorithms in parallel to provide clean data for traveler information while using a
different aggregation technique for incident detection. Or the TMC could compare the results of
two different algorithms to identify potential errors in either of them. Similarly, while new
aggregation algorithms are under development, they can be deployed in addition to, rather than
31
in place of, the existing aggregation techniques, thereby providing greater flexibility and the
ability to test out new ideas in a low- risk environment.
New measures will emerge from the event data. For example, one can measure vehicle
length directly at dual loop detectors or estimate it accurately at single loop detectors [ 4]. These
length data can be used for vehicle classification in the TMC rather than dedicated census
stations. But the detector event data do not simply provide a means to do existing tasks cheaper,
they also enable new measures of the traffic state. We have demonstrated vehicle
reidentification using detector event data, i. e., matching the measurement of a vehicle at one
detector station with the corresponding measurement from the same vehicle at another detector
station. This work uses the existing Caltrans detector hardware and matches with high accuracy
between 7 and 70 percent of the passing vehicles, depending on traffic conditions [ 6- 7]. Perhaps
counter- intuitively, the reidentification rate increases as conditions worsen. Once a vehicle has
been reidentified, its travel time is simply the difference between the known observation times at
the two stations. These algorithms have been deployed in real- time across the detector stations
in the Berkeley Highway Laboratory ( BHL) [ 8] and have been continuously operational for
several years. Combining these measurements with the aforementioned travel time estimates [ 5],
it should be possible to produce very responsive traffic monitoring algorithms. In this scenario,
the strength of the response may depend on the difference between the measured and expected
( estimated) travel time.
4.2 Cost of Conventional Traffic Monitoring
Before addressing the additional costs necessary to transmit detector event data, it is
important to understand the expense of transmitting conventional aggregate detector data to the
TMC. This section is based on interviews with Caltrans engineers from Districts 3 ( Sacramento
Metropolitan Area) and 4 ( San Francisco Bay Area), as well as the review of various Caltrans
cost studies. Again, it is difficult to identify a precise dollar amount since many of the resources
are divided between traffic monitoring and other applications, while the needs would be expected
to vary from site to site due to the number of lanes, amount of trenching necessary, and other
design issues. These sources place the total cost in the range of $ 40k-$ 150k per new detector
station, with $ 50k-$ 60k being the most likely [ 9- 10]. Several of the estimates are enumerated in
Figure 4- 1. These totals only reflect what Caltrans would pay, they do not include delays or
other direct costs to the traveling public.
Brian Simi [ 9] estimated that the largest costs are traffic control to close the lanes during
construction ( approximately $ 1,500 per lane) and jacking conduit to route cables under the
roadway. So the costs in table 4- 1 would be likely be lower for installation on newly constructed
facilities ( which would not require lane closures). He indicated that the marginal cost to install
dual loops rather than single loops is almost negligible compared to the total cost. Mr. Simi's
estimates are based on the use of a Model 170 controller; he indicated that it would cost about
$ 2,000 more to use a Model 2070 controller. He placed annual maintenance costs around
$ 1,000, with an additional $ 500-$ 1,000 for communication in the field ( depending on the mode
and location). In contrast to the loop based system, Mr. Simi estimated the cost to deploy a non-invasive
detector station using the Remote Traffic Microwave Sensor ( RTMS) to be on the order
of $ 25k-$ 30k using the RTMS internal controller emulation.
The current District 3 configuration has every field controller communicating directly
with the TMC. The older, analog telephone circuit system requires roughly $ 50/ month per 10
field controllers for communication on the TMC side. The newer Cellular Digital Packet Data
32
Total Initial Labor and Annual Support
Detector Station Construction and Staff and Maintenance
Source Costs Hardware Costs Costs Costs
[ 9] $ 56k n/ a n/ a $ 1.5k-$ 2k
[ 10] $ 50k-$ 60k n/ a n/ a $ 2k
[ 11] $ 92.7k $ 56.5k $ 35.2k $ 7.2k
[ 12] $ 150.9k $ 43k $ 71k n/ a
[ 13] n/ a $ 151k n/ a n/ a
Figure 4- 1 Table of estimated initial and on- going conventional detector station costs.
Note that the first column, total initial detector station costs, include the costs
listed in the second and third columns, construction and hardware costs, and
labor and staff costs, respectively.
33
( CDPD) system requires roughly $ 200/ month per 100 field controllers on the TMC side.
Once inside the TMC, the detector data first enter a Front End Processor ( FEP) that costs roughly
$ 5,000, and there is a single FEP serving all of District 3. The FEP then feeds the ATMS server
( roughly $ 100k) that also handles control tasks ( changeable message signs, ramp metering, etc.).
Sean Coughlin [ 10] reported similar cost numbers, while providing additional
information on District 4. He noted that District 4 has approximately 1240 directional mainline
detector stations ( note that two directions are often but not always monitored by a single
controller). He estimated that the incremental cost to deploy a second loop per lane to be $ 550-
$ 600, which corresponds almost exclusively to the increased material cost. He also provided
more precise numbers on the current communication mode, CDPD. He said that each CDPD
installation costs roughly $ 1,000- 2,000 for hardware and installation, and $ 35/ mo for service.
The wireless service providers are phasing out CDPD and it is not yet clear what the replacement
mode will be or what it will cost. Ron Slade, also of District 4, indicated that General Packet
Radio Service ( GPRS) is the, " odds on favorite," to replace CDPD, with equipment and
installation costs similar to CDPD.
4.3 Costs of Transmitting and Integrating Detector Event Data
This section leverages our experience working with the BHL and transmitting detector
event data. The facility is one of PATH's testbeds; it includes seven dual direction loop detector
stations, two single direction loop detector stations and 14 video cameras on top of the 30 story
Pacific Park Plaza, within 50 feet of the edge of pavement. The BHL was conceived as a facility
to collect detailed traffic data and allow the demonstration of new surveillance techniques in real
time.
Within the BHL the detector stations are relevant to this report. The BHL uses the
standard Caltrans District 4 traffic monitoring station with a Model 170 controller sampling the
loop sensors at 60 Hz. Under normal operation, the 60 Hz event data are internal to the
controller, and the controller outputs aggregate data from fixed sample periods, as discussed
above. Caltrans developed new controller software for the I- 880 Field Experiment that preserves
the 60 Hz event data [ 14]. Because the Model 170 controller is based on 20- year- old technology,
formatting and outputting this data stream consumes most of the controller's processing power.
The I- 880 Field Experiment used a laptop computer in conjunction with each controller to collect
and store this data stream in the field ( due to the absence of sufficient communication bandwidth
at the time). The BHL uses the same controller hardware and software, but rather than storing
the event data locally in the controller cabinets, it is transmitted to the University of California
via a CDPD modem and the Internet. This communication architecture is similar to that used by
conventional detector stations except for the nature of the data transmitted and the server
response.
The BHL has been monitoring the freeway continuously, 24 hours a day, seven days a
week, since the end of 1999. The BHL has provided proof- of- concept for simultaneously
reidentifying vehicles, measuring travel time directly, providing conventional traffic measures
( flow, velocity and occupancy), and the deployment of microscopic detector validation tests
across 14 directional pairs of detection stations.
As noted by [ 10], any large- scale deployment to collect detector event data may need a
more expensive field communication system to transmit the higher volume of data, more data
storage, and/ or additional computing power in the TMC compared to the conventional data
collection. The approach would also fail to utilize the full processing power of the field
34
controller, but as noted earlier, this fact may allow for the use of less expensive controllers.
Finally, there is an increased cost in data aggregation. In the field all of the data are available
directly but aggregating the detector event data after transmission to the TMC will require
additional processing overhead to sort the data and the system will have to accommodate
possibility of lost data packets.
Based on interviews with Randall Cayford [ 15], who led the implementation of the BHL
loop detector data collection and real- time processing, the current implementation uses a data
collection server, a database server and a web server. These three computers are all over four
years old and it is envisioned that the functionality could be consolidated onto one contemporary
computer. There are plans to revise the system using two computers for increased reliability
($ 4k each) and Mr. Cayford estimates that this pair of computers will have sufficient processing
power to provide data collection, vehicle reidentification, travel time measurement, conventional
traffic measures, and microscopic detector validation tests for up to 700 dual direction detector
stations ( though additional memory and larger hard disks would be required to actually
implement a system that large). An issue with system expansion is increased bandwidth costs
and, potentially, network contention caused by all the stations sending their information more or
less simultaneously.
The current communication system in the BHL suffers from packet collisions upstream of
the data collection server ( roughly one percent of the data does not reach the server). This loss is
likely due to the overloaded University of California network in the building where the servers
are located ( shared 10 Mb Ethernet serving 248 computers). When the network is too busy,
packets are discarded. This happens fairly frequently on the campus network. Mr. Cayford
noted that this theory would be tested with the migration of the data collection system to the
California Center for Innovative Transportation ( CCIT) facility in Berkeley. If the problems
persist, additional measures can be taken to ensure data reception by setting the modems to
resend if no acknowledgement is received. Discussions with the CDPD modem vendor have
indicated that a confirmation and resend system, similar to that used in modems attached to
priority traffic signal controllers would provide the necessary delivery assurance.
Collecting detector event data entails transmitting a larger amount of data from the field
to the TMC than is required by conventional data collection. The bandwidth required for an
individual station is approximately 8 times the bandwidth required for collecting the
conventional aggregate data. While the requirements for an individual station are well within the
available bandwidth for CDPD transmission or any likely replacement technology, the increased
bandwidth needed by a large scale implementation could require upgrading the communication
link between the TMC and the wireless network. A 700 station system would generate
approximately 420 kbits per second of detector event data. This would require at least a T1 level
connection between the TMC and its internet provider. A T1 connection provides 1.54Mbits per
second of bandwidth so a large scale deployment would consume a fairly large percentage of the
available capacity. Only part of the cost of T1 line, around $ 500 per month, would be an
additional cost to the TMC, however. A conventional system would require at least one or two
56Kbits per second connections, which would be replaced by the higher capacity T1 connection.
Mr. Cayford expects that if deployed on a larger scale, most of the BHL data collection
system should work with little modification to the software. The possible exceptions are as
follows. First, the vehicle reidentification algorithms may need revision because they have not
yet been tested on a wide number of locations due to lack of available data. Second, the system
works with Traffic Monitoring Stations ( TMS), further development would be needed to make
35
the system compatible with Ramp Metering Stations ( RMS). Here the bottleneck is the Model
170 controller. Possible solutions at RMS all would require additional processing power in the
field controller cabinet, they include the use of Model 2070 controllers, using an inexpensive PC
to assist the Model 170 controller, or placing two Model 170 controllers in parallel.
Based on [ 9- 10, 15], for the initial deployment, it is most likely that the detector event
data server would replace a FEP, passing data to the ATMS server in conventional formats. The
aforementioned computers could serve this role. The cost to update the ATMS server software is
likely to be high and it is most likely that this would only be done with the next server update. In
the mean time, the new FEP could provide cleaner data to the ATMS server and even use
measured travel times to feed the ATMS true link velocities as if they were measured at a
detector station.
Assuming no investment to incorporate or further the benefits of advanced detector
technology, as listed in Section 4.1, [ 15] estimates the following would be necessary to convert
any or all of the detector stations in District 4 to transmit detector event data to the TMC.
• Purchase the two new computers, $ 8,000, which are already budgeted in a 2003-
2004 PATH project
• Adapt the current software for the TMC
• Add configuration information for each station to the system
• Test each station
• Correct as necessary any identified problems both within the TMC and in the field
After adding a few stations, the marginal cost of adding another station is just data entry
and fixing any problems in the field station that may be identified by the detector event data
based tests. Some of these field problems may be compensated for at the TMC, while the rest
should be fixed regardless of whether one is collecting detector event data or conventional
aggregate data from the field controller. The algorithm that calculates conventional aggregate
traffic measures in the BHL needs to be revisited to improve its robustness in the presence of lost
packets. The current aggregation algorithm was developed quickly to prove the feasibility and
was not the core focus of the research. It is estimated that this work would take a few weeks.
Finally, CDPD service plans allow unlimited data transmission while current GPRS service plans
charge per the amount of data transferred. So although the field communication costs to transmit
detector event data are currently identical to that of conventional aggregate data, it is possible
that the higher bandwidth requirements may push costs higher once CDPD is discontinued. It is
likely that Caltrans can negotiate a favorable rate, but these factors are unknown at the time of
writing.
Baring any unforeseen complication, the total hardware and development costs to convert
any or all of the TMS in District 4 to transmitting detector event data to the TMC could be on the
order of $ 300k. Most of this cost is in one time conversion efforts to set up and test the
replacement system. A second major source of cost would be one time development costs to
adapt the software from the current university setting to a TMC setting. The actual incremental
cost of the event data system versus the conventional aggregate data system is a very small
portion of the estimated conversion cost. The converted system could provide conventional
aggregate data of comparable quality to what is provided by the existing monitoring system. A
replacement of the current systems with one that collects detector event data and simply mimics
the aggregate data would provide a limited set of the benefits available. In this scenario, the two
server computers would be located in the District 4 TMC and integrated into the existing ATMS
36
server by mimicking the existing FEP protocol. Assuming Caltrans is interested in eliminating
data errors, the field visits to rectify existing problems at the detector stations may prove to be
the dominant cost. Until reviewing detector event data from across the district, we are unable to
comment on how extensive such field visits might be. Regardless, each station would have to be
visited to update locally the controller software, but this effort could be done for negligible cost
if it were concurrent with the CDPD replacement program.
Finally, [ 10] emphasized that most of the applications that use the detector event data
could be implemented in the field using Model 2070 controllers. Thereby eliminating the need
to transmit the large quantity of event data to the TMC. The Model 2070 controller has flash
memory, allowing for the download of revised thresholds as needed without a visit to each
location. Even some of the vehicle reidentification algorithms could potentially be supported if
the controller extracted the relevant data and summarized it for transmission ( though a central
server would still likely be needed to collect and process the data for vehicle reidentification).
Of course any major revision to the algorithms would likely require a field visit to each
controller to update its software. This field controller based option should remain in
consideration for large- scale deployment, however, the cost of implementing it is not clear. We
do not know how difficult it would be to program and debug the Model 2070 to implement the
applications discussed in Section 4.1, and thus, can not quantify the costs for this alternative
approach. Furthermore, the specification for the Model 2070 controller is in flux, the final
specification may not be able to support some of the applications. If favorable service plans do
not become available for GPRS that allow the transmission of large quantities of detector event
data, the field controller based option may lead to lower communication costs.
4.4 Case Study
The BHL has proven beneficial as a research test- bed, but the ultimate goal of this
research is to improve the quality of data that Caltrans uses for operational and planning decision
making. Preliminary discussions with Caltrans Headquarters, District 4, and the BHL research
team lead to the objective of investigating the possibility of extending the BHL surveillance
system to a long corridor. The BHL research team established several desirable criteria for such
a corridor, as enumerated below, along with the motivation:
1. The selected pilot freeway facility should be located in District 04.
• The reason for this criterion is because of the longstanding cooperative
arrangements with District 4 and the convenience of being near to the BHL
laboratory and staff.
2. It should be between 3 and 8 miles in length.
• The reason for this criterion is to study a reasonable length of freeway;
sufficiently long to provide meaningful results but not so long to cause
unnecessary effort to undertake a cost- effectiveness evaluation.
3. It should have a minimum of three lanes in each direction and preferably four
lanes in each direction.
• The reason for this criterion is that six- lane and eight- lane freeways are more
normally encountered in areas where detector data are needed.
37
4. There should be a current standard District 04 detector system in good
operating condition.
• There should be significant portions of a current standard District 04 detector
system in place. The reason for this criterion is to reduce the implementation
time in the event it is decided to install a BHL- type detector system.
5. There should be pairs of loop detectors in each lane at each station and in each
direction of traffic, and the stations should be spaced at approximately 0.5 mile
intervals.
• The reason for this criterion is that stations having pairs of detectors at
approximately 0.5 mile intervals appear to be typical for both the standard
Caltrans- type and BHL- type detector systems.
6. There should be no ramp metering on the section.
• The reason for this criterion is that the existence of ramp metering will place
added burdens for both the cost- effectiveness evaluation and if
implementation is considered.
7. There should be some congestion during one or more of the daily peak periods.
• The reason for this criterion is that both detector systems should be evaluated
under both free- flow and congested- flow conditions.
8. Caltrans staff should consider the pilot freeway facility as a good site for the
cost- effectiveness evaluation
• The reason for this criterion is that Caltrans should feel that the cost-effectiveness
evaluation results obtained are typical and transferable to other
similar sites.
9. Caltrans staff would be receptive to consider implementation of the new detector
system at the selected site in the event it proves to be significantly more cost-effective.
• The reason for this criterion is that if the new detector system is shown to be
significantly more cost- effective, its implementation would be a step in
improving the District- wide detector system.
The BHL research team then provided these criteria to the Caltrans Advisory Group
Members and asked them to do three things: review the site selection criteria, identify sites in
district 4 that meet this criteria, and attend a meeting to select the pilot freeway facility. Three
corridors were identified at the meeting for further analysis: I- 80 from the Central Ave to SR- 4
( 10 mi), SR- 24 from Fish Ranch Rd to I- 680 ( 8 mi), and I- 680 from Alcosta Blvd to SR- 24 ( 14
mi). These locations are listed in the final order of preference and it was agreed that attention
would be given to the first two sites. District 4 engineers then provided detailed descriptions of
the I- 80 and SR- 24 sites, including the locations of detectors, ramps, lane drops ( additions), and
other pertinent features.
The number of detector cabinets is of greatest relevance to the cost of transmitting
detector data, though these costs are currently the same for conventional and detector event data.
38
The SR 24 site has 27 directional detector stations each with its own cabinet and two dual
directional detector stations that each has its own cabinet ( 29 total TMS). The I- 80 site has 6
directional detector stations each with its own cabinet and 29 dual directional detector stations
that each has its own cabinet ( 35 total TMS). The SR 24 corridor has the attractive feature that it
is on a different facility than the existing BHL. However, it does not include the primary
bottlenecks at either end of the corridor ( Caldecott Tunnel on the west, I- 680 split on the east).
The I- 80 corridor is attractive in the fact that it extends the existing BHL to include the northern
junction of I- 80/ I- 580. Preference was ultimately given to the I- 80 corridor.
In either case, the existing BHL system should be able to accommodate the small number
of detector stations without additional development or hardware costs. As with Section 4.3, the
additional stations would collect detector event data and provide conventional aggregate data of
comparable quality to what is provided by existing monitoring system. Although the data
collection system is located on the University of California campus ( with a potential move to
CCIT in the near future), it provides the aggregate data to the ATMS server in the Caltrans
District 4 TMC. The field communication costs would be identical to the conventional
surveillance system while CDPD remains available. So up to this point, the additional costs
would be negligible, with the largest component being that of visiting the stations to reconfigure
the controllers and modems. However, since these stations would be used for detailed traffic
analysis and algorithm development, they would likely require field visits by Caltrans or PATH
staff to rectify any existing problems in the field. The cost and extent of necessary work is
unknown, but it would provide for a more informed cost estimate to correct existing problems at
detector stations for a larger scale deployment. The additional costs for the field visits could be
encumbered incrementally or be bounded by an upper ceiling, e. g., fix as many stations as
possible in the corridor for a given sum.
4.5 Summary
This chapter examined the benefits and costs of transmitting detector event data. The
benefits of transmitting event data are only realized in the benefits of the specific applications
that use the data. The benefit of traffic monitoring is widely accepted, and the detector event
data promise significant benefits relative to conventional aggregate data. Several of these were
discussed, including:
• Microscopic detector validation tests
• Improved response to detector errors
• Archived data allowing for detailed diagnostics
• Reduced cost of controllers in the field
• Improved quality of aggregated data
• Ability to update the aggregation algorithm centrally
• Provision of data and other resources to develop more advanced aggregation
algorithms
• Ability to run multiple controller algorithms in parallel, optimizing each to
different tasks
• Length- based vehicle classification
• Vehicle reidentification
The cost to deploy a conventional freeway detector station with dual loops is in the range
of $ 50k-$ 60k, with an RTMS- based system being roughly half of that. In contrast, the cost to
replicate the BHL data collection system within a Caltrans district TMC is roughly $ 8k to simply
39
collect detector event data and provide conventional aggregate data for up to 700 field
controllers. Updates to the aggregation algorithm are needed and it would be necessary to ensure
that the output format was compatible with any existing ATMS server. These additional efforts
would add a one- time development cost on the order of $ 300k. Assuming Caltrans is interested
in eliminating data errors, field visits to rectify existing problems at the detector stations are
likely to prove to continue to be the dominant cost. To get a better estimate on these costs, an
expansion of the current BHL data collection effort along a corridor in District 4 could be done.
This limited deployment would not immediately realize all of the potential benefits of collecting
detector event data centrally, but it would not degrade conventional traffic monitoring and it
would allow for further development of applications using the event data and a gradual phasing
in of the advances. Although no specific value was placed on the benefits, the marginal cost of
collecting the detector event data is small.
40
5. System Operations
5.1 Task 4: Maintenance of the Data Link to Caltrans District
Caltrans collects 30 second data from highway loop detectors statewide. The Berkeley
Highway Lab, in addition to collecting 1/ 60 second data, generates 30 second data which is
relayed to Caltrans and integrated into the statewide Caltrans IFS2 data collection system. For
this data to reach Caltrans, the dedicated data communication line between the Berkeley campus
and Caltrans District 4 must function, and 30 second data must be made continuously available
over this link.
The data link that allows 30 second data to travel from the BHL system to Caltrans
District 4 is supported by a frame relay connection. This is a virtual point- to- point link with
robust error correction, and has performed very reliably during the course of the project.
A Caltrans server at the remote end of the frame relay connection continuously sends data
requests to the BHL Caltrans D4 Link Server, which provides the 30 second data in response to
each request. The BHL team monitors the Caltrans data requests and can inform Caltrans in the
event that data is not being pulled from the Berkeley Highway Lab.
The frame relay data line between the Berkeley campus and District 4 is highly reliable;
service on this line is estimated to exceed 99% availability.
The status link is monitored continuously as part of the BHL system diagnostics. Current
status of the link is displayed on the BHL Web site, and link outages cause an automated e- mail
warning to be sent to BHL team members.
This frame relay data link performs well, and there are no plans to replace or modify this
portion of the BHL infrastructure
5.2. Task 5: Maintenance of the Loop Detector Based Surveillance System
The Berkeley Highway Lab consists of many physical components, including network
communications infrastructure and computer hardware and software. To capture as much data as
possible, it is important to maintain full functionality of all of these components. At the
beginning of this project, the BHL data system only had several simplistic auto- notification
features. Maintaining the system in good working order required team members to pro- actively
check several system components several times per day to ensure proper operation.
As part of Task 2, Automated System Diagnostics ( Chapter 3), many of these system
checks are now performed automatically. If errors are generated in the system, e- mail
notification is sent to team members. Also, system status can be seen by team members ( or
anyone) at the BHL Web site; see Figure 3- 3 and Chapters 3 and 6.
5.3 Task 6: Generation and Archiving of Summary Data
The following data sets are regularly generated and archived:
• Raw, bitpacked detector data
• Sorted, bitpacked detector data
• Measured travel times
• 30 second aggregate by lane
• 5 minute aggregate by station
41
• Daily summary images
• Diagnostic data
• Individual vehicle data
The raw data are stored in six hour long intervals and include all stations. The following is a
sample of seven lines from this data set.
983693022000 983693017120 1351 40584 3 270B3D65D174C86D8AAB0DB4ABE9E4937
983693022000 983693026730 1009 38223 1 270BD0FAE7DA0D87E7C39
983693021000 983693027110 281 75085 5 2702D103DC3FF7DF70
983693023000 983693026620 1256 - 80516 2 2713B632305505B18D14A
983693022000 983693016400 710 148 7 270004A117962A34B61CEFDB5E14E8235
983693023000 983693017010 2278 - 3749 4 2700F8425D0C
The first two columns are the time in the field ( 1/ 1000 sec) corrected for clock drift since restart
and uncorrected, respectively. These values were originally relative to the PC clock in the field,
which was reset once a day when the computer underwent a forced hard restart. The two
columns were used because the PC clocks would drift significantly throughout the day. Now,
however, the PC has been eliminated from the loop and CDPD modems are being used. So the
times are generated in the server based on when the packet arrives. The next column shows the
cumulative number of PC restarts and was used to determine if the station has restarted. The
fourth column shows the offset ( sec) of the controller clock, i. e., the value to add to the controller
clock to generate the correct time. The controller clocks do not drift significantly from one day
to the next but may show significant drift after power outages and other unusual events. By
tracking the offset, the need to visit the cabinets and reset the clocks has been eliminated. The
fifth column indicates the station number and the sixth column contains the encoded controller
data. The encoded data are sent each second and include the controller time and information
about each observed transition ( detector number, state and time).
The sorted data followed the same format as the raw data; however, there are several differences
in the content. The data from each station are stored in different files. Unlike the raw data,
within each file the data are sorted by time and any duplicate packets are removed.
The measured travel times include the link number, lane, direction, travel time and time that the
reidentified vehicle exited the link. The aggregate data include station, time, lane, flow ( veh/ hr),
occupancy ( percent), and velocity ( mph) averaged every 30 sec.
The daily summary images provide an efficient overview of the BHL throughout the day. Figure
5- 1 shows a sample of these images. Distance along the facility is shown on by the abscissa and
time of day by the ordinate. Since each detector station is at a fixed location, the data fall in
discrete columns. In this figure green indicates less than 40 vehicles per mile per lane, yellow is
40 to 60 vehicles per mile per lane, and red represents 60 or more vehicles per mile per lane.
Any period without data is shown in white. Inspection of these plots shows congestion growing
from downstream and then receding in the opposite direction, both from recurring bottlenecks
and incidents.
Figure 5- 2 shows a time- space diagram depicting a vehicle passing over a dual loop detector.
The controller normally records four transitions, i. e., the turn- on and turn- off times at each of the
42
Figure 5- 1 Daily summary images
43
Second Loop's Detection Zone
First Loop's Detection Zone
Second Detector's Response
First Detector's Response
distance
time
time
6.1 m
( A)
( B)
on 1
effective vehicle
length
off 1 on 2 off 2
Vehicle Trajectory
on
off
on
off
TTr
TTf
OT1
OT2
Figure 5- 2 One vehicle passing over a dual loop detector
( A) the two detection zones and the vehicle trajectory as shown in the time space
plane. The height of the vehicle's trajectory reflects the non- zero vehicle length.
( B) The associated turn- on and turn- off transitions at each detector.
44
loops, as shown in Figure 5- 2B. These measurements are used to calculate: dual loop traversal
time via the rising edges, TT r , dual loop traversal time via the falling edges, TT f , total on- time at
the first loop, OT 1 , and total on- time at the second loop, OT 2 , as indicated in the figure.
Previously, these measurements are discarded after being used for vehicle reidentification. Now,
all of the vehicle transitions are retained after being extracted from the controller packets. It is
worth noting that occasionally a vehicle will change lanes over the dual loop detector, one of the
loop detectors will malfunction or a data packet is not received. All of these events will impact
subsequent analysis. Currently these unmatched transitions are discarded. This individual
vehicle data consists of:
• Station
• Lane ( 0- 9)
• Upstream loop on time
• Upstream loop off time
• Downstream loop on time
• Downstream loop off time
All times are in number of 1/ 60 second intervals since midnight; if a vehicle enters a dual loop
detector before midnight and exits after midnight, the entry time will be expressed as a negative
number to represent the time interval before midnight.
The rate of data generation by the BHL data processing system exceeds 4 Gigabytes per month.
This data must be removed from the data servers so that their local storage capacity is not
consumed by excessive amounts of data, but it must be stored for future analysis.
At the beginning of each calendar month, data is transferred from the data collection and data
processing computers to a desktop workstation. These data files are compressed, and the
compressed files are copied to CDR media. Duplicate copies are created so that data loss is less
likely. After duplicate data CDs have been produced for data from a given month, the original
copies of the data are removed from the servers so that there is sufficient storage space for new
data. A list of archived data appears below.
Raw, bitpacked detector data July 1999 – present
Sorted, bitpacked detector data July 1999 – present
Individual vehicle travel times July 1999 – present
30 second summary data May 2000 – present
5 minute summary data May 2000 – present
Individual vehicle data January 2002 - present
Daily summary images generated December 2001 - present
Monitor log data October 2001 - present
5.4 Task 7: Distribution of Loop Detector Data
Sharing the unique Berkeley Highway Lab data with other researchers allows others to
conduct additional traffic research beyond the scope of this project. Some Berkeley Highway
45
Lab data is publicly available via the BHL Web site; additional data is made available to other
researchers upon request, and with the understanding that Caltrans will be apprised of all data
sharing arrangements.
BHL data has been used by a number of researchers at several institutions. These include:
• Joy Dahlgren, Wei Lin, Carlos Daganzo, and Jorge Laval ( U. C. Berkeley) are using BHL
vehicle headway data for a project on traffic dynamics and traffic management strategies.
To offset some of the costs of BHL personnel time, Dr. Dahlgren has purchased hard disk
storage for the BHL servers which enables us to store and archive data more efficiently.
• Taewan Kim and Michael Zhang ( U. C. Davis) are using BHL data for modeling
microscopic traffic flows, with a focus on vehicle headways under different traffic
conditions. They use BHL detector event data to validate their models.
• Oliver Gao ( U. C. Davis), with Joy Dahlgren ( U. C. Berkeley), is studying individual
vehicle length distributions.
• Sue Ahn and Mike Cassidy ( U. C. Berkeley) are using 30 second data for a new project.
They’re also interested in individual vehicle data.
• Edgar Ergueta ( U. C. Berkeley), with Ben Coifman, is using BHL data to develop
improved vehicle travel time calculation algorithms.
• Joe Palen ( Caltrans), Dan Lyddy ( UC Berkeley) and Ben Coifman ( Ohio State) are
correlating loop and video data.
• Fabio Silva, Gen Giuliano and John Heidemann ( USC Information Sciences Institute) are
developing a deployable sensor net for vehicle traffic classification.
As long as the lab continues to operate with a scope similar to the current project, BHL data
available will be made available to other researchers on a case- by- case basis and with the
approval of Caltrans. The BHL research team will continue to evaluate with Caltrans the
importance of the project and announcing the availability of data sets.
46
6. BHL Web Site
As part of this project, the Berkeley Highway Laboratory Web site was reworked to more clearly
represent current operations and research. In addition to providing background information
about the laboratory, new diagnostic tools ( as described in Chapters 2 and 3) were incorporated
into the site and a data guide was developed to assist researchers who use data from the project.
The new BHL home page is shown in Figure 6- 1.
6.1 About the Berkeley Highway Laboratory
Site visitors can read a description of the BHL laboratory and the data collection
equipment. Previous research that provided the foundation for the current project is summarized.
The data collection system is described and illustrated in detail, and a link is provided to an off-site
page that describes the development of the vehicle reidentification algorithm that’s been
implemented in the lab’s real- time data processor.
6.2 Current Traffic Data
Current 30 second aggregate data is displayed on demand for each of the laboratory’s
eight stations. Users can select a station to view a Web page that shows, for each lane,
• Flow ( vehicles/ hour)
• % Occupancy
• Speed ( mph)
This data is continuously generated automatically by the system and is viewable any time. A
sample view of this data is shown in Figure 6- 3.
Travel times and other data related to pairs of adjacent stations are also available ( Figure
6- 4). For any such pair, users can view a Web page that shows, for each lane,
• Speed ( mph)
• Travel time ( seconds)
• Delay ( seconds; referenced to 55mph travel time)
• Density ( vehicles per mile)
These travel time pages also show when these values were last calculated for each lane.
6.3 Historical Traffic Data
Six varieties of historical performance charts can be generated from archived BHL data.
Five of these varieties show data in one travel direction from one station location for one
calendar day. The available measures are:
47
Figure 6- 1 BHL Web site home page
Site visitors are welcomed with general BHL information, research associations,
and navigation links to additional content on the site.
48
Figure 6- 2 About the Berkeley Highway Laboratory
49
Figure 6- 3 Current traffic data – 30s. aggregate data by station
Most- current 30 second aggregate data is presented for each lane at a given
station. Station 7 is shown in this example.
50
Figure 6- 4 Current traffic data – travel times
51
• Speed
• Flow
• Occupancy
• Density
• Density- Flow
A sample of one of these performance charts is shown in Figure 6- 5.
Figure 6- 6 shows a density contour map. The density contour map displays congestion
levels for one direction of travel at all 8 stations for a selected day.
6.4 System Monitoring Results
As part of Task 2, “ Automated Data System Diagnostics,” extensive system monitoring
features were added to the BHL system. Many of these features are accessible via the BHL Web
site, and are described in Chapter 3.
6.5 Detector Diagnostics Results
As part of Task 1, “ Automated Detector Diagnostics and Real- Time Data Validation,”
extensive detector diagnostic features were added to the BHL system. Many of these features are
accessible via the BHL Web site, and are described in Chapter 2.
6.6 Detector Data
Archived BHL data is made available to other researchers upon request. The redesigned
BHL Web site assists visitors with requesting, understanding, and processing detector data
( Figure 6- 7). A newly- created reference manual completely defines the format of each variety of
archived data file.
6.7 BHL- Related Research
The current Berkeley Highway Laboratory project is a continuation of previous work.
Objectives of the current project and reports from previous projects are available for download;
see Figure 6- 8.
52
Figure 6- 5 Historical traffic data – speed
This representative performance chart plots measured speed northbound at station
7 through the course of one day.
53
Figure 6- 6 Historical traffic data – density contour map
54
Figure 6- 7 Detector data
55
Figure 6- 8 Research projects
56
7. Conclusion
This final chapter in the report is divided into two major parts. The first part summarizes the
major accomplishments of this year’s project both in terms of immediate and longer- term
consequences. The second part describes future research directions with particular focus on next
year’s project.
7.1 Summary of Major Accomplishments
The major accomplishments of each of the eight tasks described in the previous five chapters
will be summarized for each chapter in the following paragraphs.
The first task was to undertake research to enhance the previously developed detector
diagnostics, to implement the enhanced diagnostics, to incorporate the results of the diagnostics
into the BHL Web site, and to make an assessment of the detector diagnostics and status of
detectors. This task was described in Chapter 2 of this report. A two- level, nine detector
diagnostic scheme has been developed including dynamic diagnostics based on speed and
vehicle composition. The scheme is now operational on a continuous basis, has been evaluated
and refined at frequent intervals, and incorporated into the BHL Web site for ready access of
results by team members and Caltrans representatives. Detector deficiencies have been
identified and as well as specific ways of refining diagnostics in the future.
The second task was to undertake research in order to develop a monitoring scheme for the entire
BHL detector system, to implement the monitoring scheme, to incorporate the results of the
monitoring scheme, and to make an assessment of the detector system. This task is described in
Chapter 3 of this report.
The third task was to undertake a comparative cost- effectiveness evaluation for the BHL- type
detector system and the standard District 04 detector system. The subtasks of this task included
the establishment of criteria in selecting a pilot freeway facility, the selection of the pilot freeway
facility with guidance from Caltrans, a quantitative comparison of costs, qualitative comparison
of benefits, and reporting of results in a cost- effective manner. This task is described in Chapter
4 of this report. Barring any unforeseen complications, the total hardware and development costs
to convert any or all of the TMS in District 4 to transmitting detector event data to the TMC
could be on the order of $ 300,000 and could provide conventional aggregate data of comparable
quality to what is provided by the existing monitoring system. Almost all of this cost is in one
time conversion costs. The incremental cost of collecting event data over conventional aggregate
data is very small, on the order of an additional $ 50 per station.
The remaining five tasks are integrated into Chapter 5 of this report because of their close
relationship. Task 4 was to maintain the data link to District 04, Task 5 was to maintain the
detector system, Task 6 was to generate and archive detector data, Task 7 was to distribute BHL
detector data to others, and Task 8 was to assemble the final report.
57
An additional chapter is included, Chapter 6, to describe the BHL Web site than has been
significantly improved and expanded. The Web site includes information about the BHL
detector system, provides access to current traffic data, provides access to historical traffic data,
reports on system monitoring results, reports on detector diagnostics results, provides for future
distribute of detector data, and gives highlights of BHL- related research.
7.2 Future Research Directions
The efforts on this current research project have resulted in the identification of future research
directions with particular focus on next year’s project. A proposal has been submitted based
upon the identified future research and approval is expected soon.
The proposed research builds upon previous research experience by the team members and
utilizes this unique microscopic detector system laboratory to move in new directions. The
research plan to accomplish the proposed research consists of seven tasks. Each task is briefly
described in the following seven paragraphs.
Comprehensive analysis of BHL detector data will be undertaken to further enhance and refine
the detector diagnostics; to identify lane associated traffic measurement patterns between lanes
for data substitution; and to develop overall performance measures. The BHL detector data will
be analyzed at both the microscopic and macroscopic level.
There are a number of issues to be addressed in this task dealing with further evaluation and
refinement of the currently implemented detector diagnostics. Three issues of greatest
importance are to refine existing diagnostics in terms of probabilities, sample size, and threshold
values; enhancing the dynamic adjustments of threshold values based on traffic flow conditions;
and consider adding other candidate diagnostics both at the microscopic and macroscopic level.
The third project task is to design, install, and test BHL detector system at CCIT. The Caltrans
state- wide test beds including the BHL detector system are being consolidated into one site at the
CCIT facilities. This will also provide the opportunity to modernize and upgrade the equipment
and software in the process.
The next task is to maintain and operate the current BHL detector system. During the beginning
of the project and then at CCIT after it becomes operational. It also includes archiving of BHL
data, facilitating greater use of the BHL data, and insuring that the BHL data continues to be sent
to Caltrans District 04.
Task five includes adapting the diagnostic system for stand- alone use and designing a portable
detector diagnostic tool. This task will move forward the production of a stand- alone testing
device that can be used by Caltrans personnel and installation contractors to verify and
troubleshoot the operation of loop detector stations.
A draft of the major portions of the final report will be prepared and discussed at the final
meeting with Caltrans representatives. Based on these discussions, the project report will be
finalized and submitted upon the completion of the project.
58
The final task of the project will be to hold quarterly meetings with Caltrans representatives to
report on accomplishments and near- term plans. Quarterly reports will be submitted to the
PATH reporting system describing accomplishments, problems, and anticipated future progress.
59
( References)
[ 1] Chen, L., and May, A. ( 1987). Traffic Detector Errors and Diagnostics Transportation
Research Record 1132 , TRB, Washington, DC, pp 82- 93.
[ 2] Coifman, B. ( 1999) Using Dual Loop Speed Traps to Identify Detector Errors,
Transportation Research Record no. 1683, Transportation Research Board, pp 47- 58.
[ 3] May, A., Coifman, B., Cayford, R., Merritt, G. ( 2002). Loop Detector Data Collection and
Travel Time Measurement in the Berkeley Highway Laboratory, PATH research report.
[ 4] Coifman, B., Dhoorjaty, S., and Lee, Z. ( 2003). Estimating Median Velocity Instead of Mean
Velocity at Single Loop Detectors, Transportation Research: Part C , vol 11, no 3- 4, pp 211- 222.
[ 5] Coifman, B. ( 2002). Estimating Travel Times and Vehicle Trajectories on Freeways Using
Dual Loop Detectors, Transportation Research: Part A , vol 36, no 4, pp. 351- 364.
[ 6] Coifman, B. and Cassidy, M. ( 2002). Vehicle Reidentification and Travel Time Measurement
on Congested Freeways, Transportation Research: Part A , vol 36, no 10, pp. 899- 917.
[ 7] Coifman, B. ( 2003) Identifying the Onset of Congestion Rapidly with Existing Traffic
Detectors, Transportation Research: Part A , vol 37, no 3, pp. 277- 291.
[ 8] Coifman, B., Lyddy, D., and Skabardonis, A., ( 2000). The Berkeley Highway Laboratory-
Building on the I- 880 Field Experiment, Proc. IEEE ITS Council Annual Meeting , pp 5- 10.
[ 9] Interview with Brian Simi, Caltrans District 3 Operations and Chair of the NTCIP Ramp
Meter Control ( RMC) working group.
[ 10] Interview with Sean Coughlin, Caltrans District 4 Operations, and Caltrans representative
on the NTCIP Ramp Meter Control ( RMC) working group.
[ 11] Caltrans, TMS Baseline Inventory, DRAFT: 4/ 11/ 01.
[ 12] Caltrans, Monitoring Station - Typical Estimate ( 6 lanes), 2/ 26/ 01
[ 13] Caltrans, TMS Baseline Inventory, DRAFT: 3/ 19/ 01.
[ 14] Skabardonis, A., Petty, K., Noeimi, H., Rydzewski, D. and Varaiya, P. ( 1996). I- 880 Field
Experiment: Data- Base Development and Incident Delay Estimation Procedures, Transportation
Research Record 1554 , TRB, pp 204- 212.
[ 15] Interview with Randall Cayford, University of California, Institute of Transportation
Studies, Programmer,.