TRAFFIC SIMULATION SOFTWARE COMPARISON STUDY

By

Steven L. Jones, Jr., Ph.D. Andrew J. Sullivan, P.E.

Naveen Cheekoti Department of Civil and Environmental Engineering

The University of Alabama at Birmingham Birmingham, Alabama

and

Michael D. Anderson, Ph.D., P.E.

Dillip Malave Department of Civil and Environmental Engineering

The University of Alabama at Huntsville Huntsville, Alabama

Prepared by

UTCA

University Transportation Center for Alabama The University of Alabama, The University of Alabama at Birmingham, and

The University of Alabama in Huntsville

UTCA Report 02217 June 2004

ii

Technical Report Documentation Page

1. Report No FHWA/CA/OR-

2. Government Accession No. 3. Recipient Catalog No.

5. Report Date June 2004

4. Title and Subtitle Traffic Simulation Software Comparison Study

6. Performing Organization Code

7. Authors Steven L. Jones, Jr., Andrew Sullivan, Michael Anderson, Dillip Malave, and Naveen Cheekoti

8. Performing Organization Report No. UTCA Report 02217

10. Work Unit No.

9. Performing Organization Name and Address Department of Civil & Environmental Engineering The University of Alabama at Birmingham 1075 13th Street South Birmingham, AL 35294-4440

11. Contract or Grant No. DTRS98-G-0028 13. Type of Report and Period Covered Final Report: 10/01/02-10/10/03

12. Sponsoring Agency Name and Address University Transportation Center for Alabama The University of Alabama P.O. Box 870205 Tuscaloosa, AL 35487-0205

14. Sponsoring Agency Code

15. Supplementary Notes 16. Abstract Currently, many planning agencies rely on regional planning models for analysis of transportation system alternatives. In order to examine the impacts of system alternatives in greater detail (e.g., highway access, interchange configuration, lane geometry), the Regional Planning Commission of Greater Birmingham (RPCGB) expressed interest in exploring the use of microscopic traffic simulation models. This project compared three commercially available traffic simulation software packages: CORSIM (version 4.32), SimTraffic (version 5.0), and AIMSUN (version 4.2). Each simulation package was evaluated using the following corridor “types:” Interstate, Signalized Principal Arterial, and an Urban Collector. Each package was evaluated according to criteria that included: system requirements, ease of coding, data requirements, relevance/accuracy of performance measures reported in the output, and versatility/expandability (intelligent transportation systems evaluations, incident management, HOV facilities, ramp metering, etc.). The results indicate that all three models can provide reasonable simulations of traffic operations, although they each offer different capabilities and require varying levels of effort to code, debug, and calibrate. SimTraffic, CORSIM, and AIRSUN each have applications to which they are particularly well-suited, and the RPCGB may want to consider a combination of models to address their planning needs. 17. Key Words simulation, traffic operations, transportation planning

18. Distribution Statement

19. Security Classification (of this report) Unclassified

20. Security Classification (of this page) Unclassified

21. No of Pages 58

22. Price

Form DOT F 1700.7 (8-72)

iii

Table of Contents Contents .................................................................................................................................iii Tables ....................................................................................................................................v Figures....................................................................................................................................vi Executive Summary ...............................................................................................................vi 1.0 Introduction...................................................................................................................1 1.1. Background & Problem Statement ...........................................................................1 1.2. Purpose and Scope ....................................................................................................1 2.0 Literature Review..........................................................................................................3 2.1. CORSIM ...................................................................................................................3 2.2. SimTraffic .................................................................................................................4 2.3. AIMSUN...................................................................................................................4 2.4. Evaluating and Comparing Simulation Modeling Packages ....................................4 3.0 Software Review...........................................................................................................6 3.1. Micro-Simulation Algorithms...................................................................................7 3.1.1 Car Following Algorithms ................................................................................7 3.1.2. Lane Changing Algorithms..............................................................................8 3.1.3. Gap Acceptance Algorithms ............................................................................9 3.2. Micro-Simulation Algorithms...................................................................................9 3.2.1 CORSIM ...........................................................................................................9 3.2.2. SimTraffic ........................................................................................................10 3.2.3. AIMSUN..........................................................................................................11 3.3. Summary of Packages...............................................................................................12 4.0 Methodology.................................................................................................................16 4.1. Corridor Selection.....................................................................................................16 4.1.1. U.S. 280 between Dolly Ridge and the Cahaba River.....................................19 4.1.2. U.S. 31 between U.S. 280 and Lakeshore Parkway.........................................19 4.1.3. I-65 between AL 119 and CR 52 .....................................................................21 4.2. Data Collection .........................................................................................................23 4.3. Network Coding and Debugging ..............................................................................23 4.4. Comparison of Models Using Default Parameters ...................................................23 4.5. Model Calibration and Validation ............................................................................24 4.6. Comparison of Outputs .............................................................................................26

iv

5.0 Results...........................................................................................................................26 5.1. Data Requirements....................................................................................................27 5.2. Network Coding........................................................................................................28 5.2.1. CORSIM Coding .............................................................................................29 5.2.2. SimTraffic Coding ...........................................................................................29 5.2.3. AIMSUN Coding .............................................................................................30 5.2.4. Summary of Network Coding..........................................................................33 5.3. Ease of Debugging and Troubleshooting..................................................................33 5.4. Comparison of Un-Calibrated Model Outputs..........................................................34 5.5. Discussion of Un-Calibrated Model Results.............................................................37 5.5.1. Traffic Volumes ...............................................................................................39 5.5.2. Average Speeds................................................................................................41 5.5.3. Maximum Queues............................................................................................42 5.5.4. Summary of Un-Calibrated Outputs ................................................................44 5.6. Network Calibration and Validation.........................................................................44 5.6.1. CORSIM Validation and Calibration...............................................................44 5.6.2. SimTraffic Validation and Calibration ............................................................45 5.6.3. AIMSUN Validation and Calibration ..............................................................45 5.7. Calibrated Outputs ....................................................................................................46 6.0 Conclusions and Recommendations .............................................................................52 7.0 Acknowledgments.........................................................................................................54 8.0 References.....................................................................................................................55

v

Tables 2-1. Summary of previous traffic simulation comparisons....................................................5 3-1. Summary of software capabilities ..................................................................................13 3-2. Comparison of default parameters..................................................................................13 3-3. Summary of how performance measures are calculated ................................................14 3-4. Comparison of relationship to other packages ...............................................................15 3-5. Comparison of environmental capabilities .....................................................................15 5-1. Approximate coding times for test networks..................................................................33 5-2. Relative ease of coding network features .......................................................................33 5-3. Un-calibrated CORSIM MOEs for U.S. 280..................................................................35 5-4. Un-calibrated SimTraffic MOEs for U.S. 280 ...............................................................36 5-5. Un-calibrated AIMSUN MOEs for U.S. 280 .................................................................37 5-6. Simulated and observed maximum queue lengths .........................................................43

vi

Figures 4-1. U.S. Highway 280 study corridor...................................................................................17 4-2. AM peak hour traffic volumes on U.S. Highway 280 ...................................................18 4-3. U.S. Highway 31 study corridor.....................................................................................19 4-4. PM peak hour traffic volumes on U.S. Highway 31 ......................................................20 4-5. I-65 study corridor ..........................................................................................................21 4-6. PM peak hour traffic volumes in I-65 study corridor.....................................................22 5-1. Link-node network coded in CORSIM ..........................................................................29 5-2. Coding an offset intersection on CORSIM or SimTraffic..............................................30 5-3. Portion of U.S. 280 coded in SimTraffic........................................................................31 5-4. Portion of U.S. 280 network coded in AIMSUN ...........................................................31 5-5. Coding turn volumes in AIMSUN..................................................................................32 5-6. Simulated vs. observed volumes – Highway 280 (un-calibrated) ..................................38 5-7. Simulated vs. observed volumes – U.S. 31 (un-calibrated)............................................38 5-8. Simulated vs. observed volumes – I-65 (un-calibrated) .................................................39 5-9. Simulated vs. observed average speeds – Highway 280 (un-calibrated) .......................40 5-10. Simulated vs. observed average speeds – U.S. 31 (un-calibrated) ...............................40 5-11. Simulated vs. observed average speeds – I-65 (un-calibrated) ....................................41 5-12. Simulated vs. observed maximum queues – Highway 280 (un-calibrated) .................42 5-13. Simulated vs. observed maximum queues – U.S. 31 (un-calibrated)...........................42 5-14. Simulated vs. observed maximum queues – I-65 (un-calibrated) ................................43 5-15. Simulated vs. observed volumes – Highway 280 (calibrated) .....................................46 5-16. Simulated vs. observed volumes – U.S. 31 (calibrated)...............................................47 5-17. Simulated vs. observed volumes – I-65 (un-calibrated) ...............................................47 5-18. Simulated vs. observed average speeds – Highway 280 (un-calibrated) .....................48 5-19. Simulated vs. observed average speeds – U.S. 31 (un-calibrated) ...............................49 5-20. Simulated vs. observed average speeds – I-65 (un-calibrated) ....................................49 5-21. Simulated vs. observed maximum queues – Highway 280 (un-calibrated) .................50 5-22. Simulated vs. observed maximum queues – U.S. 31 (un-calibrated)...........................51 5-23. Simulated vs. observed maximum queues – I-65 (un-calibrated) ................................51

vii

Executive Summary

The Regional Planning Commission of Greater Birmingham (RPCGB) is responsible for evaluating transportation projects in the Birmingham area. Currently, the RPCGB relies on a regional planning model for analysis of system alternatives, but these types of models are useful primarily for broad system-level analyses. In order to examine the impacts of system alternatives in greater detail (e.g., highway access management, interchange configurations, facility widening), the RPCGB expressed interest in using microscopic traffic simulation models. The RPCGB sought guidance on the strengths and weaknesses of the various microscopic simulation models currently available. Among the characteristics they identified as important were ease of coding, visualization capabilities, and reliability of outputs. This project is intended to provide guidance to the RPCGB on three popular software packages and determine their suitability to their needs. The three micro-simulation modeling packages chosen for evaluation in this study were: CORSIM, SimTraffic, and AIMSUN. CORSIM is the most widely used micro-simulation program in the U.S. and has been refined and updated by the Federal Highway Administration over the course of nearly 30 years. As such, it has been extensively validated and uses widely accepted car following and driver behavior algorithms. SimTraffic is a fairly new micro-simulation package that uses many of the same car following and driver behavior models as CORSIM but incorporates a more user-friendly interface that greatly eases network coding requirements and interpreting outputs. AIMSUN is a micro-simulation model developed in Spain that possesses capabilities beyond either CORSIM or SimTraffic as well as 3-D animation capabilities. AIMSUN was selected for evaluation primarily because it allows dynamic trip assignment and the modeling of impacts from ITS systems. The three software packages were compared using a variety of criteria, including:

• Hardware/software requirements; • Difficulty/ease of network coding; • Data requirements, appropriateness of defaults; • Relevance/accuracy of performance measures reported in the output;

In the end, there was no ranking of ‘best’ or ‘worst’ software. All three simulation packages were found to perform reasonably well, but with limitations that should be understood prior to selecting one for network evaluation. Each package had strengths and weaknesses that made it suitable for certain applications, depending on the type of transportation improvement or planning analysis being considered. SimTraffic was found to be the easiest of the models to use and its graphical interface resulted in coding times significantly shorter than the other two models. Even inexperienced model users could get a simple network up and running in a very short time, and its ability to export to a CORSIM format also makes it an ideal starting point when creating more complex CORSIM networks. SimTraffic’s lack of transit modeling, traffic assignment, or ITS modeling, however, may limit its usefulness in more complex networks.

viii

CORSIM’s ability to model more complex situations than SimTraffic makes it more suitable for modeling complex urban networks. It can simulate the impacts of transit and parking on traffic operations, features likely to be needed in larger urban models. It can also model the impacts of traffic incidents and traffic management strategies. CORSIM requires greater effort and time for coding networks, but when used in conjunction with the Synchro/SimTraffic export capabilities, networks can still be built relatively quickly. Once constructed, it was found that CORSIM tends to over-estimate roadway capacity, leading to cases where the simulated network performance was better than one would expect in real life. CORSIM, and in fact all models, must be carefully calibrated and validated before using its outputs. CORSIM’s traffic assignment capabilities, however, are limited to single network types and currently do not function with combined surface street/freeway networks, a serious limitation if regional models are planned. Furthermore, its trip distribution functions are static, meaning the optimum paths remain constant throughout a simulation regardless of network performance or traffic conditions. Still, CORSIM has many positive attributes including its widespread use, well documented traffic flow and driver behavior algorithms, and modest coding requirements. AIMSUN was found to operate acceptably well with outputs comparable to both SimTraffic and CORSIM. It also possesses features that would be useful for creating large urban and regional networks. Its dynamic traffic assignment capability is unmatched by either SimTraffic or CORSIM, as is its ability to fully model the effects of ITS information systems on driver behavior. The downside of AIMSUN was its rather cumbersome coding requirements. Our study, using both novice and experienced simulation modelers, found that coding in AIMSUN required anywhere from four to eight times the time required to code an equivalent network in either SimTraffic or CORSIM. For this reason, the use of AIMSUN might best be limited to scenarios requiring its full capabilities. The RPCGB may wish to consider using a combination of micro-simulation packages for their planning needs. Use SimTraffic for signal and corridor studies, and either CORSIM or AIMSUN for larger urban models. If the RPCGB plans to construct large regional networks to study the impacts of large projects on other parts of the transportation system, AIMSUN is the only package tested that would meet those requirements.

