Twin Cities Metro-Wide Traffic Micro-Simulation Feasibility Investigation

Twin Cities Metro-wide Traffic Micro-simulation Feasibility Investigation

Report # 5 in the series Access to Destinations Study

Report # 2008-15

Technical Report Documentation Page 1. Report No. 2. 3. Recipients Accession No. MN/RC 2008-15 4. Title and Subtitle 5. Report Date May 2008 Access to Destinations: Twin Cities Metro-wide Traffic 6. Micro-simulation Feasibility Investigation 7. Author(s) 8. Performing Organization Report No. John Hourdos, Panos Michalopoulos 9. Performing Organization Name and Address 10. Project/Task/Work Unit No. Department of Civil Engineering University of Minnesota 11. Contract (C) or Grant (G) No. 500 Pillsbury Dr. SE (c) 81655 (wo) 222 Minneapolis, Minnesota 55455 12. Sponsoring Organization Name and Address 13. Type of Report and Period Covered Minnesota Department of Transportation Final Report 395 John Ireland Boulevard Mail Stop 330 14. Sponsoring Agency Code St. Paul, Minnesota 55155 15. Supplementary Notes http://www.lrrb.org/PDF/200815.pdf Report #5 in the series: Access to Destinations Study 16. Abstract (Limit: 200 words)

The economic importance of effective traffic management becomes more and more evident as traffic demands increase. Faced with the negative effects of traffic congestion including higher transport costs, greater energy consumption, and increased driver delays, transportation agencies around the world areas have responded by building new roads and enhancing their traffic management systems. However, the high costs associated with these projects, and the possibility that improvements in different parts of a complex traffic management system may give rise to unforeseen interactions, have prompted many metropolitan areas to invest in the creation of metro-wide simulation systems that support the evaluation of alternative traffic management scenarios across an entire traffic network. Such undertakings are far from simple; even small-scale microscopic simulations require large amounts of high-quality data. The objectives of this project were to evaluate the feasibility of developing a traffic simulation system for the Minneapolis-St. Paul metropolitan area, and to propose the most appropriate methodology for the design and implementation of such a system, taking into account local needs and capabilities.

17. Document Analysis/Descriptors 18. Availability Statement Traffic simulation, No restrictions. Document available from: Transportation planning, National Technical Information Services, Microscopic simulation, Springfield, Virginia 22161 Large scale simulation models

19. Security Class (this report) 20. Security Class (this page) 21. No. of Pages 22. Price Unclassified Unclassified 81

Access to Destinations:

Twin Cities Metro-wide Traffic Micro-simulation Feasibility Investigation

Report # 5 in the series

Final Report

Prepared by: John Hourdos Panos Michalopoulos

Department of Civil Engineering University of Minnesota

May 2008

Published by: Minnesota Department of Transportation Research Services Section 395 John Ireland Boulevard, MS 330 St. Paul, MN 55155

This report represents the results of research conducted by the authors and does not necessarily represent the views or policies of the Minnesota Department of Transportation and/or the Center for Transportation Studies. This report does not contain a standard or specified technique.

The authors and the Minnesota Department of Transportation and Center for Transportation Studies do not endorse products or manufacturers. Trade or manufacturers’ names appear herein solely because they are considered essential to this report. Acknowledgments

This report would not have been possible without the support and collaboration of a large number of people and organizations. We would like to acknowledge the support of the two project Technical Liaisons, Brian Isaacson from Mn/DOT and Robert Byers from Hennepin County. They along with the members of the Technical Advisory Panel assured that the project stayed real and that it produced useful information for the practitioners and it wasn’t just another university research project. We would also like to thank Mark Filipi from the Metropolitan Council, Brian Kary from Mn/DOT, John Levin from Metro Transit and many others for their insight and guidance. Finally we would like to thank the staff of the Center for Transportation Studies for supporting the project and assisting in the publication of this report.

Funding for this project was provided by Mn/DOT and Hennepin County, through funds provided by the Federal Transit Administration.

Table of Contents

Chapter 1: Introduction 1 Chapter 2: State-of-practice in Large Urban Traffic Simulation 2 Chapter 3: Stakeholder Interviews 28 Chapter 4: Overview of Commercial Applications 34 Chapter 5: Functionality and Data Requirements for a Metro-Wide Simulation Model 62 Chapter 6: Proposed Approach for a Metro-wide Simulation Model 67 References 72

List of Figures

Figure 1: Model Geometry 5 Figure 2: Area photo 5 Figure 3: Madrid metro-wide model in AIMSUN NG 6 Figure 4: Madrid metro-wide model in VISUM and sub-areas in VISSIM 7 Figure 5: Barcelona Metro-wide model 8 Figure 6: Columbus CBD and surrounding area model 9 Figure 7: Kansa City center model in VISUM and VISSIM 11 Figure 8: Kansa City area. The Area modeled in VISUM is in the red box 12 Figure 9: Hessen motorway model 14 Figure 10: Milwaukee model 15 Figure 11: Munich North metro model 16 Figure 12: Berlin model in VISUM and VISSIM 18 Figure 13: Lausanne metro-wide simulation model 20 Figure 14: Birmingham model 22 Figure 15: VISSIM subarea network of Coventry, VISSIM subarea network of LRT corridor in Birmingham Centre 22 Figure 16: Sydney metro wide model in PARAMICS 24 Figure 17: Toronto network with Paramics 25 Figure 18: Stockholm metro-wide model in AIMSUN 26 Figure 19: Proposed study area in London, UK 26 Figure 20: Multi-Resolution Simulation Model Approach 36 Figure 21: PTV-Vision 37 Figure 22: PTV-Vision Data Flow 41 Figure 23: CUBE 44 Figure 24: AIMSUN NG 49 Figure 25: AIMSUN Simulation Process – Volume Based 51 Figure 26: AIMSUN Simulation Process – Route Based 52 Figure 27: AIMSUN NG Modules 54 Figure 28: Integrated Analysis Methodology 67 Figure 29: Combining Meso and Micro approaches 69

Executive Summary

Motivation and objectives

The investigation of the feasibility of developing a traffic simulation system for the Twin Cities metropolitan area was proposed in response to the needs of multiple stakeholder groups, including University of Minnesota researchers, transportation engineers, and policymakers.

Under the umbrella of the Access to Destinations Study, several research teams are working to produce new metrics for transportation system performance based on the concept of accessibility—the ability of people to reach the locations they need to visit in order to meet their needs and satisfy their desires. A key challenge of this research effort is how to estimate future levels of accessibility based on today’s growth estimates, land use decisions, and development plans. Travel time is a key factor in any such estimation. Today, measuring (or even estimating) travel times on arterial streets is extremely difficult; on freeways, although travel times can be measured with good accuracy, it is difficult to predict what will happen under different demand and capacity scenarios. One way to overcome these obstacles is found in the recent rapid advances in simulation and modeling, specifically microscopic simulation. A simulation model encompassing the entire metropolitan area has the potential to greatly improve researchers’ ability to estimate travel times across the entire transportation network.

In addition to the goal of measuring and forecasting accessibility, a metro-wide simulation model offers several potential benefits to engineers and traffic managers. These include an enhanced ability to carry out system-wide performance evaluations, more effective optimization of traffic controls, better design and evaluation of new transportation projects, and support for planning and operational functions related to emergency situations such as the collapse of the I-35W bridge.

In view of these goals and potential benefits, investigation of the feasibility of developing a metro-wide simulation system was broken down into the following tasks:

• Report on the state-of-practice in large urban traffic simulation. • Identify the needs and requirements for a metro wide simulation model in the context of the Twin Cities metropolitan region. • Compile a review of currently available commercial simulation packages, focusing on features and data requirements. • Identify the quality and quantity of available data required for the development of a metro-wide simulation model. • Identify the general steps needed to develop a metro wide simulation model as well as a methodology for its use and maintenance.

Information Acquisition In researching metro-wide simulation projects carried out by other local and regional organizations, the lack of published literature proved to be a significant obstacle. In most cases, such projects are seen as “practical” and lacking in larger scientific significance, so very few papers are devoted to the subject. To be clear, this is not true of the methodologies underlying the construction and calibration of large or metro-wide simulation models; the latter topic has generated great scientific interest, resulting in an extensive body of literature. The task at hand, however, was focused on implementation rather than on design principles, and issues of data availability, application scalability, and cost were of primary importance. Information acquisition activities included:

1. Literature search for published papers or reports. 2. Communication with major developers of simulation applications to request examples and permission to communicate with clients for detailed information. 3. Based on information from developers, communication with project contractors, client agencies, or both. In the main body of this report, 18 projects are presented, along with details of data used, methodologies followed, and outcomes and costs where such information was available.

Stakeholder Interviews To identify the specific requirements for a simulation system to serve the Twin Cities metropolitan region, the research team conducted a series of stakeholder interviews including representatives of the following groups: Metropolitan Council planners City of Minneapolis traffic engineers Minnesota’s Federal Highway System (FHWA) representative Minnesota Department of Transportation (Mn/DOT) Regional Traffic Management Center traffic engineers Hennepin County and related cities’ traffic engineers Mn/DOT planning group and related consultants Metro Transit engineers and analysts These interviews focused on stakeholder needs in terms of the projects and tasks they currently undertake, desires for better methodologies and results if a hypothetical model were available, and types of data they have or know that are available.

Overview of Commercial Applications Having evaluated the current state of the practice regarding large-scale urban simulation models, identified the needs of stakeholders, and determined what data were available, the research team created a summary of the relevant features of five commercially available simulation packages and one package supported by the Federal Highway Administration. This summary highlighted the capabilities of various packages, and focused on the ability of each package to integrate strategic planning and operational simulation functions. It should be noted that the information contained in this report is based in large part on information received from developers; considering the complexity of these software applications, it is not possible to verify all features and capabilities outside of the specific aspects deemed important for the development of a metro-wide simulation model. The simulation packages examined in this report are:

1. PTV Vision (Visum / Vissim) 2. Transmodeler (TransCad / TransModeler) 3. CUBE (Voyager / DynaSim) 4. AimSun (Emme2 / AimSun2) 5. Paramics (Estimator / Modeler) 6. DynaSmart-P For the benefit of readers not familiar with the theories and modeling assumptions underlying applications of this type, a brief discussion of different modeling approaches is included.

Functionality and Data Requirements The common factor connecting all large urban area traffic simulation efforts presented in this report is a close relationship with the regional travel demand model. Specifically, in all cases the foundational data

set (apart from the geometry of transportation networks) was the daily or peak-period origin/destination (O/D) matrices produced by the planning model. Indeed, this connection was so important that in several cases it determined the success or failure of the project. As the research team examined the various projects an evolution became evident: although the planning models and the microscopic simulation models began as two completely separate applications, the latter’s dependence on O/D information prompted an integration of the two applications into one larger framework. The results of this evolution are clearly seen in the analysis current commercial applications: the largest commercial developers offer simulation packages containing modules that cover two or more levels of modeling resolution. The research team made an assessment of several types of currently available information comprising the “building blocks” of a traffic simulation model: geometry; demand; control; and calibration data. This assessment moved from two opposite directions having the knowledge of the type, format, quantity of local data as well as the individual simulation application needs for specific data types, format, and resolution. Based on this final analysis, the research team was instructed by the Technical Advisory Panel to avoid selecting a specific commercial product and proposing the best course of development; instead, the team was charged with proposing the best general methodology to be followed. Indeed, it had become evident from the information collected that matching the scarce data resources currently available in the Twin Cities region with the input requirements of any of the applications evaluated in this study would be challenging. Accordingly, the research team believes that the best course of action is to use a new approach described in this report.

Proposed Approach In this report, the research team asserts that the most appropriate approach to developing a metro-wide simulation capability for the Twin Cities region would be to employ a hybrid mesoscopic/microscopic simulation application featuring close integration with a macroscopic planning model. This modeling framework would provide users with an integrated set of modeling tools for complete corridor analysis. In use, this application would start at a high level with regional travel demand (based on the established four-step process) to provide a primary set of O/D matrices. These matrices would be further refined and adjusted, using additional information to estimate peak spreading and adjusting for shorter time intervals from available link flow counts. The refined O/D matrices would be input into dynamic models at meso- and/or micro-scales, depending on the needs of the users, along with the specifications of management strategies to be evaluated according to selected performance measures.

The use of a balanced meso/micro approach is believed to be the best course of action based on the availability of data for the Twin Cities region. Specifically, the availability of traffic measurements on freeways has been proven to produce high-quality simulation models. The only questionable assumption in freeway simulation has been the definition of demand (ramp entrance and exit volumes). Even in the case of ramp metering, which is known to affect route choice, all modeling efforts have assumed no diversion strategy both in evaluation projects and as regular freeway improvement projects. This flaw could be partially alleviated by the use of mesoscopic simulation for the arterial system. Enough information exists to construct an efficient and relatively accurate mesoscopic model for the Twin Cities’ arterial system. The research team is confident that such a model would equal or exceed the accuracy of the macroscopic regional planning model. The development of a mesoscopic model would entail an upgrade of the macroscopic model, bringing higher levels of efficiency and utility to the modeling process. The benefits of a hybrid meso/micro simulation approach are presented by example in this report.

Conclusions The research activities presented in this report covered a lot of ground: from a detailed examination of the state of the practice in large urban simulation projects around the world, to interviews with local stakeholders, and a thorough examination of the capabilities of currently available simulation packages. Although some non-commercial simulators were examined, the research team does not believe it prudent to make such an investment in simulation without professional support and model evolution.

Leaving aside considerations of data availability, a micro-simulation approach would have been the best possible solution. Current micro-simulation packages are fast, and can handle very large models without difficulty. Unfortunately, the lack of suitable data for the greater part of the road network precludes such an approach. Taking data availability into account, the hybrid mesoscopic/microscopic approach described in this report has been identified as optimal. This methodology, although relatively novel, has been thoroughly discussed in the relevant literature and rests on a firm theoretical foundation. This report contains enough information to justify the research team’s recommendation, but also provides details necessary to develop more traditional approaches. It is the hope of the research team that local stakeholders and decisionmakers find this report helpful, both today and in the future.

Chapter 1 Introduction

In view of these goals and potential benefits, investigation of the feasibility of developing a metro-wide simulation system was broken down into the following tasks: • Report on the state-of-practice in large urban traffic simulation. • Identify the needs and requirements for a metro wide simulation model in the context of the Twin Cities metropolitan region. • Compile a review of currently available commercial simulation packages, focusing on features and data requirements. • Identify the quality and quantity of available data required for the development of a metro-wide simulation model. • Identify the general steps needed to develop a metro wide simulation model as well as a methodology for its use and maintenance.

This report is a compilation of the project task deliverables.

1 Chapter 2 State-of-practice in Large Urban Traffic Simulation

This chapter summarizes the findings of the feasibility investigation for this project. The objective of this task was to collect as many examples as possible of similar past or current attempts for the creation of metro-wide simulation models. This task was elevated in importance by the project’s technical advisory panel because it is crucial to the whole feasibility investigation. From a methodological standpoint, the idea of a metro-wide simulation model is feasible. Challenges arise in the implementation because success is greatly dependent on data availability. Therefore, attention was given during the collection of information to the amount and quality of data—for development and for calibration and validation— that previous projects had available and what problems were encountered.

In order to explain the methodology used for the collection of information, this section begins with a description of the steps and issues involved. A discussion of findings follows, summarizing our impressions from the review of all the available examples, whether or not they were successful. Finally, the examples are presented in ascending order based on size, relevance, complexity, and availability of information.

Information acquisition activities included:

1. Literature search for published papers or reports 2. Communication with major developers of simulation applications to request examples and permission to communicate with clients for detailed information 3. Based on information from developers, communication with project contractors, client agencies, or both.

The following information was requested of all the developers of commercially available simulation applications.

1) Purpose of building the urban network model with a microscopic model. 2) Current use of the model built with (insert name of simulator). Did it achieve its intended purpose? 3) Network size and complexity, i.e., number of lane miles, links, types of interchanges, intersections, special geometries. 4) Level of traffic demand, i.e., low, high, etc. 5) Data collection method a. How Origin/Destination (O/D) data (time dependent) was collected, calculated, and checked. b. The size of time slices for the aforementioned demand data, i.e., 5-min. or 10 min. etc.

2 6) How the model was calibrated. a. What type/amount of real data was collected to calibrate and validate the model. b. Budget spent to collect the data for calibration and validation. 7) Types of traffic control systems modeled, e.g., metering,coordinated signal control, etc. 8) Types of MOEs used for simulation analysis. 9) What kind of training, including duration, was needed to build this large model? 10) Major difficulties in modeling a large urban area network. 11) Total budget spent to model the network. 12) Maintenance, expansion, and upkeep costs. 13) Procedures for producing future forecasted conditions. 14) How have the model results been used in the decision-making process? How did it improve prior practices?

We requested that respondents forward this questionnaire to as many people as possible even if this meant duplication of information. We did this to maximize the information received (nobody completed the entire questionnaire) and to have some verification of the supplied information. Unfortunately, communicating electronically did not yield all of the required information so we finalized the data collection with a series of phone calls to individuals for whom we had contact information and were willing to talk to us. This was an iterative process where we tried to extract information, which in some cases, had almost been forgotten by the people involved.

As it will become evident in the examples we focused mainly on the project objective, the simulated network size and complexity, the data availability, and the calibration and validation process that was followed. Although we pressed for information on each project’s person effort and cost, we rarely received complete answers.

Examples of Large Scale Urban Simulation Models The examples included in this report range spatially from very large models involving more than the actual metropolitan area to large simulation projects that do not cover the entire metro region, but involve all the necessary elements: an urban grid with controlled intersections; several alternative routes for each O/D pair; as well as several freeway interchanges. There were a number of spatially large projects that involved long stretches of freeways. We did not include these examples since the scope and methodologies involved are very different from the ones involved in a metro-wide simulation project.

The projects collected range in scope from cases like Singapore, Madrid, and Hessen where the model serves real-time traffic operation needs, to more traditional projects involving the creation and maintenance of metro-wide master models for use in future projects, to one-time use models for large projects like the ones in Manhattan and Columbus.

