Incorporating Reliability Performance Measures into Operations and Planning Modeling Tools (2014)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

61 FRAMEWORK AND TOOLS FOR TRAVEL TIME RELIABILITY ANALYSIS This part of the report describes the modeling tools and the general methodology/process of how to use the tools and interpret the results. p A r t 2

62 Scenario Manager The Scenario Manager is essentially a preprocessor of simula- tion input files for capturing exogenous sources of travel time variation. Recognizing the importance of the scenario defini- tion and the complexity of identifying relevant exogenous sources, the Scenario Manager provides the ability to construct scenarios that entail any mutually consistent combination of external events. These may be both demand- and supply-related events, including different traffic control plans that may be deployed under certain conditions. Accordingly, it captures parameters that define external sources of unreliability (such as special events, adverse weather, and work zones) and enables users either to specify scenarios with particular historical sig- nificance or policy interest, or to generate them randomly given the underlying stochastic processes with specific characteristics (parameters) following a particular experimental design. The built-in Monte Carlo sampling functionality allows the Scenario Manager to generate hypothetical scenarios for analy- sis and design purposes. When exercised in the latter manner (i.e., in random generation mode), the Scenario Manager becomes the primary platform for conducting reliability analy- ses: experiments are conducted to replicate certain field condi- tions, under both actual and hypothetical (proposed) network and control scenarios. In particular, the Scenario Manager enables execution of experimental designs that entail simula- tion over multiple days, thus reflecting daily fluctuations in demand, both systematic and random. The Scenario Manager also allows users to manage the conduct of reliability analyses by providing an environment for storage and retrieval of previously generated scenarios, through a scenario library approach. The scenario manage- ment functionality allows retrieval of historically occurring scenarios or of previously constructed scenarios as part of a planning exercise (e.g., in conjunction with emergency pre- paredness planning). Given a particular scenario, the Scenario Manager’s main function then is to prepare input files for The travel time reliability analysis framework incorporates two essential tools that provide the capability to produce reli- ability performance measures as output from operational planning and simulation models. The Scenario Manager, an integral component of the overall analytical framework, cap- tures external unreliability sources such as special events, adverse weather, and work zones, and generates appropriate files as input into simulation models. The other key analysis tool is a vehicle Trajectory Processor that calculates and visu- alizes travel time distributions and associated reliability indi- cators (such as 95th percentile travel time, Buffer Time Index, Planning Time Index, frequency that congestion exceeds some threshold) at link, path, O–D, and network levels. The travel time distributions and associated indicators are derived from individual vehicle trajectories, defined as sequence of geographic positions (nodes) and associated passage times. These trajectories are obtained as output from particle-based microscopic or mesoscopic simulation tools. Such trajectories may alternatively be obtained directly through measurement (e.g., GPS-equipped probe vehicles), thereby also enabling vali- dation of travel time reliability metrics generated on the basis of output from simulation tools. It should be noted that both the Scenario Manager and the Trajectory Processor have been developed at a prototype level of detail and functionality for project team use only and are shared with the developer and user community on an “as is” basis. For this reason, they may not meet all requirements of an implementing agency without further development. A prerequisite for the use of these analysis tools is the avail- ability of a particle-based traffic simulation model, capable of producing vehicle trajectory output. It is further assumed that the simulation model is fully calibrated to reasonably simulate traffic flows. For demonstration purposes, the Sce- nario Manager and Trajectory Processor prototypes incorpo- rate interfaces to the Aimsun and DYNASMART-P simulation platforms, as examples of microscopic and mesoscopic tools, respectively. Model and Data Requirements C h A p t e r 5

63 quantify user-centric reliability measures, the experienced travel time and the departure time of each vehicle are extracted from the vehicle trajectory. By comparing the actual and the preferred arrival time, the probability of on-time arrival can be computed. data requirements This section provides a brief discussion of the types of data needed to implement the proposed reliability analysis frame- work. This discussion assumes that a base simulation model is already developed and properly validated, and focuses on (a) data required for the development of scenarios for reliability analysis, and (b) data required to refine/adapt the simulation model and/or to perform travel time reliability analysis based on observed congestion conditions. As indicated, numerous external factors can affect varia- tions in travel time. To consider these factors in the compre- hensive methodology, extensive background data are required. These includes collision data, weather data, and event data encompassing lane closures, work zones, and other incidents affecting normal traffic flow. In addition, historical vehicle traffic volumes and background travel demand for other sce- narios are important in being able to simulate events that may cause changes in travel patterns or the overall level of traffic demand. Desirable data also include trajectory data from GPS or other probe vehicle sources. These data can be processed to provide valuable information regarding actual trip travel times (portions of trips) through the study area, thus allowing comparisons to simulated data. Data for Scenario-Based Analysis The reliability analysis framework addresses a number of sources of travel time variability under both recurring and nonrecurring congestion conditions, whether these affect the demand or supply side of the transportation system, in a ran- dom or systematic manner, endogenously or exogenously to the involved modeling tools. In general, data are needed to parameterize factors that will be captured endogenously in the model(s), whether on the demand or supply side of the system. For example, speed, flow, and occupancy data can be used to describe character- istics relevant to flow breakdown conditions (jam density, and so forth); locations, time, and pricing applicable by vehi- cle class and type (truck, bus, high-occupancy vehicle/single- occupancy vehicle) would be needed to incorporate dynamic pricing schemes; event logs and observed or estimated com- pliance rates may also be needed to capture user responses to information and control measures. For the proposed scenario-based analysis in particular, data are needed to generate scenarios for factors causing travel time mesoscopic/microscopic simulation models. In addition, the Scenario Manager can facilitate direct execution of the simulation software for a particular scenario, by creating the necessary inputs that reflect the scenario assumptions. An especially important and interesting feature of a well- configured Scenario Manager is that it can be tied into an area’s traffic and weather monitoring system(s). As such, particular scenario occurrences could be stored when they materialize, with all applicable elements that define that scenario, especially demand characteristics and traffic control plans triggered for that scenario. For example, if Houston experiences major rain- fall with extensive flood-like conditions, that scenario could be stored in terms of the events and exogenous parameter values as such. With a properly configured Scenario Manager inter- faced with the data warehousing system at a given traffic man- agement center, it would then be possible to extract the relative occurrence probabilities and distribution functions, which would then allow calibration of these external event scenarios to actual observations. Considerable sophistication and func- tionality could be introduced in such a process over time, as the historical data records increase in quantity, quality, and com- pleteness and allow robust estimation of occurrence probabili- ties of otherwise infrequent events. trajectory processor The vehicle Trajectory Processor is introduced to extract reliability-related measures from the vehicle trajectory out- put of the simulation models. It produces and helps visualize reliability performance measures (travel time distributions, indicators) from observed or simulated trajectories. Indepen- dent measurements of travel time at link, path, and O–D level can be extracted from the vehicle trajectories, which allow for constructing the travel time distribution. From the system operator’s perspective, reliability perfor- mance indicators for the entire system allow comparison of different network alternatives and policy and operational scenarios. This could facilitate decision making in regard to actions intended to control reliability and evaluation of sys- tem performance. Reliability measures (such as 95th percen- tile travel time, Buffer Index, Planning Time Index, frequency that congestion exceeds some expected threshold) can be derived from the travel time distribution or, alternatively, computed directly from the travel time data. In addition to the reliability performance indicators, it is essential to reflect the user’s point of view, as travelers will adjust their departure time, and possibly other travel deci- sions, in response to unacceptable travel times and delays in their daily commutes. User-centric reliability measures describe user-experienced or perceived travel time reliability, such as probability of on time arrival, schedule delay, and vol- atility and sensitivity to departure time. In particular, to