1

Section 1 Introduction

1.1. Background & Problem Statement The Regional Planning Commission of Greater Birmingham (RPCGB) is responsible for evaluating transportation projects in the Birmingham area. Currently, the RPCGB relies on a regional transportation model for analysis of transportation system alternatives. Large-scale, regional transportation models are primarily useful for system-level analyses and lack the resolution to evaluate operational effect of proposed transportation projects. In order to examine the impacts of system alternatives in greater detail, in particular access management treatment, the RPCGB expressed interest in using microscopic traffic simulation models. It is believed that the performance measures generated by such models, as well as their visualization capabilities, will allow detailed operational analyses of travel corridors in the area and assist in determining the potential effectiveness of transportation projects and access management practices. The RPCGB sought guidance on the strengths and weaknesses of the various microscopic simulation models currently available. Among the characteristics they identified as important were ease of coding, ability to interface with other software packages, visualization capabilities, and reliability of outputs. This project was conducted to provide guidance to the RPCGB on three popular software packages and determine their suitability to their needs. 1.2. Purpose & Scope The project consists of a review and comparison of three commercially available traffic simulation software packages:

• CORSIM (version 5.1) – developed for the Federal Highway Administration, distributed by McTrans, Gainesville, FL.

• SimTraffic (version 5.0) – developed and distributed by Trafficware Corporation, Albany, CA1.

• AIMSUN (version 4.2) – developed by Traffic Simulation Systems, Barcelona, Spain. CORSIM was selected for evaluation as it is the most widely used traffic simulation package in the U.S. The CORSIM model, developed by the Federal Highway Administration, has been in use for over 30 years and employs widely accepted driver behavior and vehicle performance models. SimTraffic is a micro-simulation model developed for the Synchro signal timing

1 After much of the analysis was completed for this project, version 6.0 was released. New capabilities associated with 6.0 were incorporated into this version in this report where appropriate.

2

program and was originally intended to allow traffic engineers to evaluate coordinated system timings plans. The model has since been expanded to a fully functional traffic simulation tool capable of modeling freeways and other traffic features. Its user-friendly interface and simplified coding methods have made it an increasingly popular choice for traffic engineers. AIMSUN is a popular micro-simulation package used primarily in Europe but now seeing wider use in the U.S. It was selected for evaluation because it offers 3D visualization and very detailed operational analysis capabilities. It also has dynamic traffic assignment capabilities. Each simulation package was evaluated using case studies representing the following three corridor “types”:

• Interstate (including interchanges) • Signalized principal arterial • Urban collector

The goal was to test those features which the RPCGB would be most likely to use in their transportation planning work, in particular the evaluation of access management alternatives. It should be stated that all of the models have capabilities that were not tested as part of this study (e.g., modeling transit stops and routes, advanced ITS systems, and ramp metering). Although these features are quite useful and vary among the packages, the current focus was to compare the more basic functions. As such, each package was evaluated based on the following criteria:

• Hardware/software requirements; • Difficulty/ease of network coding; • Data requirements, appropriateness of defaults; • Relevance/accuracy of performance measures reported in the output; • Interoperability of input/output with other traffic analysis packages (e.g., Transyt,

Highway Capacity Software); and • Versatility/expandability (ITS evaluations, incident management, HOV facilities,

ramp metering, etc.). This report presents the results of this evaluation, as well as background information on each simulation package and a review of relevant literature. The comparison results are presented in Section 5.

3

Section 2 Literature Review

Beginning in the 1990s, several studies were performed to evaluate different traffic simulation packages and their ability to adequately simulate various test networks and transportation system configurations. Studies of the capabilities of specific packages as well as previous studies comparing models are reviewed in the following sections. The literature review is not intended to be exhaustive. Instead, the articles reviewed are intended to provide a sample of the type of work previously conducted on simulation models as well as identify issues germane to the present study. 2.1. CORSIM CORSIM has been studied extensively and is well documented in the literature. Some key papers are summarized in the following section. Owen et al. (2000) presented an excellent overview of the CORSIM model and its uses. In particular, they focused on its ability to model special circumstances such as HOV facilities and real-time adaptive traffic control systems. Hansen et al. (2000) and Perrin et al. (2002) both presented work on the ability of CORSIM to interface with and analyze real-time adaptive traffic control operations. Cragg and Demetsky (1995) examined the use of CORSIM for incident management. The research developed CORSIM models for a case study area, which included a freeway, interchange and surface streets. The authors concluded that CORSIM is a quality model, but can not possibly model all potential transportation system improvements. Nonetheless, the usefulness of CORSIM as a traffic engineering tool has been demonstrated repeatedly. It can be used for operational analyses. For example, Kim et al. (2003) evaluated the HCM-based level-of service thresholds for rural freeway facilities using CORSIM. Bared et al. (2003) displayed the use of CORSIM, in conjunction with Transyt-7F, for examining traffic operations at single point urban interchanges. Others such as Jones and Selinger (2003) have compared interchange alternatives using CORSIM. Chien et al. (2002) used CORSIM to simulate delays associated with work zone traffic control. With respect to access management treatments, Yang and Zhou (2004) used CORSIM to evaluate the relative merits of requiring a right-turn plus a u-turn to and from driveways in lieu of a more conventional direct left-turn. CORSIM has been used extensively to examine traffic control operations. Catarella et al. (2001) showed the use of CORSIM for modeling specific aspects operations of left-turn phasing in coordinated signal systems. Mussa and Selekwa (2003) examined various time-of-day (TOD) signal timing plans and Zhang et al. (2002) examined the optimization of traffic signals in the presence of a railroad crossing using CORSIM. Researchers have also used CORSIM to evaluate transit operations. Luh (2001) examined the use of CORSIM for modeling project improvements for a stretch of Interstate 10 and a light rail

4

application. CORSIM was shown to be superior to the Highway Capacity Software (HCS) when considering traffic operations with adjacent effects and CORSIM was also cited for its animation feature allowing visualization of results. Chien et al. (2002) used CORSIM to evaluate bus arrival times predicted by two artificial neural networks they developed. Gan et al. (2003) used CORSIM to estimate and compare travel speeds for bus and other vehicles in a study of bus lane performance. 2.2. SimTraffic There were numerous examples in the literature of applications of SimTraffic. An introduction to SimTraffic and its applications was presented by Sorenson and Collins (2000). Sargeant and Christie (2002) showcased the unique abilities of the Synchro/SimTraffic model to analyze roundabouts. In this study the software was used to compare the operation MOEs (e.g., delay) of roundabouts with that of stop-controlled and signalized intersections serving the same traffic. Drummond et al. (2002) used SimTraffic to generate traffic MOEs to compare with computed crash rates. As with CORSIM, there are numerous examples of SimTraffic being used to analyze traffic operations. Although it does not explicitly treat transit, Gerken and Tracy (2001) used SimTraffic creatively to examine impacts to vehicular traffic from light rail transit crossings. 2.3. AIMSUN Barcelo (2003) describes the AIMSUN model and its potential applications. Barcleo (2001) presents a detailed description of the dynamic assignment capabilities of AIMSUN. Within the discussion, a description of the car-following and lane changing algorithms in AIMSUN and their relation to past methodologies is presented. AIMSUN was applied to traffic-responsive signal control analyses by Diakaki et al. (2003). In addition to examining traffic-responsive control and its advantages in saturated traffic conditions, the work also examined priority control for transit vehicles in a coordinated urban traffic control system. Barcelo and Garcia (2002), Barcelo et al. (2001) and Barcelo et al. (1999) developed papers on the use of AIMSUN for modeling incident management and traffic management strategies. In particular, the articles focused on the dynamic route assignment capabilities of AIMSUN. The concept of alternate routing within a traffic management architecture is developed in all three papers. Finally, Barcelo (2001) provides a case study showcasing the use of AIMSUN in analyzing ITS strategies such as ramp metering and advanced traffic information systems (referred to as vehicle guidance systems in the paper). 2.4. Evaluating and Comparing Simulation Modeling Packages Although there are no specific references reviewed documenting the comparison of CORSIM, SimTraffic and AIMSUM, numerous researchers have compared various capabilities of traffic simulation packages in past efforts. A summary of key comparisons is presented in Table 2-1. Again, the purpose of the review was not to summarize all work in this area, but rather to present representative findings relevant to the current study. The studies listed in Table 2-1 are offered for reference and additional reading. A comprehensive review of simulation models was

5

conducted by the Institute for Transport Studies at the University of Leeds (ITS, 2000). The study compared the capabilities of more than 50 simulation packages. The results are available on the internet at http://www.its.leeds.ac.uk/projects/smartest/finrep.PDF.

Table 2-1. Summary of previous traffic simulation comparisons Reference Packages Compared Key Findings

Middelton and Cooner, 1999

CORSIM (FRESIM component), FREQ and INTEGRATION

Models were used to simulate congested freeway conditions. All models performed relatively well for uncontested conditions. They were all, however, inconsistent in their ability to accurately model congested conditions.

Bloomberg and Dale, 2000 CORSIM and VISSIM

Models compared for congested arterials. Found models produced consistent results among them. Also cited that both equally user friendly with respect to initial coding. Paper stressed need to understand how models work and compute performance measures.

Boxill and Yu, 2000

CORSIM, INTERGRATION, AIMSUN and PARAMICS

Models were evaluated on their ability to simulate ITS. Study concluded that AIMSUN and PARAMICS have significant potential for modeling ITS but require more calibration and validation for the U.S. CORSIM and INTERGRATION were concluded to be the most probable for ITS applications due to familiarity and extensive calibration/validation.

Barrios et al., 2001

CORSIM, VISSIM, PARAMICS and SimTraffic

Packages were evaluated based on their graphical presentation (animation) capabilities. In particular, the selected package was to be used to simulate bus operations. A review of transit-related and visualization capabilities of each model is presented. Ultimately, VISSIM was selected due to its 3-D capabilities.

Trueblood, 2001 CORSIM and SimTraffic Results showed little difference between models for arterials with low to moderate traffic. Paper stressed importance of user familiarity with models and need to properly validate.

Choa et al., 2002 CORSIM, , PARAMICS and VISSIM

Ability of models to accurately simulate a freeway interchange is compared. Study concluded that CORSIM was the easiest to code. Cited link-based routing in CORSIM and POARAMICS as a source of potential inaccuracy in modeling closely spaced intersections. VISSIM uses route-based routing that eliminates problems associated with link-based. Ability of CORSIM to compute control delay for individual approaches was cited as an advantage. “Artificial barrier” between surface streets and freeways in CORSIM cited a source of inaccuracies. PARAMICS and VISSIM were determined to more closely reflect actual conditions. 3-D capabilities of PARAMAICS and VISSIM cited as an advantage.

Demmers et al., 2002 CORSIM and SimTraffic Model results compared for congested arterial conditions. Models

produced different results for the same arterial.

Kaskeo, 2002 VISSIM, CORSIM and SimTraffic

Simulations were conducted and compared for three facility types: freeways, interchanges, and arterials with coordinated signals. Stated that CORSIM was the most mature and widely used package. Study found that VISSIM was most powerful and versatile (e.g., roundabout, LRT, and pedestrian capabilities). Study found VISSIM the least user friendly and cited additional effort and post-processing to make use of outputs. SimTraffic was found to be the most straightforward to use.

Tian et al., 2002 CORSIM , SimTraffic and VISSIM

Signalized arterials were studied. Results indicate that outputs varied with link length and speed range in addition to volume levels. In general outputs varied more as volume approached capacity. CORSIM displayed less overall variability than SimTraffic.

Bloomberg et al., 2003

CORSIM, INTEGRATION, MITSIMLab, PARAMICS, VISSIM and WATSIM

