Traffic Analysis Toolbox Volume IV:

Guidelines for Applying CORSIM

Microsimulation Modeling Software

PUBLICATION NO. FHWA-HOP-07-079 JANUARY 2007
ii 

Foreword 

Traffic simulation software has become increasingly more popular as a traffic analysis tool 

used in transportation analyses. One reason for this increase is the need to model and 

analyze the operation of complex transportation systems under congested conditions. 

Where some analytical techniques break down under these types of conditions, simulation 

has the potential to successfully model these complex scenarios. However, despite the 

widespread use of traffic simulation software, there are a variety of conflicting thoughts 

and practices on how simulation should be used. 

The purpose of the Guidelines for Applying CORSIM Microsimulation Modeling Software is to 

provide more specific guidance for using CORridor SIMulation (CORSIM) traffic 

simulation software to conduct a transportation analysis using the process recommended 

by Volume III: Guidelines for Applying Traffic Microsimulation Modeling Software. CORSIM is 

the core simulation and modeling component of the Traffic Software Integrated System 

(TSIS) tool suite. The guidelines provide the reader with a seven-step process that begins 

with project scope and ends with the final project report. The process is specific to using 

CORSIM and TSIS. It is hoped that this document will assist the transportation 

community in creating a more consistent process in the use of CORSIM traffic simulation 

software. 

This document serves as Volume IV in the FHWA Traffic Analysis Toolbox. Other 

volumes currently in the toolbox include: Volume I: Traffic Analysis Tools Primer, Volume 

II: Decision Support Methodology for Selecting Traffic Analysis Tools, and Volume III: 

Guidelines for Applying Traffic Microsimulation Modeling Software. 

The intended audience for this report includes the CORSIM simulation analyst, the 

reviewer of CORSIM simulation analyses, the procurer of CORSIM simulation services, 

and the researcher using CORSIM. 

Regina McElroy, 

Director 

Office of Transportation Management 
iii 

Notice 

This document is disseminated under the sponsorship of the U.S. Department of 

Transportation in the interest of information exchange. The U.S. Government assumes no 

liability for its contents or use thereof. 

The U.S. Government does not endorse products or manufacturers. Trade and 

manufacturers’ names appear in this report only because they are considered essential to 

the objective of the document. 

Quality Assurance Statement 

The Federal Highway Administration (FHWA) provides high-quality information to serve 

Government, industry, and the public in a manner that promotes public understanding. 

Standards and policies are used to ensure and maximize the quality, objectivity, utility, 

and integrity of its information. FHWA periodically reviews quality issues and adjusts its 

programs and processes to ensure continuous quality improvement. 
iv 

Technical Report Documentation Page 

1. Report No. 

FHWA-HOP-07-079 

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

5. Report Date 

January 2007 

4. Title and Subtitle 

Traffic Analysis Toolbox 

Volume IV: Guidelines for Applying CORSIM Microsimulation 

Modeling Software 6. Performing Organization Code 

7. Author(s) 

Peter Holm, Daniel Tomich, Jaimie Sloboden, Cheryl Lowrance 

8. Performing Organization Report No. 

9. Performing Organization Name and Address 10. Work Unit No. (TRAIS) 

ITT Industries, Inc. 

11. Contract or Grant No. 

13. Type of Report and Period Covered 

Final Report, February 2004 – 

December 2006 

12. Sponsoring Agency Name and Address 

Office of Operations 

Federal Highway Administration 

400 7th Street, S.W. 

Washington, D.C. 20590 14. Sponsoring Agency Code 

15. Supplementary Notes 

FHWA COTR: John Halkias, Office of Transportation Management 

FHWA COTM: James Colyar, Office of Operations Research & Development 

16. Abstract 

This report describes a process and acts as guidelines for the recommended use of CORSIM traffic 

simulation software in transportation analyses. The seven-step process presented in these guidelines 

highlights the aspects of a CORSIM analysis from project start to project completion. The seven steps 

in the process include: 1) scope project, 2) data collection, 3) base model development, 4) error 

checking, 5) calibration - comparing model MOEs to field data (and adjusting model parameters), 6) 

alternatives analysis, and 7) final report. Each step is described in detail and an example problem 

applying the process is carried through the entire document. 

The report appendices contain detailed information covering areas such as: fundamentals of CORSIM 

model theory, an overview of CORSIM capabilities and limitations, guidance on the initialization 

period, a discussion on actuated signal control in CORSIM, coding techniques for complex situations, 

and run-time extension. 

This is the fourth volume in a series of volumes in the Traffic Analysis Toolbox. The other volumes 

currently in the Traffic Analysis Toolbox are: 

Volume I: Traffic Analysis Tools Primer (FHWA-HRT-04-038) 

Volume II: Decision Support Methodology for Selecting Traffic Analysis Tools (FHWA-HRT-04-039) 

Volume III: Guidelines for Applying Traffic Microsimulation Software (FHWA-HRT-04-040)

17. Key Word 

CORSIM, traffic simulation, traffic analysis tools, 

highway capacity, simulation guidelines, 

microsimulation 

18. Distribution Statement 

No restrictions. This document is available to the 

public through the National Technical 

Information Service, Springfield, VA 22161 

19. Security Classif. (of this report) 

Unclassified 

20. Security Classif. (of this page) 

Unclassified 

21. No. of Pages 

348 

22. Price 

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized
v 

SI* (MODERN METRIC) CONVERSION FACTORS 

APPROXIMATE CONVERSIONS TO SI UNITS

Symbol When You Know Multiply By To Find Symbol 

LENGTH 

in inches 25.4 millimeters mm 

ft feet 0.305 meters m 

yd yards 0.914 meters m 

mi miles 1.61 kilometers km 

AREA 

in2 square inches 645.2 square millimeters mm2

ft2 square feet 0.093 square meters m2

yd2 square yard 0.836 square meters m2

ac acres 0.405 hectares ha 

mi2 square miles 2.59 square kilometers km2

VOLUME 

fl oz fluid ounces 29.57 milliliters mL 

gal gallons 3.785 liters L 

ft3 cubic feet 0.028 cubic meters m3 

yd3 cubic yards 0.765 cubic meters m3 

NOTE: volumes greater than 1000 L shall be shown in m3

MASS 

oz ounces 28.35 grams g

lb pounds 0.454 kilograms kg

T short tons (2000 lb) 0.907 megagrams (or "metric ton") Mg (or "t") 

TEMPERATURE (exact degrees) o

F Fahrenheit 5 (F-32)/9 Celsius oC 

or (F-32)/1.8 

ILLUMINATION 

fc foot-candles 10.76 lux lx 

fl foot-Lamberts 3.426 candela/m2 cd/m2

FORCE and PRESSURE or STRESS 

lbf poundforce 4.45 newtons N 

lbf/in2 poundforce per square inch 6.89 kilopascals kPa 

APPROXIMATE CONVERSIONS FROM SI UNITS 

Symbol When You Know Multiply By To Find Symbol 

LENGTH

mm millimeters 0.039 inches in 

m meters 3.28 feet ft 

m meters 1.09 yards yd 

km kilometers 0.621 miles mi 

AREA mm2

 square millimeters 0.0016 square inches in2 

m2 square meters 10.764 square feet ft2 

m2 square meters 1.195 square yards yd2 

ha hectares 2.47 acres ac 

km2 square kilometers 0.386 square miles mi2 

VOLUME 

mL milliliters 0.034 fluid ounces fl oz 

L liters 0.264 gallons gal 

m3 cubic meters 35.314 cubic feet ft3 

m3 cubic meters 1.307 cubic yards yd3 

MASS 

g grams 0.035 ounces oz

kg kilograms 2.202 pounds lb

Mg (or "t") megagrams (or "metric ton") 1.103 short tons (2000 lb) T 

TEMPERATURE (exact degrees) o

C Celsius 1.8C+32 Fahrenheit oF 

ILLUMINATION 

lx lux 0.0929 foot-candles fc 

cd/m2 candela/m2 0.2919 foot-Lamberts fl

FORCE and PRESSURE or STRESS 

N newtons 0.225 poundforce lbf 

kPa kilopascals 0.145 poundforce per square inch lbf/in2

*SI is the symbol for th International System of Units. Appropri e ate rounding should be made to comply with Section 4 of ASTM E380. 

(Revised March 2003)
vi 

Table of Contents 

Introduction ................................................................................................................................................ 1

1.0 Define the CORSIM Study ......................................................................................................... 9

1.1 Study Purpose and Objectives............................................................................................... 9

1.2 Study Scope ............................................................................................................................ 10

1.2.1 Freeway Projects..................................................................................................... 12

1.2.2 Arterial Projects ...................................................................................................... 12

1.2.3 Combined Network Project (Corridor) ............................................................... 12

1.2.4 Temporal Scope ...................................................................................................... 13

1.2.5 Design Year ............................................................................................................. 14

1.3 Analytical Approach Selection ............................................................................................ 14

1.4 Analytical Tool Selection (Software)................................................................................... 15

1.4.1 CORSIM Capabilities and Limitations................................................................ 15

1.4.2 TSIS Input/Output/Interface Support Tools..................................................... 15

1.4.3 Third Party Products ............................................................................................. 16

1.4.4 User Training/Support ......................................................................................... 17

1.4.5 Ongoing Software Enhancements........................................................................ 17

1.5 Resource Requirements ........................................................................................................ 17

1.5.1 Other Resources...................................................................................................... 17

1.6 Management of a CORSIM Study....................................................................................... 18

1.7 Example Problem: Study Scope and Purpose ................................................................... 21

2.0 Data Collection and Preparation.............................................................................................. 27

2.1 Geometric Data ...................................................................................................................... 30

2.2 Demand Data ......................................................................................................................... 31

2.3 Control Data........................................................................................................................... 33

2.3.1 Sign Data ................................................................................................................. 33

2.3.2 Pre-Timed Signal Control Data ............................................................................ 34

2.3.3 Actuated Signal Control Data............................................................................... 34

2.3.4 Pedestrian Demand Estimates.............................................................................. 35

2.3.5 Ramp Meter Control Data..................................................................................... 35

2.4 Calibration Data..................................................................................................................... 36

2.4.1 Capacity and Saturation Flow Data..................................................................... 36

2.4.2 Point Speed Data .................................................................................................... 36

2.4.3 Travel Time Data.................................................................................................... 37

2.4.4 Delay and Queue Data .......................................................................................... 37

2.5 Field Inspection...................................................................................................................... 37

2.6 Quality Assurance ................................................................................................................. 38
vii 

2.6.1 Data Verification..................................................................................................... 38

2.6.2 Data Validation....................................................................................................... 38

2.7 Reconciliation of Traffic Counts .......................................................................................... 39

2.8 Example Problem: Data Collection and Preparation........................................................ 41

3.0 Base Model Development ......................................................................................................... 51

3.1 Create a New TSIS Project and TRAFED Network .......................................................... 53

3.1.1 Set the Simulation Run Control Data .................................................................. 53

3.1.2 Set the TRAFED Preferences................................................................................. 54

3.2 Link-Node Diagram: Model Blueprint............................................................................... 54

3.2.1 Nodes ....................................................................................................................... 54

3.2.2 Links......................................................................................................................... 61

3.2.3 Surface Street Link Data........................................................................................ 68

3.2.4 Corridors ................................................................................................................. 74

3.2.5 Review ..................................................................................................................... 74

3.3 Traffic Demand Data............................................................................................................. 74

3.3.1 Entry Volume.......................................................................................................... 74

3.3.2 Freeway Demand ................................................................................................... 77

3.3.3 Surface Street Demand .......................................................................................... 81

3.3.4 Vehicle Mix.............................................................................................................. 84

3.4 Traffic Control........................................................................................................................ 84

3.4.1 Freeway Ramp Meter Control.............................................................................. 84

3.4.2 Arterial Control ...................................................................................................... 86

3.4.3 Review ..................................................................................................................... 89

3.5 Traffic Operations and Management Data for Links ....................................................... 89

3.5.1 Modeling Traffic Incidents or Events .................................................................. 89

3.5.2 Incident Detection .................................................................................................. 91

3.5.3 Bus Operations ....................................................................................................... 91

3.5.4 Pedestrian Interaction............................................................................................ 93

3.6 Example Problem: Base Model Development ................................................................... 94

4.0 Error Checking............................................................................................................................. 99

4.1 Review Software Errors........................................................................................................ 99

4.2 Review Input Data............................................................................................................... 100

4.2.1 CORSIM Input Data............................................................................................. 102

4.2.2 CORSIM Diagnostics ........................................................................................... 103

4.3 Review Animation............................................................................................................... 104

4.4 Key Decision Point .............................................................................................................. 106

4.5 Example Problem: Error Checking ................................................................................... 107

5.0 Calibration.................................................................................................................................. 117
viii 

5.1 Objectives of Calibration .................................................................................................... 117

5.2 Calibration Approach ......................................................................................................... 118

5.3 Establish Calibration MOEs and Targets ......................................................................... 120

5.3.1 Selection of Calibration MOEs ........................................................................... 120

5.3.2 Establishing Calibration Targets ........................................................................ 121

5.4 CORSIM Run Considerations............................................................................................ 124

5.4.1 Multiple CORSIM Runs ...................................................................................... 124

5.4.2 Simulation Time Frame ....................................................................................... 125

5.4.3 Exclusion of Initialization Period....................................................................... 126

5.4.4 Link Aggregations into Sections ........................................................................ 126

5.5 Calibrate Capacity at Key Bottlenecks.............................................................................. 126

5.5.1 Freeway Capacity Calibration............................................................................ 127

5.5.2 Surface Street Capacity Calibration ................................................................... 130

5.6 Calibrating Traffic Volumes............................................................................................... 132

5.6.1 Freeway Traffic Volume Calibration ................................................................. 133

5.6.2 Surface Street Traffic Volume Calibration........................................................ 133

5.7 Calibrating System Performance....................................................................................... 134

5.7.1 Freeway System Performance Calibration ....................................................... 135

5.7.2 Calibrating Arterial System Performance......................................................... 137

5.8 Key Decision Point: Check Overall Calibration Targets ................................................ 138

5.9 Example Problem: Model Calibration .............................................................................. 140

6.0 Alternatives Analysis ............................................................................................................... 149

6.1 Baseline Demand Forecast ................................................................................................. 150

6.1.1 Demand Forecasting ............................................................................................ 150

6.1.2 Constraining Demand to Capacity .................................................................... 151

6.1.3 Allowance for Uncertainty in Demand Forecasts............................................ 151

6.2 Generation of Project Alternatives.................................................................................... 151

6.3 Selection of Measures of Effectiveness (MOEs) .............................................................. 152

6.3.1 Candidate MOEs for Overall System Performance......................................... 153

6.3.2 Candidate MOEs for Localized Problems......................................................... 154

6.3.3 Choice of Average or Worst Case MOEs .......................................................... 155

6.4 Model Application .............................................................................................................. 156

6.4.1 Multiple CORSIM Runs ...................................................................................... 156

6.4.2 Exclusion of Initialization Period....................................................................... 157

6.4.3 Impact of Alternatives on Demand ................................................................... 157

6.4.4 Signal/Meter Control Optimization.................................................................. 157

6.5 Tabulation of Results .......................................................................................................... 158

6.5.1 Numerical Output................................................................................................ 158
ix 

6.5.2 Correcting Biases in the Results ......................................................................... 158

6.6 Evaluation of Alternatives.................................................................................................. 160

6.6.1 Interpretation of System Performance Results................................................. 160

6.6.2 Hypothesis Testing .............................................................................................. 162

6.6.3 Confidence Intervals and Sensitivity Analysis ................................................ 162

6.6.4 Comparing Results to Other Traffic Analysis Tools ....................................... 164

6.6.5 Reviewing Animation Output............................................................................ 164

6.6.6 Comparison Techniques...................................................................................... 168

6.7 Example Problem: Alternatives Analysis ........................................................................ 171

7.0 Final Report and Technical Documentation........................................................................ 181

7.1 Final Report .......................................................................................................................... 181

7.2 Technical Report .................................................................................................................. 182

7.2.1 Technical Memorandums ................................................................................... 183

7.3 Presentation of a CORSIM Simulation Analysis............................................................. 184

7.4 Example Problem: Final Report......................................................................................... 186

Appendix A: Introduction to CORSIM Theory................................................................................ 187

Appendix B: CORSIM Capabilities and Limitations...................................................................... 195

Appendix C: Initialization Period....................................................................................................... 201

Appendix D: Generation and Usage of Random Numbers in CORSIM .................................... 205

Appendix E: Vehicle Entry Headway Generation in CORSIM .................................................... 213

Appendix F: Actuated Signal Control................................................................................................ 217

Appendix G: Error Checking Process – Coded Input Data Checklist.......................................... 241

Appendix H: Understanding CORSIM Output ............................................................................... 243

Appendix I: Frequently Asked Questions......................................................................................... 275

Appendix J: Converting Between Systems of Actuated Control Parameters ............................. 287

Appendix K: Coding Techniques for Complex Situations ............................................................ 295

Appendix L: Run-Time Extension Overview ................................................................................... 305

Appendix M: CORSIM Path Following Capability ........................................................................ 309

Appendix N: Emergency Vehicle Operation .................................................................................... 311

Appendix O: File Extensions ............................................................................................................... 317

Glossary ................................................................................................................................................... 319

Acknowledgments ................................................................................................................................. 325

References................................................................................................................................................ 327

Bibliography ........................................................................................................................................... 329

Index ......................................................................................................................................................... 331 
x 

List of Figures 

Figure 1. Flowchart. CORSIM model development and application process.................... 6

Figure 2. Chart. Selecting a peak period for analysis. .......................................................... 13

Figure 3. Chart. Prototypical CORSIM analysis task sequence. (7)...................................... 18

Figure 4. Graphic. Example problem: study map. ................................................................ 22

Figure 5. Graph. Example problem: peak period selection. ................................................ 23

Figure 6. Chart. Example problem: study schedule.............................................................. 25

Figure 7. Illustration. Traffic count example.......................................................................... 40

Figure 8. Illustration. Example problem: aerial photo and planimetric map.................... 42

Figure 9. Chart. Example problem: turning movement count. ........................................... 43

Figure 10. Illustration. Example problem: freeway bottleneck locations. ......................... 46

Figure 11. Graph. Example problem: freeway travel time summary................................. 47

Figure 12. Drawing. Example problem: HWY 100 lane geometry schematic................... 48

Figure 13. Drawing. Example problem: Minnetonka Blvd. lane geometry drawing....... 48

Figure 14. Illustration. Typical surface street node location................................................ 56

Figure 15. Illustration. Overlapped turn bay node location. ............................................... 57

Figure 16. Illustration. One-way street node location. ......................................................... 57

Figure 17. Illustration. Freeway placement of nodes............................................................ 58

Figure 18. Illustration. Node layout in TRAFED................................................................... 60

Figure 19. Illustration. Freeway lane identification codes. .................................................. 64

Figure 20. Illustration. Freeway layout with 11 lanes........................................................... 65

Figure 21. Illustration. Lane drop downstream of ramp meter. ......................................... 67

Figure 22. Illustration. Effects of incorrect link length. ........................................................ 69

Figure 23. Illustration. TRAFVU intersection pull back....................................................... 70

Figure 24. Chart. Surface street lane numbering. .................................................................. 71

Figure 25. Illustration. Left turn channelization.................................................................... 72

Figure 26. Illustration. Sample lane alignment...................................................................... 73

Figure 27. Illustration. Turning alignments. .......................................................................... 73

Figure 28. Graph. Volume interpolation when not assigned for a time period................ 76

Figure 29. Illustration. Ramp-to-ramp trips........................................................................... 80

Figure 30. Illustration. Conditional turn movement example at diamond interchange. 82

Figure 31. Illustration. TRAFED actuated control property dialog.................................... 87

Figure 32. Illustration. TRAFED pre-timed controller property dialog............................. 88

Figure 33. Illustration. Example problem: HWY 100 link-node diagram.......................... 95
xi 

Figure 34. Illustration. Example problem: freeway origin-destination table. ................... 96

Figure 35. Illustration. Example problem: base model development review. .................. 97

Figure 36. Illustration. Example problem: HWY 100 northbound lane geometry 

schematic. ................................................................................................................ 108

Figure 37. Illustration. Example problem: link-node diagram of HWY 100 interchanges.

................................................................................................................................... 108

Figure 38. Illustration. Example problem: volume error check at node 325, time period 1.

................................................................................................................................... 110

Figure 39. Illustration. Example problem: volume error check at node 325, time period 4.

................................................................................................................................... 111

Figure 40. Illustration. Example problem: sample signal timing sheet............................ 112

Figure 41. Illustration. Example problem: sample signal plan schematic. ...................... 113

Figure 42. Illustration. Example problem: TRAFVU detector error check. ..................... 113

Figure 43. Illustration. Example problem: warning message from TRAFED-CORSIM 

translation. .............................................................................................................. 114

Figure 44. Illustration. Incorrect coding of lane drop......................................................... 115

Figure 45. Flowchart. Calibration approach. ....................................................................... 119

Figure 46. Equation. Calculating the GEH Statistic.(14)....................................................... 123

Figure 47. Equation. Determining the appropriate number of simulation runs to 

complete. ................................................................................................................. 125

Figure 48. Illustration. Typical freeway bottleneck locations............................................ 127

Figure 49. Figure. Example of sensitivity of car following sensitivity multiplier on 

throughput of a basic freeway segment. ............................................................ 129

Figure 50. Figure. Example of sensitivity of mean discharge headway on throughput of 

a signalized intersection approach. ..................................................................... 131

Figure 51. Figure. Example of comparing actual speed from field to modeled speed. . 135

Figure 52. Figure. Speed-volume relationship in CORSIM for a basic freeway segment.

................................................................................................................................... 136

Figure 53. Illustration. Example problem: HWY 100 freeway bottleneck locations. ..... 141

Figure 54. Graph. Example problem: capacity calibration at northbound HWY 100/25th

1⁄2 Street Exit. ........................................................................................................... 143

Figure 55. Graph. Example problem: speed calibration results for northbound HWY 100 

during AM peak..................................................................................................... 147

Figure 56. Graph. Example problem: speed calibration results for northbound HWY 100 

at WB TH 7 Exit during AM peak. ...................................................................... 147

Figure 57. Equation. Calculating the 95th percentile probable worst outcome............... 156

Figure 58. Formula. Determining the nearest neighbor value. ......................................... 165

Figure 59. Graph. Sample mean data graph for nearest neighbor example.................... 166
xii 

Figure 60. Illustration. Washington State DOT traffic profile graph.(20) .......................... 168

Figure 61. Illustration. Sample comparison of project alternatives using schematic 

drawing. .................................................................................................................. 170

Figure 62. Illustration. Example problem: traffic demand forecast at HWY 100/TH 7 

interchange.............................................................................................................. 172

Figure 63. Illustration. Example problem: alternatives generation and analysis process.

................................................................................................................................... 173

Figure 64. Illustration. Example problem: visual comparison of HWY 100/TH 7 

interchange alternatives. ....................................................................................... 179

Figure 65. Graph. Maximum acceleration versus speed by performance index. ........... 192

Figure 66. Graph. Fuel consumption for different acceleration rates............................... 193

Figure 67. Graph. Vehicles discharged from an internal link in equilibrium example. 201

Figure 68. Illustration. Reaching equilibrium...................................................................... 203

Figure 69. Graph. Random variations in average speed among 10 runs......................... 205

Figure 70. Equation. Schrage random number generator.................................................. 207

Figure 71. Graph. Normal distribution................................................................................. 214

Figure 72. Graph. Exponential variates. ............................................................................... 215

Figure 73. Graph. Erlang distribution................................................................................... 216

Figure 74. Diagram. Typical traffic signal dual-ring diagram........................................... 218

Figure 75. Diagram. Standard NEMA phasing. .................................................................. 218

Figure 76. Diagram. Lagging left turn phase. ...................................................................... 219

Figure 77. Diagram. Leading protected left turns on the main street, concurrent sidestreet phases............................................................................................................ 219

Figure 78. Diagram. Dual ring, leading protected left turns on the main street, split sidestreet phases............................................................................................................ 220

Figure 79. Diagram. Single Ring, Split Phasing................................................................... 220

Figure 80. Formula. Extendable interval duration.............................................................. 221

Figure 81. Formula. Max phase green duration. ................................................................. 222

Figure 82. Chart. Variable initial timing. .............................................................................. 222

Figure 83. Chart. Gap reduction concept.............................................................................. 224

Figure 84. Illustration. Overlapping phase. ......................................................................... 229

Figure 85. Diagram. Pedestrian demand.............................................................................. 230

Figure 86. Diagram. Typical coordination timing dial. ...................................................... 232

Figure 87. Chart. Phase split diagram................................................................................... 232

Figure 88. Diagram. Examples of timing plan transitions. ................................................ 238

Figure 89. Graph. Cumulative versus interval data............................................................ 243

Figure 90. Diagram. Control delay components. ................................................................ 244
xiii 

Figure 91. Equation. Control delay components................................................................. 245

Figure 92. Equation. Calculating intersection control delay.............................................. 245

Figure 93. Equation. Calculating intersection total delay. ................................................. 245

Figure 94. Diagram. Intersection phased in a quad left sequence. ................................... 287

Figure 95. Formula. CORSIM yield point............................................................................. 288

Figure 96. Diagram. NETSIM offset versus NEMA offset. ................................................ 289

Figure 97. Diagram. Signal coordination parameters......................................................... 290

Figure 98. Equations. Force off calculations......................................................................... 290

Figure 99. Equation. Permissive period 1............................................................................. 292

Figure 100. Equation. Permissive period 2........................................................................... 292

Figure 101. Equation. Permissive period 2 (recalculated).................................................. 292

Figure 102. Equation. Permissive period 3........................................................................... 293

Figure 103. Equation. Permissive period 3 (recalculated).................................................. 293

Figure 104. Illustration. Roundabout example in TRAFVU. ............................................. 296

Figure 105. Illustration. Dummy freeway sections. ............................................................ 297

Figure 106. Illustration. Surface street section. .................................................................... 297

Figure 107. Illustration. U-turn example. ............................................................................. 298

Figure 108. Illustration. Continuous left turn. ..................................................................... 299

Figure 109. Illustration. Two controllers act as one controller to control two 

intersections. ........................................................................................................... 300

Figure 110. Illustration. Mid-block pedestrian actuated crossing..................................... 302

Figure 111. Illustration. Actuated control dialog for a mid-block pedestrian phase. .... 303

Figure 112. Illustration. Reversible freeway lane example. ............................................... 304

Figure 113. Diagram. TSIS architecture. ............................................................................... 306

Figure 114. Illustration. Path file format and example for path following...................... 309

Figure 115. Illustration. Example of the vehicle file for path following. ......................... 310

Figure 116. Illustration. Example of the probe file format for path following................ 310

Figure 117. Illustration. Emergency vehicle contra-flow. .................................................. 314
xiv 

List of Tables 

Table 1. Professional staff and suggested chapters................................................................. 4

Table 2. Example milestones and deliverables for a CORSIM study.(7)............................. 19

Table 3. Example problem: key tasks and level of effort estimated. .................................. 24

Table 4. Example spreadsheet storage of freeway mainline geometry data. .................... 30

Table 5. Geometric data for CORSIM...................................................................................... 31

Table 6. Demand data for CORSIM......................................................................................... 32

Table 7. Example problem: heavy truck and fleet composition data. ................................ 44

Table 8. Sample node numbering scheme.............................................................................. 61

Table 9. Example problem: geometric inputs with incorrect coding. .............................. 109

Table 10. Example problem: southbound HWY 100 at TH 7 westbound exit volumes. 109

Table 11. Wisconsin DOT freeway model calibration targets.(14)...................................... 123

Table 12. Example adjustment of the car-following sensitivity factor. ............................ 129

Table 13. Example problem: model adjustments for calibrating capacity....................... 142

Table 14. Example problem: NB HWY 100 AM peak traffic volumes. ............................ 144

Table 15. Example problem: final system performance calibration values for NB HWY 

100............................................................................................................................. 146

Table 16. Example nearest neighbor calculation with multiple MOEs. ........................... 167

Table 17. Sample MOE summary table................................................................................. 169

Table 18. Example problem: HWY 100/Minnetonka Blvd. interchange operations in 

2031 .......................................................................................................................... 176

Table 19. Example problem: northbound HWY 100 freeway operations in 2031. ......... 177

Table 20. Default CORSIM vehicle specifications. .............................................................. 191

Table 21. CORSIM freeway modeling capabilities.............................................................. 196

Table 22. CORSIM surface street modeling capabilities..................................................... 197

Table 23. Bus route MOEs....................................................................................................... 247

Table 24. Bus station MOEs. ................................................................................................... 247

Table 25. Data station MOEs. ................................................................................................. 248

Table 26. Data station histogram MOEs. .............................................................................. 248

Table 27. Freeway detector MOEs. ........................................................................................ 249

Table 28. Surface street detector MOEs. ............................................................................... 249

Table 29. Entry link MOEs...................................................................................................... 250

Table 30. Link fleet MOEs....................................................................................................... 250

Table 31. Freeway lane MOEs. ............................................................................................... 251

Table 32. Freeway HOV lane MOEs...................................................................................... 252
xv 

Table 33. Surface street lane MOEs. ...................................................................................... 253

Table 34. Freeway link MOEs................................................................................................. 254

Table 35. Surface street link MOEs........................................................................................ 257

Table 36. Network-wide MOEs.............................................................................................. 267

Table 37. Freeway network MOEs......................................................................................... 268

Table 38. Surface street network MOEs. ............................................................................... 269

Table 39. Section MOEs........................................................................................................... 271

Table 40. Link vehicle type MOEs. ........................................................................................ 272

Table 41. Freeway network vehicle type MOEs. ................................................................. 273

Table 42. Surface street network vehicle type MOEs.......................................................... 274

Table 43. Conflict data MOEs................................................................................................. 274

Table 44. Permissive periods. ................................................................................................. 291

1 

Introduction 

Traffic microsimulation software has become increasingly popular as a traffic analysis tool 

used in transportation analyses. One reason for this increase is the need to model and 

analyze the operation of complex transportation systems under congested conditions. 

Much of the current transportation investment program is trying to improve traffic 

operations on congested freeways and arterials and microsimulation is becoming the 

analysis tool of choice to understand and evaluate improvements. Where some analytical 

techniques break down under these types of conditions, microsimulation has the potential 

to successfully model these complex scenarios. Another reason for the increase in 

popularity of microsimulation is the increased availability of personal computers capable 

of performing a large number of calculations very quickly. However, despite the 

widespread use of traffic microsimulation software, there are a variety of conflicting 

thoughts and practices on when microsimulation should be used and how it should be 

applied. This document is designed to provide guidelines on how to consistently use the 

CORridor SIMulation (CORSIM) simulation model to perform a traffic analysis, and it was 

developed in consultation with the software developer. 

Overview of FHWA Traffic Analysis Toolbox 

Traffic Analysis Tools is a collective term used to describe a variety of software-based 

analytical procedures and methodologies that support different aspects of traffic and 

transportation analyses. Traffic analysis tools include methodologies such as sketchplanning, travel demand modeling, traffic signal optimization, and traffic simulation. The 

purpose of the FHWA Traffic Analysis Toolbox is to provide guidance, recommendations, 

and examples on the selection and use of traffic analysis tools. The volumes in the toolbox 

are described below. 

• Volume I: Traffic Analysis Tools Primer. The purpose of this volume is to give the 

reader an overview of the different types of traffic analysis tools and to describe their 

role in transportation analyses. 

• Volume II: Decision Support Methodology for Selecting Traffic Analysis Tools. The 

purpose of this volume is to provide an overview of the role of traffic analysis tools in 

transportation studies and to present a detailed methodology for selecting the 

appropriate tool for the current analysis. 

• Volume III: Guidelines for Applying Traffic Microsimulation Modeling Software. 

The purpose of this volume is to provide a recommended process for using traffic 

microsimulation software in transportation analyses. Volume III is generic, in that it is 

independent of the specific software tool used in the analysis. 

• Volume IV: Guidelines for Applying CORSIM Microsimulation Modeling Software 

(this document). The purpose of this volume is to provide a recommended process for 
2 

using CORSIM traffic simulation software in transportation analysis. These guidelines 

follow the process outlined in Volume III using CORSIM as the microsimulation tool. 

• Volume V: Traffic Analysis Tools Case Studies. The purpose of this volume is to 

provide real-world examples of the application of traffic analysis tools to show what 

can be achieved when the analysis methods described in the Traffic Analysis Toolbox are 

correctly applied. Altogether, these case studies show how different types of tools 

have been effectively applied to the wide range of problems that confront every 

community and agency. 

These volumes can be downloaded at the FHWA Traffic Analysis Tools web site at: 

http://ops.fhwa.dot.gov/trafficanalysistools/index.htm

Purpose and Objectives of this Document 

CORSIM is the core simulation and modeling component of the Traffic Software 

Integrated System (TSIS) tool suite. The guidelines herein provide the reader with a sevenstep process that begins with project scope and ends with the final project report. Volume 

IV is specific to using CORSIM and TSIS and is based on TSIS/CORSIM Version 6.0, 

released in 2006. The purpose of this document is to assist the transportation community 

in creating an appropriate, consistent, and repeatable process for applying CORSIM traffic 

simulation software to transportation project analyses. 

This document is to be used in conjunction with the other volumes in the FHWA Traffic 

Analysis Toolbox. CORSIM and its user environment, TSIS, should not be used unless 

justified by the analysis outlined in Volumes I and II. 

Specific objectives of this document are to explain and provide guidance on: 

• How to define and scope a CORSIM analysis. 

• What data to collect, and when and how to collect the data. 

• How to consistently build a CORSIM network. 

• How to calibrate a CORSIM model. 

• How to conduct an alternative analysis in CORSIM. 

• What and how to report the results of a CORSIM analysis. 

• How to apply the strengths and overcome the weaknesses of CORSIM. 
3 

This document is not intended to explain the 

mechanics of how to code each parameter in 

CORSIM; rather, the intention is to explain to a 

user who already understands the basics of 

CORSIM how to apply CORSIM to a 

transportation analysis in an appropriate, 

consistent, and repeatable process. 

Target Audience for this Document 

This document is a resource guide targeted at practitioners, managers, and researchers 

involved in the transportation analysis process. Each of these target audiences has a 

different role to play in the analysis process so the use and application of this document 

will differ between each of these audiences. The following discussion demonstrates how 

these target audiences could use this document. 

Practitioners/analysts: In most instances, practitioners will not need to read the entire 

document at the start of each new traffic analysis, but can simply refer to those sections 

containing information relevant to their assignments. Chapter 1 should be reviewed so 

that analysts understand their role in the development of the project scope and how their 

analysis affects the overall project objectives. Chapters 2 through 5 should be used as a 

reference guide and consulted as needed when developing the model. Chapter 5 is 

particularly important and may offer some crucial guidance on how the model should be 

calibrated to represent real-world conditions. Chapters 6 and 7 should be reviewed by 

practitioners to obtain guidance on interpretation and presentation of results and on 

preparing the final documentation for the project. The Appendices can be a great 

advantage to the practitioner providing a wealth of information that should be consulted 

as needed.

Decision makers/managers: Decision makers will find this document useful in 

understanding the overall microsimulation process. A review of the Introduction will 

provide a high-level understanding of CORSIM and the other tools in the Traffic Analysis 

Toolbox. Chapter 1 will be useful to decision makers in obtaining an understanding of the 

project scoping process. Decision makers and managers should use Chapter 1 to ensure 

the project scope are adequately developed and agreed upon by all parties involved in the 

analysis and review process before commencing the project analysis. Chapters 6 should be 

reviewed for guidance on the management of the alternatives and the interpretation of 

results and recommendations. Finally, Chapter 7 should be consulted for guidance on the 

documentation required to present the material in a manner that provides sufficient detail 

to aid in the decision making process. 

Researchers: Researchers will find the material beneficial for providing overview 

information in areas such as Run-Time Extensions, documentation of CORSIM theory and 

logic using TSIS/CORSIM to perform a sensitivity study, or any attempts at novel or 

complex applications. Chapters 2 through 6 should be used as a reference guide and 

consulted as needed when developing a CORSIM model. The appendices will also be of 

The intention of this document is to 

explain to a user who already 

understands the basics of CORSIM 

how to apply it to a transportation 

analysis in an appropriate, 

consistent, and repeatable process. 
4 

great benefit to researchers because of the detail provided on CORSIM theory and complex 

applications that will benefit the more advanced user. 

By making use of this document, it is envisioned that the reader will gain insight into 

enhancing the reliability and credibility for future traffic analysis. Table 1 provides a quick 

reference to the chapters that would be most applicable for each staff category. Then the 

remainder of the document can be used as a resource guide, which can be consulted as 

needed. 

Table 1. Professional staff and suggested chapters. 

Professional Staff Suggested Chapters and/or Sections 

in this Document 

Practitioners, Analysts Chapters 1-7 and Appendices 

Managers Introduction, Chapters 1, 6, 7 

Researchers Chapters 2-6 and Appendices 

CORSIM Overview 

CORSIM has a long history reaching back to the 1970’s and mainframe computers. Many 

fixes, improvements, and enhancements have been made since the original coding but the 

basic theory of CORSIM still retains its roots. In 1994, two separate software programs, 

one for modeling surface streets (NETSIM) and one for modeling freeways (FRESIM), were 

combined to form the CORSIM program. In a corridor simulation with both surface streets 

and freeways, each type of facility is referred to as a subnetwork.(1)

CORSIM applies time step simulation to model traffic operations. CORSIM is a 

microscopic simulation model, implying that it models individual vehicle movements 

based on car-following and lane-changing theories on a second-by-second basis for the 

purpose of assessing the traffic performance of highway and street systems. 

CORSIM is a stochastic simulation model, which means that it incorporates random 

processes to model complex driver, vehicle, and traffic system behaviors and interactions. 

Stochastic simulation models produce output that is itself random. Because the output of a 

stochastic model is random, each run of a stochastic simulation model produces only 

estimates of a model’s true characteristics for a particular set of input parameters. Thus, 

relying on the measures of effectiveness (MOEs) generated from a single run of CORSIM 

may be misleading. To produce meaningful MOEs, several independent runs of the model 

will be required for each set of input parameters to be studied. A more in-depth 

discussion of CORSIM theory is provided in appendix A. 
5 

CORSIM Model Development and Application Process 

Ideally, two studies with the same inputs and implemented by different analysts should 

produce nearly identical conclusions. However, this is not often the case because analysts 

have varying levels of experience and use different approaches for applying a model (i.e., 

they may calibrate the model differently). This document presents a consistent and 

comprehensive process for applying TSIS/CORSIM to a traffic analysis study so that the 

analysis can be consistent, traceable, and repeatable. By using the process outlined in this 

document, future modelers will benefit from the past experiences of others. 

The overall process for developing and applying a TSIS/CORSIM model to a specific 

traffic analysis problem consists of seven major tasks. A flow chart capturing this overall 

process is presented in Figure 1. The process as described here may be useful for a 

procurer in composing a Scope of Work before beginning a microsimulation analysis. 

Each task is described in more detail in subsequent chapters. 
6 

Figure 1. Flowchart. CORSIM model development and application process. 
7 

Organization of this Document 

This document is organized into the following chapters and appendices: 

• Introduction (this chapter) highlights the key guiding principles of CORSIM and 

provides an overview of this document. 

• Chapter 1 addresses the management, scope, and organization of CORSIM analyses. 

• Chapter 2 discusses the steps necessary to collect, prepare, and calibrate input data for 

use in CORSIM models. 

• Chapter 3 discusses the coding of input data into the CORSIM models. 

• Chapter 4 presents methods for error-checking the CORSIM models. 

• Chapter 5 provides guidance on the calibration of CORSIM models to study area traffic 

conditions. 

• Chapter 6 explains how to use CORSIM models for alternatives analysis. 

• Chapter 7 provides guidance on the documentation of CORSIM model analysis. 

• Appendix A provides an introduction to the fundamentals of CORSIM model theory. 

• Appendix B provides an overview of CORISM capabilities and limitations. 

• Appendix C provides guidance on the initialization period. 

• Appendix D provides guidance on the generation and usage of random numbers in 

CORSIM. 

• Appendix E provides guidance on the vehicle entry headway generation in CORSIM. 

• Appendix F provides a discussion of actuated signal control in CORSIM. 

• Appendix G provides a coded input data checklist to be used during the error 

checking process. 

• Appendix H provides guidance on understanding CORSIM output. 

• Appendix I answers Frequently Asked Questions about CORSIM and other TSIS tools. 

• Appendix J provides guidance on converting between systems of actuated control 

parameters. 

• Appendix K provides guidance on coding techniques for complex situations. 
8 

• Appendix L provides guidance on the run-time extension. 

• Appendix M provides guidance on the CORSIM path-following capability. 

• Appendix N provides guidance on the CORSIM emergency vehicle capability. 

• Appendix O provides guidance on CORSIM file name conventions (i.e., file 

extensions). 
9 

1.0 Define the CORSIM Study 

CORSIM simulation can provide a wealth of 

information; however, it can also be a very 

time-consuming and resource-intensive 

effort. It is critical that the manager 

effectively coordinate the effort to ensure a 

cost-effective outcome to the study. An 

effective management plan defines the 

objectives, scope, approach, tools, resources, 

and time schedule for the study. This 

chapter presents the key components of an 

overall management plan for achieving a 

cost-effective CORSIM simulation analysis. 

1.1 Study Purpose and Objectives 

The purpose of the project analysis can be 

described as the overall view of the project 

summarized in one or two sentences. The 

purpose should quickly convey who, what, where, when, and why a study is being 

conducted. For example, “IDOT is conducting a traffic alternatives analysis of the I-35 

corridor in Des Moines from the Main Street interchange to the State Street interchange 

over the next six months to optimize vehicle/passenger throughput, minimize queues at 

and adjacent to the interchange ramps, and minimize travel time through the corridor.” 

The study purpose should be agreed to by all study participants and decision makers. 

Once the purpose is established, multiple objectives can be determined, which flow out of 

and support the purpose. Before embarking on any major analytical effort, it is wise to 

assess exactly what it is the analyst, manager, and decision makers hope to accomplish. 

Study objectives should answer the following 

questions in detail: 

• Why is the analysis needed? 

• What questions should the analysis answer? 

• What alternatives will be analyzed? 

• What are the performance requirements? (For example; minimize commute 

congestion, minimize queue on ramps, provide for stable flow on mainline, maximize 

progression, minimize intersection delay, provide reliable commute, etc.) 

• Who are the intended recipients/decision makers for the results? 

W orking M odel

Before Calibration W orking Model

Before Calibration

4

7

Error Checking

1

Define the Project

- Define project purpose

- Identify influence areas

-Select approach

-Select model

-Estimate staff time 

1 -

-

-

-

-

2 Data Collection

-Traffic vo lum es

-Base m aps/in ventory

-Field observations

2 -

-

3

Base M odel Development

Input data

D evelop quality assurance 

3 -

-

- Review Inputs

- Review A nim ation 

See Chapter 1

See Chapter 2

See Chapter 3

See Chapter 4

W ork prior to

actual modeling

Initial modeling

Yes

C alibrated Model

5

-Volum es & Speeds m atch?

- Congestion in right places?

Compare Model

5 MOEs to Field Data 

-

-

See Chapter 5

Calibration

-Key Results

- Technical Docum entation 

6 -Forecast Demand

-Base Case

-Project Alternatives

Alternatives Analysis

-M odify G lobal P aram eters

-M odify Link Param eters

-M odify R oute C hoice Param eters

Adjust M odel Parameters

-

-

Final Report

Acceptable

Match?

N o

See Chapter 6

See Chapter 7

Model

Application

It is critical that the manager 

effectively coordinate the effort to 

ensure a cost-effective outcome to the 

study. 
10 

Try to avoid broad, all-encompassing study objectives. They are difficult to achieve with 

the limited resources normally available, and they do not help focus the analysis on the 

top-priority needs. Provide as much detail to the project objectives as can be agreed upon 

by all stakeholders involved in the project. An example of specific objectives relating to 

performance requirements could state that the selected alternative should: 

• Provide for minimum average freeway speeds of 75 kilometers/hour (km/h) (47 

miles/hour (mi/h)) throughout the peak period between Points A and B. 

• Provide for ramp operations which do not generate queues or spillback which impact 

operations on the freeway or major crossroad. 

• Arterial operations within 4.0 km (2.5 mi) of freeway interchanges maintain an average 

speed of 55 km/h (34 mi/h) and arterial intersections do not result in phase failure or 

queue spillback into adjacent intersections. 

Determining these objectives could be established with an understanding of existing 

conditions and preliminary assessments of future no-build conditions. When establishing 

these objectives, the analyst should be aware that looking up Highway Capacity Manual 

(HCM) (3) levels of service using MOEs produced by a different analytical method 

(including CORSIM) is not appropriate, and is prone to bias and error. Additional 

information regarding this is contained in the Traffic Analysis Toolbox Volume 6 

(Definition, Interpretation, and Calculation of Traffic Analysis Tools MOEs). 

Besides stating specific projects objectives, a great deal of study resources can be saved if 

the manager and the analyst can identify upfront what WILL NOT be achieved by the 

analysis. The objectives for the analysis should 

be realistic, recognizing the resources and time 

that may be available for their achievement. 

Identifying the study objectives also reduces 

scope creep where more and more objectives are added to the study as it progresses. This 

can get very expensive if not controlled from the beginning. 

1.2 Study Scope 

Once the study objectives have been identified, the next step is to identify the scope, or 

breadth, of the analysis. Several questions related to the required scope of the analysis 

should be answered at this time: 

• What are the characteristics of the project being analyzed? How large and complex is 

it? 

• What are the alternatives to be analyzed? How many of them are there? How large 

and complex are they? 

It can be just as useful to identify 

what WILL NOT be analyzed as it is 

to identify what WILL be analyzed. 
11 

• How will the alternatives change the flow patterns (e.g., inserting a freeway 

interchange between two existing interchanges will alter the turning percentages at 

existing interchanges)? This should be considered at the onset of the project. 

• What measures of effectiveness (MOEs) or set of MOEs will be required to evaluate the 

alternatives and how can they be measured in the field? 

• What resources are available for the analysis? How many analysts can be used? How 

much time is available to conduct the study? Are there any externally defined project 

milestones such as a presentation to decision makers? 

• How is congestion defined in the context of this study? 

• What are the probable geographic and temporal scopes of the impact of the project and 

its alternatives (now and in the future)? How far and for how many hours does the 

congestion extend? The geographic and temporal boundaries selected for the analysis 

should encompass all of the expected congestion to provide a valid and consistent 

basis for comparing alternatives. 

• What is the appropriate design year for evaluating alternatives? 

• Will a sensitivity analysis be incorporated into the study to provide insights to the 

effects of minor and modest changes in the travel demand forecasts and assumptions? 

• Will the impact of different alternatives be very similar or very different from each 

other? How disaggregate an analysis is required? Is the analysis likely to produce a 

set of alternatives where the decision makers must choose between varying levels of 

congestion (as opposed to a situation where one or more alternatives eliminate 

congestion, while others do not)? 

• What type of information should be provided to the decision makers, and how will 

that information be conveyed? 

• What degree of precision do the decision makers require? Is a ten percent error 

tolerable? Are hourly averages satisfactory? 

• Will the presentation of benefits and impacts, based on a geographic or multi-hour 

time period provide a new perspective or insight to the decision making process? 

How to best develop the logical terminus of an improvement project has been debated 

since the early days of microsimulation; in the end, it is a matter of balancing study 

objectives and study resources. Therefore, the modeler needs to understand the operation 

of the improvement project to develop logical termini. The study termini will be 

dependent on the “zone of influence,” and the project manager will probably make that 

determination in consultation with the project stakeholders. Once that has been 

completed, the modeler then needs to look at the operation of the proposed facility. When 

determining the zone of influence, the modeler needs to understand the operational 
12 

characteristics of the facility in the proposed project. This could be one intersection 

beyond the project terminus at one end of the project or a major generator 3.2 km (2 mi) 

away from the other end of the project. Therefore, there is no specific geographical 

guidance that can be given. However, some general guidelines can be summarized in the 

following text. 

1.2.1 Freeway Projects 

The geographical scope of a freeway project must take into account significant sources of 

traffic upstream and bottlenecks downstream of the project area. At the very least, a two 

lane facility should extend up to 2.4 km (1.5 mi) from both termini of the improvement or 

study area being evaluated and up to 1.6 km (1 mi) on either side of the freeway. This will 

allow for sufficient temporal and spatial scope for CORSIM to better represent the trafficstream characteristics reflected in the real-world through the study area. 

Levels of congestion and number of lanes may also require the distances upstream and 

downstream to be extended. In heavily congested areas, CORSIM requires more distance 

to establish the traffic stream. CORSIM also does not preposition vehicles on the entry link 

based on downstream turn movements. The vehicles must have enough time and distance 

to make the required lane changes to position themselves for the upcoming turn 

movement. 

In addition, CORSIM has inputs for freeway entry lane distribution percentages. This 

allows the analyst to model the lane volume distribution due to an on-ramp just upstream 

of the project boundaries. Even though a higher percentage of vehicles are placed in the 

right lanes of an entry point they may not exit at the next right side exit ramp. 

1.2.2 Arterial Projects 

The arterial portion of a model network should extend at least one intersection beyond 

those within the boundaries of the improvement or study area. The network may need to 

be expanded depending on the interaction due to adjacent intersections or corridors. The 

network should be sized to capture influences such as the upstream metering of traffic due 

to traffic signals and the downstream queuing of traffic. 

The analyst should consider the potential impact on arterial coordination as warranted. 

Signal timing studies may need to be expanded to include other signalized intersections 

that produce platooned arrivals at the arterial being studied. 

1.2.3 Combined Network Project (Corridor) 

One of CORSIM’s strengths is the ability to model the operation of a corridor network. To 

gain the most benefit from CORSIM when analyzing corridor type networks, the analyst 

should include elements of both surface streets and freeways. 

The network should be sized to capture influences such as the upstream metering of traffic 

and the downstream queuing of traffic. Modeling a freeway off-ramp without the traffic 

signal at the interchange will not represent a queue that may be generated by that signal. 
13 

Likewise, modeling a freeway on-ramp without the traffic signal at the interchange will 

not represent platooned arrivals onto the freeway that are generated by that traffic signal. 

1.2.4 Temporal Scope 

The length of the modeling period relates to the location of the project and the type of 

congestion that is experienced. Congestion levels can often extend beyond a one-hour 

peak. The modeling period should be long enough to capture the build-up of congestion, 

the entire length of the congestion, and the dissipation of the congestion. This could take 

two to three hours or more in heavily congested areas. Within the longer time periods, 

traffic flow rates should be adjusted every 15 minutes to reflect the dynamic nature of 

traffic flow, such as the build up to congestion and the recovery afterwards. In rural areas, 

peak traffic conditions could be less than one hour; in these cases, a single peak hour may 

be modeled.(2) 

An example of selecting a peak period for analysis based on traffic volumes and average 

speeds, as well as differentiating between the peak hour and peak period, is shown 

graphically in Figure 2. 

Northbound HWY 100 North of TH 7

0

1000

2000

3000

4000

5000

6000

5:306:006:307:007:308:008:309:009:30

Time (a.m.)

Traffic Volume (veh/h)

0

10

20

30

40

50

60

70

80

Average Speed (mi/h)

Volume Speed

Peak 

Period

Peak 

Hour

Figure 2. Chart. Selecting a peak period for analysis. 

The time frame for the build-up of volume should be chosen carefully. Very large 

networks may have significant travel time from the entry points to the exit points. If the 

initialization process (discussed in appendix C) is not taken into account properly, the 

internal roadways of a large network may have more or less congestion than is 

experienced in the real-world. For a very large network, the model may have to be started 

prior to the real-world peak period (by about the time it takes to travel the longest path 

through the network) to allow the initialization period to fill the network accurately. 
14 

1.2.5 Design Year 

Traditionally, the design year is a 20 year horizon from the anticipated opening date of the 

project. In addition to analyzing the existing and design year, interim years may need to 

be considered, resulting from phased construction, changes in land use, or other projects 

within the area of influence. Selecting an appropriate design year and interim analysis 

horizons should be done upfront in the project scoping step with the consensus of all 

stakeholders involved, as the design year may affect the analytical approach and tool 

selected for the traffic analysis as discussed in the next two sections. 

1.3 Analytical Approach Selection 

FHWA Traffic Analysis Toolbox, Volume II: Decision Support Methodology for Selecting Traffic 

Analysis Tools (a separate document) provides detailed guidance on the selection of an 

appropriate analytical approach. That document should be consulted to determine if a 

microsimulation analysis tool is warranted. This section provides a brief summary of the 

key points. 

The following are several situations where microsimulation is the most appropriate 

technical approach for performing a traffic analysis: 

• Conditions violate the basic assumptions of the other available analytical tools. 

• Conditions are not covered by the other available analytical tools. 

• There is testing of vehicle performance, guidance, and driver behavior modification 

options. 

For example, most of the Highway Capacity Manual (HCM) (3) procedures assume that the 

operation of one intersection or road segment is not adversely affected by conditions on 

the adjacent roadway. Long queues from one location interfering with another location 

would violate this assumption. Simulation may be a more appropriate analytical tool for 

this situation. Simulation can model the effects of one surface street intersection on other 

nearby intersections, it can model the effects of one freeway on-ramp on other nearby 

ramps, and it can model the effects of a surface street intersection on a freeway segment. 

This is however not to suggest that the HCM not be used. Rather, it may be prudent for 

the analyst to apply multiple tools to support an analysis. 

Because it is sensitive to different vehicle performance characteristics and differing driver 

behavior characteristics, CORSIM is capable of testing intelligent transportation system 

(ITS) strategies designed to improve traffic congestion. The HCM procedures, for 

example, are not designed to be sensitive to new technology options, while CORSIM can 

predict the effect of new technology on capacity before the new technology is actually in 

place. 
15 

1.4 Analytical Tool Selection (Software) 

Although this document is dedicated to the use of CORSIM to perform an analysis, 

CORSIM is not the most appropriate tool for all analyses. When analysts become 

comfortable with the application of CORSIM to projects, they may be tempted to apply 

CORSIM to all projects. Each project is different and the most appropriate tool must be 

selected based on the project itself. 

The selection of the appropriate analytical tool is a key part of the study scope and is tied 

into the selection of the analytical approach. Generally, it is a good idea to separate the 

selection of the appropriate analytical tool from the actual implementation of the tool. 

This can be accomplished through a selection process that is independent from any 

project-level analytical activities. The FHWA Traffic Analysis Toolbox, Volume II: Decision 

Support Methodology for Selecting Traffic Analysis Tools, identifies several criteria that should 

be considered in the selection of an appropriate traffic analysis tool and helps identify the 

circumstances when a particular type of tool should be used. Some of the key criteria for 

software selection are technical capabilities and limitations, input/output/interfaces, user 

training/support, and ongoing software enhancements. A brief discussion of each of these 

criteria in relation to CORSIM is given in the remainder of the section. 

CORSIM has many capabilities and limitations that the analyst must be familiar with 

before selecting it for the project. The following sections describe these capabilities and 

limitations. 

1.4.1 CORSIM Capabilities and Limitations 

CORSIM can model many elements of modern traffic systems explicitly. Many of the 

other features can be approximated using the basic elements of CORSIM, along with 

engineering judgment. There may be other tools that are better suited for a given 

situation. The analyst should consider the tool that is most appropriate for the analysis. 

This section is to be used to decide if CORSIM is the appropriate tool. The authors do not 

want to promote the use of CORSIM for situations in which they know there are other 

tools that may be better suited for the situation. Appendix B has a detailed discussion of 

CORSIM’s capabilities and limitations. 

1.4.2 TSIS Input/Output/Interface Support Tools 

The process of selecting an analytical tool must take the supporting tools into account. 

Using CORSIM by itself is not something that is easily done. However, CORSIM is 

supported by many tools that have been developed over many years to make the task 

easier. The TSIS package has many tools that make building networks, running CORSIM, 

collecting data, and animating the output of CORSIM relatively simple. 

These tools can be classified into a graphical user interface and three different types of 

tools. Tools that directly run CORSIM are called Process tools. Tools that allow creating 

and editing inputs to CORSIM are called Input tools. Tools that allow the user to view the 

information produced by CORSIM are called Output tools. The following paragraphs give 
16 

a brief overview of the TSIS support tools. More details can be found in the individual tool 

user’s guides provided with the TSIS package. 

TShell: TSIS is, by design, an integrated set of traffic analysis tools. To provide this 

integrated environment, TSIS is implemented using container/component architecture. In 

this architecture, TShell serves as the container, while the tools are its components. 

Because of its centralized role in this architecture and because it provides the primary user 

interface for TSIS, TShell is often referred to as TSIS. In reality, TSIS is a collection that 

includes all of its constituent tools and TShell. The TShell program encapsulates all these 

different types of tools into one user interface. Although TShell makes these tools easier to 

use, the important work in TSIS is actually performed by the tools. 

The TShell User’s Guide(4) concentrates on describing the user interface concepts of TShell. 

It focuses on describing the features of TShell that enable you to apply those tools 

effectively and to maintain the TSIS tool configuration. Furthermore, it illustrates how to 

use TShell to manage your traffic analysis projects. For more information please refer to 

the TSIS and TShell User’s Guides. (4,5)

Process Tools: The process tools that allow execution of CORSIM include the CORSIM 

Driver, which provides a Windows interface into CORSIM, the CORSIM Server, which 

allows CORSIM to run in its own memory space so multiple instances of CORSIM can be 

running at the same time, and the Script Tool that allows the analyst or researcher to write 

scripts to do repetitive work. 

Input Tools: The input tools that allow creating and modifying CORSIM input files 

include TRAFED, which provides a graphical way to input data, the Text Editor, which 

allows editing the TRF file and provides some user reference for data fields, and the 

Translator which imports and exports between TRAFED files and TRF files. 

Output/Reviewer Tools: The output/reviewer tools inherent to TSIS include the OUT file 

and the CSV file generated by CORSIM that provide tables of data collected during a run 

of CORSIM; TRAFVU, which animates vehicles, signals, and MOEs generated by CORSIM; 

and the Output Processor, which collects and collates selected data for selected links, 

detectors, and other network objects over multiple runs of the simulation and stores this 

data in selected formats. 

Interfaces: CORSIM has many built in interfaces that allow the analyst or researcher to get 

information from CORSIM, set data in CORSIM, or operate CORSIM. These interfaces are 

described in the Script Tool User’s Guide.(6) 

1.4.3 Third Party Products 

There are third party products that have been developed over the long life of CORSIM to 

perform special functions. There are many tools and the list changes frequently so they are 

not listed here. If the tools built into TSIS do not suit your needs, it may be worthwhile 

researching other tools. A good resource to consider is the McTrans Center. Their web site 

can be found at http://mctrans.ce.ufl.edu. 
17 

1.4.4 User Training/Support 

There are organizations that provide traffic simulation training specific to CORSIM. The 

National Highway Institute (NHI) has an Introduction to CORSIM training course that 

provides hands-on training on basic CORSIM concepts. The McTrans Center also teaches 

a CORSIM course. For more information on these and other training opportunities please 

refer to the specific organization. The NHI web site can be found at 

http://www.nhi.fhwa.dot.gov/ and the McTrans Center web site is provided above. 

1.4.5 Ongoing Software Enhancements 

TSIS and CORSIM are continually being updated and enhanced. Refer to the McTrans 

Center website listed above for information on the latest release version and software 

enhancements. 

1.5 Resource Requirements 

Any traffic analysis requires resources. These resources include people, time, and 

computer resources. Large analysis projects require extensive computer resources 

including disk space, central processing unit (CPU) time, and memory. 

When simulating the base network and all the alternatives multiple times each to capture 

the stochastic nature of the model, hundreds of megabytes of disk space may be required. 

Small to medium projects will require substantially less disk space. Reducing the number 

of files that are generated during a run or multi-run of CORSIM will reduce the amount of 

required data storage and reduce the computer processing time. For example, it is 

recommended that animation files not be generated when performing multiple runs for 

statistics generation. 

CORSIM uses many CPU cycles to perform each second of simulation. Although CORSIM 

is extremely fast at processing the model, the time required is significant. This is 

dependent on the number of links, signals, and vehicles in the network. The faster the 

computer processor, the quicker CORSIM executes. When running the model numerous 

times, the processing time becomes a substantial resource to manage. 

1.5.1 Other Resources 

The resource requirements for the development, calibration, and application of CORSIM 

will vary according to the complexity of the project, its geographic scope, temporal scope, 

number of alternatives, and the availability and quality of the data. 

In terms of training, the person responsible for the initial round of coding can be a 

beginner or an intermediate level person in terms of knowledge of the software. They 

should have supervision from an individual with more experience with the software. 

Error checking and calibration are best done by a person with advanced knowledge of 

microsimulation software and the underlying algorithms. Model documentation and 
18 

public presentations can be done by a person with an intermediate level of knowledge of 

microsimulation software. 

A prototype time schedule for the various model development, calibration, and 

application tasks is presented in Figure 3, which shows the sequential nature of the tasks 

and their relative durations. Data collection, coding, error checking, and calibration are 

the critical tasks for completing a calibrated model. The alternatives analysis cannot be 

started until the calibrated model has been reviewed and accepted. 

Figure 3. Chart. Prototypical CORSIM analysis task sequence. (7)

1.6 Management of a CORSIM Study 

The process outlined in this document has a sequential nature. Most of the tasks cannot be 

started until the previous task has finished; although efficiencies may be gained as 

practitioners employ a methodology which promotes a systematic process. Error checking 

is the one task that can be done in parallel with the base model development. However, 

the final error checking must be done after the base model is completely finished. 

To ensure the success of the project, strict management of the project must be maintained. 

It is very easy to continue to make improvements to the model well beyond the criteria 

outlined in the scope of work. It is also quite easy to continue calibration in an attempt to 

make the model “perfect” well after the comparison goals have been met. Use 

checkpoints, milestones, and reviews to ensure the time schedule is maintained. Example 

milestones and deliverables for a CORSIM study are shown in Table 2. 

Task

1. Define the Project 

2. Data Collection 

3. Develop Base Model 

4. Error Checking 

5. Calibration 

6. Alternatives Analysis 

7. Final Report

Project Schedule 
19 

Table 2. Example milestones and deliverables for a CORSIM study.(7)

Milestone Deliverable Contents 

1. Study Scope 1. Study scope and schedule 

2. Proposed data collection plan 

3. Proposed calibration plan 

4. Coding quality assurance 

plan 

Study objectives, geographic 

and temporal scope, 

alternatives, data collection 

plan, coding error-checking 

procedures, calibration plan and 

targets 

2. Data Collection 5. Data collection results report Data collection procedures, 

quality assurance, summary of 

results 

3. Model Development 6. 50% coded model Software input files 

4. Error checking 7. 100% coded model Software input files 

5. Calibration 8. Calibration test results report Calibration procedures, adjusted 

parameters and rationale, 

achievement of calibration 

targets 

6. Alternatives 

Analysis 

9. Alternatives analysis report Description of alternatives, 

analytical procedures, results 

7. Final Report 10. Final Report Summary tables and graphics 

highlighting key results 

 11. Technical documentation Compilation of prior reports 

documenting model 

development and calibration, 

software input files 

Different tasks and subtasks can be assigned to different people. The division of labor and 

the division of tasks can greatly reduce the time required to complete a project but, it 

simultaneously increases the control required. An experienced CORSIM user should 

define the project. A beginning CORSIM user can be involved in many subtasks. An 

experienced CORSIM user should supervise the beginning user and should lead the error 

checking and calibration tasks. 

By monitoring resource usage and task completion times, the management and 

documentation of the study is much easier. These data can be used for future study 

estimation. Documenting the CORSIM modeling should be ongoing throughout a project. 

The number and type of deliverables should be scoped out at the beginning of the project. 

Intermediate technical memorandums, documentation of the model calibration, study 

reports, and interstate access requests are the types of documents that may need to be 
20 

prepared in addition to basic documentation of the study. The size and number of 

deliverables necessary is proportionate to the size of the model and project. A larger 

project may require more intermediate deliverables to facilitate the decision-making 

process, whereas a smaller project may require only a few deliverables.(2) 

One possible way to structure the final deliverables is to create two separate documents, a 

final report and a technical report. This may only be necessary for larger projects while for 

smaller projects the documentation may be provided in one report. The key is that the 

results must meet the needs of two audiences: the non-technical decision makers and the 

technical specialists responsible for technical reviews. The types of analyses and 

information that may be delivered at the conclusion of the study could include the 

following: 

• Final Report. 

o Study objectives and scope. 

o Overview of study approach (tools used, methodology, rationale). 

o Data collection (sources and methods). 

o High-level model description, diagrams, assumptions, and modifications. 

o Demand forecast assumptions (assumed growth inside and outside of the study 

area, street improvements, variations to support a sensitivity analysis, etc.) 

o Description of alternatives and modifications (improvements). 

o Discussion of success or failure of design/alternatives. 

o Results and recommendations. 

• Technical Report. 

o Input data (CADD files, diagrams, schematics, tables, demand data, traffic balance 

data, and traffic control data). 

o Model assumptions. 

o Sensitivity analysis (a targeted assessment of the reliability of the model results, 

given the uncertainty in certain input data or assumptions. Additional information 

on sensitivity analysis can be found in Chapter 6.) 

o Calibration tests and results (which parameters were modified and why). 

o Alternatives analysis. 

o MOE report on a spatial and temporal scale to show how the MOEs change 

throughout the analysis period and study area. 

o Output data (electronic files). 
EXAMPLE

21 

1.7 Example Problem: Study Scope and Purpose 

An example problem has been provided to illustrate each step in the overall process. Each 

step will be explained throughout this document under the appropriate chapters. 

The example problem presented is an evaluation of a proposed interchange modification 

to HWY 100/TH 7 Interchange and HWY 100/Minnetonka Boulevard interchanges. The 

HWY 100 project is part of an eight-mile freeway reconstruction program with a total cost 

between $100 and 200 million. The project illustrated in this example problem is a major 

part of the reconstruction program. The microsimulation modeling supports the 

reconstruction program and this particular project. To keep costs in perspective, the cost 

to prepare the modeling is considerably less than one percent of the construction cost. 

The proposed interchange projects will include provisions for widening HWY 100 to three 

lanes in each direction. Currently, the construction area maintains two lanes in each 

direction while outside of the construction area HWY 100 is three lanes in each direction. 

This project is the last phase in converting HWY 100 into a six-lane freeway. 

Study Objectives 

The primary objectives of the study are to: 

• Evaluate the proposed interchange concepts. 

o Identify operational deficiencies in the freeway system. 

o Identify operational deficiencies at the ramp terminal intersections and adjacent 

intersections in the proposed design. 

• Refine concepts and re-evaluate.

• Recommend final design of interchange areas for construction in 2014.
EXAMPLE

22 

Study Breadth (Geographic) 

The proposed reconstruction area will involve less than one mile of HWY 100 freeway; 

however, due to the operational influence of two system interchanges, the CORSIM model 

limits are shown in Figure 4 and have been expanded to include the entire HWY 100/I-394 

Systems Interchange and the HWY 100/HWY 62 systems interchange to the south. 

Figure 4. Graphic. Example problem: study map. 

The arterial operations at the Minnetonka Blvd (CR 5 on the study map) interchange area, 

including the ramp terminal intersection and intersections adjacent to the interchanges, are 

areas of concern within the construction limits and were thus included in the model. 

However, the TH 7 /Route 169 intersection was not included in the model, as it is over one 

mile away from HWY 100 and does not have a significant impact on operations at the TH 

7/HWY 100 interchange. 

Study Breadth (Temporal) 

The congestion on HWY 100 in the study area is pervasive. The peak periods of 

congestion can be determined only after the data collection phase. 
EXAMPLE

23 

The data showed that northbound HWY 100 north of the TH 7 interchange experienced 

significant congestion during the morning peak period. Figure 5 shows the a.m. peak 

period. The peak hour was found to be from 6:45 a.m. to 7:45 a.m. In order to capture this 

peak hour, a three-hour peak period is defined from 6:00 a.m. to 9:00 a.m. 

Northbound HWY 100 North of TH 7

0

1000

2000

3000

4000

5000

6000

5:306:006:307:007:308:008:309:009:30

Time (a.m.)

Traffic Volume (veh/h)

0

10

20

30

40

50

60

70

80

Average Speed (mi/h)

Volume Speed

Peak 

Period

Peak 

Hour

Figure 5. Graph. Example problem: peak period selection. 

Analytical Approach 

This project uses CORSIM to model and analyze the HWY 100 corridor from the 

interchange at HWY 62 to the interchange at I-394. It was agreed that model scenarios will 

be prepared for no-build conditions for the existing year, opening year (2010), and a 20-

year future design (2030); three different build alternatives for the 20-year future; and the 

preferred build alternative for the opening year. To achieve the project objectives, the 

work tasks listed in Table 3 will be performed. 

Analytical Tool 

The use of CORSIM microsimulation model was selected for this project because it can 

appropriately model the analytical approach requirements. Additional tools to be used in 

evaluating and developing refinements to the design will include signal timing 

optimization software for optimizing traffic signal timings. 

Resource Requirements and Schedule 

The time and resources required to complete the objectives of the project have been 

estimated. The schedule on this project was critical and all work was to be completed 
EXAMPLE

24 

within a six-month time frame. The level of effort and time schedule with key milestones 

is included for reference in Figure 6. 

Table 3. Example problem: key tasks and level of effort estimated. 

Task Number Task Description Estimated Person 

Hours 

1 Data Collection 350 hrs 

2 Base Model Development 330 hrs 

3 Calibration 340 hrs 

4 Design Year Alternatives 840 hrs 

5 Year Opening Analysis 370 hrs 

6 Final Documentation 80 hrs 

7 Project Management/meetings 80 hrs 

 Total 2,390 hrs 
EXAMPLE

25 

Figure 6. Chart. Example problem: study schedule. 

27 

2.0 Data Collection and Preparation 

Data collection is a critical step in the 

analysis process. Knowing what to collect, 

when to collect, how long to collect, where 

to collect, and how to manage the data must 

be addressed before starting the collection. 

This chapter provides guidance on the 

identification, collection, and preparation of 

the data sets needed to develop a CORSIM 

model for a specific project analysis, and the 

data needed to evaluate the calibration and 

fidelity of the model to real-world 

conditions present in the project analysis 

study area. There are agency-specific 

techniques and guidance documents that 

focus on data collection, which should be 

used to support project-specific needs. A 

selection of general guides on the collection 

of traffic data are listed on page 23 of 

Volume III.(7) These sources should be consulted regarding appropriate data collection 

methods (they are not all-inclusive on the subject of data collection). The discussion in this 

chapter focuses on data requirements, potential data sources, and the proper preparation 

of data for use in a CORSIM analysis. 

If the amount of available data does not adequately support the project objectives and 

scope identified in Chapter 1, then the project team should return to Chapter 1 and 

redefine the objectives and scope so that they will be sufficiently supported by the 

available data. 

Managing the data that is collected is critical to the success of the study. It may be 

impossible to go back to collect data that was missed or lost if conditions have changed. It 

is difficult to put confidence in data that was mishandled or its origins are not known. 

Prior to beginning data collection, ensure that a data management system is in place and 

all personnel involved in the data collection know what the process is for collecting and 

storing the data. If good management practices are in place, data will be less likely to be 

lost or corrupted. 

Sources of data, times of traffic data collection, unusual events during collection, data 

collection decisions that were made, and time spent collecting and organizing should be 

documented. By documenting the data collection while it is in progress, the final report 

becomes much easier to prepare. The documentation can also be used to build historical 

data for future analysis project estimation. 

W orking M odel

Before Calibration W orking Model

Before Calibration

4

7

Error Checking

1

Define the Project

- Define project purpose

- Identify influence areas

-Select approach

-Select m odel

-Estim ate staff tim e 

1 -

-

-

-

-

2 Data Collection

-Traffic volumes

-Base maps/inventory

-Field observations

2 -

-

3

Base Model Development

Input data

D evelop quality assurance 

3 -

-

- Review Inputs

- Review Anim ation 

See Chapter 1

See Chapter 2

See Chapter 3

See Chapter 4

W ork prior to

actual modeling

Initial modeling

Yes

Calibrated Model

5

-Volum es & Speeds m atch?

- Congestion in right places?

Compare Model

5 MOEs to Field Data 

-

-

See Chapter 5

Calibration

-Key Resu lts

- Technical D ocum entation 

6 -Forecast Demand

-Base Case

-Project A lternatives

Alternatives Analysis

-M odify G lobal Param eters

-M odify Link Param eters

-M odify Route Choice Param eters

Adjust Model Parameters

-

-

Final Report

Acceptable

Match?

N o

See Chapter 6

See Chapter 7

Model

Application
28 

Geometric, traffic demand (present and future), and signal data can be collected from 

many sources. Collecting data for a traffic analysis may involve contacting many different 

agencies to obtain the data they maintain. It is a good idea to assess what data are 

collected on an on-going basis or was collected recently for another analysis. It may be 

possible to use existing data that is collected by planning organizations or from existing 

detectors from traffic management systems. It is also a good idea to contact local agencies 

to make sure the traffic signal timings are not being updated or a large construction project 

is not scheduled to begin during the data collection period. Some sources that may be 

contacted for data required for the analysis include: 

• City or municipal street departments. 

• County roadway departments. 

• Regional council of governments. 

• Planning agencies. 

• State departments of transportation. 

In order to get current traffic data, it may be necessary to collect additional data that does 

not currently exist. Additional data collection may involve tube-counters, radar speed 

measurement devices, turn count collection devices, and other methods mentioned in this 

chapter. 

Geometric data do not vary on a daily basis. However, traffic and volume data does vary 

from day to day. By collecting data on only one day, the data will likely not reflect the 

average traffic patterns. Depending on the congestion and size of the study area, different 

sample periods should be collected. The variability in the daily traffic will determine how 

long to collect data. On lightly congested roadways it may be possible to collect only a few 

days worth of traffic data. For projects with more significant congestion, a week or more 

of data collection may be needed. 

All data should be collected during the same time frame if possible. If all the data are not 

collected over the same time frame, there may be problems resolving data inconsistencies 

or in calibrating the model. For example, collecting mainline volume data during one 

week and collecting turning data during the next week may result in turning data that are 

difficult to match with the mainline volume data. 

Data should be collected during peak or off peak periods when typical traffic conditions 

exist. Traffic data collection should be avoided during such conditions as during 

incidents, inclement weather, special events, construction, holidays and seasonal 

variations (unless these special conditions are part of the analysis purpose). 

A good storage process is critical to the success of the analysis. For easier data access and 

quality control checking, it may be easier to store data in one of a number of different ways 

including a spreadsheet, a database, XML files, or in separate text files. The important 
29 

thing is that a consistent process be adopted and used. One such process is to store data in 

a spreadsheet format, as explained in the following section. 

Spreadsheet storage: Many agencies use spreadsheets to manage geometric data and 

traffic data. TSIS and CORSIM do not have the capability to directly import data from 

these formats; however, third party products may be available that can import data from, 

and export data to, an acceptable CORSIM format. Also, the TRF Manipulator tool could 

also be used in a script or macro to change data in the TRF file based on entries in a 

spreadsheet. 

Typically, similar data are stored together on a worksheet in the spreadsheet file. For 

example, all freeway geometric data are stored together on a sheet, all surface street data 

are stored together on a sheet, all traffic demand data are stored together on a sheet, and 

all pre-timed control data are stored together on a sheet. Table 4 shows an example 

spreadsheet with freeway data.(2) The spreadsheet is a living document that is developed 

and maintained as more data are gathered. 

Videotape or photograph area for later review: Being able to refer back to a videotape or 

digital photo to see how lanes join or where signs are located is very helpful. This is 

especially true for situations where the analyst is not located near the site. Videotaping 

and digital images should be captured during the peak hour so as to depict accurate 

congestion levels and queues. 
30 

Table 4. Example spreadsheet storage of freeway mainline geometry data. 

Segment Length 

(ft) 

Number 

of Lanes 

Grade 

(%) 

Radius 

(ft) 

Posted Speed 

(mi/h) 

NB TH 100 – TH 62 EB Exit 3,550 3 0 - 65 

TH 62 EB Exit – TH 62 EB 

Entrance 

1,235 3 0 - 65 

TH 62 EB Entrance – TH 62 

WB Exit 

285 3 0 - 65 

TH 62 WB Exit – TH 62 WB 

Entrance 

1,330 3 1 - 65 

TH 62 WB Entrance – 

Benton Ave. Entrance 

1,980 3 1 - 65 

Benton Ave. Entrance – 

50th St. Exit 

3,780 3 0 7,200 65 

50th St. Exit – 50th St. EB 

Entrance 

975 3 -3 5,700 65 

50th St. EB Entrance – 50th

St. WB Entrance 

1,100 3 0 5,700 65 

50th St. WB Entrance – 

Excelsior Blvd. Exit 

4,580 3 0 5,000 65 

Note: Rows with “-“ in the radius column indicate there is no curvature for the section and thus no 

radius. 

2.1 Geometric Data 

Up-to-date maps and engineering drawings are the desired method of geometric data 

collection. However, if possible field verification of geometry should be obtained. Table 5 

provides an overview of geometric data that will be needed to develop the CORSIM 

model. Geometric data consists of the roadway layout and configuration, such as number 

of lanes, intersection locations, turn bays, and horizontal and vertical grades. Geometric 

data is typically expressed as node and link data in CORSIM. A link connects to one node 

at the upstream end and one node at the downstream end. It contains the attributes of a 

roadway where most data are consistent. The link data are normally gathered from 

engineering drawings, CAD files, site inspection, and aerial photographs of the project 

area. The data collection task for link data is to collect the drawings of the project area. 
31 

Table 5. Geometric data for CORSIM. 

Geometric Data CORSIM 

Node coordinates Required 

Link length Required 

Number of lanes Required 

Length of turn bays Required 

Lane drop locations Required 

Lane add locations Required 

Lane connection information Required 

Lane channelization Required (CORSIM provides default) 

Link free-flow speed Required (CORSIM provides default) 

Grade Optional 

Lane widths Optional 

Curvature data Optional 

Bus stop data Optional 

The mean free-flow speed is a user input for each link. Free flow speed is the average 

speed vehicles would travel if they were not affected by other vehicles or control. (1) The 

free-flow speed can be measured in the field as the mean vehicle speed during off-peak 

times when there is low traffic volume. The free-flow speed is not the same as the design 

speed, posted speed, or observed speed during the peak period. 

2.2 Demand Data 

All traffic demand data and calibration data should be collected simultaneously if 

resources permit. Otherwise, it becomes difficult to properly calibrate the CORSIM model. 

Demand data should be collected in 15-minute increments throughout the analysis period 

to capture changes over time. Table 6 provides a summary of the demand data required to 

develop the CORSIM model. 
32 

Table 6. Demand data for CORSIM. 

Demand Data CORSIM 

Entry volumes Required 

Turning movements Required (Optional if O-D data are 

provided) 

Origin-Destination (O-D) data Required (Optional if turning movement 

data are provided) 

Vehicle mix Required 

Vehicle performance Required 

As shown in the table, entry volumes (traffic entering the study area) are required by 

CORSIM. Entry volumes are collected at the edges of the network or at internal traffic 

generators (parking lots, small side streets, developments, etc.). CORSIM will accept 

values in vehicles per hour equivalents or in actual traffic counts by time period. CORSIM 

can also accept changes in the vehicle demand within a time period. 

CORSIM also requires either turning movement data or Origin-Destination (O-D) data. If 

the turning movement approach is selected, then turning movements must be collected for 

each approach at each arterial intersection and at each freeway diverge point (e.g., offramps). Turning movement data should be collected in 15-minute increments. If the 

turning movement approach is used, there are some special considerations that need to be 

addressed: 

• Weave Zones. CORSIM can be adjusted to model weave zones which can significantly 

affect traffic conditions. Data necessary to model this behavior includes: percentage of 

vehicles that enter from an approach that turn a certain direction at the next 

intersection and what percent of vehicles entering the freeway at an on-ramp exit at the 

next off-ramp. 

• Lane Usage. CORSIM can be adjusted to model turn maneuvers. Examples include 

turning from the near lane to the near lane or from the near lane to the far lane to be in 

position for the next turn downstream. 

• Vehicle Type Usage. CORSIM can alter turning movements based on vehicle type. 

Certain types of vehicles may turn in higher or lower percentages at one intersection 

than they do at other intersections. For example, a freeway vehicle weigh station may 

require all truck type vehicles, and no other vehicle types, to exit at an off-ramp. 

If the O-D data approach is selected, then a license plate matching survey is an accurate 

method for measuring existing O-D data. The analyst establishes checkpoints within and 

on the periphery of the study area and notes the license plate numbers of all vehicles 

passing by each checkpoint. A matching program is then used to determine how many 
33 

vehicles traveled between each pair of checkpoints. However, license plate surveys can be 

quite expensive. For this reason, estimating O-D data from traffic counts is a viable 

alternative. Section 2.1 of Volume III(7) contains more information and references on 

converting traffic counts to O-D data. 

If congestion is present at a count location (or upstream of it), then care should be taken to 

ensure that the count measures the true demand and not capacity-constrained volumes. 

The count period should ideally start before the onset of congestion and end after the 

dissipation of all congestion to ensure that all queued demand is eventually included in 

the count.(7) Counting the arrival volume, rather than the departure volume, at an 

intersection or specific point will reflect the true demand. However, this is often not 

possible if queues become long. Roess et al. describes a method for estimating the arrival 

volume (demand) by counting the queue length and departure volume.(8)

Data can be collected via existing detectors in an instrumented system or using tube 

counters or other methods in an un-instrumented system. Collecting data on an uninstrumented system can be expensive and time-consuming.(2) Detector data can be used 

to estimate both turning movements or O-D data. 

The vehicle characteristics, including vehicle mix and performance, can have an impact on 

the model. The study area may have a high percentage of long trucks or buses that can 

affect queues, lane changing, weaving, etc. These characteristics should be collected to 

ensure the model is a representation of the real world. Collecting this data is not easy over 

a long data collection period. Many planning agencies or state motor vehicle 

administrations maintain this type of data. The task for data collection is to obtain the 

normal daily mix of vehicles and their characteristics. 

2.3 Control Data 

Control data are generally available from the local operating agency. The type of data 

collected depends on the type of control being used. Control data includes stop and yield 

signs, traffic signal controller data, and ramp metering controller data. The following text 

discusses the data needed for each of these control types in more detail. 

For controls that stop traffic, the analyst may need to collect or estimate the start-up lost 

time and queue discharge headway to be able to calibrate the model to the observed 

operation at an intersection. These data are not considered control data, but do have a 

significant effect on the behavior of traffic at an intersection within the model. 

2.3.1 Sign Data 

The required data for signs may be obtained by direct observation of the intersections or 

freeways of interest or by using a signing plan. The sign type (e.g., stop, yield, exit signing 

and/or lane assignment for major forks) and sign location are generally all that are 

required. Sign data for all approaches to an intersection must be collected. Also, if there 

are any specific conditions that occur during the times-of-day the sign is to be observed, 

that information must be recorded as well. For example, if the signs are temporary signs, 
34 

the times-of-day and the specific traffic situation or event when the sign was observed 

should be recorded. 

2.3.2 Pre-Timed Signal Control Data 

In general, the analyst must collect/obtain the red, yellow, and green times for each 

allowed movement on each approach in the pre-timed cycle for the intersection. For leftturn movements, the analyst should record if the movement is protected or permitted, 

although this information can be deduced from the full set of timing data. The analyst 

must obtain the right-turn-on-red policy for the governing jurisdiction, and any 

intersection-specific restrictions/permissions for right-turn-on-red. If the pre-timed signal 

is part of a coordinated set of signals, its offset time must be obtained. 

If the pre-timed signal implements more than one plan during its operation, the analyst 

must then obtain the signal timing data for each plan that is implemented. Furthermore, 

the analyst must obtain the minimum main-street green time and type of plan transition 

for multiple plan implementation. 

2.3.3 Actuated Signal Control Data 

The actuated and pre-timed signal control data can usually be obtained from the traffic 

engineering division for the local jurisdiction that controls the traffic signals. The analyst 

is cautioned that different controller manufacturers may use slightly different terminology 

for the actuated control parameters, but this information can also be obtained from the 

local traffic engineer. The analyst will also need to perform a field observation of the 

traffic signal functionality to be sure the traffic signal sequence in the field matches the 

timing plan data retrieved. 

To be able to model the operation of an observed intersection under actuated control, the 

analyst must also have calibrated the approach demands and turn movement percentages 

for that intersection within the model. Thus, the analyst may need to collect volume data 

and data required to estimate the turn movement percentages (e.g., turn movement 

counts). These data are not controller parameters, but most actuated controllers are tuned 

to the demand present at the intersection. 

At an actuated controlled intersection, the analyst must collect/obtain information 

regarding the assignment of phases to the allowed movements on each approach, and 

whether split phasing or concurrent phasing is implemented. For phases that are actuated, 

the detector locations on the approach are required. In addition, the details of each phase 

must be obtained, such as minimum green time, maximum green time, yellow change 

interval time, and red clearance interval time. 

For controllers that are operating in semi-actuated, coordinated mode, the analyst must 

obtain the controller parameters that govern the coordinated operation of the controller. 

Typically, these data include the cycle length, phase split times, and offset time. If a 

coordinated controller implements more than one plan during its operation, the analyst 

must obtain the controller transition parameters from one plan to the next. 
35 

Actuated signal control operation settings can be complex to understand. Appendix F 

provides a more detailed discussion of actuated signal control logic and parameters in 

CORSIM. 

2.3.4 Pedestrian Demand Estimates 

Pedestrian demand data are not controller operational parameters, but are used by 

CORSIM to simulate the effects of pedestrians on a controller. CORSIM can model 

pedestrian demand either deterministically or stochastically. For the deterministic mode, 

the analyst must estimate the start time and arrival headway for pedestrians. For the 

stochastic mode, the analyst must estimate the pedestrian intensity in pedestrians per 

hour. 

2.3.5 Ramp Meter Control Data 

The data required for specifying ramp meter control in CORSIM depends on the type of 

ramp metering that is being modeled. In general, the analyst must obtain parameters 

regarding the metering rate (or headway) associated with a ramp meter and how the 

metering rate is determined. The metering rate is directly related to the duration of the red 

and green intervals (and optional yellow intervals) in the metering cycle. Metering rates 

should be collected at the time speed and volume data are collected. 

Ramp metering can be performed in several ways, requiring collection of additional data. 

For traffic-responsive ramp metering, demand/capacity metering, and multiple threshold 

occupancy metering, the analyst must obtain information on the location and type of 

detectors. 

The clock-time (i.e., fixed-time) ramp meter is the simplest form of ramp metering and is 

the only type in CORSIM that allows a different specification (plan) for different time 

periods. For each plan, the analyst must obtain the metering rate (veh/h) or headway 

(sec), the time metering becomes active relative to the start of the time period, and the 

number of vehicles discharged per green indication. 

ALINEA metering(9) uses the concept of a linear regulator to achieve the desired 

occupancy on the freeway by controlling the metering rate. For this type of metering, the 

analyst must obtain the following parameters, some of which are unique to the ALINEA 

metering algorithm: 

• Update interval for rate selection. 

• Initial metering rate. 

• Minimum metering rate. 

• Regulator parameter. 

• Desired occupancy. 
36 

• Time metering becomes active relative to the start of the simulation. 

2.4 Calibration Data 

Calibration data consist of measures of capacity, traffic volumes, and measures of system 

performance. The data are collected in order to compare the real world to the results of 

CORSIM. In order to compare similar data, the capacity and system performance data 

must be gathered simultaneously with the traffic counts and turning movements. For 

calibration purposes, only data that can also be measured in CORSIM should be collected. 

The calibration data are measured within the network as opposed to the demand (entry) 

data which is collected at the edges of the network. Even though CORSIM is a 

microsimulation tool, it is a simplification of the extremely complex driver behavior and 

vehicle interactions that take place in the real world. Calibrating CORSIM to the real 

world in an area of complex vehicle interaction is challenging. Therefore, the calibration 

data should be collected in areas of relatively steady flow if possible. Try to avoid 

collecting data and performing calibration at the point of a merge or diverge or in the 

middle of a weave zone. Collect data upstream or downstream of these types of facilities. 

Where possible, collect data at instrumented sites (where detectors are located) that are 

located in areas of relatively steady flow to calibrate the model. 

2.4.1 Capacity and Saturation Flow Data 

Capacity and saturation flow data are particularly valuable calibration data since they 

determine when the system goes from uncongested to congested conditions: (7) 

• Capacity can be measured in the field on any street segment immediately downstream 

of a queue of vehicles. The queue should ideally last for a full hour; however, 

reasonable estimates of capacity can be obtained if the queue lasts only 0.5 hour. The 

analyst would simply count the vehicles passing a point on the downstream segment 

for one hour (or for a lesser time period if the queue does not persist for a full hour) to 

obtain the segment capacity. 

• Saturation flow rate is defined as “the equivalent hourly rate at which previously 

queued vehicles can traverse an intersection approach under prevailing conditions, 

assuming that the green signal is available at all times and no lost times are 

experienced, in vehicles per hour or vehicles per hour per lane.”(3) The saturation flow 

rate should be measured (using procedures specified in the HCM) at all signalized 

intersections that are operating at or greater than 90 percent of their existing capacity. 

At these locations, the estimation of saturation flow and, therefore, capacity will 

critically affect the predicted operation of the signal. Thus, it is cost-effective to 

accurately measure the saturation flow and, therefore, capacity at these intersections. 

2.4.2 Point Speed Data 

Collecting freeway speed data on links internal to the network will assist in comparing the 

model to the real world. Speed data can be collected from a Traffic Management Center 
37 

(TMC) with an instrumented system. (See Volume III for more details on loop detector 

speed data.)(7) Other temporary solutions are also possible including roadside radar and 

tube counters set up for speed detection. 

2.4.3 Travel Time Data 

Travel time through the study area can be used to test the overall network performance. A 

travel time study involves collecting travel times by timing a number of trips through the 

network using a number of vehicles. A driver driving with the flow of traffic and an 

assistant using a simple stop watch with split time to record locations and times are all that 

is needed to conduct a travel time study; however, GPS equipment on probe vehicles can 

also be used. 

CORSIM has the capability to generate a probe vehicle that can be tested against realworld “floating car” data. (Probe vehicles are discussed in appendix M.) Start at a known 

entry point so that a CORSIM probe vehicle can start at the same location. The assistant 

should log times at significant points along the main route in question. The travel time 

study should be conducted on the same days as the other data are collected. 

2.4.4 Delay and Queue Data 

Collecting delay and queue data can provide essential information that may be useful 

during calibration of the network. Delay can be computed from floating car runs or from 

delay studies at individual intersections. (7) Intersection delay can be measured on the 

approaches to an intersection. 

Floating car runs can provide satisfactory estimates of delay along the freeway mainline; 

however, they may be too expensive to make the necessary additional runs to measure 

ramp delays. Floating cars can be somewhat biased estimators of intersection delay on 

surface streets because they reflect only those vehicles traveling a particular path through 

the network. For an arterial street with coordinated signal timing, the floating cars 

running the length of the arterial will measure delay only for the through movement with 

favorable progression. Using intersection delays thus estimated, can underestimate the 

delays caused to vehicles on competing movements on the arterial. This problem can be 

overcome by running the floating cars on different paths; however, the cost could be 

prohibitive. 

Comprehensive measures of intersection delay can be obtained from surveys of stopped 

delay on the approaches to an intersection (see the HCM for the procedure). The stopped 

delay can be converted to control delay using the procedure found in appendix A of 

chapter 16 in the HCM. 

2.5 Field Inspection 

There are some data that are hard to measure with instruments. A field inspection of the 

study area should be conducted to look for queues, weave zones, lane usage, reaction 
38 

points and spillback. These items can change the behavior of the network and can be 

adjusted in CORSIM to more closely match real-world conditions. 

Vehicles or drivers begin to react to certain geometry changes at certain locations. 

Measuring this in the field is difficult, but it can be important to the operation of the 

network. Freeway vehicles that want to exit at an off-ramp may not get over until they 

have passed the location of an intermediate on-ramp. They may change lanes far 

upstream because they know the queue builds up significantly upstream of the off-ramp. 

The reaction point (also referred to as a warning sign location) can be modeled in 

CORSIM. These are not the locations of actual signs that are placed on the roadway. They 

are the location where vehicles start to react to the upcoming geometry change. There are 

reaction points for off-ramps, lane drops, and anticipatory lane changes (to avoid 

congestion caused by on-ramps). 

Placing the reaction point may require observation or video tape to determine where lane 

changing is taking place in reaction to a change in the network. Video tape running in 

reverse allows you to see an exiting vehicle and determine when it was positioned to make 

the proper movement. This requires a clear view of a significant length of the approach to 

the off-ramp, lane-drop, or on-ramp gore point (for anticipatory lane changing). 

2.6 Quality Assurance 

The quality of the input data is extremely important to the confidence level for the whole 

study. The quality and integrity of the data must be assured. This is done through data 

verification and data validation. 

2.6.1 Data Verification 

Data verification can help to ensure that the data were tabulated correctly. If resources 

permit, it is a good idea to use someone who was not involved in the initial data reduction 

to verify the data. Data should be reviewed to ensure geometric data are consistent with 

current engineering drawings. Traffic data counts and speeds should be reviewed to 

ensure the average data was used. Verify that data from days when inclement weather, 

traffic accidents, or construction occurred were not used to derive the average traffic data. 

2.6.2 Data Validation 

The data should be evaluated to ensure the data makes sense. Make sure the traffic data 

collected over many days are correctly reduced to single average numbers that can be used 

for model input. Speeds should be reviewed from floating car runs for realistic speeds. 

Traffic counts should be reviewed for unexplained large jumps or drops from upstream 

locations to downstream locations. One way to validate capacity or saturation flow rate 

data is to determine if it is consistent with the HCM. An approximate comparison to the 

HCM estimates for similar facilities can help identify major mistakes. However, this 

should be done with caution since HCM data must also be calibrated. 
39 

2.7 Reconciliation of Traffic Counts 

Inevitably, there will be traffic counts at two or more adjacent locations that do not match. 

This may be a result of counting errors, counting on different days (counts typically vary 

by 10 percent or more on a daily basis), major traffic sources (or sinks) between the two 

locations, or queuing between the two locations. In the case of a freeway, a discrepancy 

between the total traffic entering and exiting the freeway may be caused by storage or 

discharge of some of the vehicles in growing or shrinking queues on the freeway. (7) 

The analyst must review the counts and determine (based on local knowledge and field 

observations) the probable causes of the discrepancies. Counting errors and counts made 

on different days are treated differently than counting differences caused by midblock 

sources/sinks or midblock queuing. (7) 

Discrepancies in the counts resulting from counting errors or counts made on different 

days must be reconciled before proceeding to the model development task. Inconsistent 

counts make error checking and model calibration much more difficult. Differing counts 

for the same location should be normalized or averaged assuming that they are reasonable. 

Alternatively, another approach is to find a single day that is representative of a normal or 

average day and use the count data from that single day. This approach eliminates the 

problem of balancing averaged numbers. 

Differences in counts caused by midblock sources (such as a parking lot) need not be 

reconciled if they are accounted for by coding midblock sources and sinks in the CORSIM 

model during the model development task. (7) Chapter 3 discusses coding midblock 

sources and sinks in more detail. 

Differences in entering and exiting counts that are caused by queuing between the two 

count locations suggest that the analyst should extend the count period to ensure that all 

demand is included in both counts. (7)

The process for balancing counts is to review the data as a whole and identify directional 

traffic counts that are not consistent with the surrounding data. Traffic counts will have to 

be checked by starting at the beginning or perimeter of the system and add or subtract 

entering and exiting traffic. Along the way, count information should match from one 

station to the next. If it does not balance, a decision needs to be made on how to best 

reconcile the counts.

Figure 7 shows five locations where traffic counts could be gathered. At a specific point in 

time, the traffic count at point E is the result of traffic passing point A and entering or 

exiting at points B, C, and D. Taking the sum of (A – B + C + D) should roughly equal E 

for a given time period. However, this flow balance exercise will not always hold true, 

even with perfect traffic counts taken on the same day, when the distances between points 

are great, a queue developed in the middle of the section, or speeds were changing along 

the section. Thus, the analyst should be aware of these situations when attempting to 

balance traffic counts. 
40 

Figure 7. Illustration. Traffic count example. 
EXAMPLE

41 

2.8 Example Problem: Data Collection and Preparation 

The example problem for this chapter is a continuation of the problem discussed in 

Chapter 1. In this project a CORSIM model of HWY 100 including the ramp terminal 

intersections at the interchanges being reconstructed were included. 

Road Geometry Data 

For this project, planimetric base mapping files shown in Figure 8 were available. These 

drawing files were supplied in a CAD format allowing for mapping out of link-nodes. 

CAD design files were also available. Mapping files were converted into bitmaps to be 

brought into TRAFED to facilitate building of the model. 

The lane configurations on the freeway and arterials are converted into coding schematic 

diagrams. These diagrams are discussed and illustrated under the Data Preparation 

section of this example. Preparing the link-node and coding schematic diagrams in an 

electronic format at the data collection phase not only helps in creating the model but 

facilitates presentation of results in later phases of the project. 
EXAMPLE

42 

Figure 8. Illustration. Example problem: aerial photo and planimetric map. 

Traffic Demand Data 

Traffic volume demands were collected for the HWY 100 project using a variety of 

methods. An example of a turning movement count is shown in Figure 9. The freeway 

data were collected from traffic management sensors located on the freeway mainline and 

ramps and turning movement counts were collected manually at all locations. A complete 

volume data set for both peak periods was assembled in a spreadsheet database. The 
EXAMPLE

43 

volumes were balanced reconciling differences due to counts on different days and bad 

detector data. 

Figure 9. Chart. Example problem: turning movement count. 

Truck Percents and Fleet Composition 

Heavy truck data are collected on the system on a bi-yearly basis at several traffic data 

collection sites in the modeling area. Historical count data at the relevant stations were 

assembled into the database as is shown in Table 7 for the a.m. peak period. 
EXAMPLE

44 

Table 7. Example problem: heavy truck and fleet composition data. 

ATR Year

Route Description Site # Count Time Direction Total Pass. Cars Trucks Truck %

6:00-9:00 EB 8242 8043 199 2.4%

6:00-9:00 WB 9195 8798 397 4.3%

7:00-9:00 EB 10358 9972 386 3.7%

7:00-9:00 WB 9778 9267 511 5.2%

6:00-9:00 EB 1753 1719 34 1.9%

6:00-9:00 WB 2049 2014 35 1.7%

6:00-9:00 EB 10407 10017 390 3.7%

6:00-9:00 WB 5811 5464 347 6.0%

6:00-9:00 NB 7271 6998 273 3.8%

6:00-9:00 SB 11161 10797 364 3.3%

6:00-9:00 NB 12023 11559 464 3.9%

6:00-9:00 SB 12830 12402 428 3.3%

6:00-9:00 EB 4445 4312 133 3.0%

7723 6:00-9:00 WB 2798 2677 121 4.3%

12/5/2003

8/9/1996

9/18/2003

10/21/2003

9/19/2003

5/4/2001

1406

1704

7455

7718

7721

7724

E of TH100

Between TH100 and 

TH169

E of TH100

Between TH100 and 

TH169

Between Excelsior 

Blvd and 50th ST

Minnetonka Blvd and 

I-394

W of TH100

TH100

TH100

TH7

I-394

CSAH 25

TH62/TH

212

AM Peak Period

TH62 6/21/2002

Traffic Control Data 

There are a number of traffic signals and ramp meters in the study area. The data was 

gathered from three separate sources: 1) as-built traffic signal and timing plans obtained 

from the three operating agencies in the study area, 2) ramp metering timings and 

information collected from the Traffic Management Center, and 3) field observations of the 

traffic signal and ramp meter operations performed to confirm the as-built timing plans. 

The following information was gathered from these data sources: 

• Detector locations.

• Detector types (i.e., passage or presence). 

• Signal phasing.

• Special phasing or sequence of operations.

• Lane geometrics and storage lane lengths.

Calibration Data 

HWY 100 is a complex freeway system with closely-spaced interchanges and ramps. 

Isolating a specific location that can be used to calibrate capacity was difficult. In order to 

illustrate the process and to show how data can be correlated, a number of calibration 

samples have been assembled. These include capacity, saturation flow rates, and freeway 

speeds (travel time). 

Capacity 

The bottleneck location to be used for calibrating capacity was not obvious. Figure 10 

shows the entire congested area for northbound HWY 100 and illustrates that the 
EXAMPLE

45 

congested area for this study extends throughout the length of the reconstruction area. 

Within the congested area are a number of individual bottleneck locations including a lane 

drop at 36th Street, and closely-spaced weaves at TH 7 and between TH 7 and Minnetonka 

Blvd. This project was unusually complex with the effects of bottlenecks overlapping in 

such a short area. 

The target capacity for calibration is shown in the hourly flow chart between Minnetonka 

Blvd Entrance and the 25th 1⁄2 Exit. After the Minnetonka Blvd entrance, traffic flow picks 

up to a maximum hourly rate for 15 minutes of 2,654 veh/h. This high rate is not 

maintained for the entire hour; therefore, the peak hour volume between 7:00 and 8:00 a.m. 

of 4,928 vehicles is at a rate of 2,464 veh/h per lane. 
EXAMPLE

46 

Figure 10. Illustration. Example problem: freeway bottleneck locations. 
EXAMPLE

47 

Saturation Flow Rates 

Saturation flow rates for one signalized intersection were checked in the field and found to 

match CORSIM default discharge headways. 

Freeway Speeds 

Speed observations were collected using the floating car technique. The floating car was 

used to validate the spot speeds calculated from surveillance detectors in the pavement. 

Figure 11 illustrates the data from northbound Highway 100 in the morning peak. The 

simulated data will be plotted onto the same graphic. The two different charts show that 

the detector data was representative of observed speeds in the field. 

Figure 11. Graph. Example problem: freeway travel time summary. 

Data Preparation 

All the data that was gathered for this project was assembled into electronic data bases. 

The freeway schematic shown in Figure 12 was created in a spreadsheet and will 

ultimately be linked with the model results. Figure 13 shows the example lane schematic 

for Minnetonka Boulevard. 

Note: Each line represents 

a different travel time run. 
EXAMPLE

48 

Figure 12. Drawing. Example problem: HWY 100 lane geometry schematic. 

Figure 13. Drawing. Example problem: Minnetonka Blvd. lane geometry drawing. 
EXAMPLE

49 

Field Observations 

Field observations were conducted using a variety of techniques. During travel time runs, 

general observations were made about congestion and hot spot locations, as well as how 

drivers were using the system. In addition to observations from a driver’s perspective, 

observations were made from bridge overpasses and Freeway Surveillance Cameras. 

Photos and video were taken to highlight significant operational issues that occurred. 

51 

3.0 Base Model Development 

This chapter provides general guidance on the 

procedures for developing a base CORSIM 

model. The guidance provided here is intended 

to give specific advice on model development; 

however, the analyst should consult the TSIS 

software documentation for additional 

information on available data input tools and 

techniques. 

The CORSIM base model development process 

begins after the data has been assembled and 

prepared. Building a model is analogous to 

building a house. You begin with a blueprint 

and then you build each element in sequence—

the foundation, the frame, the roof, the utilities 

and drywall, and finally the interior details. The 

development of a successful CORSIM model is 

similar in that you must begin with a blueprint 

(the link-node diagram) and then you proceed to 

build the model in a sequence that breaks down the total model into basic steps. CORSIM 

follows the base model development process outlined below: 

• Create a new TSIS project and TRAFED network. 

• Create the link-node diagram. 

• Add travel demand data. 

• Add traffic control data. 

• Add traffic operations and management data. 

There are many benefits of preparing all CORSIM models using the process described in 

this document: 

• Quality control and review of the model will be consistent, reducing modeling 

mistakes and review time. 

• Less time will be spent debating on how to model and more time will be spent on what 

is modeled and the results that are produced. 

• Parts of the model can be prepared separately and combined at the end to develop the 

completed model. This will allow you to better utilize staff resources through multitasking activities. 

W orking M odel

Before Calibration W orking Model

Before Calibration

4

7

Error Checking

1

Define the Project

- Define project purpose

- Identify influence areas

-Select approach

-Select m odel

-Estim ate staff tim e 

1 -

-

-

-

-

2 Data Collection

-Traffic volum es

-Base m aps/in ventory

-Field observations

2 -

-

3

Base Model Development

Input data

Develop quality assurance 

3 -

-

- Review Inputs

- Review Anim ation 

See Chapter 1

See Chapter 2

See Chapter 3

See Chapter 4

W ork prior to

actual modeling

Initial modeling

Yes

Calibrated Model

5

-Volum es & Speeds m atch?

- Congestion in right places?

Compare Model

5 MOEs to Field Data 

-

-

See Chapter 5

Calibration

-Key Resu lts

- Technical D ocum entation 

6 -Forecast Demand

-Base Case

-Project A lternatives

Alternatives Analysis

-M odify G lobal Param eters

-M odify Link Param eters

-M odify Route Choice Param eters

Adjust Model Parameters

-

-

Final Report

Acceptable

Match?

N o

See Chapter 6

See Chapter 7

Model

Application
52 

• Reuse of the model is viable. This process and criteria were established so that a 

minimal amount of effort would be required to add to an existing model or to modify a 

model with a different design condition. 

The development of the base model can be broken down into different subtasks that can be 

worked on by potentially many people. For the base model development to go smoothly, 

the study management team must control the division of labor and the division of tasks. 

Different subnetworks or sections of the network can be assigned to different people to 

facilitate efficient completion of the model. Different subtasks can be done by different 

people but the tasks must be clearly delineated and done uniformly. For example, a 

common node numbering scheme should be developed and used (a sample node 

numbering scheme is discussed later in this chapter). 

During the modeling process, unusual model 

problems may arise where an unconventional 

approach may be required. These problems and 

solutions require documentation for future 

justification. Documenting them during the 

development process alleviates trying to recall 

what was done and why it was done that way. 

Prior to creating the link-node diagram for freeways, surface streets, and intersections, 

there are some files that need to be created and properties to be set. Creating these files 

requires some understanding of the TSIS file terminology. For clarification, we introduce 

the following TSIS terminology: 

• Case. A single simulation file for a specified traffic network as defined by its 

simulation input file (e.g., a signal timing variation for an arterial in a downtown area). 

A case includes the simulation input file and all data files generated by the simulation. 

These are also known as “alternatives.” 

• Project. A set of simulation cases or alternatives that reflect a common theme, e.g., all 

signal timing variations developed for a study. TShell can create a new project when 

requested. Use a descriptive Project name to identify the project. TShell can 

automatically create a file system directory to hold this project or use an existing 

directory. 

• Run. A single case that has not changed other than the random number seeds. 

Multiple runs of the case are used for gathering statistics for the case. The CORSIM 

Driver Multi-run processing will automatically create individual runs of a case with a 

unique set of random numbers. 

• TRF file. A text file with CORSIM inputs. It has the case name as its root name with 

TRF as its file extension. The inputs in the file are in fixed column format. See the 

CORSIM reference manual(1) for detailed information about the TRF file. 

Documenting problems and solutions 

during development alleviates trying 

to recall what was done and why it 

was done. 
53 

• TNO file. A text file with XML tags containing Traffic Network Objects (TNO). It has 

the case name as its root name with TNO as its file extension. This file is more flexible 

than the TRF file but is not typically directly edited. The TNO file also contains other 

data that the TRF file does not contain. 

• Translation. The TRF file and the TNO file are in different formats but they can be 

translated from one format to the other via the TSIS Translator. TRAFED has a 

translator built into it so that TRF files can be generated directly from TRAFED. See 

the Translator User’s Guide(10) for more details. 

3.1 Create a New TSIS Project and TRAFED Network 

TShell should be used to create a new project and to create a new TRAFED network. See 

the TShell User’s Guide(4) for more detailed steps. Upon creation of a new TRAFED 

network, the user is automatically prompted to enter the simulation run control data. 

3.1.1 Set the Simulation Run Control Data 

The simulation run control data controls how CORSIM executes. See the TRAFED User’s 

Guide(11) or the CORSIM Reference Manual(1) for more details. The run control data 

consists of the following: 

• Time Period Duration. The analyst must set a duration for each time period in order 

for CORSIM to run. For initial network building the analyst may use a short duration 

for testing purposes. Typically, each time period duration is set to 15 minutes (900 

seconds). 

• Number of Time Periods. Multiple time periods are used to change data over time 

(e.g., entry volumes are entered every 15 minutes). Multiple time periods can also be 

used to break the reporting of statistics into smaller periods. TRAFED initially creates 

one time period. For initial network building the analyst may use one time period for 

testing purposes. In order to model the peak period, multiple time periods and a 

longer duration must be set. 

• Start Time. The start time is used for display purposes and for synchronizing 

coordinated actuated control. If no default is set in the preferences, the time of 

network creation is used. 

• Random Numbers. Seed numbers are used 

for the stochastic process in CORSIM. Use the 

default random number seeds unless some 

specific reason exists to change them. The 

random number generator and the seed usage 

are explained in appendix D. 

• Fill Time. The fill time loads the network with vehicles prior to collecting statistics. 

Adjusting the fill time and its control are important to the results of the study. A small 

Use the default random number seeds 

unless some specific reason exists to 

change them. 
54 

network of a few short roadways may only need three to five minutes to fill. A large 

network with long travel distances may require 15 to 30 minutes to fill. See appendix 

C for more details. 

• Time Interval. The time interval controls the frequency by which simulation statistical 

results can be obtained. It is normally based on the most common traffic signal cycle 

length so that MOEs do not improve when the signal is green and worsen when the 

signal is red. An interval that is equal to the most common cycle length generates 

MOEs that are an average during the signal cycle. The fill time, the time periods, and 

the time between successive reports of simulation results must be an integer multiple 

of the time interval duration. 

3.1.2 Set the TRAFED Preferences 

TRAFED has user preferences that are maintained between sessions of TRAFED use. 

These can be very useful and reduce the amount of work required. TRAFED preferences 

can be set to automatically save the network in both TNO and TRF format each time a save 

is executed. The TRF file has many lines of text, and each line is a Record Type. Records 

of the same type can be automatically sorted by the translator so that entries that make a 

record unique will be sorted. TRAFED preferences can be set to do this automatically. See 

the TRAFED User’s Guide(11) for more details. 

3.2 Link-Node Diagram: Model Blueprint 

The link-node diagram is the blueprint for constructing a CORSIM model. The diagram 

identifies which streets and highways will be included in the model and how they will be 

represented. This step is critical and the modeler should always prepare a link-node 

diagram for a project of significant complexity. The first task in creating the link-node 

diagram is laying out the nodes. 

3.2.1 Nodes 

Nodes are used to connect links together and they provide positioning of network objects 

so the network can be graphically displayed. A node is a point in space and is described in 

X and Y coordinates in units of feet. The node positions are normally selected from 

engineering drawings of the project area. The orientation of the network is controlled by 

the node placement and is up to the analyst. However, most analysts are used to viewing 

maps of streets with North being at the top of the screen. TRAFED allows placing nodes at 

negative X and Y locations. When a TRAFED file is translated to CORSIM (TRF) format, 

the network coordinates are shifted so that all nodes have positive values. 

Nodes are required at intersections of roadways or where some roadway characteristics 

change, including the following locations: 

• At-grade intersections or merge points. 

• Change of links. 
55 

o Change in the number of surface street lanes. 

o Changes of grade. 

o Changes of free-flow speed. 

o Changes of curvature (optional). 

o Length of link exceeds its maximum length. 

• Locations of traffic control (Ramp meter control and non-typical control such as 

crosswalks or draw bridges may require placement of nodes to facilitate the control). 

In addition to the required node locations listed above, it may be desirable to strategically 

place nodes where they will break roadways into more manageable links. Statistics 

gathered on a link are gathered over the whole link. This may lead to statistics that 

misrepresent the behavior on the link. Some roadways may not have any characteristics 

that would require a node for many miles. For example, a long freeway link that 

approaches a highly congested area may have vehicles stopped at the congested end of the 

link and vehicles flowing at free-flow speed at the other end of the link. The link average 

speed would indicate a relatively high speed even though there are vehicles stopped on 

the link. Where there is little variance in the vehicle flow along the length of the link, long 

links are appropriate and help to conserve node numbers for other areas. Where there is a 

large variance in the vehicle flow on the link or in congested areas, breaking the roadway 

into shorter links of 150, 300, or 500 m (or 500, 1,000, or 1,500 ft) distances may be required. 

If a project is 13 km (8 mi) long and if there are nodes every 300 m (1,000 ft) (not required 

by CORSIM), there may be 40 to 50 nodes in the network. Add in the opposing direction 

of traffic and add the links for crossing roadways every mile or so and the number of 

nodes can quickly add up to 500 or 1,000 nodes. Large networks require even larger 

numbers of nodes. The current limit of internal nodes is 6,999 so the number of nodes 

should not present a problem except in extremely large, regional projects. 

User Node Preferences 

User preferences in TRAFED can be used to simplify network creation. TRAFED assigns 

node numbers automatically. By changing the base node number in the TRAFED 

Preferences before starting a new section of the network, TRAFED will begin numbering 

the next nodes at the new base number. When placed or moved, nodes will snap to the 

nearest Snap to Grid granularity value set in the preferences. If the value is set to 10 ft, the 

new nodes will be placed on 10 ft values such as 510, 520, 530, etc. The location can be 

overridden by manually setting the value in the node property dialog or by selecting the 

node and using the arrow keys to move the node in one foot increments. 

Surface Street Node Location 

In most cases surface street links are positioned so 

that the node is at the end of the left curb or the 

A surface node can only have five 

approach links. 
56 

extension of the left curb. This allows two links that share the node to use the same set of 

link placement rules when building the network. In addition to the changes in roadway 

characteristics noted above, nodes are needed at changes in the number of arterial lanes 

(other than turn bays). Keep in mind, a surface node can only have five approach links. 

In a typical four-approach intersection with the same number of lanes from each approach, 

the streets are positioned so that the node will be located in the middle of the intersection. 

Figure 14 shows a typical surface street intersection in TRAFVU where the streets are 

positioned so that the node lies in the center of the intersection of all of the left edges of all 

of the streets. 

Figure 14. Illustration. Typical surface street node location. 

Surface streets that have opposing overlapped turn bays are offset from the node location 

so that the node is not at the extension of the left curb, but where the turn bays are 

overlapped. Figure 15 shows an example of the street placement in TRAFVU when 

opposing turn bays overlap. 
57 

Figure 15. Illustration. Overlapped turn bay node location. 

At the intersection of two one-way streets, the streets will be positioned so that the node 

will be located at the intersection of the left edges and not in the middle of the intersection. 

Figure 16 shows the position of one-way streets around a node. 

Figure 16. Illustration. One-way street node location. 

Freeway Node Location 

Freeway links are positioned so that nodes are located along the left curb of the roadway. 

This was done for consistency with the arterial streets and so that opposing freeways that 

are in close proximity can be easily positioned. Two nodes can be located at the same X 
58 

and Y location to model no median between opposing freeways. Figure 17 shows the 

freeway placement in TRAFVU for: 

1. Northbound freeway with a right off-ramp fed by a multi-destination lane (a lane 

where vehicles can either travel straight or exit). 

2. Northbound freeway with a right off-ramp fed by a deceleration lane. 

3. Northbound freeway with a right on-ramp. 

4. Northbound freeway with a left off-ramp fed by a multi-destination lane. 

5. Northbound freeway with a left off-ramp fed by a deceleration lane. 

6. Northbound freeway with a left on-ramp. 

Notice that all freeways are placed with the left edge over the node. Notice that the multidestination lanes appear to be downstream of the node location. They actually start at the 

node location and are drawn on top of the freeway lanes. 

Figure 17. Illustration. Freeway placement of nodes. 

CORSIM can model many types of freeway interchanges but implementing some 

configurations is not straight-forward. Node placement may require special consideration 

in these situations. Appendix K shows some ways to model complex link configurations. 

A freeway node can only have three links connected to it with specific rules on the types of 

connections and lane alignments. 

1 2 3 4 5 6
59 

Interface Node Location 

An interface node is a node that connects two different subnetworks (i.e., freeway and 

surface street subnetworks). When placing interface nodes, select locations that allow the 

surface street side of the interface to be as long as possible to allow more area for weaving. 

Vehicles crossing from one type of network to another have very little knowledge of what 

lies downstream of the interface node. For car-following purposes, vehicles are aware of 

the next vehicle downstream of the interface node. One of CORSIM’s weaknesses is lane 

choice of vehicles on multilane interface links. In reality, drivers will often choose which 

lane to be in while on multilane freeway off-ramps based on their turn decision at the 

surface street intersection downstream of the off-ramp. The current version of 

TSIS/CORSIM (version 6.0) has no way to base the freeway off-ramp lane choice based on 

the downstream surface street intersection turn decisions, which can cause heavy weaving 

on the surface street of the interface node as turn decisions are assigned after crossing the 

interface node. This situation can be partially mitigated by placing the interface node as 

far upstream along the off-ramp as possible to give drivers adequate time and distance on 

the surface street to react to their upcoming turn. 

Layout Nodes in TRAFED 

Creating the link-node diagram is accomplished by laying out the nodes in TRAFED. 

Select either the Surface Node tool or the Freeway Node tool from the TRAFED toolbar 

and add nodes to the network. Refer to the TRAFED User’s Guide(11) for more details on 

laying out nodes. 

An accurately scaled background image can also be used to layout a network. Use caution 

to be as accurate as possible when scaling the image because even small errors in the scale 

can lead to large errors in the geometry of the network. The image can also be used as a 

reference when presenting results. Figure 18 shows the same node layout with and 

without a scaled background image. It is clear that the background image is useful for 

orientation of the nodes to the network. 
60 

Figure 18. Illustration. Node layout in TRAFED. 

Node Numbering Schemes 

The purpose of creating a node numbering convention is to create consistency, which 

allows for easy review by the model developer and others. By using the numbering 

sequence presented in this section, sorting links in a sequence that facilitates reviewing 

and selecting MOEs is an easier process. For instance, if you want to review southbound 

freeway mainline links, the file can be scanned for nodes that are numbered in the 2000s. 

Also, combining models becomes an easier process when the likelihood of duplicate node 

numbers is eliminated.(2) 

Use different sets of numbers to represent different areas of the network. For example, use 

1000s for a freeway and 2000s for the opposing freeway. Evens and odds could represent 

eastbound and westbound or northbound and southbound links. Table 8 shows a 

recommended scheme for assigning node numbers. The 7000 series of numbers must be 

used for interface nodes and the 8000 series of numbers must be used for entry nodes. 
61 

Table 8. Sample node numbering scheme. 

Node 

Numbers Description 

1-999 Miscellaneous 

1000-1199 Northbound Freeway Mainline 

1200-1299 Northbound Freeway Ramps 

2000-2199 Southbound Freeway Mainline 

2200-2299 Southbound Freeway Ramps 

3000-3199 Eastbound Freeway Mainline 

3200-3299 Eastbound Freeway Ramps 

4000-4199 Westbound Freeway Mainline 

4200-4299 Westbound Freeway Ramps 

5000-5999 East-West Arterials 

6000-6999 North-South Arterials 

When assigning node numbers, the node value at the beginning of the roadway should be 

a low value and increased sequentially as you move down the freeway. Invariably the 

user will need to add an additional node that will not fit the numbering scheme or require 

renumbering all the nodes. If gaps are left in the node numbers it is easier to insert nodes 

into existing links. For example, when numbering the nodes, use 5, 10, 15, 20, and so on. 

Later a node can be inserted and labeled as number 6 or 7 without having to renumber the 

whole sequence. 

When assigning node values at entrance ramps, it is useful to “pair” the numbers. For 

instance, if there is a ramp junction node of 110, the first node on the ramp link should be 

210. By “pairing” the last two digits of the ramp junction node and the first node on the 

ramp, you will have another mechanism for reviewing the input file. Depending on the 

number of nodes on the ramp link, the pairing sequence may not work. The purpose of 

this pairing concept is to make modeling easier, so be prepared to move onto the next 

steps if this becomes too complicated. The model will run with any number used as long 

as it has not been duplicated (with the exception that interface nodes must be in the 7000s 

and entry nodes must be in the 8000s). 

3.2.2 Links 

Links in CORSIM are connected to one node on the upstream end and one node on the 

downstream end of the link. When connecting links between nodes, TRAFED makes the 

link of the same type as the nodes it is connecting to. When connecting nodes of different 

types, TRAFED automatically makes a set of interface links and inserts an interface node. 
62 

If using freehand layout of links, where no nodes exist but are created when the links are 

created, the default type of link must be set first. 

User Link Preferences 

Setting the link preferences in TRAFED prior to laying out links may save time later by 

reducing the changes required for each link. The number of lane preferences for different 

types of links can be changed to a new number prior to laying out a new section of 

roadways with similar numbers of lanes. The free-flow speed preference can also be 

changed to a new speed prior to laying out a new section of streets with similar speeds. 

Layout Links in TRAFED 

Choose the One-way Link or the Two-way Link tool in TRAFED. TRAFED determines the 

type of link based on the node it is connecting to. If the user is creating links and nodes at 

the same time by dragging out the links where no nodes exist, the Default link type will be 

used. If freeway links are being created with the two-way link tool, only one link will be 

created because freeway nodes do not service both directions of travel. Click on the 

upstream node first. In the case of a two-way surface link, it does not matter which node 

is clicked on first. Move the mouse cursor to the downstream node and click on the node 

to create the link. If the node is not in view, move the cursor off the side of the view where 

the node is located. The view will automatically scroll in the direction. The length and 

direction are displayed in the status bar. 

Entry and Exit link descriptions: Entry and Exit links are points where vehicles enter or 

exit the network. Entry links gather data that can be used for calculating delay. There are 

no statistics generated for Exit links. To ensure entering vehicles are distributed across all 

lanes of traffic on the first internal link, make sure the number of lanes on an entry link 

matches the number of lanes on the downstream link. 

The only way in TRAFED to make an entry node and entry link is to drag a link from 

“greenspace” (where no other object exists) to an existing internal node. The only way to 

make an exit node and exit link is to drag a link from an existing internal node to 

“greenspace”. The links and nodes are then created automatically. 

Edit Link Properties in TRAFED 

Double click on each link or right click and select “Properties” from the popup menu to 

change the properties of the link. A brief description of some of the link properties for 

each link and those that are specific to a type of subnetwork is presented in the following 

paragraphs. 

Some link properties that can be set for the link are: 

• Free-flow speed –the desired, unimpeded mean free-flow speed. It is not the observed 

speed. 

• Optional link geometric data. 
63 

o Lane widths may be input but they are not used to influence driver behavior. They 

are only used by CORSIM to determine the size of an intersection and by TRAFVU 

to draw the lanes. 

o Link Names – Each link may have a name assigned to it. These names are for 

reference only. TRAFVU can display these names in different styles, which helps 

orient an observer. 

• Graphics – CORSIM was originally designed without concern for graphics. Some 

parameters have been added to produce graphics. They have no effect on CORSIM 

operations. Roadway curvature or underpasses/overpasses have no effect on driver 

behavior or vehicle performance. 

o Curve data – affects the display of the link only. The graphic curve data should not 

be confused with the freeway radius of curvature data that is used to limit the freeflow speed. 

Freeway Link Data 

Freeway Link Length: In the freeway subnetwork there are no intersections created at the 

ends of the link; therefore, the link length is also the node-to-node distance (along the 

curve of the link if curved). However, there may be problems with short freeway links in 

that vehicles in CORSIM are not allowed to jump over links. Therefore, links should not 

be any shorter than the distance the fastest vehicle can travel in one time step. On the 

other extreme, the maximum freeway link length is 30,480 m (99,999 ft) or almost 30.48 km 

(19 mi). 

There are a number of rules for connecting freeway links in CORSIM. Please refer to the 

CORSIM Reference Manual (1) for more details on the following information. 

The maximum number of freeway links at a freeway node is three (two mainline and one 

ramp link). It is not possible to connect two ramp links and one mainline link. A ramp 

link cannot be split into two ramp links nor can two ramp links be merged into one ramp. 

(Appendix K has a discussion of ways to work around this.) Ramp links can connect to 

only one other ramp, mainline link, or interface link. Mainline freeway links can only have 

one off ramp at a node (i.e., left and right exits cannot both be located at the same node). 

It is recommended that the mainline links be laid out first and then the ramps. TRAFED 

will automatically make a link a mainline if no other connection at a freeway node exists. 

If the ramp link is created prior to the second mainline, TRAFED will automatically assign 

the link as a mainline link. When the second mainline link is added, TRAFED will assign 

the link as a ramp link. This can get confusing if care is not taken when laying out the 

links. 

Lanes: There are different types of lanes and rules for using them and numbering them. 

Unlike the surface streets of CORSIM, the freeways must have an equal number of lanes 

leaving a node as entering. A multi-destination lane leading to an off-ramp is the one and 

only exception to this rule (see configuration 1 in Figure 17). Use auxiliary lanes and 
64 

add/drop lanes as a way to ensure the lanes are consistent. Figure 19 shows the freeway 

lane identification codes. Lanes can be set for different usage including truck bias, truck 

restriction, exclusive truck lanes, and high occupancy vehicle (HOV) lane operations. 

Refer to the CORSIM Reference Manual (1) for more information. 

Figure 19. Illustration. Freeway lane identification codes. 

Acceleration/Deceleration Lanes: Acceleration lanes extend from the upstream end of a 

freeway link to a user-specified mid-link position and must be fed by an on-ramp. 

Vehicles will use this lane to transition from the on-ramp and merge with traffic on the 

mainline lanes. Deceleration lanes extend from a user-specified mid-link position to the 

downstream end of the link and must feed an off-ramp. Vehicles will use this lane to 

transition from the mainline lanes to the off-ramp. It is possible to have two different 

auxiliary lanes with the same identification number on the same link. For example, if there 

are both an acceleration lane and a deceleration lane on the right side, both lanes would be 

numbered as lane 9. 

Full Auxiliary Lanes: CORSIM can have up to three full auxiliary lanes on both sides of 

the link. A full auxiliary lane extends the entire length of the link. It can connect to a ramp 

link or it can connect to a mainline lane. Full auxiliary lanes function with the same driver 

behavior as through lanes. Using full auxiliary lanes, it is possible to model up to 11 lanes 

of traffic. Figure 20 depicts mainline links with through lanes and full auxiliary lanes that 

combine to total 11 lanes of traffic. Notice that entry and exit links can only connect to 

links with, at most, five through lanes. Therefore, to create a segment with more than five 

lanes, the extra auxiliary lanes must be added and removed at different points along the 

segment until the desired number of lanes is achieved. 

1

2

3

4

5

1

2

3

8

7

6

5

4

3

2

1

1

2

3

4

5

1

2

3

11

10

9

1

2

3

4

5

Left Auxiliary Lanes

Right Auxiliary Lanes

Node Node Node
65 

Figure 20. Illustration. Freeway layout with 11 lanes. 

Add/drop Lanes: Through lanes can be added or dropped at user specified mid-link 

locations on the mainline or the ramp links. Up to three lanes can be added or dropped on 

each link. However, the user cannot add lanes to create more than five through lanes on 

the mainline or more than three lanes on the ramp. The user cannot drop lanes to create a 

link with no through lanes. 

Superelevation, Pavement Friction, and Radius of Curvature 

CORSIM provides inputs for superelevation, pavement friction, and radius of curvature 

that reduce the free-flow speed on the link. CORSIM uses the lower value of the input 

free-flow speed or the speed based on the calculation from superelevation, friction, and 

radius of curvature. A warning message is produced if the free-flow speed is set by these 

inputs. Error checking and calibration may be affected by these inputs if they result in 

undesirable free-flow speeds. The freeway radius of curvature only affects the free-flow 

speed; it is not used by TRAFVU to draw links. TRAFVU draws links based on the node 

locations, link length, and type of curvature. 

Barriers 

Barriers can be added to prevent vehicles from merging with other vehicles. Barriers can 

be used to prevent or control a weave zone. Exclusive HOV lanes may be used in 

conjunction with barriers to model barrier protected HOV lanes. Barriers can also be used 

to model high occupancy toll (HOT) lanes or HOV lanes that have limited access to the 
66 

general purpose lanes by placing barriers on the links where access is restricted and no 

barriers on the links with open access to the HOV or HOT lanes. Barriers do not influence 

the driver reaction; vehicles will not slow down when next to a barrier nor will they move 

away from a barrier. 

Reaction Points 

Vehicles or drivers begin to react to certain roadway geometries and guide signing objects 

at certain locations. These locations are not necessarily where the traffic sign or feature is 

located in the real world. (These are also referred to in CORSIM as a “Warning Sign.” 

This is a poor term that tends to confuse new users into placing them at the location where 

the actual sign is in the real-world.) The placement of these points is very important to 

being able to realistically model the real world. In general, drivers do not react to guide 

signs, but field verification is usually needed to understand how drivers are reacting. 

When CORSIM vehicles cross this “reaction point” 

their lane codes are set so vehicles will begin to 

move into certain lanes or out of certain lanes. 

These reaction points have default values in 

CORSIM. Measuring this in the field is difficult, 

but it can be important to the operation of the 

network. In the real-world, vehicles that want to 

exit at a distant off-ramp may not get over until they have passed the location of an 

intermediate on-ramp. They may move over well upstream because they know the queue 

builds up well upstream of the off ramp. 

Exit-ramps Reaction Point: An off-ramp reaction point should be placed far enough 

upstream that vehicles in the farthest lane have enough time and distance to move over to 

position themselves for exit at the off-ramp. The default value of 762 m (2,500 ft) may not 

be long enough for links with more than two lanes. For example, vehicles in the fifth lane 

need more space to change lanes prior to reaching the off-ramp. (As a rule of thumb; use 

762 m (2,500 ft) plus 305 m (1,000 ft) for each lane greater than two lanes. Thus, five lanes 

of traffic need about a mile of reaction distance.) 

In the case where there are only a few lanes but there is an on-ramp located between the 

default reaction point and the off-ramp with a large volume of traffic, the warning sign 

may need to be placed downstream of the on-ramp to model vehicle staying in the left lane 

until they are past the on-ramp traffic. This congestion due to traffic from the on-ramp is 

normally handled by Anticipatory Lane Changing (discussed below); however a vehicle 

that has moved into an appropriate lane for the upcoming off-ramp will not move out of 

that lane based on the anticipatory lane change logic. Be cognizant of reaction point 

locations and whether their region overlaps other traffic areas. 

Lane Drops Reaction Point: A lane drop reaction point should be placed far enough 

upstream that vehicles have enough time and distance to move over to position 

themselves to avoid being stuck at the lane drop location. The lane drop reaction location 

may need to be moved close to the actual lane drop to allow vehicles to use the lane up to 

the point of the warning sign. Figure 21 shows the lane drop reaction point downstream 

In CORSIM, if the analyst does not 

change the default value for the 

reaction point, it is a modeling 

decision just the same as if it were 

changed. 
67 

of the ramp meter. If the reaction point is upstream of the ramp meter vehicles will avoid 

using the lane that is dropping. 

Figure 21. Illustration. Lane drop downstream of ramp meter. 

Anticipatory Lane Change (merge locations): Congestion caused by vehicles entering the 

freeway from an acceleration lane on a link can cause upstream vehicles to make lane 

changes away from the side of the freeway where the acceleration lane is located. 

CORSIM models this behavior with Anticipatory Lane Changing, of which a brief 

description is given below. 

Speed Trigger: The average speed of all the vehicles that are currently on the subject link 

in the anticipatory region (lanes 1, 9, 10, and 11 for a right-side on-ramp) is evaluated 

every second. When this average falls below the threshold specified by this entry, 

anticipatory lane changing will begin. The speed trigger defaults to 2/3 of the free-flow 

speed. Lane changing will only happen if there is no disadvantage in the lanes of the 

non-anticipatory region. If the average speed increases to a value above the threshold, 

anticipatory lane changing will cease in this region. 

To prevent anticipatory lane changing in this region, enter a very low minimum speed, 

such as 1.6 km/h (one mi/h). To maximize anticipatory lane changing in this region, 

enter a very high minimum speed, such as 159.3 km/h (99 mi/h). 

Distance to React: Congestion caused by vehicles entering the freeway from an 

acceleration lane on this link can cause upstream vehicles to make lane changes away 

from the side of the freeway where the acceleration lane is located. The distance 
68 

upstream to the point at which vehicles will react to the congestion is determined by this 

entry, measured in feet from the upstream end of the link. If the speed threshold has 

been exceeded, the desire to perform the lane change will increase linearly from the 

minimum value to the maximum value as the vehicle travels between the upstream 

reaction point and the upstream end of the subject link. 

Anticipatory lane changing can be prevented by specifying a very short reaction 

distance, such as one ft. To simulate a recurring congestion problem caused by an onramp, use a long distance to model vehicle moving over in anticipation of the congestion 

that is present on a daily basis. 

HOV Lane Reaction Point: This is the location where HOV vehicles begin to react to an 

upcoming HOV lane. HOV vehicles will begin to change lanes in order to position 

themselves for entry into the HOV lane. 

HOV Exit Reaction Point: This reaction point defines the upstream location for an HOV 

exit warning sign. All HOV vehicles that will be exiting the freeway from this link will 

avoid exclusive HOV lanes after passing this warning sign. If they are currently in an 

exclusive HOV lane they will attempt to exit from that HOV lane as soon as possible. This 

entry has no effect on other vehicles and only affects HOV vehicles when exclusive HOV 

lanes have been entered. This value must be greater than or equal to the off-ramp reaction 

point. 

3.2.3 Surface Street Link Data 

There are a number of considerations specific to surface street link data including link 

length and lane data. 

Link Length 

Link length is measured from the stop bar of the upstream link to the stop bar at the 

downstream node including the upstream intersection if there is one. TRAFED uses the 

node-to-node distance when assigning the original link length. If the user has not changed 

the link length from the node-to-node distance, dragging the node at either end 

automatically changes the link length. Once the link length has been changed by the user 

and is no longer equal to the node-to-node distance, dragging a node will not change the 

length of the link. 

In some cases, the link length will correspond to the node-to-node distance. In other cases, 

the two measurements can be significantly different. For example, consider two parallel 

but opposing streets with no intersection at one end and a seven-lane intersection at the 

other end. Figure 22 shows that two such parallel links can have significantly different 

link lengths. The links were both unchanged from the length that TRAFED created them, 

500 ft. The westbound link should be 584 ft from stop bar to stop bar. It shows vehicles in 

a queue spaced widely apart. The eastbound link should be 416 ft from stop bar to stop 

bar. It shows vehicles overlapped due to the discrepancy between the input length and the 

actual length. 
69 

Figure 22. Illustration. Effects of incorrect link length. 

If the length is not correct, CORSIM may be able to store more or less vehicles on the link 

than can be stored in the real world. CORSIM may allow more vehicles on a link than is 

possible in the real world because the link length was not accurate, or CORSIM may not 

allow as many vehicles on the link as the real world link can hold. 

TRAFVU animation will show problems with the 

link length in different ways. Overlapped 

vehicles will show up when the link length, as 

determined by TRAFVU, is less than was input to 

CORSIM. (i.e., CORSIM calculates that there is 

more storage than there actually is.) Also, 

vehicles will appear to animate very slowly across 

these links. Use the TRAFVU Link Properties to 

show the input length and the TRAFVU calculated length for comparison. If the input 

length is shorter than TRAFVU determines is required based on the geometry, vehicles 

will be spaced very far apart when in queue. (i.e., CORSIM calculates that there is less 

storage than there actually is.) Vehicles will also animate very fast across these links. 

Lane Data 

Links are the main connector from node-to-node, but it is at the lane where vehicles 

interact. Lanes can vary in width from lane to lane and from link to link, however, lane 

width does not affect driver behavior in CORSIM. The only use for lane width in CORSIM 

is to determine the size of an intersection. Lane width is used by TRAFVU to draw links, 

lanes, and intersections. 

CORSIM does not have the capability of modeling partial lanes or placing vehicles in two 

lanes at the same time. Vehicles always travel in a specific lane. Any animation effect that 

shows vehicle crossing the lane line during lane changing is done by TRAFVU as it 

interpolates the vehicles position from one second to the next. This becomes significant 

when modeling tapered lanes and modeling links that merge with other links at shallow 

angles. 

CORSIM may allow more vehicles 

on a link than is possible because the 

link length was not accurate or 

CORSIM may not allow as many 

vehicles on the link as the real world 

link can hold. 
70 

TRAFVU Surface Street Intersection Pull Back Description: The way an intersection is 

created and drawn in TRAFVU is to lay down the end of the left curb of all the links at the 

node and then pull them back to the point that they do not overlap. This works fine for 

perpendicular roadways, but links that approach a node at shallow angles tend to pull 

back a long way. This also shortens the adjacent links considerably. With very little 

graphical information, there is no other way to do this. There is no drop lane or 

acceleration lane concept on the surface street. One method to work around this situation 

is by connecting to a full lane that drops at the next node. The top drawing in Figure 23 

shows how TRAFVU draws the links when they merge at shallow angles and the bottom 

drawing in the figure shows the work around to the link pull back problem. This method 

requires adding a short link with an extra lane of traffic that the vehicles use to merge with 

the through lanes. 

Figure 23. Illustration. TRAFVU intersection pull back. 
71 

Lane Numbering Diagrams: There can be up to seven lanes on each surface street. There 

can be two turn bays on each side of the street. If there are two turn bays on each side of 

the street, there can only be three through lanes. Figure 24 shows the lane numbering 

scheme for surface streets. It is important to understand how CORSIM numbers the 

surface street lanes for placement of detectors and for assigning channelization. 

X <= 4 

7 6 5

X <= 5 

X . . . 1

7 6

X <= 5 

X . . . 1

6 7

X <= 6 

X . . . 1

7

Y = 0 Y = 1 Y = 2

Z = 0

Z = 1

Z = 2

X + Y + Z <= 7 is a necessary condition

X <= 7 

X . . . 1

X Number of full lanes

Y Number of lanes in right-turn pocket

Z Number of lanes in left-turn pocket

X <= 5

X . . . 1

7 6

5

X <= 3 

6 7 4

X . . . 1

X <= 4

6 7 5

X . . . 1

X . . . 1

X <= 6 

X . . . 1

7

Figure 24. Chart. Surface street lane numbering. 
72 

Lane Channelization: Lanes can be channelized for different types of traffic flow (turns) or 

for special utilization. Unfortunately, turn movements and utilization cannot be 

combined. Surface street lanes in CORSIM can have special utilization including buses 

only, carpools only, or closure. Lanes can alternately be channelized for left, right, 

through, or diagonal movements, or combinations of these movements. Turn bays are 

automatically channelized to the corresponding turn movement. They do not need to be 

set nor can they be changed. Turn bays that are the full length of the link should be coded 

as channelized full lanes because upstream feeder links cannot connect to a full length turn 

bay. Figure 25 shows full left turn lanes channelized for left turns only. 

Figure 25. Illustration. Left turn channelization. 
73 

Lane Alignments versus Turning Alignments: The lane alignment and turning 

alignments are sometimes confusing. Lane alignment is for through movement. CORSIM 

and TRAFVU use lane alignment to align the intersection. By default, lane 1 on the 

upstream link aligns with lane 1 on the downstream link. However, lane 1 on the 

upstream link may align with lane 2 on the downstream link or lane 2 on the upstream 

link may align with lane 1 on the downstream link. Figure 26 shows both lane alignment 

situations. 

Figure 26. Illustration. Sample lane alignment. 

On the other hand, the turning alignments are used to restrict vehicles to turn into certain 

lanes or allow them to turn into additional lanes. By default, CORSIM only allows vehicles 

to turn from the near lane on the upstream link to the near lane on the downstream link. 

Turning alignments do not need to be set unless vehicles should be allowed to turn into 

other lanes. Figure 27 shows such a situation. 

Figure 27. Illustration. Turning alignments. 
74 

A unique lane channelization, lane alignment, or turning alignment may be needed in the 

base CORSIM model to replicate an existing condition. The analyst should take note of 

these unique features and be sure to revisit them in the alternatives analysis step, as a 

unique geometric feature in the existing conditions may be fixed or altered in a future case 

alternative. 

3.2.4 Corridors 

Surface street subnetworks and freeway subnetworks can be connected to form a corridor 

where the two subnetworks interact. Interface nodes are used to connect the two 

subnetworks. Only two links can connect at an interface node. TRAFED will connect the 

two subnetworks and add the necessary interface nodes by simply dragging a link 

between the two different subnetwork nodes. The number of lanes must match on both 

sides of the interface node. Mainline freeway links and ramp links can connect to surface 

links directly at the interface node. 

3.2.5 Review 

At this point in the base network development, the network will not run in CORSIM 

without more modifications, but it can be viewed in TRAFVU. This is a good checkpoint. 

Save the TRAFED network and save it (translate it) to a TRF file. Then open the TRF file 

with TRAFVU and review the geometry of the network. This is a cursory review of the 

network; a detailed review and error checking will come later. For large networks, 

performing a cursory review of the link-node diagram at multiple points of development 

(e.g., after the freeway is coded or after each interchange is coded), rather than only at the 

conclusion of the network, would help ensure errors are caught early in the coding 

process. 

3.3 Traffic Demand Data 

The demand data consists of Entry Volumes, Turn Volumes or Turn Percentages, OriginDestination data, and Vehicle Mix. 

3.3.1 Entry Volume 

Entry points describe the volume, in either vehicles per hour or traffic counts for the time 

period, entering the CORSIM network. Counts will be changed into hourly equivalents 

within CORSIM so that entry headways can be easily calculated. 

Entry volumes are required for all freeway networks and surface street networks that do 

not use the traffic assignment option. The traffic assignment option used to generate 

surface street traffic volumes does not require entry volumes entered at entry points. 

Using that option requires entering the volume of traffic in the origin-destination trip table 

(see “Surface Street Demand” discussion in this section for more detail). 

Entry nodes usually form the outer boundary of the network. The network will normally 

receive traffic from entry nodes on its periphery. The exception to this is large internal 
75 

traffic generators or receivers such as parking garages, side streets, or neighborhoods that 

can be modeled as internal entry nodes with their own traffic volumes. 

Entry links are unique in that they are not part of the network itself. As vehicles are 

generated by CORSIM, they are accumulated on the entry links for later discharge onto the 

network from the entry link. The car-following, control, and spillback conditions at the 

downstream node of the entry link regulate entry of vehicles onto the network. Network 

statistics are not accumulated for the entering vehicles until they have left the entry link. 

The entry volume must also specify the percentage of vehicles of each type. Carpool and 

truck percentages must be defined explicitly. By default, no carpools or trucks are part of 

the traffic flow. When carpool and truck percentages are input, the car percentages are 

defined by subtracting carpool and truck percentages from 100 percent. Bus volumes are 

not part of the entry volume and are defined separately. 

Specified entry point volumes cover all lanes of 

the link; they are not specified on a per lane basis. 

The maximum number that can be entered for an 

entry point is 9,999 vehicles for a given time 

period. Thus for a one hour time period, this 

equates to slightly less than 2,000 vehicles per 

lane for a five-lane freeway or slightly more than 

1,400 vehicles per lane for a seven-lane surface street. If higher volumes are required, they 

can be entered as counts with time period durations less than one hour or using volumes 

that vary within a time period. Refer to volume variations within a time period in the 

CORSIM Reference Manual(1) for more information. 

Time Period Varying Demand 

CORSIM can capture the onset, presence, and dissipation of congestion by varying the 

input volume over multiple time periods. Specified entry link volumes will stay in effect 

until the end of the simulation unless changed by subsequent entries in the same period or 

in later periods. The volume will be smoothly increased or decreased to adjust to the new 

volume input in a different time period. If a subsequent time period has no changes and 

then a later period includes inputs that specify 

different entry volume, the volume through the 

period for which no entry volumes were 

specified will be linearly interpolated between 

the specified volume at the end of the previous 

period and the specified volume at the 

beginning of the next period. 

For example, if a simulation includes three time periods where an entry volume of 1,000 

vehicles per hour was specified for time period one, and no subsequent time period 

includes any changes to the volume, the volume will remain constant at 1,000 vehicles per 

hour for all three periods. However, if there is an entry for time period three that changes 

the volume to 2,000 vehicles per hour, but no change was entered for time period two, then 

the entry link volume will vary throughout time period two, starting at 1,000 vehicles per 

hour and increasing to 2,000 vehicles per hour at the end of the period. Figure 28 shows a 

If higher volumes are required, they 

can be entered as counts with time 

period durations less than a full hour 

or using volumes that vary within a 

time period. 

For high volume freeways, a 15 

minute time period will adequately 

represent the dynamic nature of 

traffic volume patterns for most 

design/analysis studies. 
76 

graph of this example. The lower line depicts explicitly setting the volume during the 

second time period to 1,000 vehicles per hour. 

Figure 28. Graph. Volume interpolation when not assigned for a time period. 

When entry link volumes are not constant throughout the simulation, the best way to be 

sure that the volumes are correct is to specify the volumes explicitly for each time period. 

Sub-time period varying demand: The analyst can specify variations in entry volumes 

within a time period. The analyst can specify up to 16 variations in volume for each time 

period. If the entries are specified in vehicles per hour, CORSIM will interpolate between 

the data points to determine flow rates at times between the specified times. If the entries 

are specified in vehicle counts, CORSIM will calculate the required flow rate to generate 

that number of vehicles over the specified time interval. 

Some valid uses of sub-time period variations are: 

• More variations in the volume are necessary (CORSIM only allows 19 time periods). 

• The volumes change more frequently than on the time period boundary. For example, 

each time period is defined as 15 minutes long but the volume data are in five-minute 

intervals. 

0

500

1000

1500

2000

2500

135 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45

Time (minutes)

Assign Volume for All 

Time Periods 

Assign Volume for Time Periods 1 

and 3 only 

Traffic Volume (veh/h)

Time Period 1 Time Period 2 Time Period 3 
77 

• There is no need for time period reporting or other variations that would require the 

use of time periods. All input volume can be done through sub-time period entries. 

Vehicle Entry Headway 

Vehicle entry headway is the time between one vehicle entering the network and the 

previous vehicle to enter the network. The headway is defined as 3600 divided by N, 

where N is the hourly volume in vehicles/hour. CORSIM can generate these headways 

deterministically, using a constant headway (which is the default), or stochastically using 

either a normal or an Erlang distribution. The type of headway applies to the whole 

network and cannot be modified for individual links (i.e., a global parameter). See 

appendix E for more details. The three types of headways are briefly described below: 

• Constant Headway: All vehicle entry headways are set equal to the constant headway, 

defined as 3600 divided by N, where N is the hourly volume in vehicles/hour. This 

produces a constant stream of vehicles. Use constant headway to model an upstream 

stop sign or ramp meter flow metering. It is also useful when performing traffic 

modeling research where no variation in the vehicle injections is desired. 

• Normal Distribution: This distribution produces a truncated bell curve of entry 

headways. The headway, defined as 3600 divided by N, where N is the hourly volume 

in vehicles/hour, is used as the mean value for the distribution. If headway values less 

than the minimum value are produced, a redraw of the value is performed. This 

distribution produces platoons of vehicles instead of a constant flow. 

• Erlang Distribution: This produces different distributions of entry headways 

determined by the Erlang parameter. The distributions can vary from an exponential 

distribution to a normal distribution. The headway, defined as 3600 divided by N, 

where N is the hourly volume in vehicles/hour, is used as the mean value for the 

distribution. If headway values less than the minimum value are produced, a redraw 

of the value is performed. This distribution provides more variation in vehicle 

headways than constant or normal distribution. See appendix E for detailed discussion 

and graphs of the Erlang distribution. 

While the default setting is a constant headway, a stochastic distribution (Normal or 

Erlang) would be more appropriate for real-world applications to account for natural 

randomness in driver behavior. In the absence of field measured headways, an Erlang 

Distribution with α =1 may be used, which replicates a negative exponential distribution. 

A negative exponential distribution is commonly used for generating the inter-arrival time 

of “customers” (e.g., vehicles) to a system. Refer to appendix E for more information on 

headway distributions. 

3.3.2 Freeway Demand 

The freeway subnetwork has some specific considerations related to demand inputs 

including origin-destination data, off-ramp turning percentages, minimum separation of 

entering vehicles, and the distribution of vehicles between lanes. 
78 

To code the freeway traffic volume data, entry volumes and turning percentages are 

required, while origin-destination (O-D) data is optional. There are three approaches to 

entering freeway demand data: 1) entry volume data and turn percentages; 2) entry 

volume data, turning percentages, and complete O-D data, or 3) entry volumes, turning 

percentages, and partial O-D data. The most straightforward way to enter freeway 

demand data is by using entry volumes and turn percentages (approach 1). 

Approach 1: Complete Turning Counts or Percentages 

In this approach, the counts of vehicles or percent of traffic should be specified for every 

node that has an off-ramp. If turn specifications are entered in the form of vehicles/hour, 

CORSIM will internally convert these inputs to turn percentages. Entry volumes are used 

to generate the actual number of vehicles on the network, whereas turning counts are used 

strictly to assign relative turning movements of these vehicles that entered the network. 

The freeway entry volumes and turning percentages at ramp exits are internally converted 

to an O-D table. The gravity model is designed to perform this conversion. More 

information about the gravity model as applied in CORSIM can be found in the CORSIM 

User’s Guide.(1) 

Vehicle Type-specific Turn Movements: By default, the turn percentages at an off-ramp 

apply equally to all vehicle types. It is possible to specify that certain vehicle types have 

different turning fractions for specific off-ramps. If altering the turning percentages for a 

specific set of vehicle types, it may be necessary to set all vehicle types to ensure the 

overall exiting volume remains correct. An example of when this is useful is when 

modeling the effects of a truck weigh station. A high percentage of the trucks would be 

assigned to the exit and a very low percentage of other vehicle types would be assigned to 

the exit. This vehicle type-specific turn movement is not necessary for buses and will not 

have an effect on buses. 

Approach 2: Complete Origin-Destination Data 

The number of vehicles that exit at an off-ramp can also be specified through O-D data. 

The trip table from the origin to the destination specifies the percentage of traffic that will 

exit at individual destinations from an origin node. The destination volumes are modeled 

by linear systems according to the input data. An iterative process is used to solve the 

linear systems. Where there are groups of freeway interchanges, in some rare cases, the 

sufficient condition for the convergence of the linear systems cannot be satisfied. 

Consequently, the destination volumes may not converge. If that happens, a warning 

message will be generated by CORISM. 

Even when the complete O-D data set is known, the analyst must still specify entry 

volumes and exit percentages. CORSIM will use that data to create an internal table of 

origin volumes versus destination volumes. O-D data can be used to ensure that the 

correct origin-destination relationships are enforced, but CORSIM will attempt to balance 

all of the information from the three input types. Therefore, it is important that the entry 

volumes and turn percentages are consistent with the O-D data. The analyst may find it 
79 

useful to develop a spreadsheet to estimate entry volumes and exit percentages based on 

the known O-D data. 

The analyst is responsible for ensuring that the traffic volumes for all destination nodes 

agree with the traffic volumes entered using input data. Otherwise, the origin-destination 

table may not be balanced. If that happens, a warning message will indicate the 

unbalanced volumes at specific exit nodes. The analyst should make the necessary change. 

If the convergence could not be achieved and/or the O-D table could not be balanced, 

CORSIM can still run. However, CORSIM can not assign the correct volumes on all links. 

CORSIM will report the O-D tables to assist the analyst in debugging the O-D input data. 

The analyst can increase the number of iterations to improve the convergence. 

Approach 3: Partial Origin-Destination Data 

If entry volume and turn percentage data are available, but at the same time it is important 

to maintain some of the O-D pairs, CORSIM will first calculate destination volumes based 

on a linear system equation model by entry volume and turn percentage. Second, 

CORSIM utilizes the input O-D data to “override” CORSIM calculated O-D pairs. 

CORSIM then calibrates the O-D pairs without the specified input O-D data. Finally, a 

balanced O-D table is generated. However, the “override” makes sense only when the OD table can be balanced. In this case, it is suggested that users prepare entry volumes, turn 

percentages, and O-D data, then perform a CORSIM run and check for warning messages. 

If warning messages are generated, follow instructions in the CORSIM Reference Manual(1)

for O-D data to try to eliminate the warning message. For a simple FRESIM network, you 

may want to generate a complete O-D pair table first, then, follow the steps outlined in the 

previous situation. For a complicated network, you can check the CORSIM O-D table 

output and make necessary changes to the turn percentages and/or O-D data. 

Using partial freeway O-D trip data, it is possible to control traffic flow on an individual 

interchange basis. In CORSIM, the percentage of vehicles exiting at the off-ramp does not 

depend on where the vehicle entered the freeway unless O-D is used. In most real world 

situations, traffic entering the freeway at an on-ramp probably does not exit at the next offramp. Modeling this weave zone correctly can improve the comparison to the real world. 

Using O-D trip tables helps prevent vehicles from continuously traveling on a clover-leaf. 

Figure 29 shows a situation where very little traffic would enter the freeway at point A and 

then immediately exit at point B. Using the O-D trip table, the percentage of traffic that 

has an origin of A and a destination of B could be set to zero. 
80 

Figure 29. Illustration. Ramp-to-ramp trips. 

Minimum Separation of Vehicle Generation 

The minimum separation for generation of vehicles governs the maximum rate at which 

vehicles on a single lane freeway can be emitted onto the network in a given lane. Overall, 

the rate that vehicles are emitted is governed by the volume of traffic entering the network 

at a certain location. If the input volume is greater than 2,250 vehicles per hour per lane, 

the default minimum separation of 1.6 seconds will not allow all the vehicles to enter the 

network. To achieve 2,400 vehicles per hour per lane, the minimum separation must be 

reduced to 1.5 seconds (i.e., 3600/1.5 = 2400). This is a network-wide parameter that 

affects all freeway entry points, and it should be adjusted to accommodate the highest 

entry volume in the network. 

Distribution Among Lanes 

The distribution of vehicles entering different freeway lanes can be defined by the user to 

model real world distributions. For example, across three lanes of traffic 50 percent could 

be assigned to lane one and 30 percent to lane two and 20 percent to lane three. This can 

be used to model the effects of an on-ramp upstream of the entry point where many 

vehicles are still in the lanes coming from the on-ramp when they reach the entry point. 

The percentage of vehicles entering each lane is based on the total flow rate specified. The 

sum of the percentages must equal 100 percent. Downstream of the entry point, vehicles 

will begin to change lanes for discretionary or mandatory purposes so the lane distribution 

will not stay in effect downstream of the entry point. 

Point B Point A
81 

3.3.3 Surface Street Demand 

Turn Percentages 

Turn movement percentages only apply to passenger cars, carpools, and trucks. Bus turn 

movement data is based on the specified bus path data. All traffic exiting on interface 

nodes must travel straight through to the next network. Turn movement data can be 

entered for each time period to reflect the changes in turn percentages or traffic blockages. 

If turn specifications are entered in the form of vehicles/hour, CORSIM will internally 

convert these inputs to turn percentages. If the entries do not total 100, CORSIM will treat 

them as volumes and will convert them into percentages. Entry volumes are used to 

generate the actual number of vehicles on the network, whereas turning counts are used 

strictly to assign relative turning movements of these vehicles that entered the network. 

Vehicle Type-specific Turn Movements: The turn percentages at an intersection apply 

equally to all vehicle types. It is possible to indicate that certain vehicle types have 

different turning fractions for specific intersections that have an associated turn. 

Interchange origin-destination 

Multilevel urban interchanges can be modeled in NETSIM. To assist in the coding of 

interchanges, there is an option of entering travel demand patterns (i.e., O-D information) 

through an interchange instead of turn percentages for each link. 

Conditional Turn Movements 

Conditional turn movements can be used to prevent vehicles from making a series of 

unrealistic turn movements. For example, at a diamond interchange, the user may want to 

prohibit vehicles from making a left-turn to an on-ramp when they just made a left-turn 

from an off-ramp (i.e., restrain vehicles from returning to the freeway when they just 

exited the freeway). The NETSIM model normally applies the specified turn movement 

percentages to all vehicles entering a link, regardless of their previous path. CORSIM 

allows the user to define discharge turn percentages that are conditioned on the basis of 

entry movement. Therefore, the percentage of vehicles executing left turns after entering 

via a left turn can be made substantially less than the percentage of vehicles executing left 

turns after entering via a through movement. 

If the user defines turn percentages for one entry movement–exit movement combination, 

they must define the discharge turn percentages for all other traffic entering the link. 

When discharge turn percentages are defined for traffic entering from some directions and 

not from others, the traffic entering from the remaining directions is assigned discharge 

movements subject to the turn percentages of each turn movement defined. This could 

result in undesirable turning volume. 

For example, Figure 30 shows a typical diamond interchange. The original traffic counts 

may have shown that 20 percent of the vehicles on the southbound link turn left to the 

eastbound on-ramp. Without conditional turn movements, on average 20 percent of the 
82 

vehicles that came from the westbound off-ramp would turn left at the on-ramp 

(approximately 40 vehicles over an hour). With conditional turn movements, that number 

can be changed. If zero vehicles that came from the westbound off-ramp should turn left 

onto the eastbound on-ramp, all 200 vehicles per hour will travel southbound through the 

intersection. If the number of vehicles that came from the upstream southbound link is not 

changed by using the conditional turn movement also, only 20 percent (i.e., 200 vehicles) 

of the 1,000 vehicles per hour will turn left. However, since 1,200 vehicles travel on the 

link per hour, a total of 240 vehicles (20 percent of 1,200 vehicles) should be making a left 

turn at the intersection. For an accurate representation of the field data, the analyst must 

also specify conditional turn movements for the vehicles entering the approach link via a 

through movement. Conditional turn movements must be specified so that 24 percent of 

the vehicles entering via the through movement turn left onto the on-ramp while 76 

percent travel through the intersection. 

Figure 30. Illustration. Conditional turn movement example at diamond interchange. 

Origin-Destination Trip Table 

Specification of the trip table can be entered in the form of origin-and-destination nodes. 

Sources and/or destinations (sinks) of traffic that are internal to the network can also be 

specified. When traffic assignment is requested, all record types relating to entry volumes 

and turn movements should be left out of the dataset; the volumes and percentages will be 

determined by the traffic assignment results. 

Due to the unspecified volume of traffic entering the surface street subnetwork from a 

freeway subnetwork at an interface node, traffic assignment can only be performed when 

surface streets are the only links in the network. At the time the traffic assignment model 

1000 veh/h

200 veh/h

20% LT
83 

was developed, the interface with a freeway subnetwork was not an option. If traffic 

assignment must be used, the surface street subnetwork must be developed prior to the 

freeway subnetwork or the freeway subnetwork must be developed separately and 

combined after traffic assignment has been run and turning percentages have been 

calculated. 

Another limitation of traffic assignment is that it is not entirely accurate when intersections 

are controlled with actuated control. This is due to the uncertain amount of green time 

during a phase. If traffic assignment must be used, the surface street subnetwork must be 

developed with fixed time control with appropriate green times. After traffic assignment 

has been run and turning percentages have been calculated and input into the model, the 

controllers can be changed to be actuated control. 

Although traffic assignment models are not categorized as simulation models, they 

represent an essential interface between travel demand and actual traffic flows. 

Assignment models convert O-D trip tables into estimates of network loadings, which can 

then be used by simulation models to evaluate the network performance as well as 

demand responses to operational changes. The purpose of the traffic assignment feature 

for surface streets is to generate an estimate of turning volumes, or percentages, at 

intersections. The analyst should review the assigned turning volumes, or percentages, at 

specific intersections after performing a CORSIM run with surface street traffic 

assignment. Adjustments may then be needed to the turning volumes to better match 

actual traffic flows. Refer to the CORSIM Reference Manual(1) for more information on 

traffic assignment. 

Source-Sinks 

Source/sink locations represent net flow for the entire block. They represent the net gains 

or losses for all parking lots or garages on the links and the net curb parking turnover. 

Source/sink locations are best for representing places with flow that occurs predominantly 

in one direction. If there are minor streets such as alleys, business or retail driveways, or 

stop sign controlled minor streets with only two or three vehicles per hour on the link, 

they would also be included in this number. Therefore, source/sink locations are pseudo 

nodes representing the aggregate of many minor traffic activities, and are not real nodes 

representing a single traffic activity. Entry/exit links can be used within the network for 

locations that both generate traffic and remove traffic from the network (such as very large 

parking garages). 

Negative flow values are specified for net flow off of the street. Positive flow values are 

specified for net flow onto the street. For example, ten vehicles per hour enter the street 

from a bank driveway but fifteen vehicles per hour leave the street into a strip mall 30.5 m 

(100 ft) downstream. These could be represented with a single source/sink with negative 

five vehicles per hour flow rate. Thus, source/sink locations can be used to reconcile 

minor differences between the number of vehicles entering and exiting a link. 

CORSIM treats the activity of the source/sink centroid as occurring mid-block. There is no 

disruption of the traffic flow when an auto or truck enters or exits the link (buses are not 

affected by source/sinks). Vehicles simply appear or disappear from the street at the 
84 

location of the source or sink without disrupting traffic (i.e., they do not slow down to 

exit). If there are major sources or sinks with continuous in and out activity that disrupts 

traffic flow through the time period, then these should be modeled as side streets with 

entry nodes and not with source sink locations. 

For the purposes of counting trips, vehicles that come from source nodes or that exit at 

sink nodes only count as half a trip because they only traveled half of the link. Vehicles 

entering from a source node travel the downstream half and vehicles exiting at a sink node 

travel the upstream half of the link. When COSRIM reports the number of vehicles 

discharged it reports all of the vehicles that reach the end of the link and get discharged 

onto the next link. It does not matter if they entered the link from a source node or if they 

entered the link from an upstream link. 

3.3.4 Vehicle Mix 

CORSIM allows four different fleets (passenger car, truck, bus, and carpool) and defaults 

to nine vehicle types. The vehicle mix is defined by the analyst, often in terms of the 

percentage of vehicles types at each entry node. Typical vehicle types in the vehicle mix 

might be passenger cars, single-unit trucks, semi-trailer trucks, and buses. Default 

percentages are usually included in most microsimulation programs; however, vehicle mix 

is highly localized and default values will rarely be valid for specific locations. For 

CORSIM, the default is for passenger cars only. If other vehicle types are required the 

analyst will need to input these values. A detailed discussion on vehicle mix is provided 

in appendix A. 

3.4 Traffic Control 

There are four types of traffic control data in CORSIM: freeway ramp meter data, sign 

control data, actuated signal control data, and pre-timed signal control data. Each of these 

control types is discussed in the remainder of this section. 

3.4.1 Freeway Ramp Meter Control 

CORSIM defines five types of on-ramp signal control strategies and the location of the 

detectors necessary for the application of metering strategies. The user may also specify an 

externally-defined ramp meter type that is not implemented inside CORSIM and that must 

be controlled using a Run-Time Extension (refer to appendix L for more information). 

Detectors must be set on the appropriate links for ramp meter controls that use thresholds 

for adjusting the metering rate. These should be set prior to setting up a traffic responsive 

ramp meter. The practitioner should be aware that once ramp metering is initiated in a 

simulation run, it cannot be “turned off.” 

Clock-time 

To simulate clock-time control of the on-ramp, a single, fixed headway is specified. The 

meter’s countdown clock is initialized to this value at the beginning of the red indication 
85 

and the signal is set to green each time the clock expires (returns to zero). For typical 

project/design analysis, the clock-time metering is usually sufficient control to evaluate 

project design alternatives. 

Demand/capacity 

The demand/capacity metering algorithm performs an evaluation of current excess 

capacity, immediately downstream of the metered on-ramp, at regular intervals, based on 

counts from the surveillance detectors on the freeway mainline. A maximum metering 

rate is calculated such that the capacity of this freeway section is not violated. In addition 

to the specification of the capacity, the user must specify the detectors on the link that will 

provide the input to the metering algorithm. 

Speed Control 

The algorithm for this form of ramp metering is similar to the demand/capacity strategy. 

A freeway link detector station must be established and identified at which speeds are 

evaluated and used to establish a metering rate. Generally, this detector location will be 

upstream of the on-ramp, although the logic does not preclude other placements. The user 

must specify a table of speeds and metering headways for the on-ramp. As each 

evaluation period concludes, the prevailing speed at the freeway detector station is 

compared to the tabulated minimum speeds to determine the proper metering rate. 

Multi-threshold Occupancy 

The algorithm for this form of ramp metering is similar to the demand/capacity strategy. 

A freeway link detector station must be established and identified at which occupancies 

are evaluated and used to establish a metering rate. Generally, this detector location will 

be upstream of the on-ramp, although the logic does not preclude other placements. The 

user must specify a table of occupancies and metering headways for the on-ramp. As each 

evaluation period concludes, the prevailing occupancy at the freeway detector station is 

compared to the tabulated minimum occupancies to determine the proper metering rate. 

ALINEA Control(9) 

The ALINEA ramp metering control uses a feedback strategy based on a linear regulator 

control system. ALINEA is an acronym for the French “Asservissement Linéaire d’Entrée 

Autoroutière”, which loosely translates to Linear Control of Entries to Motorways. More 

information on ALINEA metering is available in the TRAFED User’s Guide.(11)

HOV Bypass Lane 

If an HOV lane exists at a ramp meter, the ramp meter will not control the HOV lane. The 

vehicles in the HOV lane will bypass the ramp meter. 
86 

3.4.2 Arterial Control 

Sign Control 

Stop and yield signs can be modeled in CORSIM. The signs are placed at the downstream 

end of the approach link. Any or all approaches to an intersection may be stop sign 

controlled. All-way stops are implemented so that the first vehicle to reach the stop bar 

will have the right-of-way to discharge first. 

Sign control and right turn on red are subject to the gap acceptance parameters set in 

CORSIM. The gaps for right turning vehicles are checked against vehicles approaching 

from the left. Gaps for left turning vehicles are checked against vehicles approaching from 

the left, the right, and from the opposing link. The gap acceptance parameters can have a 

significant effect on the operation of sign control and should be calibrated to local 

conditions as necessary (see discussion on calibration in Chapter 5). 

Actuated Signal Control 

The actuated control model in CORSIM is an implementation of an eight-phase, dual-ring 

NEMA controller, as specified in the NEMA TS 1 and TS 2 standards. The model can be 

configured to emulate the operation of a Model 170 controller and many of its features, but 

the CORSIM terminology is taken from the NEMA specification. Figure 31 shows a 

sample TRAFED Actuated Control dialog screen. Refer to the TRAFED User’s Guide(11) for 

specific guidance on inputting data. It should be noted that it is possible to create arterial 

networks with signal control in Synchrotm and transfer the network to CORSIM for 

analysis. Additional details of this process are described under signal optimization, 

discussed later in this section. 

The CORSIM actuated controller can be configured to operate in one of three modes: fully 

actuated, semi-actuated, or semi-actuated coordinated. In fully-actuated mode, detection 

is provided on all approaches to the intersection, and the controller operates without a 

common background cycle (i.e., operating “free”). In semi-actuated mode, detection is 

provided only on the side-street approaches (and perhaps main-street, left-turn 

movements). The main street signals remain green until a call for service is placed by the 

side-street detectors. In this mode, the controller operates without a common background 

cycle (i.e., operating “free”). 

Semi-actuated, coordinated operation is used to provide progressive vehicle flow through 

a series of controlled intersections. In this mode, each controller in the coordinated system 

operates within a common background cycle length. The coordinator in the controller 

guarantees that the coordinated phases (generally phase 2 in ring 1 and phase 6 in ring 2) 

will display green at a specific time within the cycle, relative to a system reference point 

established by the specified cycle length and system synch reference time. An offset time, 

relative to the system reference point, is specified for each controller in the series to 

maintain the smooth progression of vehicles through the intersections. The coordinator 

also controls when and for how long non-coordinated phases can indicate green so that the 

controller will return to the coordinated phases at the proper time. A detailed discussion 

of Actuated Control as implemented in CORSIM is documented in appendix F. 
87 

 Figure 31. Illustration. TRAFED actuated control property dialog. 

Pre-timed Control 

Pre-timed signals can also be modeled in CORSIM. The models can simulate a multipledial traffic control system in which pre-timed timing plans can vary in offset, interval 

durations, and signal codes from one timing plan to another. The approaches to the 

intersection, the number of signal intervals, and the duration of each interval must all be 

input as well as the control facing each approach during each interval, such as green ball, 

amber ball, red ball, and green left turn arrow. If a left turn has an opposing through 

movement, CORSIM internally makes the turn permitted. Figure 32 shows a sample 

TRAFED Pre-timed Controller Property dialog screen. Refer to the TRAFED User’s 

Guide(11) for specific guidance on inputting data. 
88 

Figure 32. Illustration. TRAFED pre-timed controller property dialog. 

Amber intervals for single movements (e.g., left-turn arrows and right-turn arrows), with 

other movements retaining the green, are computed internally by the models. For these 

movements, the user specifies an amber code for the approach for the movement specific 

amber interval. The user then specifies the appropriate code for the green indications in 

the subsequent interval. CORSIM internally computes to which movement(s) the amber is 

applied. 

To simulate a multiple-dial system, the user must specify the type of transition between 

signal timing plans. Three transitions are possible: immediate transition; two-cycle 

transition; and three-cycle transition. The transition to a new timing plan occurs the first 

time a controller reaches main street green after the beginning of a new time period. The 

user must specify that interval number 1 is coded as main street green (i.e., the coordinated 

phase). Because no transition can occur for the first timing plan, no minimum value for 

main street green can be specified for Time Period 1. Even if only some of the controllers 
89 

change their timing from one timing plan to another, all intersections must have their 

timing specified for the new timing plan. 

Right Turn On Red 

CORSIM can model right turn on red. The user must select whether it is allowed or not at 

each approach to a node. 

Signal Optimization 

CORSIM does not optimize traffic signal timings. TRAFVU has a very rudimentary timespace diagram that shows the green time and slope of the free-flow speed. This is not to be 

used for detailed optimization of the signal times. For optimization of the signal timings, 

it is recommended to use a software product designed for such a purpose. SynchroTM has 

the capability of exporting its file data to TRF format. (The TRF file may not be formatted 

exactly correct.) TRANSYT-7FTM also has the ability to read in and write out the TRF file. 

TRANSYT-7FTM has a new feature called “Direct CORSIM Optimization”, whereby 

TRANSYT-7FTM uses a genetic algorithm to develop numerous timing plan alternatives, 

and then the alternatives can be simulated directly in CORSIM. Thus, an input file (TRF 

file) is created with the overall optimized timing plan, which can then be animated 

through TRAFVU. 

3.4.3 Review 

At this point in the base network development, the network should run in CORSIM 

without additional modifications. This is a good checkpoint. Save the TRAFED network 

and save it (translate it) to a TRF file. Run the network with CORSIM. Then open it with 

TRAFVU and review the animation. This is a cursory review of the network; a detailed 

review and error checking will come later. 

3.5 Traffic Operations and Management Data for Links 

CORSIM can model many types of traffic operations and management data, including 

incidents and events, pedestrian delays, on-street parking delays, and bus operations. 

3.5.1 Modeling Traffic Incidents or Events 

Traffic incidents or events in CORSIM are modeled as blockages in the road. They are 

displayed in TRAFVU as small red rectangles or roadway colors that designate the area of 

the incident. 

Surface Street Events 

CORSIM can model both short- and long-term interruptions to surface street traffic 

(known as "events"). Short-term events are events with an average duration of less than 60 

seconds that take place in the curb lane. Long-term events are longer-duration 

interruptions to traffic for any regular (non-pocket) lane. 
90 

Short-term events need to be specified only if one or more internal links on the analysis 

network experience short-term blockages due to illegal parking, standing, or stopping the 

curb lane only. If two events are scheduled concurrently, then they are combined in the 

curb lane. The blockage will be positioned where the earlier event begins and will remain 

until the later scheduled termination time is reached. 

Long-term events should be specified only if one or more internal links in the surface 

street subnetwork experiences long-term blockages due to roadway utility work, a vehicle 

crash, or a vehicle breakdown. 

Surface Street Parking: If curb parking activity is of sufficient intensity to impede moving 

traffic on a surface street link, then the user can specify parking activity for the link. Note 

that parking activity can take place only in lane 1 (curb lane) if a link is part of a two-way 

street. If the link represents a one-way street, then parking activity can impede moving 

vehicles in both curb lanes (left and right side). Also note that a parking lane is not 

reflected as a closed lane; a parking lane is simply not included in the number of lanes. 

Freeway Incidents 

A comprehensive freeway incident simulation procedure is provided in CORSIM. The 

user can specify either blockages or “rubbernecking” to occur on a lane-specific basis. 

Incidents could be used to model a traffic accident or a lane blockage due to road 

construction. Each incident occurs at the specified longitudinal position on a freeway link, 

extends over the user-specified length of the roadway, and lasts for any desired length of 

time. 

The character of an incident can change with time. For example, it is possible to specify a 

two-lane blockage that becomes a one-lane blockage after a specified duration. The lane 

from which the blockage is removed can then become unrestricted or subject to 

rubbernecking. 

“Rubbernecking” is where drivers slow down to look at incidents or anything else out of 

the ordinary on the highway. It affects the adjacent lanes or lanes in the opposing 

direction. Rubbernecking results in lower speeds and therefore lower capacity and can 

explain the additional capacity reduction beyond the physical blockage. Rubbernecking 

can be applied, without a corresponding blockage, to simulate a shoulder incident or 

reaction to an incident on the opposing roadway. The user can enter a factor indicating the 

reduction in capacity for vehicles traversing the affected lane segment. The rubberneck 

factor indicates the percentage of capacity reduction of each remaining lane that is not 

blocked during the incident.(12) 

The following rules should be followed when coding a blockage incident: 

• The length of the roadway that is blocked should be determined. A reasonable 

predictor of the affected roadway length is the number of vehicles involved plus 1 

times the average length of a vehicle. For example, assuming the length of each vehicle 

is 20 ft, a two-vehicle collision would be represented appropriately by a 60-ft blockage 

((2 veh+1) * 20 ft = 60 ft). 
91 

• Rubbernecking should be specified for the non-blocked lanes. 

• A secondary incident that consists only of rubbernecking should extend downstream 

from the primary incident. The length of the affected roadway should be the same as 

for the primary incident. 

• Another secondary incident can also be coded upstream of the primary incident to 

model vehicles reacting to the upcoming incident. 

• Another secondary incident can also be modeled for a different link that is adjacent to 

the incident. 

• The warning sign location should be set based on the type of incident. The warning 

sign for a long-term construction type incident should be set a long distance upstream 

to allow vehicles plenty of distance to change lanes out of the lanes that are blocked. 

The warning sign for an accident type incident should be set relatively close to model 

vehicles needing to merge into the non-blocked lanes. 

3.5.2 Incident Detection 

CORSIM has the capability of performing on-line and off-line freeway incident detection. 

In the on-line mode, incident detection is performed as CORSIM simulates the movement 

of vehicles through a specified network. When off-line incident detection or MOE 

estimation is requested, detector data will be stored in a data file and analyzed at the 

completion of the simulation run. See the CORSIM Reference Manual(1) for more 

information on incident detection algorithms. 

3.5.3 Bus Operations 

Bus operations in a network are described in terms of bus paths, station routes, and flow 

rates. CORSIM computes measures of effectiveness for buses on a route-specific basis. 

The delays and stops for buses are also included in the overall MOEs computed by 

CORSIM. 

Stations 

The bus stations are defined in terms of the link they are on, the type of station (whether it 

is protected or unprotected), the distance from the downstream node, and their capacity 

(in numbers of buses). The average time each bus stops (dwells) at a station as well as the 

dwell time distribution to use, along with the percentage of buses that do not stop (bypass) 

is also specified for the station. Bus stops cannot be specified on a freeway link. 

Buses frequently bypass bus stops because of the lack of passengers to pick up or unload. 

CORSIM will generate a warning message if the bypass percentage is between 90 percent 

and 100 percent, but it will still allow that value to be used. 
92 

On-street vs. Protected Bus Stations: CORSIM models lanes blocked by buses as on-street 

or unprotected bus stations. A protected bus station forms a bay to the side of a link 

where buses are out of the traffic flow. 

Bus Station as a Turn Bay: A station cannot be located within a turn pocket. However, a 

bus station may create a turn bay. The curb space reserved for a bus station located at the 

downstream end of a link can be used as a right-turn pocket when a protected station is 

unoccupied, provided that the position is less than or equal to 15.2 m (50 ft) from the 

downstream end, and the station number is less than 64. If the station number is 64 or 

greater, it will not be used as a right-turn pocket, regardless of its location. 

Dwell Times: After defining the locations of bus stations, the average (mean) time the bus 

spends stopped at each bus station should be defined. The “type” of station pertains to the 

statistical distribution of dwell times applicable to the station. This distribution is 

expressed as a percentage of the mean dwell time specified referenced by a random 

number between 1 and 10. The model accommodates six different station types. 

Path 

The bus path is the geometric series of nodes that the bus traverses as it travels through the 

network. The path can traverse interface nodes between subnetworks so that a path may 

cover both streets and freeways. Buses must enter the network from an entry node, and 

they can traverse both internal and interface nodes before exiting at an exit node. 

Route 

Each route is assigned a "route number," which is then used to identify the stations that 

buses may stop at along the route, the flow rates, and the release offsets. Each bus route is 

defined by the unique series of bus stations at which a bus stops as it traverses its path. It 

is possible for two bus routes to have the same path through the network but to serve 

different stations. 

Release Offset: Bus route offset can be used to offset the time at which a bus route emits 

buses. The first bus on this route will be delayed by the time specified, and then all other 

buses will be emitted based on the headway for the route. This feature is useful if two bus 

routes have the same route and headway through the network. One bus route can be 

given an offset so that a bus for each route will not enter the network at the same time. 

Headways: The final step in the specification of bus information is to define the flow rates, 

which must be specified for all routes. Bus flow rates for a route are defined in terms of 

the headway between buses on that route. Headways can be any integer value greater 

than zero. Values that are less than 30 seconds, however, will cause CORSIM to issue a 

warning that the value is low and should be checked by the user. Headways can appear in 

subsequent time periods to modify the flow rate. This can be used to generate higher flow 

rates in the rush-hour period and diminished flow rates in the post-rush-hour period. 
93 

3.5.4 Pedestrian Interaction 

If pedestrian activity is of sufficient intensity on some surface streets to impede moving 

traffic, then the user can specify pedestrian input for these links. Pedestrians will cross the 

intersection parallel to moving traffic and will cause delay to the right and left turning 

vehicles. The pedestrian interaction specified for this entry is applied to both sides of the 

link. This will cause right turn and left turn vehicles to pause for a randomly determined 

amount of time, which causes delay on the approach1. 

The duration of vehicular delay (in seconds) for each conflict period is defined by a 

statistical decile distribution that can also be changed by the analyst. Strong interaction 

delay for heavy pedestrian flow is twice the table values. By increasing or decreasing the 

amount of delay time in the strong and weak interaction periods, the analyst can change 

the amount of delay, and therefore, change the pedestrian flow rate that is modeled. In the 

past it was reported that pedestrian flow rate less than 100 pedestrians per hour could not 

be modeled by CORSIM. By reducing the amount of delay it would be possible to model 

smaller pedestrian flow rates. 

Review 

At this point in the base network development the network should run in CORSIM 

without more modifications. This is good a checkpoint. Save the TRAFED network and 

save it (translate it) to a TRF file. Then open it with TRAFVU and review animation. This 

is a cursory review of the network; a detailed review and error checking will come later. 

Rather than performing a single cursory review once the base model is complete, cursory 

reviews should take place at multiple steps in development of the base model, as 

highlighted in the numerous “Review” sections in this chapter. This will help ensure 

errors are caught as early as possible in the coding process. 

 

1 CORSIM can model random arrivals of pedestrians making a call at an actuated controller which sets 

the walk signal times. It is coded on the actuated controller at an intersection. The actuated controller 

pedestrian demand and the vehicle delay are not coordinated in any way. They are input and 

requested separately and operate independently. Both should be specified when modeling pedestrians 

at actuated controlled intersections. 
EXAMPLE

94 

3.6 Example Problem: Base Model Development 

This example continues with the HWY 100 interchange reconstruction project. The 

example for base model development will illustrate the a.m. peak period model to 

illustrate some of the key features. 

Create a TSIS Project and Set the Run Control Parameters 

The Run Control Parameters are the first model inputs that are asked for when starting in 

TRAFED. The key run control items for HWY 100 are as follows. 

Simulation Duration and Time Periods: The simulation duration for the a.m. peak period 

model was three hours sub-divided by 15-minute intervals. 

Start Time: The start time for the a.m. peak period model was 6:00 a.m., or 600 in military 

time. 

Entry Headway: The reviewing agency has specified that the entry headway distribution 

be changed from the default setting of a uniform distribution to an Erlang distribution. 

The Erlang distribution provides more variation in the entry volumes than the uniform 

distribution.

Initialization: The initialization time was set to 60 minutes, which should be adequate 

because networks of this size and type typically reach equilibrium well before 60 minutes. 

Link-Node Diagram: Model Blueprint 

The link-node diagram shown in Figure 33 was developed using criteria for node locations 

similar to the criteria in this chapter. The node numbering conventions used were nodes 

in the 100s for the northbound freeway and nodes in the 200s for the northbound freeway 

ramps. The node diagram was reproduced in CAD on the base mapping to convey to 

reviewers the model structure. 

Link Geometry Data was entered into the model based on the lane schematic and link 

node diagram information assembled in the data collection phase. 
EXAMPLE

95 

Figure 33. Illustration. Example problem: HWY 100 link-node diagram. 

Traffic Demand Data 

Traffic demand data for the HWY 100 model was extensive; therefore, a database method 

for automating the input was essential. With the large number of freeway ramps and 

arterial intersections, the amount of traffic demand data to be entered for 12-time periods 

was extensive. The input TRF file for one peak period for this model was nearly 6,000 lines 
EXAMPLE

96 

long. Manually entering this much information through TRAFED was judged impractical; 

therefore, a database method for automating the input was used. 

The types of traffic demand data used for this project included: 

• Arterial volumes were entered as entry volumes at entry nodes and turning 

percentages at intersections.

• Freeway volumes were entered as entry volumes at entry nodes and turn percentages 

at exit ramps. Additional origin-destination data for mainline freeway were estimated 

based on traffic counts and likely patterns. There are a number of closely spaced 

weave areas such as the cloverleaf interchange at TH 7 where none of the entering 

vehicles will exit at the next exit ramp. The O-D matrices as shown in Figure 34 were 

used to calculate the origin-destination for each mainline freeway direction. The 

calculations were converted into TRF format using a database. 

Exit Location

105 109 118 129

Detector 1051 1099 1275 2004

Name Station Node # Volume Vol Vol % Vol Vol % Vol Vol % Vol Vol %

TH 100 Northbound 377 103 251 34 0.14 20 0.08 26 0.10 32 0.13

TH 62 EB Entry 1263 108 91 0 0.00 0 0.00 12 0.13 15 0.16

TH 62 WB Entry 1267 112 115 0 0.00 0 0.00 15 0.13 19 0.16

Benton Ave. Entry 1271 114 11 0 0.00 0 0.00 1 0.13 2 0.16

50th St. EB Entry 1276 121 22 0 0.00 0 0.00 0 0.00 4 0.19

50th St. WB Entry 1277 123 34 0 0.00 0 0.00 0 0.00 6 0.19

36th St. Entry 2004r2 137 98 0 0.00 0 0.00 0 0.00 0 0.00

TH 25/TH 7 EB Entry 2018 145 83 0 0.00 0 0.00 0 0.00 0 0.00

TH 25/TH 7 WB Entry 2022 153 9 0 0.00 0 0.00 0 0.00 0 0.00

Minnetonka Blvd. Entry 2024r1 161 61 0 0.00 0 0.00 0 0.00 0 0.00

Cedar Lake Rd Entry 2034 170 21 0 0.00 0 0.00 0 0.00 0 0.00

I-394 EB Entry 2035 172 38 0 0.00 0 0.00 0 0.00 0 0.00

I-394 WB Entry 2040 175 53 0 0.00 0 0.00 0 0.00 0 0.00

Glenwood Ave Entry 2040r2 181 18 0 0.00 0 0.00 0 0.00 0 0.00

Entry Location

TH 100 Northbound (AM)

TH 62 EB Exit TH 62 WB Exit 50th St. Exit Excelsior Blvd. Exit

Figure 34. Illustration. Example problem: freeway origin-destination table. 

Intersection Traffic Control Data 

Traffic signals were actuated, but were coded as pre-timed signals to save time for this 

example. Data for coding signals was collected by reviewing signals in the field for cycle 

lengths, phasing, and interval timings and by examining the signal design and timing 

plans. 

Traffic Operations and Management Data 

The HWY 100 project was a design evaluation study. Evaluating ITS strategies and 

incidents were not part of the scope. However, after the design was selected, the final 

model could be used to test different management scenarios. 

Review 

After the base model was built and running, the model was checked by comparing 

QA/QC tables to link-node and coding schematic diagrams and by reviewing the 
EXAMPLE

97 

animation. The graphic shown in Figure 35 is a series of screen shots of the HWY 100 

Model that was reviewed. 

Figure 35. Illustration. Example problem: base model development review. 

99 

4.0 Error Checking 

Once the analyst is satisfied that the CORSIM 

model is fully coded, the analyst must then 

examine the model for completeness and 

errors. The error correction step is essential 

in developing a working model so that the 

calibration process does not result in 

parameters that are distorted to compensate 

for overlooked coding errors. There is a 

distinct difference between the error checking 

stage and the calibration stage. The error 

checking stage examines and removes the 

errors produced during model development. 

Conversely, the calibration stage involves 

adjusting the model parameters to assure the 

model will accurately reproduce local traffic 

conditions. The calibration process relies on 

the elimination of all major errors in demand 

and network coding before calibration 

begins. Error checking involves various reviews of the coded network, coded demands, 

and default parameters. 

Error checking proceeds in three basic stages: 

• Reviewing software errors. 

• Reviewing input data. 

• Reviewing animation. 

The practitioner should manage the error checking step by controlling the resources 

assigned to error checking, ensuring a consistent process is followed, staying on task (i.e., 

not rushing into calibration or alternatives analysis), and completing the task on schedule. 

The analyst should document the errors and the approach and techniques used for 

resolving them. 

4.1 Review Software Errors 

The analyst should review the software and user group Web sites to ensure that he or she 

is aware of the latest known “bugs” and user workarounds for the software. The analyst 

should ensure that he or she is using the latest version and “patch” of the software. 

W orking M odel

Before Calibration W orking Model

Before Calibration

4

7

Error Checking

1

Define the Project

- Define project purpose

- Identify influence areas

-Select approach

-Select m odel

-Estim ate staff tim e 

1 -

-

-

-

-

2 Data Collection

-Traffic volum es

-Base m aps/in ventory

-Field observations

2 -

-

3

Base Model Development

Input data

D evelop quality assurance 

3 -

-

- Review Inputs

- Review Animation 

See Chapter 1

See Chapter 2

See Chapter 3

See Chapter 4

W ork prior to

actual modeling

Initial modeling

Yes

Calibrated Model

5

-Volum es & Speeds m atch?

- Congestion in right places?

Compare Model

5 MOEs to Field Data 

-

-

See Chapter 5

Calibration

-Key Resu lts

- Technical D ocum entation 

6 -Forecast Demand

-Base Case

-Project A lternatives

Alternatives Analysis

-M odify G lobal Param eters

-M odify Link Param eters

-M odify Route Choice Param eters

Adjust Model Parameters

-

-

Final Report

Acceptable

Match?

N o

See Chapter 6

See Chapter 7

Model

Application
100 

Check the McTrans website (http://www-mctrans.ce.ufl.edu/) or the PCTrans website 

(http://www.ku.edu/~kutc/pctrans/) for known problems, issues, and updates of 

TSIS/CORSIM. 

Software errors can be tested by coding simple test problems (such as a single link or 

intersection) where the result (such as capacity or mean speed) can be computed manually 

and compared to the model. Some software errors can only be resolved by working with 

the software distributor or software developer. 

4.2 Review Input Data 

It is good practice to have an analyst familiar with the project, but not involved in the base 

model coding, perform the review of the input data. Subtle coding errors may be easier to 

detect from someone that has not been personally involved in the base model 

development. The analyst should check for data 

coding errors that may be causing the simulation 

model to represent travel behavior incorrectly. 

Subtle data coding errors are the most frequent 

cause of unrealistic vehicle behavior in a CORSIM 

model. Subtle coding errors include apparently 

correctly coded input that is incorrect because of how it is used in the model to determine 

vehicle behavior. Input data errors may happen for different reasons including: 

1. Mistakes. 

a. Typographic errors: Simply entering data wrong will definitely cause errors. For 

example, entering a turn percentage as 63 percent instead of 36 percent can have a 

large impact on the results. 

b. Failure to set a value (accepting the default): For ease of use, CORSIM has many 

default values. If the default value was not the intended or most realistic value, the 

results will not be the desired results. Setting a parameter that is known to be 

different from the default value during the model development phase or the error 

checking phase will save time during the calibration phase. 

2. Implementation errors. 

a. Misuse of the software. Trying to use CORSIM for a purpose that was not 

intended could cause errors. 

b. Misunderstanding of the software. Not understanding all the implications of the 

implementation could cause errors. 

3. Poor data collection. The collected data may have been correctly entered into the 

model, but was not collected correctly. This will cause the model to not reflect the real 

world. 

It is a good practice to use a different 

analyst to review input data for 

errors from the analyst that coded the 

base model. 
101 

4. Error in Analyst Expectations. The analyst should first verify the correct vehicle 

behavior in the field for the location and time period being simulated before deciding 

that the animation is showing unrealistic vehicle behavior. Many times, the analyst’s 

expectations of realistic vehicle behavior are not matched by actual behavior in the 

field. A videotape of the study area made during the data collection period is very 

helpful. Field inspection may also reveal the causes of vehicle behavior that are not 

apparent when coding the network from plans and aerial photographs. These causes 

need to be coded into the model if the model is expected to produce realistic behavior. 

A checklist for verifying the accuracy of the coded input data is provided below and 

available as a reproducible checklist in appendix G: 

1. Model run parameters. 

a. Check time periods and durations to ensure the full extent of congestion is 

captured. 

b. Verify fill time is long enough to allow the network to become fully loaded before 

collecting statistics. 

2. Link and node network geometry. 

a. Check basic network connectivity (are all connections present?). 

b. Check link geometry (lengths, number of lanes, free-flow speed, facility type, etc.). 

c. Check for prohibited turns, lane closures, and lane restrictions at the intersections 

and on the links. 

3. Demand. 

a. Check vehicle mix proportions at each entry node. 

b. Check identified sources and sinks for traffic. 

c. Verify volumes against traffic counts. 

d. Check vehicle occupancy distribution (if modeling HOV vehicles). 

e. Check turn percentages (if appropriate). 

f. Check origin-destinations of trips on the network. 

4. Control. 

a. Check intersection controls (control type, control data). 

b. Check ramp meter controls (control type, control data). 
102 

5. Traffic operations and management data. 

a. Verify bus operations, such as dwell times and bus paths, are coded reasonably. 

b. Check parking operations. 

c. Verify pedestrian operations and delays are properly accounted for in the model. 

6. Driver behavior and vehicle characteristics. 

a. Check and revise, as necessary, the default vehicle types and dimensions. 

b. Check and revise, as necessary, the default vehicle performance specifications. 

c. Check and revise, as necessary, the default driver behavior specifications. 

4.2.1 CORSIM Input Data 

There are many ways to review the input data. For example, it may be easier to use other 

tools than those built into TSIS. Many companies and individuals have created scripts that 

perform data entry and data transfer tasks. Reviewing the input data using the TSIS 

provided tools are described below. 

TRAFED 

In TRAFED each network object (e.g., links, nodes, and controllers) can be clicked on so 

the input data can be viewed and checked. 

The following techniques may be useful to increase the efficiency and effectiveness of the 

error-checking process: 

• Overlay the coded network over aerial photographs of the study area to quickly verify 

the accuracy of the coded network geometry. 

• Check for unintentionally superimposed links and nodes. Two or more nodes placed 

in the same location will look like a single node but the node numbers will overlap and 

not be readable in most cases. The links may connect to one of the nodes, but not to the 

other. 

• For a large network, a report summarizing the link attributes should be created so that 

their values can be easily reviewed. 

TRAFVU 

In TRAFVU, each network object can be clicked on to view their properties and checked 

against the input data. TRAFVU also has the advantage of being able to show the links 

and lanes in both “map” mode and “link-node” mode. 
103 

A network does not have to run in CORSIM to be able to be viewed in TRAFVU. This is 

very useful for checking errors produced during a CORSIM run. TRAFVU can show links 

that do not connect correctly or the placement of network objects like bus stations or 

parking zones that produce errors. 

Input Link Length vs. TRAFVU’s Calculated Length: TRAFVU also has the ability to 

compare the input link length to the “as drawn” link length. Each link’s property page 

shows both the input link length and the TRAFVU calculated link length. A list of links 

that are more than 6.1 m (20 ft) different between the input length and calculated length 

are accessible via the TRAFVU Window/Case Description menu item and by clicking on 

the Messages button on the Case Description dialog. These messages and distance 

advisories should be evaluated for validity. In some cases the input length is the correct 

length. In many cases however, TRAFVU’s calculation, which uses the stop bar to stop bar 

distance, is quite accurate. 

TRF File Review 

The TRF file is a text file that can be viewed with any text editor including the text editor 

built into TSIS. Comparing the TRF file parameters to the data collected during the data 

collection phase (stored in a spreadsheet format) is important to ensuring the correct data 

is being modeled. Unfortunately, reading the file is not the most straight-forward 

approach to data error checking and it does require knowledge of the TRF file record 

types. The records in the TRF file can be sorted so they are easier to review. Turn on 

sorting in the TRAFED preferences. The records will be sorted by their unique identifier 

(normally the first entry or the first two entries). 

4.2.2 CORSIM Diagnostics 

CORSIM itself can be used to check the network for errors and warnings. CORSIM checks 

all the network parameters to ensure they fall between the minimum and maximum 

values. It also checks against many other rules that exist. TRAFED checks many of these 

same ranges and rules to catch data input errors as they are input. However, TRAFED 

does not check every single rule that CORSIM checks so there may be error messages 

generated when the network is run through CORSIM. TRAFED can use CORSIM to do a 

diagnostic check of the input data by using the Network/Check menu item. Input errors 

will be displayed in the Output Window. 

Review Error Messages 

When running CORSIM there may be many 

errors and warnings. Some of these messages are 

due to input data errors, or they may be due to 

situations during the run that cause errors to 

occur. Error messages stop the execution of 

CORSIM. The errors must be corrected prior to 

continuing. It is advisable to fix the first error first and work down the list. Correcting the 

first error will sometimes correct subsequent errors. 

Fix CORSIM errors in the order they 

are listed, as correcting the first error 

will sometimes correct subsequent 

errors. 
104 

Review Warning Messages 

Warning messages may indicate significant potential problems that should be corrected or 

they may indicate conditions that should be evaluated and thereafter ignored. Each 

warning message should be investigated. If it is decided to allow the warning to remain, 

the reason for allowing it should be documented. A few such warnings are discussed 

below: 

• Input link length is less than the node-to-node distance. CORSIM makes a very 

crude check of the input link length versus the node-to-node distance. In some 

instances the surface link length can be significantly different from the node-to-node 

distance because it should be input as the stop bar to stop bar distance. In some 

instances the freeway link length for right-hand on and off-ramps can be significantly 

less than the node-to-node distance because the node location, as drawn by TRAFVU, 

is on the left side of the main freeway lanes. The message needs to be evaluated for 

validity. 

• Input speed versus curvature limited speed. The freeway free-flow speed calculated 

from the input values of roadway friction, curvature, and super elevation may produce 

a value that is less than the input free-flow speed. A message will be displayed to 

warn of the difference. The lower speed will be used during the simulation. The 

message needs to be evaluated for validity. 

• Vehicles backed up behind node. During simulation CORSIM reports the number of 

vehicles backed up behind an entry node in fifty-vehicle increments. This is often an 

indication that some network data was not input correctly. For example, the link 

length of the downstream link does not allow the correct amount of storage or the 

actuated control at the downstream intersection may not be operating as it does in the 

real world. If this increases throughout the simulation, or it is obvious from the 

animation that the vehicles are still backed up to an entry link at the end of the 

simulation, the delay incurred by these vehicles that did not enter the network should 

be included in the delay calculations for the network. 

4.3 Review Animation 

The importance of a comparison of model animation to field design and operations cannot 

be overemphasized. More than just a presentation tool, animation is a great debugging 

tool. The network has not yet been calibrated so the network may not operate exactly as it 

does in the real world, but the animation should at least be viewed in this step to make 

sure the modeled network is in a reasonable range with the real world. 

Animation output enables the analyst to observe the vehicle behavior that is being 

modeled and assess the reasonableness of CORSIM. Running the simulation model and 

reviewing the animation, even with artificial demands, can be useful to identify input 

coding errors. A two-stage process can be followed in reviewing the animation output: 
105 

1. Run the animation at an extremely low demand 

level (so low that there is no congestion). The 

analyst should then trace single vehicles 

through the network and see where they 

unexpectedly slow down. Uncharacteristic 

vehicle behavior (such as unexpected braking or stops) is a quick indicator of possible 

coding errors. These will usually be locations of minor network coding errors that 

disturb the movement of vehicles over the link or through the node. This test should 

be repeated along selected links in the network. 

2. Once the extremely low demand level tests have been completed, then run the 

simulation at 50 percent of the existing demand level. At this level, demand is usually 

not yet high enough to cause congestion. If congestion appears, it may be the result of 

some more subtle coding errors that affect the distribution of vehicles across lanes or 

their headways. Check entry and exit link flows to verify that all demand is being 

correctly loaded and moved through the network. 

The animation should be observed in close detail at key congestion points to determine if 

the animated vehicle behavior is realistic. If the observed vehicle behavior appears to be 

unrealistic, the analyst should explore the following potential causes of the unrealistic 

animation in the order shown below: 

• Overlooked data values that need refinement. Entering the wrong number of lanes, or 

the wrong channelization, are common mistakes. 

• Formation of persistent queues. Cyclical queues at signals that clear each cycle are not 

usually as critical unless they block some other traffic movement. Eliminating the 

cause of the persistent or primary queue may eliminate all secondary queuing. Thus, 

the analyst should focus on the few minutes just prior to formation of a persistent 

queue to identify the causes of the queuing. 

• Uncharacteristic vehicle operations (e.g., vehicles stacked on top of each other). The 

input link length may be different from the TRAFVU calculated link length. 

• Previously unidentified points of major ingress or egress (these might be modeled as 

an intersecting street). 

• Operations that CORSIM cannot explicitly replicate, such as a two-way center turn 

lane (this might be modeled as an alternating short turn bay). 

• Unusual parking configurations, such as median parking (this might be modeled 

operationally by reducing the free-flow speed to account for this friction). 

• Average travel speeds that seem excessive. 

• Turn bays that cannot be fully utilized because of being blocked by through traffic. 

Run the animation at an extremely 

low demand level (so low that there is 

no congestion). 
106 

• Bus stations modeled as unprotected stations that block traffic when they are protected 

stations in the real world. 

• Vehicles stopped or stuck on on-ramps. 

Check the on-ramp speeds, link lengths, lane 

types, and anticipatory lane changing 

parameters. Other parameters, such as the 

percentage of cooperative drivers may 

improve this problem. 

• In general, localized problems that can result in a system-wide impact. 

Someone who drives the area being modeled on a daily basis is normally quite familiar 

with the conditions that exist in the real world. These people are an excellent resource and 

should be used to review the animation of the network. With little effort, they can visually 

determine if the model is performing like the real world. 

4.4 Key Decision Point 

Before embarking upon model calibration, the analyst should confirm that error checking 

has been completed, specifically: 

• All input data are correct. 

• Values of all initial parameters and default parameters are reasonable. 

• Animated results look reasonable based on judgment or field inspection. 

Once the error checking has been completed, the analyst has a working model (though it is 

still not calibrated). If the error checking is satisfactory, the study can move to the next 

phase. 

However, if the errors cannot be resolved a decision must be made whether to recheck all 

the data that was collected, recheck all the model input data, bring in an expert to try to 

solve the problem, work around the error, redefine the study, find a different tool, or 

cancel the study. It is important to decide if the study can successfully achieve its 

objectives. This is a major decision point because the calibration phase of the study can be 

quite time consuming. CORSIM may not be the right tool for the study if the analyst is not 

satisfied that the model is producing reasonable results. If CORSIM is too limited, the 

analyst might seek an alternate software program without the same limitations. 

A potential cause of unrealistic 

vehicle behavior, observed with 

animation, is vehicles stopped on an 

on-ramp. 
EXAMPLE

107 

4.5 Example Problem: Error Checking 

The focus of the example problem for this chapter is the HWY 100 project (as discussed in 

previous chapters) in the northbound direction between Excelsior Boulevard and 

Eastbound TH 7 (nodes 127 to 145). 

Review Software Errors 

The latest version of CORSIM was used to model existing conditions and alternatives for 

the HWY 100 project. The distributor’s website was visited to determine if there were any 

known problems or patches that may affect the analysis. There were no known problems 

found. 

Review Input Data and Parameters 

After the model was coded, an internal and independent review was made of the model 

inputs including the geometry, traffic demand, and signal timing data. The verification 

was made by comparing the model inputs against the source data and by visual inspection 

of the TRAFVU animation file. 

The input data was reviewed by an independent party to ensure that data correctly 

reflected the source data. Different techniques were used to verify the input data against 

the real-world conditions. The following errors were found: 

• Geometry – a lane drop was not coded. 

• Geometry – a number of auxiliary lane lengths were not coded correctly. 

• Geometry – freeway links with curvature had incorrect link lengths. 

• Volumes – exit ramp turning volumes were incorrectly entered. 

The following sections identify how the geometric errors were discovered using the error 

checking methods described previously in this chapter. 

Geometry 

The source data is illustrated in a lane coding schematic and a link-node diagram shown in 

Figure 36 and Figure 37. The schematic includes the link length data, radius of curvature 

and the auxiliary lane lengths. The information was synthesized from aerials, mapping 

files, and the field review. 

 
EXAMPLE

108 

Figure 36. Illustration. Example problem: HWY 100 northbound lane geometry schematic. 

Figure 37. Illustration. Example problem: link-node diagram of HWY 100 interchanges. 
EXAMPLE

109 

Review Geometric Inputs: Tabular Data 

In order to verify that geometric data was input correctly a tabular summary of model 

inputs was reviewed and compared against the lane schematic figure. Table 9 is a 

summary of the base model in the key area being reviewed. 

Table 9. Example problem: geometric inputs with incorrect coding. 

Auxiliary Lane Geometrics

From To Node 

From 

Node

To

Receiving

Node

Length 

(feet) Type No. oflanes Grade SuperElev.

Radius 

(feet) No. Type* Length (feet) No. Type* Length (feet)

Excelsior Boulevard 

Exit 127 129 131 873 0 3 0 5 3300 9 2 200 

Excelsior Boulevard 

Exit 36th Street Exit 129 131 135 1140 0 3 0 6 2500 9 2 150 

36th Street Exit 131 135 136 1493 0 3 00 0 

135 136 137 1030 0 2 0 6 2800 

36th Street Entrance 136 137 141 585 0 2 00 0 

36th Street Entrance TH 25/TH 7 EB Exit 137 141 145 944 0 2 0 5 3500 9 1 150 9 2 100

TH 25/TH 7 EB Exit

TH 25/TH 7 EB 

Entrance 141 145 149 643 0 2 00 0 

TH 25/TH 7 EB

Entrance TH 25/TH 7 WB Exit 145 149 153 380 0 2 00 0 9 1 150 9 2 150

*Auxiliary Lane Type 1= Acceleration

2=Deceleration

000 incorrect geoemtric inputs

1st Aux. Lane 2nd Aux. Lane

TH 100 NB

Link Geometrics

Freeway 

Segment

Link Description 

Review Volume Inputs: Tabular Data 

Traffic volumes input into the model should be checked against the source database 

information. There are two basic methods for entering this information, manually or 

automated through an independent program. Regardless of the method, a back check of 

what is actually coded into the model versus what was intended should be conducted. 

The following table and figures illustrate how the volumes at the exit from southbound 

HWY 100 to westbound were verified. 

Table 10 below shows the portion of the freeway volume database required for coding the 

exit ramp volume to westbound TH 7 for Node 325. 

Table 10. Example problem: southbound HWY 100 at TH 7 westbound exit volumes. 

PM Peak Period Freew ay Volume Database

Time Period/End Time

1 2 3 4 5 6 7 8 9 10 11 12

Description Node 15:15 15:30 15:45 16:00 16:15 16:30 16:45 17:00 17:15 17:30 17:45 18:00

TH7 WB Exit Ramp 325 124 102 76 83 102 90 80 97 80 106 100 106

SB TH100 Thru 970 1045 1025 974 1037 1110 1133 1023 1077 1082 1070 1008

Using TRAFED, Node 325 is selected and the dialog box for the “Freeway Node 

Properties” is displayed as illustrated in Figure 38. The different time periods are selected 

and the volume inputs are checked against the database. From Table 10, time period 1 

shows the volume should be 124 veh/h exiting and 970 veh/h going through on 

southbound TH100. Figure 38 shows that time period 1 is coded correctly. 
EXAMPLE

110 

Figure 38. Illustration. Example problem: volume error check at node 325, time period 1. 

Continuing the error checking process, time period 4 from Table 10 was also checked. The 

table shows that there should be 83 veh/h exiting westbound and 974 veh/h going 

through on southbound TH 100. From Figure 39, time period 4 shows 830 veh/h exiting 

westbound indicating that there was an error when coding the volumes. 
EXAMPLE

111 

Figure 39. Illustration. Example problem: volume error check at node 325, time period 4. 

Review Signal Timing Data 

Checking signal timing includes interpretation of the signal timing sheets and signal 

design plans. The signal timing sheets are used to verify that signal timings and phasings 

have been coded correctly in the model. Figure 40 shows a sample signal timing sheet. 

Typical data to review include pedestrian walk and clearance times and yellow and all red 

clearance times. 

Volume Coding Error: 

Exiting Traffic is 83 not 830 
EXAMPLE

112 

Intersection Timings

Streets: Minneonka Boulevard And Toledo Avenue

PHASES 12345678

Direction EB SB WB EBLT

Roads Mtka Toledo Mtka Mtka

Min Green 10 6 10 6

Walk 0 14 8 0

Ped Clear 0 12 12 0

Veh Extension 4.0 3.5 4.0 3.0

Max Extension 0 0 0 0

Max 1 30 30 30 25

Max 2 0 0 0 0

Max 3 0 0 0 0

Yellow Clear 4.0 3.5 4.0 3.5

Red Clear 1.5 1.5 1.5 1.0

Red Revert 2.0 2.0 2.0 2.0

Acts B4 2 0 2 0

Secs/Actuation 1.9 0.0 2.4 0.0

Max Initial 20 0 25 0

Time B4 Reduction 10 0 25 0

Cars Waiting 10 0 10 0

Time to Reduce 10 0 10 0

Min Gap 3.0 0.0 3.0 0.0

Locking x x x x

Soft Recall x x

Phases on Recall

Section/L.T Head 3

Figure 40. Illustration. Example problem: sample signal timing sheet. 

The primary emphasis from the signal design plans is to verify lane assignments, traffic 

signal phasing, and physical features such as inductive loop detectors. The signal plan can 

be used to compare against the TRAFVU animation with detectors turned on. Figure 41 

illustrates a sample signal plan schematic showing detectors and phasing information. 

Figure 42 shows the same intersection in TRAFVU illustrating that a detector was not 

coded in the model that appears on the signal plan. For this example, the signals were 

coded as pre-timed to save time. Detectors were coded in the model in case future 

alternatives needed to show actuated signals. The illustration is provided as an example of 

a coding error. 
EXAMPLE

113 

Figure 41. Illustration. Example problem: sample signal plan schematic. 

Figure 42. Illustration. Example problem: TRAFVU detector error check. 

Detector 1 missing 
EXAMPLE

114 

Review Warning Messages 

During the translation from TRAFED to CORSIM a warning message was produced as 

displayed in Figure 43. The analyst then decided to view the geometry at this node in 

TRAFVU to investigate this warning message. 

Figure 43. Illustration. Example problem: warning message from TRAFED-CORSIM 

translation. 

Review Animation 

Geometric Inputs 

A review of the TRAFVU animation confirmed the lane drop warning shown in Figure 43 

that the geometry in this section was not coded properly. From the lane schematic 

drawing shown previously in Figure 36, a lane drop occurs 335.3 m (1,100 ft) downstream 

of node 131, or 119.7 m (393 ft) upstream of node 135, and not directly at node 135 as is 

currently coded. In addition, the lane drop should occur in the right-hand lane, not in the 

left-hand lane as is currently coded. The analyst noticed both of these errors in reviewing 

the TRAFVU animation and was thereafter able to correct these errors. 
EXAMPLE

115 

Figure 44. Illustration. Incorrect coding of lane drop. 

Key Decision Point 

After carefully reviewing all areas of the network while the network was animated and 

correcting previously found errors, it was determined that the network was modeled 

correctly. It was decided to start the calibration of the network. 

Incorrect coding 

of lane drop 

117 

5.0 Calibration 

Upon completion of the error checking step, 

the analyst has a working model. However, 

without calibration, the analyst has no 

assurance that the model will correctly predict 

traffic performance for the project. 

Calibration is the adjustment of model 

parameters to improve the model’s ability to 

reproduce local traffic conditions. 

CORSIM cannot be expected to perfectly 

match all possible real-world conditions and 

situations. CORSIM was designed to be 

flexible enough that an analyst can correctly 

calibrate the network to match the local realworld conditions at a reasonably accurate 

level. For the convenience of the analyst, 

CORSIM provides default values for the 

model parameters. However, only under rare 

circumstances will the model be able to produce accurate results for a specific area using 

only the default parameter values. 

Therefore, the importance of calibration cannot be 

overemphasized. Calibration is a required step 

during a traffic analysis to ensure the model can 

reproduce local driver behavior and traffic 

performance characteristics, and calibration should 

always be done prior to evaluating alternatives. 

Regardless of the size or complexity of the network, the analyst should always perform 

some level of calibration tests to ensure that the coded model accurately reproduces local 

traffic conditions and behavior. 

5.1 Objectives of Calibration 

The fundamental assumption of calibration is that the travel behavior models in the 

simulation model are essentially sound. There is no need to verify that they produce the 

correct delay, travel time, and density when they are given the correct input parameters 

for a link. It is the software developer’s job to perform verification by checking the accuracy 

of the software implementation. It is also the software developer’s job to perform 

validation of the model to ensure it produces data that is consistent with a wide range of 

real-world applications.(7) 

W orking M odel

Before Calibration W orking Model

Before Calibration

4

7

Error Checking

1

Define the Project

- Define project purpose

- Identify influence areas

-Select approach

-Select m odel

-Estim ate staff tim e 

1 -

-

-

-

-

2 Data Collection

-Traffic vo lum es

-Base m aps/in ventory

-Field observations

2 -

-

3

Base M odel Development

Input data

D evelop quality assurance 

3 -

-

- Review Inputs

- Review A nim ation 

See Chapter 1

See Chapter 2

See Chapter 3

See Chapter 4

W ork prior to

actual modeling

Initial modeling

Yes

Calibrated Model

5

-Volum es & Speeds m atch?

- Congestion in right places?

Compare Model

5 MOEs to Field Data 

-

-

See Chapter 5

Calibration

-Key Results

- Technical Docum entation 

6 -Forecast Demand

-Base Case

-Project Alternatives

Alternatives Analysis

-M odify G lobal Param eters

-Modify Link Parameters

-M odify Route Choice Param eters

Adjust Model Parameters

-

-

Final Report

Acceptable

M atch?

N o

See Chapter 6

See Chapter 7

Model

Application

Calibration is a required step during 

a traffic analysis to improve the 

model’s ability to reproduce local 

traffic conditions. 
118 

CORSIM comes with a set of user-adjustable parameters for the purpose of calibrating the 

model to local conditions. Therefore, the objective of calibration is to find the set of 

parameter values for the model that best reproduces local traffic conditions. 

5.2 Calibration Approach 

The calibration approach provided in this guide is based on the same approach 

recommended in Volume III.(7) Due to the nature of calibration, an analyst can end up in a 

circular process that seems to be never-ending. Fixing one problem may lead to new 

problems occurring somewhere else in the model. For this reason, the calibration process 

needs to be practical, logical, and sequential. 

Volume III identified a basic strategy that is summarized in Figure 45. The process begins 

by identifying the calibration MOEs and targets (i.e., thresholds where the differences 

between the field and model MOEs are acceptable). Once the calibration MOEs and 

targets are established, calibration should be performed in three basic steps: (7) 

• Calibrate capacity at key bottlenecks: This is an initial calibration of the capacity of key 

bottlenecks in the study area. These bottlenecks will be responsible for the majority 

of congestion (and thus delays and queuing) in the model. If the model cannot 

match the capacity at these bottlenecks, then the system performance MOEs will be 

nearly impossible to calibrate later in the process.

• Calibrate traffic volumes: CORSIM internally converts entry volumes and turning 

percentages into origin-destination percentages and then assigns routes for 

vehicles. This conversion results in a good approximation of volumes on small or 

linear models; however, discrepancies in link and turning movement volumes can 

occur for larger models with multiple routes possible between origins and 

destinations. In these cases, calibration of traffic volumes will be needed to ensure 

that the model volumes throughout the study area match those in the field. 

• Calibrate system performance: The overall model MOEs of interest that are used to 

measure system performance are calibrated in this step. Typical system 

performance MOEs include speed, density, travel time, delay, and queues. This 

step ensures that the model as a whole reasonably matches the local conditions. 

Within each of these steps, real-world MOEs measured in the field are compared to the 

MOEs estimated by CORSIM and, if they do not meet the established targets, then the 

model parameters are systematically adjusted until an acceptable match is found. This 

process continues through each of the three basic steps until all calibration targets have 

been met. Once the calibration targets have been met, then the model represents a close 

match to field conditions and the analyst is ready to move to the alternative analysis phase 

of the project. The following sections of this chapter provide more detail for each of the 

steps shown in Figure 45. 
119 

Figure 45. Flowchart. Calibration approach. 

As in the other tasks of the analysis process, it is important to manage and document the 

calibration process. For example, issues such as who made adjustments to the base model, 

what adjustments were made, where in the model the adjustments were being made, and 

why the adjustments were made should all be documented. Remembering who changed a 

default value from 1.8 to 1.9 and why that value was changed will be difficult six months 

after the calibration is complete. Maintaining control over the base network files and 

providing proper documentation of the calibration process will eliminate such questions. 

Documentation summarizing the calibration process and justification for the calibration 

adjustments, such as supportive MOE statistics that document how the calibration process 

provided a closer match to field conditions, should be included as part of the final report 

and possibly an interim technical memorandum. 

Establish Calibration 

MOEs and Targets 

(see Section 5.3)

Calibrate Capacity at 

Key Bottlenecks 

(see Section 5.5)

Calibrate Traffic 

Volumes 

(see Section 5.6)

Calibrate System 

Performance 

(see Section 5.7)

Are All 

Calibration 

Targets Met? 

No 

Model is Calibrated 

(go to Chapter 6) Yes 

Field MOEs Model MOEs 

Acceptable 

Match? 

Yes 

Adjust Model 

Parameters 

Go to Next 

Calibration Step

No 

Process for Each Calibration Step
120 

5.3 Establish Calibration MOEs and Targets 

Before starting the process of calibration, it is important to select which MOEs to calibrate 

and target thresholds for those MOEs. Establishing calibration MOEs and targets upfront 

allows consensus to be built by all parties involved on the degree of error allowed in the 

calibration process and, as well, provides a “blueprint” for which MOEs to focus on and at 

which point to stop the calibration process. 

5.3.1 Selection of Calibration MOEs 

CORSIM accumulates and calculates hundreds of MOEs. Some of these MOEs can be 

measured in the real world, such as average speed and traffic volumes. Other MOEs, such 

as fuel consumption and vehicle emissions, are very difficult and expensive to measure in 

the real world. System-wide MOEs, such as vehicle-miles traveled (VMT) and vehiclehours traveled (VHT), are another example of MOEs that are difficult and expensive to 

collect in the field. Overall, the selection of MOEs for calibration is limited to those that 

can be practically collected in the field and are 

accumulated and reported in CORSIM. Even if 

the MOE is the critical MOE used in the 

alternatives analysis, if it cannot be measured in 

the field, then it cannot realistically be included as 

a calibration MOE. 

Capacity MOEs 

The first step in the calibration process is to calibrate the capacity at key bottlenecks. 

CORSIM, like other microsimulation models, does not output a number called “capacity.” 

Rather, the capacity can be estimated by measuring the maximum throughput at the 

bottleneck location. The throughput should only be collected when a queue is continually 

present upstream of the bottleneck, as this is the only time when throughput can be used 

to determine the capacity of a given location. Measuring the throughput downstream of a 

queue is sometimes referred to as the queue discharge rate, which is often slightly lower 

than the maximum flow rate before flow “breakdown” (i.e., when traffic flow transitions 

from uncongested to congested conditions). For calibration purposes, it is recommended 

to use the queue discharge rate as the capacity MOE for freeway bottlenecks, rather than 

maximum flow before breakdown, because the discharge rate is more stable and much 

easier to measure in the field. Section 2.4 of this volume, along with section 5.3.2 of 

Volume III,(7) discusses measuring capacity in the field in more detail. In CORSIM, the 

capacity on freeways can be measured using the “Vehicles Out” MOE for the link 

immediately downstream of the bottleneck location, so long as there is a continuous queue 

upstream of the bottleneck for the measurement period. 

On surface streets, bottlenecks are most often located at traffic signals and stop-controlled 

intersections. The capacity of an approach at a traffic signal is directly related to the 

discharge headway at the stop line (the capacity is a function of the discharge headway 

and the proportion of effective green time given for that approach). Section 2.4 of this 

volume, along with sections 5.3.1 and 5.3.2 of Volume III,(7) discusses measuring capacity 

The selection of calibration MOEs 

is limited to those that can be 

practically collected in the field and 

are accumulated in CORSIM. 
121 

at intersections in more detail. In CORSIM, the “Vehicles Discharged by Lane” MOE can 

be used to estimate the model capacity, so long as there is a continuous queue upstream of 

the intersection approach of interest for the measurement period. 

Traffic Volume MOEs 

The second step in the calibration process is to calibrate the traffic volumes, which consists 

of ensuring that the link and turning movement volumes in the CORSIM model match the 

field traffic counts. On freeways, “Vehicles In,” “Vehicles Out,” and “Volume” are all 

reported on individual links by CORSIM. On surface streets, “Average Volume” and 

“Vehicles Discharged by Lane” are reported on individual links by CORSIM. “Vehicletrips” is reported for each turning movement on CORSIM surface streets. Any of these 

MOEs can be used to calibrate field measured volumes, as long as the field measurement is 

defined and measured similarly to the MOE used in CORSIM. For example, a 15-minute 

average turning count at an intersection is a typical field measurement. To calibrate this 

measured volume, an analyst would need to obtain a 15-minute average of the “Vehicles 

Discharged by Lane” for the particular turning lane from the CORSIM output, taking care 

not to obtain the cumulative count over the entire simulation period. 

System Performance MOEs 

The third, and likely most difficult, step in the calibration process is to calibrate the system 

performance of the model. Types of MOEs to use in the system performance calibration 

include speed, density, travel time, delay, stops, and queues. CORSIM measures all of 

these types of MOEs, often in many different forms. For example, CORSIM measures the 

“Delay Time,” “Stopped Time,” “Queue Delay,” and “Control Delay” on surface street 

links, expressed in seconds per vehicle. The key is to select the delay MOE for calibration 

which matches how delay was measured in the field. This will ensure an “apples-toapples” comparison between field and model MOEs. For example, if stopped time was 

collected in the field, then the “Stopped Time” MOE should be used in CORSIM for system 

calibration. 

The scope of the analysis will also help define the 

system performance calibration MOEs. For 

example, if the purpose of the analysis is to test 

different bus route alternatives, the calibration 

MOEs should include MOEs related to bus 

routing. 

5.3.2 Establishing Calibration Targets 

Once the calibration MOEs have been selected, the project team should then establish 

calibration targets for these MOEs. The objective of model calibration is to obtain the best 

match possible between model and field measurements of MOEs. However, there is a 

limit to the amount of time and effort anyone can put into eliminating error in the model. 

There comes a point of diminishing returns where large investments in effort yield small 

improvements in accuracy.(7) The purpose of setting calibration targets is to set a stopping 

point for fine-tuning the calibration and consider the model calibrated. 

The key in selecting calibration 

MOEs is to select MOEs from 

CORSIM that match how MOEs 

from the field were measured – this 

ensures that an “apples-to-apples” 

comparison is made. 
122 

There are no standards on acceptable calibration targets, as the targets will likely vary 

according to the size of the model, resources available, the purpose and objectives of the 

project, and the types of decisions that will be made from the simulation analysis. For 

example, large simulation models will probably have less stringent targets than small 

models due to the difficulty in matching MOEs for all links in a large, complex network. 

Also, using the simulation analysis to test finely-tuned signal optimization plans will 

require more stringent targets than using the model for determining the number of 

freeway lanes needed. 

Calibration targets can be relatively straight-forward, such as having a target of all model 

MOEs for all network links being within 10 percent of the field MOEs. Such a simple 

calibration target plan is best suited for small, straight-forward modeling projects. 

However, for larger models, a more sophisticated set of targets may be necessary; in 

particular, a set of targets that acknowledges that it will be very difficult to ensure all links 

within the network will meet the target. For larger networks, it is important to focus on 

matching MOEs at critical locations in the network (i.e., bottleneck locations or locations 

where roadway improvements are being considered), as many hours can be wasted on 

calibrating portions of the network that will not have an impact on the final results or 

recommendations. 

Table 11 provides an example of calibration targets that were developed by Wisconsin 

DOT for their Milwaukee freeway system simulation model.(7) They are based on 

guidelines developed in the United Kingdom.(13) These targets acknowledge the difficulty 

in matching all links in the network to field conditions, as the targets ensure that at least 85 

percent of the links are within a target percentage or value of the field conditions. This 

table is provided merely as an example, as the calibration targets should be tailored to the 

specific analysis at hand. As mentioned previously, the calibration targets will likely vary 

depending on factors such as the size of the model, resources available, purpose and 

objectives of the analysis, and types of alternatives analyzed. The project team should 

develop consensus on specific calibration targets before proceeding with the calibration 

effort. 
123 

Table 11. Wisconsin DOT freeway model calibration targets.(14)

MOE Criteria Calibration Acceptance 

Targets 

Hourly Flows, Model versus Observed 

Individual Link Flows 

 < 700 veh/hr Within 100 veh/hr of Field 

flow for > 85% of cases 

 700 to 2,700 veh/hr Within 15% of Field flow for 

> 85% of cases 

 > 2,700 veh/hr Within 400 veh/hr of Field 

flow for > 85% of cases 

 

Sum of all link flows Within 5% of sum of all link 

counts 

GEH Statistic* for individual link flows GEH < 5 for > 85% of cases 

GEH Statistic for sum of all link flows GEH < 4 for sum of all link 

counts 

Travel Times, Model versus Observed

Journey Times, Network Within 15% (or 1 min, if 

higher) of > 85% of cases 

Visual Audits 

Individual Link Speeds Visually acceptable speedflow relationship to analyst’s 

satisfaction 

Bottlenecks Visually acceptable queuing 

to analyst’s satisfaction 

 * - The GEH Statistic is computed as shown in Figure 46 below. 

where: E = model estimated volume 

 V = field count 

Figure 46. Equation. Calculating the GEH Statistic.(14) 
124 

Another example of suggested calibration targets is “Theil’s Inequality Coefficient,” which 

is broken down into three parts, each of which provides information on the differences 

between the model measures and the target measures. Further discussions on Theil’s 

Inequality Coefficient can be found in the Advanced CORSIM Training Manual(2) and in 

Hourdakis, Michalopoulos, and Kottommanil(15). 

5.4 CORSIM Run Considerations 

The calibration approach described in this chapter requires the analyst to run, or apply, 

CORSIM for the existing or baseline conditions many times, until the model MOEs 

adequately match the field (real-world) MOEs. The CORSIM User’s Guide(1) describes in 

detail the steps required to run CORSIM. The purpose of this section, however, is to 

discuss some key issues that the analyst should consider when running CORSIM during 

the calibration step. 

5.4.1 Multiple CORSIM Runs 

Due to the stochastic nature of CORSIM, the results from individual runs can vary by 25 

percent and higher standard deviations may be expected for facilities operating at or near 

capacity.(7) Thus, it is necessary to run CORSIM multiple times with different random 

number seeds to gain an accurate reflection of the performance of the model. The 

CORSIM Driver Tool has a built-in multiple-run capability and a built-in output processor 

that collects statistics from each run and summarizes them. The multi-run capability runs 

a test case multiple times, changing the random number seeds for each run. Refer to 

Appendix D for more information on the usage of random seed values in CORSIM. The 

output processor collects user-selected MOE data for selected links from CORSIM over 

multiple runs and organizes the data into a single summary file. When output processing 

is selected, a statistics file (or files, depending on how many formats are selected) is 

created. These files are overwritten if they already exist, and are created if they do not 

exist. The benefits of using the multi-run feature include: 

• Data from multiple runs are automatically summarized based on user-selected MOEs 

and statistics, eliminating unnecessary time and errors that could be made in manually 

compiling statistics from multiple runs. 

• The feature is very flexible in that it allows the analyst to select just one, or all, of the 

MOEs to summarize statistics across multiple runs. 

• The analyst can select from a wide range of summary statistics to be automatically 

calculated based on the selected MOEs, such as the mean, median, standard deviation, 

and 95th confidence interval. 

• Use of the tool encourages analysts to account for the stochastic nature of CORSIM. 

When the base model is satisfactory, the number of runs has been set, and MOE selection 

is complete, the model should be run multiple times using the CORSIM multi-run feature. 

When all runs are finished, the output processing will write data to the selected file types. 
125 

This may take some time depending on the size of network, length of run, number of 

MOEs selected, number of network objects selected, and number and type of statistical 

processing. 

After the multiple runs of CORSIM have been completed, the analyst should review the 

output to verify that all of the individual runs finished correctly. Under certain 

circumstances, the CORSIM simulation may encounter exceptional conditions and be 

unable to complete a run. If this happens, statistical data for that run will be discarded 

and will not factor into the analysis functions (such as Mean and Standard Deviation). The 

analysis functions will be applied as if that run had not occurred. Refer to the CORSIM 

User’s Guide(1) for more information on setting up and starting multiple runs of CORSIM. 

Determining the number of times to run the simulation depends on two primary variables: 

the variance in the mean of one or more MOEs, and the tolerable error as selected by the 

analyst. The sample size required for the selected tolerable error calculates the minimum 

number of simulation runs (i.e., the sample size) required to produce results with a 

“sampling error” less than or equal to the tolerable error entered by the user. The formula 

for the sample size calculation is: 

Figure 47. Equation. Determining the appropriate number of simulation runs to complete. 

The CORSIM output processor can calculate how many runs are necessary to achieve 

results that are within the tolerable error. Refer to the “Formats and Options” dialog in the 

CORSIM User’s Guide(1) for information on selecting the option to calculate the required 

number of runs. In order to calculate the number of runs, a preliminary set of runs must 

be made. Twenty runs should produce enough variance to calculate a reasonable number 

of runs for the statistical analysis. 

5.4.2 Simulation Time Frame 

The time frame to simulate should have been decided in the scope of the project (chapter 1) 

so that the data collection (chapter 2) would be based on that time frame. Prior to this 

stage in the model development process (chapter 3), a short simulation time may have 

been used for error checking. Make sure the start time and duration of the simulation 

reflect the period designated in the scope of the project and represented in the demand 

data. 
126 

5.4.3 Exclusion of Initialization Period 

The artificial period where the simulation model begins with zero vehicles on the network 

(referred to as the “initialization period” or “fill period”) must be excluded from the 

reported statistics for system performance. CORSIM will do this automatically. The 

initialization period typically ends when equilibrium has been achieved. Equilibrium is 

achieved when the number of vehicles entering the system is approximately equal to the 

number leaving the system. The algorithm used by CORSIM does not work properly in all 

circumstances. For example, if the data collected during a run shows a sharp decrease in 

value soon after the initialization period, it is a good indication that equilibrium was not 

reached. Thus, the analyst should check the CORSIM output data to ensure equilibrium 

has been reached in the CORSIM run. Model output should not be used if equilibrium has 

not been reached, as the results will not represent the actual volumes attempted to be 

modeled. Appendix C has a more in depth discussion of the initialization period. 

5.4.4 Link Aggregations into Sections 

CORSIM can treat a particular set of links as a single entity for the purpose of computing 

significant MOEs over multiple links. Each such set is known as a “link aggregation” or 

“section” and is identified by a user-defined section number. 

Any surface links within the network can be specified as part of a section; however, the 

links do not have to form a continuous path through the network. It is possible to 

aggregate any set of links into a section. 

When this option is selected, an additional output table is provided within each standard 

cumulative output. This table presents aggregated statistics for each section identified. 

The full set of statistics is still provided for each link individually in the link statistics table. 

5.5 Calibrate Capacity at Key Bottlenecks 

As shown above in Figure 45, calibrating the capacity at key bottlenecks is the first step in 

the calibration process. Having a CORSIM model that can replicate the location and 

severity of bottlenecks in the field is a crucial initial step in calibration, as these bottlenecks 

will be responsible for the majority of congestion throughout the network. Thus, if the 

model cannot replicate the throughput at bottlenecks, then it will be very difficult to 

calibrate the system performance MOEs later in the calibration process. 

This step is performed by evaluating a few key points in the network and adjusting the 

model parameters in a systematic manner until the throughput volume just downstream of 

these bottlenecks can be matched between the field and model. As mentioned earlier in 

section 5.3, it is recommended to measure the queue discharge rate downstream of the 

bottleneck as the measure of capacity, rather than the maximum flow before breakdown 

(which is typically slightly higher than the queue discharge rate) because the discharge 

rate is more stable and much easier to measure both in the field and in CORSIM. Figure 48 

shows some typical bottleneck locations on freeways. 
127 

If the model does not initially show congestion at the same bottleneck locations as exist in 

the field, then the demands coded in the model should be temporarily increased to force 

the creation of congestion in the model at those bottlenecks. These temporary increases 

should be removed after the capacity calibration has been completed. On the other hand, 

if the model initially shows congested bottlenecks at locations that do not exist in the field 

(i.e., false bottlenecks), it will be necessary to increase the capacity of the model at these 

points to remove the false bottleneck from the model.(7)

Figure 48. Illustration. Typical freeway bottleneck locations. 

5.5.1 Freeway Capacity Calibration 

There are many parameters in CORSIM that affect the freeway capacity, so it is important 

to narrow the list to a few parameters that are the most sensitive to capacity. A recent 

sensitivity test was completed on all CORSIM parameters relating to driver behavior logic. 

This test is documented in the report entitled, Identifying and Assessing Key Weather-Related 

Parameters and Their Impacts on Traffic Operations Using Simulation.(16) Based on this study, 
128 

and past experiences with real-world simulation studies, the candidate list of key 

parameters to adjust for calibrating freeway capacity include: 

• Car following sensitivity factor – This is a global parameter that affects all freeway links. 

This value represents the primary factor in calculating the desired time headway (in 

seconds) between a leader-follower pair. A higher value means more space between 

vehicles and thus a lower capacity. Each driver type has a different value (ranges from 

1.25 seconds for conservative drivers to 0.35 seconds for aggressive drivers, with a 

mean value of 0.80 seconds). 

• Car following sensitivity multiplier – This parameter can be adjusted for each individual 

link and represents a multiplier of the car following sensitivity factor. The default 

value is 100 percent; thus increasing this value for a specific link to 110 percent (as an 

example) would increase the individual car following sensitivity factor for each driver 

type by 10 percent on that link. Increasing this value means more space between 

vehicles and thus a lower capacity. 

• Lag acceleration and deceleration time – These are global parameters (acceleration and 

deceleration time are two separate parameters) that affect all freeway links. These 

values represent the time delay due to perception/reaction time for drivers when 

starting to accelerate or decelerate. A higher value for these parameters means slower 

reactions, which translates to a lower capacity. The default values for these parameters 

are 0.3 seconds. 

• Pitt car following constant – This is a global parameter that affects all freeway links. This 

value represents the minimum distance between the rear of the lead vehicle and front 

of the following vehicle. A higher value for this parameter means more space between 

vehicles and thus a lower capacity. The default value is 3.05 m (10 ft). 

These parameters are directly related to the car following logic within FRESIM. There are 

also 10 parameters related to the lane changing logic within FRESIM; however, altering 

these parameters is typically not worthwhile because they are not very sensitive to 

aggregate measures (i.e., 15-minute averages) of throughput.(16) 

Table 12 shows an example of adjusting the car-following sensitivity factor in an attempt 

to increase the freeway capacity. In this example, the default values for each driver type 

were decreased by 10 percent, which will create less space between vehicles and thus 

increase the capacity. Note that decreasing all driver type values by 10 percent is 

equivalent to decreasing the “Car following sensitivity multiplier” for all freeway links on 

the network by 10 percent. 
129 

Table 12. Example adjustment of the car-following sensitivity factor. 

Driver Type 

Case 1 2 3 4 5 6 7 8 9 10 

Default 1.25 1.15 1.05 0.95 0.85 0.75 0.65 0.55 0.45 0.35 

10% 

Decrease 

1.13 1.04 0.95 0.86 0.77 0.68 0.59 0.5 0.41 0.32 

Out of the parameters described above, the “Car following sensitivity factor” and linklevel multiplier of that factor are the most sensitive to changes in the default values when 

attempting to alter the capacity at a bottleneck. Figure 49 shows an example of the 

sensitivity of throughput to changes in the “Car following sensitivity multiplier.” The test 

network for this figure was a basic freeway segment with three lanes. The maximum 

throughput on the segment represents the capacity of the segment. As shown in the 

figure, increasing the “Car following sensitivity multiplier” for the freeway link results in a 

proportional decrease in capacity. Increasing the multiplier from 100 to 125 results in an 

approximately nine percent decrease in capacity (from 2,200 to 2,000 veh/h/ln). 

1000

1200

1400

1600

1800

2000

2200

2400

1000 1500 2000 2500

Entering Volume (veh/hr/ln)

Throughput (veh/hr/ln)

100 125 150 175 200

Car Follow ing 

Sensitivity 

Multiplier Values:

Figure 49. Figure. Example of sensitivity of car following sensitivity 

multiplier on throughput of a basic freeway segment. 

Attempts to match field-measured bottleneck capacity should first focus on the key global 

parameters, starting with the “Car following sensitivity factor” and then the “Lag 

acceleration and deceleration time” and “Pitt car following constant.” Attempts to 

increase the freeway capacity on the network would require decreasing the values of these 

parameters from their default values. While it is possible to just focus on link-level 

parameters such as the “Car following sensitivity multiplier”, a global adjustment ensures 

the accuracy of the capacities on all links (even those not currently congested), rather than 

only those on specific links.(7) 
130 

In cases where there are multiple freeway bottlenecks, some of which require the model 

capacity to be increased and others which require the model capacity to be decreased, then 

adjusting the global factors by themselves will not be sufficient. In this case, the link-level 

“Car following sensitivity multiplier” value may need to be adjusted separately for each 

bottleneck calibration. This link-level calibration may be needed when the bottleneck is 

due to a local condition not present in the remainder of the network, such as a horizontal 

curve, vertical curve, or narrow lanes. 

In addition to the key parameters listed above, many of the input values entered in the 

base model development step (chapter 3) also have an impact on capacity, such as the 

percentage of trucks; origins and destinations within weaving areas; and the placement of 

warning signs for anticipatory lane changes, exit ramps, and lane drops. The values 

entered for these parameters should be entered in the base model development step based 

on field data collection and, thus, should be known and set values. However, if the key 

parameters listed above do not have the desired impact in calibrating capacity, then slight 

modifications to these additional capacity-altering parameters may be warranted. 

For example, when CORSIM vehicles cross warning sign “reaction points”, vehicles begin 

to react to downstream conditions or begin to target a new lane (e.g., targeting an exit 

ramp or moving away from a lane drop). Refer to chapter 3 of this volume, or the 

CORSIM User’s Guide(1), for more information on warning sign parameters. In general, 

moving these warning sign locations further upstream will result in smoother, less 

turbulent lane changing conditions and can thus increase the capacity of a bottleneck. 

5.5.2 Surface Street Capacity Calibration 

As mentioned previously, surface street bottlenecks are primarily created by traffic signals 

or stop-controlled intersections and, thus, capacity calibration on surface streets should 

focus on a few key intersections. The candidate list of parameters to adjust for calibrating 

the capacity of signalized and stop-controlled intersections includes: 

• Mean discharge headway – This is a link-level parameter that represents the mean 

headway between vehicles discharging from a standing queue. The default value 

is 1.8 seconds. Increasing this value will result in a decrease in capacity. This 

parameter is useful in calibrating the capacity of signalized intersections. 

• Mean startup delay – This is a link-level parameter that represents the mean delay 

due to perception/reaction time of the first vehicle in a queue due to a traffic 

signal. The default value is 2.0 seconds. Increasing this value will result in a 

decrease in capacity. This parameter is useful in calibrating the capacity of 

signalized intersections. 

• Acceptable gap in oncoming traffic (left turns and right turns) – These are global 

parameters (left turns and right turns have separate parameters) that represent the 

acceptable gap in crossing traffic that a vehicle will accept while making a 

permitted left turn or a right turn on red (RTOR) at a traffic signal. Each driver 

type has a different value (the left turn values range from 7.8 seconds for 

conservative drivers to 2.7 seconds for aggressive drivers, with a mean value of 5.0 
131 

seconds). Increasing these values will result in vehicles waiting longer at signals 

and thus lowering the capacity for these movements. 

• Cross-street acceptable gap distribution (near-side and far-side) – These are global 

parameters that represent the acceptable gap in crossing traffic that a vehicle will 

accept while at a stop sign. Each driver type has a different value (the near-side 

values range from 5.6 seconds for conservative drivers to 2.0 seconds for aggressive 

drivers, with a mean value of 3.8 seconds). Increasing these values will result in 

vehicles waiting longer at stop signs and thus lowering the capacity of the 

approach. Vehicles at yield-controlled intersections will subtract 1.5 seconds from 

these values to calculate their acceptable gap in crossing traffic. 

For calibrating signalized intersection approaches, the capacity is most sensitive to the 

“Mean discharge headway” parameter and, thus, attempts at calibration should focus first 

on this parameter, followed by the “Mean startup delay” parameter. Figure 50 shows an 

example of the sensitivity of throughput to changes in the “Mean discharge headway.” 

The test network for this figure was a fully-actuated signal with two through lanes and a 

separate left turn lane with a protected left turn phase. The maximum throughput on the 

segment represents the capacity of the segment. As shown in the figure, increasing the 

“Mean discharge headway” for the approach link results in a proportional decrease in 

capacity. For example, increasing the value from 1.9 to 2.2 seconds results in an 

approximately 12 percent decrease in capacity (from 5,180 to 4,540 veh/h). 

3000

3400

3800

4200

4600

5000

5400

3000 3500 4000 4500 5000 5500 6000

Total Entering Volume (veh/hr)

Throughput (veh/hr)

19 22 25 27 30

Mean Discharge 

Headw ay values

(19 = 1.9 seconds):

Figure 50. Figure. Example of sensitivity of mean discharge headway on 

throughput of a signalized intersection approach. 

The distribution of discharge headway and startup delay can be edited on a global scale 

using the distribution codes by driver type for these two parameters. However, changing 

the distribution of these values is not recommended because a recent sensitivity test of 

these distributions showed that they are not sensitive to aggregate MOEs such as 15-

minute averages of throughput, speed, and/or density.(16)
132 

Another consideration in the calibration of signalized intersection approaches is that the 

green time given to the approach in the model matches that in the field. The green time for 

the approach directly affects the capacity of the approach, so ensuring the model is 

consistent with the field will make this calibration effort much easier. For actuated signals 

that are operating at or over capacity, this can simply be done by checking that the 

maximum green time coded in the model matches that in the field. 

The parameters related to acceptable gap listed above are only adjustable on a global scale; 

thus, calibrating individual stop-controlled or permitted left-turn movements is not 

possible in the most recent version of TSIS/CORSIM (version 6.0) without changing the 

values for all movements in the network. As stated previously, the primary focus of 

capacity calibration should be on the key bottlenecks in the network, as they will directly 

impact the performance of the overall network. Thus, the analyst should still use these 

global parameters in the calibration of any bottlenecks related to stop, yield, or permitted 

left-turn movements. The performance of the entire system will be calibrated in the final 

calibration step, giving the analyst an opportunity to calibrate other portions of the 

network impacted by these global parameters. 

In congested networks with closely-spaced intersections or a grid pattern of surface streets, 

bottleneck capacity could be impacted by weaving on roadway sections due to short lanechanging areas or queues that spillback and block upstream intersections. In these cases, 

the analyst should consider calibrating parameters such as “Spillback probabilities” and 

“Time to react to sudden deceleration of lead vehicle.” These parameters are discussed in 

more detail in section 5.7. 

5.6 Calibrating Traffic Volumes 

As shown above in Figure 45, calibrating the traffic volumes is the second step in the 

calibration process. This step is only needed if the model includes parallel streets or a 

network of streets with multiple routes possible within the model. The purpose of this 

step is to ensure that the model volumes throughout the study area match those in the 

field. Having a CORSIM model that can replicate the traffic volumes in the field is a 

crucial step in calibration, as the traffic volumes directly impact the performance of the 

entire network. Thus, if the model cannot replicate the traffic volumes in the field, then it 

will be very difficult to calibrate the system performance MOEs later in the calibration 

process. 

This step is performed by comparing the link and turning movement volumes throughout 

the model to those measured in the field (not a future forecasted volume), and then 

adjusting the model parameters in a systematic manner until the volumes in the model 

match those in the field to an acceptable degree as established in the calibration targets 

(section 5.3). At this point in the modeling process, it is assumed that the field volumes 

were entered into CORSIM correctly without any errors, and that any discrepancies 

between field and model volumes are due to how CORSIM routes vehicles through the 

network. 
133 

Typically, the analyst should calibrate the model volumes to all traffic counts in the field. 

However, for very large networks this may not be feasible and, in these cases, the analyst 

should focus on calibrating the volumes at all critical locations in the network (e.g., 

bottlenecks and congested locations). 

5.6.1 Freeway Traffic Volume Calibration 

As described previously in section 3.3, the most direct and common method of entering 

traffic volumes for freeways is by using entering volumes at entry nodes and turning 

percentages at off-ramp locations. CORSIM then internally converts these values into 

origin-destination percentages (i.e., percentage of traffic between each entry node and offramp location) using a gravity model (see the CORSIM User’s Guide(1) for more 

information). CORSIM does not route vehicles dynamically based on network conditions 

(e.g., avoiding areas of congestion), and there are no user-editable parameters that affect 

the internal calculation of origin-destination percentages. However, unless there are 

multiple freeways being modeled with more than one possible freeway path between 

origin and destination, the traffic volumes on individual freeway links should be 

consistent with those entered into the model. 

If the network does consist of multiple freeways with more than one possible freeway path 

between origin and destination, then the analyst could manually enter a complete origindestination table via Record Type 74 to minimize discrepancies in link-level volumes due 

to CORSIM’s internal origin-destination calculations. Refer to the CORSIM User’s Guide(1)

and section 3.3 of this document for more information on this method. 

At a local scale, volumes entering and exiting the freeway at adjacent interchanges may 

need to be calibrated. For example, some percentage of freeway on-ramp traffic may exit 

at the next downstream off-ramp which may not match those calculated by the internal 

CORSIM gravity model. In this case, partial origin-destination data may be entered to 

“override” the CORSIM calculated origin-destination percentages. Refer to the CORSIM 

User’s Guide(1) and section 3.3 of this document for more information on this method. 

5.6.2 Surface Street Traffic Volume Calibration 

As described in section 3.3, the most direct and common method of entering traffic 

volumes for surface streets is by using entering volumes at entry nodes and turning 

percentages at intersections. Thus, each vehicle entering the network will be assigned a 

path based on the turning percentages encountered at each intersection. This method 

results in a good approximation of the volumes on small or linear surface street networks 

with few route choices available within the network. 

However, the volumes on larger networks or those with a grid-type layout will be more 

difficult to calibrate because of the various possible routes. One possible method to better 

control the volumes on specific segments of the network is to use conditional turn 

movements. As described in section 3.3, conditional turn movements allow the user to 

define turn percentages that are conditional based on the entry movement (i.e., which 

direction the vehicle entered the link). Conditional turn movements are useful for closely-
134 

spaced intersections, such as at a diamond interchange or offset T intersection, where 

unrealistic weaving and queuing may occur if the correct volumes are not modeled. 

Another method possible for calibrating surface street volumes is when a multi-level 

urban interchange is present. If this is the case, then origin-destination data through the 

urban interchange can be coded rather than turn percentages for each link. Refer to the 

CORSIM User’s Guide(1) and section 3.3 of this document for more information on this 

method. 

A final method that may be useful for calibrating traffic volumes on complex surface street 

networks is to specify an origin-destination table for the entire network via Record Type 

176. As explained in the CORSIM User’s Guide(1) and section 3.3 of this document, 

specifying an origin-destination table in NETSIM has limitations, such as the specification 

that only NETSIM links can be coded and that the traffic assignment algorithm is not 

entirely accurate when actuated control traffic signals are present, so care should be taken 

in using Record Type 176 and acknowledging its limitations. 

5.7 Calibrating System Performance 

In the third, and likely most difficult, step of calibration, the overall traffic performance 

predicted by the fully functioning model is compared to the field measurements of the 

system, such as speed, density, travel time, and queue lengths. At this stage, the capacities 

of the key bottlenecks and the traffic volumes throughout the network have been 

calibrated; thus, the system performance MOEs from the model should be fairly close to 

those measured in the field. However, additional calibration will likely still be needed. 

This step is performed by comparing the system MOEs measured in the field to those from 

the model and adjusting the model parameters in a systematic manner until the system 

MOEs in the model match those in the field to an acceptable degree as established in the 

calibration targets (section 5.3). 

Figure 51 shows an example of comparing the field measured average speed to that 

estimated by the model on a section of freeway. As shown, the speed profile changes on 

each segment of the freeway and, while not shown in the figure, the speed profile also 

changes temporally (i.e., a different speed profile could be graphed for each 15-minute 

interval). Thus, comparing the field MOE to model MOE is more complex than just 

comparing two numbers to each other. Employing graphical and spreadsheet techniques 

to compare MOEs over time and space can be useful in the calibration process. Chapter 6 

shows some examples of how to visualize and compare simulation output. 

Viewing the animation of CORSIM runs in TRAFVU can be a useful qualitative tool when 

calibrating the system performance. For example, using TRAFVU to view the progression 

of vehicles in a coordinated set of traffic signals on an arterial can help verify the accuracy 

of the progression in CORSIM as compared to the field. The quality of platoon 

progression can have a significant impact on the system performance (e.g., delays, speeds, 

and stops) in CORSIM; thus, ensuring the platoon progression is realistic is important. 
135 

0

10

20

30

40

50

60

70

80

Average Speed

(MPH)

Mi

25 1/2 STCedar Lake Rd

I-394 Interchange

Glenwood Ave

nnetonka 

Blvd

Excelsior Blvd

36th ST

TH7/TH25

50th ST

Benton Ave

TH 62

Speed Comparison 

Actual Vs Modeled 

Interchange Locations 

Actual Speeds

Modeled Speeds

HWY 100 Northbound

Figure 51. Figure. Example of comparing actual speed from field to modeled speed. 

5.7.1 Freeway System Performance Calibration 

There are many parameters in CORSIM that affect the freeway system performance, so it is 

important to narrow the list to a few parameters that are the most sensitive to system 

MOEs. A candidate list of parameters to adjust for calibrating freeway system 

performance includes: 

• Car following sensitivity factor, Car following sensitivity multiplier, Lag acceleration and 

deceleration time, and Pitt car following constant – As described above in section 5.5, these 

parameters affect freeway capacity and, as a result, also affect system performance. 

Increasing these parameter values will have the effect of degrading the system 

performance MOEs. The “Car following sensitivity factor” and “Car following 

sensitivity multiplier” are the most sensitive of these parameters and, thus, are the 

most effective for calibrating the system performance MOEs. However, if these 

parameters were already calibrated in the bottleneck capacity step, then they should be 

altered here at a minimum level, if possible, to avoid undoing the capacity calibration 

done earlier. 

• Time to complete lane change – This is a global parameter that represents the time to 

complete a lane change maneuver. The default value is 2.0 seconds. Increasing this 

value results in more extended, smooth lane changes and, thus, generally improved 

system performance. Based on a recent CORSIM sensitivity test, this is the only one of 

FRESIM’s 10 lane changing parameters that have a consistent and moderate impact on 

system performance MOEs.(16) This parameter may be helpful in calibrating freeway 

sections with a high frequency of lane changing, such as weaving sections or closelyspaced interchanges, where the lane changing activity is affecting the system 

performance. 

• Mean free-flow speed – This is a link-level parameter that represents the desired mean 

speed of vehicles in the absence of any impedance due to other vehicles or traffic 

control devices. Each driver type has a different free-flow speed based on a global 

multiplier (ranges from 88 percent for conservative drivers to 112 percent for 

aggressive drivers). Changing the distribution of free-flow speed by altering the global 

multipliers is not recommended because a recent sensitivity test showed that changing 
136 

the distribution resulted in inconsistent and occasionally unrealistic impacts on system 

performance MOEs.(16) 

The mean free-flow speed should be used for system performance calibration when the 

model cannot match field conditions at low levels of congestion, as the parameter is 

intended to model speeds at free-flow conditions. For example, freeway segments that 

have a tight horizontal curve, steep vertical curve, or narrow lanes, or alternatively 

attempting to model adverse weather conditions, may cause degraded system 

performance during low congestion based on more conservative driver behavior occurring 

in these conditions. Ideally, the free-flow speed was measured in the field and entered 

into the model in the base model development step (chapter 3); however, other driver 

behavior changes may be occurring during low congestion that are not easily measurable 

but can be approximated using the free-flow speed parameter. 

For congested conditions, the other parameters mentioned above are better suited for 

calibration than free-flow speed. However, it is important to understand that altering the 

free-flow speed in CORSIM will likely change the average speed for a wide-range of 

volume conditions all the way up to the point of maximum throughput (i.e., capacity). 

Figure 52 shows the speed-volume relationship on a basic freeway segment in CORSIM for 

various free-flow speeds. The test network for this figure is a basic freeway segment (i.e., 

no on- or off-ramps) with four lanes. As shown, the average speed is relatively constant at 

just below the free-flow speed until the volume approaches capacity, at which point the 

average speed will decrease dramatically with a small increase in volume. Thus, altering 

the free-flow speed affects all volume conditions up until the freeway breaks down into 

congestion. 

0

10

20

30

40

50

60

70

0 250 500 750 1000 1250 1500 1750 2000 2250 2500

Volume (veh/hr/lane)

Avg. Speed (mi/hr)

55 mi/hr 60 mi/hr 65 mi/hr 70 mi/hr

Mean FreeFlow Speed:

Figure 52. Figure. Speed-volume relationship in CORSIM for a basic freeway segment. 

The parameters altered in this step to calibrate the system performance will also affect the 

capacity, so care should be taken to not modify them to a degree that the capacities of key 

bottlenecks, as calibrated in the first step, become “uncalibrated” in this step. Having 
137 

already calibrated the capacity in the first step will likely result in the system performance 

MOEs of the model to be reasonably close to the field; thus, this step will likely result in 

fine-tuning of these parameters. 

The warning sign locations (see chapter 3 for more detail on these parameters), while 

coded in the base model development step (chapter 3), can have a significant impact on the 

system performance around on- and off-ramps. Thus, if the above parameters do not have 

the desired impact in calibrating system performance, then slight modifications to the 

warning sign locations may be warranted. In general, moving these warning sign 

locations further upstream will result in smoother, less turbulent lane changing conditions 

and can thus improve the system performance. 

5.7.2 Calibrating Arterial System Performance 

There are many parameters in CORSIM that affect the surface street system performance, 

so it is important to narrow the list to a few parameters that are the most sensitive to 

system MOEs. A candidate list of parameters to adjust for calibrating freeway system 

performance includes: 

• Mean discharge headway, Mean startup delay, Acceptable gap in oncoming traffic (left 

turns and right turns), and Cross-street acceptable gap distribution (near-side and far-side) 

– As described above in section 5.5, these parameters affect the capacity at surface 

street intersections and, as a result, also affect system performance. Increasing 

these parameter values will have the effect of degrading the system performance 

MOEs on surface streets. However, if these parameters were already calibrated in 

the bottleneck capacity step, then they should be altered here at a minimum level, if 

possible, to avoid undoing the capacity calibration done earlier. 

• Spillback probabilities – This is a global parameter that sets probabilities for vehicles 

in a queue to join a downstream queue and thus block an intersection. For closelyspaced intersections with long queues, a queue that blocks an upstream 

intersection will have a major impact on the system performance. Thus, calibrating 

this parameter to match local conditions is important in these circumstances. 

• Time to react to sudden deceleration of lead vehicle – This is a global parameter that 

represents the amount of time for a driver to begin decelerating after the leader 

begins a sudden deceleration due to perception/reaction time. The default value is 

1.0 second. Increasing this value generally results in degraded system 

performance. 

• Mean free-flow speed - This is a link-level parameter that represents the desired mean 

speed of vehicles in the absence of any impedance due to other vehicles or traffic 

control devices. Each driver type has a different free-flow speed based on a global 

multiplier (ranges from 75 percent for conservative drivers to 127 percent for 

aggressive drivers). Changing the distribution of free-flow speed by altering the 

global multipliers is not recommended because a recent sensitivity test showed that 

changing the distribution resulted in inconsistent and occasionally unrealistic 

impacts on system performance MOEs.(16) 
138 

As mentioned above, the mean free-flow speed should be used for system performance 

calibration at low levels of congestion, as the parameter is intended to model speeds at 

free-flow conditions. For congested conditions, the other parameters mentioned above are 

better suited for calibration than free-flow speed. 

As mentioned previously, the quality of platoon progression can have a significant impact 

on the performance (e.g., delays, speeds, and stops) of arterials; thus, ensuring the platoon 

progression is realistic is an important step. Viewing the progression of vehicles in 

TRAFVU can be a useful qualitative tool to verify the accuracy of the CORSIM model to 

the field. 

The parameters altered in this step to calibrate the system performance will also affect the 

capacity, so care should be taken to not modify them to a degree that the capacities of key 

bottlenecks, as calibrated in the first step, become “uncalibrated” in this step. Having 

already calibrated the capacity in the first step will likely result in the system performance 

MOEs of the model to be reasonably close to the field; thus, this step will likely result in 

fine-tuning of these parameters. 

5.8 Key Decision Point: Check Overall Calibration Targets 

At this point, the analyst makes a final check that 

all calibration targets have been satisfied. If so, 

then the model is ready to proceed to the 

alternatives analysis step (chapter 6). If not, then 

the analyst should iterate back to bottleneck 

capacity calibration and step through each of the 

three calibration steps again. The calibration 

process is inherently an iterative balancing act, as 

altering a parameter could cause one MOE to meet 

its calibration target yet cause another MOE to move away from its calibration target. This 

could be the case when altering a parameter for capacity calibration and then fine-tuning it 

later for system performance calibration, only to find that the fine-tuning caused the 

capacity to move outside the calibration target. If iteration through the calibration steps is 

necessary, each round of iteration will likely be quicker and increasingly consist of finetuning parameters. 

If repeated iteration of calibration still does not result in all calibration targets to be met, 

then the project team should review the calibration targets to make sure they are realistic 

given the project at hand. The relaxing of certain calibration targets may be warranted if 

they do not impact critical network locations or if they will minimally impact the overall 

transportation decisions being made. 

If repeated iterations of calibration and the reasonable relaxation of calibration targets do 

not result in a satisfactory model, then the project team should reconsider the use of 

TSIS/CORSIM for the project at hand. The modeled network and conditions may be 

beyond the capabilities of the software. Software limitations can be identified through 

careful review of the software documentation. If software limitations are a problem, then 

The calibration process is inherently 

an iterative balancing act, as 

altering a parameter could cause 

one MOE to meet its calibration 

target yet cause another MOE to 

move away from its calibration 

target. 
139 

the analyst will have to work around the limitations to produce the desired performance. 

If the limits are too great, the analyst might seek an alternate software program without 

the limitations. Advanced analysts can also write their own software interface with 

TSIS/CORSIM (called a “Run Time Extension (RTE)) to overcome the limitations and 

produce the desired performance. More detail on RTE functionality is provided in 

appendix L. 
EXAMPLE

140 

5.9 Example Problem: Model Calibration 

The focus of the example problem for this chapter is the HWY 100 project (as discussed in 

previous chapters) in the northbound direction between Excelsior Boulevard and 

Eastbound TH 7 (nodes 127 to 145). The calibration approach employed was consistent 

with that shown in Figure 45 above. 

Establish Calibration MOEs and Targets 

The link discharge rate just downstream of the freeway bottleneck locations was chosen as 

the capacity calibration MOE. The link volumes were used as the MOE for the traffic 

volume calibration step. For the system performance calibration, average link speeds and 

overall travel time were the primary MOEs chosen. 

An initial target was set that all model MOEs would be within 10 percent of the field 

measured MOEs. Any differences beyond 10 percent would be reviewed on a case-by-case 

basis. 

Calibrate Bottleneck Capacity 

The first step in the calibration process is to calibrate the capacity of key bottlenecks. The 

primary bottleneck within the study area was on northbound HWY 100 at the 25th 1⁄2 Street 

Exit. The peak hour target capacity volume as measured in the field was 4,930 veh/h. The 

bottleneck location extended over a larger area due to the complexity of lane drops and 

closely spaced ramps; however, at the end of the congestion area the discharge of traffic 

from the congested area was a significant traffic flow that was ideal for calibrating capacity 

due to the persistent upstream queues. Figure 53 shows a schematic drawing of the 

northbound HWY 100 study area and existing bottleneck locations. 

The process to calibrate capacity used was to: 

1. Adjust the “Car following sensitivity factor” for each driver type by a set percentage. 

2. Run the model 10 times. 

3. Evaluate the results. 

a. If the model capacity (measured as the discharge volume immediately downstream 

of the bottleneck) matches the field capacity to an acceptable level, then the 

capacity is considered calibrated and this step is complete. 

b. If the model capacity does not match the calibration target, then repeat the process 

with new “Car following sensitivity factor” values. If altering this parameter does 

not result in the desired model capacity after several iterations, then other capacityrelated parameters would be attempted. 
EXAMPLE

141 

Figure 53. Illustration. Example problem: HWY 100 freeway bottleneck locations. 
EXAMPLE

142 

The strategy used to adjust the “Car following sensitivity factors” was to systematically 

adjust the factor for each driver type by the same percentage. On the first try after the base 

model was tested, the model capacity was found to be lower than the field measured 

capacity. Thus, the “Car following sensitivity factors” were reduced by 10 percent initially 

to increase the capacity of the model. During the second try, the factors were reduced by 

another 10 percent. The second try did not have a significant effect on the results, so the 

same factors were used on the third try and, in addition, the “Pitt car following factor” was 

reduced from 10 to 5 to further increase the capacity of the model. Table 13 summarizes 

the process used in calibrating the bottleneck capacity at the northbound HWY 100/25th 1⁄2 

Street Exit. 

Table 13. Example problem: model adjustments for calibrating capacity. 

Iteration Car Following Sensitivity Factor for each Driver Type 

1 2 3 4 5 6 7 8 9 10 

Pitt Car 

Following 

Factor 

Default 1.25 1.15 1.05 0.95 0.85 0.75 0.65 0.55 0.45 0.35 10 

1 1.13 1.04 0.95 0.86 0.77 0.68 0.59 0.50 0.41 0.32 10 

2 1.02 0.94 0.86 0.77 0.69 0.61 0.53 0.45 0.37 0.29 10 

3 1.02 0.94 0.86 0.77 0.69 0.61 0.53 0.45 0.37 0.29 5 

Figure 54 shows the throughput volume measured in the field and with the various model 

iterations at the HWY 100/25th 1⁄2 Street Exit bottleneck. As shown, the default model 

values resulted in the bottleneck capacity being 16.9 percent lower than that measured in 

the field. However, by the third iteration, the model capacity was only 2.7 percent lower 

then that measured in the field, well within the 10 percent calibration target. 
EXAMPLE

143 

0

1000

2000

3000

4000

5000

6000

Field Model -

Default

Model -

Iteration 1

Model -

Iteration 2

Model -

Iteration 3

Hourly Volume (veh/hr)

-16.9%

x.x% = Percent difference 

from field volume.

-11.6% -12.7%

-2.7%

Figure 54. Graph. Example problem: capacity calibration at northbound HWY 100/25th 1⁄2 

Street Exit. 

Calibrate Traffic Volumes 

The HWY 100 network is linear with no alternate routes possible between each origin and 

destination. Therefore, as described earlier in section 5.6, calibrating the traffic volumes 

was not necessary. A check of link volumes on the HWY 100 corridor confirmed that all 

modeled volumes were within the 10 percent calibration target. The link volumes are 

displayed in Table 14. As shown in the table, the model volumes ranged from 3.3 percent 

lower to 5.5 percent higher than the field volumes. A similar check was done for the 

surface streets modeled around the interchanges and also found the model volumes to be 

within the calibration target. 
EXAMPLE

144 

Table 14. Example problem: NB HWY 100 AM peak traffic volumes. 

Segment Field Volume 

(veh/hr) 

Model 

Volume 

(veh/hr) 

Percent 

Difference 

NB TH 100 – TH 62 EB Exit 3,120 3,124 +0.13 

TH 62 EB Exit – TH 62 EB Entrance 2,848 2,825 -0.81 

TH 62 EB Entrance – TH 62 WB Exit 3,482 3,465 -0.49 

TH 62 WB Exit – TH 62 WB Entrance 2,943 2,957 +0.48 

TH 62 WB Entrance – Benton Ave. Entrance 3,640 3,661 +0.58 

Benton Ave. Entrance – 50th St. Exit 3,901 3,921 +0.51 

50th St. Exit – 50th St. EB Entrance 3,344 3,410 +2.0 

50th St. EB Entrance – 50th St. WB Entrance 3,683 3,760 +2.1 

50th St. WB Entrance – Excelsior Blvd. Exit 4,021 4,103 +2.0 

Excelsior Blvd. Exit – 36th St. Exit 3,044 3,140 +3.2 

36th St. Exit – 36th St. Entrance 2,431 2,561 +5.4 

36th St. Entrance – TH 25/TH 7 EB Exit 3,204 3,345 +4.4 

TH 25/TH 7 EB Exit – TH 25/TH 7 EB Entrance 3,149 3,286 +4.4 

TH 25/TH 7 EB Entrance – TH 25/TH 7 WB 

Exit 

3,782 3,882 +2.6 

TH 25/TH 7 WB Exit - TH 25/TH 7 WB 

Entrance 

3,721 3,769 +1.3 

TH 25/TH 7 WB Entrance – Minnetonka Blvd. 

Exit 

3,963 3,964 +0.03 

Minnetonka Blvd. Exit - Minnetonka Blvd. 

Entrance 

3,913 3,879 -0.87 

Minnetonka Blvd. Entrance – 25th 1⁄2 St. Exit 4,930 4,799 -2.7 

25th 1⁄2 St. Exit – I-394 EB Exit 4,488 4,340 -3.3 

I-394 EB Exit – Cedar Lake Rd. Entrance 2,842 2,784 -2.0 

Cedar Lake Rd. Entrance – I-394 EB Entrance 3,139 3,086 -1.7 

I-394 EB Entrance – I-394 WB Exit 3,590 3,527 -1.8 

Note: The “model volume” represents the volumes based on the model after the capacity calibration step is 

complete. 
EXAMPLE

145 

Calibrate System Performance 

After the model was successfully calibrated for capacity and traffic volumes, the model 

was calibrated for system performance. The primary system performance measures used 

were average link speeds and over all travel time, while other measures such as control 

delay, average density, and queue lengths were used to calibrate localized congestion 

spots. Several iterations of changing parameter values were tried in a similar fashion to 

that explained in the capacity calibration step. The “Car following sensitivity multiplier,” 

“Mean free-flow speed,” and the anticipatory lane changing parameters were the main 

parameters used for the system performance calibration. Table 15 shows the final 

calibration parameter values for the freeway system performance calibration, with those 

parameters changed from their default values highlighted. In addition to those shown in 

the table, the anticipatory lane change parameters were adjusted just upstream of the TH 

25/TH 7 EB Entrance and TH 25/TH 7 WB Entrance ramps to essentially prevent 

anticipatory lane changes from occurring (by changing the minimum speed trigger to 16.1 

km/h (10 mi/h) and reaction point distance to 3.0 m (10 ft)). This was done to more 

realistically model driver behavior in this section, as the majority of drivers were not 

moving to the left upstream of the merge because many of them were positioning to exit 

the freeway at an upcoming ramp. 
EXAMPLE

146 

Table 15. Example problem: final system performance calibration values 

for NB HWY 100. 

Segment Mean Free-flow 

Speed (mi/h) 

Car Following 

Sensitivity 

Multiplier 

NB TH 100 – TH 62 EB Exit 65 100 

TH 62 EB Exit – TH 62 EB Entrance 65 100 

TH 62 EB Entrance – TH 62 WB Exit 65 100 

TH 62 WB Exit – TH 62 WB Entrance 65 100 

TH 62 WB Entrance – Benton Ave. Entrance 65 100 

Benton Ave. Entrance – 50th St. Exit 65 100 

50th St. Exit – 50th St. EB Entrance 65 100 

50th St. EB Entrance – 50th St. WB Entrance 65 100 

50th St. WB Entrance – Excelsior Blvd. Exit 65 120 

Excelsior Blvd. Exit – 36th St. Exit 65 140 

36th St. Exit – 36th St. Entrance 65 140 

36th St. Entrance – TH 25/TH 7 EB Exit 60 120 

TH 25/TH 7 EB Exit – TH 25/TH 7 EB Entrance 60 120 

TH 25/TH 7 EB Entrance – TH 25/TH 7 WB Exit 60 120 

TH 25/TH 7 WB Exit - TH 25/TH 7 WB Entrance 60 110 

TH 25/TH 7 WB Entrance – Minnetonka Blvd. Exit 60 100 

Minnetonka Blvd. Exit - Minnetonka Blvd. Entrance 60 90 

Minnetonka Blvd. Entrance – 25th 1⁄2 St. Exit 60 80 

25th 1⁄2 St. Exit – I-394 EB Exit 65 90 

I-394 EB Exit – Cedar Lake Rd. Entrance 65 100 

Cedar Lake Rd. Entrance – I-394 EB Entrance 65 100 

I-394 EB Entrance – I-394 WB Exit 65 100 

Note: Shaded cells represent values that were changed from their default during the calibration process. 

As a result of the calibration efforts, the average speeds of all links were within six percent 

of the field speeds during the AM peak hour and within five percent during the PM peak 

hour for northbound HWY 100. A few individual links were more than 10 percent away 

from the field measurements, but these were considered acceptable given the difficulty in 

matching speeds for a large freeway section with congested conditions. Figure 55 shows 

the results of the AM peak hour average speed calibration for northbound HWY 100. As 

shown, the model replicates the speeds on northbound HWY 100 much more closely after 

calibration than with the base model. 
EXAMPLE

147 

0

10

20

30

40

50

60

70

80

Average Speed (mi/hr)

Field Base Model Calibrated Model

TH 62

Northbound HWY 100 Benton 50th Excelsior

TH 7MinnetonkaI-394

Figure 55. Graph. Example problem: speed calibration results for 

northbound HWY 100 during AM peak. 

While the graph above shows a calibration that was performed using aggregated one-hour 

average speeds, the variations in 15-minute average speeds over the entire three-hour 

analysis period were also calibrated at key locations. Figure 56 shows a typical graph that 

was used to compare the field and model speeds on individual links. As shown, the 

model slightly underestimates the field speeds but matches the general speed profile as it 

decreases over time. 

0

10

20

30

40

50

60

70

80

1 2 3 4 5 6 7 8 9 10 11 12

Time Period (15-minute average)

Average Speed (mi/hr)

Field Speed

Model Speed

Figure 56. Graph. Example problem: speed calibration results for 

northbound HWY 100 at WB TH 7 Exit during AM peak. 
EXAMPLE

148 

A similar calibration process was used to calibrate other system performance MOEs, such 

as overall travel time through the corridor, density and queuing at congested locations, 

and control delay and queuing at the signalized intersections at the interchange terminals. 

Key Decision Point: Check Overall Calibration Targets 

A review was completed of all calibration MOEs and whether they met the established 

calibration targets. The MOEs were found to be well-calibrated and, while a few MOEs 

such as average link speeds exceeded the target, the model overall represented the field 

conditions as well as could be expected given that this is a large simulation model with 

existing congestion. 

After discussing the calibration results with the project team, consensus was established 

that the model was fully calibrated and ready to proceed to the alternatives analysis step.
149 

6.0 Alternatives Analysis 

Project alternatives analysis is the sixth step in 

the CORSIM analysis process. It is often the 

primary reason for developing and calibrating 

the model. The lengthy model development 

process has been completed and now it is 

time to put the model to work. (7)

The analysis of project alternatives involves 

the forecasting of the future demand for the 

base model and the testing of various project 

alternatives against this baseline future 

demand. The analyst must run the model 

several times, review the output, extract 

relevant statistics, correct for biases in the 

reported results, and perform various 

analyses of the results. These analyses may 

include hypothesis testing, computation of 

confidence intervals, and sensitivity analyses 

to further support the conclusions of the analysis. 

The alternatives analysis task consists of several 

steps: 

1. Development of Baseline Demand Forecasts. 

2. Generation of Project Alternatives for Analysis. 

3. Selection of Measures of Effectiveness (MOEs). 

4. Application of CORSIM Model (Runs). 

5. Tabulation of Results. 

6. Evaluation of Alternatives. 

Documenting the development of the alternative networks and analysis of the alternatives 

is very important to the success of the study and it makes the final documentation much 

easier to understand. Decisions, procedures, and assumptions made during the alternative 

analysis process should be documented so that when the study is reviewed in the future it 

is clear why the study was done as it was. For example, traffic forecasts need to be part of 

the alternatives analysis of a future year’s traffic; however, traffic forecasts may be 

different for different alternatives due to changes in traffic routing and circulation 

patterns. The results of an analysis may be summarized in a summary report that contains 

W orking M odel

Before Calibration W orking Model

Before Calibration

4

7

Error Checking

1

Define the Project

- Define project purpose

- Identify influence areas

-Select approach

-Select m odel

-Estim ate staff tim e 

1 -

-

-

-

-

2 Data Collection

-Traffic vo lum es

-Base m aps/in ventory

-Field observations

2 -

-

3

Base M odel Development

Input data

D evelop quality assurance 

3 -

-

- Review Inputs

- Review A nim ation 

See Chapter 1

See Chapter 2

See Chapter 3

See Chapter 4

W ork prior to

actual modeling

Initial modeling

Yes

C alibrated Model

5

-Volum es & Speeds m atch?

- Congestion in right places?

Compare Model

5 MOEs to Field Data 

-

-

See Chapter 5

Calibration

-Key Results

- Technical Docum entation 

6 -Forecast Demand

-Base Case

-Project Alternatives

Alternatives Analysis

-M odify G lobal P aram eters

-M odify Link Param eters

-M odify R oute C hoice Param eters

Adjust M odel Parameters

-

-

Final Report

Acceptable

Match?

N o

See Chapter 6

See Chapter 7

Model

Application

The analysis of project alternatives 

involves the forecasting of the future 

demand for the base case and the 

testing of various project alternatives 

against this baseline future demand.
150 

the MOEs for the alternatives tested. Such a summary report could then be later 

incorporated into the final documentation. 

6.1 Baseline Demand Forecast 

This step consists of establishing the future level of demand to be used as a basis for 

evaluating project alternatives. Additional information and background regarding the 

development of traffic data for use in highway planning and design may be found in 

National Cooperative Highway Research Program (NCHRP) Report 255, Highway Traffic 

Data for Urbanized Area Project Planning and Design. 

6.1.1 Demand Forecasting 

A significant component to the analysis of alternatives is the development of traffic 

forecasts. This process is quite involved and relies on estimates and assumptions to 

determine what the traffic volumes will be in the future.(2) Forecasting techniques include: 

• Regional Travel Demand Models. The regional models are large-scale models that 

assign traffic to the roadway system based on desired travel between areas called 

Traffic Analysis Zones (TAZs) and major roadways that leave the study areas. Within 

each TAZ, trips are estimated based on the socio-economic information including 

residential population and employment. Trips are assigned to the roadway network 

based on the desired destination between zones and the relative congestion on each 

road. The regional forecast model will take into account parallel routes and divert 

traffic accordingly. The results from travel demand models require careful review, as 

the estimates of capacity are at a planning level and may not take into account detailed 

operational constraints, such as queue blockages or freeway weaving areas. 

• Applying Historical Growth Patterns. The analyst may seek to develop demand 

forecasts based on historic growth rates. A trend-line forecast might be made, 

assuming that the recent percentage of growth in traffic will continue in the future. 

These trend-line forecasts are most reliable for relatively short periods of time (5 years 

or less). They do not take into account the potential of future capacity constraints to 

restrict the growth of future demand. Strong caution must be used when historical 

growth is applied; a mature corridor may not grow at a high rate or the growth rate 

may not take into account realistic system capacities and possible diversions to other 

routes. 

• ITE Trip Generation Methods. The Institute of Transportation Engineers maintains a 

Trip Generation Manual,(17) which contains trip rates for different land use types and 

sizes. This methodology would involve adding traffic to existing traffic counts based 

on new development. This method would not take into account background growth 

outside of the study area. 

• Hybrid of all the above. It is possible to employ all of these methods to develop traffic 

forecasts. 
151 

As discussed earlier in section 3.3, entering traffic demand in CORSIM using 15-minute 

time periods throughout the entire peak period (i.e., the onset of congestion through the 

dissipation of congestion) should adequately represent the dynamic nature of demand in a 

study area. However, forecasting the traffic demand for a future year is not a precise 

science. While estimating daily traffic and peak hour traffic for a future year is difficult, 

estimating the future year demand in 15-minute increments is even more difficult. 

In order to analyze peak periods in CORSIM for the future condition, the analyst could 

first forecast the future year peak hour demand based on the forecasting techniques 

discussed above and then factor the existing 15-minute demands uniformly by the future 

peak hour demand divided by the existing peak hour volume. This is similar to applying 

a peak hour factor in the HCM. In essence, the existing peak period traffic pattern is 

applied to the future in order to analyze the build-up, duration, and dissipation of 

congestion. 

6.1.2 Constraining Demand to Capacity 

Regardless of which method is used to estimate future demand, care must be taken to 

ensure that the forecasts are a reasonable estimate of the actual amount of traffic that can 

arrive within the analytical period at the study area. Regional model forecasts are usually 

not well constrained to system capacity and trend-line forecasts are totally unconstrained. 

Appendix F of Volume III provides a method for constraining future demands to the 

physical ability of the transportation system to deliver the traffic to the model study area.(7)

6.1.3 Allowance for Uncertainty in Demand Forecasts 

All forecasts are subject to uncertainty. It is risky to design a road facility to a precise 

future condition given the uncertainties in the forecasts. There are uncertainties in both 

the probable growth in demand and the available capacity that might be present in the 

future. Slight changes in the timing or design of planned or proposed capacity 

improvements outside of the study area can significantly change the amount of traffic 

delivered to the study area during the analytical period. Changes in future vehicle mix 

and peaking can easily affect capacity by 10 percent. Similarly, changes in economic 

development and public agency approvals of new development can significantly change 

the amount of future demand.(7) Thus, it is good practice to explicitly plan for a certain 

amount of uncertainty in the analysis. This level of uncertainty is the purpose of 

sensitivity testing (explained further in section 6.6). 

6.2 Generation of Project Alternatives 

In this step, the analyst generates improvement alternatives based on direction from the 

decision makers and through project meetings. They will probably reflect operational 

strategies and/or geometric improvements to address the problems identified based on 

the baseline demand forecasts. The generation of alternatives should consider at the 

minimum: 
152 

• Performing CORSIM analyses of the baseline 

demand forecasts (“future no-build” 

alternative) to identify deficiencies in the 

transportation system or performance goals 

and objectives which the “build” alternative(s) will support. The future analysis years 

could consist of interim and opening years of the improvement(s) considered and 

future design year established in the scoping phase of the project (refer to section 1.2 

for more detail). 

• Performing CORSIM analyses of potential improvements (“future build” alternatives) 

that solve one or more of the identified problems in the baseline alternatives. In 

addition to considering traditional infrastructure and geometric improvements, 

alternatives should also consider transportation system management strategies (e.g., 

ramp metering, traffic signal coordination, and improved traveler information) as well 

as alternative transportation mode strategies (e.g., HOV lanes and ramps and 

improved transit service). 

One difficulty in generating alternatives is maintaining control of the alternatives and the 

base network. The analyst must make sure the base network is used as the basis for all 

alternatives. Invariably, after all the base model development and error checking is done 

and alternatives have been developed, an error will be found in the base model that affects 

all of the alternatives. Making the change in the base model and all of the alternatives can 

be tedious and error prone. Therefore, using an automated way to make changes is 

beneficial. 

The TRF Manipulator tool can be used in a script to repeatedly open a CORSIM (*.TRF) 

input file, manipulate the contents, and save the file with a new name. Well written scripts 

can make this tool do much of the previously intensive and error prone task of changing 

data. A change file specific to the changes for each alternative can be applied to the base 

network making the creation of alternative network files quite simple and repeatable. The 

TRF Manipulator tool uses the TRF format database to know what columns of text on the 

specified record entries to manipulate. The TRF Manipulator is also very useful when 

performing sensitivity studies. It can be used in a nested loop to set a parameter then 

increment it multiple times. This tool has many functions to change different types of 

data. For more information refer to the TSIS Script Tool User’s Guide.(6) 

6.3 Selection of Measures of Effectiveness (MOEs) 

MOEs are the system performance statistics that best characterize the degree to which a 

particular alternative meets the project objectives (which were determined in the Project 

Scope task). Thus, the appropriate MOEs are determined by the project objectives and 

agency performance standards rather than what is produced by the model. The selection 

of appropriate MOEs ideally would have been developed through the consensus of all 

stakeholders at the beginning of the project (Project Scope task) concurrently with the 

development of the project objectives; however, if this was not the case, then MOEs should 

be selected at this point so that the analyst understands which MOEs to base his/her 

findings upon. 

The analyst must make sure the base 

network is used as the basis for all 

alternatives. 
153 

The following project objectives were given in chapter 1 as an example of establishing 

objectives that are specific and measurable (note that these represent only an example): 

• Provide for minimum average freeway speeds of 75 km/h (47 mi/h) throughout 

the peak period between Points A and B. 

• Provide for ramp operations which do not generate queues or spillback which 

impact operations on the freeway or major crossroad. 

• Arterial operations within 4.0 km (2.5 mi) of freeway interchanges maintain an 

average speed of 55 km/h (34 mi/h) and arterial intersections do not result in 

phase failure or queue spillback into adjacent intersections. 

In this example, the MOEs reported for each alternative would thus need to reflect 

measurement of average speeds on the freeway, queues on the ramps, average speeds on 

the arterial, queues on the arterial approaches, and phase failure at the arterial 

intersections. 

Because the selection of appropriate MOEs depends on the project objectives, needs and 

priorities of the stakeholders, agency performance standards, and/or past practice in the 

region, this section does not recommend specific MOEs to select; rather, this section 

highlights possible candidate MOEs typically produced by CORSIM so that the analyst can 

appreciate what output might be available for constructing the desired MOEs. CORSIM 

calculates hundreds of possible MOEs, thus it is important that the key MOEs for the 

particular study be selected upfront before the analyst begins the alternatives analysis. 

An understanding of how MOEs are defined and accumulated in CORSIM is critical when 

evaluating the performance of alternatives. For example, understanding how and when to 

report cumulative, time period-specific, or time interval-specific MOEs is important when 

identifying and evaluating location-specific problem areas. Appendix H (Understanding 

CORSIM Output) contains more detailed information on understanding and interpreting 

CORSIM MOEs. 

6.3.1 Candidate MOEs for Overall System Performance 

Many MOEs of overall system performance can be computed directly or indirectly from 

the following three basic system performance measures as reported in the TSIS Output 

Processor. (Note: This is the terminology used in CORSIM): 

• Travel Distance Total (Vehicle-miles traveled (VMT)). 

• Travel Time Total (Vehicle-hours traveled (VHT)). 

• Speed Average. 

These three basic performance measures can also be supplemented with other model 

output, depending on the objectives of the analysis. For example, Delay Travel Total is a 

useful overall system performance measure for comparing the congestion-relieving 
154 

effectiveness of various alternatives. The number of stops is a useful indicator for traffic 

signal coordination studies. Another indicator is the time to onset of a congested state, 

such as speed below 88.5 km/h (55 mi/h) or a signal phase failure (i.e., a vehicle queue at 

a traffic signal does not clear the intersection in a single green phase). These indicators 

provide insight that one alternative may remain in a desired operational state until a 

specific point in time, while another alternative may remain in a desired operational state 

for a shorter or longer period of time. 

In order to understand the characteristics of each alternative, multiple system-wide MOEs 

should be looked at and considered. The Traffic Analysis Toolbox, Volume VI: Definition, 

Interpretation, and Calculation of Traffic Analysis Tools Measures of Effectiveness recommends 

that a “starting set” of basic MOEs first be evaluated: throughput, mean delay, travel time 

index, freeway segments at breakdown, and surface street intersections with long queues, 

turn bay overflows, and exit blockages.(18) These basic MOEs are analogous to the initial 

exams given to every patient checking into the emergency room (i.e., temperature, pulse, 

blood pressure, and blood oxygen), which give the doctors a basic understanding of the 

general health of the patient and some indication of fields to investigate for the source of 

the problem. Similarly, the basic MOEs serve as this initial high-level screening of the 

overall performance of the system. Then, based on these basic MOEs, a more detailed 

analysis of specific MOEs at hotspot locations can be used to further understand the extent 

and nature of the problems.(18) 

Many CORSIM studies cover large areas with multiple hours to properly capture the 

spatial and temporal extent of congestion. While reporting the average of a particular 

MOE for the entire study area and analysis period will help prioritize the overall 

effectiveness of an alternative, a more insightful approach is to report the selected MOEs 

by segment or section of roadway and by time period (i.e., 15-minute period). Reporting 

the MOEs by spatial bounds and temporal periods will allow the extent and location of 

congestion to become evident for each alternative. Comparing the MOE results between 

alternatives is discussed further in section 6.6. 

6.3.2 Candidate MOEs for Localized Problems 

In addition to evaluating overall system performance, the analyst should also evaluate if 

and where there are localized system breakdowns (“hot spots”). Hot spot locations can 

often initially be identified by reviewing the CORSIM animation; however, care should be 

taken in relying on the animation of a single CORSIM run to identify hot spots (discussed 

further in section 6.6). While reviewing the animation can be a powerful tool in 

identifying localized problems, link-level MOEs from CORSIM output should be 

evaluated over multiple runs to quantify the location, severity, and extent of hot spots. 

Several MOEs that can be used to identify these breakdowns or hot spots include: 

• Persistent queue that lasts too long. There is no single CORSIM MOE that reports the 

extent and duration of a queue that spans multiple links. On freeways (reported in the 

FRESIM output), the location and extent of queues can be estimated based on low 

average speeds or high average densities for consecutive links. Queuing can also be 

identified if a vehicle back-up warning message is generated (e.g., “Warning – 100 
155 

Vehicles Backed Up Behind Node 8001”), which occurs when queues on the network 

prevent vehicles from entering the network at an entry node. This warning message 

can be viewed while CORSIM is running and is also reported in the output file (*.OUT 

file). On surface streets (reported in the NETSIM output), long queues can be 

identified based on the “Average Queue Length by Lane” or “Maximum Queue 

Length by Lane” MOEs, which are generated for each link. Queuing can also be 

estimated based on high delay values on specific links (e.g., “Queue Delay per 

Vehicle”). 

• A signal phase failure (a vehicle queue at a traffic signal does not clear the intersection in a 

single green phase). CORSIM output includes a “Phase Failure” MOE for each surface 

street link, which is a cumulative count of the number of times during the simulation 

that the queue at a signal fails to be discharged completely during a green phase. 

• A blocked link or a queue that spills back onto an upstream intersection. CORSIM output 

includes warning messages when surface street links experience queue spillback (i.e., 

queues extend to an upstream link). The warning message states when spillback 

begins and ends, which could occur multiple times throughout the duration of a 

simulation run. 

• Freeway merging or weaving area that creates a bottleneck condition resulting in upstream 

queues and congestion. As stated above, the location and extent of queuing due to a 

freeway bottleneck can be estimated based on low average speeds or high average 

densities for consecutive links. 

6.3.3 Choice of Average or Worst Case MOEs 

The analyst needs to determine if the alternatives should be evaluated based on their 

average predicted performance or their worst case predicted performance. As discussed in 

Chapter 5, accumulating and reporting statistics over many runs is easily done with the 

TSIS tools. The standard deviation of the results can be computed and used to determine 

the confidence interval for the results. 

The worst case result for each alternative is slightly more difficult to compute. It might be 

tempting to select the worst case result from the simulation model runs; however, the 

difficulty is that the analyst has no assurance that if the model were to be run a few more 

times, an even worse result might be computed. Thus, the analyst never knows if they 

have truly obtained the worst case result. The solution is to compute the 95th percentile 

probable worst outcome based on the mean outcome and an assumed normal distribution 

for the results.(7) The equation below can be used to make this estimate: 
156 

Figure 57. Equation. Calculating the 95th percentile probable worst outcome.

6.4 Model Application 

The calibrated CORSIM model is applied, or ran, in this step to compute the MOEs for 

each alternative. The CORSIM User’s Guide(1) describes in detail the steps required to run 

CORSIM. The purpose of this section, however, is to discuss some key issues that the 

analyst should consider when running CORSIM for the alternatives analysis. 

6.4.1 Multiple CORSIM Runs 

Due to the stochastic nature of CORSIM, the results from individual runs can vary 

significantly, especially for facilities operating at or near capacity. Thus, it is necessary to 

run CORSIM multiple times with different random number seeds to gain an accurate 

reflection of the performance of the alternatives. The CORSIM Driver Tool has a built-in 

multiple-run capability and a built-in output processor that collects statistics from each run 

and summarizes them. 

The multi-run capability runs a test case multiple times, changing the random number 

seeds for each run. Thus, by default CORSIM will change the random seed values for 

multiple runs of the same CORSIM file (using the “random.rns” file). When running a 

separate CORSIM file (i.e., different alternative) multiple times, the output processor will 

subsequently use the same set of random seed values in the “random.rns” file. Using the 

same set of random seed values among all alternatives will ensure that the only difference 

in output among alternatives is due to the differences in the alternatives themselves (i.e., 

different traffic demands, geometries, traffic control strategies, etc.). 

Overall, using the multi-run function in the output processor will automatically change the 

random seed values for multiple runs of the same CORSIM file and use the same set of 

random seed values across multiple alternatives. The output processor does allow an 

analyst to change the default set of random seed values if necessary. Refer to Appendix D 

for more information on the usage of random seed values in CORSIM. 

Section 5.4 discusses in more detail how to calculate the appropriate number of runs for 

each alternative. Also, the CORSIM User’s Guide(1) contains detailed information on 

setting up and performing multiple simulation runs in CORSIM. 
157 

6.4.2 Exclusion of Initialization Period 

The artificial period where the simulation model begins with zero vehicles on the network 

(referred to as the “initialization period” or “fill period”) must be excluded from the 

reported statistics for system performance. CORSIM will do this automatically. The 

initialization period typically ends when equilibrium has been achieved. Equilibrium is 

achieved when the number of vehicles entering the system is approximately equal to the 

number leaving the system. The algorithm used by CORSIM does not work properly in all 

circumstances. For example, if the data collected during a run shows a sharp decrease in 

value soon after the initialization period, it is a good indication that equilibrium was not 

reached. Thus, the analyst should check the CORSIM output file (*.OUT file) to ensure 

equilibrium has been reached in the CORSIM run. Model output should not be used if 

equilibrium has not been reached, as the results will not represent the actual volumes 

attempted to be modeled. Appendix C has a more detailed discussion of the initialization 

period. 

6.4.3 Impact of Alternatives on Demand 

The analyst should consider the potential impact 

of alternative improvements on the base model 

forecast demand. This should take into 

consideration the effects of a geometric alternative 

and/or a traffic management strategy. The 

analyst should then make a reasonable effort to 

incorporate any significant demand effects into the analysis. 

For example, if improvements are added to serve the existing 4,000 vehicles per hour, the 

improvements themselves may draw, or induce, an additional 500 vehicles per hour after 

the improvements are completed. Drivers may alter their route to take advantage of the 

improvements and create an unforecasted demand change. For a second example, if a 

freeway interchange is inserted between two existing interchanges, the exit and turn 

percentages at the existing interchanges will most likely change from the base model 

percentages. New turning fractions must be estimated by repeating the traffic assignment 

based on the improvements. 

6.4.4 Signal/Meter Control Optimization 

CORSIM does not optimize signal timing or ramp 

meter controls. Thus, if the analyst is testing 

various demand patterns or alternatives that 

significantly change the traffic flows on specific 

signalized streets or metered ramps, he or she may 

need to include a signal and meter control 

optimization step within the analysis of each 

alternative. This optimization might be performed offline using a macroscopic signal 

timing or ramp metering optimization model. Or, the analyst may run CORSIM multiple 

times with different signal settings and manually seek the signal setting that gives the best 

New turning fractions must be 

estimated by repeating the traffic 

assignment based on the 

improvements. 

The analyst may use a signal 

optimization model to estimate optimal 

signal timing settings for an alternative 

and then enter the settings into 

CORSIM. 
158 

performance. Refer to the Signal Optimization discussion in section 3.4 for information on 

third party products that can be used to aid in developing optimized signal timing 

settings. 

6.5 Tabulation of Results 

The process of collecting and summarizing CORSIM output using the output processor is 

discussed briefly in section 5.4 and in more detail in the CORSIM User’s Guide(1). 

Tabulating the results for the alternative analysis in this chapter is essentially the same 

process as used in chapter 5 with possible exceptions of selecting different MOEs and 

running various future-year alternatives. 

6.5.1 Numerical Output 

TSIS and CORSIM report the numerical results of the model run in text output files or 

spreadsheet files. The results are summarized over time and/or space. It is critical that 

the analyst understands how CORSIM has accumulated and summarized the results to 

avoid pitfalls in interpreting the numerical output. 

The CORSIM output file (*.OUT file) accumulates the data over time intervals and either 

reports the cumulative sum, the maximum, or the cumulative average. The output 

processor can also report the data specific to the time interval or time period. Intervalspecific data can be useful for comparing volume data that varies over time periods or for 

measuring the extent and duration of queuing and congestion dynamically over time 

through the entire simulation. Changes in the performance of the network are reflected 

immediately when using interval-specific data, whereas cumulative data, which is 

averaged over the duration of the entire run, takes a long time to reveal the changes. 

CORSIM can report the results for specific points on a link in the network by using 

detectors or data stations or for aggregated data over the entire link. The point-specific 

output is similar to what would be reported by detectors in the field. Link-specific values 

of road performance are accumulated over the length of the link and, therefore, will vary 

from the point data. CORSIM also reports results for network wide or subnetwork wide, 

bus station or bus route, vehicle fleet, or link aggregation statistics. Appendix H has a 

summary of all MOEs available through the output processor. 

6.5.2 Correcting Biases in the Results 

The geographic and temporal model limits 

should be sufficient to include all congestion 

related to the base case and all of the 

alternatives. An example of this would be 

modeling a network where an entry node has 

spillback. Otherwise, the model will not 

measure all of the congestion associated with an alternative, thus causing the analyst to 

underreport the benefits of an alternative. 

Congestion should not extend 

physically or temporally beyond the 

geographic or temporal boundaries of 

the simulation model. 
159 

To make a reliable comparison of the alternatives, it is important that vehicle congestion 

for each alternative be accurately tabulated by the model. This means that congestion 

(vehicle queues and/or low travel speeds) should not extend physically or temporally 

beyond the geographic or temporal boundaries of the simulation model. Congestion that 

overflows the geographic limits of the network will be reported by CORSIM, both on the 

screen at run time and in the output (*.OUT) file. 

Ideally, the simulation results for each alternative would have the following 

characteristics: 

• All of the congestion begins and ends within the simulation study area. 

• No congestion starts before or ends after the simulation period. 

• No vehicles are unable to enter the network from any entry point during any time step 

of the simulation. 

It may not always be feasible to achieve all three of these conditions, so it may be necessary 

to make adjustments for congestion that is missing from the model output. Some possible 

adjustments are described below. 

Adjustment of Output for Blocked Vehicles 

If simulation alternatives are severely congested, then CORSIM may be unable to load 

vehicles onto the network. Some may be blocked from entering the network on the 

periphery. Some may be blocked from being generated on internal links. These blocked 

vehicles will not be included in the travel time or delay statistics for the model run. The 

best solution is to extend the network back to include the maximum back of the queue. If 

this is not feasible, then the analyst should correct the reported delay to account for the 

unreported delay for the blocked vehicles. 

CORSIM will tally the excess queue that backs up outside the network as “blocked” 

vehicles (vehicles unable to enter the network). The MOEs collected at the entry links 

provide the number of vehicles that were delayed, the total time vehicles were delayed, 

and the average delay per vehicle. When a block of fifty vehicles back up at an entry point, 

there is a message displayed to the screen and written to the output (*.OUT) file (e.g., 

“Warning – 100 Vehicles Backed Up Behind Node 8001”). The delay resulting from 

blocked vehicles should then be added to the model-reported delay for each model run. 

Adjustment of Output for Congestion Extending Beyond the End of the Simulation 

Period 

Vehicle queues that are present at the end of 

the simulation period may affect the 

accumulation of total delay and distort the 

comparison of alternatives (cyclical queues at 

signals can be neglected). The “build” 

alternative may not look significantly better 

The “build” alternative may not look 

significantly better than the “no-build” 

alternative if the simulation period is 

not long enough to capture all of the 

benefits. 
160 

than the “no-build” alternative if the simulation period is not long enough to capture all of 

the benefits. The best solution is to extend the simulation period until all of the congestion 

that built up over the simulation period is served. If this is not feasible, the analyst can 

make a rough estimate of the residual delay that was not captured by using the method 

outlined in section 6.5.3 of Volume III.(7)

6.6 Evaluation of Alternatives 

The evaluation of alternatives using CORSIM output involves the interpretation of system 

performance results and the assessment of the robustness of the results. Methodologies for 

the ranking of alternatives and cost-effectiveness analyses are well documented in other 

reports and are not discussed here. 

6.6.1 Interpretation of System Performance Results 

This subsection explains how to interpret the differences between alternatives for three 

basic system performance measures (Travel Distance Total, Travel Time Total, and 

Average Speed) (as reported by the Output Processor). 

Travel Distance Total (Vehicle-Miles Traveled) 

Travel Distance Total provides an indication of total travel demand (in terms of both the 

number of trips and the length of the trips) for the system. Travel Distance is computed as 

the product of the number of vehicles traversing a link and the length of the link, summed 

over all links. Increases in Travel Distance generally indicate increased demand. Since 

Travel Distance is computed as a combination of the number of vehicles on the system and 

their length of travel, it can be influenced both by changes in the number of vehicles and 

changes in the trip lengths during the simulation period. The following can cause changes 

in Travel Distance between one alternative and the next: 

• Random variations between one alternative and the next. Increasing the number of 

runs for each alternative will reduce the difference in average Travel Distance due to 

random variations in traffic. Thus, any differences observed will only be due to the 

differences in the alternatives. 

• Changed demand. 

• Increased congestion may also reduce the number of vehicles that can complete their 

trip during the simulation period, also decreasing Travel Distance. 

• Inability of the model to load the coded demand onto the network within the 

simulation period. Increased congestion may force the model to store some of the 

vehicle demand outside the network due to bottlenecks at loading points; in this 

situation, increased congestion may actually lower Travel Distance because the stored 

vehicles do not travel any distance during the simulation period.(7)
161 

• Changed capacity. Increasing the capacity from one alternative to the next (e.g., from 

base case to a build alternative) can increase the number of vehicles served and thus 

produce a higher Travel Distance Total for an alternative that improves the system. 

Travel Time Total (Vehicle-Hours Traveled) 

Travel Time Total provides an estimate of the amount of time expended traveling on the 

system. Decreases in Travel Time generally indicate improved system performance and 

reduced traveling costs for the public. Travel Time is accumulated every second a vehicle 

is on the link. The Travel Time for all links is summed to get the system Travel Time. 

Travel Time can be influenced by both changes in demand (the number of vehicles) and 

changes in congestion (travel time). Changes in Travel Time between one alternative and 

the next can be caused by the following: 

• Random variations between one alternative and the next. 

• Changed demand. 

• Changed congestion. 

• Demand stored off-network because of excessive congestion at load points. Increased 

congestion that causes demand to be stored off-network may reduce Travel Time if the 

software does not accumulate delay for vehicles stored off-network.(7)

• Changed capacity. Increasing the capacity from one alternative to the next (e.g., from 

base case to a build alternative) can increase the number of vehicles served and thus 

produce a higher Travel Time Total for an alternative that improves the system. 

Speed Average 

Speed Average is an indicator of overall system performance. Higher speeds generally 

indicate reduced travel costs for the public. The mean system speed is computed as Travel 

Distance Total divided by Travel Time Total. Changes in the average speed between one 

alternative and the next can be caused by the following: 

• Random variations between one alternative and the next. 

• Changed link speeds and delays caused by congestion. 

• Changes in vehicle demand. 

• Changes in the number of vehicles stored off-network caused by excessive congestion 

at loading points.(7)

Delay Travel Total 

Delay Travel Total is useful because it reports the portion of total travel time that is most 

irritating to the traveling public. CORSIM defines Delay Travel Total as the Travel Time 
162 

Total minus the Move Time Total where Move Time Total is the theoretical travel time for 

all vehicles if they were moving at the free-flow speed, calculated as the link travel 

distance total divided by the free-flow speed, computed by link and summed for all links 

in the network. Changes in the total delay time between one alternative and the next can 

be caused by the following: 

• Random variations between one alternative and the next. 

• Changed delays caused by congestion. 

• Changes in vehicle demand. 

• Changes in signal timing. 

• Changes in the number of vehicles stored off-network caused by excessive congestion 

at loading points. 

Travel Time Studies 

Travel time studies are beneficial to understanding the benefits of various build 

alternatives. They provide context to the public. Using probe vehicles to travel through 

the network along common commutes provides a connection for the public and decision 

makers. Average travel times on common routes can also be estimated by aggregating the 

average travel times of all links in particular routes of interest. 

6.6.2 Hypothesis Testing 

When CORSIM is run several times for each alternative, the analyst may find that the 

variance in the results for each alternative is close to the difference in the mean results for 

each alternative. The analyst needs to determine if the differences in the alternatives are 

statistically significant. The analyst also should determine to a certain degree of 

confidence that the observed differences in the simulation results may be caused by the 

differences in the alternatives and not just the result of using different random number 

seeds or of insufficient runs. This is the purpose of statistical hypothesis testing. 

Hypothesis testing determines if the analyst has performed an adequate number of 

repetitions for each alternative to truly tell the alternatives apart at the analyst’s desired 

level of confidence. Hypothesis testing is discussed in more detail in Appendix E of 

Volume III.(7)

6.6.3 Confidence Intervals and Sensitivity Analysis 

Confidence intervals are a means of recognizing the inherent variation in stochastic model 

results and conveying them to the decision maker in a manner that clearly indicates the 

reliability of the results. For example, a confidence interval would state that the mean 

delay for alternative “X” lies between 35.6 sec and 43.2 sec, with a 95-percent level of 

confidence. If the 95-percent confidence interval for alternative “Y” overlaps that of “X”, 

then the analyst may not be able to decisively state that one alternative is statistically 
163 

different than the other. The analyst would need to perform hypothesis testing as 

discussed above. Computation of the confidence interval is explained in more detail in 

Appendix B of Volume III.(7)

A sensitivity analysis is a targeted assessment of the reliability of the simulation results, 

given the uncertainty in the input values or assumptions. The analyst identifies certain 

input values or assumptions about which there is some uncertainty and varies them to see 

what their impact might be on the CORSIM results. Additional model runs are made with 

changes in demand levels and key parameters to determine the robustness of the 

conclusions from the alternatives analysis. The analyst may vary the following parameters 

to determine how sensitive the model is to change: 

• Demand. 

• Street improvements assumed to be in place outside of the study area. 

• Parameters for which the analyst has little information. 

A sensitivity analysis of different demand levels is particularly valuable when evaluating 

future conditions. Demand forecasts are generally less precise than the ability of CORSIM 

to predict their impact on traffic operations. A 10-percent change in demand can cause a 

facility to shift from operating at 95 percent of capacity to 105 percent of capacity, resulting 

in an exponential increase in the predicted delay and queuing for the facility. 

The analyst should estimate the confidence interval for the demand forecasts and test 

CORSIM at the high end of the confidence interval to determine if the alternative still 

operates satisfactorily at the potentially higher demand levels. 

The analyst should plan for some selected percentage above and below the forecasted 

demand to allow for these uncertainties in future conditions. The analyst might consider 

at least a 10-percent margin of safety for the future demand forecasts. A larger range 

might be considered if the analyst has evidence to support the likelihood of greater 

variances in the forecasts. To protect against the possibility of both underestimates and 

overestimates in the forecasts, the analyst might perform two sensitivity tests—one with 

110 percent of the initial demand forecasts and the other with 90 percent of the initial 

demand forecasts—for establishing a confidence interval for probable future conditions. 

Street improvements assumed to be in place outside the simulation study area can also 

have a major impact on the simulation results by changing the amount of traffic that can 

enter or exit the facilities in the study area. Sensitivity testing would change the assumed 

future level of demand entering the study area and the assumed capacity of facilities 

leaving the study area to determine the impact of changes in the assumed street 

improvements. 

The analyst may also run sensitivity tests to determine the effects of various assumptions 

about the parameter values used in the simulation. If the vehicle mix was estimated, 

variations in the percentage of trucks might be tested. The analyst might also test the 

effects of different percentages of familiar drivers in the network. 
164 

6.6.4 Comparing Results to Other Traffic Analysis Tools 

Analysts may attempt to compare the results of 

CORSIM to the results from other traffic analysis 

tools. The reasoning for this comparison varies. 

These types of comparisons however are not 

recommended because of the differences in how 

each traffic analysis tool defines and calculates 

the respective MOEs. 

Each tool (including the Highway Capacity Manual (HCM) method) has notably different 

definitions of what constitutes stopped and queued vehicles and because the tools also 

vary significantly in the determination of which vehicles to include in the computations of 

MOEs. For example, some simulation tools compute the vehicle-miles traveled only for 

vehicles that enter the link during the analysis period, others include the vehicles present 

on the link at the start of the period and assume that they travel the full length of the link, 

and yet others include only the vehicles able to exit the link during the analysis period 

(CORSIM included).(18) 

Further, simulation models (including CORSIM) are not directly translatable into HCM 

level of service (LOS) measures because the HCM bases hourly level of service on the 

performance of the facility during the peak 15-consecutive-minute period within the 

analysis hour. Also, most simulation models (including CORSIM) report the density of 

vehicles, while the density used in HCM LOS calculations for uninterrupted flow facilities 

is the passenger-care equivalent in passenger car units (pcu) of the actual density of 

vehicles on the facility.(18) 

As a result, it is not feasible for an analyst to take the macroscopic output from one tool, 

apply a conversion factor (or procedure) and compare the results to that of another tool. 

This means that looking up HCM LOS using MOEs produced by CORSIM is prone to bias 

and error and is thus not appropriate.(18) 

For similar reasons, analysts should not be switching tools in the middle of a comparison 

between alternatives. One set of tools should be consistently used to evaluate MOEs 

across all alternatives. One should not evaluate one alternative with one tool, another 

alternative with a second tool, and then use the MOEs produced by both tools to select 

among the alternatives. Comparison of results between tools is possible only if the analyst 

looks at the lowest common denominator shared by all field data collection and analytical 

tools: vehicle trajectories. Further discussion on this topic is provided in Volume VI.(18) 

6.6.5 Reviewing Animation Output 

Animation is a very powerful tool to convey differences in alternatives. However, one 

problem with animating an alternative is selecting which individual case to animate. If the 

stochastic processes are set up correctly, each run is a valid representation. However, it is 

not possible to animate the mean values of all MOEs, so the analyst must choose an 

individual run (defined by a set of random number seeds) that demonstrates a 

Comparing the results of CORSIM to 

other tools is not recommended because 

of the differences in how each traffic 

analysis tool defines and calculates the 

respective MOEs. 
165 

representative run of the MOEs of interest. The analyst must determine if they want to 

animate the worst case, best case, or mean case. One technique to select a representative 

mean case is to calculate the nearest neighbor value, as discussed below. 

Nearest Neighbor 

The CORSIM output processor can calculate the “nearest neighbor” value for each 

simulation run. The nearest neighbor value is the sum of the absolute values of the 

difference between the sample value at each interval and the sample mean for that 

interval. The formula to compute the nearest neighbor value for “run j” is: 

Figure 58. Formula. Determining the nearest neighbor value. 

The simulation run with the lowest nearest neighbor value can be thought of as the run 

that most closely matches the mean throughout the duration of the simulation. This is 

useful if an analyst wants to generate animation files that are representative of the average 

results. 

Figure 59 shows the results of an example simulation case with four different runs, along 

with the mean over all four runs. A single MOE was selected, and the mean value of the 

MOE for each of the ten time intervals is plotted on the graph. As the figure indicates, all 

four runs have the same overall mean value of five when averaging over all ten time 

intervals. Locating the mean of each interval in the graph, runs A and D have nearest 

neighbor values of 22, while run B has a nearest neighbor value of 17. Run C has a nearest 

neighbor value of eight and, as can be seen graphically, is nearest to the mean of the 

interval value. 
166 

Figure 59. Graph. Sample mean data graph for nearest neighbor example. 

The example and graph above shows the nearest neighbor for a specific MOE. Each MOE 

may have different runs that are the nearest neighbor. Selecting the run that best 

represents the mean values requires determining what MOEs are most important or which 

run is consistently close to being the nearest neighbor. In order to use Travel Distance 

Total, Travel Time Total, and Average Speed, the run that is consistently the lowest should 

be chosen. It most likely will not be the lowest for all MOEs. Table 16 shows an example 

of nearest neighbor data for 10 runs of a test case. The sum of the nearest neighbor values 

shows that run nine is the run that most closely matches the mean for all three MOEs. 

Sample Mean Data

0

1

2

3

4

5

6

7

8

9

10

1 2 3 4 5 6 7 8 9 10

Interval

Mean Value

A

B

C

D

Mean

A

B

C

D

MEAN
167 

Table 16. Example nearest neighbor calculation with multiple MOEs. 

Nearest Neighbor Value 

Run 

Travel Time Total 

(VHT) 

Travel Distance 

Total (VMT) 

Average Speed 

(mi/h) 

Sum 

1 5.8 113.4 9.7 128.9 

2 8.6 125.0 15.8 149.4 

3 5.3 96.4 11.7 113.4 

4 5.6 107.9 10.7 124.2 

5 5.9 94.8 9.8 110.5 

6 7.8 118.3 15.6 141.7 

7 10.8 113.6 20.6 145 

8 8.9 120.9 17.9 147.7 

9 6.0 82.0 9.9 97.9 

10 6.1 143.4 9.2 158.7

Note: Shaded cells represent the lowest nearest neighbor values for each column. 

The pitfall of using a global summary statistic (such as VHT) to select a model run for 

animation review is that overall average system conditions does not necessarily mean that 

each link and intersection in the system is experiencing average conditions. The median 

VHT run may actually have the worst performance for a specific link. If the analyst is 

focused on a specific “hot spot” location, then he or she should select a MOE related to 

vehicle performance on that specific link or intersection for selecting the run for animation 

review.(7)

Review of Key Events in Animation 

The key events to look for in reviewing animation are the formation of persistent queues 

and congestion. TRAFVU has the capability of animating different alternatives side-byside. This provides an excellent visual comparison. Due to the stochastic nature of the 

simulation, any one time frame in one alternative compared to the same time frame in 

another alternative should not be considered significant unless the condition is persistent 

or representative of the summary of all runs.(7)

Animation of Interval MOEs 

In addition to animating vehicles moving on the roadways, TRAFVU can show tables or 

graphs of the MOEs of an individual link or sets of links. The data can show either 

interval-specific data or cumulative data. 

TRAFVU can be set to automatically display “hot spots” in the network also. Each link can 

be set to change color based on user specified thresholds for the values of many MOEs. 
168 

This hot spot view can be animated over the duration of the simulation. This is useful for 

showing increasing congestion or other areas of interest. See the TRAFVU User’s Guide(19)

for more information. 

6.6.6 Comparison Techniques 

There are many possible techniques and formats for comparing the results of alternatives. 

Comparison techniques can be visual, graphical, and/or tabular displays of the model 

output. The key is to present the model output in a manner that tells a comprehensive 

story of the performance of the alternative while also being easy to interpret and 

understand from a non-technical decisionmaker’s perspective. 

Different organizations have developed various techniques that concisely show simulation 

results in a concise manner. One such example is Washington State DOT’s Traffic Profile 

graphic as shown in Figure 60. The figure clearly shows the operations of the I-5 corridor, 

including where the congestion is located and when the congestion begins and ends. Such 

a graphic can be created by manipulating the output results of CORSIM. For example, the 

CORSIM output processor could be used to produce a spreadsheet file with intervalspecific average speed results for each link along the freeway, of which this data could 

then be manipulated to create a figure such as the one shown in Figure 60. 

Figure 60. Illustration. Washington State DOT traffic profile graph.(20) 

Comparative summary tables are necessary to filter the information from the model run 

reports to the essential information necessary for making a decision. Table 17 shows a 
169 

sample table used by Minnesota DOT (Mn/DOT) when comparing the results for existing 

(2005) conditions and two alternatives each for opening year (2015) and future year (2025). 

Table 17. Sample MOE summary table. 

Design Year 

2005 2015 (Alt. A) 2015 (Alt. B) 2025 Analysis 

Segment 

Speed1 Density2 Speed1 Density2 Speed1 Density2 Speed1 Density2

I-94 Merge 

to High 

Ridge Exit 

64 (64) 11 (6) 32 (64) 34 (9) 64 (64) 15 (9) 64 (64) 16 (11) 

High Ridge 

Exit to 

High Ridge 

Entrance 

64 (64) 10 (4) 7 (64) 111 (6) 63 (64) 14 (6) 63 (64) 13 (7) 

High Ridge 

Entrance to 

I-94 

Diverge 

58 (63) 12 (4) 8 (62) 108 (7) 61 (64) 15 (6) 61 (63) 17 (7) 

Notes: 1. Speed is expressed as mi/h. 

2. Density is expressed as veh/lane/mi. 

Table values are listed as XX (YY), where XX represents the a.m. peak average and YY represents the 

p.m. peak average. 

Shaded cells represent where the average speed drops below 30 mi/h for any peak period for that 

alternative. 

Figure 61 shows a sample graphic used by Mn/DOT for comparing the results for existing 

(2005) conditions, opening year (2015), and a future year (2025). 
170 

Figure 61. Illustration. Sample comparison of project alternatives using schematic drawing. 
EXAMPLE

171 

6.7 Example Problem: Alternatives Analysis 

The purpose of the alternatives analysis for this example problem (as continued from 

previous chapters) is to test various promising design scenarios and compare them to the 

no-build or base alternatives. As discussed in previous chapters, a CORSIM model was 

developed and calibrated to test the concept of widening HWY 100 and reconstructing the 

TH 7 and Minnetonka Boulevard interchanges. The complexity of the project resulted in 

the testing of numerous iterations of project alternatives. The alternative analysis process 

for the HWY 100 study included comparing the existing cloverleaf interchange to a 

diamond interchange at the HWY 100/TH 7 interchange, and analyzing numerous 

variations of a diamond interchange with frontage roads at the HWY 100/Minnetonka 

Boulevard interchange. 

Prior to the modeling of alternatives, a number of design concepts were developed and 

screened down to a few viable alternatives. An alternative was deemed unviable if the 

basic geometric layout resulted in prohibitive right-of-way and/or environmental impacts. 

Step 1: Baseline Demand Forecast 

Traffic forecasts were prepared for the study area using the Regional Travel Demand 

model and manual post-processing techniques. The design year being considered for this 

project was 2031. Figure 62 shows an illustration of the resulting peak hour and daily 

baseline future demand forecasts for the HWY 100/TH 7 interchange area in 2031. 
EXAMPLE

172 

Figure 62. Illustration. Example problem: traffic demand forecast at HWY 100/TH 7 

interchange. 
EXAMPLE

173 

Step 2: Generation of Project Alternatives 

The general process followed for generating and analyzing alternatives is shown in Figure 

63. As shown in the figure, a large number of alternatives were considered initially and, 

for this project, they were analyzed at a high-level using sketch planning techniques. 

Various geometric layouts and concepts were developed and reviewed by all stakeholders 

in this stage. Due to right-of-way impacts, the desire to maintain access, and high 

construction costs, the alternative development and review process was extensive and took 

multiple years. 

Figure 63. Illustration. Example problem: alternatives generation and analysis process. 

A small number of viable alternatives were then modeled and evaluated using CORSIM. 

The viable alternatives were then further screened down to a recommended alternative, 

which included adding mainline lanes on HWY 100, a cloverleaf interchange at TH 7, and 

diamond interchange at Minnetonka Boulevard. The CORSIM analysis was used to finetune these recommended alternatives and compare them to no-build or baseline 

conditions. Fine-tuning included modifying storage lengths, changing lane configurations, 

and adding auxiliary lanes. 
EXAMPLE

174 

Step 3: Selection of MOEs 

The MOEs were discussed and agreed upon by all stakeholders involved in the process. 

The primary MOEs used for evaluating the freeway operations were: 

• Mainline average density - expressed in vehicles per mile per lane. As density increases, 

freeway operations deteriorate, freedom to maneuver is more restricted, and 

operations become volatile and sensitive to any disruption, such as a lane change or 

entering ramp traffic.

• Mainline average speed – expressed miles per hour. The average vehicle speed was 

tabulated for each freeway segment over the analysis period, which serves as an 

indicator of the amount of congestion the mainline. 

• Vehicles served – expressed as the number of vehicles that are actually able to pass 

through a given location in the network. Also referred to as throughput, this MOE 

serves as a comparison to the traffic volume demand at a location in the network. This 

MOE was tabulated for both the peak hour and entire analysis period, and it is related 

to density in that throughput decreases as density increases. 

The primary MOEs used for evaluating the arterial operations were: 

• Average control delay – expressed as seconds per vehicle. This MOE was tabulated for 

both individual approaches to a signalized intersection and for the intersection as a 

whole. As control delay increases, arterial operations deteriorate.

• Vehicles served – the same MOE as above for freeway operations, but on arterials it was 

tabulated for links at the approach to signalized intersections.

Step 4: Model Application 

Before running CORSIM, the signal timing settings on the arterials were optimized using a 

commercial signal optimization software package. This step expedited the evaluation of 

arterial operations by developing optimized signal timings which were then used as input 

to the CORSIM model. Then, each CORSIM model alternative was run ten times with 

different random number seeds, and the MOEs from the five runs were averaged. 

The traffic demand entering the re-construction area of HWY 100 at TH 7 and Minnetonka 

Boulevard exceeds the current capacity of the facilities surrounding the reconstruction 

area. The initial model runs of the proposed improvements indicated significant shortfalls 

in traffic at TH 7 and Minnetonka Boulevard. The proposed design capacity 

enhancements were made in the CORSIM model at the HWY 100/TH 62 and HWY 100/I394 interchanges so traffic could both enter and exit the re-construction area. The 

improvements and capacity constraints outside of the reconstruction area could then be 

conveyed to the appropriate planning and programming officials for future 

considerations. 
EXAMPLE

175 

Step 5: Tabulation of Results 

The model results for ten runs of each alternative were output into a spreadsheet and 

averaged for each alternative. With the capacity improvements modeled at the HWY 

100/TH 62 and HWY 100/I-394 interchanges, there were no problems with queues 

extending beyond the study area or past the simulation analysis period. Overall, no postmodel adjustments of untallied congestion were necessary. 

The HWY 100/Minnetonka Boulevard interchange was considered for a new diamond 

interchange configuration and a new frontage road system. A total of six different 

alternatives were evaluated for this interchange. Table 18 shows the results of Alternative 

1 (no-build) and Alternative 6 (one-way frontage road and ramp option). 
EXAMPLE

176 

Table 18. Example problem: HWY 100/Minnetonka Blvd. interchange operations in 2031 . 

Alternative 1 (No Build) Alternative 6 (Preferred) 

Intersection Approach 

Control 

delay: 

approach 

Control 

delay: 

intersection 

Vehicles 

served: 

approach 

Control 

delay: 

approach 

Control 

delay: 

intersection 

Vehicles 

served: 

approach 

EB 25 (23) 1178 (1393) 15 (8) 1497 (1439) 

WB 87 (47) 1167 (1286) 28 (19) 1729 (1834) 

SB 81 (25) 628 (1057) N/A N/A 

Minnetonka 

Blvd/NB 

Ramp 

NB 187 (121) 

87 (49) 

766 (912) 22 (28) 

22 (17) 

882 (994) 

WB 22 (14) 801 (1453) 9 (7) 962 (1466) 

EB 41 (46) 1400 (1520) 17 (13) 1736 (1578) 

Minnetonka 

Blvd/SB 

Ramp 

SB 74 (29) 

41 (30) 

462 (795) 16 (17) 

14 (12) 

586 (801) 

SB 70 (23) 356 (373) 19 (17) 400 (381) 

WB 21 (16) 703 (1388) 21 (16) 801 (1442) 

NB 85 (17) 332 (418) 14 (12) 384 (421) 

Minnetonka 

Blvd/Lake 

St 

EB 121 (67) 

77 (32) 

878 (908) 30 (19) 

23 (16) 

1117 (956) 

NB 2 (2) 78 (189) 2 (2) 76 (194) 

SB 57 (0) 309 (373) 0 (1) 343 (376) 

Vernon 

St/HWY 100 

Off-Ramp 

WB 10 (4) 

40 (1) 

80 (30) 5 (5) 

1 (1) 

80 (30) 

Notes: EB = Eastbound, WB = Westbound, SB = Southbound, NB = Northbound. 

 N/A = Not applicable. 

XX (YY) = AM peak hour (PM peak hour). 

Control delay is expressed in seconds per vehicle. 

 Vehicles served is expressed in vehicles through the intersection approach in the peak hour. 

Shaded cells represent where the control delay is greater than 55 seconds per vehicle for either 

peak hours. 

The operations of the HWY 100 freeway were evaluated for the 2031 design year with a 

single lane added in each direction with and without various interchange improvement 

alternatives. 

Table 19 shows the results for northbound HWY 100 without interchange improvements 

(baseline) and with the recommended interchange improvements for the HWY 100/TH 7 

and HWY 100/Minnetonka Blvd interchanges. The MOE results in the table represent 

operations for the 2031 design year. 
EXAMPLE

177 

Table 19. Example problem: northbound HWY 100 freeway operations in 2031.

One Lane Added HWY 100, No 

Interchange Improvements 

One Lane Added HWY 100, All 

Recommended Interchange 

Seg- Improvements 

ment Average 

Speed 

Average 

Density 

Vehicles 

Served 

Average 

Speed 

Average 

Density 

Vehicles 

Served 

1 62 (61) 17 (23) 11696 (15908) 62 (58) 14 (29) 9736 (18437) 

2 62 (62) 16 (22) 10916 (15123) 62 (59) 13 (27) 8631 (17219) 

3 48 (48) 20 (25) 12784 (16678) 39 (38) 21 (37) 11316 (19538) 

4 61 (61) 18 (21) 11497 (14491) 60 (59) 15 (25) 9435 (16263) 

5 60 (60) 20 (23) 13846 (17032) 58 (56) 20 (30) 12795 (19878) 

6 61 (55) 21 (26) 14418 (17499) 59 (58) 20 (30) 13617 (20560) 

7 62 (59) 19 (22) 12944 (15301) 62 (61) 17 (26) 11505 (17512) 

8 60 (60) 19 (20) 13828 (16061) 60 (59) 18 (26) 12770 (18673) 

9 58 (58) 23 (24) 14687 (16826) 57 (46) 22 (38) 13968 (19721) 

10 61 (61) 18 (18) 11981 (14200) 60 (56) 18 (26) 11101 (16667) 

11 44 (60) 39 (19) 10517 (11989) 61 (60) 18 (24) 8637 (12766) 

12 18 (41) 75 (30) 12474 (14764) 37 (48) 35 (28) 10580 (15513) 

13 18 (36) 89 (42) 11960 (13914) 60 (60) 18 (24) 8412 (12549) 

14 21 (30) 65 (48) 13785 (16669) 57 (53) 23 (32) 11188 (16192) 

15 27 (53) 71 (33) 13147 (15599) 58 (59) 22 (27) 13571 (18375) 

16 26 (53) 60 (28) 13875 (16669) 61 (61) 19 (29) 8938 (14867) 

17 23 (55) 75 (32) 13594 (15418) 60 (60) 16 (25) 10099 (16564) 

18 33 (44) 48 (38) 15867 (17555) 41 (37) 21 (40) 11873 (20711) 

19 51 (58) 31 (29) 13766 (15732) 61 (58) 14 (28) 8629 (18188) 

20 62 (58) 14 (19) 9365 (12239) 60 (46) 13 (35) 10440 (22242) 

21 60 (56) 15 (20) 10147 (13393) 63 (57) 14 (33) 9218 (20900) 

22 49 (45) 17 (25) 11339 (16298) 62 (57) 14 (34) 9807 (22521) 

Notes: Segments are numbered from the southern end of the HWY 100 study area to the northern end, 

with each segment representing a continuous section of northbound HWY 100 between ramps. 

XX (YY) = AM peak hour (PM peak hour). 

Average speed is expressed in miles per hour. 

 Average density is expressed in vehicles per mile per lane. 

Vehicles served is expressed in vehicles through the segment in the peak period. 

Shaded cells represent where the average density is greater than 38 veh/mi/lane for either of the 

peak hours. 
EXAMPLE

178 

Step 6: Evaluation of Alternatives 

The evaluation of alternatives was prioritized to ensure that the freeway would operate 

sufficiently and the proposed interchange modifications would not negatively impact the 

freeway. A secondary goal was to ensure that the local streets operated acceptably. In 

order to prove the benefits of the reconstruction, the no-build scenario was evaluated for 

the 2031 design year and then compared to the various build alternatives. It was clear that 

under the no-build scenario, both the freeway and interchanges experienced significant 

delays and congestion (as highlighted in step 5 above). 

A number of visual graphics were prepared to present the simulation results in a clear and 

concise manner. The graphics relayed the location and severity of “hot spot” locations to 

non-technical decision-makers. Figure 64 presents an example of these visual graphics, 

which consists of a comparison of the HWY 100/TH 7 interchange operations in 2031. The 

figure shows a schematic drawing of the no-build (existing cloverleaf interchange) and 

preferred (diamond interchange) alternatives, and specific segments were shaded where 

the operations will be unacceptable (decided to be when control delay exceeded 55 

seconds per vehicle or average density exceeded 38 vehicles per mile per lane). 

 
EXAMPLE

179 

Figure 64. Illustration. Example problem: visual comparison of HWY 100/TH 7 interchange 

alternatives. 
EXAMPLE

180 

 Overall, the CORSIM analysis allowed for the testing of many alternatives, which helped 

decision-makers make a sound transportation investment decision in the end. The 

analysis that the recommended build scenario for HWY 100 achieved the goals of ensuring 

that the freeway functioned acceptably, with the proposed interchange configurations at 

the HWY 100/TH 7 and HWY 100/Minnetonka Boulevard interchanges having minimal 

impact to the freeway. The analysis also showed that the HWY 100/TH 7 interchange 

would function well from the local street perspective, but the HWY 100/Minnetonka 

Boulevard interchange required additional work to operate acceptably on the local streets. 

The analysis also allowed a system-wide perspective to be taken on the HWY 100 corridor, 

which was useful because, through the CORSIM analysis, it was discovered that capacity 

expansions are needed just outside the re-construction area at the HWY 100/TH 62 and 

HWY 100/I-394 interchanges to adequately meet the 2031 demand forecasts.
181 

7.0 Final Report and Technical Documentation 

This chapter discusses the suggested 

documentation of the CORSIM analysis in a 

final report with supporting technical 

documentation. The effort involved in 

summarization of the results should not be 

underestimated, since CORSIM produces a 

wealth of numerical output that must be 

tabulated and summarized. The list of 

suggested deliverables was established in 

the scope of the project in Chapter 1. If 

documentation was developed and refined 

throughout the analysis according to the 

scope laid out in Chapter 1, the final step 

may be as simple as collecting and delivering 

the appropriate documents. 

The report form will depend on factors such 

as the reviewing agency’s guidelines, the 

size and complexity of the analysis, and 

consensus on the final deliverables before beginning the analysis. One possible way to 

structure the final deliverables is to create two separate documents, a final report and a 

technical report. This may only be necessary for larger projects while for smaller projects 

the final report and technical documentation may be provided in one report. The key is 

that the results must meet the needs of two 

audiences: the non-technical decision makers 

and the technical specialists responsible for 

technical reviews. The suggested format that 

follows may be useful regardless of whether 

the final documentation is presented in one 

report or divided into two reports. 

7.1 Final Report 

The final report presents the analytical steps, assumptions, and results of the analysis in 

sufficient detail for decision makers to understand the basis for and implications of 

choosing among the project alternatives. The final report should include the following: 

1. Study objectives and scope. 

2. Overview of study approach (tools used, methodology, rationale). 

3. Data collection (sources and methods). 

4. High level model description, diagrams, assumptions, and modifications. 

W orking M odel

Before Calibration W orking Model

Before Calibration

4

7

Error Checking

1

Define the Project

- Define project purpose

- Identify influence areas

-Select approach

-Select m odel

-Estim ate staff tim e 

1 -

-

-

-

-

2 Data Collection

-Traffic volum es

-Base m aps/in ventory

-Field observations

2 -

-

3

Base Model Development

Input data

D evelop quality assurance 

3 -

-

- Review Inputs

- Review Anim ation 

See Chapter 1

See Chapter 2

See Chapter 3

See Chapter 4

W ork prior to

actual modeling

Initial modeling

Yes

Calibrated Model

5

-Volum es & Speeds m atch?

- Congestion in right places?

Compare Model

5 MOEs to Field Data 

-

-

See Chapter 5

Calibration

- Key Results

- Technical Docum entation 

6 -Forecast Demand

-Base Case

-Project A lternatives

Alternatives Analysis

-M odify G lobal Param eters

-M odify Link Param eters

-M odify Route Choice Param eters

Adjust Model Parameters

-

-

Final Report

Acceptable

Match?

N o

See Chapter 6

See Chapter 7

Model

Application

Project documentation must meet the 

needs of two audiences: the nontechnical decision makers and the 

technical specialists responsible for 

technical reviews. 
182 

5. Demand forecast assumptions (assumed growth inside and outside of the study area, 

street improvements, variations to support a sensitivity analysis, etc.) 

6. Description of alternatives and modifications (improvements). 

7. Discussion of success or failure of design/alternatives. 

8. Results and recommendations. 

The benefits and implications of alternatives should be presented in the final report, 

preferably in layman terms. Using the output data, summarizing it, and converting it to 

decision support intelligence should make it very clear what decisions are recommended. 

7.2 Technical Report 

The technical report plus appendices 

should document the CORSIM analysis in 

sufficient detail, including the version of 

the software used, to enable an analyst to 

understand the calibration process, repeat 

the alternatives analysis, and reproduce 

the results. The technical report may be 

an appendix to the final report or a separate document. The technical report is a vital step 

in preserving the rationale for the various decisions that were made in the process of 

developing, calibrating, and operating the CORSIM model. Due to the stochastic nature of 

simulation models, the high probability of errors in model coding, and incorrect judgment, 

these models must “hold up” to scrutiny. 

The technical report should typically be submitted with both electronic data and hard copy 

printouts of project drawings and narrative descriptions of the material provided. The 

technical report should include the model input, data collection and field observations, 

calibration adjustments, model results, and output files (in electronic format) for the final 

model calibration run and alternatives analysis model runs. In addition to the electronic 

format, the technical report should include a printed listing of the files with a text 

description of the contents and purpose of each file. Each step in the analysis should be 

documented and should include: 

1. Study Objectives and Scope. 

2. Data Collection. 

• Input Data. 

o Link-node diagrams for all alternatives. 

o Plan sheets of the link-node diagrams. 

o Lane schematics. 

• Traffic demand data. 

o Arterial turning movement counts - raw and balanced. 

The technical report should document the 

CORSIM analysis in sufficient detail to 

enable an analyst to understand the 

calibration process, repeat the alternatives 

analysis and reproduce the results. 
183 

o Freeway mainline and ramp traffic volumes. 

o Traffic count reconciliation process and results. 

o Balanced traffic count dataset. 

o Origin-destination matrix calculations (if necessary). 

• Traffic control data. 

o Ramp metering rates and timing data. 

o Signal timing data from signal controller printouts and field observations. 

• Transit, pedestrian, bicyclist, or other relevant data. 

• Traffic operations and management data (ITS devices and locations, traveler 

information sources, etc.) 

• Field observations (video, pictures, sketches, or notes). 

3. Model Development. 

• Model assumptions. 

• QA/QC process and results. 

• Coding techniques for complex or unconventional geometrics or operations. 

4. Error Checking. 

• Error checking process and results. 

• 100% coded model. 

5. Calibration. 

• Calibration process, tests, and results (which parameters were modified and why). 

6. Alternative analysis. 

• Sensitivity analysis. 

• MOE report on a spatial and temporal scale to show how the MOEs change 

throughout the analysis period and study area. 

• Final results and recommendations. 

• Output data (electronic files). 

o CORSIM TRF files. 

o TRAFED TNO files. 

o Background image files. 

o MOE files. 

o Configuration files for MOE multi-run data. 

o Signal optimization tool files. 

o CADD files. 

7.2.1 Technical Memorandums 

Technical memorandums are intermediate reports of technical issues pertaining to the 

model during the course of the project. These memos are usually defined during the 

project scoping process; however, during the project, the need to elaborate on a particular 
184 

issue may be necessary. Below are some of the intermediate tech memos that may need to 

be prepared. 

• Traffic Demand Forecast Methodology and Results. Future year demand forecasts are 

a critical factor in the alternatives analysis, and thus the forecasts need to be clearly 

documented and agreed to by all parties involved before beginning the modeling 

process. This memorandum can be incorporated into the final documentation. 

• Intermediate Modeling Issues. During the modeling process, unusual or complex 

issues or problems may arise where an unconventional modeling approach may be 

required. This may require documentation to record the problem and potential 

solutions. Discussions with software technical support personnel may also be needed. 

Any such modeling issues could be documented in a memo, discussed, and a 

satisfactory approach should be agreed upon before beginning the alternatives analysis. 

• Model Calibration. A well-calibrated model is crucial to a sound analysis of 

alternatives, and thus the calibration needs to be clearly documented and agreed to by 

all parties involved before beginning the alternatives analysis. This memo would 

document the process and resulting changes made to the model related to calibration. 

The memo would also provide justification for any model changes and supportive 

statistics of comparisons between observed and modeled MOEs. 

• MOE Summary Report. The interim results of an alternatives analysis may be 

summarized in a memo that contains the MOEs for the alternatives tested. Such a 

memo would give the reviewing agencies a chance to review and comment on the 

results before the final report is prepared and the analysis is complete. The report 

should present the MOEs on a spatial and temporal scale to show how the MOEs 

change throughout the analysis period and study area. 

7.3 Presentation of a CORSIM Simulation Analysis 

The presentation of the CORSIM analysis is very 

important to the possible acceptance or rejection 

of the recommendations of the analysis. CORSIM 

can produce such a large quantity of data that it 

can become overwhelming to decision makers. 

The data must be reduced by using drawings, 

graphics, animation, and summary data tables. Decision makers may be skeptical of the 

methods used to produce the data. The presenter must be prepared to defend the analysis 

methods. 

Animation of simulation runs representing current conditions and various alternatives is a 

very effective way to display the traffic operations to decision makers and, in particular, to 

point out deficiencies, or unacceptable operations, within the alternatives. The animation 

should focus on areas that show the advantages and disadvantages of the alternatives. A 

particularly difficult issue is in choosing which simulation run to show an animation, as it 

is not possible to animate the mean values of all MOEs. The analyst must choose an 

Animation of selected areas of 

simulation runs is a very effective way 

to display the traffic conditions to 

decision makers. 
185 

individual run that demonstrates a representative run of the MOEs of interest. The analyst 

must also determine if they want to animate the worst case, best case, or mean case of the 

MOEs of interest. The “Reviewing Animation Output” discussion in section 6.6 contains 

important information on how to select a representative run when presenting an 

animation. 
EXAMPLE

186 

7.4 Example Problem: Final Report 

Returning to the example problem for HWY 100, a final report was prepared for 

presentation to the client. The format for this document was one final report with 

appendices providing the technical output of the preferred alternative. The final report 

follows the model development and application process outlined in this document. The 

report begins with a brief executive summary that provides a project overview. Then, 

details of data collection, model development and calibration are provided before moving 

into the alternatives analysis discussion. The report thoroughly explains the alternatives 

and provides graphics and spreadsheets to easily compare output data. The report also 

addresses the preferred alternative, providing graphics and spreadsheets to support the 

conclusions. 
187 

Appendix A: Introduction to CORSIM Theory 

This appendix provides an introduction to the fundamentals of CORSIM model theory. 

CORSIM has a long history reaching back to the 1970s and mainframe computers. Many 

fixes, improvements, and enhancements have been made since the original coding but the 

basic theory of CORSIM still retains its roots. In 1994 two separate programs, one for 

modeling surface streets (NETSIM) and one for modeling freeways (FRESIM), were 

combined to form the CORSIM program. CORSIM can model both uninterrupted and 

interrupted types of facilities. Each facility is modeled in a separate “subnetwork”. 

“Uninterrupted flow facilities have no fixed elements, such as traffic signals, that may interrupt the 

traffic flow. Traffic flow is a result of the interactions among vehicles in the traffic stream and 

between vehicles and the geometric and environmental characteristics of the roadway.” (3) 

Uninterrupted flow facilities in CORSIM are represented by freeways. They are modeled 

internally in CORSIM using code that came from FRESIM (abbreviated for FREeway 

SIMulation). FRESIM was the successor to FHWA’s freeway simulation program called 

INTRAS, which was developed in the late 1970s.(21) Its purpose was to assess the 

effectiveness of freeway control and management strategies. INTRAS was originally 

developed to work on a mainframe computer, while FRESIM was developed to operate on 

a microcomputer. 

“Interrupted flow facilities have fixed elements that may interrupt the traffic flow. Such elements 

include traffic signals, stop signs, and other types of controls. These devices cause traffic to stop 

periodically (or slow significantly), irrespective of how much traffic exits.” (3)

Interrupted flow facilities in CORSIM are represented by surface streets. They are 

modeled internally in CORSIM using code that came from NETSIM (abbreviated for 

NETwork SIMulation). NETSIM was originally developed as the “Urban Traffic Control 

System” (UTCS-1) in the early 1970s. It was created for FHWA’s test bed in Washington, 

DC.(8) The program evolved under the direction of the FHWA and was later named 

NETSIM. 

The physical environment is represented as a network composed of nodes and 

unidirectional links. The links generally represent urban streets or freeway sections, and 

the nodes generally represent urban intersections or points at which a property changes 

(such as a change in grade or free-flow speed). In a corridor simulation with both surface 

streets and freeways, each type of facility is referred to as a subnetwork.(1) Vehicles in 

CORSIM travel from one subnetwork to another subnetwork on a second-by-second basis. 

CORSIM applies time step simulation to model traffic operations. This is called a 

microscopic model, wherein the behavior of every vehicle is represented at each time step. 

Other types of models include macroscopic and mesoscopic. A microscopic simulation, 

such as CORSIM, models individual vehicle movements based on car-following and lanechanging theories on a second-by-second basis for the purpose of assessing the traffic 
188 

performance of highway and street systems. In a macroscopic model, platoons of vehicles 

are moved on a section-by-section basis over short time periods rather than by tracking 

individual vehicles every second. Macroscopic models do not have the ability to analyze 

transportation movements in as much detail as microscopic models and therefore have 

fewer computer requirements. A mesoscopic model combines the properties of both 

microscopic and macroscopic models. The vehicle movements are based on local 

prevailing speeds, consistent with established macroscopic speed-density relationships. 

CORSIM is a stochastic simulation model, which means that it incorporates random 

processes to model complex driver, vehicle, and traffic system behaviors and interactions. 

Stochastic simulation models produce output that is itself random. On the other hand, a 

deterministic model produces output that is “determined” once the set of input quantities 

and relationships in the model have been specified. The Highway Capacity Model (HCM) 

is an example of a deterministic model. 

Note that a random process is directly related to an observed behavior. For example, at a 

particular intersection it can be observed that twenty percent of the vehicles turn left. In 

CORSIM, a random number is drawn each time a vehicle makes a turn decision. If the 

random draw produces a number that is twenty or below, the vehicle will be assigned a 

left turn. This may produce three vehicles that turn left in succession or it may not 

produce a left turning vehicle in 100 draws. However, over the course of a large number 

of vehicle decisions, twenty percent of the vehicles will end up turning left. In contrast, if 

the twenty percent was used directly without modeling a random process, every fifth 

vehicle would turn left. This would produce the correct percentage of vehicles turning 

left, but would not represent the behavior observed in the real world. 

Because the output of a stochastic model is random, each run of a stochastic simulation 

model produces only estimates of a model’s true characteristics for a particular set of input 

parameters. Thus, relying on the MOEs generated from a single run of CORSIM may be 

misleading. To produce meaningful MOEs, several independent runs of the model will be 

required for each set of input parameters to be studied. For example, a single run may 

result in three very conservative drivers driving side-by-side on a three-lane roadway, 

blocking more aggressive drivers behind them. The resulting MOEs would reflect a lower 

average speed and higher travel time than has been observed in the real world, although it 

is possible that this scenario could happen in the real world given enough observations. 

To gain a better understanding of network performance, the network should be simulated 

several times using different sets of random number seeds (to produce a different series of 

random draws). The resulting distribution of MOEs should then be an accurate 

representation of the network performance. 

CORSIM uses three random number seeds during each simulation run to decide many 

processes. One random number seed is used in generating vehicle entry headways, one is 

used to determine surface street routing, and one is used to determine time dependent 

stochastic processes like time and location of parking and short term events. When a 

vehicle uses a random number it stores a new random number seed to be used the next 

time a random number is required. This sequence of random number seeds is repeatable. 
189 

The first random number seed is used to generate vehicle entry headways. Stochastic 

vehicle entry headways can be generated from a normal distribution, negative exponential 

distribution, or Erlang distribution (see appendix E for more detail on vehicle entry 

headway distributions). By default, CORSIM emits vehicles from entry links and source 

links at a constant rate, derived from the input volume. The user can vary the vehicle 

generation by selecting a distribution of the entry times instead of a constant rate and 

change this seed between runs to produce variation in the times that vehicles are 

scheduled to enter the simulated roadways. Note that the total number of vehicles due to 

be emitted will remain the same between runs even though the time between individual 

vehicle emissions will vary. 

A second random number seed is used in generating vehicles for the surface street traffic 

stream. Decisions such as the routing pattern of each vehicle and the characteristics of 

each driver/vehicle combination are generated from this base seed. The user should keep 

this entry constant during multiple runs if he/she wants to obtain identical traffic 

movements. A series of runs with different values for this random number would 

illustrate the variance in the traffic performance measures of effectiveness that are due to 

variations in traffic patterns. 

The third random number seed is used by CORSIM for all stochastic processes other than 

vehicle headway generation and traffic stream generation. It is used in all time-dependent 

stochastic decision-making processes (e.g., accepting available gaps for turns, determining 

location and duration of lane blockages, calculating pedestrian inter-arrival times, and 

determining lane change gap acceptance risk). The user should vary this entry during 

multiple runs to obtain different traffic environments. By changing this random number 

seed and keeping the traffic random number seed constant, the user can simulate with 

traffic streams exhibiting identical routing and driver/vehicle characteristics, but in a 

stochastically-derived traffic environment. 

A more detailed description of random numbers in CORSIM is given in appendix D. 

Each vehicle is identified by fleet (auto, carpool, truck, or bus) and by type. Up to sixteen 

different types of vehicles (with different operating and performance characteristics) can 

be specified, thus defining the four vehicle fleets. Furthermore, a "driver behavioral 

characteristic" is assigned to each vehicle. Each vehicle is assigned one of ten different 

“driver types” that increase in aggressiveness from 1 to 10. Its kinematic properties (speed 

and acceleration) as well as its status (queued or moving) are determined. Turn 

movements are assigned stochastically, as are desired free-flow speeds, queue discharge 

headways, and other behavioral attributes. As a result, each vehicle's position and 

behavior can be simulated in a manner reflecting real-world processes. 

Vehicles are allocated to the network via an imaginary link called an entry link. The 

vehicle characteristics (such as type of vehicle, driver type, desired lane, and desired 

speed) are stochastically assigned. The vehicle will enter the network at user assigned 

volumes at intervals stochastically determined by the user’s preferred method of emission. 

In general, a vehicle that is not influenced by other vehicles or network objects will attempt 

to increase its acceleration to the maximum possible value in an effort to attain a desired 
190 

free-flow speed. When the desired free-flow speed has been attained no more acceleration 

is allowed. Each of the ten driver types will have a desired free-flow speed on a particular 

link that is equal to the facility free-flow speed adjusted by a multiplier unique to the 

driver type. The free-flow speed of the facility is defined as the speed in free flowing 

conditions such as a low volume condition. 

The car-following logic assumes that a follower vehicle will maintain a desired headway 

between itself and its leader. The distance between the vehicle and its leader will depend 

on the speed the vehicle is traveling. For example, if a vehicle is traveling at a speed of 

27.4 meters per second (m/s) (90 feet per second (ft/s)), and has a desired headway of one 

second, it will try to maintain a distance of 27.4 m (90 ft) from its leader. Each of the ten 

driver types has a unique, desired headway. If the current distance is not sufficient to 

maintain the desired headway, the vehicle will decelerate in an effort to attain the desired 

headway. If the distance is larger than the desired headway the vehicle will attempt to 

accelerate to achieve the desired headway unless it is at its desired free-flow speed. 

The behavior of a lead vehicle is also dependent on the upcoming network characteristics 

(e.g., changes in lane configuration, turning movements, control, blockages, etc.). The 

vehicle will scan the upcoming network objects and attempt to adjust its speed or lane in 

order to react to the objects. 

A vehicle that must make a lane change due to a lane drop, exit, turn, or blockage will 

make a “mandatory” lane change. A mandatory lane change is the most stringent of the 

types of lane changes. Vehicles will accept a higher risk (deceleration) as the vehicle 

approaches the network object requiring the lane change. A vehicle that is traveling 

slower than its desired speed may find it advantageous to change lanes to achieve a higher 

speed. This type of lane change is referred to as a “discretionary” lane change. 

CORSIM accumulates different types of data every time step (i.e., every second). These 

“raw” data, such as travel time and distance traveled, are gathered as the vehicles move 

and interact with other vehicles and traffic control objects. At the end of each user 

specified time interval the accumulated “raw” data is used to report MOEs and produce 

other MOEs. For example, the distance traveled is divided by the travel time to produce 

an average speed. 

Vehicle mix 

CORSIM only allows four different fleets (Passenger Car, Truck, Bus, and Carpool) and 

defaults to nine vehicle types. By default, only the Passenger Car Fleet is used. The 

vehicle mix attributed to Trucks and Carpools must be input by the analyst or they will not 

be used. If Trucks and Carpools are requested they will default to the percent of fleet 

shown in Table 20. Prior to combining NETSIM and FRESIM to form CORSIM, each 

subnetwork had its own vehicle type identifiers. In the table, both the NETSIM (N) and 

FRESIM (F) identification numbers and the default percentage of fleet for each vehicle type 

are listed. 
191 

Table 20. Default CORSIM vehicle specifications. 

Fleet 

Component 

Vehicle ID and Type Perform. 

Index 

Length 

(feet) 

Occupants Default % of 

Fleet Component 

PASSENGER 

CAR 

2(F) 1(N) = High performance 

1(F) 5(N) = Low performance 

2 

1 

16 

14 

1.3 

1.3 

75(F) 75(N) 

25(F) 25(N) 

TRUCK 3(F) 2(N) = Single unit 

4(F) 6(N) = Semi-trailer with medium load 

5(F) 7(N) = Semi-trailer with full load 

6(F) 8(N) = Double-bottom trailer 

3 

4 

5 

6 

35 

53 

53 

64 

1.2 

1.2 

1.2 

1.2 

31(F) 100(N) 

36(F) 0(N) 

24(F) 0(N) 

9(F) 0(N) 

BUS 7(F) 4(N) = Conventional 7 40 25.0 100(F) 100(N) 

CARPOOL 9(F) 3(N) = High performance 

8(F) 9(N) = Low performance 

9 

8 

16 

14 

2.5 

2.5 

75(F) 100(N) 

25(F) 0(N) 

Notes: (F) = FRESIM, (N) = NETSIM. 

Each vehicle type must belong to one or more of the fleets. The percentage of a fleet for all 

vehicle types that make up the fleet must add up to 100 percent. For example, a 10.7 m (35 

ft) single unit truck could make up a percentage of the Truck fleet and also make up a 

portion of the Bus Fleet when modeling a second, shorter bus type. However, the 

Conventional bus type percent of the Bus fleet would need to be reduced to make the total 

Bus fleet add up to 100 percent. Surface streets and freeways can have their own 

percentage of the vehicle type within the fleet. 

The table also shows the default performance index, default length, and default average 

number of occupants for each vehicle type. The length specifies the bumper-to-bumper 

length of a vehicle type. The occupants (load factor) are used to accumulate and calculate 

MOE related to numbers of people. 

Performance Index 

CORSIM maintains tabulated data for maximum acceleration, fuel consumption, and 

environmental emissions as well as for the effect of grade on acceleration and fuel 

consumption. These tables are referenced by vehicle speed and (for environmental 

emissions and fuel consumption only) acceleration. CORSIM contains seven different 

tables for each of these data types. The seven tables correspond to the seven groups of 

vehicle performance. The seven groups are referenced by the Performance Index. The 

analyst can specify which of the seven tables best describes the defined vehicle 

performance. The default tables should be used unless there is adequate support to 

deviate from the defaults. 

Acceleration Tables 

CORSIM allows the analyst to modify any or all of the tabulated data that define 

maximum acceleration, grade correction factor for maximum acceleration, and grade 

correction factor for fuel consumption. The data are input for speeds in 10 ft/s speed 
192 

intervals. Values in between those entered are computed internally by the CORSIM model 

via linear interpolation. 

Figure 65 shows a graph of the default maximum acceleration in feet per second squared 

for each speed in feet per second for the seven different performance indexes. High 

performance vehicles use performance index two while heavy trucks use performance 

indexes five and six. 

-2

0

2

4

6

8

10

12

14

0

4

8

12

16

20

24

28

32

36

40

44

48

52

56

60

64

68

72

76

80

84

88

92

96

100

104

108

Speed (ft/sec)

Acceleration (ft/sec2

)

PI 1

PI 2

PI 3

PI 4

PI 5

PI 6

PI 7

Figure 65. Graph. Maximum acceleration versus speed by performance index. 

Vehicle Fuel Data and Vehicle Emissions 

CORSIM allows the user to modify any or all of the parts of internal data tables defining 

fuel consumption and pollutant emission rates. The tables express these rates as a function 

of acceleration, given the vehicle performance index and vehicle speed. Figure 66 shows 

the default fuel consumption rates versus the speed at different acceleration rates. Similar 

tables exist for different types of vehicle emissions. 

This data is difficult to collect and calibrate and has not been updated within CORSIM in 

many years. It is recommended to use this data for comparison analysis only. Do not use 

this data as an absolute indication of the capabilities of today’s vehicles. For example, it 

may not be valid to report that 200 fewer grams of hydrocarbons were emitted using a 

certain alternative. It may be more proper to report a 10 percent decrease in emissions 

with a certain alternative. 

PI 1 

PI 2 

PI 3 

PI 4 PI 5 PI 6 

PI 7
193 

0

200

400

600

800

1000

1200

1400

0

4

8

12

16

20

24

28

32

36

40

44

48

52

56

60

64

68

72

76

80

84

88

92

96

100

104

108

Speed (ft/sec)

Fuel Consumption Rate x 10,000 (gallons/sec)

0 ft/sec2 1 2 3 4 5 6 7 8 9 10

Figure 66. Graph. Fuel consumption for different acceleration rates 

for performance index 1. 

Fleet Type 

The need to assign each vehicle type to one or more fleet components reflects the fact that 

several considerations are based upon the identification of fleet components. Each vehicle 

processed by the model is identified by type and fleet component. For example, the 

analyst can reserve lanes for buses and carpools, specify data so that certain streets are 

reserved for buses, and specify the percentage of trucks and carpool vehicles on each entry 

link. Bus vehicles are assigned routes and stations. A carpool fleet can include several 

vehicle types (such as automobiles and minibuses), or a bus fleet can include several 

different types of buses with different performance characteristics because a vehicle type 

can be part of one or more fleet components. 

Vehicle Types 

CORSIM allows the user to create or modify up to 16 different vehicle types. Each vehicle 

must be part of one or more of the vehicle fleets. 100 percent of each vehicle type must be 

allocated to the different fleets. Each vehicle type must use one of the seven existing or 

modified vehicle performance indexes. These are used to determine the vehicles 

acceleration, emissions, and fuel usage. Each vehicle type may have its own 

characteristics. 

Freeway Vehicle Parameters 

In addition to the vehicle parameters listed above, freeway vehicles have some separate 

user-modifiable parameters including Jerk Factor and Maximum Deceleration Rate. 

Acceleration: 
194 

Jerk Factor 

The jerk factor (rate of change of acceleration) value is the maximum change allowed in the 

value of acceleration from one time step to the next for a vehicle type. It is input in tenths 

of feet per second cubed. 

Maximum Deceleration Rate 

The maximum deceleration rate is the maximum deceleration on level grade and dry 

pavement for a vehicle type. It is used in car-following and lane-changing. 

Surface Street Vehicle Parameters 

In addition to the vehicle parameters listed above, surface street vehicles have an 

additional user-modifiable parameter called the Headway Factor. The Headway Factor 

defines a multiplicative factor applied to the mean discharge headway that was assigned 

on a link-specific basis. This factor reflects the difference in queue discharge headway 

between a “typical” passenger car and this vehicle type. 
195 

Appendix B: CORSIM Capabilities and 

Limitations 

This appendix identifies some of the capabilities and limitations of the CORSIM model. 

CORSIM Capabilities 

CORSIM can model many elements of modern traffic systems explicitly. Many of the 

other features can be approximated using the basic elements of CORSIM, along with 

engineering judgment. There are other tools that may be better suited for a given 

situation. This section is to be used to decide if CORSIM is the appropriate tool. The 

authors do not want to promote the use of CORSIM for situations in which we know there 

are tools that may be better suited for the situation. 

There may be modeling situations where CORSIM models some portion of the network 

better than other tools but the other tools may model different portions of the network 

better than CORSIM. Only the analyst’s engineering judgment can be used to decide 

which tool to use. For example, if the sole purpose of the analysis is to model 

roundabouts, CORSIM is not the tool to use. If the main purpose of the analysis is to 

model a freeway segment that has a roundabout at the end of one of the off-ramps, 

CORSIM may be a viable option. 

Table 21 and Table 22 are arranged into freeway and surface street systems and show 

CORSIM built-in capabilities. 
196 

Table 21. CORSIM freeway modeling capabilities. 

Freeway Modeling Features CORSIM 

Capability? 

Bottlenecks Yes 

HOV lanes, including ramp meter bypass Yes 

Barriers Yes 

Lane closures Yes 

Interchanges Yes 

Weaving sections Yes 

Toll booths / weigh stations / draw bridges No* 

Oversaturation (congestion) Yes 

Time-varying demand Yes 

Trucks biased or restricted to specific lanes Yes 

Incidents Yes 

Workzones Yes 

Surveillance Yes 

Fixed-time ramp metering Yes 

Time varying fixed-time ramp metering Yes 

Traffic-responsive ramp metering Yes 

Bus operations Yes 

*These features are not modeled explicitly by CORSIM, but can be modeled using 

basic CORSIM elements. Some of them require using both surface street elements 

and freeway elements. 
197 

Table 22. CORSIM surface street modeling capabilities. 

Surface Street Modeling Features CORSIM 

Capability? 

Bottlenecks Yes 

Complex intersections Yes 

HOV lanes Yes 

On-street parking Yes 

Two-way left turn lanes No* 

Oversaturation (congestion) Yes 

Time-varying demand Yes 

Incidents Yes 

Delay due to Pedestrians Yes 

Workzones Yes 

Unsignalized intersections Yes 

All-way stops Yes 

Roundabouts No* 

Fixed-time signals Yes 

Actuated signals Yes 

Signal coordination Yes 

Surveillance Yes 

U-turns No* 

Transit signal priority No 

Bus operations Yes 

Light rail No* 

*These features are not modeled explicitly by CORSIM, but can be modeled using 

basic CORSIM elements. Some of them require using both surface street elements 

and freeway elements. Appendix K contains some examples of ways to code 

situations that are not directly modeled by CORSIM. 
198 

CORSIM Limitations 

Like all models, CORSIM is an approximation of the real world. CORSIM has limitations 

that must be understood in order to use the model correctly. Understanding the 

limitations will also prevent the analyst, reviewer, decision maker, and reviewing public 

from expecting too much from the model. Some of these limitations may warrant using a 

different simulation tool. 

The components of CORSIM were designed as flow models to generate the correct overall 

flow on the links. New users of CORSIM often expect it to model the smallest details of 

driver behavior and vehicle interaction perfectly. During CORSIM’s development, 

individual vehicle interaction details were not as critical as the overall traffic flow. 

CORSIM was designed to operate very fast and efficiently. When the vehicle animation 

capabilities were added, many vehicle interaction problems were discovered. Many 

problems have been fixed; however, some low-level vehicle interaction problems still exist. 

Scrutinizing vehicle animation will usually yield a situation that is not exactly life-like. 

The analyst and reviewers must emphasize that the calibrated model will match the real 

world traffic flows, which is what CORSIM was designed to do. 

One reason some driver behaviors and vehicle interactions do not match the real world is, 

by default, CORSIM uses a one-second time step. Vehicle positions and interactions are 

only updated every whole second. In the real world, drivers begin to react and apply 

accelerations and decelerations in smaller time frames than one second. Beginning with 

TSIS/CORSIM version 6.0 the freeways can be updated at less than one second intervals, 

although the sub-second movements cannot be animated in TRAFVU. In many cases, this 

improves the vehicle interaction but it slows the execution time of CORSIM. 

CORSIM is a one-dimensional model augmented at lane change. Each vehicle’s actions are 

based on the current link and current lane only. For safety reasons, real-world drivers 

often adjust their speed to reduce the speed differential between lanes. In CORSIM, 

vehicles do not adjust their speed based on vehicles in adjacent lanes unless a lane change 

is required. 

Each vehicle follows the vehicle directly in front of it and in most cases is only aware of 

that vehicle. In the real world, drivers often react to the actions of the vehicles 

downstream of the leader. CORSIM does not have this capability. A CORSIM vehicle 

does not have the capability of making lane choice based on the type of vehicles 

downstream. A real-world driver may change lanes to avoid being behind a large slow 

moving vehicle that is currently stopped in queue at a traffic signal. CORSIM does not 

have this look-ahead decision making process. 

No major adjustments are made by CORSIM vehicles in order to find a better gap. Realworld drivers will speed up or slow down in response to larger gaps ahead of them or 

behind them. CORSIM vehicles will make adjustments to find a better gap based only on 

the vehicles directly adjacent to them. Real-world drivers on an on-ramp may adjust their 

speeds upstream of the gore point to fit into a gap in the mainline traffic. CORSIM 

vehicles do not have this capability. 
199 

CORSIM vehicle positions are based on the link they are on, the lane they are in, and the 

distance from the upstream end of the link. All vehicles are in a lane at all times. There is 

no capability to move a vehicle over by half of a lane. At the point where lanes are added 

or dropped there is no transition region. The lane is either there or it is not there. 

TRAFVU depicts a transition region (lane taper) for display purposes only. 

CORSIM surface streets can only have seven lanes of traffic total. There can be only two 

turn bays on each side of the link. There are no acceleration lanes on surface streets. 

CORSIM freeway links can have five mainline lanes plus three auxiliary lanes on the left 

side of the link and three auxiliary lanes on the right side of the link. However, full 

auxiliary lanes may be used as through lanes in most situations. This allows a total of 11 

through lanes. 

Internal nodes can be labeled from 1 through 6999, limiting the number of internal node to 

6,999 nodes. Interface nodes can be labeled from 7000 through 7999, limiting the number 

of interface nodes to 1,000 nodes. Entry and exit nodes can be labeled from 8000 through 

8999, limiting the number of entry/exit nodes to 1,000. 

The number of links is only limited by the number of nodes and the number of 

connections allowed at a node. The maximum number of approaches to a surface street 

node is five. The maximum number of approaches or departures from a freeway node is 

two. 

The maximum length of a surface street is 3,047.7 m (9,999 ft). The minimum length of a 

surface street is 15.2 m (50 ft). Using all possible nodes and two direction surface links and 

the maximum link length, it would be theoretically possible to model over 41,842.9 km 

(26,000 mi) of surface streets in one network. 

The maximum length of a freeway link is 30,479.7 m (99,999 ft). The minimum length of a 

freeway link is dependent on the maximum distance the fastest driver type can travel in 

one second based on the free-flow speed. Normally the minimum length is around 33.5 m 

(110 ft). Ramp links or freeway links with low free-flow speeds may have much shorter 

lengths. Using all possible nodes and the maximum link length, it would be theoretically 

possible to model over 212,433.4 km (132,000 mi) of freeway in one network. 

There are nineteen possible time periods in CORSIM. Each time period is limited to 9,999 

seconds. Theoretically, 52 hours of time could be modeled. Using typical 15 minute time 

periods, 19 total time periods would model 4.75 hours of time. 

Freeway links have a maximum free-flow speed of 112.6 kilometers per mile (km/h) (70 

miles per hour (mi/h)). This is the maximum mean speed that can be input to the model. 

Some vehicles with more aggressive driver types will travel faster than this speed but not 

more than 120.4 km/h (74.8 mi/h). The maximum speed on surface streets is 104.6 km/h 

(65 mi/h). The minimum speed on surface streets is 1.6 km/h (1 mi/h). 

CORSIM is not a dynamic traffic model where turn decisions are made based on current 

conditions. A vehicle will wait in a queue for the duration of the simulation rather than 

change turning movements to take an alternate path. 
200 

TSIS and CORSIM are not geometric design tools. The drawing capability, radius of curve 

data, superelevation data, and pavement type data are only intended to supply CORSIM 

with input data for rough geometric estimates for vehicle movement purposes. 

Traffic Control 

CORSIM’s pre-timed control is limited to 12 intervals, which can be configured to model 

four sets of green, yellow, and red times. This may be a limitation for intersections with 

more than four approaches or where more than four phases are required. However, a pretimed signal with more than 12 intervals can be replicated by coding it as actuated control 

with all phases on maximum recall. An actuated controller does not have the 12-interval 

limitation in CORSIM. 

CORSIM’s actuated control model is based on a dual-ring, eight-phase controller, as 

specified in the NEMA TS 1 standard. The CORSIM model can be configured to emulate 

the operation of the Model 170 controller and many of its features, but the CORSIM 

terminology is taken from the NEMA specification. The CORSIM model is limited to two 

rings and eight phases, where phases 1 through 4 are in ring 1 and phases 5 through 8 are 

in ring 2. However, fewer than eight phases and single ring operation can be coded. The 

barrier is fixed between phases 1, 2 (5, 6) and 3, 4 (7, 8). 

Facilities Not Modeled 

There are some types of facilities that cannot be directly modeled in CORSIM, nor can they 

be indirectly modeled without substantial software development and interfacing with 

CORSIM via a run time extension. 

• Transit signal priority (changing the signal timing based on approaching transit 

vehicles). 

• Light rail facilities. 

• Variable message signs. 

Facilities Indirectly Modeled 

Some facilities that are not explicitly modeled may be modeled indirectly in CORSIM. It 

may be necessary to use a different tool other than CORSIM that directly models these 

types of facilities if their presence in the model is critical. Some discussion of these types 

of facilities is presented in appendix K. 

• Roundabouts. 

• U-turns. 

• Toll booths. 

• Weigh station. 

• Draw bridge. 

• Two-way left turn lane. 
201 

Appendix C: Initialization Period 

This appendix provides guidance on the estimation of the duration of the initialization 

period, after which the simulation has stabilized and it is then appropriate to begin 

gathering performance statistics. 

Initialization Period, Fill Time and Equilibrium 

Large networks need longer fill time for vehicles to reach their destination. If equilibrium 

is not reached, a steady state is not present. Even if the conditions that indicate that 

equilibrium has been reached are satisfied, a steady state may still not be present. There 

are conditions where the network may report reaching equilibrium when in actuality it has 

not. These conditions are discussed in this appendix. 

If equilibrium is not reached or is falsely reported as being reached, the statistics that are 

gathered in the early portion of the simulation will not reflect conditions as they are in the 

real world. The MOEs gathered during non-equilibrium periods also affect cumulative 

data for the entire simulation. 

Figure 67 shows a graph of the number of vehicles discharged from an internal link in an 

example network that has a constant volume (i.e., no variation in demand). While the 

demand is constant for this network, the internal link does not reach a steady state until 

approximately four minutes into the simulation due to the time it takes for all portions of 

the network to fill up with vehicles. It is clear from the figure that the initialization period 

should be at least four minutes in this example, when equilibrium has occurred on the 

internal links. 

0

10

20

30

40

50

60

70

80

90

100

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Time (minutes)

Vehicles Discharged

Figure 67. Graph. Vehicles discharged from an internal link in equilibrium example. 

A steady-state volume 

occurs at approximately 

four minutes, indicating 

equilibrium for this link. 
202 

If the specified maximum initialization time is not an integer multiple of the time interval 

specified, the program will round it down to the nearest integer multiple of the time 

interval. The algorithm to test for equilibrium requires the initialization time to be at least 

three time intervals. If the specified initialization time is less than three time intervals, the 

program will automatically increase initialization time to three time intervals. 

The analyst selects the initialization options in TRAFED on the Network/Properties dialog 

on the Run Control Page. These options are discussed below. 

Use initialization period 

The analyst may want to turn off the initialization period to view how the network fills or 

to collect statistics during the initialization period for research purposes. This is a very 

useful debugging tool and also a valuable teaching tool. 

Maximum initialization prior to simulation 

This is the amount of time that CORSIM will use as its maximum initialization period. 

CORSIM can determine that it has reached equilibrium prior to this time and start the 

simulation and collection of statistics. CORSIM will not run longer than this time in the 

initialization period. A message will be displayed to indicate whether or not equilibrium 

has been reached. A rule of thumb is to set this time to the travel time for the longest 

realistic path through the network. 

Stop if initialization does not reach equilibrium 

If the maximum initialization period time has been reached and equilibrium has not been 

achieved, then the simulation will either start collection statistics or stop depending on this 

setting. Stopping the run will prevent data for that run from being used in the statistical 

output. 

Force maximum initialization time 

CORSIM may falsely determine that it has reached equilibrium. The analyst can force 

CORSIM to stay in the initialization period until the maximum time has expired. For 

example, a very large network may have a number of vehicles entering at the extreme 

upstream entry point and on-ramps near the downstream exit point. If the number of 

vehicles entering and exiting are similar, CORSIM may determine that equilibrium has 

been reached well before the entering vehicles can traverse the length of the network. 

The initialization period runs until either equilibrium is reached or the maximum time 

allowed for initialization is reached. When the time allowed has been reached and 

equilibrium has not been reached the simulation will begin unless the user specified that 

the simulation should abort in that case. When equilibrium is reached during the 

initialization period, initialization will terminate unless the user specified that initialization 

should run for the entire time allowed. 
203 

Equilibrium is determined by comparing the number of vehicles in the network on 

consecutive time intervals. If the difference between the current interval and the previous 

interval is less than eight percent and the difference between the previous interval and the 

one before it was less than 12 percent, CORSIM determines that equilibrium has been 

reached. If those conditions have not been met, but the difference between the current 

interval and the previous interval is less than six percent, CORSIM determines that 

equilibrium has been reached. 

The example network in Figure 68 would reach equilibrium prior to the 360-second point. 

It would reach it at 300 seconds because the previous interval (240 seconds) percent was 

less than 12 and the current percent is less than 8. If the user requested the full time to 

reach equilibrium, the initialization would continue to the 420-second point. If force 

maximum initialization time is not requested, the initialization would end and the 

simulation would reset the clock to zero and start collecting statistics. Even if the above 

were not satisfied, the network would have been considered in equilibrium at the 360 

second mark because the 3 percent difference (6.6 – 3 = 3.6%) is less than 6 percent 

difference. 

Figure 68. Illustration. Reaching equilibrium. 

This process does have some flaws. Specifying small (one second) time intervals 

terminates the initialization period too early because the volume does not increase enough 

between periods. Very large networks with high volumes do not allow vehicles to reach 

the center of the network before equilibrium is satisfied because the percentage of volume 

does not change enough. That is why the ability to force the full initialization period to 

occur was added to CORSIM. 

When modeling a network that includes long distances, where travel time may be 

significant, the travel time must be taken into account when setting up the simulation. 

Initialization (fill time) uses the conditions at the beginning of the simulation to fill the 

network of roadways. Use caution to use input data that will reflect the true conditions at 

locations well downstream. In order to accurately model the conditions during a period of 

interest, it may be necessary to start modeling the network with data for the time prior to 

the start of the analysis. 
204 

For example, when modeling a 24.1 km (15 mi) stretch of freeway with three on-ramps, 

take into account the time it takes to travel 24.1 km (15 mi). If the traffic is averaging 96.6 

km/h (60 mi/h), then it will take 15 minutes to travel from the entry point to the end of the 

freeway. If the analysis period starts at 7:30 a.m. and lasts until 8:00 a.m., the actual 

number of vehicles that come onto the freeway from 7:30 to 7:45 a.m. and from 7:45 to 8:00 

a.m. could be input. However, using these counts as the starting counts for the analysis, a 

15-minute initialization period (travel time through the network) will use the 7:30 counts 

to fill the whole network. In actuality, the vehicles departing the freeway crossed the entry 

point (data station or tube counter) at approximately 7:15 a.m. If the volume of traffic 

between 7:15 and 7:30 a.m. is significantly different than it is from 7:30 to 7:45 a.m., then 

traffic conditions downstream will be significantly different. 

As mentioned previously, the analysis period chosen should begin before the onset of 

congestion and end after the dissipation of all congestion to ensure that all queued 

demand is eventually included in the analysis. Further, this discussion on the 

initialization period shows that beginning the analysis period when demand is increasing 

sharply from an uncongested to congested state can cause the demand in the first analysis 

period to be unrepresentative of the actual demand. As a result, the timing of the first 

analysis period is an important consideration, especially when demand is increasing 

sharply, and simulating an additional time period before the actual analysis period would 

better capture the true demand under these circumstances.
205 

Appendix D: Generation and Usage of Random 

Numbers in CORSIM 

Introduction 

CORSIM employs stochastic processes to simulate many aspects of real-world behavior, 

including driver behavior, vehicle operational characteristics, and decision-making 

processes. To facilitate these stochastic models, CORSIM uses a pseudo-random number 

generation process. Figure 69 shows the variation in average speed for a network run 10 

times with different random number seeds. 

25

30

35

40

45

50

300 600 900 1200 1500 1800 2100 2400 2700 3000 3300 3600

Time (seconds)

Average Speed (MPH)

1

2

3

4

5

6

7

8

9

10

Mean

Figure 69. Graph. Random variations in average speed among 10 runs. 

The use of pseudo-random number generators is central to the modeling of stochastic 

processes in simulations.(22) In their text on simulation, Law and Kelton provide a 

thorough discussion on the application and evaluation of random number generators. 

Because the focus of this document is on CORSIM, the reader is referred to Law and 

Kelton for more information on the general application and properties of pseudo-random 

number generators. In TSIS/CORSIM version 6.0, CORSIM uses a random number 

generator recommended by Law and Kelton that is portable, computationally efficient, 

and possesses good statistical performance characteristics. 

Run # 
206 

Background 

In TSIS/CORSIM versions 5.1 and earlier, CORSIM employed a pseudo-random number 

generator that exhibited poor statistical qualities, including: 

• The random number generator performed adequately for only a subset of its possible 

seed values, and the default seed values produced random number sequences that 

failed to pass several evaluation criteria. 

• The period of the random number sequence (when it began to repeat itself) depended 

on an arbitrarily selected multiplier, which could lead to short periods for the random 

number sequence. 

• Research indicated that even the use of valid values for the seed and for the multiplier 

could yield sequences that exhibit autocorrelation and fail to pass several of the 

performance tests identified by Law and Kelton. 

• The seed value was constrained to be an odd integer that could not end in 5. That is, 

the seed value was constrained to end in 1, 3, 7, or 9. 

Because of the poor statistical qualities of the pseudo-random number generator, it was 

replaced in TSIS/CORSIM version 6.0. The CORSIM development team evaluated several 

generators, including the Marse-Roberts, Schrage, and FORTRAN intrinsic generators. 

Law and Kelton described and recommended both the Marse-Roberts and Schrage 

generators. 

Although the FORTRAN intrinsic generator has appealing qualities, not enough was 

known about it to recommend it over the other generators. Furthermore, use of the 

FORTRAN intrinsic generator would require changes to the CORSIM code structure to 

support the generator’s need for multiple seeds; therefore, it was not selected. 

The CORSIM development team conducted timing studies using the Marse-Roberts and 

Schrage generators. In raw timing studies (generation of a large sequence of random 

numbers), the Schrage generator was found to be approximately twice as fast as the MarseRoberts generator. The team also conducted timing studies by using the generators in 

CORSIM on a variety of test cases. The team determined that the Schrage generator had 

the least impact on the run-time performance of the simulation, providing approximately 

the same performance as the generator used in TSIS/CORSIM version 5.1 and earlier. The 

Marse-Roberts generator had minimal impact on the run-time performance for smaller 

cases, but had a greater impact on larger, longer running cases. That impact was amplified 

when conducting multiple runs of the simulation for statistical analysis. 

Based on its analysis, the CORSIM development team chose the Schrage generator to 

replace the old CORSIM pseudo-random number generator. 
207 

Schrage Random Number Generator 

The Schrage random number generator, recommended by Law and Kelton when 

computational speed is a concern, is a prime modulus multiplicative linear congruential 

generator (PMMLCG). Although it is similar in nature to the previous CORSIM random 

number generator, its use of a prime modulus and large multiplier gives this generator 

much better statistical behavior than the one previously used by CORSIM. Like the old 

CORSIM generator, this generator is also portable. The Schrage generator employs the 

following recursive relation to compute the (n+1)st random number, Xn+1, from the nth

random number, Xn: 

Figure 70. Equation. Schrage random number generator. 

The choice of these numbers is based on the current word size (32-bit) used by most 

desktop computers. The value of m is the largest prime number that fits in the 32-bit word 

size. 

First, the sequence produced by this generator has a period of 231 - 2, regardless of the seed 

value used. Second, it has been shown that this generator exhibits good statistical 

behavior. (22) Finally, use of this generator does not place any restrictions on the seed 

values which can be any integer in the closed interval [1, 231-2]. 

Studies have indicated that the multiplier used in the Marse-Roberts generator yields 

better statistical performance than the multiplier used in the Schrage generator. (22) On the 

other hand, the statistical performance of the Schrage generator is adequate and it is about 

twice as fast as the Marse-Roberts generator. 

Usage of Random Numbers in CORSIM 

As previously stated, CORSIM employs random numbers to implement the stochastic 

processes it uses to simulate aspects of real-world behavior, including driver behavior, 

vehicle operational characteristics, and decision-making processes. CORSIM groups its 

stochastic processes into three categories, each category requiring a random number seed 

value. The default values for the three seeds are contained in the “random.rns” file, which 

contains a list of 30 seed values for each of the three stochastic categories. Thus, if 30 runs 

are completed for a given CORSIM file using the TSIS Output Processor, then each run will 

use different seed values from the “random.rns” file and thus result in different output 

results for each run due to the stochastic processes. 

Instead of using the default seed values, an analyst can create their own random seed file 

to be used (e.g., robust lists of random seed values can be found in Law and Kelton(22)), 

keep the seed values constant between runs (thus resulting in identical results for multiple 
208 

runs of the same CORSIM file), or have CORSIM generate the seed values randomly. 

Refer to the CORSIM User’s Guide(1) for more information regarding random seed values 

in CORSIM. 

The following sections summarize each of the three stochastic process categories in 

CORSIM. 

Traffic Stream Generation in NETSIM 

NETSIM assigns a unique random number, based on a root seed, to each vehicle that is 

emitted into the network. Each vehicle uses its seed to make random choices based on 

vehicle-driver characteristics and in determining the route it will take through the 

network. The following NETISM processes are controlled by the vehicle-unique seed: 

• Bus Operations – decision by a bus to bypass a bus station. 

• Bus Operations – bus station dwell time. 

• Bus Operations – driver type assignment. 

• Driver familiarity in making lane change. 

• Driver type assignment for entry link vehicles. 

• Driver type assignment for source node vehicles. 

• Fleet type assignment. 

• Vehicle type assignment. 

• Interchange turn movement selection. 

• Upcoming turn movement selection. 

• HOV violator assignment for non-HOV vehicles. 

When using a distribution for generating entry headways, changing the seed value used in 

obtaining headways can change the order in which vehicles are emitted into the network. 

To obtain identical traffic streams between runs while allowing randomness in the entry 

headways, NETSIM assigns a seed to each combination of entry link and turn movement 

at the start of the simulation. When a vehicle enters via an entry link, it is assigned the 

seed corresponding to its turn movement. This isolates the assignment of vehicle seeds 

from the order in which vehicles are emitted into the network. 

Specifically, the following process is used to generate vehicle seeds in NETSIM: 

• Using the user-specified seed, assign seeds to each entry link/ turn movement 

combination. 
209 

• When a vehicle is to be emitted, assign its seed value according to the following 

formula: vehicle seed = entry link by turn movement seed – 1. The subtraction of 1 

ensures scattering of seeds. 

• If the assigned vehicle seed is 0, reset it to the maximum seed value allowed by the 

generator. 

• Replace the “entry link by turn movement” seed with the next value in its random 

number sequence. 

Response to Traffic Choices and Other Stochastic Processes 

Time-dependent stochastic decision-making processes, other than vehicle headway 

generation and traffic stream generation, use a single user-specified seed. This seed 

controls processes such as accepting available gaps for turns, determining the location and 

duration of lane blockages, and determining the inter-arrival times for pedestrians at an 

intersection. At the beginning of the simulation, CORSIM makes a copy of this userspecified seed so that both the NETSIM and FRESIM logic have separate seeds, starting at 

the same value. The following lists summarize how the random numbers in this generic 

category are used in NETSIM and FRESIM. 

NETSIM: 

• Emergency Vehicles - driver awareness of and cooperation with emergency vehicle. 

• Lane Changing – discretionary lane change decision. 

• Lane Changing – driver familiarity in choosing goal lane. 

• Lane Changing – driver familiarity in making a lane change. 

• Left-turn jump determination. 

• Left-turn lagger gap acceptance. 

• Long-term event location. 

• Parking – event location. 

• Parking – inter-arrival time between parking events. 

• Parking – maneuver duration. 

• Pedestrian delay calculation. 

• Pedestrian inter-arrival time calculation. 

• Short-term event duration. 
210 

• Short-term event location. 

• Spillback – determine if vehicle will discharge with spillback. 

• Spillback – determine if left-turner will discharge with spillback. 

• Upcoming movement choice for vehicle on FRESIM to NETSIM interface link. 

FRESIM: 

• Determine lane in which to emit vehicle. 

• Driver type assignment. 

• Fleet type assignment. 

• Vehicle type assignment. 

• HOV – decision for HOV vehicle to enter an HOV lane. 

• HOV – determination if vehicle should reenter HOV lane after being forced out. 

• HOV – violator assignment for non-HOV vehicles. 

• Lane Changing – acceptable risk for lane changing based on cooperative driver. 

• Lane Changing – desire to make discretionary lane change. 

• Lane Changing – discretionary lane change advantage, left / right decision. 

• Lane Changing – lane change gap acceptance risk. 

• Lane Changing – mandatory lane change, left / right decision. 

• Lane Changing – random lane change decision. 

• Lane Changing – speed advantage for lane change. 

• Ramp meter cheater decision. 

• Random assignment for vehicle destination based on origin-destination probabilities. 

• Random perturbation of acceleration. 
211 

Vehicle Entry Headway Generation 

When injecting vehicles into a network at an entry node, CORSIM can generate vehicle 

entry headways deterministically or stochastically, using one of several distribution types. 

In the deterministic mode, vehicles are injected into the network at a constant headway. 

In the stochastic mode, CORSIM uses a random sampling of a user-selected distribution to 

generate vehicle entry headways. This process does not vary the number of vehicles 

emitted during each run; only the headways between the vehicles are varied. CORSIM 

supports three types of distributions: normal (Gaussian), negative exponential, or Erlang. 

Appendix E describes in more detail the different user-selected distributions possible for 

generating vehicle entry headways. 

213 

Appendix E: Vehicle Entry Headway Generation in 

CORSIM 

When injecting vehicles into a network at an entry node, CORSIM can generate vehicle 

entry headways deterministically or stochastically, using one of several distribution types. 

In the deterministic mode, vehicles are injected into the network at with a constant 

headway. In the stochastic generation mode, CORSIM uses a random sampling of a userselected distribution to generate vehicle entry headways. 

Deterministic Mode 

In the deterministic mode, vehicles are injected into the network at with a constant 

headway, defined as 3,600 divided by N, where N is the hourly volume in vehicles/hour 

defined for the entry node. As expected, using a constant headway generates a constant 

flow of vehicles into the network with a constant temporal spacing between entering 

vehicles. 

Stochastic Mode 

In a real traffic network, vehicles do not generally travel with a constant headway. 

Therefore, it is more realistic to inject vehicles into a simulated network by using nonconstant headways. By using a random distribution of headways, the analyst can replicate 

platoons of vehicles when injecting vehicles into the network. Such groupings of vehicles 

are often seen in the real world. 

In the stochastic mode, CORSIM uses a random sampling of a user-selected distribution to 

generate vehicle entry headways. This process does not vary the number of vehicles 

emitted each run; only the headways between the vehicles are varied. The constant 

headway, defined in the previous paragraph, serves as the mean value for a user-selected 

distribution function. The analyst can select from one of three types of distributions: 

normal (Gaussian), negative exponential, or Erlang. 

Normal Distribution 

The normal (Gaussian) distribution is often selected for a stochastic process as an 

approximation of more complex distributions, or when little else is known about the true 

distribution of a random variable beyond its mean and variance. 

When the analyst selects the normal distribution for generating vehicle entry headways, 

the mean value for the distribution is defined as 3,600 divided by N, where N is the hourly 

volume in vehicles/hour defined for an entry node. CORSIM defines the standard 

deviation for the distribution as the difference of the mean and minimum headway values 

divided by 2.575. This definition is a holdover from the old lookup table logic and 

effectively defines the minimum value to be 2.575 standard deviations from the mean. 
214 

Figure 71 illustrates a normal distribution, generated by CORSIM using a volume of 480 

veh/h. The mean and standard deviation for the distribution are calculated as described 

in the preceding paragraph. A minimum value of 1.2 seconds is used. 

Normal: mean = 7.5, std dev = 2.45, min = 1.2

7.5

0

100

200

300

400

500

600

700

800

900

1000

1.21.92.63.34.04.75.46.16.87.58.28.99.6

10.311.011.712.413.113.814.515.215.916.617.318.0

Headway (sec)

Figure 71. Graph. Normal distribution. 

Negative Exponential Distribution 

The negative exponential distribution is a specialization of the gamma (and Erlang) 

distribution, and is commonly used for generating the inter-arrival time of “customers” to 

a system. Figure 72 illustrates the histogram for the negative exponential distribution, 

generated using the inverse-transform method. The mean headway is 7.5 seconds and 

minimum headway is 1.2 seconds in this example. 

In the absence of field measured headways, analysts should use a negative exponential 

distribution for real-world applications. 
215 

Exponential: mean = 7.5, min = 1.2

7.5

0

100

200

300

400

500

600

700

800

900

1000

1.22.64.05.46.88.29.6

11.012.413.815.216.618.019.420.822.223.625.026.427.829.230.632.033.434.836.2

Figure 72. Graph. Exponential variates. 

When the analyst selects the negative exponential distribution for generating vehicle entry 

headways, the mean value for the distribution is defined as 3,600 divided by N, where N is 

the hourly volume in vehicles/hour defined for an entry node. 

Erlang Distribution 

The Erlang (sometimes called m-Erlang) distribution is a specialization of the gamma 

distribution, and is commonly used for generating the time required to complete some 

task. 

When the analyst selects the Erlang distribution for generating vehicle entry headways, the 

mean value for the distribution is defined as 3,600 divided by N, where N is the hourly 

volume in vehicles/hour defined for an entry node. Furthermore, the analyst can specify 

the value of the Erlang distribution shape parameter to be used in generating vehicle entry 

headways. Figure 73 illustrates the Erlang distribution for several values of the shape 

parameter, α, and for a mean value of 1. 
216 

α = 9 α = 7

α = 5

α = 3

α = 1

α = 2

0.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0

(α /h)

α

t/h

e

−α f (t) (α − 1)! t

α−1 =

μ = h

σ

2

= h2/α

Figure 73. Graph. Erlang distribution. 

The equation for the Erlang headway distribution is included in the Erlang distribution

figure, where t represents the headway and h is the mean (average) headway computed as 

previously described. The shape parameter, α, describes the level of randomness of the 

distribution ranging from α = 1 (most randomness) to α = ∞ (constant value at the mean). 

When α = 1, the Erlang distribution is equivalent to the negative exponential distribution. 

CORSIM can generate headways from Erlang distributions ranging from α = 1 to α = 9. 

The entry headway is a global parameter in CORSIM, meaning the parameter cannot be set 

differently for individual links or subnetworks, and the default setting is a constant 

headway. However, a stochastic distribution (Normal or Erlang) would be more 

appropriate for real-world applications to account for natural randomness in vehicle 

headways. In the absence of field measured headways, an Erlang Distribution with α = 1 

may be used, which equates to a negative exponential distribution. A negative 

exponential distribution is commonly used for generating the inter-arrival time of 

“customers” (e.g., vehicles) to a system. 

 
217 

Appendix F: Actuated Signal Control 

The actuated control model in CORSIM is an implementation of an eight-phase, dual-ring 

NEMA controller, as specified in the NEMA TS 1 and TS 2 standards. The model can be 

configured to emulate the operation of a Model 170 controller and many of its features, but 

the CORSIM terminology is taken from the NEMA specification. 

The CORSIM actuated controller can be configured to operate in one of three modes: fully 

actuated, semi-actuated, or semi-actuated coordinated. In fully-actuated mode, detection 

is provided on all approaches to the intersection, and the controller operates without a 

common background cycle (i.e., operating “free”). In semi-actuated mode, detection is 

provided only on the side-street approaches (and perhaps main-street, left-turn 

movements). The main street signals remain green until a call for service is placed by the 

side-street detectors. In this mode, the controller operates without a common background 

cycle (i.e., operating “free”). 

Semi-actuated, coordinated operation is used to provide progressive vehicle flow through 

a series of controlled intersections. In this mode, each controller in the coordinated system 

operates within a common background cycle length. The coordinator in the controller 

guarantees that the coordinated phases (generally phase 2 in ring 1 and phase 6 in ring 2) 

will display green at a specific time within the cycle, relative to a system reference point 

established by the specified cycle length and system synch reference time. An offset time, 

relative to the system reference point, is specified for each controller in the series to 

maintain the smooth progression of vehicles through the intersections. The coordinator 

also controls when and for how long non-coordinated phases can indicate green so that the 

controller will return to the coordinated phases at the proper time. 

Specifying Approaches, Turn Movements, and Phases 

In CORSIM, approaches to a controlled intersection are defined by links whose 

downstream node number identifies that same controlled intersection. The geometry of 

the intersection and its approach links determines which turn movements are physically 

possible from each approach. 

The first step in specifying actuated control is defining the turn movements associated 

with each controller phase. The TRAFED actuated control interface will display all turn 

movements that are physically possible from each approach. Figure 74 shows a ring 

diagram that illustrates the concepts of NEMA phases, rings, and barriers. 

It is typical to assign main-street movements to phases 1, 2, 5, and 6 and side-street 

movements to phases 3, 4, 7, and 8. For safety, the controller implements “barriers” that 

separate the two sets of phases: {1, 2, 5, 6} and {3, 4, 7, 8}. These barriers assure there will 

be no concurrent selection and timing of conflicting phases for traffic movements in 

different rings. Thus, phases in one set will not be concurrently active with phases in the 

other set. Regardless of the specification of which set of phases is main-street, do not mix 

main-street and side-street movements in the same set of phases on one side of the barrier. 
218 

Left turn movements are typically assigned to the odd-numbered phases. Because of lane 

channelization and time-of-day restrictions, not all of the turn movements may be 

assigned to phases. 

Figure 74. Diagram. Typical traffic signal dual-ring diagram. 

The actual number of rings and phases required depends on the layout of the intersection 

and the type of control implemented, e.g., split phasing or concurrent phasing. The 

following figure illustrates the standard NEMA phasing for a four-legged intersection with 

protected, leading main street left-turn phases (i.e., left turn phases come before the 

through phases). 

Figure 76 illustrates a ring diagram where the main street left turns are protected and 

lagging (i.e., come after the through phases) and the side street left turns are protected and 

leading. 

Figure 75. Diagram. Standard NEMA phasing. 

1 2 3 4

5 6 7 8

Barrier Barrier

Ring 1 

Phase
219 

When specifying lagging phases in TRAFED, the phase boxes are not rearranged as 

illustrated above. Rather, the analyst must select the phase order for each of the phase 

pairs, 1 and 2, 3 and 4, 5 and 6, 7 and 8 on the Phase Sequence tab of the actuated control 

interface. 

Figure 77 through Figure 79 illustrates how several other common types of signal phasing 

can be implemented in CORSIM. 

Figure 76. Diagram. Lagging left turn phase. 

Figure 77. Diagram. Leading protected left turns on the 

main street, concurrent side-street phases. 
220 

Specifying Detectors 

Once the phases have been assigned turn movements, detectors can be specified on the 

approaches and associated with the phases that are affected when the detectors are 

actuated. The type of detector used and its location on the approach links depends on the 

purpose of the detector. Extension and count detectors operating in presence mode and 

located at the stop bar are typically used to signal the controller that there is demand for a 

phase to be serviced. Extension and count detectors operating in passage mode and 

located upstream of the stop bar are typically used for extending the green time for a 

phase or when implementing the volume/density functions of the controller. 

CORSIM supports the specification of detectors on links that are not direct approaches to 

the intersection under control, but that are used by the controller at the intersection. These 

additional, or indirect approaches, are used when emulating a field system where two 

Figure 78. Diagram. Dual ring, leading protected left 

turns on the main street, split side-street phases. 

Figure 79. Diagram. Single Ring, Split Phasing.

1 2 3 4

5 6 7 8
221 

intersections are controlled by one controller. They are also used when a direct approach 

is not long enough to support the location of an upstream detector, which must be placed 

on the upstream link that connects to the direct approach. In CORSIM, a maximum of five 

links can be direct approaches to an intersection node. However, up to 10 links can have 

detectors that support the operation of the controller at an intersection, including the direct 

approaches. Thus, for an intersection with four direct approaches, six additional links can 

be specified if required. 

Specifying Phase Timing Parameters 

Once the approaches have been configured (i.e., phases have be assigned turn movements 

and detectors have been specified), time parameters can be specified for the phases using 

the Time Settings tab on the TRAFED actuated control interface. These parameters are 

standard parameters found on any controller that conforms to the referenced NEMA 

standards. TRAFED is designed so that the more commonly used timing parameters are 

located on the Time Settings tab. Phase split times can only be entered when the controller 

is operating in a coordinated mode. Thus, the split times will be discussed later in the 

section on coordination. 

CORSIM offers two approaches to limiting the amount of time a phase can remain green 

under continuous flow conditions (i.e., continuous demand with no significant gaps 

between vehicles). To understand how the two approaches differ, the factors that affect 

the phase green duration must be examined. There are two basic components to the phase 

green time: the initial interval and the extendable interval. The initial interval is 

determined by the specified minimum green and the variable initial operation. When 

variable initial operation is enabled, the initial interval is computed at the beginning of 

phase green based on the vehicle detections that occurred during the immediately 

preceding yellow/red interval (see next section). Thus, the initial interval can vary from 

cycle to cycle, but it can never be less than the specified minimum green nor greater than 

the specified maximum initial interval. Furthermore, the controller will hold the phase in 

green for the duration of the initial interval regardless of demand or conflicting calls. 

During the extendable interval, the phase will be allowed to terminate (e.g., gap out) if the 

vehicle headways exceed the specified vehicle extension (passage) time. However, the 

phase must terminate at the end of the extendable interval, even when there is demand. In 

CORSIM, the duration of the extendable interval is either calculated from the specified 

maximum green or can be directly specified, but each approach yields a slightly different 

behavior, as explained below. 

Maximum Green 

Maximum green is the maximum amount of time a phase will be allowed to be active (i.e., 

display green), and includes both the initial and extendable intervals. The duration of the 

extendable interval is allowed to vary based on the actual initial interval, as follows: 

Figure 80. Formula. Extendable interval duration. 
222 

Thus, the total green duration under continuous flow conditions will remain constant and 

equal to the specified maximum green time.

Maximum Extension 

Maximum extension is the amount of time a phase will be allowed service after the 

minimum green and variable initial have timed out. The extendable interval is held 

constant and equal to the specified maximum extension, and the max phase green 

duration is allowed to vary based on the actual initial interval, as follows: 

Figure 81. Formula. Max phase green duration. 

Thus, the total green duration under continuous flow conditions could vary from one 

cycle to the next, depending on the duration of the initial interval. While some 

controller manufacturers still use maximum extension, it is more commonly found in 

older, isolated NEMA and Type 170 controllers. 

Specifying Volume/Density Function Parameters 

Additional timing parameters may need to be specified if the controller being modeled 

implements volume/density functions. CORSIM implements two volume/density 

functions specified by the NEMA standard: variable initial and gap reduction. The 

parameters for these functions are specified on the Volume/Density tab of the TRAFED 

actuated control interface. 

Variable Initial 

Variable initial timing is used to increase the initial green interval of a phase based on the 

demand for that phase during its previous inactive (yellow and red) state. This extra time 

provides an opportunity for a stopped platoon of vehicles to proceed through the 

intersection before the phase’s passage timer is allowed to become active. This function is 

ineffective with long presence detection located at the stop line. The concept of variable 

initial timing is illustrated in Figure 82. 

Initial 

Timing (sec)

Vehicle Actuations

Maximum Initial 

Minimum Green Seconds/Actuation

Extended 

Initial Range 

Figure 82. Chart. Variable initial timing. 
223 

CORSIM supports three types of variable initial operation: 

• Extensible initial: The extensible initial period is a method of calculating the variable 

initial period commonly used in field practice. With this method, the variable initial 

interval is increased from zero by the specified seconds/actuation for each vehicle 

actuation received by a phase during the yellow and/or red signal up to the specified 

maximum initial time. The initial timing will not exceed the maximum initial time and 

will not be less than the minimum green time. This method is common in both Type 

170 and NEMA and is the method illustrated in the previous figure. 

• Added initial: The added initial method is similar to extensible initial with the 

exception that the seconds/actuation calculation does not begin until a user-specified 

number of vehicles actuations have occurred. Also, the variable initial interval is 

increased from the minimum green time rather than from zero. The added initial 

option is generally used when long minimum green times are specified. If this option 

is selected for any phase, it must be selected for all phases. 

• Computed initial: The computed initial method calculates the amount of time given to 

each vehicle actuation (computed seconds per actuation) during the yellow and red 

signal display of the phase based on the following formula: 

o Specified maximum initial time divided by the specified number of 

actuations that can be serviced during the minimum initial interval times 

the number of recorded actuations. 

The total time allowed for the computed initial interval is limited by both the minimum 

green time and maximum initial interval. 

Gap Reduction 

Gap reduction, as the name implies, reduces the gap or allowable headways between 

vehicles from a starting value (maximum gap) to a lesser value (minimum gap) over a 

specified amount of time. While gap reduction is used sporadically in the field, it can be a 

valuable tool. For example, assume there is an approach to a fully actuated intersection 

that experiences a very sluggish “start-up,” creating excessive headways until vehicles are 

moving at a more normal speed. If the gap is set where it should be for the normal speeds, 

the phase would constantly gap-out early. If, however, the gap were set to accommodate 

the start-up vehicles, the phase would run to maximum green more times than necessary. 

This problem could be handled by providing a long minimum green time or extending the 

vehicle call, but those actions would also contribute to an inefficient signal operation. By 

providing a longer than normal vehicle extension (gap) time at the beginning of the signal 

phase and then reducing the gap to a more reasonable value following the vehicle start-up 

time, the problem is relieved with little or no effect on efficiency. Similarly, gap reduction 

can reduce the problems experienced at intersections with large fluctuations in traffic 

volumes during the day. Generally these intersections have low vehicular volumes with 

long vehicle headways during off-peak travel times and shorter headways during peak 

travel periods. Gap reduction techniques could provide a longer gap at the beginning of 
224 

the phase when volumes are low, headways are long, and an overall shorter cycle length is 

provided. The gap would then be reduced to a lesser value as volumes increase, 

headways decrease, and the cycle length increases. 

CORSIM supports three types of gap reduction as illustrated in Figure 83: 

• Reduce by/Reduce every. The gap is reduced by a user-specified amount for every 

user-specified interval. Older Type 170 controllers only support this option. 

• Reduce by every second. The gap is reduced by a user-specified amount every 

second. 

• Time to reduce to minimum gap. The gap is reduced from a specified maximum 

value to a specified minimum value over a user-specified amount of time. This 

method of gap reduction is commonly used in the field and is supported by all NEMA 

and newer model Type 170 controllers. 

Maximum

Gap

0

Minimum 

Gap

Time 

Before 

Gap 

Reduction

Allowable

Gap 

∆Y

∆X

Opposing Call

0 

Gap Setting

Green Time

The allowable gap varies from maximum gap to minimum gap

∆Y Reduce by amount 

∆X Reduce every amount

Figure 83. Chart. Gap reduction concept. 

Usage Notes: 

1. To disable gap reduction in CORSIM, set the minimum gap equal to the maximum 

gap. 

2. For any method of gap reduction in CORSIM, the gap begins to be reduced at the 

receipt of a call on a conflicting phase. This is generally, but not always, the beginning 
225 

of phase green. Unlike the CORSIM model, NEMA and newer Type 170 controllers 

allow the field engineer to specify an amount of time from the beginning of phase 

green until gap reduction begins. This value is called “Time Before Reduction” and is 

commonly used in the field when gap reduction is active. To incorporate this value in 

CORSIM, the analyst should assume there is always a conflicting vehicle call (which is 

generally the case) and should specify the CORSIM Time-to-Reduce parameter as the 

sum of the Time-Before-Reduction and Time-to-Reduce values obtained from the 

controller. This will tend to flatten the slope of the gap reduction line but will 

generally make little difference in the analysis. If the analyst would prefer to maintain 

the slope of the gap reduction line, the gap reduction line can be extended back to the 

beginning of phase green, and the gap value at that point should be specified for the 

maximum gap. Although neither approximation produces an exact simulation of the 

field operation, either method should produce acceptable analytical results when 

compared to actual field data. 

3. CORSIM enforces a 1.1 second minimum value for minimum and maximum gap 

values, although lower values are common in field applications where a long detection 

zone presence detector is used. While the analyst can input lower values, CORSIM 

will reset these lesser values to 1.1 seconds. Depending on the detector configuration, 

traffic volumes and vehicle headways, this limitation may have little impact on the 

intersection analysis. 

Specifying Phase and Unit Control Parameters 

The Phase Controls tab in the TRAFED interface allows the analyst to specify basic 

operational characteristics for each phase, in addition to the phase timing parameters that 

were specified on the Time Settings tab. The Unit Controls tab is used to specify 

operational characteristics that apply to the entire controller. The following paragraphs 

provide more details regarding these operational characteristics. 

Min and Max Recall 

A phase can operate with either min recall or max recall, but not both. With the minimum 

vehicle recall active and in the absence of a vehicle call on the phase, a temporary call to 

service the minimum initial time will be placed on the phase. If a vehicle call is received 

prior to the phase being serviced, the temporary call will be removed. Once the phase is 

serviced it can be extended based on normal vehicle demand. With the maximum vehicle 

recall active, a constant vehicle call will be placed on the phase. This constant call will 

force the controller to time the maximum green. Maximum recall is generally used to call 

a phase when local detection is not present or inoperative. 

Usage Notes: 

1. CORSIM does not currently support soft recall or call to non-actuated. If the analyst 

encounters either of these functions in a field controller, minimum recall should be 

used to approximate soft recall and maximum recall should be used for call to nonactuated. 
226 

2. If the controller is in a coordinated system and the coordinated phases (2 and 6) are not 

actuated, then either minimum recall or maximum recall must be set active for the 

controller to service the coordinated phases. 

Dual Entry 

When dual (double) entry is specified, a vehicle call on one phase, in the absence of a call 

on a compatible phase, will automatically place a call on the primary corresponding 

compatible phase. For example, assume the intersection being simulated is under light 

traffic conditions and its controller is using the standard NEMA phase numbering scheme 

illustrated in Figure 75. A call for service is received on phase 2, but there are no other 

calls on phase 5 or 6. With dual entry active, the call on phase 2 automatically places a 

temporary call on phase 6. When phase 2 becomes active and no call has been received on 

phase 5, phase 6 will be displayed simultaneously with phase 2. If a call had been received 

on phase 5 before phase 2 became active, the temporary call on phase 6 would have been 

removed and phases 2 and 5 would have been displayed. In the standard NEMA phase 

numbering scheme, compatible dual-entry phases are 1 and 5, 2 and 6, 3 and 7, and 4 and 

8. If dual entry is not active, a vehicle call on a phase will only allow the display of that 

phase in the absence of a call on a compatible phase. The usage of dual entry is generally a 

policy decision by the local DOT. However, common usage is to have dual entry active on 

the NEMA standard even-number phases (through movements) and inactive on NEMA 

standard odd-number phases (left-turn movements). 

Red Revert 

Under very light traffic conditions and fully actuated control, it is possible for a phase to 

go from green to yellow and then back to green without ever displaying a red indication. 

Red revert timing prevents this signal display sequence by forcing the red indication to be 

displayed after a yellow for at least the red revert time. Red revert is generally factory 

programmed at two seconds and seldom changed by the field engineer. 

Simultaneous Gap 

The operational logic for both NEMA and Type 170 controllers specifies that both 

controller rings 1 and 2 (refer to the figure included in the discussion of Dual Entry) must 

cross the barriers at the same time. This can be accomplished by each of the phases 2 and 6 

gapping-out, maxing-out, or forcing-off. With simultaneous gap-out inactive, one ring can 

gap-out and the other can max-out. Additionally, once a phase gaps-out it will stay in that 

condition, regardless of any future vehicle actuations until the phase in the opposite ring 

either gaps-out or reaches max-out and then both phases cross the barrier. With 

simultaneous gap-out active, neither ring can cross the barrier until both phases have been 

terminated in the same manner, either by both gapping-out or both maxing-out. 

Additionally, if a phase initially gaps-out and then, due to increased vehicle demand, 

vehicle arrivals are less than the extension time, the gap-out flag for that phase is removed. 

With simultaneous gap-out active, the vehicle headways on both phases must currently be 

exceeding the current gap value. The inactive status for this function generally produces a 

quicker reacting signal installation and shorter cycle lengths. 
227 

Conditional Service 

When a heavy left-turn demand exists at an isolated (i.e., not coordinated) intersection, it 

may be desirable to service one of the left-turn phases twice in the same cycle. Conditional 

service, under a specific set of circumstances, allows the left turn to be serviced first as a 

leading phase and then as a lagging phase. Enabling conditional service will allow the 

simulated controller to operate in this manner under the following circumstances: 

• There is a call for service on a leading left-turn phase. 

• The controller is operating in a non-coordinated mode. 

• There is a conflicting call on the opposite side of the barrier. Otherwise the left-turn 

phase will automatically be serviced next by standard controller logic unless the antibackup controller feature is active. 

• The through phase of the phase pair with the left-turn call for service has gapped-out. 

• The time remaining on the active through phase’s maximum timer exceeds the 

conditional service phase’s minimum conditional service time. 

Conditional service should not be confused with conditional re-service, which is currently 

not supported by CORSIM. 

Red and Yellow Lock 

Red lock is not supported by NEMA controllers and is not a common function in Type 170 

controllers. When red lock is set to “on” (active), the controller “remembers” vehicle 

actuations that occur during the red display of the signal phase. When the controller 

determines if the phase should be called for service, it uses the remembered actuations to 

call the phase to service, even if the phase has no currently occupied detectors. When red 

lock is set to “off” (inactive), the controller does not remember actuations and the phase 

will be called to service only if it has a currently occupied detector. Red lock should not be 

set active unless the controller being analyzed specifically has a “red locking memory” that 

is active. 

Most NEMA and Type 170 controllers use yellow lock as a factory standard setting that 

cannot be changed by the field engineer. However, some manufacturers provide this 

memory lock as a toggled option. When yellow lock is set to “on” (active), the controller 

“remembers” vehicle actuations that occur during the yellow and red display of the signal 

phase. When the controller determines if the phase should be called for service, it uses the 

remembered actuations to call the phase to service, even if the phase has no currently 

occupied detectors. When yellow lock is set to “off” (inactive), the controller does not 

remember actuations and the phase will be called to service only if it has a currently 

occupied detector. In no case should the locking memory set to “off” be considered as a 

red lock “on”. Both red lock and yellow lock can be set as inactive but both cannot be set 

active because yellow lock includes the actuations during the red interval. 
228 

Pedestrian Recall and Rest 

When pedestrian recall is enabled, a pedestrian call for service will be input to the 

controller. When pedestrian recall is active, both the vehicular and pedestrian timing for 

the phase are active. When pedestrian rest is enabled the pedestrian WALK interval will 

rest in the phase. Either pedestrian recall or pedestrian rest can be specified, but not both. 

Red Rest 

This unit function designates that all phases of the controller are allowed to rest in red in 

the absence of calls or recalls on any phase. While this function is not uncommon, 

especially for an isolated intersection with relative even traffic flows on all approaches, it is 

the more general practice to allow the controller to rest in green on the mainline 

approaches in the absence of calls. To provide this behavior, rest in red would be set 

inactive. 

Specifying Phase Sequence and Overlapping Phases 

Phase Sequence 

The concept of lagging phases was introduced in the section describing the assignment of 

turn movements to phases. A phase can be specified as a lagging phase on the Phase 

Sequence tab in the TRAFED actuated control interface. For the purposes of this 

discussion, a phase pair is defined as adjacent phases in the same ring on the same side of 

the barrier on a standard NEMA phase diagram (refer to the figure included in the 

discussion of Dual Entry). Therefore, phase pairs are phases 1 and 2, 3 and 4, 5 and 6, and 

7 and 8. Phase pairs are not NEMA compatible signal display phases such as 1 and 5, or 2 

and 6. 

In a standard NEMA 8 phase configuration operating in leading dual lefts on both streets, 

phases 2, 4, 6 and 8 are lag phases while phases 1, 3, 5, and 7 are leading phases. For a 

lead/lag sequence, phase 2 can lead, and phase 1 can lag. This will produce the signal 

display sequence of phases 2 and 5, then phases 2 and 6, then phases 1 and 6. It is also 

possible to have both left turns lagging by specifying phases 2 and 6 as leading and phases 

1 and 5 as lagging. 

Overlapping Phases 

An overlap is a vehicle movement, generally a right turn, which is allowed to run 

concurrently with two standard phases. For example, in Figure 84 the phase 4 right turn 

movement from link (10, 4) is defined as overlap “A”. Usually a 5-section signal head with 

a right arrow controls this type of overlap movement. In this case, overlap “A” is allowed 

to run concurrently with not only phase 4, under green ball control, but also whenever 

phase 1 is active in either the phases 1 and 5, or 1 and 6 combination. Therefore phases 1 

and 4 are “parent” phases to overlap “A”. When overlap “A” is active with phase 1, the 

signal controlling the overlap movement is generally displaying a green right arrow 

indication. 
229 

Ø1 Ø6

Overlap A

10 4 11

9

3

Ø5

Ø4

Figure 84. Illustration. Overlapping phase. 

When a movement is added to the phase diagram, TRAFED automatically determines if 

the movement occurs in adjacent phases and can be considered a potential overlapping 

movement. If so, the movement is indicated as a green arrow in the phase diagram. 

However, potential overlap movements will not operate as overlapping movements in 

CORSIM unless the parent phases are specified in the Phase Sequence tab. 

Specifying Pedestrian Demand 

CORSIM does not simulate pedestrian traffic2. Therefore, when modeling a controller that 

implements pedestrian phases, the analyst must specify pedestrian demand parameters for 

CORSIM to emulate pedestrian calls to the controller. CORSIM supports three pedestrian 

actuation modes as follows: 

1. Actuation based on the stochastic arrival of pedestrians. 

2. Actuation based on the deterministic arrival (constant headways) of pedestrians. 

3. Actuation based on the periods of constant pedestrian demand (pedestrian push 

button is continuously depressed). 

It is not necessary to define the pedestrian generator unless the pedestrian demand 

conflicting with the turn movements from the phase being programmed is greater than 100 

crossings per hour and is defined in the data for the link serviced by the phase. The 

absence of generator data for any phase with less than 100 crossings per hour will have no 

 

2 CORSIM can model the delay to turning vehicles due to pedestrian traffic. It is coded on an approach 

link to an intersection. The actuated controller pedestrian demand and the vehicle delay are not 

coordinated in any way. They are requested separately and operate independently. Both should be 

specified when modeling pedestrians at actuated controlled intersections. 
230 

impact on the CORSIM analysis or the output MOEs. However, it may be prudent for the 

analyst to define the pedestrian generator data for approaches and phases with low 

pedestrian crossing values in order to show observers of the animation how a pedestrian 

signal would operate at an intersection even though the output MOEs would not be 

affected. 

It should be remembered that the pedestrian signal associated with a phase is for 

pedestrians crossing the approaches that receive the left and right turn movements from 

the phase being coded. For example, assume an isolated intersection is being coded where 

north is up, as shown in the following figure. In Figure 85, approach 1, 2, 3, and 4 are the 

westbound, northbound, eastbound, and southbound approaches to the intersection 

respectively. Also in the example, phase 2 displays green for all movements from the 

westbound approach. When specifying generator data for phase 2, the pedestrian volume 

and other data input are for pedestrians crossing approaches 2 and 4. Additionally, the 

pedestrian intensity code must be set for the link assigned as approach 1. 

Approach 3

Approach 2

(northbound)

Approach 1

Phase 2

Approach 4

Figure 85. Diagram. Pedestrian demand. 

Pedestrian generation mode 1 would typically be used for an intersection with relative 

light pedestrian volumes. Pedestrian generation mode 2 would typically be used at an 

intersection in a downtown business district during the lunch hour. Pedestrian generation 

mode 3 would typically be used at an intersection adjacent to a commuter train station 

where continuous pedestrian demand exists, followed by a period of no demand, followed 

by another period of continuous demand when the next train arrived. 

CORSIM does not have the ability to simulate an exclusive pedestrian phase using the 

phase 9 method as provided by many controller manufacturers. However, in a limited 

number of situations where there are unused phases in the controller, the analyst may be 

able to employ one of those phases as an exclusive pedestrian phase. One such situation is 

the mid-link pedestrian signal. In this case the analyst can place node with actuated 

control at the location of the crossing signal. The vehicle through movements can be coded 

in phase 1, and phase 2 can be coded as the exclusive pedestrian phase. There are other 
231 

possible configurations, but the analyst is cautioned to be careful when coding an unused 

phase as an exclusive pedestrian phase because the phase may be concurrent with a phase 

in the opposite ring. 

Specifying Coordination 

CORSIM can model any type of coordination control (i.e., hardware and master 

coordinator, telemetry communications and closed loop master, central office control, or 

any form of time-based local coordinator control) as long as the local controller is either a 

NEMA or Type 170 or equivalent. 

Coordinated operation is used to provide progressive vehicle flow through a series of 

controlled intersections. Each controller in the coordinated system is semi-actuated and 

operates within a common background cycle length. Typically, the coordinated phases are 

not actuated and are placed in maximum vehicle recall. Furthermore, an offset time, 

relative to the system reference point, is specified for each controller in the series to 

maintain the smooth progression of vehicles through the intersections. The controller’s 

coordinator also controls when and for how long non-coordinated phases can indicate 

green so that the controller will return to the coordinated phases at the proper time. 

It should be noted that an isolated actuated controller operating with maximum recalls 

active on all phases is not the same as operating with a background cycle length. This type 

of operation does not require coordination data to be specified to allow the mainline 

phases to begin operation at some random point in the cycle. 

Finally, CORSIM allows the simulation of networks that contain both coordinated and 

non-coordinated (“free”) controllers. 

Prior to describing how to specify coordination parameters, the following discussion is 

presented as a summary explanation of coordination in general and how it is handled by 

CORSIM. The following typical timing dial diagram and phase split diagram represented 

in Figure 86 and Figure 87 present a graphical representation of the coordination 

parameters, and should be referenced throughout the remainder of the discussion. 

Coordinated Operation 

All controllers operating within a coordinated system must have the same common 

background cycle length (multiples of the background cycle length are allowable if a 

controller is being “double cycled”). Within the background cycle length, the coordinated 

(or sync) phases (phases 2 and 6 in CORSIM) are guaranteed to display green at a certain 

time (start of coordinated phases) and for a minimum duration (split) within the 

background cycle length. If the controller is in the coordinated phases, it will remain there 

until the split has been timed out and a call for service during the time that calls are 

allowed to be registered by the controller (permissive period) has been received on some 

non-coordinated phase. The point at which the controller is allowed to leave the 

coordinated phases to service other phases is the yield point, and in CORSIM it is always 

measured from the system reference (sync) point (system time T = 0) to the end of phase 2 

and 6 green. The system reference (sync) points are defined by the actuated controller 
232 

sync reference time and the background cycle length. The yield point is the local reference 

point used internally by the controller and is referred to as “local zero or local t = 0.” As 

will be seen later, the yield point is directly related to the controller’s offset parameter. 

Note: Specified green times 

are split (coordination) green 

times and not maximum green

End Permissive Period 2

Force-off Phases 1 & 5 

Phase 3 & 7 Green (10 sec.)

(Min. Green = 5 sec.)

End Permissive Period 1

Phases 3 & 7 Clearance (5 sec.)

Force-off Phases 3 & 7 

Begin Permissive Period 2

Phases 4 & 8 

Clearance (5 sec.)

Force-off Phases 4 & 8 

Begin Permissive Period 3

End Permissive Period 3 Phases 1 & 5 Green (10 sec.) 

(Min. Green = 5 sec.)

Start of Coordination Phases

Phases 2 & 6 Green (30 sec.)

(Min. Green = 10 sec.)

Phases 2 & 6 Clearance (5 sec.)

Yield point (local t = 0)

Begin Permissive Period 1 

End of Coordination Phases

Phases 4 & 8 Green (30 sec.) 

(Min. Green = 10 sec.)

Phases 1 & 5 Clearance (5 sec.)

Cycle Length = 100 sec.

0

10

20

30

40

50

60

70

80

90

Figure 86. Diagram. Typical coordination timing dial. 

Phase 3 & 7

Force Off 

Phase 1 & 5 

Split 

Phase 2 & 6

Split 

Phase 4 & 8 

Split 

Phase 3 & 7

Split 

Phase 1 & 5 

Force Off 

seconds

System Time (T)

Local Time (t)

Yield Point Offset = 40 sec

min. green

green

yellow change 

red clearance

Yield

Point

0 10 20 30 40 50 60 70 80 90 

60 70 80 90 0 10 20 30 40 50 

Permissive

Period 1 

Permissive

Period 2 

Permissive

Period 3 

Phase 4 & 8

Force Off 

Figure 87. Chart. Phase split diagram. 
233 

Once a non-coordinated phase becomes active, i.e., displaying green, it will stay in that 

phase until it either gaps-out, reaches max-out, or reaches its force-off point (the end of its 

split duration or the maximum time the phase is allowed to remain green within the 

background cycle length). Additionally, any of the three permissive periods not used 

within the current cycle are removed and the controller is allowed to service 

vehicle/pedestrian actuations normally. However, force-off points remain active to ensure 

the controller returns to the coordinated phase at the proper time in cycle. The analyst is 

cautioned that the maximum green time for each phase is generally considered to be an 

isolated intersection function and may not be appropriate for all cycle lengths and split 

combinations to be simulated. Many system operators disable the maximum green 

function when the controller is in coordination. This is done by enabling the controller 

function “Inhibit Max Termination.” When this function is enabled, phases can then only 

be terminated by gapping-out or by a force-off as described in the previous paragraph. 

Because all controller phases may have to be serviced within any background cycle length, 

it is not possible to allow the controllers to service calls any time there is demand as is 

common in an isolated actuated operation. Permissive periods provide specific intervals 

when the controller can respond to these calls. CORSIM and many field controllers 

provide three permissive periods at user-specified times within the cycle. When modeling 

dual leading lefts on both streets using the standard NEMA phase numbering, permissive 

period 1 is generally programmed to allow the controller to service vehicle or pedestrian 

calls from phases 3 and 7, 4 and 8, and 1 and 5. Permissive period 2, occurring later in the 

cycle, allows service to phases 4 and 8, and 1 and 5. Permissive period 3 only allows 

service to controller phases 1 and 5. 

While many permissive period configurations are in everyday usage in field operations, 

the following is fairly common and is used as a default by several controller 

manufacturers. CORSIM requires the beginning of permissive period 1 to be at the end of 

green for the coordinated phases (i.e., the yield point or local zero). This is the point at 

which the permissive window opens to respond to calls for service. The end of permissive 

period 1 will be at the point in the next phase where, if activated, there is still time 

remaining in the phase to service the clearance period for the current phase and the 

minimum green or pedestrian times before the force-off point for that phase is reached. 

Mathematically, it is the phase 3/7 split – phase 3/7 clearance – phase 3/7 minimum 

green, where “3/7” indicates potentially concurrent phases 3 and/or 7. The beginning of 

permissive periods 2 and 3 will be at the force-off points for phases 3/7 and 4/8, 

respectively. The end of permissive period 2 and 3 will be at the minimum service green 

point for phases 4/8 and 1/5, respectively. 

Finally, while yield point, permissive period, and force-off times are not common 

coordination timing input values in newer NEMA or Type 170 controllers, these are the 

parameters used by the coordinators inside the controller. However, most modern 

controllers use the more common data input of cycle length, split and offset and then 

convert the data to yield point and force-off times for use by the coordinators. Because of 

this, TRAFED also uses cycle length, split, and offset data inputs. It automatically converts 

those input values to yield point and force-off times for use by CORSIM. See appendix J 

for a description of the conversion process. 
234 

Specifying Coordination Parameters 

The TRAFED actuated controller dialog was designed to reduce the amount of input an 

analyst must supply for basic coordinated systems. For many coordinated systems, the 

analyst need only specify the data in the dialog’s Operation Group (i.e., cycle length and 

offset) and the phase splits in the Time Settings tab. TRAFED provides reasonable default 

values for all other “advanced” coordination parameters. However, should the analyst 

need to review or change those parameters, they are accessible via the Actuated Controller 

Coordination dialog. 

Cycle Length 

While the cycle length is entered for each controller, the value should be the same for all 

controllers that are in the same coordination series. For example, a network may contain 

multiple independent arteries, each requiring a different background cycle length to 

maintain progression. CORSIM allows the specification of multiple background cycle 

lengths in a network, but the analyst is responsible for using the proper cycle when 

specifying each controller. 

Because the phase split times must total to the cycle length, changing the cycle length for a 

controller in TRAFED will cause the split values in the Time Settings tab to be 

automatically updated. 

Actuated Control Sync Reference Time 

The sync reference time is used for coordinating actuated controllers within the traffic 

network, and specifies the time of day at which the actuated controllers are synchronized. 

The sync reference time is not specified on the actuated controller dialog in TRAFED, but 

is specified in the Network Properties dialog under the Controllers tab. 

This value, along with the background cycle length, specified for each controller, defines 

the “system zero” (T = 0) times for the controllers. The offset time specified for each 

controller is relative to the system zero. For example, if the sync reference time is 2:00 a.m. 

and the background cycle length is 100 seconds, system zeros occur at 02:00:00, 02:01:40, 

02:02:20, and so on. 

If not used, the sync reference time depends on the specified simulation start time and the 

length of the initialization period. This value must be specified to control the sync 

reference time. When the sync reference time is specified, CORSIM will automatically 

force the initialization period to run to the specified maximum value. 

Offset 

In TRAFED, the offset value for a controller is measured from the system reference point 

(T = 0) to the start of the coordinated (sync) phases, as specified in the NEMA TS 2 

standard. TRAFED will automatically convert the offset value to yield point for use by 

CORSIM. The yield point is defined as the time, in seconds, from the system reference 

point (T = 0) to the end of green for the coordinated (sync) phases. 
235 

Inhibit Max Termination 

For a coordinated controller, the phase maximum green values are often set low to enable 

the controller to function in the isolated backup mode, e.g., in the case that one or more 

detectors fail. Assuming a long cycle length and split, it is possible that once the phase is 

active it will always terminate at the end of maximum green and never reach the phase 

force-off point. Controller manufacturers have implemented the Inhibit Max Termination 

function to resolve this problem. 

When the Inhibit Max Termination function is enabled, the controller will allow phases to 

terminate by “gap-out” or by “force-off” but will not allow phases to “max-out”. This is a 

unit (controller) function and cannot be set independently for a specific phase. 

Phase Splits 

A phase split controls the duration of a phase and includes the yellow change and red 

clearance durations as well as the green time for the phase. In most cases, the total of the 

splits for the phases within a ring must add up to the cycle length. In cases where some of 

the phases are unused, the splits in a ring may not add up to the cycle length. Also, the 

sum of the splits for the phases in a ring on one side of a barrier must equal the sum of the 

splits for the phases in the other ring on the same side of the barrier. TRAFED will warn 

the user when there is an error in the split value specification. Splits are specified in the 

TRAFED Time Settings tab, which allows the analyst to specify splits either as absolute 

times or as percentages of the cycle length. 

Specifying Advanced Coordination Parameters 

If a controller uses a non-standard permissive period specification, the analyst can specify 

the permissive period parameters using the Advanced Coordination dialog in TRAFED. 

That dialog also provides access to other parameters that control the operation of the 

coordination and parameters that govern how a controller transitions between different 

timing plans. 

Permissive Periods 

CORSIM allows the specification of up to three permissive periods. During these periods, 

calls can be answered for phases other than the sync phases. Each permissive period has a 

begin time and an end time and can overlap; i.e., the beginning time for one can occur 

before a previous permissive period has ended. 

Once the controller yields, all subsequent permissive periods are disabled for that cycle 

and the controller will sequence normally from that point depending on demand. Once 

the controller returns to the sync phase during a cycle, it will stay in the sync phase until 

the next yield point. 

In CORSIM, at least one permissive period should start at the yield point (t = 0), i.e., the 

starting time of at least one permissive period should be 0. 
236 

Each non-sync phase can be assigned to any or all of the three permissive periods. Note 

that phases 2 and 6 are not assigned permissive periods. All other active phases must be 

assigned to a permissive period or they will not be serviced. 

TRAFED provides three options for defining the permissive periods used in coordination: 

• Remaining Phases in Cycle. 

• Next Phase in Cycle. 

• Manual Specification. 

For the “Remaining Phases in Cycle” option, the start of permissive period 1 is at the yield 

point; the start of permissive period 2 is at the force-off of the next phase in sequence after 

the sync phase; and the start of permissive period 3 is at the force-off of the next phase in 

sequence after the phase used in permissive period 2. The end times for the permissive 

periods are set so that if a phase is activated during the permissive period, it will be able to 

service its minimum initial plus its yellow change plus its red clearance intervals before 

reaching its force off. For each permissive period all remaining phases that occur before 

the next sync phase can be serviced. 

For the “Next Phase in Cycle” option, the permissive period start and end times are 

calculated in the same way as for the “Remaining Phases in Cycle” option. However, for 

each permissive period only the next phase in sequence can be serviced. 

The “Manual Specification” option enables the user to code a set of permissive periods that 

do not conform to the other two default options. When using this option, remember that 

the time parameters are referenced to the controller’s yield point, not to the system (sync) 

reference point or to the offset time. 

Extended Side-Street Leading Left-Turn Phases 

Preset signal splits based on pedestrian timing requirements can be dynamically altered by 

the simulated controller when no side street pedestrian demand exists. This feature causes 

the controller to skip the side street pedestrian phase when no demand exists and extend 

the force-off time for the leading left-turn side-street phases. In the absence of actuated 

pedestrian calls, modern controllers allow force-off points for leading left-turn phases to be 

extended into what would normally be the next through phase. For example, assume the 

phase 4 and 8 split is controlled by the time it takes to accommodate pedestrian timing and 

not vehicle demand. In the absence of pedestrian actuations, the phase 4 and 8 green time 

could be shortened and the extra green time given to a heavy demand left turn on phases 3 

and 7. This function must be manually set to be active in the controller and phases and 

times defined. The status of this controller function should be determined prior to 

CORSIM analysis. 

From the Advanced Coordination dialog, the analyst can specify up to two leading sidestreet left-turn phases that can be extended beyond their normal force-off time when no 
237 

pedestrian demand exists. When using this option, the analyst must also specify the 

number of seconds that the force-off times can be extended for the corresponding phases. 

Phase Termination Flags 

During coordinated operation, a hold can be placed on user-selected phases to prevent 

those phases from terminating before their force-off point is reached. This is desirable 

when lead-lag left-turn phasing combinations are used to maximize two-way progression. 

Placing a hold on a lagging left-turn phase prevents that phase from premature “gap-out” 

and ensures that the phase does not terminate until its force-off point is reached. This 

prevents the concurrent through phase from terminating prematurely and shortening the 

progression band in that direction. 

The lag phase hold input is commonly used in closed-loop systems that do not have local 

intersection vehicle detection. Once the phase is initialized, by either minimum recall or 

maximum recall it will continue to display green; not terminating until its force-off point is 

reached. Furthermore, the maximum green (or maximum extension) and passage time 

inputs will be ignored. The user is cautioned not to confuse this input with the controller 

function “Inhibit Max Termination”. That function allows the controller to “gap-out” or be 

“forced-out” but not “max-out”. The lag phase hold to force-off function will only allow 

the controller to be “forced out” and has no impact on controllers that are not operating 

within a coordinated system. 

Plan Transition Settings 

New timing plans can be implemented in actuated controllers by changing the parameters 

for an actuated controller in subsequent time periods, as scheduled by time of day or some 

other mechanism. The analyst can specify how the controller will transition between plans 

to maintain the progression of the coordinated system. Specification of a new plan does 

not necessarily require transition, but transition may be required if either the offset or cycle 

time are changed. 

Typically, if the offset of a new plan is different from the old plan, then the controller will 

have to transition to the new plan. This is a 3-step process and may take several cycles. 

First, at the end of the coordinated phase, the splits and cycle time of the new plan are 

loaded. Next the cycle time of this new plan is adjusted over a period of several cycles 

until the actual specified offset of the new plan is obtained. When the current signal 

timings are in step with the desired timing plan, the cycle time is restored to the cycle time 

of the new plan. 

Figure 88 illustrates how a controller might transition to a new plan. This figure was 

adapted from, Bullock, D., T. Urbanik, and A. Catarella, “Traffic Signal System Progression 

Recovery from Railroad Preemption,” Proceedings of the Fifth International Symposium 

on Railroad-Highway Grade Crossing Research and Safety, October 20-22, pp. 355-365, 

1998. Sub-figure (a) depicts the desired (new) signal timings with an offset of O. Subfigure (b) shows the signal timings after the split and cycle time parameters of the new 

plan have been loaded into the controller. If no adjustment is made to these signal 

timings, the timing plan in the controller will always start main-street green late (by the 
238 

offset difference O' – O) and the intersection will not be well coordinated. Sub-figures (c) 

and (d) illustrate how the transition process can be accomplished by extending (Add 

method) or shortening (Subtract method) the cycle time of the new plan. After each cycle, 

the offset difference decreases and eventually the offsets shown in these figures are 

consistent with the offset shown in sub-figure (a). 

In general, new timing plans can include changes to the majority of the actuated controller 

parameters. A free-controller loads the new parameters (new plan) at its first phase 2 

amber indication following the time period change. A coordinated controller loads the 

new parameters (new plan) at its first yield point (end of phase 2/6 green) following the 

time period change. When a controller is coordinated and the new plan includes changes 

to either its cycle length or offset, then the controller must transition from its old plan to 

the new plan according to one of the transition methods described in the following 

paragraphs. 

(a) Desired offset when system is in step

(b) Offset pattern if no cycle adjustments are made

(c) Offset pattern if cycles are shortened to get in step

(d) Offset pattern if cycles are lengthened to get in step

Sync 

Reference 

Point 

t 

Sync 

Reference 

Point 

t + L 

Sync 

Reference

Point 

t + 2L

Sync 

Reference

Point 

t + 3L 

Sync 

Reference 

Point 

t + 4L 

Sync 

Reference

Point 

t + 5L 

O L L L L L O

O' L L L L L O'

O' L– x% L– x% L L O

O' L + y% L + y% L + y% L O

L – x% 

1 

5 

2 

6 3 4 

Figure 88. Diagram. Examples of timing plan transitions. 
239 

CORSIM supports four transitions methods: 

• Short Way. 

• Dwell. 

• Add. 

• Subtract. 

To determine if a transition is required, the transition manager in the actuated control logic 

computes the difference between the next local zero (yield point) for the current plan and 

the next local zero for the new plan. The local zero for a plan is computed from the system 

sync reference time, the plan cycle length, and plan offset. If there is a difference, then a 

transition is required. The following paragraphs describe the operation of each transition 

method: 

Short Way: The Short Way method is a composite of the Add and Subtract methods. At 

the controller’s yield point in each cycle during the transition, the transition manager 

computes the local zero difference as described above. The transition manager then 

determines if it is shorter (less time) to make up this difference by implementing an Add 

transition or a Subtract transition for the next cycle. Some controller vendors refer to this 

method as “Smooth” or “Best Way”. 

Dwell: For the Dwell method, the transition manager computes the local zero difference, 

as described above, just prior to the controller’s yield point. Then the Dwell method logic 

extends the current phase 2/6 green by the difference, up to the maximum percent of cycle 

length specified. If the difference exceeds the maximum allowed, the Dwell method logic 

continues to add green time to the phase 2/6 split for subsequent cycles until the 

difference is made up. 

Add: At the controller’s yield point in each cycle during the transition, the transition 

manager computes the local zero difference as described above. Then the Add method 

logic adds time to each of the phase splits for the upcoming cycle, where the total amount 

of time added does not exceed the maximum percent of cycle length specified. The 

amount of time added to each phase is based on its percentage of the cycle length in the 

new plan. If the local zero difference exceeds the maximum allowed, the Add method 

logic continues to add time to each phase over multiple cycles until the difference is made 

up. 

Subtract: At the controller’s yield point in each cycle during the transition, the transition 

manager computes the local zero difference as described above. Then the Subtract method 

logic subtracts time from each of the phase splits for the upcoming cycle, where the total 

amount of time subtracted does not violate the maximum percent of cycle length specified. 

The amount of time subtracted from each phase is based on its percentage of the cycle 

length in the new plan, subject to the phase minimum split. The minimum split for a 

phase is calculated as the sum of its yellow change interval, red clearance interval and the 

maximum of its: minimum green, pedestrian timing, and maximum initial interval. In 
240 

some cases where the amount subtracted from a phase is limited due to its minimum split, 

additional time can be subtracted from other phases that have not been limited, subject to 

no phase being reduced by more than the specified percentage. Finally, if the local zero 

difference cannot be made up in one cycle, the Subtract method logic continues to subtract 

time from each phase over multiple cycles until the difference is made up.
241 

Appendix G: Error Checking Process – Coded 

Input Data Checklist 

a. Check time periods and durations to ensure full 

extent of congestion is captured. 

1. Model run parameters: 

b. Verify fill time is long enough for network to become 

fully loaded. 

a. Check basic network connectivity (are all connections 

present?). 

b. Check link geometry (lengths, number of lanes, freeflow speed, facility type, etc.). 

2. Link and node network 

geometry: 

c. Check for prohibited turns, lane closures, and lane 

restrictions at the intersections and on the links. 

a. Check vehicle mix proportions at each entry node. 

b. Check identified sources and sinks for traffic. 

c. Verify volumes against traffic counts. 

d. Check vehicle occupancy distribution (if modeling 

HOV vehicles). 

e. Check turning percentages. 

3. Demand: 

f. Check origin-destinations of trips on the network (if 

coded). 

a. Check intersection controls (control type, control 

data). 

4. Control: 

b. Check ramp meter controls (control type, control 

data). 

a. Verify bus operations, such as dwell times and bus 

paths. 

b. Check parking operations. 

5. Traffic operations and 

management data: 

c. Verify pedestrian operations and delays are properly 

accounted for in the model. 

a. Check and revise, as necessary, the default vehicle 

types and dimensions. 

b. Check and revise the default vehicle performance 

specifications. 

6. Driver behavior and 

vehicle characteristics: 

c. Check and revise the default driver behavior 

specifications. 

243 

Appendix H: Understanding CORSIM Output 

TSIS and CORSIM report the numerical results of the model run in text output files or 

spreadsheet files. The results are summarized over time and/or space. It is critical that 

the analyst understands how CORSIM has accumulated and summarized the results to 

avoid pitfalls in interpreting the numerical output. A summary of all MOEs available 

through the output processor is presented at the end of this appendix. 

Cumulative Versus Interval Data 

CORSIM accumulates data over time intervals and either reports the cumulative sum, 

maximum, or average. The output processor can also report data specific to the time 

interval or time period. Interval specific data are useful for comparing volume data that 

vary over time periods. The changes are reflected close to when the changes were made, 

whereas cumulative data, especially data averaged over the duration of the run, takes a 

long time to reflect the changes in the output. Figure 89 shows the cumulative average 

speed and the interval specific average speed over the duration of a peak period. The 

figure shows that the cumulative average speed is slow to react to the conditions in the 

network while the interval average speed shows the speed changes more like they occur in 

the real world. 

0

10

20

30

40

50

60

70

0 15 30 45 60 75 90 105 120 135 150 165 180 195 210 225 240 255 270 285

Time (minutes)

Average Speed (MPH)

Cumulative Interval

Figure 89. Graph. Cumulative versus interval data. 

CORSIM can report the results for specific points on a link in the network by using 

detectors or data stations, or for aggregated data over the entire link. The point-specific 
244 

output is similar to what would be reported by detectors in the field. Link-specific values 

of road performance are accumulated over the length of the link and, therefore, will vary 

from the point data. 

The key to correctly interpreting the numerical output of CORSIM is to understand how 

the data were accumulated by the model and summarized in the report. The report 

headings give the analyst a clue as to the method of accumulation used. The method of 

data accumulation and averaging can be determined through a detailed review of the 

CORSIM documentation of the reports that it produces and, if the documentation is 

lacking, by querying the software developers themselves through technical support or 

other means. 

An initial healthy skepticism is valuable when reviewing reports until the analyst has 

more experience with CORSIM. CORSIM, like any other software program, may have an 

error in the programming. It helps to cross-check output to ensure that the analyst 

understands how the data is accumulated and reported by the software. 

Control Delay 

In the 1997 version of the HCM, intersection control delay (ICD) was defined as the delay 

incurred by the control facility. “Control delay includes initial deceleration delay, queue 

move-up time, stopped delay and final acceleration delay.”(3) Figure 90 illustrates the 

components of control delay. Distance

ffs or Normal

operating speed 1

d’

d3

d2

d1

Deceleration begins

Dicd

Dd Ds Da

Acceleration ends

t1 t2 t’ t3

Time

Figure 90. Diagram. Control delay components. 
245 

 From the figure, it can be seen that: 

Figure 91. Equation. Control delay components. 

The intersection control delay Dicd can be calculated as follows: 

Figure 92. Equation. Calculating intersection control delay. 

When traffic volume is light, the free-flow speed of the vehicle on the link can replace V in 

the equation in Figure 92. However, at high demand, V can be considerably smaller than 

the free-flow speed. In other words, while the vehicle is delayed by intersection control, it 

is also delayed by high volume. The total delay from time t1 to t3 is calculated in the 

equation in Figure 93. 

Figure 93. Equation. Calculating intersection total delay. 

It should be pointed out that only control delay fully accounts for any slow down caused 

by intersection signal control. Stopped delay (Ds) only considers the time lost while a 

vehicle stops in the queue waiting for a green signal indication or waiting for its leader to 

move forward. It does not consider the time lost while a vehicle is slowing down and 

approaching the stop bar or the end of the queue (Dd), nor does it consider the time lost 
246 

while a vehicle is in a process of regaining its normal operating speed (Da). Approach 

delay may fully account for Ds and Dd, however, accumulation of Da is terminated when a 

vehicle passes the stop bar of the intersection, even though it may still be in the process of 

regaining its full operating speed. This of course underestimates the delay incurred 

during the acceleration stage. In addition, the portion of Da that is ignored may represent 

a significant part of Da if the vehicle is among those first vehicles behind the stop bar. 

Obviously, control delay is a more accurate measurement of vehicular delay caused by 

intersection control. 

Average ICD (AICD) can be calculated analytically by applying formulas (9-22) through 

(9-27) in the HCM.(3) There are several approaches to measure ICD at existing 

intersections: 

• Test-car observing. 

• Path tracking. 

• Arrival and departure queue observing. 

The HCM expounds on the procedures to measure intersection control delay using the 

arrival departure queue observation in its appendix III (3). Because CORSIM is a 

microscopic simulation, it is possible to track individual vehicle profiles and make 

accurate counts of ICD. In addition to its ability to calculate control delay for fixed time 

intersections, CORSIM can also calculate and accumulate control delay for intersections 

under sign control (stop or yield sign), and under actuated signal control. 

HOV Link Statistics 

Most of these statistics are the same as the link statistics, except broken down by lane, and 

some MOEs are converted to units per person. The conversion is accomplished by 

dividing the MOEs by the total number of occupants transported by all of the vehicles on 

the link since the beginning of the simulation. This table also indicates that a lane is an 

HOV lane or an SOV lane and reports the volume of violators that used the HOV lanes. A 

violator is a vehicle that does not qualify to use the HOV lane but uses it anyway. 

Output Processor MOE Descriptions 

The output processor writes the collected data to an Excel workbook, a comma-separated 

file, a tab-separated file, and/or an XML file. Data collected during multiple runs of 

CORSIM can be averaged and many other statistics can be calculated. Interval data and 

time period data can be selected to produce interval specific data or time period specific 

data in addition to cumulative data. Application Program Interface (API) functions in 

CORSIM are used by the Output Processor so the MOEs available in CORSIM can change 

without requiring changes to other components of the TSIS package. Consequently, all 

data that are available in the CORSIM output (*.out) file are available from the output 

processor. All values are calculated by CORSIM. The TSIS Output Processor is capable of 

collecting and summarizing an extensive list of different MOEs. 
247 

Table 23 through Table 43 describe the MOEs available through the output file (*.out) or 

Output Processor. 

Table 23. Bus route MOEs. 

CLASS NAME: Bus_Route 

MOE LABEL UNITS DESCRIPTION 

Person Travel Time Minutes Total time that persons spent traversing the route. 

Calculated as Travel Time Total times the average 

bus occupancy. 

Person Trips ---- Number of persons that have completely traversed the 

route in a bus. Calculated as Bus Trips times the 

average bus occupancy. 

Travel Time Per Bus Minutes/Bus Average time a bus spent traversing the route. 

Calculated as Travel Time Total divided by Bus Trips. 

Travel Time Total Minutes Total time that buses spent traversing the route. 

Accumulated when a bus discharges from the last link 

of the route. 

Trips ---- Number of buses that have completely traversed all 

links in the route. Accumulated when a bus exits the 

last link of a route. 

Table 24. Bus station MOEs. 

CLASS NAME: BusStation 

MOE LABEL UNITS DESCRIPTION 

Buses Serviced Total ---- The total number of buses that serviced the station. 

Accumulated during the evaluation interval. 

Capacity Exceeded Time 

Total 

Minutes Total time that the capacity of the station was 

exceeded. Accumulated when buses cannot enter the 

station because the station is full. 

Dwell Time Total Minutes Total time that buses dwelled in the station. 

Accumulated during the evaluation interval. 

Empty Time Total Minutes Total time that the station was empty (no buses 

dwelling in the station). Accumulated during the 

evaluation interval. 
248 

Table 25. Data station MOEs. 

CLASS NAME: Data_Station 

MOE LABEL UNITS DESCRIPTION 

Headway Average Seconds Average time between vehicles crossing the data 

station. Calculated as the sum of the headways of all 

vehicles crossing the data station divided by the 

number of vehicles crossing the data station. 

Speed Average Feet/Second Average speed of vehicles crossing the data station. 

Calculated as the sum of the speeds of all vehicles 

crossing the data station divided by the number of 

vehicles crossing the data station. 

Table 26. Data station histogram MOEs. 

CLASS NAME: Data_Station_Histogram 

MOE LABEL UNITS DESCRIPTION 

Headway Histogram Data ---- Histogram of headways. Calculated as the number of 

vehicles that crossed the data station with a headway 

in the indicated range, divided by the number of 

vehicles crossing the data station, multiplied by 100 to 

express in percentage. 

Speed Histogram Data ---- Histogram of speeds. Calculated as the number of 

vehicles that crossed the data station with a speed in 

the indicated range, divided by the number of vehicles 

crossing the data station, multiplied by 100 to express 

in percentage. 
249 

Table 27. Freeway detector MOEs. 

CLASS NAME: Detector_Freeway 

MOE LABEL UNITS DESCRIPTION 

Headway Average Seconds Average headway of vehicles crossing the detector. 

Calculated as the sum of vehicle headways divided by 

the vehicle count. 

Occupancy Percent ---- Ratio of the detector on time to the duration of the 

evaluation interval scaled to a point value and 

expressed as a percent. Calculated as the detector 

on time divided by the duration of the evaluation 

interval and multiplied by the ratio of the average 

vehicle length divided by the sum of the average 

vehicle length plus the detector length. 

Speed Average Miles/Hour Average speed of vehicles crossing the detector. 

Calculated as the sum of the speeds of all vehicles 

crossing the detector divided by the vehicle count. 

Volume Vehicles/Hour Number of vehicles crossing the detector, converted 

to an hourly count. Calculated as the vehicle count 

divided by the length of the evaluation interval and 

scaled to one hour. 

Table 28. Surface street detector MOEs. 

CLASS NAME: Detector_Surface 

MOE LABEL UNITS DESCRIPTION 

Count ---- Number of vehicles crossing the detector. 

Accumulated during the evaluation interval. 

Occupancy Percent ---- Ratio of the detector on time to the duration of the 

evaluation interval, expressed as a percent. 

Calculated as On Time divided by the duration of the 

evaluation interval. 

On Time Seconds Total time that the detector was activated. 

Accumulated during the evaluation interval. 

Speed Average Miles/Hour Average speed of vehicles crossing the detector. 

Calculated as the sum of the speeds of all vehicles 

crossing the detector divided by Count. 
250 

Table 29. Entry link MOEs. 

CLASS NAME: Entry_Link 

MOE LABEL UNITS DESCRIPTION 

Delay Per Vehicle Seconds/Vehicle Total delay experiences by all vehicles waiting to 

enter the network divided by the number of vehicles 

waiting to enter the network. 

Delay Total Seconds Total delay experienced by all vehicles waiting to 

enter the network. 

Delayed Vehicles Vehicles Total number of vehicles that were unable to enter the 

network at their scheduled time. 

Vehicles Discharged Total Vehicles Number of vehicles that have been discharged from 

the link. Accumulated during the evaluation interval. 

Vehicles In Queue Current Vehicles Total number of vehicles that are currently in queue at 

the entry link because they were unable to enter the 

network at their scheduled time. 

Table 30. Link fleet MOEs. 

CLASS NAME: Fleet_Link 

MOE LABEL UNITS DESCRIPTION 

Fuel Consumption Gallons Total amount of fuel consumed by all vehicles in the 

fleet. Accumulated for the link during the evaluation 

interval. 
251 

Table 31. Freeway lane MOEs. 

CLASS NAME: Lane_Freeway 

MOE LABEL UNITS DESCRIPTION 

Content Current Vehicles A snapshot of the current number of vehicles in the 

lane. 

Delay Travel Per Vehicle Seconds/Vehicle Average time a vehicle was delayed in the lane. 

Calculated as Travel Time Per Vehicle minus Move 

Time Per Vehicle. 

Delay Travel Total Minutes Total time vehicles were delayed in the lane. 

Accumulated per vehicle during the evaluation 

interval, using each vehicle's travel time, distance 

traveled in the lane, and desired free-flow speed. 

Move Time Per Vehicle Seconds/Vehicle Theoretical time for a vehicle to travel the length of the 

lane if it were moving unimpeded at the free-flow 

speed. Calculated as (Travel Time Total minus Delay 

Travel Total) divided by Travel Time Total times 

Travel Time Per Vehicle. 

Person Delay Per Person Seconds/Person Average time a person is delayed in the lane. 

Calculated as (Travel Time Total divided by Person 

Travel Time Total) times Delay Time Per Vehicle. 

Person Move Time Per 

Person 

Seconds/Person Move Time Per Vehicle times average content divided 

by average occupancy per vehicle, using data 

accumulated per lane. 

Person Travel Time Per 

Person 

Seconds/Person Average time a person travels in the lane. Calculated 

as Person Delay Per Person plus Person MoveTime 

Per Person 

Person Travel Time Total Seconds Total time that people were traveling in the lane. 

Accumulated during the evaluation interval. 

Speed Average Miles/Hour Average speed of the vehicles in the lane. Calculated 

as Travel Distance Total divided by Travel Time Total. 

Travel Distance Total Miles Total distance traveled by vehicles while they were in 

the lane. Accumulated during the evaluation interval. 

Travel Time Per Vehicle Seconds/Vehicle Average time for a vehicle to traverse the entire lane. 

Calculated as the length of the lane divided by Speed 

Average. 

Travel Time Total Minutes Total time that vehicles were in the lane. 

Accumulated during the evaluation interval. 

Volume Vehicles/Hour Number of vehicles using the lane, expressed as an 

hourly value. Calculated as the lane density times 

Speed Average for the lane. Lane density is 

determined by dividing the average content for the 

lane by the length of the lane. 
252 

Table 32. Freeway HOV lane MOEs. (continued) 

CLASS NAME: Lane_Freeway_HOV 

MOE LABEL UNITS DESCRIPTION 

Content Current Vehicles A snapshot of the current number of vehicles in the 

lane. 

Delay Travel Per Vehicle Seconds/Vehicle Average time a vehicle was delayed in the lane. 

Calculated as Travel Time Per Vehicle minus Move 

Time Per Vehicle. 

Delay Travel Total Minutes Total time vehicles were delayed in the lane. 

Accumulated per vehicle during the evaluation 

interval, using each vehicle’s travel time, distance 

traveled in the lane, and desired free-flow speed. 

Move Time Per Vehicle Seconds/Vehicle Theoretical time for a vehicle to travel the length of the 

lane if it were moving unimpeded at the free-flow 

speed. Calculated as (Travel Time Total minus Delay 

Travel Total) divided by Travel Time Total times 

Travel Time Per Vehicle. 

Person Delay Per Person Seconds/Person Average time a person is delayed in the lane. 

Calculated as (Travel Time Total divided by Person 

Travel Time Total) times Delay Time Per Vehicle. 

Person Move Time Per 

Person 

Seconds/Person Move Time Per Vehicle times average content divided 

by average occupancy per vehicle, using data 

accumulated per lane. 

Person Travel Time Per 

Person 

Seconds/Person Average time a person travels in the lane. Calculated 

as Person Delay Per Person plus Person MoveTime 

Per Person 

Person Travel Time Total Seconds Total time that people were traveling in the lane. 

Accumulated during the evaluation interval. 

Speed Average Miles/Hour Average speed of the vehicles in the lane. Calculated 

as Travel Distance Total divided by Travel Time Total. 

Travel Distance Total Miles Total distance traveled by vehicles while they were in 

the lane. Accumulated during the evaluation interval. 

Travel Time Per Vehicle Seconds/Vehicle Average time for a vehicle to traverse the entire lane. 

Calculated as the length of the lane divided by Speed 

Average. 

Travel Time Total Minutes Total time that vehicles were in the lane. 

Accumulated during the evaluation interval. 

Vehicles Entering HOV 

Lane 

Vehicles Number of vehicles entering an HOV lane at the start 

of the HOV lane. Accumulated during the evaluation 

interval. 
253 

Table 32. Freeway HOV lane MOEs. (continued) 

CLASS NAME: Lane_Freeway_HOV 

MOE LABEL UNITS DESCRIPTION 

Vehicles Exiting HOV Lane Vehicles Number of vehicles exiting an HOV lane at the end of 

the HOV lane. Accumulated during the evaluation 

interval. 

Violator Volume Vehicles/Hour Hourly volume of all vehicles that used the lane even 

though they do not meet the requirements for the 

lane. Calculated as the lane density times Speed 

Average for violators using the lane. Lane density is 

determined by dividing the average content for 

violators in the lane by the length of the lane. 

Volume Vehicles/Hour Number of vehicles using the lane, expressed as an 

hourly value. Calculated as the lane density times 

Speed Average for the lane. Lane density is 

determined by dividing the average content for the 

lane by the length of the lane. 

Table 33. Surface street lane MOEs. 

CLASS NAME: Lane_Surface 

MOE LABEL UNITS DESCRIPTION 

Content Current Vehicles A snapshot of the current number of vehicles in the 

lane. 

Queue Average Number 

Vehicles 

Vehicles Average number of vehicles in queue in the lane. 

Calculated as the number of vehicles in queue, 

accumulated every second, divided by the duration of 

the evaluation interval. 

Queue Current Length Feet A snapshot of the distance from the stop line to the 

end of the current queue in lane. 

Queue Current Number 

Vehicles 

Vehicles A snapshot of the current number of vehicles in queue 

in the lane. 

Queue Maximum Number 

Vehicles 

Vehicles Largest number of vehicles in queue in the lane during 

the evaluation interval. 

Vehicles Discharged Per 

Hour 

Vehicles/Hour Number of vehicles discharged from the lane, 

converted to an hourly rate. 

Vehicles Discharged Total Vehicles Total number of vehicles discharged from the lane 

during the evaluation interval. 
254 

Table 34. Freeway link MOEs. (continued) 

CLASS NAME: Link_Freeway 

MOE LABEL UNITS DESCRIPTION 

Bus Delay Per Vehicle Seconds/Vehicle Average time that a bus was delayed on the link. 

Calculated as Bus Delay Total divided by Bus Trips. 

Bus Delay Total Minutes Total time that buses were delayed on the link. 

Calculated as Bus Travel Time Total minus Bus Move 

Time Total. 

Buses That Stopped ---- Number of buses that stopped at least once on the 

link. Accumulated during the evaluation interval when 

a bus stops, provided the bus has not previously 

stopped. 

Bus Move Time Per 

Travel Time Ratio 

---- Ratio of the theoretical move time to the actual travel 

time for buses on the link. Calculated as Bus Move 

Time Total divided by Bus Travel Time Total. 

Bus Move Time Total Minutes Total theoretical time for discharged buses to travel 

the length of the link if moving unimpeded at the freeflow speed. Calculated as Bus Trips times the length 

of the link divided by the link free-flow speed. 

Bus Person Trips ---- Number of persons that have completely traversed the 

link in a bus. Calculated as Bus Trips times the 

average bus occupancy. 

Bus Speed Average Miles/Hour Average speed at which a bus traverses the link. 

Calculated as Bus Trips times the length of the link 

divided by Bus Travel Time Total. 

Bus Travel Time Per 

Vehicle 

Seconds/Vehicle Average time for a bus to traverse the link. Calculated 

as Bus Travel Time Total divided by Bus Trips. 

Bus Travel Time Total Minutes Total time that discharged buses spent traversing the 

link. Accumulated whenever a bus discharges the link 

during the evaluation interval. 

Bus Trips ---- Number of buses that have completely traversed the 

link during the evaluation interval. 

Content Average Vehicles Average number of vehicles on the link during the 

evaluation interval. Calculated as the Travel Time 

Total divided by the duration of the evaluation interval. 

Content Current Vehicles A snapshot of the current number of vehicles on the 

link. 
255 

Table 34. Freeway link MOEs. (continued) 

CLASS NAME: Link_Freeway 

MOE LABEL UNITS DESCRIPTION 

Delay Travel Per 

Distance Traveled 

Minutes/Mile Average time vehicles were delayed per each mile of 

travel. Calculated as Delay Travel Per Vehicle divided 

by Travel Time Per Vehicle multiplied by Travel Time 

Per Distance Traveled. 

Delay Travel Per 

Vehicle 

Seconds/Vehicle Average time that a vehicle was delayed on the link. 

Calculated as the Delay Travel Total divided by 

Vehicles Discharged. 

Delay Travel Total Minutes Total time that all vehicles were delayed on the link. 

Calculated as the Travel Time Total minus Move Time 

Total for the link. 

Density Per Lane Vehicles/Mile/Lane Average number of vehicles per mile per lane. 

Calculated as Content Average divided by link area. 

Link area is the sum of the lengths of the lanes in the 

link. 

Emissions Rate CO Kilograms/Mile-Hour The CO emission rate due to all vehicles on the link. 

Calculated as Emissions Total CO divided by the 

duration of the evaluation interval. 

Emissions Rate HC Kilograms/Mile-Hour The HC emission rate due to all vehicles on the link. 

Calculated as Emissions Total HC divided by the 

duration of the evaluation interval. 

Emissions Rate NOx Kilograms/Mile-Hour The Nox emission rate due to all vehicles on the link. 

Calculated as Emissions Total Nox divided by the 

duration of the evaluation interval. 

Emissions Total CO Grams/Mile The total CO emissions per mile produced by all 

vehicles on the link. Accumulated during the 

evaluation interval. 

Emissions Total HC Grams/Mile The total HC emissions per mile produced by all 

vehicles on the link. Accumulated during the 

evaluation interval. 

Emissions Total Nox Grams/Mile The total Nox emissions per mile produced by all 

vehicles on the link. Accumulated during the 

evaluation interval. 

Fuel Consumption Total Gallons Total fuel consumed by all vehicles on the link. 

Calculated as the sum of the Fuel Consumption by 

fleet on the link. 

Lane Changes Total ---- Total number of lane changes that have been 

completed on the link. Accumulated during the 

evaluation interval. 
256 

Table 34. Freeway link MOEs. (continued) 

CLASS NAME: Link_Freeway 

MOE LABEL UNITS DESCRIPTION 

Move Time Per Travel 

Time Ratio 

---- Ratio of the theoretical move time to the actual travel 

time for vehicles on the link. Calculated as Move 

Time Total divided by Travel Time Total. 

Move Time Per Vehicle Seconds/Vehicle Theoretical time for a vehicle to travel the length of the 

link if it were moving unimpeded at the free-flow 

speed. 

Move Time Total Minutes Total theoretical time for discharged vehicles to travel 

the length of the link if moving unimpeded at the freeflow speed. Calculated as Travel Distance Total 

divided by the free-flow speed on the link. 

Speed Average Miles/Hour Average speed of a vehicle that has completely 

traversed the link. Calculated as Travel Distance 

Total divided by the Travel Time Total. 

Travel Distance Total Miles Total distance traveled by vehicles on the link. 

Accumulated during the evaluation interval. 

Travel Time Per 

Distance Traveled 

Minutes/Mile Average time for a vehicle to travel one mile. 

Calculated as Travel Time Total divided by Travel 

Distance Total. 

Travel Time Per Vehicle Seconds/Vehicle Average time for a vehicle to traverse the link. 

Calculated as the length of the link divided by Speed 

Average. 

Travel Time Total Minutes Total time that all vehicles were on the link. 

Accumulated during the evaluation interval. 

Vehicles Discharged Vehicles Number of vehicles that have been discharged from 

the link. Accumulated during the evaluation interval. 

Vehicles Discharged 

Left 

Vehicles Number of vehicles that have been discharged from 

the link exiting to the left. Accumulated during the 

evaluation interval. 

Vehicles Discharged 

Right 

Vehicles Number of vehicles that have been discharged from 

the link exiting to the right. Accumulated during the 

evaluation interval. 

Vehicles Discharged 

Through 

Vehicles Number of vehicles that have been discharged from 

the link continuing through. Accumulated during the 

evaluation interval. 

Vehicles Entering Link Vehicles Number of vehicles that have entered the link. 

Accumulated during the evaluation interval. 
257 

Table 34. Freeway link MOEs. (continued) 

CLASS NAME: Link_Freeway 

MOE LABEL UNITS DESCRIPTION 

Vehicles Exiting Link Vehicles Number of vehicles that have exited from the link. 

Accumulated during the evaluation interval. 

Volume Per Lane Vehicles/Hour/Lane Average number of vehicles traversing each lane, 

converted to an hourly value. Calculated as Density 

times Speed Average. 

Table 35. Surface street link MOEs. (continued) 

CLASS NAME: Link_Surface 

MOE LABEL UNITS DESCRIPTION 

Bus Delay Per Vehicle Seconds/Vehicle Average time that a bus was delayed on the link. 

Calculated as Bus Delay Total divided by Bus Trips. 

Bus Delay Total Minutes Total time that buses were delayed on the link. 

Calculated as Bus Travel Time minus Bus Move Time. 

Buses That Stopped ---- Number of buses that stopped at least once on the 

link. Accumulated when a bus stops, provided the 

bus has not previously stopped. 

Bus Move Time Per Travel 

Time Ratio 

---- Ratio of the theoretical move time to the actual travel 

time for buses on the link. Calculated as Bus Move 

Time divided by Bus Travel Time. 

Bus Move Time Total Minutes Total theoretical time for discharged buses to travel 

the length of the link if moving unimpeded at the freeflow speed. Calculated as Bus Trips times the length 

of the link divided by the link free-flow speed. 

Bus Person Trips ---- Number of persons that have completely traversed the 

link in a bus. Calculated as Bus Trips times the 

average bus occupancy. 

Bus Speed Average Miles/Hour Average speed at which a bus traverses the link. 

Calculated as Bus Trips times the length of the link 

divided by Bus Travel Time Total. 

Bus Travel Time Per 

Vehicle 

Seconds/Vehicle Average time a bus traverses the link. Calculated as 

Bus Travel Time Total divided by Bus Trips. 
258 

Table 35. Surface street link MOEs. (continued) 

CLASS NAME: Link_Surface 

MOE LABEL UNITS DESCRIPTION 

Bus Travel Time Total Minutes Total time that discharged buses spent traversing the 

link. Accumulated whenever a bus discharges the link 

during the evaluation interval. 

Bus Trips ---- Number of buses that have completely traversed the 

link during the evaluation interval. 

Content Average Vehicles Average number of vehicles on the link during the 

evaluation interval. Calculated as Travel Time Total 

divided by the duration of the evaluation interval. 

Content Current Vehicles A snapshot of the current number of vehicles on the 

link. 

Content Current Diagonal Vehicles A snapshot of the current number of diagonal-turning 

vehicles on the link. 

Content Current Left Vehicles A snapshot of the current number of left-turning 

vehicles on the link. 

Content Current Right Vehicles A snapshot of the current number of right-turning 

vehicles on the link. 

Content Current Through Vehicles A snapshot of the current number of through-moving 

vehicles on the link. 

Delay Control Per Vehicle Seconds/Vehicle Average time that a vehicle was delayed due to 

signals on the link. Calculated as Delay Control Total 

divided by the sum of Trips and Content Current. 

Delay Control Per Vehicle 

Left 

Seconds/Vehicle Average time that a left-turning vehicle was delayed 

due to signals on the link. Calculated as Delay 

Control Total Left divided by the sum of Trips Left and 

Content Current Left. 

Delay Control Per Vehicle 

Right 

Seconds/Vehicle Average time that a right-turning vehicle was delayed 

due to signals on the link. Calculated as Delay 

Control Total Right divided by the sum of Trips Right 

and Content Current Right. 

Delay Control Per Vehicle 

Through 

Seconds/Vehicle Average time that a through-moving vehicle was 

delayed due to signals on the link. Calculated as 

Delay Control Total Through divided by the sum of 

Trips Through and Content Current Through. 

Delay Control Total Minutes The total time vehicles are delayed due to signals on 

the link. The CORSIM User’s Guide(1) contains a 

detailed description of control delay. 
259 

Table 35. Surface street link MOEs. (continued) 

CLASS NAME: Link_Surface 

MOE LABEL UNITS DESCRIPTION 

Delay Control Total Left Minutes The total time left-turning vehicles are delayed due to 

signals on the link. The CORSIM User’s Guide(1)

contains a detailed description of control delay. 

Delay Control Total Right Minutes The total time right-turning vehicles are delayed due 

to signals on the link. The CORSIM User’s Guide(1)

contains a detailed description of control delay. 

Delay Control Total 

Through 

Minutes The total time through-moving vehicles are delayed 

due to signals on the link. The CORSIM User’s 

Guide(1) contains a detailed description of control 

delay. 

Delay Queue Per Vehicle Seconds/Vehicle Average time that a vehicle was queued on the link. 

Calculated as Delay Queue Total divided by the sum 

of Trips and Content Current. 

Delay Queue Total Minutes Total time that vehicles were queued on the link. The 

CORSIM User’s Guide(1) contains a detailed 

description of queue delay. 

Delay Queue Total Left Minutes Total time that left-turning vehicles were queued on 

the link. The CORSIM User’s Guide(1) contains a 

detailed description of queue delay. 

Delay Queue Total Right Minutes Total time that right-turning vehicles were queued on 

the link. The CORSIM User’s Guide(1) contains a 

detailed description of queue delay. 

Delay Queue Total 

Through 

Minutes Total time that through-moving vehicles were queued 

on the link. The CORSIM User’s Guide(1) contains a 

detailed description of queue delay. 

Delay Stop Per Vehicle Seconds/Vehicle Average time that a vehicle was stopped on the link. 

Calculated as Delay Stop Total divided by the sum of 

Trips and Content Current. 

Delay Stop Total Minutes Total time that vehicles were stopped on the link. 

Accumulated during the evaluation interval. 

Delay Stop Total Left Minutes Total time that left-turning vehicles were stopped on 

the link. Accumulated during the evaluation interval. 

Delay Stop Total Right Minutes Total time that right-turning vehicles were stopped on 

the link. Accumulated during the evaluation interval. 
260 

Table 35. Surface street link MOEs. (continued) 

CLASS NAME: Link_Surface 

MOE LABEL UNITS DESCRIPTION 

Delay Stop Total Through Minutes Total time that through-moving vehicles were stopped 

on the link. Accumulated during the evaluation 

interval. 

Delay Travel Per Distance 

Traveled 

Minutes/Mile Average time vehicles were delayed per each mile of 

travel. Calculated as Delay Travel Total divided by 

Travel Distance Total. 

Delay Travel Per Vehicle Seconds/Vehicle Average time that a vehicle was delayed on the link. 

Calculated as Delay Travel Total divided by the sum 

of Trips and Content Current. 

Delay Travel Per Vehicle 

Left 

Seconds/Vehicle Average time that a left-turning vehicle was delayed 

on the link. Calculated as Delay Travel Total Left 

divided by Trips Left. 

Delay Travel Per Vehicle 

Right 

Seconds/Vehicle Average time that a right-turning vehicle was delayed 

on the link. Calculated as Delay Travel Total Right 

divided by Trips Right. 

Delay Travel Per Vehicle 

Through 

Seconds/Vehicle Average time that a through-moving vehicle was 

delayed on the link. Calculated as Delay Travel Total 

Through divided by Trips Through. 

Delay Travel Total Minutes Total time that vehicles were delayed on the link. 

Calculated as Travel Time Total minus Move Time 

Total. 

Delay Travel Total Left Minutes Total time that left-turning vehicles were delayed on 

the link. Calculated as Travel Time Total Left minus 

Move Time Total Left. 

Delay Travel Total Right Minutes Total time that right-turning vehicles were delayed on 

the link. Calculated as Travel Time Total Right minus 

Move Time Total Right. 

Delay Travel Total 

Through 

Minutes Total time that through-moving vehicles were delayed 

on the link. Calculated as Travel Time Total Through 

minus Move Time Total Through. 

Emissions Rate CO Kilograms/MileHour The CO emission rate due to all vehicles on the link. 

Calculated as Emissions Total CO divided by the 

duration of the evaluation interval. 

Emissions Rate HC Kilograms/MileHour The HC emission rate due to all vehicles on the link. 

Calculated as Emissions Total HC divided by the 

duration of the evaluation interval. 
261 

Table 35. Surface street link MOEs. (continued) 

CLASS NAME: Link_Surface 

MOE LABEL UNITS DESCRIPTION 

Emissions Rate NOx Kilograms/MileHour The Nox emission rate due to all vehicles on the link. 

Calculated as Emissions Total Nox divided by the 

duration of the evaluation interval. 

Emissions Total CO Grams/Mile The total CO emissions per mile produced by all 

vehicles on the link. Accumulated during the 

evaluation interval. 

Emissions Total HC Grams/Mile The total HC emissions per mile produced by all 

vehicles on the link. Accumulated during the 

evaluation interval. 

Emissions Total Nox Grams/Mile The total Nox emissions per mile produced by all 

vehicles on the link. Accumulated during the 

evaluation interval. 

Fuel Consumption Total Gallons Total fuel consumed by all vehicles on the link. 

Calculated as the sum of the Fuel Consumption by 

fleet on the link. 

Lane Changes Total ---- Total number of lane changes that have been 

completed on the link. Accumulated during the 

evaluation interval. 

Move Time Per Travel 

Time Ratio 

---- Ratio of the theoretical move time to the actual travel 

time for vehicles on the link. Calculated as Move 

Time Total divided by Travel Time Total. 

Move Time Per Travel 

Time Ratio Left 

---- Ratio of the theoretical move time to the actual travel 

time for left-turning vehicles on the link. Calculated as 

Move Time Total Left divided by Travel Time Total 

Left. 

Move Time Per Travel 

Time Ratio Right 

---- Ratio of the theoretical move time to the actual travel 

time for right-turning vehicles on the link. Calculated 

as Move Time Total Right divided by Travel Time 

Total Right. 

Move Time Per Travel 

Time Ratio Through 

---- Ratio of the theoretical move time to the actual travel 

time for through-moving vehicles on the link. 

Calculated as Move Time Total Through divided by 

Travel Time Total Through. 

Move Time Total Minutes Total theoretical time for discharged vehicles to travel 

the length of the link if moving unimpeded at the freeflow speed. Calculated as Travel Distance Total 

divided by the free-flow speed on the link. 
262 

Table 35. Surface street link MOEs. (continued) 

CLASS NAME: Link_Surface 

MOE LABEL UNITS DESCRIPTION 

Move Time Total Left Minutes Total theoretical time for discharged left-turning 

vehicles to travel the length of the link if moving 

unimpeded at the free-flow speed. Calculated as 

Travel Distance Total Left divided by the free-flow 

speed on the link. 

Move Time Total Right Minutes Total theoretical time for discharged right-turning 

vehicles to travel the length of the link if moving 

unimpeded at the free-flow speed. Calculated as 

Travel Distance Total Right divided by the free-flow 

speed on the link. 

Move Time Total Through Minutes Total theoretical time for discharged through-moving 

vehicles to travel the length of the link if moving 

unimpeded at the free-flow speed. Calculated as 

Travel Distance Total Through divided by the free-flow 

speed on the link. 

Person Delay Total Person-Minutes Total delay to persons completely traversing the link. 

Calculated as Person Travel Time Total minus the 

division of Person Travel Distance Total by the freeflow speed on the link. 

Person Travel Distance 

Total 

---- Total distance traveled by persons on the link. 

Calculated as Travel Distance Total times the average 

number of persons per vehicle for vehicles on the link. 

Person Travel Time Total Minutes Total time that people were traveling the link. 

Calculated as Travel Time Total times the average 

number of persons per vehicle for vehicles on the link. 

Person Trips Total ---- Total number of people traversing the link. Calculated 

as Trips times the average number of persons per 

vehicle for vehicles on the link. 

Phase Failures Total ---- Total number of phase failures on the link. A phase 

failure occurs when vehicles queued at a signal are 

not all discharged in one cycle during the phase 

serving the queue. Accumulated during the 

evaluation interval. 

Speed Average Miles/Hour Average speed of a vehicle that has completely 

traversed the link. Calculated as Travel Distance 

Total divided by the Travel Time Total. 
263 

Table 35. Surface street link MOEs. (continued) 

CLASS NAME: Link_Surface 

MOE LABEL UNITS DESCRIPTION 

Speed Average Left Miles/Hour Average speed of a left-turning vehicle that has 

completely traversed the link. Calculated as Travel 

Distance Total Left divided by the Travel Time Total 

Left. 

Speed Average Right Miles/Hour Average speed of a right-turning vehicle that has 

completely traversed the link. Calculated as Travel 

Distance Total Right divided by the Travel Time Total 

Right. 

Speed Average Through Miles/Hour Average speed of a through-moving vehicle that has 

completely traversed the link. Calculated as Travel 

Distance Total Through divided by the Travel Time 

Total Through. 

Stopped Vehicles Vehicles Number of discharged vehicles that stopped at least 

once on the link. Accumulated during the evaluation 

interval. 

Stopped Vehicles Percent ---- Percentage of vehicles that have completely traversed 

the link that were forced to stop at least once while on 

the link. Calculated as Stopped Vehicles divided by 

Trips. 

Stopped Vehicles Percent 

Left 

---- Percentage of left-turning vehicles that have 

completely traversed the link that were forced to stop 

at least once while on the link. Calculated as the 

number of left-turning vehicles that stopped divided by 

Trips Left. 

Stopped Vehicles Percent 

Right 

---- Percentage of right-turning vehicles that have 

completely traversed the link that were forced to stop 

at least once while on the link. Calculated as the 

number of right-turning vehicles that stopped divided 

by Trips Right. 

Stopped Vehicles Percent 

Through 

---- Percentage of through-moving vehicles that have 

completely traversed the link that were forced to stop 

at least once while on the link. Calculated as the 

number of through-moving vehicles that stopped 

divided by Trips Through. 

Storage Percent ---- Average percentage of link length that vehicles 

occupied. Calculated as Content Average times the 

average vehicle length divided by the link area. Link 

area is the sum of the lengths of the lanes in the link. 

Travel Distance Total Miles Total distance traveled by vehicles on the link. 

Accumulated during the evaluation interval and 

adjusted for vehicles entering the link via a right turn. 
264 

Table 35. Surface street link MOEs. (continued) 

CLASS NAME: Link_Surface 

MOE LABEL UNITS DESCRIPTION 

Travel Distance Total Left Miles Total distance traveled by left-turning vehicles on the 

link. Calculated as Travel Distance Total times Trips 

Left divided by Trips. 

Travel Distance Total 

Right 

Miles Total distance traveled by right-turning vehicles on the 

link. Calculated as Travel Distance Total times Trips 

Right divided by Trips. 

Travel Distance Total 

Through 

Miles Total distance traveled by through-moving vehicles on 

the link. Calculated as Travel Distance Total times 

Trips Through divided by Trips. 

Travel Time Per Distance 

Traveled 

Minutes/Mile Average time for a vehicle to travel one mile. 

Calculated as Travel Time Total divided by Travel 

Distance Total. 

Travel Time Per Vehicle Seconds/Vehicle Average time for a vehicle to traverse the link. 

Calculated as Travel Time Total divided by the sum of 

Trips and Content Current. 

Travel Time Per Vehicle 

Left 

Seconds/Vehicle Average time for a left-turning vehicle to traverse the 

link. Calculated as Travel Time Total Left divided by 

Trips Left. 

Travel Time Per Vehicle 

Right 

Seconds/Vehicle Average time for a right-turning vehicle to traverse the 

link. Calculated as Travel Time Total Right divided by 

Trips Right. 

Travel Time Per Vehicle 

Through 

Seconds/Vehicle Average time for a through-moving vehicle to traverse 

the link. Calculated as Travel Time Total Through 

divided by Trips Through. 

Travel Time Total Minutes Total time that all discharged vehicles were on the 

link. Accumulated during the evaluation interval when 

a vehicle exits the link. 

Travel Time Total Left Minutes Total time that discharged left-turning vehicles were 

on the link. Accumulated during the evaluation 

interval when a left-turning vehicle exits the link. 

Travel Time Total Right Minutes Total time that discharged right-turning vehicles were 

on the link. Accumulated during the evaluation 

interval when a right-turning vehicle exits the link. 

Travel Time Total Through Minutes Total time that discharged through-moving vehicles 

were on the link. Accumulated during the evaluation 

interval when a through-moving vehicle exits the link. 
265 

Table 35. Surface street link MOEs. (continued) 

CLASS NAME: Link_Surface 

MOE LABEL UNITS DESCRIPTION 

Trips ---- Total number of vehicles that have traversed the link. 

A vehicle that completely traverses the link counts as 

one full trip. A vehicle that enters at the upstream end 

of the link but is extracted at a sink node counts as 

half of a trip, and a vehicle that enters from a source 

node and discharges at the downstream end of the 

link is counted as half a trip. Accumulated during the 

evaluation interval when a vehicle exits the link. 

Trips Left ---- Total number of left-turning vehicles that have 

traversed the link. A vehicle that completely traverses 

the link counts as one full trip. A vehicle that enters at 

the upstream end of the link but is extracted at a sink 

node counts as half of a trip, and a vehicle that enters 

from a source node and discharges at the 

downstream end of the link is counted as half a trip. 

Accumulated during the evaluation interval when a 

vehicle exits the link. 

Trips Right ---- Total number of right-turning vehicles that have 

traversed the link. A vehicle that completely traverses 

the link counts as one full trip. A vehicle that enters at 

the upstream end of the link but is extracted at a sink 

node counts as half of a trip, and a vehicle that enters 

from a source node and discharges at the 

downstream end of the link is counted as half a trip. 

Accumulated during the evaluation interval when a 

vehicle exits the link. 

Trips Through ---- Total number of through-moving vehicles that have 

traversed the link. A vehicle that completely traverses 

the link counts as one full trip. A vehicle that enters at 

the upstream end of the link but is extracted at a sink 

node counts as half of a trip, and a vehicle that enters 

from a source node and discharges at the 

downstream end of the link is counted as half a trip. 

Accumulated during the evaluation interval when a 

vehicle exits the link. 

Vehicles Discharged Vehicles Total number of vehicles that have been discharged 

from the link. Accumulated during the evaluation 

interval when a vehicle exits the link. 
266 

Table 35. Surface street link MOEs. (continued) 

CLASS NAME: Link_Surface 

MOE LABEL UNITS DESCRIPTION 

Vehicles Discharged Left Vehicles Total number of left-turning vehicles that have been 

discharged from the link. Accumulated during the 

evaluation interval when a vehicle exits the link. 

Vehicles Discharged Right Vehicles Total number of right-turning vehicles that have been 

discharged from the link. Accumulated during the 

evaluation interval when a vehicle exits the link. 

Vehicles Discharged 

Through 

Vehicles Total number of through-moving vehicles that have 

been discharged from the link. Accumulated during 

the evaluation interval when a vehicle exits the link. 

Volume Vehicles/Hour Average number of vehicles traversing the link, 

converted to an hourly value. Calculated as Trips 

divided by the duration of the evaluation interval. 
267 

Table 36. Network-wide MOEs. 

CLASS NAME: Network 

MOE LABEL UNITS DESCRIPTION 

Content Average Vehicles Average number of vehicles in the network during the 

evaluation interval. Calculated as the Travel Time 

Total divided by the duration of the evaluation interval. 

Content Current Vehicles Snapshot of the current number of vehicles in the 

network. 

Delay Travel Per Distance 

Traveled 

Minutes/Mile Average delay per mile traveled. Calculated as Delay 

Travel Total divided by Travel Distance Total. 

Delay Travel Total Hours Total time that all vehicles were delayed in the 

network. Calculated as the Travel Time Total minus 

Move Time Total for the network. 

Move Time Per Travel 

Time Ratio 

---- Ratio of the theoretical move time to the actual travel 

time for vehicles in the network. Calculated as Move 

Time Total divided by Travel Time Total. 

Move Time Total Hours Total theoretical time for all vehicles traveling in the 

network if moving unimpeded at the free-flow speed. 

Calculated as Travel Distance Total divided by the 

free-flow speed, computed by link and summed for all 

links in the network. 

Speed Average Miles/Hour Average speed of a vehicle traveling in the network. 

Calculated as Travel Distance Total divided by Travel 

Time Total. 

Travel Distance Total Miles Total distance traveled by all vehicles. Calculated as 

the sum of Travel Distance Total for all subnetworks. 

Travel Time Per Distance 

Traveled 

Minutes/Mile Average time for a vehicle to travel one mile. 

Calculated as Travel Time Total divided by Travel 

Distance Total. 

Travel Time Total Hours Total travel time for all vehicles in the network. 

Calculated as the sum of Travel Time Total for all 

subnetworks. 
268 

Table 37. Freeway network MOEs. 

CLASS NAME: Network_Freeway 

MOE LABEL UNITS DESCRIPTION 

Content Average Vehicles Average number of vehicles in the FRESIM 

subnetwork during the evaluation interval. Calculated 

as the sum of Content Average for all links in the 

subnetwork. 

Content Current Vehicles Snapshot of the current number of vehicles in the 

FRESIM subnetwork. Calculated as the sum of 

Content Current for all links in the subnetwork. 

Delay Travel Per Distance 

Traveled 

Minutes/Mile Average delay per mile traveled. Calculated as Delay 

Travel Total divided by Travel Distance Total. 

Delay Travel Total Hours Total time that all vehicles were delayed in the 

FRESIM subnetwork. Calculated as the sum of Delay 

Travel Total for all links in the subnetwork. 

Lane Changes Total ---- Total number of lane changes that have been 

completed on all links in the FRESIM subnetwork. 

Calculated as the sum of Lane Changes Total for all 

links in the subnetwork. 

Move Time Per Travel 

Time Ratio 

---- Ratio of the theoretical move time to the actual travel 

time for vehicles in the FRESIM subnetwork. 

Calculated as (Travel Time Total minus Delay Travel 

Total) divided by Travel Time Total. 

Speed Average Miles/Hour Average speed of a vehicle traveling in the FRESIM 

subnetwork. Calculated as Travel Distance Total 

divided by Travel Time Total. 

Travel DistanceTotal ---- Total distance traveled by all vehicles in the FRESIM 

subnetwork. Calculated as the sum of Travel 

Distance Total for links in the subnetwork. 

Travel Time Per Distance 

Traveled 

Minutes/Mile Average time for a vehicle to travel one mile in the 

FRESIM subnetwork. Calculated as Travel Time Total 

divided by Travel Distance Total. 

Travel Time Total Hours Total travel time for all vehicles in the FRESIM 

subnetwork. Calculated as the sum of Travel Time 

Total for all links in the subnetwork. 
269 

Table 38. Surface street network MOEs. (continued) 

CLASS NAME: Network_Surface 

MOE LABEL UNITS DESCRIPTION 

Content Average Vehicles Average number of vehicles in the NETSIM 

subnetwork during the evaluation interval. Calculated 

as the sum of Content Average for all links in the 

subnetwork. 

Content Current Vehicles Snapshot of the current number of vehicles in the 

NETSIM subnetwork. Calculated as the sum of 

Content Current for all links in the subnetwork. 

Delay Queue Total Minutes Total time that vehicles in the NETSIM subnetwork 

were in queue. Calculated as the sum of Delay 

Queue Total on all links in the subnetwork. 

Delay Stop Total Minutes Total time that vehicles were stopped in the NETSIM 

subnetwork. Calculated as the sum of Delay Stop 

Total on all links in the subnetwork. 

Delay Travel Total Hours Total time that vehicles were delayed in the NETSIM 

subnetwork. Calculated as Travel Time Total minus 

Move Time Total. 

Lane Changes Total ---- Total number of lane changes that have been 

completed on all links in the NETSIM subnetwork. 

Calculated as the sum of Lane Changes Total for all 

links in the subnetwork. 

Move Time Per Travel 

Time Ratio 

---- Ratio of the theoretical move time to the actual travel 

time for vehicles in the NETSIM subnetwork. 

Calculated as Move Time Total divided by Travel 

Time Total. 

Move Time Total Hours Total theoretical time for all vehicles traveling in the 

NETSIM subnetwork if moving unimpeded at the freeflow speed. Calculated as the sum of Move Time 

Total for all links in the subnetwork. 

Phase Failures Total ---- Total number of phase failures in the NETSIM 

subnetwork. A phase failure occurs when vehicles 

queued at a signal are not all discharged in one cycle 

during the phase serving the queue. Calculated as 

the sum of Phase Failures Total on all links in the 

subnetwork. 

Speed Average Miles/Hour Average speed of a vehicle traveling in the NETSIM 

subnetwork. Calculated as Travel Distance Total 

divided by Travel Time Total. 
270 

Table 38. Surface street network MOEs. (continued) 

CLASS NAME: Network_Surface 

MOE LABEL UNITS DESCRIPTION 

Stopped Vehicles Percent ---- Percentage of vehicles that have completely traversed 

links in the NETSIM subnetwork that were forced to 

stop at least once while on a link. Calculated as the 

sum of Stopped Vehicles divided by sum of Trips for 

all links in the subnetwork. 

Storage Percent ---- Average percentage of total subnetwork link length 

that vehicles occupied. Calculated as the sum of the 

product of Content Average and average vehicle 

length divided by the sum of link area for all links in 

the subnetwork. 

Travel Distance Total Miles Total distance traveled by all vehicles in the NETSIM 

subnetwork. Calculated as the sum of Travel 

Distance Total for all links in the subnetwork. 

Travel Time Per Distance 

Traveled 

Minutes/Mile Average time for a vehicle to travel one mile in the 

NETSIM subnetwork. Calculated as Travel Time Total 

divided by Travel Distance Total. 

Travel Time Total Hours Total travel time for all vehicles in the NETSIM 

subnetwork. Calculated as the sum of Travel Time 

Total for all links in the subnetwork. 

Trips ---- Number of vehicles that have left the subnetwork via 

an exit node or sink node. Accumulated during the 

evaluation interval. 
271 

Table 39. Section MOEs. 

CLASS NAME: Section 

MOE LABEL UNITS DESCRIPTION 

Content Average Vehicles Average number of vehicles in the section. 

Calculated as the sum of Content Average on all links 

in the section. 

Delay Travel Total Minutes Total time that vehicles were delayed in the section. 

Calculated as the sum of Delay Travel Total on all 

links in the section. 

Speed Average Miles/Hour Average speed of a vehicle traveling in the section. 

Calculated as Travel Distance Total divided by Travel 

Time Total. 

Stopped Vehicles Percent ---- Percentage of vehicles that have completely traversed 

links in the section that were forced to stop at least 

once while on a link. Calculated as the sum of 

Stopped Vehicles for the links in the section divided 

by Trips. 

Travel Distance Total Miles Total distance traveled by all vehicles in the NETSIM 

subnetwork. Calculated as the sum of Travel 

Distance Total for links in the section. 

Travel Time Per Vehicle Seconds/Vehicle Average travel time for a vehicle in the section. 

Calculated as Travel Time Total divided by Trips. 

Travel Time Total Minutes Total travel time for all vehicles in the section. 

Calculated as the sum of Travel Time Total for all links 

in the section. 

Trips ---- Total number of vehicles that have completely 

traversed the links in the section. Calculated as the 

sum of Trips on all links in the section. 
272 

Table 40. Link vehicle type MOEs. 

CLASS NAME: Vehicle_Type_Link 

MOE LABEL UNITS DESCRIPTION 

Emissions Total CO Grams/Mile The total CO emissions per mile produced by all 

vehicles of the specified type on the link. 

Accumulated during the evaluation interval. 

Emissions Total HC Grams/Mile The total HC emissions per mile produced by all 

vehicles of the specified type on the link. 

Accumulated during the evaluation interval. 

Emissions Total NOx Grams/Mile The total Nox emissions per mile produced by all 

vehicles of the specified type on the link. 

Accumulated during the evaluation interval. 

Fuel Consumption Total Gallons Total fuel consumed by all vehicles of the specified 

type on the link. Accumulated during the evaluation 

interval. 

Fuel Efficiency Miles/Gallon Average distance traveled per gallon of fuel for 

vehicles of the specified type on the link. Calculated 

for each vehicle type as Travel Distance Total divided 

by Fuel Consumption Total. 

Speed Average Miles/Hour Average speed of vehicles of the specified type on the 

link. Calculated as Travel Distance Total divided by 

Travel Time Total. 

Travel Distance Total Feet Total distance traveled by all vehicles of the specified 

type on the link. Accumulated during the evaluation 

interval. 

Travel Time Total Seconds Total travel time for vehicles of the specified type on 

the link. Accumulated during the evaluation interval. 

Vehicles Discharged Vehicles Number of vehicles of the specified type that have 

discharged from the link. Accumulated during the 

evaluation interval. 
273 

Table 41. Freeway network vehicle type MOEs. 

CLASS NAME: Vehicle_Type_Network_Freeway 

MOE LABEL UNITS DESCRIPTION 

Emissions Total CO Grams/Mile The total CO emissions per mile produced by all 

vehicles of the specified type in the FRESIM 

subnetwork. Accumulated during the evaluation 

interval. 

Emissions Total HC Grams/Mile The total HC emissions per mile produced by all 

vehicles of the specified type in the FRESIM 

subnetwork. Accumulated during the evaluation 

interval. 

Emissions Total NOx Grams/Mile The total Nox emissions per mile produced by all 

vehicles of the specified type in the FRESIM 

subnetwork. Accumulated during the evaluation 

interval. 

Fuel Consumption Total Gallons Total fuel consumed by all vehicles of the specified 

type in the FRESIM subnetwork. Accumulated during 

the evaluation interval. 

Fuel Efficiency Miles/Gallon Average distance traveled per gallon of fuel for 

vehicles of the specified type in the FRESIM 

subnetwork. Calculated as the total number of miles 

traveled in the FRESIM subnetwork divided by Fuel 

Consumption Total. 
274 

Table 42. Surface street network vehicle type MOEs. 

CLASS NAME: Vehicle_Type_Network_Surface 

MOE LABEL UNITS DESCRIPTION 

Emissions Total CO Grams/Mile The total CO emissions per mile produced by all 

vehicles of the specified type in the NETSIM 

subnetwork. Accumulated during the evaluation 

interval. 

Emissions Total HC Grams/Mile The total HC emissions per mile produced by all 

vehicles of the specified type in the NETSIM 

subnetwork. Accumulated during the evaluation 

interval. 

Emissions Total NOx Grams/Mile The total NOx emissions per mile produced by all 

vehicles of the specified type in the NETSIM 

subnetwork. Accumulated during the evaluation 

interval. 

Fuel Consumption Total Gallons Total fuel consumed by all vehicles of the specified 

type in the NETSIM subnetwork. Accumulated during 

the evaluation interval. 

Fuel Efficiency Miles/Gallon Average distance traveled per gallon of fuel for 

vehicles of the specified type in the NETSIM 

subnetwork. Calculated as the total number of miles 

traveled in the NETSIM subnetwork divided by the 

Fuel Consumption Total. 

Table 43. Conflict data MOEs. 

CLASS NAME: Conflict_Data 

MOE LABEL UNITS DESCRIPTION 

Conflicts Total ---- Total Number of Conflicts. 

Conflicts Total Auto Auto ---- Total Number of Auto/Auto Conflicts. 

Conflicts Total Auto Truck ---- Total Number of Auto/Truck Conflicts. 

Conflicts Total Truck Auto ---- Total Number of Truck/Auto Conflicts. 

Conflicts Total Truck Truck ---- Total Number of Truck/Truck Conflicts. 
275 

Appendix I: Frequently Asked Questions 

The following list of frequently asked questions has been developed over the last ten years 

of experience with TSIS and CORSIM. The questions and answers are grouped by the tool 

that they apply to. 

CORSIM 

Q: How do I use CORSIM to model a toll booth? 

A: A toll booth can be modeled several different ways. The most popular way is to split a 

single NETSIM link into several parallel links and using a fixed time signal on each of 

the parallel links to model the delay at the booth. See the “CORSIM City” 

demonstration file provided with the TSIS software for an example of this method. 

Q: How do I use CORSIM to model a weigh station? 

A: Use a combination of Record Types 24 and 25 to force all trucks to exit the freeway 

while all other vehicles remain on the freeway. At the end of the off-ramp, use one or 

more NETSIM links with some type of control device to represent the time the trucks 

spend being weighed. Have another NETSIM link feed an on-ramp back onto the 

freeway. 

Q: How do I use CORSIM to model a bi-directional freeway HOV lane? 

A: Model the lane on two parallel opposing links and use different time periods to 

represent the times when the lane is in use in each direction. Close the lane in the 

direction not being used. Insert a transitional time period in which the lane is closed in 

both directions to allow vehicles to get out of the lane before it starts accepting traffic 

in the opposite direction. 

Q: What's the difference between on-line and off-line incident detection? 

A: On-line incident detection is applied as the simulation proceeds. Off-line incident 

detection is performed after the simulation is finished. Off-line allows the detection to 

be performed more than once using different detection algorithms. On-line only 

allows one detection algorithm. 

Q: What causes 6710 errors? 

A: Error message 6710 states that a vehicle is on a lane that does not exist. A 6710 error is 

usually caused by a problem with the leader-follower chain. When a vehicle has a 

leader it simply follows that leader without bothering to look for geometric objects 

such as lane drops or the end of auxiliary lanes. CORSIM assumes that the leader will 

react to those objects and the follower will stay behind the leader. When there is an 

error in determining which vehicle is the leader of another vehicle, a follower can 

blindly drive off the end of an existing lane, causing a 6710 error. Occasionally, the 

leader-follower errors are caused by programming bugs. They can also be caused by 

improper inputs, such as links that are too short. They can also be caused by a 
276 

geometry that forms a complete circle, such as a cloverleaf with full auxiliary lanes 

connecting the branches. An off-ramp that leads to an on-ramp that leads back onto 

the freeway will also cause leader-follower errors. 

A 6710 error can also be caused by having more lanes on the NETSIM side of an 

interface than there are on the FRESIM side, where traffic flows from NETSIM into 

FRESIM. The number of lanes and the lane IDs must match on both sides of the 

interface node. 

Q: How can I increase the entry volume on my freeway network? 

A: The default value for the minimum time between successive vehicles entering the 

network in a given lane (i.e., the “Minimum separation for generation of vehicles” 

parameter in CORSIM) is 1.6 seconds. That limits the entry volume to 2,250 

veh/h/lane. If a higher volume is desired, then that default value should be 

decreased, which is entry 2 on Record Type 70 or on the “Miscellaneous” page of the 

“FRESIM Setup” dialog in TRAFED. You might also need to reduce the car following 

sensitivity factors, which are on Record Type 68 or on the “Driver Behavior” page of 

the “FRESIM Setup” dialog in TRAFED, so that vehicles will remain closer to their 

leader after they enter the network. 

Q: Is there a good way to get queue length parameters from the CORSIM outputs? 

A: Look for the "Average Queue by Lane" MOE in the output file. The number reported is 

the average number of vehicles in queue. If you select Intermediate Reports on Record 

Type 5 or on the “Reports” page of the “Network Properties” dialog in TRAFED, you 

will also get the queue length in feet. 

Q: Can I get time period specific output from CORSIM? 

A: CORSIM will provide time period specific output in the output file (*.out) for the 

NETSIM subnetwork only. However, the Output Processor was designed to report 

MOEs in three different modes: cumulative, interval specific, and time period specific. 

All three modes work for NETSIM and FRESIM, as well as network wide. Cumulative 

MOEs use data accumulated from the beginning of the simulation until the end of the 

current time period. MOEs by interval use data accumulated over the current interval, 

and MOEs by time period use data accumulated over the current time period. They 

can be selected individually or in any combination. 

Q: What causes numerous instances of warning message 720? 

A: This is usually caused by the lane drop warning sign distance. The warning sign for a 

lane drop should never be at a location with only one lane. The warning sign location 

is really the point at which vehicles respond to the object associated with the warning 

sign. If there is only one lane at the point, or only one lane usable by certain vehicles, 

the warning sign will be ignored. 

Q: Why do I observe incorrect traffic-actuated phase operations in conjunction with 

passage or pulse detectors? 
277 

A: The operational mode of the detector depends on what functionality it supports with 

regard to actuated control operations. Presence mode should be used when the 

detector is being used solely to call the phase (e.g., a detector located at or near the stop 

bar). Passage (pulse) mode detectors are typically used to support green extension and 

the volume/density operations of the actuated controller (e.g., variable initial and gap 

reduction functions). When used for these purposes, the passage mode detector is 

typically located upstream of the stop bar and is primarily used to note the passage of 

a vehicle (green extension and gap reduction) or to count vehicles (variable initial 

timing). If a passage mode detector is also being used to call the phase, then the yellow 

lock function for that phase should be set. With yellow lock set, if any vehicle activates 

the detector during the yellow or red intervals of the phase, the controller will 

“remember” that the detector was activated and will call the phase. Yellow lock also 

applies to presence mode detectors that are located upstream of the stop bar. 

Q: Why does the CORSIM output file show instances of the following warning messages: 

"Vehicles missed destinations - vehicle number...", and 

"Computed leader..." 

A: The message regarding missed destinations states that a vehicle was unable to get to its 

freeway off-ramp and missed its destination. In this case, the vehicle will be rerouted 

to the next off-ramp downstream. This will change the percentages of vehicles exiting 

at those off-ramps. You should try to determine why so many vehicles are missing 

their destinations. Consider off-ramp warning sign locations and any messages from 

CORSIM about vehicles not having acceptable candidate lanes to travel in. The 

computed leader warning message indicates that the FRESIM lane change logic broke 

down, possibly because of incorrectly specified connections between freeways. 

Q: What is causing unusual or unrealistic traffic assignment results in NETSIM? 

A: Unrealistic traffic assignment results will occur at actuated signals, because no 

methodology is present in CORSIM for estimating the average green times. The traffic 

assignment logic also requires that all signalized or uncontrolled intersection 

approaches actually have vehicle volume on them. 

Q: What causes an actuated phase in NETSIM to terminate right after the minimum green 

time, even when volumes are heavy? 

A: There have been several fixes to the actuated control logic included in TSIS/CORSIM 

version 6.0 which eliminated premature phase termination problems associated with 

the use of the volume/density functions. If premature phase termination is still a 

problem when using TSIS/CORSIM 6.0: 

• Check that the maximum green time (or maximum extension time) is properly set 

(i.e., not too low). 

• For a coordinated controller, check that the split time is properly set (i.e., if too 

small, the phase may be forced off too soon). Keep in mind the split time includes 

the minimum green, yellow interval, and red interval times. 
278 

• If gap reduction is enabled, check that the minimum and maximum gap settings 

are properly set (i.e., if too low, the phase may gap out even in heavy volume). 

Q: What causes warning message 725 (e.g., “While traveling on lane 1 on link (2, 3), 

vehicle 4 no longer has a candidate lane on which to travel.”)? 

A: Various downstream geometric objects, such as off-ramps, lane drops and incidents, 

force vehicles to avoid certain lanes. When warning signs for those objects are not 

located correctly, the result can be that there are no lanes that should not be avoided by 

some, or all, vehicles. A vehicle is in that situation will ignore the warning signs and 

stay in its current lane, which can cause vehicles to get stuck at lane drops or incidents, 

or take the wrong exit. Vehicles begin to react to the geometric objects where the 

warning sign is located, so the combined effect of the warning signs must allow at least 

one lane that can be used by the vehicles that have crossed the warning sign. 

Q: How can I code "split phasing" for actuated controllers? 

A: Suppose that split phasing is desired for the side-street approaches to an intersection 

where the side streets are oriented in an east-west direction. For split phasing, all 

eastbound movements are served by a single phase, followed by a single phase for all 

westbound movements. Typically, side-street phases are coded in dual-ring phases 3, 

4, 7, and 8. Phases 3 and 7 are designed to run concurrently because they are typically 

used for overlapping protected left turns. Similarly, phases 4 and 8 are designed to run 

concurrently to support concurrent side-street phasing (both directions concurrently, 

with permitted left turns possible). Because only one phase in each ring can be active, 

coding all eastbound movements in phase 3 and all westbound movements in phase 4 

will implement split phasing. Alternatively, phases 7 and 8 could be used. Because 

CORSIM does not allow the specification of a barrier between phase 3 and 8 (or 4 and 

7), they can also operate concurrently and cannot be used for split phasing. Finally, a 

similar coding scheme can also be used to implement split phasing for the main-street 

approaches using phases 1 and 2 or phases 5 and 6. 

Q: How can I code an entry node volume greater than 9,999 vehicles per hour (veh/h)? 

A: The limit for standard coding at a single entry node is 9,999 veh/h. There are a couple 

of ways around that limitation. One would be to create two or more entry nodes using 

9,999 veh/h each, and then funnel that traffic onto the entry link. Another way would 

be to specify the entry volume in terms of vehicle counts. This allows 9,999 vehicles to 

be specified as a vehicle count, and allows counts as often as every minute. Therefore 

the maximum that could be entered is 9,999 vehicles per minute, although there is an 

internal limitation of 1,500 vehicles per minute, so the absolute maximum for one entry 

node is 90,000 vehicles per hour. 

Q: Overall vehicular demand in the network is such that queues from downstream 

intersections are blocking upstream intersections. This is having the effect that traffic 

cannot cross from the side streets and network-wide gridlock quickly occurs as the 

queues build back to subsequent intersections. In reality, the city has implemented a 

"Do Not Enter" policy, where traffic is supposed to wait until vehicles clear the 
279 

intersection before they proceed. Is it possible to include the "Do Not Enter" condition 

in the model? 

A: In TRAFED, you can select Network > NETSIM Setup > Spillback, to calibrate the 

probability of vehicles becoming or joining spillback. For the scenario where no 

vehicles will block an intersection, enter values of “0” for all spillback parameters, 

meaning that there will be zero probability that a vehicle will join the back of a queue 

and block an intersection. 

Q: What causes fatal errors 6197 and 6198? 

A: Fatal error messages 6197 and 6198 are often caused by a missing record type 25. Offramps are defined by record type 25. For the freeway mainline link, record type 25 

must be coded to indicate which node receives off-ramp traffic. Without record type 

25, CORSIM cannot locate the off-ramp destination node. When all of the necessary 

record type 25s are entered, this allows the origin-destination inputs on record type 74 

to function properly. These errors can also be caused by specifying a destination node 

that is not the upstream node of a mainline exit link or the upstream node of the first 

link of an off-ramp. 

Q: What causes the error message that says: “A fatal error was detected in the leaderfollower chain.” 

A: There are multiple possibilities for the leader-follower error. One possibility is that the 

network geometry involves a cloverleaf where a vehicle, in searching for a leader, 

follows a path that leads to itself as its leader. There is a work around that involves 

breaking the path so that a vehicle will not find itself as its leader. One way to 

accomplish this is to break the loop by adding a small NETSIM link in one of the loops 

of the cloverleaf. Another solution is to break one of the full auxiliary lanes between 

connectors into an acceleration lane followed by a deceleration lane with at least on 

foot separation between the two. The NETSIM link solution is probably the cleaner of 

the two because you can maintain the cloverleaf geometry better. This problem is 

more likely to occur with networks that have very few vehicles but can occur in any 

network that has a continuous cloverleaf. 

Another possible reason for this error is due to short link lengths, which can cause a 

corruption in the leader-follower chain. When the link is short enough, and the freeflow speed is high enough, it becomes possible for a vehicle to completely jump over 

the short link during a one-second time step. When this occurs, CORSIM's vehicle 

processing logic completely breaks down, and the result is usually leader-follower 

errors. Beginning with TSIS/CORSIM version 5.0, CORSIM sends red-colored 

warning messages to the TSIS output window when it detects links that are short 

enough to cause modeling problems. 

Correcting link free-flow speeds can also solve the leader-follower error. FRESIM links 

connected to an interface node should have the same free-flow speed as NETSIM links 

on the opposite side. 

A problem with the leader-follower chain can also be caused by a 2.0 second lane 
280 

change interval and lane drop that has a warning sign only one foot upstream of the 

lane drop. The warning sign location should always be far enough upstream so that 

vehicles can stop before reaching the lane drop if they cannot make a lane change. 

Vehicles reach the end of the lane and then other vehicles behind them pile up onto 

them. Somewhere in that pile up, the leader-follower chain gets corrupted. 

Q: How can I force more vehicles to use the outer lane (left most or right most) in 

NETSIM? 

A: There are a few things you can try in order to better control vehicle paths or lane 

utilization in NETSIM: 

• Channelization codes. NETSIM can be calibrated to produce the correct lane 

utilization by using special channelization codes. In order for this to work, it is 

necessary to select a channelization code for a turn movement (usually diagonal) 

that does not exist. Just apply the diagonal channelization code to a particular lane, 

assign a percentage of turns to that diagonal movement, and then specify the 

correct left-turn, through, or right-turn receiving node for that diagonal movement. 

• Turning movements that feed the downstream through node, sometimes used in 

conjunction with a dummy node. This is a coding technique that encourages a 

certain percentage of vehicles to move into the outer most lanes. 

• Conditional turning movements. This input specification prevents vehicles from 

making consecutive unrealistic turn movements. 

• Driver familiarity with path distribution. By default 90 percent of drivers know 

their "goal lane", so some users change this to 100 percent so that drivers will make 

better decisions in advance. 

• Interchanges. Origin-destination data may be specified at interchanges and 

NETSIM determines the paths through the interchange and assigns vehicles to 

those paths accordingly. 

• Driver cooperation. The percentage of cooperative drivers can be increased. The 

default is 50 percent. 

Q: Is it possible to specify freeway capacity per lane in FRESIM? 

A: Although there is no explicit input parameter for freeway capacity, the inputs that can 

potentially affect freeway capacity in FRESIM include: Global or link-specific car 

following sensitivity factor, threshold speed and distance for anticipatory lane 

changing, minimum separation for vehicle generation, vehicle lengths, free-flow speed 

distribution, off-ramp warning sign distance, ramp and freeway number of lanes, 

acceleration/deceleration lane length, heavy vehicle percentages, off-ramp exit volume 

fractions, origin-destination volume fractions, simulated incidents, and queue spillback 

from arterial street signalized intersections. Refer to chapter 5 for more specific 

information on calibrating the capacity of freeway bottlenecks. 
281 

Q: What does "Network Did Not Reach Equilibrium" mean? 

A: CORSIM networks contain no vehicles at the beginning of a run. As the first seconds 

are simulated, vehicles are emitted onto the network from entry and source nodes. The 

time required to fill the network with traffic is referred to as the initialization period. 

Because the initialization period does not accurately represent the conditions to be 

modeled, no statistics are gathered during this period. A check is made at the end of 

every time interval for equilibrium. Equilibrium is assumed when the number of 

vehicles in the network is within eight percent of the number of vehicles in the network 

during the previous time interval, and within 12 percent of the number of vehicles in 

the network during the second previous time interval. In the CORSIM output file, this 

information is reported in the section called "Initialization Statistics". Refer to 

appendix C for more information on the initialization period and reaching equilibrium. 

Q: Is there a way to input the volumes of weaving and non-weaving vehicles between an 

on-ramp and an off-ramp? 

A: This can be done by specifying origin-destination information. The user can specify an 

origin node and the percentage of vehicles that will exit at each destination node that 

can be reached from that origin. Be careful in doing this, as this input overrides the 

coded off-ramp exiting vehicle fractions. 

Q: How can I model a major merge or diverge of freeways? 

A: If a freeway branch is defined, the existing convention calls for one branch to be 

defined as the mainline, and for the other to be defined as the ramp. Therefore, major 

merge or diverge sections must usually be modeled by defining "dummy" interface 

nodes and NETSIM links between the freeway sections. If a dummy upstream 

mainline section is coded, NETSIM links may not be needed. 

Q: How can I model a simple highway-to-highway connection? 

A: Highways can be directly connected using FRESIM ramp links. For a simple highwayto-highway connection, an off-ramp from the first highway may connect to an on-ramp 

onto the next highway. However, there are limitations that sometimes require the use 

of NETSIM links. When using FRESIM only, it is not possible to have a ramp that 

splits into two ramps, and it is not possible to have two ramps that merge into one. 

Q: What causes fatal error 6500 (e.g., “Link (32, 369) defined on RT 19 does not belong to 

any disjoint freeway segment.”)? 

A: Fatal error 6500 is usually related to incorrectly specifying the link type (i.e., ramp 

versus mainline) or specifying invalid freeway segments. Valid segments begin at an 

entry or entry interface node and end at an exit or exit interface node. There must be a 

continuous sequence of mainline links between the beginning and the end of the 

segment. 

Q: How do I prevent vehicles that have just exited the freeway from immediately reentering the freeway? Specification of turning movement percentages does not 

prevent this behavior. 
282 

A: Use conditional turning movements. In TRAFED, simply right-click on the affected 

intersection and in the "Intersection Properties" dialog box click on "Conditional 

Turning Movements." Specify the conditional turn percentages for the approaches to 

the intersection such that vehicles that came from the freeway do not turn toward the 

freeway entrance. 

Output Processor 

Q: I selected MOEs in the Output Processor and specified the “MS Excel” file format. 

Where is the Excel file located? 

A: The file containing the results from the Output Processor will be located in the same 

folder as the network input file. If you have configured a tool that opens files with the 

.xls extension, the Excel file will be shown in the Project View. The name of the file 

will depend on the Data Granularity that you selected. If your input network is named 

“network.trf”, then the possible Excel file names will be “network_cumulative.xls,” 

“network_interval.xls,” and “network_time_period.xls.” 

Q: How is the Output Processor in TSIS/CORSIM version 6.0 different than the one 

introduced in version 5.1? 

A: The Output Processor was introduced as a proof of concept in version 5.1. It proved to 

be a very useful tool, but was limited in its capabilities. It was redesigned for version 

6.0 so that all MOEs computed by CORSIM could be accessed and, in addition, those 

MOEs could be accumulated by time step, time interval, or time period, or any 

combination of those. Specific information is given in the CORSIM User’s Guide(1) in 

the section titled “Configuring and Running CORSIM.” 

TRAFVU 

Q: Can I use a bitmap background? 

A: Yes. That capability was added in TSIS/CORSIM version 5.1. 

Q: How do I make a link curved? 

A: TRAFVU uses the link curvature entry 4 on Record Type 196 to determine the 

curvature of all links. This can be set in TRAFED on the link’s property dialog on the 

“Graphics” page. The amount of curvature will depend on the length of the link and 

location of the nodes. 

Q: Why is my link curved at the ends when I set the link to be straight? 

A: When two through links join at a node, TRAFVU tries to make them tangent at the 

node even if they are straight links. You may get a small curve drawn so that they line 

up correctly at the node. You can control the amount of curvature that is allowed for 

drawing purposes for individual links with a parameter on Record Type 196. 

Q: Why do some vehicles overlap in queue? 

A: Most likely the length of the link as drawn by TRAFVU is shorter than the link length 

input for the link. You can check this by right-clicking on the link and selecting the 
283 

Geometric Data item while in TRAFVU. Both the TRAFVU calculated length and the 

input length are displayed. Remember that the link length is measured from upstream 

stop bar to downstream stop bar, not from node-to-node. There can be quite a 

discrepancy between those two distances when the upstream and downstream 

intersections are not similar. This is not only a drawing issue but can affect your link 

storage if not corrected. CORSIM uses the link length from Record Type 11 when 

determining how many vehicles can be on the link, not the node-to-node distance. 

Q: Why do some vehicles in queue have a large gap between them? 

A: Most likely, the length of the link as drawn by TRAFVU is longer than the link length 

input for the link. You can check this by right-clicking on the link and selecting the 

Geometric Data item while in TRAFVU. Both the TRAFVU calculated length and the 

input length are displayed. Remember that the link length is from upstream stop bar 

to downstream stop bar, not from node-to-node. There can be quite a discrepancy 

between those two distances when the upstream and downstream intersections are not 

similar. This is not only a drawing issue but can affect your link storage if not 

corrected. CORSIM uses the link length from Record Type 11 when determining how 

many vehicles can be on the link, not the node-to-node distance. 

Q: Why do some vehicles overlap during lane changing? 

A: CORSIM uses a grace period when making a lane change so that vehicles can make 

their way into the new lane. CORSIM allows vehicles to overlap during this grace 

period. TRAFVU places the vehicles in the lane and at the distance along the link 

where CORSIM dictates. 

Q: Why do some left turning vehicles “Crash” into opposing left turners in the middle of 

an intersection? 

A: TRAFVU draws simple curved paths from the end of one link to start of the next link. 

If the size of the intersection is not very big, these paths can overlap. In real life, 

drivers would adjust their path to avoid this collision. 

Q: How can I see the node numbers in TRAFVU? 

A: Hold the shift key down when you click on a node to display all the node numbers for 

the nodes in view. 

Q: Can I change the background color of TRAFVU? 

A: Yes, this can be done through the Options > Window menu item, which displays the 

“Preferences” dialog for the selected window. The “Background” page allows you to 

change the color of the background. Changing the background color can be helpful 

when printing or comparing two test cases. 

Q: How can I save an image of the TRAFVU display? 

A: You can hit the “Print Screen” button on your keyboard, which copies the image 

currently displayed on the screen to the Windows clipboard. You can then paste the 
284 

image in a graphics program like Microsoft Paint. Holding the “Alt” key down while 

hitting the Print Screen button will copy only the window with focus. 

Q: Where is the link length measured? 

A: TRAFVU uses the left curb length from upstream stop bar to downstream stop bar for 

its “calculated length”. 

Q: Why do I get a CORSIM warning if I use TRAFVU’s “calculated length” as the link 

length? 

A: CORSIM uses simple geometry to take the difference between the upstream and 

downstream nodes to do a “reality” check on the link length. CORSIM does not report 

the actual stop bar to stop bar distance that it should use for this check. TRAFVU 

reports the correct distance in most cases. 

Q: The bitmap background image is not visible within TRAFVU. Is there any size 

limitation for the bitmap background file? 

A: Yes. Bitmaps are stored on disk differently depending on the type of bitmap. 24-bit 

color bitmaps use 3 bytes per pixel, 256 color bitmaps use 1 byte per pixel, 16 color 

bitmaps use 2 pixels per byte, and black and white bitmaps use 8 pixels per byte. So 

the size of the file can change dramatically based on the type of bitmap. Depending on 

the image that is trying to be loaded and the purpose of the image, reducing a 24-bit 

color image to a 256 color image could buy a lot better resolution. Orienting the image 

so the longer direction is vertical could allow a bigger bitmap than orienting it 

horizontally. 

Q: Why does there appear to be an abnormal spacing of vehicles on certain links, or, why 

do vehicles appear to be stacking on top of one another on certain links? 

A: This usually indicates a mismatch between the link length input to CORSIM (which is 

the distance from the upstream stop bar to the downstream stop bar) and the link 

length calculated by TRAFVU (which uses node coordinates and the location of other 

links to determine where the stop bars are located). This mismatch forces TRAFVU to 

stretch or compress the link, in order to be consistent with the node coordinates. 

 TRAFVU draws vehicles according to their length without compressing or stretching 

them, so sometimes it appears that the vehicles are farther apart, and sometimes it 

appears that they are overlapping each other. 

The solution is to enter consistent link lengths and node coordinates. TRAFVU locates 

the node at the point where the left curbs intersect. The locations of the stop bars are 

then determined by considering the way the links connect and the number of lanes on 

the links. Read section 3.3.2 in the TRAFVU User's Guide(19) for more details. 

The node-to-node distance is not necessarily equal to the link length. The link length is 

the stop bar to stop bar distance. The intersection width needs to be added to the 

node-to-node distance. Select the link in TRAFVU and right click the mouse. Select 

Geometric Data, and compare "TRAFVU calculated length" to "length". Those 
285 

numbers should be the same, or nearly the same. If they are different, take the 

TRAFVU calculated length and use it as the link length. 

TRAFED 

Q: Can I use a scaled bitmap as a background for my network? 

A: Yes, an aerial photo, map, or drawing can be used as tool to layout a network. By 

scaling the bitmap correctly, links and nodes can be drawn on top of the bitmap. Using 

this method, you can quickly layout a large network. The bitmap can be scaled and the 

position adjusted in TRAFED. TRAFED is not a bitmap editor however. If you need to 

rotate or edit the bitmap you will need to edit it with a different program. 

Q: How do I put in an entry or exit node? 

A: You cannot explicitly put in an entry or exit node in TRAFED. These 8000 nodes are 

created when you drag out a link to a location that does not currently have a node 

(“green space”). The entry nodes are represented by a ‘+’ (plus) sign and exit nodes 

are represented by a ‘-‘ (minus) sign. If you start dragging a link from an existing 

entry/exit node, it will be changed into an internal node that connects the two links. 

You can drag out an entire network without ever placing nodes! 

Q: How do I put in an interface node? 

A: You cannot explicitly create an interface node. Interface nodes and interface links are 

created automatically by TRAFED when you drag a link from one type of network to 

another type of network. For example, drag a one-way link from a surface node to a 

freeway node and you will get a surface interface link, an interface node, a freeway 

interface link, a required freeway dummy node, and another freeway ramp link 

between the two original nodes. 

Q: How do I create links of a different type? 

A: The “Default Link Type” menu item on the “Network” menu controls the default link 

type that is dragged out by using the One-Way Link or the Two-Way Link tools. 

However, when you drag out a link from an existing node or to an existing node, the 

link that is created will be of the type of node, no matter what the default link type is 

set to. For example, dragging a link from a Freeway node will create a freeway link 

even if the default link type is set to surface street. 

Q: Why does TRAFED use a TNO file instead of a TRF file? 

A: The TNO file is arranged so that all the similar data is stored together and written in 

XML format. The data can be in a variety of different formats and is not restricted by 

the 80-column punch card format of the TRF file. Because the XML format requires 

individual pieces of data to be tagged, the data can be added, subtracted, changed, or 

moved without causing problems between versions. The TNO file also contains 

additional data that the simulation does not use, like the name of the bitmap 

background file. 

Q: Can TRAFED create a TRF file automatically? 
286 

A: Yes, the “TRF File Generation” tab on the “Preferences” dialog (located on the 

“Network” menu item) controls the automatic creation of a TRF file when you save the 

TNO file. This a user preference so you can turn this behavior off during a network’s 

initial creation stages and then back on when only minor adjustments are being made. 

Q: What is the difference between the “Translator” tool and the “Export” menu? 

A: The translator is a stand-alone program that will translate TNO format data into TRF 

format data and visa versa. It has to load the data from the files first before it does the 

translation. Exporting is done from within TRAFED and only exports out to TRF 

format. Because it uses the data that is currently loaded in TRAFED, it is much faster 

than translating the data. They both use the same underlying code so the result is the 

same. 

Q: Can I enlarge the drawing area while I am creating a network with TRAFED? 

A: Yes, TRAFED can toggle between full screen mode and regular mode by hitting the 

“F2” key. This allows TRAFED to be the full size of the screen for maximum editing 

area. Pressing “F2” again will return TRAFED to it normal place inside of TShell. 

Q: Where should I place my nodes? 

A: For the most part you should place your surface street nodes at the left curb for nonintersection nodes or at the extension of the left curb for nodes in the center of an 

intersection. For freeway links, place the node at the left edge of the mainline link. 

For example, a four-way intersection with four approaches and four departures of the 

same number of lanes, the node will be in the center of the intersection. For an 

intersection of two one-way streets, the node will be located at the crossing point of the 

left curbs (not in the center of the intersection). If the user moves the node location, the 

intersection and connected links will also move to reflect the change. One example of 

when the left curb rule is not true is when there is a link that merges with another link 

(e.g., on-ramp). The link to the right will not have its left curb over the node. The left 

curb will be placed where it needs to align properly. These same rules apply in the 

FRESIM and NETSIM subnetworks. 

The node coordinate is only used in CORSIM to get the node-to-node distance as a 

preliminary check of a link's length. CORSIM does not use it for any other purpose, as 

it is used purely for graphical display purposes in TRAFED and TRAFVU. 

Q: Why does the software sometimes say "Parse Error: not well-formed"? 

A: There is a known problem concerning non-standard characters. The XML parser that 

TRAFED uses can only process the standard character set, which includes all ASCII 

codes less than or equal to 127. The extended character set, which includes all ASCII 

codes greater than 127, is not supported. For example, when the problem is caused by 

an input file that contains the special character “û”, replacing it with a standard “u” 

eliminates the problem. 
287 

Appendix J: Converting Between Systems of 

Actuated Control Parameters 

Most modern controllers use the cycle length, split, and offset (CSO) parameter system for 

specifying the actuated controller parameters that govern coordination. TRAFED uses the 

CSO system in its actuated controller dialogs. However, the CORSIM actuated control 

model uses cycle length, force-off, and yield point parameters rather than the CSO system. 

TRAFED automatically converts the CSO parameters to the parameters used by CORSIM 

in a process that is transparent to the analyst. However, for those who are interested in the 

process, the following discussion provides the mathematical details of the conversion 

process. 

The discussion is based on an eight-phase, dual-ring actuated controller that is part of a 

progressive system of controllers. The intersection is phased in a quad left sequence as 

illustrated in Figure 94. 

Figure 94. Diagram. Intersection phased in a quad left sequence. 

Assume the controller is presently displaying green for the coordinated phases 2 and 6 

(also noted as Ø 2/6). For ease of calculation, also assume leading dual left turn phasing, 

that the background cycle length is 100 seconds, the offset is 10 seconds (measured to the 

beginning of phase 2 and 6 green) and the splits are Ø1 and 5 = 10 sec, Ø2 and 6 = 40 sec, 
288 

Ø3 and 7 = 15 sec, Ø4 and 8 = 35 sec. The respective vehicle clearance and minimum green 

times for the even number phases are 5 and 7 seconds and 4 and 4 seconds for the odd 

numbered phases. Clearance times include the yellow change interval and red clearance 

durations. Finally, assume the controller has progressed to the end of the coordinated 

phase, which (in CORSIM) is the yield point and the beginning of local controller time t = 

0. 

Converting NEMA Offset to Yield Point 

In the example, as in most NEMA controllers, the offset is measured from the beginning of 

the system reference point, system T = 0, to the beginning of the coordinated phase green. 

In CORSIM, the offset value is measured from system T = 0 to the end of the coordinated 

phase green, i.e., the yield point. To translate the NEMA offset to the CORSIM yield point 

the following formula is used: 

Figure 95. Formula. CORSIM yield point. 

The yield point cannot be larger than the cycle length or less than zero. If the calculation 

produces a value outside this range, the cycle length must be subtracted from the 

calculated value or, in the case of negative values, the computed value must be subtracted 

from the cycle length to produce a number within the appropriate range. Figure 96 

presents a graphical illustration of the offset conversion. 
289 

Figure 96. Diagram. NETSIM offset versus NEMA offset. 

Converting Splits to Force-Off Values 

Each non-coordinated phase has an associated force-off point. This is the point in the cycle 

where service for that phase must terminate to allow time in the cycle to service other noncoordinated phases and guarantee the return to the coordinated phases at the proper time 

in the cycle to maintain progression. 

The force-off points are at the end of the phase extension green or if there is a pedestrian 

interval at the end of walk. Figure 97 illustrates the force-off points. Figure 98 shows how 

the force-off points are calculated from the split and clearance times. 
290 

Figure 97. Diagram. Signal coordination parameters. 

Figure 98. Equations. Force off calculations. 

In the example, each pair of compatible phases (3 and 7, 4 and 8, 1 and 5) has identical 

force-off times. However, it is possible and common that compatible phases may have 

different force-off times. A lead-lag signal operation is a good example of this condition. 

However, the logic used in calculating force-off times can be applied to any phasing and 

timing scheme. 
291 

Computing Permissive Periods 

There are several methods of assigning the phases that allowed to be serviced to 

permissive periods. When analyzing an operating controller, the method used should be 

determined and programmed into the CORSIM data set. Generally, this information is not 

easily obtained from controller displays and is typically programmed as a default 

condition chosen by the manufacturer. The best source for this information would be the 

local signal operations and maintenance personnel. If there is still doubt about how the 

phases are assigned, the following example seems to be fairly common practice. 

In order for each signal phase to be serviced and the controller to return to the coordinated 

phase(s) at the designated time in the cycle, individual phases can only be allowed service 

during specific periods within the cycle and for specific duration. Permissive periods 

control when and over what time duration the controller is allowed to service noncoordinated phases. CORSIM allows up to three permissive periods to be specified as 

shown graphically in Figure 97. 

In the example, the permissive periods will allow servicing of phases in order according to 

Table 44. 

Table 44. Permissive periods. 

Permissive 

Period 

Associated Phases 

(Service Allowed) 

1 Ø 3/7, Ø 4/8, Ø 1/5 

2 Ø 4/8, Ø 1/5 

3 Ø 1/5 

The permissive strategy presented in the table allows service to all non-coordinated phases 

during the first permissive period and is more restrictive during subsequent periods until 

the final period when service is allowed only to the phase that immediately precedes the 

coordinated phase. This assures that the coordinated phase will be serviced at its proper 

time in the background cycle. While this permissive strategy seems to be the most 

common, it does have one problem. If while in Permissive Period 1, a slight gap in traffic 

occurs on phases 3/7 and there is a call on 4/8, Phases 3/7 will be skipped and must wait 

for the next cycle to be serviced. An alternative to the above strategy, and one employed 

as the default by at least one major manufacturer, would be to only allow phases 3/7 to be 

serviced during Permissive Period 1, phases 4/7 during Permissive Period 2, and phases 

1/5 during Permissive Period 3. This alternative strategy also allows the coordinated 

phase green to be extended into the normal time for phase 3/7 if there is no demand on 

those phases. This may be an advantage if the system green band width is limited by the 

end of the coordinated phase green. 
292 

The following paragraphs illustrate how to compute the permissive periods for the 

example using the strategy shown in the table above. In CORSIM, the times that specify 

permissive periods are relative to the yield point. 

Permissive Period 1: In CORSIM, the start of Permissive Period 1 is always at the yield 

point and will always have the value of zero. The end of Permissive Period 1 will be at the 

point in the cycle where there is still sufficient time remaining to service the minimum 

green or pedestrian timing (whichever is greater) and all vehicle clearances. Thus, the end 

time for Permissive Period 1 is calculated as follows: 

Figure 99. Equation. Permissive period 1. 

Permissive Period 2: The start of Permissive Period 2 for the next non-coordinated phase 

will be at the force-off time for the proceeding phase. In the example, the beginning of 

Permissive Period 2 is at the force-off time for phases 3/7 or 16 seconds (see force-off 

calculations above). The end time for Permissive Period 2 is calculated as follows: 

Figure 100. Equation. Permissive period 2. 

The end of Permissive Period 2 can also be calculated using the previously calculated 

force-off times for phases 4/8, as follows: 

Figure 101. Equation. Permissive period 2 (recalculated). 

Permissive Period 3: The start of Permissive Period 3 is the force-off time for the 

proceeding phase or Ø 4/8, which is 50 seconds (see force-off calculations above). The end 

time for Permissive Period 3 is calculated as follows: 
293 

Figure 102. Equation. Permissive period 3. 

The end of Permissive Period 3 can also be calculated using the previously calculated 

force-off times for phases 1/5, as follows: 

Figure 103. Equation. Permissive period 3 (recalculated). 

Once a non-coordinated phase has received service from any permissive period, the 

remaining permissive periods in the cycle are omitted and the controller operates normally 

until the beginning of the next cycle when all permissive periods are again activated. 

295 

Appendix K: Coding Techniques for Complex 

Situations 

This appendix briefly explains how to model some complex situations or applications in 

CORSIM. Some of the techniques presented in this appendix are methods to work around 

limitations in CORISM. This discussion is prefaced with a caution that other tools may be better 

suited for modeling a given complex situation.

Roundabouts 

CORSIM does not explicitly model roundabout movements; however, it is possible to 

indirectly model a roundabout movement. There may be some scenarios where a 

roundabout needs to be modeled to match the operation of the real world. Use of this 

capability is not recommended if the purpose of the analysis is directly affected by the 

roundabout operation. For example, if an intersection adjacent to the roadway being 

modeled is designed as a roundabout, it may be possible to model that intersection as a 

roundabout without jeopardizing the main objectives of the analysis. 

A problem CORSIM has in modeling a roundabout is that the minimum length of a link is 

15.2 m (50 ft), and the link length by definition includes the upstream intersection in the 

length. These two conditions cause problems in modeling a roundabout due to the short 

link sections necessary for a roundabout. Very small roundabouts may be impossible to 

model and animate. Short links are also difficult to curve into a realistic looking 

roundabout. 

Figure 104 shows a roundabout displayed in TRAFVU. For this roundabout, nodes were 

placed at each roundabout approach, and yield signs were placed at the approaches. 

Within the roundabout, short links were coded to connect the nodes at the approaches. As 

shown, it is possible to create a roundabout in CORSIM; however, the performance of the 

model should be carefully calibrated with real-world data to ensure that the model 

represents a reasonable match with real-world conditions. 
296 

Figure 104. Illustration. Roundabout example in TRAFVU. 

Ramp to Ramp Splits 

When coding freeway ramps, existing FRESIM convention calls for one branch to be 

defined as the freeway mainline and the other to be the ramp. This causes problems when 

modeling freeway-to-freeway ramps. Another limitation with freeway ramps is that 

FRESIM does not allow a ramp to be further split into two ramps, which an analyst may 

want to code when two freeways have ramps that merge onto the same ramp. There are a 

couple of possible workarounds to these ramp to ramp limitations. 

One workaround is to separate the ramp links with “dummy” freeway mainline sections. 

To do this, create small freeway segments that have dummy entry nodes with no volume. 

This allows ramp segments to merge and diverge from the dummy freeway segment. 

Figure 105 shows the dummy freeway sections that connect the ramp links highlighted in 

red (or darker link). 
297 

Figure 105. Illustration. Dummy freeway sections. 

Another workaround is to use surface street (NETSIM) sections to separate ramp links. 

The problem with this approach is the car-following on the surface street sections is 

different than on the freeway/ramp sections. Vehicles will slow down to create a larger 

headway than is on the freeway section. Figure 106 shows a surface street section inserted 

in a freeway interchange to allow merging of ramp lanes. 

Figure 106. Illustration. Surface street section. 

Dummy freeway sections. 

Surface street section. 
298 

U-turns 

CORSIM does not explicitly model U-turn movements. It is possible to indirectly model a 

U-turn movement. There may be some scenarios where a U-turn needs to be modeled to 

match the operation of the real world. Use of this capability is not recommended if the 

purpose of the analysis is directly affected by the U-turn operation. By assigning the 

downstream node of a link’s left-turn or left-diagonal movement to the link’s upstream 

node, a U-turn will be created. Use the turn lane alignments to allow the U-turn vehicles 

to make a wider turn than they would without the alignments. 

Figure 107 shows an example of a left-diagonal movement used as a U-turn movement. 

There are two problems to consider when modeling a U-turn. Vehicles using a leftdiagonal movement will turn at a higher speed than a left-turn movement due to left-turn 

speed restrictions. These speeds may over estimate the ability of a vehicle to make a Uturn. Secondly, the left-turn movement is used to check for spillback that could block the 

through movement. Using the left-turn movement to model the U-turn movement can 

cause delays on the through movement. If either of these problems affects the analysis 

being conducted, use a different simulation model that models U-turns correctly. 

Figure 107. Illustration. U-turn example. 

Downstream 

node of U-turn 

movement 
299 

Continuous Left Turn (crossing an intersection) 

Left turn lanes that extend across an intersection can be modeled in CORSIM. This 

provides storage for vehicles in spillback from the left turn. It also allows the model to 

position the vehicles for their upcoming turn. CORSIM permits assigning both a turn 

movement and a through movement to have the same downstream node. In Figure 108, 

the westbound approach link has two through lanes and a left-diagonal lane that all have 

the same downstream node. Using a left-diagonal movement has a couple advantages 

over using a left-turn movement. Vehicles making a left diagonal are not forced to slow 

down to the left turning speed as they discharge, therefore they do not cause delay on the 

link. Left diagonal movements also can be isolated from the other left-turn movement 

when assigning conditional turn movements. Therefore, 100 percent of the vehicles that 

enter the downstream link from a left-diagonal movement can be assigned a left-turn 

movement. Vehicles that enter the downstream link from a through movement must also 

be assigned as 100 percent traveling through and zero percent allowed to turn left. 

Otherwise, a percentage of the through vehicles will try to turn left. 

Figure 108. Illustration. Continuous left turn. 

Two Intersections with Two Controllers Acting as One 

When two intersections are in close proximity, as in a diamond interchange or an 

intersection with offset streets, the signals at both intersections are often controlled by a 

single controller. Although the actuated control model in CORSIM does not provide for 

this type of control explicitly, two controllers can be configured to emulate the control of 

both intersections by a single controller. 

To model this type of operation, the “additional links” feature of the CORSIM actuated 

control model must be employed to specify detectors on streets that are not direct 

approaches to an intersection. Specifically, the detectors that are placed on the direct 

Left-turn 

extends across 

intersection 
300 

approaches to one intersection are duplicated on those same links, which serve as indirect 

approaches to the second intersection, and vice versa. 

Furthermore, the same number of phases must be used for both intersections, and the 

same timing values must be specified for the identically numbered phases in each 

controller. However, the movements defined for the identically numbered phases in each 

intersection will be slightly different and will depend on the type of intersection and 

phasing being modeled. Although complex phasing schemes can be modeled using this 

approach, a simple example is provided to demonstrate this modeling technique. 

Figure 109 illustrates a diamond interchange serving an east-west freeway. The 

movements on the north intersection that serve the westbound off-ramp traffic will be 

specified concurrent with the movements on the south intersection that serve the 

eastbound off-ramp traffic. Left turns on the streets between the intersections that allow 

traffic onto the freeway will be specified as protected and concurrent with each other. 

After the protected left turns are served, the north-south movements at both intersections 

are run concurrently and with permitted left turns. The actuated controller ring diagram 

is displayed for each intersection in the figure. 

Figure 109. Illustration. Two controllers act as one controller to control two intersections.

Node 10 

Link (11, 10) 

Link (17, 10) 

Node 11 

Link (10, 11) 

Link (19, 11) 

1 2 3 4 

1 2 3 4 
301 

North Intersection (Node 11) 

The phases for the north intersection are configured as illustrated in the ring diagram in 

the figure. Detectors are placed in the through and left-turn lanes of link (19, 11) and are 

configured to call phase 2. A detector is placed in the left-turn lane of link (10, 11) and is 

configured to call phase 3. 

Links (11, 10) and (17, 10) are specified as additional (indirect) links to the intersection. A 

detector is placed in the left turn lane of indirect link (11, 10) and is configured to call 

phase 3 of the controller. Detectors, placed in the left and through lanes of link (17, 10), are 

configured to call phase 2 of the controller. 

South Intersection (Node 10) 

The phases for the south intersection are configured as illustrated in the ring diagram in 

the figure. Detectors are placed in the through and left-turn lanes of link (17, 10) and are 

configured to call phase 2. A detector is placed in the left-turn lane of link (11, 10) and is 

configured to call phase 3. 

Links (10, 11) and (19, 11) are specified as additional (indirect) links to the intersection. A 

detector is placed in the left turn lane of indirect link (10, 11) and is configured to call 

phase 3 of the controller. Detectors, placed in the left and through lanes of link (19, 11), are 

configured to call phase 2 of the controller. 

Finally, the timing parameters for the phases in the south intersection should be specified 

to be the same as the timing parameters for the corresponding phases in the north 

intersection. In the example, phase 4 in each intersection is placed on max recall because 

no detection was specified for that phase. 

Mid-block Actuated Pedestrian Crosswalk 

Using the pedestrian generator that is built into the actuated control functionality of 

CORSIM, it is possible to create a mid-block pedestrian crosswalk. Figure 110 shows a 

sample mid-block pedestrian crossing. No vehicle detectors are necessary. The main 

street phases should use recall in lieu of detectors. Calls to the controller are generated by 

the model to simulate a pedestrian pushing the pedestrian call button. 
302 

Figure 110. Illustration. Mid-block pedestrian actuated crossing. 

CORSIM does not have the ability to simulate an exclusive pedestrian phase using the 

phase 9 method as provided by many controller manufacturers. However, in a limited 

number of situations where there are unused phases in the controller, the user may be able 

to employ one of those phases as an exclusive pedestrian phase. In this case, the user can 

place a node with actuated control at the location of the pedestrian crossing signal. The 

vehicle through movements can be coded as phase 1, and phase 2 can be coded as the 

exclusive pedestrian phase as shown in Figure 111. There are other possible 

configurations, but the user is cautioned to be careful when coding an unused phase as an 

exclusive pedestrian phase because the phase may be concurrent with a phase in the 

opposite ring. 
303 

Figure 111. Illustration. Actuated control dialog for a mid-block pedestrian phase. 

Reversible Freeway Lanes 

In the real world, reversible lanes are the same lanes that vehicles travel on in both 

directions at different times of the day. In CORSIM, links can only be coded for a single 

direction, not bi-directional. In other words, vehicles cannot travel both directions on a 

link. In order to model a reversible freeway lane for express lanes or directional HOV 

lanes, each direction must be modeled separately using dummy freeway segments. By 

controlling the volume that enters the reversible lane in different time periods, it is 

possible to model reversible freeway lanes as shown in Figure 112. In this example, the 

analyst uses time period one to model the a.m. peak when the eastbound vehicles use the 

reversible lanes, time period two to model the off-peak period when no vehicles can access 

the reversible lanes, and time period three to model the p.m. peak when the westbound 

vehicles use the reversible lanes. 

Alternatively, you can model the direction of flow in separate files, such as an a.m. period 

in one file and a p.m. period in a separate file. In this case, it is possible to overlap the 

reversible lanes and control which direction is visible by changing which links underpass 

the other links in the specific file. 

Use the 

Pedestrian 

Generator 

Phase 2 is 

exclusive 

Pedestrian 
304 

Figure 112. Illustration. Reversible freeway lane example. 

Eastbound uses reversible lanes in 

time period one only 

Westbound uses reversible lanes in 

time period three only 
305 

Appendix L: Run-Time Extension Overview 

TSIS provides a mechanism by which an external application can interface directly with 

the CORSIM simulation tool. This type of application has become known as a CORSIM 

run-time extension (RTE). The original RTEs were tailored for signal timing studies. 

However, the concept has been expanded to support freeway monitoring, incident 

detection, and ramp metering. 

The RTE capability enables CORSIM to operate with actual hardware in the loop. Some 

examples of these hardware-in-the-loop experiments include using 170, NEMA, and 2070 

controllers to control the signal states at certain intersections in the simulation. In these 

experiments, the controller is interfaced to the simulation using a Controller Interface 

Device (CID) that connects to the serial interface of the computer that hosts the simulation. 

Another experiment involved using an advanced camera sensor and image processing 

software to estimate the queue state of simulated vehicles as they approach an intersection. 

The queue states for the approaches to the intersection are used by an adaptive control 

algorithm to make intelligent decisions about what the optimal signal state should be. 

RTEs can also be used to test adaptive signal control algorithms for effectiveness before 

they are implemented in the field. With the rapid evolution of technology, these types of 

experiments are necessary, not only to assess the benefits of advanced ITS applications, but 

to verify their operational capability before field deployment. 

The Run-Time Extension Interface 

Figure 113 illustrates the operation of CORSIM within the TSIS 6.0 architecture including 

the interfaces that support the operation of RTEs. In the figure, the block arrows represent 

Component Object Model (COM) interfaces and the thin arrows represent standard 

dynamic-link library (DLL) interfaces. In this model, the CORSIM Driver Component is 

the TSIS tool that runs the CORSIM simulation and interfaces to the TShell user interface. 

This component enables the user to control CORSIM execution and output processing, and 

manages all user-supplied RTE. Although the entire CORSIM architecture is shown for 

completeness, the RTE interfaces are marked 1, 2, 3, and 4 in the diagram. 
306 

TShell CORSIM

Driver

Component

CORSIM

Server

CORSIM

Exported

Memory

Exported

Functions

CORWin

Interface

TSD / TID

Interface

CORSIM

Property

Pages

Files

RTE

1

2

3

4

Figure 113. Diagram. TSIS architecture. 

For each simulation time step, the CORSIM Server calls a series of functions within 

CORSIM to drive the simulation event loop. When an RTE is present and enabled, the 

CORSIM Server also calls the exported functions of the RTE based on messages it receives 

from CORSIM at different points in the CORSIM execution timeline. The server also calls 

the RTE's initialization function during CORSIM initialization and the RTE's exit function 

at the end of the simulation. This interface is illustrated in the figure by the path marked 

"1". Although not illustrated in the figure, the architecture supports multiple RTEs. 

TSIS also provides an interface (CORWin) that enables an RTE to send messages to the 

CORSIM Server and to send text messages to be displayed by the CORSIM Driver. This 

interface is illustrated in the figure by the path marked "2". 

Additionally, the RTE can directly access many of the data structures in CORSIM because 

they have been exported as shared memory. The shared memory not only allows the RTE 

to extract information from the simulation but also enables the RTE to control different 

aspects of the simulation. The shared memory interface is illustrated in the figure by the 

path marked "3". 

As this architecture evolves, the CORSIM shared memory interface is being replaced by 

Application Program Interfaces (APIs). Use of APIs rather than the shared-memory 

mechanism reduces the coupling between a user’s RTE and the underlying CORSIM data 

structures. With APIs, CORSIM developers can modify those data structures to maintain 

and enhance CORSIM without causing users to re-write their RTEs. 

Finally, the RTE may directly call exported CORSIM functions via the control API (e.g., to 

abort the simulation) and the actuated control API. These interfaces are illustrated in the 

figure by the path marked "4". 
307 

Building a CORSIM RTE requires a suitable compiler such as Microsoft Visual C++ or 

FORTRAN and the TSIS package, which includes all of the components shown in the 

previous figure (except for the RTE). Compilers supplied by vendors other than Microsoft 

can be used but the developer will have to refer to the compiler-specific documentation for 

information regarding linking with Microsoft-compiled libraries. 

The TSIS RTE Toolkit contains valuable tools to assist an analyst in understanding how to 

create their own RTEs. The RTE Toolkit contains a RTE Developers Guide, CORSIM Data 

Dictionary, a debug version of the CORSIM Driver, and a sample RTE. This Toolkit can be 

obtained from the TSIS distributor where the TSIS package was purchased; however, at 

this time the Toolkit and RTE functionality are not part of the standard TSIS package. 

309 

Appendix M: CORSIM Path Following Capability 

The path following capability in CORSIM was developed to test the Dynamic Traffic 

Assignment (DTA) prototypes being developed for FHWA.3 An extensive set of functions 

was developed to allow the DTA system to interact with CORSIM at run time. A filebased interface that interacts with CORSIM during the simulation is included in CORSIM, 

but it is currently undocumented and unsupported. The path following capability works 

by reading two input files that specify the paths and the vehicles that follow the paths. If 

the input file is named “case.trf,” then the path file must be named “case.pat” and the 

vehicle file must be named “case.veh.” Any run of CORSIM will look for these files and 

try to use them if they are in the same directory with the file that is being run. 

The path definition must start and end with an 8000 node. The number of paths is limited 

to 5,000, which should be more than enough for any network that CORSIM could model. 

The format for the path file, along with an example file, is displayed in Figure 114. 

Figure 114. Illustration. Path file format and example for path following. 

The format for the vehicle file is: entry time (the second that the vehicle enters the 

network), entry node, path ID (path IDs are the sequence number in the path file), driver 

type, vehicle fleet, and vehicle type. All of these entries are included on a single line 

separated by spaces. A new line is created for each driver type-vehicle type combination 

that the analyst wants to follow a certain path. An example of the vehicle format file is 

shown in Figure 115. 

 

3 This capability was designed for research purposes and can be quite tedious for large networks or large 

volumes of vehicles. At this time there is no intention of creating a user interface for this functionality 

or supporting it further. 
310 

Figure 115. Illustration. Example of the vehicle file for path following.

The vehicles will be injected into the stream of vehicles at the time specified. These 

vehicles will interact with other vehicles created by CORSIM via the Record Type (RT) 50 

if entry volumes are input. If the entry volumes are zero, only the injected vehicles will be 

present on the network. 

Probe Vehicle Tracking File 

As a method to check the entry and exit times of a path following vehicle, a probe vehicle 

file is created when path following vehicles are injected into the network. If the input file 

is named “case.trf,” then the probe file will be named “case.prb.” The format for the probe 

file is: time, vehicle ID, the text “ENTRY” or “EXIT”, path ID, and the node number for 

either the entry or exit node of choice. An example of the probe vehicle tracking file is 

shown in Figure 116. 

Figure 116. Illustration. Example of the probe file format for path following. 
311 

Appendix N: Emergency Vehicle Operation 

Emergency vehicles (EV), such as fire trucks and ambulances, using lights and siren while 

moving along a route of streets to respond to a request for emergency services can 

adversely affect traffic flow in the vicinity of the emergency vehicle. This adverse effect 

can be momentary or it may take a very long time to dissipate after the passage of the EV. 

In addition to the adverse effect the EV can have on the traffic, the traffic can have an 

adverse affect on the time it takes the EV to reach its destination. Traffic signal preemption 

has been shown to improve the EV response time and reduce traffic accidents, but it 

adversely affects traffic flow. 

Traffic signal preemption temporarily alters normal signal time allocations in some 

manner. It gives preference to the movement of the preempting EV through intersections, 

with limited regard to the effect the preemption may have on other vehicles on the traffic 

facility. The character and significance of the effect depends on the geometric 

characteristics, the size and complexity of the traffic facility, the traffic loading and traffic 

mix (which is usually dependent on the time of day), the intersection approach on which 

preemption is being requested, the number and characteristics of the emergency vehicles 

requesting preemption, and the signal control methodology and the signal timing patterns 

in use. 

An analysis was performed as part of Phase 1 of the ITS Public Safety Program’s 

Emergency Vehicle Network Delay (EVND) Study with the goal of illustrating and 

assessing the suitability of an approach for evaluating emergency vehicle preemption 

impacts on subsequent responders using micro-simulation. The background and 

characteristics of the experiment, the process of setting up and running the test cases, and 

the results of this assessment analysis were detailed in the report on the work completed in 

October 2001: Plan and Assessment for the Study of Impact on Delay, of the Use of “Lights and 

Siren”, and Signal Preemption by Emergency Vehicles Operating on a Network. 

Based on the results of the assessment analysis, it was concluded that the use of the 

CORSIM micro-simulation with appropriate extensions provided an adequate starting 

point for the evaluation of emergency vehicle preemption impacts on subsequent 

responders. A significant finding of the Phase 1 assessment analysis was that the 

modeling of the special behaviors, which civilian and public safety vehicles exhibit when 

they interact, is essential to simulating real-life conditions and estimating impacts.4

 

4 It was determined that this functionality should be made public to promote discussion and research. 

This capability was designed for research purposes and can be quite tedious for large networks or large 

numbers of EV. At this time there is no intention of creating a user interface for this functionality or 

supporting it further. Only limited testing of the EV capability has been performed. Lack of real-world 

data to validate this capability against has been a problem. Therefore, this functionality should only be 

used with the understanding that it has not been extensively tested nor has it been validated. 
312 

Modifications to CORSIM 

In the following paragraphs, some of the modifications that were made to CORSIM to 

meet the requirements for the EV modifications are presented. First, CORSIM supports 

several new inputs that are input via an external file with an *.evd extension. For example, 

for each EV, users will specify if it has signal preemption capability. Likewise, for each 

signal, users will need to specify if it supports preemption. Link inputs were expanded to 

include specification of shoulder and median availability. Several new driver behavior 

parameters were defined, including auditory and visual detection thresholds, reaction 

time factors, and motivational factors. Several new vehicle movements that result from a 

driver becoming aware of an EV, given the driver's current speed, distance from the EV, 

current lane, and motivational factors are supported. The probability of a driver choosing 

one of these possible movements is included. (NOTE: No modifications have been made 

to TRAFED at this time. Inputs for EV specifications are handled by a separate *.evd 

file created by the analyst.)

One of the basic elements to the operation of EV within the network is that when an EV 

enters the network, other vehicles will become aware of the EV’s presence. To facilitate 

this operation, CORSIM was modified to determine which vehicles are aware of the EV, 

based on the distance to the EV and the reaction thresholds of the individual drivers. As 

an EV traverses the network, more vehicles become aware of its presence. Once a vehicle 

becomes aware of an EV, the vehicle employs movement logic that will override its normal 

movement logic. This logic depends on many factors, such as: whether the driver is 

cooperative or not, whether the vehicle is moving or already stopped, whether the EV is 

traveling in the same or conflicting direction as the vehicle, whether there is a 

shoulder/median, whether the EV is to the left or right of the vehicle, whether the vehicle 

can make a lane change or is stopped at the intersection (and thus cannot make a lane 

change). The result of this logic is to choose one of the movements specified in the 

document Operator and Driver Special Behaviors from the Phase 1 study mentioned earlier. 

Under normal operation, CORSIM vehicles randomly choose where to turn based on user 

input turning percentages. This can lead to some undesirable effects. For example, a 

vehicle may choose to make four left turns in succession, which would cause the vehicle to 

drive around the block. An EV responding to a call must obviously take the most direct 

route possible. CORSIM has the capability to force individual user-specified vehicles to 

follow user-specified paths through the network. EVs take advantage of this capability 

and follow specified paths through the network. The vehicle specification file was 

modified for EV processing as documented at the end of this appendix. 

CORSIM was modified to have a new “fleet” of vehicles that are EVs. The EV fleet is 

designated in the *.evd file with a fleet number of four. Also, the number of vehicle types 

was increased to 16. These two inputs to CORSIM are undocumented features and only 

explained in this paragraph. The same vehicle type could be a member of different fleets. 

For example, a 6.1 m (20 ft) automobile could be of the Auto, Carpool, or EV fleet (to 

simulate a police car). 

A vehicle of the EV fleet uses different movement logic than the other vehicle fleets. For 

example, an EV is able to use any lane to perform any turn movement. It is allowed to 
313 

drive on the median or the shoulder if one exists on the current link. CORSIM was also 

modified to allow an EV to travel in opposing lanes, otherwise known as “contra-flow.” 

EVs are allowed to drive through a red signal and they use special logic when traversing 

the intersection. TRAFVU was modified to display the enhanced movements of both EV 

and other vehicles responding to the presence of EV. 

Specific Implementation Notes 

The definition of the input file that adjusts vehicle behavior based on the presence of an EV 

is contained at the end of this appendix. The file is the Emergency Vehicle Data (EVD) file 

(also referred to as the *.evd file). The data in the EVD file may eventually be made into 

optional record types that could be incorporated into the simulation input file. For the 

time being, they are implemented as a separate file that CORSIM reads in when it is 

present. 

The EVD file enables the user to specify when a vehicle becomes aware of an EV and when 

an aware vehicle cooperates with an EV. These are determined by setting percentages of 

vehicles based on the distance from the EV to the vehicle in question. A random number is 

drawn and if the random number is greater than the percentage, the aware or cooperative 

flags are set for the vehicle. The speed that the EV is traveling can reduce the distance at 

which a vehicle becomes aware of the EV, as has been shown in many studies. The 

distance that a vehicle follows an EV can also be set by the user in the EVD file. Finally, 

the existence of preemption equipment at a signalized intersection and the range over 

which it can receive a preemption call is set in the EVD file. 

The definition of the path following capability is contained in appendix M. This preexisting CORSIM capability makes it possible for an EV to follow a specific path from 

origin to destination. For example, the EV can start at the firehouse and travel on specific 

links en-route to a specific exit node that acts as its destination. The vehicle file was 

modified to allow inputs for the speed adjustment factor that an EV may travel faster or 

slower than the free-flow speed. Care should be taken in adjusting this parameter, 

however, as many governing agencies have set rules for EV vehicles to travel an adjusted 

speed based on the posted speed and not the free-flow speed (e.g., 16.1 km/h (10 mi/h) 

over the posted speed). Another modification enables the specification of the range of the 

signal preemption emitter on the EV. A distance of zero indicates the EV is not equipped 

with a signal preemption emitter. 

The changes to CORSIM that model emergency vehicles are quite extensive. Basically, the 

EV follows most car-following rules but has some overriding rules. The EV travels on the 

left lanes of the link because its “goal” lane is set to the left side of the link. The EV’s freeflow speed for the link is increased based on the input data for the vehicle. The EV 

searches for vehicles on surrounding links and flags them as aware and cooperative if they 

fall within the specified distance and have random number draws that indicate that the 

vehicle should cooperate. EVs will stop at a red signal, but then they can discharge when 

the vehicles at the other approaches are cooperating. An EV can also use contra flow to 

bypass a queue of vehicles. The contra flow lane was simulated using a non-existent lane 

eight, which is to the left of all other lanes. The EV checks for oncoming vehicles and 

vehicles check for oncoming EVs, and both react accordingly. 
314 

A cooperative vehicle will have its goal lane set to the right lane of the link and have its 

free-flow speed set to zero. The effect is that vehicles move to the right and slow down. 

However, if a vehicle is already on the far left lane in a left-turn bay, then it will remain on 

the left side of the link and not move across all lanes of traffic. If a right shoulder exists 

and is free of other vehicles, the vehicle may use it. The shoulder was simulated by using 

a lane zero, which is to the right of lane one. Lane zero is the lane used by buses to 

simulate a protected bus station. A vehicle stopped at a signal is permitted to discharge 

from the signal even if the signal is red, if the EV is in the same lane as the vehicle and 

close behind the vehicle. 

CORSIM inputs to specify if a median curb or shoulder exists are specified on the Record 

Type (RT) 80 of the CORSIM input file (*.trf file). By default, shoulders and median curbs 

do not exist on any links in the network. By setting column 56 to 1 on RT 80 of a specific 

link, shoulders will be available for use by vehicles moving out of the path of an EV. By 

setting column 60 to 1 on RT 80 for a specific link, a median curb will exist and EVs will 

not be allowed to cross the median curb to simulate contra-flow as shown in Figure 117. If 

the median curb does not exist (default condition), contra-flow will be used when 

appropriate. These two inputs to the TRF file are undocumented features and only 

explained in this paragraph. 

Figure 117. Illustration. Emergency vehicle contra-flow. 

A fixed-time signal can be preempted from its normal cycle if an EV with an emitter is 

within range and the signal has a receiver. The signal will allow a pedestrian phase to 
315 

terminate and then the signal will change so that the EV’s approach receives a green 

signal. This will last as long as the EV is preempting the signal. When the EV exits the 

intersection, the signal will transition back to its normal cycle. If the signal is coordinated 

with other signals (i.e., an offset has been set), an attempt is made to return the signal to 

coordination. This operation currently only applies to fixed-time controllers. 

Emergency Vehicle Delay File Format 

The EVD file is associated with a specific simulation input file via the filename. If the 

simulation input file is named “casename.trf,” then the EVD file must be named 

“casename.evd.” The EVD file contains five sets of values used by CORSIM to maneuver 

an EV through the network: awareness, cooperation, speed, trailing, and preemptable 

signal values. Each set has two lines of text that can be changed to make the simulation 

behave differently. A line that starts with “/” will be treated as a comment and will be 

ignored. Section tags are required, and data without a tag will be ignored. Just the first 

letter of the tag is actually used: “A” or “a” for Awareness values; “C” or “c” for 

Cooperation values; “S” or “s” for Speed values; “T” or “t” for Trailing values; and “P” or 

“p” for Preemptable signal values. An example EVD file is as follows: 

/ The first set of values governs the awareness of a passenger vehicle to an EV in the vicinity. 

/ It must start with the letter “A” or “a” for Awareness. 

/ The first line has the distances where a passenger vehicle becomes aware of the EV, in feet. 

/ The second line is the percentage of vehicles that become aware at those distances. 

Awareness 

50 100 150 200 300 400 500 700 1000 1500 

99 90 70 50 40 30 20 10 5 2 

 

/ The second set of values governs the cooperation of a passenger vehicle with the EV. 

/ It must start with the letter “C” or “c” for Cooperation. 

/ The first line is the distance where the passenger vehicle begins to cooperate with the EV, in feet. 

/ The second line is the percentage of vehicles that cooperate at those distances. 

Cooperation 

50 100 150 200 300 400 500 700 1000 1500 

90 80 70 60 50 50 50 50 30 20 

 

/ The next set of values governs the reduction in awareness due to speed. 

/ It must start with the letter “S” or “s” for Speed. 

/ The first line is the speed the EV is traveling, in feet/sec. 

/ The second line is the reduction in the percentage of vehicles that become aware at those speeds. 

Speed 

10 20 30 40 50 60 70 80 90 100 

 3 6 10 15 20 25 30 35 40 45 

 

/ The next set of values is the distance behind the EV that the passenger vehicle will travel. 

/ It must start with the letter “T” or “t” for Trailing. 

/ The first line is the distance the passenger vehicle will trail behind the EV, in feet. 

/ The second line is the percentage of passenger vehicles that will maintain at that distance. 
316 

Trailing 

50 75 100 125 150 200 250 300 400 500 

99 99 90 80 70 60 50 30 10 5 

/ The next set of values governs the signals that are equipped with preemption devices. 

/ It must start with the letter “P” or “p” for Preemptable signal. 

/ The first entry on each line is the node number, and the second number is the range of the device in feet. 

Preemptable Signal 

220 1500 

Path-following Vehicle Modifications 

Modifications to the vehicle file (*.veh) were made for the EV project. Normal (nonemergency) vehicles are separated by "N" or “n” for Normal. If no delimiter is present in 

the *.veh file, then CORSIM assumes the vehicles are normal vehicles. EVs are separated 

by "E" or “e” for Emergency. Vehicle types may switch back and forth using the proper 

separators. An example of a modified VEH file is as follows: 

/ The format is: 

/ entry time (sec), entry node, path ID, driver type, fleet #, vehicle type # 

/ EV additional codes: speed adjustment (ft/sec from normal), and Preempt emitter range (use zero if not equipped) 

Emergency Vehicles 

45 8200 2 10 4 15 5 1500 

90 8200 2 10 4 16 5 1500 

145 8200 2 10 4 15 5 1500 

Normal Vehicles 

190 8200 2 10 0 2 

245 8200 2 10 0 2 

Emergency Vehicles 

290 8200 2 10 4 16 5 1500 

345 8200 2 10 4 15 5 1500 

390 8200 2 10 4 16 5 1500 
317 

Appendix O: File Extensions 

The files used by TSIS tools have a fixed file naming convention. The convention is 

defined as follows: 

file_name.??? 

where: 

file_name is any standard file name. In many cases the file_name is the same name as the 

case. 

.??? is the file extension. Many of the file extensions are listed below. 

User Generated Files 

INP – Contains a list of input file names and directory paths to be used in the run-many 

cases script. 

PAT – Path data file used by CORSIM. The file_name is the case_name. 

TCF – TSIS Configuration File. A file that defines a TSIS project and contains information 

about the project , e.g., project description and creator. The file_name is the project name. 

TNO – Traffic Network Object file that contains the geometric, control, demand, and 

graphic data for the network. Created by TRAFED in XML format. The file_name is the 

case_name. 

TRF – A file that contains the input data used to define a CORSIM network and to drive 

the CORSIM simulation for a single simulation case. Created by TRAFED or with a text 

editor. The file_name is the case_name. 

TXT – A text file that can be created or edited with a text editor. 

VBS – Visual Basic Script. A file that contains a Visual Basic script. 

VEH – Probe vehicle injection data used by CORSIM when path following is requested. 

The file_name is the case_name. 

TSIS Generated Files 

CSV – Comma Separated Value file. Normally used as an input to a spreadsheet program. 

CORSIM creates the output data in CSV format. The Output Processor can also produce 

its results in CSV format. The file_name is the case_name. 

LU? – Temporary file used during the execution of CORSIM. The file_name is the 

case_name. 
318 

OUT – Output file generated by CORSIM, which contains the results of the run including 

messages and MOE. The file_name is the case_name. 

PRB – Probe vehicle file created by CORSIM to track vehicles injected via the path 

following capability of CORSIM. The file_name is the case_name. 

TS? – Time Step Data file, created by the CORSIM driver. Contains the vehicle, incident 

and control data generated by CORSIM that is used by TRAFVU to animate the network. 

Each file has a maximum size of 2 gigabytes so in order to animate larger amounts of data, 

subsequent files are generated. TS0 is generated first, TS1 is generated next, TS2 is 

generated after that, and so on. The file_name is the case_name. 

TSI – Time Step Index file, created by the CORSIM driver. Contains indexes into the TSD 

data files to allow moving through the TSD file efficiently. The file_name is the 

case_name. 

TID – Time Interval Data file, created by the CORSIM driver. Contains the MOE data 

generated by CORSIM that is used by TRAFVU to display the network MOE. The 

file_name is the case_name. 

TII – Time Interval Index file, created by the CORSIM driver. Contains indexes into the 

TID data file to allow moving through the TID file efficiently. The file_name is the 

case_name. 

XLS – A Microsoft Excel spreadsheet file. The Output Processor can produce its results in 

Excel format. The file_name is the case_name plus an identifier to show the granularity of 

the data (e.g. _cumulative, _interval, _timeperiod). 

TSIS System Files 

DLL – Dynamic-Link Library. In general, a DLL is a file that contains one or more 

functions that are compiled, linked, and stored separately from the processes that use 

them. 

OCX – ActiveX control file. A component format used by the TSIS container. 

PDF – Portable Document Format. A universal, portable document format developed by 

Adobe. TSIS user guide's are distributed using this format. 
319 

Glossary 

ATMS – Advanced Traffic Management Systems. 

Calibration – Process where the analyst selects the model parameters that cause the model 

to best reproduce field-measured local traffic operations conditions. 

Case – A single simulation for a specified traffic network as defined by its simulation input 

file. A case includes the simulation input file and all data files generated by the simulation 

during a run. Multiple runs of the simulation for gathering statistics is still considered 

part of a single case provided the input has not changed. 

CID – Controller Interface Device. This is a hardware interface used to connect a signal 

controller to a computer running a traffic simulation. 

Common Controls – A Microsoft component that supports the use of common graphical 

interface controls, e.g., a list box, within programs that run under the Windows operating 

systems. 

COM – Component Object Model. 

Component – An independent software application that can be easily integrated into other 

software applications or into a container program. 

Component architecture – A software architecture in which a framework, called a 

container, supports the use and interaction of independent software components (tools).. 

Container – A computer program composed of a framework that supports the use and 

interaction of independent software components. 

CORDebug – This is the name of the debug version of the CORSIM Driver DLL. It is used 

for debugging RTEs. 

CORSIM – CORridor SIMulation. A microscopic traffic simulation tool supported by the 

TSIS environment. 

CORSIM Data Dictionary – This document contains a description of the CORSIM 

elements that are shared for access by code that resides outside of the CORSIM DLL. 

CORSIM Driver – This is the name of the DLL that is installed as a tool in the TSIS 

package and is used to run the CORSIM simulation. 

CORSIM Server – The CORSIM Server is an interface between the CORSIM Driver tool 

and the CORSIM DLL. The Server enables TSIS to run multiple simulations at one time. 
320 

CORWin – The CORWin interface provides a Windows interface between the CORSIM 

Server and the CORSIM DLL. It also serves as an interface between an RTE and the 

CORSIM Server, which enables the RTE to display messages in the CORSIM Driver tool. 

DCOM – Distributed Component Object Model. 

Destination folder – A user-specified folder (directory) to which the setup program will 

install the TSIS software or sample projects. 

DLL – Dynamic-Link Library. In general, a DLL is a file that contains one or more 

functions that are compiled, linked, and stored separately from the processes that use 

them. 

DOT – Department of Transportation. 

Dynamic-link library – In general, a DLL is a file that contains one or more functions that 

are compiled, linked, and stored separately from the processes that use them. 

Dynamic memory – Memory that is allocated while a process is running as opposed to 

statically allocated at the time a module is compiled and linked. 

Exported functions – A function that resides in a DLL, but that made accessible (exported) 

to other processes. 

FHWA – Federal Highway Administration. Sponsor for the development of the TSIS suite 

of traffic analysis tools. 

FRESIM – FREeway SIMulation. The part of the CORSIM simulation that models freeway 

operations. 

Graphical user interface – An interface between a user and a software tool, consisting of 

graphical elements and controls, e.g., windows, dialogs, buttons. 

GUI – Graphical User Interface. 

HOV – High Occupancy Vehicle. This term is generally used to describe roadway lanes 

(facilities) that are reserved for vehicles that contain more than one occupant (person). 

HTML – Hypertext Markup Language is a system of marking up or tagging a document 

so that it can be published on the World Wide Web. It is used to display TSIS on-line help. 

McTrans Center – A vendor that distributes and supports the TSIS software. For more 

information, please visit the McTrans web site at http://mctrans.ce.ufl.edu. 

MDAC – Microsoft Data Access Components. The Microsoft Data Access Components 

architecture provides a universal framework for exposing both traditional SQL-based 

database sources and non-SQL data stores such as documents or multidimensional 

sources. In TSIS, MDAC supports the use of the TRF database. 
321 

MFC – Microsoft Foundation Classes. The C++ class library that Microsoft provides with 

its C++ compiler to assist programmers in creating Windows-based applications. MFC 

hides the fundamental Windows API in class hierarchies so that programmers can write a 

Windows-based application without needing to know the details of the native Windows 

API. TSIS and its components are built using MFC. 

Microsimulation – Modeling of individual vehicle movements on a second or sub-second 

basis for the purpose of assessing the traffic performance of highway and street systems. 

Model – A specific combination of modeling software and analyst-developed input 

parameters for a specific application. A single model may be applied to the same study 

area for several time periods and several existing and future improvement alternatives. 

MOE – Measure of Effectiveness. An output measurement from a simulation tool used as 

a measure of the performance of the traffic flow on a network. Decision makers may use 

one or more key MOEs when deciding the optimum system design. 

MS-DOS – Microsoft Disk Operating System. A Microsoft operating system that predates 

the Windows operating systems. 

NETSIM – NETwork SIMulation. The part of the CORSIM simulation that models 

surface-street operations. 

OCX – ActiveX control file. A component format used by the TSIS container. 

PC-TRANS – A vendor that distributes and supports the TSIS software. For more 

information, please visit the PC-TRANS web site at http://www.kutc.ku.edu/pctrans. 

PDF – Portable Document Format. A universal, portable document format developed by 

Adobe©. TSIS User Guides are distributed using this format. 

PR – Problem Report. 

Project – A set of simulation cases that reflect a common theme, e.g., signal timing 

variations for an artery in downtown Washington, D.C. See the definition for case. 

RAM – Random Access Memory. 

RTE – Run-Time Extension. A method by which a TSIS user can extend (or replace) 

functionality in the CORSIM simulation without having to modify, compile, and link the 

CORSIM code. It is typically used to modify/replace the signal control logic in CORSIM. 

See appendix L for more information on RTE. 

Script Tool – The TSIS Script Tool is a combined script editor and tool for executing Visual 

Basic Scripts. Using the built-in TSIS interfaces, the Script Tool is a powerful mechanism 

for extending the functionality of the other TSIS components. 

Shared memory – A mechanism by which CORSIM exports its memory for use by other 

processes such as run-time extensions. 
322 

Software – Set of computer instructions for assisting the analyst in the development and 

application of a specific microsimulation model. Several models can be developed using a 

single software program. These models will share the same basic computational 

algorithms embedded in the software; however, they will employ different input and 

parameter values. 

System files – Microsoft support files, required by TSIS, that the TSIS setup program 

installs to the system directory of your computer. Because these files are used by a wide 

variety of Microsoft and other third-party software products, they are often already 

installed on your system. TSIS will only install the files if they do not exist or if the 

existing files are older than those needed by TSIS. 

TCF – TSIS Configuration File. A file that defines a TSIS project and contains information 

about the project (e.g., project description and creator). 

Text Editor – This editor is a standard text editor that has the additional capability of 

"understanding" the CORSIM TRF file format. When editing a TRF file with this editor, 

the TShell output window displays text describing the entry field and record type at the 

current cursor position. Clicking a specific field description in the output window 

highlights the corresponding entry field in the displayed TRF file. 

Time step – The smallest unit of time at which CORSIM moves vehicles (updates vehicle 

positions). This is also the frequency at which CORSIM calls a run-time extension's main 

execution function. 

TNO – Traffic Network Object. TNO is a file format used by the TRAFED network editor. 

Tool – A program or component that is installed into the TSIS environment for use in 

conducting traffic operations analysis. A tool can be an application (EXE), Dynamic-Link 

Library (DLL), COM object or ActiveX Control (OCX), or a batch program (BAT). 

TRAFED – TRAFED is a graphical user interface-based editor that allows you to easily 

create and edit traffic networks and simulation input for the CORSIM model. 

TRAFVU – TRAFVU (TRAF Visualization Utility) is a user-friendly graphics postprocessor that displays traffic networks, animates simulated traffic flow operations, 

animates and displays simulation output measures of effectiveness, and displays userspecified input parameters for simulated network objects. 

TRF – A file that contains the input data used to define a CORSIM network and to drive 

the CORSIM simulation for a single simulation case. 

Translator – A TSIS tool used to translate between the TRF and TNO file formats. It 

converts TRF files for use by TRAFED. The translator also performs the reverse operation 

of translating the TRAFED native format (TNO) files into TRF files for use by CORSIM and 

other tools. 
323 

TShell – The graphical user interface for the TSIS integrated development environment. It 

provides a Project view that enables you to manage your TSIS projects. It is also the 

container for the pre-configured tools and any tools that you add to the suite. 

TSIS – Traffic Software Integrated System. TSIS is the integrated development 

environment that hosts the CORSIM simulation and its support tools. 

Validation – Process where the analyst checks the overall model-predicted traffic 

performance for a street/road system against field measurements of traffic performance, 

such as traffic volumes, travel times, average speeds, and average delays. Model 

validation is performed based on field data not used in the calibration process. This report 

presumes that the software developer has already completed this validation of the 

software and its underlying algorithms in a number of research and practical applications. 

VBS – Visual Basic Script. A file with a VBS extension that contains Visual Basic code. See 

definition of Visual Basic Script for more information. 

Verification – Process where the software developer and other researchers check the 

accuracy of the software implementation of traffic operations theory. This report provides 

no information on software verification procedures. 

Visual Basic Script – VBScript is a lightweight and extremely fast language engine 

designed specifically for environments like the Internet, intranets, or the World Wide Web. 

325 

Acknowledgments 

The authors would like to express appreciation to the following sources of information. 

The outline of the document is based directly on the outline presented in Volume III: 

Guidelines for Applying Traffic Microsimulation Modeling Software.(7) Much of the general 

simulation guidance contained in this document originates from the Volume III document. 

Much of the CORSIM-specific guidance presented in this document is based on the 

Advanced CORSIM Training Manual,(2) sponsored by the Minnesota Department of 

Transportation, FHWA, and Hennepin County (MN). This manual is available online at 

http://www.dot.state.mn.us/trafficeng/modeling/. 

Most of the TSIS and CORSIM technical information comes from the TSIS, CORSIM, 

TRAFED, TRAFVU, TShell, and Script Tool User’s Guides,(5,1,11,19,4 ,6) which are provided 

with the purchase of TSIS/CORSIM. The authors would like to acknowledge the work 

done on these guides over many years. 

327 

References 

1. CORSIM User’s Guide, CORSIM Reference Manual, Version 6.0. ITT Industries, Inc., 

Systems Division, Prepared for Federal Highway Administration under contract 

number: DTFH61-01-C-00005, May 2005. 

2. Advanced CORSIM Training Manual. Short Elliott Hendrickson, Inc., Prepared for 

Minnesota Department of Transportation, SEH No. A-MNDOT0318.00, September, 

2003. 

3. Highway Capacity Manual, HCM2000. TRB, National Research Council, Washington, 

D.C., 1994. 

4. TShell User’s Guide, Version 6.0. ITT Industries, Inc., Systems Division, Prepared for 

Federal Highway Administration under contract number: DTFH61-01-C-00005, May 

2005. 

5. TSIS User’s Guide, Version 6.0. ITT Industries, Inc., Systems Division, Prepared for 

Federal Highway Administration under contract number: DTFH61-01-C-00005, May 

2005. 

6. Script Tool User’s Guide, Version 6.0. ITT Industries, Inc., Systems Division, Prepared for 

Federal Highway Administration under contract number: DTFH61-01-C-00005, May 

2005. 

7. Traffic Analysis Toolbox Volume III: Guidelines for Applying Traffic Microsimulation 

Modeling Software. Dowling, Richard, Alexander Skabardonis, Vassili Alexiadis. 

Federal Highway Administration, Publication No. FHWA-HRT-04-038, June 2004. 

8. Traffic Engineering, Second Edition. McShane, William R., Roger P. Roess, and Elena S. 

Prassas. Prentice Hall, Upper Saddle River, NJ, 1998. 

9. ALINEA: A Local Feedback Control Law for On-Ramp Metering. Papageorgiou, Markos, H. 

Hadi Salem, J-M. Blosseville. Transportation Research Record. Vol. 1320, 1991. 

10. Translator User’s Guide, Version 6.0. ITT Industries, Inc., Systems Division, Prepared for 

Federal Highway Administration under contract number: DTFH61-01-C-00005, May 

2005. 

11. TRAFED User’s Guide, Version 6.0. ITT Industries, Inc., Systems Division, Prepared for 

Federal Highway Administration under contract number: DTFH61-01-C-00005, May 

2005. 

12. Characterization of Accident Capacity Reduction., Final report for ITS Center project: Incident 

capacity estimation., Qin, Ling, B. Smith. Smart Travel Lab Report No. STL-2001-

02University of Virginia, 2002. 
328 

13. “Traffic Appraisal in Urban Areas, Highways Agency,” Design Manual for Roads and 

Bridges: Volume 12, Section 2, Department for Transport (formerly Department of 

Environment, Transport, and the Regions), London, England, May 1996. 

14. “Freeway System Operational Assessment.” Paramics Calibration and Validation 

Guidelines (Draft), Technical Report I-33, Wisconsin DOT, District 2, June 2002. 

15. “Practical Procedure for Calibrating Microscopic Traffic Simulation Models.” Hourdakis, J., 

P. Michalopoulos, and J. Kottommannil, TRB, TRR 1852, Washington, D.C., 2003. 

16. “Identifying and Assessing Key Weather-Related Parameters and Their Impacts on Traffic 

Operations Using Simulation.” Zhang, Li, Peter Holm. Federal Highway Administration, 

Publication No. FHWA-HRT-04-131, September, 2004. 

17. Trip Generation Manual, 7th Edition. Institute of Transportation Engineers, Washington, 

D.C., ISBN No: 0-935403-79-5, 2003. 

18. Traffic Analysis Toolbox Volume VI: Definition, Interpretation, and Calculation of Traffic 

Analysis Tools Measures of Effectiveness. Dowling, Richard, anticipated publication April 

2007. 

19. TRAFVU User’s Guide, Version 6.0. ITT Industries, Inc., Systems Division, Prepared for 

Federal Highway Administration under contract number: DTFH61-01-C-00005, May 

2005. 

20. “Central Puget Sound Freeway Network Usage and Performance, 1999 Update, Volume 1.” 

Ishmaru, John M., Jennifer Nee, and Mark E. Hallenback. Prepared for Washington 

State Department of Transportation, Report No. WA-RD 493.1, May 2001. 

21. “Comparison of the 1994 Highway Capacity Manual’s Ramp Analysis Procedures and the 

FRESIM Model.” Roess, Roger P., Jose M. Ulerio. NCHRP Report 385, National 

Academy Press, Washington, D.C., 1997. 

22. Simulation Modeling and Analysis. Law, Averill M., and W. David Kelton. McGraw 

Hill, New York, NY, 2000. 
329 

Bibliography 

Actuated Controllers in TRAF: Record Types 43-48. Viggen Corporation, Viggen Document 

No. TD0001, Rev. 1.01, August, 1996. 

Guidelines for Calibration of Microsimulation Models, Framework and Applications. , Dowling, 

Richard, et al. Transportation Research Record 1876, TRB, National Research Council, 

Washington, D.C., 2004, pp. 1 – 9. 

Advanced CORSIM Training Manual., Minnesota Department of Transportation 

<http://www.dot.state.mn.us/trafficeng/modeling/> , April 2005. 

Introduction to CORSIM, Participant Workbook, NHI Course 137022, Morales, Juan, Charles 

Wallace, and Morya Wills. National Highway Institute, Federal Highway Administration, 

Publication No. FHWA-NHI-02-31, April 2002. 

Numerical Recipes, The Art of Scientific Computing Press, William H., Brian P. Flannery, Saul 

A. Teukolsky, and William T. Vetterling., Cambridge University Press, Cambridge, UK, 

1987. 

Text Editor User’s Guide, Version 6.0. ITT Industries, Inc., Systems Division, Prepared for 

Federal Highway Administration under contract number: DTFH61-01-C-00005, May 2005. 

Highway Traffic Data for Urbanized Area Project Planning and Design., Pedersen, N.J., 

Samdahl, D.R., NCHRP Report 255, TRB, National Research Council, Washington, D.C., 

December 1982. 

331 

Index 

A

Acceleration Data ..................................................191 

Actuated Control .............................................86, 217 

Coordination .....................................................231 

Cycle Length.....................................................287 

Detectors...........................................................220 

Force-Off ..........................................................289 

Offset ................................................................287 

Permissive Periods............................................291 

Split...................................................................287 

Yield Point........................................................288 

Actuated Controllers 

Overlaps............................................................228 

Plan Transition................................................237 

Alternative Analysis ..............................................149 

Analysis 

Management .......................................................18 

Analysis Process Overview .......................................5 

Animation......................................................104, 164 

Anticipatory Lane Change.......................................67 

B

Base Model Development........................................51 

Bus Operations ..................................................53, 91 

Bus Stations.............................................................91 

C

Calibration Data.......................................................36 

Component Object Model......................................305 

Conditional Turn Movements..................................81 

Control Data ............................................................33 

CORSIM 

Capabilites ..................................................15, 195 

Diagnostics .......................................................103 

Limitations........................................................198 

Output ...............................................................243 

Overview.......................................................4, 187 

Theory...............................................................187 

D

Data Collection 

How Long ...........................................................28 

How to ................................................................28 

Overview.............................................................27 

Storage ................................................................28 

When to...............................................................28 

Deliverables...........................................................181 

E

Emergency Vehicle Operation...............................311 

Entry Headway ......................................................213 

Entry Volume ..........................................................74 

Equilibrium............................................................201 

Erlang Distribution ................................................215 

Error Checking ........................................................99 

F

Facilities 

Indirectly Modeled............................................200 

Not Modeled .....................................................200 

File Extensions ......................................................317 

Fill Time ................................................................201 

Final Report...........................................................181 

Fleet.......................................................................190 

Freeway Demand.....................................................77 

Freeway Incidents....................................................90 

Frequently Asked Questions..................................275 

Fuel Consumption..................................................192 

G

Geometric Data........................................................30 

Graphics...................................................................63 

I

Incident Detection....................................................91 

Incidents ..................................................................89 

Initialization Period ...............................................201 

L

Lane Numbering................................................63, 71 

Link Names .............................................................63 

Link-Node Diagram.................................................54 

Long-Term Events...................................................90 

N

Nearest Neighbor...................................................165 

Node Location .........................................................55 

Node Numbering Scheme........................................60 

O

Output Processor ...................................................246 

P

Parking.....................................................................90 

Path-following .......................................................309 

Peak Hour ................................................................13 

Peak Period..............................................................13 

Pedestrian Delay......................................................93 

Pedestrian Demand................................................229 

Performance Index.................................................191 

preferences.............................................53, 54, 55, 62 

Pre-timed Control ..............................................34, 87 
332 

Q

Quality Assurance....................................................38 

R

Ramp Meter Control..........................................35, 84 

Random Number Generator...................................207 

Random Numbers..................................................205 

Reaction Point .........................................................66 

Resource Requirements ...........................................17 

Run Control Data.....................................................53 

Run-Time Extension Overview .............................305 

S

Script Tool..............................................................16 

Short-term Events....................................................90 

Source-sink..............................................................83 

Station......................................................................91 

status bar..................................................................62 

Stochastic Process..................................................205 

Study 

Deliverables ........................................................19 

Objectives .............................................................9 

Purpose .................................................................9 

Scope ..................................................................10 

Sub-time period demand..........................................76 

T

Technical Report....................................................182 

Teminology..............................................................52 

Text Editor...............................................................16 

Time Period Demand...............................................75 

TNO file.............................................................53, 54 

Traffic Forecast .....................................................150 

Translator...........................................................16, 53 

TShell......................................................................16 

TSIS 

Tools ...................................................................15 

V

Vehicle Characteristics ............................................33 

Vehicle Mix...........................................................190 

Visual Basic scripts..........................................16, 29 

W

Warning Sign...........................................................66 
 

U.S. Department of Transportation 

Federal Highway Administration 

 

U.S. Department of Transportation 

400 Seventh Street S.W., Room 4410 

Washington, DC 20590 

http://www.fhwa.dot.gov

Publication No.: FHWA-HOP-07-079 

 

 Publication Date: January 2007 

Recycled 

Recyclable