64 Trajectory Travel Time Data and Sources The specific analysis approach in the proposed reliability evalu- ation framework requires a special type of travel time data, which was not available until recent technological develop- ments made this possible. In particular, the requirement for trajectory-based travel times for individual vehicles, which are then analyzed over their time and space dimensions and various aggregate metrics, may almost exclusively be satisfied by vehicle probe data. As the proposed reliability evaluation framework is based on travel times reported (and/or estimated) on a per vehicle trajectory basis, the travel time data required to support this research need to satisfy the following trajectory information requirements: • Report travel times by vehicle trip on a trajectory basis; at a minimum provide X-Y coordinates and time stamp at each reported location. variability due to supply-side changes that need to be addressed exogenously to the models through the Scenario Manager. Such data should include information about incidents (ideally including severity of incident and length of time), special events (type, location, time/date, duration), weather condi- tions, and work zones. In addition, before-after studies for major planned events can be helpful. Similarly, depending on the scenarios to be addressed in the reliability analysis, data are needed for the Scenario Manager to address demand-side changes (e.g., attendance at a special event, visitors to a special place, or closure of alternative modes). Table 5.1 provides a summary of data that could be used to generate scenarios for certain exogenous factors. Such data are typically available through transportation authorities that manage, control, or simply monitor transportation systems in an area, or through other third parties (e.g., metrological service for weather conditions) if additional detail is needed for modeling purposes. Table 5.1. Typical Data Requirements for Development of Scenarios for Travel Time Reliability Analysis event type Data Requirements Incident • Type (e.g., collision, disabled vehicle) • location • date/time of occurrence and time of clearance • Number of lanes/shoulder affected and length of roadway affected • Severity in case of collision (e.g., damage only, injuries, fatalities) • weather conditions • Traffic data in the area of impact before and during the incident (e.g., traffic flows, speed/delay/travel time measurements, queues and other performance measures or observations, if available) Work zone • work zone activity (e.g., maintenance, construction) that caused lane/road closure, and any other indication of work zone intensity • location and area/length of roadway impact (e.g., milepost); number of lanes closed • date/time and duration • lane closure changes and/or other restrictions during the work zone activity • weather conditions • Special traffic control/management measures, including locations of advanced warning, speed reductions • Traffic data upstream and through the area of impact, before and during the work zone (e.g., traffic flows and percentage of heavy vehicles, speed/delay/travel time measurements, queues and other performance measures or observations, if available) • Incidents in work zone area of impact Special event • Type (e.g., major sporting event, official visit/event, parade) and name or description • location and area of impact (if known/available) • date/time and duration • Event attendance and demand generation/attraction characteristics (e.g., estimates of out-of-town crowds, special additional demand) • Approach route(s) and travel mode(s), if known • Road network closures or restrictions (e.g., lane or complete road closures, special vehicle restrictions) and other travel mode changes (e.g., increased bus transit service) • Special traffic control/management measures (e.g., revised signal timing plans) • Traffic data in the area of impact before, during, and after the event (e.g., traffic flows, speed/delay/travel time measurements, queues and other performance measures or observations, if available) Weather • weather station Id or name (e.g., klgA for the automated surface observing system station at laguardia Airport, Ny) • Station description (if available) • latitude and longitude of the station • date/time of weather record (desirable data collection interval: 5 minutes) • visibility (miles) • Precipitation type (e.g., rain, snow) • Precipitation intensity (inches per hour, liquid equivalent rate for snow) • other weather parameters: temperature, humidity, precipitation amount during previous 1 hour, etc. (if available)

65 • Provide travel time at disaggregated levels (e.g., vehicle travel time) and at fine time intervals (e.g., link/path travel time for every 5 minutes), in addition to average travel times, to capture time-of-day variation and vehicle-to- vehicle variation. • Provide sufficient information on components, causes, and other characteristics of congestion, so that appropriate parameterization can be established for simulation testing purposes. The emergence of probe data over the past few years has opened the opportunity to capture all necessary information for this type of analysis, since such data can be available all the time for all major roads in the network including major arteri- als. Probe-based trajectory data represent a significant increase in the quality and quantity of relevant information. The detail in such data makes it possible to analyze travel time data according to network and route components (e.g., on a link and path basis) as well as according to geographic aggrega- tions (e.g., on an O–D zone basis). • Capture both recurring and nonrecurring congestion on a range of road facilities (from freeways to arterial roads and possibly managed lanes). • Represent sufficient sampling and time-series to allow statistically meaningful analysis. • Provide the ability to tie travel time data to other ancillary data for time variability sources (to allow parameterization for simulation testing purposes as discussed earlier). Furthermore, the trajectory data should ideally possess the following general characteristics for travel time reliability analysis: • Capture both types of congestion (recurring and nonrecurring). • Cover the range of road facilities that may be included in the subject area analysis from freeways to arterial roads and (possibly) managed lanes. • Allow statistically meaningful analysis of data through availability for a relatively long period of time (e.g., a time frame long enough to cover seasonal variation).

66 Introduction Purpose and Objectives Distinguishing exogenous sources of variation both on the demand and the supply sides from endogenous sources of variation lie at the foundation of this conceptualization and approach. It should be recognized, however, that unlike regimes, which are typically mutually exclusive states with distinct properties of a physical system, these sources of vari- ation can operate simultaneously and often will. In other words, incidents may well occur during times of otherwise recurring congestion, precipitation may act in concert with a surge in demand or special event, and so on. Therefore, from a modeling standpoint, it is desirable to retain the ability to apply any source of variation that may be applicable in a scenario of interest. Recognizing the importance of the scenario definition and the complexity of identifying relevant exogenous sources, the study adopts the concept of a Scenario Manager, which pro- vides the ability to construct scenarios that entail any mutually consistent combination of external events, both demand as well as supply related, including different traffic control plans that may be deployed under certain conditions. The Scenario Generator also acts in a scenario management role, which allows retrieval of historically occurring scenarios or of previ- ously constructed scenarios as part of a planning exercise (e.g., in conjunction with emergency preparedness planning). It also allows generation, through Monte Carlo sampling, of hypothetical scenarios for analysis and design purposes. Of course, the Scenario Manager/Generator facilitates direct exe- cution of the simulation software for a particular scenario, by creating the necessary inputs that reflect the scenario assump- tions. When exercised in the latter manner (i.e., in random generation mode), the Scenario Manager becomes the pri- mary platform for conducting reliability analyses, as experi- ments are conducted to replicate certain field conditions, under both actual and hypothetical (proposed) network and control scenarios. In particular, the Scenario Generator enables execution of experimental designs that entail simula- tion over multiple days, thus reflecting daily fluctuations in demand, both systematic and random. An especially important and interesting feature of a well- configured Scenario Manager is that it can be tied into an area’s traffic and weather monitoring system(s). As such, particular scenario occurrences can be stored when they materialize, with all applicable elements that define that scenario, especially demand characteristics and traffic control plans triggered for that scenario. For example, if Houston experienced major rain- fall with extensive flood-like conditions, that scenario could be stored in terms of the events and exogenous parameter values as such. With a properly configured Scenario Manager inter- faced with the data warehousing system at a given traffic man- agement center, it would be possible to extract the relative occurrence probabilities and distribution functions and to calibrate these external events to actual observations. Consid- erable sophistication and functionality could be introduced in such a process over time, as the historical data records increase in quantity, quality, and completeness and allow robust estima- tion of occurrence probabilities of otherwise infrequent events. Concept of Operations The methodological framework recognizes the different sources of uncertainty that affect the reliability of travel time in the roadway environment. As discussed in Chapter 4, a previous study (Cambridge Systematics, Inc. 2005) identified seven major root causes of travel time variability: (1) traf- fic incidents, (2) work zones, (3) weather, (4) special events, (5) traffic control devices, (6) fluctuations in demand, and (7) inadequate base capacity. Many existing simulation tools view and model these factors as exogenous events using user- specified scenarios (Mahmassani et al. 2009). Distinct from these exogenous factors, there are also endogenous sources of variation that are inherently reproduced, to varying degrees, by C h A p t e r 6 Scenario Manager