All six models were applied to signalized intersections and freeways. Study concluded that all models performed reasonably well and were fairly consistent. The study underscored the need for thorough and consistent calibration in simulations modeling.

6

Section 3 Software Review

Traffic simulation packages use fundamental traffic flow, speed, and density relationships to estimate network capacity and system performance. There are two primary types of simulation models, micro-simulation and macro-simulation. Micro-simulation models incorporate specific car-following, vehicle performance, and lane changing algorithms to model individual vehicle behavior. Macro-simulation models, on the other hand, focus not on individual vehicles in the traffic stream but instead consider traffic as an aggregate flow using continuum equations. These macroscopic models usually require less data input and simpler coding efforts but provide corresponding lower levels of output detail. The following section presents a brief description of the traffic simulation packages analyzed. 3.1. Micro-simulation Algorithms Most micro-simulation models use various algorithms and driver behavior models to simulate the movement of individual vehicles on a network. Each vehicle that enters the network is assigned a vehicle type (auto, truck, bus, or carpool) and corresponding vehicle performance characteristics (acceleration, deceleration, speed, and turning characteristics). It is also assigned one of ten driver characteristics (ranging from aggressive to cautious), giving each vehicle a unique and realistic performance profile that it maintains while traveling through the network. The position and speed of each vehicle on the network is updated once per second based on its own performance and driver characteristics, the actions of vehicles around it, roadway properties, and traffic control devices. Thus the interaction of vehicle to vehicle, vehicle to road, and vehicle to control devices are modeled accurately for each simulation. Default vehicle and driver characteristics can also be modified to better reflect actual traffic conditions for a given scenario. Once a vehicle is assigned performance and driver characteristics, its movement through the network is determined by three primary algorithms:

• Car following • Lane changing • Gap Acceptance

There are other algorithms which influence vehicle behavior, such as those which govern queue discharge and traffic signal control, but car following, lane changing, and gap acceptance are perhaps the most important and are common to all traffic simulation models. As CORSIM is generally the most familiar of the three packages, the three algorithms are described in terms of their treatment within CORSIM. As these three parameters are fundamental to traffic simulation, the following discussion is equally relevant to SimTraffic and AIMSUN.

7

3.1.1. Car Following Algorithm The car following algorithm determines how vehicles interact with one another and how vehicles distribute themselves within a traffic stream. It, in effect, determines the headway (or spacing) between vehicles. In the real world, drivers will generally try to maintain a safe distance between themselves and the vehicle in front in order to allow for safe reaction times and braking. In CORSIM, each simulated driver has an ideal headway (or spacing) that he tries to maintain with the vehicle ahead. In the simulation, this desired headway averages about one second but varies from driver to driver and vehicle to vehicle just as it does in the real world, where aggressive drivers follow vehicles more closely than cautious drivers. The actual headway a driver maintains depends on his own aggressiveness, his vehicle characteristics, and the characteristics of those around him. In CORSIM, a driver will attempt to maintain his ideal headway with other vehicles while also attempting to travel as close to his ideal free flow speed as possible. 3.1.2. Lane Changing Algorithms The lane changing algorithms control how vehicles merge, weave, and make lane changes within the traffic stream. Lane changes are complex maneuvers involving driver behavior, vehicle performance, and conditions within the traffic stream. Drivers can choose to make lane changes for different reasons, which typically include mandatory lane changes (e.g., a lane is obstructed, ends, or becomes a turn lane), positioning lane changes (e.g., putting themselves in the correct lane in order to make a turn), and discretionary lane changes (e.g., changing lanes to pass a slower vehicle). Once they have decided to make a lane change, drivers must find an acceptably large gap in the adjacent traffic stream and ensure that there are not differences in speeds between vehicles that would make the maneuver dangerous (for example, a slower moving vehicle pulling out in front of a much faster moving vehicle). It is because of this complexity that lane changing behavior is some of the most difficult to model and why it is often the source of irregularities in simulation. These irregularities may not be noticeable under traffic conditions where only light or moderate lane changing takes place, but in situations where there are heavy merging or weaving movements there can be large variances between what is modeled and what is actually observed in the field. CORSIM models all three types of lane changes and allows the user to modify selected parameters in order to calibrate lane changing behavior to the real world. In general, each driver in the model is assigned lane changing characteristics, which include:

• maximum deceleration rates they will accept in order to make a lane change; • average time/distance over which they will perform a lane change; • minimum acceptable gap in an adjacent traffic stream; • distance at which they begin positioning for lane changes (“look ahead” distance); and • desire and thresholds for making discretionary lane changes.

8

Drivers will typically accept a higher deceleration rate when making a mandatory lane change than they will for a discretionary one, because the urgency is normally greater. Drivers will also accept riskier maneuvers as the situation requiring the lane change nears, meaning drivers will initially seek a comfortable gap and minimal deceleration conditions in which to change lanes, but as the mandatory lane change point approaches will display greater urgency and begin to consider shorter gaps and higher deceleration rates. By adjusting these maximum deceleration rates and lane change distances, CORSIM can model conservative or aggressive lane changing behavior. CORSIM simulates discretionary lane changes by assigning each driver type a threshold for making a lane change. CORSIM computes the ‘desire’ for making a lane change based on vehicle speed, desired speed, current headway, and the potential benefit gained by switching to an adjacent lane. If a driver is traveling below his desired speed because of a slower vehicle in front, he will begin to consider whether changing lanes would be advantageous (this reflects his ‘desire’). CORSIM evaluates the potential benefit of changing lanes by considering a vehicle’s speed, its desired speed, and the vehicle speeds in adjacent lanes. If it determines the benefits are above a minimum threshold, the vehicle will attempt to change lanes. In the real world this threshold varies from driver to driver. Aggressive drivers will attempt a lane change even when the potential benefits are small, while conservative drivers will not attempt a lane change unless the benefits exceed a rather high threshold. These parameters can be adjusted in CORSIM to reflect real world conditions. CORSIM models positioning lane changes by looking ahead a specified number of links and initiating appropriate lane changes to correctly position a vehicle for a turn. By default, CORSIM assumes that 90% of drivers know their turn movements (left, thru, or right) at the next two intersections and that 10% “look ahead” only one intersection. What this means in simulation is that most vehicles will initiate positioning lane changes 2 roadway segments (or links) in advance. This works well if the links over which the vehicles are traveling are long enough to accommodate the desired lane changes; however, problems can occur when intersections are closely spaced and the next two links are very short, not providing vehicles enough distance to make necessary lane changes, particularly if traffic volumes are heavy and gaps are few. What can result is an unrealistic simulation of lane changing behavior, where vehicles either miss their turn or stop in an adjacent lane while waiting to merge into the proper lane. In CORSIM, these parameters can therefore be modified to allow simulated drivers to look as many as 12 links ahead. This often better reflects driver behavior in congested conditions, where drivers know they have to allow extra distance to make lane changes. Lane changing parameters must be carefully coded in CORSIM (and all simulation models) because they can have a large impact on network performance. Unrealistic lane changing behavior can either create excessive delays where none exist. Alternatively, it can suggest better operations than actual conditions causing a user to overlook potential choke points. Again, the impacts of lane changes will be less apparent under low density conditions, but as roadway conditions approach capacity the impacts can be substantial.

9

3.1.3. Gap Acceptance Algorithms The gap acceptance algorithms control how the simulated vehicles turn into or across conflicting traffic streams. An example is a vehicle waiting to turn onto a major street from a side street, or a vehicle on the mainline waiting to make a left turn across conflicting traffic. In CORSIM it is assumed that drivers wishing to make a turn will wait for a minimum gap (measured in seconds) in the opposing or conflicting traffic stream before they will initiate a turning maneuver. Anything less than this minimum gap would be considered unsafe and would be rejected. These minimum acceptable gaps are different for different maneuvers (e.g., longer for left turns than thru movements) and further vary by driver type (aggressive drivers will typically accept shorter gaps). How long or short these gaps are assumed to be can significantly influence the realism of a simulation. Gap requirements set too high may yield unrealistically long queues as drivers wait for unreasonably long gaps in traffic before making turns. Gaps set too low may produce unrealistically aggressive (and unsafe) driver behavior and underestimate turning delays at intersections. One weakness of the CORSIM gap acceptance parameters is that they are static, meaning drivers will insist on an ‘ideal’ minimum gap in traffic no matter how long they have been waiting. In reality, many drivers will consider shorter gaps as their wait time increases. 3.2. Overview of Software Packages Some background on each of the models is necessary to understand the differences in capabilities and performance. This review of the models was developed primarily from literature and manuals available from the developers of the packages. 3.2.1. CORSIM CORSIM is a comprehensive traffic simulation package developed to model surface streets, freeway systems, and combined networks having simple or complex control conditions. The strengths of the model lie in its ability to simulate a wide variety of traffic conditions from signalized arterial corridors and freeway corridors to stop controlled intersections. CORSIM is also one of the most well-documented simulation tools available, due in large part to the continued validation and updating that have occurred over nearly 30 years of use. Its simulation capabilities include:

• Arterial networks; • Freeway and surface street interchanges; • Pre-timed and actuated signals, coordination, and pre-emption; • Freeway weaving sections, lane adds and lane drops; • Stop and yield controlled intersections; • Simulation of queue length, queue blockage, and spillback; • Origin-destination traffic flow patterns and traffic assignment; • Network animation (CORSIM, 2003).

10

The CORSIM traffic simulation model was originally developed for the Federal Highway Administration in the mid-1970s as two separate models: NETSIM for surface street networks and FRESIM for freeway networks. The two models have been united under CORSIM, which permits modeling of unified freeway/arterial networks. 3.2.2. SimTraffic Synchro/SimTraffic is a software package originally developed for modeling and optimizing traffic signal timings. Synchro provides a Windows-based, easy-to-use solution for single intersection capacity analysis and signal timing optimization. In addition to calculating capacity, Synchro can also optimize signal timings, eliminating the ‘trial and error’ process for determining appropriate signal timings. All input data and parameters are entered in easy-to-use forms, a format that has made it an increasingly popular choice among traffic professionals. SimTraffic is a microscopic simulation package that uses the outputs of the Synchro program to model street networks. It was originally developed to model the arterial signal system timings developed in Synchro and provide the user with an animated view of how the system would function in the field. Since the original version shared the same graphical user interface with Synchro it allowed for relatively easy coding of street networks. The capabilities of SimTraffic were expanded in subsequent versions to model additional features such as freeways, ramps, and roundabouts. With these additions, SimTraffic has become a full-function simulation package, although with more limited features than either CORSIM or AIMSUN. The structure of SimTraffic is very similar to CORSIM. It is a link-node model that uses driver behavior and vehicle performance algorithms to simulate individual vehicle movements through a network. By design, SimTraffic uses many of the same driver behavior and vehicle performance parameters used in CORSIM. In many cases, vehicle lengths, acceleration rates, deceleration rates, cruising speeds, fuel consumption, and emissions factors are identical for both CORSIM and SimTraffic. Other parts of the model, such as reaction times and lane changing, use similar algorithms with slightly different default parameters. Perhaps the greatest difference between CORSIM and SimTraffic lies in the car-following algorithm. CORSIM tries to maintain a fixed headway between vehicles, one that varies based on driver type but averages around 1 second for all speeds and driving conditions. SimTraffic also attempts to maintain a fixed headway between vehicles, but those headways vary based on speed, driver type, and link geometry. In general, this leads to SimTraffic generating saturation flow rates (and therefore roadway capacities) lower than those found in CORSIM. What this means in practical terms is that for a given segment with fixed traffic volumes, CORSIM will tend to generate higher link capacities (and therefore less congestion) than SimTraffic. Another difference between the two models is that CORSIM updates vehicle position, speed, and other performance measures once every second. SimTraffic updates these data in 0.1 second time steps, yielding a finer degree of detail and potentially more accurate modeling of reaction times and vehicle movements. Since CORSIM only updates vehicle performance every second,

11

coding reaction times in fractions of a second is not possible. SimTraffic does not have this limitation.