It was not surprising to find that the majority of these models are not located in the United States. All simulation packages capable of undertaking such a large and complex model are developed by European companies and have larger user bases outside the United States. This does not mean, however, that there are no relevant projects in the United States.

Regarding feasibility, we make the following conclusions based on the examples included in this report:

• Need: Why do we need this? Considering the different objectives that drove the projects presented, we suggest the same needs and questions exist, more or less, in the Twin Cities. Some of the simulations developed go beyond this region’s needs; the congestion problem in the Twin Cities does not yet justify the need for ultra modern traffic management systems like the ones developed in Singapore and Madrid. It might never be needed. It is our opinion, though, that

3 many local projects would benefit from a regional approach and a unified control structure. As transportation problems grow, interagency boundaries can compound the problem and potentially limit the investigation of solutions.

• Data availability: Although we do not claim to have a definite answer to this question, it is clear that the majority of prior projects started with the same, or even less, data than is currently available for the Twin Cities. In all cases, the source of the initial information is the regional model. We also note that in all cases it was not enough. Additional steps had to be taken in order to increase the resolution of the information temporally and spatially. The success of most of these examples increases our confidence that such an undertaking is possible, although not easy. The cases we find encouraging are where the undertaking of a metro-wide model has benefited the overall system by fine-tuning the regional model or determining the necessary data collection points. The latter is obviously a key consideration when large detector deployments are not possible financially.

Island of Singapore (AIMSUN) The metro-wide simulation model of the Island of Singapore is the largest example we found. Because it was completed so recently, there is very little independent literature about it available. The information collected is mainly from the software developers who were also the primary contractors in the project. We have verified that the system has been in operation since April 2006. This metro-wide simulation model was developed for real-time simulation in support of the regional traffic management system. Although the intended application is beyond the needs of an envisioned Twin Cities model, it is still a fitting example.

The Singapore model covers an area of 683 square kilometers (sq km), in which it models a total of 1,650km of roadways (4,483 lane km) and 10,580 intersections (~1,000 controlled). The area is divided into 3,153 zones. Figure 1 presents the model as seen in the simulator screen and Figure 2 is an aerial photo of the area.

According to the information gathered from the contractor of the project, the network geometry was imported from an earlier GIS model. Substantial effort was spent to add basic model details relevant to the micro-simulation model. The final model was exported back to the GIS system to keep the new level of detail consistent among applications and to enhance it for other users.

The demand information was originally obtained through a preexisting EMME/2 regional model. Peak period matrices were obtained from EMME/2. From these seed matrices, hourly ones were extracted and adjusted based on 380 detector counts. It is unclear if these detectors were preexisting or installed because of this project, although our discussions with those involved suggest the latter. When questioned on the difficulties encountered, the contractors said that they had the usual problems with calibrating O/D information, but the long timeline of the project (three years) helped alleviate them.

Because the scope of this model is to help in real-time operations, a special model has been developed that matches predetermined hourly O/D matrices with current collected detection information and uses them for the strategy evaluation event horizon. The O/D matcher utilizes known patterns in the real-time information to select the most appropriate O/D matrix from a library.

The bulk of the information we collected came from the project contractors. We were provided with a client contact in Singapore, but our e-mails were not answered.

Figure 1: Model Geometry

Figure 2: Area photo

5 Madrid, Spain (AIMSUN) This is a new project currently under development. The scope mirrors Singapore as a real-time operations platform based on simulation. In fact, the Singapore project was a key factor in the decision of Madrid authorities. Madrid officials visited Singapore and have a demonstration of how the system works. The objectives are to provide:

• off-line management scenario analysis • Real-time simulation scenarios for incident and congestion management • short-term forecasts • operations alternatives for the traffic control center

The model is being built to support the planned on-line traffic management system for the city of Madrid. There will be two phases. In the first phase, highlighted in green in Figure 3, the model will expand the critical belt south around Madrid’s Ring Road M-30. This is a heavily congested urban freeway with an average of 400,000 vehicles per day in both directions. They are currently covering the part of the Ring Road in the green highlighted area. The size of the first phase model is 4,896 sections, 2,109 intersections and 207 zones. The final phase will expand the area covered by the model close to the size of Singapore.

The geometry is imported from the EMME/2 regional model and adjusted based on GIS and CAD information. Again, the seed matrices are obtained from an EMME/2 regional model. In the Madrid case, the peak period matrices will be broken down to 15 minutes based on information from 2,146 pre-existing count detectors. A statistical analysis of the detector data will identify the patterns and classify the 15- minute O/D matrices.

Figure 3: Madrid metro-wide model in AIMSUN NG

6 Madrid, Spain (PTV-VISION) An earlier model of the metro area of Madrid, Spain has been built with a different simulator (VISUM+VISSIM). We could not confirm the information justifying the need to switch models. One version is that the PTV simulation application cannot handle networks of this size in real-time. Indeed, as will be the case in subsequent examples, the main model is built in the VISUM planning model application and only selected parts of it are implemented in the micro-simulation model VISSIM. In the case of this Madrid model in VISUM, 8,345 links for a total length of 225 km are modelled covering 536 zones. Only 926 links are modelled in VISSIM with 45 controlled intersections covering 126 zones.

The objective of the project was to study the M30 ring-road renovation. The project scope covered the estimation of hourly traffic flow for different projection years (2007, 2012, and 2037), a capacity analysis of bottlenecks created by weaving/lane changes as well as from spillbacks from adjacent intersections, and the evaluation of solutions for the elimination of bottlenecks.

Figure 4: Madrid metro-wide model in VISUM and sub-areas in VISSIM

There was no specific information regarding the import of geometry, but the PTV applications can import GIS and other pre-existing formats. The original peak period matrices (two 4-hour matrices) from the EMME/2 regional model were used for the analysis. The original EMME/2 model was calibrated based on 55 site counts. Network topology and O/D were converted to VISUM and recalibrated for the base case against 20 detector counts with screen line analysis. Assignment within VISUM and the sub-area network, plus path flows, were exported to VISSIM. Time profiles with 15 minute aggregates were overlaid on top of inflows of VISSIM (path flows imported from VISUM as single 4-hour value). Typical time profiles estimated from current detector counts at signalized intersections and aggregated to 15 min values. Typical profiles were taken as shares for the 4-hour inflows.

The MOEs used for the simulation analysis were:

• v/c-ratio per link for different time periods • delay per turning movement at signalized intersections • queue length and delay on M30 and off-/on-ramps

7 The contractor received ten days of assistance from PTV during the initial phase of the project. They also reported a 24 person-months effort for converting the regional model to VISUM, minor recalibration of VISUM and building the future M30 designs in VISUM and VISSIM.

The results and decisions influenced by the project can be summarized as follows:

• Supported the advantages of the renovation of the M30 inner-urban ring road (accessibility of the city center and keeping through traffic out of the old center). • VISSIM animations were used for public hearings and for making the case to funders. • Identification of bottlenecks with minor realignment of the M30. • Improved regional model which is better calibrated than the existing one for other planning purposes (Madrid is still growing).

Barcelona, Spain (AIMSUN) The “Agencia de Ecologia Urbana de Barcelona”, an agency of the municipality of Barcelona, built the model with the main purpose of using it as a master model to support operational planning projects in various districts of the city. Such projects cover needs for urban, strategic public transport and operations planning. The model encompasses 344 zones, 7,901 intersections, and 1,438 kilometres of roadway.

Since its completion in 2002, the model has been used to conduct studies on urban reshaping and redefinition of new traffic management schemes in the Dracia and Poble Nou districts of Barcelona and is currently being used for similar projects in other districts. The model was also used to conduct a feasibility study on the impact of alternative designs for the planned Light Railway Train through the CBD. The size of the sub-model is 1563 sections, 659 intersections and 208 zones. The sub-model can be seen as a cut-out on Figure 5.

Figure 5: Barcelona Metro-wide model

According to the contractor, the primary issue encountered in the model development revolved around the OD matrix data. The only OD available was the 24h OD matrix from the planning surveys from which the

8 AM and PM peak hour matrices had to be estimated and adjusted. The main problem with the adjustment was the inappropriate detection layout that does not allow a proper OD reconstruction. We suspect that the metro-wide matrices have not been calibrated adequately for serving micro-simulation needs of the entire area. It was mentioned that a separate project is ongoing that uses the metro-wide model and based on statistical techniques tries to minimize the need for detector installation by determining the most strategic locations in the network. Regardless, the projects served by the master model were calibrated separately. The detailed calibration included only the sub-model area while the boundary conditions were estimated through the master model.

The Barcelona model is the closest example to what we are envisioning for the Twin Cities. The previous models were either made to serve real-time operational goals or, as was the case of the first Madrid model, a very specific large construction project with no definite plans for re-use. It is interesting to note that the ability to cut a sub-model out of the master model and to be able to work on it with minimal effort, is feasible and we believe essential for our intended use.

Columbus, Ohio (PTV-VISION) The main goal of the study, completed in 2005, was to investigate access to downtown during the AM peak hour in anticipation of a 377% population growth, 30% growth in employment, 321% growth in households, and a 15% growth in automobiles per household. The study area shown in Figure 6 is within the metropolitan area of Columbus, Ohio. It represents approximately 30 square miles and includes the central business district (CBD). While there is no current plan for future use, the model did achieve its intended purpose.

Figure 6: Columbus CBD and surrounding area model

The study area, comprised of over 450 intersections (330 signalized) and 25 freeway interchanges, was divided into 294 zones. Of these, 65 zones are within the Columbus CBD. Approximately 100,000 private auto trips are made during the AM peak hour. In addition to private transport, all the transit lines in the corridor were also modeled.

9 The data collected as part of the study included aerial photographs/CAD drawings for geometry, traffic counts, posted speed limits and intersection control data. Data from the Automated Traffic Recorders (ATR) include traffic counts and vehicle classification. In addition to the ATR counts, the Ohio Department of Transportation (ODOT) gathers traffic counts using portable tubes at most of the entrance and exit ramps in urban areas. Due to the scope of the network, extensive manual field counts were obtained to supplement the limited automated data available from the DOT. Speed data at key locations on the freeway corridor and some important arterial roads, was obtained using the floating-car method.

The original CUBE planning model was calibrated and validated on a regional scale. This was translated to a VISUM model which was also calibrated further. Matrix estimation for the network was carried out using tighter constraints for high volume links (freeway/ramp segments) and principal arterials. These constraints were relaxed for minor streets and urban collectors. The first pass matrix estimation was based on only link counts. Once a satisfactory convergence was achieved in the first pass, turn counts were added as constraints to the matrix estimation process in the second pass. In all, 95 percent of available link counts and 95 percent of available turn counts were included in matrix estimation.

Two goodness-of-fit statistics—correlation coefficient and root mean squared-error—were used to compare the model assignment to observed traffic counts. Standard practice for ODOT is checking the percent RMSE (%RMSE) of specific volume groups against a prescribed maximum level. In addition to the aforementioned statistics, observed and simulated speed profiles along the freeway corridor were also measured and compared.

Difficulties encountered in modeling this large urban network include: • Utilization of several tools required throughout the study. Practitioners needed to be proficient in several traffic analysis tools and be aware of some common problems that crop up while using them. It was observed that the same data has to be entered into different programs, as the format of input data is different from program to program. • Data requirements for large-scale models are extensive. • Gathering field data for such models is a laborious and time consuming process. • The process of manual data entry for large networks is error prone, very time consuming and laborious. • Although computing power has improved during the past few decades, model convergence still takes substantial time for large-scale transportation networks. A computer with a P4 3.4 GHz processor and 3 GB of RAM was used to perform simulations. An additional 3GB of virtual memory was solely provided for the Dynamic Traffic Assignment (DTA) process. Overall, the DTA procedure required approximately 720 hours to achieve convergence.

The contractor reported a number of lessons learned that can be applied to future studies:

• It would be beneficial to have a standard input data format for some of the most popular tools associated with operational modeling so that essential data like traffic counts need not be re- entered. • Software modules that eliminate the task of repetitive data entry into different modeling tools and those that can effectively process large model outputs (to provide meaningful results from microscopic analysis) are vital for speedy development and analysis of large-scale transportation network models.

Although the contractors did not report to us any definite plans for use of this model in other projects, the intention to do so was indicated.

10 Kansas City, Kansas (PTV-VISION) The primary goal of this model, developed by HNTB Corporation, was to develop a traffic model to be used to forecast and simulate travel in the core area of Kansas City, Missouri with a sub-model for the CBD. The model in VISUM can be seen in the left part of Figure 7, while the more detailed VISSIM model of the CBD is on the right. The model represents the traffic demand of future development on the street and highway network. This model is the most detailed representation of this sub-area of the Kansas City region to date.

Figure 7: Kansas City center model in VISUM and VISSIM

Figure 8: Kansas City area. The Area modeled in VISUM is in the red box

The Kansas City CBD Travel Demand Model was developed with the software package, VISUM. VISUM is travel demand forecasting software that utilizes the traditional modeling process of trip generation, trip distribution, mode choice, and traffic assignment.

A traffic micro-simulation model has also been developed for the CBD loop area in VISSIM. This model contains a sub-area of the VISUM model. The simulation model provides additional traffic operations detail of travel in the CBD loop. In addition, transit route information has been added to the simulation model in order to reflect the impact of transit on overall travel operations.

The original regional model was in EMME/2 and was imported to VISUM. We were not able to secure information regarding the data used to calibrate the matrix further and specifically the more detailed calibration of the CBD for use in VISSIM.

The demand and simulation models have been used by the City of Kansas City, MoDOT and the KCATA to assess a variety of issues including: one-way street conversions, impacts of the KC Live Development,

12 impacts of street closures during construction, bus operations in the CBD, changes in bus routing, and effectiveness of changes to the CBD freeway loop.

Hessen, Germany (AIMSUN) The model was built to support the decision-making process as part of the Intermodal Strategy Manager, a traffic management system conceived to convey real-time traffic information to drivers in the Hessian road network and implement real-time management strategies in response to incidents, recurrent congestion, and planned events, such road maintenance on the network or events at the Frankfurt International Exhibitions (e.g. the International Car Exhibition every September).

The Hessen model was completed in 2003, the project was successful, and the system was accepted by Hessian authorities after a testing period. Preliminary results were presented at the ITS World Congress meeting in Chicago in 2002 and the final results at the same event in Madrid in 2003. The lessons learned from the Hessen model paved the path to what is now called “AIMSUN Online”, a new product for traffic management. In reality, the Hessen model was the one that issued the new developments implemented in Singapore and currently in Madrid. Considering the primary focus on motorway coverage of the model, it is less relevant to our needs as compared to the earlier examples. Regardless, the complexity and size of the model makes it notable and relevant for this report.

In total, 1,512km of total length in 245 zones for 462 intersections (200 controlled) on the freeway system were simulated in the section displayed in Figure 10. The planned strategies combined typical actions (speed control, rerouting, etc.) with specific actions based on information trying to convince the drivers to change their mode and use the park-and-ride facilities combined with the public transport (bus, train, and metro) available in the Frankfurt region.

There was a significant collection of traffic data available for this project (over 700 detection stations with 4 to 6 detection points each, depending on the number of lanes, collecting speeds, volumes and traffic mix every minute since 1998). Regardless, the following issues were encountered during model development:

• Availability of the control data for the approximately 200 controlled intersections (many off ramps of motorways have controlled intersections with the highways). The nature of the problem was administrative, not technical, as the owner of the control data was not a partner of the project. • O/D matrices from regional planning were poor, outdated and zoning was not finite enough in most cases. Matrix adjustment was a time consuming and difficult task. • Given its size and the amount of vehicles in it (about 100,000), running the model was initially a problem with the regular computers available in 2002-2003.

It should be noted, however, that while issues did exist during the project, the calibration was indeed successful and, with the current version of AIMSUN and industry progressions in computer hardware, the model can run faster than real time on a laptop with at least 5 GB of RAM.

Figure 9: Hessen motorway model

Milwaukee, Wisconsin (PARAMICS) Under the auspices of the Freeway Systems Operational Assessment (FSOA) project the Wisconsin Department of Transportation (WisDOT) developed a simulation model of all the freeway sections in the Milwaukee area. FSOA was a detailed examination of the safety and operational performance of the metropolitan Milwaukee freeway system. Performance measures are to support project scoping, evaluation, and programming, resulting in an enhanced WisDOT highway improvement program.

The study area includes 150 miles of freeways and parallel arterials with more than 40 system and service interchanges. The Marquette Interchange is the most heavily traveled system interchange with 300,000 daily volumes at the intersection of I-94/I-43/I-794. Based on ground traffic counts, 100-zone origin- destination trip tables for 2001 AM/PM/Adjacent peak/Off-peak traffic conditions were synthesized and validated. The calibration and validation of the Metro Milwaukee models were strategically carried out according to the FSOA simulation guidelines.

Figure 10: Milwaukee model

Munich, Germany (PTV-VISION) Within the research program INVENT, financed by the German Ministry of Research and supported by the automobile industry (mainly DaimlerChrysler, BMW and Volkswagen), PTV developed a VISUM and VISSIM model for the northern part of Munich as a simulation test site for new information technologies. Different ITS strategies for metropolitan areas, including en-route navigation with dynamic travel time information, were tested. In order to test various control methods like adaptive signal control linked with ITS on urban motorways and traffic information services, the simulation model was set up in 2003 and applied in 2004-2005. The model (mainly the motorway part) is also being used by the South Bavarian DOT as a decision support system for some widening schemes, reconstruction of entrances/exits and ITS control logics.

Figure 11: Munich North metro model

The current VISUM modeled area has a total length of 1,113km separated into 11,080 links. It is not known if the VISSIM model covers the same area as the VISUM one but it is most likely. The VISSIM model contains 6 motorway interchanges, 23 entrance /exit ramps, and 98 signalized intersections. The level of demand in the network is high (v/c>0.8 for many links) during 6 hours of peak traffic per day.