67 encompassing any systematic variations. While exogenous sources of variation are captured through scenarios by the Scenario Manager, endogenous variation sources are captured in the traffic simulation model, depending on the modeling capability of the selected tool. In this framework, the traffic simulation models refer to particle-based models, namely, microscopic and mesoscopic simulation models (Chang et al. 1985; Mahmassani 2001) that produce individual vehicle (or particle) trajectories. Regardless of the specific reliability measures of interest, to the extent that they can be derived from the travel time distribution, the availability of particle trajectories in the output of a simulation model enables construction of any level of travel time distributions of interest (e.g., network- wide, O–D, path, and link). As such, the key building block for producing measures of reliability in this framework consists of particle trajectories and the associated experi- enced traversal times through entirety or part of the travel path. Tasks such as converting simulated trajectories into various reliability measures are performed by the Trajectory Processor. The latter obtains the scenario-specific travel time given traffic simulation models. Many studies have proposed ways to capture random variation in various traffic phenom- ena within particular micro- or mesosimulation models. Exam- ples include flow breakdown (Dong and Mahmassani 2009), incidents due to drivers’ risk-taking behaviors (Hamdar and Mahmassani 2008), and heterogeneity in driving behaviors (Kim and Mahmassani 2011). Based on this identification, this study establishes a con- ceptual framework for modeling and estimating travel time reliability using simulation models. As shown in Figure 6.1, the framework features three components: Scenario Manager, traffic simulation model, and Trajectory Processor. The pri- mary role of the Scenario Manager is to prepare input sce- narios for the traffic simulation models, which is a core part of this framework as it directly affects the final travel time distributions. Once the Scenario Manager generates a set of input scenarios, which represent any mutually consistent combinations of demand- and supply-side random factors, these scenarios are simulated in a selected traffic simulation model in conjunction with average demand obtained at a demand-supply equilibrium point under normal conditions Supply-side - Weather, Incident, Work zone - Traffic control, Dynamic pricing Demand-side - Day-to-day variation - Special events - Schedule adjustment Exogenous Sources of Variability SCENARIO MANAGER TRAJECTORY PROCESSOR TRAFFIC SIMULATION MODELS Demand-side Scenarios Supply-side Scenarios Average Demand Scenario-based Input Files Microscopic/ Mesoscopic Traffic Simulation Scenario-specific Travel Times Travel Time Distribution/ Reliability Measures - Flow breakdown - Drivers’ risk-taking behaviors and endogenous collision - Heterogeneity in driving behaviors - State-dependent traffic control Endogenous Sources of Variability Std. Dev., Coeff. of Var. Median, 95th percentile Buffer Index, Misery Index, Planning time index, Travel time index, Probability of on-time arrival Reliability Performance Indicators Obtained at a demand-supply equilibrium point under normal conditions encompassing any systematic variations Figure 6.1. Core elements of reliability modeling framework.

68 distribution from each simulation run and constructs the overall travel time distribution aggregated over multiple scenarios. While chaining these three modules completes the neces- sary procedures for performing a scenario-based reliability analysis, there are two feedback loops worth mentioning to further incorporate behavioral aspects of travelers into the reliability modeling framework. The inner loop in Figure 6.1 suggests that information from scenario-specific travel times might be used to make scenario-conditional demand adjust- ments (e.g., departure time change under severe weather condition). The outer loop indicates that the overall system uncertainty might affect the average demand by shifting the equilibrium point (i.e., reliability-sensitive network equilib- rium) based on travel demand forecasting models that pre- dict the impact of reliability measures on travel patterns (e.g., Zhou et al. 2008; Jiang et al. 2011). Methodology for Scenario-Based reliability Analysis Using Simulation tools Scenario-Based Reliability Analysis This section elaborates on the basic idea of the scenario- based reliability analysis within the aforementioned frame- work. Conceptually, the traffic simulation models can be viewed as an input-output function, in which inputs are sce- narios that represent exogenous sources of roadway disrup- tions and outputs are travel time distributions experienced by travelers under such disruptions. The objective of the sce- nario-based reliability analysis is to investigate variability in the output travel time distribution by controlling the input scenario (i.e., input scenarios can be generated completely at random or in a more directed manner based on a particular experimental design). In this equation, endogenous sources of random variations are not part of control variables as those are considered as part of the traffic simulation model logic. To enhance understanding and conceptualization of pro- cesses, the mathematical representation of the basic concept of this analysis is presented. Let X denote a vector of exogenous sources of random variation (e.g., weather, incident, day-to-day demand varia- tion) that is selected as scenario components to characterize input scenario and let Xj represent the jth element of X. Each scenario component itself is also a vector of several attri- butes describing temporal (e.g., start-time and duration), spatial (e.g., event location), and state (i.e., intensity or con- dition) aspects of a given demand- and supply-side factor. Let Si denote the ith input scenario, which is the ith realiza- tion of the set of scenario components X, that is, Si = X(i) = {X1 (i), X2 (i), . . . , XJ (i)}. Consider we have N input scenarios S1, S2, . . . , SN drawn from a joint distribution of X. Then the output travel time distribution for each scenario is obtained by Equation 6.1: , 1, . . . , 6.1T H S i Ni i( ) ( )= = where Ti represents a collection of travel time t for a given O–D/path/link of interest under the ith scenario Si, and H(z) denotes a black-box representation of a traffic simulation model. Let fi(t) denote the probability density function of scenario-specific travel times under Si such that {t ∈ Ti: t ~ fi(t)}. Then the main goal of the analysis is to obtain the probability density function of overall travel times f(t) based on the scenario-specific travel time distributions fi(t). By knowing the probability of each scenario occurring, f(t) can be calculated by the weighted sum (i.e., convex combi- nation) of scenario-specific travel time distribution fi(t) as follows in Equation 6.2: 6.2 1 f t w f ti i i N∑( ) ( ) ( )= = where wi denotes the weight of the ith scenario with Σni =1wi = 1, which is typically obtained from the scenario probability wi = P(Si). Figure 6.2 presents a schematic diagram to illus- trate the procedure of constructing the overall travel time distribution based on this concept. Approaches to Assessing Reliability Travel time reliability is a relative concept in that it depends on the temporal and spatial boundaries for which travel times are observed. For example, the travel time reliability for week- days is different from that for weekends on the same road network. Therefore, defining time and space domains needs to precede assessing reliability. In general, the time domain is specified by a date range of the overall time period (e.g., 6/1/2012–8/31/2012), day of week (e.g., Monday–Friday), and time of day (6 a.m.–10 a.m.). Or the time domain could be a specific season or day of each year (e.g., Thanksgiving Day). The space domain defines at which level travel times are collected and the reliability measures are calculated (e.g., network-level, O–D-level, path-level, and link-level). Two dif- ferent approaches are explored to assess the travel time reli- ability for given time and space domains: (1) Monte Carlo approach and (2) mix-and-match approach. The former tries to generate all possible scenarios that could occur during the given temporal and spatial boundaries to introduce realistic variations in the resulting travel time distribution; the latter constructs scenarios by manually choosing various combina- tions of scenario components. These approaches are dis- cussed in more detail.

69 Monte Carlo Approach This approach uses Monte Carlo simulation to prepare input scenarios aimed at propagating uncertainties in selected scenario components X into uncertainties in the generated scenarios Si (i = 1, . . . , N), which can be, in turn, translated into the resulting travel time distribution. As depicted in Figure 6.3, the Scenario Manager performs Monte Carlo simulation to generate hundreds or thousands of input scenarios by sampling from the joint probability distribution of scenario components. Each scenario is equally likely, thus allowing the Trajectory Processor to sim- ply aggregate travel time distributions from a large number of simulation runs to obtain the most likely (probable) out- come of a set of reliability performance indicators for the given time and space domains. Mix-and-Match Approach Instead of generating scenarios randomly given the underly- ing stochastic processes, one could explicitly specify scenarios with particular historical significance or policy interest. The mix-and-match approach aims to construct input scenarios in a more directed manner either by mixing and matching possible combinations of specific input factors or by directly using known historical events or specific instances (e.g., holi- day, ball game). Figure 6.4 shows a schematic diagram illus- trating this approach with a simple example. Consider two scenario components—collision and heavy rain—where each component has two discrete states—occur and not occur. From the Cartesian product of two components’ states, four possible scenario groups are defined as shown in the figure. Suppose that we have a representative scenario for each group with the scenario probability assigned based on the joint prob- ability of collision and heavy rain events. Then a probability- weighted average of travel time distributions under all four scenarios can be used as the expected travel time distribution to approximate the overall reliability measures. A more infor- mative use of this approach is to understand the impact of a particular scenario component on travel time variability by investigating gaps between different combinations of output results. Combined Approach Unlike the simple example in Figure 6.4, however, it is often necessary to allow randomness in scenarios within each group, especially when there is no predefined representative scenario. It is also possible to have no probability value for each scenario group known to users. In both cases, the Monte Carlo approach can be used in conjunction with the mix- and-match approach—that is, sampling random scenarios from their conditional distributions given each group (for the former); and generating a large number of scenarios for the entire scenario space and categorizing them into the Rain Collision Time Intensity Space Scenario 1 (S1) Simulation Run Travel Time (t ) Scenario-specific Travel Time Distribution Travel Time (t ) P(S1) : Probability of S1 P(S2) P(SN) Aggregated Travel Time Distribution Collision Work zone Scenario 2 (S2) Scenario N (SN) N Generated Input Scenarios f1(t) f2(t) f(t) fN(t) Intensity Intensity Space Space Time Time Travel Time (t ) Travel Time (t ) Figure 6.2. Schematic illustration of constructing travel time distribution based on scenario-specific simulation outputs.