3.2.3. AIMSUN AIMSUN (Advanced Interactive Micro-Simulation for Urban and Non-Urban Networks) is a full function microscopic simulation tool with a broad range of simulation capabilities. Like CORSIM and SimTraffic, it can simulate surface street networks, freeways, interchanges, weaving sections, pre-timed and actuated signals, stop controlled intersections, and roundabouts. It also has features not contained in either CORSIM or SimTraffic, such as full trip distribution capabilities, dynamic traffic assignment, real-time vehicle guidance, and 3-D animations. AIMSUN is used in conjunction with the traffic network graphical editor (TEDI) and is part of the Generic Environment for Traffic Analysis and Modeling (GETRAM) open simulation environment. The basic structure of AIMSUN is similar to both CORSIM and SimTraffic. Vehicles enter the network at entry points and their movements through the network are determined by car following, lane changing, and gap acceptance algorithms. Each vehicle is assigned a set of vehicle and driver attributes which are used by these algorithms to model vehicle movement. These algorithms differ slightly from CORSIM and SimTraffic, with key differences discussed below. Vehicle attributes such as length, width, maximum speed, and normal and maximum acceleration are assigned when a vehicle enters the network. Users can select from a wide variety of vehicle types, and within each type there will be some variation in these parameters based on statistical distributions. This differs from CORSIM, which uses discrete attributes for each vehicle type, in that there is a greater variation of performance characteristics within the vehicle stream. The same is true for driver characteristics such as desired minimum headways and speed acceptance (obedience to the speed limit). Whereas CORSIM has 10 discrete driver types, AIMSUN simply establishes mean driver performance values and varies driver behavior for each vehicle about the mean (within specified minimum and maximum values). Turning speeds also vary by driver, whereas they are fixed for all driver types in CORSIM and based on roadway geometry in SimTraffic. The result is again greater variation of driver characteristics within the vehicle stream. The gap acceptance algorithms are again similar to CORSIM but with one key difference. CORSIM has fixed gap acceptance values, based on driver type, that are maintained throughout the duration of a turning maneuver. This does not necessarily reflect how drivers behave in real life. In fact, after some period of waiting for an acceptable gap, most drivers will begin to accept shorter and shorter gaps as their wait time increases. AIMSUN attempts to replicate this behavior with initial gap values that decrease after a specified wait time. AIMSUN can function as either a stochastic model, where vehicles travel through the network based on turn probabilities, or a traffic assignment model using O/D tables. It is also capable of dynamic traffic assignment, where optimum vehicle paths between centroids are computed at the

12

beginning of the simulation and then updated based on feedback from the network. Thus, route choice is based on actual traffic conditions and may vary at different points in the simulation. This is more advanced than either SimTraffic, which is purely stochastic, or CORSIM, which offers only limited O/D capabilities. The current version of CORSIM does not permit O/D trip assignment on combined freeway and surface networks (FRESIM and NETSIM). CORSIM’s trip assignment is also static throughout the simulation. Finally, AIMSUN can simulate the effects of ITS systems, providing active vehicle guidance (either variable message signs or in-vehicle systems) to modify route choice during a simulated incident. Its diversion algorithms are more complex than those found in CORSIM, which limit the impacts of VMS to the next interchange. Lane changing algorithms are similar in principle to both CORSIM and SimTraffic, with drivers executing discretionary, positioning, and mandatory lane changes. AIMSUN’s “look ahead” distance for lane changes is essentially 2 links (or ‘segments’), similar to that for CORSIM and one less than that of Synchro. It has been found that AIMSUN is sensitive to lane changing parameters just like CORSIM and SimTraffic. Overall, AIMSUN is the most sophisticated of the three models, providing advanced features not found in either CORSIM or SimTraffic. The dynamic traffic assignment and ITS features would likely prove useful for larger regional networks. 3.3. Summary of Packages A detailed comparison of the three packages is presented in the following sections. The purpose of the comparison is to highlight the different as well as common capabilities and features among the packages. No attempt is made to rank the packages. A brief comparison of the features for all three models is provided in Table 3-1. A summary of default values assumed in each model for key parameters is shown in Table 3-2 and Table 3-3 shows how the MOEs are determined in each package. The variation in computational methods described in Table 3-3 and the default parameters shown in Table 3-2 can lead to significant differences in how each model simulates a given set of traffic conditions. Table 3-4 provides a comparison of how each package relates to other transportation software.

13

Table 3-1. Summary of general software capabilities. Feature/Capability CORSIM SimTraffic GETRAM

Network • Surface Streets ● ● ● • Freeways ● ● ● • HOV Lanes ● ● • Two-way left turn lanes Control • Unsignalized Intersections ● ● ● • Actuated Signals ● ● ● • All-Way Stop ● ● ● • Coordination ● ● ● • Roundabouts ○ ● ● • Ramp Metering ● ● • Signal Priority ● Operations • Weaving Sections ● ● ● • U-turns ● • Transit Operations ○ ● • Pedestrians ○ ● ● • Parking ● ● Other • Incidents ● ● • Spillback ● ● ● • Time Varying Demand ● ● • O/D Assignment ○ ● • Dynamic Traffic Assignment ● • Variable Message Signs ● ● • Detection/Surveillance ● ● • 2-D Animation ● ● ● • 3-D Animation ● • Signal Optimization ●

Legend: ● = full capability, ○ = partial capability, [blank] = no capability

Table 3-2. Comparison of default parameters CORSIM SimTraffic AIMSUN

Vehicle Length Car = 19.5 ft (with spacing) Car = 19.5 ft (with spacing) Car = 16.5 ft (with spacing) Max. Acceleration Rate Car = 10 fps2 (at 0 mph) Car = 10 fps2 (at 0 mph) Car = 9.91 fps2

Vehicle Headways 1.0 sec, with variance by driver

type (all speeds) 0.5 s at 0 mph

1.3 s at 30 mph 1.5 s at 50 mph,

with variance by driver type

NA

Deceleration Rates (Car)

15 fps2 (emergency) 8 fps2 (typical) 4 fps2 (turns)

12 fps2 (emergency) 7-12 fps2 (typical)

4 fps2 (turns)

26.25 fps2 (emergency) 13.12 fps2 (typical)

NA (turns)

Gap Times

Main Right = 3.6 – 10.0 s Main Left = 2.7 – 7.8 s Cross Left = 2.0 – 5.6 s Cross Thru = 3.1 – 6.8 s Cross Right = 2.0 – 5.6 s

Main Right = 3.0 s Main Left = 3.6 s Cross Left = 3.9 s Cross Thru = 3.4 s Cross Right = 2.9 s

* vary according to turn length. Net gaps average 4.0 – 5.5 s.

Main Right = 3.0 s Main Left = 3.6 s Cross Left = 3.9 s Cross Thru = 3.4 s Cross Right = 2.9 s

Driver Types 10 discrete types 10 discrete types Probabilistic

Queue Discharge Mean Headway = 1.8 s Mean Lost Time = 2.0 s

Reaction Time = 0.2 – 0.5 s Reaction Time = 1.0 s

Free Flow Speeds 0.75 – 1.27 x coded speed 0.75 – 1.27 x coded speed 1.0 x coded speed (car), but can be modified by user.

Turn Speeds Left = 22 fps (≈15 mph) Right = 13 fps (≈9 mph)

Left = 22 fps (≈15 mph) Right = 13 fps (≈9 mph)

Calculated based on geometry (range: 12 fps to free flow

speed)

14

Table 3-3. Summary of how performance measures are calculated

CORSIM SimTraffic AIMSUN Time Increment (dT)

1.0 second for surface street networks, 1.0 second for freeway networks

0.1 second for all networks User-defined, typically set equal to reaction time. Can range from 0.1 s to 1.0 s.

Link Distance Measured stop bar to stop bar. Measured stop bar to stop bar. Measured between junctions. Total Link Delay

Total travel time (all vehicles on link) minus free flow travel time (all vehicles on link)

Total travel time (all vehicles on link) minus free flow travel time (all vehicles on link)

=ΣdT*(spdmax-spd)/spdmax

Not explicitly calculated by AIMSUN. Can be computed by hand using Average Vehicle Delay and Mean Flow.

Avg. Link Vehicle Delay

Total Delay/number of vehicles Total Delay/number of vehicles Mean of individual link delays computed for each vehicle. Di = TTi – (L/Desired Speed)

Control Delay Sum of stop delay, deceleration delay, and acceleration delay Dicd = Ds + Dd + Da

• Not explicitly calculated by SimTraffic.

• ‘Signal delay’ calculated using HCM procedures.

Not calculated by AIMSUN.

Stop Delay • Vehicle considered stopped if speed falls below 3 ft/s (≈2 mph).

• Vehicle considered stopped if speed below 10 ft/s

• Vehicle considered moving again when speed exceeds 15 ft/s (≈10 mph)

• Vehicle considered stopped when speed < 3.3 ft/s

• Vehicle considered moving again when speed > 13.1 ft/s (≈9 mph)

Queue Delay • Vehicle considered queued every second if speed is below 3 ft/s (≈7 mph) and acceleration less than 2 fps2.

• Vehicle queued every other second if 3 ft/s< speed < 9 ft/s and acceleration below 2 fps2.

• Not explicitly calculated by SimTraffic.

• Not explicitly calculated by AIMSUN.

Queued Vehicle Length

Not assumed in CORSIM. User must determine based on vehicle mix.

19.5 feet (passenger car), including 3 feet between vehicles

Not assumed. User must determine based on vehicle mix.

Average Queue Length

• Vehicle considered queued if 3 ft/s< speed < 9 ft/s and acceleration is less than 2 fps2.

• Average queue length during simulation period.

• Average queue length is reported in terms of number of vehicles. CORSIM does not specify whether vehicles are cars or trucks. Calculated queue length can therefore vary significantly based on vehicle mix assumptions.

• Vehicle considered queued when speed <10 ft/s (≈7 mph)

• Records the maximum observed queue for each 2 minute simulation interval.

• Average Queue is the average of all the 2-minute maximum queues.

• Average Queue is reported in feet for each lane.

• Vehicle considered queued when speed < 3.3 ft/s (≈2 mph)

• Vehicle considered to leave queue when speed > 13.1 ft/s

• Average Queue is the average of vehicles queued in each of the analysis intervals/ number lanes.

• Average Queue is reported as number of vehicles. Calculated queue length can vary significantly based on vehicle mix assumptions.

Maximum Queue

• Maximum queue is the longest observed queue during the analysis period.

• Maximum queue is reported in terms of number of vehicles. CORSIM does not specify whether vehicles are cars or trucks. Calculated queue length can therefore vary significantly based on vehicle mix assumptions.

• Vehicle considered queued if speed <10 ft/s (≈7 mph).

• SimTraffic records the maximum observed queue for each 2 minute simulation interval.

• Maximum queue is the longest 2-minute queue observed during the analysis period.

• Maximum Queue is reported in feet for each lane.

• Vehicle queued when speed < 3.3 ft/s

• Vehicle leaves queue when speed > 13.1 ft/s

• Maximum Queue is the maximum number of vehicles queued/number of lanes.

• Max Queue is reported as number of vehicles. Calculated queue length can therefore vary significantly based on vehicle mix assumptions.

95% Queue Not computed by CORSIM. • Calculated as Average Queue (see above) plus 1.65 standard deviations.

• 95% Queue is a calculation and not simulated.

Not computed by AIMSUN.

Avg. Speed • Total travel distance (all vehicles on link) divided by total travel time (all vehicles on link).

• Total travel distance (all vehicles on link) divided by total travel time (all vehicles on link).

• Mean of average speeds computed for each vehicle. Average speed = link time per vehicle/link distance.

15

Table 3-4. Comparison of relationship to other transportation software CORSIM SimTraffic AIMSUN TranPlan Emme/2 HCS ● Passer Transyt ● ● Synchro ● CORSIM ● ● SimTraffic ○ ● AIMSUN ●

Legend: ● = interoperable, ○ = compatible, [blank] = no relationship

Table 3-5. Comparison of environmental capabilities CORSIM SimTraffic AIMSUN CO emissions ● ● ● HC emissions ● ● ● NOx emissions ● ● ● PM emissions Noise Fuel economy ● ● ●

Legend: ● = full capability, ○ = partial capability, [blank] = no capability

16

Section 4 Methodology

This section describes the methodology used to evaluate and compare the three different simulation packages. To provide a reasonable range of traffic and geometric conditions to test it was decided to select three test corridors to code using each of the models. The basic steps were as follows:

1. Corridor Selection 2. Data Collection 3. Network Coding and Debugging 4. Comparison of Models Using Default Parameters 5. Calibration and Validation 6. Comparisons of Model Functions and Outputs

4.1. Corridor Selection Three corridors in the Birmingham area were selected to serve as test cases for comparing the various model features. All of the corridors were selected in light of access management issues and RPCGB plans to utilize simulation modeling in future access management studies. Three Birmingham corridors were tested for modeling purposes: 1. U.S. 280 between Dolly Ridge Road and the Cahaba River; 2. U.S. 31 between U.S. 280 and Lakeshore Parkway; 3. I-65 between AL 119 and County Road (CR) 52. Each of these corridors is described briefly along with its key attributes. 4.1.1. U.S. 280 between Dolly Ridge Road and the Cahaba River U.S. 280 is a 6-lane facility that serves as the primary travel corridor for commercial and residential development southeast of the City (see Figure 4-1). It is currently the most congested corridor in the Birmingham area and carries over 82,000 vehicles per day on the segment modeled for this study. This segment was chosen for several reasons:

• It exhibits fairly well controlled access; • It is over-capacity during peak hours, experiencing significant congestion and delay; • It includes two interstate ramps with heavy merging volumes; • It has substantial grades which impact vehicle speeds; and • It operates under a coordinated signal system.

17

It was felt the high volumes would provide a good test for the three simulation models under saturated conditions. AM peak hour traffic volumes are shown in Figure 4-2.

Figure 4-1. U.S. Highway 280 study corridor

18

Figure 4-2. AM peak hour traffic volumes on U.S. Highway 280

19

4.1.2. U.S. 31 between U.S. 280 and Lakeshore Parkway This segment of U.S. 31 is a 4-lane arterial that runs through a commercial district in Homewood. It has several unique characteristics we felt would be useful in our evaluation, namely:

• It runs through an older commercial district with poor access management; • It exhibits relatively low speeds for a multilane arterial; • It has several closely spaced intersections, useful for evaluating queuing and spillback; • It has several skewed (i.e., not right angle) intersections; • It operates under a coordinated signal system; and • It has a range of left turn signal phasing, including permitted, protected, and

protected/permitted. This segment was chosen primarily to evaluate how the three models handle traffic interactions between closely spaced intersections and non-standard intersection geometries. The study corridor is shown in Figure 4-3 and the PM peak hour traffic volumes are shown in Figure 4-4.

Figure 4-3. U.S. Highway 31 study corridor

20

Figure 4-4. PM peak hour traffic volumes on U.S. Highway 31

21

4.1.3. I-65 between AL 119 and CR 52 I-65 between AL 119 and CR 52 is a heavily traveled 4-lane Interstate segment that carries over 70,000 vehicles per day. The interchanges at AL 119 and CR 52 are diamond-type and both experience significant congestion during peak hours. This segment was selected to evaluate each model’s ability to simulate freeways and (congested) interchanges. Ultimately, examination of this corridor will provide insight into the modeling of access management treatments near interchanges in future projects. The study corridor is shown in Figure 4-5 and the PM peak hour traffic volumes are shown in Figure 4-6.

Figure 4-5. I-65 study corridor

22

Figure 4-6. PM peak hour traffic volumes in I-65 study corridor

23

4.2. Data Collection The data requirements for creating micro-simulation models are extensive. For each corridor the following data was collected:

• turning movement counts at all intersections; • traffic signal controller settings; • lane geometry; • posted speed limits as well as actual free flow speeds; and • grades.

Recent traffic count and signal timing data was obtained from ALDOT from ongoing signal improvement projects in both the U.S. 280 and U.S. 31 corridors. Count information for the I-65 segment was collected by hand. Lane geometry was gathered from aerial photos and field verified. Grades and all other features were gathered during field inventories. For validation and calibration purposes, speed, travel time, and spot queuing data were collected in each of the corridors. 4.3. Network Coding and Debugging One of the objectives of this study was to compare the time and effort required to code the three networks in each of the three software packages. It was decided that each network would be coded twice in each of the software packages, once by graduate students who had little experience using simulation software and once by a faculty member familiar with coding simulation networks (but not necessarily each package studied here). This was intended to give an idea of how user friendly the software is for both novice and experienced users. While developing the networks, the users noted the ease of coding various components:

• links and link geometry; • traffic volumes; • link properties, such as speed and grade; • traffic signal settings; • debugging.

4.4. Comparison of Models Using Default Parameters Every model, no matter how carefully coded, will require validation and calibration to ensure its outputs are meaningful. However, the reality is that many simulation users rely heavily (or in some cases exclusively) on model default parameters, if for no other reason than they lack good data upon which to base adjustments. Many of the driver behavior and vehicle performance parameters, for instance, are quite difficult to measure in the field. It is also not always clear to users which of the many variables should be adjusted when the model is not yielding results consistent with field measurements.

24

There are further difficulties associated with calibrating and validating models for future year conditions or for facilities that do not currently exist. In those cases, the user will have little or no field data upon which to base either validation or calibration. This is also true when examining future scenarios for roadways that currently carry low traffic volumes. On low volume roads, large changes in certain calibration parameters may actually yield very small changes in model outputs such as speeds, delays, or turning behavior because there is so little vehicle interaction that drivers essentially drive at free flow speeds. In such cases, the user may calibrate the model for current conditions but may not have confidence that those same parameters will hold for future years when traffic volumes, and therefore vehicle interactions, have increased significantly. While it is never good practice to rely solely on default parameters in simulation modeling, it was of interest to see how well each of the models simulated existing conditions using only the programmed defaults. In this case, each model was run using default parameters and the results were compared to see how well they correlated to actual field conditions. 4.5. Model Calibration and Validation As discussed in the previous section, these models use a wide range of user-defined parameters to model driver behavior and vehicle performance. Each of these parameters is assigned a default value by the software, but in order to generate meaningful outputs from a simulation model it is important that each model be validated and calibrated to local conditions. Validation is the process whereby model outputs are compared to actual field data to determine how well the model replicates real-world conditions. Calibration is the process in which model parameters are adjusted to reflect the unique driving conditions associated with the network being modeled, and thereby generate a model that more closely reflects real-world conditions (Rakha et al., 1996). After the initial comparison of outputs described in the previous section, each network was validated and calibrated for observed field conditions. Primary validation parameters were:

• traffic volumes; • speeds; • travel times; and • observed queues.

These validation measures were selected largely for their ease of collection in the field. The models were calibrated based on appropriate parameters, including but not limited to headway factors, lane changing variables, driver familiarity, and free flow speeds. 4.6. Comparison of Outputs Once the networks were calibrated and validated, each was run multiple times and the results were analyzed with respect to key performance measures. The primary performance measures selected for comparison in this study included:

25

• simulated volumes; • link speed and travel time; • average and total delay; • control delay (signalized intersections); • queue lengths (maximum); and • spillback

The focus of this study was to compare these outputs for each of the models and evaluate how each model replicates real-world conditions. As stated previously, each of these models have features and outputs that were not evaluated as part of this study.

26

Section 5 Results

The results of the simulation comparison are summarized in this section. The primary comparison criteria included:

• data requirements; • ease of network coding; • ease of debugging; • validity of default parameters; • ease of calibration and validation; • output format; and • validity of MOEs.

These criteria are discussed in this chapter, along with a comparison of how the three software packages rated relative to each. The evaluation attempted to identify strengths and weaknesses of each software package rather than rank one package over another. 5.1. Data Requirements Micro-simulation models in general require fairly extensive data collection prior to network coding. All three models in this study require essentially the same data, which include:

• lane geometry on each link and at each intersection; • lengths of storage bays and turn lanes; • free-flow speeds by link; • grades, lane widths, and link distances; • hourly turn movement volumes at major intersections; • vehicle mix (autos, trucks, buses, HOV); • transit schedules (CORSIM and AIMSUN); • origin-destination (O/D) trip tables (traffic assignment only); and • traffic signal timing data;

There were no major differences in the types or amounts of input data required among the three models. Any significant differences were related primarily to different capabilities and features among the models. For instance, the Synchro input program used to develop SimTraffic networks can generate optimized signal timings as part of its analysis, obviating the need to use a separate piece of software to optimize timings for different scenarios. Likewise, CORSIM and AIMSUN can model transit operations thus requiring more data collection if transit is to be

27

included. For basic arterial and freeway segments, however, the generic data types are similar for all three models. 5.2. Network Coding All three of the simulation packages allow the user to import an aerial photo to aid in network coding. The user can import the aerial photo and literally “draw” the network on top of it, eliminating the need to measure coordinates, link lengths, or turn bay lengths. This greatly simplifies the coding process compared to older versions of these packages. The only limitation noted was that CORSIM allows only the use of bitmap images (.bmp) while AIMSUN and SimTraffic allow the use of other image types (.jpg, .gif, .tif). In most cases it is a simple process to convert files to a bitmap image, but it does require an extra piece of software to do so. As discussed previously, each network was coded twice in each software package, once by a novice and once by a person familiar with simulation software (although not necessarily each package being studied here). This gave a good idea of the ease of use for experienced simulation users as well as the learning curve required for those new to simulation. It must be noted that many of the observations related to network coding are subjective, but they are an attempt to identify strengths and weaknesses in each model and without “ranking” the models relative to one another. Each model is discussed separately in the following sections. 5.2.1. CORSIM Coding CORSIM is a link-node type model that uses a graphical user interface called TrafEd to construct networks. TrafEd was considered fairly easy to use and the link-node format easy to understand. In a link-node network, nodes represent key points in network geometry, essentially any location where there is a significant change in roadway geometry. These significant locations include intersections, points where roadways widen or narrow, merge points, and diverge points. Once located in the TrafEd editor, the nodes are joined by links, which represent the roadway segments in between these points. An example of a link-node network is shown in Figure 5-1.

28

Figure 5-1. Link-node network coded in CORSIM

The main advantage of the link-node format is that it greatly eases network coding. One must simply place a node at an intersection and connect links to it, and TrafEd will create the intersection. The downside of this format is that it can make coding complex intersections more difficult. Examples include offset intersections or highly skewed intersections, both fairly common occurrences, that can not be accurately represented with a single node. Using the case of an offset intersection shown in Figure 5-2, CORSIM requires two nodes to represent this intersection (nodes 2 and 3) and creates a “short link” between the two (link 2,3). Not only is signal operation more difficult to define, the presence of a short link in the network is not desirable as it also affects the lane-changing and “look ahead” algorithms. The user must further be careful to define vehicle movements between nodes and program clearance intervals to properly model the longer clearance times through this type of intersection.

29

Figure 5-2. Coding an offset intersection in CORSIM or SimTraffic

Defining a network spatially in CORSIM was generally found to be very straightforward. Defining the network properties is typically more time consuming. Link properties such as number of lanes and free flow speed can be entered by double-clicking on a link and entering the data in a window. Node/intersection properties are likewise entered into data windows. One weakness of this system is that it requires the user to open multiple windows to input data, so data for different approaches to an intersection are not all visible at once. Another weakness is that links and approaches are all referenced by node numbers, meaning users must frequently refer back to the link-node diagram to correctly code links and intersection approaches. 5.2.2. SimTraffic Coding The user-friendly interface of the Synchro/SimTraffic package has made it a very popular traffic analysis tool. SimTraffic uses the same link-node system as CORSIM but employs a highly simplified user interface that can significantly reduce input time. Among its most attractive features is the fact that most coding is done in one of four main input windows, where data for all approaches to an intersection are shown at once. Each approach is labeled by direction and movement (e.g., “NBL” or “SBT”) rather than the node referencing system used in CORSIM. These features were found to reduce coding time significantly. Another advantage is that Synchro automatically assigns phase numbers to each movement and assumes default detector locations for actuated signals. Both of these assisted in the coding of traffic signals and the defaults were generally found to be adequate for modeling actuated

2 3Short Link

30

signals. In general, SimTraffic’s ability to assume default values for a number of parameters such as lane usage and signal timing, and automatically balance traffic volumes between intersections was found to reduce network coding time by nearly half relative to CORSIM and still provide most of the same functionality.

Figure 5-3. Portion of U.S. 280 coded in SimTraffic

5.2.3. AIMSUN Coding The level of effort required to code a network in AIMSUN is much greater that that required in either CORSIM or SimTraffic. Although AIMSUN is often described as a link-node simulation model, it is in fact different in structure from both CORSIM and SimTraffic. Users do not place nodes as in CORSIM, nor are they automatically generated at the point where two links meet, as in SimTraffic. AIMSUN uses a system of segments, junctions, and “joins” to build a network. Roadway segments are placed as they are in SimTraffic, but the link properties are defined graphically rather than through data input windows. Users click and drag segments to achieve proper lane widths and proper turn bay lengths. This was found to make network coding more time consuming. The debugging and coding errors, however, were less of a problem because the actual geometry was always visible rather than a series of links and nodes.

31

The major difference between AIMSUN and the other two simulation packages occurs at intersections. Intersections are defined in terms of permitted turning movements rather than nodes and approach links. This allows more accurate modeling of complex intersections. Using the example of the offset intersection described in the previous section, AIMSUN models it as a true single intersection with permitted turn movements defined correctly for each signal phase. Overall, though, this does result in longer coding times, even for standard intersections.

Figure 5-4. Portion of the US 280 network coded in AIMSUN

The traffic signal coding methodology found in AIMSUN was confusing to both novice and experienced users alike. Version 4.2 has greatly simplified this from previous versions, but it is still not intuitive and was found to be very difficult for novice users to grasp. It does ultimately allow flexibility in signal operation greater than CORSIM and on par with SimTraffic, but it was felt this could be improved with a more user-friendly interface.

