TRAFFIC SIMULATION SOFTWARE COMPARISON STUDY

(1)

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

(2)

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)

(3)

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

(6)

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

(7)

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,

(8)

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.

(9)

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.

(10)

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.

(11)

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

(12)

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

(13)

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.

(14)

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.

(15)

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

(16)

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.

(17)

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;

(18)

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,

(19)

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

(20)

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.

(21)

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 fps}2_{(at 0 mph)} _{Car = 9.91 fps}2

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 Lost Time = 2.0 s}Mean Headway = 1.8 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)

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

(22)

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.

(23)

Table 3-4. Comparison of relationship to other transportation software

TranPlan Emme/2 HCS ● Passer Transyt ● ● Synchro ● CORSIM ● ● SimTraffic ○ ● AIMSUN ●

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

Table 3-5. Comparison of environmental capabilities

CO emissions ● ● ● HC emissions ● ● ● NOx emissions ● ● ● PM emissions Noise Fuel economy ● ● ●

(24)

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

(25)

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.

(26)

(27)

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.

(28)

(29)

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

(30)

(31)

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.

(32)

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:

(33)

• 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.

(34)

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

(35)

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

TRAFFIC SIMULATION SOFTWARE COMPARISON STUDY