The original information was processed by VISEM. VISEM is an activity-based demand model. This is a model for the greater Munich region with socio-demographic data supplemented by a household survey and an additional survey for freight transport (Model WIVER). Trip chaining with VISEM allows generating hourly O/D-matrices per trip purpose (in this case 4 trip purposes). The regional model was calibrated against traffic counts for the base case of average weekday traffic. The regional model has been built by PTV and is currently maintained by the planning authority of the city of Munich. The sub-area network and sub-area O/D-matrices (per trip purpose) were generated from the regional model using the partial network generator of VISUM.

Time profiles (shares with 15min resolution) were overlaid on top of the hourly OD-matrices to simulate a day from 6am to 8pm. The time profiles were taken from a sample of 98 strategic continuous detector counts (45 on motorways). Counts were averaged over a period of 6 months with typical days to identify representatives. Three person-months were spent to identify representative count profiles from a database of traffic counts and for the re-calibration of the O/D matrices.

The MOEs provided by the study were the following:

• travel time per link and per O/D-pair for different time periods • delay per link and per O/D-pair for different time periods • v/c-ratio per link for different time periods • delay per turning movement at signalized intersections

The following are reported difficulties encountered during the life of the project:

• Gathering urban traffic control data was difficult since the traffic control unit of Munich was not involved as closely as the transport planning unit • For all intersections with actuated signal control, the original plans were available in a form that VISSIM could work with (VISSIM-Trends and VISSIM-TL similar to VISSIM-NEMA in the United States). However signal groups which were not modeled in the large urban model—like pedestrian and bicyclists—had to be eliminated manually (signal groups not modeled should be automatically ignored for future cases). • Calibration of the O/D-demand on an hourly level • O/D centroids and inflow for micro-simulation: the zonal size should not be too small in order to keep a reasonable amount of vehicles per O/D-pair and per time slice. On the other hand, inflow from centroid to adjacent network links should be lower than the capacity of that link. This required including additional connectors from centroid to links per zone so that traffic could distribute on various links without splitting zones, which would decrease the number of trips per zone.

To date, the following planning and operational decisions have been affected by this project:

1. South Bavarian DOT • Decisions on the length and width of extended weaving sections for three entries around the new soccer stadium (Allianz Arena) • Decisions on adding extra lanes in two cases and no-extension in one case • Decisions on control logics of ITS measures (shoulder lane usage at high volumes, dynamic speed control) • Testing ramp metering logics with no final decision yet • Results for BMW Group • Travel times for specific links for varying demands–network reliability for pre-trip travel information and benchmarks for on-trip travel information for the next generation of in-car navigation systems

2. Munich MPO • Proof of concept that an interface between a regional model and sub-models with micro- simulation works but has to be maintained by local staff

The simulation model is currently being extended by PTV to a full metropolitan network for the Munich region as one of the core tasks within the initiative ARRIVE.

Berlin, Germany (PTV-VISION) As part of the Traffic Management Center operations in Berlin, Siemens conducted a VISSIM study for the center of Berlin. The VMZ Berlin contains the metropolitan region of Berlin and the VISSIM network was built to gain some modeling experience for the downtown region. Lateron, a mesoscopic model, was chosen for real-time state estimation and real-time forecasting. During the development stage of the forecasting model, the VISSIM model was used to evaluate travel times as a function of demand and traffic control. VISSIM satisfied this purpose. In the later stage, the mesoscopic model did not model the signalized intersections in such detail as is done in VISSIM, so that the VISSIM model is not being used within the VMZ anymore.

17 Although the VISSIM model is not being used anymore by the VMZ because the real-time forecasting is done at a coarser scale without actuated signal control, the VISSIM model is still being used for various actuated signal control schemes, especially some transit priority schemes in the eastern part of the city. Micro-simulation with VISSIM is used in Berlin for every major transit priority scheme for trams and buses. Schemes outside the city center are modeled with dedicated VISSIM models not being linked to the city center model.

Similar to the previous examples, the modeling was a combination of VISUM and VISSIM, the latter covering only a subset of the scope. Specifically, the VISUM model has 6,016km of links (8,638 links) separated in 1,118 zones. The VISSIM model covers 272km (1170 links) in 152 zones. Additionally, the VISSIM model contains 217 intersections, 55 of which are under pre-timed control and 43 under actuated control.

Originally, a proprietary disaggregate tour-based demand model was developed for the city by the Technical University of Berlin. The survey data were converted to a VISEM activity-based demand model for Berlin with socio-demographic data supplemented by household surveys for three time periods (6am-9am; 9am-3pm, 3pm-6pm). The regional model was calibrated against traffic counts for the base case for average weekday traffic. Two hundred fifty detectors on urban roads were dedicated for traffic surveillance and strategic traffic control (not to control individual controllers) plus 200 sites on the urban motorway.

Figure 12: Berlin model in VISUM and VISSIM

These 450 detection sites were used to calibrate the regional model and generate suitable profiles for the micro-simulation model. The regional model has been built by a local Berlin consultant (IVU) and is now being maintained by VMZ Berlin. Sub-area network and sub-area O/D-matrices (per trip purpose) were generated from the regional model using the partial network generator of VISUM.

18 The MOEs provided by the study were the following:

Some of the lessons learned include:

• Coding intersections from scratch in VISSIM is time consuming (intersections are not modeled in detail in the regional model). • O/D-matrices were taken unchanged and, therefore, link flows matched reality much better than turning flows. However, for micro-simulation, turning flows are very important to get queues and spillbacks right.

The project took 9 person months for the micro-model only (mainly coding about 100 intersections).

Manhattan, New York (PARAMICS) The purpose of this model is to serve as a design evaluation and public presentation tool for the Route 9A rehabilitation. Route 9A is in lower Manhattan, NY and passes in front of the World Trade Center site. This project involves a very controversial issue where presentation is as important as engineering accuracy and utility. The size of the model covers approximately a 5 square mile area in lower Manhattan with all the signalized intersections and control strategies. The site experiences a high traffic demand.

The original O/D information was extracted from the NYC regional model. The expanded 15 minute matrices were initially adjusted based on detector volumes and speeds. Further fine-tuning was accomplished by matching manually collected queue sizes with strategic intersections. The main problem encountered was the calibration of path choice since in such a dense grid network there are a lot of alternative routes for each O/D pair.

The project took 1.5 years to be completed and the modeling part costs $200K-$300K with 50% of these funds spent for data collection. The overall Route 9A project costs more than $1M.

Xanadu, New York (PARAMICS) This project was contracted by a private firm and its objective was to analyze the effects of a new sports mall and new roadway projects around the New York Giants football stadium. The model covers an area of approximately 5 square miles. The complexity of the model is very high since it involves parking islands, 28,000 trips for the stadium plus other local traffic, as well as standard and toll freeway interchanges.

Like the majority of the presented examples, the initial information came from the regional model. The model used 10 minute O/D matrices which were calibrated with the help of detector volume and speeds collected in fixed and temporary locations in the area. Several scenarios were generated covering 6-10 different time periods in order to represent lane and link closures by the sports authority.

The cost of the project was approximately $1 million, with 50% spent on data collection for calibration and validation, and it took a little over one year to conclude.

There are no plans for further use of the model on other studies. The model was built with PARAMICS.

19 Lausanne, Switzerland (AIMSUN) This large urban network (4,100 links, 1,600 nodes, 290 zones) was built primarily for research purposes. The objective of its use was to assess the performances of probe vehicle-based travel time estimation methods and dynamic route guidance systems. However, the network edition and calibration has been funded with governmental money because the Lausanne City Council plans to use it for their internal studies. Consequently, they are currently using it for “traditional” applications of “what if…” questions, i.e. should they exchange signalized intersections for double roundabouts on congested places, etc.

The simulation project itself has been successful. Calibration and validation has been made on an evening peak hour base and has been considered as sufficiently good.

As is the case in many projects with large networks, the toughest problem came from the O/D matrix quality. An EMME/2 model maintained by a private company provided the original matrix. During the various calibration steps, several inconsistencies were found in the AIMSUN simulation data. It was discovered that in most of the cases the problem was coming from mistakes in the macro modelling in EMME/2. In other words, calibrating the AIMSUN network has been a good opportunity to recalibrate the EMME/2 model entirely. Another problem came from the relatively low number of comparison points in terms of traffic flow for a good calibration process (90 points). This is due to the fact that the loops used for adaptive control plans don’t record their data and are only locally (controller) used (as is the unfortunate case for a lot of intersections in the Twin Cities metro area). The 90 points used involved detectors installed for long-term statistical purposes.

Figure 13: Lausanne metro-wide simulation model

Helsinki, Finland (AIMSUN) At the beginning of 2002, the Finnish National Roads Administration (FNRA) addressed a very detailed and long questionnaire to their main software developers. At that time, FNRA maintained a master strategic planning model of Helsinki based on EMME/2 and was interested in a master operational planning model of Helsinki for operational purposes. The objective was not a specific application but to provide the support for future applications. In other words, have a master model that later on could be used either as a global model or to extract sub-models of districts and selected areas for specific studies.

Two tests were key in making the decision:

20 • An EMME/2 interface: an automatic translation of the Helsinki EMME/2 model into the simulator skeleton model. • The ability to dynamically open windows of sub-networks to generate sub-models.

Following further feasibility investigations, the FNRA proceeded in building the Helsinki model with AIMSUN. The resulting model has 3,188 links, 1,193 intersections and is separated into 339 zones.

We were unsuccessful in communicating with the provided contacts in the FNRA in order to collect additional information on the actual use of the model or regarding problems. We do know that they are still maintaining it.

Birmingham, UK (PTV-VISION) PRISM (Policy Responsive Integrated Strategy Model) has been developed by Mott MacDonald and RAND Europe as a new strategic model for the West Midlands in the United Kingdom with Birmingham as the center, supported by the seven district authorities, the highways agency and CENTRO (regional transit agency). The original model built during 2002–2006 is now being shared by different competing consultants under the supervision of West Midlands Planning Organization and CENTRO.

PRISM covers the West Midlands metropolitan area in 898 zones with 21,200km of a detailed network description including 5,895 intersection configurations of the highway and transit networks. The model operates in the VISUM software and represents in a detailed manner travel responses to congestion, investment, and policy change in trip-making, destination choice, mode choice, departure-time choice and route choice. The PRISM model has been designed to support assessment of the following issues:

• local transport plan submission and targets (federal funding in the UK requires such LTPs) • Metro and LRT extensions • park-and-ride schemes • motorway widening • general regional and local planning and policies

An important role is the geo-database with future scenarios and the database of travel movements as input for local models, including detailed micro-simulation studies with VISSIM. A number of local studies have now been conducted with VISSIM based on sub-area networks from the VISUM geo-database of PRISM. Some VISSIM models include:

• Extension of the existing LRT between Wolverhampton and Birmingham with a 3km extension in Birmingham City Centre with 14 LRT priority signals. The project was approved with major changes in alignment and control logic due to VISSIM micro-simulation. • Coventry Ring Road Study with different options of grade separation and intersection layout. VISSIM is of great help to identify suitable solutions and present those at public hearings.

A number of other confidential VISSIM studies have already been conducted based on the PRISM database. Currently a new VISSIM project utilizing the PRISM database is announced to study land-use, highway and intersection improvements and transit schemes in Longbridge.

While the VISSIM models in West Midlands are typically only single purpose models, the PRISM database based on the VISUM software will be maintained for many years, also serving as a multi- purpose database for VISSIM sub-area models.

Figure 14: Birmingham model

Figure 15: VISSIM subarea network of Coventry, VISSIM subarea network of LRT corridor in Birmingham Centre

The strategic model PRISM in the West Midlands differs in two respects from the majority of demand models found in the United States:

• The demand model is a disaggregate travel demand model which takes the individual traveler as the decision maker, rather than relying on zonal proxies. Because of the detail in the

22 representation of population, the model can forecast the impacts of socio-economic and demographic developments on travel patterns and distinguish the impacts of policies on different social grouping.

• The network topology is modeled with a lot of detail concerning intersections. Over 5000 intersections are modeled on a lane-by-lane level including the length of additional turning pockets. Using the dynamic stochastic assignment of VISUM, this topology allows getting fairly reasonable estimates of queue lengths of individual turning movements even in a strategic model. Furthermore this detailed junction coding allows easy data sharing with VISSIM.

A major task within PRISM was setting up a well-structured demand model which can reflect the current situation as well as forecasting future cases, including changes in travel demand due to demographic changes. As such a detailed population segmentation was carried out regarding car availability, worker status, gender adult status, and number of children based on the 2001 census, plus 14,000 household interviews, and roadside interviews at 200 sites. The roadside interviews were used for screenline analysis with assigned path flows.

Although the Birmingham model is not directly applicable to the needs of this feasibility analysis, we choose to include it to illustrate the collaboration between planning and simulation applications and how both disciplines can benefit.

Sydney, Australia (PARAMICS) Limited information is known about this project. The objective was to build a master model of the metro area to serve various regional and sub-region developments and operational strategies. The project was completed in 2002 and involved and area of 12sq km with 600 intersections (200 signalized). The calibration of the matrices extracted from the regional model was accomplished with the help of car park and link volume measurements. The modeling took approximately 2,000 person-hours. We failed to secure more detailed information other than the picture in Figure 14.

Figure 16: Sydney metro wide model in PARAMICS

Toronto, Canada (PARAMICS) Similar to the Sydney model, the Toronto metro area model was also built with Paramics. In the case of Toronto, the model was constructed and is maintained by the University of Toronto. Based on the lack of information and after consulting with engineers of the Toronto area transportation management organization, we can safely conclude that this model is not being used outside of the University. In a project not yet started that investigates the operations of the major freeway and arterials in the city, this model was not considered and a new one will be constructed.

Figure 17: Toronto network with Paramics

Stockholm, Sweden (AIMSUN) The Stockholm authorities had an objective and approach similar to the ones in Helsinki. They desired to build a micro-simulation model of the Stockholm metro area and they desired to accelerate the process by importing the geometry from their regional model. Unfortunately, this path did not prove to be a successful one. The current planning model is with CONTRAM and there are very large incompatibilities between the way CONTRAM describes intersections and the usual representation in a micro-simulator. Although the translation succeeded and the resulting model has a total length of 1,369km, 2,090 intersections and 346 zones, the additional manual effort to adjust the intersection information exceeded the available funds. The current project has been abandoned for now, but as the head engineer told us, the need for a metro-wide model exists and the project might be resurrected in the future.

Figure 18: Stockholm metro-wide model in AIMSUN

London, UK (PTV-VISION) The London Transit Authority is currently scoping a new project. The intended first phase involves the area of central London, has a length of 220 miles and 2,000 intersections, 250 of them signalized and coordinated with the SCOOT strategy. Preliminary figures show the planned area. The model will be initially built in VISUM, but it is unclear how much of this area will be modeled in VISSIM for micro- simulation purposes.

Figure 19: Proposed study area in London, UK

26 Projects with little available info PTV America also identified several projects that might pertain to our feasibility investigation, but we failed to secure any additional information. They are all VISUM+VISSIM (PTV-Vision) projects but their differences are unclear. All projects took approximately eight months to a year for the modeling part alone.

• Dubai, UAE – 400 sq km – 85 controlled intersetions, 10 controlled and 5 uncontrolled roundabouts, 8 freeway interchanges – Evaluate incident management (ITS) – Regional model based with adjustments from manual and automated counts – Calibration based on counts and travel time studies

• Cleveland, Ohio – 50 signalized intersections with mid block pedestrian crossings – Analysis of transit signal priority – Regional model based with adjustments from manual and automated counts – Calibration based on counts and travel time studies

• Detroit, Michigan – 70 signalized intersections – Analysis of transit signal priority – Data from prior models reused along with new manual counts and filed obtained travel times

• Dallas (1) • Area: 120 signalized intersections • Objective: impact of new light rail line

• Dallas (2) • CBD access study • 200+ signalized intersections • Dynamic traffic assignment

27 Chapter 3 Stakeholder Interviews

The second task of the metro-wide microscopic model feasibility project called for an investigation of current needs and practices that could be covered or enhanced with the use of a metro-wide microscopic model. The investigation was based on interviews with local stakeholders including Mn/DOT, the Metropolitan Council, Hennepin County, and others. The interviews covered the following elements:

• A summary of the findings of the literature review and a short presentation of the examples collected during the first task of the project. Attention was drawn to the objectives of the examples and the subsequent utilization of the various metro-wide models. • Open-ended questions were posed:

o If such a simulation engine was available would you be interested in using it? o What applications are likely to be most suitable for your purposes? o What is keeping you from using simulation for such applications today? o Do you envision such an engine to be a way of the future or do you think that the current way of doing things is good enough? o Do you agree that microscopic simulation should be used in conjunction with planning tools for complex applications? Any examples? o What are the major obstacles in reaching this vision?

• Depending on the response received, we either drilled down to specific applications or offered some of our own vision for the utilization of a metro-wide model of the Twin Cities:

o Allowing engineers or agencies to access any part of the area they wish to simulate for a particular project. o Eventually allowing real-time incident management, travel time estimation/forecasting, and other demanding ATIS/ATMS applications. o Allowing more sophisticated planning analysis beyond the traditional 6 step process when warranted. An example includes the effects of hot lanes on a corridor or the entire freeway network. o Allowing larger scale planning and evaluation of Transit strategies like bus rapid transit, LRT lines, etc.

• In the cases where the general consensus was that a metro-wide model will be beneficial and desired we concluded with a short discussion regarding the development stages and the data availability from the point of view of the specific stakeholder.

The following sections attempt to capture the outcome of the interviews with each stakeholder group.

28 Interview with Metropolitan Council Planners The Metropolitan Council has two major functions related to the overall Access to Destinations Study:

1. To analyze, predict, and guide present and future land use changes and development. The main tool utilized for these purposes is a GIS package. 2. To model, analyze, and predict travel demand on the Twin Cities transportation network. This function mainly involves the application of the four-step process of trip generation, trip distribution, mode choice, and trip assignment. The main tools utilized for this function are the TP+, CUBE VOYAGER, and TRANPLAN planning packages.

The interview was with people from the transportation group and focused on their needs. The consensus was that the first group has no interest in a metro-wide simulation model, therefore there was no need for a separate interview. Regardless, the basic need for exchange of information between groups has been noted for future reference.