The input methodology for traffic volumes and turning movements was also found to be cumbersome and excessively detailed for common simulation uses. When using the model

32

stochastically, users must convert all turning volumes to percentages before entering them into the model. Furthermore, users must code turning percentages for each vehicle type separately (cars, large trucks, small trucks, etc…), and must code them by how they arrived from the previous intersection (i.e., as the result of either a left, thru, or right turn at the previous intersection). As shown in Figure 5-5, AIMSUN requires the user to code turn movements at Intersection #1 in terms of how vehicles arrived from the previous intersection (#2). First the user codes turn percentages for vehicles that arrive from movement A (left turn), then movement B, and then movement C. While this level of detail is needed in some cases, such as at interchanges, and permitted under both CORSIM and SimTraffic as additional coding fields, it was felt to be excessive for typical intersection applications. The reality is that this level of detailed turning data rarely exists in most traffic studies and the user is forced to make assumptions and take extra coding steps with no real increase in accuracy.

Figure 5-5. Coding turning volumes in AIMSUN

For typical networks with fairly standard intersections, the extra time required to code AIMSUN was considerable. In general, it was felt that this would be a disincentive to coding small networks for “quick” analyses. For networks with complex intersections this could be practical, but overall it was felt it was far less user friendly than either CORSIM or SimTraffic.

33

5.2.4. Summary of Network Coding Table 5-1 presents a summary of the time required to code each network using each of the three simulation packages, for both experienced and novice users. It can be seen that the differences in coding effort are significant between the three models. In general, additional features and model capabilities come at the expense of increased coding time.

Table 5-1. Approximate coding times for test networks Coding Time (hours)

SimTraffic CORSIM AIMSUN

Network Novice Experienced Novice Experienced Novice Experienced U.S. Highway 280 10 5 20 8 >40 17 U.S. Highway 31 8 3 20 5 35 14 I-65 10 6 16 9 40 20

Table 5-2 presents a summary of the relative ease of coding different network features in each of the software packages.

Table 5-2. Relative ease of coding different network features Feature SimTraffic CORSIM AIMSUN

Network layout ● ● ○ Link geometry ● ● ○ Intersection data ● ○ ● Turning Volumes ● ○ X Traffic Signals ● ○ X Key: ● = Good, ○ = Fair, X = Poor 5.3 Ease of Debugging and Troubleshooting

First-time users of simulation models often experience the elation of completing the coding task only to discover that the real work has just begun. Debugging simulation networks, particularly complex ones, can require substantial amounts of time just to reach the point where the model will run and the user can further validate its operation. The debugging tools included with each simulation package are therefore critical to the coding process.

Of the three models, CORSIM has the most extensive error checking software. When converting the edit file to a .trf input format, TrafEd performs an initial error check on the input data. It provides two types of messages, ‘warnings’ of inconsistencies that may indicate an error but will not prevent the network from running, and ‘fatal errors’ that will prevent program execution. Once a .trf file is successfully created and run through CORSIM, a second round of error checking is performed, providing similar warnings and error messages. It was felt by the novice users that the CORSIM error messages were often cryptic and not easily understood. All coding errors are referenced by node number, approach number, and lane number, none of which may be immediately recognizable to the user. It was also felt that TrafEd/CORSIM’s lack of error checking during coding allows coding errors to go unnoticed during the network building process.

34

SimTraffic provides a similar level of error checking but in a manner slightly different from CORSIM. Specifically, the Synchro interface provides on-the-fly error checking, highlighting erroneous fields in red during the coding process so that many errors are caught early (analogous to how spell-check software highlights misspelled words as they are typed). It was also felt that having all the input data displayed on just four screens allowed the user to detect errors, particularly data omissions, more easily. Finally, when SimTraffic does detect errors, it references them by node number, directional approach, and turn movement (i.e., node 6, northbound left turn) making identifying the error easier.

AIMSUN performs all error checking during the data input process, unlike CORSIM which does most of it at the very end. AIMSUN checks the validity of all input parameters as they are entered and will not allow a data input window to be closed until all errors are resolved. While this makes the coding process longer, it allows errors to be identified at the time they will be most obvious to the user (e.g., identifying signal phasing errors while the user is keying in the signal data rather than hours or perhaps days after the signal data was entered) and most easily corrected. It also means that once a network is coded, there are likely to be few, if any, data errors that will prevent the simulation from running.

It should be noted that debugging is different from network validation. Debugging refers to eliminating coding errors that will prevent a simulation from running. This does not mean that the debugged network will accurately reflect real world conditions. It may still contain incorrect roadway geometry, traffic volumes, or control plans and these must be detected by the user.

In summary, it was felt that the “debug as you go” methods used in AIMSUN and SimTraffic were preferable to the post-coding debugging method of CORSIM. Errors were easier to identify and rectify as the data was being input rather than hours or often days after the fact. Furthermore, many users, particularly novices, felt that the error messages in CORSIM were often cryptic and difficult to identify. In this study, all of the AIMSUN networks ran without error once coding was completed, and the SimTraffic networks ran after only a few run-time errors.

5.4 Comparison of Un-Calibrated Model Outputs

Every model, no matter how carefully coded, will require validation and calibration to ensure its outputs are meaningful. However, the reality is that many simulation users rely heavily (or in some cases exclusively) on model default parameters, if for no other reason than they lack good data upon which to base adjustments. Many of the driver behavior and vehicle performance parameters, for instance, are quite difficult to measure in the field. It is also not always clear to users which of the many variables should be adjusted when the model is not yielding results consistent with field measurements. While it is never recommended that un-validated or un-calibrated model data be used, the initial un-calibrated runs of each model were compared to see how well they correlated to observed traffic conditions in the field.

35

Key MOEs examined included:

• Traffic volumes – how well did the models simulate the correct traffic volumes? • Speeds – how did simulated speeds compare to field measurements? • Maximum queues – how did the simulated maximum queues compare to field

observations? • Travel delay – not easily measured in the field, but how do each of the models

compare in terms of delay on key links?

Five runs of each model were performed for each of the networks. Random number seeds were varied with each model run to simulate normal variation in traffic patterns. Summaries of the results for the US 280 Corridor are presented in Tables 5-3 through 5-5. The overall conclusions for this section were drawn from all three test networks.

Table 5-3. Un-calibrated CORSIM MOEs for U.S. 280 corridor Link/Volumes (vph) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 EB between Dolly and Summit 2492 2459 2465 2502 2520 2488 0.8% US 280 EB between 459 and Perimeter 3889 3856 3949 3969 3988 3930 1.2% US 280 WB between Grandview and Perim. 3516 3486 3512 3519 3483 3503 0.4% US 280 WB between 459 Ramps 3716 3768 3725 3718 3646 3715 0.7% US 280 WB left to 459 710 683 694 654 708 690 2.5% I-459 Ramp 2010 2005 2011 2041 2075 2028 1.2% Link/Average Speed (mph) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 WB between Perimeter and 459 31.9 32.4 33 32.4 32.2 32.38 0.8% US 280 WB between Summit and Dolly 28.8 28.5 27.6 28.6 29.2 28.54 1.4% US 280 EB between 459 & Perimeter. 18.4 14.8 19.6 20.7 18.1 18.32 8.2% Link/Max. Queue (ft) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 WB at Perimeter 500 540 480 460 560 508 6.6% US 280 WB left at 459 460 480 460 420 500 464 4.5% US 280 WB at Summit 540 560 560 520 500 536 3.9% Link/Average Delay (sec/veh) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 WB at Perimeter 24.2 24.7 23.7 22.6 24.9 24.02 2.9% US 280 WB at Summit 31.4 29.7 29.7 31.3 30.2 30.46 2.3% US 280 EB at Perimeter 33.4 49.7 28.4 25.7 32.2 33.88 18.7% 459 NB Ramp 8.4 8.2 8.3 7.4 6.9 7.84 7.0%

36

Table 5-4. Un-calibrated SimTraffic MOEs for U.S. 280 corridor Link/Volumes (veh/hr) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 EB between Dolly and Summit 2425 2446 2409 2524 2463 2667 1.2% US 280 EB between 459 and Perimeter 3564 3543 3627 3578 3579 3889 0.5% US 280 WB between Grandview and Perim. 3610 3627 3570 3679 3546 3920 1.0% US 280 WB between 459 Ramps 3965 3970 4025 3983 3732 4277 1.9% US 280 WB left to 459 920 857 890 876 891 964 1.7% I459 Ramp 1907 1874 1927 1891 1906 2066 0.7% Link/Average Speed (mph) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 WB between Perimeter and 459 9 8 12 7 11 9.4 17.9% US 280 WB between Summit and Dolly 16 13 12 13 17 14.2 13.0% US 280 EB between 459 & Perimeter. 18 19 20 20 19 19.2 3.3% Link/Max. Queue (ft) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 WB at Perimeter 1737 1488 1738 1758 1737 1692 4.8% US 280 WB left at 459 570 486 571 574 571 554 4.9% US 280 WB at Summit 924 855 878 1128 1058 969 10.3% Link/Average Delay (sec/veh) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 WB at Perimeter 52 33.4 46.4 69.3 46.8 49.58 17.9% US 280 WB at Summit 47.3 41.3 51.1 53.9 42.9 47.3 8.8% US 280 EB at Perimeter 23.4 20.1 18.6 18.3 20.4 20.16 6.9% 459 NB Ramp 12.2 10.3 9.6 10.7 10 10.56 6.7%

37

Table 5-5. Un-calibrated AIMSUN MOEs for U.S. 280 corridor Link/Volumes (veh/hr) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 EB between Dolly and Summit 2525 2554 2515 2562 2604 2552 1.0% US 280 EB between 459 and Perimeter 2670 2735 2664 2685 2722 2695 1.0% US 280 WB between Grandview and Perim. 3525 3529 3483 3562 3522 3524 0.5% US 280 WB between 459 Ramps 3638 3625 3566 3591 3620 3608 0.7% US 280 WB left to 459 822 839 848 787 842 828 2.2% Link/Average Speed (mph) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 WB between Perimeter and 459 16.7 17.3 17.4 17.2 17.2 17.2 1.1% US 280 WB between Summit and Dolly 25.6 26.3 26.4 26.3 26.7 26.3 1.0% US 280 EB between 459 & Perim. 44.3 43.9 43.7 43.4 40.5 43.2 2.5% Link/Max. Queue (ft) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 WB at Perim 540 500 488 488 515 506 3.4% US 280 WB left at 459 450 400 400 410 392 410 3.9% US 280 WB at Summit 450 480 488 530 500 489 4.2% Link/Average Delay (sec/veh) Run 1 Run 2 Run 3 Run 4 Run 5 Average Deviation US 280 WB at Perim 11 11 11 11 11 11 0.0% US 280 WB at Summit 20 20 21 21 21 21 2.3% US 280 EB at Perim 10 8 10 7 14 9.8 18.8% 459 NB Ramp 67 66 71 66 66 67 2.3%

Tables 5-3 through 5-5 indicate relatively consistent performance among the models for the un-calibrated runs. The un-calibrated results are discussed in greater detail in the following section.

5.5 Discussion of Un-Calibrated Results

5.5.1. Traffic Volumes All three of the models produced consistent and accurate simulations of real world traffic volumes. The simulated traffic volumes generally varied from the mean by less than 5% between runs, consistent with typical daily fluctuations. Figures 5-6, 5-7, and 5-8 present sample simulation volumes from all three networks. The only major variation noted was for CORSIM on the I-65 network. The entry links for CORSIM did not permit as high a capacity as did the other two models, and therefore lower volumes were simulated for the freeway segments. This was a disparity that increased as entry volumes increased.

38

0

500

1000

1500

2000

2500

0 500 1000 1500 2000 2500

Observed Volume (vph)

Sim

ulat

ed V

olum

e (v

ph)

SimTrafficCORSIMAIMSUNObserved

Figure 5-6. Simulated vs. observed volumes – Highway 280 (un-calibrated)

0

500

1000

1500

2000

2500

0 500 1000 1500 2000 2500

Observed Volume (vph)

Sim

ulat

ed V

olum

e (v

ph)

SimTrafficCORSIMAIMSUNObserved

Figure 5-7. Simulated vs. observed volumes – Highway 31 (un-calibrated)

39

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

0 1000 2000 3000 4000 5000

Observed Volume (vph)

Sim

ulat

ed V

olum

e (v

ph)

SimTrafficCORSIMAIMSUNObserved

Figure 5-8. Simulated vs. observed volumes – I-65 (un-calibrated)

