SHRP 2 Reliability Project L02 Guide to Establishing Monitoring Programs for Travel Time Reliability PREPUBLICATION DRAFT • NOT EDITED © 2013 National Academy of Sciences. All rights reserved. ACKNOWLEDGMENT This work was sponsored by the Federal Highway Administration in cooperation with the American Association of State Highway and Transportation Officials. It was conducted in the second Strategic Highway Research Program, which is administered by the Transportation Research Board of the National Academies. NOTICE The project that is the subject of this document was a part of the second Strategic Highway Research Program, conducted by the Transportation Research Board with the approval of the Governing Board of the National Research Council. The members of the technical committee selected to monitor this project and to review this document were chosen for their special competencies and with regard for appropriate balance. The document was reviewed by the technical committee and accepted for publication according to procedures established and overseen by the Transportation Research Board and approved by the Governing Board of the National Research Council. The opinions and conclusions expressed or implied in this document are those of the researchers who performed the research. They are not necessarily those of the second Strategic Highway Research Program, the Transportation Research Board, the National Research Council, or the program sponsors. The information contained in this document was taken directly from the submission of the authors. This document has not been edited by the Transportation Research Board. Authors herein are responsible for the authenticity of their materials and for obtaining written permissions from publishers or persons who own the copyright to any previously published or copyrighted material used herein. The Transportation Research Board of the National Academies, the National Research Council, and the sponsors of the second Strategic Highway Research Program do not endorse products or manufacturers. Trade or manufacturers’ names appear herein solely because they are considered essential to the object of the report. The National Academy of Sciences is a private, nonprofit, self-perpetuating society of distinguished scholars engaged in scientific and engineering research, dedicated to the furtherance of science and technology and to their use for the general welfare. On the authority of the charter granted to it by Congress in 1863, the Academy has a mandate that requires it to advise the federal government on scientific and technical matters. Dr. Ralph J. Cicerone is president of the National Academy of Sciences. The National Academy of Engineering was established in 1964, under the charter of the National Academy of Sciences, as a parallel organization of outstanding engineers. It is autonomous in its administration and in the selection of its members, sharing with the National Academy of Sciences the responsibility for advising the federal government. The National Academy of Engineering also sponsors engineering programs aimed at meeting national needs, encourages education and research, and recognizes the superior achievements of engineers. Dr. Charles M. Vest is president of the National Academy of Engineering. The Institute of Medicine was established in 1970 by the National Academy of Sciences to secure the services of eminent members of appropriate professions in the examination of policy matters pertaining to the health of the public. The Institute acts under the responsibility given to the National Academy of Sciences by its congressional charter to be an adviser to the federal government and, upon its own initiative, to identify issues of medical care, research, and education. Dr. Harvey V. Fineberg is president of the Institute of Medicine. The National Research Council was organized by the National Academy of Sciences in 1916 to associate the broad community of science and technology with the Academy’s purposes of furthering knowledge and advising the federal government. Functioning in accordance with general policies determined by the Academy, the Council has become the principal operating agency of both the National Academy of Sciences and the National Academy of Engineering in providing services to the government, the public, and the scientific and engineering communities. The Council is administered jointly by both Academies and the Institute of Medicine. Dr. Ralph J. Cicerone and Dr. Charles M. Vest are chair and vice chair, respectively, of the National Research Council. The Transportation Research Board is one of six major divisions of the National Research Council. The mission of the Transportation Research Board is to provide leadership in transportation innovation and progress through research and information exchange, conducted within a setting that is objective, interdisciplinary, and multimodal. The Board’s varied activities annually engage about 7,000 engineers, scientists, and other transportation researchers and practitioners from the public and private sectors and academia, all of whom contribute their expertise in the public interest. The program is supported by state transportation departments, federal agencies including the component administrations of the U.S. Department of Transportation, and other organizations and individuals interested in the development of transportation. www.TRB.org www.national-academies.org Copy No. _____ SHRP 2 Project L02 Establishing Monitoring Programs for Travel Time Reliability Guidebook – Final Validated Prepared for: Strategic Highway Research Program 2 (SHRP 2) TRANSPORTATION RESEARCH BOARD NAS-NRC LIMITED USE DOCUMENT This document is furnished only for review by members of the SHRP 2 Technical Coordinating Committee and is regarded as fully privileged. Dissemination of information included herein must be approved by SHRP 2 Program officials. September 10, 2012 Institute for Transportation Research and Education In association with: Iteris/Berkeley Transportation Systems, Inc. Kittelson & Associates, Inc. National Institute of Statistical Sciences University of Utah Rensselaer Polytechnic Institute Joseph Schofer of Northwestern University Asad Khattak of Planitek Guidebook – Final Validated Draft SHRP 2 L02 Establishing Monitoring Programs for Travel Time Reliability TABLE OF CONTENTS LIST OF TABLES LIST OF FIGURES GLOSSARY OF TERMS AND ACRONYMS EXECUTIVE SUMMARY ....................................................................................................... ES-1 CHAPTER 1: INTRODUCTION ................................................................................................1-1 The Context within the Strategic Highway Research Program 2 Structure of the Guidebook How To Use This Guidebook What Is Travel Time Reliability? Supply-Side and Demand-Side Perspectives Trip-Making Concepts Probability Density Functions References 1-4 1-5 1-7 1-7 1-10 1-11 1-12 1-15 CHAPTER 2: DATA COLLECTION AND MANAGEMENT ...............................................2-1 Infrastructure-Based Sources Automated Vehicle Identification Sources Automated Vehicle Location Sources Private Sector-Based Sources Data Management for Recurring Conditions Data Management for Non-Recurring Events Summary References 2-3 2-5 2-8 2-9 2-10 2-12 2-15 2-15 CHAPTER 3: COMPUTATIONAL METHODS ......................................................................3-1 Network Concepts Trip-Making Concepts Operating Conditions and Regimes Imputation Segment Travel Time Calculations Route Travel Time Calculations Influencing Factor Analysis Summary References 3-2 3-4 3-6 3-8 3-14 3-29 3-37 3-40 3-40 ii Institute for Transportation Research and Education SHRP 2 L02 Guidebook – Final Validated Draft Establishing Monitoring Programs for Travel Time Reliability CHAPTER 4: APPLICATIONS .................................................................................................4-1 Case Studies San Diego, California Northern Virginia Sacramento–Lake Tahoe, California Atlanta, Georgia New York/New Jersey Berkeley Highway Lab Use Cases See What Factors Affect Reliability (AE1) Assess the Contributions of the Factors (AE2) View the Travel Time Reliability Performance of a Subarea (AE3) Assist Planning and Programming Decisions (AE4) Determine When a Transit Route is Unreliable (AP5) Be Alerted When the System has Become Unreliable (MM5) Summary 4-1 4-3 4-6 4-9 4-13 4-16 4-18 4-20 4-23 4-30 4-35 4-37 4-41 4-43 4-45 CHAPTER 5: SUMMARY ..........................................................................................................5-1 Step 1: Collect and Manage Traffic Data Step 2: Measure Travel Times Step 3: Characterize Step 4: Collect, Manage, and Impute Non-Recurring Event Data Step 5: Identify the Sources of Congestion and Unreliability Step 6: Understanding the Impact of the Sources of Unreliability Step 7: Make Decisions Conclusion 5-2 5-3 5-7 5-8 5-9 5-10 5-11 5-12 SUPPLEMENT A: MONITORING SYSTEM ARCHITECTURE ....................................... A-1 SUPPLEMENT B: METHODOLOGICAL DETAILS ........................................................... B-1 SUPPLEMENT C: CASE STUDIES Chapter C1: Introduction Chapter C2: San Diego, California Chapter C3: Northern Virginia Chapter C4: Sacramento–Lake Tahoe, California Chapter C5: Atlanta, Georgia Chapter C6: New York/New Jersey C1-1 C2-1 C3-1 C4-1 C5-1 C6-1 SUPPLEMENT D: USE CASE ANALYSES ............................................................................ D-1 Institute for Transportation Research and Education iii Guidebook – Final Validated Draft SHRP 2 L02 Establishing Monitoring Programs for Travel Time Reliability LIST OF TABLES Table 2-1: Example Database Table Relationship 2-11 Table 3-1: Illustration of Regimes 3-8 Table 3-2: Example of Measured Speeds by Lane, San Francisco Bay Area 3-16 Table 3-3: Example of an Incidence Matrix – percentage of vehicles having both a travel rate on the upstream segment ab in a particular range and a travel rate on the downstream segment bc in a particular range 3-32 Table 4-1: User Types and Their Classification 4-21 Table 4-2: Use Case Template 4-21 Table 4-3: Use Cases for the Travel Time Reliability Monitoring System 4-22 Table 4-4: See What Factors Affect Unreliability (AE1) 4-24 Table 4-5: Assess the Contributions of the Factors (AE2) 4-30 Table 4-6: Semi-Variances for Each Regime for Three Routes in San Diego 4-34 Table 4-7: Percentages for Semi-Variances for Each Regime for Three Routes in San Diego 4-34 Table 4-8: View the Travel Time Reliability Performance of a Subarea (AE3) 4-35 Table 4-9: Contribution by Regime to Total Semi-Variance for Three Routes in San Diego 4-36 Table 4-10: Assist Planning and Programming Decisions (AE4) 4-37 Table 4-11: Changes in Reliability over Time for a Hypothetical Route 4-38 Table 4-12: Determine When a Route is Unreliable (AP5) 4-41 Table 4-13: Hours of Unreliable Operation by Regime and Facility 4-42 Table 4-14: Percentage of Unreliable Operation by Regime and Facility 4-42 Table 4-15: Be Alerted When the System has Become Unreliable (MM5) 4-43 iv Institute for Transportation Research and Education SHRP 2 L02 Guidebook – Final Validated Draft Establishing Monitoring Programs for Travel Time Reliability LIST OF FIGURES Figure ES-1: Seven Major Sources (Factors) of Nonrecurrent Congestion ES-2 Figure ES-2: Information Flow in a TTRMS ES-3 Figure ES-3: Block Diagram for a Travel Time Reliability Monitoring System (TTRMS) ES-5 Figure ES-4: Illustration of Variation in Travel Times by Time of Day Across a Year with NonRecurrent Events Excluded ES-6 Figure ES-5: Illustration of Variation in Travel Times by Time of Day Across a Year with NonRecurrent Events Included ES-7 Figure ES-6: How Travel Rates Are Affected by Congestion and Non-Recurring Incidents ES-8 Figure 1-1: Five-Minute Average Travel Times on I-5 in San Diego 1-2 Figure 1-2: Information Flow in a TTRMS 1-2 Figure 1-3: Seven Major Sources (Factors) of Nonrecurrent Congestion 1-5 Figure 1-4: Reliability Monitoring System Overview 1-6 Figure 1-5: Concepts of Desired and Actual Times of Arrival 1-8 Figure 1-6: Disutility Function to Characterize Desired and Actual Times of Arrival 1-9 Figure 1-7: Example of Travel Time Histogram for Various Event Conditions 1-12 Figure 1-8: Example of Probability Density Functions for Various Event Conditions 1-13 Figure 1-9: Example of Cumulative Distribution Functions under Various Regimes (Operating Conditions) 1-14 Figure 2-1: Types of Data Collection Sources Figure 2-2: Types of Infrastructure-Based Data Collection Sources Figure 2-3: Types of Vehicle-Based Data Collection Sources 2-1 2-2 2-3 Figure 3-1: Illustration of Monuments 3-3 Figure 3-2: Illustration of Segments 3-4 Figure 3-3: Illustration of Routes 3-5 Figure 3-4: Illustration of Route Bundles 3-6 Figure 3-5: Imputation of Traffic Data 3-9 Figure 3-6: Imputation Routine Example 3-11 Figure 3-7: Super Segment Examples 3-14 Figure 3-8: Example of Five-Minute g-Factor Estimates at a Detector 3-16 Figure 3-9: Example Estimates of g-Factors at a Detector (I-880 North, Oakland, CA) 3-17 Figure 3-10: Assignment of Segments to Point Detectors 3-18 Figure 3-11: Example Bluetooth Responses for a Single Vehicle 3-19 Figure 3-12: Example Application of AVI Sensor Placement 3-20 Figure 3-13: Raw Observations, US-50, South Lake Tahoe, CA to Placerville, CA 3-21 Figure 3-14: Filtered Observations of Trip Times, Placerville to South Lake Tahoe 3-22 Figure 3-15: Examples of Bluetooth-Based Vehicle Travel Times 3-23 Figure 3-16: Example of Cumulative Density Functions of Bluetooth-Based Vehicle Travel Times 3-24 Institute for Transportation Research and Education v Guidebook – Final Validated Draft SHRP 2 L02 Establishing Monitoring Programs for Travel Time Reliability Figure 3-17: Daily Trends in Individual Vehicle Travel Times – I-5 Southbound 3-25 Figure 3-18: Daily Trends in Individual Vehicle Travel Times – I-5 Southbound (subset) 3-25 Figure 3-19: Example Illustrating Trends in the 5th and 75th Percentile Travel Times for Individual Vehicles 3-26 Figure 3-20: Example of Locations and Headings Reported by AVL-Equipped Vehicles Trips 3-27 Figure 3-21: Example of Map Matching Challenges for AVL Data 3-28 Figure 3-22: Example of Route Section Travel Times 3-30 Figure 3-23: Example of Distribution of Simulated versus Actual Travel Rates for a Route 3-33 Figure 3-24: Example of a Network Simulated Using the Point-Queue-Based Model 3-33 Figure 3-25: Example of Actual versus Simulated Travel Times using the Point-Queue based Model 3-34 Figure 3-26: Examples of Simple Median Method (FasTrak Data, San Francisco Bay Area, California) 3-36 Figure 3-27: Example of Cumulative Distribution Functions by Regime and Non-Recurrent Event Type 3-39 Figure 4-1: Case Study Locations 4-1 Figure 4-2: Study Area for San Diego Case Study 4-3 Figure 4-3: Study Area for Northern Virginia Case Study 4-7 Figure 4-4: Study Area for Sacramento–Lake Tahoe Case Study 4-10 Figure 4-5: Study Area for Atlanta Case Study 4-13 Figure 4-6: Study Area for New York/New Jersey Case Study 4-16 Figure 4-7: Study Area for Berkeley Highway Laboratory Data Investigations 4-19 Figure 4-8: Sub-area being examined for Use Case AE1 4-25 Figure 4-9: Five-Minute Average Weekday Travel Rates for Three Routes in San Diego 4-26 Figure 4-10: Five-Minute Average Weekday Travel Rates Plotted Against VMT/Hour for Three Routes in San Diego 4-27 Figure 4-11: Semi-Variances by Five-Minute Time Period for the Normal Condition for Three Routes in San Diego 4-29 Figure 4-12: CDFs by Regime for the Three Routes in San Diego 4-32 Figure 4-13: Subarea Aggregation Approaches 4-35 Figure 4-14: Using TR-CDFs to Analyze Performance Changes 4-39 Figure 4-15: Relative Importance of Different Conditions 4-40 Figure 4-16: Trends in Travel Time Percentiles and Their Standard Deviation 4-44 Figure 5-1: Generalized Process for Developing a Travel Time Reliability Monitoring System 5-1 Figure 5-2: The Role of Data 5-2 Figure 5-3: Measuring Travel Times 5-4 Figure 5-4: Characterizing the Observed Travel Times 5-7 Figure 5-5: The Role of Sources of Unreliability 5-8 Figure 5-6: Identifying Sources of Congestion 5-9 Figure 5-7: Understanding Recurrent and Nonrecurrent Causes of Congestion 5-11 vi Institute for Transportation Research and Education SHRP 2 L02 Guidebook – Final Validated Draft Establishing Monitoring Programs for Travel Time Reliability Figure 5-8: Making Decisions Institute for Transportation Research and Education 5-12 vii 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 GLOSSARY ACRONYMS APC ASOS AVI AVL AWOS CAD CDF CV ESS ETC GPS HAR ITS LCS LPR MAC PDF PeMS RFID SHRP2 TMC TT-CDF TT-PDF TTRMS VMT Automated Passenger Count Automated Surface Observing System Automated Vehicle Identification Automated Vehicle Location Automated Weather Observing System Computer Aided Dispatch Cumulative Density Function Connected Vehicle Environmental Sensor Station Electronic Toll Collection Global Positioning Satellite Highway Advisory Radio Intelligent Transportation System Lane Control Status License Plate Reader Media Access Control Probability Density Function Performance Measurement System Radio-Frequency Identification Strategic Highway Research Program 2 Transportation Management Center Travel Time Cumulative Density Function Travel Time Probability Density Function Travel Time Reliability Monitoring System Vehicle Miles Traveled 28 TERMS 29 30 31 32 33 34 35 36 37 38 39 40 41 42 Market: A set of users in combination with a route bundle Monument: A reference point used for travel time measurement Non-Recurring Event: An event that does not occur regularly during a typical time of day, including traffic incidents, work zones, weather, special events, traffic control devices, and fluctuations in demand. The effect of non-recurring events can be magnified by inadequate base capacity. Passage Time: A timestamp assigned to a vehicle when it passes a given monument Regime: The categories of conditions under which the segment, route, or network is operating at a given point in time (or from one time to another). It is effectively the “loading condition” on the system. Route: A sequence of segments GL-1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Route Bundle: A set of two or more routes Sample Space: The set of raw data that pertain to each context for which a probability density function is being developed, such as those that pertain to a regime (e.g., congested conditions) or to another logical grouping (e.g., 7:00-9:00 a.m.) Also known as an observation set, observation time frame, or sample frame. Segment: A path between two monuments Travel Rate: Travel time per unit distance Travel Time: The amount of time spent traveling over a given segment or route Trip Time: The door-to-door time for a trip Use Case: Description of a system’s behavior based on user needs User: People or package making a trip across the network GL-2 1 EXECUTIVE SUMMARY 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 This guidebook describes how to develop and use a Travel Time Reliability Monitoring System (TTRMS). It explains why such a system is useful, how it helps agencies do a better job of managing network performance, and what a traffic management center (TMC) team needs to do to put a TTRMS in place. The guidebook was prepared under Project L02 within the Strategic Highway Research Program 2 (SHRP 2) under the management of the Transportation Research Board. Travel time reliability is the absence of variability in the travel times. If a system is reliable, people can get to where they want to go, when they want to be there, all the time. If a freeway is reliable, for example, then its travel times are the same for the same condition, all year long. It is similar to a vehicle that always starts when the key is turned on. Of course, in reality no system or roadway is perfectly reliable, and unexpected events (e.g., incidents) sometimes significantly reduce the reliability of a system. This executive summary is organized into the following sections:  Structure of the Guidebook  Why Do We Need a Travel Time Reliability Monitoring System?  What Should a Travel Time Reliability Monitoring System Do?  How Should a Travel Time Reliability Monitoring System be Structured?  An Illustration  Implementation  Conclusion 22 STRUCTURE OF THE GUIDEBOOK 23 24 25 26 27 28 29 30 31 32 33 34 35 The guidebook is organized into the following major parts:  An Executive Summary (this document) that gives agency managers a description of what a TTRMS is, why it is valuable, and how it can be used. The document is intended to prepare such individuals for the input they will receive from their staff and help them make informed decisions about future actions.  A five-chapter guidebook that describes the process of measuring, characterizing, identifying, and understanding the effects of recurrent congestion and non-recurrent events that affect travel time reliability.  A series of four supplements that provide more detailed information on the functional specification of a monitoring system, methodological details, a series of case studies, and a series of use cases (applications) of the guidebook. The project also has a separate final report that documents the research that led to the guidebook. 36 WHY DO WE NEED A TRAVEL TIME RELIABILITY MONITORING SYSTEM? 37 38 39 40 Travel time reliability is effectively the absence of variation in travel times. The absence of reliability can be largely attributed to seven influencing factors that cause congestion and unreliable travel times (illustrated in Figure ES-1):  Traffic incidents, ES-1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26       Work zones, Weather, Special events, Traffic control devices, Fluctuations in demand, and Inadequate base capacity. Source: Strategic Highway Research Program 2 Figure ES-1: Seven Major Sources (Factors) of Nonrecurrent Congestion System operators also want to determine what actions they need to take to reduce variability and enhance reliability. System users, on the other hand, want to avoid variability. When making trips, they want to select routes that have reliable travel times, and they want to leave at the right moment so they can arrive on time or minimize the probability of being late. A TTRMS can help operating agencies, like those with Transportation Management Centers (TMCs), monitor the performance of their system, understand the impacts of the various influencing factors, provide credible information to the system users about what travel time reliability to expect, and decide what actions to take to help improve reliability. This is the reason why a TTRMS should be created. Most TMCs currently do not have these features or capabilities. Creating a TTRMS involves creating a new module that plugs into an existing TMC platform. The TTRMS relies on the TMC to gather the sensor data, manage the data processing and storage, and communicate the results of its findings to the outside world. The TTRMS focuses on using the incoming sensor data, along with supplemental information about the ES-2 1 2 3 4 5 6 7 influencing factors, and create a credible picture of how well the system is performing at the present time and in the past. The payoff is better reliability. The TTRMS will ensure that the TMC team knows what how reliability will suffer if certain events take place. It will let them understand the impacts of weather, incidents, special events, etc. It will also help the TMC team manage the network’s reliability—in real time—by providing up-to-date information about how the variability in segment and route travel times is either increasing or decreasing in response to actions taken. 8 WHAT SHOULD A TRAVEL TIME RELIABILITY MONITORING SYSTEM DO? 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 To fulfill its mission as a decision support tool, the TTRMS needs to execute four key steps as illustrated in the conceptual diagram of information flow shown in Figure ES-2. Figure ES-2: Information Flow in a TTRMS Firstly, the TTRMS needs to effectively measure travel times. This is a complex technical topic due to the variability of traveler behavior and the plethora of different measurement sensors. Correctly measuring travel times along a given route requires a great deal of systems development effort and statistical knowledge. This guidebook serves as a primer on how to measure travel times using available technologies and statistical techniques. Measuring an individual travel time is the foundational unit of analysis for reliability monitoring. Secondly, the TTRMS needs to clearly characterize the reliability of a given system. This is the process of taking a set of measured travel times and assembling them into a statistical model of the behavior of a given segment or route. The statistical paradigm outlined in this guidebook is that of using probability density functions (PDFs) and cumulative distribution functions (CDFs) to characterize the performance of a given segment or route, usually specific to a particular operating regime (a combination of congestion level and non-recurring event). This ES-3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 guidebook gives specific advice on the statistical decisions required to effectively characterize the travel times. Characterizing the reliability of a segment or route is fundamental to making good decisions about what to do to improve the performance of that segment or route. Thirdly, the TTRMS needs to identify the sources of unreliability. Once the reliability of a segment or route has been characterized, transportation managers need to understand what caused the unreliability (and how to “fix” it). This guidebook follows the causal list that FHWA uses to describe why congestion arises, breaking these sources into the seven major influencing factors described previously. It discusses how to pull in data for these influencing factors and effectively fuse them with the travel time data generated in previous steps. Identifying the travel times impacted by these sources of congestion is required preparation for understanding system reliability. Finally, the TTRMS needs to help operators understand the impact of these sources of unreliability on the system. This final step in turning raw data into actionable decisions requires both quantitative and qualitative methodologies: operators need clear visualizations of data, as well as quantifications. This dual approach supports both data discovery and final decisionmaking about a given route. Understanding reliability is the key to good decision-making about improving system reliability. Once in place, a TTRMS that accurately and consistently executes these four steps becomes a powerful tool for traffic management. It is a tool that decision makers can use to understand how much of their delay is due to unreliability, and how to mitigate that delay. For example, should a freeway operator deploy more service patrol vehicles (to clear incidents more quickly) or focus their efforts on coordinating special event traffic (to reduce delay from stadium access)? A reliability monitoring system, as outlined in this guidebook, can tell an operator which of these activities is worth the investment, and what the payoff will look like. Building this system will add a new, powerful, practical traffic management tool to the arsenal of system operators. 27 28 HOW SHOULD A TRAVEL TIME RELIABILITY MONITORING SYSTEM BE STRUCTURED? 29 30 31 32 33 34 35 36 37 38 39 40 41 42 The process described above is designed to be integrated within an existing traffic management system with a structure generalized in Figure ES-3. Inside the large box are the three major modules of the TTRMS: a data manager, a computation engine, and a report generator. The data manager assembles incoming information from traffic sensors and other systems, such as weather data feeds and incident reporting systems, and places them in a database that is ready for analysis as “cleaned data”. The computation engine works with the cleaned data to prepare “pictures” of the system’s reliability: when it is reliable, when it is not, to what extent, under what conditions, etc. In the figure this is illustrated by “regime TT-PDFs,” or travel time probability density functions organized by regimes (i.e., the congestion level and the type of non-recurring event, including none, like high congestion and an incident or low congestion and work zone activity). The report generator responds to inquiries from users (system managers or travelers) and uses the computation engine to analyze the data and provide information that can then be presented back to the inquirer or decision maker. ES-4 1 2 3 4 5 6 7 Each of these modules is discussed and described in the guidebook. In addition, case studies and use cases illustrate how these modules work together to produce answers to questions that managers would likely pose. The supplemental material provides further details about how each of the modules should work, together and separately. 8 AN ILLUSTRATION 9 10 11 12 13 14 15 16 17 18 19 20 21 Figure ES-3: Block Diagram for a Travel Time Reliability Monitoring System (TTRMS) As an illustration, Figure ES-4 shows the travel times for a specific trip on a freeway (Interstate 5 in San Diego, California) throughout a typical weekday, excluding any nonrecurrent events such as incidents, weather, unusual demand, or special events. Time of day is shown along the x-axis, and the travel time in minutes is shown on the y-axis. It is clear from this figure that the travel times on this roadway segment are not always the same; the system is unreliable, even without the influence of incidents, weather, etc. Not only does the travel time vary but the spread in the times varies, slightly during the a.m. peak but dramatically during the p.m. peak. At about midnight, the minimum and maximum are only 5 minutes different (50 minutes versus 55 minutes) but differ by 50 minutes during the weekday p.m. peak without the additional influence of non-recurring events (50 minutes versus 100 minutes). This is the effect of recurring congestion. ES-5 120 Travel Time (min) 100 80 60 40 20 0 0:00 1 2 3 4 5 6 7 8 9 10 11 12 6:00 12:00 Time of Day (hr:min) 18:00 0:00 Figure ES-4: Illustration of Variation in Travel Times by Time of Day Across a Year with NonRecurrent Events Excluded Figure ES-5 shows the same travel times, now with non-recurrent events included. It is clear that non-recurring events have an impact, with the spread between minimum and maximum times widening. A good example is the effect of adverse weather, especially during the peak period. Traffic incidents also have an effect on travel time reliability, as do special events and unusually high demand. The TTRMS helps indicate when, why, and by how much travel time will vary. ES-6 180 160 Travel Time (min) 140 120 100 80 60 40 20 0 0:00 6:00 No Events 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Incidents 12:00 Time of Day (hr:min) Demand 18:00 Special Events 0:00 Weather Figure ES-5: Illustration of Variation in Travel Times by Time of Day Across a Year with NonRecurrent Events Included Figure ES-6 shows an example from a different data source (Interstate 8 westbound in San Diego, California) of what to expect as an output from the TTRMS. The figure shows plots with the distribution of travel rates (seconds per mile) across a three-month period under two identified operating conditions (uncongested conditions and high recurrent congestion) and whether an incident is also present. The distributions for this example are shown in a cumulative fashion (as a CDF); the location of each line shows how many travel rates are that value or shorter. For example, when traffic incidents occur during heavy (recurrent) congestion, one half (50%) of the travel rates are up to 65 sec/mile. That is, 50% of the travel rates are this long or shorter/smaller. The 90th percentile travel rate is 100 seconds per mile. Or put another way, 9 out of every 10 vehicles is traveling at that rate or faster. The value comes from comparing one distribution with another. For example, analysts can compare the distribution for high recurrent congestion and traffic incidents with high recurrent congestion without incidents. Without incidents, 50% of the vehicles are traveling at approximately 55 sec/mi instead of 65 sec/mi—considerably faster. And at the 90th percentile, the difference is even more dramatic, being approximately 60 sec/mi versus 100 sec/mi. ES-7 1.0 Cumulative Probability 0.9 0.8 0.7 Normal Conditions, Uncongested 0.6 0.5 Normal Conditions, High Congestion 0.4 0.3 Incident Conditions, Uncongested 0.2 Incident Conditions, High Congestion 0.1 0.0 40 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 60 80 100 Travel Rate (sec/mi) 120 140 Figure ES-6: How Travel Rates Are Affected by Congestion and Non-Recurring Incidents The cumulative distribution function presented here as an output of the TTRMS are the technical means by which many useful outcomes can be reached. Some examples include the following:  Understanding the System: The TTRMS shows that the impact of incidents on travel rates is dramatic, particularly during periods when the facility is already congested due to normal traffic conditions (e.g., peak hour travel). This allows an agency to prioritize funding towards measuring and respond to the types of nonrecurrent events that most significantly affect that agency’s system.  Communicating to the Public: The TTRMS can be used to communicate travel times or ranges of travel times to the traveling public and to passenger and freight movers, both pre-trip and en-route. This allows the public to be informed and a partner in managing the demand on the system.  Measuring the Effects of Actions: The TTRMS can be used to measure the effect of actions taken to improve reliability. The mitigating actions would be intended to cause the travel times (or travel rates) during incidents to get much closer to those when there are no incidents. Moreover, after the mitigating actions were taken, the TTRMS would be able to show how reliability improved. The guidebook contains many examples of potential applications of the use of a TTRMS through a series of use cases. The use cases are organized around the various stakeholders that use or manage aspects of the surface transportation system, including the following:  Policy and Planning Support: Agency administrators and planners that have responsibility for and make capital investment decisions about the highway network.  Overall Highway System: Operators of the roadway system (supply), including its freeways, arterials, collectors, and local streets and drivers of private autos, trucks, and transit vehicles (demand). ES-8  1 2 3 4 5  Transit Sub-system: Operators of transit systems that operate on the highway network, primarily buses and light rail (supply) and riders (demand). Freight Sub-system: Freight service suppliers (supply) and shippers and receivers that make use of those services (demand). IMPLEMENTATION 6 7 8 9 10 11 12 13 14 15 16 17 Much of the work of developing a TTRMS can be carried out by a team that includes people with expertise in database management, statistics, traffic detection technology, and traffic engineering. Executive-level guidance to the implementation team should include the following: 18 CONCLUSION 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 In conclusion, a TTRMS will help an agency understand the reliability performance of their systems and monitor how reliability improves over time. It will help an agency answer a variety of key questions, including:          What is the desired geographical scope of the system? Are periodic reports (weekly, monthly, quarterly, or annual) sufficient, or does the system need to provide continuous real-time reporting capabilities? Is the reliability information primarily for the agency’s internal use, or is the intent to provide information to the public in a way that will influence travel decisions? How much detail is required? Is it sufficient to have a generalized comparison of reliability on different routes, or is it desirable to know about the reliability of individual trips on a specific highway segment? What is the extent of congestion within the system (in space and time)? What is the effect of non-recurring events (i.e., the seven sources of unreliability) on the operation of the system? How are freeways and arterials performing relative to performance targets set by the agency? Are capacity investments and other improvements necessary given the current distribution of travel times? Are operational improvement actions and capacity investments improving the travel times and their reliability? ES-9 1 CHAPTER 1 2 INTRODUCTION 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 This guidebook describes how to develop and use a Travel Time Reliability Monitoring System (TTRMS). It explains why such a system is useful, how it helps agencies do a better job of managing network performance, and what a traffic management center (TMC) team needs to do to put a TTRMS in place. Travel time reliability is the absence of variability in the travel times. If a system is reliable, people can get to where they want to go, when they want to be there, all the time. If a freeway is reliable, for example, then its travel times are the same for the same condition, all year long. It is similar to a vehicle that always starts when the key is turned on. Of course, in reality no system or roadway is perfectly reliable, and unexpected events sometimes significantly reduce the reliability of a system. These unexpected events are due to internal and external influencing factors like capacity reductions and traffic control devices (internal) and weather, incidents, special events, work zones, and demand (external). A TTRMS can help operating agencies, like TMCs, monitor the performance of their system, understand the impacts of the various influencing factors, provide credible information to the system users about what travel time reliability to expect, and decide what actions to take to help improve reliability. This is the reason why a TTRMS should be created. Most TMCs currently do not have these features or capabilities. Creating a TTRMS involves creating a new module that plugs into an existing TMC platform. The TTRMS relies on the TMC to gather the sensor data, manage the data processing and storage, and communicate the results of its findings to the outside world. The TTRMS focuses on using the incoming sensor data, along with supplemental information about the influencing factors, and create a credible picture of how well the system is performing at the present time and in the past. The payoff is better reliability. The TTRMS will ensure that the TMC team knows what how reliability will suffer if certain events take place. It will let them understand the impacts of weather, incidents, special events, etc. It will also help the TMC team manage the network’s reliability—in real time—by providing up-to-date information about how the variability in segment and route travel times is either increasing or decreasing in response to actions taken. It is clear that this variability exists. Figure 1-1 shows the various 5-minute travel times observed across 2011 for Interstate 5 in San Diego, California. There are 72,000 data points plotted in the figure. It is easy to see that during the p.m. peak, the travel times vary widely:  The variation is greater when congestion is higher, that is, when the demand-tocapacity ratio is high;  The variation is much lower off-peak, especially at night and early in the morning, when congestion is low; and  There were impacts not only from congestion (which is internal to the system) but from incidents, weather, special events, and unusually high demand. 1-1 180 160 Travel Time (min) 140 120 100 80 60 40 20 0 0:00 6:00 No Events 1 2 3 4 5 6 Incidents 12:00 Time of Day (hr:min) Demand 18:00 Special Events 0:00 Weather Figure 1-1: Five-Minute Average Travel Times on I-5 in San Diego To fulfill its mission as a decision support tool, the TTRMS needs to execute four key steps as illustrated in the conceptual diagram of information flow shown in Figure 1-2. 1-2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Figure 1-2: Information Flow in a TTRMS Firstly, the TTRMS needs to effectively measure travel times. This is a complex technical topic due to the variability of traveler behavior and the plethora of different measurement sensors. Correctly measuring travel times along a given route requires a great deal of systems development effort and statistical knowledge. This guidebook serves as a primer on how to measure travel times effectively using available technologies and statistical techniques. Measuring an individual travel time is the foundational unit of analysis for reliability monitoring. Secondly, the TTRMS needs to clearly characterize the reliability of a given system. This is the process of taking a set of measured travel times and assembling them into a statistical model of the behavior of a given segment or route. In this guidebook, regimes refer to the categories of conditions under which the segment, route, or network is operating at a given point in time (or from one time to another). The statistical paradigm outlined in this guidebook is that of using probability density functions (PDFs) to characterize the performance of a given segment or route, usually specific to a particular operating regime (a combination of congestion level and non-recurring event). This guidebook gives specific advice on the statistical decisions required to effectively characterize the travel times. Characterizing the reliability of a segment or route is fundamental to making good decisions about what to do to improve the performance of that segment or route. Thirdly, the TTRMS should identify the sources of unreliability. Once the reliability of a segment or route has been characterized, transportation managers need to understand what caused the unreliability (and how to “fix” it). This guidebook follows the causal list that FHWA uses to describe why congestion arises, breaking these sources into the seven major influencing factors described previously (two internal and five external). It discusses how to pull in data for these influencing factors and effectively fuse them with the travel time data generated in 1-3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 previous steps. Identifying the travel times impacted by these sources of congestion is required preparation for understanding system reliability. Finally, the TTRMS should help operators understand the impact of these sources of unreliability on the system. This final step in turning raw data into actionable decisions requires both quantitative and qualitative methodologies: operators need clear visualizations of data, as well as quantifications. This dual approach supports both data discovery and final decisionmaking about a given route. Understanding reliability is the key to good decision-making about improving system reliability. Once in place, a TTRMS that accurately and consistently executes these four steps becomes a powerful tool for traffic management. It is a tool that decision makers can use to understand how much of their delay is due to unreliability, and how to mitigate that delay. For example, should a freeway operator deploy more service patrol vehicles (to clear incidents more quickly) or focus their efforts on coordinating special event traffic (to reduce delay from stadium access)? A reliability monitoring system, as outlined in this guidebook, can tell an operator which of these activities is worth the investment, and what the payoff will look like. Building this system will add a new, powerful, practical traffic management tool to the arsenal of system operators. 18 THE CONTEXT WITHIN THE STRATEGIC HIGHWAY RESEARCH PROGRAM 2 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 Reliability is one of the four focus areas of the Strategic Highway Research Program (SHRP) 2, authorized by Congress in 2006. The purpose of the reliability focus area is to “reduce congestion and improve travel time reliability through incident management, response, and mitigation” (1). Four themes have been established under this focus area:     Theme 1: Data, Metrics, Analysis, and Decision Support Theme 2: Institutional Change, Human Behavior, and Resource Needs Theme 3: Incorporating Reliability into Planning, Programming, and Design Theme 4: Fostering Innovation to Improve Travel Time Reliability The project under which this guidebook has been prepared is SHRP2 Project L02, Establishing Monitoring Programs for Travel Time Reliability. The project supports the first of these themes by providing guidance to operating agencies about how they can put better measurement methods into practice and understand the relationship that travel time reliability has to the seven major sources of nonrecurrent congestion that have been identified (2):        Traffic incidents, Work zones, Weather, Special events, Traffic control devices, Fluctuations in demand, and Inadequate base capacity. 1-4 1 2 3 4 5 6 7 8 A key part of the delivery of travel time reliability to the traveling public is the presence of a travel time reliability monitoring system that can assist engineers, planners, managers, and policy makers in making sound traffic management decisions. 9 STRUCTURE OF THE GUIDEBOOK 10 11 12 13 Source: Strategic Highway Research Program 2 Figure 1-3: Seven Major Sources (Factors) of Nonrecurrent Congestion The guidebook follows the block diagram presented in Figure 1-4 for purposes of describing the TTRMS. Each module is shown as a box, while the inputs and outputs are shown as circles. “Other Systems” refers to systems that monitor the influencing factors. 1-5 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 Figure 1-4: Reliability Monitoring System Overview Five chapters are used to define and describe the TTRMS:  Chapter 1, Introduction, presents an overview of travel time reliability.  Chapter 2, Data Collection and Management, discusses the types and application of various types of sensors, the management of data from those sensors, and the integration of data from other systems that provide input on sources of unreliability (e.g., weather, incidents). This represents the left side of the figure in Figure 1-1 and includes traffic sensors, other systems, and the data manager.  Chapter 3, Computational Methods, discusses how probability density functions are derived from the variety of data sources. This represents the center part of the figure in Figure 1-1 and includes the process of generating travel time probability density functions that can be used to derive a variety of reports to users.  Chapter 4, Applications, presents a discussion of potential use cases for a travel time monitoring system and illustrates its use with a series of real-world case studies.  Chapter 5, Summary, illustrates the entire the analytical process of a TTRMS. The guidebook is supplemented by four documents that provide additional detail to support the development and application of travel time monitoring systems. These documents are as follows:  Supplement A: Monitoring System Architecture. This document presents examples of detail data structures for the organization of various data sources. This document provides supporting detail for Chapter 2 of this guidebook.  Supplement B: Methodological Details. This document presents detailed discussions of the analytical methods that can be used to calculate travel time reliability measures from a variety of input sources. This document provides supporting detail for Chapter 3 of this guidebook.  Supplement C: Case Studies. This document presents a series of detailed case studies that exercise various aspects of the guidebook, including system architecture, analysis of recurrent and nonrecurrent sources of congestion, and the 1-6 1 2 3 4 5 6 7 8  application of a variety of use cases. This document provides supporting detail for Chapter 4 of this guidebook. Supplement D: Use Case Demonstrations. This document illustrates the application of a variety of use cases for a travel time reliability monitoring system. This document provides supporting detail for Chapter 4 of this guidebook. HOW TO USE THIS GUIDEBOOK 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Agency staff should read this material with an eye toward understanding what a TTRMS can do and what features make the most sense for their own situation. For example, from which sources can an agency collect data? Which steps can an agency employ in processing data? What performance measures can an agency realistically calculate? How can information be presented to various end-users? As such, this document can be used as a starting point for an agency to review current practices, recent reliability research, and developing technologies with the aim of designing a system that meets its own needs. The use cases and case studies presented in Chapter 4 helped guide the preparation of the module descriptions. Use cases are a formal systems engineering construct that transforms user needs into short, descriptive narratives that describe a system’s behavior. Use cases are used to capture a system's behavioral requirements by detailing scenario-driven threads through the functional requirements. The collective use cases define the monitoring system by capturing its functionalities and applications for various users. Each use case defines the purpose for the analysis, the steps the user must take to obtain the desired data, the results of the steps, the spatial aggregation used, and the travel time reliability measures that can be reported. The measures listed in these use cases are only examples and represent possible ways that reliability information can be conveyed. Travel time monitoring increasingly incorporates a blend of infrastructure from the public and private sectors. As a result, some elements of travel time monitoring systems in current use have proprietary components. This guidebook is not intended to provide a bid-ready specification of all aspects of a travel time monitoring system, some aspects of which may be proprietary. Nevertheless, the reader will be able to better understand the functional specification of such a system, defined by the required inputs and outputs of such a system. 33 WHAT IS TRAVEL TIME RELIABILITY? 34 35 36 37 38 39 40 41 42 43 This section provides a slightly more technical description of travel time reliability. While no consensus yet exists, Elefteriadou and Ciu (3) provide a starting basis in their study of travel time reliability definitions. As they discern, Ebeling (4) provides a useful basic idea, defining reliability as “the probability that a component or system will perform a required function for a given period of time when used under stated operating conditions. It is the probability of a non-failure over time.” It is slightly different from the idea of consistency, which has to do with the absence of variability. Brought into the highway network context, the system is reliable (formally speaking) if each traveler or shipper experiences actual times of arrival (ATA) which match desired times of arrival (DTA) within some window, as shown in Figure 1-5. In some cases the ATA and DTA 1-7 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 are extremely important; in other cases they are not, depending on trip constraints and penalty at the destination. For example, a trip to catch a plane is more constrained than a trip to the store. If the ATA lies outside the DTA window, especially if the ATA is after the DTA, a reliable trip was not completed. Hence, the transportation system is reliable, technically speaking, if the ATAs all lie within their DTA window. Otherwise, the system has “failed”. As Elefteriadou and Ciu (3) point out, such a definition of reliability becomes well defined. In a more general sense, the reliability of the system can be measured using utility theory, as described for example by Hansson (5). Utility (of the trip) is maximized if the ATA is inside the DTA window. Conversely, disutility is greater if the ATA lies outside the DTA window; and the aggregate disutility for all trips among all users is the “societal cost” of the system’s unreliability. The function that evaluates the disutility may be symmetric or asymmetric depending on the situation, as shown in Figure 1-6. Truckers incur significant penalties if they are either late or early in delivering shipments to the receivers. Individual travelers can be late for appointments or miss the opportunity to insert additional tasks like stopping for coffee or sleeping later if they are early. Figure 1-5: Concepts of Desired and Actual Times of Arrival 1-8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Figure 1-6: Disutility Function to Characterize Desired and Actual Times of Arrival If it were now possible, today, to observe all the trips, with the DTA windows being known, then the reliability of a given transportation system could actually be assessed. One could compute the percent of ATAs that fall within their DTA windows. This would be a useful metric both for the entities making the trips as well as the organizations providing the service (e.g., the TMC or transit system operator). The aggregate disutility could also be computed by summing the disutility values for each trip. Obviously, this world does not presently exist. What can be observed today, at least in part, are travel times on segments and routes in the network. For example, some TMCs can monitor probes, vehicles equipped with tags in areas where toll roads exist, and others can generate speed distributions at specific point locations in the network where sensors (speed traps) are installed. As a result, the TMC can establish desired travel times (DTT) or, better yet, desired travel rates (DTR) in seconds per mile so that the length of the facilities does not interfere, with performance levels to be achieved on the segments and routes, consistent with Ebeling (4). These DTRs can be dependent upon the regime under which the system is operating (combination of the influencing factors) and they can be adjusted over time as the network conditions change – demand grows and/or improvements are made. If single value measures seem easiest to master or communicate, the median travel rate is a good choice. If more complex and powerful tools are desired, travel rate probability density functions (TR-PDFs) are a good choice. Research conducted for the development of this guidebook found that in general, travel times do not follow a normal (Gaussian or bell-shaped) statistical distribution. As a result the median value (half above and half below) is generally a better measure of central tendency than the more familiar average (mean) value. Similarly, the semi-variance was found to be a better measure of variation than the standard deviation. A segment or route is then performing reliably if its actual travel rate (ATR) lies within the acceptable DTR window given the regime under which the segment or route is operating. The TMC team can monitor the number of segments or routes whose ATR lies within the DTR window; they can see how that number varies based on the network, segment, or route operating conditions (e.g., an incident during high congestion); and actions can be identified to increase the number of segments or routes whose ATR is within its DTR window. 1-9 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 This paradigm can also be extended to the system users. Trips can be considered successful if their actual travel rate (ATR) falls within an allowable DTR window based on the conditions under which the trip was made. Reliability can be measured by the percentage of trips whose ATR fall within the allowable DTR window. By extension, the aggregate disutility experienced by the travelers or shippers can be assessed, in principle, using disutility functions which compare the ATRs one-at-a-time with their corresponding DTRs and then sums the results. Service providers want to see if different ways to operate the system would be likely to produce better alignment between the ATRs and the DTRs (or if capacity investments are needed). Naturally, this decision making is aimed at variability reduction and shifts in the median values either lower or higher so that the requisite confidence interval objectives are met given the DTT windows. The decision making by the TMC team is similar to the mean-variance tradeoff analyses so prevalent in financial planning (see, for example, Maginn et al. (6)). In this instance, the tradeoff is between minimizing the median travel times, as in building new network links or adding capacity to reduce the median travel rates, versus taking actions like improving incident response or managing the impacts of weather better so that the variation in the travel rates is reduced (getting more of the ATRs within their DTR windows). 19 SUPPLY-SIDE AND DEMAND-SIDE PERSPECTIVES 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 Without overly stressing the thought, supply-side and demand-side ideas do have a bearing on travel time reliability. The supply side focuses on the TMC team and its interest in managing the segment, route, and network-level reliability so that performance goals are met. Most likely, these goals are predicated on simple metrics like the median travel rate, rather than the distribution of individual vehicle travel times. In addition, consistency across time (in a longitudinal sense) is the primary concern: how does the team make sure that every a.m. peak has an OK reliability performance? The demand side focuses on the individual travelers and the travel times they experience in making trips. Travelers’ decisions regarding modes, routes and departure times are associated with their own socio-demographics and the context in which they travel. Observations of individual vehicle (trip) travel times are important, and the travel time density functions of interest pertain to travel times experienced by individual travelers at specific points in time. That means the reported percentiles of those travel times (e.g., the 15th, 50th, and 85th percentiles) pertain to the travel times for those travelers. The important thought to carry away from this discussion has to do with making sure the context of the analysis is understood. Two analysts could think they are talking about the same reliability ideas, but in fact, the one is focused on the reliability of median travel times for the same five-minute time periods across a year—the duty cycle for the network—while the other is focused on the travel times experienced by individual vehicles in those same five-minute time periods across the year, or for a single five-minute time period (or an hour) for a given network on the same day, which is more of a cross-sectional data analysis thought. Neither analyst has the “right” or “wrong” perspective; both are very valuable. However, before they go too far in their discussion, they need to make sure they are both thinking about the problem in the same way, or that they understand how their perspectives are different and relate to one another. 1-10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 TRIP-MAKING CONCEPTS Several trip-making concepts are important in understanding the material presented in this guidebook. The first and most important concept is that trips made by persons and packages are the fundamental events on which travel time reliability is focused. Personal travel time reliability has to do with individual person trips, and freight travel time reliability has to do with individual package shipments. The second concept is that travel times and trip times are different. A trip refers to an origin, a destination, and implicitly a trip purpose. Trips can be chained trips involving intermediate stops, and thus trip times can be different from travel times. Trip times are the endto-end times involved—from origin to destination—and allow for intermediate stops and sidetrips. Travel times have such extra times removed and refer to the amount of time spent traveling. However, this distinction also pertains to observations of times for segments and routes. The trip time is the elapsed time between when one sensor identified a vehicle and a second sensor at some other location identified the same vehicle at a later time. Trip times can be travel times, but not necessarily. The trip time could include stops and/or detours, since the specific route of the vehicle between the two sensors might not be known. Travel time refers to the actual driving time between the sensors. Trip times need to be filtered in order to obtain accurate travel times. The third concept is that of a travel rate. This is travel time per unit distance, as in minutes per mile. While travel times help travelers understand how long it will take them to accomplish their trips—and help system managers determine what travel times to display on variable message signs, as an example—travel rates help system managers compare the performance of one segment with another so that strategies can be developed for making capital investments that help to improve the performance of the segments and the network as a whole. Travel rate probability density functions (PDFs) are distinguished from travel time PDFs by notation (TR-PDFs versus TT-PDFs). The fourth concept—an acceptance of the current technological frontier—is that individual person and package trip and travel times are presently difficult to observe. The best options presently available are automatic vehicle identification (AVI) and automatic vehicle location (AVL) based sensors. When those technologies become more prevalent, it will be easier to collect data on individual trips. The final concept is that it is acceptable to use aggregate measures as surrogates for the more detailed picture of individual trips. The aggregates are derived from the more detailed information (e.g., as in the average speeds provided by single-loop and double-loop detectors). Also, single-occupant vehicles are a significant portion of the traffic stream, especially during congested conditions, so insights about individual person trips can be seen in the vehicle data. The main point is that travel time reliability and the ideas about it presented in this document are intended to address questions about individual person and package trips, even though surrogate data are used. This means the methodology is designed to provide insights about the travel time reliability that might be experienced by persons and packages by extension of the insights derived from analyses of more aggregate measures. 1-11 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 PROBABILITY DENSITY FUNCTIONS Much of the material presented in this guidebook emphasizes the creation and analysis of probability density functions (PDFs) to describe the distribution of travel times and travel rates and to compare the performance of one facility with another or one operating condition with another. These distributions are often presented three ways. The first is as a histogram, where bar heights are used to represent the relative frequency with which specific conditions pertain. Figure 1-7 shows a histogram of travel times for Interstate 8 in San Diego during the a.m. peak for various operating conditions: when everything was normal, when the system was being affected by an incident, and when the system was being affected by weather. No special events were observed in the selected data set. Figure 1-7: Example of Travel Time Histogram for Various Event Conditions The second way in which these distributions are presented is via a probability density function (PDF). Figure 1-8 shows the corresponding PDFs for the three conditions. The PDF is a 1-12 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 density function that is based on the values in the histograms. In the PDF, as in the histograms, one can clearly see that some travel times are more common than others, and that the distribution of the travel times is different for the various operating conditions. Note that these histograms of San Diego data do not follow the familiar bell-shaped curve. The data has a significant “skew” even after it has been categorized. Figure 1-8: Example of Probability Density Functions for Various Event Conditions The third way in which these distributions are presented is in a cumulative density function (CDF). The CDF is based on the PDF in that the value shown in the CDF at any point in the graph is the integral of the PDF up to that point (i.e., the area enclosed within the PDF above the horizontal axis. A property of the PDF is that its area sums to 1.0 which means the CDF ultimately rises to a maximum of 1.0. Figure 1-9 shows the CDFs for the various regimes associated with the performance of a different facility in San Diego (Interstate 5, the same facility illustrated previously in Figure 1-1). As with the PDF, one can clearly see differences in the distribution of the travel rates (as compared to times) and that the distribution of rates for some regimes is much different than for others. It is through the use of these tools—the histogram, PDF, and CDF—that the case studies and use cases reach conclusions about the influence of various factors on the travel times and travel rates. Related to these thoughts about distributions and portraying them, the distributions can be, and often are, multimodal (in a statistical sense, meaning more than one point at which the 1-13 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 probability density function reaches a maximum). This is because the data may reflect more than one operating condition or regime across the span of time being studied or the users may have experienced different treatments during the analysis timeframe. An illustration of the former arises when the average travel times for a given 5-minute time slice are studied across a year. It is likely that different operating conditions existed on different days (because of weather and incidents let alone different demand levels), so multimodality should be expected. An illustration of the latter is when travelers do not all experience the same control treatment. For arterial networks, this could arise when some users are able to progress between traffic signals without stopping while others are not. For freeway networks, it can be because some vehicles are delayed by ramp metering controls while others are not; or when some vehicles experience delays from paying tolls (e.g., cash) while others do not (e.g., toll tags). Figure 1-9: Example of Cumulative Distribution Functions under Various Regimes (Operating Conditions) Since the word “mode” is used in other ways in transportation, the word regime is used instead of mode to describe these various operating conditions (or sub-conditions). Moreover, common traffic engineering names are used to describe these modes like “congested”, “uncongested”, “transition”, “incident”, “weather”, etc. The regimes help enhance the quality of the PDFs. It keeps them from being noisy, and it helps maximize the incremental value derived from the data acquired every day. The last concept—and an important one—is that all the reliability metrics of interest can be derived from these probability density functions (PDFs). The PDFs completely describe the travel times or travel rates (travel times per unit distance). Hence, the typical metrics of interest for characterizing reliability—planning index, buffer index, average, median, 95th percentile, or others—can be computed based on the PDFs. As a result, these PDFs, supplemented by ancillary data about the environment that does (or will exist) in the timeframe of the analysis (e.g., weather, incidents), represent sufficient information to answer the questions about measuring reliability. 1-14 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 REFERENCES 1. Transportation Research Board. Providing Reliable Travel Times on the Highway System. Reliability Focus Area Overview, Strategic Highway Research Program 2. June 17, 2009. http://onlinepubs.trb.org/onlinepubs/shrp2/RRPJune2009.pdf. Accessed September 2, 2012. 2. Cambridge Systematics, Inc., and Texas Transportation Institute. Traffic Congestion and Reliability: Trends and Advanced Strategies for Congestion Mitigation. Federal Highway Administration, September 2005. 3. Elefteriadou, L., and X. Ciu, “Review of Definitions of Travel Time Reliability,” Proceedings, 86th Annual Meeting of the Transportation Research Board, Transportation Research Board of the National Academies, Washington, D.C., 2007. 4. Ebeling, C. E. Introduction to Reliability and Maintainability Engineering. McGraw-Hill, 1997. 5. Hansson, S.O. Decision Theory: A Brief Introduction, Department of Philosophy and the History of Technology. Royal Institute of Technology, Stockholm, Sweden, 2005. 6. Maginn, J. L., D. L. Tuttle, D. W. McLeavey, and J. E. Pinto. Managing Investment Portfolios: A Dynamic Process. CFA Institute Investment Series, John Wiley & Sons, 3rd Edition, 2007. 1-15 1 CHAPTER 2 2 DATA COLLECTION AND MANAGEMENT 3 4 5 6 7 8 9 10 11 12 13 14 As a first step in reliability monitoring data collection, agencies need to thoroughly evaluate the existing data sources in their region and determine how they can be leveraged to support travel time computations. Following this step, agencies can take appropriate measures to determine how these sources can be integrated into the reliability monitoring system and identify where existing infrastructure should be supplemented with additional sensors or data sources. This section describes the potential sources for traffic data that can support the computation of route-level travel times and the potential sources of non-traffic data related to the sources of congestion. Figure 2-1 summarizes the data flow from various data sources into route-level travel time PDFs. This chapter discusses the lower portions of the figure, namely the traffic data sources and data types. The processing steps for converting the various data sources into routelevel travel time PDFs is presented in Chapter 3. 15 16 17 18 19 20 21 22 23 24 25 Figure 2-1: Types of Data Collection Sources As indicated in Figure 2-1, there are two broad categories of traffic data sources— infrastructure-based sources (devices mounted along the roadside) and vehicle-based sources— and these can be further separated into four broad categories of traffic data sources: 1. Infrastructure-based detectors that can sense volume, occupancy and other measures, but not speeds. 2. Infrastructure-based detectors that can sense speeds as well as other measures. 3. Automated vehicle identification (AVI) systems. 4. Automated vehicle location (AVL) systems. 2-1 1 2 3 4 5 6 7 8 9 10 11 Public agencies typically own and operate the infrastructure-based detectors and the AVI systems (used for tolls) while private, third-party sources often own and operate the AVL systems (although transit agencies are increasingly using AVL systems). This chapter outlines the differences in capabilities between these traffic data collection types and discusses the benefits and drawbacks of available technologies. Figure 2-2 and Figure 2-3 respectively show the categories and types of infrastructure-based and vehicle-based sensors described in this chapter. Figure 2-2: Types of Infrastructure-Based Data Collection Sources 2-2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Figure 2-3: Types of Vehicle-Based Data Collection Sources INFRASTRUCTURE-BASED SOURCES Infrastructure-based detectors, which include loop and radar detectors, are already a common component of traffic management systems in many regions. Some can measure vehicle speeds directly while others use post-processing algorithms to estimate speeds based on counts and occupancy. The ones that can directly measure speeds are more valuable. These sensors have a limited ability to monitor travel time reliability. While very prevalent, the drawback of these technologies is that they only provide data values at one fixed location along the roadway. As discussed in the framework section, this means that they can only report spot speeds. Consequently, they cannot directly inform on an individual vehicle’s route or time of travel between two points. As a result, the data they transmit requires some processing and extrapolation before travel times can be calculated. This also means that the accuracy of the travel time measures they produce is a function of how frequently detectors are spaced along the roadway. If existing deployments have detectors spaced at a frequency of one-half mile or less, they are suggested for inclusion in a reliability monitoring system. If detectors are placed less frequently on key routes, agencies may want to consider either installing more detectors or supplementing the existing detection with AVI sensors. Data from infrastructure-based sources needs to be reviewed for quality before calculating travel time reliability metrics. An example of this is presented in Chapter 4 in the Northern Virginia case study, where a process is illustrated for identifying detectors that are stuck or not collecting data for inductive loops and radar-based sensors. The Northern Virginia case study also describes challenges and mitigations for integrating the data feed from infrastructure-based detectors with a reliability monitoring system. 2-3 1 2 The following types of technologies are considered infrastructure-based sources. Loop Detectors 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Loop detectors are located in-pavement on many roadway facilities. They have historically been the most common traffic monitoring tool due to their relatively low installation cost and high performance. Coverage, however, varies greatly among cities and states. In many urban locations, they are common on freeway facilities. Many arterials also use loop detectors to control actuated and adaptive traffic signals. However, it should be noted that loop detectors used in traffic-responsive signal systems are usually not well-adapted to providing the data required to support reliability monitoring. Firstly, due to memory constraints in the traffic signal controller, data are usually not collected for each individual lane and are usually discarded rather than being sent to a control center for archiving and analysis. Even in locations where data are sent to a control center, they are usually aggregated up to levels that are too high (for example, hourly flow and occupancy values) to enable accurate travel time calculations. However, in some cases it will be possible for agencies to modify the existing signal system sensors to collect additional data and transmit them to a centralized location to support reliability monitoring. Loop detectors typically measure traffic volumes and occupancies and send data to a centralized location every 20 to 60 seconds. From these data, spot speeds can be calculated with a reasonable accuracy, at least in freeway applications, and can be used to extrapolate travel times. Loop detectors in a dual configuration can directly report speed values. Loop detectors have two significant drawbacks: their intrusive installation, and their significant maintenance requirements stemming from their vulnerability to damage or destruction. 22 Wireless Magnetometer Detectors 23 24 25 26 27 28 29 30 31 32 33 34 Like loop detectors, wireless magnetometer detectors are located in the roadway surface. However, wireless magnetometer detectors can be installed simply by drilling a hole into the pavement, eliminating the need for cutting pavement during installation and reducing maintenance requirements. These sensors use radio signals to communicate with access points located on the roadside, usually on poles, preventing the need to hardwire a detector to a controller cabinet. Like loop detectors, they report volume and occupancy data with a granularity that depends on the sensor’s setting. Sensors in a dual configuration can also directly report speed values. The data accuracy of wireless magnetometer detectors is similar to that of inductive loops (1). As such, where agencies would like to install additional in-road infrastructure detectors, wireless magnetometer sensors are a good alternative to loop detectors. Recent developments have also adapted some wireless magnetometer detectors to re-identify vehicles at a second detector, giving them AVI capabilities that are described later in this section. 35 Video Image Processors 36 37 38 39 40 41 Many agencies have begun installing video image processors, especially on arterial facilities, as an alternative for loop detection. Video image processing can retrieve volume, occupancy, and speed data from cameras on the roadway. This technology usually requires users to manually set up detection zones on a computer that are in the field-of-view of each camera, meaning that it is important that the cameras not be moved and the detection zones be set up correctly. Some specialized systems can also re-identify vehicles detected at two separate 2-4 1 2 3 4 5 cameras (2), giving them AVI capabilities discussed later in this section. This technology could be a viable method for travel time reliability monitoring where agencies already have video cameras installed. Video-based detection generally works best in locations with relatively mild weather, as they are sensitive to challenging weather conditions such as snow, fog, or temperature change. 6 Radar Detectors 7 8 9 10 11 To overcome the intrusive installation and maintenance of loop detectors, many regions have deployed microwave radar detectors, which are placed overhead or roadside and measure volume and speed data. One drawback to radar detectors is that they can lose their speed calibrations. Radar detectors are a viable option for agencies that want to increase the frequency of data collection infrastructure along a roadway without installing additional loop detectors. 12 Other Infrastructure-Based Sources 13 14 15 16 17 There are a number of additional overhead vehicle detection technologies that have capabilities similar to microwave radar detectors. These can be considered on a site-specific basis or used for travel time reliability monitoring where they have already been deployed. These technologies include passive infrared sensors, ultrasonic sensors, passive acoustic array sensors, and combinations thereof. (2) 18 AUTOMATED VEHICLE IDENTIFICATION SOURCES 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Automated Vehicle Identification (AVI) data collection sources, which include Bluetooth readers and License Plate Readers, detect a passing vehicle at one sensor, then re-identify the vehicle at a second sensor, allowing the vehicle’s trip time between two points to be directly computed. The drawback of AVI technologies is that while they provide the trip time between two points, they cannot inform on the route taken by individual vehicles, or whether the trip included any stops. Since there are often multiple ways to travel between two points, especially in urban areas, and since the travel time without stops is the value of interest in reliability calculations, processing and filtering is required to ensure that reliability computations are based on representative travel times for a given route. Techniques to perform this data processing are described in Chapter 3, and an example is illustrated in the Sacramento/Lake Tahoe case study in Chapter 4. Inaccuracies can also be reduced by deploying sensor readers at frequent intervals, to reduce the likelihood that a vehicle took a different route than the one assumed in the computation. Supplement B provides guidance about sensor spacing and sampling. The following technologies are sources for AVI trip time data. 33 BluetoothTM 34 35 36 37 38 39 40 BluetoothTM receiver technology has only recently been applied to traffic data collection, but appears promising for measuring trip times, especially on arterials. In the context of traffic, Bluetooth detectors record the public Media Access Control (MAC) address of a driver’s mobile phone or other consumer electronic device as the vehicle passes a point. This recorded ID number (or a curtailed version of it, to reduce privacy concerns) can then be matched as the vehicle passes subsequent detectors, allowing travel times between points to be calculated. Some vendors are also developing Wi-Fi detectors based on similar principles. 2-5 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 This technology is advantageous in that it is accurate, low-cost, and portable. A drawback, however, is that currently only a small percentage of drivers have Bluetooth-enabled devices in their vehicles; estimates range from 5 percent in the Washington D.C. metropolitan area to 1 percent outside of Indianapolis (3,4). Still, it can be assumed that these percentages will grow as commercial Bluetooth applications, particularly smart phones, become more prevalent, making Bluetooth an important data collection alternative for future projects. There are a few issues with Bluetooth measurements that need to be accounted for in the data filtration process. Firstly, Bluetooth readers frequently record the same wireless network ID more than once as a vehicle passes, especially when vehicles are traveling slowly. These duplicate addresses have to be removed to avoid counting a vehicle’s travel time more than once. Secondly, Bluetooth readers have a wide detection range that could collect travel times that do not reflect actual conditions. For example, a Bluetooth sensor station on a freeway might detect a vehicle that is in a queue on an entrance ramp, thus generating a travel time that is not representative of mainline freeway traffic flow. These unrepresentative trip times have to be filtered out during data processing. Additionally, on arterial streets, Bluetooth readers report trip times from non-vehicular modes like walking or cycling; these times have to be removed in the data cleaning process. 18 License Plate Readers 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 License plate readers (LPR) employ cameras that capture a digital image of a vehicle’s license plate and use Optical Character Recognition (OCR) to read the plate number. While primarily used for toll enforcement, LPR can also be used to calculate trip times for vehicles that pass by two or more cameras. The advantage of LPR is that it can collect trip time samples from vehicles without requiring the presence of any specific device within the vehicle. This method, however, is not well-suited for data collection on high-speed freeways. Additionally, plate matching is not always accurate, especially during adverse weather conditions (5). The equipment needed is also costly, and there are privacy concerns that come with tracking a vehicle by its license plate number. In a travel time context, LPR has been used by the Florida Department of Transportation to distribute travel times to Changeable Message Signs in various Florida cities, as well as on the Arizona State Route 68 Work Zone Project near the Hoover Dam. (6) The FHWA Travel Time Data Collection Handbook includes the following guidelines for using LPR (5):  Place cameras at mid-route checkpoints such as major interchanges, intersections, jurisdictional boundaries, and transition points between different roadway crosssections or land uses with the following spacing (which can vary depending on the roadway network and the desired detail of study): o Freeways/Expressways, high access frequency: 1 to 3 miles o Freeways/Expressways, low access frequency: 3 to 5 miles o Arterial Streets, high cross-street frequency: 0.5 to 1 miles o Arterial Streets, low cross-street frequency: 1 to 2 miles  50 license plate matches is the target sample size for a given roadway segment and time period to accurately represent travel time variability. It should be noted that the percentage of successful matches is about 5 percent to 20 percent in a given period. 2-6 1 2 3 Due to LPR’s accuracy issues and high cost, it is recommended that only those locations that have already installed LPR infrastructure use it as a primary method of data collection for reliability monitoring. 4 Radio-Frequency Identification 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 Radio-Frequency Identification (RFID) technology is employed in electronic toll collection (ETC) and can be used to re-identify vehicles for travel time purposes. RFID is embedded in toll-tags such as E-ZPass on the East Coast and FasTrak in the San Francisco Bay Area. More than 20 states currently have locations that use RFID toll tags, including some that have collected travel time data from their systems, including the San Francisco Bay Area, New York/New Jersey, Houston, and Orlando (7,8). The iFlorida toll tag travel time project found that toll tag penetration is high in urban areas with toll roads, but much lower in other areas. This means that this data collection option is best suited for urban areas with a high toll tag saturation rate. The study found comparable rates of saturation between urban freeways and urban arterials; however, the percentage of vehicles that could be re-identified at a second sensor was lower for arterials due to the fact that more vehicles enter and exit the facility between sensor stations. As a result, in Orlando, toll tag readers usually only generated between 10 and 20 travel time estimates per hour (8). Agencies should thoroughly evaluate their regional saturation rate of RFID toll tags to determine whether this technology can supply the number of travel time samples needed to robustly estimate reliability measures over time. RFID is also an alternative for areas that do not have ETC if agencies distribute RFID tags to volunteer drivers. This was done in San Antonio as part of the TransGuide traffic monitoring program, where 30,000 tags were distributed in the first 10 months of operation (9). The FHWA’s Travel Time Data Collection Handbook offers the following suggestions to increase the number of RFID tags in the regional vehicle fleet:  Priority passage through toll facilities;  Priority passage through weigh/inspection stations (for trucks);  Ability to receive in-vehicle travel information;  Free electronic tag;  Voucher for merchandise or fuel;  Registration for roadside maintenance service; or  Some type of user incentive payment. Aside from sample size concerns, privacy issues are raised because RFID transmits data that is identifiable to an individual vehicle. Therefore, if RFID is used to collect travel times, the system will need to encrypt data to remove personal information. The iFlorida deployment does this by sending the DOT database an encrypted hash that represents the toll tag number, rather than the actual toll tag number itself. 37 Vehicle Signature Matching 38 39 40 41 42 43 Vehicle signature matching refers to methods that match the unique magnetic signature of a vehicle as it passes over a detector to the same signature from an upstream detector. Single loop, double loop, and wireless magnetometer detectors all have this capability. While loops are not capable of matching every vehicle, research and testing of this method has shown that it can match enough vehicles to provide accurate travel time distributions for both freeways and arterials. (10) 2-7 1 2 3 4 5 6 7 One advantage of this method is that it can use existing detectors in new ways that improve travel time data accuracy. For arterials, it is advantageous over traditional detector data since it estimates travel times without the need for signal phase information. It also offers an additional benefit over other AVI technologies: it avoids potential privacy concerns through anonymity. This technology has only seen limited use in practice thus far, with projects in a few locations in California, but appears promising for measuring travel times on both freeways and arterials. (10) 8 AUTOMATED VEHICLE LOCATION SOURCES 9 10 11 12 13 14 15 Automated Vehicle Location (AVL) refers to technologies that track a vehicle along its entire path of travel. These methods provide the most accurate and direct measurements of travel times, but have not yet seen deployment sufficient to provide reliable data on a regional scale. This will change as more vehicles become equipped with AVL technologies and agencies become more accustomed to using them for real-time data collection. An example of incorporating AVL equipment to analyze transit performance is illustrated in the San Diego case study in Chapter 4. 16 Global Positioning Satellite 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Any vehicle equipped with a Global Positioning Satellite (GPS) receiver can be tracked along its path of travel to calculate route-based travel times and other traffic data. GPS technology is well-suited for accurate travel time calculations because it can pinpoint a car’s location within a few meters and its speed within 3 miles per hour. (13) GPS has traditionally been used to calculate travel times through test probe vehicles equipped with GPS receivers. The value of this data is limited because of the small number of test probe vehicles typically deployed, and it does not provide real-time data on a permanent basis. However, even in a more advanced system that monitors all GPS-equipped vehicles in-real time, the low market penetration rate of GPS technology will be a constraint on the ability to accurately represent travel time variations. However, it can be reasonably assumed that more vehicles and devices will have GPS capabilities in the future. GPS is also used by many transit agencies to monitor bus locations and schedule adherence in real-time. As such, another alternative for agencies looking to monitor reliability is to use equipped buses as travel time probes. By identifying and separating out bus-specific activities, such as dwell times and different acceleration rates, arterial travel times can be estimated from bus AVL data (11). 33 Connected Vehicle 34 35 36 37 38 39 40 41 The Connected Vehicle (CV) research program, sponsored by the U.S. Department of Transportation (USDOT), is focused on leveraging wireless technology to allow vehicles and roadway facilities to communicate with one another, with the aim of improving safety, monitoring conditions, and providing traveler information (12). The majority of Connected Vehicle research will be completed by 2013; therefore, at this point it is impossible to know the full scope of the contributions that the research will make to reliability monitoring efforts. At this point, however, it seems that Connected Vehicle technologies could provide a rich source of travel time information, since the Vehicle to Infrastructure (V2I) communication channels 2-8 1 2 implemented through the Connected Vehicle program could be used to send collected vehiclespecific location data to a central data server for travel time processing. 3 Cellular Networks 4 5 6 7 8 9 10 11 Cellular telephone networks track cell phones to hand them off to different base stations as they travel, and travel times can be calculated through this information. The precision of location data increases with the number of cellular towers for which a phone is in range. In urban areas, location accuracy can be within a hundred feet (15), which in some cases is too large to assign vehicles to a specific link, especially in dense urban networks. In more rural areas, location accuracy can be off by more than a mile, which would negate the value of travel times estimated in this manner. To obtain cellular travel times for reliability monitoring, agencies would either have to partner with cell phone companies or buy data from a third-party provider. 12 PRIVATE SECTOR-BASED SOURCES 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Interview results from this project established that many public transportation agencies are interested in obtaining data from private sources, in order to save time and money on data collection and processing. While these private sources can provide data for facilities that are otherwise unmonitored (such as arterials), the lack of transparency on their proprietary methods of data collection could present challenges for agencies seeking to monitor reliability. The data disseminated by these sources vary. In most cases, the commercial offerings provide a speed range (i.e. 30 to 40 mph) for stretches of roadway defined by Traffic Message Channel IDs. These data are, by their very nature, opaque to agencies. For example, it is not clear from the data where on that stretch of roadway the speeds were observed, or when during the time period they were observed. More importantly, little information is given on the methods used to calculate the speeds. For example, the speeds may have been calculated from multiple GPS probe readings on the roadway, and thus be highly accurate, or they may have been interpolated entirely from historical data because no real-time samples were collected during the time period. 27 Transportation Data 28 29 30 31 32 33 34 35 36 37 38 39 40 These private source firms collect data from a variety of sources, including GPS probes, road sensors, toll tags, and cellphones. Many of these firms also collect incident and event data. Typically, the business model of these firms revolves largely around the traveler information market, and they sell this data to public agencies as a sideline to their core business. As such, the data itself largely reflects the needs of traveler information systems and not performance measurement. The simplest data these firms collect are fixed roadway sensors. These are largely the result of a series of public-private partnerships, stretching back to the mid-1990s, in which firms were allowed to install and maintain fixed detectors on public roadways, usually in exchange for an exclusive concession to sell the traffic data to another market, such as the local media market. Typically, these data are available already to the public agency, as part of the concession. In some cases, the agency might procure this data, or additional rights to data they already receive (as part of a new travel time reliability system, for example). 2-9 1 2 3 4 5 6 7 8 9 10 Increasingly, these firms are collecting probe data. This probe data has historically been the purview of freight companies, who were the only firms that had the necessary cost incentives to equip their vehicles with GPS. For example, freight companies can rent or purchase tracking devices to place on vehicles, and then pay a flat communication fee to receive web access and real-time alerts on vehicle locations. Thus, the first data sources for private providers were primarily freight carriers. However, in a world of cheaper GPS and ubiquitous smart phones, this is rapidly changing. Currently, an estimated 51% of drivers have smart phones, many of whom use the devices’ GPS capabilities in-vehicle for navigation assistance (14). Firms are increasingly acquiring data directly from consumers as part of the growing personal navigation market. As a consequence, the size and diversity of the probe data sets are exploding. 11 Data Transparency 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 While some providers may supply metadata on the data quality (for example, a ranking scale), the methods for the quality assessment remain opaque. For the most part, these limitations are inherent to the business model of the data provider. Generally speaking, these private source data providers have built their competitive advantage on their network of data sources and data fusion methodologies. Because of this, they are unlikely to reveal the underlying sources and methodologies to the agencies that may wish to know. This fact must be considered by agencies interested in using private source data to produce or supplement reliability information. Generally speaking, an agency must ask itself two questions: 1. Can we perform the necessary (travel time reliability) calculations with this form of data? 2. Do we believe that the data are sufficiently accurate? If the answer to both of these questions is yes, then this “black box” approach to data acquisition may be entirely appropriate for a given agency. Both of these questions can be answered, but they generally must be answered on an application-by-application basis. For example, to answer the second question, an agency could purchase a data sample from a firm and independently test its accuracy. To answer the first, an agency might attempt to build travel time distributions out of data binned by speed to examine if these simplified distributions were adequate to its needs. 31 DATA MANAGEMENT FOR RECURRING CONDITIONS 32 33 34 35 36 37 38 39 40 41 42 43 Travel time reliability is often monitored through a combination of real-time and off-line systems. Off-line, regimes are developed that characterize the manner in which segments and routes operate. Then, in real-time, tests are performed to determine what regime is operative for a segment or route at any given point in time and what regime(s) are likely to be operative in the short-term future. The regimes are described by probability density functions that portray the distribution of travel times likely to be experienced by travelers. The best database design for this type of situation is a data warehouse model, which means that data are stored in the database in a non-normalized format, at multiple levels of aggregation and imputation. This ensures that the system can support report generation at several levels of temporal and geographic granularity. A data warehouse is a type of relational database, which is composed of two-dimensional storage elements (tables). Each table has fields (columns) and records (rows). Tables relate to 2-10 1 2 3 4 5 6 one another through common fields. An example relationship between tables in a travel time database is shown in Table 2-1. The top table contains background information on routes in the system, and the bottom table contains 5-minute travel times. The two tables relate to one another through the Route ID field. Table 2-1: Example Database Table Relationship Route ID Route Name Length (miles) 009 Golden Gate Bridge to Bay Bridge 6 020 Walnut Creek to Oakland Coliseum 15 116 Downtown Berkeley to Rockridge 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 Time ID Route ID Travel Time (mins) Operative Regime 11/25/2009 17:00:00 009 25 1 11/25/2009 17:00:00 020 32 3 11/25/2009 17:00:00 116 15 2 Five general types of tables are commonly used in reliability monitoring systems: 1. Configuration information. This is information that is not in real-time and does not change in the field. Examples of configuration information include the definitions of the routes for which reliability will be monitored and the locations of detectors and sensors on freeways and arterials. 2. Raw data. These data are directly received by devices in the field and not processed in any significant way. The form of the raw data is dependent on the sensor technology; for example, data from loop detectors contains different fields than data from a GPS device. As a result, different raw data tables are needed for each of the four data sources: (1) and (2) infrastructure-based; (3) AVI-based; and (4) AVL-based. Examples of these are included in Supplement A as discussed below. 3. Travel time information by sensor type. Since the computational process for deriving travel time information from the raw data is dependent on the technology used in data collection, different database tables are needed to store the travel time information derived from the different source types. Where routes are being monitored by multiple technologies, data from the different sources can be fused to improve the travel time information. In these cases, a final database table is needed to store the fused travel time data, which ultimately are used to update the travel time density functions and regimes and facilitate the reliability computations. 4. Travel time density functions. These density functions are derived off-line from the travel times kept in the data tables described above. They are commonly separated by segment and route regimes that have been identified by the travel time reliability monitoring methodology described in Chapter 3. 2-11 1 2 3 4 5 6 7 8 9 10 11 Database design usually takes the form of a schema, which formally describes the database structure, including the tables, their relationships, and constraints on data value types and lengths. A companion document to this guidebook, Supplement A: Monitoring System Architecture, presents example tables that can store information generated during all steps of the reliability monitoring computation process, from the raw data to the travel time density functions and reliability metrics. The exact tables, fields, and relationships are flexible to the needs of the agency, the data available, and the desired reporting capabilities. 12 DATA MANAGEMENT FOR NON-RECURRING EVENTS 13 14 15 16 17 18 Additional information beyond the already-discussed traffic data is required to understand the impact of non-recurring events on travel time reliability. The primary nonrecurring events that affect reliability are incidents, weather, construction, and special events. The ability of agencies to collect data on these events, and the types of data they can collect, will vary between locations. As such, this section is meant to be flexible, so that agencies can tailor recommendations to fit the data that they have at their disposal. 19 Data Characterization 20 5. Reliability summaries. These tables contain information that portrays the manner in which segments, routes, and special areas have been operating in specific spatial and temporal timeframes. This section presents four of the major sources for non-recurrent congestion. 21 Transportation Incidents 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 Traffic incidents can reduce available roadway capacity and include accidents, vehicle disablements, debris on roadway, and vehicle abandonments. Higher frequency of incidents on specific roadway segments is typically associated with greater travel time variability. There are many viable sources for collecting incident data. Most state (and some local) emergency response agencies use Computer Aided Dispatch (CAD) systems to respond to incidents; these systems have feeds to connect with. The benefit of this data source is that it is in real-time, but the drawback is that the data has not been cleaned (for example, locations may not be clearly specified and durations may be inaccurate). Many State Departments of Transportation have databases with cleaned up incident records for state highways (for example, the Caltrans Accident Surveillance and Analysis System), for the purpose of performing detailed analyses. These sources can also be leveraged for reliability monitoring. Another potential source for incident data is the local Transportation Management Center (TMC), where operators usually enter incident information into their management software. Finally, private sources such as Traffic.com often collect incident data at a high level of specificity from various sources, including video, mobile (patrol) units, and emergency communication frequencies. While many potential sources for incident data exist, it should be noted that these data are often incomplete, many times lacking severity indicators, clearance times, and exact incident locations. The following variables can be used to relate traffic incidents with travel time variability:  Location  Date 2-12 1 2 3 4 5 6 7 8  Type  Starting time and duration  Full time to clearance  Severity  Lanes impacted In addition, transit incidents, such as bus collisions or disablements can disrupt the operations of a transit system and cause major delays. Such incidents are increasingly being detected by the AVL systems used by transit agencies. 9 Weather 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 Severe weather events include rain, snow, extreme temperatures, strong winds, blowing dust, and wildfires. Adverse weather typically results in lower vehicular speeds and higher incident frequencies, increasing travel time variability. One source for weather data is existing weather stations operated by various governmental organizations or research bodies. For example, the most accurate sources of weather information are the Automated Surface Observing System (ASOS) and Automated Weather Observing System (AWOS) stations maintained and used for real-time airport operations by the Federal Aviation Administration (FAA). Another good source is an online interface from the National Climatic Data Center (NCDC) of the National Oceanic and Atmospheric Administration (NOAA), which provides hourly, daily, and monthly weather summaries for 1,600 U.S. locations. For mountainous rural areas, the major sources of weather-related delay are closures and chain control stations. These data are frequently available from rural traffic management centers, although collecting feeds of such data is rare and problematic. One of the richer sources of this data may be Highway Advisory Radio (HAR) networks, which broadcast closure and chain control locations and are frequently available via statewide feed. Any weather data obtained from sources not directly on a monitored route will have to be associated with nearby routes in the system. Another option for collecting weather data is to install Environmental Sensor Stations (ESS) at key roadway locations. Many states have used these to build Road Weather Information Systems, which archive weather data and use it in roadway-related decision making. The following variables can be used to relate weather with travel time variability:  Air temperature  Type of precipitation  Amount of precipitation  Visibility  Wind speed  Pavement temperature  Surface condition Transit agencies can use similar methods to monitor weather conditions and develop operational plans that can help them deal with potential disruptions in service and variability in travel times during a variety of adverse weather events. As of this writing, the process for connecting weather data to travel time monitoring systems is largely manual. Examples from the San Diego and Atlanta case studies are presented in Chapter 4. 2-13 1 Work Zones 2 3 4 5 6 7 8 9 10 11 12 13 14 Work zones typically reduce the capacity of roadways, increase driver distractions, increase incident frequency, and cause major delays in the transportation network. They are typically associated with higher travel time variability. There are a few different sources for construction-related lane closures. Many states have lane closure systems that serve as a communication interface between the contractors and state agencies to facilitate lane closure management; this data source can be obtained in real-time. Private sources are another option; for example, Traffic.com reports both scheduled and unscheduled construction events. Another option is to manually obtain construction-related information from Changeable Message Sign logs or feeds. The following variables can be used to relate work zones with travel time variability:  Start time and duration  Start and end locations  Lanes impacted 15 Special Events 16 17 18 19 20 21 22 23 24 25 26 Frequently, special event data must be collected by individuals rather than systems, since there are no standardized, centralized sources for this information. One option is to manually review calendars for major event venues near a route. Another option is to obtain event data from TMCs, many of which collect event logs to know when and where to activate event-based signal timing plans. The following variables can be used to relate special events with travel time variability:  Location  Routes affected  Duration  Type of event  Attendance 27 Data Storage 28 29 30 31 32 33 34 35 36 37 38 39 40 41 The data storage regime for the non-recurring events is dependent on exactly which variables are collected, and at what granularity. The spatial and temporal resolution of nonrecurring events data is an important consideration that impacts the strength of the relationships developed with travel time variability. Data on non-recurring events, to some degree, needs to be aggregated to the same temporal and spatial resolution, in that it all needs to be spatially collected by route and temporally collected for each day in the analysis period. Collecting data on some of the sources at higher spatial and temporal resolutions would lead to more accurate analysis. The case studies and use case analyses, described in Chapter 4, suggest that a granularity of five-minutes is sufficient to link the effects of non-recurring events like weather to their travel time impacts. Granularities greater than 15 minutes are too coarse. Finer granularities, such as one minute or 30 seconds, are helpful but not necessary. The data on non-recurrent events does not need to be stored in the same tables as the route travel times, since the analysis to link travel time variability with its causes is typically a manual exercise. As such, the database for non- 2-14 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 recurring events can be uniquely designed to store the data that each agency is able to collect. Examples of typical data tables are provided in Supplement A: Monitoring System Architecture. The most useful way to store the event data is in separate files tailored to the event type where beginning and ending times can be recorded along with descriptive information. This is because these events have no specific synchronization with the traffic sampling intervals and should not be forced to be synchronous. Moreover, the events can have temporal and spatial impacts outside the bounds of their duration and physical location. For example, in the case of the Lake Tahoe analyses, the heavy snowstorms had impacts extending well beyond the time when the snow stopped falling. Also, in Sacramento, accidents on intersecting freeways, near the interchanges with the subject facility, had impacts on the travel times observed. An important corollary to this is that the queries seeking explanatory information for high travel rates or times at a specific location and time must look outside the bounds of that location and time. Although the weather data may indicate that the weather event is over, the query must seek causal explanations from earlier weather events. Similarly, although there may be no event at the location being examined, the query must look for events on intersecting facilities. (It must also look downstream of the location being examined.) Another significant issue is that event data seem to lack quality information about duration. Moreover, the end of the interval during which the incident has an impact on travel times tends to be larger than the duration of the incident event itself, e.g., the increased travel times persist for some time after the incident has been recorded as “over”. A final note is that AVI and AVL data show travel time (and rate) transients with a granularity dictated by the frequency with which such observations are obtained. The case studies and use cases tend to suggest that with today’s penetration rate for such devices, keeping all the raw data makes sense (sanitized to protect privacy). Summarizing it based on some granularity (e.g., 5 minutes) has no value and can obscure very useful information about travel time/rate transients. 27 SUMMARY 28 29 30 31 32 33 34 35 36 37 38 39 40 The final database design for a reliability monitoring system must reflect the technologies used to collect data and the processes used to derive travel time estimates from the raw data. In general, four types of tables are needed to fully describe the monitoring system and its outputs. Configuration tables are needed to define the routes and route segments for which travel times are to be computed, including their starting and ending point, where their detectors are located, and what type of detection they have. Raw data tables are needed to store the unaltered inputs from the various detection types. Travel time tables are needed to store the representative travel times calculated for each route segment, time period, and detection type, as well as the intermediary information generated during the computation. Finally, reliability tables can be used to store high-level monthly, quarterly, and yearly summaries of reliability statistics for individual routes or higher spatial aggregations. One-way (irreversible) encryption can be applied to protect the privacy of personally-identifiable information such as license plate numbers. 41 REFERENCES 42 43 1. California Center for Innovative Transportation. Evaluation of Wireless Traffic Sensors by Sensys Networks, Inc. University of California, Berkeley, October 2006. 2-15 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 2. Klein, L., M. Mills, D. Gibson. Traffic Detector Handbook: Third Edition—Volume 1. Report No. FHWA-HRT-06-108. Turner-Fairbank Highway Research Center, Federal Highway Adminstration, October 2006. 3. Venere, Emil. Method uses Bluetooth to track travel time for vehicles, pedestrians. Purdue University, May 27, 2008. 4. Traffax, Inc. http://www.traffaxinc.com. Accessed October 16, 2009. 5. Texas Transportation Institute. Travel Time Data Collection Handbook. Report FHWAPL-98-035. Federal Highway Administration, 1998. 6. PBS&J. License Plate Reader Operations. Florida Department of Transportation, 2006. 7. Dahlgren, Joy and John Wright. Using Vehicles Equipped with Toll Tags as Probes for Providing Travel Times. California Partners for Advanced Transit and Highways, 2001. 8. Haas, R., M. Carter, E. Perry, J. Trombly, E. Bedsole, and R. Margiotta. iFlorida Model Deployment Final Evaluation Report. FHWA Report No FHWA-HOP-08-050. Federal Highway Administration, January 2009. 9. Riley, J. D. Evaluation of Travel Time Estimates Derived from Automatic Vehicle Identification Tags in San Antonio, TX. MS thesis. Virginia Polytechnic Institute and State University, Blacksburg, 1999. 10. Kavaler, R., K. Kwong, R. Rajagopal, and P. Varaiya. “Arterial Travel Time Estimation Based on Vehicle Re-Identification Using Wireless Magnetic Sensors.” Transportation Research Part C: Emerging Technologies. Volume 17, Issue 6, December 2009, Pages 586–606. 11. Berkow, M., J. Chee, R. Bertini, and C. Monsere. “Transit Performance Measurement and Arterial Travel Time Estimation Using Archived AVL Data.” Presented at ITE District 6 Annual Meeting, Portland, Oregon, July 2007. 12. Research and Innovative Technology Administration. “Achieving the Vision: From VII to Intellidrive.” http://www.its.dot.gov/press/2010/vii2intellidrive.htm. Accessed September 2, 2012. 13. University of California at Berkeley. “New research project captures traffic data using GPS-enabled cell phones.” February 2008. http://www.physorg.com/news121845452.html. ccessed October 19, 2009. 14. J.D. Power and Associates. Smartphone Ownership Drives Increased Vehicle Owner Interest in Communication- and Connectivity-Related Features. Press release. http://businesscenter.jdpower.com/news/pressrelease.aspx?ID=2010095. Accessed September 2, 2012. 15. Wunnava, S., K. Yen, T. Babij, R. Zavaleta, R. Romero, and C. Archilla. Travel Time Estimation Using Cell Phones (TTECP) for Highways and Roadways. Florida Department of Transportation, 2007. 2-16 1 CHAPTER 3 2 COMPUTATIONAL METHODS 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 The computational methods used by travel time reliability monitoring systems (TTRMS) need to be designed to generate information about the ways in which travel times and rates vary during system operation and the reasons why those variations occur. Ultimately, system managers want to use the TTRMS to improve the reliability of the system and to convey its current and projected performance to the people who use the system. This guidebook presents ways to create probability density functions for the travel times and travel rates (TT-PDFs and TR-PDFs) experienced by network segments and routes and tools that show how these PDFs are affected by influencing factors, both internal and external to the system. The TTRMS can be thought of as comprising three parts. The first is a travel time processing unit: it takes the raw data outlined in Chapter 2, cleans it, fills in gaps, estimates errors, and produces the travel times upon which the PDFs are based. The second is a data processing unit: it takes these travel times and creates the PDFs that characterize the performance of the system under various operating conditions. The third is an analysis tool: it sees how the various influencing factors, both internal and external, affect the reliability performance of the system. In this chapter, seven subsections are used to describe the TTRMS:  Network Concepts: how the TTRMS represents travel times.  Trip-Making Concepts: how the TTRMS represents trip travel times.  Operating Conditions and Regimes: how the impacts of influencing factors are studied.  Imputation: how the TTRMS should impute estimates for missing or invalid data.  Segment Travel Time Calculations: the steps and computations that transform raw sensor data into observations of segment travel times.  Route Travel Time Computations: how travel times are assembled into probability density functions for segments and routes.  Causal Factor Analysis: how the TTRMS can be used to examine the influence on reliability of various causal factors, both internal and external. As discussed in Chapter 1, both operators (the supply side) and travelers (on the demand side) need to be kept in mind in describing the TTRMS. Operators and managers want to minimize variability in the travel times so that network performance is consistent. They want to find ways to reduce this variability when it is unreasonably high. Travelers want to make trips that avoid highly variable travel times so they can get to destinations on time. They want to make astute route and departure time decisions. In all instances, the fundamental unit of observation is travel times and rates for individual vehicles (or people or packages) making trips across the network. These are the entities that are moving. This is the raw data upon which the TTRMS is based. Either the TTRMS receives this raw data directly from AVI and AVL-equipped vehicles, or it receives it implicitly through average speeds and travel times provided by single and double loop detectors or third-party data sources (e.g., TMC segment travel times). 3-1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Some of this raw data is eventually archived for future use in developing the PDFs for analyses of the past. In the case studies presented in Chapter 4, all the data have been kept, even the individual AVI and AVL vehicle records, to support methodological development across the project. But for operating agencies, this is unlikely to be a suitable practice, especially for the AVI and AVL data because of the large amounts of storage required (and privacy issues). It will be sufficient to keep PDFs that describe the system performance under various conditions along with samplings of the AVI and AVL data (scrubbed so identities are removed) and the system detector data (as is the current practice). The sufficiency test is this: are the data that are being kept sufficient to develop any and all PDFs that are likely to be of interest in comparing past performance with the current status quo. For both the present and the past, the raw data are summarized into PDFs that look at trends across time for the same time period (e.g., the same 5-minute periods on weekdays across the year) or across vehicles at the same point in time (using cross-sectional data) to look at variations in the trip times or rates for travelers who are all making the same trip at the same time, or traversing the same parts of the network at the same point in time. The longitudinal PDFs are often used by system operators to understand how travel time variability is affected by internal and external influencing factors such as congestion (internal) and weather, incidents, and special events (external). The cross-sectional PDFs are used by travelers to understand how long it will take them to make a trip at a particular point in time and the probability that they will arrive on time. 21 NETWORK CONCEPTS 22 23 24 The first task in establishing a TTRMS is to define a network topology that can be used to study the system’s travel time variability. Notions of monuments, segments and routes need to be created. 25 Monuments 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 The first idea is a monument. Similar in concept to monuments used by land surveyors, it is a reference point (node) to and from which the travel times are measured. As illustrated in Figure 3-1, while monuments could be placed at the ends of the physical links (i.e., in the middle of intersections or interchanges), the findings from this study suggest this is not wise; the travel times become ambiguous because turning movements confound the observations. Placing the monuments at the midpoints of the physical links removes this confusion. It ensures that the correct turning movement delay is included in each monument-to-monument travel time. This is clearly important for arterials but it is also important for freeways. Ramp movements can have different travel times (e.g., direct ramp or loop ramp, as well as and any traffic control on the ramp—such as a signal—as is sometimes the case in Los Angeles). The monuments should be—and need to be—linked to locations that the traffic management center uses to monitor the system, as in the location of system detectors on both the freeway and arterial networks. This minimizes the database management tasks involved in keeping track of where the monuments are located. They can also be the location of toll tag readers and AVI sensors. They should not be placed at locations where standing queues occur. 3-2 1 2 3 4 5 Figure 3-1: Illustration of Monuments Passage Times 6 7 8 9 10 11 12 13 14 15 16 The second idea is a passage time. It indicates when a vehicle has passed a given monument. When the monument is at the location of a detector (e.g., a loop in the pavement or an AVI reader), the passage time is the instant at which the vehicle crosses the detector. In the case of an AVI reader used for collecting tolls, it is the time when the toll is collected. In the case of other AVI sensors, where the tag may be identified more than one time when the vehicle is passing the sensor, it should be the time when the vehicle is closest to the sensor. For Bluetooth sensors, the response with the greatest signal strength should be used, or an interpolation of the response pulses to identify this location, or the mean of the strongest responses. For AVL vehicles, as is the case for some AVL applications, it should be the time when the vehicle passes the monument location based on comparing the latitude and longitude of the vehicle with the latitude and longitude of the monument. 17 Segments 18 19 20 21 22 23 24 25 26 27 28 A segment is a path between two monuments. In some cases there will be only one segment between the monuments. In other cases there may be two or more. It is these segments for which the travel times ought to be monitored and estimated. The segments can be, and should be, related to the physical network. A good option is to map them to demarcations of the network used for other purposes (e.g., TMC segments, which are explained later in this chapter). It is the segments for which PDFs are estimated. Figure 3-2 shows examples of segments that tie the midpoint of a north-south link south of an intersection to the midpoint of an east-west link to the east of the intersection. The northbound-to-eastbound segment connecting the monuments on these two links represents the northbound right turn at the intersection. The segment in the other direction represents the westbound left. 3-3 1 2 3 4 Figure 3-2: Illustration of Segments 5 Routes 6 7 8 9 Routes are sequences of segments. Routes are defined by the sequence of segments, and thus monuments, that they pass through; routes with the same origin and destination are unique unless they go through the same segments in the same order. Figure 3-3 shows an example of two routes. 10 TRIP-MAKING CONCEPTS 11 12 13 14 15 16 For system operators, monitoring the performance of segments and routes is likely to be sufficient unless reliability goals and objectives are established for specific sets of users (i.e., travelers or shippers). For travelers and shippers, however, additional trip-making concepts are needed to appropriately analyze the raw data. This includes: the travelers that are of interest, the geographic definitions of the origins and destinations, the routes and segments involved, and the conditions under which the trips were made. 3-4 1 Users 2 3 4 5 6 7 8 9 In this context, users are people (or packages) making trips across the network. (They may also be users of the TTRMS, but that is a different thought.) Users can be organized into groups with the same or similar trip-making behavior. An example would be commuters making weekday trips from zone A to zone B. Another would be vehicles traveling from a residential zone the airport. The analyst needs to determine how “similar” these users need to be for them to be classified as a single group, or how heterogeneous they can be without undermining the usefulness of the travel time reliability information. 10 11 12 Figure 3-3: Illustration of Routes 13 Route Bundles 14 15 16 17 18 19 20 21 Route bundles are sets of two or more routes. The routes in a bundle can have the same monument pair as the start and end points (a set of different paths for the same point-to-point pair) or they can be for slightly different monument pairs, as might be the case for all the routes leading from the monuments in one zone (e.g., a ZIP code or traffic analysis zone) to all the monuments in another zone. The majority of the intervening segment sequences might be largely the same (one general route) or varied (several general routes exist). Hence, the bundles arise because a) there are many routes or b) there are many originating or terminating monuments, or c) both. These are illustrated in Figure 3-4. 3-5 1 2 3 Figure 3-4: Illustration of Route Bundles 4 Markets 5 6 7 A market is formed by a set of users in combination with a route bundle. An example would be commuters who have toll tag equipped vehicles (user group) that travel in the morning (time period) from a suburban area to downtown destination (using a specific route bundle). 8 OPERATING CONDITIONS AND REGIMES 9 10 11 12 13 14 Operating condition concepts form the basis for describing the conditions under which the segment, route, or network is operating at a given point in time. They also serve as the basis by which the operation at a given point in time can be classified. Ultimately, it is for these conditions that the PDFs are developed and via these conditions that the operation is understood (i.e.., its variability) and for which actions are taken to improve reliability. 15 Congestion Conditions 16 17 18 19 20 21 22 23 24 25 It is useful to categorize 5-minute time periods on the basis of the level of congestion (demand-to-capacity ratio) that would normally be occurring at that point in time. For example, 7:55–8:00 on weekdays that are workdays (not holidays) might be classified as “high congestion” if it were a 5-minute time period that would normally be experiencing high congestion during the a.m. peak. It is well recognized that the level of congestion affects the variability of the travel times and a categorization scheme that codifies that affect is helpful. It is also valuable to use four categories for these congestion conditions: uncongested, low, moderate, and high. Other analysts might find it helpful to use additional categories. Also, it is not necessary to apply all of these categories to every segment or route. Uncongested is defined as meaning that the vehicle interactions were not having a perceptible impact on the 3-6 1 2 3 4 5 6 7 8 distribution of the vehicle travel times. Travelers were able to use their desired speeds. Low means there was some evidence of increased variability in the travel times (more than would arise under uncongested conditions) so the vehicle interactions had to be interfering with the ability of travelers to move at their desired speeds, but not so much as to create queues. Moderate means that the demand-to-capacity ratio was sufficiently high to create short-term queuing, as often occurs in queuing systems where the queues form and dissipate quickly. High meant that there were sustained queues caused by demand in excess of capacity that were only cleared when the demand-to-capacity ratio again diminished and the system was able to catch up. 9 Non-Recurring Events 10 11 12 13 14 15 16 17 18 19 The second dimension for categorizing system behavior is based on the non-recurring events that occurred, including “none” or “normal operations”. These designations were intended to be consistent with the FHWA ideas about sources of congestion. The authors were able to identify the impacts of incidents, weather, special events, traffic control devices, and unusually high demand. The impacts of “insufficient base capacity” were captured by the nominal congestion condition categories described above (i.e., situations where the demand-to-capacity ratio is high enough that sustained queuing occurs). The high demand category is equivalent to “fluctuations in demand”. Work zones were not present in any of the networks for which analyses were conducted, but it is clear from the congestion-related analyses that they would have an impact on reliability. 20 Regimes 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 Regimes are the resulting categories of conditions under which the segment, route, or network is operating at a given point in time (or from one time to another). It is effectively the “loading condition” on the system. It is helpful to define these regimes based on combinations of the congestion condition that would normally be occurring, reflecting the demand-to-capacity condition that would nominally arise at that point in time , as well as the non-recurring event (if any) that was occurring at that point in time. Table 3-1 illustrates how these regimes were used. It shows the amount of variability experienced during a year can be categorized based on these regimes for three routes in San Diego that were examined in one of the use cases. The particulars are not important here, only the illustration of the regimes. That having been said, notice that for the I-5 route, that 50% of the extra time attributable to variable travel times is attributable to periods of high congestion when no non-recurring event has arisen. High congestion under periods of higher-than-normal demand accounts for another 13% and non-recurring weather and incident events account for another 13% and 16% respectively. On the basis of these regimes, analysts can identify times and conditions for which mitigating actions would be appropriate (including adding more capacity or altering the use of traffic control devices) to reduce the amount of extra travel time created by the variability in the travel times. 3-7 1 2 Table 3-1: Illustration of Regimes Route Condition I-5 Uncongested High Uncongested Low Moderate High Uncongested Moderate High CA-15 CA-163 Normal (%) 8 50 4 4 7 35 4 12 35 Demand (%) 1 13 0 0 0 17 0 1 19 Weather (%) 1 8 0 0 0 6 0 1 5 Special Events (%) 0 3 0 0 0 6 0 2 4 Incidents (%) 1 16 0 0 0 19 0 3 14 Total (%) 11 89 4 5 8 83 4 19 77 Facility Total (%) 100 100 100 3 4 5 6 7 8 9 10 11 12 13 14 Readers should recognize that the right set of regimes for a given segment, route, or system will be site-specific. Care should be taken in identifying these regimes so that they represent the smallest set of categories that clearly describe how the system operates and performs. The incentive for using fewer (rather than more) is so that the data are categorized into groups of sufficient size that meaningful PDFs can be developed that describe the system’s operation under that condition (regime). It is also important that these regimes be the system states that are most critical to study, manage, and improve from the operating agency’s perspective. The ones that are important are likely to evolve over time as the agencies fix problems and develop more insight into travel time reliability. Akin to the development of signal timing plans, the system manager will determine over time what conditions are the most important ones to monitor. 15 Sample Space 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 The sample space (observation set, observation timeframe, sample frame) is the set of raw data that pertain to each context for which a PDF is being developed (a regime or some other basis). A simple example would be the observations that pertain to the high congestion / normal regime. Another, which is not a regime, is observations of travel times (or rates) between two points in time for some non-recurring condition (e.g., between 7:00 a.m. and 9:00 a.m. on weekdays that are workdays when it was snowing). This latter sample frame is a very logical one; it is just not necessarily a regime. The timeframe of 7:00 a.m. to 9:00 a.m. is likely to be one across which the nominal level of congestion is varying considerably, and the fact that the nonrecurring condition is “snowing” is a specific instance of a weather condition. It is certainly possible to develop PDFs for this condition, to study them and see how they indicate system performance (variability in the travel times) is different for this situation than it is for others (e.g., high congestion during “no” non-recurring event), and the main point is that the sample space would be observations of travel times (or rates) that occurred during this time frame when it was snowing. The main point is that it is always important to understand what data were used to conduct the analysis so that the findings are correctly understood and interpreted in a manner that is consistent with the data used in the analysis. 33 IMPUTATION 34 35 For a TTRMS to function effectively, it needs complete information about the travel times and rates for all segments in the network. Missing data makes it impossible to both analyze 3-8 1 2 current (and past performance) and to develop projections of future conditions. This section provides guidance about how best to deal with situations where field data are missing. 3 Imputation for Infrastructure-Based Sensors 4 5 6 7 8 9 10 11 12 13 The most prevalent type of roadway data currently comes from point sensors, such as loop and radar detectors. While these data sources provide valuable information about roadway performance, they have two main drawbacks: (1) detectors frequently malfunction; and (2) they only provide data in the temporal dimension (speeds at a point, or their inverse, spot rates), whereas travel times require data over spatial segments. The first issue is best dealt with through an imputation process, which fills in data holes left by bad detectors. This is the issue addressed in this section. Rigorous imputation is a two-step process. First, the system needs to systematically determine which detectors are malfunctioning. Then, the data from the broken detectors must be discarded and the remaining holes filled in with imputed values. 14 The Imputation Concept 15 16 17 18 19 20 21 22 23 24 25 Once the system has classified infrastructure-based detectors as good or bad, it must remove the data transmitted by the bad detectors so that invalid travel times are not incorporated into the reliability computations. However, removing bad data points will leave routes and facilities with incomplete data sets for time periods where one or more detectors were malfunctioning. Since travel time computations for infrastructure-based sensors rely on the aggregation and extrapolation of values from every detector on the route, travel time computations for a route would be compromised each time a detector failed (which, given the nature of detectors, will occur frequently). For this reason, imputation is required to fill in the data holes and thus enable the calculation of travel times and variability. Figure 3-5 shows the high-level concept of imputation. 26 27 28 29 30 31 Figure 3-5: Imputation of Traffic Data From a data management perspective, agencies are advised to store and archive both the raw data and the imputed data in parallel, rather than discarding the raw data sent by detectors diagnosed as bad. This ensures that, when imputation methods change, the data can be re- 3-9 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 imputed where necessary. It also gives system users the ability to skeptically examine the results of imputation where desired. When imputation is needed for infrastructure-based data, it must begin at the detector level. The strength of an imputation regime is determined by the quality and quantity of data available for imputation use. The best imputations are derived from local data, such as from neighboring sensors or historical patterns observed when the detector was working. Modest imputations can also be performed in areas that have good global information, by forming general regional relationships between detectors in different lanes and configurations. It is important to have an imputation regime that makes it possible to impute data for any broken detector, regardless of its characteristics. As such, the best practice is to implement a series of imputation methods, employed in the order of the accuracy of their estimates. In other words, when the best imputation method is not possible for a certain detector and time period, the nextbest approach can be attempted. That way, data that can be imputed by the most accurate method will be, but imputation will also be possible for detectors that cannot support the best or most rigorous methods. The following imputation methods are recommended to be employed where possible, in this order, to fill in data holes for bad detectors (1). The first two methods make use of real-time data, while the third and fourth methods rely on historically archived values. 19 Linear Regression from Neighbors Based on Local Coefficients 20 21 22 23 24 25 26 27 28 29 30 31 This imputation method is the most accurate due to the fact that there are high correlations between occupancies and volumes of detectors in adjacent locations. Infrastructurebased detectors can be considered neighbors if they are in the same location in different lanes or if they are in adjacent locations upstream or downstream to the bad detector. In this approach, an offline regression analysis is used to continuously determine the relationship between each pair of neighbors in the system. The dependent variable is the flow or occupancy at a detector (when the detector was good) and the independent variables are the flow or occupancy at adjacent detectors. Then, when a detector is broken, its flow and occupancy values can be determined by using the estimated regression parameters. The regression equations can take the form given in Equations 3-1 and 3-2 as follows: 32 33 34 35 36 37 38 39 40 41 42 q i (t )   0 (i , j )   1 (i , j )  q j (t ) Equation 3-1 ki (t )   0 (i, j )  1 (i, j )  k j (t ) Equation 3-2 where:  (i,j) is a pair of detectors,  q is flow,  k is occupancy,  t is a specified time period (for example, 5 minutes), and   0 ,1 ,  0 , 1 are parameters estimated between each pair of loops using five days of historical data. These parameters can be determined for any pair of loops that report data to a historical database. 3-10 1 Linear Regression from Neighbors Based on Global Coefficients 2 3 4 5 6 7 8 9 This imputation method is similar to the first, but is needed because there are some loops that never report data because they are always broken. This makes it impossible to compute local regression coefficients for them. For these loops, it is possible to generate a set of global parameters that expresses the relationship between pairs of loops in different configurations. The configurations refer to location on the freeway and lane number. The linear model is developed for each possible combination of configurations and takes the following form: 10 11 12 13 14 15 16 17 18 19 20 21 22 23 q i (t )   0* ( , l i , l j )   1* ( , l i , l j ) q j (t ) Equation 3-3 k i (t )   0* ( , li , l j )   1* ( , li , l j ) k j (t ) Equation 3-4 where:  (i,j) is a pair of detectors;  δ = 0 if i and j are in the same location, 1 otherwise;  li = lane number of detector i; and  lj = lane number of detector j. The terms are derived using locally available data for each of the different configurations. Figure 3-6 shows an example of this type of imputation routine. Figure 3-6: Imputation Routine Example 24 Imputing Based on Temporal Medians 25 26 The above two linear regression methods cannot be applied during time periods when adjacent detectors are not reporting data themselves (for example, when there is a widespread 3-11 1 2 3 4 5 communication outage). In this case, temporal medians can be used as imputed values. Temporal medians can be determined by examining the data samples transmitted by that detector for the same day of week and time of day over the previous ten weeks. The imputed value is then taken as the median of those historical values. Note that if a large number of samples have to be imputed using temporal medians, it may be difficult to assess travel time variability. 6 Imputing Based on Cluster Medians 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 This is the imputation method of last resort, for those detectors and time periods where none of the above three methods are can be applied. A cluster is defined as a group of detectors that have the same macroscopic flow and occupancy patterns over the course of a typical week. An example cluster is all of the detectors that are monitoring a freeway into the downtown area of a city. These detectors would all have comparable macroscopic patterns in that the a.m. and p.m. peak data would be similar across detectors due to commuting traffic. Clusters can be defined within each region. For each detector in the cluster, the joint vector of aggregate hourly flow and occupancy values can be assembled and, from this, the median time-of-day and day-ofweek profile for each cluster can be calculated. Once values have been imputed for all broken detectors, the data set within the system will be complete, albeit composed of both raw data and imputed values. It is important that the quantity and quality of imputed data be tracked. That is, the database should store statistics on what percentage of the data behind a travel time estimate (and thus a travel time reliability measure) is imputed and what methods were used to impute it. This allows analysts to make subjective judgments on what percentage of good raw data must underlie a measure in order for it to be usable in analysis. 23 Imputation for Vehicle-Based Sensors 24 25 26 27 28 29 30 31 32 33 34 35 Fundamentally, vehicle-based sensors are different from point sensors. They provide observations of travel times across distances—not spot rates—so they are true indications of the time required to travel from one monument to another and they are observations of individual vehicle travel times—not averages or aggregates—so they provide a picture of the distribution of the travel times as well. The critical quality control issue with vehicle-based sensor data is filtering out unrepresentative travel times collected from travelers who make a stop or take a different route. This section describes methods for identifying malfunctioning AVI sensors, and imputing data where sensors are malfunctioning or an insufficient number of vehicles samples were obtained in a given time period. The emphasis is principally on generating estimates of the average or median travel times, as opposed to imputing the entire distribution, but the latter is briefly addressed as well. 36 Identifying Malfunctioning AVI Sensors 37 38 39 40 41 There are two scenarios for which an AVI sensor might transmit no data: (1) the sensor is broken; or (2) no vehicle equipped for sampling passed by during the time period. Therefore, it is important to implement a method for distinguishing between these two cases, so that malfunctioning sensors can be detected and fixed. A simple test for flagging a sensor as broken is if it did not report any samples throughout a single day. 3-12 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 It is important to recognize that travel times from AVI sensors are based on differences in time stamps for vehicles passing two AVI detectors. The system computes travel times for segments defined by two sensors positioned at the segment's beginning and ending points. For example, sensors A and B define segment A–B. The number of vehicles measured at each sensor can be written as nA and nB respectively, and the number of matched vehicles over segment A–B as nA–B. As a rule: 36 Imputing Travel Times for Missing or Bad Vehicle-Based Sensor Data 37 38 39 40 41 42 43 The fact that vehicles can be traced from one AVI sensor to another provides additional ways to impute travel times not available for infrastructure-based sensors. If vehicle-based sensor B is broken, it may no longer be possible to measure travel times from A to B or B to C, but it is still possible to measure travel times from A to C. Thus, with vehicle-based sensors, malfunctions impact the spatial granularity of reported travel times, but not their accuracy. The idea of “super segments” is the best way to impute travel times (and travel time distributions) for segments whose endpoint detector is malfunctioning. Figure 3-7 illustrates this nAB  min(nA , nB ) Equation 3-5 If either sensor is broken or there is little to no traffic equipped for sampling, then nA  0 or nB  0 , and therefore nAB  0 . There are three scenarios for which a vehicle-based sensor pair would report no travel time data:    Either or both sensor A and B are malfunctioning; No equipped vehicles passed by A or B during the time period; or No vehicle was matched between A and B during the time period. For the calculation of travel times, the consequence of a malfunctioning sensor and few to no equipped vehicles at the sensor are identical: there are not enough data points to calculate the travel time summary statistics for the segment during the time period. Similar to the individual sensor malfunction test, a segment can be considered to be broken on day d if its sensors do not report any samples throughout the day. This "missing" data case is straightforward to detect. It is more difficult to handle the case when there are too few data points to construct meaningful travel time trends. For example, if only one data point per hour is observed over a 24-hour period, detailed 5-minute or hourly travel time trends cannot be recovered. Such data sparseness is expected during night when traffic volumes are actually low, and does not cause problems during these free-flow periods. But such data sparseness is not acceptable during peak hours in urban areas. As such, the system should employ a test for data sparseness. A segment A–B can be considered to have sparse data on day d if the total number of samples throughout the day is less than a specified threshold (for example, 200 samples per day). This approach looks at an entire day of data to determine where sensors are broken and data is sparse. More granular approaches are also possible, such as running the above test for individual hourly periods. However, more granular tests would have to use varying thresholds based on the time of day and day of the week to fit varying demand patterns. 3-13 1 2 3 idea. If AVI detector B is broken, the super segment A–C provides a way to impute vehicle travel times for both segments A–B and B–C. 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 When all three detectors are working properly, regression equations can be developed that predict the travel times for A–B and B–C based on the travel time for A–C. Then, when detector B is malfunctioning, these equations can be used to impute individual vehicle travel times (or the average or some other percentile value such as the median) based on the travel time observations between A and C. The same idea applies to the segments B–C and C–D if detector C is malfunctioning, only there are two super-segments that could be used to impute the missing values (i.e., super segments A–D and B–D). The super segment that is the best predictor of the travel times on the subject segment (i.e., which might be either B–C or C–D) should then be used to impute the missing travel times. Where infrastructure-based detection is present, one can use the point speeds (spot rates) from those sensors to adjust and/or cross-check the imputed distribution of travel times. Also, equations (e.g., regression) can also be developed to use the system detector data directly in doing this. (Of course, the infrastructure-based point speeds can be used directly to estimate average travel times for the subject segments.) A temporal median approach, equivalent to the one described for option 3 for infrastructure-based imputation, can also be used. A temporal median is the median of the historical, non-imputed route travel time values reported for that segment for the same day of week and time of day over the most recent ten weeks. As a general rule of thumb, if more than 50 percent of the data are imputed, the results can have questionable validity. 26 SEGMENT TRAVEL TIME CALCULATIONS 27 28 29 30 31 Ultimately, the TTRMS needs to have segment travel times; and from the segment travel times, route travel times. Moreover, these travel times are needed both on a longitudinal basis (for the same points in time each day across months, seasons and years) and on a cross-sectional basis (for multiple vehicles, or perhaps even multiple segments and routes at the same point in time). This section describes how to develop the segment travel times. 32 Infrastructure-Based Sensors 33 34 35 Infrastructure-based sensors typically collect observations at a single location in the network. Examples are single- and double-loop detectors, radar detectors, and video detectors. The sensors all see individual vehicle inputs, but they report out only sums (volumes) and Figure 3-7: Super Segment Examples 3-14 1 2 3 averages (e.g., average occupancies and speeds). Perhaps at some time in the future, these devices will report other statistics for the observed inputs (perhaps even a PDF), but that capability does not exist today. 4 Estimating Spot (Time-Mean) Speeds (for Single Loop Detectors) 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 In the case of many point sensors, the speeds are directly observed and averages of those speeds are periodically reported out by the device. But in some cases, the speeds are not directly observed and must be estimated. This is typically the case for single-loop detectors. Estimation of the average speed is then done by using a "g-factor", which uses an assumed average length of vehicle to estimate the average speed value from the flow and occupancy data using the below equation: flow 1 speed   Equation 3-6 occupancy g Here, (1/g) is the average effective vehicle length, which is equal to the sum of the actual vehicle length and the width of the loop detector. At a given loop, the average vehicle length will vary by time of day and day of the week due to truck traffic patterns. For example, trucks make up a larger percentage of traffic in the early morning or midday hours in urban regions, while automobile traffic dominates during commute hours. Vehicle length is also dependent on the lane of the loop; loops in the right-most lanes will typically have longer lengths than those in the lefthand lanes since trucks usually travel in the right lanes. Despite this variability, most agencies use a constant g-factor that gets applied across all loops and all time periods in a region. Analysis of this approach has shown that it can introduce errors of up to 50% into speed estimates (2). Since average travel time computations require the aggregation and extrapolation of multiple loop detector speed estimates, this has ramifications for the reliability of calculated average travel times. As such, agencies are advised to implement methods that account for the time- and location-dependency of the g-factor. The g-factors can be estimated for each time of day and individual detector using a weeks-worth of detector data. By manipulating the above equation to make speed the known variable and the g-factor the unknown variable, g-factors can be estimated for all free-flow time periods. Free-flow conditions can be identified in the data as time periods where the occupancy falls below 15%. For these conditions, free-flow speeds can be approximated based ideally on speed data obtained from the field for different lanes and facility types. An example of speeds by facility type, lane, and number of lanes derived from double-loop detectors in the San Francisco Bay Area is shown in Table 3-2. Using the assumed free-flow speeds, g-factors can be calculated for all free-flow time periods according to the below equation: k (t ) *T g (t )  V free Equation 3-7 q(t ) where:  g(t) is the g-factor at time of day t (a 5-minute period),  k(t) is the observed occupancy at t,  q(t) is the observed flow at t,  T is the duration of the time-period (for example, 5 minutes), and  Vfree is the assumed average free-flow velocity. 3-15 1 2 3 4 5 Table 3-2: Example of Measured Speeds by Lane, San Francisco Bay Area # of Lanes Lane 1 HOV 1 65 HOV 2 65 ML 1 65 ML 2 71.2 65.1 ML 3 71.9 69.7 62.7 ML 4 74.8 70.9 67.4 62.8 ML 5 76.5 74.0 72.0 69.2 64.5 ML 6 76.5 74.0 72.0 69.2 64.5 64.5 ML 7 76.5 74.0 72.0 69.2 64.5 64.5 Type 6 7 8 9 10 11 12 13 14 15 Lane 2 Lane 3 Lane 4 Lane 5 Lane 6 Lane 7 65 64.5 Applying this equation to the data transmitted by a loop detector over a typical week yields a number of g-factor estimates at various hours of the day for each day of the week, which can be formed into a scatterplot of g-factor versus time. To obtain a complete set of g-factors for each 5-minute period of each day of the week, the scatterplot data points can be fitted with a regression curve, resulting in a function that gives a complete set of g-factors for each loop detector. An example of this analysis is shown in Figure 3-8. Figure 3-8: Example of Five-Minute g-Factor Estimates at a Detector 3-16 1 2 3 4 5 6 7 8 9 10 11 In the figure, the dots represent g-factors directly estimated during free-flow conditions, and the line shows the smooth regression curve (3). The 5-minute g-factors from the regression function can then be stored in a database for each loop detector, and used in real-time to estimate speeds from flow and occupancy values. An example of the g-factor functions for the detector in the left-most lane (Lane 1) and the right-most lane (Lane 5) of a freeway in Oakland, California, is shown in Figure 3-9. As is evident from the plot, the g-factors in the left-lane are relatively stable over each time of day and day of the week, but the g-factors in the right-lane vary widely as a function of time. These g-factors should be updated periodically to account for seasonal variations in vehicle lengths, or changes to truck traffic patterns. It is recommended that new g-factors be generated at least every three months. 12 13 14 Figure 3-9: Example Estimates of g-Factors at a Detector (I-880 North, Oakland, CA) 3-17 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Estimating Segment Travel Times from the Average Speeds Traffic monitoring systems typically assign short segments of the highway network to each point sensor. (These segments can be the segments by which travel time reliability is monitored, or aggregations of these short segments may form the TTRMS segments.) The sensor-related segments often extend from midway to the upstream detector to midway to the downstream detector. This practice is illustrated in Figure 3-10, where the segments assigned to 10 point sensors are shown. As can be seen, this midpoint-to-midpoint designation is common, but there are exceptions, as in the case of the detector highlighted in the middle by the red triangles, where the entire six-lane section is assigned to that detector and in the case of the first detector to the right of milepost 7.12, which is at the eastern end of the six-lane section, but the entire six-lane section is assigned to it. Hence, this discussion focuses on how to develop average travel times for these point-sensor-linked segments. 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 For these infrastructure-based detectors, the process of calculating segment average travel times from raw data requires (1) estimating spot speeds from the raw data; and (2) transforming these speed estimates into segment travel times. Almost all estimation methodologies today compute mean speeds by dividing the sum of the speed observations by the number of data points observed. This value is then inverted to obtain the average travel rate (spot rate) at that location of the sensor; and that rate is multiplied by the segment length to obtain an estimate of the travel time for the segment. A shortcoming of this technique is that it misses the effects of bottlenecks or other influencing factors, such as on-ramps, that produce nuances in the travel speed across the segment. An important aside is that the median travel rate is actually a more useful and stable statistic, although it is not often employed. It is less sensitive to the impacts of outliers. One can diminish the impact of outliers by removing them, but this can make it more difficult to fully capture the impacts of incidents and other disruptive events. 33 Estimating Vehicle Travel Times based on Average Travel Times 34 35 36 37 38 39 As indicated earlier, even though the infrastructure sensors observe individual vehicle speeds (or occupancies) they only report averages (speeds and/or occupancies) along with the number of vehicles observed. Consequently, the infrastructure sensors cannot be used directly to generate observations (or estimates) of the individual vehicle travel times across a segment. To do this, separate field observations of the individual vehicle speeds have to be obtained or an assumption must be made about the distribution of those speeds based on similar facilities. There Source: PeMS Figure 3-10: Assignment of Segments to Point Detectors 3-18 1 2 3 4 is a use case that illustrates how to do this. For situations where only the average (or median) travel times are of interest, estimation of these vehicle travel times (and their distribution) can be skipped, but when distributions of segment or route travel times for individual vehicles is the focus of the analysis, then the estimates must be developed. 5 Vehicle-Based Sensors 6 7 8 9 10 11 Vehicle-based sensors directly report individual vehicle travel times, but only for some of the roadway travelers. Hence, in this situation, the main computational steps are to (1) compute segment travel times for individual vehicles by differencing the timestamps reported by the readers at either end of the segment or route; (2) filter out non-representative travel times, such as those involving a stop; and (3) determine if enough valid travel time observations remain to compute an accurate representation of the travel times for the time period of interest. 12 Generating Passage Times for Bluetooth Readers (and other AVI Sensors) 13 14 15 16 17 18 19 20 21 22 23 24 25 It is common for Bluetooth Readers (and other AVI sensors) to observe the same vehicle multiple times while the sensed device is in the vicinity of the reader. However, most of these devices report out only one passage time. Figure 3-11 shows an extreme case for the sequence of readings for a single vehicle (device) obtained by a Bluetooth reader that was located on US-50 between Sacramento and South L