The macroscopic models involved in the four-step process are designed to produce static results. From the discussion, this was the major point of difference with a microscopic model. Specifically, the planning model does not take into account the dynamic effect introduced in the system by traffic adaptive control strategies like the Minnesota stratified ramp control algorithm or urban street control system like SCOOT and SCATS. One of the needs expressed by the stakeholders was the analysis of the impact these control systems have in the entire system.

From the discussion, it was concluded that the availability of a metro-wide model will allow the expansion of the scope of major transportation projects like new LRT lines, the I-394 HOT lane, and others. Although it was pointed out that no financial savings can be expected in each project, the availability of a metro-wide microscopic model will allow for more thorough evaluation of the proposed designs as well as illustrate their impact on the entire system.

There was a small discussion regarding the utilization of the metro-wide micro-simulation model for the improvement of the planning model. Although no specific details were analyzed, the discussion uncovered the following possibilities:

o Locally calibrated sub-areas can produce more accurate travel time–volume relationships. The planning model depends on predefined travel time – volume relationships in the final step of trip assignment to paths. As it stands today, these relationships are very difficult to calibrate since collected travel times are rarely collected simultaneously on all alternative paths of an O/D pair. As more sub-areas of the microscopic model are calibrated due to different projects in the region, the more accurate the metro-wide simulation model will become. It is conceivable that iterations between the planning and the micro models will yield improved estimation of both O/D volumes as well as link and path travel times. Naturally, the micro model will also take into account the actual traffic control in the production of the path travel times. o Assuming the software applications used in the creation and maintenance of the planning and micro models are able to exchange information, the geometric accuracy for the planning model might be improved by importing the more geometrically and topologically accurate model built for the micro-simulation. Again in this application, we assume that the micro model will benefit from various smaller projects, that accurately represent smaller areas in the metro region, to slowly improve the overall model accuracy as well as stay up to date on network changes.

The discussion concluded with the subject of project staging. The consensus was that the first necessary step would be to build the freeway and highway network. Specific attention was given to the inclusion of all highways and expressways including, HW-61, HW-120, HW-81, HW-55, HW-52, and more.

29 According to metropolitan council staff, even this level of coverage will produce a micro model that can be used for the improvement of the planning one. Similarly, a freeway and highway-only micro model will also be a good start for seeing benefits on smaller scale sub-area projects.

Interview with City of Minneapolis traffic engineers In the interview with engineers from the City of Minneapolis, three representatives were present from the city planning, traffic control, and maintenance departments.

Early in the discussion it was clear that the city does not have projects that span its entire area, or at least no projects that might benefit from a metro-wide micro-simulation model. With respect to planning projects, the city depends on the Metropolitan Council for modeling and analysis. Regardless, if a metro- wide or Minneapolis and surrounding areas micro model existed, they might expand their current scope into needs and projects that can utilize such a model.

Although they closely collaborate with Metro Transit, the city does not get involved in transit planning for the region so this is also an area of no benefit. When posed with a question regarding big projects like the North Star commuter rail corridor, or the Central Corridor LRT, they replied that they participate in the analysis and planning done by Hennepin County or the Metropolitan Council.

Specifically, in regards to the new baseball stadium plans, as well as other special events, they are interested in expanding their analysis to a larger area. In addition, the city engineers are interested in real- time applications of traffic control and operations during such special events. According to their traffic control engineer, they will soon have the capability to dynamically control the traffic lights anywhere in the city. A real-time simulation tool would assist them in such a task.

Interview with local Federal Highway Administration (FHWA) representative Locally, the focus of the FHWA division office is in the smaller scale CORSSIM-style analysis of interstate access improvement. In that regard, they are keenly interested in expanding the use of micro- simulation and in the establishment of good practice guidelines. They are not interested or involved in larger scale planning level projects or applications. Regardless, for such applications they are suggesting the use of Dynasmart-P software that FHWA has developed and supports. No specific applications were discussed in that regard.

Interview with Regional Transportation Management Center (RTMC) engineers An interview with RTMC staff was conducted separately from the main Mn/DOT stakeholder group discussed later in this document. Specifically, this interview explored the utility of a metro-wide simulation model for traffic operations prompted by the large-scale, real-time simulation examples collected during Task 1 of the project. In general, the RTMC does not deal either with simulation or planning. Regardless, they see large value in the availability of a metro-wide micro-simulation model, specifically a freeway-wide one, and would be eager to use it in the following cases:

o Global optimization of the stratified ramp metering strategy. In a similar way, such a model will be useful in subsequent developments and improvements of the ramp control strategy. There are a plethora of traffic conditions for which the ramp control strategy can be optimized to generate a long-term use of the metro-wide model. o Investigation of certain special events and the impact they have in the entire freeway system. A network-wide tool for traffic management strategy evaluation is currently missing. Strategies are created by experience but fall short in really rare cases. This need is limited to foreseeable rare events and does not promise continued use.

30 o Real-time analysis of special events. In response to the growing number of examples of the use of simulation in real-time operations, RTMC engineers do not see the need yet for such extreme management tools. They do see the utility of a metro-wide model for the quick evaluation of traffic management scenarios during special events. o Post incident management analysis and training. Certain large-scale incidents impact traffic conditions in a very large portion of the road network. The impact area usually includes major arterials and highways. Currently post-incident analysis is conducted in a heuristic, experience- based way. According to the RTMC engineers, such a practice can be greatly improved with the use of metro or freeway-wide simulation model. o Investigation of short and long-term construction zone impacts on the system. Traditional analysis of workzone traffic management has been confined to the area of the actual project. Experience has shown that separate construction projects can generate far-reaching interruptions in traffic, unforeseen by the analysis of the individual cases. A metro-wide model could be helpful in such cases.

Interview with Hennepin County and City Engineers In addition to Hennepin County engineers, city engineers from Maple Grove and Eden Prairie participated in the interview. The discussion involved two major areas. The first area was the feasibility of a metro- wide simulation model in terms achieving accuracy at an appropriate level for the given objective. The second area was the needs of the county and cities with respect to simulation and modeling in general. In regards to the achieved accuracy, the idea of a metro-wide simulation model was compared with the proven use of the four-step planning modeling methodology. As stated in the interview, if the metro-wide model cannot reach a global accuracy superior to that achieved by the four-step approach, then it appears to be more cost effective (for large applications) to stay with the four-step approach and only model small areas with a micro-simulator. This opinion was reinforced by the county engineers who feel that the four- step approach is adequate for their current planning needs. As stated during the interview, the county does not have a pressing need to look at the entire metro area at the level of a microscopic simulator. They are dealing with problems on the arterial level with applications like Synchro and Simtraffic. The city engineers felt that larger areas need to be evaluated. Specifically, feelings were expressed regarding the current policy of Mn/DOT not to include local streets in their analysis of freeway access facilities. The consensus was that the level of interaction between the local streets and the freeway is such that the location of entrance and exit ramps greatly affects a large area of the city local streets. It was not clear if the size of this area is large enough to justify a large-scale microscopic model. As stated in the interview, Hennepin County and the participating cities have minor involvement with regional transit planning done by Metro Transit. Regardless, the engineer from the city of Maple Grove stated that such collaboration would be welcome. Overall, the county’s need for a metro-wide simulation mode is limited to the benefit such a model might have for other collaborating organizations; for example, in increasing the accuracy of the Metropolitan Council Twin Cities planning model or allowing Mn/DOT to extend the analysis of freeway access to the local street level.

Interview with Mn/DOT Staff and Transportation Consultants Although aimed at identifying Mn/DOT’s needs and interest for a metro-wide micro-simulation model, the meeting attracted a large number of engineers from transportation consulting firms. The interest in a potential metro-wide simulation model was strong. The discussion moved quickly into the following types of questions: • How can you build it? • Can you extract segments and simulate them independently? • How can the demand data be maintained so that it is up-to-date?

31 • What will be the effort of building the geometry? The consultants from the beginning showed interest and agreed that if such a model existed, they would have use for it by either extracting and working with pieces of it, or using it in conjunction with the four- step planning programs to complete the information available on demand patterns. Mn/DOT engineers pointed out that the format for such a model would depend on the application. For planning purposes, the four-step approach is adequate but the metro-wide model would be beneficial in the following situations: • Evaluation of traffic operation strategies: for example, closing TH-36 completely for a reconstruction project. In such cases, evaluating only the freeway will not be sufficient. The analysis must include all adjacent arterials. • Geometric improvements: planning programs cannot handle geometric improvements like the ones envisioned for I-94 in downtown Minneapolis or the evaluation of HOT lanes operation. • Transit applications and their interactions: new LRT and BRT lines, and their influence of, and by, the HOT lanes. • Emergency evacuation planning and scenario evaluations. • Smaller projects where only a segment of the network is needed but the greater network needs to be present in order to extract accurate demand patterns. The Metropolitan Council model has difficulties in providing realistic O/D patterns for small areas of the network. Locations like the I- 94 in downtown Minneapolis require very accurate O/D information in order to capture the weaving and lane densities that are the cause of the problems encountered there. • The creation and use of such a model can be the catalyst for the consolidation of data related to the Twin Cities transportation network. Data is currently kept by different organizations and there is a lack of established communication channels for information dissemination. The group also pointed out several areas of potential difficulty in developing a metro-wide simulation model. Specifically, the amount of effort required in entering the geometry is important even if it is assumed that the basic structure of the network will be imported from a planning model. Additionally, the quality and upkeep of the demand data is an issue better solved before such an undertaking is begun. Similarly, the network is constantly changing therefore consideration must be given as to which authority will maintain and update the model.

Interview with Metro Transit Staff Following the pattern of the earlier interviews, the interview with Metro Transit staff included a short presentation of the other large simulation model and a summary of the findings so far. The following is a compilation of comments received during the interview as well as comments send to the research team in later days. Metro Transit was interested in both the real-time application (the only group interviewed who was interested in this application) and the off-line application of a metro-wide model. They described two possible application scenarios: o For the off-line application, the metro-wide model is calibrated based on historical AVL information and loaded with a “typical” flow and demand. The goal in this is to analyze the operation of many transit lines simultaneously; planning and managing transfer stations and schedule plans. Considering the span of Metro Transit operations, the required model, even if it is not metro-wide, will have to be very large. o A real-time application would assist in feeding the system with “live” AVL data in order to predict short-term traffic and service conditions and propose appropriate responses that can be actuated automatically – by traffic control signals or suggested action to management. For example, a situation was posed where a choice exists between the use of the freeway or a parallel arterial route for a BRT route. With the use of a real-time simulation model, the two alternatives can be quickly evaluated and the one with the shortest travel time selected.

32 In both of the aforementioned applications, the attractiveness of these systems to Metro Transit is the proactive potential. Today, they react to customer-generated service complaints. It was suggested that a metro-wide, or even a large simulation model, can be augmented with the integration of a Transit Passenger Model. The latter will provide passenger demand and can work with the traffic model in estimating the service performance of the transit lines as well as take into account transit stop, transfer station, and park-and-ride capacities, utilization, and optimal location. The research team has no experience with transit passenger modeling, therefore such an application requires further analysis in order to judge its feasibility. It was pointed out during the interview that the goal of Metro Transit, finding ways to speed up operations and be most competitive with automobiles, is hampered today by the lack of coordination with other organizations. Specifically, in terms of traffic control schemes like signal priority and transit optimized signal control, the current level of collaboration and information exchange is not optimal. The idea is that the consolidation of information required for the creation and maintenance of a metro-wide traffic simulation model would make the acquisition of information as well as the collaboration for changes easier and more efficient. Similar to other groups interviewed, the Metro Transit people believe that the creation of a metro-wide traffic simulation model is an enormous task and need to be approached in a staged manner. Specifically, they propose to start by creating the model of a piece of the area such as the I-394 ICM project or an area covering one or more local arterials in Minneapolis (outside of the downtown area).

33 Chapter 4 Overview of Commercial Applications

The intent of this chapter is to highlight the capabilities of available simulation packages and focuses on the ability of each package to integrate strategic planning and operational simulation functions. It should be noted that the information contained in this report is based in large part on information received from developers; considering the complexity of these software applications, it is not possible to verify all features and capabilities outside of the specific aspects deemed important for the development of a metro- wide simulation model.

The packages of interest for this report are:

1. PTV Vision (VISUM/VISSIM) 2. Transmodeler (TransCad/TransModeler) 3. CUBE (Voyager/DynaSim) 4. AIMSUN (EMME2/AIMSUN2) 5. PARAMICS (Estimator/Modeler) 6. DYNASMART-P

For the benefit of readers not familiar with the theories and modeling assumptions underlying applications of this type, a brief discussion of different modeling approaches is included.

Current generation of simulation models The increasing complexity of transportation systems highlights the demand for a variety of modeling capabilities for the distinct purposes of 1) long-term transportation planning, 2) short-term operational planning, and 3) traffic operations analysis. Depending on the level of detail of their traffic flow representation, transportation models, and by extension commercial applications, can be categorized into three types, namely macroscopic, mesoscopic, and microscopic. Each of these complementary approaches plays a well-defined role in transportation analysis, as each one has unique characteristics to answer appropriately certain questions that the others cannot answer as effectively. The following table summarizes the pros and cons of each approach.

The most widely used models are the macroscopic travel demand models, partly because they are the oldest most mature technology and because they require the least amount of information for their development and operation. The focus of these models is to utilize ten-year census, socio-economic data with estimated roadway capacities to produce rough estimates of the distribution of traffic over a very large metropolitan network. These models produce static O/Ds for either an average day (24-hour matrix) or, at best, two peak period ones. Considering the aforementioned limitations, it is logical that such models totally miss the effects of the ordinary traffic fluctuations, special events, traffic control, or traveler information strategies. Regardless, these models are the most logical first step for any traffic analysis. Programs like CUBE Voyager, TransCAD, VISUM, AIMSUN Planner and others belong to this category.

Mesoscopic models are a recent addition to the traffic analysis tool box. These models support transportation network planning and traffic operations decisions, including evaluation of ITS deployment options, through the use of simulation-based dynamic traffic assignment. Mesoscopic models provide the capability to model the evolution of traffic flows in a traffic network, which result from the decisions of individual travelers seeking the best paths en-route over a given planning horizon. It overcomes many of the known limitations of static tools used in current planning practice. These limitations pertain to the types of alternative measures that may be represented and evaluated, and the policy questions that planning agencies are increasingly asked to address.

Meso models define a new generation of transportation planning methodologies, which can interface readily with existing four-step procedures, yet provide a meaningful jump in the range and type of measures that can be evaluated. Because they consider the time-varying nature of traffic flows, meso models are expected to produce more useful estimates of stated variables such as speeds, queue lengths, delays, and congestion effects to better assess the functional and environmental impacts of a variety of traditional and emerging transportation planning measures, including the deployment of ITS and non-ITS technologies. Naturally, mesoscopic models require more information for their development than the macroscopic models, but one can still get by with an average picture of the system. For example, using a default traffic plan for non-critical intersections rather than the real one. Mesoscopic models generally recognize two types of traffic, moving and queued. This is adequate for arterial streets where traffic is governed by intersection control and traffic fluctuations are small. Freeways, where road geometry and factors like traffic composition and driver behavior generate large and wide spread traffic fluctuations, are not captured well by the currently available mesoscopic models. Programs like Dynasmart-P, DynaMIT, Dynameq, and CUBE Avenue Extension belong to this category and focus mainly on the implementation of dynamic traffic assignment.

35 Microscopic traffic models reached the market earlier than the mesoscopic ones, and were initially oriented towards specific, limited-size projects of new construction or traffic control. These models emulate traffic down to the individual vehicle based on models of driving behavior. Due to their detail in representing the system, these models require the largest amount of information for their development. Accurate traffic control plans, link costs, roadway geometric features, traffic composition, and driving behaviors are essential information. Assuming one can provide all this information and calibrate them; microscopic models will produce the most accurate result as well as provide the most robust platform for evaluating any traffic management strategy. Regardless, with the progress of computing systems as well as larger and more organized GIS systems metro-wide implementations of microscopic models have emerged. As outlined in Task 1, most notable are the models of Singapore, Madrid, Sydney and others. One common factor in all of these projects is that all required well-behaved macroscopic travel demand models to produce the starter set of O/D information for time division and adjustment based on accurate closely spaced detector infrastructures. The first has prompted an all out integration of macroscopic travel demand applications with microscopic simulation ones, and the potential of these now as a single application. The second point (detector infrastructure) still renders large-scale model development a very costly proposition or in many cases an impossible one. The programs with the largest market share in microscopic simulation are AIMSUN NG, CUBE, PARAMICS, and PTV Vision (VISUM + VISSIM).

Emerging developments During the most recent large-scale implementations of microscopic models, it was observed that in the larger areas of the network (most arterial streets) where traffic has few fluctuations, microscopic models produced similar results with the mesoscopic models; therefore, not justifying the very large cost of their development. This realization has sparked the still embryonic development of mesoscopic-microscopic integrated models. The objective of these hybrid models has been for now isolated in the development of decision-support simulation tools for operational planning and traffic operations. This multi-resolution approach that combines both mesoscopic and microscopic simulation models can be seen in Figure 18. The mesoscopic model predicts and evaluates regional traffic diversion, and the resulting traffic flow from this model serves as input to the microscopic simulation model, where detailed traffic control strategies can be evaluated.

Modeling Requirements

Regional Traffic Diversion Detailed Traffic Dynamics

Mesoscopic Simulation Microscopic Simulation

An Integrated Multi-Resolution Simulation Model Figure 20: Multi-Resolution Simulation Model Approach

Current research and practice make extensive use of both mesoscopic and microscopic traffic simulation models, but they rarely integrate the two. However, there is a growing awareness that single resolution simulation models may not be sufficient to handle large-scale complex transportation network problems, and that integration of simulation tools at different resolutions is required. As a signal of this trend, several commercial traffic simulation developers, for example AIMSUN NG and TransModeler have started to offer simulation models at all three levels.

36 • Interface with the suite through COM where users can write their own scripts to automate workflow tasks.