70 Realization N : Work zone (SN) Realization 3 : No event (S3) Realization 2 : Incident (S2) Realization 1 : weather+incident(S1) …… Traffic Simulation Output (t |S2) Output (t |S3) Output (t |SN) Output (t |S1) …… Generate random scenarios by drawing from distributions of input parameters; Si = {weather(X1(i)), incident(X2(i)), … , work zone(XJ(i))}, i =1, …, N Travel time distribution aggregated over multiple random scenarios Overall travel time reliability for given time and space domains Trajectory Processor Traffic Simulation Model Scenario Manager Figure 6.3. Monte Carlo approach. Traffic Simulation Output (t |S2) Output (t |S1) Impact of heavy rain on travel time variability when there is no collision P(S2) P(S1) Normal day Scenario (S1) Heavy Rain only Scenario (S2) Collision only Scenario (S3) Collision and Heavy Rain Scenario (S4) Output (t |S3) Output (t |S4) P(S4) Trajectory Processor Traffic Simulation Model Scenario Manager No Collision Collision Define scenario groups based on different combinations of uncertainty factors and prepare scenarios for each group with the associated probability. No Heavy Rain S1 S3 Heavy Rain S2 S4 P(S3) Probability-weighted average of travel time distributions under multiple scenarios Figure 6.4. Mix-and-match approach. associated groups to obtain the group probabilities (for the latter). Generating Scenarios Considering Dependencies One of the practical issues in generating scenarios is consid- ering dependencies in various random factors. As represented by the dotted arrows in Figure 6.5, certain scenario compo- nents are dependent on other components. Incident occurrence is the most prominent example in which event properties (e.g., frequency, duration, and severity) tend to be affected by weather and other external events. The team investigated weather-conditional incident rates (incidents/hour/lane- mile) by measuring the number of incidents during the total period of time exposed to different weather conditions using historical incident data collected from 2007 to 2010 in Chicago, Illinois. As shown in Figure 6.6, incident rates tend to increase as the severity of rain or snow events increases. In addition to incidents, dependencies are also observed on the traffic