5.5.2. Average Speeds None of the models accurately simulated speeds across all traffic conditions. It was found that speeds on low and medium volume segments were generally simulated fairly well by all three models. This is consistent with other studies that have found simulation accuracy typically decreases as v/c ratios increase. It was found that deviations of simulated speeds from field measurements increased on the most congested segments, particularly on sections of U.S. 280 and I-65. In fact, simulated speeds on the freeway networks showed the widest variation from observed speeds. This is most likely due to the fact that free-flow speeds on freeways are much higher than they are on surface streets and there is greater room for variation. The variations from observed speeds grew more pronounced as speeds increased. All three models tended to overestimate speeds on congested segments, a result of the fact that they tend to overestimate segment capacity. Of the three models, though, SimTraffic appeared to most closely model observed speeds, followed by CORSIM. It was found that AIMSUN and CORSIM significantly overestimated speeds on congested links, which is consistent with other studies. Figures 5-9, 5-10, and 5-11 present scatter plots of observed vs. simulated average speeds for all three networks.

40

0

5

10

15

20

25

30

35

40

45

0 5 10 15 20 25

Observed Speed (mph)

Sim

ulat

ed S

peed

(mph

)

SimTrafficCORSIMAIMSUNObserved

Figure 5-9. Simulated vs. observed average speeds – Highway 280 (un-calibrated)

0

5

10

15

20

25

30

0 5 10 15 20 25 30

Observed Speed (mph)

Sim

ulat

ed S

peed

(mph

)

SimTrafficCORSIMAIMSUNObserved

Figure 5-10. Simulated vs. observed average speeds – Highway 31 (un-calibrated)

41

0

10

20

30

40

50

60

70

0 10 20 30 40 50 60 70

Observed Speed (mph)

Sim

ulat

ed S

peed

(mph

)

SimTrafficCORSIMAIMSUNObserved

Figure 5-11. Simulated vs. observed average speeds – I-65 (un-calibrated)

In summary, even the un-calibrated models seemed to return fairly good approximations of vehicle speeds when segment traffic volumes were low to moderate and free flow speeds were low, such as on Highway 31. Users should be cautious, however, when using un-calibrated simulation models of congested or high speed networks. In these cases, the simulated speeds can vary dramatically from observed speeds and the un-calibrated outputs may be meaningless.

5.5.3. Maximum Queues Maximum queue lengths are of particular interest to traffic engineers because they are used to design storage lanes and evaluate the potential for spillback between congested intersections. Vehicle queues that overflow a storage lane can block thru lanes and create significant congestion on the mainline, so it is important that roadway designs be able to accommodate expected vehicle queues. The maximum queue lengths generated for key segments in each model were compared to see how well the simulations correlated with observations. Figures 5-12, 5-13, and 5-14 present summaries of observed and simulated maximum queues for each of the three networks.

42

0

500

1000

1500

2000

2500

3000

0 500 1000 1500 2000 2500

Observed Max. Queue (ft)

Sim

ulat

ed M

ax. Q

ueue

(ft)

SimTrafficCORSIMAIMSUNObserved

Figure 5-12. Simulated vs. observed maximum queues – Highway 280 (un-calibrated)

0

100

200

300

400

500

600

700

800

900

1000

0 200 400 600 800 1000

Observed Max. Queue (ft)

Sim

ulat

ed M

ax. Q

ueue

(ft)

SimTrafficCORSIMAIMSUNObserved

Figure 5-13. Simulated vs. observed maximum queues – Highway 31 (un-calibrated)

43

0

200

400

600

800

1000

1200

1400

1600

0 200 400 600 800 1000 1200 1400 1600

Observed Max. Queue (ft)

Sim

ulat

ed M

ax. Q

ueue

(ft)

SimTrafficCORSIMAIMSUNObserved

Figure 5-14. Simulated vs. observed maximum queues – I-65 (un-calibrated)

As with vehicle speeds, the greatest variation in queue lengths was found on congested segments. Queue lengths on minor movements were generally found to be reasonable among all three models and correlated well with observed field conditions. For congested segments or movements, however, there was much greater variation. Examples can be found on critical segments on the U.S. 280 and U.S. 31 networks:

Table 5-6. Simulated and Observed Maximum Queue Lengths (ft) Segment Traffic SimTraffic CORSIM AIMSUN Observed

U.S. 31 NB Left at 29th Avenue Light 105 96 88 100 U.S. 31 EB at 28th Avenue Moderate 193 208 188 175 U.S. 31 NB Left at Hollywood Moderate 227 204 260 225 U.S. 280 WB Left at I-459 SB Moderate 554 464 410 600 U.S. 280 WB at Perimeter Park High 1692 508 506 2000 U.S. 280 WB at Summit Blvd. High 969 536 489 1200

Again, no model was perfect, but SimTraffic appeared to provide the closest estimates for queuing. It should be noted, however, that SimTraffic considers a vehicle queued when its speed falls below 7 miles per hour, whereas CORSIM and AIMSUN use more conservative thresholds (see Table 2-1). This likely explains at least part of its tendency to yield higher maximum queue lengths than CORSIM or AIMSUN.

44

5.5.4. Summary of Un-Calibrated Outputs Even un-calibrated models can return fairly good approximations of vehicle speeds, queues, and flows when traffic volumes are low to moderate. In these cases, vehicle interactions are low enough and there is sufficient network capacity that most vehicles will travel at close to free flow speeds on major segments. Disruptions to traffic movement at these moderate flow rates are usually caused by traffic control devices and if those are coded correctly the models seem to provide reasonable outputs. Users should be cautious, however, when using un-calibrated simulation programs on networks with heavy traffic flow or congested conditions. In these cases, the simulated speeds and queue lengths can vary dramatically from observed conditions.

CORSIM and AIMSUN were found to have the greatest variation from observed speeds and queue lengths largely because their car following algorithms generate higher saturation flow rates than SimTraffic. All three models, however, need to be carefully calibrated when simulating congested conditions.

SimTraffic generally yielded un-calibrated results most consistent with field observations. Particularly useful was the fact that SimTraffic provides queue calculations in terms of feet rather than number of vehicles, as in CORSIM and AIMSUN. This was felt to provide more accurate queue estimates and required less computation time for the user.

5.6 Network Validation and Calibration The evaluation of the un-calibrated networks underscores the importance of carefully validating and calibrating simulation models. One difficulty in doing this, however, is that simulation users often do not know which of the many default parameters should be changed. A variety of default parameters were modified in each model to create more realistic simulations. These parameters included start-up lost time, queue discharge headways, lane changing distances, segment speeds, headway factors, and speed limit adherence. Each simulation network was calibrated to achieve the closest correlation with observed field conditions. A brief summary of each follows. 5.6.1. CORSIM Validation and Calibration The evaluation of the un-calibrated networks revealed that CORSIM had a tendency to over-estimate arterial and surface roadway capacities, particularly on congested segments. The result was that key MOEs for congested segments often indicated better operating conditions than those observed in the field. Average speeds were higher than those recorded in the field and queue lengths tended to be shorter. This was most noticeable in the U.S. 280 network and the segment of CR 52 in the I-65 network. The primary calibration parameters for the CORSIM arterial networks were “mean startup delay” and “mean discharge headway,” both of which are link parameters. The default values for CORSIM are 2.0s and 1.8s respectively, and these were adjusted upwards, on some segments to 2.6s for the discharge headways, in order to yield more realistic outputs. Changes were also made to the lane changing “look ahead” distances, as the default values were found to be too short for congested conditions, leading to excessive queuing and lane blockages.

45

On freeway segments, CORSIM actually tended to underestimate speeds and vehicle queues. In this case, the primary calibration factors were lane changing distances and headway factors. The headway factors were decreased slightly to increase link capacities. Lane changing “look ahead” distances were increased to prevent unrealistic lane changing behavior. This calibration procedure, while effective, also highlighted one of the difficulties found in calibrating all simulation models – the user rarely has the kind of data required to adjust many of the default parameters, such as vehicle performance characteristics or distributions for discharge and lost time parameters. In the case of U.S. 280, adjusting the mean startup delay and mean discharge headway parameters from their default values yielded more realistic network performance, but it was not known how accurately these reflect actual vehicle and driver behavior. 5.6.2. SimTraffic Validation and Calibration As discussed in previous sections, SimTraffic generally yielded un-calibrated results that most closely reflected observed field conditions. Nonetheless, all three SimTraffic networks required significant calibration. The primary adjustments made in SimTraffic were to the headway factors and the driver lane changing parameters. Segment speeds were also adjusted slightly to achieve better results. As with CORSIM, it was generally felt that the default lane changing distances were too short for the most congested segments, resulting in many vehicles blocking traffic while waiting to make lane changes. The default lane changing distances were increased to correct this. As with CORSIM, headway factors were the primary calibration parameter for adjusting freeway speeds and queuing. SimTraffic has the added advantage of allowing headway factors to be modified for individual movements, while this can only be done for links in CORSIM. By allowing these adjustments to be made for individual movements, SimTraffic in effect allows the user to adjust saturation flow rates in greater detail. 5.6.3. AIMSUN Validation and Calibration AIMSUN displayed many of the same characteristics as CORSIM, which were the tendencies to over-estimate capacity and speeds on congested segments. The primary calibration parameters used in AIMSUN were ‘reaction time at stop’, segment speeds, and lane changing times. AIMSUN displayed the same characteristics regarding lane changing that CORSIM and SimTraffic did, which was that the default lane changing distances, while adequate for lower volume segments, were inadequate for congested segments. AIMSUN does allow the direct editing of lane change times/distances by link, as well as the editing of global parameters. These were sufficient to correct observed problems. One difference between AIMSUN and the other models was that turn capacities at signals seemed to be lower than in either CORSIM or SimTraffic. Left turn queues that cleared every cycle in CORSIM and SimTraffic often did not in AIMSUN, requiring changes to turning speeds

46

and start-up headways. One difficulty with this is that AIMSUN allows only global modification of start-up headways, not by link, so care must be taken when making these changes. 5.7 Calibrated Outputs Once calibrated, each of the models provided reasonable simulation outputs. The best fit with observed traffic conditions was generally associated with basic MOEs such as simulated volumes and queue lengths in turn bays. Greater variance was found with mainline queue lengths and mainline speeds, and these variances tended to be most pronounced as link congestion increased. Of the three models, SimTraffic required the least calibration effort for two of the three test networks (U.S. 280 and U.S. 31). CORSIM required the least calibration effort for the I-65 network. It should be noted again, though, that all three models required significant calibration in every case. Figures 5-15 through 5-23 show calibrated volumes, speeds, and queues for each of the nine test networks. All three models typically required very little calibration to achieve a good match between observed and simulated traffic volumes. The most interesting case was the freeway network coded in CORSIM, which required slight increases in the capacity of the entry links to allow the proper volumes to enter the network. All other adjustments tended to be minor.

0

500

1000

1500

2000

2500

3000

3500

4000

4500

0 1000 2000 3000 4000 5000

Observed Volume (vph)

Sim

ulat

ed V

olum

e (v

ph)

SimTrafficCORSIMAIMSUNObserved

Figure 5-15. Simulated vs. observed volumes – U.S. 280 (calibrated)

47

0

500

1000

1500

2000

2500

0 500 1000 1500 2000 2500

Observed Volume (vph)

Sim

ulat

ed V

olum

e (v

ph)

SimTrafficCORSIMAIMSUNObserved

Figure 5-16. Simulated vs. observed volumes – U.S. 31 (calibrated)

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

0 1000 2000 3000 4000 5000

Observed Volume (vph)

Sim

ulat

ed V

olum

e (v

ph)

SimTrafficCORSIMAIMSUNObserved

Figure 5-17. Simulated vs. observed volumes – I-65 (calibrated)

48

Of all the model outputs the greatest variations were in speed. In all three models, calibrating link speeds was probably the most difficult, because adjustments to global headway and speed parameters would affect all links. Adjustments to link-specific parameters such as discharge headways were usually found to be most effective because they had minimal impacts on adjacent links.

0

5

10

15

20

25

0 5 10 15 20 25Observed Speed (mph)

Sim

ulat

ed S

peed

(mph

)

SimTrafficCORSIMAIMSUNObserved

Figure 5-18. Simulated vs. observed speeds – U.S. 280 (calibrated)

49

0

5

10

15

20

25

30

35

0 5 10 15 20 25 30

Observed Speed (mph)

Sim

ulat

ed S

peed

(mph

)

SimTrafficCORSIMAIMSUNObserved

Figure 5-19. Simulated vs. observed speeds – U.S. 31 (calibrated)

0

10

20

30

40

50

60

70

0 10 20 30 40 50 60 70

Observed Speed (mph)

Sim

ulat

ed S

peed

(mph

)