The primary components of interest in PT Vision for this report are VISUM (travel demand modeling) and VISSIM (microscopic simulation) and will be discussed in later sections. In addition to VISUM and VISSIM, PT Vision is comprised of:

• VISUM Information Server - a universal information and forecasting tool for all transportation planning processes. The integrated data platform processes both transportation model data and data from external systems. • VISEM – a generation model that will display activities and their link to a "mobility program" for demand modeling and trip generation. This model distinguishes between several homogeneous behavioral population groups and generates a specific set of activity chains for each of them. One can also create future scenarios to accommodate the availability of diverse forms of transportation, group membership, activity chains and other parameters required for the specific decision-making situation. It can also create travel demand data in the form of trip matrices based on model data and calculations generated within. • INTERPLAN - the operational planning system for public transport. The following tasks can be planned with this software: timetable and vehicle scheduling, crew scheduling, and duty- rostering. • INTERPLAN/select - the operational planning system for individual crew scheduling (bid processing) and driver dispatching. • SITRAFFIC P2 – a traffic engineering workstation that provides all functionalities required for editing of individually controlled and coordinated traffic signal controls. It includes export/import mechanisms for data exchange with the control device program Control as well as with the microscopic simulation software VISSIM. It also supports the OCIT in-station VI standard interface for data exchange with software components from different software providers.

VISUM Overview VISUM is an information and planning system that combines all aspects of strategic planning along with operational planning. The current VISUM release allows the user to directly integrate real-time data into the strategic planning process. It is therefore possible to evaluate the impacts of strategic planning on operational planning by using real-time data. Additionally, it enables the planner to integrate the values resulting from changing conditions into the planning process.

VISUM can import models from other applications (EMME2, TMODEL2, CUBE, and TRANSCAD). It has scripts to automatically generate those items required for an accurate network representation.

Data modeling in PTV Vision covers the four stages of standard transportation modeling. VISUM offers integrated procedures for traffic and transportation generation, distribution and transport mode choice, thereby initially displaying a trip-end model on the basis of the trip purpose. The model approach based on activity chains or O/D groups is used for traffic generation in VISEVA and VISUM. The chart below explains the structure of the VISUM system:

User interface Program use/ Network editing Interfaces/Data exchange/Display of workflow (COM + VB + Python)

Travel demand model Network model Origin, destination, number of trips, temporal contains supply data: Transport system, traffic distribution of travel demand zones, nodes/stops, stop areas, count points, POIs, links, PuT lines

Impact model Methods to determine impacts User model: Traffic assignment, calculation of service indicators Operator model: Number of vehicles, line costing, revenues Environmental model: Pollution and noise emissions

Results Lists and statistics (calculated attributes of network objects and routes) Indicator matrices (journey time, number of transfers,...) Graphical analyses (flow bundles, isochrones,...) Plots

VISSIM Overview VISSIM is the associated microscopic, time-step and behavior-based simulation model developed to model urban traffic and public transit operations. The program can analyze traffic and transit operations under constraints such as lane configuration, traffic composition, traffic signals, transit stops, etc., for the evaluation of various alternatives based on transportation engineering and planning measures of effectiveness.

VISSIM can be applied as a tool in a variety of transportation problem settings. The following list provides a selective overview of illustrative applications: • Development, evaluation and fine-tuning of transit signal priority logic.

39 A simulation technology that, in the opinion of some, covers all of the above levels of functionality and resolution is TRANSIMS, developed by the Los Alamos National Laboratory. TRANSIMS is an agent- based simulation package that has modules for macroscopic and microscopic simulations. The microscopic model employed in TRANSIMS is a cell-transmission, car-following model. In general such models have displayed bad performance in replicating realistic traffic flow patterns, specifically when merging and weaving is involved. In addition to the above shortcoming, TRANSIMS has a notorious computing power requirement and execution speed. Although TRANSIMS is a free open-source application, this project aims to create a tool for use by local stakeholders with reasonable resources and professional support for the core application.

Review of Simulation Packages

PT Vision

PT Vision is a suite of products offered by PTV AG that incorporate strategic, operational, and traffic management applications. PTV Vision enables users to work on a variety of applications. For example, the same user can apply PTV Vision to a planning study that has regional implications as well as to an operational study along an urban roadway where traffic management concepts are evaluated at the roadway and intersection level.

Figure 21: PTV-Vision

PTV Vision provides the ability to:

• Share data elements between simulation and travel demand modeling. • Incorporate real-time traffic data into the planning and analysis phases of a project. • Share data across the internet among various transportation organizations. Depending on the level of access granted, these organizations can even query the transportation databases managed by PTV Vision. • Access GIS data from sources like ArcGIS, Mapinfo and NAVTEQ to build and update/maintain model networks for a sub-area/corridor, metropolitan region, evacuation area or an entire country. • Perform intersection level-of-service analyses based on the Highway Capacity Manual, or other commonly used capacity analysis methodologies. • Share data with signal timing optimization programs and then import optimized timings back to PTV vision. From there, the timings can be uploaded to the field and/or used to evaluate scenarios.

37 o VISSIM can use various types of signal control logic. In addition to the built-in fixed-time functionality, there are several vehicle-actuated signal controls identical to signal control software packages installed in the field. In VISSIM some of them are built-in, some can be docked using add-ons, and others can be simulated through an external signal-state generator that allows the design of user-defined signal control logic. Thus a variety of signal control logic (including SCATS and SCOOT) can be modeled and simulated within VISSIM if either the controller details are available or there is a direct VISSIM interface available (e.g. VS- PLUS). • Evaluation and optimization (interface to Signal97) of traffic operations in a combined network of coordinated and actuated traffic signals. • Feasibility and traffic impact studies of integrating light rail transit into urban street networks. • Analysis of slow speed weaving and merging areas. • Comparison of design alternatives including signalized and stop sign controlled intersections, roundabouts and grade separated interchanges. • Capacity and operations analyses of complex station layouts for light rail and bus systems have been analyzed with VISSIM. • Preferential treatment solutions for buses (e.g. queue jumps, curb extensions, bus-only lanes) have been evaluated with VISSIM. • With its built-in dynamic assignment model, VISSIM can answer route choice dependent questions such as the impacts of variable message signs or the potential for traffic diversion into neighborhoods for networks up to the size of medium sized cities.

As with VISUM, VISSIM can be used as a stand-alone application. Creation of the model can either be completed through import tasks or edits within the system.

Microscopic Sub-Area Analysis As described earlier, sub-area analysis is possible between VISUM and VISSIM due to the integrated nature of PT Vision. From any given planning network and assignment in the demand modeling software VISUM, a consistent VISSIM network can be generated. The data flow diagram provides the appearance of a seamless integration between VISUM and VISSIM. It should be noted, however, that depending on the level of complexity of either model, fully automated transfer may not occur and steps three through six below will require user intervention. If the VISUM model is set up at a granular enough level, the translation to VISSIM can be automatic. If the VISUM model is more aggregate, the user may wish to manually control the individual objects.

Figure 22: PTV-Vision Data Flow

Microscopic sub-area analysis begins from a given planning scenario in VISUM. Once the specific corridor or sub-area is selected all network data and assignment results of this sub-area network are then handed over to VISSIM for its runs. Steps required are:

1. Identify sub-area in macroscopic network. 2. Highlight the sub-network of interest. 3. Refine the node-link network and the TAZ system (if necessary). 4. Adjust turning movement volumes (if necessary). 5. Add additional intersection geometry and signal timing data (if necessary). 6. Generate VISSIM input data (automated). 7. Run microscopic simulation. 8. Refine the simulation as necessary.

The integrated nature of PT Vision will allow a user to develop operational plans from a given strategy and also use actual results to help shape the strategy.

TransModeler

Caliper Corporation, a worldwide developer of transportation and GIS software, designed TransModeler for ease-of-use by traffic engineers and planners. TransModeler has an intuitive user interface and is the only simulation software that fully supports Windows standards. TransModeler lets the user create and manage multiple projects, networks, demand profiles, and traffic signal control strategies for alternatives analysis. With TransModeler the user can:

• Import simulation data from Corsim and SimTraffic to take advantage of TransModeler functionality.

41 • Manage a variety of input files for multiple scenarios including ArcInfo, DGN, MIF, ITD, VPF, and NTAD to name a few. • Share project databases, traffic signal timing plans, and other input data between multiple projects. • Export subareas of larger networks to simulate traffic operations on a more localized scale. • Compare output results from multiple simulation runs. • Generate formatted reports, maps, and charts for inclusion in reports and presentation slides.

TransModeler has a GIS architecture that integrates traffic simulation models with a geographic information system (GIS) that has been extended to store, maintain, and analyze transportation and traffic data. TransModeler provides a tool for compiling, maintaining, and utilizing traffic data in simulation and other forms of analysis. TransModeler allows the user to keep important city or regional traffic information such as traffic counts, lanes, and speeds in spatially accurate databases that can be readily accessed and updated as well as directly applied in traffic simulation and travel demand forecasting. The user can store and simulate traffic signal timing plans for multiple scenarios and times of day. In addition to using TransModeler as a simulator, it can be used as an enterprise or metropolitan-wide database system for traffic and related data.

TransModeler is a versatile traffic simulator with features including support for key aspects of intelligent transportation systems. TransModeler simulates a wide variety of facility types, including mixed urban and freeway networks, and may be customized for modeling specific geographic areas such as downtowns, highway corridors, or beltways. It allows the user to:

• Model freeway and urban networks in the same network with driver behavior models that are sensitive to complex inter-vehicle interactions in merging areas and intersections. • Simulate common traffic signal systems, including pre-timed and traffic actuated signal control. • Simulate more complex traffic signal control systems, including coordinated and coordinated- actuated control. • Model signal preemption strategies for transit or emergency vehicle applications. • Evaluate signal warrants and generate timing plans based on turning movement volume tables. • Apply customizable templates to create actuated signal controllers, either based on a ring & barrier concept, or phase group diagrams. • Model rotaries with driver behavior models that capture the unique interactions between vehicles entering and vehicles inside the rotary. • Model high occupancy vehicle (HOV) lanes, bus lanes and toll facilities to better understand their effects on traffic system dynamics. • Model evacuation plans and scenarios for response to natural disasters, hazardous spills, and other emergencies. • Model work zones to manage traffic during construction and maintenance projects. • Simulate complex lane choice and other driver behavior phenomena at toll plazas with electronic, manual, and hybrid payment booths. • Vary service times at toll plazas by booth and by vehicle type. • Simulate the impacts on traffic operations of electronic toll collection facilities and booth closures.

TransModeler simulation scenarios may be run at multiple levels:

Microscopic - When used as a microscopic simulator, TransModeler simulates the behavior of each vehicle every one-tenth of a second. Vehicles can vary in terms of their physical and performance characteristics, and can be custom-defined by users. Acceleration, deceleration, car following, lane changing, merging/yielding, and movements at intersections are simulated in

42 detail and are affected by driver aggressiveness, vehicle characteristics, and road geometry. While default settings are provided for important behavioral models, users can easily change the parameters of these models. Dynamic Traffic Assignment - TransModeler can determine vehicle routes using dynamic traffic assignment of O/D trip tables. Travel times by time period and network segment can be input from external data or developed by running traffic assignments and traffic simulations. Vehicle paths can also be input from external files including those generated by TransCAD and/or created or edited by analysts. Mesoscopic and Macroscopic - TransModeler can also simulate wide area networks at varying levels of fidelity and with different simulation methods. TransModeler includes mesoscopic and macroscopic simulators in addition to its microscopic simulator. In the mesoscopic simulator, vehicles are collected into traffic cells and streams and their movements are based upon predefined capacities and speed-density functions. Individual vehicles are tracked, but vehicle movements use aggregated speed-density functions rather than car-following and lane-changing logic. In the macroscopic simulator, vehicle movements are based upon volume delay functions that depend upon the functional class of the road system. The operation of traffic signals is not modeled explicitly in mesoscopic and macroscopic simulation. Rather, signal timing plans are converted into equivalent capacities for turning movements. Capacity constraints and queue spillbacks are examined before vehicles enter and exit segments, so that queues will form when capacity is not available downstream. A time-based approach is still used, but the time steps do not need to be as fine-grained in these simulation modes. Hybrid - TransModeler provides a hybrid simulation capability in which high fidelity micro- simulation can be intermixed at will with mesoscopic and macroscopic simulation on any network segments. Portions of the network of greatest interest can be simulated with micro- simulation and other portions can be simulated with less detailed methods.

Integrated Travel Demand and Traffic Modeling Used in combination with TransCAD, a Caliber product that fully integrates GIS with demand modeling and logistics functionality, TransModeler provides the capability for integrated demand and traffic modeling. Demand forecasts can be subjected to more detailed operational analysis in TransModeler. Traffic assignment results can be modeled dynamically in the time domain to identify bottlenecks, queues, and the actual capacity of the road network. Used together, the user can more fully understand the trip distribution, mode choice, and route choice impacts of major construction projects.

TransModeler is designed to dovetail with TransCAD and includes additional features that streamline the use of simulation for travel demand forecasting. This makes it straightforward to:

• Use O/D trip matrices to model vehicle demand with time-variant departure rates and multiple vehicle classes. • Simulate vehicles from multiple matrices for different times of day and/or different vehicle characteristics. • Control the vehicle inter-departure profile with a constant rate, a time-based curve, or a series of matrices with varying start times. • Match observed traffic conditions with a variety of parameters that control the randomness and scale of each matrix. • Load trips in a matrix from node to node, link to link, centroid to centroid or between any combination of nodes, links and centroids. • Specify the properties of each matrix, such as vehicle class, HOV eligibility, and driver groups representing route choice characteristics.

43 The user can generate simulation inputs directly from TransCAD or other planning models to:

• Convert the geographic line layer to a traffic network database format ready for additional editing for simulation • Use trip matrices generated by the trip distribution model as input demand for the network • Use the powerful trip table estimator in TransCAD to generate trip tables that are consistent with traffic counts • Run a stochastic-user equilibrium or a dynamic-user equilibrium traffic assignment to generate congested link travel times, flows, and turning movements as input to the TransModeler route choice models. • Create and manage alternative paths available to drivers in large and complex networks. • Use sophisticated route choice and pathfinding methods in TransModeler to automatically generate feasible paths for all vehicles. • Modify the path table created by TransModeler or use map-based graphical tools to draw paths and create your own path table. • Map a vehicle’s current path or map the probability that a vehicle will traverse any given link when traveling between a given O/D pair.

CUBE Solution Overview CUBE Base is the user interface for the entire CUBE system and provides interactive data input and analysis, GIS functionality via ArcGIS, model building and documentation, and scenario development and comparison. Links between the model, the data, and GIS are integrated.

Freight Passenger

Cube Cargo Cube Voyager product

ArcGIS

targetCube placeArcGIS ArcGISprice marketBase Cube Dynasim and Cube Land Micro- & Meso- Cube DTA ArcGIS Land Use Scopic Simulation promotion

Cube Polar

Air Quality

Figure 23: CUBE

44 CUBE Base allows a user to run models developed with CUBE Voyager, CUBE Cargo, CUBE Analyst, CUBE Dynasim, CUBE Polar, TP+, TRIPS and TRANPLAN.

• CUBE Voyager - The CUBE extension for personal travel forecasting. It uses a modular and script-based system flexible enough to incorporate methods ranging from four-step to discrete choice to activity-based models. Advanced methodologies provide junction-based capacity restraint for highway analysis and multipath transit path building and assignment. Other features include flexible network and matrix calculators with unrestricted data sizes.

• CUBE Cargo - The CUBE extension for freight forecasting. CUBE Cargo offers specific methodologies for studying freight demand using a commodity-based approach. A variety of policies and infrastructure improvements can be tested, from pricing strategies to freight-specific facilities. Freight forecasting using CUBE Cargo can leverage existing passenger data and models.

• CUBE Analyst - The CUBE extension developed specifically for estimating and updating base year automobile, truck and public transit trip tables. CUBE Analyst enables the user to exploit a variety of data that contributes to matrix updating and matrix development.

• CUBE Dynasim - The CUBE extension for conducting detailed multimodal micro simulations. CUBE Dynasim is linked directly to the other CUBE extensions, allowing data and results to be shared, and provides methodologies for the simulation of automobiles, pedestrians, trucks, buses and rail vehicles with 3D graphical displays.

• CUBE Polar - The CUBE extension for calculating air quality emissions and energy consumption. CUBE Polar takes highway network assignments from CUBE Voyager, TRIPS and TP+ and produces estimates dependent on vehicle classifications, fuel characteristics, and speed profiles.

CUBE functional libraries can be utilized to perform analysis creating input data for the simulation as well as processing simulation output to be used for mapping or input into another process.

Of primary interest in this report are the capabilities and integration between Voyager and Dynasim.

CUBE Voyager CUBE Voyager uses a modular and script-based structure allowing the incorporation of any model methodology ranging from standard four-step models, to discrete choice to activity-based approaches. Methodologies provide junction-based capacity restraint for highway analysis and discrete choice multi- path transit path-building and assignment. CUBE Voyager includes network and matrix calculators for the calculation of travel demand and for the detailed comparison of scenarios.

CUBE Voyager was designed to provide an open and user-friendly framework for modeling a wide variety of planning policies and improvements at the urban, regional and long-distance level. CUBE Voyager brings together these criteria with a library of planning functions applied under the general CUBE framework. This eases the process of data management and coding complex methodologies.

Models built with CUBE Voyager can take multiple forms:

• Four-step models commonly used in urban areas: includes templates for developing generation, distribution, mode choice and assignment structures.

45 • Modified four-step with feedback: hybrids of four-step models designed to improve on the weaknesses of pure four-step models. Such modifications include car ownership models, combined mode and destination choice, and iterative feedback for model equilibrium. • Activity-based demand: provides the flexibility to incorporate most of these techniques. It is simple to incorporate specifically designed modules for the analysis and estimation of activity patterns. • Combined equilibrium models: provides a complete scripting and equilibrium feedback language allowing models of this form to be implemented.

CUBE Voyager includes a library of functions for the modeling and analysis of passenger transport systems: roadways, public transit, pedestrians and bicycles, to include:

• Networks: create detailed representations of roadway segments, intersections, and ramps. This module creates a comprehensive roadway database for use in estimating point-to-point paths and associated travel times, costs, and distances. A key element in CUBE Voyager is the ability to represent signalized and non-signalized controlled intersections, circles, and ramps as part of the pathfinding and assignment process. o This module serves as a general calculator providing the ability to compare and contrast highway and public transit networks and their variables. Highways: used to estimate zone to zone paths and matrices of impedances for use in analysis and in demand models. Paths can be built using a variety of methodologies: all-or-nothing, all-shortest paths, Dial, Burrell. Capacity restraint: intersection, link, or either using standard processes or user- supplied curves or equations. Assignment: iterative and incremental using equilibrium adjustment. Junction-based assignment: CUBE Voyager includes methods for performing intersection-constrained assignments. This process provides the best estimate of travel flows, delays and queues in urban locations.

• Public Transit: provides functionality for the study of public transit systems. Public transit services are coded as running in mixed traffic or on dedicated facilities. Automated processes for creating walk, automobile and transfer links between services. Ability to represent infrequent and time coordination. Point-to-point paths are found using a variety of techniques: all-or-nothing, stochastic multi-path, or discrete route multi-path. o Users may represent service levels using either headways or public transit timetables. CUBE Voyager provides methods to represent highly complex fare structures and for modeling public transit capacity restraint. Outputs user controlled matrices of times, costs, distances by mode and component. Large number of reports and tabulations of public transport data and results. o Voyager provides a major improvement to public transit assignment as compared with other packages. The discrete route multi-path process estimates, full, alternative paths between each origin and destination along with the individual elements of public transit costs (access times, wait times, transfer times, etc.). TRIPS are assigned across paths using a multinomial logit approach.

• Travel Demand: CUBE Voyager Demand processes zonal data and matrices according to user specified expressions. Zonal data and matrices are input, and matrices and reports are output. Various file formats for both input and output are supported. There are no default processes. The powerful scripting language combined with user-friendly wizards, allows for the application of all types of commonly used demand processes (multinomial and hierarchical choice models, cross classification

46 and regression models, gravity models, matrix frataring). New functionality is provided for applying activity-based processes using travel tours. If you have a complex demand process, we are almost certain that CUBE Voyager Demand can apply it.

CUBE Dynasim CUBE Dynasim is a package that allows a user to simulate the operation of any transportation system. It was developed and has been used in France and Italy since the early 1990’s, and has been marketed as a part of the CUBE System since 2003. The user can develop scenarios to compare alternative geometric designs, operational strategies, and travel demands. It provides data links to the other CUBE components, such as the demand forecasting system. These data links allow a user to reuse data.

CUBE Dynasim captures the full dynamics of time-dependent traffic phenomena by using a microscopic, stochastic, event-based, driver-behavior model. It performs detailed operational analysis of complex roadway systems while realistically emulating the flows of pedestrians, bikes, cars, trucks, buses, and railways. CUBE Dynasim has three primary components:

• Graphical network editor - The network editor allows a user to view and edit all simulation scenarios in a single file. It separates all pieces of the simulation into layers and scenarios, which may be imported. As a result, the user will never have to create or maintain the same portion of a network multiple times to facilitate multiple scenarios. After creating layers and scenarios, the user can mix and match them to create any number of different simulations to analyze.

• Simulation engine - The simulation engine provides offline simulations. The system will automatically compile the output data from multiple simulation runs using standard and user defined measures for use in validation and other activities. It can: o Simulate any geometric configuration o Provide detailed control over all vehicle behavior o Customize behavior at and within junctions o Customize behavior and implement restrictions by lane

• Output processor - The output processor presents animations and numerical data. The user can view animations in both 2D and 3D formats on background maps which may be further enhanced by landscapes. The user may examine numerical data in custom charts and graphs or export the final results to an executable file, which can be freely shared and distributed. The exported file has the same output processor capabilities as CUBE Dynasim, offering animations and numerical results. This allows anyone who does not own the software to view the animations and statistical reports.

Voyager – Dynasim Integration Dynasim is a fully functional, stand-alone simulation. However, it may also be integrated within CUBE, which provides a gateway that allows the user to take data from any source and link it to the micro- simulation. Data from other data sources, files, or traffic and planning programs can be accessed and used for simulation of a large area or a sub-area.

The defined methodology by CUBE for sub-area analysis is:

1. Identify sub-area and run analysis (flows and routing) in Voyager. 2. Correct the O/D matrix for projections, counts, or surveys. 3. Load background layers (images, shape, dxf) into Voyager.

47 4. Confirm geometric information (Junction Editor) in Voyager. 5. Confirm control information (Junction Editor, Import) in Voyager 6. Extract sub-area network to Dynasim. 7. Extract and append additional scenarios in Dynasim. 8. Clean-up the imported data as necessary. 9. Simulate and validate scenarios. 10. Extract output data back into CUBE for visualization.

AIMSUN NG

AIMSUN NG is a modular environment that incorporates different functionalities for planning, simulation, logistics and other. For the purposes of this report we will summarize the characteristics of two modules, the AIMSUN PLANNER and the AIMSUN simulator.

AIMSUN Planner The AIMSUN Planner has been designed and implemented to support the analyst in the application of main stages of the four-step transportation methodology.

In the current version, it has three main functions:

• Traffic Assignment - The equilibrium traffic assignment is based on Wardrop’s user-optimal principle: no user can improve his travel time by changing routes. Every section in the network must have an associated volume delay function (VDF). A default template offers a set of VDFs associated with every road type in it. VDFs can be set by road type or defined on a per section basis.

Following the assignment procedure, results may be presented in a graphical or non-graphical format. Output that may be reviewed includes:

o Flows and Travel Times o Turnings – the percentages of the volume on a section that take each of the possible turnings when arriving at a node, the volume of vehicles taking each turning, and the turning time. o Shortest Path – for each O/D pair the list of shortest paths, together with their path proportion and travel time obtained in the assignment is displayed. o Validation – the ability to compare results obtained during assignment with detection data. o Refinement – with this information, the user can decide whether to continue the assignment with more iterations or forcing the gap to be smaller.

• Multi-User Assignment - A Multi-User Assignment will give the simultaneous assignment of several demand O/D matrices, which correspond to different vehicle types using the network.

• Demand Analysis (including matrix import and export, matrix manipulation, matrix balancing and matrix adjustment) - Following user-required matrix manipulation, the user will have the opportunity to compare the results obtained in the assignment of the adjusted matrix with the set of detection data that was used for this adjustment.

• Traversal Generation - The objective is to extract an O/D matrix for a sub-area. Its traversal matrix will contain the gate-to-gate traversal trips calculated from the assignment of the trips of a global matrix in the global network.

The problem area may be selected using a polygon defined by the user. When the traversal matrix is calculated, a new centroid configuration corresponding to the problem area is automatically calculated.

Given a generic network with a defined centroid configuration and a sub-area of the network, a new centroid configuration for the sub-area is created adding a centroid at every in and out gate and for the centroids connected with sections inside the sub-area, a new centroid will be created for each of its connections.

Figure 24: AIMSUN NG

AIMSUN Simulator AIMSUN (Advanced Interactive Microscopic Simulator for Urban and Non-Urban Networks), is a microscopic traffic simulator that can deal with different traffic networks: urban networks, freeways, highways, ring roads, arterials and any combination thereof. It has been designed and implemented as a tool for traffic analysis to help traffic engineers in the design and assessment of traffic systems. It has proven to be very useful for testing new traffic control systems and management policies, either based on traditional technologies or as implementation of intelligent transport systems.

49 AIMSUN can simulate adaptive traffic control systems such as SCATS, VSPLUS and C-Regelaar; vehicle-actuated, control systems that give priority to public transport, advanced traffic management systems (using VMS, traffic calming strategies, ramp metering policies, etc), vehicle guidance systems, public transport vehicle scheduling and control systems, or applications aimed at estimating the environmental impact of pollutant emissions, and energy consumption.

AIMSUN currently follows a microscopic simulation approach, although the research team was able to evaluate a beta version of the upcoming hybrid meso-micro simulator. The reported functionality is similar to the one found on TransModedler. For the purposes of this report, we will only elaborate on the now available capabilities, hence only on the microscopic simulation part. In AIMSUN, the behavior of each vehicle in the network is continuously modeled throughout the simulation time period while it travels through the traffic network, according to several vehicle behavior models (e.g., car following, lane changing). AIMSUN is a combined discrete/continuous simulator. This means that there are some elements of the system (vehicles, detectors) whose states change continuously over simulated time, which is split into short fixed time intervals called simulation cycles. There are other elements (traffic signals, entrance points) whose states change discretely at specific points in simulation time. The system provides highly detailed modeling of the traffic network, it distinguishes between different types of vehicles and drivers, it enables a wide range of network geometries to be dealt with, and it can also model incidents, conflicting maneuvers, etc. Most traffic equipment present in a real traffic network is also modeled in AIMSUN: traffic lights, traffic detectors, variable message signs, ramp metering devices, etc.

The input data required by AIMSUN is a simulation scenario, and a set of simulation parameters that define the experiment. The scenario is composed of four types of data: network description, traffic control plans, traffic demand data and public transport plans. The simulation parameters are fixed values that describe the experiment (simulation time, warm-up period, statistics intervals, etc) and some variable parameters used to calibrate the models (reaction times, lane changing zones, etc). The outputs provided by AIMSUN are a continuous animated graphical representation of the traffic network performance, both in 2D and 3D, statistical output data (flow, speed, journey times, delays, stops), and data gathered by the simulated detectors (counts, occupancy, speed).

Simulation Process The logic of the simulation process in AIMSUN is illustrated in Figure 25. It can be considered as a hybrid simulation process, combining an event scheduling approach with activity scanning. At each time interval (simulation step), the simulation cycle updates the unconditional events scheduling list (i.e. events such as traffic light changes which do not depend on the termination of other activities). The “Update Control” box in the flow chart represents this step. After this updating process, a set of nested loops starts to update the states of the entities (road sections and junctions) and vehicles in the model. Once the last entity has been updated, the simulator performs the remaining operations such as inputting new vehicles, collecting new data, etc.

Figure 25: AIMSUN Simulation Process – Volume-Based

Depending on the type of simulation, new vehicles are input into the network according to flow generation procedures (headway distributions for example) at input sections, or using time sliced O/D matrices and explicit route selection. In this case, the simulation process includes an initial computation of routes going from every section to every destination according to link cost criteria specified by the user. Figure 26 shows the simulation process for the Route-Based model. In this case, a shortest route component periodically calculates the new shortest routes according to the new travel times provided by the simulator, and a route selection model assigns the vehicles to these routes during the current time interval. Vehicles keep their assigned route from origin to destination unless they have been identified as “guided” at generation time. They can then dynamically change their trajectory en-route as required for simulating vehicle guidance and vehicle information systems.

Figure 26: AIMSUN Simulation Process – Route-Based

Network Layout An AIMSUN traffic network model is composed of a set of sections (one-way links) connected to each other through nodes (intersections), which may contain different traffic features. To build the network model, the following input data is required:

• Map of the area, preferably a digitized map in .DXF format. o GIS data from sources like ArcGIS, Mapinfo and NAVTEQ can be used to build a sub- area/corridor, or a metropolitan region. • Details of the number of lanes for every section, reserved lanes and side lanes (on and off ramps). • Possible turning movements for every junction, including details about the lanes from which each turning is allowed and solid lines marked on the road surface. • Speed limits for every section and turning speed for allowed turns at every intersection. • Detectors: position and measuring capabilities. • Variable message signs: position and (optionally) the possible messages.

Traffic Demand Data Traffic demand data can de defined in two different ways: • by the traffic flows at the sections • by an O/D matrix

Depending on the type of model selected, the following input data must be provided: 1. Traffic Flows • Vehicle types and their attributes • Vehicle classes (for reserved lanes) • Flows at the input sections (entrances to the network) for each vehicle type

52 • Turning proportions at all sections for each vehicle type 2. O/D Matrix • Centroid definitions: traffic sources and sinks • Vehicle types and attributes • Vehicle classes (for reserved lanes) • Number of trips going from every origin centroid to any destination one

Traffic Control AIMSUN takes into account different types of traffic control: traffic signals, give-way signs and ramp metering. The first and second types are used for junction nodes, while the third type is for sections that end at join nodes. The input data required to define the traffic control is as follows:

• Signalized junctions: location of signals, the signal groups into which turning movements are grouped, the sequence of phases and, for each one, the signal groups that have right of way, the offset for the junction, and duration of each phase. • Unsignalized junctions: definition of priority rules and location of yield and/or stop signs. • Ramp metering: location, type of metering, control parameters (green time, flow or delay time).

Public Transport The user may opt to have AIMSUN take public transport into account. The input data required to define public transport is as follows:

• Public transport lines: a set of consecutive sections composing the route of a particular bus • Reserved lanes • Bus stops: location, length and type of bus stops in the network • Allocation of bus stops to public transport lines • Timetable: departures schedule (fixed times or frequency), type of vehicle, and stop times (specifying mean and deviation) for each bus stop

Integration AIMSUN NG is a working environment that integrates modules purposely designed and developed to support traffic and transportation analysis tools and algorithms to address the different types of traffic and transportation problems of interest. The conceptual architecture of AIMSUN NG is depicted below.

AIMSUN has demonstrated an integration of macro and micro level tools in Spain as described in Combining Macroscopic and Microscopic Approaches for Transportation Planning and Design of Road Networks by L. Montero, E. Codina, J. Barceló, P. Barceló.

The main components for transportation analysis tools currently integrated in AIMSUN NG are:

• Kernel: a common, extensible, object environment that can be used by multiple transport applications • Filters: access to and from most data sources and formats • Traffic Tools: access to the necessary software tools to carry out a project from start to finish, or to set up the working environment for an application • Graphical User Interface (GUI) to set up a user-friendly environment for all the required tasks

53 GUI Edition 2D and 3D Animation

DATA IMPORTERS TRANSPORT - Traffic Data PLANNING - Digital Maps GIS/CAD/Ortophotos ALMO AIMSUN Simu lator EXTENSIBLE MESOSCOPIC OBJECT Simulato r MODEL IMPORTERS MODEL - GIS TRAFFIC CONTROL - CONTRAM Actuated, Adaptive - PARAMICS - CUBE SCENARIO ANALYSIS

VALIDATION TOOL INTERFACES - EMME/2 AIMSUN - SATURN LOGISTICS

IMPORTERS & MODEL INTERFACES DATABASE TRAFFIC TOOLS

Figure 27: AIMSUN NG Modules

AIMSUN NG can be integrated through this framework with a number of other systems. It has graphical user interfaces for integration with:

• EMME/2 Traffic Assignment Tool o Translation of an AIMSUN NG network model into an EMME/2 model o Generation of input files to AIMSUN NG from an EMME/2 assignment o Generation of an AIMSUN NG network model mock-up from an EMME/2 model o Matrix import and export o Matrix adjustment automatic execution o Traversal generation • CUBE o CUBE to AIMSUN NG – AIMSUN can import from CUBE: Geometric Data of the Network O/D Matrices • Paramics o Paramics to AIMSUN NG – AIMSUN can import from Paramics: Geometric Data of the Network O/D Matrices • Saturn 10.5 Planning Software o Exportation from AIMSUN NG to Saturn Gemotric Data of the Network O/D Matrices o Import from Saturn to AIMSUN NG

54 Geometric Data of the Network O/D Matrices • Contram (CONtinuous TRaffic Assignment Model): o Import from Contram to AIMSUN NG Geometric Data of the Network Traffic States • TRANSYT Network Study Tool: o Convert an AIMSUN NG network (or part of it) into a TRANSYT one. o Import an optimized TRANSYT control plan back into the AIMSUN NG environment o Compare TRANSYT units and measures of performance with the ones produced by AIMSUN • UTOPIA Adaptive Signal Control System: o Import from UTOPIA into AIMSUN NG Controllers Intersections Detectors Signal Groups Control Plans

The AIMSUN NG approach is based on the concept of a scenario. A scenario is a model of a traffic network, or a sub-network of a large network, in which a traffic problem has been identified: the problem network. The model represents the network at the level of detail required by the suite of programs implementing the appropriate algorithms for the type of analysis to be conducted on the defined scenario, i.e. the link-node representation proper of the traffic assignment algorithms in the case of the transport planning or demand analysis studies, or the detailed geometry representation in the case of the microscopic traffic simulation study. The scenario input includes the traffic demand in the problem network for the time period for which the problem is to be studied, as well as the current operational conditions in the road network represented at the level required by the model, i.e. volume delay functions and turning penalties in the case of traffic assignment models, or current traffic control at signalized intersections for the microscopic simulation models.

PARAMICS

Paramics is a suite of microscopic simulation modules providing an integrated platform for modeling a range of real-world traffic and transportation problems. Paramics is fully scaleable and designed to handle scenarios as wide-ranging as a single intersection, to a congested freeway, or the modeling of an entire city’s traffic system.

Quadstone's Paramics system is being used in over 40 countries worldwide and has in excess of 500 users including commercial consultants, transportation researchers, and government agencies. Paramics has been deployed successfully in hundreds of networks worldwide and has been particularly useful in modeling large-scale networks in California, New York City and Sydney, among others. Additionally, Paramics has been utilized on numerous ITS projects in Europe and Australia.

Paramics can be applied to any aspect of a modern transportation network with equal ease and clarity. Some of the most common application areas include:

• Priority intersections, signalized intersections and roundabouts

55 • Urban cities, corridor studies and congested freeways • Public transport and light rail • Actuated signal control • Special user groups e.g. HOV, emergency vehicles, transit priority • ITS elements e.g. ramp metering, VMS, route control, lane usage, freeway speed control • Work zones, event management and pollution modeling • Public presentation

Project Suite The Project Suite consists of the following modules and provides the user with the required tools to undertake a wide variety of different projects for the full duration of the project—from initial model development, simulation, and analysis through to final reporting of statistics and presentation.