71 Independent Weather Planned Special Event Scheduled Traffic Control Incident Work zone Incident Management Strategies Weather-responsive Traffic Management (WRTM) Strategies Extra Demand/ Schedule Adjustment Day-to-day Random Variation Sc en ar io G en er at io n Pr oc es s A affects B; the attributes of B are dependent on the attributes of A. A B Supply-side Demand-side Dependent Figure 6.5. Various scenario components and dependency relations. 0 0.0005 0.001 0.0015 0.002 0.0025 0.003 0.0035 0.004 0.0045 Clear Light Rain Moderate Rain Heavy Rain In ci de nt Ra te (# in ci de nt s/ hr /l an e m ile ) Weather Condition Mean 2007 2008 2009 2010 (a) (b) 0 0.0005 0.001 0.0015 0.002 0.0025 0.003 0.0035 0.004 0.0045 Clear Light Snow Moderate Snow Heavy Snow Weather Condition Mean 2007 2008 2009 2010 Figure 6.6. Weather-conditional incident rates (Chicago incident data, 2007–2010). (a) = rain; (b) = snow. management side: weather-responsive traffic management (WRTM) strategies are deployed based on types and severities of weather events (Mahmassani et al. 2012); and traffic inci- dent management is triggered by incident events. In the Sce- nario Manager, such dependencies are taken into account during the generation process. Once the scenario compo- nents of interest are defined, it identifies dependency relations between components and derives a generation order such that components that affect others are generated before their dependent ones. Following the generation order, the Scenario Manager generates each component sequentially (e.g., weather → incident → incident management) so that each component is sampled from its distribution conditioned on all the previously sampled components.

72 Implementation of Scenario Manager The main role of the Scenario Manager is to prepare a set of scenarios that will be used as input to the traffic simulation models. The implementation of the Scenario Manager is done in two steps: scenario specification and scenario generation. The following sections describe each step. Scenario Specification In the scenario specification step, the user mainly defines a high-level design for the reliability analysis and parameter set- tings for the scenario generation. Various tasks entail defining the spatial and temporal boundaries for which travel time vari- ability is examined (e.g., a specific road section on weekdays) as well as the time-of-day selection for the scenario time horizon (e.g., morning peak period between 8 a.m. and 10 a.m.), deter- mining the analysis approach (e.g., Monte Carlo sampling approach versus what-if scenario approach), and selecting sce- nario components of interest (e.g., weather, collision, demand variation). Depending on the scenario component, the user might collect historical data to describe probability distribu- tions of input parameters for attributes like frequency, duration, and intensity. Structure of Scenarios Throughout this document, a set of terminologies is used to describe different components in the structure of scenarios, some of which are shown in Figure 6.7. In what follows, a definition of each terminology is provided. Project. A project is a high-level plan that defines temporal and spatial boundaries for which the travel time variability is examined and other necessary settings required to generate scenarios. Based on the boundaries, the user will collect the historical event data, determine the scenario components, and obtain the necessary information such as event fre- quency, duration pattern, available states, and so on. As such, the scope of each project represents a specific study area and time period of interest. For example, the user will create one project to study the reliability of a specific road section dur- ing morning peak hours on weekdays. If the user wants to study the reliability of the same road section under a different temporal background, another project will be defined. Scenario group (or scenario case, scenario category). This is a simplified representation of a group of scenarios with some common features. The scenario group is used to classify indi- vidual scenarios with high dimensional attributes into pre- defined representative groups, in which scenarios belonging to each group are considered to be similar and to share the same probability of occurrence. Under a given project, several sce- nario groups would be defined for the purpose of experimental design. For example, the user could mix and match different combinations of scenario components to define scenario groups as shown in Figure 6.8: Scenario Group 1 represents sce- narios containing the weather event (rain) and signal control; Scenario Group 2 represents scenarios containing rain, signal control, and trip cancelation; and so on. Each scenario group is assigned the probability of occurrences either during the gen- eration process or manually by the user. If the user samples a certain scenario from a specific scenario group with the prob- ability of, say, 0.3 and simulates it using traffic simulation mod- els, then the travel time distribution from the simulation output will be considered to represent the travel time distribu- tion that occurs 30% of the time in the study area. Scenario. A scenario is a sequence of event instances. Typi- cally one scenario represents a single day; the length of the “day” depends on the time horizon for the traffic simulation (e.g., 8 a.m.–11 a.m. for morning peak). Based on the scenario components defined for the scenario specification, zero or more instances of each event will be included in the generated scenario. Figure 6.9 provides a simplified representation of a generated scenario, in which instances of snow, collision, and work-zone events are displayed on a time-space diagram as an example. Scenario component. A component that constitutes a sce- nario. Types of scenario components include all the exogenous factors of roadway environment: 1. For external events: weather, incident, work zone, and special event; 2. For traffic management strategies: variable message signs (VMS), signal control, ramp metering, and pricing; and 3. For travel demand-side factor: day-to-day variation and schedule adjustment. Project Scenario Group Scenario Group Scenario Scenario : Scenario : Scenario Scenario : Event Event Event : Event Figure 6.7. Structure of scenarios.

73 SG 1 External Events Scenario Groups (SG) Traffic Management Demand-side Factors Rain Collision VMS SCENARIO COMPONENTS Weather Work zone Incident Signal Control VMS Pricing Day-to-day Variation Demand Adjustment Signal control Low variation Low variation Work zone Trip cancelation Low variation High variation High variation SG 2 SG 3 SG 4 SG 5 SG 6 SG 7 Figure 6.8. Example of scenario groups. Figure 6.9. Sequence of event instances representing one scenario realization. In general, each scenario component defines multidimen- sional distributions of input parameters that represent tem- poral, spatial, and intensity characteristics of the associated event. For example, generating collision events requires the user to specify the collision scenario component in terms of (1) incident frequency and duration distribution (temporal characteristics); (2) collision location (spatial characteris- tics); and (3) discrete or continuous distribution of capacity loss states (intensity characteristics). State. State is the severity or condition of a given event (e.g., light rain, moderate rain, and heavy rain for the rain event; Type 1 and Type 2 for VMS). For a given event variable, a set of states are defined such that states are mutually exclu- sive and exhaustive; therefore, the sum of the probabilities that one of the specified states will happen is one. For instance, if the user defines an event variable named “Rain,” possible states might be {No Rain, Light Rain, Moderate Rain, Heavy Rain}. If the user defines the event variable in a more aggre- gate way, say “Weather,” then the possible states might be {No Precipitation, Rain, Snow}. As such, how coarse or fine the state categorization is completely depends on the experimen- tal design for the study and also on the availability of the data for calculating the probability of each state. Event (or event instance). An event is an instance (or real- ization) of the scenario component. Each generated scenario consists of a sequence of event instances. The event instance, which is the smallest unit in the scenario structure, contains the information on start and end times (i.e., duration), loca- tion, and selected state, which are determined based on the associated scenario component specification. Figure 6.10

74 illustrates these event attributes in a time-space-intensity dia- gram using an example of a collision event. Scenario Generation Weather Scenario Modeling weather events in a fully parametric manner is a nontrivial task; it requires theoretical models that characterize complex weather phenomena, and identifying such models is beyond the scope of this study. Therefore, the team used a nonparametric sampling approach, in which the historical data are directly used for generating weather scenarios. For example, to construct a 4-hour weather scenario, the team sampled a 4-hour time-series of 5-minute weather observa- tions from an automated surface observing system (ASOS), collected for given space and time domains. This way, the team can preserve the dependency structure between different weather attributes (e.g., precipitation intensity, visibility, duration). Based on the categorization used in ASOS data, seven mutually exclusive and exhaustive states are defined for weather: clear (CL), light rain (LR), moderate rain (MR), heavy rain (HR), light snow (LS), moderate snow (MS), and heavy snow (HS). Each 5-minute data point is assigned one of these states, and the same consecutive conditions are grouped into one event to identify discrete points in time when the weather condition changes, as illustrated in Figure 6.11a. In many cases, the team may focus on networkwide weather scenarios, which assume that the entire network experiences the same time-dependent weather conditions. In such cases, only the temporal distribution of weather events matters, eliminating the need for modeling their spatial distribution. Incident Scenario While weather is modeled nonparametrically, we model inci- dents parametrically as a stochastic spatial–temporal point process. The following sections describe detailed methods for characterizing temporal and spatial distributions of incidents in detail. It is noted that these methods are not limited to the mod- eling of incidents but can also be applied to generating other types of events, such as work zone or planned special events, as long as the underlying assumptions for the parametric models can hold. Temporal DisTribuTion The occurrence of incidents is assumed to follow a Poisson process, that is, the probability distribution of the number of incidents occurring in a given time interval is a Poisson dis- tribution. A Poisson random variable is characterized by its Figure 6.10. Properties of event instance. Clear (CL) Light Rain (LR) Heavy Rain (HR) Moderate Rain (MR) Time (a) Weather Time Incident n Incident n+1 Incident n+2 i = 1 wi = CL CL i = 2 wi = LR LR i = 3 wi = HR HR i = 4 wi = MR MR (b) Incident Figure 6.11. Approach to generating correlated weather and incident event (each rectangle represents an event instance in which width and height indicate duration and intensity properties, respectively).

75 rate parameter l, which is the expected number of events that occur per unit of time. As previously mentioned in the report, the incident rate is not constant over time but depends on the prevailing weather condition. To incorporate such a dependency between weather and inci- dent into the scenario generation process, we consider the inci- dent rate as a function of a weather state variable and use it to calculate the conditional probability of the incident, given weather based on the Poisson formula as follows (Equation 6.3): P N t k W w w t e k i i i i k w ti i( ) ( )( ) ( )= = = λ ( )( )− λ | ( ) ! 6.3 where N(t) = number of incidents occurring within the time interval t in a given network, l(W) = mean incident rate under weather condition W (incidents/hour), i = index for a time interval with a homogenous weather condition, ti = length of time interval i (hours), and wi = weather condition (state) during time interval i; wi ∈ {CL, LR, MR, HR, LS, MS, HS}. Equation 6.3 represents the conditional probability distribu- tion of the number of incidents given a weather condition, where the rate parameter is determined based on the given weather. The approach to generating incident scenarios using Equation 6.3 is described as follows and is also illustrated in Figure 6.11b. • Given the weather scenario constructed by the empirical approach discussed previously, identify discrete time inter- vals of varying lengths, where each time interval i is assigned one of seven weather state variables wi ∈ {CL, LR, MR, HR, LS, MS, HS}. • Estimate weather-conditional incident rates l(W) based on historical data W ∈ {CL, LR, MR, HR, LS, MS, HS}. • For each time interval i, obtain the conditional probability distribution of the number of incidents given weather con- dition wi based on l(wi) and the interval length ti using Equation 6.3. Determine how many incidents will occur over the entire network for each time interval i by randomly drawing from the conditional probability distribution; also determine their start-times by randomly distributing the given number of incidents over ti (i.e., the incident occur- rence times are uniformly distributed on that interval). • Assign additional properties such as duration and severity to each incident instance. For example, one could randomly draw the duration of incidents from a gamma distribution and the severity, which is expressed as the number of lanes closed or the percent of link capacity lost, from an empirical probability mass function, respectively. The selection of distribution types and the estimation of the parameters can be done based on the historical data. spaTial DisTribuTion Once the temporal distribution of incident events is deter- mined, the next step is to distribute the generated incidents over the study network (i.e., determine the incident locations). The Scenario Manager provides three different ways of deter- mining the spatial distribution of incidents: (1) distributed based on lane-miles, (2) distributed based on vehicles miles traveled, and (3) distributed based on historical observations. 1. Distributed based on lane-miles. This is the probability that a given incident occurring at a specific link is proportional to the lane-miles of the given link (see Equation 6.4). This method does not take into account the traffic volume on each link. For this type of incident distribution, incident rate l (incidents/hour) for a given area is calculated based on lLM, which denotes the expected number of incidents per hour per lane-mile (incidents/hour/lane-mile), representing the incident rate per unit space for the target region. Thus, l is obtained by multiplying lLM by the total lane-miles for the given area as shown in Equation 6.5. Figure 6.12 shows an example of the spatial distribution pattern of incidents gen- erated using this method. The region with light gray roads is a target area to which incidents are generated, and the triangles represent generated incidents. 2. Distributed based on vehicles miles traveled. This is the prob- ability that a given incident occurring at a specific link is proportional to the average daily vehicle-miles traveled on the given link (see Equation 6.6). This method randomly distributes generated incidents based on the traffic load on each road section so that higher-volume roads have higher collision probability. It also implicitly captures the effect of facility types (e.g., freeway, arterial) in the incident distribu- tion, as different facility types are largely characterized by dif- ferent traffic volume levels. Specifically, this method considers traffic volume as “exposure” in defining the incident rate (i.e., incident rate = incidents/exposure) and uses lVMT, which rep- resents the expected number of incidents per million vehicle miles traveled (incidents/million VMT). The way to obtain incident rate l (incidents/hour) from lVMT (incidents/ million VMT) is presented in Equation 6.7. This method uses the information on the average daily traffic (ADT) for each link so that VMT for each link and the entire target network can be calculated. Figure 6.13 depicts an example of the spatial distribution pattern of incidents generated using this method. In Figure 6.13, incidents are more strongly clustered along freeways compared with the pat- tern in Figure 6.12. 3. Distributed based on historical observations. This method simply uses the actual incident locations observed in the his- torical data as candidate links for the incident distribution.

76 Figure 6.12. Example of spatial distribution pattern of incidents: Distributed based on lane-miles of roads. Triangles = generated incidents; dots = actual (observed) incidents. Figure 6.13. Example of spatial distribution pattern of incidents: Distributed based on vehicle miles traveled (VMT) of roads. Triangles = generated incidents; dots = actual (observed) incidents.

77 This method might be used only when the source region, where the incident data are collected and parameters (e.g., incident rates) are estimated, fully covers the target region, where the incident scenarios will be generated. a m l m l a Aa a a a a A∑ ( ) ( )= ∈ = Pr , 6.4 1 m la a a A∑ ( )λ = λ × = 6.5LM 1 a ADT l ADT l a Aa a a a a A∑ ( ) ( )= ∈ = Pr , 6.6 1 ADT la a a A∑ ( )λ = λ × × =1,000,000 1 24 6.7VMT 1 where Pr(a) = probability that link a is chosen as the event loca- tion for a given incident; A = set of all links in the study network; |A | = total number of links; la = length of link a (mile); ma = number of lanes on link a; ADTa = average daily traffic on link a; ADTa × la = average daily VMT on link a; lLM = expected number of incidents per hour per lane- mile (incidents/hour/lane-mile); and lVMT = expected number of incidents per million VMT (incidents/million VMT). Demand Scenario: Day-to-Day Random Variation To model day-to-day fluctuations in demand, we define a ran- dom variable called the demand multiplication factor (DMF). The demand multiplication factor is a multiplier that is applied to the O–D matrix to uniformly increase or decrease the overall network loading level. For example, DMF of 1.1 results in a 10% increase in the number of trips for all departure time intervals and all O–D pairs given a base-case O-D demand matrix. DMF of 0.95 results in a 5% decrease in the base-case demand; DMF of 1.0 maintains the base-case demand level, and so on. The Scenario Manager allows users to specify the types and param- eters for the probability distribution of DMF, which could be estimated from historical day-to-day demand patterns for the study network of interest. Steps for Using Scenario Manager This section briefly introduces sample steps for generating a set of scenarios using the prototype of the Scenario Manager application developed under this project. Figure 6.14 shows a main window of the Scenario Manager: maps and simulation networks are displayed on the right side, Figure 6.14. Scenario Manager main window.

78 and various database-related tasks are performed in the left panel. The step-by-step procedures for generating scenarios are as follows: Step 1. Define time and space domains. After launching the Scenario Manager application, the user loads a map for the study network in the format of a shapefile (.shp). Pro- vided that the Scenario Manager is populated with histori- cal weather and incident data associated with the selected study network, the user specifies time and space domains for investigating travel time variability (i.e., for obtaining historical patterns and parameters for exogenous random factors such as weather and incidents). Step 2. Estimate input parameters from historical data. For given time and space boundaries, the Scenario Manager estimates necessary input parameters for scenario compo- nents based on historical data. In the current prototype, the parameters include the distribution of weather condi- tions (i.e., clear, light rain, moderate rain, heavy rain, light snow, moderate snow, and heavy snow), incident fre- quency (i.e., incident rate expressed as incidents/hour/ lane-mile), incident duration, and the weather conditional incident occurrence rates (see Figure 6.15). Step 3. Launch scenario generation tool. The user launches a sce- nario generation tool to start the scenario generation pro- cess as shown in Figure 6.16. Launching a scenario generation tool provides a unifying environment for defining various scenario-related settings, generating random scenarios, and sampling input scenarios for traffic simulation. Step 4. Select and specify scenario components. In the scenario generation tool, the user can select which components will be included in the input scenario (see Figure 6.17). For example, the user could choose weather and incident as sce- nario components to generate input scenarios with the combination of various weather and incident events. The tabs represent the available scenario components, which include weather, incident, planned special event, traffic management and control, and demand variation. On each tab, the user can specify input parameters for characterizing the associated scenario component. In general, event prop- erties such as frequency, duration, location, and intensity are specified either parametrically or nonparametrically. Step 5. Generate scenarios. Once all the necessary input param- eters are specified along with the scenario time horizon (i.e., time of day and scenario duration), the user can generate as many scenarios as desired by clicking a button, which starts a scenario generation process using Monte Carlo simulation. All the generated scenarios can be reviewed through a visu- alization tool as shown in Figure 6.18 and Figure 6.19. Step 6. Obtain scenario probabilities. Based on the distribu- tion of scenarios generated in the previous step, the Scenario Manager calculates the probability of any par- ticular scenario that is of concern to the user. This will be used as a scenario weight for aggregating travel time Figure 6.15. Define time and space domains and estimate input parameters from historical data.

79 Figure 6.16. Launch scenario generation tool. Figure 6.17. Select scenario components and generate scenarios.

80 Figure 6.18. Obtain scenario generation results and examine generated scenarios. Figure 6.19. Example of scenario consisting of weather and collision: Temporal profiles represented by “rectangular pulse” with duration (width) and intensity (height).

81 distributions across multiple scenarios in the Trajectory Processor later. Step 7. Export generated scenarios to text file. The user can export detailed descriptions for the generated scenarios to a single text file in the table-like comma-separated value (CSV) file format, as shown in Figure 6.20. This is the main output of the Scenario Manager, which describes the detailed event properties of the generated scenarios, includ- ing temporal attributes (e.g., start and end times), location information (e.g., latitude and longitude), and intensity characteristics (e.g., crash severity or precipitation intensity) of a given event type (e.g., weather, incidents, and demand variation). Because the Scenario Manager is intended to serve as a unifying tool for particle-based traffic simula- tion models regardless of their specific software packages, this output file is designed to have a generic and platform- independent form. That way it can be easily interpreted and converted to the required input format for a specific traffic simulation software package at hand. Step 8. Output scenario files for traffic simulation models. The user can either manually select or randomly sample a set of input scenarios to create software-specific input files for performing traffic simulation runs. The current version of the Scenario Manager produces input files for Aimsun and DYNASMART simulation models based on the selected scenarios. Figure 6.20. Example of Scenario Manager output file.

82 C h A p t e r 7 Introduction To promote the use of end-to-end travel time reliability mea- sures in the professional community for regionwide transpor- tation operations planning, it is important and critically necessary to develop a flexible visualization platform for ana- lyzing microscopic and mesoscopic dynamic simulation results, particularly in tracking vehicular movement, path, and time-dependent trip-related statistics. As a generic visualiza- tion platform for travel time reliability, the vehicle Trajectory Processor designed in this project aims to apply new methods of communication between transportation practitioners, decision makers, and the public. This software package aims to help stakeholders from DOTs and MPOs effectively apply data processing and visualization tools to (1) understand advanced but sophisticated model structures and reliability- related output and (2) use higher fidelity transportation simu- lation and measurement results to estimate and calibrate underlying transportation system processes under different traffic conditions. Purpose and Objectives The objective of the vehicle Trajectory Processor is to provide a visualization platform for tracking and analyzing traffic assignment simulation results with a special focus on system- level travel time reliability. The vehicle Trajectory Processor is designed to perform the following tasks: • Read vehicle trajectory files for each scenario, including an interface that directly imports simulation outputs from DYNASMART and other software packages, such as Aimsun. • Read GPS vehicle trajectory data. • Publish scenario-specific travel time reliability measures and display on the network/Google maps (e.g., most unre- liable O–D, link, path). • Display the aggregate travel time distribution over multiple scenarios by considering the probability of each scenario. • Compare observed and simulated travel time reliability measures. Concept of Operations To meet the design goals, the vehicle Trajectory Processor con- sists of the following basic functioning modules. Map Matching and Vehicle Data Preprocessor Internally, simulated vehicle trajectories (from DTA or micro- simulation) may not contain longitude and latitude infor- mation. In addition, although the GPS trajectories data are recorded in a longitude and latitude coordinate system, this information may not match to the real-world network. Thus, to correctly display the vehicle trajectories on the real-world network, the raw data must be preprocessed by the map matching module to correct geographic location information. As the vehicle trajectory data can come from various sources, including geographically distributed (clouded-based) data- bases, a vehicle data preprocessor must be able to access the data, locally or remotely, and convert various sources of data into a universal data representation for easier processing for the vehicle Trajectory Processor. Vehicle Trajectory Processor The vehicle Trajectory Processor module is the core data fusion component of the software application developed in this research. The inputs to this module include a set of simu- lated vehicle trajectories, generated using different scenarios in traffic simulation software, and GPS vehicle trajectories (both data sources are already preprocessed and converted into a universal format by the vehicle data preprocessed mod- ule). Based on the predefined measure of effectiveness (MOE) Trajectory Processor

83 settings, this module will generate individual scenario-specific O–D travel time statistics (scenario-specific average O–D travel time and standard deviation) and aggregated O–D travel time statistics (aggregated average O–D travel time and stan- dard deviation). It also produces both O–D-level and path- level travel time statistics. Besides these statistics, the vehicle Trajectory Processor module also prepares data for various internal visualization tools to present the results. Statistics Result Presenting and Analysis Module This module provides three styles of user interfaces (UI) to present statistics results to better analyze either O–D-level or path-level travel time. a. Table-based statistic presentation UI. Both O–D-level and path-level travel time statistics (average and standard devia- tion of travel time) are presented in tables. Scenario-specific travel time statistics are listed side-by-side for straight- forward comparisons so that the critical O–D pairs or most unreliable O–D pairs can be easily identified. b. Chart-based statistic presentation UI. The O–D-level travel time distribution is visualized with different graphs: scenario-specific or aggregated probability distribution function (PDF) graph, cumulative distribution function (CDF) graph, and so on. This UI can also display addi- tional travel time reliability indices, for example, Planning Time Index or buffer time. c. Google Earth-based path presentation UI. To view and compare paths, this UI is able to display any possible paths between any O–D pair on Google Earth. With this capabil- ity, it is much easier to identify whether a path is a normal path or a detour. The overall system architecture is illustrated in Figure 7.1. Software description The major software components developed in this research can be described by the universal vehicle data representation used to describe the vehicle trajectory data and by the data flow diagrams, which identify system components and their interactions. Universal Vehicle Data Representation The input data for the vehicle Trajectory Processor are simu- lated vehicle trajectory files from traffic assignment and simu- lation software packages, for example, DYNASMART and Aimsun. GPS vehicle trajectory data are another important source of input data. The simulated vehicle trajectory files from these software packages and the GPS vehicle trajectory data have their own unique formats to represent the movements of the vehicles in the network. For the vehicle Trajectory Proces- sor to load and analyze these various sources and formats of vehicle trajectory files, it is important to design a universal data structure internally to represent these various input data. After thoroughly investigating the formats of the vehicle files from the DYNASMART and Aimsun software packages and GPS vehicle trajectory data, this universal vehicle representation (data structure) is designed to encompass necessary informa- tion to identify the vehicle movement and allow derivation of the travel time information between origin and destination zones. Table 7.1 lists the necessary information recorded by this universal vehicle data structure. Data Flow The overall vehicle trajectory processing procedure can be divided into three subprocedures: preprocessing, vehicle trajectory processing, and result presentation. Figure 7.2 illus- trates the input and output data for each subprocedure. During the preprocessing, the map-matching engine converts the vehicle movements in a transportation planning network into real-network representation. These converted vehicle trajectory data are then output in a universal format. The universally formatted vehicle trajectory data are input for the vehicle trajectory processing procedure, along with MOE settings. The standard output from this procedure is O–D-level or path-level, scenario-specific or aggregated travel time statistics (average and standard deviation of travel time). Based on specified MOE settings, other MOEs can be gener- ated as well. The result presentation procedure takes the statistics gen- erated in the vehicle trajectory processing procedure and pre- pares data for display in various UIs. Based on the UI control selected by the user, the corresponding UI is activated to present the statistic results. Integration with Selected Models (dYNASMArt and Aimsun) Procedure 1. Import trajectory for multiple scenarios: a. DTA simulation results (e.g., DYNASMART); b. GPS vehicle location records (e.g., from TomTom); c. Simulated vehicle records (e.g., from VisSim, Aimsun). 2. Read user defined MOE (critical O–Ds, paths). 3. Extract trajectory set for selected spatial element (O–D, path).

84 Figure 7.1. System architecture.

85 4. Calculate travel time PDF/CDF and Planning Time Index/ Buffer Time Index, for individual scenarios and in combi- nation, based on prespecified MOE settings. 5. Present calculated statistics and MOEs in a straight forward presentation UI to facilitate comparisons of observed and simulated travel time reliability measures. The calculated O–D-based path statistics may be displayed as path travel time PDF/CDF. If multiple scenarios are loaded for analysis, the combined PDF and CDF from these scenarios can also be generated and displayed. Figure 7.3 shows an example O–D statistics user interface. Additional MOEs, such as planning time and schedule delay, if prespecified, can also be displayed in the user interface, as shown in Figure 7.4. To view the path on the Google Earth interface, a user can simply select a path (a row) in the path statistics table. The user can also press and hold the control key to select mul- tiple rows in the path statistics table to view multiple paths in the Google Earth display. The “Type” column indicates the source of the path: “V-file” indicates this path is extracted from a DYNASMART vehicle file, and “GPS” indicates this path is from a GPS trajectory file. An example of paths between an O–D pair is shown in Figure 7.5. Exporting function is provided to export all of the content in the O–D statistics table to the project folder for further analysis. Processing and Analyzing GPS Data The GPS traces from TomTom Inc. were used to compare with the routes produced by the Google routing engine (i.e., Google Earth) to evaluate the applicability of using GPS data for traffic simulation calibration and assessment. The first objective is to examine and validate the data quality of GPS records and provide insights on using those data for travel time reliability studies. The second goal is to select some rep- resentative O–D pairs for further comparisons with simulated vehicle trajectories from DTA simulators (e.g., DYNASMART). The GPS data provided by TomTom cover approximately 10 days, with data from May 3, 2010 (Monday), used in the following analysis. The routes that share the same origin and destination are analyzed. The zone identification numbers in the GPS data fol- low the zonal definition from the Best Practice Model for the New York region. Consider the O–D pairs Origin ID: 637 and Destination ID: 529. For example, the vehicles (Internal Vehi- cle_IDs: 1051, 1774, 2956, 3049, 3287, 3533; Origin ID: 637; Destination ID: 529) share the same origin and destination. Table 7.2 shows some of the comparisons of travel time between TomTom and Google Earth for O–D pairs with large volumes. Figure 7.6 shows a comparison of path from TomTom GPS traces and Google Earth. By investigating the detailed underlying path traces, the user can investigate the possible reasons for detour. They may be to avoid traffic congestion or perform other activities in a single trip (visit intermediate destinations). In the example shown in Figure 7.7, the possible reason for detour is to per- form other activities in a single trip—for example, drop off/ pick up children—and the possible intermediate destination may be Thomas Jefferson High School. The following example, with data shown in Figure 7.8, com- pares O–D pairs with a large number of records. The travel time from TomTom is 25.34 min while the travel time from Google Earth is 5 min. The travel speed from TomTom is 13.09 mile/h. A possible reason for longer travel time from TomTom com- pared with the same path by Google Earth may be that conges- tion was experienced. From these comparisons between TomTom and Google Earth, we can obtain the following conclusions: 1. In general, the travel time of GPS traces of TomTom is longer than that of Google Earth. The route provided by Google Earth is the free flow, which does not take conges- tion into consideration. And the GPS traces do not always comply with the shortest path due to some personal driver behaviors. So the travel time of GPS traces of TomTom is longer than that of Google Earth. 2. Even when the GPS traces of one vehicle have the same path as the Google Earth vehicle (Internal Vehicle_ID: 3533), the travel time of TomTom is longer than that of Google Earth. The possible reason is the congestion in the real world. 3. According to the GPS trajectory of the vehicles, some vehi- cles detour a lot. They may have tried to do something else first. For example, a student may drive to pick up his friends first before going to the university. In the team’s comparison, the vehicle (Internal Vehicle_ID: 358) is typical. We can infer that this vehicle detours to the airport to do something. It is possible that some vehicles (Internal Vehicle_ID: 1002) got lost trying to find a parking lot. Table 7.1. Universal Vehicle Representation Data element Definition vehicle Id Identify an individual vehicle origin zone Id The starting zone Id of a vehicle destination zone Id The ending zone Id of a vehicle departure time The departure time from origin zone by this vehicle Total travel time The total travel time between origin and destination zones by this vehicle Node array An array recording the nodes traveled by this vehicle from the origin zone to the destination zone (text continues on page 90)

86 Figure 7.2. Data flowchart.

87 Figure 7.3. Example O–D statistics user interface. Figure 7.4. Additional MOEs displayed in the vehicle Trajectory Processor. Upper curve, planning time; lower curve, preferred arrival time.

88 Table 7.2. Vehicle Trajectory Path Analysis: Comparison Between GPS and Google Routing Paths Internal Vehicle ID Departure Time (2010-5-3) Trajectory Length from TomTom (mile) Routing Length from Google Earth (mile) Travel Time from TomTom (min) Travel Speed from TomTom (mile/h) Average Link Speed (mile/h) Travel Time from Google Earth (min) Route Comparison 1051 11:54 a.m. 6.77 3.8 24.17 16.81 9.43 5 Detour 1774 6:55 a.m. 5.53 3.8 25.91 12.81 8.80 5 Same Path 2956 8:06 a.m. 5.39 3.8 21.73 14.88 10.49 5 Same Path 3049 8:31 a.m. 6.78 3.8 21.23 19.14 10.74 5 Detour 3287 8:58 a.m. 5.71 3.8 23.51 14.57 9.70 5 Same Path 3533 6:37 a.m. 5.53 3.8 25.34 13.09 9.00 5 Same Path Figure 7.5. Paths between an O–D pair. Figure 7.6. Comparison of path from TomTom GPS traces and Google Earth.

89 Figure 7.7. Another comparison of path from TomTom GPS traces and Google Earth. Figure 7.8. GPS traces of TomTom and corresponding historical traffic condition maps from Google Maps.

90 Processing Vehicle Trajectory Files from VisSim and Aimsun Through Map Matching Vehicle Trajectory File in VisSim and Aimsun Usually, the vehicle trajectory generated by traffic assignment and simulation software packages includes the vehicle move- ment information. However, this information often represents in node IDs/link IDs used by the underlying transportation planning network. To display this information to the real-world geographic information system (GIS) network, it is necessary to map the node IDs/link IDs to the longitude and latitude coordinate system. Therefore, map matching is required before the reconstructed trajectories can be correctly displayed on the map. VisSim and Aimsun can be programmed to record indi- vidual vehicle parameters for each simulation step. Recording vehicle parameters on a second-by-second basis can be most beneficial for creating vehicle trajectory files. The vehicle records output in VisSim is configured through Evaluation=> Files . . . =>Vehicle record. The Configuration window allows for definition of any combination of the vehicle parameters. The vehicle trajectory file that can be used for map match- ing can be obtained through a combination of the following parameters: • Simulation time (or simulation time of day); • Vehicle number; • Link number; • World coordinate X; and • World coordinate Y. If the VisSim simulation resolution is set to 10 (which is updating simulation parameters every 0.1 second, most com- mon for microsimulation models), the Resolution of the Vehi- cle Record Filter should be set at 10 Time step(s). This provides vehicle record outputs for every second. The output is by default given in .fzp file, which is basically a text file. However, since vehicle records for each vehicle for large networks and long-time evaluation periods can be quite large, the team rec- ommends configuring the database vehicle record file for easier manipulation (in the Vehicle Record-Configuration window). travel time reliability Indices Various studies have identified a number of reliability perfor- mance measures and provided recommendations on their suit- ability for different purposes. Lomax et al. (2003) defined three broad categories of reliability performance indicators and dis- cussed a variety of measures based on these concepts: (1) sta- tistical range, (2) buffer time measures, and (3) tardy trip indicators. The authors suggested three specific indicators— Percent Variation, Misery Index, and Buffer Time Index—as promising measures that provide consistent analytical conclu- sions. NCHRP Report 618 (Cambridge Systematics, Inc. et al. 2008) provides guidance on selecting measures for different purposes and types of analyses. The reliability measures rec- ommended by that study include Buffer Index, percent on- time arrival, Planning Time Index, percent variation, and 95th percentile. The second Strategic Highway Research Pro- gram (SHRP 2) conducted an extensive empirical study and pointed out some shortcomings of the performance metrics recommended by previous studies (Cambridge Systematics, Inc. et al. 2013). For example, the 95th percentile travel time may be too extreme to reflect certain improvements intro- duced by traffic operations strategies, but the 80th percentile would be useful in such cases. Also, for performance indica- tors that measure the distance between central and extreme values (e.g., Buffer Index), the median would be a more robust central tendency statistic than the mean, as travel time distri- butions are by nature skewed. Based on such modifications, the SHRP 2 study recommended a final set of six reliability metrics: Buffer Index, failure/on-time measures, Planning Time Index, 80th Percentile Travel Time Index, Skew Statistic, and Misery Index. While many previous studies have focused on corridor- or link-level travel time reliability, this project aims to perform a full range of analysis addressing network-level, O–D-level, path-level, and segment/link-level travel time reliability using regional planning and operations models. In doing so, users need to consider not only different properties of the reliability measures, as investigated in the above-mentioned studies, but also their applicability to an intended analysis level. Table 7.3 presents a list of available reliability measures, categorized on the basis of their applicability to different levels of travel time distributions and associated reliability analysis, namely, network-level, O–D-level, and path/segment/ link-level. For the network-level, travel times experienced by vehicles are not directly comparable because distances traveled by vehicles may be significantly different. In this case, measures that are normalized by the trip distance can be used. Each vehicle’s travel time can be converted into the distance- normalized travel time (i.e., travel time per mile, or TTPM); and various statistics can be extracted from the distribution of TTPMs, as presented in Type A measures in Table 7.3. For the O–D-level, travel times experienced by vehicles are com- parable, although actual trip distances could be different depending on the route followed by each vehicle. The O–D- level travel times are not limited to travel times between actual traffic analysis zones (TAZ). Travel time distributions between any two points can be included in this category. Reli- ability measures that can be used when travel times are (continued from page 85)

91 comparable include many conventional metrics such as the mean and standard deviation of travel times, percentiles, and Buffer Index, as presented in Type B in Table 7.3. For O–D- level analysis, therefore, both Type A and Type B measures can be used. At the path/segment/link-level, not only are the travel times for different vehicles comparable but trip dis- tances are also the same. This allows the calculation of the Table 7.3. Reliability Measures for Different Analysis Types Analysis Level Network o–D path/Segment/Link Characteristic travel times for vehicles Not comparable comparable comparable travel distances for vehicles different different Identical Applicable measures Distance- normalized measures (Type A) • Average of travel times per mile (ttpMs) • Standard deviation of ttpMs • 95th/90th/80th percentile ttpM Measures for comparable travel times (Type B) • Average travel time • Standard deviation of travel times • Coefficient of variation Standard deviation of travel times/mean travel time • 95th/90th/80th percentile travel time • Buffer Index (95th percentile travel time - mean travel time)/(mean travel time) • Skew Index (90th percentile travel time - median travel time)/(median travel time - 10th percentile travel time) • percent on-time arrival Percent of travel times < 1.1 median travel time Measures for the same travel distance (Type c) • ttI (travel time Index) Mean travel time/free-flow travel time • ptI (planning time Index) 95th percentile travel time/free-flow travel time • Misery Index Mean of the highest 5% of travel times/free-flow travel time • Frequency of congestion Percent of travel times > 2 free-flow travel time unique free-flow travel time for a given path and, therefore, allows the use of additional measures that require the free- flow travel time. Such measures include Travel Time Index, Planning Time Index, Misery Index, and frequency of con- gestion as shown in Type C in Table 7.3. As such, users can use any of Type A, B, and C measures for the path/segment/link- level travel time reliability analysis.