SimTrafficCORSIMAIMSUNObserved

Figure 5-20. Simulated vs. observed speeds – I-65 (calibrated)

50

Calibration of maximum queue lengths was achieved largely through the adjustment of discharge headways and lane changing parameters. Since these are mostly link-specific parameters, it was possible to achieve good correlations between observed and simulated queue lengths without affecting queues on adjacent links. It is interesting to note that none of the models was able to properly simulate queue lengths on County Road 52 in the I-65 network (see Figure 5-23). This suggests that there may be other factors affecting the operation of this segment that need to be investigated further.

0

500

1000

1500

2000

2500

0 500 1000 1500 2000 2500

Observed Max. Queue (ft)

Sim

ulat

ed M

ax. Q

ueue

(ft)

SimTrafficCORSIMAIMSUNObserved

Figure 5-21. Simulated vs. observed maximum queues – U.S. 280 (calibrated)

51

0

100

200

300

400

500

600

700

800

900

1000

0 200 400 600 800 1000

Observed Max. Queue (ft)

Sim

ulat

ed M

ax. Q

ueue

(ft)

SimTrafficCORSIMAIMSUNObserved

Figure 5-22. Simulated vs. observed maximum queues – U.S. 31 (calibrated)

0

200

400

600

800

1000

1200

1400

1600

0 200 400 600 800 1000 1200 1400 1600

Observed Max. Queue (ft)

Sim

ulat

ed M

ax. Q

ueue

(ft)

SimTrafficCORSIMAIMSUNObserved

Figure 5-23. Simulated vs. observed maximum queues – I-65 (calibrated)

52

Section 6 Conclusions and Recommendations

This project found that SimTraffic, CORSIM, and AIMSUN can all provide reasonable results for typical simulation applications. In the end, there was no ranking of ‘best’ or ‘worst’ software. All three simulation packages were found to perform reasonably well, but with limitations that should be understood prior to selecting one for network evaluation. It was felt that each package had strengths and weaknesses that made it suitable for certain applications, depending on the type of transportation improvement or planning analysis being considered. SimTraffic was found to be the easiest of the models to use and its graphical interface resulted in coding times significantly shorter than the other two models. Even inexperienced model users could get a simple network up and running in a very short time, and its ability to export to a CORSIM format makes it an ideal starting point when creating more complex CORSIM networks. In the test of un-calibrated networks it was found that SimTraffic generally produced results that more closely reflected observed traffic conditions. This was especially true for congested networks. SimTraffic’s ability to generate optimized signal timings also makes it an ideal package for simulating signalized arterials. SimTraffic’s lack of transit modeling, traffic assignment, or ITS modeling, however, may limit its usefulness in more complex networks. CORSIM’s ability to model more complex situations than SimTraffic may make it more suitable for modeling urban networks. It can simulate the impacts of transit and parking on traffic operations, features likely to be needed in larger urban models. It can also model the impacts of traffic incidents and traffic management strategies. CORSIM requires greater effort and time for coding, but when used in conjunction with the Synchro/SimTraffic export capabilities, networks can still be built relatively quickly. Once constructed, it was found that CORSIM tends to over-estimate roadway capacity, leading to cases where the simulated network performance was better than one would expect in reality. CORSIM, and in fact all models, must be carefully calibrated and validated before using its outputs. CORSIM’s traffic assignment capabilities are limited to single network types and currently do not function with combined surface street/freeway networks, a serious limitation if regional models are planned. Furthermore, its trip distribution functions are static, meaning the optimum paths remain constant throughout a simulation regardless of network performance or traffic conditions. Still, CORSIM has many positive attributes including its widespread use, well documented traffic flow and driver behavior algorithms, and modest coding requirements.

53

AIMSUN was found to operate acceptably well for “American” networks, with outputs comparable to both SimTraffic and CORSIM. However, AIMSUN, like CORSIM, was found to over-estimate link capacities and therefore requires careful validation and calibration. AIMSUN’s output was generally easy to follow, although all MOEs are listed by segment number, requiring the user to refer back to a network diagram. AIMSUN also provides a smaller range of MOEs than either SimTraffic or CORSIM. AIMSUN possesses features that would be useful for creating large urban and regional networks. Its dynamic traffic assignment capability is unmatched by either SimTraffic or CORSIM, as is its ability to fully model the effects of ITS information systems on driver behavior. The downside of AIMSUN was found to be its rather cumbersome coding requirements. In this study both novice and experienced simulation modelers found that coding in AIMSUN required anywhere from four to eight times the time required to code an equivalent network in either SimTraffic or CORSIM, although some of that time is made up by a much simplified debugging process. For this reason, the use of AIMSUN might best be limited to scenarios requiring its full capabilities. The RPCGB may wish to consider using a combination of micro-simulation packages for their planning needs. In particular it is suggested that RPCGB use SimTraffic for signal and corridor studies, and either CORSIM or AIMSUN for larger, regional analyses. If the RPCGB plans to construct large regional networks using dynamic traffic assignment to study the impacts of large projects on other parts of the transportation system, AIMSUN is the only package evaluated that would meet those requirements.

54

Section 7 Acknowledgements

The researchers wish to thank the Regional Planning Commission of Greater Birmingham for its funding and technical support of this project. Special thanks are extended to Mr. Steve Ostaseski for his interest and guidance throughout the project. Appreciation is also expressed to members of the Alabama Department of Transportation, Third Divisions, for their assistance in obtaining data for the project.

55

Section 8 References

Barcelo, J., Ferrer, J. and Martin, R. “Simulation Assisted Design and Assessment of Vehicle

Guidance Systems” International Transactions on Operations Research, Vol. 6, No. 1, pp. 123-143, 1999.

Barcelo, J. “Microscopic Traffic Simulation: A tool for the Analysis and Assessment of ITS

Systems” Highway Capacity Committee, Half Year Meeting, Lake Tahoe, July, 2001. Barcelo J. and Ferrer, J. “Assessment of Incident Management Strategies using AIMSUM”

Available at http://www.tss-bcn.com/euro_its_lyon.pdf. October, 2003. Barcelo, J. and Garcia, D. “Scenario Analysis: A Simulation Based Tool for Regional Strategic

Traffic Management,” Proceedings from the 9th World Congress on Intelligent Transport Systems, ITS America, Washington, DC, 2002.

Barcelo, J. “So Real, Surreal,” Traffic Technology International, May 2003. Bared, J., Powell, A., and Kaisar, E. “Traffic Planning Models for Single-Point and Tight

Diamond Interchanges,” Transportation Research Record, No. 1847, Transportation Research Board, Washington, DC. 2003.

Catarella, A., Wolshon, B. and Juneau, N. “A Method for the Simulation of Coordinated Lead-

lag Left-turn Phasing in CORSIM,” ITE Journal, Institute of Transportation Engineers, Washington, DC, September 2001.

Chien, S., Goulias, D., Yahalom, S., and Chowhury, S. “Simulation-based Estimates of Delays

at Freeway Work Zones,” Journal of Advanced Transportation, Institute for Transportation, Calgary, AB, August 2002.

Chien, S., Ding, Y., and Wei, C. “Dynamic Bus Arrival Time Prediction with Artificial Neurral

Networks,” Journal of Transportation Engineering, American Society of Civil Engineers, Reston, VA, September 2002.

Corsim Product Information. Available from McTrans Website

http://mctrans.ce.ufl.edu/store/description.asp?itemID=450. August, 2003.

56

Cragg, C.A. and Demetsky, M.J. Simulation Analysis of Route Diversion Strategies for Freeway Incident Management, Final Report. Published by the Virginia Transportation Research Council. February 1995.

Diakaki, C., Dinopoulou, V., Aboudolas, K., Papageorgiou, M., Ben-Shabat, E., Seider, E., and

Leibov, A. “Extensions and New Applications of the Traffic-responsive Urban Control Strategy: Coordinated Signal Control for Urban Networks,” Transportation Research Record, No. 1856, Transportation Research Board, Washington, DC. 2003.

Drummond, K., Hoel, L., and Miller, J. “Using Simulation to Predict Safety and Operational

Impacts of Increasing Traffic Signal Density,” Transportation Research Record, No. 1784, Transportation Research Board, Washington, DC. 2002.

Gan, A., Yue, H. Ubaka, I. and Zhao, F. “Development of Operational Performance and

Decision Models for Arterial Bus Lanes,” Transportation Research Record, No. 1858, Transportation Research Board, Washington, DC. 2003.

Gerken, J. and Tracy, S. “Analysis of Traffic Impacts at Isolated Light Rail Transit (LRT)

Crossings Using SimTraffic,” Improving Transportation Systems Safety and Performance, 2001 Spring Conference and Exhibit, Monterey, CA, Institute of Transportation Engineers, March 2001.

GETRAM Product Information. Available from the GETRAM Internet Site http://www.tss-

bcn.com/. August, 2003. Integration Product Information. Available from McTrans Website

http://mctrans.ce.ufl.edu/store/description.asp?itemID=444. August, 2003. Jones, E. and Selinger, M. “Comparison of Operations of Single-point and Tight Urban

Diamond Interchanges. Transportation Research Record, No. 1847, Transportation Research Board, Washington, DC. 2003.

Kim, J., Courage, K., Washburn, S., and Bonyani, G. “Framework for Investigation of Level-

of-service Criteria and Thresholds on Rural Freeways,” Transportation Research Record, No. 1852, Transportation Research Board, Washington, DC. 2003.

Luh, J.Z. “Case Studies for Simulation of Roadway and Traffic Operations Using CORSIM”

ITE Journal, Institute of Transportation Engineers, Washington, DC, July 2001. Maki, P.J. “Adverse Weather Traffic Signal Timing” Published online from

www.trafficware.com. August, 2003. Mussa, R. and Selekwa, M. “Proposed Methodology of Optimizing Transitioning Between

Time-of-day Timing Plans,” Journal of Transportation Engineering, American Society of Civil Engineers, Reston, VA, July 2003.

57

Owen, L., Zhang, Y., Rao, L., and McHale, G. “Traffic Flow Simulation Using CORSIM,”

Proceedings of the 2000 Winter Simulation Conference, IEEE Service Center, Piscataway NJ, 2000.

Perrin, J., Martin, P., and Jhaveri, C. “Interfacing SCOOT and CORSIM: Three Salt Lake City

Networks Modeled,” Compendium of Technical Papers from the ITE 2002 Annual Meeting and Exhibit, Philadelphia, PA, Institute of Transportation Engineers, August 2002.

Rakha, H., Hellinga, B., Van Aerde, M., and Perez, W. “Systematic Verification, Validation

and Calibration of Traffic Simulation Models. Compendium of Papers from the 1996 Transportation Research Board Annual Meeting. Washington D.C. January, 1996.

Sargeant, S. and Christie, J. “Performance Evaluation of Modern Roundabouts on South

Golden Road,” Transportation Visioning – 2002 and Beyond, Proceedings of the 37th Annual Conference, St. John’s, Newfoundland, Canadian Transportation Research Forum, May 2002.

Sorenson, D. and Collins, J. “Practical Applications of Traffic Simulation Using SimTraffic,”

Compendium of Technical Papers from the ITE 2000, District 6 Annual Meeting, San Diego, CA, Institute of Transportation Engineers, June 2000.

Synchro/SimTraffic Product Information. Available from the TrafficWare Internet Site

www.trafficware.com. August, 2003. VISSIM Product Information. Available from McTrans Website

http://mctrans.ce.ufl.edu/store/description.asp?itemID=662. August, 2003. Wang, Y. and Prevedouros, P.D. “Comparison of INTEGRATION, TSIS/CORSIM and

WATSim in Replicating Volumes and Speeds on Three Small Networks” Compendium of Papers from the 1998 Transportation Research Board Annual Meeting. Washington D.C. January, 1998.

Wang Y. and Prevedouros P.D. “Synopsis of Traffic Simulation Models” Compendium of

Papers from the 1996 Transportation Research Board Annual Meeting. Washington D.C. January, 1996.

Washburn S.S. and Larson N. “Signalized Intersection Delay Estimation: Case Study

Comparison of TRANSYT-7F, Synchro and HCS” ITE Journal, Institute of Transportation Engineers, Washington, DC, March 2002.

Yang, X. and Zhou, H. “CORSIM-based Simulation Approach to Evaluation of Direct Left

Turn Versus Right Turn Plus U-turn from Driveways,” Journal of Transportation Engineering, American Society of Civil Engineers, Reston, VA, January 2004.

58

Zhang, L., Hobeika, A. and Ghaman, R. “Optimized Traffic Network Signals Around Railroad Crossings: Model Validations,” Transportation Research Record, No. 1811, Transportation Research Board, Washington, DC. 2002.