• Converter – a tool to take existing network data from a range of sources and "convert" it into a basic Quadstone Paramics network. o Converter reads network data and allows the user to "teach" the application how that data should be interpreted and transformed into a basic Quadstone Paramics network. The user can then edit the basic network data through an interactive GUI and graphical display. Multiple views of the same data can be generated allowing the user to make edits to the data and preview how they will look when exported to the standard Quadstone Paramics format. o Converter can work with data from various sources including, EMME/2, MapInfo, ESRI, Synchro, Corsim, CUBE/TP+/Viper, flat ascii, and CSV. Because you can teach Converter how to read your data, you can actually provide that data in any format you like, as long as some basic attributes are present, i.e. node coordinates and a/b nodes per link.

• Modeller – a commercial transportation modeling tool. Modeller provides the three fundamental operations: model building, traffic simulation (with 3-D visualization), and statistical output accessible through a graphical user interface. Every aspect of the transportation network can be investigated in Modeller including: o Mixed urban and freeway networks o Right-hand and left-hand drive capabilities o Advanced signal control o Roundabouts o Public transportation o Car parking o Incidents o Truck-lanes, high occupancy

• Estimator - an O/D matrix estimation tool designed to integrate with the core Paramics modules. Estimator utilizes all aspects of the core Paramics simulation, ensuring maximum compatibility between the O/D matrices, model structure, and underlying assignment techniques. Estimator will compute O/D matrices at the same level the simulation will be conducted. Users can interact directly with the O/D estimation process as it runs.

• Processor - a batch simulation productivity tool used for sensitivity and option testing. Processor can be used to automate simulation and analysis processes, reducing user down time, and speeding up the model development lifecycle. Processor utilizes the core Paramics simulation and works in harmony with Analyzer.

56 • Analyzer - a post-data analysis tool used for custom analysis and reporting of model statistics. Analyzer can be used to interrogate a single set of data or it can be used to compare multiple datasets from multiple sources e.g. base layout, alternatives, and observed field data helping to speed up the model calibration and validation process. Analyzer provides statistics including user definable HCM- style level-of-service and other measures of effectiveness. Analyzer provides a set of automation tools such as report templates and project workspaces to help users manage their data and minimize the time required to obtain project-critical statistics.

• Programmer - a development API for the Paramics suite. Programmer allows users to augment the core Paramics simulation with new functions, driver behaviors and practical features. Also, researchers can override or replace sections of the core Paramics simulation with their own behavioral models. Programmer can be used for research, all aspects of ITS, real-time connectivity and control, connectivity to real world hardware and software systems, and advanced or customized model behaviors.

Key Functionality Paramics provides the following functionality elements: • Comprehensive modeling support for all network elements • Simultaneous network editing, simulation, and visualization • Fully scaleable platform, optimized to model single junctions or entire cities • Integrated calibration and validation support tools • Integrated network auditing tools • Comprehensive reporting and analysis tools including user defined statistics • Seamless 2D/3D visualization, life like quality with real time video capture for presentations • Fully customizable core simulation engine that can be altered or added to by the user • Full capability to model simple or complex ITS network elements • A comprehensive set of core modules designed to improve usability, integration, and productivity

Connectivity Paramics uses an open flat-file format that allows connectivity to other applications. The core network structure of a Paramics model follows the industry standard of ‘node and link’ which allows import and export of data to other simulation and traffic planning tools, GIS tools, and signal control systems such as: Corsim; EMME/2; TranPlan/TP+/CUBE etc.; ArcView; Transyt; Synchro; Sidra; SCATS; and VS- PLUS.

DYNASMART-P

DYNASMART-P is one of the two dynamic network traffic operational planning tools developed under the FHWA Dynamic Traffic Assignment (DTA) research project. DYNASMART-P, developed by researchers at the University of Maryland, supports transportation network planning and traffic operations decisions, including evaluation of ITS deployment options, through the use of simulation-based dynamic traffic assignment. This tool combines (1) dynamic network assignment models, used primarily in conjunction with demand forecasting procedures for planning applications, and (2) traffic simulation models, used primarily for traffic operational studies.

DYNASMART-P allows for consideration of an expanded set of measures compared to both conventional static assignment models and traffic simulation tools. This is primarily due to: richer representation of traveler behavior decisions than static assignment models; explicit description of traffic

57 processes and their time-varying properties; and complete representation of the network elements, including signalization and other operational controls.

DYNASMART-P defines a new generation of transportation planning methodologies, which can interface readily with existing four-step procedures, yet provides a meaningful jump in the range and type of measures that can be evaluated. Because it considers the time-varying nature of traffic flows, it is expected to produce more useful estimates of state variables such as speeds, queue lengths, delays, and congestion effects to better assess the functional and environmental impacts of a variety of traditional and emerging transportation planning measures, including the deployment of ITS and non-ITS technologies.

Features The principal function of DYNASMART-P is to describe the evolution of traffic flows in a traffic network that result from the travel decisions of individual trip-makers seeking to fulfill a chain of activities. It serves to support strategic and operational planning decisions by helping to identify deficiencies, design, and evaluate the impact of alternative courses of actions, in the context of the broader set of policy objectives for the study area. It overcomes many of the known limitations of static tools used in current planning practice. These limitations pertain to the types of alternative measures that may be represented and evaluated, and the policy questions that planning agencies are increasingly asked to address.

The functionality of DYNASMART-P is achieved through a selection of modeling features that achieve a balance between representational detail, computational efficiency and input data requirements. These features include:

• Micro-simulation of individual trip-maker decisions, particularly route, departure time and mode, including user responses to varying types of information, as well as higher order activity participation and sequencing decisions • Efficient hybrid traffic simulation approach, which moves individual particles according to macroscopic traffic flow relations • Ability to load trip chains, with several intervening stops with associated durations, in addition to the conventional approach of loading individual trips • Representation of multiple user classes in terms of (1) operational performance (e.g. trucks, buses, passenger cars), (2) information availability and type, and (3) user behavior rules and response to information • Representation of traffic processes at signalized junctions, under a variety of operational controls (critical for urban congestion and ITS) • Iterative algorithms for computation of mutually consistent flow patterns and user decisions, e.g. time-varying user equilibria where applicable

A partial list of the strategic and operational network planning decisions that can be evaluated with the aid of DYNASMART-P includes:

• Congestion build-up/dissipation in response to various network improvements and demand management schemes • High-occupancy facilities and special-use lanes and/or facilities, in conjunction with variable pricing schemes, e.g., HOV/HOT lanes • Evaluation and design of operational strategies, including network structure, signal control strategies, signal coordination schemes along arterials as well as path-based coordination schemes (possible in conjunction with Dynamic Traffic Assignment tools)

58 • Advanced Traffic Management System (ATMS) Strategies, including variable message signs (VMS) location and information supply strategy, adaptive coordinated ramp metering, and incident management schemes. These are particularly useful to support operational planning decisions in conjunction with planned reconstruction activities. • Congestion pricing schemes that vary with location and time, and prevailing network state. It also models high occupancy vehicle (HOV) facilities and special-use lanes and/or facilities in conjunction with variable pricing schemes, e.g. high occupancy vehicle lanes and high occupancy toll lanes. • DYNASMART-P can also be used in air quality impact evaluations as it produces detailed time- varying network flow characteristics that could provide the required input to most empirical air quality assessment models • In addition to the general applications, DYNASMART-P is also ideally suited as the assignment capability in activity-based micro-simulation approaches to travel demand forecasting

DYNASMART-P produces a wide array of output information to assist users in performing detailed traffic analysis. The output report contains measures of effectiveness (MoEs) commonly used by traffic engineers, such as volumes, speeds, travel times, delays, etc. DYNASMART-P also produces an individual vehicle trajectory file, which is very useful for research purposes. In addition, through its intuitive graphical user interface (GUI), DYNASMART-P provides the user with the means to view simulation results and other characteristics through various graphical formats, both static and animated.

Network Size and Structure: DYNASMART-P is not limited by the size of the network, except for hardware-related constraints (e.g. memory). It is designed for use in urban areas of various sizes and is scalable, in terms of the geometric size of the network, with minimal degradation in performance. The arrays and data structures are of a variable size and limited only by the hardware. The computational and memory-taxing features of DYNASMART-P, such as shortest path calculations and simulation intervals, can be edited prior to running the program to facilitate analyzing larger networks.

DYNASMART-P can also model the fine details of transportation networks such as zones (any number of zones), intersections, links, origins and destinations. The user can specify any zonal configuration for the network, as long as it is consistent with the origin-destination demand matrix. Links may be modeled as freeways, highways, ramps, arterials, and high occupancy toll lanes, etc. Each link is represented by its length, number of lanes, existence of left-turn bays, maximum traffic speeds, etc. Two-way lane roads are modeled as two links, i.e. no overtaking is allowed by taking space in the opposing lane. Link junctions with different signalized and non-signalized control options are also modeled in DYNASMART-P. Finally, DYNASMART-P can represent trip origins, destinations and even intermediate destinations for trip chaining.

General Overview of DYNASMART-P Input Files DYNASMART-P requires two classes of input files: traffic simulation and graphical representation input files. There are four ways to create DYNASMART-P input files:

1. Using a text editor (both externally or within the GUI environment); and/or 2. Through GUI input dialog boxes; and/or 3. Through DYNABUILDER; and/or 4. Through DSPEd, a DYNASMART-P editor

DYNABUILDER is well suited to converting networks from GIS format into DYNASMART-P format. DYNABUILDER is not designed to create all of the input files, just the necessary and complicated ones.

59 DSPEd, on the other hand, provides a data entry environment for creating DYNASMART-P input files, but may be time consuming for certain input files. Therefore, each of these methods has their own advantages and disadvantages. The recommended method to create the input files would be to integrate all of these techniques.

Demand Representation (O/D Matrix and Trip Chaining) DYNASMART-P is flexible in the way it accepts loading information (time-varying rates prevailing over specified intervals, numbers of vehicles in discretized time slices, individual vehicle schedules). It can also be interfaced with demand data inputs developed from either conventional aggregate models or disaggregate micro-simulation based procedures.

There are two methods for preparing vehicle generation in DYNASMART-P. The first method is to specify O/D matrices among origin-destination zones at different time intervals. A flexible dynamic demand input format is supported by DYNASMART-P. The user needs to define the number of loading intervals, a multiplication factor for demand generation (to facilitate experimentation at different demand loading levels), the starting time of each period, and the end of vehicle generation time (loading period). For each time period, an O/D zone matrix needs to be prepared in order to generate and load vehicles onto the network. This gives the user flexibility to specify demand level and demand distribution between different zones, for any loading period.

The second vehicle loading method is to specify the itineraries (origin and destination) of all vehicles with or without their corresponding travel plans. In this format, users can specify a trip plan (chain) for each traveler. The data required are the intermediate stops considered by each traveler, and the corresponding activity durations. This approach provides maximum flexibility to interface with micro-simulation activity-based travel demand forecasting models.

Traffic Control DYNASMART-P can model common control strategies at link junctions such as no control, yield signs, stop signs, pre-timed signals, and actuated signals. Coordinated actuated control is not explicitly modeled, but can be approximated. At signalized intersections, users can specify any phasing pattern, the movements, and the other signal settings to represent any real network. DYNASMART-P can also model ramp metering on freeways. Users can specify any number of ramp meters, their location, and their operational period in the network.

Traffic Flow Model DYNASMART-P uses a modified Greenshields model for traffic propagation. In the current version, two types of the modified Greenshields family of models are available. Type one is a dual-regime model in which constant free-flow speed is specified for the free-flow conditions (1st regime) and a modified Greenshields model is specified for congested-flow conditions (2nd regime).

Dual-regime models are generally applicable to freeways, whereas single-regime models apply to arterials. The reason why a two-regime model is applicable for freeways in particular is that freeways have typically more capacity than arterials, and can accommodate dense traffic (up to 2300 pc/hr/ln) at near free-flow speeds. On the other hand, arterials have signalized intersections, meaning that such a phenomenon may be short-lived, if present at all. Hence, a slight increase in traffic would elicit more deterioration in prevailing speeds than in the case of freeways. Therefore, arterial traffic relations are better explained using a single-regime model.

Parameters for the dual-regime Greenshields model (in DYNASMART-P) were calibrated for the San Antonio, TX, freeway system, whereas the single-regime parameters were calibrated for the Irvine, CA, surface street network. No calibration studies have been performed on other areas due to the general lack

60 of time-dependent traffic data.

Conclusions

In this section we compiled all the available information regarding the most relevant, currently available simulation applications. Since the majority of the available applications have integrated travel demand modeling with finer resolutions of traffic simulation (mesoscopic and microscopic), it is fair to say that we presented the available information for the most relevant transportation planning packages. The research team is intimately familiar with several of the presented packages, but since it was not possible to reach the same level of familiarity for all of them, we restricted our reporting to the information available from the developers or documented by users (published papers and project reports). In several cases we communicated directly with the developers in order to drill down on details not sufficiently explained in the documentation.

The originally planned next step was to select one or two of the available simulation applications and proceed to a deeper investigation between the Twin Cities reality and the simulators’ features. Following consultation with the project Technical Liaisons, it was agreed that such a selection is not desired for the following reasons:

• From the evaluation presented in this report, it was concluded that for the majority of the available applications, at least in theory, the development of a metro-wide simulation model is technically feasible. • The Twin Cities reality regarding the type, format, and completeness of the available information is the biggest, if not the only, deciding factor for the development of a metro-wide simulation model. • The selection of a transportation planning package is, in part, a political decision encompassing needs and views of a wide variety of departments and local government organizations.

In view of the above issues, it is not the simulation application that needs to be evaluated further, but the modeling methodology bridging the gap between the available data and the software implementation.

61 Chapter 5 Functionality and Data Requirements for a Metro-wide Simulation Model

The common factor connecting all large urban area traffic simulation efforts presented in this report is a close relationship with the regional travel demand model. Specifically, in all cases the foundational data set (apart from the geometry of transportation networks) was the daily or peak-period O/D matrices produced by the planning model. Indeed, this connection was so important that in several cases it determined the success or failure of the project. As the research team examined the various projects an evolution became evident: although the planning models and the microscopic simulation models began as two completely separate applications, the latter’s dependence on O/D information prompted an integration of the two applications into one larger framework. The results of this evolution are clearly seen in the analysis of current commercial applications: the largest commercial developers offer simulation packages containing modules that cover two or more levels of modeling resolution.

Needs vs. Data Availability

Following the aforementioned categorization of the currently available models, our discussion will not seek to define whether one approach is better than the other, or if there is a unique approach that can satisfactory replace all the others. Our objective is to define a feasible approach that works best for Twin Cities stakeholder needs. The Task 2 deliverable described the process that helped us uncover these needs. An outline of these results follows. • Metropolitan Council needs. Metropolitan Council staff primarily have long-term planning needs that are best addressed by the macroscopic models they already employ. Regardless, as mentioned earlier, these models have several deficiencies that can be overcome if a microscopic or hybrid model is available. The first of these deficiencies is in the estimation of travel time. Although most integrations of macro with micro are one-way it is possible to have a two-way flow of information. In this case the macro model produces the O/D matrices fueling the micro one based on its rough application of traffic assignment. The micro model can do a better job on the assignment and produce better relationships between link volume and travel time. These relationships can improve the four-step process of the macro model and iteratively produce better results. The second deficiency comes in the poor representation of the road geometry in the macro model. It is possible that the geometry developed for the micro model (being a product of GIS translations or merging of smaller project results) can be used to improve the quality of the macro model. • RTMC needs. At the other end of the spectrum, the Mn/DOT traffic operations staff have different needs for a metro-wide simulation model. Issues they have include: o Global optimization of the ramp control strategy o Investigation of impact of special events o Real-time analysis of special events o Post-incident management analysis and training o Investigation of short and long-term construction projects

Although the outlined needs are, at least at first glance, related only to the freeway system, it would be a mistake to assume so. The common factor in all of these needs is the impact operational decisions have on drivers, and specifically on traffic diversion and route choice. A freeway-wide simulation model, albeit useful, would be incomplete without at least a rudimentary representation of the arterial system that feeds it. In the aftermath of the I-35W bridge incident, traffic operations staff admitted that they have no clue where one third of the 140,000 vehicles that used the bridge daily went after its collapse. This large number of trips did not disappear but

62 simply fanned out in the arterial network to such an extent that individual link volume increases are indistinguishable from normal fluctuations. The need for a freeway and arterial metro-wide model is clear.

• Mn/DOT planning group. During a separate interview with Mn/DOT planners, a new set of needs emerged. Issues they have include: o Evaluation of traffic operations alternatives specifically in the case of planned construction. o Greater network impacts of geometric improvements in key network links. o Transit interaction with freeway demand and traffic. o Emergency evacuation planning and scenario evaluations. o Need for accurate demand patterns in small area project. A greater network modeling can provide more accurate estimates. o Need to consolidate the data of the Twin Cities transportation network. The development of a metro-wide simulation model can be the catalyst that will help accomplish this.

• Metro Transit needs. Metro Transit staff had needs that matched and surpassed a lot of the previously outlined needs. They are interested in both off-line and real-time simulation—the first for planning purposes and the second for operations. Currently Metro Transit does not depend on modeling in the planning or operations of its transit lines. They are reacting to customer- generated service demands instead of looking to optimize transit operations as a system. The need for the selected model to adequately emulate transit operations is clear. The discussion extended further to include the integration of a metro-wide simulation model with a transit ridership model. • Cities and counties. The interviews included several metropolitan area cities and counties. Although their needs are similar to the ones already described, they do not see the benefit from a metro-wide model as long as the macro model can provide reasonable estimates of the demand entering and exiting their borders.

It is important to repeat here that the model’s feasibility was always a prevalent issue. Although during the interviews, the research team tried to separate the feasibility and cost from the hypothetical needs of the stakeholders, a number of potential uses were not voiced simply because the cost of building a metro- wide model seemingly outweighed the benefit. This was an unfortunate side effect but very understandable since the task of building a metro-wide model seems huge even without the extreme data needs required for calibration. It is these data requirements that will finally form the feasibility of a metro- wide simulation model. In the following paragraphs the data requirements are outlined in terms of the three major input requirements (Geometry, Demand, and Control) as well as the requirements of calibration.

