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.
17 The scenario-based reliability analysis framework developed under this project aims to provide a systematic and unifying way to incorporate travel time reliability into the decision-making process in traffic operations and planning. The roles and functions of the Scenario Manager and the Trajectory Processor within this framework have been discussed in the previous chapters. This chapter outlines the overall steps for implementing the framework using these tools, and it provides a brief discussion of general approaches to performing each step. The basic steps addressed in this chapter are (1) scoping the study, (2) scenario definition, (3) design of simulation experiments, and (4) output analysis. SCOPING THE STUDY To develop the scope of the study, the problem or objective must first be defined. Defin ing the problem includes identifying the scale or spatial magnitude of the prob- lem, which in turn determines the type of analysis to be applied. This analysis type could be networkwide, corridor-specific, segment, or other. The spatial magnitude of the problem may also determine the simulation resolution to be applied. In addition to the spatial limits, the temporal boundaries should be defined such that any analysis focuses on the specific problem whether it is related to a weekday peak period or to a weekend special event. Acquisition of relevant data is also fundamental to properly assess the reliability impacts associated with the network, corridor, segment, and so on. Depending on the problem at hand, specific data may be required to create the various testing scenarios. Data related to the various exogenous factors affecting travel time reliability need to be acquired to populate the scenario manager, again depending on the problem to be 5 USING THE TOOLS
18 A LEXICON FOR CONVEYING TRAVEL TIME RELIABILITY INFORMATION analyzed. These additional data could include road closure information, collision data, weather data, special event data, and so on. The data to be collected would correspond to the spatial and temporal limits defined earlier. SCENARIO DEFINITION 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 weekdays is different from that for weekends on the same road network. Therefore, defining the applicable time and space domains (i.e., temporal horizon and geographic scope) is an essential first step for any study. In general, the time domain is specified by a date range of the overall time period (e.g., 6/1/2012 to 8/31/2012), day of week (e.g., Monday to Friday), and time of day (6 a.m. to 10 a.m.); or it could be a specific season or day of each year (e.g., Thanksgiving Day). The space domain defines the level for which travel time data are collected and the reliability measures calculated (e.g., network level, O-D level, path level, and link level). Once space and time domains are defined, the next step is to identify factors that affect travel time distributions for the given domains. Various supply- and demand- side factors can be considered as scenario components that define input scenarios for traffic simulation. Figure 5.1 depicts examples of supply-side factors: weather, planned special events, work zone, incident, and traffic management and control. Figure 5.1 also provides examples of demand-side factors: day-to-day demand random variation and temporary demand surge due to a certain special event. Once a user determines the factors to be included as scenario components, the next step is to construct actual scenarios that will be simulated using traffic flow models. In this study, the term scenario represents a collection of various event instances of supply- and demand-side factors; each event instance can be represented by a set of attributes specifying when (time), where (location), and how (intensity) it occurs, as illustrated in Figure 5.2. Each scenario represents a possible daily situation on a given network. The user defines a set of input scenarios either by generating random scenarios using the Scenario Managerâs Monte Carlo sampling capability or by using deterministic scenarios from the existing historical scenarios. An important issue in generating scenarios is to consider dependencies between different factors. As represented by the dotted arrows in Figure 5.1, certain scenario components are dependent on other components. Incident occurrence is the most prominent example: event properties (e.g., frequency, duration, and severity) tend to be affected by weather and other external events. Dependencies are also observed on the traffic management side: weather-responsive traffic management (WRTM) strate- gies are deployed based on type and severity of weather events, and traffic incident management is triggered by incident events. In the Scenario Manager, such dependen- cies 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
19 A LEXICON FOR CONVEYING TRAVEL TIME RELIABILITY INFORMATION Figure 5.1. Various scenario components and dependency relations. Figure 5.2. Definition of scenario: Combination of various event instances represented by time, space, and intensity properties. Work Zone Work zone Light rain
20 A LEXICON FOR CONVEYING TRAVEL TIME RELIABILITY INFORMATION generates each component sequentially (e.g., weather â incident â incident manage- ment) so that each component is sampled from its distribution conditioned on all the previously sampled components. DESIGN OF SIMULATION EXPERIMENTS Monte Carlo Approach This approach uses Monte Carlo sampling to prepare input scenarios aimed at prop- agating uncertainties in selected scenario components (e.g., weather, incident, and demand variation) into uncertainties in the generated input scenarios. These uncertain- ties, in turn, can be translated into the resulting traffic simulation output (i.e., travel time distributions). The Scenario Manager performs Monte Carlo sampling to generate hundreds or thousands of input scenarios by drawing from the joint probability dis- tribution of parameters for the selected scenario components. For instance, one could select weather and incidents as scenario components. In that case the Scenario Man- ager identifies the empirical distribution of weather events from historical weather data and estimates parameters for the stochastic process of incident occurrences based on incident data. Then it randomly samples a specified number of realizations of weather and incident combinations to construct input scenarios. Each scenario is equally likely, allowing the Trajectory Processor to simply aggregate travel time distributions from a large number of simulation runs to obtain the most likely (probable) estimators for a set of reliability performance indicators for the given time and space domains. Mix-and-Match Approach Instead of generating scenarios randomly given the underlying 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 by mixing and matching possible combinations of specific input fac- tors or by directly using known historical events or specific instances (e.g., holiday, ball game). Such design schemes are necessary when the user wants to control specific fac- tors in constructing scenarios. For example, the user may set a demand pattern using actual data obtained from a particular ball game day while allowing other components such as weather, incident, and traffic controls to vary. The user can then identify all the possible scenarios under the ball game day by mixing and matching various scenario components, conditioning on the given demand pattern. By obtaining scenario-specific travel time distributions from each scenarioâs traffic simulation run as well as the prob- ability of each scenario occurring, one can construct the overall travel time distribu- tion and the associated reliability measures to assess travel time reliability on a ball game day. OUTPUT ANALYSIS Suppose that we simulated N input scenarios, Si, i = 1,â¦, N, and that we are interested in obtaining the overall distribution of travel time T that is the travel time for a given O-D/path/link under consideration. From the traffic simulation outputs, we obtain N
21 A LEXICON FOR CONVEYING TRAVEL TIME RELIABILITY INFORMATION scenario-specific travel time distributions, denoted by conditional probability density function f(T|Si), i = 1,â¦, N. Then the overall travel time distribution, the probability density function of T, f(T) can be calculated by the weighted sum of the scenario- specific travel time distributions as follows: f T f T S P Si i N i 1 â ( ) ( )( ) = = where P(Si) represents the probability of scenario Si occurring P S 1i i N 1 â ( ) =ï£ï£¬   = . This process takes place within the Trajectory Processor, which accepts N vehicle trajectory data sets (from N scenarios) as input and processes the trajectory data to construct both scenario-specific and combined travel time distributions for any given trip. The graphical user interface (GUI) of the Trajectory Processor allows users to select the entire network, sub-area, specific O-D pair, path/segment, or link on the study network; it also provides various visualization options for displaying the associ- ated travel time distributions and reliability measures listed in Table 2.1. Users can export all the data presented on the GUI of the Trajectory Processor to text files so that further analysis can be performed using spreadsheets or statistical tools. The Trajectory Processor is designed to load multiple data sets from different sce- narios so that users can compare reliability performance measures under different scenarios as well as obtain the combined travel time distribution aggregated over mul- tiple scenarios with different scenario probabilities or weights. Another important function provided by the Trajectory Processor is the ability to process GPS observations. The Trajectory Processor internally conducts a pre- processing step in which it maps GPS traces based on the real-world coordinate sys- tem to the link-node representation associated with the simulation network under consideration. This allows users to analyze GPS trajectories in the same manner as the simulated trajectories. Users can load the GPS trajectory data set, extract reli- ability measures for a given spatial boundary (e.g., entire network, sub-area, specific O-D pair, path/segment, or link), and compare the travel time distribution from the GPS data to that from the simulation result for validation purposes.