• Geometry. The Twin Cities network is large in comparison to the current large urban simulation examples found in Europe and Asia, although the density and number of vehicles is generally a lot smaller. Regardless, in terms of entering road geometry, the length is the deciding factor followed by the number of intersections. Smaller simulation projects depended on manual entry of the roadway geometry based on aerial photos to guide the modelers. At the moment, this approach is not favored therefore a requirement would be to have an automated mechanism that can translate existing models of the roadway system, either from the planning model or from GIS records. Considering the peculiarities of different travel demand modeling software or GIS records, the selected simulation system has to be robust in its importing functionality. Additionally, so far there is no single source of all the information. To facilitate easy entry of the geometry information, the selected system must be able to either import different elements from different sources, or the team that develops it has to go through a preliminary integration of geometry information sources prior to the importing to the simulation application.

63 Following some investigation, we believe we now know the different GIS models available for the Twin Cities network. Two different efforts have resulted in the geo-coding of the regional roadway network. All models located stem from two separate efforts of roadway geo-coding. The first and oldest is the geo-coding performed by the Metropolitan Council in their development of the regional planning model. The second is the geo-coding performed by the Lawrence Group. In May 1997, an agreement for the use of The Lawrence Group (TLG) Geospatial Landmark data and the TLG street centerline data was completed by the Metropolitan Council, Mn/DOT, and TLG. The agreement makes these data sets available to all state and local government agencies and colleges and universities in the state of Minnesota. Both efforts have severe limitations regarding their use as geometry-input to traffic simulators. The Metropolitan Council regional planning model GIS export has only approximate geo-located information. Specifically, since the original design was not intended to be used as a GIS resource, only the intersections (nodes) are geo-located in a reasonably accurate manner. Links on the other hand are simple straight lines connecting the nodes and do not represent the actual geometry of the roadways. The attributes though provided in this model include useful information like the directionality, number of lanes, road type, speed limit, and capacity. The GIS export of the regional model does not include all roadways in the metro area. Unfortunately, in addition to the fact that only major roads are included, in many cases the developers have grouped many minor streets into a bigger imaginary link. Anyone using this GIS model as a base for a metro wide simulation model will have to either manually enter the geometry in locations where geometry is essential, i.e. freeways, or use another GIS source. In discussions with Metropolitan Council staff, we have been informed of plans to improve the regional model to include accurate roadway geometries. It is not clear yet what the timeframe is for this improvement but if it happens in collaboration with traffic simulation engineers, it could greatly simplify the geometry translation and decrease the effort for a metro-wide model considerably. The TLG GIS model, on the other hand, has a near perfect geometric representation of all roadways in the metro area. Translating this GIS model into a simulation network will result in very high accuracy. Unfortunately, limitations also come with the TLG model. What is geo-coded is the roadway centerline only. Regardless if a link is one-way or two, it is represented as a single line with no directionality information. The attributes of the TLG elements include only number of lanes and speed limit relevant to traffic simulation. Differing from the regional planning model, the TLG model does not contain nodes, although it would be a simple GIS exercise to add them. The TLG GIS model has served as the basis for the creation of a number of derivative GIS models like the ‘Major Highways’, the ‘Functional Class Roads’, the ‘Bus Routes’ and others. Some of these models are more rich in terms of attributes but all share the primary limitation of the TLG which is centerline-only representation. In addition to the free, state-sponsored GIS models, there are others developed by the private sector for navigation and other purposes. For example, a very accurate roadways representation can be purchased from TeleAtlas. Considering the cost of even a small area of the Twin Cities metro area, we did not further investigate the merits of commercial maps.

• Demand. In all of the previous sections, the issue of demand was prevalent. Unless the correct amount and type of vehicles is generated in the simulated network, the produced results will be useless. As mentioned earlier, macroscopic travel demand models depend on ten-year survey information and other socio-economic information to produce the number of trips residents in the metro area would like to perform daily. Considering the stochastic nature of the system, it is impossible to expect that such information will produce the observed volumes on each link at every time in the day for all days. This is why the macro models do not produce anything more than peak period results on an imaginary average day. Still, this information is all that is available and has served our planning and operations purposes adequately until now.

64 To climb to the next level of functionality and resolution, mechanisms will need to be developed that will utilize additional information in order to improve the initial demand information. The selected simulation platform must either have such mechanisms or allow for their development. Specifically, most of the commercial simulation applications have been recently equipped with O/D matrix splitting and adjustment tools. Unfortunately, since this is a new development it is still unclear how accurate it is or what its requirements are for additional data. Nevertheless, brave pioneers have moved forward and have applied these mechanisms in real practice. Notable are the tools for matrix splitting and adjustment utilized in the Barcelona metro-wide model development and the Milwaukee project utilization of the Paramics Estimator to build hourly O/D matrices from detector information. The latter did not even use an original planning level O/D as a seed. It is clear to the research team that this is new ground and every step must be adequately evaluated and supported. As a final requirement, we believe that the flexibility of the simulation system to utilize different data sources for generating demand is essential. Following some investigation of the Twin Cities regional planning model, we believe that it can be a relatively straightforward task to translate the TAZ centroids into traffic simulation O/D centroids. The current capability of the regional model of extracting O/D matrices in text form greatly simplifies the demand information input.

• Control. The problem of control is similar to that of the geometry. The information is in different places and in formats that can be incompatible to any automated entry system. Regardless, as pointed out by Mn/DOT staff, this is the opportunity to consolidate all this information into one source. Naturally, the simulation platform selected must be flexible enough to accommodate this yet unknown source of intersection control information. In regards to freeway control, the research team believes that the currently available commercial products all have enough functionality to allow the integration of the current and future Mn/DOT ramp metering algorithms. Additionally, congestion pricing schemes must be easily accommodated by the simulation platform.

There are two issues involved with the traffic control information. First, there is no comprehensive list of intersection traffic control information. No GIS model has any such information available; in addition to the fact that for the models that do not contain all links and nodes, a lot of signalized intersections can be missing altogether. The only known GIS database of signalized intersections is the one belonging to the city of Minneapolis. Second, the record keeping in regards to signal timing is practically non-existent. Even the most organized authority (Mn/DOT) who controls most of the “important” roads, there is little effort spent in organizing and recording past and current intersection timings. This is a problem affecting transportation planning and operations on many levels, in addition to the feasibility of a metro-wide simulation model.

• Calibration. It is a little premature to discuss the data requirements, since the final form of a potential metro-wide simulation model has not been decided yet. Regardless, as mentioned earlier, it is the availability of data for calibration that will inform this decision. The calibration process has generally been a manual process with few attempts in developing automated calibration systems. Detector volume information has been the biggest source for calibration data, followed by travel time, and link speeds. Naturally, the more such data is available, the better the calibration can be.

In general, the Twin Cities roadway system can be divided into two categories, the well- instrumented and the practically non-instrumented. Metered freeways belong in the first category. Past experience has shown that the historical detector information provided by Mn/DOT, as well as the organized way of integrating this information with incident, weather, enforcement, and

65 maintenance information, allows for very high-quality calibration of micro-simulation models. Conversely, the practically non-existent information on arterials can be potentially a great hindrance. Even in the cases where a sophisticated traffic control system with advanced and stop- line detectors exist, this information is rarely routinely collected and saved. In most cases manual counts and estimations of ADT is the only available information. In the process of calibrating the regional planning model, travel time studies are conducted but the information is not widely available. Experimental methodologies are currently being investigated by University of Minnesota researchers in an attempt to mass produce travel times on arterials. It is yet unclear how this will develop.

In the process of developing the data requirements for the metro-wide simulation model, it is critical to consider the requirements of the currently used models. The macroscopic travel demand models are based on very vague and low-resolution information. Regardless, the need is such that they are currently indispensable tools for transportation planning and operations. If the original developers had stopped because more accurate information was impossible to collect, transportation engineering would be fundamentally different.

As outlined in the previous sections there is a variety of available information to guide the formulation of an appropriate metro-wide simulation application. Specifically the most useful information available is the following:

• The network geometry from the metro planning model • The network geometry from existing GIS records • Detailed aerial photos of the entire metro area – the latest from 2006 • Traffic control plans for all urban intersections, however these are not located in a single location or format • Well-documented ramp metering and congestion pricing strategies • Several sets of peak period O/D information for past, current, and future passenger vehicle trips as produced by the metro planning model • Heavy vehicle counts or adjustment factors in the majority of freeway and arterial links • A very dense detector infrastructure in the freeway system • A very loose detector infrastructure in the arterials or nonexistent in large areas of the network • Manual counts of volume in critical arterial links of the network. This is the information used to refine the planning model.

66 Chapter 6 Proposed Approach for a Metro-wide Simulation Model

Following the guidance of the Technical Advisory Panel and that of the project Technical Liaisons, the proposed steps and methodology for developing a Twin Cities metro-wide simulation model will be general and not refer to a specific simulation package. In fact, as it will be discussed in the following section, we do not believe a conventional approach will be successful, but rather propose one that capitalizes on the characteristics of different modeling approaches.

As mentioned in an earlier section, there is an emerging trend still in an embryonic stage toward hybrid simulation applications. Hybrid simulation employs models of two or more levels of resolution. We believe that the most appropriate combination for the Twin Cities would be a hybrid mesoscopic/microscopic simulation application featuring close integration with a macroscopic planning model. This modeling framework would provide users with an integrated set of modeling tools for complete corridor analysis, as depicted in Figure 26, Alexiadis 2007. In use, this application would start at a high level with regional travel demand (based on the established four-step process) to provide a primary set of O/D matrices. These matrices would be further refined and adjusted, using additional information to estimate peak spreading and adjusting for shorter time intervals from available link flow counts. The refined O/D matrices would be input into dynamic models at meso- and/or micro-scales, depending on the needs of the users, along with the specifications of management strategies to be evaluated according to selected performance measures.

Figure 28: Integrated Analysis Methodology Alexiadis, V. Role of Simulation in Corridor Management, TRB2007 Simulation Workshop, Washington, January 2007.

Setting aside the well defined role of macroscopic analysis, if the purpose of the transportation study is primarily more for planning than for operations, and the size of the modeled network is substantially large, then a mesoscopic approach would be recommended from a practical point of view. The data requirements for the mesoscopic approach are less intensive and the mesoscopic model is easier to

67 calibrate because it depends on a smaller set of behavioral parameters. The mesoscopic model provides user equilibrium results similar to those of the planning models with the advantage of insight into the time dependencies of traffic flows and travel times that explicitly take into account the queue spillbacks and the impacts of flow interdependencies at intersections. This is made possible by the heuristic solution provided by the simulation to the mathematical model formulated in terms of a system of variational inequalities. The microscopic simulation approach is recommended when the objectives of the simulation study explicitly ask for detailed analysis of queuing evolution, spillback and dissipation, explicit analysis of conflicts at intersections, flow breakdowns, impacts of actuated or adaptive control systems (namely with pre-emption for public transport systems), merging, diverging and weaving areas in freeways, and impacts of advanced traffic information systems—either based on on-board or road-side equipment, like VMS panels, which imply rerouting, dynamic speed control or other traffic management strategies or impacts of other ITS systems.

From a software point of view, most simulators do not put any constraint on the size of the models. However, the data intensiveness of the microscopic approach and the calibration resources usually required by a proper calibration of microscopic models, make the microscopic models more appropriate for full dynamic analysis of small to moderate large networks. Mesoscopic models are appropriate for large to very large networks when dynamics play a relevant role, but it is not required for a highly detailed analysis.

The use of a balanced meso/micro approach is believed to be the best course of action based on the availability of data for the Twin Cities region. Specifically, the availability of traffic measurements on freeways has been proven to produce high quality simulation models. The only questionable assumption in freeway simulation has been the definition of demand (ramp entrance and exit volumes). Even in the case of ramp metering, which is known to affect route choice, all modeling efforts have assumed no diversion both in strategy evaluation projects as well as regular freeway improvement projects. This flaw could be partially alleviated by the use of mesoscopic simulation for the arterial system. Enough information exists to construct an efficient and relatively accurate mesoscopic model for the Twin Cities’ arterial system. The research team is confident that such a model would equal or exceed the accuracy of the macroscopic regional planning model. The development of a mesoscopic model would entail an upgrade the macroscopic model, bringing higher levels of efficiency and utility to the modeling process.

The benefits from a hybrid meso/micro simulation can be clearly seen in the context of the following example. Consider the network presented in Figure 27 (Barcelo et al, 2006). The problem stems from the location of the congestion that could be due to geometric design or to traffic control reasons. In the traditional approach, there are three different ways of analysis: macro, meso, and micro. The macro approach cannot handle time-dependent events so if the reason of the congestion is not known beforehand, it will not be able to capture it. The meso approach can handle more cases than the macro but again, if the problem is something like a freeway bottleneck or an adaptive traffic control strategy like the Minnesota ramp metering algorithm, it is not possible to accurately capture the behavior of the system. The micro approach would have been able to handle the problem if sufficient data were available to simulate the entire area influenced by the problem in one link. None of the traditional, single approaches can efficiently handle such a problem.

Figure 29: Combining Meso and Micro approaches

A hybrid meso/micro simulation would have been able to harness the difficulties of the problem by simulating on the meso model the big network and only the area under consideration would need to be simulated at the microscopic level. Detailed data would only be required for the subarea. In terms of the example in Figure 27, a vehicle traveling from origin i to destination j is continuously being tracked by the simulation engine; it follows a route from the origin until the border of the subarea, according to the proposed mesoscopic simulation of traffic flows. After crossing the border, the simulation engine changes the simulation mode to the microscopic approach along the part of the path in the subarea. When the vehicle completes the trip across the subarea, arriving to the opposite border, the simulation mode changes back to mesoscopic until it reaches its destination. In the case of congestion arising in the area, alternative paths around the subarea can become more attractive as shown in Figure 27.

This combination of simulation approaches raises additional consistency problems when the mesoscopic simulator and the microscopic simulator are two independent pieces of software. The integration of meso and micro-simulators has been analyzed in detail by Burghout (2004), and Burghout et al. (2005), in the case of MIME and MITSIM. In particular, the integration has to solve the consistency problems in route choice and network representation, traffic dynamics at meso-micro boundaries, traffic performance for micro and meso models, and communication and data exchanges. The network representationof consistency problems has already been discussed before, but the other problems arise from the fact that vehicles in the meso model and vehicles in the micro model are not the same, and the path calculation is different. However, if the two models reside under the same software application, and by extension, share the same network representations, the same object model, and model database, vehicles can be unique and the same for meso and micro models, if the meso model is based on an approach of individualized vehicles. Furthermore, path calculation can be carried out by the common “shortest path server” and are the same at both levels.

69 Building a hybrid simulation model In previous sections, there was an extensive discussion of needs as well as the status of Twin Cities data as it relates to the three data requirements for developing a simulation model (geometry, demand, and control). In view of a hybrid simulation model, the following allowances can be made:

• Geometry: The regional planning model can be used initially to form the basis of the arterial part of the network. Methodologies and tools are needed in order to create an intersection with default traffic control plans. This approach has already been followed by the University of Arizona and the DynusT laboratory in their development of the Twin Cities metro model under DynusT (a customized version of Dynasmart-P still in beta version). The freeway network can be based on an enhanced version of the TLG GIS model and finished manually by hand. This approach achieves a fast start by leading quickly to a functional model and allows for later refinement as projects require attention in subareas of the network.

• Demand: The only source of reliable demand is from the regional planning model. Currently this model can produce hourly matrices that can be tuned to specific days and events based on detector information where available.

• Traffic control: As mentioned under the geometry section, signalized intersections will be initially generated following a default design. Later, as information becomes available and the model is used, more realistic control information can be implemented. Again, we would like to point out that the status of information regarding traffic control information for Twin Cities intersections is very bad. Unless institutional changes take place to improve the current practice, any attempt for improvement will be severely hampered. On freeways, the problem is much simpler since the Minnesota stratified ramp control algorithm has already been implemented successfully in more than one microscopic simulator.

The construction of the model can be accomplished separately for the micro and the meso models. This way the calibration of the micro model will be simpler and faster. The two models can be integrated at a later stage. As noted earlier, a lot of problems are solved simply by using the same software for both levels of the simulation. Such software is becoming available from several commercial companies investigated in this report. Further details regarding the development of a hybrid simulation model will have to be software specific and are beyond the scope of this report.

70 Conclusions

The research activities presented in this report covered a lot of ground: from a detailed examination of the state of the practice in large urban simulation projects around the world, to interviews with local stakeholders, and a thorough examination of the capabilities of currently available simulation packages. Although some non-commercial simulators were examined, the research team does not believe it prudent to make such an investment in simulation without professional support and model evolution.

Leaving aside considerations of data availability, a micro-simulation approach would have been the best possible solution. Current micro-simulation packages are fast, and can handle very large models without difficulty. Unfortunately, the lack of suitable data for the greater part of the road network precludes such an approach. Taking data availability into account, the hybrid mesoscopic/microscopic approach described in this report has been identified as optimal. This methodology, although relatively novel, has been thoroughly discussed in the relevant literature and rests on a firm theoretical foundation. This report contains enough information to justify the research team’s recommendation, but also provides details necessary to develop more traditional approaches. It is the hope of the research team that local stakeholders and decision-makers find this report helpful, both today and in the future.

71 References

Alexiadis, V. Role of Simulation in Corridor Management, presented at TRB2007 Simulation Workshop, Washington, D.C. January 2007.

Barceló, J., Casas, J., García, D., and Peranau, J. (2006). “A hybrid simulation framework for advanced transportation analysis,” Proceedings of the 11th IFAC Symposium on Control in Transportations Systems: Paper No. 246, Delft.

Burghout W. (2004). Hybrid microscopic-mesoscopic traffic simulation. Doctoral Thesis, Royal Institute of technology, Stockholm, Sweden.

Burghout, W., Kotsopoulos, H., and Andréasson, I. (2005) “Hybrid Mesoscopic-Microscopic Traffic Simulation.” Proceedings of the 83rd TRB Annual Meeting, Washington, D.C.