VISSIM 5.30-05 User Manual

VISSIM 5.30-05 User Manual

PTV 

Planung 

Transport 

Verkehr AG 

2 VISSIM 5.30-05 © PTV AG 2011

Copyright 

© 2011 

PTV 

Planung Transport Verkehr AG 

Stumpfstraße 1 

D-76131 Karlsruhe 

Germany 

All rights reserved. 

April 2011 

Copy and Use 

Although you are encouraged to make a backup copy of VISSIM for your 

own use, you are not allowed to make more than one copy. The Software 

may be used only on a single computer owned, leased or controlled by you 

at any one time. The Software is protected by the copyright laws that pertain 

to computer Software. It is illegal to submit copies to another person, or to 

duplicate the Software by any other means including electronic transmission. 

The Software contains trade secrets, and in order to protect them you may 

not decompile, reverse engineer, disassemble, or otherwise reduce the 

Software to human-perceivable form. You may not modify, adapt, translate, 

rent, lease, or create derivative work based upon the Software or any part 

thereof. 

Disk Warranty 

PTV (respectively the agent distributing VISSIM) warrants that the original 

disks are free from defects in material and workmanship, assuming normal 

use, for a period of ninety (90) days from date of purchase. If a defect occurs 

during this period, you may return your faulty disk to your local distributor, 

along with a dated proof of purchase; you will receive a replacement free of 

charge. 

EXCEPT FOR THE EXPRESS WARRANTY OF THE ORIGINAL DISKS SET 

FORTH ABOVE, NEITHER PTV AG NOR ANY OF THEIR DISTRIBUTORS 

GRANTS ANY OTHER WARRANTIES, EXPRESS OR IMPLIED, BY 

STATUTE OR OTHERWISE, REGARDING THE DISKS OR RELATED 

MATERIALS, THEIR FITNESS FOR ANY PURPOSE, THEIR QUALITY, 

THEIR MERCHANTABILITY, OR OTHERWISE. THE LIABILITY OF PTV 

User Manual © PTV AG 2011 3

UNDER THE WARRANTY SET FORTH ABOVE SHALL BE LIMITED TO 

THE AMOUNT PAID BY THE CUSTOMER FOR THE PRODUCT. IN NO 

EVENT SHALL PTV BE LIABLE FOR ANY SPECIAL, CONSEQUENTIAL, 

OR OTHER DAMAGES FOR BREACH OF WARRANTY. 


Table of Contents 

Important Notice to Users of Previous VISSIM Versions 17 

Versions Previous to 5.30 17 

Versions Previous to 5.20 17 



VISSIM Quick Start Checklist 19 

1 Introduction 21 

1.1 What is VISSIM? 22 

1.2 The Traffic Simulation Model 23 

2 Program Installation 27 

2.1 System Requirements 28 

2.2 Installation and Deinstallation of VISSIM 30 

2.3 Access to the EXAMPLES folder 31 

2.4 The Distributable VISSIM Viewer 32 

3 Program Handling 33 

3.1 The VISSIM Desktop 34 

3.1.1 The VISSIM Menus 35 

3.1.1.1 Default Menus 35 

3.1.1.2 Customizing Menus 40 

3.1.2 The VISSIM Toolbars 41 

3.1.2.1 Default Toolbars 41 

3.1.2.2 Customizing Toolbars 44 

3.1.3 How to Reset Customized Menus, Toolbars and Windows 45 

3.1.4 The VISSIM Status Bar: Data Output 46 

3.2 Keyboard and Mouse Operation 47 

3.2.1 General Behavior 47 

3.2.2 The VISSIM Shortcuts (Hotkeys) 47 

3.2.2.1 Default Shortcuts 48 

3.2.2.2 Customizing Shortcuts 49 

3.3 Selection of Network Elements 51 

3.3.1 Standard (Single-Select) Mode 51 

3.3.2 Multi-Select Mode (2D only) 52 

3.3.2.1 Multiselection of Network Elements 52 



3.3.2.2 Properties & Options: Editing in Multiselect Mode 53 

3.3.3 Label Mode (2D only) 54 

3.4 The VISSIM Command Line Operations 55 

3.5 The COM Interface (Optional Module) 57 

3.5.1 Loading and Running Scripts in VISSIM 57 

3.5.2 Python as Script Language 58 

3.6 Print Output 61 

3.6.1 Printing the Graphical Network 61 

3.6.2 Other Printouts 63 

3.7 Decimal Separator & Data Editing 64 

3.7.1 Default Settings 64 

3.7.2 Data Editing 64 

4 View Settings 65 

4.1 Display Options 66 

4.1.1 Network 66 

4.1.2 Vehicles 67 

4.1.3 Colors 68 

4.1.4 3D 71 

4.1.4.1 The Texture Manager 72 

4.1.4.2 Traffic Signal Default Properties 73 

4.1.5 Language & Units 76 

4.1.6 Simulation Time Display in the Status Bar 76 

4.2 The 2D Graphics Mode 77 

4.2.1 Visualization of Network Elements 77 

4.2.2 2D Visualization of Vehicles and Pedestrians 78 

4.2.2.1 Standard Coloring 78 

4.2.2.2 Automatic Dynamic Color Mode 79 

4.2.2.3 User-Definable Dynamic Colors 80 

4.2.3 2D Display of Aggregated Values for Vehicles (LOS) 80 

4.2.3.1 Viewing Aggregated Values of Vehicle Traffic 81 

4.2.3.2 Examples: Aggregated Values of Vehicle Traffic 82 

4.3 The 3D Graphics Mode 83 

4.3.1 Navigation 83 

4.3.1.1 Navigation Modes 83 

4.3.1.2 Sitting in the Driver’s Seat 84 

4.3.1.3 Changing the Field of View (Focal Length) 85 

4.3.2 3D Visualization of Vehicles and Pedestrians 85 

4.3.3 3D Animation of PT Vehicle Doors 86 

4.3.4 3D Signals 87 

4.3.4.1 Creating 87 

4.3.4.2 3D Signals in the Network Display 88 



4.3.4.3 Properties & Options 89 

4.3.4.4 Editing 95 

4.3.5 Static 3D objects 97 

4.3.6 Fog/Haze 98 

4.4 Background Images 100 

4.4.1 Supported Background Data Formats 100 

4.4.2 Workflow: Creating a Background 100 

4.4.3 Workflow: Scanning an Image 102 

4.5 Save/Load Settings 104 

5 Base Data for Simulation 105 

5.1 Acceleration and Deceleration Functions 106 

5.2 Distributions 110 

5.2.1 Desired Speed Distribution 110 

5.2.2 Weight Distribution 111 

5.2.3 Power Distribution 111 

5.2.4 Color Distribution 112 

5.2.5 Model Distribution 112 

5.2.5.1 2D Model Definition (Geometry) 113 

5.2.5.2 3D Model Definition 116 

5.2.6 Dwell Time Distribution (PT Stops & Parking Lots) 120 

5.2.7 Location Distribution (PT Boarding/Alighting Pass.) 121 

5.2.8 Temperature Distribution (Cold Emissions module only) 122 

5.3 Vehicle Type, Class and Category 123 

5.3.1 Vehicle Types 123 

5.3.2 Vehicle Classes 127 

5.4 Driving Behavior 128 

5.4.1 The “Wiedemann” Approach 129 

5.4.2 Car Following Behavior 130 

5.4.2.1 Wiedemann 74 Model Parameters 131 

5.4.2.2 Wiedemann 99 Model Parameters 132 

5.4.3 Lane Change 133 

5.4.4 Lateral Behavior 138 

5.4.5 Signal Control 141 

5.4.6 Changing the Saturation Flow Rate 143 

5.5 Links: Behavior Type and Display Type 147 

5.5.1 Link Behavior Type by Vehicle Class for Links 147 

5.5.2 Display Type by Link/Connector or Construction Element 148 

5.6 Managed Lane Facilities & Toll Pricing Models 152 

5.6.1 Managed Lane Facilities 152 

5.6.1.1 The Pricing Model 153 



5.6.1.2 The Decision Model 155 

5.6.2 Toll Pricing Calculation Models 156 

6 The Traffic Network 159 

6.1 Overview 160 

6.2 Data Import/Export 163 

6.2.1 Data Import 163 

6.2.1.1 Read Network Additionally 163 

6.2.1.2 SYNCHRO 7 Import (add-on module) 165 

6.2.1.3 Adaptive SYNCHRO7 Import 166 

6.2.1.4 ANM Import 167 

6.2.1.5 Adaptive ANM Import 173 

6.2.1.6 Hermes XML Import 174 

6.2.2 Data Export 175 

6.2.2.1 FILE - EXPORT - VISUM - NODES/EDGES... 175 

6.2.2.2 FILE - EXPORT - VISUM - LINKS/CONNECTORS... 181 

6.2.2.3 EVALUATION – FILE – Link evaluation 181 

6.2.2.4 FILE – EXPORT – 3DS MAX 183 

6.3 Network Coding 184 

6.3.1 Links 184 

6.3.1.1 Creating 185 


6.3.1.3 Editing 190 

6.3.2 Connectors 193 

6.3.2.1 Creating 193 


6.3.2.3 Editing 197 

6.3.3 Desired Speed Changes 201 

6.3.3.1 Reduced Speed Areas 201 

6.3.3.2 Desired Speed Decisions 204 

6.3.4 Rotate and Translate Network 206 

6.3.5 Pavement Markers and Zebra Crossings 206 

6.4 Automobile Traffic 208 

6.4.1 Vehicle Compositions 208 

6.4.1.1 Creating & Editing 208 


6.4.2 External Vehicle Course Files 209 

6.4.3 Vehicle Inputs (Traffic Volumes) 210 



6.4.4 Routing Decisions and Routes 215 

6.4.4.1 Creating 216 

6.4.4.2 The Routes Window Structure 218 



6.4.4.3 Editing 220 


6.4.4.5 Sorting & Filtering Data in Lists 230 

6.4.4.6 How Routing Decisions Come Into Action 232 

6.4.5 Parking Lots 235 

6.4.5.1 Roadside Parking Functionality 236 

6.4.5.2 Creating 237 


6.4.5.4 Editing 240 

6.4.6 Direction Decisions 240 

6.4.7 Routing Decisions versus Direction Decisions 242 

6.5 Public Transport 244 

6.5.1 PT Stops 244 

6.5.1.1 Creating 244 


6.5.1.3 Editing 247 

6.5.2 PT Lines (Bus/Tram lines) 248 

6.5.2.1 Creating 248 


6.5.2.3 Editing 251 

6.5.2.4 PT Line Route Alignment 251 

6.5.2.5 PT Line-specific Stop Data 251 

6.5.2.6 Methods for PT Vehicle Dwell Time Calculation 255 

6.5.2.7 Variation of Arrival Times 257 

6.6 Non-Signalized Intersections 258 

6.6.1 Priority Rules 258 

6.6.1.1 Principles 258 

6.6.1.2 Creating 261 


6.6.1.4 Editing 263 

6.6.1.5 Examples 264 

6.6.2 Conflict Areas 270 

6.6.2.1 Principles 270 

6.6.2.2 Creating 273 


6.6.2.4 Editing 276 

6.6.3 Stop Sign Control 277 

6.6.3.1 Creating 278 


6.6.3.3 Right Turn On Red 279 

6.6.4 Merging and Weaving Sections 280 

6.7 Signal Controllers 282 

6.7.1 Signal Groups and Signal Heads 282 

6.7.1.1 Creating 283 




6.7.1.3 Editing 285 

6.7.2 Detectors 285 

6.7.2.1 Creating 285 


6.7.2.3 Exponential Smoothing of the Occupancy Rate 288 

6.7.2.4 Editing 289 

6.7.3 Signal Control Types 289 

6.7.3.1 Creating 290 


6.7.3.3 VAP - Vehicle-Actuated Signal Control (optional module) 291 

6.7.3.4 SCATS (optional module) 291 

6.7.3.5 SCOOT (optional module) 292 

6.7.3.6 LISA+ OMTC (optional module) 292 

6.7.3.7 Ring Barrier Controller (optional module) 292 

6.7.3.8 Econolite ASC/3 (optional module) 294 

6.7.3.9 External 294 

6.7.3.10 Fixed time control 296 

6.7.3.11 Greentime Optimization of Stage-based Fixed-time Control 

298 

6.7.4 The SC Editor 300 

6.7.4.1 Editing Signal Groups 305 

6.7.4.2 Editing Intergreen Matrices 307 

6.7.4.3 Editing Stages (VISSIG add-on) 310 

6.7.4.4 Editing Stage Assignments (VISSIG add-on) 311 

6.7.4.5 Editing Stage Sequences (VISSIG add-on) 313 

6.7.4.6 Editing Signal Programs 316 

6.7.4.7 Editing Interstages (VISSIG add-on) 323 

6.7.4.8 Editing Daily Signal Program Lists (VISSIG add-on) 326 

6.7.4.9 Detecting Inconsistent Planning Scenarios 329 

6.7.4.10 Export Functions 331 

6.7.5 Changing the Signal Control Type 335 

6.7.6 Signal Control Communication 335 

6.7.7 Railroad Block Signals 336 

7 Simulation of Pedestrians 339 

7.1 The Pedestrians Editor (Add-on) 341 

7.1.1 The Pedestrian Mode 341 

7.1.2 Types of Pedestrians 342 

7.1.2.1 Creating 342 


7.1.3 Classes of Pedestrians 344 

7.1.3.1 Creating 344 


7.1.4 Construction Elements: Areas, Ramps, Obstacles 345 

7.1.4.1 Creating 346 



7.1.4.2 The Window Structure by Construction element type 348 

7.1.4.3 Properties & Options of Pedestrian Areas 348 

7.1.4.4 Properties & Options of Obstacles 351 

7.1.4.5 Properties & Options of Ramps/Stairways 352 

7.1.4.6 Multiple Levels (Add-on) 354 

7.1.4.7 Editing Construction Elements 355 

7.1.5 Links as Areas of Pedestrians 358 

7.1.5.1 Creating 364 


7.1.5.3 Editing 365 

7.1.6 Pedestrian Compositions 366 

7.1.6.1 Creating 366 


7.1.7 Pedestrian Inputs 367 



7.1.8 Routing Decisions and Routes 371 

7.1.8.1 Types of Routing Decisions and Routes for Pedestrians 372 

7.1.8.2 Partial Routes for Pedestrians 373 

7.1.8.3 Static partial routes of pedestrians: Use cases 375 

7.1.8.4 Creating 379 

7.1.8.5 The Pedestrian Routes Window Structure 381 


7.1.8.7 Editing 385 

7.1.8.8 Dynamic Potential: Overview 387 

7.1.8.9 Dynamic Potential: Use Cases 388 

7.1.8.10 Dynamic Potential: Editing 388 

7.1.8.11 Dynamic Potential: Properties & Options 389 

7.1.8.12 Dynamic Potential: Description of the Method 389 

7.1.8.13 The Service Point Selection Method 391 

7.1.9 Area-based Walking Behavior 395 

7.1.9.1 Walking Behavior Parameter Sets 395 

7.1.9.2 Area Behavior Types of Construction Elements 396 

7.2 Evaluation Types for Simulations of Pedestrians 398 

7.2.1 Pedestrian Travel Time Measurements 398 

7.2.2 Pedestrian Area Evaluations 401 

7.2.3 Pedestrian Record 408 

7.2.4 Pedestrian Queue Evaluations 413 

7.2.5 Pedestrian Information 416 

7.3 2D Visualization of Pedestrian Traffic 417 

7.3.1 Display Types of Construction Elements 417 

7.3.2 Display Options for Pedestrians 417 

7.3.3 2D Display of Aggregated Values for Pedestrians (LOS) 419 

7.3.3.1 Display Options for LOS of Pedestrian Traffic 421 

7.3.3.2 Examples: Aggregated Values of Pedestrian Traffic 423 



7.4 3D Visualization of Pedestrian Traffic 425 

7.5 Simulation of Pedestrians: Preconditions & How to 426 

7.5.1 Preconditions for Simulating Pedestrian Flows 426 

7.5.2 How the Simulation Internally Works 426 

7.6 Parameters of the Social Force Model in VISSIM 429 

7.6.1 Model Parameters by Pedestrian Type 429 

7.6.2 Implementation-specific Global Parameters 431 

7.7 Fields of Application & Requirements 434 

7.7.1 Overview: Pedestrians as PT Passengers 436 

7.7.2 Step-by-Step Instruction: Pedestrians as PT Passengers 438 

8 Simulation and Test 449 

8.1 Simulation of Vehicles and Pedestrians 450 

8.1.1 Simulation Parameters 450 

8.1.2 Saving the Simulation State (*.SNP) 453 

8.1.3 Multirun Simulation 454 

8.2 Test of Signal Control without Traffic Simulation 457 

8.2.1 Interactive Placement of Detector Calls 457 

8.2.2 Using Macros for Test Runs 458 

8.2.3 Using Batch Mode Operation for Test Runs 460 

8.2.3.1 Red Time Distribution (*.AWZ) 462 

8.2.3.2 Green Time Statistics (*.AGZ) 463 

8.2.3.3 Time-Time Diagram (*.AZZ) 464 

9 Presentation 465 

9.1 Animation 466 

9.1.1 Record Animation File 466 

9.1.2 Replay Animation File 467 

9.1.3 Record ANI.TXT File (optional module) 467 

9.2 Recording 3D Video files 469 

9.2.1 Recording Options 469 

9.2.2 Keyframes 469 

9.2.2.1 Creating 469 


9.2.2.3 Editing 471 

9.2.2.4 How Keyframes Come Into Action 473 

9.2.3 Starting the AVI Recording 473 

10 Output of Results 475 

10.1 Enabling Evaluations 476 

10.1.1 Output to Window 478 



10.1.2 Output to File 479 

10.1.3 Output to Database 481 

10.1.3.1 System Requirements 482 

10.1.3.2 Database Connection 482 

10.1.3.3 Database Output Data 484 

10.2 Runtime Messages 486 

10.2.1 Protocol Window 486 

10.2.2 Error Messages 487 

10.2.2.1 Fatal Error 487 

10.2.2.2 Troubleshooting via VDiagGUI.exe 488 

10.2.2.3 Program Warnings (*.ERR file) 492 

11 Evaluation Types for Simulations of Vehicles 495 

11.1 Travel Times 496 

11.2 Delay Times 500 

11.3 Data Collection 503 

11.4 Queue Counters and Vehicle Stops 508 

11.5 Green Time Distribution 511 

11.6 Vehicle Information 514 

11.7 Vehicle Record 515 

11.8 Dynamic Signal Timing Plan 525 

11.9 Signal Control / Detector Record 528 

11.10 Signal Changes 532 

11.11 Link Evaluation 534 

11.12 Node Evaluation 539 

11.13 Network Performance Evaluation 546 

11.14 Observer 551 

11.15 Lane Changes 552 

11.16 PT Waiting Time 554 

11.17 Vehicle Input 555 

11.18 Emission Statistics 556 

11.19 Export 557 

11.20 Special Evaluations (Discharge rate evaluation) 558 

11.21 Paths Evaluation 561 

11.22 Convergence Evaluation 565 

11.23 Managed Lanes 567 

11.24 Analyzer Report 569 



11.24.1 Quick Start 569 

11.24.2 User Interface In Depth 571 

11.24.3 The Analyser Report Format 579 

11.24.4 Database Tables 582 

11.24.5 Extras: Export to VISUM network file *.NET 588 

11.24.6 Troubleshooting Tips 589 

12 Dynamic Assignment 591 

12.1 Introduction 592 

12.2 Principle 593 

12.3 Building an Abstract Network 596 

12.3.1 Parking Lots and Zones 596 

12.3.2 Nodes 600 

12.3.2.1 Creating 601 


12.3.2.3 What the Colors Mean 603 

12.3.2.4 Editing 604 

12.3.2.5 Converting a Node 607 

12.3.3 Edges 608 

12.3.4 Check Nodes/Edges 611 

12.3.4.1 Correction of Overlapping Nodes 611 

12.3.4.2 Correction of Multiple Edges Between Two Nodes 612 

12.3.4.3 Correction of Unexpected Start/End of Nodes 613 

12.4 Traffic Demand 615 

12.4.1 Origin-Destination Matrices (OD matrices) 615 

12.4.2 Trip Chain Files 617 

12.5 Simulated Travel Time and General Cost 620 

12.5.1 Simulation Period and Evaluation Interval 620 

12.5.2 Simulated Travel Times 620 

12.5.3 General Cost 622 

12.6 Route Search and Route Choice 624 

12.6.1 Routes and their Cost 624 

12.6.2 Route Choice 624 

12.6.3 Route Search 626 

12.6.4 Route Visualization 627 

12.7 Optional Enhancements of the Model 630 

12.7.1 Multi-class Assignment 630 

12.7.2 Parking Lot Selection 630 

12.7.3 Detour Detection 632 

12.7.4 Correction of Overlapping Paths 632 

12.7.5 Dynamic Routing Decisions 634 



12.7.6 Route Guidance 635 

12.8 Assignment Control 637 

12.8.1 Path Evaluation File 637 

12.8.2 Iteration Control 637 

12.8.3 Convergence Control 638 

12.8.4 Route Search Control and Local Calibration 639 

12.8.5 Generation of Static Routing 643 

12.8.6 Summary of the Dynamic Assignment Parameters 645 

12.9 Initial Solution from VISUM 648 

12.9.1 Automatic VISUM Assignment Calculation 648 

12.9.2 Manual VISUM Assignment Calculation 649 

13 VISSIM Programming Interfaces (API) 653 

13.1 COM Interface 654 

13.2 External Driver Model - DriverModel.DLL 655 

13.3 3dsMaxExport 656 

13.4 Car2X Module 657 

13.5 External Signal Control – SignalControl.DLLs 658 

13.6 Emission Calculation – EmissionModel.DLL 659 

13.7 Tolling – TollPricing.DLL 660 

14 Glossary of Files associated with VISSIM 661 

14.1 Simulation Output Files 662 

14.2 Test Mode Files 665 

14.3 Dynamic Assignment Files 666 

14.4 ANM Import Files 667 

14.5 Other Data Files 668 

15 Service & Support 671 

15.1 Online Help 672 

15.1.1 Find topic 672 

15.1.2 Show topic 675 

15.2 License Info 677 

15.3 Contact Info 678 

15.3.1 Sales & Distribution 678 

15.3.2 Technical Hotline 679 

15.4 Services 680 


Important Notice to Users of Previous VISSIM Versions 

This section includes information about changes and new functionality only in 

those cases where there are substantial changes in VISSIM compared to 

previous versions. A complete list of all changes and news is contained in 

the file RELEASE_NOTES_530_E.TXT which is included in the DOC 

directory of your VISSIM installation. 

Versions Previous to 5.30 

The destinations as well as the intermediate points of pedestrian routes can 

be placed on ramps now. 

The path and cost files created with VISSIM 5.20 can no longer be used if 

they contain data generated with certain edge models. 

Each VISSIM 5.30 installation without the pedestrians add-on provides the 

opportunity to model up to 30 pedestrians in the network. 

In the 3D mode, just right-click to load a static 3D object file (*.SKP, *.DWF 

or *.3DS). The Select 3D Model window will open as for *.V3D files. Rightclick 

and pressing CTRL simultaneously is no longer required to load a file of 

the file types mentioned above. 

To delete a static 3D object, select the object by left-click and press DEL 

subsequently now. The left-click will no longer immediately remove the object 

from the network display. 

With Windows 7 and Windows Vista, just one EXAMPLES folder is now 

installed per main version. Access to this folder is provided via the 

environment variable VISSIM530_EXAMPLES, cf. section 2.3. 

Versions Previous to 5.20 

For the desired position at free flow you may now also select option Right for 

left-side traffic and vice versa in driving behavior parameter sets. 

In the default driving behavior parameter set “Urban“, the Look ahead 

distance has been set to 4 observed vehicles (instead of 2). 

Now click CTRL+L (instead of just the L key) to toggle between different LOS 

views. 

Keyframes can optionally be defined with Absolute start times. In case of 

changes to keyframe settings, the renamed option Shift subsequent 

keyframes leads to a different behavior now. The start times of later frames 

are now shifted by Δt: 

Δt = new start time – old start time + new dwell time – old dwell time. 


Important Notice to Users of Previous VISSIM Versions 

Thus it is no longer possible to shift a keyframe to another position within the 

list and to retain the movement times and dwell times simultaneously. You 

may not enter a new start time which is before the end of the dwell time of 

the previous keyframe. 

For Fixed time control, the Signal program Editor replaces the previous 

tabular data supply for SC of that type. All fixed time controllers are now 

handled as external (VISSIG) controllers. Hence the controller data is not 

stored in the *.INP file anymore but in a separate *.SIG file for each 

controller. Please keep that in mind if you transfer VISSIM project data to 

another location or client. 


In addition to link-based vehicle traffic VISSIM now includes an area-based, 

multi-level pedestrian behavior model (optional module). Its main advantage 

is its capability to model walkable areas and ramps as well as obstacles 

rather than directional links/connectors. Thus pedestrians are able to move in 

all directions including counter-flow situations. 

To automatically multi-select all links/connectors of any display type or 

behavior type, the new function MULTI-SELECT IN NETWORK is available in the 

context menu of the list of all display types and behavior types respectively. 

The *.BEW and *.WEG files are no longer necessarily overwritten during a 

(Multirun) Simulation, since existing output files can be saved to archive now. 

VISSIM provides complete unicode support for filenames. 


Link types are now split into link behavior types and link display types. This 

allows to handle the graphical display of a group of links independently of the 

driving behavior. Link display types have several new attributes for 3D 

display. 


VISSIM Quick Start Checklist 

For those users who are constructing their first network this is a checklist 

intended to assist in building the network in the most efficient order. 

1. Open VISSIM and create a new file 

2. Set the simulation parameters (cf. section 8.1.1) 

3. Create/edit speed profiles (cf. section 5.2.1) 

4. Check/edit vehicle type characteristics (cf. section 5.3.1) 

5. Create vehicle compositions (cf. section 6.4.1) 

6. Open the master plan of your study area as a background image (cf. 

section 4.4) 

7. Place and scale the background image and save background image file. 

Note: Scaling the background image accurately is extremely important 

(cf. section 4.4.3) 

8. Draw links and connectors for roadways tracks and crosswalks (cf. 

section 6.3.1) 

9. Enter vehicle volumes at network endpoints and pedestrian volumes on 

crosswalks (cf. section 6.4.3) 

10. Enter routing decision points and associated routes (cf. section 6.4.4) 

11. Enter speed changes (cf. sections 6.3.3.1 and 6.3.3.2) 

12. Define conflict areas for non-signlized intersections (cf. section 6.6.2), for 

special cases you may enter priority rules, if applicable (cf. section 6.6.1) 

13. Enter stop signs for non-signalized intersections (cf. section 6.6.3) 

14. Create Signal Controls with signal groups, enter timing for fixed time or 

choose a different controller for vehicle actuated signals (e.g. VAP or 

NEMA, cf. section 6.7) 

15. Enter signal heads in network (cf. section 6.7.1) 

16. Enter detectors for intersections controlled by traffic actuated signal 

control (cf. section 6.7.2) 

17. Enter stop signs for right turns on red (cf. section 6.6.3) 

18. Enter priority rules for permissive lefts, right turns on red, pedestrian 

crosswalks (cf. section 6.6.1) 

19. Create dwell time distributions and place PT stops in network (cf. 

sections 5.2.6 and 6.5.1) 

20. Create PT lines (cf. section 6.5.2) 

21. Setup for output files, e.g. travel time segments, delay segments, queue 

counters, data collection points (cf. chapter 11). 

22. Run the simulation (cf. section 8.1). 


1 Introduction 

VISSIM is a microscopic, time step and behavior-based simulation model 

developed to model urban traffic and public transport operations and flows of 

pedestrians. 



1.1 What is VISSIM? 

The program can analyze private and public transport operations under 

constraints such as lane configuration, vehicle composition, traffic signals, 

PT stops, etc., thus making it a useful tool for the evaluation of various 

alternatives based on transportation engineering and planning measures of 

effectiveness. Accordingly, also pedestrian flows can be modelled, either 

exclusively or combined with private traffic and/or public transport. 

VISSIM can be applied as a useful tool in a variety of transportation problem 

settings. The following list provides a selective overview of previous 

applications of VISSIM: 

► Development, evaluation and fine-tuning of signal priority logic: 

VISSIM can use various types of signal control logic. In addition to the 

built-in fixed-time functionality there are several vehicle-actuated signal 

controls identical to signal control software packages installed in the field. 

In VISSIM some of them are built-in, some can be docked using add-ons 

and others can be simulated through the external signal state generator 

(VAP) that allows the design of user-defined signal control logic. Thus 

virtually every signal control (incl. SCATS, SCOOT) can be modeled and 

simulated within VISSIM if either the controller details are available or 

there is a direct VISSIM interface available (e.g. VS-PLUS). 

► Evaluation and optimization (interface to Signal97) of traffic operations in 

a combined network of coordinated and actuated traffic signals. 

► Feasibility and traffic impact studies of integrating light rail into urban 

street networks. 

► Analysis of slow speed weaving and merging areas. 

► Easy comparison of design alternatives including signalized and stop 

sign controlled intersections, roundabouts and grade separated interchanges. 

► Capacity and operations analyses of complex station layouts for light rail 

and bus systems have been analyzed with VISSIM. 

► Preferential treatment solutions for buses (e.g. queue jumps, curb 

extensions, bus-only lanes) have been evaluated with VISSIM. 

► With its built-in Dynamic Assignment model, VISSIM can answer route 

choice dependent questions such as the impacts of variable message 

signs or the potential for traffic diversion into neighborhoods for networks 

up to the size of medium sized cities. 

► Modeling and simulating flows of pedestrians - in streets and buildings - 

allow for a wide range of new applications. VISSIM can also simulate and 

visualize the interactions between road traffic and pedestrians. 


1.2 The Traffic Simulation Model 

The Traffic Simulation Model 

The simulation package VISSIM consists internally of two different parts, 

exchanging detector calls and signal status through an interface. The 

simulation generates an online visualization of traffic operations and offline 

the generation of output files gathering statistical data such as travel times 

and queue lengths. 

The traffic simulator is a microscopic traffic flow simulation model including 

the car following and lane change logic. The signal state generator is a 

signal control software polling detector information from the traffic simulator 

on a discrete time step basis (down to 1/10 of a second). It then determines 

the signal status for the following time step and returns this information to the 

traffic simulator. 

Communication between traffic simulator and signal state generator 



Car following logic (Wiedemann 1974) 

The accuracy of a traffic simulation model is mainly dependent on the quality 

of the vehicle modeling, e.g. the methodology of moving vehicles through the 

network. In contrast to less complex models using constant speeds and 

deterministic car following logic, VISSIM uses the psycho-physical driver 

behavior model developed by WIEDEMANN (1974). The basic concept of 

this model is that the driver of a faster moving vehicle starts to decelerate as 

he reaches his individual perception threshold to a slower moving vehicle. 

Since he cannot exactly determine the speed of that vehicle, his speed will 

fall below that vehicle’s speed until he starts to slightly accelerate again after 

reaching another perception threshold. This results in an iterative process of 

acceleration and deceleration. 

Stochastic distributions of speed and spacing thresholds replicate individual 

driver behavior characteristics. The model has been calibrated through 

multiple field measurements at the Technical University of Karlsruhe (since 

2009 KIT – Karlsruher Institut für Technologie), Germany. Periodical field 

measurements and their resulting updates of model parameters ensure that 

changes in driver behavior and vehicle improvements are accounted for. 

VISSIM’s traffic simulator not only allows drivers on multiple lane roadways 

to react to preceding vehicles (4 by default), but also neighboring vehicles on 

the adjacent travel lanes are taken into account. Furthermore, approaching a 

traffic signal results in a higher alertness for drivers at a distance of 100 

meters in front of the stop line. 

VISSIM simulates the traffic flow by moving “driver-vehicle-units” through a 

network. Every driver with his specific behavior characteristics is assigned to 

a specific vehicle. As a consequence, the driving behavior corresponds to 


The Traffic Simulation Model 

the technical capabilities of his vehicle. Attributes characterizing each drivervehicle 

unit can be discriminated into three categories: 

► Technical specification of the vehicle, for example: 

- Length 

- Maximum speed 

- Potential acceleration 

- Actual position in the network 

- Actual speed and acceleration 

► Behavior of driver-vehicle units, for example: 

- Psycho-physical sensitivity thresholds of the driver (ability to 

estimate, aggressiveness) 

- Memory of driver 

- Acceleration based on current speed and driver’s desired speed 

► Interdependence of driver-vehicle units, for example: 

- Reference to leading and following vehicles on own and adjacent 

travel lanes 

- Reference to current link and next intersection 

- Reference to next traffic signal 


2 Program Installation 

VISSIM is designed to run on systems with Microsoft Windows 7 and XP 

and with Vista. 

This chapter contains the following information: 

► Technical requirements 

► Reference to the VISSIM Installation Guide 

► Access to the EXAMPLES folder 

► The VISSIM Viewer 



2.1 System Requirements 

The performance of a VISSIM simulation mainly depends on the following: 

► the number of vehicles simultaneously contained in the network 

► the number of signal controlled junctions 

► the type of signal controllers 

► the number of processor cores being used 

Using identical VISSIM input files, a faster computer will always lead to a 

faster simulation. 

VISSIM is also provided in a 64 bit edition. This makes using more than 

3 GB RAM possible. 

For very large applications (like an urban network with more than 50 signal 

controlled junctions) at least 1 GB of RAM is recommended: 

VISSIM edition Recommended memory 

32 Bit minimum 2 GB RAM 

64 Bit minimum 4 GB RAM 

As a rule of thumb one VISSIM vehicle takes about 2 kB of RAM. So if a 

simulation contains 50,000 vehicles in the network, the vehicles alone take 

up about 100 MB of RAM. Quad-Core processor machines are 

recommended. 

Hyperthreading allows for parallel calculation runs on those computers and 

the simulation speed is supported. Even while a simulation is running, 

working is more comfortable. 

To provide an optimal desktop layout when multiple windows are displayed 

simultaneously it is beneficial to use the highest resolution supported by the 

hardware configuration. At a minimum, a resolution of 1280x800 pixel should 

be used. However, we recommend a resolution of 1920x1080 for 

convenience. 

In 3D mode, simulation speed may be significantly lower by using higher 

screen resolutions. In order to increase the 3D visualization speed it may be 

useful to resize the main VISSIM window to a smaller size. 

The 3D visualization of VISSIM may run significantly slower compared to the 

2D visualization. This is due to the fact that the 3D visualization requires a lot 

more computer power. VISSIM uses Open-GL routines for the 3D visualization, 

therefore a graphics card with Open-GL support takes a lot of the 

workload and results in a faster visualization speed compared to other 

graphics cards. For up-to-date information on recommended graphics cards 

please check FAQ #6 on our website on www.ptvag.com/FAQ_VISSIM. 

We strongly recommend to use the most recent driver for your graphics card 

since simply updating the driver solves most problems that occur with the 3D 

visualization. For most graphic cards the driver update can be downloaded 

from the Internet. 


System Requirements 

In case of problems with the VISSIM 3D visualization, please make sure 

that you have installed the latest graphics driver on your computer before 

contacting the VISSIM hotline. 



2.2 Installation and Deinstallation of VISSIM 

The file VISSIM_530_INSTALLMANUAL.PDF contains the guide for the 

installation and deinstallation procedures of the VISSIM version. 

► The DVD (here, drive D:) stores this file in the folder 

D:\ONCD\DOCUMENTATION\ENG 

► After the installation, you find can the file on your PC in the folder 

C:\PROGRAM FILES\PTV_VISION\VISSIM530\DOC\ENG 

There, you can open this file in the Explorer or via the button START > ALL 

PROGRAMS > PTV_VISION > VISSIM 5.30 > DOCUMENTATION > ENGLISH 


2.3 Access to the EXAMPLES folder 

Access to the EXAMPLES folder 

For VISSIM installations with Windows 7 or Windows Vista, all VISSIM 

examples are stored in the following directory: 

PROGRAMDATA\PTV_VISION\VISSIM530\EXAMPLES 

Exceptions: instead of PTV_VISION, PTV_DEMO is used with demo 

versions and PTV_UNI for installations at academic institutions. 

For access to the EXAMPLES\ folder, you can apply either option: 

► Use the START button for direct access via the reference: 

Click START > PROGRAMME > PTV_VISION > VISSIM 5.30 > EXAMPLES 

► Use the environment variable VISSIM530_EXAMPLES, which is created 

with the installation: 

In the Windows Explorer, enter %VISSIM530_EXAMPLES% in the 

address bar and confirm. 

This directory structure and the environment variable apply to VISSIM 

installations with Windows 7 and Windows Vista. 

For Sitraffic Office installations and installations running with Windows XP, 

the VISSIM examples are installed in the same directory as the VISSIM 

EXE directory. 



2.4 The Distributable VISSIM Viewer 

Amendatory to your VISSIM installation, there is also a restricted VISSIM 

version (= VISSIM Demo version without demo examples) that VISSIM users 

can hand out to the clients along with VISSIM project data. 

These are the main restrictions of this version: 

► Network files cannot be saved. 

► Evaluation files cannot be generated. 

► Simulation runs are possible only for the first 1800s. This period cannot 

be extended in order to show longer simulation runs. If it is necessary to 

show the visualization of vehicles and/or pedestrians beyond the first 

1800s, animation files (*.ANI) can be used. For animation files there is no 

time limit. 

► The COM interface cannot be used. 

How to install the VISSIM-Viewer 

Follow the steps outlined below for a download of the VISSIM Viewer setup 

package: 

1. Click www.ptv‐vision.com/download 

The Traffic Customer Service Download area opens. 

2. Enter guest and click the LOG-IN button. 

The list of available downloads appears. 

3. Select the recent version of VIEWER_VISSIM_CD.ZIP and click the 

DOWNLOAD button. 

The authentication window appears. 

4. Enter guest twice and confirm OK. 

Save the *.ZIP file to your hard disk. 

5. Extract the *.ZIP file and start a VISSIM Viewer session. 

For instructions on how to create a CD for your clients that contains the 

distributable VISSIM version along with project data please refer to the file 

README.TXT which is contained in the downloaded *.ZIP file. 


3 Program Handling 

Similar to other software programs, the VISSIM main window is surrounded 

by a menu bar and several toolbars which can freely be placed on screen 

and can be customized by the user. 



3.1 The VISSIM Desktop 

The desktop of VISSIM is divided into the following areas: 

Header Shows program title, version and service pack no. and also the name of the 

network file; for demo versions, “Demo” is added to the version no. 

Menu bar Access is provided via mouse click or keyboard shortcut, cf. section 3.1.1. 

Some of the menu commands point to a submenu or window: 

4 Indicates a pull-out menu. 

“...“ Indicates that a window will open. 

The last eight network files accessed by VISSIM (“most recently used files”) 

are listed in the FILE menu. Click one of hese files to open it. 

Tool bars Control network editor and simulation functions (cf. section 3.1.2). 

Status bar Shows editing instructions and simulation status (cf. section 3.1.3). 

Scroll bars Horizontal and vertical scrolling of network viewing area. 

Logo Depending on the location of the sale of the software license a logo will 

appear in the upper right corner of the VISSIM network. 

In the lower right corner, you may display a custom logo by naming it 

CUSTOM.BMP and placing it in the same directory as VISSIM.EXE. 


3.1.1 The VISSIM Menus 

The VISSIM Desktop 

Menu items can be re-arranged, inserted or removed. Also all menu 

commands can be placed inside any of the toolbars, cf. section 3.1.1.2. 

3.1.1.1 Default Menus 

FILE General file management and printing commands: 

New Initialize system (close network file without 

saving data, create new VISSIM network) 

Open Open network file 

Read Additionally Open network file in addition to the existing 

network 

Save Save network to current *.INP file CTRL+S 

Save As ... Save network to selected path & file name 

If a different path is chosen, the referenced 

files required by the network need to be 

copied manually to the new folder. 

Import Read SYNCHRO7 data from file or load 

Abstract Network Model data from VISUM, 

cf. section 6.2.1 

Export Start data export to VISUM or to 3DS MAX, 

cf. section 6.2.1.6 

Page Setup Set parameters for print output 

Print Preview Page preview on screen prior to printing 

Print Print output to file/device 

Open Working 

Directory 

List of most 

recently used 

files 

Opens the Windows Explorer in the current 

working directory (where the *.INP file is 

stored) 

List of most recently used network files. 

The list is updated whenever an *.INP file is 

either opened or saved with a new file 

name. Update is performed before the FILE 

menu is opened. That is why all parallel 

running instances of a single main version 

(5.20) share a single list. 

Exit Terminate session, close VISSIM 

EDIT Network editing commands: 

Undo Undo functionality for construction element 



editing (Pedestrians add-on): Undoes the 

previous action. 

Redo Redo functionality for construction element 

editing (Pedestrians add-on): Redoes the 

previously undone action. 

Delete Delete selected Links/Connectors and/or 

Nodes 

Split Link Splits the selected link F8 

Combine Routes Combines static routes 

3D Signal Heads Enables the 3D Signal Heads editing mode 

and displays 3D signal head locations in 2D 

Selection Mode Allows for selection of the Standard (Single- 

Select), Multiselect or Label mode for 

network editing 

Selection List Calls the list of network elements for the 

currently active network editing mode 

Check 

Nodes/Edges 

Only in the Nodes mode: Checks the 

nodes/edges structure for damages 

Edge Selection Active only in Nodes mode: Opens the list of 

all edges of a Dynamic Assignment 

Auto Routing 

Selection 

Active only in Routes mode or Parking Lots 

mode: Opens the list of all paths of a 

Dynamic Assignment 

Rotate Network Rotates the entire network around (0,0) 

Translate 

Network 

Moves the entire network in x, y and/or 

z direction 

VIEW Commands and options for display on screen: 

Options Set general display options 

36 VISSIM 5.30-05 © PTV AG 2011 

DEL 

CTRL+H 

Level Display Define 3D display for pedestrians add-on 

Center Line Toggle center line display CTRL+A 

3D Mode Toggle 2D/3D display mode CTRL+D 

Network 

Elements 

Show Network 

Elements 

Configuration of the multiple network 

elements display 

Switch on/off display of network elements CTRL+N 

Background Load and configure background image 

file(s)

Show 

Background 


Toggle background display CTRL+B 

Status Bar Select simulation time display format 

Load Settings... Open VISSIM settings file *.INI 

Save Settings… Save VISSIM settings file *.INI 

BASE DATA User-editable base data for the simulation: 

Functions Cf. section 5.1 

Distributions Cf. section 5.2 

Emission Parameters for Cold Emission module 

Vehicle Types Cf. section 5.3.1 

Vehicle Classes Cf. section 5.3.2 

Driving Behavior Cf. section 5.4 

Link Behavior 

Types 

Cf. section 5.5.1 

Pedestrian Types Cf. section 7.1.2 

Pedestrian 

Classes 

Cf. section 7.1.3 

Walking Behavior Cf. section 7.1.9.1 

Area Behavior 

Types 

Cf. section 7.1.9.2 

Display Types Display options for links and construction 

elements, cf. section 5.5.2 

Level Properties Definition for Multiple Levels Add-on 

(currently for pedestrians only) 

TRAFFIC User-defined vehicle/pedestrian flow data: 

Vehicle 

Compositions 

Pedestrian 

Compositions 

External Vehicle 

Course Files 

Dynamic 

Assignment 

Dynamic 

Assignment - 

Traffic compositions for vehicular traffic, cf. 

section 6.4.1 

Traffic compositions for pedestrian traffic, cf. 

section 7.1.6 

Display of externally created vehicle data, 


Parameters for Dynamic Assignment, 


Starts the automatic VISUM assignment 

calculation 



SIGNAL 

CONTROL 

VISUM 

Assignment 

Toll Pricing 

Calculation 

Models 

Managed Lanes 

Facilities 

Data input for Signal Control: 

Definition for managed lanes 

Definition for managed lanes 

Edit Controllers Create/Edit/Delete signal controllers, 


Communication Link/Unlink signal controllers, 


Optimize All 

Fixed Time 

Signal 

Controllers 

Starts the greentime optimization of all the 

stage-based fixed time controllers in the 

network, cf. section 6.7.3.11 

EVALUATION Select evaluation type(s) and set parameters: 

Windows Configuration of online evaluations, cf. 

chapter 10 

Files Configuration of off-line evaluations, cf. 

chapter 11 

Database Database configuration for evaluations, 


Analyzer Reports Production of report-ready evaluations of 

simulation runs, cf. section 11.24 

SIMULATION Simulation parameters and run control: 

Parameters Set simulation parameters, cf. section 8.1.1 

Continuous Run simulation continuous F5 

Single Step Run simulation one step further F6 

Stop Stop the simulation run ESC 

Multirun Set parameters and start Multirun 

simulation, cf. section 8.1.3 

Load Snapshot Load simulation snapshot file, cf. section 

8.1.2 

Save Snapshot Save current simulation state as snapshot 


PRE- 

SENTATION 

file *.SNP 

Create and control a simulation presentation, cf. chapter 9: 

3D Video 3D Mode only: Set parameters for video 

recording, cf. section 9.2 

AVI Recording 3D Mode only: Toggle *.AVI file recording, 


Animation 

Parameters 

Set parameters for recording an animation 

file, cf. section 9.1 

ANI Recording Toggle *.ANI file recording, cf. section 9.1.1 

ANI.TXT 

Recording 

Saves the trajectories of vehicles and 

pedestrians to a text file for import in 

Autodesk´s 3ds Max software 


Continuous Run continuous animation F5 

Single Step Run animation one step further F6 

Stop Stop the animation run ESC 

Single Step 

Backwards 

Continuous 

Backwards 

Run animation one step backwards 

Run animation continuously backwards 

TEST Test of signal control without traffic simulation, cf. section 8.2: 

Continuous Run continuous test F5 

Single Step Run test one step further F6 

Stop Stop test run ESC 

Macro Define/Edit macros for test runs 

Loop Batch mode operation for test runs 

Recording Toggle macro recording for test run 

SCRIPTS Access to script files, cf. section 3.5.1: 

Run script file Open and run script file (*.VBS, *. PYS, 

*.PY, *.JS) 

HELP Information on current VISSIM version, Service and Contact, cf. chapter 15: 

Online Help Opens the online help F1 



License Shows details of the current license 

Log Window Lists messages on screen, cf. section 10.2.1 CTRL+ 

Info Info about VISSIM and contact information 

3.1.1.2 Customizing Menus 

SHIFT 

+F10 

Menu commands can be re-arranged, new commands inserted or exiting 

ones removed. A copy of a submenu can be placed outside the menu area 

either as a toolbar or floating window. Menu commands can also be placed 

inside of any toolbar. 

In case of customized VISSIM menus it might be difficult for you to locate 

menu commands that are referenced in the manual or by the hotline. 

To tear away a copy of a sub-menu from its original location 

1. Drag the menu at the “grip” section (between the title 

and the commands) and pull it to the desired location. 

2. The sub menu is shown as a floating 

toolbar. 

3. Now you can also dock this menu 

to any border of the main VISSIM 

menu. 


To edit the menu content 

1. Right click inside the menu area. A context menu 

appears. 

2. Choose CUSTOMIZE... to call the Customize window. 


3. While being in the Customize mode you may do the 

following: 

- Add a menu command: 

On the [COMMANDS] tab, choose the desired 

command and drag it with the mouse to the 

desired position inside an existing menu. 

- Move a menu command: 

Drag the command with the mouse to the 

desired position. 

- Remove a command from a menu: 

Drag the command outside any menu. 

- Reset a menu to its VISSIM default: 

Right-click on that menu and choose RESET from the context menu. 

- Reset the entire menu structure to its VISSIM default: In the 

[TOOLBARS] tab, click RESET... and confirm with Ok. 

3.1.2 The VISSIM Toolbars 

VISSIM offers toolbars that can be docked to any position along the four 

borders of the main VISSIM window. Toolbars can also be torn away from 

the toolbar area and placed as a floating window. To hide or show a certain 

toolbar, right click inside the toolbar area and choose the desired toolbar 

from the context menu. 

Depending on the current edit and graphics mode, not all of the buttons 

might be available. Buttons that are disabled are shown colorless. 

3.1.2.1 Default Toolbars 

FILE General file management and printing commands: 

Create new VISSIM network file 

Open existing VISSIM network file 

Save VISSIM network file to given path / file name CTRL+S 

Print Preview 

Print 



SELECTION Defines the edit mode in combination with the selected network element: 

PEDESTRIAN 

MODE 

Single-select mode (Standard) 

Multi-select mode 

Label position mode. Any labels of network 

elements (e.g. of signal heads) can be relocated 

while the edit mode of that network element is 

active. 

If several links/connectors are located at the mouse 

click position click this button to browse through all 

these links/connectors. 


TAB 

Pedestrian mode add-on for modelling and simulation of pedestrian flows. 

For the Pedestrian elements toolbar, please see below. 

Toggles between vehicular and pedestrian traffic 

mode. 

SIMULATION The toolbar for SIMULATION run control is visible by default. 

There are additional toolbars for ANIMATION or TEST runs. Furthermore there 

is the RUN CONTROL toolbar which controls the most recently used run mode. 

All of these additional toolbars are not visible by default. 

Run simulation continuous F5 

Run simulation one step further F6 

Stop simulation ESC 

NAVIGATION Commands for changing the observer position within the network. 

Show entire network 

Dynamic zoom (left click or mouse wheel), 

Previous view (right click) 

Zoom by factor 

PAGE UP, 

PAGE DOWN 

Move network (3D only, shortcuts also in 2D) ,,, 

Rotate network (3D only) 

Fly through network (3D only)

NETWORK 

ELEMENTS 


In the vehicular traffic mode a new element of the corresponding type can be 

created or existing items of this type can be edited, while one of the following 

buttons is pressed. For details by element please refer to chapter 6 if not 

stated otherwise. 

Links and connectors 

Pavement Markers (Graphics only) 

Vehicle inputs 

Routing decisions and routes (to direct traffic within the network) 

Desired speed decisions (permanent change of vehicle speed) 

Reduced speed areas (temporary change of vehicle speed) 

Priority rules (e.g. for non-signalized intersections) 

Conflict areas 

Stop signs 

Signal heads 

Signal detectors 

Public transport stops 

Public transport lines 

Cross section measurements (cf. chapter 11) 

Travel time and delay measurements (cf. chapter 11) 

Queue counters (cf. chapter 11) 

Parking lots / zone connectors (cf. chapter 12) 

Nodes (some VISSIM licenses also allow for node evaluation 

independently of Dynamic Assignment; cf. chapter 12) 



PEDESTRIAN 

MODE 

ELEMENTS 

In the pedestrian traffic mode a new construction element of the 

corresponding type can be created or an existing item can be edited while 

one of the upper three buttons is pressed. The buttons underneath serve for 

definition of pedestrian inputs or routes and evaluations as well. For details 

please refer to chapter 7 if not stated otherwise. 

Pedestrian areas 

Pedestrian obstacles 

Pedestrian ramps 

Inputs of pedestrian flows 

Routes of pedestrians 

Measurement areas of pedestrians 

Travel times of pedestrians 

3.1.2.2 Customizing Toolbars 

Buttons of toolbars can be re-arranged, inserted or removed. New toolbars 

can be created. Also menu commands are available to be placed inside any 

of the toolbars. 

If you customize VISSIM toolbars it might be difficult for you to locate 

buttons that are referenced in the manual or by the hotline. 

Editing the toolbar content 

1. Right click inside the toolbar area. The context 

menu appears. 

2. Choose CUSTOMIZE... to open the Customize window 

3. In the [TOOLBARS] tab you may 

- Enable/Disable a toolbar: 

Toggle the checkbox in the list of Toolbars 

- Create a new toolbar: 

Press NEW... and choose the desired name and 

position of the new toolbar. Then confirm with 

OK 

- Rename/Delete a custom toolbar: 

Press the corresponding buttons (the standard 

VISSIM toolbars cannot be removed or deleted) 

- Reset to VISSIM defaults: Press RESET... and 

confirm with Ok 



4. In the [COMMANDS] tab you may 

- Add a menu command to a toolbar: 

Choose the desired command and drag it with the mouse to the 

desired position inside an existing toolbar 

- Move a button/command to another toolbar: 

Drag the button to the desired position inside another toolbar 

- Remove a button/command from a toolbar: 

Drag the button outside any toolbar. 

3.1.3 How to Reset Customized Menus, Toolbars and Windows 

1. Close the VISSIM session. 

2. In the Explorer, open the EXE 

folder of your VISSIM 

installation and double-click 

VDIAGGUI.EXE. 

3. In the [ACTION] tab, left-click the 

appropriate button: 

- RESET TOOLBAR AND MENU 

or 

- RESET WINDOW POSITIONS 

This will take effect when the 

next program session starts. 

For details on the support 

functionality of this diagnostics 

tool, please refer to section 

10.2.2.2. 



3.1.4 The VISSIM Status Bar: Data Output 

The status bar is divided into three sections. Depending on the current 

program mode each section displays different data: 

Section 1 2D Graphics: 

► Current cursor position (x, y coordinates in meters, “world 

coordinates”) 

3D Graphics: 

► All modes except flight mode (only if not in any run mode): 

Current position (x, y, z coordinates in meters) of that part 

of the network, that is displayed at the center of the VISSIM 

window at ground level. 

► Flight mode: Current camera position (x, y, z coordinates in 

[m]). 

Section 2 Network editing: 

► Number of selected link/connector 

► Position within selected link/connector (if mouse is inside 

selected link) 

Simulation: 

► Current simulation time and local cycle time 

Cf. section 4.1.6: The default shortcut CTRL-U toggles 

between the display types of the simulation time. 

3D Graphics (Flight mode, not during simulation): 

► Focal point position (the point the ‘plane’ is aiming for; x, y, 

z coordinates in meters) 

Section 3 Network editing: 

► Editing instructions 

Network editing (3D-Zoom, Rotate, Pan): 

► Current observer position (d, A, C): 

- d = distance (in meters) above level 0.0 m 

- A = angle between XZ-plane and observer 

- C = angle between XY-plane and observer 

Simulation: 

► Number of vehicles currently in the network 

► Speed factor (actual simulation speed compared to real 

time) 

► In parentheses: Number of vehicles that could be simulated 

at real time (displayed only if simulation speed = maximum) 

► When command line parameter -s was used to start 

VISSIM: 

No. of current simulation run and (total number of runs). 


3.2 Keyboard and Mouse Operation 

Keyboard and Mouse Operation 

The information provided in section 3.2.1 applies to the general philosophy 

that is widely used for the VISSIM network editor (as far as it is not overruled 

by standard Windows behavior). 

3.2.1 General Behavior 

Right 

mouse key 

Left mouse 

key 

Middle 

mouse key 

Mouse 

wheel 

Click outside the network: Calls a list of all defined elements 

of the current edit mode. Here, the ZOOM button can be used 

to focus on the network section where the network element is 

located. 

Click inside the network (e.g. on a link): Inserts a new 

element. 

Single-click: Select an existing element. 

Double-click: Open the associated properties window. 

Panning the network display 

Up = Zoom in / Down = Zoom out 

RETURN Corresponds to a mouse click on the highlighted button 

(usually the OK button). 

ESC Corresponds to a mouse click on the CANCEL button. 

DEL Deletes a selected network element. 

3.2.2 The VISSIM Shortcuts (Hotkeys) 

VISSIM offers a selection of default keyboard shortcuts (hotkeys). 

It is also possible to create your own shortcut for any of the VISSIM menu 

commands and/or to change the existing shortcuts, cf. section 3.2.2.2. 

In order for a shortcut to be executed, the main VISSIM window needs to be 

active. 

If you customize VISSIM shortcuts it might be difficult for you to locate 

shortcuts that are referenced in the manual or by the hotline. 



3.2.2.1 Default Shortcuts 

CTRL+A Toggles between Center Line and the last active link display 

mode (either Normal or Invisible). 

CTRL+B Toggles the display of loaded background images. 

CTRL+C Copies the selected 3D signal, continue with CTRL+V. 

CTRL+D Toggles between 2D edit mode and 3D display mode. 

CTRL+H Toggles the display of 3D signals. 

CTRL+L Loops through all LOS definitions during the simulation of 

pedestrians in aggregate data display mode. 

CTRL+M Toggles the display of the compass. 

CTRL+N Toggles the display of network elements/labels. 

CTRL+Q Controls the visualization mode (3 states: normal visualization 

of individual vehicles/pedestrians / alternative 

display of aggregate values for vehicles on links or of 

pedestrians on construction elements / no visualization). 

While the pedestrian simulation is running in aggregate data 

display mode, the currently selected LOS type is displayed in 

the status bar when looping via CTRL+L. 

CTRL+T Toggles the color of links and walkable elements: either 

display type specific color or global color, cf. section 4.1.3 

CTRL+U Toggles the type of display of the simulation time within the 

status bar (either seconds or time of day). 

CTRL+V Toggles the extended vehicle display, cf. section 4.2.2. 

CTRL+Z Dynamic Assignment only (while in Parking Lots mode): 

Shows the centroids of all parking lots that belong to the 

same zone. Cf. section 12.7.2 for details. 

CTRL+ 

SHIFT+C 

Dynamic Assignment only: Sets the relative volumes of all 

parking lots to the volume totals of their paths in the current 

path file *.WEG. Cf. section 12.7.2 for details. 

TAB Moves to next link or connector layer (when clicking at a 

position with at least two links/connectors). 

F5 Simulation Continuous: 

Starts/continues continuous simulation. 

F6 Simulation Step: Executes next simulation time step. 

ESC Simulation Stop: Ends the simulation. 

ENTER (during a simulation run only:) 

Switch to continuous simulation. 

SPACE (during a simulation run only:) 

Executes next simulation time step. 


Keyboard and Mouse Operation 

+ Increase simulation speed (depending on computer 

performance) 

- Decrease simulation speed 

* Maximum simulation speed (depending on computer 

performance) 

/ (if maximum speed is active:) Back to last speed value 

1 Simulation speed real time (1.0s) 

HOME Display entire network 

BACKSPACE Back to previous view 

PGUP, PGDN Zoom in/out (fast) 

T, G Zoom in/out (slow) 

,,, 

or E, D, S, F 

Scrolls the screen. To speed up moving, hold down 

simultaneously. 

K, I 3D mode only: Tilt the network plain up/down 

J, L 3D mode only: Rotate the network around the z-axis 

Q, A 3D mode only: Moves the current observer camera vertically 

(like an elevator). To speed up moving, hold down 


CTRL+PGUP, 

CTRL+PGDN 

3.2.2.2 Customizing Shortcuts 

1. Right click in the 

toolbar area. 

2. Select CUSTOMIZE... 

from the context 

menu. The Customize 

window opens. 

3. Press KEYBOARD... 

The Customize 

Keyboard 

opens. 

window 

4. Out of the Categories 

list, select a command 

category. On 

the right, select the 

command for which 

you would like to add 

a shortcut. 

3D mode only: Increase/Decrease the focal length of the 

observer camera (telephoto/wide-angle). 



5. Choose the desired 

shortcut from the 

selection list. If the 

selected shortcut has 

been assigned to 

another command already, 

the command 

is shown below the 

selection list. 

6. Press ASSIGN to 

confirm your selection. 

In case the 

shortcut was already 

assigned to another 

command, this assignment 

is deleted. 

7. Close both windows 

by pressing CLOSE. 


3.3 Selection of Network Elements 

Selection of Network Elements 

The selection mode defines the way and what portion of network elements 

can be selected for editing. 

► In 2D display mode, all three selection modes are available. 

► In 3D display mode, only the standard selection mode is available. This 

is due to the fact, that all network elements except static 3D objects can 

only be edited in 2D mode. 

3.3.1 Standard (Single-Select) Mode 

To select a network element and access its data the corresponding edit 

mode needs to be active. Except for links and nodes all network elements 

need to be placed on a link or connector. 

To place such an element follow the steps outlined below: 

► Select the desired element edit mode 

► Mark the desired link or connector by a single left click 

► Follow the instructions how to create a new element of that type 

While an element edit mode is active, a single element can also be selected 

by its number. This is done by selecting the desired element out of the list of 

all network elements of that type. There are two ways to open this list: 

► Right click outside the VISSIM network (not clicking on a link or 

connector) 

► Click menu EDIT – SELECTION LIST... 

The element type is displayed in the 

window title along with the total number of 

instances of this type. 

From that list, the properties of each 

network element are available (DATA...) 

and also the location can be found (ZOOM). 

In a large network it might be helpful to 

use the ZOOM BY FACTOR command 

additionally after pressing the ZOOM button 

to see the surrounding area of the 

selected network element. 



3.3.2 Multi-Select Mode (2D only) 

Currently the multi-select mode is available for processing of network 

elements being located completely within the selection: 

► Editing certain properties of links and connectors 

► Moving links, connectors and nodes 

► Deleting links, connectors and nodes 

3.3.2.1 Multiselection of Network Elements 

► Keep left mouse-key pressed while spanning a rectangle. 

All elements being located completely inside are selected: 

- Links and connectors 

- Node polygons 

► Links/connectors can be added to the selection (independent of their 

previous state) by pressing SHIFT while drawing the rectangular selection 

box. 

► Links/connectors can be removed from the selection (independent of 

their previous state) by pressing CTRL while drawing the rectangular 

selection box. 

► Toggle functionality: Left-click the a single link/connector or node to add 

the single element to the selection or to remove ir from the selection. 

► The entire selection can be cancelled by clicking outside the selection 

while pressing CTRL. 

► All links/connectors in the selection can be moved by clicking inside the 

selection. 

Connectors that connect two selected links are moved together with the 

corresponding links - even if the connector itself is not included in the 

selection. 

If intermediate points of a connector should not be moved (along with 

the start and end points) such a connector needs to be deselected and 

CTRL must be pressed while moving the selection. 

► The following applies to nodes defined by link segments (exported from 

VISUM) 

- Segment nodes in the polygon are not highlighted as if being 

selected. 

- Their status selected / not selected cannot be changed by mouseclick. 

- They are not affected by moving links - only the position of labels 

may change. 

- Even if being not selected, segment nodes inside the polygon are 

deleted like selected polygon nodes. 


3.3.2.2 Properties & Options: Editing in Multiselect Mode 

Selection of Network Elements 

The properties of all selected links and connectors can be accessed by right 

mouse click (for link evaluations, cf. chapter 11.11). The following attributes 

can be changed (for details please refer to the sections Links and 

Connectors in section 6.2.2.4): 

● Behavior Type: If the original 

values are not identical for all 

links, select the entry 0 Keep old 

values to retain these values for 

all links. 

● Display Type: ditto 

● Gradient 

● Thickness (3D) 

● Link Evaluation 

● Segment length of links 

● Visualization (of vehicles) 

● Label 

● COST calls the Link Cost window 

● LANE CLOSURE calls the Lane Closure window 

● CONNECTORS calls the Connectors (Multiselection) window. 

Here the following connector attributes can be edited additionally: 

- Emergency Stop position 

- Lane Change position 

- Recalculate Spline: If this 

option is active, you can either 

keep the number of points 

given by connector or you can 

enter the new number of 

points which is to be applied 

for curve calculation to all of 

the selected connectors. 

- Vehicle class closure (for 

Dynamic Assignment only) 

- Direction: If two or more connectors within the selection have 

different Direction values then the default is set to Keep Values (i.e. 

all connectors remain unchanged). To change all connectors to the 

same value, select the desired Direction. 



3.3.3 Label Mode (2D only) 

If any of the labels of network elements are visible (cf. section 4.2.1), these 

labels can be moved in label mode. 

To move a label, the corresponding network element mode needs to be 

active. E.g., to move the visible label of a signal head, the Signal heads 

mode must be active. The position of each label is stored in the VISSIM 

network file *.INP. 


3.4 The VISSIM Command Line Operations 

The VISSIM Command Line Operations 

VISSIM can also be controlled from the command line prompt. In order to get 

results from an input file run in batch mode, the desired evaluations must be 

specified in the VISSIM.INI file used by the VISSIM executable. The VISSIM 

executable uses the VISSIM.INI file in the directory where it is called from. 

Therefore the VISSIM.INI file you use must be stored in the same directory 

as the batch file. 

The following table shows the optional parameters and their functionality: 

Loads the input file. 

-b Loads a background bitmap and zooms in according to 

the information contained in the *.INI file (only works in 

conjunction with an input filename). An *.INI file can be 

saved using VIEW – SAVE SETTINGS... in the main menu. 

Example: VISSIM.EXE LUX567.INP -BLUX567.INI 

-d 

opens VISSIM with the network file LUX567.INP and 

the options file LUX567.INI. 

Sets the number of decimal places for the evaluation 

files to . The following evaluations are regarded: 

► Analyzer output 

► Node evaluation 

► Link evaluation 

► Vehicle protocol 

► Pedestrian protocol 

-nopathfile Dyn. Assignment: Do not save path file. 

-nocostfile Dyn. Assignment: Do not save cost file. 

-nosearchpaths Dyn. Assignment: Do not perform short path search. 

-regserver 

-unregserver 

Register/unregister VISSIM as COM server. The main 

VISSIM window is briefly shown in case of successful 

registration, otherwise a message box appears. 

-s Starts and runs the simulation times. Any noncritical 

runtime errors will not display a message box. 

The status bar shows the number of the current run. 

Refer to section 8.1.3 for another method of running 

multiple simulation runs with VISSIM. 

-threads 

[2 ≤ n ≤ 8] 

In the simulation kernel, VISSIM uses multithreading. 

Thus a simulation can run much faster on multiprocessor 

or multicore PCs using this option. 

-v The volume flag is only used with Dynamic Assignment 

(optional module) and the number following is the 

percentage that - during each simulation run - is added 

to the percentage specified in the Dynamic Assignment 

window as Scale Total Volume to [%]. The volume will 



increase by this percentage every run until 100% is 

reached. Further runs will be performed with 100%. 

Example Example for running VISSIM from a batch file: 

C:\VISSIM\EXE\VISSIM.EXE C:\VISSIM\EXAMPLE\KING.INP -S7 -V10 


3.5 The COM Interface (Optional Module) 

The COM Interface (Optional Module) 

VISSIM offers an additional module which provides COM (component object 

model) functionality for use with external programming environments (e.g. 

VBA in Microsoft Excel). This way it is possible to automate certain tasks 

in VISSIM by executing COM commands from an external program. 

A list of all available functions and commands in the COM interface is 

included in the documentation VISSIM_COM.PDF which is contained in the 

folder \DOC. 

Please note that neither the external COM interface nor the SCRIPTS menu is 

provided with VISSIM demo or viewer versions, cf. section 2.4. 

3.5.1 Loading and Running Scripts in VISSIM 

Example 

*.VBS 

External scripts can be read from file interactively via 

menu SCRIPTS - RUN SCRIPT FILE. 

The execution of the script will start automatically then. 

Open script file 

► Click menu SCRIPTS – RUN SCRIPT FILE. 

► The window Open Script File appears. 

► Select a file and click OPEN. 

In VISSIM, script files have the extensions *.VBS, *.JS, *.PYS or *.PY. 

Notes to users starting a script file interactively 

The global variable Vissim can be used throughout the script without prior 

initialization. It always refers to the VISSIM instance from which the script is 

run. 

This object Vissim on top of the script file has not been created with 

CreateObject, because VISSIM is already running (it is possible however, to 

do so if further Vissim instances are needed in the script). Scripts can use 

the entire command set of the Visual Basic Scripting Edition (VBS), e.g. 

loops, if-then-else, I/O functions and error handling. Scripts may not contain 

any global declarations. 

This script serves for dividing all input flow volumes by two: 

Set all_flows = VISSIM.Net.VehicleInputs 

For i = 1 To all_flows.Count 

all_flows(i).AttValue("VOLUME") = 0.5 * all_flows(i).AttValue("VOLUME") 

Next 



3.5.2 Python as Script Language 

Example 

*.PYS 

VISSIM additionally supports Python besides VBA/VBS. Python is 

characterized by its very comfortable functions, e.g. for chart creation as well 

as for the development of functions of user surfaces. Python provides for the 

setup of a user guidance tailored to a particular project. 

Python and all additional libraries are open source programs without any 

confinements concerning their use. 

As a precondition, the Python interpreter and the PythonWin supplement 

providing Python with a COM functionality have to be installed first. 

PTV provides a library of scripts for a great variety of tasks. They can 

easily be used by the user and modified according to their own requirements. 

In the future, these scripts will be provided on the PTV website. 

As an example of the possibilities of the script language, the following 

example file serves for dynamic changes to the state of static 3D objects: 


The COM Interface (Optional Module) 

# Python Script sample for VISSIM 

# Copyright (C) PTV AG. All rights reserved. 

# SB, VR 2006-07-25 

# 

# This code demonstrates the use of the following interfaces for the simulation of a 

# car park with access control and available free places information: 

# - ISignalControllers and ISignalGroups 

# - IDetectors: Use of the attributes PRESENCE and IMPULSE 

# - IStaticObjects: Use of the attribute STATE to change 3D state during simulation time 

#======================================================= 

import win32com.client 

#constants 

#======================================================= 

NAREAS = [0, 1, 2] 

GREEN = 2 #signal group type #permanent green# 

RED = 3 #signal group type #permanent red# 

OPENEDTIME = 5 #opened barrier time 

NPLACES = 11 #number of places 

#======================================================= 

#initialize global variables 

#======================================================= 

Sim = VISSIM.Simulation 

SgCtrls = VISSIM.Net.SignalControllers 

SgGrps = [SgCtrls.GetSignalControllerByNumber(i+1).SignalGroups.GetSignalGroupByNumber(1) 

for i in NAREAS] 

[SgGrps[i].SetAttValue("TYPE", RED) for i in NAREAS] 

StObjs = VISSIM.Net.StaticObjects 

Barriers = [StObjs.GetStaticObjectByName('Barrier0' + str(i+1) + '.v3d') for i in NAREAS] 

[Barriers[i].SetAttValue("STATE", 0) for i in NAREAS] 

BarrierOpening = [False for i in NAREAS] 

BarrierClosing = [False for i in NAREAS] 

Dets = [SgCtrls.GetSignalControllerByNumber(i+1).Detectors for i in NAREAS] 

DetsIn = [Dets[i].GetDetectorByNumber(11) for i in NAREAS] 

DetsPass = [Dets[i].GetDetectorByNumber(12) for i in NAREAS] 

DetsOut = [Dets[i].GetDetectorByNumber(91) for i in NAREAS] 

VehEntering = [False for i in NAREAS] 

VehParked = [0 for i in NAREAS] 

CtrName = [['Counter_P0' + str(i+1) + j + '.v3d' for i in NAREAS] for j in ['a', 'b']] 

#======================================================= 

#control detector for the entrance, pass and exit 

#======================================================= 

def ControlEntrances() : 

#Through all entrances for i in NAREAS : 

#if vehicle is on the entrance and no entrance is being processed 

#then start enter process 

if DetsIn[i].AttValue("PRESENCE") and not VehEntering[i] : 

VehEntering[i] = True #start entrance process 

BarrierOpening[i] = True #start open barrier process 

#did the entering vehicle enter? 

if VehEntering[i] and DetsPass[i].AttValue("PRESENCE") : 

SgGrps[i].SetAttValue("TYPE", RED) #don't allow to enter 

BarrierClosing[i] = True #start closing barrier 

#======================================================= 

#open and close barriers appropriately 

#======================================================= 



def ControlBarriers() : 

#through all barriers for i in NAREAS : 

if BarrierOpening[i] : #opening barrier 

if Barriers[i].AttValue('STATE') < Barriers[i].AttValue('NSTATES') - 2 : 

Barriers[i].SetAttValue('STATE', Barriers[i].AttValue('STATE') + 1) #opening 

if Barriers[i].AttValue('STATE') == Barriers[i].AttValue('NSTATES') - 2 : # opened 

BarrierOpening[i] = False 

SgGrps[i].SetAttValue('TYPE', GREEN) #allow vehicle to enter 

if BarrierClosing[i] : #closing barrier 

if Barriers[i].AttValue('STATE') > 0 : 

Barriers[i].SetAttValue('STATE', 

Barriers[i].AttValue('STATE') - 1) #closing 

if Barriers[i].AttValue('STATE') == 0 : #barrier closed 

BarrierClosing[i] = False 

VehEntering[i] = False 

#======================================================= 

#update occupied places counters 

#======================================================= 

def CountOccupiedSpaces() : 

... 

... 

#======================================================= 

#update digit counters 

#======================================================= 

def UpdateCounters() : 

... 

... 

#======================================================= 

#start simulating 

for SimStep in range(1, Sim.Period * Sim.Resolution) : 

Sim.RunSingleStep() 

ControlEntrances() 

ControlBarriers() 

CountOccupiedSpaces() 

#update counters every second 

if (SimStep % Sim.Resolution) == 0: 

UpdateCounters() 

VISSIM.DoEvents() #allow VISSIM to handle its events 

#======================================================= 


3.6 Print Output 

Print Output 

This section shows how to print the graphical network and other VISSIM 

outputs. 

3.6.1 Printing the Graphical Network 

The Graphical network (e.g. the current simulation state) can be printed or 

exported to a print file using the FILE - PRINT command. The print output of a 

VISSIM network consists of the following: 

► the current screen display 

► a legend containing program and user-defined data 

Prior to printing, the design can be checked using the FILE - PRINT PREVIEW 

command. 

Prepare Printing 

Choose the network section to be printed. 

► Size the VISSIM network window on screen and/or 

► Zoom to the desired section 



Page Setup Options 

FILE - PAGE SETUP opens the Page Setup window. The following settings are 

available: 

● Fit to page: If this option is 

- active the current network view 

will be extended to fill the 

available print space. 

- not active the current network 

view will be aligned to the top 

and left margins. 

● Landscape Format: Use landscape 

rather than portrait format. 

● Margins: Print margins (always in 

mm - independent of current unit 

settings) 

● Text Fields: Two rows for userdefined 

data (defaults: Project and 

Scenario). 

● PRINTER: calls the 

Print window of 

the operating 

system. 

Print Preview 

FILE - PRINT PREVIEW opens the Print Preview window to check the print 

output on the screen prior to printing. 


Print Output 

The language displayed in the Print Preview window depends on the 

language of the installed .NET-Framework version. 

3.6.2 Other Printouts 

In VISSIM there is no direct option to print the output data files or windows. 

Please find below ways to print this information externally. 

► Result text files can be viewed and printed with standard Windows 

applications such as Notepad. Furthermore, most output files are 

created in *.CSV format (comma/semicolon separated values) for easy 

import into spreadsheet applications (e.g. Microsoft Excel). 

► Result windows (e.g. dynamic signal timing window) can be imported 

into image processing applications (e.g. PaintShopPro) or word processors 

(e.g. Microsoft Word) using the Windows print screen 

function ALT + PRT SCREEN and the clipboard. The best results are 

achieved with the highest available monitor resolution. 

► SC Editor users please refer to section 6.7.4.10 for special output 

options. For consulting and testing purposes, the attached document 

_DESCRIPTION.* is provided as Word file and as PDF in the following 

subfolder of your VISSIM installation: ..\EXAMPLES\TRAINING\ 

SIGNALCONTROL\MANUALEXAMPLE.VISSIG\ENG 



3.7 Decimal Separator & Data Editing 

This section describes the decimal separator default settings and how to 

handle the input of decimal numbers in VISSIM. 

3.7.1 Default Settings 

In VISSIM there is no direct option to choose either decimal point or comma 

as decimal symbol for numerical values with decimal places. 

By default, the current Windows settings on your personal computer are 

regarded for data display in VISSIM windows. 

Check (and adjust, if applicable) this selection via START > SETTINGS (only 

XP) > CONTROL PANEL > REGIONAL AND LANGUAGE OPTIONS > REGIONAL OPTIONS 

(XP, or FORMATS with VISTA) tab > CUSTOMIZE… button > [NUMBERS] tab > 

Decimal symbol selection list. 

3.7.2 Data Editing 

For data input of real numbers, both decimal point and comma could be used 

equally in previous VISSIM versions. 

Resulting from the implementation of modern data grids, you should take the 

following changes into consideration for data input in the current VISSIM 

version: 

Elder edit boxes Modern data grids 

Data display Decimal point Default setting 

Data input Decimal point or comma Default setting 

For data input of decimals, preferably use the decimal separator being 

currently set as default selection via the Control panel, cf. section 3.7.1. 

A warning will be dispayed, if the entered decimal separator does not meet 

the requirements. 


4 View Settings 

VISSIM offers the display of vehicles and/or pedestrians both in 2D and 3D 

mode. Except for placing static 3D models, the 3D graphics mode is intended 

solely for presentation purposes. All network editing is to be done in the 2D 

graphics mode. 

In addition to that there is a 2D graphics mode that displays aggregated 

values by colored link segments instead of displaying each vehicle 

separately. 



4.1 Display Options 

4.1.1 Network 

This section describes the global display parameters. Most of them are 

contained in the Display Options window provided via VIEW – OPTIONS. 

Display option settings can be stored in the *.INI file, cf. section 4.5. 

VIEW - OPTIONS... - [NETWORK] contains options for displaying the link network. 

The following options are available: 

● Normal shows links in 

their full width with 

selected color. 

● Center Line displays 

only the link 

centerlines using one 

of these colors: 

- Blue: Normal links 

- Green: Links without 

visualization 

(e.g. tunnel or 

underpass) 

- Pink: Connectors 

- Red: PT stops 

● Invisible: Links are not displayed at all but will be highlighted if selected. 

This option can be used to animate the simulation on a background map. 

● Total Redraw every time step: VISSIM completely redraws the entire 

screen at every visualization interval. 

● Display Compass: Displays a compass indicating the North direction. 

Double click inside the compass toggles the edit mode where the 

following actions can be done: 

- Rotate: Click and drag the mouse to change the North orientation. 

- Translate: Click and hold down SHIFT while dragging the mouse to 

move the compass to the desired location. 

As long as this option is active, the user-defined North direction is regarded 

for any directions listed in Node Evaluation output files, cf. section 11.12. 

If the compass is not set by the user, "up" is still North, by default. 


Display Options 

● Lane marking (width) defines the pixel width used to display the lane 

markings on multiple lane links (0 = no display). 

● Minimum lane width defines the minimum width for lane display. (This 

takes effect only during a simulation run using the Aggregated values 

display mode and during route or PT line editing.) 

4.1.2 Vehicles 

The default shortcut CTRL+A toggles between the last selected display (of 

either normal or invisible mode) and center line display. 

In 3D mode when displaying a background during the simulation, VISSIM 

automatically refreshes the background every time the vehicles move. 

When the link display is switched off (option invisible) the vehicle 

movements are shown directly on the background map. 

The options provided for visualization of road users and for display of 

compiled data gained from vehicular or pedestrian traffic are almost alike for 

vehicles on links and pedestrians on areas and ramps or stairways. 

For display of pedestrians, please refer to section 7.3. 

This section describes the options for the visualization of vehicular traffic in 

the link network, which can be accessed via VIEW - OPTIONS... - [VEHICLES]. 


● Individual vehicles: Each vehicle is animated separately. They are 

represented as colored, rounded boxes (2D) or by a 3D model from the 



4.1.3 Colors 

model distribution which has been assigned to the vehicle type (3D) via 

BASE DATA – DISTRIBUTIONS – 2D/3D MODEL…. 

- CONFIGURATION: Select the parameter for colored vehicle display, 

enter the upper limit by class and set the color by class for display of 

vehicles, cf. section 4.2.2. 

- Interval defines that only every th frame of the visualization will 

be updated. The default value is 1 and corresponds to a frame 

update at every simulation time step. 

● Aggregated values: If this option is active, each link segment is colored 

instead of individual vehicles. For that the color code representation of 

the parameter selected via CONFIGURATION is used. Different segment 

lengths can be defined for links and connectors and the display can be 

checked or unchecked, cf. section 6.3.1.2 and 6.3.2. 

- CONFIGURATION: Select the parameter for colored aggregate value 

visualization, enter the upper limit by class and set the color by class 

for colored display of compiled data, cf. section 4.2.3.1. 

● No visualization: Neither individual vehicles nor aggregated values are 

displayed during the simulation. Use this option to maximize simulation 

speed. 

Click CTRL-Q to activate the next of these three display options during a 

simulation (Individual vehicles / Aggregated values / No visualization). 

The visualization of traffic requires a substantial amount of computing time. 

Turning off the visualization increases the simulation speed. Another option 

to increase the simulation speed is to increase the interval of frame 

updates for the visualization (Interval). 

VIEW - OPTIONS... - [COLORS] contains color options for scene and network as 

well as options for bitmap display. 




● Press the appropriate colored buttons next to Sky, Land, Links/Areas or 

Marking to call the Color selection window and select a specific color for 

this portion of the model display on screen. 

● Use display type colors: 

If this option has been checked, each link/connector and walkable 

construction element is colored according to its display type (except in 

2D mode during a simulation run). 

If this option has not been checked, all links, connectors, areas and 

ramps/stairways are painted with the color selected for Links/Areas. 

Press CTRL+T simultaneously to toggle between link/area coloring by 

display type and global coloring. 

● SET DEFAULT COLORS resets the colors to the program defaults. 

The color chosen for Links/Areas is always used for simulation and 

animation in 2D graphics. 

Additionally, it is used for all other display modes if Use display type 

color is not checked. For obstacles, the Land color is used in this case. 

The Sky color is visible in 3D graphics mode only. 

Colors for vehicles or pedestrians are set in a different way, cf. section 

4.2.2. 

The colors of the nodes in the network are neither defined by the user nor 

set due to display type. The color of a node represents the node’s 

properties, cf. section 12.3.2.3. 

● Marking: The link/connector colors differ according to the values of the 

selected attribute. 



These attributes are available: 

- None 

- Lane closure (at least one closure to at least one vehicle class) 

- Gradient (different from 0) 

- Link evaluation (active) 

- Cost/Surcharge (at least one value different from 0) 

- Connector closure (to at least one vehicle class) 

● Bitmap Display: Changes the appearance of a background bitmap image 

in 2D display. The options are 

- More Black (emphasis on black pixels) 

- More White (emphasis on white pixels) 

- Best for colors (calculating average colors) 

● 3D Background Resolution: User-selectable maximum resolution for 

background images in 3D (raster and vector graphics). The maximum resolution 

for correct display of background images in 3D depends on the 

graphics hardware in the computer and on the number of images loaded 

at the same time. 

Options: 

- Lowest (1024) 

- Low (2048) 

- Medium (4096) 

- High (8192) 

- Tiles: If this option has been selected, the image is loaded tile by tile. 

The width (W) and height (H) of the tiles have to be entered as Tile 

Size. 

This option is recommended for large networks, if also large 

background images are used. Opening these image files may take 

some time due to file size - especially in 3D graphics mode. 

A background file being read from file in VISSIM appears as tiles on 

screen. While the tiles are being drawn in 3D mode, you may edit the 

current window section. As long as the image has not been loaded 

completely, the entire network is displayed on screen. Subsequently, the 

user-defined window section that was displayed before loading the image 

file will be displayed again. 


4.1.4 3D 


VIEW - OPTIONS... - [3D] provides options for display in 3D graphics mode. 

Default Textures 

For sky, land and for links and connectors as well as areas and ramps/stairs, 

textures (image files) may be used instead of colors. 

For each option the textures are stored separately. 

Please note that when using textures the computer performance greatly 

depends on the available memory of your graphics card. 

Click the button to call the Texture Manager for the corresponding option, 

cf. section 4.1.4.1. 

● Sky: Projects the selected texture on a half sphere that is automatically 

placed around the VISSIM network. 

The graphics card of the computer needs to be equipped with at least a 

16 bit z-buffer, otherwise the skydome is not displayed because of the insufficient 

depth resolution. 

● Land: Displays the selected texture on the land around the network. If it 

is not large enough to fill the entire land space the texture is tiled. 

● Links/Areas: Displays the selected texture tiled on all links or connectors 

and areas and ramps. 

The Default Texture selected for Links/Areas in this window can be overruled 

for any link/connector and area or ramp/stair by a different texture 

selected for its display type, cf. sections 5.5.2, 6.3.1 and 6.3.2. 



Traffic Signals 

● PROPERTY DEFAULTS opens the 3D Traffic Signal Defaults window (cf. 

4.1.4.2). 

● Display Style: Defines the way signals are displayed in 3D mode. These 

options are available: 

- Signals & Blocks 

- Signals & Stop Lines 

- Signals Only 

- Blocks Only 

- Stop Lines Only 

- None 

Level Of Detail 

User-defined LOD cutoff distances to provide simplified display of objects 

that are far away from the observer and thus speeding up 3D graphics 

display. There are several levels of simplification. Their threshold values 

(min. distance of activation) can be entered separately for each level of 

simplified display: 

● Simplified vehicle geometry beyond: Simplified display of vehicles as 

boxes with lighting, the object surfaces are painted uniformly (no “shiny” 

surfaces). 

● No lighting beyond: Simplified vehicle display as boxes without lighting. 

● Draw vehicle blocks beyond: Simplified display of vehicles as cuboids. 

These settings are saved with the *.INP file. 

4.1.4.1 The Texture Manager 

Click the appropriate button provided via VIEW - OPTIONS... - [3D] to open 

the Texture Manager for the option listed to the left. Here standard textures 

(image files) can be selected to be displayed on links/connectors, land or 

sky. 

A preview of the selected texture is shown in the right part of the window. 

While the corresponding option is enabled in VIEW - OPTIONS... - [3D], the 

selected texture is shown in the 3D mode. 

For one or multiple links/connectors, a different texture can be selected, cf. 

section 6.3.1 and section 6.3.2. The same applies to walkable construction 

elements, cf. section 7.1.4.3 and section 7.1.4.5. 

Almost every type of image files can be used to store a texture. Please 

note, that textures for links/areas and land need to have dimensions that 

are powers of 2 (e.g. 128x128, 256x128, 256x256 pixels etc.). Otherwise 

the tiling effect looks poor. 



● ADD: Opens the file selection window to load a texture file. 

● REMOVE: Removes the texture file from the selection list. The actual file 

remains intact. 

● Description: User-defined name of the texture provided as graphics file. 

● Filename: Path and name of the file. 

● Scale Factor: Defines the scale of the texture. 

When changing the selected texture, the result can be seen immediately in 

the main VISSIM window without closing the texture manager. 

4.1.4.2 Traffic Signal Default Properties 

VIEW - OPTIONS... - [3D] - PROPERTY DEFAULTS opens the 3D Traffic Signal 

Defaults window where the default settings for 3D signal heads are set. The 

defaults are stored in the *.INP file and will be applied to each newly created 

element. 



[MAST] Signal mast defaults: 

● Style: Appearance of 

the mast. 

● Scale: Percentage of 

normal size. 

● Height: Mast height 

(max: 60m). 

● Diameter: Mast diameter. 

● Light Style: Defines if a 

street light is attached 

to the mast. 

[ARM] 

● Boom length: Length of the boom incl. the light (max: 20m). 

● Attached to mast at: Mounting height of the light relative to lower end of 

the mast. 

● Style: Appearance of 

the arm. 

● Scale: Percentage of 

normal size. 

● Length: Arm length 

(max: 60m). 

● Attached to mast at: 

Mounting height of the 

arm relative to lower 

end of the mast. 

● Rotation Spacing: 

When inserting another 

arm to the same mast it 

is inserted at this angle 

relative to the orientation 

of the previously 

inserted one (counterclockwise). 

For the arm position, the direction of traffic is regarded that is currently 

selected in the simulation parameters window. 


[SIGNAL 

HEAD] 


● Layout traffic: Configuration of the signal heads for motorized vehicles. 

Various default models are provided (1-lens up to 6-lens signal heads). 

● Layout pedestrian/bike: Configuration of the signal heads for pedestrians 

and bicyclists. Various default models are provided (1-lens up to 3-lens 

signal heads, some of them with a timer, cf. section 4.3.4.3). 

● Layout public transport: Configuration of the signal head for public 

transport vehicles. Various default models are provided (1-lens up to 3lens 

signal heads). 

● Red & amber with colored arrow: If inactive a black arrow on red and 

amber light is displayed. 

● Scale: Percentage of normal size. 

● Vertical/Horizontal: Defines the orientation of the signal head. 

● Attached to mast at: Mounting height of the bottom of the signal head 

relative to lower end of the mast. 

● Horizontal offset: Defines the horizontal placement of the signal head 

front plate in relation to the mast center. 

● Rotation spacing (mast): When inserting another signal head to the same 

mast it is inserted at this angle relative to the orientation of the previously 

inserted one (counterclockwise). 

● Vertical offset (arm): Defines the vertical placement of the signal head 

center in relation to the arm center. 

● Horizontal spacing (arm): Defines the horizontal offset of the first signal 

head to the mast, and of subsequent signal heads placed on the same 

arm. Negative values define an offset to the left. 

The properties of 3D signal heads are described in section 4.3.4.3. 



4.1.5 Language & Units 

VIEW - OPTIONS... - [LANGUAGE & UNITS] allows for selection of the language 

and the units to be used. 

● Language: Select the 

language from those 

provided with the 

VISSIM installation. 

● Units: Select either a 

metric or an imperial 

unit for the following 

parameters: 

- Distance (short) 

- Distance (long) 

- Speed 

- Acceleration 

The current language will be used in menus and windows. The available 

languages depend on your VISSIM license. 

The units selected here are used in all VISSIM windows as well as in the 

output files (exception: For raw data output, almost always metric units are 

used). 

4.1.6 Simulation Time Display in the Status Bar 

Select the status bar representation of the simulation time during a 

simulation run. Two options are provided: 

► Simulation second (VIEW - STATUS BAR - SIMULATION SECOND) 

► Time of day using the format hh:mm:ss. (VIEW - STATUS BAR - TIME). 

The initial time (= time at simulation second 0) can be set in the 

simulation parameters. 

The default shortcut to toggle the time display type is CTRL+U. 


4.2 The 2D Graphics Mode 

The 2D Graphics Mode 

The VISSIM network along with the vehicles can be viewed in the network 

editor either in 2D or 3D graphics. The 2D Graphics mode is the standard. All 

network editing (except of static 3D objects) must be done using the 2D 



4.2.1 Visualization of Network Elements 

The Display of Network Elements window allows for display of more than one 

network element at a time (independently of the current edit mode) and for 

showing any labels of network elements (e.g. detector no.). 

► VIEW - SHOW NETWORK ELEMENTS (default shortcut CTRL+N) toggles the 

display of the selected network elements. This is convenient when a 

large number of elements is displayed simultaneously. 

► VIEW - NETWORK ELEMENTS... opens the Display of Network Elements 

window. 



Here for each network element the following settings can be changed: 

● Show Element: Turns on the display of that element. 

● Color of Element determines the color for display of the (active) element. 

● Fill: Creates a solid display as opposed to the default outline (only if 

corresponding edit mode is not active). 

● Label: Enables text displays associated with that element. A label may 

be switched on independently of the element display. 

● Color of Label sets the label text color. 

● Size of Label determines the label font size. 

Initially, the label is placed in the center of the associated element. It can 

be moved (using the mouse) if both, the edit mode of that network element 

and the label mode are active. 

4.2.2 2D Visualization of Vehicles and Pedestrians 

Depending on the current display option settings (cf. sections 4.1.2 and 

7.2.5) In the 2D display mode, VISSIM displays either individual vehicles or 

pedestrians respectively or aggregated data. 

The visualization can also be switched off completely for the entire network 

or for certain links/connectors or construction elements only, cf. for example 

section 6.3.1.2 [DISPLAY] for vehicles. 

Multiple options are available for the vehicle color: 

► Standard coloring: The vehicle color is determined by either vehicle 

type, vehicle class or PT route, cf. section 4.2.2.1. 

► Automatic dynamic colors: Vehicle colors are determined by certain 

states of the vehicles, e.g. lane change, gridlock resolution etc. For 

details please refer to section 4.2.2.2. 

► User-defined dynamic colors: Vehicle colors are determined by a 

selected parameter and class boundaries referring to the parameter 

value. For details please refer to section 4.2.2.3. 

In addition to vehicles, the current state of signal heads is displayed as a 

colored line at the location of the signal head, cf. section 5.3. 

If display of other network elements has been activated, then these elements 

are also displayed. 

4.2.2.1 Standard Coloring 

The color of a vehicle or pedestrian is determined by its type, class or PT 

route. This is the case if neither the automatic nor the user-defined dynamic 

color mode is active. 


Defined by 

type 

Defined by 

class 

Defined by PT 

Line 

Color distribution - - Type 

Color distribution Color - Class 

Color distribution - Color PT line 

Color distribution Color Color Class 


Displayed Color 

determined by 

For display of vehicles/pedestrians of a type belonging to several classes 

(which not necessarily have to be mapped with colors) the color set for the 

first one with color specification of those classes will be used. 

4.2.2.2 Automatic Dynamic Color Mode 

The following applies to the automatic dynamic color mode: 

► It provides additional information on vehicle movements that can be 

identified by the vehicle color. 

► It can be toggled using CTRL+V whenever the VISSIM network window is 

active. 

► It works also in 3D display mode (as long as the color of the 3D vehicle 

models is determined by VISSIM). 

The following color code is used for vehicles: 

Yellow Cooperative braking to allow other vehicle to change lanes 

Orange Lane change desired but not yet started 

Dark red Braking for own necessary lane change 

Light blue Waiting for necessary lane change at the emergency stop 

position for more than 6 simulation seconds 

Light green Currently lane changing 

Dark green Lane change finished during the last 6 simulation seconds 

Bluish green Ignoring priority rules (to solve the detected gridlock) 

Black Part of a priority rule gridlock situation 

Dark yellow During the last 3 simulation seconds, the vehicle decided to 

ignore a red signal or priority rule because its speed was 

too high to stop safely before the stop line 

Purple Light braking (between -1.0 to -3.0 m/s 2 ) 

Pink Heavy braking (below -3.0 m/s 2 ) 

Red Temporary lack of attention 

White Vehicle is in queue condition (only if there is at least one 

queue counter in the network) 

Dark blue All other situations (standard) 



4.2.2.3 User-Definable Dynamic Colors 

The colors of vehicles or pedestians are determined by the selected 

parameter. 

For display of user-defined dynamic colors the automatic dynamic color 

mode has to be switched off. 

For vehicles, the configuration is done 

via VIEW - OPTIONS - [VEHICLES] - 

CONFIGURATION for Individual vehicles. 

● Parameter: The desired parameter 

to be displayed with the color 

code. ‘None’ switches off the user 

definable dynamic colors. The 

currently active unit is displayed 

underneath. 

● Classes: For each user-defined 

range of values of the selected 

parameter a Color is to be defined. 

The Color is selected by clicking 

the colored box adjacent to the 

value field. Up to 10 classes are 

available. The upper boundary is 

included in the respective class. If 

a class value is deleted, the 

following values will be shifted to 

fill the gap. 

● DEFAULT CLASSES resets all values 

and colors to the defaults. 

4.2.3 2D Display of Aggregated Values for Vehicles (LOS) 

As an alternative to the display of individual vehicles or pedestrians, VISSIM 

can also display certain parameters as aggregated values using a color 

code. 

This is extremely helpful when trying to locate hot spots in a big network. 

Basically, the options for visualization of aggregated values of the simulated 

traffic are the same for vehicles on links and pedestrians on areas, cf. 

section 7.3.3. 

This section describes the display of aggregated values for vehicle traffic in 

the link network. Click VIEW - OPTIONS... - [VEHICLES] and set the options. 



The color code is used to color each segment of a link (or lane, if applicable) 

in the VISSIM network according to the online data of the selected 

parameter, cf. section 4.1.2. Therefore, you can freely select the class limits 

by parameter and the color by class. According to the color code settings, 

each segment of a link or connector will be colored, even by lane, if 

applicable, cf. section 4.2.3.1 

The segment length can be set and display can be enabled or disabled either 

for each link and connector individually in Standard mode or for multiple links 

and connectors simultaneously in Multi-select mode, cf. section 3.3.2. 

4.2.3.1 Viewing Aggregated Values of Vehicle Traffic 

Click VIEW – OPTIONS... to open the Display Options window. 

In the [VEHICLES] tab do the following: 

1. Check option Aggregated Values 

2. Click the CONFIGURATION button 

3. Set the options 

The color of a segment results from these settings. 

● Parameter: The desired parameter 

to be displayed by color code. If 

no selection is available, press 

LINK EVALUATION... to select the 

desired parameter. The appropriate 

unit appears underneath. 

● Cumulative: If checked, data 

being collected during the current 

interval is added to the previous 

value and the result is shown. 

● LINK EVALUATION... calls the link 

evaluation configuration window 

(cf. section 11.11.) for parameter 

selection and time interval defiition. 

The selected parameters are 

displayed in the Parameter list box 

after the window is closed. 

● Classes: Define the class limits 

(upper limit belongs to the interval) 

for the values of the selected 

parameter and click the 

associated color icon to the right 

to set the color by class. 

● Click DEFAULT CLASSES to restore 

the default settings (limits/colors). 



4.2.3.2 Examples: Aggregated Values of Vehicle Traffic 

Example 1 Typical visualization using the above color code for Speed evaluation: 

Example 2 Typical Density visualization: 


4.3 The 3D Graphics Mode 


In the VIEW menu, click the 3D Mode command (default shortcut CTRL+D) to 

call the three-dimensional display of the VISSIM model. Furthermore, also 

static elements can be added to the network display at any network position. 

The network display can be viewed from any observer position. 

Except for placing static 3D models, the 3D graphics mode is intended 

solely for presentation purposes. All network editing is to be done in 2D 


If a background image is active, when changing into 3D mode for the first 

time (with that bitmap visible) it may take a moment for VISSIM to convert 

the image to a 3D texture. 


Static 3D objects are taken into consideration when the rectangular floor 

space is calculated. In this way, resulting gaps between the models and the 

floor area can be avoided and also view problems in case of very large 

models. 

4.3.1 Navigation 

This section describes the options how to move the observer position in 3D 

mode. 

4.3.1.1 Navigation Modes 

In 3D mode additional toolbar buttons become active. The following 

commands are available in the Navigation toolbar: 

Show Entire Network: Displays the entire network. 

Dynamic Zoom: In contrast to the ZOOM command in 2D which uses a 

window to select the new viewing area DYNAMIC ZOOM in 3D moves the 

network closer dynamically by dragging the mouse from left to right and 

moves the network further away by dragging the mouse from right to left. 

A right click restores the previous view. Alternatively the mouse wheel can be 

used to zoom in/out independently of the current navigation mode. 

Zoom by Factor: Zooms by a user-defined factor: Values < 1.0 zoom in. 



Pan: Pressing left-hand mouse-key allows for dragging the 3D network in 

any direction without changing the height of the observer. This command will 

move the network within the network plain. Thus if the camera position is 

very low, just a small movement of the mouse will result in a large movement 

of the network. 

Rotate network: Changes the location from which the VISSIM network is 

viewed (“camera position”). When 3D is initially switched on, the network is 

viewed from directly overhead, similar to the standard 2D view. When 

ROTATE NETWORK is selected and the mouse is dragged on the screen, the 

camera position changes: 

► Dragging up and down changes the vertical angle at which the scene is 

observed (changing the height and angle of the observer). 

► Dragging left and right rotates the point of view around the network. 

Fly through the network: In this mode the observer is moved continuously 

through the network. 

► Double-click (left) starts/ends the movement; 

double-click (right) starts/ends backwards movement. 

► Movement of the mouse changes the direction of the flight. 

► The speed of the flight can be changed: 

- With the left SHIFT key the speed is increased. 

- With the left CTRL key the speed is decreased. 

The 3D viewing modes are: 

► Rotate network 

► Pan network 

► Fly through the network 

The selected 3D viewing mode remains active until either the singleselect 

mode is enabled or another 3D viewing mode is selected. 

4.3.1.2 Sitting in the Driver’s Seat 

Another 3D viewing option is to “sit in the driver´s seat”. This can be done in 

single step mode by double-clicking on the vehicle. To leave the vehicle, 

close the corresponding vehicle information window. The view from of the 

driver´s seat is also possible to be used as a camera position for a keyframe 

(in order to record an *.AVI file). 


4.3.1.3 Changing the Field of View (Focal Length) 


You can adjust the viewing angle that is used to look at a 3D scene. This is 

similar to changing the focal length of a camera. The standard viewing angle 

in VISSIM is set to 45°, which is a focal length equivalent of about 43mm (for 

a 35mm camera system). 

To change the field of view, use one of the options below: 

► Press CTRL+PGUP or G to decrease the viewing angle by 1 degree 

(i.e. moving a zoom lens towards the telephoto end). 

► Press CTRL+PGDN or T to increase the viewing angle by 1 degree 

(i.e. moving a zoom lens towards the wide-angle end). 

The current viewing angle is displayed in the second section of the status bar 

while the viewing angle is changed. 

VISSIM does not store any changes to the viewing angle. As soon as 

VISSIM is closed and reopened, the standard value applies. 

Changing the viewing angle applies to all 3D navigation modes as well as 

all the keyframes. 

The following table shows the focal length equivalents of various viewing 

angles: 

View. angle F. length (35mm) View. angle F. length (35mm) 

4° 500mm 38° 53mm 

7° 300mm 40° 50mm 

10° 200mm 44° 45mm 

11° 180mm 54° 35mm 

15° 135mm 65° 28mm 

20° 100mm 72° 25mm 

24° 85mm 81° 21mm 

29° 70mm 90° 18mm 

4.3.2 3D Visualization of Vehicles and Pedestrians 

3D models in VISSIM can be assigned to each type of vehicles or 

pedestrians respectively using model and color distributions (cf. sections 

5.2.4 and 5.2.5 for details). 



4.3.3 3D Animation of PT Vehicle Doors 

Select the 3D Model of the PT vehicle via BASE DATA – DISTRIBUTIONS - 2D/3D 

MODEL... - 2D/3D Model Distributions, cf. section 5.2.5.2. 

If the *.V3D model file stores also vehicle doors for the 3D model, the 

opening and closing of sliding doors (also double doors) is visualized in the 

3D mode. 

Here, the following applies: 

► For animated display, the doors need to satisfy the following conditions: 

- Boarding and/or alighting must be permitted for the door and at the 

stop. 

- The door is located at a valid position at a platform edge. 

Without a platform edge, which is only required for pedestrians as 

passengers, the door needs to be in a valid position between start 

and end of the PT stop. 

► Temporal restrictions: 

As soon as the vehicle does no longer move at the PT stop, the opening 

of the vehicle doors starts which lasts 1.5 seconds. 

The closing of the doors depends: 

- For calculated dwell times: The closing of the vehicle doors starts 3 

seconds prior to the end of the vehicle´s dwell time at the stop. 

- For “real” pedestrian flows: The doors start closing, if no passenger 

has tried to use one of the vehicle´s doors for boarding or alighting 

during the last 3 seconds. 

Door closing always takes 2 seconds. 

- During the first of these two seconds, the doors will open again if a 

passenger wants to board or alight. 

- During the second of these two seconds, the passengers behave as 

if the doors were already closed. 

When the doors are closed, the vehicle waits another seconds and will 

depart then. 

The number of time steps depends of the simulation resolution. 

► During the opening process, shifting the door polygons is performed as 

follows: 

- By 6 cm perpendicular to the vehicle for 0.3 s 

- By the width of the door in parallel to the vehicle element heading to 

the direction with the bigger distance to the next door (or end of the 

vehicle, if applicable). 

Closing the doors means the reverse order and direction of these two 

polygon shifting steps. 


4.3.4 3D Signals 

4.3.4.1 Creating 


There is a choice of signal head displays in 3D mode (cf. section 4.1.4 for all 

available displays). One option is to show real signals rather than the blocks 

used in versions prior to VISSIM 4.20. This section describes how to enable 

and configure real signal heads. 

Creating a signal head requires the 2D graphics mode and the Signal 

heads edit mode. 

Editing signal heads can be done in 2D mode and in 3D mode. 

► In the 2D graphics mode, the Signal heads edit mode needs to be 

active. 

► In the 3D graphics mode they can only be edited within the dialog 

window (double click on the object in 3D mode to open the window), 

whereas in 2D, they can be moved and rotated outside of the dialog 

box, too. 

Most properties of a new 3D signal are taken from the signal defaults (cf. 

section 4.1.4.2). 

Follow the steps below to create a new 3D signal: 

1. Open the Signal Head window for the signal head you want to create a 

new 3D signal for. 

2. Press NEW 3D SIGNAL to open the 3D Traffic Signal window. 

3. Set the position of the new signal. 

Select one of the options: 



4. Confirm with OK. The Signal Properties window opens. 

5. Edit the signal data (cf. section 4.3.4.3) and confirm with OK. 

6. Close the Signal Head window with OK. 

7. Switch on the 2D representation of the 3D signals (default shortcut 

CTRL+H). The new signal can now be placed and edited (cf. below for 

details). 

4.3.4.2 3D Signals in the Network Display 

EDIT - 3D SIGNAL HEADS (default shortcut 

CTRL+H) shows the 3D signals as a 2D representation: 

► Unselected 3D signal heads are displayed 

as a green square with a diamond and a red 

circle inside. A selected signal is painted in 

dark blue in 2D, light blue in 3D mode. 

► The circle represents the mast. 

► Any arm is displayed as a red line indicating 

the direction and length of that arm. 

► Small blue arrows along the arm indicate 

the signal heads. 

In 2D mode, signal heads which are directly 

attached to the mast are displayed as a blue 

circle. 

While holding the left mouse-key down, you 

may drag a 3D signal head to a new 

position on the mast in 2D mode. 

Select Click on the green square. The selected square is painted blue. 


Move Entire Signal: Select the signal and drag it to the desired location. 

Copy & 

Paste 


Arm only: An arm can be sized or rotated around the mast: Click inside the 

red circle at the far end of the arm and drag it to the desired length and 

location. 

Cf. section 4.3.4.4: Move, Tilt, Rotate, etc. 

Select the signal to copy and press CTRL+C. 

To paste a copied signal, press CTRL+V and drag the copied signal to the 

desired position while holding down left mouse-key. 

Edit data Double click on the green square to open the Mast Properties window. 

Delete Select the signal and press DEL. 

4.3.4.3 Properties & Options 

This section describes all parameters and options to be set for each signal 

individually. 

The definition of the default properties for new 3D signals is described in 

section 4.1.4.2. 

The default properties for a new 3D signal are defined in the view settings 

(cf. section 4.1.4.2). 

A 3D signal may consist of up to 4 components: 

► Mast 

► Arm 

► Signal Head 

► Sign 



Mast 

Double click on the 2D representation of the signal opens the Mast 

Properties window: 

● ID (in window title, read-only): Shows the mast identification no. 

● Style: Appearance of the mast. 

● Height: Mast height. 

● Arm length: Length of the currently selected arm. 

● Diameter: Mast diameter. 

● Z-Position: Charted elevation of the mast position, (> 0 e.g. for masts on 

bridges). 

● ADD ARM: Creates a new arm and opens the Arm Properties window. 

● ADD SIGNAL: Creates a new signal head that is attached directly to the 

mast (not to an arm) and opens the Signal Head Properties window. 

● ADD SIGN: Creates a new sign that is attached directly to the mast (not to 

an arm) and opens the Sign Properties window. 

● ADD LIGHT: Creates a new arm with the style Light. 

● FLIP ALL: Toggles the direction of the arm on the mast accordingly for 

right-hand traffic or left-hand traffic. 

The following buttons are enabled only if either an arm, a signal head or a 

sign is selected: 



● EDIT ARM / EDIT SIGNAL / EDIT SIGN: Opens the corresponding Properties 

window. 

● HIDE/SHOW: Disables/Enables the visibility of the selected object(s). 

Hidden objects of first degree are shown in grey. Nested hidden objects 

are not shown. 

● DELETE: Deletes the object. 

Arm 

In the Mast Properties window, click on the desired arm and press EDIT ARM. 

The Arm Properties window allows to edit the properties: 

● ID (in window title, read-only): Shows the mast and arm identification no. 

● Style: Appearance of the arm. 

● Length: Arm length. 

● ADD SIGNAL: Creates a new signal head and opens the Signal Head 

Properties window. 

● ADD SIGN: Creates a new sign and opens the Sign Properties window. 

The following buttons are enabled only if the particular component has been 

selected: 

● EDIT SIGNAL / EDIT SIGN: Opens the corresponding Properties window. 

● HIDE/SHOW: Disables/Enables the visibility of the selected object(s). 

Hidden objects are shown in grey. 

● DELETE: Deletes the object. 



Signal Head 

On Mast In the Mast Properties window, click on the desired signal head that is 

attached directly to the mast and press EDIT SIGNAL. 

On Arm In the Arm Properties window, click on the desired signal head and press 

EDIT SIGNAL. 

The Signal Properties window allows to edit the signal head properties: 

● ID (in window title, readonly): 

Shows the mast, arm 

(if applicable) and signal 

head identification no. 

● Type: Due to the selected 

type (Pedestrian/Bike, 

Traffic or Public Transport), 

various layouts are provided 

for the signal head. With the 

Pedestrian/Bike type, also 

signals with timer can be 

chosen. 

● Orientation: Choose Vertical 

or Horizontal orientation. 

● Associated controller data: 

Link to VISSIM controller 

and signal group no. that 

should be displayed on this 

signal head. Depending on 

the Layout one or more of 

the direction lines Left, 

Through and Right are 

enabled, e.g. Left is enabled 

only if the Layout contains at 

least one bulb with a left 

arrow. 

● Layout: Number of lenses and configuration of the signal head. 



With a fixed time signal control, 

countdown timers show the 

currently remaining red and 

green times of a signal group 

during the cycle. 

If required, they can also be 

used in combination with signals 

of any vehicle type if desired. 

They are activated as soon as 

they are linked to a signal group 

(as with all other 3D signals). 

These are the characteristics of 

the timers: 

- The timer is colored “red” 

during signal group states 

“red” and “red/amber”. 

- The timer is colored “green” 

during signal group state 

"green" (and not e.g. during 

"green flashing"). 

- For all other signal group 

states (e.g. “amber”, “red 

flashing”, “amber flashing” or 

“green flashing”) the timer 

remains off (dark). 

- The displayed red and green timings (timer start values) are taken 

from the last red and the last green period of the signal group 

respectively (where red/amber belongs to red in this context). I.e., the 

timer always starts with the value of the last duration of the 

corresponding state. If that duration was 0 then no timer is displayed. 

- Timers do not function properly if there are more than one red or 

green time period within the same cycle (because the counters will 

still show the timings of the last green or red period). 

Note that due to the “history” behaviour, timers may display no or incorrect 

values during the first and possibly second signal cycle after simulation 

start, and also during the first and possibly second signal cycle after any 

change of signal program. 

Timers are intended for fixed time signals only. 

If they are used with vehicle-actuated signal controls, the timers will display 

incorrect timings due to the unpredictable red and green times. 



Sign 

On Mast In the Mast Properties window, select the desired sign that is attached 

directly to the mast and press EDIT SIGN. 

On Arm In the Arm Properties window, select the desired sign and press EDIT SIGN. 

The Sign Properties window allows for interactive changes to the sign 

dimensions as well as to edit other sign properties. 

Each shape consist of two parts that can be scaled independently using the 

mouse: 

► Border: Click on the edge of the border and drag the mouse to the 

desired dimension. 

► Internal area: Click inside the internal area to select it. A dashed line 

indicates that the internal area is selected. Then click on its edge and 

drag the mouse to its desired dimension (inside the border area). 

The current scale (Width, Height) can be checked in the lower part of the 

Sign Properties window. 

● ID (in window title, read-only): Shows the mast, arm (if applicable) and 

sign identification no. 

● Shape: Geometrical form of the sign. 

● Width: Length of the largest horizontal extension of the shape. 

● Height: Length of the largest vertical extension of the shape. 


4.3.4.4 Editing 


● ASSIGN TEXTURE…: Opens the Texture Manager window (cf. 4.1.4.1) to 

assign a texture to the shape. 

● REMOVE TEXTURE: Removes the texture from the shape. 

● Border Color: Color used to paint the border of the shape. Press to 

select a different color. 

● Background Color: Color used to paint the internal area of the shape. 

Press to select a different color. 

The upper part of the property window of each component includes a preview 

panel that shows the selected component along with other components 

attached to it (e.g. arm on mast in the Mast Properties window). 

All these preview panels reflect the changes of all properties and allow 

interactively for the following actions: 

Action Add. Key Mouse Action Shortcut 

Pan entire preview ./. Click background & drag ,,, 

or E,D,S,F 

Rotate entire preview CTRL Click background & drag ./. 

Zoom entire preview ./. Mousewheel with nothing 

selected 

PGUP, 

PGDN 

These actions are available only in the Mast Properties and Arm Properties 

windows: 

Action Add. Key Mouse Action Shortcut 

Move object 

up, down, left, right 

./. Click object & drag ./. 

Move object in & out SHIFT+ALT Click object & drag ./. 

Rotate object (vertic.) CTRL Click object & drag ./. 

Tilt object (horizont.) CTRL+ALT Click object & drag ./. 

Scale object ./. Select object, 

then Mousewheel 

Some of these actions are graphically supported by colored arrows indicating 

the particular plane and the possible directions of movement. 

User Manual © PTV AG 2011 95 

./.


Move 

Tilt 


Rotate 

4.3.5 Static 3D objects 


In 3D mode, static objects like trees, buildings or any other user-defined 3D 

objects can be placed at any position within the VISSIM network and edited 

using the following mouse operations: 

Mouse click Add. key Action 

Right ./. Inserts a static 3D object from a *.V3D file at 

the click position by opening the Select 3D 

Model window for file selection. The 

procedure is similar to selecting a 3D vehicle 

file *.V3D (cf. section 5.2.5). 

Furthermore the following is possible: 

Direct import of Google SketchUp files 

(*.SKP) up to version 8, Autodesk files 

(*.DWF) and Autodesk 3DS files (*.3DS). 

Left ./. Selects a 3D object, which then appears 

within a bounding box. 

Press DEL to remove the marked object from 

the network. 

Left SHIFT Horizontal movement of the 3D object within 

the network plane 

Left SHIFT+ALT Vertical movement of the 3D object 



4.3.6 Fog/Haze 

Mouse click Add. key Action 

Left CTRL Rotates the 3D object 

Left CTRL+SHIFT Scales the 3D object (smaller: mouse move 

left, larger: mouse move right) 

If complex 3D objects are used then switching into 3D mode may take a 

moment for VISSIM to initialize. 

To select a static 3D model, the mouse click position needs to be unambiguous, 

i.e., the 3D model must not overlap at the click position. 

Static 3D objects (such as buildings etc.) can be converted from Autodesk 

3DS-Max file format *.3DS into the VISSIM 3D file format *.V3D using the 

optional module V3DM (VISSIM 3D Modeler). 

Furthermore, simple 3D models can be modeled directly in V3DM and 

textures used to give them a realistic appearance. 

SketchUp files do not have to be converted into *.V3D files by means of 

V3DM. 

Fog can be added to any 3D scene in VISSIM. The fog is visible only on 3D 

objects, not on the surrounding area that is referred to as ‘sky’. In order to 

get a fog effect on the sky also, you need to place a static 3D object ‘wall’ 

with a sky texture on it. As an easy alternative you can also color the sky with 

a grey color similar to the fog. 

The following hotkeys control the fog appearance: 

Hotkey Action 

CTRL+F9 Toggle fog display on/off 

CTRL+F3 Move the fog front towards the observer 

CTRL+F4 Move the fog front away from the observer 

CTRL+F5 Move the 0-visibility front towards the observer 

CTRL+F6 Move the 0-visibility front away from the observer 

From the observers point to the fog front, there is always 100% visibility. The 

fog increases between the fog front and the 0-visibility front. Behind the 0visibility 

front there is 0% visibility. Consequently, the fog density decreases 

as the distance between the fog front and the 0-visibility front increases. The 

0-visibility front cannot be moved in front of the fog front. Neither can the fog 

front be moved behind the 0-visibility front. 



VISSIM does not store any changes regarding fog/haze. As soon as 

VISSIM is closed and reopened, haze/fog is disabled. 

Adding fog/haze applies to all 3D navigation modes and all the keyframes. 

Illustrations for the effects of the fog parameters 

For this example, V3DM (optional 

module) was used to place a sky 

picture on a vertical plain. This plain 

was included in VISSIM as a static 

3D object. Otherwise, the fog would 

not be visible above the horizon. 

Scene 1: Fog front and 0-visibility front are 

set to the same value: The fog appears as 

a solid wall. 

Scene 3: Coming from scene 1, the fog 

front is moved further towards the observer 

(default shortcut CTRL+F3). 

Scene 0: No fog at all. 

Scene 2: Coming from scene 1, the 0visibility 

front is moved further away 

from the observer (default shortcut 

CTRL+F6) 

Scene 4: Both settings from scene 2 and 

scene 3 are combined here. 



4.4 Background Images 

Building an accurate VISSIM model from scratch requires at least one scaled 

map that shows the real network. The image file of a digitized map can be 

displayed, moved and scaled in the VISSIM network window and is used to 

trace the VISSIM links and connectors. 

In the VISSIM 64 bit edition, the selection of background image file formats 

is limited. Files with some vector formats (*.DWG, *.DXF) may not be 

displayed correctly. Work-around: Convert the file to a raster graphics 

format (e.g. *.BMP, *.JPG) with a graphics program. 


4.4.1 Supported Background Data Formats 

VISSIM can display various image file formats, both bitmaps and vectors. 

Among the supported formats are: 

Supported bitmap formats Supported vector formats 

BMP DWG 1) 

JPG DXF 1) 

PNG EMF 

TGA WMF 

TIF (uncompressed & packbits) 

SID (Mr. SID) 

(best resolution for display) 

ECW (fixed resolution only) 

SHP (shape files) 

1) TM 

Note: Each new version of Autodesk AutoCAD will update DWG and 

DXF formats automatically. VISSIM can handle DWG versions 13 - 15 and 

DXF versions 9 - 14. 

*.DWG and *.DXF files may contain multiple images. Currently only the first 

image of a file is shown in VISSIM. 

4.4.2 Workflow: Creating a Background 

The following steps explain how to convert image files to VISSIM background 

maps. We recommend to start with a map which shows the entire network 

area: 


Background Images 

1. Go to VIEW - BACKGROUND - EDIT..., press LOAD... and select the name of 

the desired graphics file in order to import it into VISSIM. This process 

may take a few moments for large image files. 

Although it is possible to select many different file 

types, VISSIM does not necessarily support all the 

selectable file types. If a file type is not supported, 

VISSIM shows a message box. 

2. Close the Background selection window and select SHOW ENTIRE 

NETWORK from the Navigation toolbar to display the entire map. 

Be aware that the map is not displayed to scale, even if the image file 

has an intrinsic scale. Precise scaling is necessary for an accurate 

network model, therefore we strongly recommend to use large scale 

distances (> 100 m / > 300 ft). To fit the map to VISSIM units, zoom in to 

an object or distance between two objects where you know the original 

distance precisely. For example, this could be a map scale or the 

distance between two building edges or geographic points. 

3. Open again the Background selection window (VIEW - BACKGROUND - 

EDIT...), select the file to be scaled and press SCALE. The mouse pointer 

turns into a ruler with the upper left corner as the “hot spot”. 

4. Click and hold the left mouse button and drag the mouse along the scale 

distance. 

5. After releasing the left mouse button, enter the real distance of the scale 

line and confirm with Ok. 

The scale of a VISSIM network cannot be changed later on. Therefore we 

strongly recommend to use great precision in the scaling process to avoid 

inconsistencies. 

6. While the Background Selection window is still open, press ORIGIN in 

order to move the background image to the desired position. The mouse 

pointer turns into a hand with its thumbnail acting as the “hot spot”. Keep 

the left mouse button pressed to drag the background map to its new 

location. Typically, moving the background is not necessary for the first 

bitmap as long as it does not have to fit an existing VISSIM network. 

7. Go to VIEW - BACKGROUND - PARAMETERS... and press SAVE in order to 

permanently store the scaling and origin information of the background 

image. This command creates a parameter file named .BGR. Whenever you reload that background, make sure that the 

corresponding *.BGR file is located in the same directory as the background 

file. In case the *.BGR file is missing, VISSIM will read data from 

the *.HGR file and save changes to the newly created *.BGR file. 



The size of an image file depends on the following: 

► data format and compression (especially *.JPG) 

► screen resolution and color depth 

► computer and graphics card memory (especially for 3D mode) 

Thus the max. file size depends on the system configuration. 

If the background file you would like to open exceeds the available main 

storage, a warning will be displayed. Optionally, this message provides 

further loading. 

In case of incorrect image display (black or white box instead of the image) 

reduce the file size by either cropping a smaller section or reducing the 

resolution. 

After the “overview” background map has been established, other maps 

(showing smaller areas in high detail) can be loaded and scaled in the same 

way and then be moved to their correct position. In order to place them 

correctly (in relation to the other background images) it is recommended to 

create a coarse VISSIM network first, where strategic links are placed on the 

main “overview” background. Place links at positions where this background 

overlaps with the background to be moved into the right place. To 

accomplish this it could be helpful to place some VISSIM links temporarily on 

building edges. For detailed node modelling precise maps should be used. 

Multiple images can be loaded simultaneously. 

Once one or more background images are loaded, their visibility can be 

toggled using VIEW - SHOW BACKGROUND or the default shortcut CTRL+B. 

Image files may, but do not have to be stored in the same directory as the 

network file (*.INP). 

In the *.INI file, background file paths are saved as meta filenames 

(especially #data# for current data directory). This allows to continue to use 

*.INI files that reference background files in the data directory (where *.INP 

resides) after the whole directory has been renamed, moved or copied to a 

different place. 

Loaded background images are removed, if an *.INI file is read via menu 

VIEW – LOAD SETTINGS which refers to another background file itself. 

4.4.3 Workflow: Scanning an Image 

The following steps outline the recommended procedure for scanning maps 

and plans for use with VISSIM: 


Background Images 

1. Maps and plans to be scanned should include a north arrow and a scale. 

It is recommended to create one overview map that shows all 

intersections to be modeled and individual signal plans for each 

intersection showing stop lines and detector locations (if applicable). 

2. Ensure that the scanned plans show a strong contrast. 

3. Maps and plans should be oriented to North direction. In the case of 

modeling a North-South corridor, another orientation could be useful. 

4. Use a copy machine to reduce plans in case they do not fit the available 

scanner. 

5. An A4 sized map should be scanned with 300 dpi. Depending on the 

speed of the computer also higher resolutions can be useful. Generally 

speaking, the higher the resolution the bigger the bitmap file size and the 

longer it takes VISSIM to load the bitmap and to refresh the network. 

6. Save the scanned file to one of the supported bitmap formats (e.g. as 

*.BMP, *.JPG or uncompressed *.TIF file). 



4.5 Save/Load Settings 

Several graphics and other VISSIM options can be saved to a settings file 

(*.INI). Among the stored settings are: 

► Main window size and position 

► Zoom factor 

► Display options 

► Evaluation settings for online or offline output 

The size and position of all VISSIM dialog windows are stored separately 

(not in the settings file). 

Save settings to file 

1. Click VIEW - SAVE SETTINGS... 

2. Enter the filename. 

3. Confirm OK. 

Read settings from file 

1. Click VIEW - LOAD SETTINGS... 

2. Select the filename. 


Alternatively, you can drag the *.INI file from the Windows Explorer and drop 

it in the VISSIM window to read the settings from file. 


5 Base Data for Simulation 

The stochastic nature of traffic implies the necessity to provide this kind of 

variability in VISSIM models also. The heart of VISSIM, the car following 

model of Wiedemann (cf. section 1.2), deals with this fact by incorporating 

several parameters that use stochastic distributions. This chapter deals with 

the base information for the traffic simulation by explaining the different type 

of distributions and functions, and also the way vehicles or pedestrians are 

modeled. If you would only like to use the VISSIM test functionality then you 

do not need to read this chapter. 

User Manual © PTV AG 2011 105


5.1 Acceleration and Deceleration Functions 

VISSIM does not use a single acceleration and deceleration value but uses 

functions to represent the differences in a driver’s behavior. Acceleration and 

deceleration are functions of the current speed. Combustion engines reach 

their maximum acceleration at low speeds, whereas three-phase motors of 

e.g. trams or trains show a constant acceleration within a wide range of 

speeds. 

For each vehicle type two acceleration functions and two deceleration 

functions (graphs) need to be assigned: 

► Maximum acceleration: Max. technically feasible acceleration. Regarded 

only if an acceleration exceeding the desired acceleration is required to 

keep the speed on slopes. 

► Desired acceleration: Used for any other situation. 

► Maximum deceleration: Max. technically feasible deceleration. Adjusted 

on slopes by 0.1 m/s² for each percent of positive gradient and -0.1 m/s² 

for each percent of negative gradient. 

► Desired deceleration: If it is lower than the max. deceleration, then the 

desired deceleration is used as the maximum for the deceleration 

- caused by a desired speed decision, 

- in case of Stop & Go traffic, when closing up to a preceding vehicle, 

- in case of insufficient lateral distance for overtaking within the lane, 

- towards an emergency stop position (route), 

- for co-operative braking: In this case, 50% of the vehicle´s own 

desired deceleration is used as the max. reasonable deceleration for 

the decision, whether an indicating vehicle may change from the 

neighbouring lane to the vehicle´s lane. 

In any other case, the parameters of the car following model are relevant. 

Predefined functions are provided with each of the default vehicle types in 

VISSIM. They can be edited or new graphs can be created through BASE 

DATA – FUNCTIONS... When one of the four types is selected, an edit window 

opens to allow for editing the existing acceleration graphs. 


Acceleration and Deceleration Functions 

To reflect the stochastic distribution of acceleration and deceleration values, 

each graph consists of three different curves showing the minimum, mean 

and maximum values. Each curve can be edited individually. 

The vertical axis depicts the acceleration value and the horizontal axis 

depicts the corresponding speed. The visible range of both axes can be set 

using the corresponding fields. Pressing the button BEST FIT will use the 

current graph to determine the minimum and maximum values to be shown 

on both axes. 

Within one graph each curve can be edited separately by dragging one of its 

intermediate points. When dragging points of the median curve (red dots) 

both the values of the border lines are adjusted as well. 

The default maximum acceleration/deceleration curves in VISSIM 

The default maximum acceleration curves for cars are almost the original 

ones provided with the Wiedemann 74 model, cf. section 5.4.1. 

► For cars, these measurements performed in Germany before 1974 have 

slightly been adapted for shorter time steps with jerk limitation and for the 

user-defineable spread (min-max). 

Jerk is the rate of change of acceleration; that is, the derivative of 

acceleration with respect to time. With more than 2 time steps per 

second, it is limited by the share that corresponds with twice the time 



step length. Example: With 10 time steps per second (time step = 0.1 s), 

the limit is 20% (0.2) of the intended change in acceleration. 

The accelerations from standstill have been validated against test vehicle 

data in the European research project RoTraNoMo 

(www.rotranomo.com) in 2004. 

► For trucks, the acceleration/deceleration curves have been adapted to 

data from the European research project CHAUFFEUR 2 in 1999. 

► For trams and buses, the acceleration/deceleration curves have been set 

according to information from the Karlsruhe public transport company 

(VBK), 1995. 

All curves should be adapted to local conditions (especially the vehicle 

fleet) if these are substantially different from Western Europe. 

Speed calibration by adjusting the maximum acceleration/deceleration 

curves 

For all vehicles, the maximum acceleration is affected by the gradient: 

► It is reduced by 0.1 m/s² per 1% upwards gradient. 

► It is increased by 0.1 m/s² per 1% downwards gradient. 

For trucks, the actual acceleration is limited by the desired acceleration 

function, too, so the surprisingly high maximum acceleration values for trucks 

are only relevant at very low speeds for steep gradients. 

The maximum acceleration of a specific vehicle at a certain speed is 

somewhere between the maximum value and the minimum value (black lines 

without red dots in the maximum acceleration curve dialog). 

The position in this range is determined by the following: 

► By power and weight for vehicles of a vehicle type with category "HGV". 

► By a random value for all other vehicles. 

The random value is normal distributed (with average 0.5 and standard 

deviation 0.15 but limited to [0..1], so the distance between the average 

curve and the and min/max curve is 3.333 times the standard deviation 

(SD)). 

This results in the following: 

- About 70% of the vehicles are in the inner third (-1 SD .. + 1 SD) of 

the random values 

- And 95% are inside the inner two thirds (-2 SD .. + 2 SD). 

Linear interpolation in VISSIM: 

- For random values below 0.5 VISSIM interpolates between the min 

(0.0) and the average curve (0.5), 

- For random values above 0.5 VISSIM interpolates between the 

average and the max curve (1.0). 


Acceleration and Deceleration Functions 

HGV vehicles do not use a random value but the power/weight ratio instead. 

With metric units, the minimum is 7 kW/ton and the maximum is 30 kW/ton, 

which means an average of 18.5 kW/ton. 

Accordingly, the following applies: 

► All HGV with a p/w ratio of 7 or less will use the minimum curve. 

► All HGV with a p/w ratio of 30 or more will use the maximum curve. 

► All HGV with a p/w ratio of 18.5 will use the average. 

► For HGV with any other value, linear interpolation will be performed. 

If your actual power/weight ratios are outside of this range, it is necessary 

to use separate maximum acceleration curves (and separate vehicle types) 

for specific power/weight ranges, with a very small spread. 

After the interpolation, the maximum acceleration is modified by the 

gradient, as described above. 



5.2 Distributions 

A range of parameters in VISSIM is defined as a distribution rather than a 

fixed value. Thus the stochastic nature of traffic situations is reflected 

realistically. Most of the distributions are handled similarly and it is possible 

to use any kind of empirical or stochastic data for definition. All distributions 

can be accessed by BASE DATA - DISTRIBUTIONS. 

5.2.1 Desired Speed Distribution 

For any vehicle type the speed distribution is an important parameter that 

has a significant influence on roadway capacity and achievable travel 

speeds. If not hindered by other vehicles, a driver will travel at his desired 

speed (with a small stochastic variation called oscillation). The more vehicles 

differ in their desired speed, the more platoons are created. If overtaking is 

possible, any vehicle with a higher desired speed than its current travel 

speed is checking for the opportunity to pass - without endangering other 

vehicles, of course. 

Stochastic distributions of desired speeds are defined for each vehicle type 

within each vehicle composition. The window Desired Speed Distribution can 

be accessed via BASE DATA – DISTRIBUTIONS - DESIRED SPEED.... A desired 

speed distribution can then be selected (single mouse click), edited (single 

mouse click and EDIT or double click) or created (NEW). Creating or editing a 

desired speed distribution opens the window shown above. 

The minimum and maximum values for the desired speed distribution are to 

be entered into the two fields above the graph (the left number must always 


Distributions 

be smaller than the right number). Intermediate points are displayed as red 

dots. They can be created with a single right button mouse click and moved 

by dragging with the left mouse button. Merging two intermediate points 

deletes the first one of them. 

The horizontal axis depicts the desired speed while the vertical axis depicts 

the cumulative percentage from 0.0 and 1.0. Two intermediate points are 

generally adequate to define an s-shaped distribution which is concentrated 

around the median value. 

5.2.2 Weight Distribution 

The weight of vehicles categorized as HGV can be defined as a weight 

distribution. Along with a power distribution it affects the driving behavior on 

slopes. 

Each vehicle type is assigned to one vehicle category. For each vehicle of a 

type that is defined as HGV category, VISSIM randomly selects one value 

out of the weight distribution and another one out of the power distribution 

that is assigned to its vehicle type. The weight and power values do not 

automatically correspond to each other (i.e. it is possible that a vehicle gets a 

high power and low weight assigned). VISSIM therefore computes the 

power-to-weight-ratio of the vehicle as kW/t. In order to prevent extreme 

power/weight combinations the power-to-weight-ratio has a range of 7-30 

kW/t. If the ratio is computed lower than 7 kW/t, the ratio is internally set to 7 

kW/t; if the ratio is computed higher than 30 kW/t, it is set to 30 kW/t. 

According to the power-to-weight-ratio, one curve out of each 

acceleration/deceleration function is selected for this vehicle proportionally. 

Example: If the power-to-weight-ratio is computed as 7 kW/t, the resulting 

max. acceleration curve is the lower border of the range of curves (cf. section 

5.1). If it is 30 kW/t, the resulting curve is the upper border. 

A Weight Distribution can be defined/edited by BASE DATA - DISTRIBUTIONS – 

WEIGHT... in the same way as a speed distribution (cf. 5.2.1 for details). 

5.2.3 Power Distribution 

The power of vehicles categorized as HGV can be defined as a power 

distribution. Along with a weight distribution it affects the driving behavior on 

slopes. 

A Power Distribution can be defined/edited by BASE DATA - DISTRIBUTIONS – 

POWER... in the same way as a speed distribution (cf. 5.2.1 for details). 

Please refer to the weight distribution for details on how the power 

distribution comes into action. 



5.2.4 Color Distribution 

This distribution is only necessary for graphical display - it has no effect on 

simulation results. A Color Distribution can be defined and edited via BASE 

DATA - DISTRIBUTIONS - COLOR... 

The color distribution is used instead 

of a single color for a type of vehicles 

or pedestrians. Even if only one color 

should be used for a type a distribution 

still needs to be defined (with 

one color only). 

Up to 10 colors are possible for each 

distribution and each one needs to 

have a relative percentage > 0 

(Share). The absolute percentage is 

automatically computed by VISSIM as 

the proportion of an individual Share 

compared to the sum of all Shares. 

5.2.5 Model Distribution 

This distribution defines the variety of the dimensions, colors and textures 

which is required for graphical display: 

► vehicle properties within a vehicle type 

► properties of pedestrians within a type of pedestrians 

Especially the dimensions have an effect on simulation results (e.g. due to 

length and width of vehicles or pedestrians, as applicable). 

A Model Distribution can be defined or edited via BASE DATA - DISTRIBUTIONS - 

2D/3D MODEL... in the 2D/3D Model Distribution window. 


The model distribution is used 

instead of a single model for a 

type of vehicles or pedestrians. 

Even if a type should only be 

represented by one model still a 

distribution needs to be defined 

(with one model only). 

Up to ten models are possible 

for each distribution and each 

one needs to have a relative 

percentage (Share) >0. 

The absolute percentage is 

computed automatically: The 

proportion of an individual 

Share is compared to the sum 

of all Shares. 

Distributions 

Via , each pedestrian/vehicle model can be defined by its Geometry or by 

the selection of a 3D-Model file. 

5.2.5.1 2D Model Definition (Geometry) 

In the 2D/3D Model Distribution window, the Geometry button opens the 

Geometry window. 

This window contains the number of elements the particular vehicle or 

pedestrian model consists of. All defined elements are listed on the left and 

can be selected for editing in the tabs to the right. 

The list can be edited as follows: 

► Click NEW to add another element to the model. 

► Click DELETE to discard the selected element. 

[BASE] In the [BASE] tab, each 

element can be defined in 

detail. 

The Length entry is used as 

element ID. 

The units of the parameters 

depend on the global unit 

selection, cf. section 0. 

See the illustrations below for the parameters which are to be defined. 



Zugfahrzeug 

Lorry 

Deichsellänge 

Shaft length 

Gelenk vorn 

Front joint 

(Element 1) 

= 0 

= 0 

Gelenk hinten 

Rear joint 

Achse vorn 

Front axle 

Achse hinten 

Rear axle 

Länge 

Length 

1. Wagen 

1st Car 

(Element 1) 


Shaft length 

= 0 

Gelenk vorn 

Front joint 

= 0 

Gelenk hinten 

Rear joint 

Achse vorn 

Front axle 

Achse hinten 

Rear axle 

Länge 

Length 

Bahn, Tram 

Train, Tram 

Anhänger 

Trailer 

(Element 2) 

Gelenk hinten 

Rear joint 


Shaft length 

Gelenk vorn 

Front joint 

Achse vorn 

Front axle 

Achse hinten 

Rear axle 

Länge 

Length 


= 0 

2. Wagen 

2nd Car 

(Element 2) 

Gelenk hinten 

Rear joint 

Gelenk vorn 

Front joint 


Shaft length 

Achse vorn 

Front axle 

Achse hinten 

Rear axle 

Länge 

Length

Distributions 

[DOORS] This tab contains the door 

data for 2D models of PT 

vehicles. 

For the selected element of 

the model, create a row per 

door and enter the following 

data: 

● Position: Distance of 

the door from the front 

of the vehicle element 

● Width: 

door 

Width of the 

● Z-Offset: Height above the link level 

● Side: Select Both, if the element has doors on both sides, or select the 

particular direction of traffic. 

● Usage: Select whether the door is intended for either Alighting or 

Boarding only or Both for alighting and boarding as well. Furthermore, 

option Closed is provided. 

For any length data, the unit currently selected via VIEW – OPTIONS – 

[LANGUAGE & UNITS] is regarded. 



5.2.5.2 3D Model Definition 

In the 2D/3D Model Distribution window, the 3D Model button opens the 

Select 3D Model window: 

In this window, you can select the 3D models for static objects, vehicles and 

pedestrians. 

Some of the V3DM settings can be made visible, though they are not subject 

to changes in VISSIM. 

A 3D model still has to be defined with the help of V3DM or any other 

appropriate tool. 


Menu bar 

File 

selection 

Distributions 

► In the PANEL OPTIONS menu, you may check or uncheck the display of the 

V3DM attribute panels one by one or all at once: 

- DIMENSIONS 

- STATES 

- DETAILS 

- LODS (LEVELS OF DETAIL) 

- TEXTURES 

When UNCHECK ALL is clicked, the Preview window will appear next to the 

navigator tree, since the sections in the middle are faded out. Closing the 

window will reset the Select 3D Model window view to the default 

settings. 

► In the VIEW OPTIONS menu, you may check or uncheck the display of the 

auxiliary view components known from V3DM one by one or all at once: 

- AXLE PLACEMENT 

- JOINT PLACEMENT 

- SHAFT LENGTH 

- DISPLAY GROUND 

Additionally, the LOCK LEVEL OF DETAIL command is provided. 

Beneath the menu bar, the path of the currently selected model file is 

displayed. 

The two buttons on top of the navigator tree allow for general path selection. 

Subsequently, select the appropriate *.V3D file in the list of files underneath. 

► Click the CURRENT PROJECT button to open the project folder of the 

currently loaded *.INP file. 

► Click the STANDARD 3D MODELS button to open the 3DMODELS folder 

which is provided in the EXE folder of your VISSIM installation. The 3D 

models provided with the VISSIM installation are stored in the following 

sub-folders: 

- STATIC 

- TEXTURES 

- VEHICLES 

All *.V3D files provided via the selected path are listed in the window section 

underneath and can be displayed in the Preview section after selection from 

the list of files. 



Element 

grouping 

Preview 

(3D) 

Section 

Textures 

Section Dimensions 

You may combine multiple elements to form a group representing a vehicle. 

● Show group elements: If this option is active, the selected elements 

are displayed in the pane on the bottom of the window. These elements 

are grouped automatically. Use the buttons to arrange them accordingly 

prior to Preview (3D) display. 

● ADD TO GROUP: This button is only provided if option Show group 

elements is active. Click this button to add the selected file to the 

Selected Model Elements section. 

Vehicles that consist of more than one element (e.g. trams) can be 

composed using ADD TO GROUP with a factor > 1 to combine the desired 

vehicle elements. 

The blinking cursor in the Selected Model Elements section indicates the 

current insert position for the next ADD TO GROUP action. You can move 

the cursor freely, even to the front position. 

● The corresponding buttons underneath the Selected Model Elements 

section allow for the following: 

- Use or to move the selected element to the correct position. 

- DELETE removes the selected element. 

- CLEAR ALL removes all of the contained elements from the selection. 

- PREVIEW shows the grouped elements in the Preview (3D) section. 

As soon as the Select 3D Model window is closed, the length of the vehicle is 

computed as the sum of the 3D elements. The length is shown in the Vehicle 

Type window (cf. section 5.3.1). 

For models of pedestrians, only the first element of the model is regarded. 

Other model elements are ignored. 

3D display of the selected model (or the model resulting from the grouped 

elements respectively). 

► Zoom: Use the mouse wheel to zoom in or out. The distance value on 

top of the preview is adjusted accordingly. 

Alternatively, you may change the View distance on top and confirm 

ENTER. The unit of the View distance depends on the current settings via 

menu VIEW – OPTIONS – [LANGUAGE & UNITS]. 

► Rotate: Left-click and keep the mouse-key pressed while moving the 

model display in any direction. 

For models which do not consist of grouped elements, the following details 

are displayed: 

● File size of the *.V3D file (Texture only, if applicable). 

● The original model view. 

For each model the Height, Width and Length data is displayed. In case of 

grouped elements, the new values are calculated immediately. 


Section 

Details 

Section 

States 

Section 

Levels of 

Detail 

Distributions 

● Base color: For color preview purposes, click the Color icon to open the 

palette. Select the appropriate VISSIM color (for example, as set by a 

type or class of vehicles or pedestrians) for the display of the 3D model. 

This selection cannot be stored in this window. Color settings are 

defined by means of color distributions per vehicle class or type, cf. 

section 5.3 (for pedestrians, cf. section 7.1 respectively). 

● # Polys: The variance of the number of polygons (high/low) is displayed. 

Next to the button, the number of states being available for this model is 

displayed. 

● ANIMATE: In case of various model states (as required for walking 

pedestrians, for example) all states are displayed automatically one by 

one. 

Alternatively, you may click the button indicating the particular direction 

to call the display of either the previous or the next state manually. 

Additionally to the global Level of Detail settings defined via VIEW – OPTIONS 

– [3D], you may define different LOD display parameters for the same 

distances and graphical display settings for additional distances for the 

particular 3D model. 

Click the or button to call the next LOD for this 3D model. The name of 

the currently displayed level is displayed. 

● Override global cutoffs: Check this option to redefine the global LOD 

settings by 3D model: 

- Simple (Simplified vehicle geometry beyond) 

- No lighting (No lighting beyond) 

- Blocks (Draw vehicle blocks beyond) 

● Min dist/level: Enter the new distance 

● # Polys (curr): Output of the number of polygons, the model consists of. 

The closer the distance, the more polygons are usually required for 

modeling. 

For Static 3D models, also the Elevation value ±0 can be entered and the 

degrees can be specified for rotation in any direction (YZ, XY, XZ). 

In 2D mode the vehicle is always displayed with the values (vehicle length, 

axle positions, …) entered / shown in the Geometry dialog. In 3D mode the 

3D model from the selected file is used. The geometry values from the 3D 

model file are ignored in the simulation after any modification in the 

Geometry dialog. This can cause vehicles to overlap or keep too large 

gaps in 3D mode. After loading an *.INP file a warning message is 

displayed if the geometry data differs from the values in the 3D model file. 

Accordingly, the selection of a new 3D model will overwrite all Geometry 

data. 



If a type´s link from the 2D model to a 3D model is lost or if no 3D model is 

assigned at all, in 3D mode the vehicle/pedestrian will be displayed as a 

colored box with the dimensions as defined for 2D Geometry. 

Due to the fact that 3D elements have a static length, a length distribution 

can be defined by choosing different models with different lengths into the 

same distribution. 

The color as chosen in the distribution or for a class or PT line will be used 

to fill all “designated surfaces” within the 3D model. Appropriate basic 

models provided, these surfaces may be specified in the optional VISSIM 

module “V3DM” (VISSIM 3D Modeler). 

During the simulation VISSIM uses a vehicle path algorithm to determine 

the location of subsequent elements within the network (trajectories). Thus 

the turning behavior of segmented vehicles will look more natural the 

higher the number of time steps per simulation second is set. 

New VISSIM files have a default model distribution for each vehicle type. 

The distribution for cars contains six different car models with different 

percentages. These models are assigned to predefined 3D vehicle models 

named CAR1.V3D ... CAR6.V3D. To change one of these default vehicle 

models, rename the desired *.V3D vehicle file to one of these file names. 

Caution: Changing a default vehicle model file causes different simulation 

results only if the changed geometry values are passed into the Geometry 

dialog by OK in the Select 3D Model dialog. 

5.2.6 Dwell Time Distribution (PT Stops & Parking Lots) 

The dwell time distribution is used by VISSIM for dwell times at 

► parking lots which have to be defined per time interval for routing 

decisions of the parking lot type, cf. section 6.4.4, 

► stop signs and e.g. toll counters, 

► PT stops. For PT vehicles (e.g. buses, trams) the amount of time they 

stop at a passenger pick up area has to be defined for each PT stop or 

train station if the time required for boarding and alighting is not 

calculated by one of the methods provided. 

A Dwell Time Distribution can be defined or edited by BASE DATA - 

DISTRIBUTIONS - DWELL TIME... Two types are provided: 


● Normal distribution: A normal distribution 

is defined by the mean value and 

the standard deviation (in seconds). 

Defining the standard deviation as 0s 

creates a constant dwell time. If a 

negative dwell time results from the 

normal distribution it is automatically 

cut to 0s. 

Distributions 

● Empirical distribution: An empirical distribution is defined by providing a 

minimum and a maximum value and any number of intermediate points 

to build a graph of various shapes (similar to the definition of speed 

distributions, cf. section 5.2.1). Thus any type of distribution can be 

defined. 

For the allocation of dwell time distributions to stops, cf. section 6.5.2.5. 

5.2.7 Location Distribution (PT Boarding/Alighting Pass.) 

The allocation of alighting passengers to the doors of a PT vehicle can be 

defined through a Location Distribution via BASE DATA - DISTRIBUTIONS - 

LOCATION.... 

It shows how the total number of boarding and alighting passengers is 

spread over the whole length of the vehicle. Each door of a vehicle dwelling 

inside the PT stop (which is used for boarding and alighting) calculates "its" 

part of the total vehicle length: 

► half-way to the adjacent door(s) respectively 

► full distance to the front/rear of the vehicle. 

To each share of the total vehicle length, the increase in y direction over this 

part on the x axis of the location distribution is assigned as percentage of 

passengers to the respective door. 

► The alighting location distribution can be selected per PT line stop: 

Double-click on a red PT stop in a selected PT line, cf. section 6.5.2.5. 

Default is no distribution which assigns the same percentage to each 

door (regardless of the position). 

► The boarding location distribution can be selected for each pedestrian 

area with PT usage separately in the Boarding location selection list, cf. 


Default is Nearest door which assigns each boarding passenger to the 

door which is situated most closed to him and can be reached quickly. 

VISSIM provides five predefined distributions: 

● Uniform: linear over the whole length of the vehicle 

● Center: more passengers alight near to the middle of the vehicle 

● Front: more passengers near the front 



● Rear: more passengers near the rear 

● Front and Rear: fewer passengers near the middle of the vehicle 

► Click NEW to add another distribution. 

► Click DELETE to discard the selected distribution. 

► Click EDIT to modify the properties of the selected distribution in the 

graph: 

5.2.8 Temperature Distribution (Cold Emissions module only) 

The temperature of the coolant and of a catalytic converter of vehicles can 

be defined as a temperature distribution. Along with other distributions it 

effects the emission results when using the optional internal cold engine 

emissions module. 

A Temperature Distribution can be defined or edited by BASE DATA – 

DISTRIBUTIONS – TEMPERATURE... in the same way as a speed distribution (cf. 

5.2.1 for details). 


5.3 Vehicle Type, Class and Category 

Vehicle 

type 

Vehicle 

class 

Vehicle 

category 

Vehicle Type, Class and Category 

VISSIM uses a hierarchical concept to define and provide vehicle information 

at different levels throughout the application. This table shows the individual 

levels: 

Group of vehicles with similar technical characteristics and physical driving 

behavior. Typically the following are vehicle types: car, LGV, HGV (truck), 

bus, articulated Bus, Tram, Bike, Pedestrian. 

One or more vehicle types are combined in one vehicle class. Speeds, 

evaluations, route choice behavior and certain other network elements refer 

to vehicle classes. By default one vehicle class refers to one vehicle type 

with the same name. More than one vehicle type is to be included in a 

vehicle class if they incorporate a similar general driving behavior but have 

different vehicle characteristics (e.g. acceleration values). If only the shape 

and length of a vehicle is different they can be placed in the same type using 

the vehicle model and color distributions. 

► Example 1: The models “Car1” to “Car6” refer to different models with 

different vehicle length yet similar driving behavior. Therefore they can 

be placed into one vehicle type using a model distribution with the six 

different models. 

► Example 2: Standard and articulated buses only differ in length, thus they 

can be placed into one type with a distribution of two models. Exception: 

When these two bus types need to be used in different PT routes then 

they need to be defined as two separate vehicle types. 

Preset, static categories of vehicles that incorporate similar vehicle 

interaction. For instance, the vehicle category “tram” does not allow for lane 

changes on multi-lane links and does not oscillate around its desired speed. 

Every vehicle type is to be assigned to a vehicle category. 

5.3.1 Vehicle Types 

In addition to the default vehicle types (Car, HGV, Bus, Tram, Bike and 

Pedestrian), new vehicle types can be created. Existing types can be 

modified. For vehicles of the same category having different e.g. acceleration 

or speed properties, the appropriate number of vehicle types need to be 

defined. 

The data associated with vehicle types is accessed by BASE DATA – VEHICLE 

TYPES... 

Press one of the buttons EDIT, NEW or COPY or double-click the selected list 

entry to open the Vehicle Type window. The following parameters are 

available: 



[STATIC] 

● No.: Unique vehicle type 

identification 

● Name: Any name or comment 

● Category: Defines the vehicle 

category 

● Vehicle Model: Defines the 

shape and length (distribution) 

of the vehicle type by selection 

of one of the defined model 

distributions. New models 

cannot be defined directly within 

the vehicle type data but in the 

vehicle model distribution (cf. 

5.2.5). 

● Length: Shows the range of 

vehicle lengths (min. and max.) 

according to the selected model 

distribution (this value is read 

only). 

● Width: Defines the displayed width of a 2D vehicle in VISSIM. This 

parameter is relevant also if overtaking within the same lane is possible 

(cf. “lateral behavior” in the driving behavior parameter set). 

● Occupancy: Defines the number of persons (including the driver) 

contained in a vehicle. 

● Color determines the color distribution that the current vehicle type will 

have. When displaying the vehicle in 3D, all VISSIM specific objects of 

that model (to be defined in the optional add-on “VISSIM 3D Modeler”) 

will be filled with that color. For color distributions, cf. section 5.2.4. 

The color information may be overruled by the color of the vehicle class 

to which this vehicle type is assigned or by the route color of a PT 

vehicle. 


[FUNCTIONS 

& DISTRIBU- 

TIONS] 

● Acceleration and Deceleration 

curves: Define the 

acceleration and deceleration 

behavior of that vehicle type. 

For more information cf. 

section 5.1. 

● The Weight and Power 

distributions are active only 

for vehicle types of Category 

HGV, and also, if an external 

model is selected. For further 

details cf. sections 5.2.2 and 


[SPECIAL] Dynamic Assignment: 

● COST COEFFICIENTS: Opens 

the Cost Coefficients window. 

For further details please refer 

to section 12.5. 

● Equipment: Defines if the 

vehicle has any route 

guidance system or similar 

equipment installed. This 

setting is relevant for en-route 

re-routing within a Dynamic 

Assignment. 


● PARKING LOT SELECTION: 

This data is used for 

vehicle routing in Dynamic 

Assignment. The parameters 

determine the desired 

destination in the 

Decision Situation described 

in the list box on 

top. All parameters are 

weights added to the 

values attributed to parking 

lots in the situation. 

For example, if the Parking Cost variable is weighted heavily, then 

cheaper parking lots will have an advantage over closer parking lots. 



[EXTERNAL 

DRIVER 

MODEL] 

Others: 

● PT PARAMETERS (only applicable for public transport vehicles): Opens the 

Vehicle Type window: PT parameters to define the parameters for dwell 

time calculation (cf. section 6.5.2.6, option B). 

● The EMISSION CALCULATION settings will only be effective if an emission 

model (optional VISSIM module) is activated. For details please refer to 

separate documentation. 

● External Emission Model (not available in all VISSIM licenses): 

Indicates that this vehicle type is subject to an external emission model. 

● Use external driver model 

(add-on): Indicates that this 

vehicle type is not subject to the 

VISSIM driving behavior 

parameters but ruled by an 

external driver model. 

● Path and filename of driver model 

DLL: Enter or select filename. 

● Path and filename of parameter 

file: Enter or select filename. 

VISSIM sends the following data to the *.DLL even if 0 was returned by 

DriverModelGetValue (DRIVER_DATA_SETS_XY_COORDINATES, ...): 

► DRIVER_DATA_VEH_REAR_X_COORDINATE and 

► DRIVER_DATA_VEH_REAR_Y_COORDINATE 

This means that vehicle rear world coordinates are available in an external 

driver model for vehicles on VISSIM links. 

Two new type codes have been added to the files DRIVERMODEL.CPP and 

DRIVERMODEL.H in VISSIM version 5.20-10: 

► DRIVER_DATA_STATUS 

► DRIVER_DATA_ STATUS _DETAILS 

In the DRIVERMODEL.CPP, the command DriverModelSetValue() can 

handle the following two parameters without returning zero: 

► DRIVER_DATA_VEH_ACTIVE_LANE_CHANGE 

► DRIVER_DATA_VEH_REL_TARGET_LANE 


5.3.2 Vehicle Classes 


A vehicle class represents a logical container for one or more previously 

defined vehicle types. A vehicle type can also be part of several vehicle 

classes, thus “overlapping” classes are possible. 

Vehicle classes can be defined and edited via BASE DATA – VEHICLE CLASSES. 

The Vehicle Classes window contains a list of all 

classes defined. Use the control buttons to the 

right to edit the list. 

To define a Vehicle Class, all of the vehicle types 

that are to be included must be highlighted in the 

list of Vehicle Types. A multi-selection is done by 

pressing CTRL while clicking on the desired 

vehicle type(s). 

Furthermore, the following parameters 

may be defined: 

● No.: Unique identification of the class 

● Name: Label of the class 

● COLOR (only active, if option Use 

vehicle type color is unchecked): 

Defines the vehicle color for all 

vehicle types contained in that class. 

This overrides all color information of 

the vehicle types and can be used to 

identify vehicles of a certain class by 

color, cf. section 4.2.2.1. 

● Use vehicle type color: If checked, the vehicle color is determined by 

each vehicle type (or PT route respectively). 

A new class can be used to collect data specifically for certain vehicle 

types or to distinguish those vehicles by color during a simulation. 



5.4 Driving Behavior 

Add 

parameter 

set 

Delete 

parameter 

set 

Both the car following and lane change models in VISSIM use an extensive 

range of parameters. Some of these may be adapted by the experienced 

user to change basic driving behavior. 

As these parameters directly affect the vehicle interaction and thus can 

cause substantial differences in simulation results, only experienced users 

should eventually modify any of the parameters described in this section. 

The driving behavior is linked to each link by its behavior type. For each 

vehicle class, a different driving behavior parameter set may be defined - 

even within the same link (cf. section 5.5). The parameter sets can be edited 

in the Driving Behavior Parameter Sets windows which is accessible by BASE 

DATA – DRIVING BEHAVIOR. 

By default, five different parameter sets are predefined. 

Right-click in the list to call the context menu. 

► Click NEW (or DUPLICATE after selection of a set). 

► Enter No. and Name in the main window. 

► Enter the parameters in the tab pages. 

► Select the parameter set in the list. 

► Click DELETE in the context menu. 


5.4.1 The “Wiedemann” Approach 

Driving Behavior 

The traffic flow model in VISSIM is a discrete, stochastic, time step based, 

microscopic model with driver-vehicle-units as single entities. The model 

contains a psycho-physical car following model for longitudinal vehicle 

movement and a rule-based algorithm for lateral movements. The model is 

based on the continued work of Wiedemann. [1] [2] 

The basic idea of the Wiedemann model is the assumption that a driver can 

be in one of four driving modes (cf. also illustration in section 1.2): 

► Free driving: No influence of preceding vehicles observable. In this 

mode the driver seeks to reach and maintain a certain speed, his 

individually desired speed. In reality, the speed in free driving cannot be 

kept constant, but oscillates around the desired speed due to imperfect 

throttle control. 

► Approaching: The process of adapting the driver’s own speed to the 

lower speed of a preceding vehicle. While approaching, a driver applies a 

deceleration so that the speed difference of the two vehicles is zero in 

the moment he reaches his desired safety distance. 

► Following: The driver follows the preceding car without any conscious 

acceleration or deceleration. He keeps the safety distance more or less 

constant, but again due to imperfect throttle control and imperfect 

estimation the speed difference oscillates around zero. 

► Braking: The application of medium to high deceleration rates if the 

distance falls below the desired safety distance. This can happen if the 

preceding car changes speed abruptly, of if a third car changes lanes in 

front of the observed driver. 

For the complete list of interaction states which can be recorded during the 

simulation please refer to section 11.7. 

For each time step, the vehicle’s state of interaction can be displayed in the 

vehicle information window or stored with the vehicle protocol file, cf. 

section 11.6 and section 11.7. 

For each mode, the acceleration is described as a result of speed, speed 

difference, distance and the individual characteristics of driver and vehicle. 

The driver switches from one mode to another as soon as he reaches a 

certain threshold that can be expressed as a combination of speed difference 

and distance. For example, a small speed difference can only be realized in 

small distances, whereas large speed differences force approaching drivers 

to react much earlier. The ability to perceive speed differences and to 

estimate distances varies among the driver population, as well as the desired 

speeds and safety distances. 

1 Wiedemann, R. (1974). Simulation des Straßenverkehrsflusses. Schriftenreihe des 

Instituts für Verkehrswesen der Universität Karlsruhe, Heft 8. 

2 Wiedemann, R. (1991). Modeling of RTI-Elements on multi-lane roads. In: Advanced 

Telematics in Road Transport edited by the Commission of the European Community, 

DG XIII, Brussels. 



Because of the combination of psychological aspects and physiological 

restrictions of the driver’s perception, the model is called a psycho-physical 

car-following model. 

The following sections describe the various behavior parameters in VISSIM. 

5.4.2 Car Following Behavior 

These parameters are available: 

● The Look ahead distance defines the distance that a vehicle can see 

forward in order to react to other vehicles either in front or to the side of it 

(within the same link). This parameter is in addition to the number of 

Observed Vehicles. 

- The min. value is important when modeling lateral vehicle behavior. 

Especially if several vehicles can queue next to each other (e.g. 

bikes) this value needs to be increased. The value depends on the 

approach speed. In urban areas it could be 20-30m (60-100 ft). 

- The max. value is the maximum distance allowed for looking ahead. 

It needs to be extended only in rare occasions (e.g. for modeling 

railways if signals and stations are to be recognized in time) 

Without increasing the min. look ahead distance while modeling lateral 

behavior it may happen that vehicles do not stop for red lights or for each 

other. The Number of Observed Vehicles (by default: 4 for Urban driving 

behavior, else 2) should not be changed to compensate for this behavior as 

it might easily result in unrealistic behavior elsewhere. 



● The number of Observed vehicles affects how well vehicles in the 

network can predict other vehicles´ movements and react accordingly. As 

some of the network elements are internally modeled as vehicles it might 

be useful to increase this value if there are several cross sections of 

network elements within a short distance. However, the simulation will 

run slower with higher values. 

● The Look back distance defines the distance that a vehicle can see backwards 

in order to react to other vehicles behind (within the same link). 

- The min. value is important when modeling lateral vehicle behavior. 

Especially if several vehicles can queue next to each other (e.g. 

bikes) this value needs to be increased. The value depends on the 

approach speed. In urban areas it could be 20-30m (60-100 ft). 

- The max. value is the maximum distance allowed for looking 

backward. In networks with many small meshes, e.g. with many 

connectors over a short distance, the simulation speed can be 

improved if the maximum look back distance is reduced from the 

default value. 

● Temporary lack of attention (“sleep” parameter): Vehicles will not react to 

a preceding vehicle (except for emergency braking) for a certain amount 

of time. 

- Duration defines how long this lack of attention lasts. 

- Probability defines how often this lack of attention occurs. 

The higher both of these parameters are, the lower the capacity on the 

corresponding links will be. 

● Car following model selects the basic model for the vehicle following 

behavior. Depending on the selected model the Model parameters 

change. 

- Wiedemann 74: Model mainly suitable for urban traffic 

- Wiedemann 99: Model mainly suitable for interurban (motorway) 

traffic 

- No Interaction: Vehicles do not recognize any other vehicles (can be 

used for a simplified pedestrian behavior). 

● Model parameters: Depending on the selected Car following model a 

different number of Model parameters is available. Cf. sections 5.4.2.1 

and 5.4.2.2 for details. 

These are the main parameters to affect the saturation flow rate. For 

examples, cf. section 5.4.6. 

5.4.2.1 Wiedemann 74 Model Parameters 

This model is an improved version of Wiedemann’s 1974 car following 

model. The following parameters are available: 

● Average standstill distance (ax) defines the average desired distance 

between stopped cars. It has a variation between -1.0 m and +1.0 m 



which is normal distributed around 0.0 m with a standard deviation of 0.3 

m. 

● Additive part of desired safety distance (bx_add) and Multiplic. part of 

desired safety distance (bx_mult) affect the computation of the safety 

distance. The distance d between two vehicles is computed using this 

formula: 

d = ax + bx 

where ax is the standstill distance 

bx = ( bx _ add + bx _ mult * z) 

* 

v is the vehicle speed [m/s] 

z is a value of range [0,1] which is normal distributed around 0.5 with a 

standard deviation of 0.15. 

5.4.2.2 Wiedemann 99 Model Parameters 

This model is based on Wiedemann’s 1999 car following model. The 

following parameters are available: 

● CC0 (Standstill distance) defines the desired distance between stopped 

cars. It has no variation. 

● CC1 (Headway time) is the time (in s) that a driver wants to keep. The 

higher the value, the more cautious the driver is. Thus, at a given speed 

v [m/s], the safety distance dx_safe is computed to: 

dx_safe = CC0 + CC1 • v. 

● The safety distance is defined in the model as the minimum distance a 

driver will keep while following another car. In case of high volumes this 

distance becomes the value with the strongest influence on capacity. 

● CC2 (‘Following’ variation) restricts the longitudinal oscillation or how 

much more distance than the desired safety distance a driver allows 

before he intentionally moves closer to the car in front. If this value is set 

to e.g. 10m, the following process results in distances between dx_safe 

and dx_safe + 10m. The default value is 4.0m which results in a quite 

stable following process. 

● CC3 (Threshold for entering ‘Following’) controls the start of the 

deceleration process, i.e. when a driver recognizes a preceding slower 

vehicle. In other words, it defines how many seconds before reaching the 

safety distance the driver starts to decelerate. 

● CC4 and CC5 (‘Following’ thresholds) control the speed differences 

during the ‘Following’ state. Smaller values result in a more sensitive 

reaction of drivers to accelerations or decelerations of the preceding car, 

i.e. the vehicles are more tightly coupled. CC4 is used for negative and 

CC5 for positive speed differences. The default values result in a fairly 

tight restriction of the following process. 


v


● CC6 (Speed dependency of oscillation): Influence of distance on speed 

oscillation while in following process. If set to 0 the speed oscillation is 

independent of the distance to the preceding vehicle. Larger values lead 

to a greater speed oscillation with increasing distance. 

● CC7 (Oscillation acceleration): Actual acceleration during the oscillation 

process. 

● CC8 (Standstill acceleration): Desired acceleration when starting from 

standstill (limited by maximum acceleration defined within the 

acceleration curves) 

● CC9 (Acceleration at 80 km/h): Desired acceleration at 80 km/h (limited 

by maximum acceleration defined within the acceleration curves). 

5.4.3 Lane Change 

There are basically two kinds of lane changes in VISSIM: 

► Necessary lane change 

(in order to reach the next connector of a route) 

► Free lane change 

(because of more room / higher speed) 

In case of a necessary lane change, the driving behavior parameters contain 

the maximum acceptable deceleration for the vehicle and the trailing vehicle 

on the new lane, depending on the distance to the emergency stop position 

of the next connector of the route. 

In case of a free lane change, VISSIM checks for the desired safety distance 

of the trailing vehicle on the new lane. This safety distance depends on its 

speed and the speed of the vehicle that wants to change to that lane. There 

is currently no way for the user to change the "aggressiveness" for these 

lane changes. However, changing the parameters for the desired safety 

distance (which are used for the vehicle following behavior) will effect the 

free lane changes as well. 

In both cases, when a driver tries to change lanes, the first step is to find a 

suitable time gap (headway) in the destination flow. The gap size is 

dependent on the speed both of the lane changer and the vehicle that 

“comes from behind” (on that lane the lane changer changes to). In case of a 

necessary lane change it also depends on the deceleration values of the 

“aggressiveness”. 



Lane Change Parameters 

● General Behavior: Defines the way of overtaking: 

- Free Lane Selection: Vehicles are allowed to overtake in any lane. 

- Right Side Rule resp. Left Side Rule: Allows overtaking in the fast 

lane only if the speed in the fast lane is > 60 km/h. For slower 

speeds, vehicles in the slow lane are allowed to “undertake” with a 

max. speed difference of 20 km/h. 

To improve the general lane change behavior with either option, you can 

add the parameters for cooperative lane changing to the *.INP file with a 

text editor: 

If the keyword COOPERATIVE follows after the keyword 

RIGHT_HAND_RULE or FREE_LANESEL in the *.INP file, the lane 

change behavior of the respective driving behavior parameter set will be 

more cooperative. In this case, a vehicle A who sees that the leading 

vehicle B on the adjacent lane wants to change to the lane of the vehicle 

A tries to change lanes itself to the other side in order to make room. It 

behaves as if it had to change lanes for a connector far in the distance, 

accepting only the base values for necessary lane changes ("Accepted 

deceleration") for its own deceleration and for the trailing vehicle C on the 

new lane. Vehicle A does not change cooperatively to a lane which is 

less suited for its own route, and it does not change lanes cooperatively if 

vehicle B is more than 3 m/s faster or if the collision time would be more 

than 10 seconds with the speed of vehicle A increased by 3 m/s. These 

two parameters can be optionally changed, too, in the *.INP file, after the 

keyword COOPERATIVE: 

COOPERATIVE SPEED COLLISION_TIME . 


Necessary 

Lane 

Change 

(Route) 


If they are not specified, the default values 3 m/s and 10 seconds are 

used. 

Example *.INP: 

… 

-- Driving Behavior: -- 

----------------------- 

DRIVING_BEHAVIOR 1 NAME "Urban (motorized)" 

LANE_CHANGE_BEHAVIOR FREE_LANESEL COOPERATIVE SPEED 3.0 COLLISION_TIME 10.0 

T_DISAPPEAR 60.00 MIN_LC_GAP 0.50 MIN_FREEFLOW 0.00 

MIN_ACCELERATION OWN MIN -3.00 DISTANCE 50.00 MAX -1.00 

TRAILING_VEHICLE MIN -3.00 DISTANCE 50.00 MAX 0.00 

CAR_FOLLOW_MODEL WIEDEMANN74 

NUMB_PRECED 2 OBS_DISTANCE MIN 0.00 MAX 250.00 REAR_OBS_DISTANCE MIN 0.00 MAX 

150.00 

AX_AVERAGE 2.00 BX_ADD 2.00 BX_MULT 3.00 

CC0 1.50 CC1 0.90 CC2 4.00 CC3 -8.00 CC4 -0.35 

CC5 0.35 CC6 11.44 CC7 0.25 CC8 3.50 CC9 1.50 

LATERAL_BEHAVIOR MIDDLE 

OVERTAKE RIGHT VEHICLE_CLASSES 

OVERTAKE LEFT VEHICLE_CLASSES 

LAT_DISTANCE DEFAULT DY_STAND 1.00 DY_50KMH 1.00 

TURN COLLISION_TIME 2.00 SPEED 1.00 

AMBER_BEHAVIOR CONT_CHECK 

AMBER_ALPHA 1.59000000 AMBER_BETA1 -0.26000000 AMBER_BETA2 0.27000000 

DRIVING_BEHAVIOR 2 NAME "Right-side rule (motorized)" 

LANE_CHANGE_BEHAVIOR RIGHT_HAND_RULE COOPERATIVE 





… 

For lane changes that result from routes, the aggressiveness of lane change 

can be defined. This is done by defining deceleration thresholds both for the 

lane changer (Own) and the vehicle that he is moving ahead of (Trailing). 

The range of these decelerations is defined by the Maximum and Accepted 

Decelerations. In addition, a reduction rate (as meters per 1 m/s²) is used to 

reduce the Maximum Deceleration with increasing distance from the 

emergency stop position. 

Example: The following parameters result in the graph shown below: 



Other 

Parameters 

[m/s2 [m/s ] 2 ] 

-3.50 

-3.00 

-2.00 

-1.00 

-0.25 

‚lane changer‘ (Own) 

Trailing vehicle 

-1000m -500m Emerg. stop 

● Waiting time before diffusion defines the maximum amount of time a 

vehicle can wait at the emergency stop position waiting for a gap to 

change lanes in order to stay on its route. When this time is reached the 

vehicle is taken out of the network (diffusion) and a message will be 

written to the error file denoting the time and location of the removal. 

● Min. Headway (front/rear) defines the minimum distance to the vehicle in 

front that must be available for a lane change in standstill condition. 

● The value for To slower lane if collision time is used only if Lane Change 

Behavior is set to Right Side Rule resp. Left Side Rule. It describes the 

minimum time headway towards the next vehicle on the slow lane so that 

a vehicle on the fast lane changes to the slower lane. 

● Safety distance reduction factor: During lane changes the reduction 

factor is regarded, which takes effect for 

- the safety distance of the trailing vehicle in the new lane for the 

decision whether to change lanes or not, 

- the own safety distance during a lane change and 

- the distance to the leading (slower) lane changing vehicle. 

During any lane change, the resulting shorter safety distance is 

calculated as follows: original safety distance x reduction factor. The 

default factor of 0.6 reduces the safety distance by 40%. After the lane 

change, the original safety distance is regarded again. 



● Maximum deceleration for cooperative braking: Defines if a trailing 

vehicle will start cooperative braking allowing a leading vehicle to change 

from an adjacent lane into its lane. If the trailing vehicle determines that it 

would have to brake with a higher deceleration than this value if the 

leading vehicle started the lane change, it does not start or continue 

cooperative braking. A higher value will result in more braking and thus 

probability of lane changing. The leading vehicle will still initiate the lane 

change dependent upon the safety distance reduction factor for lane 

changing and car-following parameters. Maximum values suggested are 

0.7-1.0 local acceleration due to gravity (9.81 m/s², 32.2 ft/s²). 

Cooperative braking uses the following: 

- up to 50% of the desired deceleration (cf. section 5.1) until the 

leading vehicle starts changing lanes, 

- between 50% of the desired deceleration and this user-defined 

Maximum deceleration. Typically, deceleration during lane changes 

will be significantly lower than the Maximum deceleration, since a 

lane changing leading vehicle will not expect an extremely high 

deceleration of the trailing vehicle. 

Note: Lane change behavior is similar to VISSIM version 4.10, if the 

- Safety distance reduction factor is set to 0.0 - 0.1 and 

- Maximum deceleration for cooperative braking is set to -9m/s². 

● Overtake reduced speed areas: This option is off by default. 

- If this option is checked, you can model lane-dependent speed 

restrictions which are considered for lane changing. 

If this option is not checked, vehicles never change lanes directly 

upstream of a reduced speed area. Furthermore, they ignore reduced 

speed areas on the target lane. 



5.4.4 Lateral Behavior 

By default, one vehicle occupies the entire width of one lane in VISSIM. The 

lateral behavior parameters enables vehicles to travel at different lateral 

positions and also overtake other vehicles within the same lane if it is wide 

enough. 

These parameters are available: 

● Desired position at free flow defines the desired lateral position of a 

vehicle within the lane while it is in free flow. The options are: Middle of 

Lane, Any or Right resp. Left. 

● Observe vehicles on next lane(s): Vehicles also consider the lateral 

position of vehicles that are traveling on adjacent lanes and keep the 

minimum lateral distance. For this purpose, they even adjust their own 

lateral position in their own lane by drawing aside. The simulation also 

regards the exact position of the rear ends of vehicles during or after lane 

change to adjacent lanes. If this option is not ticked, vehicles in adjacent 

lanes are ignored even if their widths exceed the width of their lanes 

(except in case of lane changing). 

This option will reduce the simulation speed significantly. 

● Diamond shaped queuing: Allow for staggered queues (e.g. for 

cyclists) according to the realistic shape of vehicles. 

● Consider next turning direction: For none lane based traffic, this option 

provides improved modeling of the lateral behavior upstream of turns. 

If this option is checked, late overtaking of vehicles going through is 

avoided in the with-flow direction toward the direction of the turn. 

The relevant connector is always the first one downstream in the 

vehicle's route which has a desired direction value of "left" or "right". If 



the vehicle is inside the lane change distance of this connector (ignoring 

the flag "lane change distance per lane") the vehicle moves laterally on 

its lane to the respective side and vehicles which do not want to turn at 

the same connector or earlier on the same side try not to overtake the 

vehicle on that side. (In previous versions, only the immediate next 

connector was checked, and the lane change distance was ignored.) 

With the *.INP file, a data row consisting of the three driving behavior 

parameters for lateral behavior is stored on top of the 

AMBER_BEHAVIOR data row in this case. 

Example: 

… 

DRIVING_BEHAVIOR 1 NAME "Urban (motorized)" 

LANE_CHANGE_BEHAVIOR FREE_LANESEL COOPERATIVE 





NUMB_PRECED 2 OBS_DISTANCE MIN 0.00 MAX 250.00 REAR_OBS_DISTANCE MIN 0.00 MAX 

150.00 

AX_AVERAGE 2.00 BX_ADD 2.00 BX_MULT 3.00 

CC0 1.50 CC1 0.90 CC2 4.00 CC3 -8.00 CC4 -0.35 

CC5 0.35 CC6 11.44 CC7 0.25 CC8 3.50 CC9 1.50 

LATERAL_BEHAVIOR MIDDLE 

OVERTAKE RIGHT VEHICLE_CLASSES 

OVERTAKE LEFT VEHICLE_CLASSES 

LAT_DISTANCE DEFAULT DY_STAND 1.00 DY_50KMH 1.00 

TURN COLLISION_TIME 2.00 SPEED 1.00 

AMBER_BEHAVIOR CONT_CHECK 

AMBER_ALPHA 1.59000000 AMBER_BETA1 -0.26000000 AMBER_BETA2 0.27000000 

… 

Please note, that the default values of the latter two AMBER_BEHAVIOR 

parameters can only be modified manually in the *.INP file. 

These parameters work as follows: 

Parameter Meaning 

TURN The direction (left / right / through (= "all")) of 

the next turning movement (i.e. the next 

connector of the vehicle's route) is taken into 

consideration: 

● The vehicle does not change the lateral 

position in order to overtake a vehicle on 

the wrong side (since this would cause a 

collision at the next intersection) 

● The vehicle moves laterally on the lane to 

the side of the next turn if there is room. 

Option Consider next turning direction has precedence 

over option Desired position at free 

flow. 

Please note, that the lane change distance of 

the connector is ignored so far and only the 



Parameter Meaning 

next connector is considered. 

COLLISION_TIME Minimum collision time gain (calculated with the 

desired speed of the vehicle) which is required 

for a change of the lateral position. The default 

= 2 seconds can be set to a lower value if 

vehicles should move laterally for smaller 

advantages, too. 

SPEED Minimum longitudinal speed [m/s] allowing 

lateral movement. The default = 1 m/s can be 

set to a lower value if vehicles should move 

laterally even if they have almost come to a 

standstill already. 

● Overtake on same lane: Select all vehicles classes that are allowed to be 

overtaken within the same lane by any vehicle of that class for which this 

parameter set is assigned. You can define also on which side they are to 

be overtaken (on left, on right or on both sides within the same lane). 

● Min. Lateral Distance: Minimum distances for vehicles passing each 

other within the same lane and for the lateral distance to vehicles in the 

adjacent lane are defined for each vehicle class to be passed. The 

distance is defined for standstill (at 0 km/h) as well as for 50 km/h. For 

other speed values, the appropriate minimum distance value is gained by 

linear interpolation. For those vehicle classes where no values are 

defined, the default definition applies. 

Example 

Bikes and cars travel on the same one-lane-link. Bikes are to drive on the 

right hand-side. Cars are allowed to overtake bikes on the left; bikes are 

allowed to overtake cars on the right, and other bikes on the left. 

This behavior is accomplished in VISSIM as follows: 

1. Create a new parameter set “Urban lateral” as a copy based on “Urban” 

behavior. 

2. Edit parameters: 

- [FOLLOWING] min. look ahead distance: from 0 

to 30m 

- [LATERAL] Overtake on same lane: Add new 

line and select vehicle class “Bike” to be 

overtaken on left. 

3. Create a new parameter set “Urban cycle” as a copy based on “Cycle- 

Track” behavior. 

4. Edit parameters in [LATERAL] Overtake on same lane: 


- uncheck “All” vehicle classes, 

- add new line and select vehicle class “Car” 

to be overtaken on right, 

- add new line and select vehicle class “Bike” 

to be overtaken on left. 


5. Create a new link behavior type “Urban lateral cycle”. Assign the “Urban 

lateral” behavior as default, and additionally assign the “Urban cycle” 

behavior to vehicle class “Bike”. 

6. Assign the new link behavior type “Urban lateral cycle” to the desired 

link(s). 

5.4.5 Signal Control 

Reaction to amber signal 

The decision model defines the vehicle behavior in front of a signal control 

showing amber. 

● Decision model: Select the appropriate decision model. 

- Continuous Check: Vehicles assume that the amber light stays 

amber for 2 seconds and continuously decide whether to proceed at 

each time step thereafter until passing the signal head. 

The vehicle will not brake, if even the maximum deceleration would 

not allow for a stop at the stop line or if a value > 4.6 m/s 2 would be 

required for braking to the halt. 



The vehicle brakes if it cannot pass the signal head within 2 seconds 

when continuing at its current speed rate. 

In the range in-between, if both options applied, a normally 

distributed random variable decides whether the vehicle brakes. 

- One Decision: The probability p of the driver stopping at amber light 

is calculated using a logistic regression function with the current 

speed v and the distance from the vehicle front to the stop line dx as 

independent variables and three fitting parameters (Alpha, Beta 1, 

Beta 2): 

p = 

1+ 

e 

1 

−α 

−β 

1v− 

β 2dx 

The provided standard parameter values have been derived from 

empirical data. 

Enter the appropriate probability factors. 

A decision is kept until the vehicle has passed the stop line. 

The option One Decision will produce the most accurate results if the 

number of Observed vehicles is increased accordingly (see [FOLLOWING]). 

This is due to the fact that a signal head internally is modeled as a vehicle 

and will only be recognized if the number of vehicles and network elements 

in front of the signal head does not exceed the value resulting from number 

of Observed vehicles minus 1. 

Applied deceleration 

Once the driver has decided to stop according to the decision model, a 

constant deceleration rate will be calculated for the target braking to the 

stop line, cf.section 5.1. 

The applied deceleration rate bapplied depends on the distance to the stop 

line dx and the current vehicle speed v and is calculated as follows: 

Where brequired is the required deceleration and bmax is the maximum 

possible deceleration according to the defined deceleration function. 


Behavior at red/amber signal 


This parameter defines the vehicle behavior in front of a signal control 

showing red/amber. 

For the driving behavior parameter set, you can select Go (same as green) 

or Stop (same as red) to adjust the behavior to different country/region 

specific habits or rules: 

Reduced safety distance close to a stop line 

These parameters define the vehicle behavior close to a stop line. 

● Reduction factor: Within the given distance from Start to End, the userdefined 

reduction factor is applied to the vehicle´s desired safety 

distance, cf. section 5.4.3. 

For lane changes in front of a signal control, both the resulting values are 

compared to each other. VISSIM will use the shorter distance. 

● Start upstream of stop line: Distance upstream of the signal head. 

● End downstream of stop line: Distance downstream of the signal head. 

5.4.6 Changing the Saturation Flow Rate 

In VISSIM the saturation flow is a result of a combination of parameters that 

are relevant for the simulation. Thus the saturation flow cannot be explicitly 

defined but experienced users may want to change the relevant driving 

behavior parameters in order to get a different saturation flow rate. The 

saturation flow rate defines the number of vehicles that can free flow on a 

VISSIM link during a period of one hour. 

Depending on the selected Car following model different Model parameters 

are available, cf. section 5.4.2.1 and section 5.4.2.2 for details. 

Wiedemann 74 Car Following Model 

The model contains two parameters which have major influence on the 

safety distance and thus affect the saturation flow rate. 

These parameters are: 

► Additive part of desired safety distance (bx_add) and 

► Multiplicative part of desired safety distance (bx_mult) 

Apart from that the saturation flow rate is also dependent on many other 

parameters, such as vehicle speed, truck percentage, number of lanes etc. 

The results shown in the graph below provide the resulting saturation flows 

for some specific VISSIM examples only. The results will be different for 

networks that do not conform with the properties of these examples. 

The graph below is based on the following assumptions: 

► single lane link, 



► speed distribution 48-58 km/h, 

► standard driving parameters except the values for both bx_add and 

bx_mult which are shown on the x-axis (in this example bx_add equals 

bx_mult -1), 

► one time step per simulation second. 

veh / h / lane 

2400 

2200 

2000 

1800 

1600 

1400 

Saturation Flow 

1200 

2,00 2,25 2,50 2,75 3,00 3,25 3,50 3,75 4,00 4,25 4,50 

bx_mult (=bx_add+1) 

Wiedemann 99 Car Following Model 

Scenario 74, 0% HGV 

Scenario 74, 5% HGV 

CC1 is the parameter which has a major influence on the safety distance and 

thus affects the saturation flow rate. Apart from that the saturation flow rate is 

also dependent on many other parameters, such as vehicle speed, truck 

percentage, no. of lanes etc. 

All the following scenarios are based on Wiedemann 99 car following model 

with default parameters, except for the parameter CC1 which is shown on 

the x-axis in the graphs below (one time step per simulation second). 

The main properties of each scenario shown in the following graphs are: 

Scenario Right-side rule Lanes Speed cars* Speed HGV* % HGV 

99-1 no 2 80 n.a. 0% 

99-2 no 2 80 85 15% 

99-3 yes 2 80 n.a. 0% 

99-4 yes 2 80 85 15% 

99-5 yes 2** 120 n.a. 0% 

99-6 yes 2 120 85 15% 



Scenario Right-side rule Lanes Speed cars* Speed HGV* % HGV 

99-7 yes 3*** 120 n.a. 0% 

99-8 yes 3 120 85 15% 

* as defined in the VISSIM defaults 

** lane 2 closed to all HGV 

*** lane 3 closed to all HGV 

The results shown in the graphs below provide the resulting saturation 

flows for some specific VISSIM examples only. The results will be different 

for networks that do not conform with the properties of these examples. 


2400 

2200 

2000 

1800 

1600 

1400 

1200 


0,5 0,6 0,7 0,8 0,9 1,0 1,1 1,2 1,3 1,4 1,5 

CC1 

Scenario 99-1 

Scenario 99-3 

Scenario 99-5 

Scenario 99-7 




2400 

2200 

2000 

1800 

1600 

1400 


1200 

0,5 0,6 0,7 0,8 0,9 1,0 1,1 1,2 1,3 1,4 1,5 

CC1 

Scenario 99-2 

Scenario 99-4 

Scenario 99-6 

Scenario 99-8 


5.5 Links: Behavior Type and Display Type 

Links: Behavior Type and Display Type 

Before VISSIM 5.0, each link had a link type which defined both the driving 

behavior of vehicles on that link and the graphical display of that link. 

Connectors used the link type of their origin link. 

Since version 5.0, each link and connector has a behavior type and a display 

type, allowing independent handling of these attributes. It is still possible to 

change the behavior or display of a group of links at once if all these have 

the same behavior type respectively display type. 

For links, the following options are provided: 

► Use the link behavior type to allocate a specific driving behavior 

parameter set to a selected vehicle class. 

► Use the link display type to assign specific display parameters. 

If an old network file is read (from VISSIM versions before 5.0), VISSIM 

automatically executes the following steps: 

► Link types are split into link behavior types and link display types and 

assigned to the respective links. 

► Connectors get the same link behavior type and display type as their 

origin links. 

5.5.1 Link Behavior Type by Vehicle Class for Links 

VISSIM provides several predefined link behavior types which can be edited 

via BASE DATA - LINK BEHAVIOR TYPES... 

The list of predefined types and the list of driving behavior parameter sets 

assigned to vehicle classes can be edited via NEW or DELETE in the context 

menu. 

When working with a link network, MULTI-SELECT IN NETWORK in the context 

menu serves as a link filter for further changes to the properties of all links of 

the selected type: VISSIM automatically switches into the multi-selection edit 

mode when OK is confirmed, cf. section 6.1. 

The properties of the selected link behavior type can be edited: 



● No.: Unique identification of the link behavior type. 

● Name: Label of the link behavior type. 

● Allocation Vehicle class: Driving Behavior: Assignment of a driving behavior 

parameter set to a vehicle class. To the various classes, different 

driving behavior parameter sets can be assigned. One parameter set 

needs to be assigned to the virtual class “default” which is used for all 

vehicles whose vehicle types do not belong to any of the mentioned 

vehicle classes. 

Driving behavior parameter sets are defined in BASE DATA – DRIVING 

BEHAVIOR... (cf. section 5.4). 

Certain small VISSIM licenses (e.g. U.S. level 1) are restricted to the 

maximum of two link behavior types per network file. 

For pedestrian simulations, you can define WALK BEHAVIOR PARAMETER SETS 

and assign them to AREA BEHAVIOR TYPES by pedestrian class in the BASE 

DATA menu accordingly. 

5.5.2 Display Type by Link/Connector or Construction Element 

Display types can be defined via BASE DATA – DISPLAY TYPES… for links and 

connectors as well as for areas, ramps and obstacles (Pedestrians add-on, 

cf. section 7.3.1). 

In the Display Options window, decide whether to use the display type colors 

for screen display, cf. section 4.1.3. 

In the Display Types window, the list of display types can be edited via NEW, 

DELETE and DUPLICATE in the context menu. 

When working with a link network, MULTI-SELECT IN NETWORK in the context 

menu serves as a link filter for further changes to the properties of all links of 

the selected display type: VISSIM automatically switches into the multiselection 

edit mode when MULTI-SELECT IN NETWORK is confirmed, cf. section 

6.1. 



For 2D view, the general properties of the selected display type are 

displayed on top of the tabs and can be edited: 

● No.: Unique identification of the display type. 

● Name: Label of the display type. 

● Color: Used for the display in the network (except during a simulation or 

animation run in 2D) if option Use display type colors is checked under 

VIEW – OPTIONS – [COLORS]. 

● Invisible: If this option is active none of the links or construction 

elements of this display type will be drawn during a simulation or 

animation run (but the vehicles/persons moving on these links/elements 

will be displayed). 

[3D DISPLAY] The properties for 3D display are arranged in this tab: 

● Texture: Graphics file to be used for link display in 3D mode. The cross 

means „no texture“, otherwise a preview of the texture is displayed. The 

graphics file can be selected through the texture manager (cf. section 

4.1.4.1) which is opened by a click on the preview pane. 

● Curved: If this option is selected the texture is oriented along the 

center line of the link, following its curvature (which is useful for 

text/numbers/markings on the pavement). If the option is not selected 

the textures for all links and connectors of this display type are oriented 

the same way so that no edges are visible where they overlap. 

● No Mipmapping: If this option is selected the texture is drawn with 

maximum resolution even in greater distance from the viewer, which is 

good for markings on the pavement. If this option is not selected the 

texture is drawn blurred in the distance which looks better for pavement 

without markings. 



CON- 

FIGURATION 

Links with a thickness > zero have two additional options: 

● Shaded walls: activates shading for the side walls of the link; 

● All sides same color/texture as top side: causes the side walls to be 

drawn with the same color and texture as the top side. 

Currently the drawing sequence of links cannot be changed by the user. 

● Railroad tracks: If this option is selected, railroad tracks are displayed 

on the link in 3D mode which can be configured via CONFIGURATION. 


[PEDESTRIANS] 


Optionally, you can select a different LOS scheme for the selected display 

type. Settings in this tab will overrule the global settings for area-based 

display of aggregated values via menu VIEW – OPTIONS – [PEDESTRIANS]. Type 

settings can be overruled by the current settings for a particular area or 

ramp or stairway. For more details, please refer to section 7.3.3. 



5.6 Managed Lane Facilities & Toll Pricing Models 

Prior to defining routing decisions of the Managed lanes type (cf. section 

6.4.4) in the network and using them during simulation, please define the 

following in the TRAFFIC menu: 

► MANAGED LANE FACILITIES 

► TOLL PRICING CALCULATION MODELS 

5.6.1 Managed Lane Facilities 

In VISSIM, a managed lane facility does not have co-ordinates, but combines 

a toll pricing calculation model and a decision model. 

Via menu TRAFFIC - MANAGED LANE FACILITIES the Managed Lanes Facilities 

window appears. 

Right-click to call the context menu in the list of facilities: 

Click NEW to create a new managed lane facility. 

After selection of a managed lane facility you may click DUPLICATE or DELETE. 

Alternatively, you can edit the Number or Name property of a selected 

managed lane facility in the Details section of the window. 


Managed Lane Facilities & Toll Pricing Models 

DUPLICATE creates a new managed lane facility with the properties of the 

selected managed lane facility, but a new number = 1 + maximum managed 

lane facility No. in current network. 

DELETE removes the selected managed lane facility from the current network. 

If this facility had still been allocated to a routing decision, then the routing 

decision remains incomplete: It will not take effect during simulation, though 

it has not been deleted from the network. 

5.6.1.1 The Pricing Model 

The pricing model defines when the managed lane facility will calculate the 

road toll and also the way it will be calculated. 

User classes and Pricing update interval(s) 

The following occupancy rates have been predefined: 

1 person (SOV) driver 

2 persons (HOV2) driver and co-driver 

3 or more persons (HOV3+) 3 or more people in the vehicle 

During the simulation, the user class of a vehicle is derived from the 

occupancy rate defined by vehicle type. 

Since the vehicle occupancy rate is an integer value, it is calculated as 

outlined below, for example: 



► If the predefined occupancy rate is 1 for vehicle type A, then all vehicles 

of type A are assumed to have only the driver sitting in them. 

► If the predefined occupancy rate is 1.4 for vehicle type B, then 60% of 

the vehicles of type B are assumed to have only the driver sitting in them 

and 40% are assumed to have driver and co-driver sitting in them. 

The Pricing update interval defines, how often the travel times (i.e. travel 

time savings and average speed values) and the particular road toll are recalculated. 

Travel times and road toll are valid throughout the current Pricing 

update interval and will be re-calculated when a new Pricing update interval 

starts. 

Optionally user-defined moments of time can be regarded additionally for toll 

pricing re-calulation: After re-calculation at a user-defined time the general 

Pricing update interval will be regarded again for the next re-calculation. For 

Time interval definition please refer to section 6.4.3.1. 

Road toll per occupancy rate and time interval 

Road toll is defined by time interval. You may apply it in two ways: 

► Road toll is a constant value (fixed price) 

► Road toll is derived from a user-defined calculation model: 

Click to call the selection list and make your choice. There are two 

options: 

- Select one of the pricing models from the list predefined via menu 

TRAFFIC - TOLL PRICING CALCULATION MODELS 

- Select to call the Toll Pricing Calculation Models window 

directly. 

For fixed price = 0.0 no road toll is charged. 

Also a user-defined calculation model may result in road toll = 0.0. 

Road toll = 0.0 does not automatically mean that all vehicles would take the 

managed lane (cf. section 5.6.1.2). 

Road toll is calculated according to the selected calculation model at each 

managed lane facility for each of the three user classes and remains valid 

until the next pricing update. In the network, the managed lane facilities´ 

moments of time when a pricing update has to be calculated can differ. 


5.6.1.2 The Decision Model 


The decision model calculates the number of vehicles actually using the 

managed lane. For probability calculation, a Logit model is applied using the 

following equation: 

α * U 

e 

Managed 

1 

P( 

Managed ) = 1 − 

= 1 − 

α * U 

U 

e 

U 

e 

Managed α * 

e 

Unmanaged + 

* Δ 

+ 

1 

α 

Here, the utility difference results from the travel time difference (TT savings 

= unmanaged TT - managed TT in [min]) and from the cost difference 

(charges) between managed route and unmanaged route: 

Δ Utility = CostCoefficient 

* ΔCost 

+ TimeCoefficient 

* ΔTime 

Enter the following parameters: 

● Logit-Alpha (Default = 0.05) 

● Utility-Coefficient Cost (optionally by vehicle class) 

● Utility-Coefficient Time [min] (optionally by vehicle class) 

For vehicles of a type that does not belong to any of the given classes the 

default coefficients are used. 

For vehicles of a type that belongs to several of the given classes the 

values specified for the vehicle class with the lowest number the vehicle 

type belongs to will be used. 



Travel time on the managed route exceeding the travel time on the 

unmanaged route would cause negative time savings. In this case, travel 

time saving = 0 is used. 

5.6.2 Toll Pricing Calculation Models 

Via menu TRAFFIC - TOLL PRICING CALCULATION MODELS the Toll Pricing 

Calculation Models window appears. 

Call the context menu via right-click in the list of models: 

Click NEW to create a new toll pricing calculation model. After selection of a 

toll pricing calculation model you may click DUPLICATE or DELETE. 

Edit the Number or Name property of a selected toll pricing calculation model 

in the Details section of the window. 

DUPLICATE creates a new toll pricing calculation model with the properties of 

the selected toll pricing calculation model, but a new number = 1 + maximum 

toll pricing calculation model No. in current network. 

DELETE removes the selected toll pricing calculation model from the current 

network. If a toll pricing calculation model is removed though it is still used by 

a managed lane facility then the managed lane facility will use road toll = 0.0 

instead. 

Traffic Responsive Toll Pricing 

For toll price calculation, the following values are used: 

► Travel time savings in [min] and 

► Average speed on the managed lane in [km/h or mi/h] which was 

determined for those routing decisions using the managed lane facility. 



COM scripts can also address Toll Pricing Calculation Models. 

Instead of a COM script, users may also create and use a *.DLL file for 

pricing calculation. The required header data file (C++) is to be found in the 

following sub-directory: API\TOLLPRICING_DLL\. 


6 The Traffic Network 

In this chapter, modeling a VISSIM network - creating and editing network 

elements - is described. 



6.1 Overview 

Example 

The basic element of a VISSIM traffic network is a link representing a single 

(or multiple) lane roadway segment with a specific direction of flow. A 

network can be built by connecting links via connectors. Only connected links 

allow for continuing traffic. Links that simply overlap (without a connector) 

have no interaction with each other. 

Network elements can be defined at any location within the traffic network. 

They can be edited or deleted. 

In the simple network example below, the junction is a signal-controlled 

intersection with signal heads and detectors . Additionally some 

movements are secured by priority rules (the colors of the network 

elements depend on user-defined settings). 

Normal display: 

The roadwork is displayed in dark 

gray showing an intersection with 

3 legs and 2 pedestrian crossings. 

Center line display: 

The same roadwork is displayed 

as the center lines of the links 

(blue) and connectors (purple). 

Selection of network elements 

For creating, editing or deleting a network object, the button of the respective 

network object type has to be active in the symbol bar. 

By default, network objects are selected as follows: 

Single-select mode 

► By default, a network object is selected by left-clicking directly on the 

network object in the VISSIM network display on screen. Double-click 

calls the respective Edit attributes window. 

► Alternatively, a selection list showing all network objects currently defined 

in the VISSIM network for the respective netwok object type can be 

called via 

- EDIT - SELECTION LIST or 

- right-click outside of the network. 

Further steps: 

- Select network object in the list and click DATA or DELETE. 


Overview 

- Instead of clicking DATA, the Edit attributes window can be called 

immediately by double-clicking the selected network object. 

- It might be helpful to click ZOOM additionally for visualization of the 

selected network object within the VISSIM network. 

Multi-select mode 

For definition of active nodes or links/connectors, a polygon has to drawn in 

the network display on screen, cf. section 3.3.2. 

Active network obejcts 

► can be 

- deleted or 

- moved; 

► have to be defined for two options provided under EVALUATION - FILES: 

- Link evaluation and 

- Nodes. 

For Link evaluation, relevant attributes of active links/connectors can be 

edited. 

Further selection options which might be provided for a network element 

are described in the respective section of this chapter. 

Users of the Pedestrians add-on should refer to section 7.1.4, since the 

selection of a construction area, for example, differs from the regular 

procedure. 

The VISSIM network consists of 

► static data remaining unchanged during the simulation and 

► dynamic data containing all information about the simulated traffic. 

Static data 

Static data represents the roadway infrastructure. This data is required for 

both simulation and testing of a traffic actuated signal control logic. Static 

data includes: 

► Links with start and end points as well as optional intermediate points; 

links are directional roadway segments with a specified number of lanes 

► Connectors between links, e.g. to model turnings, lane drops and lane 

gains 

► Location and length of PT stops 

► Position of signal heads/stop lines including a reference to the 

associated signal group 

► Position and length of detectors 

► Location of PT call points 



Dynamic data 

Dynamic data is only to be specified for traffic simulation applications (not for 

applications using only the test functionality). It includes the following 

information: 

► Traffic volumes including vehicle mix (e.g. truck percentage) for all links 

entering the network 

► Location of routing decision points with routes (link sequences to be 

followed), differentiated by time and vehicle classification 

► Priority rules (right-of-way) to model unsignalized intersections, 

permissive turns at signalized junctions and yellow boxes (keep-clearareas). 

► Location of stop signs 

► Public transport routing, departure times and dwell times 

Measures of Effectiveness (MOE) 

For measures of effectiveness the following elements (among others) can be 

coded: 

► Data collection points (local measurements, user-definable, e.g. traffic 

volume, acceleration and speed discriminated by vehicle class), 

► Travel time measurement sections and delay data collection, 

► Queue counters for queue length statistics. 

Users of the Pedestrians add-on should refer to section 7.2, since similar 

evaluations are provided for pedestrian flows. 


6.2 Data Import/Export 

Data Import/Export 

VISSIM allows for data exchange between VISSIM and other software 

programs. 

6.2.1 Data Import 

For a productive workflow it is possible to import part or all of VISSIM 

network data from other applications. 

6.2.1.1 Read Network Additionally 

VISSIM can read any other VISSIM network in addition to the current 

network. Any numbering conflicts of network elements or other data blocks 

are resolved. Furthermore the user can select to read certain network 

elements only. 

To read a VISSIM network file additionally: 

1. Click FILE - READ ADDITIONALLY... 

This functionality is only available if a newly created network was already 

saved to file. 

2. Select the filename of the *.INP file to be read additionally. 

3. Set the options: 

- Select the Insert Position option 

- Choose the Network Elements 


Use the default settings to read the entire network additionally. 

Use option Select position with left mouse button to fix the final position for 

the network which is read additionally. 



● Insert Position 

- Select position with left mouse button: Inserts the additional network 

as floating selection which can be moved with the mouse pointer 

prior to its definite placement. Left click defloats the additional 

network. 

- Keep original world coordinates: The additional network is placed 

exactly at the same location (“world coordinates”) as in the original 

file. This method is recommended e.g. to combine several partial 

networks that were created based on a global coordinate system. 

In both cases, the additionally read network portion remains multiselected. 



● Network Elements 

Each network element type can be activated or deactivated for the import. 

However, if a network element type is selected, all network element 

types that it refers to are automatically selected as well. If a network 

element type is deselected, all network element types referring to it are 

deselected automatically. 

For each network element type of the imported network the numbering 

scheme can be specified: 

- New Numbers: Each element will get a new number that is higher 

than the highest previously existing number of such a network 

element (in both networks), by adding a sufficiently high round 

number to the old number of the imported network element. (If this 

procedure would cause numbers higher than 2 147 483 648, the read 

process is canceled with an error message.) 

If New Numbers is not checked, each imported network element 

keeps its number if this one does not yet exist in the old network, in 

which case it is changed as above. 

- Keep Duplicates: For each network element without a geometrical 

position (e.g. distributions) the user can select if exact duplicates of 

existing network elements are to be kept (with new numbers) or not. 

Example: If the vehicle types 1..6 are defined identically in both 

networks then Keep duplicates changes the numbers of the vehicle 

types of the imported network to 11..16 (usually this is not desirable). 

If Keep Duplicates is not checked, the corresponding network 

elements of both the existing and the imported files are compared by 

all their properties except for numbers. If two network elements are 

identical (no matter what number they have) then all references from 

the imported network are changed to that network element of the 

existing file. 

6.2.1.2 SYNCHRO 7 Import (add-on module) 

VISSIM supports the import of entire networks, including signals and signal 

timing, from the software package SYNCHRO, version 7, if this module is 

part of your VISSIM license. The SYNCHRO network must be saved as a 

*.CSV combined data file prior to data import in VISSIM. 

This functionality does not facilitate the import of data generated with an 

elder SYNCHRO version. 

VISSIM will import all elements from the SYNCHRO 7 file, including network 

geometry, volumes, turning movements, vehicle compositions, intersection 

control, and signal timing. All signal timing will be imported to individual Ring 

Barrier Control (RBC) files for VISSIM. 

To use this feature, click menu FILE – IMPORT… - SYNCHRO 7. 

The SYNCHRO 7 Import window opens. 



Choose the specific SYNCHRO 7 file for input and choose the path for the 

created VISSIM files (which will include the *.INP file and the *.RBC files). 

The name of the *.CSV file selected for import will be used as *.PANM und 

*.INP file names. 

Similar to the ANM Import, a network generated via SYNCHRO7 import can 

be modified later and the modified data can be read adaptively then. 

Example workflow 

► Create the VISSIM network via menu FILE – IMPORT… - SYNCHRO7. 

► Refine the VISSIM network, e.g. adjust VISSIM link polygons, add travel 

time sections etc. 

► Run the simulation. 

► As a result, you might notice that the signal control data needs to be 

adjusted or changed in SYNCHRO 7. 

► Start SYNCHRO 7, make the desired changes to the SYNCHRO 

signalization data and save the new SYNCHRO data. 

► In VISSIM, start menu FILE – IMPORT… - SYNCHRO 7 ADAPTIVELY and 

import the new, updated SYNCHRO data. 

► VISSIM compares the originally imported (ANM) data with the new 

(ANM) data: if only signalization data differs, then only signalization data 

is re-created in VISSIM. 

► In this case, all manually changed VISSIM links/connecters remain 

unchanged, the travel time sections are retained etc. 

The adaptive import is only possible if the current network was originally 

created by SYNCHRO 7 Import. This button is disabled if no current network 

exists or if the current network was not created by SYNCHRO 7 Import. 

This is similar to the ANM Adaptive Import, as described in section 6.2.1.5. 

It should be noted that networks created through this process may not 

match an existing background map or aerial photo in the same way as a 

network built in VISSIM. The network will be as accurate as the input data 

provided and may require a minimum of adjustment. 

6.2.1.3 Adaptive SYNCHRO7 Import 

Menu FILE - IMPORT – SYNCHRO 7 ADAPTIVE starts another import run 

additionally to the initial import. 



The adaptive SYNCHRO 7Import should be called only for a VISSIM network 

that was originally created by means of an initial SYNCHRO 7 Import and 

has been modified in SYNCHRO 7 in-between, cf. section 6.2.1.2. 

6.2.1.4 ANM Import 

*.ANM files contain an abstract network model in XML format. They can be 

exported since VISUM 10 or could be created by other traffic planning or 

engineering software as well. 

ANM Import can be performed in two ways: 

► Complete import (initial: creating a new VISSIM network) 

► Adaptive import (only differences in the new *.ANM file compared with 

the *.ANM file imported earlier) in order to update only the affected data 

in the VISSIM network, cf. section 6.2.1.5. 

The abstract network model is based on nodes and edges with optional node 

details (lanes, lane turns, pockets, pedestrian crosswalks, control type, 

signalization, detectors). 

The geometry of the VISSIM links and connectors is created in VISSIM. 

Volumes and routing data which are stored in *.ANMROUTES files can be 

imported in VISSIM for further use in Dynamic Assignment or as static 

routes. 

► For dynamic assignment: 

- Matrix file(s) and path file and cost file are created. 

- The names of the generated *.FMA matrix files include demand totals 

and relevant time interval as well as the name of the input file to 

avoid overwriting any matrix files from previous exports by mistake. 



Route volumes in a path file resulting from ANM Import do not necessarily 

be integers, since the assignment result may have floating point values in 

VISUM. 

During the export, the DTA route volumes are stored as volumes per ANM 

time interval in the path file. During the import, the volume values are 

converted into volume data per evaluation interval of the Dynamic 

assignment. 

For Dynamic Assignment, these values are rounded by random in VISSIM 

(according to the share to be rounded). Example: 0.3 is rounded up to 1 

with 30% probability and down to 0 with 70% probability. Random rounding 

causes the total of the values in the matrix to remain approximately 

constant. 

► For static routing : 

- Inputs and routing decisions with static routes are created. 

- Each routing decision for static routes is assigned a name containing 

the ANM origin zone number. 

- The IDs of the ANM routes serve as route numbers of static routing 

decisions. This way, any route can be found in the ANMROUTES file 

and the respective OD pair can be determined. 

Since VISSIM 5.00-05 also data files exported by SITRAFFIC OFFICE can 

be imported. 

During ANM Import, warnings and messages are displayed in the protocol 

window, cf. section 10.2.1. 

Starting the (initial) ANM Import 

Call FILE – IMPORT… - ANM to open the ANM Import window. 



Specify the paths for input files and output files. 

● Import network data: If this option is active, path and file name of the 

ANM file to be imported as abstract network model have to be entered. 

Import network data: If this option is not active, you may - by activating 

only option Import routing - force repeated import of just the routing 

data you had imported with the abstract network model initially. 

● Import routing: If this option is active, do the following: 

- Chose whether routing data has to be imported as Static Routing or 

for further use in Dynamic Assignment. 

- For Dynamic Assignment: Enter the evaluation interval, if applicable. 

Import routing: If this option is not active, only the abstract network 

model will be imported. 

ANM Import creates a network file which includes the *.ANM file data. By 

this, your currently loaded network could be overwritten or deleted. 

If the option Static Routing is selected with the initial import of the network 

data, no parking lots (zone connectors) will be created. 

Thus, the adaptive routing import for dynamic assignment is not possible 

subsequently. 

For future adaptive ANM Import a name for the output file *.INP is required. 

The files *.PANM and *.PANMROUTES are automatically copied to the 

folder which has been specified for the *.INP file. 



● Show warnings during import: If this option is active, you have to 

confirm every warning on screen. Simultaneously, all messages and 

warnings are traced to a Log file and can be listed on screen after the 

import. 

If this option is not active, no messages will be displayed during import, 

but the Log file will be created and the list of messages can be opened 

on screen as well subsequently. 

● CLOSE closes the window and saves current settings. 

● IMPORT starts the import procedure. 

● CANCEL closes the window and ignores modified settings. 

Instead of ANM Import you may also select the *.ANM file in the Explorer 

and open it in the VISSIM window via Dragń´Drop. 

► If no *.INP network file has been loaded, this *.ANM file is imported. 

► If an *.INP network file has been loaded which initially was imported via 

ANM Import, you may pick to read this file adaptively or initially now. 

How the VISSIM Network is built 

The ANM Import creates the following VISSIM network elements from 

exported VISUM network objects: 

VISUM VISSIM 

Transport system Vehicle type and vehicle class 

Node Node (as segment node, 

cf. section 12.3.2) 

Link Links (one per segment; e.g. the start of a pocket 

creates a new link with one additional lane); multilane 

links according to lane geometry, if applicable. 

You can create multiple connectors connecting the 

same two links and also connectors from or towards 

the same lane (those can be exported since VISUM 

11.0). 

The emergency stop distance for connectors 

representing turning movements in nodes is set to 

the pocket length minus 10 m. 

The front time gap for a conflict of a left-turn and a 

parallel crosswalk is set to 2.0 seconds. (This way, 

opposite right-turns with a front time gap = 0.5 s 

may start prior to the left-turns as soon as their 

conflict area has been cleared normally.) 

Lane Lanes (with lane-specific permission or closure by 

vehicle type) 

Turn Connector, with reduced speed area in case of 

sufficient curvature. 



Blocked Turn for 

TSys 


Right-turn on red movements are created with stop 

sign, signal head and conflict area. 

Multiple lane turns from a lane to several lanes on 

the same link are permitted. 

Connector closures 

Note: 

In VISSIM, the lane closure for a specific Public 

Transport TSys is applied only if in VISUM a vehicle 

combination has been defined with this TSys 

assigned. 

Zone and Connector ► Parking lots (for dynamic assignment) or 

► vehicle input and static routing decision (for 

static routing). 

For VISSIM zone connectors cf. below 

Link attribute Type 

On connectors from/to VISSIM links, that represent 

zone connectors in the ANM file exported from 

VISUM, conflict areas are created, so that the 

vehicles entering/leaving the network via these links 

do not interfere with “normal” traffic. 

VISSIM links and connectors representing zone 

connectors in the ANM file from VISUM are created 

with option „Visualization“ unchecked by default. 

Thus vehicles driving on them are invisible. 

A Link behavior type is created accordingly 

(No./Name) and one of the automatically created 

Link display types is allocated: 

► ANM Default 

► Pedestrian Crosswalk (1 m before stop line) 

► Zone Connector (additional link) 

For connectors between links, link behavior type 

and link display type of the FromLink are allocated. 

Link attribute v0-PrT Desired speed distribution assigned to a desired 

speed decision 

Stop points PT Stops whose length and type (Street/Lay-by) 

result from the parameters that had been set in 

VISUM for ANM Export of public transport stop 

points. 

Public transport 

vehicle journeys (in 

the exported time 

period) 

Bus/Tram Lines 




Signal controller and 

signal groups 

Signal group 

assignment to lanes 

in the junction editor 

SCJ and signal groups 

Signal group assignment to signal heads on lanes 

Time interval Evaluation period for dynamic assignment 

From the node 

control type 

For NEMA signal 

controlled nodes 

Signal heads, stop signs, conflict areas 

Detectors 

VISUM zone connectors 

► It is recommended to have VISUM zone connectors only from/to nodes 

that have only one (feeder) link to/from an adjacent node, and from that 

node only to/from a single zone. In this case the parking lots (or vehicle 

inputs and routing decisions) for these zone connectors can be placed on 

the existing feeder link. 

► If the zone connector is connected to a node with more than one link or if 

more than one zone are connected to the same node each connector 

must be modeled by an additional link in the VISSIM network which is 

connected to the node’s links without any regard for the node geometry. 

Reduced speed areas on VISSIM connectors 

Reduced speed areas on VISSIM connectors are generated automatically if 

the curvature of the turn exceeds a theshold. Therefore, the coordinates of 

the adjacent links are regarded and the angle between points as well. 

Normally, the automatically created reduced speed area is placed in the 

middle of the connector and has a length of 2 m. Thus the starting position 

x = connector length : 2 - 1m. In case of connector length < 2 m, the reduced 

speed area covers the entire connector. 

Speed is assigned as follows automatically: 

► Inner turns (left-turns in case of right-hand traffic): 25 km/h 

► Outer turns (right-turns in case of right-hand traffic): 15 km/h 

The value range of the automatically generated desired speed distributions is 

{-10%...10%}. 

Since VISSIM 5.00-07, deceleration depends on the vehicle class. If the 

vehicle class includes a vehicle type of category HGV or Bus or Train, 

deceleration is set to 1.3ms 2 , otherwise deceleration is set to 2.0ms 2 (as 

before). 


6.2.1.5 Adaptive ANM Import 


The adaptive ANM Import should be called only for a VISSIM network that 

has been originally created by means of an initial ANM Import. 

In contrast to the initial ANM Import, the Adaptive ANM Import works as 

follows: 

The initial ANM data which was saved by VISSIM during the initial ANM 

import is kept independently of manual refinements in the VISSIM network. 

During an adaptive ANM Import VISSIM compares the new ANM data with 

the saved initial ANM data and uses only the differences between the two 

data sets to adapt the VISSIM network accordingly. If a node has been 

changed in the ANM file only this node and the connected edges are created 

from scratch by the adaptive import, thus only manual geometry 

improvements in this (small) part of the network will get lost. All manual 

modifications of the VISSIM network in nodes (and edges) that are not 

affected by the changes in the ANM file remain intact, however, as do 

VISSIM network objects that have been added only in the VISSIM network 

editor. 

Adaptive ANM Import allows for: 

► Exporting changes to the original VISUM network into a previously 

exported VISSIM network which has been refined manually in the 

meantime without losing much of the work in the VISSIM network editor. 

► Loading a different demand scenario (matrix and assignment result) from 

VISUM - in this case the VISSIM network remains completely unchanged 

(unless a necessary parking lot or route need to be added). 

Routing data is imported adaptively only if the routes to be imported have 

been changed, i.e. if the *.ANMROUTES file has been changed. 

If the routes have been changed manually in VISSIM and the original 

*.ANMROUTES files shall be imported again, initial ANM import has to 

be used: Select only routing for import. Then, the network will remain 

unchanged. 

Starting the adaptive import also runs an additional check of the VISSIM 

nodes. If a VISSIM node matches with an ANM zone it will be checked 

whether the current edge structure complies with the internal ANM 

attributes (IDs of the ANM zone connector) of the node. 

The node geometry cannot be restored if only node name or/and the link 

name and/or the link behavior type have changed. 

In case of changes to name or type, the reconstruction of the node 

geometry is forced on purpose in case of two parallel links between two 

nodes. 

Starting the Adaptive ANM Import 

Call FILE – IMPORT… - ANM ADAPTIVE to open the ANM Import Adaptive 

window. 



Adaptive ANM Import uses all of the parameters provided for initial ANM 

Import (cf. section 6.2.1.4) and additionally two more options: 

● Delete omitted objects: During further network processing in VISUM 

network objects could have been removed from the initial VISUM 

network after VISUM export to *.ANM file and ANM Import in VISSIM. 

Thus, a new *.ANM file provided for Adaptive Import in VISSIM might 

contain only part of the network objects which originally had been 

imported into VISSIM. This way, missing objects could occur during 

Adaptive Import of an abstract network model. 

If this option is active, these objects missing in the new *.ANM file are 

also removed from the VISSIM network and so are VISSIM network 

elements which were automatically generated from these objects. 

If this option is not checked, this portion of the VISSIM network will 

remain unchanged. 

● Complete routes after Import: If this option is active, VISSIM will 

automatically complete existing routes in the VISSIM network which were 

corrupted by adaptive ANM Import. 

The filename you enter for the *.INP file will also be used for the *.PANM 

file and the *.PANMROUTES file. 

6.2.1.6 Hermes XML Import 

Via menu FILE – IMPORT – HERMES XML, you can start the import of network 

data in XML format. The data is converted into ANI data format and will be 

stored as *.ANI data file with the given filename in the same folder. 


6.2.2 Data Export 


Via menu FILE – EXPORT you can export VISSIM data in various data formats. 

Data export to VISUM 

Menu FILE - EXPORT - VISUM provides two options to export the VISSIM 

network in VISUM network file *.NET format, cf. section 6.2.2.1 and section 

6.2.2.2. 

Furthermore, VISSIM network data can be saved as VISUM *.NET file 

additionaly to the *.STR output file during a simulation run, if option Link 

evaluation is active under EVALUATION - FILES, cf. section 6.2.2.3. 

Any export file is saved to the folder where the currently used *.INP file is 

stored. Directory changes are not permitted. 

VISSIM data exported in VISUM network file format do not code a complete 

VISUM network. In VISUM, VISSIM data in VISUM data format may 

be used for visualization only, this network file cannot be used for assignments. 

The “Export to VISSIM” functionality provided in VISUM cannot be applied 

to exported VISSIM networks. The VISSIM network originally exported from 

VISSIM to VISUM cannot be restored in VISSIM in this way. 

Data export to 3DS MAX 

Via menu FILE – EXPORT – 3DS MAX you can export VISSIM data to 3DS 

MAX, cf. section 6.2.2.4. 

6.2.2.1 FILE - EXPORT - VISUM - NODES/EDGES... 

This option is provided only for networks after Dynamic Assignment. 

You can export your VISSIM network and your VISSIM demand for import in 

VISUM to start an assignment in VISUM, cf. section 12.9. This section 

describes a static VISUM assignment, which can serve as initial solution for 

the Dynamic Assignment. After Dynamic assignment in VISSIM, you can 

export the calculated VISSIM paths for import in VISUM for subsequent 

graphical display and analysis of the paths and their volumes in VISUM. 

1. Export for subsequent assignment in VISUM 

VISSIM exports the network and the demand for import in VISUM. 

Therefore, VISSIM creates a VISUM version file *.VER. Additionally, a 

VISUM network file *.NET and a VISUM matrix file *.MTX are created. 

The version file includes this data already. 

2. Export of routes for visualization in VISUM 

VISSIM exports the network and the paths for import in VISUM. 

Therefore, VISSIM creates a VISUM version file *.VER. Additionally, a 



VISUM network file *.NET and multiple VISUM route files *.RIM are 

created. The version file includes this data already. 

Export for subsequent assignment in VISUM 

Follow the steps outlined below: 

1. Open the VISSIM network you would like to export. 

2. Via menu FILE - EXPORT - VISUM – NODES/EDGES…, open the VISUM- 

Export window. 

3. Check option For assignment in VISUM (without VISSIM paths). 

4. Use the button to select the folder and the filename for the VISUM 

version file *.VER. 

5. Click OK to start the data export. 

Just for the VISUM version file *.VER you can enter folder and filename. 

Additionally to the *.VER file, the export creates a VISUM network file 

*.NET and a VISUM matrix file *.MTX with identical filenames. All files will 

be saved to the folder specified for the VISUM version file. 

If the VISSIM network includes edges, that cannot be exported to VISUM, 

then these edges will be listed in the protocol window. Nevertheless you 

can execute the export, alternatively you may cancel. VISSIM provides 

support for the fixing of damaged nodes and edges, cf. section 12.3.4. 

VISSIM feature: Ambigious zone connectors 


A warning will appear if the 

VISSIM network includes nodes 

with ambiguous zone connectors 

(parking lot zones). 

VISSIM handling: 

Create another node to create 

unambiguous zone connectors. 


Export of routes for visualization in VISUM 


1. Open the VISSIM network you would like to export. 

2. Via menu FILE - EXPORT - VISUM – NODES/EDGES…, open the VISUM- 

Export window. 

3. Check option For visualization in VISUM (with VISSIM paths). 

4. Use the button to select the folder and the filename for the VISUM 

version file *.VER. 



5. Click OK to start the data export. 

For the VISUM version file *.VER you can enter folder and filename. 

Additionally to the *.VER file, the export routine will create a VISUM 

network file *.NET and multiple VISUM route files *.RIM. 

From the total demand in VISSIM matrices, a VISUM matrix file *.MTX is 

generated for export. Only the demand in the export time interval 

(simulation start time + simulation period as defined by the user in the 

Simulation parameters window) is regarded for export. If a VISSIM matrix 

file is not completely in the export time interval, then only the portion in the 

export time interval will be exported. Please note: The demand is summed 

up, thus you will not receive separate matrices for different VISSIM vehicle 

types and/or vehicle classes. 

Route import files are only exported if VISSIM cost and path files are 

available. Route import files contain the routes and volumes resulting from 

the Dynamic assignment: For each Dynamic assignment evaluation interval 

a separate *.RIM file is generated. 

If cost and path files do not exist, a warning will appear and only the 

network and matrix data will be exported. 

Closures of edges or connectors are exported to VISUM and can be 

regarded during the assignment. Normally, VISUM does not use paths 

which are not possible in VISSIM. 

The only exception to this rule are disjunctive parallel edges between two 

VISSIM nodes that either originate from different turns or lead to different 

turns. These are exported as a consolidated edge to VISUM. This might 

lead to paths determined in a VISUM assignment which cannot be applied 

in VISSIM. 

For details on Route import in VISUM please refer to chapter “Program 

Interfaces” in the VISUM User Manual. 

Further processing in VISUM 

How to open a version file *.VER in VISUM 

1. Click FILE – OPEN VERSION. 

2. In the Open version file window, select the desired version file *.VER. 

The VISUM version file created during export contains all required data. 

There is no need to open the additionally created VISUM files separately. If 

no version file was created during export, you may open the additionally 

created files instead one by one. 

How to open a network file *.NET in VISUM 

1. Click FILE - OPEN - Networks. 



2. In the Open network file window, select the desired network file *.NET. 

How to import the *.RIM files in VISUM 

Cf. chapter 4 and chapter 13 in the VISUM User Manual: 

1. Call CALCULATE - PROCEDURES - [OPERATIONS] 

2. Click CREATE to call the Operation window. 

3. In the Assignments folder, select the entry Route import. 


A new row is added to the list. 

5. Click SELECTION DSEG and select the demand segment. 


7. Click BROWSE to call the Open Route Import window. 

8. Select the *.RIM file. 

9. Click OPEN. 

10. Click EXECUTE to start the import. 

How to open a matrix file *.MTX in VISUM 

Please refer to chapter 3 in the VISUM User Manual: 

1. Add the matrix to the VISUM network model via VISUM menu EDIT – 

MATRIX EDITOR - ADD EXTERNAL MATRIX TO THE NETWORK MODEL. 

2. Assign the matrix to a demand segment via VISUM menu DEMAND – 

DEMAND DATA – [DEMAND SEGMENTS] – column Matrix. 

Building a VISUM network from a VISSIM network after Dynamic 

assignment 

VISUM network object Notes 

TSys, Mode, DSeg VISUM creates a single Private transport system, a 

single PrT mode and a single demand segment (C 

Car). VISSIM vehicle types and/or classes are not 

exported as various transport systems or modes or 

demand segments. 

The VISSIM route export creates an additional 

VISUM DSeg-PrT for each VISSIM Dynamic 

assignment evaluation interval. 

Nodes Are generated according to VISSIM nodes. VISUM 

node numbers correspond to VISSIM node 

numbers. Please note: The max. permitted node 

number in VISUM is 2147483647. VISSIM nodes 

with a number greater than this are renumbered, 

starting with the smallest free VISSIM node 

number. 




Node details (type, geometry, signalization, 

orientations etc.) are neither exported nor 

generated. 

Links Are generated according to VISSIM edges 

between the nodes. 

Parallel edges: in VISSIM it is possible to have 

several edges from one node to another node. In 

case of several edges between the same two 

nodes, only the shortest edge is exported. 

First, the suitability of the VISSIM network 

structure is checked. In case of unsuitable 

modeling (e.g. parallel edges) a warning appears. 

Details are listed in the Log Window. 

● Number 

● Type 

● Length 

● Number of lanes 

● Capacity PrT 

● v0 PrT 

Starts with 1. 

Has no correlation to the VISSIM link number or 

any other VISSIM network element. 

Is set to 0 for all links. 

Has no correlation to the VISSIM link behavior 

type. 

Is calculated from the corresponding VISSIM edge. 

Is set the to minimum number of lanes of all 

VISSIM links/connectors corresponding to the 

edge. 

NumberVehicles/hour = Number of lanes • 900 

Capacity = NumVeh/h • (SimPeriod/3600) 

SimPeriod = simulation period, cf. Simulation 

parameters 

Corresponds to “vehicles per simulation period”. 

Is calculated from the speed distributions of 

VISSIM origin parking lots and desired speed 

decisions on the edge. 

Speed for one distribution: 85th percentile. 

► For parking lots, only the default speed 

distribution is considered. 

► For speed decisions, the average of all given 

distributions is calculated (85th percentile of 

each distribution). 

Turns Are generated from the VISSIM edges inside the 

nodes. A VISUM turn is open if the corresponding 

VISSIM edge exists. Turn capacity is set to 99999 

for all. U-turns get type 4, other turns get type 0. 

Zones Are generated according to VISSIM zones. The 



Connectors 

(zone – node) 

6.2.2.2 FILE - EXPORT - VISUM - LINKS/CONNECTORS... 


zone position is calculated from the position of the 

parking lot to which the zone has been assigned. 

Are generated according to VISSIM parking lots 

and zones. 

► The exported VISUM network file (*.NET) contains the user-defined 

VISUM link attributes listed below for each exported VISSIM link or 

VISSIM connector. 

The exported network can be read from file in VISUM 8 and higher. 

► In VISUM, various graphical analyses can be performed, for example you 

may use the link filter for the following: 

- Set those links to the active state which show outstanding attribute 

values (e.g. emergency stop positions or cost values). 

- Highlight all links being closed to selected vehicle classes. 

User-defined VISUM attribute Link Connector 

Cost X X 

Surcharge 1 X X 

Surcharge 2 X X 

Emergency stop position X 

Lane change position X 

Closed to vehicle class (0=no, 1=yes) X 

6.2.2.3 EVALUATION – FILE – Link evaluation 

A so-called base network file containing the network objects links and link 

polygons is created and saved as .NET. 

Furthermore, an additional network file containing the evaluation data gained 

by time interval is stored as _.NET for 

each time interval. The data by time interval is coded as user-defined VISUM 

attributes. 

For data export during link evaluation: 

► Define active links in the Multi-select mode and 

► Check option Link evaluation in the Link attributes (Multiselect) window. 

Via menu EVALUATION – FILE the Evaluations (File) window is called. 

Here, the followings settings are required: 

► Check option Link evaluation. 

► Click CONFIGURATION and set parameters: 



● Check option VISUM Export (Network + link attributes), 

● Set intervals (take simulation time interval into consideration) 

For VISUM export, option by lane must be unchecked. Attribute LaneNo. is 

not exported. 

► The Base network file contains VISUM nodes and links with 

- link evaluation attributes with constant values during simulation, and 

- the user-defined link attribute LinkEvaluation {yes/no}. 

► Any Interval network file contains only data coding user-defined link 

attributes and their respective values gained in the particular time interval. 

Generating VISUM network objects from VISSIM network elements: 

► A VISSIM link without segment evaluation is modeled as VISUM link. 

► A VISSIM link with segment evaluation is modeled as a set of VISUM 

links: from each VISSIM link segment a separate VISUM link is 

generated. 

Generated VISUM nodes are numbered in adjacent order, starting from 1. 

In VISUM, follow the steps outlined below: 

► Open the exported base network file first. 

► Then read all further export network files *_.NET 

additionally. Use the option Read network additively. 

The window Read network data additively includes the Conflict 

handling column: Select option Overwrite attributes for network object 

type LINK. 


6.2.2.4 FILE – EXPORT – 3DS MAX 


Enter the file name. 

The exported *.TXT file stores merely the polygon data of links and walkable 

areas which is arranged in two data blocks. 

Either data block may be empty. 

► The coordinates in the first data line are required for the future 

calculation of the poygon point positions. 

► Then, the link data block follows. 

► Finally, the polygon data block is saved to file which contains the 

ramps/stairs and areas for pedestrians. 

For each network element, the data record starts with the “network element 

number” and ends with a g flag, it consists of the list of coordinates per 

network element. 

Example: 

[870.10447,7438.97385,0.0] 

Links 

"10000",[49.36338,-17.03216,0.00000],[49.32021,-17.04763,0.00000],[52.51336,- 

15.69895,0.00000],[52.51911,-15.69774,0.00000],[53.83595,-18.11195,0.00000],[53.75370,- 

18.15874,0.00000],[50.40885,-19.84607,0.00000],[50.27076,-19.89165,0.00000] 

g 

… 

"24",[119.98432,109.21772,0.00000],[120.12069,109.33330,0.00000],[121.04083,110.20962,0.00 

000],[122.80267,108.44778,0.00000],[121.83278,107.50869,0.00000],[121.72320,107.39984,0.00 

000],[121.51023,107.15226,0.00000],[121.30799,106.87590,0.00000],[121.15323,106.63884,0.00 

000],[119.05983,108.00547,0.00000],[119.25107,108.29841,0.00000],[119.55083,108.70804,0.00 

000],[119.89186,109.10447,0.00000],[120.08228,109.29362,0.00000],[119.23839,108.47652,0.00 

000],[120.99823,106.71668,0.00000],[121.79237,107.47300,0.00000],[121.60074,107.31058,0.00 

000] 

EndPedestrianAreas 

For more details on the subsequent import in 3DS MAX please refer to the 

files stored in the sub-folders of the …\API\3DSMAXEXPORT folder of your 




6.3 Network Coding 

The level of detail required for replicating the modeled roadway infrastructure 

depends on the purpose of a VISSIM application. While a rough outline of 

the analyzed intersection is sufficient for testing a traffic actuated signal logic, 

a more detailed model is required for simulation analyses. With VISSIM it is 

possible to model virtually any kind of intersection (or sequence/network of 

intersections) with a precision down to one millimeter! 

In the event of using VISSIM to test traffic actuated controls through interactive, 

manual detector activation, it is recommended to create a rough 

model of the analyzed intersection including all approaches. However, it is 

not necessary to place the stop lines and detector loops at the exact 

positions. 

For the purpose of simulating traffic operations, it is necessary to replicate 

the modeled infrastructure network to scale. This can be done as follows: 

► Import of a scaled network from VISUM, CROSSIG, P2 (or other applications 

that provide VISSIM network files) 

► Import of a scaled network from the signal control optimization software 

package SYNCHRO (additional module, cf. section 6.2 for details) 

► Import of base maps or drawings as a background so that the VISSIM 

network can be traced exactly according to a scaled map (cf. section 4.4 

for details) 

6.3.1 Links 

Network elements can be moved not only within the same link/connector 

but also to any other link/connector. 

Also the start and end of a connector can be moved to a different link. 

Input flows can be placed on another link in the Input flows window only. 

The start of PT routes cannot be moved. 

If you are starting with an empty network in contrast to an imported one, you 

need to ensure that the scaling is right before you start to code the VISSIM 

network. This is done using at least one scaled background graphic. For 

details on how to load, move and scale a background images, please refer to 

section 4.4. 

The first step in coding a VISSIM network is to trace links. Therefore look for 

all of the approaches to an intersection and determine the number of lanes 

both on the approach and within the intersection. Each approach and section 

will be represented by one link. Start with the major roads. 

To generate the opposite direction of a link, option Generate Opposite 

Direction has to be checked. The newly created link can have a different 

number of lanes. A link always should represent the real shape in the road 

network. 


Network Coding 

A link cannot have multiple sections with a different number of lanes. Thus 

multiple links need to be created for each section. If for any reason the 

number of lanes needs to be changed once a link is created, the split 

command can be used (EDIT - SPLIT LINK, default shortcut F8). 

Modeling techniques: 

► Create a link for one direction first, model its curvature and then use 

Generate Opposite Direction to create a similar shaped link in the 

opposite direction. 

► Connectors (rather than links) should be used to model turning movements. 

► Links should not turn corners at an intersection but should be extended 

to almost the center of the junction (if different numbers of lanes do not 

allow for a “through link”). 

This section deals with links carrying vehicular traffic. 

Users of the Pedestrians add-on can define links as walkable areas for 

pedestrians that have been defined as vehicle type. For more details cf. 



The Links & Connectors mode needs to be active. 

1. Right-click at the desired start position of the link, keep the mouse-button 

pressed while dragging the mouse in the direction of flow to the 

destination position and release the mouse button. 

2. Edit the link data (cf. section 6.3.1.2) 




The following properties can be defined for a link: 

● No: Unique identifier of the link (can only be edited when the link is 

created) 

● Name: Any label or comment 

● No. of Lanes: Number of lanes per link direction. 

● Link length: Shows the length as graphically drawn with the mouse. This 

value is not subject to changes. 

● Behaviour Type: Selects the link behavior type that controls driving 

behavior characteristics (cf. sections 5.5.1 and 5.4 for details). 

● Display Type: Selects the link display type that controls color characteristics 

(cf. section 5.5.2 for details). 

● CHANGE DIRECTION: Sets the selected link to the opposite direction of 

traffic as soon as the dialog box is closed by clicking OK. 

● Generate opposite direction: Creates a new link with the same 

curvature and the specified No. of Lanes as the existing link. This new 

link points in the opposite direction of flow and is placed next to the 

original link. If activated, the opposite direction link is generated as soon 

as the window is closed by pressing OK. Any Opposite Direction link is 

not linked with the original link. 

● Use as pedestrian area: Creates a walkable space for pedestrians 

from the link, cf. section 7.1.5 (Pedestrians add-on required). 

[LANES] All parameters refer to lanes: 

● Lane width: Defines the width of each lane of the link. 

● VARIOUS LANE WIDTHS...: Allows to define a different lane width for each 

lane separately. 



The lane width is relevant only for graphics and to determine if a vehicle 

can pass another vehicle within the same lane or on the adjacent lane (if 

driving behavior parameters allow for it). It does not automatically influence 

vehicle free flow speeds. 

● With LANE CLOSURE... one or more lanes of the 

link can be closed to any vehicle class. A LANE 

CLOSURE affects the vehicle behavior as follows: 

Vehicles of classes to which the lane is closed 

will 

- never change lanes to that lane (even if they 

would need to according to a routing 

decision), 

- not enter that lane from a vehicle input on 

this link except when all lanes are closed to 

that class, 

- try to leave that lane as soon as possible if there is an adjacent lane 

that is not closed to the vehicle’s class. 

They will however move to the lane if coming from a connector. 

If all lanes of a link are closed to a vehicle class, vehicles of that class 

will still travel on that link but will not change lanes. 

To deselect a vehicle class in the list, press CTRL while clicking with the left 

mouse button. 

Free lane change only occurs on multiple lane roadway sections, but not 

between adjacent links; thus multiple lane links have to be used whenever 

vehicles should be able to pass each other. 

With certain driving behavior settings it is possible that vehicles can 

overtake other vehicles within the same lane if it is wide enough (e.g. 

vehicles can overtake bikes on a single lane link). Cf. section 5.4 for more 

information on the required driving parameters. 



● NO LANE CHANGE...: 

Define by lane whether the 

vehicles of a vehicle class 

may change to the neighboring 

lane(s) located to the 

LEFT and to the RIGHT in 

with-flow direction. 

Banned lane changes prevent any kind of lane change, even those due to 

routes. Therefore be careful, please: See that lane changes due to routes 

either can be finished before the no-lane-change section or can be 

performed behind the no-lane-change section. 

[DISPLAY] Parameters that change the appearance of the link (no influence on driving 

behavior): 

● Height (3D): Defines the z-coordinate of the start (Begin) and the End 

point of the link to be visible in 3D graphics mode. The Height has no 

effect on any driving behavior (it is independent of the gradient). 

● Thickness (3D): Thickness of the bar representing the link in 3D graphics 

mode. 

● Recalculate Spline Point Height causes the intermediate (spline) 

points of the link to always reflect a straight “height line” between the two 

end points. Cf. section 6.3.1.3 for how to change the height of an 

individual spline point. 



● Visualization: When turned off, no vehicles are shown on that link 

during the simulation. For example, this option can be used to model 

tunnels and underpasses in 2D graphics. In 3D graphics it is 

recommended to use the Height fields instead to show a realistic picture. 

● Label: When showing link labels (to be switched on in VIEW - NETWORK 

ELEMENTS...) this option allows to individually switch off the label of that 

link. 

[OTHER] Various other parameters: 

● The Gradient affects acceleration and deceleration capabilities of all 

vehicles on the link: 

The possible acceleration decreases by 0.1 m/s² per percent of positive 

gradient (road incline). If the gradient is negative it increases by 0.1 m/s² 

per percent. The possible deceleration changes the other way round. 

The gradient has no visual effect in 3D graphics mode (use the Height 

(3D) property to model different heights in 3D). 

● EVALUATION... (relevant for Traffic Display, option Aggregated values, and 

for Link Evaluation): Enables/disables Segment Evaluation of that link 

and defines the Segment Length. These properties can also be set for 

several links simultaneously by using the multi-select option (cf. section 

3.3.2). 

● COST... (relevant for Dynamic Assignment 

only): Opens a window where the cost and 

surcharges of the link can be set. These 

numbers are used by the Dynamic 

Assignment to evaluate the link cost of 

vehicles traveling on that link. 




The Links & Connectors mode needs to be active. 

Select Single-select: 

There are two ways to select a single link or connector: 

► Right-click outside of the VISSIM network calls the Links/Connectors 

selection list: Left-click to select a link or connector and click DELETE, 

ZOOM or DATA). 

► Left-click on the link or connector within the VISSIM network. 

If multiple links/connectors overlap each other at the click position, the 

button (default shortcut TAB) may be used to browse through all links 

and connectors at the mouse click position in order to select the desired 

one. 

Multi-select (Only for Edit attributes, Move, Delete) : 

There are three ways to define active links or connectors for further editing in 

the multi-select mode: 

► Draw polygon (cf. section 6.1) or 

► Use Display type filter (cf. section 5.5.2) or 

► Use Link behavior type filter (cf. section 5.5.1). 

Move Single-select: 

1. Select link. 

2. While holding down SHIFT, left click on the link and drag it to the desired 

position. 

Multi-select: 

1. Select links and connectors. 

2. Left click on the active elements and drag them to the desired position 

while holding down left mouse-key. 


Split 1. Select link. 

2. Choose EDIT - SPLIT LINK (or default shortcut F8) 

3. Left click on the split position. 

4. Specify data: 

- Choose whether a connector should be 

created automatically or not. 

- Optionally the exact split position and the 

number of the new link can be specified. 

5. Confirm with OK. 

Edit 

data 


Single-select: Double click on the link calls the Link Data window, cf. section 

6.3.1.2. 

Multi-select: Right-click outside of 

the VISSIM network calls the Link 

Attributes (Multiselection) window 

for editing data of active links and 

connectors, cf. section 6.3.1.2 



Edit 

curvature 

Select link and choose the desired action for intermediate points: 

► Create: Right click on the desired location within the link. 

► Create spline: While holding down ALT, click left in the section (between 

two points) were you would like to start the spline, drag the mouse to the 

destination section of the spline and release the button there. 

In the upcoming window, select the number of intermediate points 

(including the start and end point of each section) and choose, if the 

existing points should be kept. Option Keep current intermediate 

points is only relevant in case of existing intermediate points. 

The spline is drawn according to the direction of the first and the last 

section of the link portion. 

► Move: Select and drag it to the desired location. The link length is 

automatically adjusted and displayed in the middle section of the status 

bar. 

► Delete: Move it onto another intermediate point. To delete a section of 

points drag the last one of that section to the first one. All points between 

the two will be deleted. 

► Define different height value: While holding down ALT, double click the 

point to enter the height. 

Delete Single-select Mode: 

Select link 

► either in the network and click 

- DEL or 

- EDIT - DELETE 

► or in the selection list, then click 

DELETE. 

Multi-select Mode: 

► Define active links 

► then click 

- DEL or 

- EDIT - DELETE. 

► finally 

- check option(s) and 

- confirm OK in the 

“Multiselection 

Delete” window. 

- 


6.3.2 Connectors 


In order to create a road network, links need to be connected to other links. It 

is not sufficient to place one link on top of another link in order for vehicles to 

continue on the other link. Instead, a connector needs to be created to 

connect the two links. Furthermore connectors are used to model turnings of 

junctions. 

Wherever possible the overlapping parts of a link and connector should be 

minimized in order to avoid modeling errors. 

If data is read from an *.INP file that has been created with a VISSIM 

version prior to 5.0 both the display type and the behavior type of its origin 

link are assigned to each connector. 


The Links and Connectors mode needs to be active. 

1. With the right mouse button click at the connector´s desired start position 

inside a link, drag the mouse in the direction of flow to the position 

inside the destination link. 

2. Release the mouse key. 

The Connector window opens, cf. section 6.3.2.2. 

3. Edit the connector data. 




The following attributes can be defined for a connector: 

● Name: Any label or comment 

● Behaviour Type: The link 

behavior type controls the 

driving behavior characteristics 

(cf. sections 5.5.1 and 

5.4 for details). 

● Display Type: The display 

type controls the color 

characteristics (cf. section 

5.5.2 for details). 

● from link / to link: Defines the 

assignment of lane(s) of the 

connector with the lanes of 

both the start and the 

destination link. Lane 1 

represents the rightmost 

lane. Multiple lanes can be 

selected by pressing SHIFT. 

The number of lanes selected from both lists must be the same. The 

allocation can still be edited once the connector has been created. 

● Recalculate Spline: If this option is checked VISSIM draws an automatic 

arc (Bezier curve) with the specified number of Points between the 

start and the end point of the connector. This can be done repeatedly in 

order to reflect changes in the placement of an adjacent link. The number 

of intermediate points of a connector determines the accuracy of the arc: 

2 points are sufficient for a straight connector, 5 to 15 intermediate points 

are recommended for curves (depending on the length and shape of the 

connector). 


[LANE 

CHANGE] 


● With LANE CLOSURE... one or more lanes of the 

connector can be closed to any vehicle class. A 

lane closure affects the vehicle behavior as 

follows: 

- Vehicles of classes to which the lane is 

closed will never move from an adjacent lane 

to that lane (even if they have to! – e.g. 

according to a routing decision). 

- If all lanes of a connector are closed to a 

vehicle class, vehicles of that class will still 

travel on that connector but will not change 

lanes. 

● The Emergency Stop and Lane change parameters are used to model 

the lane change behavior for cars following their Routes. 

- Emergency Stop defines the last possible position for a vehicle to 

change lanes. It is measured upstream from the start of the 

connector. The min. emergency stop distance is 5m. If a vehicle 

needs to change more than one lane, an additional 5m is added for 

each additional lane. If the current lane has an odd no., an additional 

2.5m is added to the total emergency stop distance. This is to avoid a 

conflict because of identical locations when two vehicles on adjacent 

lanes mutually want to change lanes. 

Example: A vehicle on lane 1 needs to change to lane 4 in order to 

continue on its route. The emergency stop distance in the subsequent 

connector is defined as 10m. Then the relevant emergency 

stop distance for lane 1 is: 10+5+5+2.5 = 22.5m. For lane 2 it would 

be 10+5=15m and for lane 3 10+2.5=12.5m. 

The emergency stop position (in contrast to the distance) is then 

computed as the difference of the link coordinate, where the 

connector starts, minus the emergency stop distance. From the result 

only the integer amount is taken (no decimals). 

Example: If the connector starts at coordinate 67.2 and the emergency 

stop distance is 12.5m, the emergency stop position results in 

67.2-12.5=54.7 -> 54m. 

- Lane change defines the distance at which vehicles will begin to 

attempt to change lanes (e.g. distance of signpost prior to a junction). 

- per lane: If this option is active, the given lane change value will be 

multiplied by the number of lanes the vehicle has to change to reach 

the connector. 

Example: To reach a connector starting only from lane 1 with lane 

change distance 200 m per lane, a vehicle on lane 3 starts to look for 

a gap to change lanes from 400 m upstream of the start of the 

connector. 

● Desired Direction: If vehicles are traveling on Routes, this option is of just 

a viewing effect during a simulation run: 



[DISPLAY] 

Taking the currently selected 

option into consideration, 

matching intended lane changes 

or turning movements are 

visualized by direction-indicating 

blinking prior to changing to a 

connector due to the vehicle´s 

route. 

When using Direction Decisions (not recommended) it needs to be set to 

a value different from All. Vehicles without any routing and direction 

information will always follow those connectors which are assigned to 

direction All. If no such connector exists, those vehicles will leave the 

network without warning 

● Thickness (3D): Thickness for 

display of connectors in 3D 

mode. 

● Recalculate Spline Point 

Height (3D mode only): Causes 

the intermediate (spline) points 

of the connector to always 

reflect a straight “height line” 

between the two end points (cf. 

the “Graphical Editing - Edit 

curvature” section on how to 

change the height of an 

individual spline point). 

● Visualization: When turned off, no vehicles are shown on that 

connector during the simulation. This option can be used e.g. to model 

tunnels and underpasses in 2D graphics. In 3D graphics rather use the 

Height fields of the surrounding links to show a realistic picture. 

Otherwise vehicles will just disappear instead of using different levels. 

● Label: When showing connector labels (to be switched on in VIEW - 

NETWORK ELEMENTS...) this option allows to individually switch off the 

label of that connector. 


[DYNAMIC 

ASSIGNMENT] 

(optional 

module) 

[OTHER] 

● Connector closed to: Allows for 

modeling multi-modal networks 

for the use with Dynamic 

Assignment. By selecting one or 

more vehicle classes in the list, 

the connector is not available 

for route choice of the selected 

classes. Pressing CTRL while 

clicking with the left mouse 

button adds or removes an item 

from the current selection. 

● COST...: Opens a window where the cost 

and surcharges of the connector can be 

specified. These numbers are used by the 

Dynamic Assignment to evaluate the cost of 

vehicles traveling on that connector 


● The Gradient affects acceleration 

and deceleration capabilities 

of all vehicles on the 

connector: 

- The acceleration decreases 

by -0.1 m/s² per percent of 

positive gradient (road 

incline) 

- If the gradient is negative it 

increases by 0.1 m/s² per 

percent. 

The possible deceleration changes the opposite way. 

The gradient has no visual effect in 3D graphics mode (use the Height 

(3D) property to model different heights in 3D). 

● EVALUATION... (relevant for Display options - [TRAFFIC], option Aggregated 

values, and for Link Evaluation): 

Enables/disables Segment Evaluation of that 

link and defines the Segment Length. These 

properties can also be set for several links 

simultaneously by using the multi-select option 

(cf. section 3.3.2). 


The Links and Connectors mode needs to be active. 



Select Single-select: 

There are two ways to select a single link or connector: 

► Right-click outside of the VISSIM network calls the Links/Connectors 

selection list: Left-click to select a link or connector and click DELETE, 

ZOOM or DATA). 

► Left-click on the link or connector within the VISSIM network. 

If multiple links/connectors overlap each other at the click position, the 

button (default shortcut TAB) may be used to browse through all links 

and connectors at the mouse click position in order to select the desired 

one. 

Multi-select (Only for Edit attributes, Move, Delete): 

► There are three ways to define active links or connectors for further 

editing in the multi-select mode: 

- Draw polygon (cf. section 6.1) or 

- Use Display type filter (cf. section 5.5.2) or 

- Use Link behavior type filter (cf. section 5.5.1). 

► Right-click outside of the VISSIM network to call the Link Attributes 

(Multiselection) window for editing data of active links and connectors. 

Move Single-select: 

A connector can only be moved along with its start and destination link while 

in Multi-Select-Mode (cf. section 3.3.2 for details). 

► To change the connector position within the start or destination link: 

1. Select the connector 

2. Click on the desired start/end point and drag it with the mouse to the 

desired location within the link. 

► To change the start/end link of the connector: 

1. Select the connector 

2. Click on the desired start/end point and drag it with the mouse to the 

desired location within the new link. 

Multi-select: 

1. Select links and connectors. 

2. Left-click in the area of active elements and drag them to the desired 

position while holding down the left mouse-key. 

Moving the start/end points of a connector or moving the entire connector 

from one link to another may break public and private transport routes. 

Split Not possible for connectors. 


Edit 

data 


Single-select: Double click on the connector calls the Connector window, cf. 


Multi-select: 

Right-click outside of the VISSIM 

network calls the Link Attributes 

(Multiselection) window for editing 

data of active links and 

connectors, cf. section 6.3.1.2. 

Click CONNECTORS… to access the 

connector-specific attributes, cf. 


The attributes Behavior Type and Display Type can be edited in the Link 

Attributes (Multiselection) window for all selected links and connectors 




Edit 

curvature 

Select connector. Choose the desired action for intermediate points: 

► Create: Right click on the desired location within the link. 

► Create automatic full spline: Double click on the connector and activate 

the Spline option. All intermediate points are automatically relocated to 

form a Bezier curve. 

► Create automatic partial spline: 

1. While holding ALT, press the left mouse button in the section 

(between two points) were you would like to start the spline and keep 

the button pressed 

2. Drag the mouse to the destination section of the spline and release 

the button there. The window Convert section to spline opens. 

3. Select the number of intermediate points (including the start and end 

point of each section) and choose, if the existing points should be 

kept. 

4. The spline is drawn according to the direction of the first and the last 

section of the connector portion. 

► Move: Select and drag it to the desired location. The connector length is 

automatically adjusted and displayed in the middle section of the status 

bar. 

► Delete: Move it onto another intermediate point. To delete a section of 

points drag the last one of that section to the first one. All points between 

the two will be deleted. 

► Define height value: While pressing ALT, double click on the point to 

enter the height. 

Delete Single-select: 

Select connector 


- DEL or 


► or in the selection list and click 

DELETE. 

Multi-select: 

► Define active elements, 


- DEL or 


► finally 





- 


6.3.3 Desired Speed Changes 


Whenever there is a change of free flow speed in the VISSIM network, a 

speed distribution change is to be defined. There are two ways of defining 

speed distribution changes: 

► Reduced Speed Areas (Temporary change) 

► Desired Speed Decisions (Permanent change) 

Speed changes are required for modeling the following: 

► bends, curves and turning lanes at intersections, 

► any speed limits, 

► bottlenecks. 

Both of them are modeled as network elements in VISSIM. The main 

difference between the two is, that with reduced speed areas a (faster) 

vehicle automatically decelerates prior to the start of the reduced speed 

area to get the speed defined for its vehcile class for that reduced speed 

area right at the start of it. After passing the reduced speed area the vehicle 

automatically accelerates to the desired speed that previously was assigned 

to it. In contrast, a desired speed decision does not affect the vehicle before, 

but when passing the decision cross section. 

Each vehicle gets a fixed fractile value for speed distributions assigned when 

entering the network. For example, if the fractile is 40%, the vehicle will 

always get the 40% percentile of the desired speed distribution at desired 

speed changes. If the fractile is 100%, the vehicle will always get the 

maximum speed value of the distribution. 

Reduced speed areas and desired speed decisions can also be labeled 

with the numbers of the assigned speed distributions. If there is only one 

distribution, the lower and upper limit of the distribution is displayed 

instead. Via VIEW - NETWORK ELEMENTS..., the label display can be switched 

on or off. 

6.3.3.1 Reduced Speed Areas 

When modeling short sections of different speed characteristics (e.g. 

curves or bends), the use of reduced speed areas is advantageous over the 

use of desired speed decisions. 

Reduced speed areas are typically used for curves (e.g. turning movements). 

Thus they are normally placed on connectors rather than links. 

For multi-lane links reduced speed areas need to be defined for each lane 

separately. Thus different characteristics can be defined for each lane. 

A reduced speed area cannot reach across multiple links. However, multiple 

consecutive areas (one for each link) can be created and placed on 

consecutive links. If two reduced speed areas with the same properties are 

placed close to each other then the vehicles affected by them will continue 

with the new speed even between the two areas. 



Upon arriving at a reduced speed area, each vehicle is assigned a new 

desired speed from within the speed distribution assigned to its vehicle class. 

Basically, a reduced speed area is not meant to speed up a vehicle when 

reaching it, though this is also possible. 

► When approaching a reduced speed area, a faster vehicle reduces its 

speed in order to reach its new (slower) speed at the beginning of the 

reduced speed area. The deceleration process is initiated according to 

the user-defined deceleration value. 

► A slower vehicle will not change its speed prior to reaching the start of 

the reduced speed area. For vehicles with a slower current desired 

speed, the start of a reduced speed area works like a desired speed 

decision with that higher desired speed. 

A reduced speed area only takes effect for vehicles of the selected vehicle 

classes. The vehicle classes of vehicles that should keep their original (slow 

or fast) speed when passing the reduced speed area may not be selected for 

the list of vehicle classes which are to be regarded by the reduced speed 

area. 

After leaving the reduced speed area, each vehicle automatically gets its 

previous desired speed again. The acceleration at the end of the reduced 

speed area is determined by the characteristics of the driver/vehicle unit as 

well as the original desired speed. Exception: If two reduced speed areas 

with identical properties were defined next to each other in with-flow 

direction, the concerned vehicles will keep the new speed even in the section 

in-between. 

Definition 

Prior to the definition of a reduced speed area at least one desired speed 

distribution needs to be defined, cf. section 5.2.1. 

1. Select the Reduced speed areas mode. 

2. Select the link or connector where the reduced speed area should be 

placed on. 

3. On the link or connector, mark the start of the reduced speed area by 

right click on its start position. Drag the mouse along the link/connector 

while keeping the right button pressed to define the length of the reduced 

speed. 

4. Release the mouse button. The Create reduced speed area window 

appears. 

5. For each selected vehicle class passing that link/connector define the 

appropriate speed and acceleration value. 


Properties & Options 

You can define the following properties of a reduced speed area: 



● No.: Unique identification of the reduced speed area. 

● Name: Label or comment 

● Length: Length of reduced speed area. 

● Lane: Lane position within the link. 

● At: Start position (link/ connector coordinate) 

● Time (from/until): Defines the time interval for which the reduced speed 

area is active. 

● Label: When showing labels (names) of all reduced speed areas (cf. 

VIEW - NETWORK ELEMENTS...), this option allows to individually switch off 

the label of that reduced speed area. 

● Vehicle Class - Desired Speed - acceleration combination: For each 

relevant vehicle class one data line needs to be defined. It includes the 

desired speed distribution to be used by vehicles of that class while they 

travel in the reduced speed area and a deceleration value that defines 

the maximum deceleration used to slow down prior to the reduced speed 

area. The lower the value, the further away a faster vehicle starts to slow 

down. 

Use NEW, EDIT and DELETE to create, modify or remove a data line. 

In order for a reduced speed area to become effective vehicles need to 

pass its start position. 

A reduced speed area should not overlap with a stop line (of a signal head, 

priority rule or stop sign) but should start after a stop line. Otherwise it 

might happen that the stop line is not recognized by all vehicles. 

The combination of vehicle classes, speed distribution and acceleration 

value of the last reduced speed area that was edited is used as a default 

when placing a new reduced speed area. 



Editing 

The Reduced speed areas mode needs to be active. 

Select There are two ways to select a reduced speed area: 

► Outside of the VISSIM network, right-click to call the Reduced speed 

areas selection list: Select the reduced speed area by left-click and click 

DELETE, ZOOM or DATA to continue. 

► In the VISSIM network, left-click to select the link or connector. Select the 

reduced speed area by another left-click. 

Zoom In the Reduced speed areas list, click ZOOM for the selected reduced speed 

area. 

Edit data In the Reduced speed areas list, click DATA for the selected reduced speed 

area. 

In the network display, double-click the reduced speed area. 

Delete In the Reduced speed areas list, click DELETE for the selected reduced speed 

area. 

In the network display, select the reduced speed area and click DEL or drag it 

out of its link/connector while keeping the left mouse-key pressed. 

6.3.3.2 Desired Speed Decisions 

A desired speed decision is to be placed at a location where a permanent 

speed change should become effective (i.e. change of desired speed). Each 

vehicle gets a new speed from the relevant speed distribution as it crosses 

over the desired speed decision. Only then it reacts to the new speed - either 

by acceleration or deceleration according to the particular acceleration / 

deceleration function. 

The typical application is the location of a speed sign in reality. Other 

applications include entries or exits of urban areas or narrow lane widths 

(average speed drops). 

For multi-lane links desired speed decisions need to be defined for each lane 

separately. Thus different characteristics can be defined for each lane. 

Definition 

Prior to the definition of a desired speed decision at least one desired speed 

distribution needs to be defined (cf. section 5.2.1). 

1. Select the Desired speed decisions mode. 

2. Select the link/connector where the desired speed decision should occur. 

3. Right click at the location of the speed decision on the selected link (decision 

point). The Create desired speed decision window opens. 

4. For each vehicle class passing that link/connector select the appropriate 

new speed distribution. 





The properties of a desired speed decision can be accessed by 

► selecting the corresponding link/connector and 

► double-clicking with the left mouse button on the desired speed decision. 

● No.: Unique identification of the 

desired speed decision. 


● Lane: Lane position within the 

link 

● At: Link/connector coordinate. 

● Time (from/until): Defines the 

time interval to which the 

desired speed decision refers. 

● Label: When showing labels (names) of all desired speed decisions 

(cf. VIEW - NETWORK ELEMENTS...) this option allows to individually switch 

off the label of that desired speed decision. 

● Vehicle Class - Desired Speed Distribution combination: For each 

relevant vehicle class one data line needs to be defined. It includes the 

desired speed distribution to be assigned to vehicles of that class as they 

cross over the desired speed decision. Use EDIT, NEW and DELETE to 

create, modify or remove a data line. 

Vehicles of classes that have not been selected for a desired speed 

decision remain unaffected. 

The combination of vehicle classes and speed distribution of the desired 

speed decision that was edited recently is used as a default when a new 

desired speed decision is added. 

The desired speed decision defines the position where vehicles intend to 

change the desired speed (not where they reach it). Thus the phase of 

acceleration or deceleration takes place after the vehicle has passed this 

decision point. Depending on the current speed, the vehicle reaches its 

new desired speed at some point downstream. 



If the desired speed decision is defined to model only a short stretch of a 

low speed area (e.g. bend or curve), a second desired speed decision has 

to be defined at the end to change the desired speed back to its original 

value. In that case it is more appropriate to use a Reduced Speed Area, 


Desired speed decisions for turning vehicles can be modeled by placing a 

Reduced Speed Area on the turning connector. 

6.3.4 Rotate and Translate Network 

In the VISSIM workspace it is possible to translate and rotate the entire 

network, including static 3D objects, 3D signals and keyframe positions. In 

addition, when the network is translated, all background images that are 

currently open in VISSIM are translated as well. 

To move only a section of the network (without 3D objects, background 

images or keyframes), the move functionality of the Multi-Select mode may 

be used (cf. section 3.3.2). 

Rotate Network 

EDIT – ROTATE NETWORK... rotates the network 

counterclockwise by the specified Angle. 

Rotating the network does not affect background 

images. 

Translate Network 

EDIT – TRANSLATE NETWORK... moves the network by 

the specified X, Y and Z Distance. 

Translating the network in z-direction does not affect 

background images. 

6.3.5 Pavement Markers and Zebra Crossings 

The Pavement Markers edit mode allows for placing markers on lanes 

showing the turning movements or direction of that lane or a high occupancy 

vehicle diamond. 


Definition 


1. To insert a marker in Pavement Marker mode, select a link or connector. 

2. Right click on the start position of 

the marker. The Create pavement 

marker window opens. 

3. Define the Type of the marker, the 

exact Position and the Direction. It 

is possible to choose any 

combination of Directions (or 

center island for US roundabouts). 

For Zebra crossings, no direction 

has to be selected, but the length 

needs to be entered. 

The visibility of all pavement markers is controlled in VIEW – NETWORK 

ELEMENTS. 

Option Zebra Crossing is meant for marking links which are defined as a 

pedestrian link and will be used as pedestrian crosswalks. It provides 

visualization in full link width. Any traffic information is to be defined with 

the link, cf. section 7.1.5. 


Double-clicking a pavement marker calls the Edit pavement marker window. 

● Type: Defines the displayed shape. 

● Directions (for option Arrow marker only): Any combination is possible for 

the upper three options. 

● Position: Enter position on link. 

Pavement markers do not affect the driving behavior. They do not provide 

a means to model turning movements. Use routes to model turning movements. 



6.4 Automobile Traffic 

In VISSIM there are basically two methods to model automobile routing 

information: 

► Static routes using routing decisions (or direction decisions): With static 

routes the path of vehicles traveling through the VISSIM network can be 

statically determined either by routing decisions (section 6.4.4) or 

direction decisions (section 6.4.5.4). However, it is strongly 

recommended to use routing decisions since routes are much easier to 

handle and the vehicle inputs can be defined more precisely. 

► Dynamic Assignment using OD matrices (“Dynamic Assignment” add-on 

required): The use of Dynamic Assignment is explained in detail in 

chapter 12. For Dynamic Assignments, neither static routes nor inputs 

need to be defined. 

6.4.1 Vehicle Compositions 

Vehicle compositions represent the mix of vehicle types and have to be 

defined prior to the input flow definition. Please note that vehicles of PT 

routes must not be included here but are to be defined separately (cf. section 

6.5). 

A vehicle composition consists of a list of one or more vehicle types. To each 

of these vehicle types, a flow percentage and a speed distribution are 

assigned. Both vehicle compositions and pedestrian flows can be defined as 

traffic compositions. 

Also pedestrian flows can be defined as a vehicle composition, but should 

preferrably be defined as a pedestrian composition. The pedestrians as 

vehicle compositions are bound to links and follow the Wiedemann model (cf. 

section 5.4.1). 

6.4.1.1 Creating & Editing 

Vehicle compositions can be defined via TRAFFIC - VEHICLE COMPOSITIONS... 


The list can be edited via 

NEW, EDIT and DELETE. 

For additional parameters 

such as Catalytic converter 

temperature distribution 

and cooling water 

temperature distribution the 

optional Emissions add-on 

is required. 

Automobile Traffic 


For each data line the following attributes are to be defined: 

● Vehicle type: Defines for which vehicle type the 

following data is defined. 

● Relative flow: The relative percentage 

(proportion) of this vehicle type. After a 

composition is completed, VISSIM internally 

adds up all Relative flow values and calculates 

the absolute percentages to be used for each 

vehicle type of this composition. 

Therefore it is not necessary to enter values strictly between 0.0 and 1.0 

but it is also possible to enter vehicle flows instead of percentages. 

● Desired speed: The speed distribution to be used for the specified 

vehicle type when entering the VISSIM network. 

6.4.2 External Vehicle Course Files 

This option allows for graphical representation of external vehicle course 

information thus not using any driving behavior of VISSIM. External vehicle 

course files need to be selected in the External Vehicle Course Files window 

which is accessed by TRAFFIC - EXTERNAL VEHICLE COURSE FILES... 

Every file defines the journey of one vehicle using the following ASCII text 

format: 

► The 1 st row contains 5 values, separated by one or more blanks: 

- vehicle type number 

- no. of starting link 

- no. of starting lane 

- coordinate within starting link [m] 



- starting time [s] 

► Every further row contains one value: 

- Speed [m/s] at the end of simulation time step 

The difference from the speed at the end of the previous time step 

returns the constant acceleration (if positive) respectively 

deceleration (if negative) during the current time step. 

Every time step of the simulation the next speed information for each vehicle 

will be read out of the file and assigned to that vehicle. 

The new coordinate is determined by the equation of motion: 

new_coordinate = old coordinate 

+ old_speed ● time_step_length 

+ 0.5 ● acceleration ● time_step_length 2 

Example 

If the parameter Simulation resolution is set to 10 Time steps per 

simulation second, VISSIM will read ten speed time steps per second 

from file. 

This leads to a coordinate time step (time_step_length) = 0.1 seconds. 

As soon as the end of the file is reached, the vehicle will be taken out of the 

network. 

6.4.3 Vehicle Inputs (Traffic Volumes) 

In VISSIM, time variable traffic volumes to enter the network can be defined. 

For vehicle input definition, at least one vehicle composition has to be 

defined, cf. section 6.4.1. 

Traffic volumes are defined for each link and each time interval in vehicles 

per hour even if the time intervals are different from one hour. Within a time 

interval vehicles enter the link according to a Poisson distribution. 

If the defined traffic volume exceeds the link capacity the vehicles are 

‘stacked’ outside the network until space is available again. If any ‘stacked’ 

vehicles cannot enter the network within the defined time interval, a message 

is traced to a log file (same name as input file with extension *.ERR) 

indicating also the time interval of the particular input. Furthermore, the user 

is notified in detail at the end of the simulation. Please note that if the vehicle 

input time interval exceeded the simulation period, no messages are stored 

in the *.ERR file in case there are stacked vehicles left. The maximum 

volume that can be reached depends on permitted speed and driving 

behavior parameters. 

Input flows do not need to be defined when Dynamic Assignment is used as 

then the flow data is contained in the OD matrices. 



Define 

new time 

interval 


For all subsequent actions the Vehicle Inputs mode needs to be active. 

There are two ways to open the Vehicle Inputs window: 

► For vehicle inputs of a certain link: Double-click that link. 

► For all vehicle inputs in the network: Right-click outside of the VISSIM 

network. 

As long as this modeless dialog window is open you may navigate or zoom 

in/out the network display. 

The vehicle input data is arranged in two sections: 

► Volumes/Compositions section 

► Time intervals section 

Time Intervals Section 

(This section can be hidden by clicking on . To show it again, click on .) 

Here the time interval boundaries are defined. At least one time interval is 

required, thus the first and the last line may not be deleted. By default, the 

simulation period is set for the time interval, cf. section 8.1.1. 

Changes to the list of time interval thresholds will immediately change the 

column layout in the Volumes/Compositions section (see below). 

1. Right click inside the section and choose NEW from the context menu. 

A new line is added at the end of the list. 

2. Enter the value of the new time interval boundary. The value must be 

different from any other time but can also be smaller than the last value. 

In that case, an existing time interval is split at the time newly entered. 



Edit time 

interval 

data 

Delete 

interval(s) 

Define new 

vehicle 

input 

Any time entry can only be changed to a value that is in between the 

neighboring times (i.e. the time sequence cannot be changed; to do so, the 

given boundary has to be deleted and a new threshold has to be added). 

1. Select the time to change. 

2. Type in the new time and confirm with ENTER. 

All flow values remain unchanged. 

1. Select the start time of the interval to be deleted. 

Press CTRL simultaneously to select several rows. 

2. Right click and choose DELETE from the context menu. 

3. Confirm the upcoming message. 

If a time interval does not contain any input values, the time interval will be 

deleted when the Inputs window is closed. 

Volumes/Compositions Section 

For each link, the vehicle inputs are arranged in columns, sorted by time 

interval. For each combination of link and time interval, a data pair consisting 

of a volume and a vehicle composition may be defined (empty pairs are 

allowed). It is not possible to define a volume without vehicle composition or 

vice versa. 

It is possible to have multiple rows for the same link if there are volumes for 

different vehicle compositions defined within a time interval. When sorted by 

link no., these rows are identified by a combined display of the link no. and 

with the same input flow name (optional). 

Prior to the definition of vehicle inputs at least one vehicle composition needs 

to be defined (cf. section 6.4.1). 

1. Double-click on the link where the new vehicle input is to be defined. The 

Vehicle Inputs window opens with the corresponding link no. 

2. If a vehicle input already exists, either change it or right click and choose 

NEW to create a new row for this link. 

3. Define the input properties, cf. section 6.4.3.2. 

Edit data For volume changes: 

1. Select the cell to change. 

2. Type in the new volume and confirm with ENTER. 

For composition changes: 


2. Press the button on the right to open the pull-down list. 

3. Select the new composition from the list. 

For further information and property changes please refer to section 6.4.3.2. 


Scale 

Volume 

Copy & 

Paste 

data 

Delete 

vehicle 

input(s) 


Select the cells with volume values to be multtiplied by the user-defined 

factor. Click SCALE VOLUMES in the context menu and enter the factor for 

volume scaling. 

In the Volumes/Compositions section, the COPY & PASTE commands (similar 

to the Microsoft Excel method) are available through context menu. Data 

exchange is permitted within the input window or from/to external data 

sources (e.g. *.XLS or *.DOC files). 

► COPY: Select a source cell or rectangular source region using 

- SHIFT + cursor keys or 

- mouse move while holding down left mouse button. 

► PASTE: Select a destination region being 

- congruent (identical dimensions) or 

- larger than the source region (e.g. source 2x3, destination 6x6 or 

10x15; not ok: 3x6 or 6x10). 

Please disable display of either volumes or compositions before selection, 

since only one data type can be copied/pasted. 

Only values of visible columns are copied and pasted (not values that are 

contained in hidden columns). 

1. Select the entire row to be deleted by clicking on the row no. (on the far 

left of the grid). Press CTRL simultaneously to select several rows. 






Cf. section 6.4.3.1 on how to open the Vehicle Inputs window. 

For information about the Time section, please refer to section 6.4.3.1. 

This section describes the properties and options for the Volumes/Compositions 

section. 

● Link Number & Link Name: Refers to the link where the vehicle input is 

placed. Values can be selected from the list of all links either by no. or 

(optional) name of the link. 

● Input Name: Optional name of the vehicle input. Refers to all data 

entered for the same link.. 

● Show Label: When showing vehicle input labels (cf. VIEW - NETWORK 


vehicle input. 

Each of the following columns (one for each time interval) contains the 

vehicle flow and vehicle composition data pair(s) per link. 

● Column Header: Shows start and end time of the interval (in simulation 

seconds). The columns are created automatically from the list of time 

intervals in the Time Interval section (if more or other time intervals are 

needed, please refer to “Add new interval” in the “Time Intervals” section 

above). 

● Data pair: For each row and time interval, a data pair may be defined: 

- Upper line: Vehicle input volume (veh/h) 

- Lower line: Vehicle composition 

The text color indicates whether the data pair is valid for 

- this interval only (black) or 



- a period of combined intervals (Continued Input: light-grey). In that 

case, only the master cell (black) can be edited and affects 

automatically all subsequent continued cells. 

The background color indicates whether the vehicle volume is 

- stochastic (white) or 

- exact (yellow). 

When EXACT VOLUME is enabled VISSIM generates exactly the edited 

number of vehicles to enter the network as opposed to a distribution. 

The configuration of the data section can be changed via the context menu. 

Select one or multiple cells and call: 

● EXACT VOLUME: Volume values are regarded as exact volumes, if this 

option is checked. The cells are highlighted in yellow. 

● STOCHASTIC VOLUME: Volume values are regarded as stochastic volumes, 

if this option is checked. The cells are not highlighted. 

● CONTINUED INPUT: Select all cells to be combined (except the master cell) 

and check this option to define a combined flow: The master cell is the 

one previous to the selected cells; the master cell entry spans over the 

selected sequence of time intervals. 

- The master cell remains editable, indicated by black text entries. 

Changes to the master cell entry are copied to all subsequent cells. 

- Grey text entries indicate combined cells (Read-only). 

Uncheck this option to separate selected combined cells. 

● VIEW VOLUMES: Toggles display of the volume values (upper line per time 

interval) on and off. 

● VIEW COMPOSITION: Toggles display of the selected vehicle compositions 

(lower line per time interval) on and off. 

● ZOOM: The input´s position in the network is placed in the middle of the 

VISSIM window on screen. 

6.4.4 Routing Decisions and Routes 

A route is a fixed sequence of links and connectors: 

► from the routing decision point (red cross-section) 

► to at least one destination point (green cross-section). 

Each routing decision point can have multiple destinations resembling a 

tree with multiple branches. 

A route can have any length - from a turning movement at a single junction to 

a route that stretches throughout the entire VISSIM network. 

A routing decision affects only vehicles of a class that is contained in the 

routing decision and not having any routing information. If a vehicle already 

has a route assigned to it then it first has to pass its destination point (green 



bar) prior to be able to receive new routing information. Exceptions to this 

rule: Partial routes and Parking lot routes. 

Types of Routing Decisions and Routes 

► Static: Routes vehicles from a start point (red) to any of the defined 

destinations (green) using a static percentage for each destination. 

► Partial: Defines a section of one or more static routes where vehicles 

should be re-distributed according to the routes and percentages defined 

by the partial routes. After leaving the partial route vehicles continue to 

travel on their original route. 

Partial routes also affect PT lines. In order to avoid rerouting of PT lines 

restrict the Vehicle Classes accordingly. 

► Parking lot (only for parking lots of type Real parking spaces): Defines a 

decision point that automatically generates routes leading to each of the 

selected destination parking lots and routes leading from those parking 

lots back into the link network. Select parking lot(s) of the appropriate 

type instead of destination point(s), cf. section 6.4.5. 

► Managed lanes: Creates two parallel routes from the decision to the 

destination. For a Managed Lanes Routing Decision, a user-defineable 

toll pricing model and a decision model have to be selected. Thus, 

vehicle occupancy (SOV, HOV2, HOV3+), simulation time and the 

current traffic situation (travel time savings, average speed) are 

regarded. 

Relevant only for Dynamic Assignment: 

► Dynamic: Defines a decision point where traffic is re-routed according to 

a user-definable condition and strategy. For more information please 

refer to section 12.3.1 and to section 12.7.5. 

► Closure: Defines a route as a link sequence to be excluded from the set 

of edges available for Dynamic Assignment. For more information please 

refer to section 12.8.4. 


Route definition (except routes of type Parking Lot) is a four step process. To 

initialize the process, activate the Routes mode. The next required action 

is shown in the status bar. To discard the recent step and return to the 

previous step, left click outside the VISSIM network. Please cf. section 

6.4.4.6 for details on where to place the decision and destination points. 


1. Select the link/connector for the start of the route. 


2. Right click on the location for the 

routing decision point (red bar) on 

the selected link. 

The Create routing decision window 

appears. 

Define basic routing decision 

properties (cf. section 6.4.4.4) and 

confirm with OK. 

3. Select the link/connector for the 

route destination. 

4. According to route type: 

- Static Routes, Partial Routes, 

Closures: 

Right-click on the location for the 

route destination point (green). 

If there is a valid connection between the red bar and the click position 

the link sequence is shown as yellow band from the routing 

decision to any destination point defined for that routing decision. 

After definition of all destinations per routing decision, right-click 

outside of the link to call the Routes window. 

Define the route properties (cf. below) and confirm with OK. 

If there is no consecutive sequence of links and connectors possible, 

VISSIM cannot suggest a route and thus no yellow band appears. 

The Routes window will not contain route data for this routing 

decision. In that case, either the destination link or destination 

location must be changed or any missing connectors be created. 

- Parking Lot: Select parking lot(s) by left-click; selected parking lots 

are highlighted in blue. 

- Dynamic: cf. section 12.7.5 

- Managed Lanes: As for static routes, right-click to define the location 

for the route destination point (green). The first route being generated 

for a routing decision of the Managed type is always a route of the 

Toll type which is highlighted green. To generate the second route, 

mark – for the same route start point – the second route destination 

point next to the first one on the same link. The second route which is 

created for a routing decision of the Managed lanes route type is 

always a route of the General purpose route type and is indicated by 

yellow color. A routing decision of the Managed lanes type has just 

two routes to which – similar to partial routes – the same destination 

point is allocated automatically 



A routing decision of the Managed Lanes type needs to be complete. 

Otherwise it is ignored in the simulation. Both a route of the Managed type 

and a route of the General purpose type are required. Furthermore, a 

managed lane facility with user-defined toll pricing calculation model and 

decision model needs to be allocated. 

To define further destinations (multiple routes) from the same routing 

decision point (red bar), follow the steps outlined below: 

► Select the next destination link immediately. 

► Right-click the position of the next destination cross-section (or parking 

lot). 

This has to be done for each additional route starting from the currently 

active decision cross-section. 

To define a new routing decision, deselect all links by double-clicking in the 

network and repeat steps 1 to 4. 

In the Routes window, the following settings are required: 

► Set the time intervals by routing decision type. 

► Select appropriate Vehicle class(es) by routing decision. 

6.4.4.2 The Routes Window Structure 

As this is a mode-less dialog you may navigate or zoom in/out the network 

display though the window is open. 


Tabs 

(Types) 


The data describing routing decisions and their routes is arranged in the 

following sections of the Routes window: 

For each type of routing decision, this section contains a specific tab. Since 

defined routing decisions are stored and edited by type, each tab contains 

the list of routing decisions of this type. Additionally the total numbers of 

routing decisions and routes of the particular type are listed underneath. 

Each tab page allows for the following steps: 

► Select a single or multiple or all routing decision(s) of this type: 

- You can edit the list of routing decisions. 

- You can call the route list display in the Routes section and edit the 

list of routes. 

► Copy/Paste/Edit the following data: Name, At, Vehicle class(es). 

► Delete the selected routing decision(s) of this type from the list. 

► Zoom into the network with the selected decision(s) in the focus. 

The content of the sections to the right depends on the particular routing 

decision type and on the selected decision(s). 

Decision This section can be hidden by clicking . To show it again, click . 

If only a single routing decision is selected in a tab, this section allows for 

the following: 

► Editing routing decision properties (except type and link number). 

► Allocating the appropriate vehicle class(es). 

List of 

Routes 

The list contains in particular: 

► all routes selected via routing decisons (and link filter, if applicable) 

► all time intervals defined for that type of routing decisons (columns) 

► the corresponding flow value per route and time interval (user entry) 

This section allows for the following processing steps: 

► Selecting a single or multiple or all route(s) starting from this decision. 

► Editing route properties. 

► Copy/Paste volume data for marked time interval(s). 

► Checking the routes for inconsistencies. 

► Deleting the selected route(s) from the list. 

► Zooming into the network with the selected route(s) in the focus. 



Time 

Intervals 

This section can be hidden by clicking . To show it again, click . 

Here all boundaries of the time intervals for which the routing decisions of 

this type should be active are defined by routing decision type. In case of 

temporal deviations of the flow shares using the routes of a routing 

decision, various non-overlapping time intervals have to be defined. 

VISSIM allows for different route proportions for each time interval. When 

multiple routes are defined for a routing decision all Relative Flows for each 

time interval are listed in the Routes section and can be edited there. 

For routing decisions of the Parking lot type not only the Time interval(s) 

need to be defined, but also the Rate of parking vehicles (in %) has to be 

entered and the Time distribution has to be selected per time interval. 

Cf. section 5.2.6. 

At least one time interval is to be defined, thus the first and the last line may 

not be deleted. By default, the time interval 0-99999s is defined. Changes 

to the list will immediately change the column layout in the Routes section. 

Create/Edit/Delete time interval(s): For details, please refer to 6.4.3.1. 

For Sorting & Filter options provided in the list of routing decisions and in the 

list of routes, please cf. section 6.4.4.5. 


For all subsequent actions the Routes mode needs to be active. 

Graphical 

selection 

Upon selection of the Routes mode, the elements are highlighted: 

► routing decisions are shown in dark red 

► destination cross sections of all routing decisions are shown in dark 

green (whereas each parking lot is surrounded by a blue frame). 

Selection of a routing decision (optional, cf. Info box below): 

1. Left-click the link where the routing decision is located, 

2. Left-click the routing decision: 

- The selected routing decision is displayed in light red and 

- only the corresponding destination cross sections (dark green) or 

parking lots (solid blue) remain visible. 

Selection of a route starting from the selected routing decision: 

1. Left-click the link where the destination cross section is located, 

2. Left-click the destination cross section: 

- The selected destination cross section is displayed in light green, 

- the route is displayed as a yellow band. 

Since VISSIM 4.30-03, a route of the type static, partial route or closure 

can be selected without selection of the routing decision cross-section: 

left-click the destination link first and the destination cross-section then. 


Selection 

in the 

Routes 

window 

Delete 


To open the Routes window for display of 

► all routes and routing decisions in the network: Right-click outside of 

the VISSIM network. 

If a routing decision is currently highlighted, the appropriate Routing 

decision type tab will open and its routes will be listed in the Route List. 

► only the routes starting from a certain routing decision: Double-click on 

that routing decision. 

If a route is currently displayed as a yellow band, the appropriate Route 

decision type tab will open and the selected route will appear blueshaded 

in the Route List. 

Alternatively, a route´s destination cross section can be double-clicked. 

All routes of those routing decisions being selected in a Routing decisions 

tab are listed in the particular Route List. 

All routes being selected in the Route List are automatically highlighted as 

yellow bands in the network display. 

► To select a single route or routing decision in the list, click in the grey 

cell to the left of the particular line. The previously selected route or 

routing decision is automatically deselected. 

► To (de)select multiple routes or routing decisions, press CTRL or SHIFT 


► SELECT ALL via context menu. 

Routing decisions and routes of the type static, partial route or closure: As 

soon as a decision is selected in the list, not only the particular routes are 

listed but the one on top of the list will be selected, too, and highlighted as 

a yellow band on screen. 

For display of a Parking lot type route as a yellow band, the route has to be 

selected in the Route List, since clicking a destination parking lot (solid 

blue) will delete the route to this parking lot. Toggle functionality: Click the 

parking lot (blue frame) again to restore the route. 

► In the Routes window, select one or several routing decisions or routes 

and continue as follows: 

- Either press DEL 

- Or click DELETE in the context menu. 

► In the network, select a routing decision or route destination and 

continue as follows: 

- Either press DEL 

- Or drag the cross section bar out of its link/connector into the 

network while holding down left mouse-key. 

With a routing decision, all of its routes are deleted. 



Shift 

position 

Edit route 

alignment 

Edit 

listed data 

► In the Routes window, edit the At property of the decision or destination 

cross section. The particular link number is not subject to changes in 

the lists. 

► In the network, drag the selected routing decision (or destination cross 

section) to another position on the same link or to any other link while 

holding down left mouse-key. 

A yellow band represents the current route alignment (link/connector 

sequence). It can be changed by using intermediate points to drag part of 

the route on a different link/connector. In contrast to intermediate points of 

links and connectors, for routes these are temporary only. 

A single right mouse button click on the yellow band creates a temporary 

intermediate point. This point can then be dragged onto another link using 

the left mouse button. VISSIM then calculates a new link sequence via the 

new intermediate point and any existing intermediate points. Intermediate 

points can be removed by dragging them onto another point. This also 

causes VISSIM to recalculate the link sequence. 

A single left click outside the yellow band accepts the currently shown link 

sequence, thus completing the modification of the route alignment. 

To each of the lists in the Routes window, the following applies: 

► A context menu can be called by right-click. 

The following functionality is provided: 

- DELETE removes the selected row, 

- COPY/PASTE for data exchange, e.g. to/from *.XLS or *.DOC files. 

- ZOOM changes network display scale and section to show all 

network elements being currently selected in the list, 

- SELECT ALL selects all of the listed routes or routing decisions. 

Additionally the CHECK command can be clicked for selected routes. In 

case of errors, a detailled message appears. 

► Editable properties can be edited directly in selected cells. 


Combine 

static 

routes 


For static routes ending on a link where another static routing decision is 

located, the combination of those routes can be triggered as follows: 

1. Click on the routing decision 

2. Click menu EDIT - COMBINE STATIC ROUTES 

All routes starting from this decision are appended to all routes ending 

upstream of this routing decision on the same link. This includes the 

following steps: 

► Deleting the selected routing decision and all destination cross-sections 

originally ending upstream of this decision. 

► Forming the maximum number of new routes from each routing 

decision originally leading to the deleted decision cross-section to each 

destination cross-section of the deleted routing decision. 

► Distributing the given total relative volumes to the resulting routes. 

Only static routes and routing decisions with identical time intervals and 

identical vehicle class selection can be combined. 

All routes that can be combined are highlighted in the network and a 

confirmation message box appears. In the Routes list, this max. number of 

routes can be reduced by the user (DELETE). 

Example Combining static routes will change data accordingly: 

From the example settings in the Routes window the elements placed on 

link 180 can be seen: 

► The common destination cross-section of 3 routing decisions (no. 22, 

24, 26) 

► The routing decision (no. 33) with 2 routes starting from it. 



COMBINE ROUTES creates six new routes: 

► They start from the original three 

decisions 22, 24, 26. 

► They lead to the original destinations 

of the two routes that started from the 

deleted decision. 






Routes 

window 

For a new routing decision on the selected link, the following properties 

have to be set, cf. section 6.4.4.1: 

● No.: Unique identification of the routing decision 


● At: Position on the link/connector. 

● Type: Select the appropriate option. 

(Static, Partial, Parking, Dynamic, Closures; Managed Lanes) 

The type is not subject to subsequent changes. 

● Show only routes over link: If this option has been checked, you can 

select the link that serves as a route filter for route list display. 

[STATIC] For a static routing decision, define in the Routes window: 

● Vehicle Class(es): From a drowp-down list, select the vehicle classes to 

be affected by this routing decision (PT routes are defined separately in 

the PT Lines mode, cf. section 6.5). For multi-selection, press CTRL 

while clicking the left mouse button. 

● Show Label: When showing labels (names) of all routing decisions 

(cf. VIEW - NETWORK ELEMENTS...) this option allows to individually switch 

off the label of that routing decision. 

Editable properties of a static route: 

● Route no.: Unique identification of the route. 

● Dest. Link: Unique identification of the destination link. 

● At: Link/connector coordinate. 

● The relative flow value by route and time interval. 

Relative Flows: Instead of absolute vehicle flows VISSIM uses relative 

flows to determine the proportions among all route destinations of one 

routing decision. This characteristic allows that either real flow volumes or 

percentages can be entered. Internally VISSIM adds up all these relative 

flows and computes the absolute percentage for each flow automatically. 



No vehicles will be taken out of or added to the network automatically in 

order to match the relative flows of a route with the absolute flows (e. g. 

counted turning proportions of subsequent junctions in most cases do not 

match). The user is responsible for consistent flow data in order to replicate 

the real condition. 

[PARTIAL] This tab page is relevant only for Partial routing decisions and routes. 

For Partial routing decisions and routes the same properties have to be set 

as for static ones. 

[PARKING] This tab page is relevant only for Parking lot type routing decisions and 

routes (only for parking lots of type Real parking spaces, cf. section 6.4.5). 

► For routing decisions of the Parking lot type, the same properties have 

to be set as for static ones. 

► For routes of the Parking lot type, the data is arranged in two tabs: 

- [ROUTING] with Decision no. and Parking lot no. 

- [PARKING RATE & DURATION], cf. section 6.4.5.2. 



A vehicle to which a parking facility of the Parking type has been assigend 

by a routing decision uses an automatically generated route to reach this 

destination. It will stay there as long as preset by the dwell time distribution. 

This dwell time distribution is allocated by time in the routing decision. Once 

the dwell time has elapsed the vehicle again uses an automatically 

generated route to reach the position behind the routing decision in the 

original route as soon as possible. 

[DYNAMIC] This tab page is relevant only for routing decisions and routes of the 

Dynamic type for Dynamic Assignment (parking lots of the Abstract parking 

lot type or Zone connector type, cf. section 6.4.5). 

► For routing decisions of the Dynamic type, the same properties have to 

be set as for static ones. 

► For routes of the Dynamic type, cf. section 12.7.5 for details. 

The dynamic routing decision should not be placed on an edge at which a 

parking lot is located that cannot be passed. 



[CLOSURES] This tab page is relevant only for Closures in Dynamic Assignment, 

cf. section 12.8.4. 

[MANAGED 

LANES] 

Except the Vehicle Class(es) property, the same properties have to be set 

for Closures as for static routing decisions. 

For route Closures, neither time intervals nor flow values are required. 

Additionally to the common properties of routing decisions, for a managed 

lane routing decision please select from the predefined selection list: 

● Vehicle class(es): Only types of the selected class(es) will be regarded. 

Vehicles of other types will use neither the managed route nor the 

general purpose route. 

● Managed Lane facility: Click EDIT for selection from the facilities 

predefined via menu TRAFFIC - MANAGES LANE FACILITIES. This way, a 

pricing model as well as a decision model is allocated to the routing 

decision, cf. section 5.6.1. 

For routing decisions of the Managed lane type, time intervals can be 

defined with the pricing model. 



For each route pair of a managed lane routing decision, define the following 

in the Routes list: 

● Route Type: From a drowp-down list, select either General Purpose 

Route or Managed Route. 

● At: Position on the selected destination link. 

6.4.4.5 Sorting & Filtering Data in Lists 

Sorting In the lists, the direction of the little triangle in the currently selected column 

header indicates either ascending or descending order of listed entries. 

Click in the column header to change the current order. 

Filter icons Use the Filter functionality to reduce the number of list entries. 

In the following columns, the options All (no filter) and Custom (userdefined 

filter conditions) are provided; alternatively, one of the entries can 

be selected from the list: 

► For Route decisions: 

- Decision no. 

- Decision name 

- Start link no. 

- Vehicle class(es), (does not apply to Closures). 

► For Routes (Static, Partial and Closures): 

- Route no. 

- Route type 

- Destination link no. 

For parking lots and dynamic routes, specific properties serve as filter 

criteria. 


Click on the filter 

icon in the column 

header and select 

one of the entries 

from the selection 

list. 

► The filter icon 

remains grey if 

All is selected. 

► Active filters are 

indicated by a 

blue filter icon. 

For user-defined filter settings, select option Custom via Filter icon. 

The window Enter filter criteria for appears: 


This third-party module allows for column-specific definition of filter 

conditions connected by AND or OR: 

● ADD CONDITION adds another line: Select Operator and Operand. 

● DELETE CONDITION removes the selected line: Select the line by clicking 

on the button to the left of the entry line. 

● AND conditions / OR conditions: The selected option regards all of the 

current filter settings. 



Filter 

option 

Additionally, the Routes section provides option Show only routes over link: 

► Check this option and 

► Select one of the VISSIM network links from the list. 

Then only those routes will be listed in the Routes section which traverse 

this link. Simultaneously, they will be highlighted in the network display. 

6.4.4.6 How Routing Decisions Come Into Action 

Routes 

in general 

Partial 

Routes 

During the simulation each vehicle that passes a routing decision point is 

assigned a specific route unless it already has a route assigned to it. The 

stochastic distribution onto multiple routes at a single routing decision point 

is based on a Monte Carlo methodology; in other words the percentage of 

vehicles on each route corresponds directly to the routes’ designated 

relative flow volume. A vehicle that is assigned to a specific route chooses 

its travel lane on multiple lane roadways independently so that it can reach 

the next connector along its route. As soon as it reaches a certain range 

defined as Lane change parameter of the next downstream connector that 

is included in its route, it tries to change to a lane that leads to this 

connector. From this point the vehicle will not change to a lane not leading 

to the connector for the purpose of passing a slower vehicle except when it 

approaches a PT vehicle that stops. 

In the 2D mode, a lane change is indicated by a short red bar at the front of 

the vehicle (indicator) and in the 3D model as a flashing indicator (if it is 

defined in the 3D model). 

Vehicles on the destination travel lane of the indicating vehicle will cooperate 

in allowing the vehicle to change lanes according to their driving 

behavior parameters (cf. section 5.4.3). 

A routing decision needs to be placed well in advance of the point where 

the routes divide into different directions. This is to allow the vehicle to react 

to its new destination. In addition, for multi-lane links it is to avoid unrealistic 

queues due to the fact that at a routing decision all vehicles will get routing 

information and thus more weaving might appear in the simulation than in 

reality. As a rule-of-thumb, the routing decision should be placed further upstream 

than the longest queue expected on that link (but - of course - 

downstream of the end of all previous routes). 

For example, partial routes can be used to model route diversion caused by 

variable message signs (VMS) without the need to change each individual 

route that passes the section where the VMS is active. Instead simply one 

partial routing decision with two routes (if there are two alternative routes 

possible) and the desired proportions of traffic assigned to these partial 

routes need to be defined. 

Recommended placement 

When a sequence of routing decisions is used (e.g. modeling turning movements 

for each junction separately) it is important to remember that a vehicle 



will disregard any routing decisions while it still travels on a previous one. For 

a vehicle to successfully move from one route to another, the start of the 

second route must be placed downstream of the previous one. 

An easy way to accomplish this is to place all green sections of a route on 

the first connector (or similar position on a link) after the last decision point 

for that route. By placing all red sections (routing decisions) always on a link 

after the junction (after all connectors ended) it is ensured that all previous 

routes ended prior to the start of the next one (see illustration below). 

As with any decision point the routing decision affects a vehicle only the 

time step after it has crossed the decision point. Therefore, the distance 

between a routing decision point and the first connector should be, at a 

minimum, equal to the distance a vehicle travels with the highest desired 

speed within one time step. 

Vehicles assigned to a specific route and waiting for a gap to merge will be 

removed from the network after a waiting period of 60 seconds to avoid 

unrealistic backups. The assumption is that in reality those vehicles would 

have forced their way into the flow. 

The default value of 60 seconds can be changed in the driving behavior 

parameter set (cf. section 5.4). 

If VISSIM cannot find a connection between the routing decision point (red 

bar) and the destination point (green bar) usually a connector is missing. 

In this case double-check the desired link sequence using the Center line 

viewing mode (VIEW – CENTER LINE or default hotkey CTRL+A). 



Managed 

Lanes 

During the simulation start, VISSIM checks for partial routes and managed 

lane routes whether all destination cross sections starting from the same 

start cross section have the identical position on the identical destination 

link. If not so, the destination link number and the position (at [m]) of the 

route having the smallest route number will be used for any other partial 

route or managed lane route starting from this decision cross section. 

During a simulation, routing decisions of the managed lanes type do only 

control the route choice of those vehicles which are already either on a 

static route or on one of the two routes starting from a routing decision of 

the managed lanes type. Vehicles on dynamic assignment paths are not 

regarded by those routing decisions. 

The managed part of a highway we call a separate road built in parallel to 

the normal - unmanaged part of the - highway. Normally, the managed part 

of the highway is equipped with numerous feeders for access and egress of 

vehicles. Routing decisions of the managed lanes type serve for modeling 

the so-called “part-distance“ use of managed and unmanaged sections of 

those roads built in parallel. 



Placing a routing decision of the Managed lanes type 

When defnining a routing decision of the managed lanes type, follow the 

outlined steps. Place 

► on the unmanaged part of the highway: a decision before each feeder 

from the unmanaged to the managed part of the highway which are in 

parallel. For each of these decisions, place the destination behind the 

nearest possible exit from the managed part towards the unmanaged 

part. 

► on the managed part of the highway: a decision before each feeder 

from the managed part of the highway to the unmanaged part of the 

highway. The destinations for each of these decisions place behind the 

nearest possible exit from the managed to the unmanaged part on the 

unmanaged part of the highway. 

When passing a routing decision of the type Managed lanes for the first 

time, a vehicle receives a random number indicating the probability for 

changing to the managed lane. The vehicle will use this random number for 

any other routing decision of the type Managed lanes. This way it can be 

guaranteed, that only in case of heavily changing traffic conditions the 

vehicle might change its initial decision. 

Two routing decisions of the managed lanes type should use the same 

Managed Lane Facility only if the following applies: 

► The courses of the unmanaged routes starting from these decisions are 

closed to identical. 

► The courses of the managed routes starting from these decisions are 

closed to identical, too. 

Graphical display of a routing decision of the Managed lanes type 

Via menu VIEW - NETWORK ELEMENTS open the Display of Network Elements 

window and 

► check option Routing decision and 

► select Managed Lanes Data in the Label column. 

Then, the network display on screen will show 

► the number of the decision of the Managed lanes type, 

► current travel time savings and speed on the managed lane and 

► the current road toll charged for user group 1 Person (SOV). 

Evaluations regarding routing decisions of the Managed lanes type 

Via menu EVALUATION - FILES you can check the Managed Lanes option to 

generate the evaluation file *.MLE (Managed Lanes Evaluation) during the 

next simulation run. 

6.4.5 Parking Lots 

Basically, the network element Parking lot is used for two completely 

different purposes: 



1. For the use of static routes: Modeling roadside parking and pick-up/dropoff 

lanes. 

2. For Dynamic Assignment: Modeling origins and destinations of trips. 

This section explains the functionality of roadside parking and the definition 

of parking lots in general. The usage in combination with Dynamic Assignment 

is described in section 12.3.1. 

6.4.5.1 Roadside Parking Functionality 

For modeling intermediate stops of a certain duration, parking lots of the type 

Real parking spaces and routing decisions of the type Parking lot are 

combined. These routing decisions work similar to partial routes. To a routing 

decision of the type Parking lot, no routes are assigned, but any number of 

parking lots. Also the dwell time distribution and the percentage of vehicles 

that should park in one of the associated parking lots needs to be defined. 

Parking Lot Placement 

A parking lot is placed on a lane. If that lane does not continue downstream 

of the parking lot, take care that the emergency stop position of the first 

downstream connector does not include any part of the parking lot (for 

details about the emergency stop position please refer to section 6.3.2.2). 

The start of a parking lot needs to be placed well downstream of the 

corresponding routing decision so that any vehicle can slow down safely to 

reach the first parking space. Otherwise it might happen that no vehicle will 

be assigned to the first parking space(s) or that vehicles will miss their 

assigned space and block the traffic flow. 

Parking Space Allocation 

Parking space is allocated through a routing decision of the type Parking Lot. 

It affects all vehicles of the assigned vehicle classes, also public transport 

vehicles. The only exception are vehicles that already have a parking space 

assigned. 

For assignment of parking lots or parking spaces the following criteria are 

relevant: 

► Open hours 

► Max. parking time 

► Available space(s) (suitable for the vehicle length) 

► Attractiveness 

A parking space is only assigned, if the parking lot is open (Opening hours), 

the vehicle dwell time (assigned by the routing decision) is less than the Max. 

Parking Time and if a suitable space is available (see below). If any of these 

criteria is not met, the vehicle continues on its route without parking. 

If all the above criteria are met, the vehicle is assigned to the best parking 

space available when crossing the corresponding routing decision. The best 



space is determined by attraction value. If two or more spaces have the 

same attraction, the first space in direction of flow is assigned. 

Finding a Suitable Space 

A vehicle fits into one parking space if the space is more than 0.5m longer 

than the vehicle. If the vehicle is longer, VISSIM checks if two or more 

consecutive spaces are available to accomodate the vehicle. However, 

partially occupied spaces will not be assigned to other vehicles (i.e. a vehicle 

will always stop at the front of a parking space). If consecutive spaces are 

not available, the long vehicle will not park and continue on its route. 

Parking Behavior on Multi-lane Parking Lot Links 

A vehicle decides to use a parking space only if either condition is met: 

► The parking space is not occupied by a parking vehicle. 

► The neighbouring parking space on the driver´s side is not occupied 

either. 

If the chosen parking space is still empty when crossing the decision cross 

section, but will be occupied right before the car arrives, then the car selects 

another parking space. Therefore, at least a single empty parking space is 

required (on the route of the parking lot decision) in with-flow direction. 

Entering and Leaving the Parking Space 

VISSIM automatically creates routes from the routing decision to each 

parking space of the associated parking lots. These routes cannot be edited 

by the user. As soon as a vehicle is assigned to a parking space, it follows 

on the corresponding route until standstill. The inside of the vehicle turns 

white once it has reached its final park position. After the dwell time is over, 

the vehicle leaves the parking space on an automatically created route that 

leads back to its original route. 

VISSIM looks for the shortest path in terms of time to get to a position 

behind the parking lot routing decision. Both, the current position of the 

vehicle as well as its entire initial route are taken into consideration. 

Thus a vehicle may travel a portion of its route twice or skip a portion of its 

original route. 


This section refers to both roadside parking and Dynamic Assignment. 

A parking lot is defined as follows: 

1. Select the Parking Lots mode. 

2. Select the desired link/connector. 

3. Define the parking lot: Right click at the start position and drag the 

mouse downstream to define the length. 



4. Once the properties and options have been specified in the Create 

parking lot window, confirm OK. 


[DYNAMIC 

ASSIGNMENT] 

This section refers to both roadside parking and Dynamic Assignment. 

Double-clicking a parking lot calls the Edit parking lot window. 

● No.: Unique 

identification of 

the parking lot. 

● Name: 

Optional label 

or comment 

● At: 

Link/connector 

coordinate of 

the destination 

(green bar). 

● Length: Total 

length of the 

parking lot 

● Type: 

- Zone connector: 

- Abstract parking lot: 

Both types refer to Dynamic Assignment, cf. section 12.3.1 

- Real parking spaces: Modeled parking capacity with user-definable 

length of the car-parking spaces on a lane in with-flow direction. 

Combining parking lots of the type Real parking spaces and routes of 

the type Parking lot allows for realistic modeling of parking and 

halting events at the road side. 

● Label: When showing labels (names) of all parking lots (cf. VIEW - 


label of that parking lot. 

These properties are regarded by Dynamic Assignment, cf. section 12.3.1. 


[PARKING 

SPACES] 

[SELECTION 

PARAMETERS] 


Only relevant to parking lots of the Real 

parking spaces type: 

● Lane: Reference lane number for the 

Location property. 

● Location (only provided when creating 

a parking lot, no subject to changes): 

- on existing lane: The parking lot 

is created on the selected 

existing lane. 

- on new lane added to the 

right/left: A new lane is created 

on the appropriate side of the 

link/lane and the parking lot is 

placed on it. 

● Length of each space: Length 

If the length total differs from the length resulting from the number of 

parking spaces (which is automatically calculated) multiplied by the 

Length of each space, then the remaining length difference will be placed 

at the end of the parking lot in direction of flow. This section will not be 

used by parking vehicles. 

● Open hours: Time interval of availability 

of the parking capacity; vehicles 

will use this parking lot only during 

opening hours and will not drive 

there before or after. 

● Maximum parking time: 

- Type Real parking spaces: 

vehicles having a longer dwell 

time will not use this parking lot. 

- Types Zone connector / Abstract 

parking lot (only relevant if a trip 

chain file is used): Time span, a 

vehicle may use this parking lot. 

The parking lot is not used by a 

vehicle, if minimum dwell time 

exceeds max. parking time. 

● Attraction: The higher the value the more attractive is the parking space. 

Thus any parking lot feature can be modeled which is not explicitly provided 

as a property in VISSIM. 

For Real parking spaces a First: and a Last: value have to be entered. 

In case of identical values, all spaces provided by this parking lot are of 

the same level of attractiveness. In case of different values, the 

attractiveness of the spaces located in a row will increase/decrease 

accordingly (linear function). To model a parking lot with the most 

attractive spaces located either in the middle of the parking lot or - also in 



a symmetric manner - to the right and to the left of e.g. the elevator, two 

parking lots of the Real parking spaces type have to be created with 

inverse Attraction values for First and Last. 

● Parking fee (only relevant for Zone connector / Abstract parking lot): 

- flat: charged for parking not regarding the dwell time. 

- per hour: charged per parking hour, thus the vehicle´s dwell time is 

taken into regard. If trip chains are used, the minimum dwell time will 

be regarded. Otherwise parking is supposed to last one hour. 


For all subsequent actions the Parking Lots mode needs to be active. 

Upon selection of the 

by a dark-blue frame: 

Parking Lots mode, the parking lots are highlighted 

Select You can select a parking lot either in the list or in the network display: 

► Right-click outside of the VISSIM network calls the Parking lots selection 

list: Left-click to select the parking lot, then click DELETE or ZOOM or DATA. 

► In the network display: Click parking lot (dark-blue): The polygon turns 

light-blue. 

Edit data 

Move 

Delete 

► In the network display: Double-click to call the Edit parking lot window 

for the selected parking lot. 

► In the selection list: Select the parking lot, then click DATA. 

► In the Edit parking lot window you can enter different At and Length 

values. Link number and world coordinates are not subject to changes. 

► In the network display: Drag the selected parking lot to another position 

within the same link or into another link/connector while holding down 

left mouse-key. The polygon turns yellow. 

► In the selection list: Select the parking lot and click DELETE. 

► In the network display: Select the parking lot and click DEL. 

Alternatively, you can drag the selected parking lot out of its link or 

connector. 

6.4.6 Direction Decisions 

Direction decisions should not be used as their handling is more difficult than 

the handling of routes. Direction decisions remain from out-dated VISSIM 

versions without routing decisions. 

Definition 

To define a direction decision, take the following steps: 

1. Select the Direction Decision mode. If it is not in the network elements 

toolbar, you can add it to the toolbar using the CUSTOMIZE function. 



2. Select a link with a single left button mouse click. 

3. Select the desired location for the direction decision point on the selected 

link with a single right button mouse click. The Create Direction Decision 



4. Select the desired 

direction of this decision 

point (Desired 

Direction). 

5. Select the class(es) 

of vehicles to be 

affected by the 

direction decision 

(Vehicle Classes). 

6. Define the percentage 

of vehicles to be 

affected by the direction 

decision (Rate). 

Example: An input of 1.000 results in all vehicles of the selected type 

being affected by the direction decision, while an input of 0.100 only 

affects 10% of the vehicles. 

7. In addition, a time period can be specified for which the direction decision 

is to be effective. 

8. Having completed the parameter settings, click OK. The location of the 

direction decision point will be indicated on the link. The appearance of 

the direction decision will be one of the following: 

Symbol Meaning 

Blue arrow Direction decision to the right or left (effective at the next 

connector specified as ‘right’ or ‘left’) 

Blue line Annihilation of all effective direction decisions 

Green arrow Direction decision to change lanes 

Green line Direction decision to stay in the current lane 

Example 

DIRECTION DECISION LEFT AT 600 M RATE 30 %; 

DIRECTION DECISION RIGHT AT 601 M RATE 20 %. 

As a result of these two direction decisions, 20% of the vehicles will turn right 

at the next intersection, 24% will turn left and 56% will continue through the 

intersection. This is because 30% have been originally assigned with a left 

turn decision, then 20% of all vehicles (including those which have already a 



routing decision!) are affected by the second direction decision and thus the 

percentage of left-turn vehicles will be reduced by 20%. 

A direction decision becomes effective the time step after the vehicle has 

passed the decision point; thus the distance between decision point and 

the next following connector should be sufficient. The minimum distance 

depends on the speed of the fastest vehicles. If the fastest vehicle is 

traveling with a speed of 20 meters per second, the minimum distance 

between direction decision point and connector is 20 meters if the model is 

running at one time step per simulation second. 

On a multiple lane section vehicles with an assigned direction decision ‘left’ 

will use the leftmost lane while vehicles with an assigned direction decision 

‘right’ will move to the far right lane 

A direction decision can affect all vehicles that have not been assigned to a 

route. If a vehicle with an assigned direction decision passes another 

direction decision point and gets a new direction decision assigned to, then 

the new decision overwrites the previous one (see example above). 

A vehicle’s direction decision is only reset when passing a connector with 

the appropriate direction setting. Otherwise it keeps the direction decision 

until it leaves the network, gets a new direction assignment or passes a 

direction decision with the ‘none’ criteria. 

Setting the desired direction to “none” resets the direction decision for 

vehicles affected by that decision point. 

6.4.7 Routing Decisions versus Direction Decisions 

Routes do have several advantages compared to direction decisions. Thus it 

is recommended always to use routing decisions. 

► While direction decisions only affect a single lane, routes capture traffic 

on all lanes, thus reducing coding effort. 

► Routes do not require the cumbersome calculation of turning 

percentages when the traffic flow is distributed between more than two 

directions. 

► Modeling traffic flow with routing decisions guaranties an accurate 

replication of merge situations. In contrast to turning decisions, routing 

decisions force vehicles to follow predefined link sequences, even if that 

means waiting at a connector for a gap to merge. Vehicles that have 

been assigned a direction decision would just continue if they cannot find 

a gap to merge, requiring the use of special “tricks” for realistic modeling. 

► Routes allow for accurate modeling of traffic flow through multiple 

intersections and turning decisions. This is in contrast to modeling with 

turning decisions where the origin of vehicles is forgotten after each 



turning movement. As a consequence, modeling with routing decisions is 

required, for example, when simulating a double-diamond freeway 

interchange where weaving between multiple traffic streams occurs 

between the two signalized intersections. 

► The modeling of roundabouts also requires routing decisions. With 

direction decisions there always would be some vehicles circulating 

within the roundabout. 



6.5 Public Transport 

Public transport vehicles can operate in mixed traffic as well as on dedicated 

roads or tracks. They are defined separately from all other traffic. 

Data input for public transport requires two steps: 

► Step 1: Creating PT stops. 

► Step 2: Creating a PT line including route, served stops, PT vehicle and 

schedules. 

6.5.1 PT Stops 

PT stops can be created on a link or next to it. There are two types of PT 

stops: 

► On Street stop (curbside stop): A PT vehicle stops on a user-defined 

travel lane of the selected link. 

► Bus Lay-by (turnout): A PT vehicle stops on a special link next to the 

slow lane of the selected link. 

Vehicles approaching a PT vehicle that stops for passenger interchange will 

attempt to pass it on a multiple lane link, but will wait behind the PT vehicle 

on a single lane link. By default, a bus leaving a lay-by will have the right-ofway 

(appropriate priority rules forcing following vehicles to yield for the PT 

vehicle are coded automatically). Deleting the priority rule for the bus priority 

changes this behavior. 


Prior to the definition of a PT stop, at least one dwell time distribution needs 

to be defined (cf. section 5.2.6) except when dwell time calculation is used 

(cf. section 6.5.2 for details). 

1. Select the PT stops mode. 

2. Select the link/connector on (or adjacent to) which the PT stop should be 

placed (a lay-by stop can only be placed on a link, not on a connector). 

3. Create the stop by right clicking at its start position (inside the 

link/connector) and dragging the mouse along the link/connector while 

the right button is held down. Thus the length of the stop is defined (it is 

displayed in the middle section of the status bar). 

4. Release the mouse button. The Create PT Stop window appears. 

5. Define the stop properties (as shown in the next section) and confirm 

with Ok. 


Public Transport 

It is possible to create a stop where more than one PT vehicle can have 

passenger interchange at the same time. In order to do so, the stop must 

be long enough to accommodate the total length of all vehicles plus 

sufficient headway ahead of, between and behind each vehicle. 

On a multi-lane link it is possible for PT vehicles to turn out behind another 

stopping vehicle or to turn into a stop ahead of another vehicle if there is 

enough space left to accommodate it completely. 

If the stop is placed on a single lane link (e.g. a lay-by), a following vehicle 

cannot leave before the preceding vehicle. 



stop. 


● Length: Length of PT stop 

● Lane: Lane position of PT stop 

● At: Start position (link/connector 

coordinate) 

● Label: When showing labels 

(names) of all PT stops (cf. VIEW - 

NETWORK ELEMENTS...) this option 

allows to individually switch off the 

label of that stop. 

● Type: Defines the placement of the stop: 

- Street (= curbside stop): Directly on the selected link and lane. 

- Lay-by (= bus turnout): Adjacent to the slow lane of the selected link. 

For this purpose a new link with two connectors is created 

automatically and the stop is placed on the new link. Furthermore two 

pairs of priority rules are created in order to model the right-of-way 

for the PT vehicle to turn back on the main road. 

● Generate platform edge: Optionally, area(s) of the polygon type serving 

as a platform edge can be created additionally for either type of stop. An 

automatically created platform edge follows the user-defined link course. 

With a width of 2m it is placed directly next to the PT stop. Select the 

appropriate position(s) due to the direction of traffic. 

The options left and right can be checked simultaneously, if 

passengers may board/alight on both sides. 

Subsequent changes to the properties of the pedestrian area are not 

necessary, since all area attributes are set automatically. The area name 

contains stop number and side (Platform edge PT stop No. (side)) and 

will not automatically be adjusted if the platform edge area is allocated to 

another stop later on. 



If a platform edge is created, the Volume [Pers/h] term in the Boarding 

Passengers windows will change to Relative volume. Any stop with an area 

defined for PT usage is used by passengers that have been generated as 

pedestrians. To the PT lines, these passengers are distributed as 

percentages. 

Without the Pedestrians add-on and as well-known from previous VISSIM 

versions, passenger volumes are distributed exactly according to the given 

volume numbers per PT stop. 

As a property of a pedestrian area, the usage as a platform edge or as a 

waiting area for one or more selected PT stops can be defined, cf. section 

7.1.4. The shape of this platform edge is given by the pedestrian area 

polygon which is to be defined manually by the user. 

A pedestrian area which is automatically created as a platform edge due to 

this option, always follows the course of the particular section of the link on 

which the PT stop has been placed. The width of an automatically created 

pedestrian area is 2 m by default. 

● PASSENGERS... (only for use with 

dwell time calculation): Opens the 

Boarding Passengers window which 

allows for definition of a passenger 

flow profile to wait for PT vehicles. 

Use the buttons EDIT, NEW or DELETE 

to modify the profile. 

A passenger profile contains the following 

information: 

- Volume: Passenger flow as persons per 

hour (independent of the time interval 

defined) 

- from/until: Time interval for which 

passengers are generated 

- Used PT Lines: Select all lines which 

passengers of this profile can use. 

Multiple lines can be selected by 

pressing CTRL while clicking. 



Relative flow volume definition for pedestrians using PT stops with platform 

edge: 

For passengers which have been defined as pedestrians of a pedestrian 

class, default data will be created in two cases: 

► If a pedestrian area (either waiting area or platform edge) is assigned 

to a PT stop for which no passenger volumes have been defined. 

► For each automatically created platform edge. 

According to the default data, any pedestrian arriving at the waiting area 

within the time interval 0 – 99999 will board any vehicle of any PT line. 

6.5.1.3 Editing For all subsequent actions the 

active. 

PT stops mode needs to be 

Upon selection of the 

dark-red frame: 

PT stops mode, the PT stops are highlighted by a 

Select You can select a PT stop either in the list or in the network display: 

► Right-click outside of the VISSIM network calls the PT Stops selection 

list: Left-click to select the stop, then click DELETE or ZOOM or DATA. 

► In the network display: Click stop (dark-red): The polygon turns light-red. 

Edit data 

Move 

► In the network display: Double-click to call the Edit PT stop window for 

the selected stop. 

► In the selection list: Select the stop, then click DATA. 

► In the Edit PT stop window you can enter different At, Length and Lane 

values. Link number and Type are not subject to changes. 

► In the network display: 

- A bus lay-by cannot be moved graphically 

- Drag the selected street stop to another position within the same 

link or into another link/connector while holding down left mousekey. 

The polygon turns light-blue. 



Delete 

► In the selection list: Select the stop and click DELETE. 

► In the network display: 

- Select the bus lay-by and press DEL. All connectors and priority 

rules are removed at the same time. 

- Select the street stop and click DEL. Alternatively, you can drag the 

selected stop out of its link or connector. 

6.5.2 PT Lines (Bus/Tram lines) 

A PT line consists of buses or light rail vehicles/trams serving a fixed 

sequence of PT stops according to a timetable. The stop times are 

determined by dwell time distributions or calculations of passenger service 

times. If a real-world PT line should operate on different routes, it has to be 

coded as multiple separate lines in the VISSIM network. 

PT lines are coded similarly as static routes except that PT lines do not 

distribute arriving vehicles but generate vehicles. 

PT vehicles follow the PT line route and remain in the VISSIM network 

even after the route finishes. Thus it is important to model PT lines as such 

as they end on an exiting link. Otherwise PT vehicles remain in the network 

and travel on undefined routes. 


Before coding a PT line, all PT stops should be created. 

It is recommended to start every PT line on a separate link that is 

dedicated to that line. Thus a “dummy stop” can be created to model a 

variation of arrival times and the sequence of vehicle arrivals of different PT 

lines can be modeled. 

PT line definition is a five step process. To initialize the process, activate the 

PT Lines mode. The next required action is shown in the status bar. To get 

back one step, left click outside the VISSIM network. 

1. Select the link for the start of the PT line. 

2. Right click anywhere inside the selected link to create the line start (a bar 

in highlighted red appears at the start of that link). 

3. Select the link/connector for the PT line destination. 

4. Right click on the location for the route destination point (green bar). 

If there is a valid connection between the red bar and the click position 

the link sequence is shown as a yellow band and the PT line window 

appears. Define the PT line data and confirm with OK. If the yellow band 

shows a route different from the desired one it can be modified later. 



If there is no consecutive sequence of links and connectors possible, 

VISSIM cannot suggest a route and thus neither the yellow band nor the 

PT line window appears. In that case either the destination link or 

destination location must be changed or any missing connectors be 

created. 

5. Include/exclude stops in the PT route as required and define their 

properties. 

To define another PT line, select the PT Lines mode again and repeat the 

steps 1 to 5. 


● No.: Unique identification 

of the PT line. 

● Name: Label or comment. 

● Vehicle type: Vehicle type 

running the PT line. 

● Desired Speed Distribution: 

Initial speed of the 

PT vehicle. 

● Time Offset: The time offset defines the amount of time PT vehicles enter 

the VISSIM network before their scheduled departure time at the first PT 

stop (as defined with START TIMES…). 

The idea is that the departure times of a real timetable are entered as the 

start times of the VISSIM PT line. Then Time Offset is defined as the 

time the vehicle travels until the first stop in the network plus the average 

passenger interchange time at this stop - hence resulting in a departure 

at the time defined as PT line start time. 

The resulting network entry time will be set to 0 for all start times that are 

less than Time Offset. 

If Time Offset is set to 0 the PT line vehicles enter the VISSIM network 

exactly at their defined start time. 

● Slack Time Fraction: The waiting time after passenger service as a 

fraction of the remaining time until scheduled departure (only relevant for 

those stops which have a departure time assigned). 

● Color: Color of the PT vehicle 



● START TIMES... Opens the 

Starting times window. The list 

can be edited using the buttons 

SERVICE RATE, NEW, EDIT and 

DELETE. Start times can be 

entered as individual runs 

(NEW...) as well as a SERVICE 

RATE... Both options can be 

mixed. Using a service rate, 

VISSIM creates multiple 

individual runs automatically. 

For more information on how to define a service rate see section below. 

Besides each starting time in the list the corresponding course number 

and occupancy are displayed. 

● PT TELEGR (relevant only for use of PT signal 

calling points): Opens the PT Telegram 

window for definition of data to be 

transmitted to traffic signal controllers at PT 

signal calling points. 

The telegrams are sent only if the option 

Line sends PT telegrams is checked. 

Every time a PT calling point is actuated, a 

telegram is sent using the data as defined 

within the window (PT line, Route, Priority, 

Tram Length, Manual Direction). 

SERVICE RATE 

To define multiple start times at one go, select SERVICE RATE in the Starting 

Times window of a PT line. 

● Starting Time: A service rate 

creates multiple starting times for 

the time interval Begin – End. The 

frequency is defined by Rate. 

● Course: Optionally, course information 

may be defined. A course 

identifies each starting time with a 

unique number and can be used 

e.g. for PT telegrams. 

To create course numbers define the First course number and the Step 

value by which the course number for each starting time should be 

increased. 

● Occupancy: Number of passengers that are in the PT vehicle when 

entering the VISSIM network. 

Course no. and Occupancy data is displayed in the list of all Starting Times. 



Accessing the PT line properties: 

► Activate the PT Lines mode 

► Open the PT Lines list (right-click outside of the VISSIM network) 

► Select the desired line 

► Click DATA 

6.5.2.4 PT Line Route Alignment 

How to visualize the route alignment of a PT line: 

► Open the PT Lines list (right-click outside of the VISSIM network) 

► Select the desired line 

► Click ZOOM 

► Close the list 


VISSIM initially activates all PT on-street stops (displayed in bright red) that 

are included in the highlighted route. Bus lay-bys are not automatically part 

of a new PT line. To include a lay-by in a PT line route while the yellow band 

is shown create an intermediate point by right clicking on the yellow band 

and drag that point onto the bus lay-by. In the same way other route 

modifications can be done. 

In order to not modify accidentally a previously adapted alignment it is 

necessary to use two more intermediate points as “pins” which enclose the 

section to be modified. Thus when dragging an intermediate point only that 

part of the route which is enclosed by the “pins” will be recalculated. 

Any stop of either type that is added after a line has been created will be 

inactive on all lines that pass it (the stop is shown in green). 

If a PT line should not service a specific stop it can be deactivated for that 

line (cf. section 6.5.2.5). 

6.5.2.5 PT Line-specific Stop Data 

The PT Line-specific stop data (PT Stop Data) can be accessed by doubleclicking 

a stop while the yellow band of a PT line is shown. 

The PT Stop Data window appears: 



● PT stop active: Allows to activate or deactivate a PT stop (for the 

current line only). A deactivated (= not served) PT stop is displayed as 

green. 

● Departure time offset: Option to define a schedule-based departure at 

this stop that will be used in addition to the passenger interchange time. 

The resulting departure time is calculated as follows: 

arrival simulation second + dwell time + 

max (0, 

( (PT line Start time + Departure time offset) 

- (arrival simulation second + dwell time)) 

• PT line Slack time fraction). 

In other words, if the scheduled departure time is later than the sum of 

arrival time + dwell time, then the PT vehicle will wait until the scheduled 

departure time is reached, if the slack time fraction is 1. In case of lower 

the slack time fraction values the vehicle departs proportionally before its 

scheduled departure time. 

If either the Slack time fraction or the Departure time offset is 0, then this 

schedule-based operation is inactive and the dwell time is determined 

according to the current settings in the Dwell time section. 

Section Dwell Time: 

Decide how the dwell time of the PT line vehicle is to be determined by stop 

event. 

As you can see from the image below, some of the PT stop parameters are 

regarded only by a micro-simulation. 

For a micro-simulation, pedestrian areas with Public transport usage (type 

Waiting area or Platform edge) need to be allocated to the PT stops, cf. 



● Minimum: 


If this option is active, the selected dwell time distribution is used to 

determine the minimum dwell time for pedestrian areas with Public 

transport usage. 

If this option is unchecked, the minimum dwell time = 0. 

PT vehicles do not depart earlier. They might depart later, since they do 

not depart until all of the alighting passengers have left the PT vehicle. 

This also applies if the minimum dwell time = 0. 

Additionally, you can check the option Late boarding possible for each 

PT line stop event. 

● Distribution: If this option is active, the selected dwell time distribution is 

used to determine the stop time or the minimum dwell time, if applicable. 

Note: In order to select this option, at least one dwell time distribution 

must be defined, cf. section 5.2.6. 

● Calculation: 

If this option is active, the stop time is determined from the number of 

boarding and alighting passengers according to the selected method, cf. 


For micro-simulations, the dwell time calculation regards the selected 

distribution and the number of boarding and alighting passengers, if the 

option Late boarding possible is checked. 

- For passengers available as vehicle type, the volume is defined in 

persons/hour by stop and line. 



- For passengers available as type of pedestrians, the volume is 

defined by relative flows. 

● Alighting percentage: If option Calculation has been selected, enter the 

percentage of passengers that alight at that stop. This value serves for 

volume-based dwell time calculation. 

No further calculation parameter settings required for pedestrians that have 

been defined as vehicle type. 

For users of the Pedestrian add-on, two more options are provided 

additionally for calculation: 

● Alighting composition: Select the appropriate composition of PT 

passengers from the list of compositions that were pre-defined via menu 

TRAFFIC – PEDESTRIAN COMPOSITIONS. Inside the PT vehicle, the 

pedestrian types are created according to selected composition and the 

user-defined percentage will be applied. 

● Alighting location: Select the appropriate distribution of alighting PT 

passengers from the list of distributions that were pre-defined via menu 

BASE DATA – DISTRIBUTIONS – LOCATION. Inside the PT vehicle, the 

pedestrians who want to alight at this stop, are distributed accordingly to 

the doors of the vehicle. 

● Alighting possible: Separately for Alighting and Boarding events, the 

option possible can be checked for either side (left/right) of the vehicle 

(due to door placement and use). 

An arrow in the PT vehicle footprint indicates the direction the PT line is 

heading to. 

● Late boarding possible: 

If this option is active, the minimum stop time is definitely kept and 

furthermore the vehicle will not depart until all boarding passengers are 

on-board. The doors are closed after three seconds without boarding or 

alighting events. 

This option has to be checked, if neither option Minimum is active nor a 

timetable is used. 

If this option is not active, minimum stop time = maximum stop time 

applies. 

- If slack time fraction = 0 applies, the vehicle will depart as son as the 

minimum dwell time is over. 

- If slack time fraction > 0 applies, the particular portion of the 

remaining time until the departure according to the timetable will be 

added to the stop dwell time, if the departure time has not yet come. 

To make sure, that the PT vehicle leaves precisely at the time of 

departure, if this option has not been checked, passengers can board the 

vehicle only until the doors start closing. 

Closing the doors takes three seconds. The doors also close if a 

passenger boarded the vehicle right before closing the doors has started. 



● Skipping possible: If this option is active, a PT stop is passed without 

stop event under certain circumstances: 

- If the dwell time is calculated: if there are no passengers who want to 

board or alight as the vehicle is within a distance of 50m in front of 

the stop. 

- If dwell time distributions are used: if the random dwell time results in 

a value less than 0.1 s. 

A lay-by is skipped completely only if it is composed of a single link which 

connects directly back to the link from which it originated. In case the 

network topology is more complex or the PT vehicle has already reached 

the lay-by link when passing the 50m threshold, it passes the stop 

without stopping. 

Skipped stops are logged in the vehicle protocol file with ID and dwell 

time 0. 

● Apply dwell time data to all lines on this stop: If this option is active, 

the current dwell time settings for the given PT line at the given PT stop 

are applied to all PT lines which serve this stop. 

Example: Setting the parameters for micro-simulation 

To reproduce the results gained in previous VISSIM versions, set the 

following parameters accordingly: 

Option Setting 

Minimum dwell time Not active 

Late boarding possible 

Slack time fraction As before 

Departure time offset As before 

6.5.2.6 Methods for PT Vehicle Dwell Time Calculation 

As mentioned in the Line-specific stop data section, there are several 

methods to model PT vehicle dwell times in VISSIM: 

► Option A: Dwell time distributions 

► Option B: Dwell time calculation using the advanced passenger model 

► Option C: If the station is simulated microscopically, the dwell time can 

be calculated as travel time between two platform edges, cf. section 

7.2.1 and section 7.7. 

Option A is much faster to define than option B but option B provides a 

means to model more accurate stopping behavior, e.g. possible clustering of 

vehicles of the same PT line due to lateness. 

Option A: Dwell Time Distributions 

To use option A, all dwell time distributions that can occur in the VISSIM 

network need to be defined beforehand (cf. section 5.2.6). Then for each 



stop (specific to each PT line) one of these dwell time distributions is to be 

assigned. 

Option B: Dwell Time Calculation (Advanced Passenger Model) 

To use the calculation of dwell times according to the advanced passenger 

model, the following data needs to be defined in the PT PARAMETERS... 

window by PT vehicle type (BASE DATA - VEHICLE TYPES... - EDIT - [SPECIAL] - PT 

PARAMETERS): 

● Alighting time: The average time it takes 

for one passenger to get off that vehicle 

(considering the number of doors, i.e. if 

one passenger needs 6s to alight and 

there are 3 doors, the alighting time to be 

entered is 2s.) 

● Boarding time: The time it takes for one 

passenger to board (considering the 

number of doors as described above). 

● The Total Dwell Time may be calculated 

by using either the Additive or the 

Maximum method. 

If there are exclusive (one-directional) doors then only the maximum out 

of the total passenger boarding and alighting time should be used, 

otherwise the sum of both. 

● Clearance time: The time needed for the vehicle to stop and to 

open/close the doors. 

● Capacity: The number of passengers the bus or tram can hold. If 

capacity is reached no more passengers can get on the vehicle. 

Other input data: 

► Initial occupancy of the PT vehicles (cf. Start Times in PT Line window) 

► Passenger flows for each PT stop (cf. section 6.5.1) 

► Alighting percentage and Skipping possible option in PT Stop Data 

window. 

Once all this data is provided, VISSIM calculates the dwell time of a PT 

vehicle at a stop as follows: 

1. Determine the number of alighting passengers (defined by the 

percentage of passengers on board that are alighting). 

2. Determine the number of boarding passengers (all waiting passengers 

whose list of acceptable lines include the line of this PT vehicle and 

taking into account its maximum capacity). 

3. Determine the time required for alighting (computed as the number of 

passengers alighting multiplied by the average alighting time). 

4. Determine the time required for boarding (computed as the number of 

passengers boarding multiplied by average boarding time). 

5. Determine the total passenger service time (computed as the sum of 

clearance time plus alighting time plus boarding time). 



6. If a departure time is defined for that stop, the PT vehicle remains at the 

stop (after completion of passenger service) for that portion of the 

remaining time until scheduled departure, which is defined by the slack 

time fraction. 

6.5.2.7 Variation of Arrival Times 

In reality, PT vehicles do not enter the simulated network section exactly 

according to schedule. Their network entry is randomly distributed around 

their scheduled time (e.g. ±1 min). In order to model this random arrival in 

VISSIM, follow the instructions below: 

1. Create a dummy link at the beginning of the PT route (typically on the 

dedicated link) and use the PT line number as link number, if possible. 

Make sure that the length is sufficient (50-100m due to vehicle length 

and speed) so that the PT vehicle can enter the network on this link and 

safely stop. Connect the dummy link to the link network. 

2. Create a dummy PT stop on the dummy link. It should start at 25 m or 

more and its length should exceed the PT vehicle length. For numbering, 

use the line number as stop number, too. This dummy stops makes it 

possible to model deviating times of arrival for PT lines which enter the 

VISSIM network. 

3. Include the dummy stop in the line oute and assign a dwell time 

distribution to the dummy stop. For example, a mean value of 60 

seconds and a standard deviation of 20 seconds could be chosen. The 

actual departure time at the dummy stop would then be normally 

distributed between 0 and 2 minutes (99% value). 

4. Consider the dwell delay at the dummy PT stop (average dwell time of 60 

sec) for all other scheduled departure times. 



6.6 Non-Signalized Intersections 

In VISSIM, non-signalized intersections as well as separating or joining links 

can be modeled by appropriate modeling techniques. In this section, these 

methods are described in detail. 

6.6.1 Priority Rules 

The right-of-way for non-signal-protected conflicting movements is modeled 

with priority rules. This applies to all situations where vehicles on different 

links/connectors should recognize each other. Vehicles within the same link 

will implicitly see each other, even if the link has multiple lanes. 

6.6.1.1 Principles 

Actually, conflict areas are recommended for modeling. If these do not 

return the expected results, the experienced user can model priority rules. 

If the Pedestrians add-on is included in your installation, then priority rules 

can also be defined for conflicting flows of pedestrians as well as for the 

interactions of pedestrians and vehicle flows, cf. section 7.1.5. 

A priority rule consists of 

► one stop line and 

► one or more conflict markers that are 

associated with the stop line. 

Depending on the current conditions at the 

conflict marker(s) the stop line allows 

vehicles to cross or not. 

The two main conditions to check at the 

conflict marker(s) are 

► minimum headway (distance) and 

► minimum gap time. 

As a rule of thumb, for free flow traffic on the 

main road the min. gap time is the relevant 

condition. For slow moving or queuing traffic 

on the main road the min. headway 

becomes the most relevant condition. 

conflict marker 

connector headway 

stop line 

conflict area 

The minimum headway is typically defined as the length of the conflict area. 

During the simulation the current headway is determined by the distance 

between the conflict marker (green bar) and the first vehicle approaching it. If 

any part of a vehicle is located on the green bar the resulting headway is 0m. 

Whenever the current headway is less than the minimum headway, the cor- 


headway 

relevant gap for min. gap time

Non-Signalized Intersections 

responding stop line (red bar) stops any approaching vehicle (similar as a 

red signal). 

The current gap time (during simulation) is determined every time step by 

the time an approaching vehicle will require to reach the conflict marker 

(green bar) - provided that it continues traveling at its current speed. A 

vehicle located on the green bar is not considered by the current gap time. If 

the current gap time is less than the entry (defined for the conflict marker) the 

corresponding stop line (red bar) stops any approaching vehicle (similar as a 

red signal). 

Example 


(headway = 10m) 

(gap time = 3.0s) 

stop line 

conflict area 

50 km/h 

(~ 14 m/s) 

10m 

49m 

The blue vehicle 

traveling on the main 

road at 50km/h (i.e. 

~14m/s) is 49m upstream 

of the conflict 

marker. The current 

gap time is 49m / 

14m/s = 3.5s. Thus 

the yellow vehicle 

(on the minor road) 

can still pass, 

because the min. 

gap time is set to 

3.0s. 


stop line 

conflict area 


10m 

28m 

The blue vehicle is 

now only 28m away 

from the conflict 

marker. The current 

gap time is 28m / 14 

m/s = 2s. Because 

the min. gap time is 

set to 3.0s the 

yellow vehicle must 

stop. 


stop line 

conflict area 

10m 

The blue vehicle 

has just passed the 

conflict marker. The 

current gap time is 

0s because the 

vehicle front has 

already passed the 

conflict marker. But 

because the min. 

headway is set to 

10m the yellow 

vehicle still needs to 

wait until the conflict 

area is cleared 

completely. 

In order for a vehicle not to stop at the stop line, the conditions of all 

corresponding conflict markers need to be satisfied (logical “AND” condition).


VISSIM supports multiple conflict markers (green bars) for each stop line 

(red bar). Thus multiple rules can be applied to the same stop line. 

Both the stop line and the conflict marker(s) can be defined for certain 

vehicle classes only. In addition, a maximum speed can be defined for 

vehicles on the major road: Then only vehicles that approach the conflict 

marker at a speed below the max. speed will be considered by the headway 

of the priority rule. 

Conflict markers and stop lines can be defined by lane or by link. Thus 

modeling can be simplified. However, for lane-specific parameters or 

different stop line positions, lane-specific stop lines and the appropriate 

number of markers need to be defined. 

Depending on the scenario to be modeled either the gap time or the headway 

can be of higher importance. Vehicles waiting for the chance to enter or 

cross a flow of higher priority usually regard the gap time. On the other hand, 

the headway is used to find out, if a vehicle of higher priority has already 

reached a certain position. 

Additionally the relevance depends 

on the flow on the link where the 

conflict marker is located. 

In case of normal traffic flows, the 

gap time is the relevant parameter, 

whereas the headway is decisive in 

case of bumper-to-bumper traffic and 

congestions. 

For a selected priority rule, min. 

headway > 0 is displayed by a green 

triangle indicating the direction of 

traffic at the given position on the 

link. 

The conflict marker recognizes vehicles on all connectors that enter the 

link before the position where the conflict marker is located. This behavior 

causes problems if the waiting vehicle is also recognized by the conflict 

marker, for example, if the waiting vehicle is within the headway range of 

the conflict marker. To avoid this problem, a conflict marker on a link 

should always be placed at a position upstream of the position where any 

relevant connectors enter that link. 

If vehicles appear to be ignoring priority rules this could be the reason: 

If at a set of priority rules one or more vehicles wait for themselves or one 

another (gridlock situation) then VISSIM recognizes the gridlock and 

resolves it: Then the vehicle with the longest waiting time comes first. 




As a priority rule always consists of at least one pair of cross sections, the 

definition process is somewhat similar to static routes. 

The definition of a priority rule is a four step process. 

To initialize the process, select the Priority Rules mode. The next action to 

be done is shown in the status bar. To go back one step, left click outside the 


1. Select the link/connector where the stop line should be placed on. 

2. Right click on the location for the stop line on the selected link. 

3. Select the link/connector where the conflict marker should be placed on. 

4. Right click on the location for the conflict marker. Typically it is located 

within the last two meters of the conflict area. The Priority rules window 

appears. Define the properties (as shown below) and confirm with Ok. 

To define more conflict markers that belong to the same stop line, click twice 

outside the VISSIM network to go back two steps and continue with steps 3 

and 4 for each additional conflict marker. 

To define a new priority rule, select the Priority Rules mode and repeat the 

steps 1 to 4. 




See section 6.6.1.2 on how to access the properties of a priority rule. 

● No.: Unique identification 

of the priority 

rule 


● Label: If showing 

labels (names) of all 

priority rules (cf. VIEW - 

NETWORK ELEMENTS), 

this option allows to 

individually switch off 

the label of that priority 

rule. 

The following properties are available for both markers (stop line and 

conflict marker) separately: 

● Lane: Defines the lane number where the marker is placed. 

● At: Link/connector coordinate of the marker. 

● All Lanes: Defines the marker to stretch over all lanes of that link (in 

contrast to be placed on a single lane). 

● Vehicle Classes: Define the vehicle classes to be affected by the marker. 

For multi-selection, press CTRL while clicking the left mouse button. 

The vehicle class configuration of the stop line (red bar) affects all conflict 

markers that belong to that stop line. In order to define a stop line for a 

different set of vehicle classes, a new (separate) priority rule must be 

created and the stop line has to be placed at the same location. 

The following properties affect the stop line: 

● CONDITION...: Opens the PR - Condition window to link the priority rule 

with the current state of a signal group. This option is useful when 

vehicles should not yield to vehicles queuing behind red signals. 



- Stop only if: Activates the condition so 

that the stop line is only active when the 

following condition is true. 

- If the selected Signal Group of the selected 

SC (Signal controller) has the selected 

Signal State then the stop line is active and 

checks the other conditions as well (min. 

headway, min. gap time etc.). 


The following properties affect each conflict marker: 

● Min. Gap Time: Minimum gap time (in s) between the conflict marker and 

the next approaching vehicle. 

● Min. Headway: Minimum headway (distance) between conflict marker 

and next vehicle upstream. 

● Max. Speed: Any vehicle approaching the conflict marker will only be 

taken into account for the headway condition if its speed is the same or 

lower as the Maximum Speed. 

● Look beyond red signals: Also vehicles located upstream of red 

signals are "seen" by the conflict marker. If deactive, headway and gap 

time are only checked up to red signal heads. 

Editing data 

The properties of a priority rule can be accessed by the following sequence: 

1. Select the Priority Rules mode (to make sure that no previous priority 

rule is selected). 

2. Select one of the corresponding links/connectors. 

3. With the left mouse button, double-click on the stop line or conflict 

marker (the corresponding pair of conflict marker and stop line is shown 

in highlighted colors). When selecting the stop line, only the 

corresponding conflict markers will be shown (in dark green). 

Alternatively, the properties can be accessed by opening the list of all Priority 

Rules (right-click outside the VISSIM network), selecting the desired priority 

rule and pressing the DATA button. 

Deleting 

► There are two options to delete a single conflict marker: 

- Open the list of all Priority Rules (right-click outside the VISSIM 

network), select the priority rule to be deleted and press the DELETE 

button. 



- Alternatively, you may drag the conflict marker (green bar) out of any 

link. 

► To delete a priority rule completely, follow the steps below: 

- Click Priority Rules mode (to make sure that no priority rule is 

selected), select the link/connector of the stop line of the priority rule 

to be deleted and drag the stop line out of any link/connector. 

6.6.1.5 Examples 

The following examples illustrate the use of priority rules. 

Example 1: Driveway Exit 

Modeling a driveway exit (or similar situation) is very simple: 

1. Place the stop line (red bar) at the position where 

yielding vehicles need to stop. 

2. Place the conflict marker (green bar) on the 

major road link (not on the connector that leads 

onto that link) about 1m before the end of the 

conflict area (before the connector enters the link 

of the major road). 

3. Accept the standard parameters (headway = 5m, 

gap time = 3s). 

The green bar is placed before (upstream of) the 

location where the minor road connector enters the 

major road so that vehicles of the minor road will not 

yield to themselves. 


connector 

stop line 

headway 

conflict area 


relevant gap for min. gap time 

headway 

Example 2: Modeling “Keep Clear Areas” and “Yellow Boxes” 

Modeling a Yellow Box causes vehicles to stop in front of an in intersection if 

it cannot continue without blocking part or all of it. Thus different priority rules 

are needed for each vehicle "length" class, e.g. cars and HGVs/buses. 

To model a Yellow box follow the steps below:

1. Place the stop line on the stop 

position before the yellow 

box/intersection. 

2. Place the conflict marker at 

least one vehicle-length 

downstream of the conflict 

area (e.g. for cars 5-6m, for 

HGVs/buses 12-18m). This is 

the "storage area" for the first 

vehicle downstream of the 

gap. 

You may want to include 

separate priority rule pairs for 

cars and HGVs as HGVs need 

more space on the far end of 

the junction. 


(gap time = 0.0 s) 

(headway ≈ (d-0.5) m) 

(max. speed = 13-20 km/h) 

Cars only 

yellow box 

stop line 

(all vehicle classes) 


yellow box 

stop line 2 

(HGV, Bus only) 


5-6 m 

conflict marker 2 



(max. speed = 13-20 km/h) d conflict marker 2 



(max. speed = 13-20 km/h) 

Additional priority rule for HGv/Bus 

d 

d 

12-18 m 

3. The headway needs to cover almost the entire distance between the stop 

line and the conflict marker. This is to prevent vehicles from entering the 

"storage area" if another vehicle is still in it. 

Make sure that the headway does not reach beyond the stop line. Otherwise 

vehicles will slow down even if they could drive through straight away. 

4. Use the parameter Max. speed to set a limit as to when the priority rule 

should be active. For normal traffic flow, you do not want only one 

vehicle in the area between stop line and conflict marker (as this would 

reduce capacity enormously). Thus set Max. speed to a value between 

13 and 20 km/h so that slow moving vehicles will recognize the gap 

whereas faster ones will not. The higher the speed, the higher is the 

acceptance of the keep clear area.


Both, the location of the conflict marker (and thus the headway) and the 

speed can be used to calibrate the acceptance of the “keep clear area”. 

Example 3: Dual-lane roundabout with dual-lane entry 

To model an entry of a roundabout several priority rules are necessary, each 

of them serving different tasks. According to their difference in acceleration 

capability and vehicle length cars and HGV/trucks/buses are dealt with 

differently. 

The following four illustrations visualize all the priority rules according to their 

task. For easy reference the rules are numbered. The numbers refer to small 

boxes within the illustration where the corresponding parameters can be 

found. The values used for min. gap time, min. headway and max. speed 

have been determined through research. Thus for most applications these 

serve as a realistic base. 

Place priority rules according to the following criteria (cf. illustrations): 

► Stop lines represent the typical waiting position. If more than one green 

bar refers to the same stop line it is important to model them as multiple 

green bars to the same red bar (not as separate priority rule pairs) as 

long as the conditions for the red bar are the same. E.g. it is not possible 

to combine two red bars into one if they have different vehicle classes 

assigned. 

► Conflict markers used for headways are to be placed shortly before the 

position where the connector enters the roundabout link (if they would be 

placed after the entry of the connector it could result in a situation where 

a vehicle would wait for itself and thus drastically reduce capacity of the 

roundabout). 

► A green bar used for min. gap time only should be placed around the 

same distance away from the conflict area as the associated stop line. 


Example 3 - Step 1 

1 t = 0 s 

x = 5 m 

v = 14 km/h 

3 t = 1.8 s 

x = 0 m 

v = 180 km/h 

1 

3 

2 


Querverkehrsstörungen 

für einen zweistreifigen Kreisverkehr 

mit zweistreifiger Zufahrt 

Priority rules 

for a two-lane roundabout 

with a two-lane entry 

Spur 1 

(lane 1) 

Spur 2 

(lane 2) 

Legende (legend) 

t: Zeitlücke 

(min. gap time) 

x: Weglücke 

(min. headway) 

v: max. Geschwindigkeit 

(max. speed) 

gestörter Querschnitt 

(stop line) 

störender Querschnitt 

(conflict marker) 


1-5 

2 t = 2.6 s 

x = 0 m 

v = 180 km/h 

At first, priority rules for vehicles entering the roundabout from lane 1 will be 

defined. All 3 priority rules mentioned here relate to the same stop line (i.e. 

one stop line with 3 conflict markers). 

There are different positions, each for time gap and headway to model a 

more realistic vehicle flow. Thus a vehicle within the roundabout driving 

faster than 14 km/h will not be detected by the headway but only by the time 

gap condition. Therefore a vehicle wanting to enter the roundabout can start 

to enter even if the one within the roundabout has not left the conflict area 

completely. Priority rules 1 and 2 model this behavior - these are valid for all 

vehicle classes: No.1 secures the conflict area during slow moving traffic and 

congestion within the roundabout; No.2 contains the conditions for normal 

traffic conditions (time gap). 

Because traffic from the inner lane of the roundabout also affects entering 

vehicles of lane 1 an additional priority rule is required (No.3). This one only 

needs a small gap time condition, which again is valid for all vehicle classes.



4 t = 0 s 

x = 5 m 

v = 180 km/h 

grün = Lkw/Bus 

green = HGV/Bus 

4 

5 







Spur 1 

(lane 1) 

Spur 2 

(lane 2) 


t: Zeitlücke 


x: Weglücke 



(max. speed) 


(stop line) 




1-5 

5 t = 3.6 s 

x = 0 m 

v = 180 km/h 

rot = Lkw/Bus 

red = HGV/Bus 

The previously entered priority rules (Nos.1-3) are valid for all vehicle 

classes. In the case where a long vehicle within the roundabout passes the 

conflict area, the minimum speed condition (No.1) is not sufficient. It could 

happen that vehicles entering the roundabout crash into an HGV/truck. To 

avoid this, another conflict marker needs to be added (No.4) to the same 

stop line as Nos.1-3 but valid only for long vehicles approaching the green 

bar (in this case HGVs and Buses). 

To finish off the priority rules related to lane 1 another one is needed to 

consider entering vehicles having a lower acceleration capability than cars. 

For this purpose priority rule No.5 is used. In contrast to all the existing 

priority rules, this one needs a new stop line because a different set of 

vehicle classes (HGV & Bus) is affected. It is placed at the same location as 

No.2 but with a higher gap time of 3.6s.


8 t = 0 s 

x = 5 m 

v = 14 km/h 

8 

9 t = 2.7 s 

x = 0 m 

v = 180 km/h 

9 

6 

6 t = 0 s 

x = 5 m 

v = 14 km/h 

7 

7 t = 2.6 s 

x = 0 m 

v = 180 km/h 








Spur 1 

(lane 1) 

Spur 2 

(lane 2) 


6-12 


t: Zeitlücke 


x: Weglücke 



(max. speed) 


(stop line) 



Now the priority rules for lane 2 of the entering traffic will be defined: 

As with lane 1 the first few priority rules deal with all vehicle classes and in 

principal work the same way. The difference for traffic from lane 2 is that both 

of the roundabout lanes need to be taken into account. Thus four priority 

rules are needed (instead of 3 for lane 1): Nos.6 and 7 for the outer and 

Nos.8 and 9 for the inner roundabout lane. All four conflict markers relate to 

the same stop line. 

Please note that because of the greater distance to the conflict area the 

minimum gap time for the inner roundabout lane (No.9) is slightly higher than 

for the outer one.



12 t = 3.7 s 

x = 0 m 

v = 180 km/h 

rot = Lkw/Bus 

red = HGV/Bus 

10 t = 0 s 

x = 5 m 

v = 180 km/h 

12 

grün = Lkw/Bus 

green = HGV/Bus 

10 

11 t = 3.6 s 

x = 0 m 

v = 180 km/h 

rot = Lkw/Bus 

red = HGV/Bus 







Spur 1 

(lane 1) 

Spur 2 

(lane 2) 


11 

6-12 


t: Zeitlücke 


x: Weglücke 



(max. speed) 


(stop line) 



Finally, the priority rules for lane 2 dealing with specific vehicle classes need 

to be entered. Same as with lane 1, long vehicles need to be secured (No. 

10 - added to the same stop line as Nos.6-9) and entering HGVs and buses 

to be provided with higher gap times (Nos. 11 and 12 - added to a new stop 

line). Same as with lane 1 there is a slightly higher value for the time gap of 

the inner roundabout lane. 

6.6.2 Conflict Areas 

Conflict areas are a new alternative to priority rules to define priority in 

intersections. 

They are the recommended solution in most cases because they can be 

modelled more easily and the resulting vehicle behavior is more intelligent. 

6.6.2.1 Principles 

A conflict area can be defined wherever two links/connectors in the VISSIM 

network overlap. For each conflict area, the user can select which of the 

conflicting links has right of way (if any).


Drivers make a plan how to cross the conflict area. A yielding driver observes 

the approaching vehicles in the main stream and decides for which gap he 

wants to go. Then he plans an acceleration profile for the next seconds that 

will allow him to cross the area, taking into account the situation behind the 

conflict area: if he knows that he has to stop or to slow down there because 

of other vehicles, he will calculate more time to cross the conflict area or 

decide not to go at all. 

Vehicles in the main stream react on the conflict area as well: if a crossing 

vehicle could not complete the crossing because the driver estimated the 

situation too optimistically, the vehicle in the main stream will brake or even 

stop. And if a queue builds up from a signal downstream the conflict area, 

the vehicles in the main stream try not to stop in the conflict area in order not 

to block the crossing stream. This is accomplished by having the drivers 

make a similar plan to cross the conflict area as the yielding vehicles do. 

A conflict area can be created at any position where two links/connectors 

overlap. 

Exceptions: In the following cases, this is not possible: 

► If the overlapping sections differ in height (z coordinate) by more than 1.0 

m 

► if the overlapping section is shorter than 0.5 m 

► if vehicles cannot use one or both of the overlapping link segments 

(since they cannot be reached from a parking lot or by an input) 



► if vehicles leave from the network immediately after passing the 

overlapping section (since there is no connecting turn starting from that 

section) 

A conflict area can be used to model the following conflict types: 

► Crossing conflicts (one link crosses the other) 

► Merging conflicts (two connectors lead to the same link or one connector 

leads to a link that has other traffic coming from upstream) 

► Branching conflicts (two connectors come from the same link or one 

connector comes from a link that continues further downstream) 

The driving behavior of vehicles approaching a conflict area provides the 

maximum possible flow-rate for the minor road without interfering with the 

traffic on the main road. (In case of merging areas vehicles entering from the 

minor road may interfere with the traffic on the main road, depending on the 

user-defined safety distance factor: The smaller the factor the stronger the 

interference.) 

► A vehicle on the minor road approaching a conflict area (where it must 

yield) determines if there will be a sufficient gap in the major road 

movement when it arrives at the conflict area (with its current travel plan, 

i.e. if it ignored the conflict area). If there is no such a gap, the vehicle 

decelerates as if it had to stop in front of the conflict area. In the next 

time step the vehicle calculates again, so it can possibly cancel the 

braking and continue even with a certain acceleration, "aiming" at a later 

gap. 

► A vehicle on the main road tries not to "crash" into vehicles on the minor 

road. If it determines that a vehicle on the minor road will still be inside 

the conflict area when it arrives there, it brakes to stop in front of the 

conflict area. (As this deceleration causes it to arrive later, it can possibly 

continue its journey without further braking in a later time step so that it 

passes just behind the vehicle on the minor road.) 

A vehicle on a minor road will try not to enter a crossing conflict area if there 

is not sufficient space downstream of the conflict area to leave the conflict 

area immediately. This means that a vehicle enters the first conflict area of 

several adjacent conflict areas (without room for the whole length of the 

vehicle in between) only if it can pass all these conflict areas in one 

continuous movement. 

With a conflict area of the crossing type, also a vehicle of the major flow 

intends to keep the conflict area clear as long as this vehicle belongs to the 

percentage that has been specified via the Avoid Blocking property, cf. 

section 6.6.2.3 

Conflict areas of the merging or branching type are not kept clear of 

major flow vehicles. To keep conflict areas of the merging or branching 

type clear, a priority rule has to be defined, cf. section 6.6.1.5, example 2. 

Vehicles on the minor road do not enter if they must assume that they cannot 

leave the conflict area before the next vehicle on the main road will arrive 

(plus safety gap, cf. section 6.6.2.3). 



A vehicle on the minor road that has already entered a conflict area will 

always try to leave it, even if this means entering another conflict area where 

the gap condition is not met (anymore). 

Conflict areas are created, deleted and edited in the Conflict Area mode. 


Define area Left-click on a position where flows might conflict: 

The two overlapping link segments are displayed in yellow with the links 

outlined in yellow, too. This is referred to as a passive conflict area. 

Define state Right-click once or several times to define an active conflict area: 

Select the appropriate right of way configuration, displayed in the status line 

and through link colors: 

► Green = main road (right of way). 

► Red = minor road (yield). 

► Both red may be used for branching conflicts where vehicles need to 

"see" each other but there is no right of way because vehicles simply 

stay in their original sequence. 

► Both yellow is passive. 


The attributes affect the calculation of the plan (acceleration profile) for each 

vehicle approaching the conflict area. The resulting situations (especially the 

resulting front and rear gaps between two vehicles) can be different from the 

defined attributes. This is caused by the fact that a vehicle may change its 

plan (and thus its current behavior) due to a change in the current traffic 

situation. 

Some of the attributes are relevant only for some conflict situations. 

● Visibility: Maximum distance 

from where an approaching 

vehicle can see vehicles on 

the other link. As long as a 

vehicle on the minor road is 

further away from the conflict 

area it plans to stop in front of 

the conflict area. Caution: 

Values below 1 m can cause a 

vehicle to stop forever 

because it may not come 

close enough to the conflict 

area due to the driving 

behavior settings. 

The blue vehicle reached the point from 

where it can fully see past the building. 

Therefore visibility for link 2 is dL2. 



● Front Gap (only for crossing 

conflicts): Minimum gap in 

seconds between the rear end 

of a vehicle on the main road 

and the front end of a vehicle 

on the minor road, i.e. the 

proposed time elapsed since 

the vehicle with right of way 

has left the conflict area before 

the yielding vehicle enters it. 

For each vehicle class, a 

separate gap can be entered. 

● Rear Gap (only for crossing 

conflicts): Minimum gap in 

seconds between the rear end 

of a vehicle on the minor road 

and the front end of a vehicle 

on the main road, i.e. the time 

that a yielding vehicle must 

provide after it has left the 

conflict area before a vehicle 

with right of way enters the 

conflict area. For each vehicle 

class, a separate gap can be 

entered. 

This illustration shows the current and the 

"planning ahead" situation ("ghost cars") 

when the car on main road just left the 

conflict area. Then the front gap is evaluated 

as the time needed for the vehicle on the 

minor road to reach the conflict area (here: 

0.5s) 

This illustration shows the current and the 

"planning ahead" situation ("ghost cars") 

when the car on main road just reached the 

conflict area.Then the rear gap is evaluated 

as the time elapsed since the vehicle on the 

minor road left the conflict area (here: 0.7s) 


● Safety distance factor: (only 

for merging conflicts) This 

value is multiplied with the 

normal desired safety distance 

of a vehicle on the main road 

to determine the minimum 

headway that a vehicle from 

the minor road must provide at 

the moment when it is 

completely inside the merging 

conflict area. For each vehicle 

class, a separate factor can be 

entered 


Similar situations but different factors 

(top = 1.0, bottom = 0.5). Thus blue vehicle 

can still enter while red vehicle needs to stop 

● Additional stop distance (only for the minor road): Distance that moves 

the (imaginery) stop line upstream of the conflict area. As a consequence, 

yielding vehicles stop further away from the conflict and thus 

also need to travel a longer distance until they pass the conflict area. 

● Observe adjacent lanes: If this option is active, the incoming vehicles 

on the minor road pay attention to the vehicles on the prioritized link 

which are going to change to the conflicting lane. Please note: This 

option will reduce the simulation speed. 

● Anticipate routes: Enter a real number in the interval [0, 1]. This factor 

describes the percentage of incoming vehicles on the minor road which 

consider the routes of those approaching vehicles on the main road that 

will turn at an upstream position and thus will not reach the conflict 

area. 

● Avoid blocking (only for crossing conflicts): Enter a rate factor in the 

interval [0, 1], which describes the percentage of vehicles on the main 

road which will not enter the crossing conflict area as long as they 

cannot expect to clear it immediately. While these vehicles on the major 

road are waiting for more room downstream of the conflict area the 

vehicles on the minor road can cross the conflict area. A prioritized 

vehicle in the selected percentage checks the room downstream of the 

crossing conflict area. If this is less than the vehicle's length plus 0.5 m 

and if the blocking vehicle is slower than 5 m/s and slower than 75% of 

its desired speed (or if the obstacle is a red signal head), the prioritized 

vehicle will not enter the conflict area. 




Nodebased 

list display 

Define 

main or 

minor link 

Set 

attribute 

values 

Call the Conflict areas dialog by 

► double-clicking a (passive or active) conflict area or 

► right-click outside of the VISSIM network. 

● show all possible Conflict Areas in Node: 

- Check the option 

- Select the node number from the selection list or enter it. 

Then, only the conflict areas inside the selected node will be listed including 

the passive ones. This is a good way to check if any conflicts inside a node 

are not yet provided with an active conflict area. 

In the network, right-click the link until the appropriate status is displayed by 

color and in the status bar. 

In the dialog window, 

► Left-click the particular entry: A double click on a link number in the 

conflict area window makes this link the major road for this conflict area 

(data row), displayed on green background, and the other link the minor 

road (red). 

► Alternatively, right click and select the appropriate option from the 

context menu. The following buttons are provided: PRIORITY, YIELD, and 

PASSIVE. 

- The conflict area can be switched to all-red (e.g. for a branching 

area) through a right click on the green link and setting it to YIELD, 

too. 

- Selecting PASSIVE in the context menu after a right-click disables 

this conflict area completely (white, respectively yellow while 

selected). 

Edit selected cell(s) by direct entry or Copy & Paste. 

For editing data by vehicle class, please see below. 


Set data by 

vehicle 

class 

Disable a 

conflict 

area 


For the attributes Front gap, Rear gap and Safety distance factor, a specific 

value can be set for each vehicle class. 

1. In the cell to be edited, place the pointer on the button. 

2. Left click to open the selection list. 

3. In the Vehicle Class column, right click to open the context menu: 

- Click NEW to add another row to the list. 

- Click DELETE to remove the selected row from the list. 

4. In the Value column, you can edit the data by vehicle class. 

5. To replace a listed vehicle class, click the button in the particular row 

of the Vehicle Class column. 

6. In either column, the entries can be sorted: Left-click in the column 

header. 

7. To close the selection list, left-click outside of the columns. 

Select the data row in the list, call the context menu and chose one of the 

options: 

► Click DELETE to remove the data row from the grid. 

► Select the PASSIVE state instead (can also be done graphically). 

6.6.3 Stop Sign Control 

Intersection approaches controlled by STOP signs are modeled in VISSIM as 

a combination of priority rule and STOP sign. A STOP sign forces vehicles to 

stop for at least one time step regardless of the presence of conflicting traffic 

while the priority rule deals with conflicting traffic, looking for minimum gap 

time and headway etc. Dispatch counters (e.g. customs clearance) represent 

a variant of STOP signs with a dwell time distribution assigned additionally. 

STOP signs can be used to model the following: 

► Regular STOP signs: Additionally to the STOP sign a priority rule has to 

be defined to make sure, that traffic flows are regarded accordingly. The 

STOP sign and the stop line (red) should be placed at the same position. 



► Right turn on red: Option Only on Red has to be checked. Then, the 

STOP sign becomes active only while the allocated signal group shows 

red. 

► Dispatch counters (e.g. customs, road toll etc.): Option Use time distribution 

has to be checked. Then, vehicles will stop as long as preset by the 

assigned time distribution (to be defined via BASE DATA – DISTRIBUTIONS – 

DWELL TIME...). 


1. Select the Stop Signs mode. 

2. Select the link on which vehicles will have to stop. 

3. With a right click, define the location on the selected link where vehicles 

should stop (stop line). 

4. Edit the stop sign properties. 

5. Confirm with Ok. 


The properties of a stop sign can be accessed by selecting the 

corresponding link/connector and double-clicking on the stop sign marker. 


stop sign 


[POSITION] 

● Lane: Defines the lane number 

where the marker is placed. 

● At: Link/connector coordinate of the 

marker. 

● Label: When showing labels 

(names) of all stop signs (cf. VIEW - 

NETWORK ELEMENTS...) this option 

allows to individually switch off the 

label of that stop sign. 


[RTOR] (= right turn on red) 

● Only on Red: The stop sign is 

only active if the selected SG 

(signal group) of the selected SC 

(signal controller) shows “red” (see 

section below for details). 

[TIME´ 

DISTRI- 

BUTION] 

● Use time distribution: For each 

vehicle class, a time distribution 

(see section 5.2.6) may be 

assigned in the list below. The list is 

edited by the NEW, EDIT and DELETE 

buttons. All vehicles of a class for 

which a time distribution is defined 

will stop for a certain time out of the 

corresponding distribution. 

If no time distribution is selected, 

the dwell time will be one time step. 


6.6.3.3 Right Turn On Red 

Stop signs are also used to model right-turn-on-red movements using the 

option Only on Red. In that case, the stop sign is active only if the 

associated signal controller phase displays red. There are two scenarios 

where right turn on red can be modeled: 

► An exclusive right turn lane: 

A stop sign (with Only on Red) needs to be placed on that lane. It 

might be advisable to additionally place a signal head in this lane and 

select a vehicle type like Tram or Pedestrian so that the vehicles on the 

lane will not be affected by it but the state of the signal will be visible. 

► A combination of through and right turn lane: 

A stop sign (with Only on Red) needs to be placed on the right-turn 

connector only. That way turning vehicles only will see the stop sign. The 

signal head is placed in the same location but on the link rather than the 

connector. The signal head will control the through movements. 



The illustration shows both scenarios. 

The South approach is a combination 

turn lane and the West approach is an 

exclusive turn lane. The lighter bars are 

signal heads and the darker are stop 

signs. 

6.6.4 Merging and Weaving Sections 

In order to get the best vehicle behavior it is important to implement merging 

and weaving sections in VISSIM properly. 

Here are the important things to remember: 

► The merge section (weaving section) should be one link with the number 

of lanes equal to the number of lanes on the main freeway plus the 

number of lanes merging onto the freeway. 

► There should be only one connector after the merge link (weaving 

section) to the main freeway. For graphical reasons an additional dummy 

link (not a connector) can be added at the end of the merging lane(s) to 

smoothen the lane reduction. 

► The through movement needs to follow a route in order to prevent it from 

using the acceleration lane(s). This route must end no sooner than on 

the main link after the merge link. Additionally the Lane Change distance 

for the connector downstream from the merge link (weaving section) 

must be larger than the length of the merge link itself. If this is not the 

case, a vehicle from a through lane may change to the acceleration lane 

(merging lane) and then needs to get back to the main link thus 

producing unrealistic lane changes. 

► The routes of the merging traffic must also extend past the merge link 

(weaving section). If not, vehicles on the merge link will not know that 

they need to change lanes in order to get on to the main link prior to the 

end of the merging lane(s). 

See below for an illustration of a one-lane merge into a three-lane freeway: 


Merging section in Normal display 

Merging section in Center Line display. 




6.7 Signal Controllers 

In VISSIM, signalized intersections can be modeled by means of the built-in 

fixed-time control including the VISSIG add-on, if applicable, cf. section 

6.7.3.10. 

Additionally, various external signal control logic add-ons are available: 

► Econolite ASC/3, cf. section 6.7.3.8. 

► LISA+OMTC, cf. section 6.7.3.6. 

► SCATS, cf. section 6.7.3.4. 

► SCOOT, cf. section 6.7.3.5. 

► VAP, cf. section 6.7.3.3. 

► Ring Barrier Controller (RBC), cf. section 6.7.3.7. 

The Ring Barrier Controller (RBC) is the default actuated signal controller 

for licenses distributed by subsidiary PTV America. 

The RBC User Manual can be accessed through the HELP menu in the 

RBC GUI, additionally it is stored in the DOC folder of your VISSIM 

installation. 

Further custom external signal controller types support Siemens VA, 

TRENDS, VAS, and VS-PLUS. 

Users of the 32 bit edition of VISSIM receive the 32 bit version of the 

specific *.DLL files. Accordingly, the 64 bit version of the specific *.DLL files 

is provided to users of the 64 bit edition of VISSIM. 

► Alternatively, you can also define an External controller using userdefined 

signal controller *.DLL and signal controller *GUI.DLL files (in C 

or C++ programming language), cf.section 6.7.3.9. 

Users of the External add-on need to compile the SC DLL files in 

accordance with the used VISSIM edition (32 bit or 64 bit). 

Click menu HELP - LICENSE to verify which signal controllers are provided with 

your license. 

VISSIM provides access to external controller data only if the network has 

been saved to file. This guarantees, that the controller files and the *.INP 

file are stored in the same folder. 

6.7.1 Signal Groups and Signal Heads 

In VISSIM every signal controller (SC) is represented by its individual SC 

number and signal groups (also referred to as signal phase) as its smallest 

control unit. Depending on the selected control logic, VISSIM can simulate 

up to 125 signal groups per signal controller. VISSIM also discriminates 

between signal groups and signal heads. 


Signal Controllers 

A signal head is the actual device showing the picture of the associated 

signal group. Signal heads are coded in VISSIM for each travel lane 

individually at the location of the signal stop line. Vehicles wait approximately 

0.5m behind a signal head/stop line that displays red. Vehicles approaching 

an amber signal will proceed through the intersection if they cannot come to 

a safe stop in front of the stop line. Optionally an advanced calculation 

method can be used for VISSIM to calculate a probability for whether the 

vehicle should continue through amber or not using three values of the 

Driving Behavior Parameters (see section 5.4). 

Signal indications are typically updated at the end of each simulation second. 

If the controller module for VISSIM is equipped for switch times down to 0.1s, 

VISSIM is able to reflect this behavior. However, this is dependent on the 

controller type. 

Signal head coding allows for the exact modeling of any kind of situation. 

This includes the ability to model different signal groups for different vehicle 

types on the same travel lane. For example, modeling a bus traveling in 

mixed traffic but yielding to its own separate signal phase is possible with 

VISSIM by selecting the appropriate vehicle classes for each signal head. 

With any SC, all conflicting movements that can run at the same time need 

to be secured using priority rules (cf. section 6.6.1). 


For coding Signal heads, a Signal controller has to be defined and Signal 

groups are required, cf. section 6.7.3: 

1. Select the Signal heads mode. 

2. Select the link on which it is to be placed. 

3. With a right click, define the position of the signal head on the selected 

link. 

4. Edit the signal head properties (cf. section 6.7.1.2). 





● No.: Unique identifier of the 

signal head 

● Name: Optional label or 

comment 

● SC: Selected signal 

controller. 

● Signal group: Selected 

signal group. 

● Type: Defines the display of 

the signal head in the 2D 

animation during a simulation 

or test run. Options: 

- Circular 

- Left Arrow 

- Right Arrow 

- Invisible. 

If the normal signal group of an (arrow) signal head has red or off and if 

an "or signal group" is defined, the state of the or signal group is displayed 

instead, without arrow (even if the normal signal group has amber 

and the or signal group has red/amber or vice versa). 

● Or Sig. Gr.: if this option is active, overlaps can be modeled by 

defining a primary signal group as well as a secondary signal group and 

combining them. The signal head will then turn green if either the first or 

the second signal group is green. If the first signal group shows red, the 

signal head displays the signal of the Or Sig. Gr. (even if it is amber or 

red/amber). If one of the two signal groups shows amber and the other 

one red/amber, the signal head displays green. 

To display the signal status of each signal group separately, create a 

short dummy link next to the intersection with a signal head for each 

signal group. 

● Label: When showing labels of all signal heads (see VIEW - NETWORK 


one (cf. section 4.2.1). 

● Vehicle Classes: Selected vehicle class(es) the signal head refers to. 

Thus e.g. bus signals can be defined which are to be ignored by private 

traffic. 

● NEW 3D SIGNAL: Create a 3D signal, cf. section 4.1.4.2 and section 

4.3.4.1. 

To model right-turn movements (right-turn-on-red), which are controlled by 

an own signal group before/after the actual stage and signalized by the 

Circular type in the actual stage in VISSIM, enter the signal group of the 

green arrow for the Or Sig.gr. option. 



1. Select the Signal heads mode. 


2. Right click in the network display to call the Signal heads list. For each 

signal head, the list contains the SC no., the name and no. of the signal 

group and the name and no. of the signal head. 

3. Select the signal head you would like to edit. 

4. Click the ZOOM button to zoom into the network display, if applicable. 

5. Click the EDIT button to modify the signal head’s properties (cf. section 

6.7.1.2). 


Alternatively, you can click the DELETE button in step 5 to delete the selected 

signal head in the network. 

6.7.2 Detectors 

Real life vehicle/pedestrian detection is achieved using various methodologies 

including induction loops, video cameras, push buttons, track circuits 

etc. VISSIM models each detector type in the same way: as a network 

element of user-definable length. 

A message impulse is transmitted to the signal controller as soon as a 

vehicle reaches this element with its front and another one when it leaves it 

with its tail. This information is then interpreted by the signal control logic. 

Detectors on pedestrian links 

Prior to VISSIM 5.20-06, only the presence at the end of the controller time 

step was passed to the controller. Now, detectors on pedestrian links detect 

changes between occupied and free between subsequent time steps, and 

pass this data to the controllers as "front ends / rear ends". 

Thus, the assigned sound file can be played, when a pedestrian arrives on 

an empty detector, too. 


To define a new detector on a link follow the steps outlined below: 

1. Select the Detectors mode. 

2. Select the link the detector is to be placed on. 

3. Right-click within the link where the detector should start. The new 

detector will be shown with a default length of 5 m and the Detector 


4. Set the detector properties (see section 6.7.2.2). 





[LOCATION] 

● No.: The physical channel 

number that the signal control 

program uses. Multiple 

detectors of the same 

controller can have the same 

channel number, causing the 

controller to treat them as one 

detector. This allows VISSIM 

to model detectors reaching 

over multiple lanes by defining 

one detector per lane coded 

with the same number. 

● Name: Label or comment. 

● SC (signal controller): 

Associates the detector to the 

controller. 

● Length defines the length of the detector. A value of 0 is permitted (e.g. 

for push buttons). The detector is then displayed as a thin line. 

● Type: Choose the appropriate detector type: 

- Standard detectors register PT vehicles like any detector. 

- Pulse detectors do not pass any presence/occupancy information to 

the signal controller. 

- Presence detectors do not pass any pulse information (vehicle front 

ends or rear ends) to the signal controller. 

- Public transport calling points only detect PT vehicles that send out 

PT telegrams, cf. section 6.5.2 for details. 

● At contains the detector’s link coordinate. 

● Lane: Defines the lane number where the detector is placed. 

● Before stop: The detector’s distance to the next signal stop line (available 

only if the stop line is located on the same link). 


[ACTIVATION] ● Vehicle Classes: The detector 

will recognize only vehicles that 

are contained in at least one of 

the selected classes. 

● PT Lines: The detector will 

recognize only vehicles of those 

PT lines that are selected here. 

A multi-selection is possible 

using CTRL and mouse click. 


● Departure Signal: The detector will detect a vehicle only in one of the 

following cases: 

- if the vehicle stops in the selected PT stop and the dwell time will 

be finished after the given time (x seconds before departure) or the 

total dwell time is shorter than the given time 

- if the vehicle has already decided to skip that PT stop (in this case 

the detector call is sent to the controller as soon as the vehicle 

reaches the detector) 

If the detecor is located on a link 

which is to be used as pedestrian 

area, and serves for push button 

modeling for pedestrians, please 

select Pedestrian class(es) and 

define the Maximum speed, cf. 




[OTHER] 

● Smoothing factors define the 

exponential smoothing of 

detector occupancy rates used 

by certain signal control 

programs. 

- Increase defines the weight 

of a new occupancy rate in 

the new exponentially 

smoothed average if the new 

rate is higher than the 

previous average 

- Decrease defines the weight 

of a new rate smaller than 

the previous average. 

● Visible (Screen): The detector will never be displayed if this option is 

turned off. 

● Label: When showing labels (names) of all detectors (see VIEW - 


label of that detector. 

● Sound: A wave file (*.WAV) can be assigned to a detector. If a sound 

card and driver is installed it is played every time a vehicle is detected. 

The wave file needs to be located in the same directory as the network 

data file (*.INP). 

6.7.2.3 Exponential Smoothing of the Occupancy Rate 

Exponential smoothing is a way of leveling out the occupancy rate of a 

detector. This is necessary because detectors are either occupied or not and 

because of that they do not provide enough information to make signal 

control decisions. Exponential smoothing allows for calculation of an 

occupancy rate using the last t seconds. 

This equation is used: 

s( t) 

= α ⋅ x + ( 1 − α) 

⋅ s( 

t −1) 

The following applies: 

s(t) is the new exponentially smoothed value 

s(t-1) is the old exponentially smoothed value (recent time step) 

x is the new detected value 

α is the smoothing factor [0..1] 

The new exponentially smoothed value is a weighted average of the new 

(detected) value and the exponentially smoothed value after the last 

simulation second. The new detected occupancy rate has a weight of α and 

the old smoothed value a weight of (1-α). In VISSIM the user can enter two 




different values for α, one for increasing x values (used if x is greater than 

s(t-1)) and one for decreasing x values (used if x is smaller than s(t-1)). 

This means that the exponentially smoothed occupancy rate is a kind of a 

floating average of the detected values from all time steps before, with the 

most current ones having the highest weight. A general rule is that with a 

smoothing factor of 1/n most of the result originates from the last 2*n values, 

e.g. with α = 0.25 the last 8 detected values account for most of the 

smoothed value. If you do not want your values to be smoothed you can set 

α to 1 and the equation will give you only the newly detected value x. 

To access the detector properties for data editing (cf. section 6.7.2.2), there 

are two ways: 

► Select the link/connector in the network display and double-click on the 

detector. 

► Alternatively, you may right-click outside of the network to call the list of 

detectors. For each detector, the list contains the SC no., the detector 

no. and the name of the detector. Select the detector in the list and click 

the DATA button. 

By dragging the detector while keeping the left mouse-button pressed, you 

can do the following: 

► Move the detector either within its link/connector or into another link or 

connector. 

► Delete the detector by dragging it outside of any link/connector. 

6.7.3 Signal Control Types 

The Signal control window contains the list of all signal controllers defined in 

the current network. This list can be edited. 

► For the SC selected in the list you can edit the header data in the upper 

section of the window. 

► By right-click in the list you can call a context menu. The context menu 

provides the following functions: 

- NEW adds another SC to the list 

- DUPLICATE creates a new SC with the properties of the selected one 

but a new SC no. = maximum SC no. + 1 

- DELETE removes the selected entry from the list 




Click menu HELP - LICENSE to check for the SC add-ons 

provided with your VISSIM installation. 

In order to define a new signal controller, access the Signal control window 

by SIGNAL CONTROL – EDIT CONTROLLERS... 

Click one of the commands below to create a new SC: 

► NEW: Enter data. 

► DUPLICATE after selection of a signal controller: Edit data. 


For each Signal Controller the following header data is available: 

● Number: Unique ID of the signal controller 


● Cycle Time: Fixed cycle length in seconds or Variable cycle length 

● Type: Select the control strategy. Other options are enabled or disabled 

according to this setting. 


[SIGTIMTBL. 

CFG] 

[SC/DET. 

REC] 


● Offset: A value that delays the first (and therefore all subsequent) cycle 

by seconds. 

For Fixed time control, significant changes have been performed and the 

functionality has been extended by various new features, One of them is 

the VISSIG add-on, for example. Please refer to section 6.7.3.10 for the 

comprehensive description. 

For the selected control strategy, the tabs contain special data, e.g. input file 

names etc. (see below). 

Here, the settings for the Signal timing plan display window (during 

simulation run) can be edited, cf. section 11.8. 

For SC using an external control strategy, the SC/Detector Record settings 

can be edited, cf. section 11.9. 

6.7.3.3 VAP - Vehicle-Actuated Signal Control (optional module) 

VISSIM can model actuated signal control in conjunction with an external 

signal state generator if the optional VAP module is installed. This signal 

state generator allows users to define their own signal control logic including 

any type of special features (e.g. PT priority, railroad preemption, emergency 

vehicle preemption, variable message signs on motorways etc.). The use of 

the external signal state generator and its VAP programming language is 

explained in file VAP.PDF in the DOCUMENTS folder of your VISSIM 

installation. VisVAP (the optional graphical desktop to model flow chart 

logics) is explained in file VISVAP.PDF in the DOCUMENTS folder of your 


Users of the 32 bit edition of VISSIM receive the 32 bit version of the VAP 

DLL files. Accordingly, the 64 bit version of the VAP DLLs is provided for 

users of the 64 bit edition of VISSIM. 

For VAP signal controllers using an Offset, values within VAP need to be 

adapted by this offset, too, in order to prevent malfunction of the time 

conditions. 

6.7.3.4 SCATS (optional module) 

SCATS requires 

► the files SCATS.DLL and SCATS_GUI.DLL and 

► the progams WinTraff and ScatSim (and SimHub if applicable). 

These are provided by the Roads and Traffic Authority of New South Wales, 

Australia. 



SCATS users receive the *.DLL files with the VISSIM edition. The *.DLL 

files are also provided as 64 bit versions. 

6.7.3.5 SCOOT (optional module) 

SCOOT requires 

► the files SCOOT_LOGIC.DLL and SCOOT_GUI.DLL and 

► the progam PCScoot. 

These are provided by Siemens (http://www.scoot-utc.com). 

● Write log information: If this option is checked, the following data is 

stored in the log file: Debug information and log information on the 

communication with the UTC. 

SCOOT users receive the *.DLL files with the VISSIM edition. The *.DLL 

files are also provided as 64 bit versions. 

6.7.3.6 LISA+ OMTC (optional module) 

Provided by SCHLOTHAUER & WAUER Ingenieurgesellschaft für 

Straßenverkehr, Berlin, Germany. 

6.7.3.7 Ring Barrier Controller (optional module) 

This controller is standard in North American releases of VISSIM. With this 

controller VISSIM can simulate fully actuated signal control as well as 

coordinated and semi-actuated coordinated signal control. 



Some of the general controller features available with RBC are: 16 signal 

groups, 16 overlaps, 8 PT signal groups, 4 rings, multiple detectors per 

signal group and multiple signal groups per detector, 8 coordination patterns, 

2 preempts, etc. PT signal priority and Preemption capabilities are available 

based on your VISSIM license level. 

The interface to the controller is accessed through VISSIM but saves its 

settings to an external data file with the extension *.RBC. The RBC manual is 

provided as MANUAL_RBC.PDF in the DOC folder of your VISSIM installation. 

This controller type replaced the NEMA controller type in North America. 

For data conversion, please refer to the NEMA_TO_RBC.PDF in the same 

folder. 

RBC users receive the *.DLL files with the VISSIM edition. They are also 

provided as 64 bit versions. 

How to edit RBC settings 

For a single controller, go on as follows: 

► Click menu SIGNAL CONTROL – EDIT CONTROLLER 

The Signal Control window opens. 

► Select the controller in the list. 

Its data is displayed in the window´s details section. 

► Select Ring Barrier Controller in the Type selection list, if applicable. 

The [RING BARRIER CONTROLLER] tab appears in the first position. 

► Check – and replace, if necessary – the preset *.DLL and *.WTT files 

(loaded from the EXE folder of your VISSIM installation). 

► Click the EDIT SIGNAL GROUPS button. 



The Ring Barrier Controller window opens. 

Continue according to the MANUAL_RBC.PDF in the DOC folder of your 


6.7.3.8 Econolite ASC/3 (optional module) 

This control type is used in North America. When creating an SC of the 

Econolite ASC/3 type, the *.WTT file is automatically set to ASC3.WTT. 

The files ASC3GUI.DLL and ASC3.DLL are provided with your VISSIM 

edition (32 bit version or 64 bit version). 

Since the nwe version of ASC/3 reqires the ASC3GUI.DLL file, for older 

projects the former file name ASC3_GUI.DLL needs to be replaced by the 

new file name ASC3GUI.DLL. 

6.7.3.9 External 

External does not represent a certain method, but is a generic name. 

You need to create user-defined DLL files in C or C++ programming 

language, which are required by VISSIM: 

► An external program DLL (controller) 

► A specific dialog DLL 



Users of the External add-on need to compile the SC DLL files in 

accordance with the used VISSIM edition (32 bit or 64 bit). 

Users with a license containing this feature can find the API source code 

modules and documentation in the API folder of the VISSIM installation. 

In the [CONTROLLER (EXT.)] tab, the following parameters have to be set for a 

signal control of the External type: 

● Program file: User-defined *.DLL 

● Dialog DLL file: User-defined *.DLL 

● Data file 1: Contains data for the control strategy. 

● Data file 2: Contains data for the control strategy. 

These data files (1/2) are only required if you do not want to include control 

strategy data into the program code of your own *.DLL file. 

● WTT files: Value-Type tables contain the SC data types which are to be 

displayed in the SC/Detector protocol or in the signal timing plan window 

and their display properties. 

● Program no.: Select the signal program for simulation. The number of the 

signal program can be entered even while the simulation is running. 

● Debug mode: If this option has been checked, the signal states can be 

observed while the simulation is running. 

External signal controls can provide filenames and paths for the program file, 

for the dialog *.DLL file and for the *.WTT files. Paths which include the 

current data folder (where the *.INP file is stored) or the program folder 

(where the VISSIM.EXE file is stored) are saved as relative path. This way 



they will still work though the data folder might have been renamed or 

copied. 

For a signal control of the External type, the number of the signal program 

can also be entered while the simulation is running. VISSIM automatically 

switches to the new signal program at the next switch point. 

With external controller DLLs, the current cycle second (determined by 

VISSIM for fixed cycle times) is computed on the basis of the start of the 

first cycle at midnight. If 00:00:00 is set as start time, this will not make a 

diference. 

6.7.3.10 Fixed time control 

The external SC type Fixed time control is a fixed time control strategy. The 

Signal Control Editor replaces the original tabular data supply method for 

fixed time controls. The graphical signal program editor allows for changes to 

the signal timing plan. Due to the particular VISSIM license, the signal 

program editor’s add-on VISSIG provides additional functionality beyond the 

VISSIM standard version. 

For Fixed time control, significant changes have been performed and the 

functionality has been extended by various new features, by the VISSIG 

add-on, for example. Please refer to section 6.7.4 for the comprehensive 

description. 

For stage-based fixed time controllers, the greentime optimization can be 

performed, cf. section 6.7.3.11: 

► For the selected fixed time controller via the button START OPTIMIZATION 

in the Signal control window – [FIXED TIME] tab. 

► For all fixed time based controllers in the network via menu SIGNAL 

CONTROL - OPTIMIZATION OF ALL FIXED TIME CONTROLLERS. 

Definition 

Via SIGNAL CONTROL – EDIT CONTROLLERS... open the Signal Control window 

and create a signal control with fixed time control. 

By right-click in the list you can call a context menu. The context menu 

provides the following functions: 

► NEW adds another SC to the list 

► DUPLICATE creates a new SC with the properties of the selected one but a 

new SC no. 

► DELETE removes the selected entry from the list 




For each Signal Controller the following header data is available: 

● Number: Unique ID of the signal controller 

● Name: Optional label or comment 

● Type (control strategy): Defines the controller type and control strategy. 

The number of provided control types depends on the current VISSIM 

license. 

In this window, the Cycle Time and Offset settings for fixed time control are 

not subject to changes. Via the Signal program Editor’s navigator entry 

Signal programs you can define Cycle Time, Offset and Switch point, cf. 


[FIXED TIME] Here, the following parameters have to be set: 

● Program file: File name (VISSIG_CONTROLLER.DLL) of the control 

strategy. (This file is preset automatically and cannot be edited.) 

● Dialog DLL file: File name (VISSIG_GUI.DLL) of the data supply 

interface. (This file is preset automatically and cannot be edited.) 

● Data file 1: Contains the configuration file VISSIG.CONFIG. (This file is 

preset automatically and cannot be edited.) 

These three files are loaded automatically if they are stored in the EXE 

folder of your VISSIM installation. 

● Data file 2: Contains the signal control file *.SIG in XML data format. 

(This file is preset automatically and cannot be edited.) 



When an elder VISSIM network file is read from file, the *.SIG files are 

created automatically. 

The *.SIG files and the VISSIM network file *.INP need to be stored in the 

same directory. 

*.WTT files are automatically loaded. They are not subject to changes. 

● Program no.: Select the signal program for the simulation. The signal 

program can also be a Daily Signal Program List, cf. section 6.7.4.8. 

In the single-step mode, the program can be switched during simulation. 

If the new signal program number is confirmed via OK, the program will 

be switched in the next simulation second. 

● EDIT SIGNAL CONTROL: Via this button, the Signal Control Editor is called, 

cf. section 6.7.4. The signal groups need to be defined and can be 

deleted in the SC Editor. Changes to the channel number of existing 

signal groups are recognized in VISSIM and will be adjusted in the 

appropriate signal heads. 

Since VISSIM 5.20, the Controler Frequency is read from the external 

control data. 

Internally, the controller frequency is the least common multiple of all SC. 

The value may not exceed 10, since VISSIM permits ten simulation steps 

per second at most. 

● START OPTIMIZATION: Click this button to start the greentime optimization 

of the current stage-based fixed-time control, cf. section 6.7.3.11. 

6.7.3.11 Greentime Optimization of Stage-based Fixed-time Control 

This functionality requires the VISSIG add-on. 

This functionality “automatically” improves the goodness of a signal plan for a 

single VISSIG signal control. 

For that purpose, VISSIM runs repeated simulations of the whole network 

with all controllers switched off except a single one. Thus, upstream signals 

have no effect. The simulations continue as long as changes of the stage 

green times increase the flow (total volume) or reduce the average vehicle 

delay. Alternatively, the user can stop the iteration. The stage timings with 

the best result (highest flow / lowest average vehicle delay) are saved in the 

*.SIG file at the end of the optimization. 

You can run the optimization either for the selected SC or automatically for 

all all fixed time SCs: 

► For a single SC, click the button START OPTIMIZATION in the Signal control 

dialog. 



► Start the automatical run for all fixed time SCs, one by one, through the 

menu item SIGNAL CONTROL – OPTIMIZE ALL FIXED TIME CONTROLLERS. 

Prerequisites and Conditions for Application 

The following needs to be defined: 

► In VISSIG: signal groups, an intergreen matrix, stages and a stagebased 

signal program. 

► In VISSIM: signal heads, a surrounding node and adjacent nodes. 

Furthermore, the following applies: 

► The minimum green times and the relevant intergreens should be 

included in the interstages because the optimization can reduce the 

stage length to zero. The signal program still needs to be consistent even 

if all stages show a length of zero. 

► The stage-based signal program has a user-defined cycle time but it can 

have arbitrary stage lengths. It is easiest to use the stage lengths that 

were the default values upon program creation. 

► Select the program number in the Signal Control window in VISSIM. 

► Traffic demand and routing must exist in the VISSIM network, too, i.e. 

vehicle inputs and routing decisions or parking lots and matrices (or a trip 

chain file) and a path file. The routing does not need to be defined as 

static turning movements. Dynamic assignment or static routes passing 

multiple nodes can also be used, since it only is relevant that the vehicles 

traverse the node of the signal controller. 

► Other signal controllers are not regarded. 

Calculation method in VISSIM 

The optimization works in the following way: 

► Using an automatically generated node evaluation, VISSIM determines 

for each signal group and for the complete simulation run the mean delay 

of all vehicles which have passed the node in the particular lanes of the 

signal group, i.e. on their particular turning relations. 

► For the optimization, the signal group at which the vehicles returned the 

greatest mean delay is determined for each stage. 

► Subsequently, the stage with the lowest maximum mean delay is 

selected for the best stage, whereas the stage with the greatest 

maximum mean delay is selected for the worst stage. From the best 

stage, one greentime second is removed, to the worst stage, one second 

is added. If no second is left over to be removed from the best stage, the 

second-best stage will be used. If even this stage cannot be reduced 

anymore, iteratively the next worst one will be used. If no stage is left 

over for further reduction, the optimization is completed. 

► A signal program is always better than another one if the flow (total 

number of vehicles passing the node while the simulation is running) 

either increased significantly (at least by 25 vehicles or by 10%, if this is 

less) or if the flow did not shrink significantly (by 25 vehicles or 10%) and 



the mean delay of all vehicles decreased. If a signal program is rated 

higher than the previous one, the former best signal program is replaced 

by the preferred one and the optimization will continue with another step. 

► Optimization terminates if either the signal program has not improved 

within 10 simulations or if the flow has decreased by more than 25% 

compared to the best signal program hitherto or if the mean delay has 

increased by more than 25%. 

6.7.4 The SC Editor 

The SC Editor has a separate user interface which consists of the following 

window sections: 

Title bar Program name, number of the selected SC and name of the currently loaded 

controller data file *.SIG. 

Menu bar By means of the mouse or using shortcuts the program can be operated. 

Menu commands contain graphical elements indicating a sub-menu or 

window: 

4 indicates a sub-ordinated menu. 

“...“ indicates a sub-ordinated dialog window. 

Toolbar Operating devices for control and editing. 

Scroll bars Shift the current window display horizontally or vertically on screen. 


The Menus 

FILE General data file management: 

Open Import of a configuration file *.SIG 

Export Output to Excel workbook or as file *.PUA 

(Interstage programs in text format for VAP) 

Save Save the VISSIG configuration file *.SIG 

with identical path and file name 

Save As… Save the VISSIG configuration file *.SIG 

with new path and file name 


CTRL+S 

Exit Terminate the VISSIG program session ALT+X 

EDIT Processing commands: 

Undo Discards the previously performed action(s). 

Each step can be dismissed. 

Redo Redoes the previously discarded action(s). 

Each step can be renewed. 

Options… General settings (Common, Optimizations, 

View and Export) 

CTRL+Z 

CTRL+Y 

Options 

This section describes the parameters which need to be set globally. 

Open the Options window via menu EDIT - OPTIONS... 

[COMMON] You may select a Language of the languages which are included in the 

license. By default, the language being currently active in VISSIM is used. 

[OPTIMI- This tab is only provided for users of the VISSIG add-on. 

ZATIONS] Refers to Interstage programs, cf. section 6.7.4.7. 

● Add minimum times in interstage: The target signal states of the 

individual signal groups show at least the minimum duration that has 

been set in the signal groups. 

● Use optimal length in front: If this option has not been checked, the 

green in the beginning of the interstage is terminated when switching 

from green to red. 

● Use optimal length in back: If this option has not been checked, the 

green is only started at the end of the interstage (or at the end of the 

interstage minus minimum duration, respectively) when switching from 

green to red. 



[VIEW] This tab is only provided for users of the VISSIG add-on. 

[EXPORT] 

Refers to Stages, cf. section 6.7.4.3. 

● Show signal group ids: In the stage diagram, the numbers of signal 

groups are displayed. 

● Use compact view: The stage diagram does not show the 

topographical but the diagrammatic display. 

Refers to Signal programs and interstages, cf. section 6.7.4.6 and 6.7.4.7. 

● Appearance: Please select one of the following options: 

- Classic 

- 3d tubes 

- 3d boxes 

● Resize automatically: In case of changes to the window height the 

data line height is adjusted automatically. 

● Show full interstage name in the stage based signal pograms: 

Instead of the number of an interstage, its name is displayed. 

This tab is only provided for users of the VISSIG add-on. 

It contains the Common export parameters. 

● Render mode: You may select one of the view modes: 

- Fixed width 

- Fixed scale (Pixel per second) 

● Signal group height: Here you can globally predefine the height of 

signal groups (in Pixel) for any graphics export actions. 



Export parameter settings for Signal programs 

● Picture width: Enter the width of the image to be exported (in Pixel). 

● Pixel per second: Enter the number of pixels representing a second in 

the export image. 

Export parameter settings for Interstages 

● Picture width: Enter the width of the image to be exported (in Pixel). 

● Pixel per second: Enter the number of pixels representing a second in 

the export image. 

Export parameter settings for Stage sequence 

● Stage width: Enter the width of the image to be exported (in Pixel). 

The Symbol bar 

Due to the navigator entry and the selected editing view, the following 

buttons can be accessed: 

Return to the Signal Control window in VISSIM 

Save CTRL+S 

Undo CTRL +Z 

Redo CTRL +Y 

Go to previous view 

Go to next view 

New 

Duplicate 

Edit 

Delete 

Signal states and Signal state sequences 

At present, the following signals are available: 

Signal states Graphical display 

Red 

Red/Amber 

Green 



Signal states Graphical display 

Amber 

Flashing Green 

Flashing Amber 

Off 

For each signal state being displayed, the signal state sequence defines 

whether it is a green state or a red state. Furthermore it defines, whether the 

signal state is of the variable type and contains the value of the duration (or 

the minimum duration respectively) of the signal state in the default 

sequence. For each signal group, the preset minimum duration can be 

edited. 

Signal state 

sequence 

Permanent red 

Permanent green 

Red-Red/Amber- 

Green-Amber 

State Green Fixed 

duration 

Minimum 

duration 


x 

1 

x 5 

Red-Green 1 

Red-Red/Amber- 

Green- Flashing 

Green-Amber 

Red-Green- Flashing 

Green 

3 

x 5 

1 

x 5 

x 4 

3 

x 5 

x 4 

1 

1 

1

Signal state 

sequence 

State Green Fixed 

duration 


Minimum 

duration 

Red-Green-Amber 1 

Off (Flashing Amber) 

Off (Off) 

6.7.4.1 Editing Signal Groups 

x 5 

In the navigator, click Signal groups to call the list of signal groups. 

Right-click in the list calls the context menu. It provides the following 

functionality: 

► NEW adds another SG with the first free channel number to the list and 

places it accordingly in the list 

► DUPLICATE creates a new SG with the properties of the selected one but a 

new SG no. 

► EDIT allows for modifying the data of the selected SG 


User Manual © PTV AG 2011 305 

3


To the new signal groups, the signal state sequence Red-Red / Amber- 

Green-Amber is assigned. To ease data input the following is 

recommended: Create a signal group for each of the required signal group 

types, supply their standard signal sequence and duplicate this template 

finally as often as necessary. 

Furthermore, you may edit the list as follows: 

● No.: Double-click in the column and edit the number of the signal group. 

● Name: Double-click in the column and edit the name of the signal group. 

● Notes: Double-click in the column to call the editing view. You may enter 

a comment describing the signal group. 

The editing view 

Here you may change the parameters of the particular signal group as 

follows: 

● Name: Short “speaking” name of the signal group. 

● Default sequence: Except for permanent signal sequences, any signal 

state sequence mentioned in section ● can be selected: 

- Red – Red / Amber – Green - Amber 

- Red - Green 

- Red – Red / Amber – Green - Flashing Green - Amber 

- Red – Green - Flashing Green 

- Red – Green - Amber 

If option Add minimum times in interstage has been checked via menu 

VIEW - Options - [OPTIMIZATIONS], increasing the duration of either the 

minimum green or increasing the duration of a fixed state may force the 

recalculation of particular interstages. Prior to storing the new data it is 

checked which of the interstages have to be recalculated. The appropriate 

query appears, if applicable. 

Also changes to current optimization settings or to stages may lead to 

recalculations which are not caused by the changes themselves. 

● Default durations: Graphical display of the signal state sequence. The 

particular value of the signal state is shown. Double-click for value 

modification. 

● Notes: Enter a comment describing the intended usage of the signal 

group. 



In the editing view of a signal group the signal state sequence can be edited 

and also the Default durations of this signal state sequence. For signal states 

with a variable duration in the signal state sequence, the entered value is 

regarded as minimum duration. Otherwise it is regarded as duration. 

In this way you can supply for instance 2 seconds Red-Amber, 5 seconds 

Amber for 70 km/h permitted speed (in Germany) or 15 seconds Minimum 

Green for a heavily loaded straight flow. The editing view can be accessed 

from the navigator, via the context menu or by double-click in one of the noneditable 

columns of the particular row in the list. 

6.7.4.2 Editing Intergreen Matrices 

Intergreen is the time that is required to elapse between the Green End of a 

clearing flow and the Green Start of an entering flow. Keeping the intergreen 

guarantees that the clearing flow will not come into conflict with the entering 

flow. 

Conflicting flows and intergreens cannot be calculated. During intergreen 

data input no checks are performed, especially the symmetry of intergreen 

matrices is not checked. 





► NEW adds another intergreen matrix to the list 

► DUPLICATE creates a new intergreen matrix with the properties of the 

selected one but a new no. 

► EDIT allows for modifying the data of the selected intergreen matrix 



● No.: Double-click in the column and edit the number of the intergreen 

matrix. 

● Name: Double-click in the column and edit the name of the intergreen 

matrix. 

● Default: The default intergreen matrix selected via Stage assignments is 

marked by x. Double-click in the column to call the particular editing view. 

To each signal group-based signal program a separate intergreen matrix can 

be assigned. One of the intergreen matrices can be marked as default via 

Stage assignments in the navigator, cf. section 6.7.4.4. This way it will be 

taken into consideration when stages, interstages and stage-based signal 

programs are created. 


You may edit the properties of the selected intergreen matrix as follows: 

● Name: Short “speaking” name of the intergreen matrix. 

To edit an intergreen value, mark a cell or double-click. Gray-shaded cells do 

not contain data. 



Marking a cell in the table will also highlight the corresponding cell in the 

opposite triangle of the matrix. 

Importing intergreens from Excel 

Interstage data can be imported from Microsoft Excel. For example, if 

you have already exported an Excel workbook (cf. section 6.7.4.10), you can 

use Copy & Paste to use the intergreen matrix data in an existing or a new 

matrix. 

Follow the steps outlined below to copy the Excel data to a new matrix which 

does not contain data yet: 

1. In the navigator, click intergreen matrices. 

2. In the context menu, select NEW to create a new intergreen matrix. 

An empty matrix is created with the name intergreen matrix. 

3. Edit name or number of the intergreen matrix, if aplicable. 

4. Skip to your Excel file. 

5. In the intergreen matrix, open 

a work sheet that contains the 

data which you would like to 

use. 

6. Hold down the left mouse key 

while marking the rows and 

columns that contain data. 

7. Press STRG+C to copy the 

marked data. 



8. Skip to the editing view of the new intergreen 

matrix. 

9. Click the top left cell of the matrix. 

The entire matrix is highlighted in blue. 

10. Press CTRL+V. 

The values are entered in the new matrix. 

You may also copy particular sections from the Excel table to the 

intergreen matrix. In this case make sure, that source section and target 

section (rows/columns) are identical. 

The cells in the matrix diagonal (gray-shaded) may not contain data. 

Pasting will be cancelled if data is copied to the diagonal. 

6.7.4.3 Editing Stages (VISSIG add-on) 

Click Stages in the navigator to call the list of stages. 

Right-click in the list of stages calls the context menu. It provides the 

following functionality: 

► NEW adds another stage to the list to which the first free number is 

assigned. The stage is placed accordingly in the list. 

► DUPLICATE creates a new stage with the properties of the selected one 

but a new number. 

► DELETE removes the selected entry from the list. 


● No.: Double-click in the column and edit the Stage number. 

● Name: Double-click in the column and edit the Stage name. 



● Pseudo stage: The duration of a stage which has been marked as 

pseudo stage is always 0 seconds in any stage-based signal program, cf. 


Only for stages without any allocated interstage the pseudo stage option 

can be checked. 

Nevertheless, this option can be unchecked at any time. 

● Stage diagram: Graphical stage display. 

For display of direction indicating arrows, nodes are required in VISSIM. 

One for the analyzed node and one for each neighbouring node. These 

nodes have to be selected for Node evalulation. 

6.7.4.4 Editing Stage Assignments (VISSIG add-on) 

Via Stage assignments in the navigator, you can either permit or block each 

of the signal groups or mark their status as not relevant. 

In the Intergreen matrices table, the selected matrix is marked as Default. 

This matrix has to be selected in the Intergreens selection list via Stage 

assignments in the navigator. 

Double-click in a cell or click an arrow in the graphical display to change the 

state of the stage’s signal group. The cycle includes the following states: 

Signal group is permitted in this stage 

Signal group is blocked in this stage 

The state of the signal group is not relevant in this stage (in case of 

partial junction control, for example) 

After selection of a default intergreen matrix, the generated stages are 

checked for conflicting flows. Permitted conflicting signal groups within a 

stage are highlighted red in this table. 



Display options 

Click and move the separator between 

tabular and graphical display to 

change the width of the two window 

sections. The display is adjusted 

immediately. 

Via the graphics context menu you 

may toggle between the list of all 

stages and the enlarged display of the 

selected stage. 

Via the context menu or via menu EDIT - OPTIONS - [VIEW] tab, you may 

enable or disable the display of direction-indicating arrows (without or without 

signal group numbers), cf. section ●. 

These view settings are also regarded for the list of stages and the stage 

sequence editing window as well as for the graphical export of stage 

sequences. 


6.7.4.5 Editing Stage Sequences (VISSIG add-on) 


Via Stage sequence editing in the navigator, you can create signal programs 

and interstages. 

The window consists of two sections. 

The upper section serves for display of defined stages as well as for 

interstage calculation and stage sequence definition. 

1. For calculation of an interstage, click the From-Stage first and then leftclick 

while pressing CTRL simultaneously to select the To-Stage. The 

stages are marked by 1 and 2. In the context menu, select the CREATE AN 

INTERSTAGE command. The created interstage wil be displayed in the 

lower section of the window. 

Between two stages, multiple interstages can be defined (e.g. with/without 

minimum duration). 

In VISSIG, a signal group can be switched only once per interstage, i.e. the 

signal group can change from permitted to blocked or vice versa. 

To model an interstage which allows for switching a signal group twice, a 

pseudostage has to be defined in VISSIG and two interstages have to be 

added (one directly before the pseudostage and the other one following the 

pseudostage), cf. section 6.7.4.3. 



2. Furthermore, you can define a stage sequence for signal program 

calculation in the upper window: 

- Click while pressing CTRL simultaneously to select the desired stage 

sequence. Click CREATE SEQUENCE in the context menu to create the 

stage sequence which will be displayed in the lower section. 

- To add another stage to the defined stage sequence, mark a single 

stage and select ADD TO SEQUENCE in the context menu or doubleclick 

the stage to be added. 

In the lower section of the window, the currently selected stage sequence is 

displayed. 



Double-click a stage or click Remove stage in the context menu to remove 

the selected stage from the sequence. 

CLEAR SEQUENCE in the context menu will delete the stage sequence 

completely. 

The context menu command EXPORT… allows for stage sequence export as 

an image file. Set the format options for the image file via menu EDIT - 

OPTIONS in the [EXPORT] tab, cf. section 6.7.4.10. 

To create a signal program with fixed cycle times from the stage sequences, 

the following options are provided: 

● Cycle time tu: Enter the duration in seconds. 

● CREATE STAGE BASED SIGNAL PROGRAM: Click this button to calculate a 

stage-based signal program for a predefined cycle time. The Signal 

programs editing view appears and allows for further signal program 

editing, cf. section 6.7.4.6. 

● CREATE SIGNAL GROUP BASED SIGNAL PROGRAM: Click this button to 

calculate a signal group-based signal program for a predefined cycle 

time. The Signal programs editing view appears and allows for further 

signal program editing, cf. section 6.7.4.6. 

You may manually define the interstages to be used for signal program 

calculation. Right-click the dark-gray space between the two desired stages 

and click INTERSTAGES - CREATE… in the context menu or select an existing 

interstage. 

These steps are performed if the interstages were not manually selected: 

For each stage changeover in the sequence of stages it is checked whether 

there is already an appropriate interstage. If so, the first matching interstage 

is used for the calculation, otherwise a new interstage will be created. The 

new interstage will be stored for stage-based signal programs, whereas it will 

be deleted after signal program calculation in case of signal group-based 

signal programs. 



Double-click an interstage to call the Interstage editing view for it. Click to 

return to Stage sequence editing. 

Click and move the separator between the two window sections to change 

the size of the two sections. 

6.7.4.6 Editing Signal Programs 

Signal programs have a name and a number and also a cycle time, an offset 

for synchronization (e.g. for progressive signal systems) and a switch point 

that allows for changing to another signal program at a certain instant, in a 

daily signal program list, for example. 

If an intergreen matrix has been assigned to a signal program, the 

compliance with the intergreens can be observed and retained during signal 

program editing. Intergreen violations will be highlighted automatically. 



The list called via the navigator entry Signal programs can contain signal 

group-based signal programs and stage-based (VISSIG required) signal 

programs as well. In Italic letters, the particular type is displayed by signal 

program in the navigator tree view. 

Stage-based signal programs can only be created from stage sequences. 

Signal group-based signal programs can also be created in the list. 



► NEW adds another signal program to the list 

► DUPLICATE creates a new signal program with the properties of the 

selected one but a new signal program no. 

► EDIT allows for editing the data of the selected signal program 


► EXPORT allows for image file export of the selected signal program 

You may edit the list as follows: 

● No.: Double-click in the column and edit the Signal program number. 

● Name: Double-click in the column and edit the Signal program name. 

● Intergreens: The used intergreen matrix is displayed. Double-click calls 

the editing view for further changes. 

● Cycle time tu: Duration of a cycle in seconds. Double-click calls the 

editing view for further changes. 

● Offset: For synchronization (e.g. for progressive signal systems). Doubleclick 

calls the editing view for further changes. 

● Switch point: Allows for switching between two signal programs. It is 

required, that all signal groups of both signal programs show the same 



signal state at that time. Double-click calls the editing view for further 

changes. 


Signal group-based signal programs allow for modification of the individual 

signal groups and/or signal times. For graphical editing, the mouse can be 

used, alternatively, listed data can be edited. The display modes of list 

columns and signal states can be edited with the help of the context menu. 

Right-click calls the context menu which provides the following commands: 

● EXPORT (VISSIG add-on required): 

Graphical output of the signal program, cf. 

section 6.7.4.10. 

● APPEARANCE: For signal program display, 

the following options are provided: 

- CLASSICAL 

- 3D TUBES 

- 3D BOXES 

● RESIZE AUTOMATICALLY: In case of changes to the window size the data 

row size is adjusted automatically. 

● SHOW ENTIRE SIGNAL PROGRAM: Redraws the signal program and adjusts 

the data row size to the window size. 

● EDIT SIGNAL STATES: Select a row and hold left mouse-key down while 

moving the first or the last point of a signal state of variable duration. This 

editing mode you can also select in the symbol bar. 

● STRETCH/COMPRESS: Select a row and hold left mouse-key down in the 

time axis label section to stretch (move pointer to the left) or compress 

(move pointer to the right) the signal state display. This editing mode you 

can also select in the symbol bar. 

● EXTRACT INTERSTAGE (VISSIG add-on required, provided only for signal 

group-based signal programs): In the graphical display, you can cut out 

any interstage. If EXTRACT INTERSTAGE is selected, the cursor will appear 

as a cross in the tu column headers section. Hold left mouse-key down 

and mark the section you would like to extract. The selected interstage 

appears in the editing view, cf. section 6.7.4.7. This editing mode you 

can also select in the symbol bar. 

● SECOND GREEN TIME (provided only for signal groupbased 

signal programs): You can add another 

green time. 


A second green time can only be defined via context menu. 


● EDIT COLUMNS… (provided only for signal group-based signal programs): 

The Select time columns to be displayed window appears. 

● Not selected columns 

are listed on the left. 

● Selected columns are 

listed on the right. 

● Use the buttons and 

to add further 

columns to the selection 

or to remove selected 

columns from it. 

You can change the height of rows: 

1. Click in the desired row. 

2. In the first gray column, move the pointer over the margin 

until it appears as a bi-directional arrow. 

3. Hold left mouse-key down while dragging the margin of the row up or 

down. 

Use the multiselect functionality (press CTRL while marking the rows) to 

change the height of multiple rows simultaneously. 

In the symbol bar of the editing view, the editing functionality can be selected 

via the following icons: 

Signal group-based editing 

Stretch/Compress 

Extract interstage program (VISSIG add-on required) 



Signal 

state 

editing 

You can define the format of the graphical display with the help of the context 

menu and via menu EDIT - OPTIONS - [VIEW] tab, cf. section ●. 

Follow the steps outlined below to edit the cycle times of a signal group 

graphically: 

1. Click the EDIT SIGNAL STATES icon. This functionality you may also 

select in the context menu. 

2. Click the desired row. 

3. As long as the pointer is moved over the displayed cycle times, you 

may select one of the options which are indicated by the particular 

pointer: 

View Description 

Hold the left mouse-key down while dragging the entire 

signal state with variable duration to the desired position. 

Hold the left mouse-key down while dragging the begin or 

the end of a signal state with variable duration to the 

desired point in time. 

Signal states with fixed duration cannot be shifted directly. 

As long as a state is shifted, reserve times are indicated by 

a green background and intergreen violations are indicated 

by an orange background. 

With the pointer in the time axis labels section, you may 

shift the entire signal program (or the zero point of the 

signal program). 


Stretch or 

compress 

a signal 

program 

Extract and 

save 

interstage 


While shifting, the pointer may not be removed from the particular section. 

Otherwise shifting is cancelled. 

The duration of each amber state can be edited separately in the table of the 

currently edited signal program if the duration differs from the user-defined 

default value of this signal group (e.g. adverse weather settings). For display 

of special programs, you may also edit the stage sequence. 

Follow the steps outlined below to stretch (or compress) a signal program: 

1. Click the STRETCH/COMPRESS icon. This functionality you may also 


2. As long as the pointer is moved in the time axis labels section, you may 

select one of the options: 


Compressing a signal program: Within the time axis label 

section, move the pointer to the left while holding the left 

mouse-key down. The section highlighted in red will be cut 

out. 

Stretching a signal program: Within the time axis label 

section, move the pointer to the right while holding the left 

mouse-key down. The duration of the section highlighted in 

green will be added in front of the section marked in green. 

If this operation cannot be perfomed (e.g. for minimum 

duration violation) the marked section is displayed with a 

gray background. 

To cancel a STRETCH/COMPRESS operation, release the mouse-key outside 

of the time axis label section. 

Follow the steps outlined below to cut a signal program: 

1. Click the EXTRACT INTERSTAGE icon. This functionality you may also 


2. In the time axis labels section, move the pointer to the right while 

holding down the left mouse-key: 


Valid interstage: Indicated by a green background. 

Release the mouse-key while the pointer is in the time axis 

label section to skip to the interstage editing view 

automatically. The interstage is stored. 



VISSIG 

add-on 


For the extracted interstage, the From-Stage and the To- 

Stage are created if these are missing. These can be 

edited immediately or in future, cf. section 6.7.4.7. 

Irrelevant interstage: Indicated by a gray background (for 

example if the amber state was not marked completely). 

The interstage cannot be stored. 

Just a single signal stage change per signal group: If a 

second green state has been marked additionally, the 

background appears gray The interstage cannot be stored. 

To cancel an EXTRACT INTERSTAGE operation, release the mouse-key 

outside of the time axis label section. 

Special case: Editing stage-based signal programs 

For editing a stage-based signal program the VISSIG add-on is required. 

In stage-based signal programs, signal times cannot be edited individually. 

► EDIT SIGNAL STATES allows for shifting the temporal position of stages 

within the signal program. Follow the steps outlined below: 


Shift the begin or end mark in the time axis label section. 

Shift the name of the interstage in the time axis label 

section. 

Shift the interstage within the signal program (only 

possible, if the interstage´s duration exceeds 0 seconds). 

For interstages, the duration of a state is predefined by the particular 

default value in the signal group definition. 

► STRETCH/COMPRESS can be applied to each stage separately. 

► EXTRACT INTERSTAGE cannot be applied to stage-based signal programs. 


Zoom in 

the signal 

program 

display 


For more precise changes to individual signal times you may zoom into a 

user-defined section of the displayed signal program (for example in case 

of controller frequency = 10 with possible switch points every 1/10 

seconds). 


1. Mark a row in the table. 

2. Click the graphical display area of the selected 

row. 

The pointer appears as hand. 

3. Click the scroll wheel in the graphical display area of the selected row to 

extend the time axis display next to the click position. 

4. Click the scroll wheel again to reset the zoom. 

Toggle between the two states. 

6.7.4.7 Editing Interstages (VISSIG add-on) 

Interstages can only be created via entry Stage sequence editing in the 

navigator (cf. section 6.7.4.5). Via entry Interstages in the navigator, they can 

be duplicated, edited, exported and deleted. 



► DUPLICATE creates a new interstage with the properties of the selected 

one but a new no. 

► EDIT allows for editing the data of the selected interstage 


► EXPORT allows for image file export of the selected interstage 



You may edit the list as follows: 

● No.: Double-click in the column and edit the Interstage number. 

● Name: Double-click in the column and edit the Interstage name. 

● From stage: The previous stage of the interstage. Double-click calls the 

associated editing view of the interstage. 

● To stage: The target stage of the interstage. Double-click calls the 

associated editing view of the interstage. 

Editing the signal times of interstages is similar to editing the signal times of 

signal group-based signal programs. Please refer to section 6.7.4.6. 


Right click to call the context menu which provides the following functionality: 

● EXPORT: Graphical output of the 

signal 

6.7.4.10. 

program, cf. section 

Via menu FILE - EXPORT - PUA you can export interstages in PUA format 

which is required for a VAP control strategy, for example. 

● APPEARANCE: For signal program display, the following options are 

provided: 



- CLASSICAL 

- 3D TUBES 

- 3D BOXES 

● RESIZE AUTOMATICALLY: In case of changes to the window height the data 

row height is adjusted automatically. 

● SHOW ENTIRE SIGNAL PROGRAM: Redraws the interstage and adjusts the 

data row height to the window height. 

The properties of the selected interstage can be edited: 

● Name: The name is taken from the stage sequence selected via Stage 

sequence editing in the navigator, cf. section 6.7.4.5. This name is 

subject to changes. 

● From stage: In the list, another origin stage can be selected. Selecting a 

new stage automatically starts the recalculation of the interstage. 

● To stage: In the list, another target stage can be selected. Selecting a 

new stage automatically starts the recalculation of the interstage. 

Appropriate origin or target stages are indicated by the following colors in 

the selection list: 



Blue background: Indicates the selected stage. 

Magenta background: Mouse-over on an interstage, 

which does not match the stage. The 

selection leads to an automatic recalculation of 

the interstage. 

White background: The selection does not lead to 

an automatic recalculation of the interstage. 

Red background: The selection leads to an automatic 

recalculation of the interstage. 

White background: The selection does not lead to 

an automatic recalculation of the interstage yet. 

Black line: The stage is not relevant. 

Via double-click in the stage area of a signal 

group the state of this signal group can be 

switched in the stage. The interstage is 

recalculated automatically. 

● Duration: In the selection list, you may edit the duration of the interstage. 

In each case, the difference between original and new value is added or 

subtracted at the end of the interstage. You may reduce the duration, but 

you may not undercut the longest duration of a fixed signal state (amber / 

red-amber state). 

If the stage of a signal group is not relevant in either source stage or target 

stage when calculating an interstage, then the signal will not be changed 

for this signal group. Within the interstage, the same signal state will be 

displayed as for the relevant stage. If the state of a signal group is not 

relevant in either source stage or target stage, then also within the 

interstage the signal state will be displayed as being not relevant. 

6.7.4.8 Editing Daily Signal Program Lists (VISSIG add-on) 

Via Daily Signal Program lists in the navigator, you can create multiple 

variants of a temporal sequence of existing signal programs for user-defined 

time intervals and store these variants as daily signal program lists. 



By means of daily signal program lists, you can switch to other signal 

programs while the simulation is running. For that purpose, not a signal 

group number has to be entered for program number, but the number of a 

daily signal program list. 

In the context menu, click NEW to create a new daily signal program list. 

Alternatively, you can select an existing list and click DUPLICATE, EDIT or 

DELETE, as applicable. 

Please note, that signal programs and daily signal program lists share the 

same numbering scheme. 

When a daily signal program list is created, numbering starts from the first 

free number. This default can be replaced by a number that is not yet in 

use for a signal program. 


Click in a row of the displayed table of daily signal program lists to call the 

editing view for this daily signal program list. 



Via the context menu, create a NEW time interval, or DELETE the marked time 

interval. 

Create or edit a daily signal program list: 

● Name: Name of the daily signal program list (optional). 

● Time: Select the instant (in hh:mm:ss format), when the time interval 

starts during which the allocated signal program is valid: 

Mark either hh or mm or ss and use the arrow keys UP (along the time 

axis) or DOWN (reverse direction). 

If the daily signal program list does not cover the whole day, then add the 

final instant to the end of the list and allocate No Signal Program for the 

rest of the day. For the interval from midnight until the first time entry, 

VISSIM automatically assumes No Signal Program. 

● Signal Program: In the selection list, pick the signal program which is to 

be regarded during the particular time interval. Signal programs of either 

type (stage-based or signal group-based) can be selected for daily signal 

program lists. 

● Notes: Comment on the daily signal program list (optional). 

If the change from one signal program to the next is marked by a red dot, 

the switch point between the two has to be adjusted. Edit one of the signal 

programs or both, if applicable, so that the states of the two signal 

programs are coordinated for the change. 


6.7.4.9 Detecting Inconsistent Planning Scenarios 


Caused by the interdependencies between the individual data objects, 

changes to the properties of an object may lead to inconsistencies in objects 

that depend on the modified object. Those inconsistencies are explicitly 

permitted to prevent the operator from any restrictions. To support the 

operator’s efforts for consistent planning, the following checks and 

mechanisms have been implemented though: 

► Changes to intergreens may cause intergreen violations in the 

associated signal programs and/or interstages. Those violations are 

highlighted graphically in the object data display. 

► Adding further conflicts may 

result in invalid stages. Cells 

with conflicting green are highlighted 

red in the table that can 

be called via Stage assignments 

in the navigator. 

► Changes to stages may lead to invalid interstages due to the new initial 

state (or target state) of a signal group. The following two cases have to 

be distinguished: 

1. The associated interstages will remain consistent, if the state of a 

signal group is changed from either green or red to not relevant. 

Since the interstage is still consistent, another selection of the edited 

stage will not start a recalculation of the interstage. To force 

recalculation, select any other stage first and select the edited stage 

then in this case. 



In stage 2, the state was changed from blocked to not relevant for N RS and S RS. 

2. Associated interstages usually become inconsistent, if the state of a 

signal group is changed to either green or red. Inconsistent 

interstages are indicated by red bars in the navigator tree view. 

In stage 2 the state of S RS has been changed from blocked to permitted. 

► In the editing view of an inconsistent interstage, the schematic display of 

the stage that caused the inconsistencies is highlighted in red. Also the 



diverging stages are marked by red color in the rows. Select the red 

stage explicitly to start the recalculation of the interstage to reach 

consistency with the modified stage. 

► Changes to interstages may lead to inconsistencies in the associated 

stage-based signal programs. These inconsistencies are indicated by red 

signal program names in the navigator tree. 

► Rows with inconsistent stage sequences caused by changes to the 

interstages are indicated by an exclaimation mark in the editing view. 

The inconsistent section is marked in red. 

The earlier change of stage 2 (described above) leads to a recalculation of interstage 2 

when explicitly selecting stage 2 once again. 

6.7.4.10 Export Functions 

Export as graphics file 

Stage sequences, signal programs and interstages can be exported as 

image files. 

The following file types are supported: 

● *.BMP 

● *.GIF 

● *.JPG 



● *.PNG 

● *.SVG (vector graphics) 

● *.TIF 

Graphic format settings are provided via menu EDIT - OPTIONS - [EXPORT], cf. 


Exporting a stage sequence 

Follow the steps outlined below for export of the displayed stage sequence: 

1. Create a stage sequence, cf. section 6.7.4.5. 

2. Right-click to call the context menu. 

3. Click the EXPORT command in the context menu. 

The Save as window opens. 

4. Select the folder for the image file. 

5. Enter the file name. 

6. Select the file type. 

7. Click SAVE. 

Exporting signal programs 

Follow the steps outlined below for export of displayed signal programs: 

1. Select Signal programs in the navigator and select a program in the list. 










Exporting interstages 

Follow the steps outlined below for the export of the displayed interstages: 

1. Select Interstages in the navigator and select an interstage in the list. 










Export as *.PUA file (VISSIG add-on required) 

The *.PUA file is a VISSIG output file which serves as input file for a VAP 

control strategy. Interstages can be exported in the PUA format. 

Follow the steps outlined below to export interstages as a *.PUA file: 

1. Select menu FILE - EXPORT - PUA. 

The VISSIG PUA Export window appears. 

Settings which do not comply with the PUA format conventions (e.g. blanks 

in the filename of a signal group) are listed in the separate Export window. 

Measures for correction according to the conventions are also displayed. 

The PUA export will continue once the Export window is closed. 

2. In the VISSIG PUA Export 

window click the button 

next to Save as. 

The Save as window appears. 

3. Select the output folder. 



6. Select the start stages in the 

VISSIG PUA Export window. 

7. Click EXPORT. 

The file *.PUA is created with the given filename and will be stored in the 

chosen directory. 

Export to Microsoft Excel (VISSIG add-on required) 

You can save any fixed time control data as an Excel workbook. 

Export the workbook as follows: 

1. Select menu FILE - EXPORT - EXCEL WORKBOOK. 

The Save as window appears. 

2. Select the appropriate folder. 





The Excel file is saved with the extension *.XLSX (Format: Microsoft 

Excel 2007). Subsequently, you can use Microsoft Excel 2003 to 

open this file after conversion into an elder data format. Therefore you have 

to install the Microsoft Office Compatibility Pack which can be 

downloaded via Microsoft Download Center (www.microsoft.com). 

The *.XLSX file can also be opened in Calc (OpenOffice.org). Prior to data 

editing in Calc, you should save the file with a new filename in Calc format. 

Creating a Microsoft Word document 

In the folder \EXAMPLES\TRAINING\SIGNALCONTROL\MANUAL 

EXAMPLE.VISSIG\ENG you can find an example and a brief instruction on 

how to include the exported image files and the data from the Excel file in 

a traffic engineering paper. 

6.7.5 Changing the Signal Control Type 

The type of signal control can be switched from fixed time to actuated control 

or vice versa after the initial setup. However, some of the required input 

parameters such as Red End, Green End etc. may be missing depending on 

the new and previous control type. These parameters can be defined in the 

Signal Groups window. Parameters that are no longer used with the new 

control type are lost and need to be re-entered in case the control is switched 

back. 

6.7.6 Signal Control Communication 

Any two Signal Controllers that support communication with other controllers 

can be linked (similar as a wire link between two controllers). 

Click SIGNAL CONTROL - COMMUNICATION 

Using the buttons to the right, 

connections can be created, edited 

and deleted. See below on how to 

establish a new connection. 



Each connection is directed from an output channel 

number of one SC to an input channel number of 

another SC. Data written by the control program to 

an output channel is transmitted in the simulation 

second to the connected input channel and can be 

read from its control program. 

Example (using controller type VAP) 

Define the SC communication from SC 1, channel 7 to SC 3, channel 5. In 

the control logic the following commands can be used to send and receive 

data: 

► Within the control logic of SC 1 the command below will set the output 

value of channel 7 to 1: 

Marker_Put( 7, 1 ) 

► One simulation second later, the control logic of SC 3 can read this value 

through channel 5 using the following command: 

Value := Marker_Get( 5 ) 

The user-defined variable “Value” will then be set to 1 and can be used 

for subsequent program commands. 

6.7.7 Railroad Block Signals 

Railroad block signals can be edited only directly in the VISSIM network file 

(INP). A signal head that is defined as a block signal ("Blocksicherung") does 

not belong to a signal group or signal controller but is switched according to 

the state of the next two signal groups downstream. 

Every block signal determines once per time step the status of the next two 

adjacent blocks downstream (a block is defined as the area between two 

block signals). The signal appears as follows: 

► Red in case of a vehicle occupying the next immediate block 

downstream 

► Amber if the next block is unoccupied and the following block is 

occupied by a vehicle 

► Green if both downstream blocks are empty 

All vehicles passing a block signal displaying amber receive the associated 

maximum speed until they approach a block signal displaying green. 

Railroad block signals count normal signal heads as block delimiters but do 

not influence the states of those signals. 

The definition of a railroad block signal will look like the line below: 



SIGNAL_HEAD 912 NAME "" LABEL 0.00 0.00 BLOCK_SIGNAL DESIRED_SPEED 25.00 

POSITION LINK 1 LANE 1 AT 558.020 VEHICLE_CLASSES ALL 

The speed 25.00 (km/h) refers to the maximum speed at an amber signal; 

the position 558.020 (meters) refers to the position along link 1 where the 

signal head is located. The link and signal head numbers refer to the link and 

signal head defined in the model. 


7 Simulation of Pedestrians 

In VISSIM, the movement of pedestrians is based on the Social Force Model 

(Helbing and Molnár, 1995). The basic idea is to model the elementary 

impetus for motion with forces analogously to Newtonian mechanics. From 

the social, psychological, and physical forces a total force results, which then 

sums up to the entirely physical parameter acceleration. The forces which 

influence a pedestrian’s motion are caused by his intention to reach his 

destination as well as by other pedestrians and obstacles. 

Prof. Dr. Dirk Helbing from ETH Zurich acts as scientific advisor for PTV AG. 

For the use in VISSIM the Social Force Model was specially expanded by 

him. 

This simulation model was validated in a threefold way: firstly, macroscopic 

parameters were calculated and compared to empirical data, secondly it was 

assured that microscopic effects like lane formation in counterflow situations 

and stripe formation in crossing flow situations are reproduced, and thirdly a 

realistic impression of resulting animations was in the focus. 



For pragmatic reasons, the behaviour of pedestrians is often classified 

hierarchically into three levels (Hoogendoorn et al. 2002): 

► On the strategic level (minutes to hours), a pedestrian plans his route. He 

generates a list of destinations. 

► On the tactical level (seconds to minutes), the pedestrian decides on the 

route between the destinations, making a rough routing decision. 

► On the operational level (milliseconds to seconds), the actual movement 

is performed. This includes evading opposing persons, moving through a 

dense crowd, or simply continuing the movement toward the destination. 

Here, the Social Force Model controls the operational level and parts of the 

tactical level, whereas the strategic level is defined by the user input. 

Literature 

D. Helbing and P. Molnár (1995). Social force model for pedestrian 

dynamics. In Physical Review E 51(5), p. 4282-4286. 

D. Helbing, I. Farkas, and T. Vicsek (2000). Simulating dynamical features 

of escape panic. In Nature, 407, p. 487–490. 

D. Helbing, I.J. Farkas, P. Molnar, and T. Vicsek (2002). Simulation of 

Pedestrian Crowds in Normal and Evacuation Situations. In Schreckenberg 

and Sharma (2002), p. 21–58. 

T. Werner and D. Helbing (2003). The Social Force Pedestrian Model Applied 

to Real Life Scenarios. In Galea (2003), p. 17–26. 

A. Johansson, D. Helbing, and P.K. Shukla (2007). Specification of the 

Social Force Pedestrian Model by Evolutionary Adjustment to Video Tracking 

Data. In Advances in Complex Systems 10(4), p. 271–288. 

S.P. Hoogendoorn, P.H.L. Bovy and W. Daamen (2002). Microscopic 

Pedestrian Wayfinding and Dynamics Modelling. In Schreckenberg and 

Sharma (2002), p. 123-154. 

M. Schreckenberg and S.D. Sharma (Editors) (2002). Pedestrian and 

Evacuation Dynamics, Duisburg, January 2002. Springer Berlin Heidelberg. 

E.R. Galea (Editor) (2003). Pedestrian and Evacuation Dynamics: 2nd 

International Conference, Old Royal Naval College, University of Greenwich, 

London, CMS Press. 

A. Schadschneider, W. Klingsch, H. Klüpfel, T. Kretz, C. Rogsch, and A. 

Seyfried. Evacuation Dynamics: Empirical Results, Modeling and 

Applications. In R.A. Meyers (Editor), Encyclopedia of Complexity and 

System Science. Part 5, p. 3142. Springer, Berlin Heidelberg New York. 

(2009). 

D. Helbing and A. Johansson. Pedestrian, Crowd and Evacuation 

Dynamics. In R.A. Meyers (Editor), Encyclopedia of Complexity and System 

Science. Part 16, p. 6476. Springer, Berlin Heidelberg New York. (2009). 


7.1 The Pedestrians Editor (Add-on) 

VISSIM can be used in two modes: 

► Vehicle traffic mode 

► Pedestrian traffic mode 

The Pedestrians Editor (Add-on) 

In the toolbar, the PEDESTRIAN EDIT MODE button serves for toggling 

between these two modes. 

When the Pedestrian traffic mode is activated, the Pedestrian Elements 

toolbar for the Pedestrian traffic mode appears. 

► The Network Elements toolbar for the Vehicle traffic mode is faded out. 

► Only common toolbars (Navigation, Selection, File) remain visible in both 

modes. 

The basic objects for modeling a network for simulation of pedestrian flows 

can be accessed in either mode. 

► In the BASE DATA menu you may define the following: 

- Pedestrian types and Pedestrian classes 

- Walking behavior parameter sets 

- Area behavior types 

- Display types (of areas) 

- Level properties for multi-storey models 

► In the TRAFFIC menu you may define Pedestrian compositions. 

7.1.1 The Pedestrian Mode 

As long as the Pedestrian Edit mode is active, the objects in the Pedestrian 

traffic mode toolbar are available. 

Areas 

Obstacles 

Ramps (or stairs) 

Pedestrian Inputs 

Pedestrian Routes 

Measurement Areas for Area evaluations (similar to Data 

collections for vehicular traffic, cf. section 11.3 and section 7.2.2) 

Pedestrian Travel Times for Travel time evaluations (similar to 

Travel time measurements for vehicular traffic, cf. section 11.1 and 

section 7.2.1) 



If the VISSIM installation includes the Pedestrians component, a set of 

default data will be generated when the program session is started. This set 

includes the following: 

► Types of pedestrians (“men”, “women”) 

► Classes of pedestrians (“people”) 

► Compositions of flows of pedestrians (“pedestrians”). 

Even if the VISSIM installation does not include Pedestrians, network data 

can be read from any *.INP file. In this case, pedestrian traffic mode data 

will be ignored. 

7.1.2 Types of Pedestrians 


Types of pedestrians can be defined and edited similar to vehicle types, cf. 


Click BASE DATA – PEDESTRIAN TYPES... to call the Pedestrian Types window: 

The grid to the left contains the list of defined types of pedestrians. Rightclick 

to open the context menu which offers the following commands: 

● NEW creates a new type of pedestrians. 

● DUPLICATE creates a new type with the properties of the selected type, 

but a new number = 1 + maximum pedestrian type number in the current 

network. 

● DELETE removes the currently selected type. 



To the right, the displayed properties of the selected type of pedestrians can 

be edited. 

Closing the dialog: 

► CANCEL or ⌧ in the top right corner of the window will discard any 

changes. 

► OK saves all modifications. 


● No.: Unique identification of the type of pedestrians 


● Behaviour parameter file: Enter or select path and name of the 

pedestrain behavior parameter file *.XML, cf. section 7.1.9.1. For global 

parameters, the values specified in the behavior parameter file for the 

pedestrian type having the smallest type no. are used, cf. section 7.6.2. 

● Maximum acceleration: Function for computation of the maximum 

acceleration (not dependent of the speed). For more information cf. 

section 5.1. This information is not used in the Social Force Model, i.e. 

it does not have an effect currently. 

● Weight: This distribution determines the mass of newly created 

pedestrians of this type and can be edited. For further details cf. section 

5.2.2. 

● Model distribution: Defines the shape and the parameters length, width 

and height of the type of pedestrians by selection of one of the defined 

model distributions. New models cannot be defined directly within the 

type data but in the 3D model distribution via BASE DATA - DISTRIBUTIONS 

– 2D/3D MODEL. 

● Model length from - to: Data from 3D model parameters (empty=0). 

Distribution of pedestrian object dimensions in direction of traffic. 

Identical height is not required for the first point and last point to be 

considered for an object dimension. 

● Dimension variance: Scaling ranges for object dimensions (refers to the 

3D model). 

- Length +/-: Scaling range for object length (refers to the 3D model 

width, e.g. from the tip of the toe of the front foot to the heel of the 

back foot). 

- Width +/-: Scaling range for object width (refers to the 3D model 

width, e.g. shoulder width). 

- Height +/-: Scaling range for object height (refers to the 3D model 

height, e.g. adults only or children and adults). 

● Color: These distributions determine the colors for 3D display of the 

four main components of a pedestrian of the selected type for all 

objects of the current type of pedestrians. Prerequisite: Via menu BASE 

DATA - PEDESTRIAN CLASSES, option Color determined by Pedestrian 

type has to be checked. This way, colors defined via add-on “VISSIM 



3D Modeler” will partially be overruled. For color distributions, cf. 


What the colors mean: 

- Color 1: Shirt 

- Color 2: Hair 

- Color 3: Trousers 

- Color 4: Shoes. 

If option Color determined by Pedestrian class is active in the 

Pedestrian classes window, the color distribution selected for Color 1 

(Shirt) will be used for class-specific display of a type of pedestrians. 

The distributions provided for selection have to be defined via BASE DATA - 

DISTRIBUTIONS, cf. section 5.2. 

7.1.3 Classes of Pedestrians 

Types of pedestrians can be grouped to form classes of pedestrians similar 

to vehicle classes, cf. section 5.3.2. Classes just ease setting up a scenario. 

These classes are neither necessarily disjunctive nor mandatory: A type of 

pedestrians can belong to either several classes of pedestrians or to none of 

the classes as well. 


Clicking BASE DATA – PEDESTRIAN CLASSES... calls the dialog: 

The grid to the left contains the list of defined classes of pedestrians. Rightclick 

to open the context menu the commands NEW, DUPLICATE and DELETE. 

● NEW creates a new class. 

● DUPLICATE creates a new class of pedestrians with the properties of the 

selected class, but a new number = 1 + maximum pedestrian class No. in 

current network. 

● DELETE removes the currently selected class. 



To the right, the details of the selected class of pedestrians are displayed 

and can be edited. 


● No.: Unique identification of the class of pedestrians 


● Color determined by: In 3D display mode, all objects of that model (to 

be defined in the optional add-on “VISSIM 3D Modeler”) will be filled 

with a color of this distribution. For color distributions, cf. section 5.2.4. 

- If option Pedestrian type is active, VISSIM will ignore the color 

distribution selected for the particular class of pedestrians and use 

the distributions selected by pedestrian type instead. 

- If option Pedestrian class is active, VISSIM will use the color 

distribution selected for the particular class of pedestrians for 

display of the shirt (cf. type color 1) for all pedestrians of a type 

belongig to the selected class. For a type belonging to two classes 

VISSIM uses the color distribution currently being allocated to the 

class with the greater number. 

● Pedestrian types: The types of pedestrians belonging to the selected 

class of pedestrians are highlighted in the list below. 

To edit this allocation, please left-click the one you would like to allocate 

to this class and thus automatically deselect all others. This way, you 

may mark multiple entries: 

- To multiselect several type entries, hold down CTRL simultaneously. 

- To select a range of types, hold down SHIFT simultaneously. 

7.1.4 Construction Elements: Areas, Ramps, Obstacles 

Pedestrians walk on dedicated pedestrian areas or on ramps. Ramps 

connect areas on different levels. Areas and ramps as well as obstacles 

represent a particular type in VISSIM: Construction Elements. 

A construction element is basically a geometric shape (either a rectangle or a 

polygon). It can be either a walkable space (area/ramp) or an obstacle. 

► Obstacles are no walkable space; on an obstacle, no pedestrians can 

walk. 

► Walkable spaces are either areas or ramps; on a walkable space, 

pedestrians can walk where no obstacle is. Where walkable spaces 

overlap, pedestrians can pass from one space to the other. 

Areas can carry further optional information for pedestrian objects like 

e.g. pedestrian inputs or routing decisions. For public transport stops, 

areas can serve as waiting area or platform edge. 




Areas have no direction and for pedestrians there is nothing corresponding 

to a connector which is known from the vehicle traffic network. Construction 

elements are connected if they touch directly or overlap. 

Obstacles have the same effect on the walking dynamics as if one had 

modeled a hole in the walkable space. 

Before the information on walkable areas is sent to the pedestrian model, 

touching and overlapping areas are combined to one walkable polygon as 

big as possible. In this case, the original area edges do not have the effect 

of an obstacle. 

Thus splitting up areas during editing does not have any influence on the 

simulation of movements of pedestrians. 

Defining an area of a difficult shape can be performed in several steps by 

specifying multiple overlapping polygons. 

Areas of pedestrians created in the Pedestrian traffic mode serve as origin 

and/or destination of the pedestrian flow, whereas a link created in the 

Vehicular traffic mode with option Use as pedestrian area serves as 

walkable space where signal heads, detectors or conflict areas can be 

placed for interaction with vehicular traffic. For more details, cf. section 

7.1.5. 

For definition of a construction element and editing in the Pedestrian traffic 

mode, the Undo and Redo functionality is provided. You may either click 

the appropriate icon in the horizontal symbol bar or use the commands in 

the EDIT menu. 

To create a construction element, follow the steps outlined below: 

1. Click the PEDESTRIAN EDIT MODE button in the symbol bar to activate 

the Pedestrian traffic mode. 

2. Click the particular icon to activate the desired type of the construction 

element: 

- Area 

- Obstacle 

- Ramp 

3. Click the appropriate Shape mode icon: 

- Rectangle 

- Polygon 



For Ramp/Stairway definition, no shape mode has to be selected. It is 

always inserted as a rectangle. 

Prior to the definition, at least two levels have to be defined 

Not regarding the particular type of the construction element, all 

construction elements are numbered in ascending order. 

Rectangle Right clicking the mouse and dragging the pointer while holding down the 

mouse-key starts creating a new rectangular pedestrian area. 

In this mode, the rectangle is inserted in two steps: 

► Your first right-click will fix the coordinates of a corner-point of the 

rectangle. Drag the mouse pointer. By releasing the right mouse key, 

the end of the length edge of the rectangular shape is fixed. The arrow 

indicates the direction of drawing. Pedestrians may walk in both 

directions. 

Holding down the SHIFT key while dragging the mouse in step one limits 

the number of possible directions; you may draw the pointer to just the 

multiples of 45°. 

► After releasing the mouse key you can determine the width of the shape 

only towards one side (and thus not symmetrically): Move the mouse 

sideward and right-click again finally. 

If the CTRL key is pressed simultaneously in step two the width of the 

shape is drawn symmetrically along the first edge which serves as a 

center axis in this case. 

Polygon Right-click to insert the first polyline point and keep mouse-key pressed 

while dragging the pointer: Successive right-clicks will add more points to 

the polyline. 

Double-click (left) to finish the polygon without adding another point. 

Alternatively, double-click (right) to insert a last point. 

The polyline is always closed automatically: The first point is automatically 

connected to the last point. 

For the definition of a new polygon, these are the steps in detail: 

► Keep right mouse-key pressed while dragging the pointer to insert the 

first vertex. 

► Insert successive vertices by right-clicking for each of them. 

Press SHIFT simultaneously to draw a line in 45° or 90° until the next 

vertex is marked. 

► To finish the polyline, double-click either right or left mouse-key. 

- Click right to finish with a final vertex at the click position. 

- Click left to finish without inserting a final vertex at the click position. 

After inserting a new construction element or double-clicking an existing one, 

the properties window of the particular type appears, cf. section 7.1.4.7 et 

seq. 



The properties of the three types are almost alike, slight differences are 

described with the particular type. 

7.1.4.2 The Window Structure by Construction element type 

List of The list contains all construction elements of the particular element type. 

elements The numbering must not be continuously ascending, since numbering of 

construction elements of different types does not count separately. 

The list allows for the following processing steps: 

► Selecting one ore more elements of the particular type for further 

processing. 

► Zoom into the network. 

► Deleting selected element(s) from the list. 

Properties In this section, you may edit the properties of the selected element(s). 

7.1.4.3 Properties & Options of Pedestrian Areas 

● No.: Unique identification of the area. 


● Level: For an area, select one of the levels defined via VIEW - LEVEL 

DISPLAY, cf. section 7.1.4.6. 

● Z-Offset top: Offset (positive or negative value) along z-axis to the 

particular edge for 3D display of the area. For areas, z = 0 is the ground 

pedestrians walk on, cf. A in figure below. 

- With Thickness > z-Offset, the walkable space rises from below zero 



- With Thickness < z-Offset, the walkable space seems to hover in 3D 

● Thickness (3D): Thickness of the area in 3D display (cf. B in figure 

below). Not regarded for simulation. 

Thickness > 0 for an area or a ramp will reduce the headroom underneath 

the construction element which is displayed in the 3D mode, since the 

thickness of the ceiling (or ramp, respectively) is not regarded for the 

headroom-based calculation of the length of the ceiling opening (or solid 

ramp foot, respectively). 

● Display Type: Color, texture etc. for the display of the area. Select one of 

the display types defined via BASE DATA - DISPLAY TYPES, cf. section 5.5.2. 

Scheme: A = Z-Offset top, B = Thickness; Obstacle (red): C = Z-Offset bottom, D = 

Height 

● Visualization: In this section, only the relevant option is regarded during a 

simulation, the other one will be ignored. This depends on the current 

selection via menu VIEW – OPTIONS – [PEDESTRIANS], cf. section 7.2.5. 

For example, these options can be used to model tunnels and 

underpasses in 2D graphics. 

- Individual pedestrians: This option is regarded, if the global display 

option Individual pedestrians is active, cf. section 7.3.2. 

When turned off, no pedestrians are shown on that area during the 

simulation. 

- Aggregated values: If the global display option Aggregated values is 

active, the currently active LOS scheme can be overruled for this 

area in case of area-based LOS display, cf. section 7.3.3. 

If this option is active, you can select either a LOS scheme which 

is different from the globally selected one or Display type from the list 

of schemes for display of this area during simulation. 

When turned off, no aggregate values are shown on that area 

during the simulation. 



● Behavior type: Optional property of areas, serves for modelling 

occasional changes to speed or other parameters. Select a type from the 

list of area behavior types defined via BASE DATA - AREA BEHAVIOR TYPES, 


● Dwell time distribution: Optional property of areas. Select a dwell time 

distribution from the list defined via BASE DATA - DISTRIBUTIONS - DWELL 

TIMES, cf. section 5.2.6. This dwell time distribution will be applied to 

pedestrians that pass this area due to their strategic route. Dwell time 

distributions at input areas have no effect on pedestrians that are 

inserted there. 

For pedestrian areas with PT usage of either waiting area or platform 

edge type, you can define a minimum dwell time by allocating a dwell 

time distribution. PT vehicles do not depart until the minimum dwell time 

is over or (even with minimum dwell time = 0) will depart later, when all 

alighters will have deboarded. Optionally, you can check the option Late 

boarding possible by PT line stop event, cf. section 6.5.2.5. 

● Queuing: Waiting type attribute of rectangular pedestrian areas with 

intermediate routing point or route destination point. If this option has 

been checked, waiting pedestrians will queue for the duration of their 

dwell time, or just for some seconds if no dwell time distribution has been 

allocated. The queuing follows the direction vector that has been defined 

during the creation of the area. The vector is displayed in center line 

mode. This option does not work with pedestrian areas for public 

transport usage. 

● Public transport usage: Select the appropriate PT usage type. 

- None: The area is not used by PT 

- Waiting area: Location where pedestrians wait for the PT line they 

want to board at the allocated stop. If at least one public transport 

stop is selected, the pedestrians will choose a random point on the 

waiting area and wait there for the next public transport vehicle. It is 

currently not possible to model ordered waiting as a queue. 

If the PT vehicle which the passenger intends to board has arrived 

already the passenger does not follow his route to the randomly 

determined position in the waiting area. Instead, he directly walks 

towards the vehicle after reaching the waiting area as long as the 

vehicle’s dwell time will last at least two more seconds. 

- Platform edge: Location where pedestrians go to when alighting from 

a PT line at the allocated stop. Alighting passengers will always use 

the nearest platform edge. Then they follow the routing decision 

placed on that area. If no routing decision has been set here, they 

are removed from the network. For a platform edge, width = 2m is 

required for minimum. An area (polygon type) serving as platform 

edge can automatically be generated with a door, cf. section 6.5.1. A 

platform edge can be allocated to multiple stops. 

● For PT stop(s): Allocate one or several public transport stops to an area 

of the Waiting area or Platform edge type. 



● Boarding location: By default, the door that is located most close to the 

passenger is used as boarding location on pedestrian areas with public 

transport usage. Alternatively, you can select one of the location 

distributions for the door choice of boarding passengers. When boarding 

a PT vehicle, the waiting passengers will select their doors accordingly, 


If at a stop at least one pedestrian area is defined as waiting area or 

platform edge, VISSIM assumes that alighting and boarding at that stop are 

to be simulated microscopically and that the dwell time is not only to be 

calculated numerically from the given numbers of alighting and boarding 

passengers. 

The difference becomes visible in the PT Line-specific Stop Data window, 

since the content of this dialog changes when at least one pedestrian area 

is defined as Waiting area or Platform edge, cf. section 6.5.2.5. 

7.1.4.4 Properties & Options of Obstacles 

● No.: Unique identification of the obstacle. 


● Level: For an obstacle, select one of the levels defined via VIEW - LEVEL 

PROPERTIES, cf. section 7.1.4.6. 

● Z-Offset bottom: Offset (positive or negative value) along z-axis to the 

particular edge for 3D display of the obstacle (cf. C in scheme). 

● Height: Height of the obstacle in 3D display (cf. D in scheme). 

● Display Type: Color, texture etc. for display of the obstacle. Select one of 

the display types defined via BASE DATA - DISPLAY TYPES, cf. section 5.5.2. 



7.1.4.5 Properties & Options of Ramps/Stairways 

The general properties of ramps/stairs (upper portion of the properties 

window) are similar to the properties of areas and obstacles. 

● No.: Unique identification of the Ramp/Stairs. 


● Levels: For a ramp/stairs, two levels have to be selected from those 

defined via VIEW - LEVEL DISPLAY, cf. section 7.1.4.6. 

- Level 1 is the level where drawing the ramp started 

- Level 2 is the level where drawing the ramp finished 

● Z-Offset (for ramps by level): Offset (positive or negative value) along zaxis 

to the particular edge for 3D display of the ramp/stairs (= ground 

pedestrians walk on, cf. A in scheme). 

- With Thickness > z-Offset, the walkable space rises from below zero. 

- With Thickness < z-Offset, the walkable space seems to hover in 3D. 

● Thickness (3D): Thickness of the ramp in 3D display (cf. B in scheme). 

Not regarded for simulation. 



● Display Type: Color, texture etc. for display of the ramp/stairs. Select one 

of the display types defined via BASE DATA - DISPLAY TYPES, cf. section 

5.5.2. 

● Visualization: In this section, only the relevant option is regarded during a 

simulation, the other one will be ignored. This depends on the current 

selection via menu VIEW – OPTIONS – [PEDESTRIANS], cf. section 7.2.5. 

For example, these options can be used to model tunnels and 

underpasses in 2D graphics. 

- Individual pedestrians: This option is regarded, if the global display 

option Individual pedestrians is active, cf. section 7.3.2. 

When turned off, no pedestrians are shown on that ramp or 

stairway during the simulation. 

- Aggregated values: If the global display option Aggregated values is 

active, the currently active LOS scheme can be overruled for this 

stairway in case of area-based LOS display, cf. section 7.3.3. 

If this option is active, you can select either a LOS scheme which 

is different from the globally selected one or Display type from the list 

of schemes for display of this stairway during simulation. 

When turned off, no aggregate values are shown on that stairway 

during the simulation. 

● Behavior type: Optional property of ramps and areas, serves for 

modelling occasional changes to speed or other parameters. Select a 

type from the list of area behavior types defined via BASE DATA - AREA 

BEHAVIOR TYPES, cf. section 7.1.9.2. 

● Element type: Walkable space connecting two storeys can be either a 

Ramp or a Stairway. Select the appropriate option and set the specific 

parameters by element type. 

Prior to Ramp/Stairway definition, at least two levels have to be defined. 

Specific properties of ramps and stairways 



[IN- 

STALLATION] 

[DESIGN 

(STAIRWAY)] 

These parameters apply to ramps and stairways: 

● Ceiling opening: Select the decisive parameter for the definition of the 

size and enter the appropriate value: 

- headroom (vertical magenta line) 

- length (horizontal green line) 

● Solid ramp foot: Select the decisive parameter for the definition of the 

size and enter the appropriate value: 

- headroom (vertical yellow line) 

- length (horizontal black line) 

● Show solid obstacle (3D): The barrier effect of the solid ramp foot is 

visualized. If this option is unchecked, the obstacle still serves as a 

barrier, though it is displayed as empty space. 

The data visualized by colored lines in the scheme do not take effect on 

pedestrian flows using the stairway or ramp. However, this data is regarded 

for the space being provided on the two neighboring storeys, since for the 

upper level, the size of the cut-out section depends on the ceiling opening 

properties and for the lower level, the blocked section depends on the 

dimensions of the obstacle. Make sure, that the footer’s headroom is 

sufficient, otherwise the pedestrians’ heads seem to go through the ramp. 

Thickness > 0 for an area or a ramp will reduce the headroom underneath 

the construction element which is displayed in the 3D mode, since the 

thickness of the ceiling (or ramp, respectively) is not regarded for the 

headroom-based calculation of the length of the ceiling opening (or solid 

ramp foot, respectively). 

Additionally, these parameters apply to stairs: 

For Stairway definition, select the decisive parameter and enter the 

appropriate value: 

● Total steps: number of steps 

● Rise: height of the rise 

● Going: step length to next step 

7.1.4.6 Multiple Levels (Add-on) 

At present, the Multiple Levels add-on can be used for pedestrians only. 


Definition For multi-storey modeling, you may define 

different levels via BASE DATA - LEVEL 

PROPERTIES: 

Right-click to call the context menu: 

● NEW or CTRL+N adds a new level. 

● DELETE removes the selected level. 

Select a level property and edit the settings: 

● Name 

● Height 

Settings Set options via VIEW - DISPLAY LEVEL. 

Enable or disable graphical display and/or 

access for editing to a defined level or for 

All levels: 


► Left-Click the eye icon to toggle between visible (open/colored) and 

invisible (shut/gray) display. 

► Left-Click the padlock icon to toggle between editable (unlocked) and 

not editable (locked) state. 

► Left-Click the figure icon to toggle between visible (black) and invisible 

(gray) state of pedestrians. 

7.1.4.7 Editing Construction Elements 

Activate the appropriate construction element type: Obstacle or Area or 

Ramp. 

For editing, the currently active shape mode is not regarded. 

The level of the element must be in the unlocked state, cf. section 7.1.4.6. 



Select Selection of one or several elements in the network display 

► Activate the appropriate construction element type. (The current shape 

mode is not regarded.) 

► Single-Select: 

- Left-click the construction element in the network display. The 

selected element is highlighted on screen. 

- Double-click the construction element to call the properties window. 

► Multi-Select: 

- Left-click and keep left mouse-key pressed while drawing a polygon 

around the elements you would like to select for further editing. 

Multi-selection regards all construction elements which are fully 

covered by the multi-selection polygon. 

- Double-click in the polygon to call the properties window. 

Single-select: If multiple construction elements of the selected type overlap 

at the click position, the button (default shortcut TAB) may be used to 

browse through all elements of this type being located at the mouse click 

position in order to select the desired area or ramp or obstacle. 

Except EDIT SHAPE, any editing functionality can be applied to both, a single 

element or multiple selected elements. 

Selection of one or several elements in the list 

► Activate the appropriate construction element type. 

► Right-click to call the list of all elements of this type. The list contains all 

construction elements of the particular element type. 

The numbering must not be continuously ascending, since numbering 

of construction elements of different types does not count separately. 

- Left-click to select a single element. The selected element is 

highlighted on screen. 

- Left-click as many elements as necessary while pressing CTRL 

simultaneously to select multiple elements one by one. 

- Left-click the first entry you would like to select and left-click the last 

entry of a continuous block of entries while pressing SHIFT 


► Right-click to call the context menu. 

Since the property window remains open during graphical editing, selection 

via the particular properties window provides quick access to data editing 

and shape or position editing simultaneously. 

Prior to DELETE, the properties window needs to be closed after selection. 


Appearance of a highlighted element 


The handles of the highlighted element allow for the following: 

- Use the cross in the middle to move the polygon. 

- Use one of the four corner points to resize the polygon. 

- Use the dot on top to rotate the polygon. 

- Right-click on a polygon edge to add an intermediate point. 

In each case, the appearance of the cursor will change accordingly. 

Zoom Press CTRL+SHIFT+Z simulaneously to place the selected element(s) in the 

center of the VISSIM window. The display is scaled accordingly. 

Edit data Given attribute data can be overruled in the properties section. Edit the 

desired cell(s) by a direct entry or a new selection. 

► Single element: The number is not subject to changes. 

► Multiple elements: The property cells indicate the following in case of 

different attribute values: 

- Grayed-out cells indicate, that identical values are not permitted 

(e.g. name). 

- Empty cells indicate, that the attribute values of the marked 

elements are different. These different values will be replaced by 

the new entry. 

Confirm changes to data by clicking APPLY instead of CLOSE in the 

Construction element window for selection of other construction elements 

and further changes to their properties. 

Delete Select the construction element(s) and press DEL. 

Move 

Copy 

► Place the cursor on the cross in the middle of the polygon. 

The pointer appears as a cross with arrow heads. 

► Left-click inside the polygon and keep the mouse-key pressed while 

dragging the polygon to the desired position. 

► Place the cursor on the cross in the middle of the polygon. 

The pointer appears as a cross with arrow heads. 

► Press CTRL. 

Next to the pointer a plus sign appears. 

► Shift the copy of the selected construction element(s) to the desired 

position. 



In order to restrict the mouse movement while generating or moving or 

copying a construction element, hold down the SHIFT key: Now you can 

move an element (or its corner/edge) along the horizontal, vertical or 45degree-diagonal 

axis. This also works in combination with the CTRL key. In 

this way, you can align precisely any copies of construction elements. 

Rotate ► Place the cursor on the dot on top of the polygon. 

The pointer appears as a rotating arrow. 

► Left-click the dot on top and keep the mouse-key pressed while 

dragging the pointer (clockwise or anti-clockwise) to the desired 

position. The footprint of the rotating polygon is displayed by a rubberband. 

The position of the cross marking the middle of the original 

polygon is kept. As soon as the mouse-key is released, the frame will 

be adjusted. 

Edit shape To edit the shape of a user-defined polygon, you can either remove an 

intermediate point from a polygon edge or add an intermediate point to an 

edge or shift a point to a new position. 

► Place the cursor. 

The pointer appears as a cross-hair. 

► Add vertex: Place the pointer precisely on the position in the polygon 

edge where you want to add another polygon point. As soon as the 

pointer is indicated by a cross-hair, you can add the new point by rightclick. 

► Move vertex: Place the pointer on the polygon point to be shifted and 

keep left mouse-key pressed while dragging the point to the desired 

position. The shape of the polygon is adjusted immediately. 

► Delete vertex: Place the pointer on the polygon point to be removed and 

keep the left mouse-key pressed while dragging this point to one of the 

neighbouring points. As soon as the mouse-key is released the dragged 

point is removed from the polygon. The shape of the polygon is adjusted 

immediately. 

7.1.5 Links as Areas of Pedestrians 

This section deals with links carrying pedestrian flows for modelling the 

interactions of vehicular traffic and pedestrians. 

Users of the Pedestrians add-on module can define construction elements 

(areas, ramps, obstacles) for pedestrian traffic and additionally links as 

walkable space for pedestrians. 


In contrast to links carrying vehicular traffic, pedestrian links 


► are not defined by direction, 

► can neither be split nor contain intermediate geometric points and 

► may neither contain inputs nor connector start or end. 

For basic link data and editing details, please refer to section 6.3.1. 

In contrast to walkable construction elements, pedestrian links 

► have to be defined and edited in the vehicular traffic mode, 

► may neither be a ramp nor an area, and 

► cannot be the start or end or an intermediate point of pedestrian routes. 

An obstacle may not be placed on a walkable ramp, but on a pedestrian 

link. 

Accordingly, a pedestrian area can be defined on a pedestrian link, which 

means, start or end or intermediate points of pedestrian routes can also be 

placed there. 

The basic idea of pedestrian links is to use the same mechanism as for 

vehicles: At a junction where vehicles and pedestrians shall cross, a VISSIM 

link serves as the basis for an automatically created pedestrian area. 

In contrast to walkable pedestrian areas, pedestrian links allow for flow 

control by link-related VISSIM objects. 

On pedestrian links, other VISSIM network elements can be placed: 

► conflict areas, cf. section 6.6.2, 

► signal control, cf. section 6.7.1, 

► detectors, cf. section 6.7.1.3, and 

► priority rules, cf. section 6.6.1. 

General Interactions between 

vehicles and pedestrians 

can be handled by the 

means of 

● signal control, 

● conflict areas, 

● detectors and 

● priority rules. 



Signal- 

Controlled 

Junctions 

Conflict 

Areas 

After creating a pedestrian 

link (B), the user can (in 

Signal head mode, defined 

signal group required) 

define signal heads (1+2) 

on corresponding links as 

for vehicles: 

► left-click to select link, 

► right-click to create 

signal head. 

A pedestrian signal head is always directed: 

► From one side it can always be passed by pedestrians. 

► From the other side it can be either open or closed (depending on the 

dynamic state of the corresponding signal group: red & amber = closed, 

all other states = open). 

The dynamic state (red, green) of the signal head is linked to the dynamic 

state of the signal group that the signal head belongs to. 

Define separate signal heads on both opposing links to handle pedestrians 

from both directions (upstream and downstream). 

The direction of the signal head corresponds to the direction of the link. 

Instead of the vehicle classes’ listbox a pedestrians classes’ listbox will 

appear for a signal head located on a pedestrian link. 

A pedestrian will consider the signal head if and only if his pedestrian type is 

element of one of the selected pedestrian classes in the dialog. 

After creating a pedestrian 

link (B), the user can (in 

Conflict area mode) define a 

conflict area where 

pedestrian link and vehicle 

link intersect: 

► left-click on the conflict 

position to create a 

passive conflict area 

(yellow: 1+2+3+4), 

► right-click on the conflict 

area to toggle the right 

of way as for vehicles. 

The conflict area dialog for so-called mixed conflict areas is the same as for 

conflicts between vehicle flows. 

The conflict areas will be created on both opposing directions of pedestrian 

links. They always have the same right of way (pedestrians either have the 



right of way or have to yield). Depending on the current right of way settings 

and based on their desired speeds and their current speeds the pedestrians 

and vehicles decide when to cross the conflict area. 

A conflict area has also a user-definable stop line distance (red: 1+2+3+4). It 

describes the upstream position on the link where pedestrians or vehicles 

have to wait if they yield. Otherwise, the stop line position is right before the 

upstream start of the conflict area. The user can define the stop line in 

upstream direction of the conflict area´s regular stop line (x_min). 

If the two links intersect with an acute angle, the distance which is to be 

covered to cross the road will increase and so will the time required for 

crossing. At present, no geometrical analysis is performed for evaluation of 

the relative position of the two links which are connected by the conflict 

area. Thus it might happen in this case, that a pedestrian is still crossing 

the road when the next vehicle enters it. 

Case 1: Pedestrians yield 

to vehicles 

Pedestrians who want to 

enter the conflicted area 

(yellow: 1+2) and cross the 

vehicle link (A1), have to 

consider the minimum 

speed, which is calculated at 

the stop lines (red: 1+2). 

At the stop lines minimum speeds are dynamically computed: Pedestrians 

walking with that or higher speed can pass the stop line, others have to wait 

in front of it. 

Pedestrians will enter the conflict area crossing a traveled road only if they 

can cross the entire link (lane by lane) without ever being located on a lane 

on which a vehicle is just passing the conflict area. Here, the desired speed 

of the pedestrian and the current speed of the vehicle are regarded. Neither 

vehicles which have not yet entered the network nor vehicles in a distance 

greater than 75 m multiplied by the number of link lanes are taken into 

account. After entering the conflict area, this condition can no longer be 

satisfied, if a vehicle accelerates, for example, or if a new vehicle enters the 

network nearby. In this case, the pedestrian will wait in front of that lane of 

the link, which he presumably cannot cross completely before the vehicle 

arrives. 



Case 2: Vehicles yield to 

pedestrians 

On the pedestrian link, the 

area from 3 m upstream to 

the begin of the conflict area 

serves as “detection area” 

for pedestrians approaching 

the conflict area (cf. 

Detectors below). 

Pedestrians inside the 

conflict area are always 

Detectors 

taken into account. 

The time gaps between (groups of) pedestrians when the conflict area is 

expected to be completely free of pedestrians are passed to approaching 

vehicles so they can react accordingly. 

Detector areas are used to model push buttons for pedestrian signals. 

The Detector object is also used as SCJ detectors for pedestrians. It has to 

be placed on the pedestrian link where the signal head is located. 

Detector 

window 

Priority 

rules 

For definition of detectors for pedestrians and subsequent changes to their 

properties please refer to the detectors for signal-controlled vehicular 

traffic, cf. section 6.7.1.3. 

[ACTIVATION] tab: 

The parameters in this tab regard 

whether the link has been defined 

for pedestrian traffic or for vehicles. 

For a pedestrian link please select: 

● Maximum speed: Enter max. 

speed value. Slower 

pedestrians will be recognized 

as demanders by the detector. 

● Pedestrian classes: A 

pedestrian is only detected if his 

type belongs to the selected 

class. 

You can define priority rules not only for vehicular traffic, but also for 

conflicting pedestrian flows and also for the interactions between vehicles 

and pedestrians. 

For pedestrians, a priority rule needs to be placed on a link that is 

permitted for pedestrians. Pedestrians can be the yielding flow as well as 

the flow having the right of way. 


Priority 

Rule 

window 


For definition of priority rules for pedestrians and subsequent changes to 

their properties please refer to the priority rules for signal-controlled 

vehicular traffic, cf. section 6.6.1. 

Actually, conflict areas are recommended for modeling. If these do not 

return the expected results, the experienced user can model priority rules. 

If the stop line (or one of the conflict markers) is located on a link which is 

used as pedestrian link, pedestrian classes are provided for selection 

instead of vehicle classes. 

For a priority rule that has already been defined, follow the steps outlined 

below to configure either combination pedestrians x vehicles, vehicles x 

pedestrians or pedestrians x pedestrians: 

► Select the link where the cross section to be edited is located. 

► Open the Link attributes window, cf. section 6.3.1.2 

► Click option Use as pedestrian link: 

- If this option is checked, pedestrian classes will be provided for 

selection at this cross section. 

- If this option is unchecked, vehicle classes will be provided for 

selection at this cross section. 




To define a pedestrian link for later use of e.g. signal heads, detectors or 

conflict areas for pedestrian flows, 

► Activate the Vehicle traffic mode and 

► Define a pedestrian link (cf. section 6.3.1) 

- as a new link or 

- by editing an existing link: 

► In both cases: check option “Use as pedestrian area” in the Link Data 

window. 

► Select Level of Area, cf. section 7.1.4. 

The height of a pedestrian link and its area is determined by the height of 

the chosen Level of Area and the user-defined Offset ([DISPLAY] tab). 

The resulting height is displayed, however, it is not subject to changes, 


Create From the above settings, VISSIM creates 

► link no. 1 as pedestrian link (drawn by pointer) and 

► link no. 2 as pedestrian link in opposite direction. 

Edit The edited vehicle link is stored as pedestrian link and an opposing 

pedestrian link is created with the coordinates of the original link, i.e. both 

links are located on top of each other. 


This section deals with those properties which are essential for links that are 

used as pedestrian areas: 

● Use as pedestrian area: Activate this option to create a walkable 

pedestrian link which 

- serves as a walking ground for pedestrians (in both directions) and 

[LANES] 


[DISPLAY] 



- will not be traversed by vehicles. 

As soon as this option is active, the Level of Area list box is provided. 

● Level of Area: Select the appropriate level from the user-defined 

selection list, cf. section 7.1.4. 

Select Display Type and Behavior Type as for links, cf. section 5.5. 

Enter Offset top and Thickness (3D) as for construction elements, cf. 


Edit data Editing a pedestrian link is similar to editing a link carrying vehicular traffic, 

cf. section 6.3.1: 

► Activate the Vehicle traffic mode and 

► Select the link 

- from the list of links/connectors and click ZOOM, DATA or DELETE; 

- in the network display and move or shorten/lengthen it or hit DEL. 

Double-click allows for data editing. 

Delete Prior to deleting the selected pedestrian 

link please confirm, that also the 

corresponding link in the opposite 

direction will be deleted. 



7.1.6 Pedestrian Compositions 


Compositions of pedestrians can be defined, edited and used similar to 

vehicle compositions, cf. section 6.4.1. 

Compositions of types of pedestrians are assigned to pedestrian inputs. 

Clicking TRAFFIC – PEDESTRIAN COMPOSITIONS... calls the dialog: 

The grid to the left contains the list of defined compositions of pedestrians. 

Right-click to open the context menu which offers the following operations: 

● NEW adds a new composition to the list. 

● DUPLICATE creates a new composition with the properties of the selected 

composition, but a new number ( = 1 + maximum pedestrian composition 

No. in current network). 

● DELETE removes the currently selected composition from the list. 

A warning will be displayed if the selected composition is still assigned to 

an input of pedestrians. 

To the right, the properties of the selected composition of pedestrians have 

to be defined and can be edited. 

► In the upper section, name and number of the selected pedestrian 

composition are subject to changes. 

► In the grid, data rows can be added or deleted via the context menu. 

► For changes to a data row, place the mouse pointer in the cell to be 

edited: 

- Select a pre-defined Pedestrian type or Desired speed distribution. 

- Enter the appropriate Ratio value. 


● No.: Unique identification of the composition of pedestrians 


The list contains a user-defined ratio for each combination of type of 



pedestrians and desired speed destribution: 

● Pedestrian Type: Select a type from the list defined via BASE DATA - 

PEDESTRIAN TYPES, cf. section 7.1.2. 

● Desired Speed: Select a distribution from the list defined via BASE DATA - 

DISTRIBUTIONS - DESIRED SPEED, cf. section 5.2.1. 

● Ratio: The ratio determines how many pedestrians of the type and with 

the given speed distribution will be created in relation to pedestrians of 

other types also included in the distribution. 

7.1.7 Pedestrian Inputs 

For a selected walkable space or pedestrian link, inputs of pedestrians can 

be defined and edited similar to vehicle inputs, cf. section 6.4.3. 

For these inputs of pedestrians, VISSIM will - at random points in time - 

create pedestrians according to pedestrian compositions and input volumes. 


► Activate the Pedestrian Edit Mode and the Pedestrian Inputs 

mode. 

► Select the pedestrian area on which you want to place the new input. 

► Right-click inside the area at the position where you want to place the 

input. The new input is represented by a red dot inside of the area. The 

dot is merely a graphical representation – the pedestrians from this input 

will be created at random locations within the corresponding pedestrian 

area. 

To open the Pedestrian Inputs window for 

► inputs of pedestrians per area: Double-click on that area. 

► all inputs of pedestrians in the network: Right-click outside of the 


Similar to the vehicle input dialog, the input of pedestrians data is arranged in 

two sections (cf. section 6.4.3.1): 



Define 

new time 

interval 

Edit time 

interval 

data 

Delete 

interval(s) 

► Volumes/Compositions section, 

► Time intervals section. 

Time Intervals Section 

(This section can be hidden by clicking . To show it again, click .) 

Here the time interval boundaries are defined. At least one time interval is 

required, thus the first and the last line may not be deleted. 

Changes to the list of time interval thresholds will immediately change the 

column layout in the Volumes/Compositions section. 

1. Right click inside the section and choose NEW from the context menu. 

A new line is added at the end of the list. 

2. Enter the value of the new time interval boundary. The value must be 

different from any other time but can also be smaller than the last value. 

In that case, an existing time interval is split at the time newly entered. 

Any time entry can only be changed to a value that is in between the 

neighboring times (i.e. the time sequence cannot be changed; to do so, the 

given boundary has to be deleted and a new threshold has to be added). 

1. Select the time to change. 

2. Type in the new time and confirm with ENTER. 

All flow values remain unchanged. 

1. Select the start time of the interval to be deleted. 

Press CTRL simultaneously to select several rows. 



If a time interval does not contain any input values, the time interval will be 

deleted when the Inputs window is closed. 

Volumes/Compositions Section 

For each area, the inputs of passengers are arranged in columns, sorted by 

time interval. For each combination of area and time interval, a data pair 

consisting of a volume and a composition may be defined (empty pairs are 

allowed). It is not possible to define a volume without composition or vice 

versa. 

It is possible to have multiple rows for the same area if there are volumes for 

different compositions defined within a time interval. 


Define new 

input of pe- 

destrians 


Prior to the definition of pedestrian inputs at least one pedestrian 

composition needs to be defined (similar to vehicle inputs, cf. section 

7.1.6.1). 

1. Double-click on the area where the new input of pedestrians is to be 

defined. The Pedestrian Inputs window opens with the corresponding link 

no. 

2. If an input of pedestrians already exists, either change it or right click and 

choose NEW to create a new row for this area. 

3. Define the input properties, cf. section 7.1.7.2. 

Edit data For volume changes: 


2. Type in the new volume and confirm with ENTER. 

For composition changes: 


2. Press the button on the right to open the pull-down list. 

3. Select the new composition from the list. 

For further information and property changes please refer to section 7.1.7.2. 

Copy & 

Paste 

data 

Scale 

Volume 

Delete in- 

put of pe- 

destrians 

In the Volumes/Compositions section, the COPY & PASTE commands (similar 

to the Microsoft Excel method) are available through context menu. Data 

exchange is permitted within the input window or from/to external data 

sources (e.g. *.XLS or *.DOC files). 

► COPY: Select a source cell or rectangular source region using 

- SHIFT + cursor keys or 

- mouse move while holding down left mouse button. 

► PASTE: Select a destination region being 

- congruent (identical dimensions) or 

- larger than the source region (e.g. source 2x3, destination 6x6 or 

10x15; not ok: 3x6 or 6x10). 

Please disable display of either volumes or compositions before selection, 

since only one data type can be copied/pasted. 

Only values of visible columns are copied and pasted (not values that are 

contained in hidden columns). 

Select the cells with volume values to be multiplied by the user-defined 

factor. Click SCALE VOLUMES in the context menu and enter the factor for 

volume scaling. 

1. Select the entire row(s) to be deleted by clicking on the row no. (on the 

far left of the grid). Press CTRL simultaneously to select several rows. 





All changes in the Vehicle Inputs window can be undone by pressing 

CANCEL instead of OK to close the window. 


Cf. section 7.1.7.1 on how to open the Pedestrian Inputs window and how to 

edit the Time section. 

This section describes the properties and options for the Volumes/Compositions 

section. 

● Area Number & Area Name: Refers to the area where the input of 

pedestrians is placed. Values can be selected from the list of all areas 

either by no. or (optional) name of the area. 

● Input Name: Optional name of the input of pedestrians. Refers to all data 

entered for the same area. 

● Show Label: Not used. 

Each of the following columns (one per time interval) contains - per area/input 

- the pair(s) consisting of flow of pedestrians data and composition of 

pedestrians data. 

● Column Header: Shows start time and end time of the interval (in 

simulation seconds). The columns are created automatically from the list 

of time intervals in the Time Interval section (for more or different time 

intervals, please refer to “Add new interval” in the “Time Intervals” section 

above). 



● Data pair: For each row and time interval, a data pair may be defined 

(several compositions can be allocated to a walkable space): 

- Upper line: Input volume (pedestrians/h) 

- Lower line: Composition of pedestrians 

The text color indicates the validity of the data pair: 

- Black: For this interval only 

- Gray: For a period of combined intervals (Continued Input). In that 

case, only the master cell (black) can be edited and affects 

automatically all subsequent continued cells. 

The background color indicates the type of the flow volume: 

- White: stochastic values or 

- Yellow: exact values. 

When EXACT VOLUME is enabled VISSIM generates exactly the edited 

number of pedestrians to enter the network as opposed to a distribution. 

The configuration of the data section can be changed via the context menu. 

Select one or multiple cells and call: 

● EXACT VOLUME: Volume values are regarded as exact volumes, if this 

option is checked. The cells are highlighted in yellow. 

● STOCHASTIC VOLUME: Volume values are regarded as stochastic volumes, 

if this option is checked. The cells are not highlighted. 

● CONTINUED INPUT: Select all cells to be combined (except the master cell) 

and check this option to define a combined flow: The master cell is the 

one previous to the selected cells; the master cell entry spans over the 

selected sequence of time intervals. 

- The master cell remains editable, indicated by black text entries. 

Changes to the master cell entry are copied to all subsequent cells. 

- Grey text entries indicate combined cells (Read-only). 

Uncheck this option to separate selected combined cells. 

● VIEW VOLUMES: Toggles display of the volume values (upper line per time 

interval) on and off. 

● VIEW COMPOSITIONS: Toggles display of the selected compositions (lower 

line per time interval) on and off. 

● ZOOM: The input´s position in the network is placed in the middle of the 

VISSIM window on screen. 

7.1.8 Routing Decisions and Routes 

Routing decisions and the routes or partial routes for pedestrians can be 

defined and edited similar to routes and routing decisions for vehicles, cf. 




Pedestrian routes belong to pedestrian routing decisions that are located on 

pedestrian areas. 

A pedestrian route is a fixed sequence of areas and ramps: 

► It starts at the routing decision area (red dot) 

► It ends at a destination area or ramp (green dot). 

Each routing decision point can have multiple destinations resembling a tree 

with multiple branches. The length of routes and partial routes is not limited. 

The start, intermediate stops and the end of a pedestrian route cannot be 

placed on a link that has been defined as a pedestrian area. 

Note: If required, you can create a construction element of the Area type on 

this link. Then place the routing decision or an intermediate point or the 

destination of a pedestrian route on that area. 

Just the construction element Area can carry the routing decision point 

information. 

Intermediate points and the destination of a static route or a partial route for 

pedestrians can be placed on an Area or a Ramp. 

Consideration of routing decisions by pedestrians 

A routing decision affects only pedestrians of a class that is contained in the 

routing decision and which do not have any routing information at the 

moment. If a pedestrian is already walking along his a route then he first has 

to reach the route’s destination (green dot) prior to be able to receive new 

routing information. Note that this is different for the routing decisions of 

partial routes. Details are explained below. 

7.1.8.1 Types of Routing Decisions and Routes for Pedestrians 

Pedestrians can be assigned Static routes or Partial routes. Routes always 

start from a routing decision which is of either type. 

► Static Route: Routes the pedestrians from a start area (red dot) to one of 

the defined destinations (green dot) using a static percentage for each 

destination (similar to static vehicle routes between start and destination 

cross section, cf. section 6.4.4). 

► Partial Route: Defines a section of one or more routes where pedestrians 

are re-distributed according to the routes and percentages defined for the 

partial routes. After having completed the partial routes the pedestrians 

continue to follow their original route. 

All pedestrians who satisfay the following conditions are assigned a new 

route from the partial route's decision area to the partial route's 

destination area. 

- The pedestrian enters an area, on which a partial routing decision is 

located whose destination is on an area where also an intermediate 

point or the destination of the pedestrian’s original route is located. 



- The pedestrian belongs to a class that is contained in the partial 

routing decision. 

After having completed the partial route, the pedestrians continue to 

follow their original routes from the partial route's destination area. It is 

not necessary, however, that the area of the partial route decision 

includes an intermediate point of the main route. Intermediate points of 

the original route are ignored until the destination area of the partial 

routing decision is reached. Multiple partial routes can overlap - the 

complete current route (extending all the way to the destination of the 

original route) is checked for the destination area of the partial routing 

decision. 

Partial routing decisions bear a Replacing Impact – in contrast to the 

Adding Impact of a normal routing decision (main routes) which can only 

take effect in two cases: Either the pedestrian is just entering the network 

or the pedestrian has reached the destination of his former route on an 

area which is carrying another routing decision. 

7.1.8.2 Partial Routes for Pedestrians 

A partial route for pedestrians can be either Static or Dynamic. 

Only those pedestrians are regarded by a partial routing decision, whose 

current route has either an intermediate point or the destination on exactly 

the destination area of the partial routes starting from this partial routing 

decision. 

For partial routes it is sufficient if the pedestrian geometrically walks on the 

area carrying the partial routing decision. In this case, the area does not 

have to represent an intermediate point. 

Please do not confuse static partial routes with static routes. Of the various 

partial routes the static partial routes work as static routes, except that they 

are partial routes. Therefore the naming similarity. To avoid confusion in 

certain circumstances static routes are also called main routes. 

► Static Partial Routes: Select Static as Route choice method and enter the 

relative flow value for each user-defined time interval. 

► Dynamic Partial Routes: Select a Route choice method other than Static 

and set the appropriate parameters. 

All partial routes starting from a partial routing decision lead to the same 

destination area. 

Overview of the Route choice methods for partial routes of pedestrians: 



Method Short description 

Static Fixed choice ratios set by the user 

Travel Time Dependence of choice ratios on the travel time of 

preceding pedestrians who have already finished 

the partial route 

Next free counter For approaching a set of parallel organized 

queues (respectively desks or counters) 

The dynamic route choice criterion Travel time 

The following steps are performed: 

► Initially the pedestrians are distributed equally on all routes of the 

decision, until each route has been concluded by at least one pedestrian. 

► VISSIM evaluates the travel times of the latest user-defined number of 

pedestrians who have concluded a route. (The default value of the userdefinable 

route choice method parameter is 10.) 

► Travel time of route i = Ti is the average of travel times of this user-defined 

number of pedestrians (respectively the pedestrians who have arrived at 

the route destination so far). 

The following route choice parameters are provided: 

Option Description 

Best Route The user-defined percentage of pedestrians uses the best 

route, i.e. the route with the minimum travel time. 

In case of two best routes, either route is charged equally. 

All other pedestrians are split randomly among all other 

routes. 

Kirchhoff The probability of a route is calculated as the inverse of the 

travel time to the power of the user-defined exponent a 

divided by the sum of these powers for all routes: 

(1/TravTime_i)â / SumOfAllRoutes_i (1/TravTime_i)â 

Logit The probability of a route is calculated as exp to the power of 

(the negative travel time divided by the user-defined 

denominator) divided by the sum of these powers for all 

routes: 

exp(-TravTime_i/denominator) / SumOfAllRoutes_i 

exp(-TravTime_i/denominator) 

Inverse 

Logit 

The probability of a route is calculated as exp to the power of 

(the user-defined numerator divided by the travel time) 

divided by the sum of these powers for all routes: 

exp(numerator/TravTime_i) / SumOfAllRoutes_i 

exp(numerator/TravTime_i) 



Overview of the properties of the route choice parameters (data type: 

double): 

Parameter Decimal places Default value Unit 

Best Route - Percentage 1 90.0 % 

Kirchhoff - Exponent 1 1.0 

Logit - Denominator 0 10 s 

Inverse Logit - Numerator 0 10 s 

7.1.8.3 Static partial routes of pedestrians: Use cases 

Basically, there are two different ways to make use of static partial routes. 

► Use case 1 is to easily distribute pedestrians with long routes on rather 

narrow spaces without making them forget their main route. 

► Use case 2 makes use of the “catch all” ability of static partial routing 

decisions: it helps to spatially distribute pedestrians in a better way, if 

their current position already suggests a certain further routing variant: In 

this case, typically only one route is attached to a routing decision. 

In the following cases, a partial routing decision can apply to a pedestrian: 

► If the pedestrian enters an area carrying a partial routing decision. 

► If the pedestrian starts to follow a new main route. 

This means, there are cases in which a partial routing decision is ignored, 

though following a partial routing decision could be expected under certain 

circumstances: 

► Two areas called A and B carry a partial routing decision each (a and b). 

Area B is located completely within area A. Thus, a pedestrian will 

always step on area A first and might then step on area B, if applicable. 

The main route and the partial routes are defined in the following way: 

Partial routing decision b applies to the pedestrian, but partial routing 

decision a does not. However, partial routing decision a would become 

valid, if partial route b had been added to the main route. Nevertheless, 

partial routing decision a is not used – neither right after partial routing 

decision b nor when the pedestrian merely stands on area A after leaving 

from area B. 

► During the simulation, a pedestrian enters the network and receives a 

main route. At his position, there are two more partial routing decisions 

called a and b. Partial route a leads to an area that also carries an 

intermediate destination of the pedestrian’s main route, but partial route b 

does not. Partial route b leads to an area that also carries an 

intermediate destination of partial route a. Nevertheless, only partial 

routing decision a is regarded, whereas partial routing decision b is not, 

since it is required for the check for existing partial routing decisions that 

a normal routing decision must have been performed. However, if partial 

routing decision b is not located directly at the position where the 



pedestrian has been generated but on an area the pedestrian entered in 

the next time step, then it will be performed, of course. 

Due to these restrictions endless loops which might arise in a single time 

step can be avoided. 

Use case 1 

Imagine pedestrians coming from different rather remote sources on routes 

with quite a few intermediate destinations, passing one common area with 

alternative routing options independent of the pedestrians’ source or 

destination and walking (with source-dependent ratios) to different remote 

destinations and again quite a number of intermediate destinations on their 

paths to come. In this case it is very helpful to model the route choice on the 

common area with special partial routes that pose only local changes to the 

routes and not to the path to come. As an example see the following figures, 

where the long up- and downstream route legs have been omitted. (Normal 

routes are depicted yellow, partial routes appear orange.) 



To make the static partial route choice apply, the destinations of all partial 

routes need also to include an (intermediate) routing point of the main route. 

Without static partial routes, the long main routes would have to be defined 

as a whole as many times, as there are local alternatives on the area in 

common. 

Use case 2 

A problem with ticket gates is that simulated pedestrians mostly prefer to 

walk on the shortest path. They do not automatically detour to save time, 

even if the detour is as short as in the case of ticket gates. Therefore – if the 

pedestrians do not approach orthogonally to the line of ticket gates – they 

may cram unrealistically into one or two ticket gates, ignoring any other. 

Static partial routes do not solve the problem (for this purpose, dynamic 

partial routes should be applied, which will be provided soon) but help to 

build a workaround. 

As the coordinate of a pedestrian being a few meters ahead of the ticket 

gates determines to some extent, which ticket gate he would use in reality, 

one can use the “catch all” ability of static partial routing decisions to guide 

him through that particular ticket gate, as to be seen from the figures below. 



In fact the routing decision is not a routing decision here, as there is only one 

route attached to each decision. This underlines that it is the “replacing” 

ability that generates the benefit here. 




Similar situations of “shortest vs. quickest route” issues can alternatively be 

addressed using the functionality of the dynamic potential (cf. section 

7.1.8.8 et sqq.). 

This functionality suits especially for alternative routes which are less 

distinct as in the case of ticket gates, or which are not at all discrete as for 

example, when a large crowd has to do a 90 degree or a u-turn around a 

corner. 

The definition of static or partial routes is a six step process. The next 

required action is shown in the status bar. To discard the recent step and 

return to the previous step, click outside the VISSIM network. 

1. Activate the Pedestrian traffic mode and the Pedestrian Routes mode 

2. Select the pedestrian area on which the decision shall be located. 

3. Right-click inside the area at the desired position to place the new routing 

decision at the cursor position. 

A red dot appears representing the new routing decision. The dot is 

merely a graphical representation – routes will be available to all 

pedestrians (when affected due to type/class) entering the corresponding 

area of pedestrians. 

The Create routing decision window appears. 

Select the Type of the routing decision and confirm OK. 

For the attributes and attribute editing please refer to section 7.1.8.6. 

4. Select the walkable construction element (area/ramp) which is the 

destination. 

5. Right-click to define the position of the destination (green dot). The beeline 

will be highlighted yellow and the Pedestrian routes window will 

appear. Enter the properties and confirm OK. 

If there is no continuous connection, no route will be suggested and the 

window will not open. In this case, either select a different destination or 

check the VISSIM network. 



6. Further steps depend on the type of the routing decision: 

Static routes: To define more destinations, i.e. several routes starting 

from this decision (red dot), continue as follows: 

- Select another destination area. 

- Right-click to mark the position of the destination. 

Repeat these steps for any further destination to be reached from 

this decision. 

Partial routes: To define more routes, i.e. several routes starting from 

this decision (red dot) and leading to the same destination, continue as 

follows: 

- Select the same destination area. 

- Right-click to mark the position of the destination. 

- Edit the course of the new partial route currently being highlighted by 

a yellow line, if applicable: 

Click the yellow handle in the middle of the line and keep the mousekey 

pressed while dragging the handle to the new position, which is 

either a ramp or an area. In this way, you can place an intermediate 

point in the course of the route. If required, you may shift the newly 

created yellow handles to define further intermediate points in the 

partial route for the benefit of realistic modeling. User-defined 

intermediate points in the course of a partial route appear blue. 

Within the same walkable area, immediate consequent intermediate points 

are not permitted along one static or partial route. 

Repeat these steps to create more partial routes starting from the 

currently selected routing decision. 



To define another routing decision, double-click in the network to deselect all 

areas and repeat the steps 1 - 6. 

In the Pedestrian Routes window, the following settings are required: 

► Select appropriate Pedestrian class(es) by routing decision. 

► Set the time intervals for all routing decisions of the Static type. 

► Set separate time intervals for all routing decisions of the Partial type 

with route choice method Static. 

► Select the route choice method by routing decision of the Partial type 

and set the parameters. 

7.1.8.5 The Pedestrian Routes Window Structure 

Below, find example settings which illustrate the properties of routing 

decisions and routes described in this section. 



Static 

routing 

decisions 

Partial 

routing 

decisions 

with route 

choice 

method 

Static 

Partial 

routing 

decisions 

with route 

choice 

method 

Travel 

Time 


Partial 

routing 

decisions 

with route 

choice 

method 

Service 

point 

selection 

Tabs 

(Types of 

Decisions) 

List of 

Routing 

Decisions 


The data describing routing decisions for pedestrians and their routes is 

arranged in the following sections of the Pedestrian Routes window: 

For each type of routing decision, this section contains a specific tab. Since 

defined routing decisions are stored and edited by type, each tab contains 

the list of routing decisions of this type. Each tab page allows for the 

following steps: 

► Select a single or multiple or all routing decision(s) of this type: 

- You can edit the list of routing decisions. 

- You can call the route list display in the Routes section and edit the 

list of routes. 

► Delete the selected routing decision(s) of this type from the list. 

► For a single decision, you can edit the following data: Name of the 

decision, Start area; Destination area, Ped. class(es), Route choice 

method. 

The content of the sections to the right depends on the particular routing 

decision type and on the selected decision(s). 

The list of pedestrian routing decisions in the left-hand section of the 

window allows for the following: 

► Selection of a pedestrian routing decision for data editing, 

► Deletion of a selected pedestrian routing decision from the list, 

► Selection of multiple pedestrian routing decisions for route list display 

and editing in the Pedestrian Routes section. 

The content of the sections to the right depends on the currently selected 

routing decision(s). 

Decision Via and you can open or close this section. 

If only a single routing decision is selected in the list, this section allows for 

input data editing, e.g. allocation of the appropriate pedestrian class(es). 



List of 

routes or 

partial 

routes, as 

applicable 

The list contains: 

► all (partial) routes starting from decisions which are currently selected in 

the list of pedestrian routing decisions. 

Due to the particular routing decision type it contains also the following 

details, if applicable: 

► all time intervals (columns) resulting from time settings, and 

► the user-defined amount of pedestrians as share of 100% per route and 

time interval. 

This section allows for the following: 

► Editing the properties of the selected routes or partial routes, 

► Deleting the selected (partial) routes from the list. 

For Sorting & Filter options provided in the list of routing decisions and in the 

list of routes, please cf. section 6.4.4.5. 


For the definition of a new routing decision for pedestrians the following 

properties have to be set: 

● Decision No.: Unique identification of the routing decision 

● Decision Name: Label or comment 

● Location: Number of the start area and name, if applicable 

● Type: At present, either Static or Partial can be selected 

In the Pedestrian Routes window, the following properties can be set: 

● Start Area: Location of the routing decision 

● Destination Area (only for partial routes): Number of the destination area 

selected for the partial routing decision. 

● Pedestrian Classes: From a drow-down list, select the pedestrian classes 

to be affected by this routing decision. For multi-selection, press CTRL 

while clicking the left mouse button. 

● Route choice method (only for partial routes): From a drow-down list, 

select the route choice method to be used by this routing decision. Set 

the appropriate route choice parameters. 

The following methods are provided: 

- Static 

- Travel time, cf. section 7.1.8.8 

- Service point selection, cf. section 7.1.8.13 

Properties of a route or partial route of pedestrians: 

● Route No.: Unique identification of the route or partial route. 

● Destination Area: Number of the destination area of the route or partial 

route. 

● Value per time interval (only for static routes and static partial routes): 

From the ratio values of the routes, the relative flows are calculated 



Graphical 

selection 

Selection 

in the Pe- 

destrian 

Routes 

window 


automatically by routing decision. If the sum of shares is not 1 (100%), 

VISSIM automatically norms the shares. Example: If a ratio of 1, 1, and 2 

is specified for three routes belonging to a single routing decision, the 

upper two routes will receive 25% each and the last one will receive 50% 

of the flow. 

● Maximum number of queuing pedestrians (only for partial routes with 

route choice method Service point selection) 

● Route choice parameters and Number of the pedestrians to be regarded 

for travel time calculation (only for partial routes with route choice method 

Travel time) 

For all subsequent actions the Pedestrian traffic mode and the 

Pedestrian Routes mode need to be active. 

Display in the Pedestrian Routes mode: 

► all defined routing decisions for pedestrians are shown as dark red dots 

► all defined destinations are shown as dark green dots 

Selection of a pedestrian routing decision: 

1. Optionally left-click the area where the routing decision is located, 

2. Left-click the routing decision: 

- The selected routing decision is displayed as light red dot. 

- The corresponding destinations are displayed as dark green dots. 

Destinations belonging to other routing decisions are hidden. 

Selection of a route starting from the selected routing decision: 

1. Optionally left-click the area where the destination is located, 

2. Left-click the destination: 

- The selected destination is displayed as a light green dot, 

- the route is displayed as a yellow band with intermediate point(s). 

► Open the Pedestrian Routes window and select the appropriate tab for 

display of all pedestrian routes and routing decisions of this type in the 

network: 

► Right-click outside of the VISSIM network calls the complete list of 

routing decisions. 

If a pedestrian routing decision is currently highlighted, the appropriate 

routes will be listed in the Route List. 

► Double-click on a routing decision. 

If a route is currently displayed as a yellow band, the selected route will 

appear color-shaded in the Route List. 

Alternatively, a route´s destination can be double-clicked. 



All routes of those routing decisions being selected in the list of routing 

decisions are listed in the particular Route List. 

All routes being selected in the Route List are automatically highlighted as 

yellow bands in the network display. 

► To select a single route or routing decision in the list, click in the grey 

cell to the left of the particular line. The previously selected route or 

routing decision is automatically deselected. 

► To (de)select multiple routes or routing decisions, press CTRL or SHIFT 


Delete In the Pedestrian Routes window: 

► Select one or several routing decisions or routes 

► Press DEL or click DELETE in the context menu 

With a routing decision, all of its routes are deleted. 

Edit route 

alignment 

Edit 

listed data 

A pedestrian route is graphically represented by a yellow line spanning 

between either two successive strategic points of the route. The center 

point of each yellow line is marked by a smaller yellow dot. The dot does 

not represent an intermediate stop but serves for editing the course of the 

route: 

► Left-click and drag the yellow handle onto another area while keeping 

the mouse-key pressed. The currently selected area is highlighted on 

screen. 

► Release the mouse-key if the correct area is marked. 

► In case of several overlapping areas hit TAB as often as necessary to 

select the desired area. 

On the chosen area, a new strategic intermediate point will be placed that is 

marked by a blue dot. 

The start can neither be placed on a stair or ramp nor on links that have 

been defined as areas. Just areas can carry this information. 

Intermediates stops and the ends of pedestrian routes can be placed on 

areas and ramps/stairs. 

In each of the lists in the Pedestrian Routes window, 

► right-click calls a context menu providing DELETE to remove the 

selected row(s) from the list, 

► editable properties can be edited directly in selected cells. 



Example The figure illustrates a pedestrian route with one intermediate strategic 

point: 

7.1.8.8 Dynamic Potential: Overview 

The dynamic potential is a route-related method to control operational 

wayfinding. The basic intention is to make pedestrians walk not on the 

shortest but more on the quickest path. 

Additionally to this overview, the following information on the dynamic 

potential of pedestrian wayfinding is provided below: 

► For use case descriptions, cf. section 7.1.8.9 

► For the editing workflow, cf. section 7.1.8.10 

► For the properties & options, cf. section 7.1.8.11 

► For the method in detail, cf. 7.1.8.12 

One way to look at the dynamic potential is to see it as a continuous 

complement to travel time based dynamic partial routes. For both the basic 

idea is that minimizing travel time is a determinant of walking behavior. 

However, while travel time based partial routes offer a way to make 

pedestrians discretely choose between distinct routes at one point in time. 

With the dynamic potential activated for a destination or intermediate 

destination (in the remainder of the section intermediate destinations are 

always included, when destinations are mentioned) pedestrians are seeking 

to walk what they currently estimate to be the quickest path. In slightly more 

technical terms: they desire to walk into that direction in which by estimation 

of some heuristic mathematical method their remaining walking time to the 

next destination is minimized. 

Already in this rough description of the method of the dynamic potential the 

continuous character is exhibited: there is not one single time of decision, but 

– as far as the time step of the simulation allows – a continuous optimization 

behavior of the pedestrians with regard to travel time; the pedestrians do not 

try to walk on one (the one with the smallest travel time) out of a finite 



number of user-defined routes, but with the dynamic potential, they implicitly 

select their route out of a continuous, infinite and uncountable set of potential 

trajectories. 

7.1.8.9 Dynamic Potential: Use Cases 

Compared with travel time based partial routes and partial routes in general, 

there are many use cases, which in principle could be addressed either with 

the dynamic potential or using partial routes, and the difference in the degree 

of how these are suited also can be large or small, i.e. in one case – after 

some experience with both – it is obvious that partial routes are the method 

of choice, in another only the dynamic potential can lead to the expected 

behavior, in a third group success might come with either method and a 

fourth group contains those cases to which neither the partial routes nor the 

dynamic potentials can so far successfully be applied. 

There is a rule of thumb which method probably would be the better one to 

be used. As partial routes are discrete and the dynamic potential is 

continuous in many aspects, one at first think of partial routes to model 

situations of discrete choice and the dynamic potential to model continuous 

choices. The simplest examples are probably the flow of a large group of 

pedestrians around a 90° or 180° corner to be modelled with the dynamic 

potential but to use partial routes, when in the corner there is an array of 

ticket gates which discretizes the choice set. “In the corner” here implies that 

the path length from origin to destination is different for each ticket gate. 

Nevertheless, as the editing effort for the dynamic potential usually is much 

smaller than for partial routes, one might sometimes try to model situations 

with the dynamic potential which appear to be better suited for partial routes. 

For that reason it is intended to offer a refined dynamic potential method in 

future VISSIM versions, which extends its scope of application into what 

currently is the realm of partial routes. 

7.1.8.10 Dynamic Potential: Editing 

Follow the steps outlined below to define the dynamic potential: 

► Activate a route such that it is shown with all red, blue and green dots 

and the yellow line. 

► Press the ALT key while double-clicking on a destination point (green or 

blue). 

The Routing Point window appears, cf. section 7.1.8.11. 

► Activate the option Use Dynamic Potential. 

► Set the Impact which describes the strength of influence. 

- If the value is 1% the method is activated and calculation time for it is 

consumed (as much as for any other parameter choice), but it almost 

has no effect and the pedestrians continue to desire to walk on the 

shortest path. 



- The higher the value, the more sensible is the reaction of the 

pedestrians to the movement of pedestrians in front of them. At 

values near 100% this can cause unrealistic behavior. 

► Set the length of the Calculation time interval for the update of the 

potential. The method of the dynamic potential takes quite some time to 

be calculated, increasing this value may help on slower PCs or with 

many dynamic potentials activated that the simulation speed will stay 

reasonable. However, so far the experience is that the smaller the value, 

the better the results are. 

► Close the dialog. The blue or green dot of the route now changes to be a 

square, which visually marks those destinations for which the dynamic 

potential has been activated. 

7.1.8.11 Dynamic Potential: Properties & Options 

How to select a route for changes to the current dynamic potential settings is 

described in section 7.1.8.10. 

● Use Dynamic Potential: Activate this option to use the dynamic potential 

for way-finding. 

● Impact: Enter the impact as percentage for correct modeling of the 

strength of influence of the dynamic potential on the behavior of the 

pedestrians. 

● Calculation time interval: Enter the length of the interval between two 

updates of the potential in simulation seconds. 

7.1.8.12 Dynamic Potential: Description of the Method 

To understand the essentials of the dynamic potential method one first has to 

ask, how in general pedestrians in the simulation find their next destination 

area. This is accomplished by having the driving force of the social force 

model point into the direction of the next destination as long as the 

pedestrian does not already walk into that direction: 



In this equation, v_alpha is the current velocity of the pedestrian, v 0 _alpha is 

his desired speed taken from a distribution defined by the user. The crucial 

value is the unit vector e_alpha which multiplied with the desired speed 

gives the current desired velocity. 

Up to now e_alpha in VISSIM always has been pointing into the direction of 

the shortest path. With the dynamic potential the idea is that it points into a 

direction which is a current estimation for the direction of the quickest path. It 

can never be analytically the “true” and correct direction of the quickest path 

as such a solution could only in principle be the result of an iterated 

simulation. Yet, up to now no such method exists for pedestrians, not even 

for small systems unless they are trivially small (e.g. just one pedestrian). As 

real pedestrians also err a lot about what at a current point in time is the 

direction that will take them in quickest time to their destination, it is not a 

principle problem that the true direction of the quickest path can not be 

calculated exactly. Therefore assuming hypothetically that the direction of the 

quickest path would be available in the simulation and thus the behavior of 

all pedestrians would be individually optimal, it would probably not be 

realistic. 

The meaning of the parameter impact is that an e_alpha s for the direction of 

the shortest path and an e_alpha q for the direction of the quickest path are 

calculated and then a resulting e_alpha is calculated in which e_alpha s and 

e_alpha q have weights according to the value of the parameter Impact. 

No matter if e_alpha points into the direction of the shortest path (dynamic 

potential deactivated) or the estimated quickest path (dynamic potential 

activated 100%) it is always calculated by at first calculating values for the 

points of a grid which give either the distance or the estimated remaining 

travel time from that particular point to the corresponding destination area. 

This grid is what is called potential, another name would be “look-up table”. 

As the distance to the destination does not change in the course of a 

simulation run, the potential holding the distance values is called static 

potential. As, on the contrary, the estimated remaining travel time to the 

destination – under consideration of the presence of all other pedestrians – 

changes continuously this potential is called dynamic potential. One can 

imagine the values of a potential as elevation values and e_alpha then 

points into the direction of steepest descent, mathematically it is the 

(negative) gradient. 

The potentials are calculated by driving a front outward from the boundaries 

of the destination area. This can be imagined as tipping some object onto a 

water surface and following the out-most wave front, for each point of the 

surface noting, at which time after the tipping it was reached. For the 

calculation of the static potential the speed of the wave front is everywhere 

the same, for the dynamic potential it is slower, if a spot is occupied by a 

pedestrian (in fact the relative walking orientation of the pedestrian also has 

an impact on the speed of the wave front). Mathematically this is the 

numerical solution of the Eikonal equation using a method similar to the Fast 

Marching Method. 



Once e_alpha has been calculated – be it based on the static or the dynamic 

potential – it is set into the driving force term and the sum of the driving force 

and the social forces makes up for the acceleration of the pedestrian in that 

particular time step. 

7.1.8.13 The Service Point Selection Method 

The dynamic routing of pedestrians can be performed by means of the 

service point selection method. 

The route choice method Service Point Selection is intended for these 

scenarios: 

1. Central queue: 

To model a “first come - first served“ principle if there are multiple service 

points that are all fed by a single queue. In reality this principle is often 

used at post offices, airports or railway stations. 

2. Immediate service point allocation: 

As a (simple) decision model if there are multiple service points that all 

have individual queues and a person needs to decide which queue to 

join. Usually he tries to find the queue where he reaches the service 

point as fast as possible, but this is not easily predictable especially if 

there is a large number of queues and/or queuing people. This situation 

can often be found at supermarket checkouts or ticket gates. 

3. Survey/interview: 

Single pedestrians walking by are asked to stop for a short time (e.g. to 

answer a few questions of a questionnaire) before they continue their 

path. 

Pedestrians that are affected by this partial routing decision are directed to 

either 

► the central queue (on the queuing area with an optional dwell time where 

the partial routing decision is located) or 

► directly to one of the service points if at least one queue at a service 

point is not longer than the value defined in the routing decision 

parameters. If all queues are “filled”, the partial routing decision is 

ignored (i.e. the pedestrian ignores the service points). 

The service point is the first queuing area in the route sequence that contains 

an intermediate point of the partial route. Each queuing area may have an 

optional dwell time distribution assigned. 

Modeling suggestions for the situations mentioned above 

Direction of flow for all illustrations is from left to right. 

Notes on the images below: 



Display Meaning 

Pedestrian area; Option Queuing has been checked 

Pedestrian area; Option Queuing has not been checked 

Partial routing decision with route choice method Service 

point selection 

Scenario 1: Central Queue 

Typical queuingThreshold Proceed to service point if no more than __ people 

are queuing there = 0. This factor ensures that there is no queue at a service 

point. 

Scenario 2: Immediate service point allocation 


are queuing there = 99. This factor guarantees that all pedestrians join a 

queue. 


Scenario 3: Survey/interview 



are queuing there = 0. This factor ensures that there is no queue at a service 

point. 

Prerequisites and Conditions for Application 

► There is one main difference between partial routing decisions with the 

method Service point selection and other partial routing decisions: In 

order for the partial route to be “seen” by a pedestrian, an intermediate 

point of the original route of the pedestrian must be located on the area 

where the partial routing decision is defined (decision area). Pedestrians 

following a route that has no intermediate point on the decision area are 

not affected by the partial routing decision (and they do not proceed to a 

service point, of course). 

► Each of the partial routes needs to include at least one intermediate 

point on a queuing area (with an optional dwell time). 

► For a central queue, the routing decision must be placed on a queuing 

area (with an optional dwell time) 

► For an immediate service point allocation, the routing decision must not 

be placed on a queuing area. 

Calculation Methods 

n is the route choice method parameter (queuingThreshold) that can be 

edited by the user which defines the maximum number of pedestrians 

queuing at one service point that still allows selection ot that queue. 

► If the decision area is a queuing area, the first pedestrian in the queue 

1. waits until his waiting time at the decision area is over (if a waiting 

time distribution is defined there), 

2. continues to the best queue only if at least one service point has no 

more than n pedestrians queuing. If all queues are “full”, the 

pedestrian waits until a space in one of the service point queues 

becomes available. 



The partial routing decision may be defined for specific pedestrian classes. 

If the decision area is a queuing area with an additional dwell time 

distribution defined, then all pedestrians of other classes than the specified 

ones will be affected by the queue as well, if they are currently on a route 

which has an intermediate point on the “Service point selection” decision 

area. Then they will wait in the same queue but will not continue to any 

service point. Instead, they will then continue on their original route. 

If the decision area is a queuing area without a dwell time distribution, then 

all such pedestrians will queue in the queue only until they reach the 

decision area and then continue immediately on their original route. 

Pedestrians who are not affected by the partial routing decision because 

their route does not have an intermediate point on the destination area of 

the partial routes are treated the same way, i.e. they can still be part of the 

queue if there is a dwell time distribution assigned to the decision area or if 

the queue extends outside of the decision area. 

Summary: All pedestrians on a route with an intermediate point on the 

decision area are affected by the queue outside of the area. Inside, they are 

only affected if there is a dwell time assigned or if they will select one of the 

service points (i.e. if they belong to one of the specified pedestrian classes 

and their original route has an intermediate point on the destination area of 

the partial routes. 

► If the decision area is no queuing area, each pedestrian (of the 

specified class) entering the decision area 

1. waits until his waiting time at the decision area is over (if a waiting 

time distribution is defined there), 

2. continues to the best queue if at least one service point has no more 

than n pedestrians queuing. If all queues are full, it continues with its 

original route (ignoring all service points). 

► The best queue is calculated as follows: 

- Select from all queues where no more than n pedestrians are 

queuing. 

- If more than one such queue exists, choose the one with the smallest 

number of pedestrians (= shortest queue). 

- If there is more than one shortest queue, choose from these the 

queue end nearest to the routing decision (bee line). 

Pedestrians who are on their way to a service point or the corresponding 

queue are considered to be in the queue already. 

Note that only the first queuing area on each route after the routing 

decision is considered (and not any further queuing areas that follow 

downstream within the partial route). 


7.1.9 Area-based Walking Behavior 


Walking behavior is composed from a desired speed, which is allocated to 

the pedestrian composition, and the parameters of the pedestrian dynamics 

model, which are allocated to the pedestrian type. Additionally there is the 

possibility to assign area-based walking behaviors to areas and ramps. 

An Area-based Walking Behavior is composed of the following: 

► One or more Walking Behavior Parameter Sets 

► A class of pedestrians to which it applies for each Walking Behavior 

Parameter Set. 

A Walking Behavior Parameter Set comprises of the following: 

► A time interval structure 

► For each time interval: a desired walking speed distribution 

► For each time interval: a parameter file 

7.1.9.1 Walking Behavior Parameter Sets 

Similar to a driving behavior parameter set for a vehicle class (cf. section 

5.4), a walking behavior parameter set is applied to pedestrians belonging to 

a certain class of pedestrians. 

The walking behavior is linked to each walkable element by the area 

behavior type. For each class of pedestrians, a different walking behavior 

parameter set may be defined - even within the same walkable element (for 

details cf. section 5.5). 

The parameter sets can be edited in the Walking Behavior Parameter Sets 

window which is accessible by BASE DATA – WALKING BEHAVIOR. 

By default, several parameter sets are provided in XML data file format in the 

sub-folder EXE\PEDESTRIANMODELDATA of your VISSIM installation. 

For the parameters in detail, please refer to section 7.6. 

For time interval definition and editing, please refer to section 6.4.3.1. 



Add 

parameter 

set 

Duplicate 

parameter 

set 

Delete 

parameter 

set 

Edit parameter 

set 

In the list of walking parameter sets: 


► Left-click NEW to add a new line to the list. 

- In the Details section, edit No. and Name, if applicable. 

- In the Time section, edit time interval(s), if applicable. 

- In the list of time intervals, select a Desired speed distribution for 

each time interval. 

In the list of walking parameter sets: 

► Select a parameter set. 


► Left-click DUPLICATE to copy the selected line in the list. 

A new parameter set is created with the properties of the selected one 

but a new number. 

► Edit the settings in the tab page. 



► Left-click DELETE in the context menu. 


► Edit the settings in the tab page. 

7.1.9.2 Area Behavior Types of Construction Elements 

The sets of area behavior types can be edited in the Area Behavior Types 

window which is accessible via BASE DATA – AREA BEHAVIOR TYPES. 



Add type Right-click in the list of area behaviour types (or column header) to call the 

context menu, then left-click NEW (or DUPLICATE after selection of a set): 

● In the upper section of the window, you may edit No. and Name. 

● In the list in the lower section, call NEW in the context menu to allocate 

the pedestrian class(es) to a walking behavior parameter set. 

Delete type ● Select the type in the list of area behaviour types. 

● Choose DELETE from the context menu. 

Edit type 

● Select the type in the list of area behaviour types. 

● In the data section to the right, edit Name or Number in the upper 

section or edit the allocation of Pedestrian Class and Behavior 

Parameter Set in the list below. 



7.2 Evaluation Types for Simulations of Pedestrians 

This section describes the options for the evaluation of pedestrian traffic. 

Similar to the vehicle information (cf. section 11.6), the online data of 

selected pedestrians can be displayed in separate windows, cf. section 7.2.5. 

Other evaluations can be stored in files or databases: Via menu EVALUATION 

– FILES the window Evaluations (File) can be called. The [PEDESTRIANS] tab 

allows for the configuration of pedestrian traffic evaluations, cf. section 10.1. 

7.2.1 Pedestrian Travel Time Measurements 

A travel time measurement for pedestrians consists of a “directed” pair of 

pedestrian areas (using existing normal areas): One of these is the starting 

area – pedestrians entering it get tracked by the device until they enter the 

corresponding destination area. When this happens, the following 

observables are recorded and written to an ASCII file associated with the 

travel time measuring device: 

● Arrival time at end of the measurement 

● Measurement number 

● Pedestrian number 

● Pedestrian type 

● Total distance walked between start and end of the measurement 

● Total time needed to walk from start to end of the measurement 

● Sum of “time lost” while walking between start and end of the 

measurement. This is the sum of “wasted times” in every time step 

computed from the difference between actual walking speed and desired 

walking speed (if walking slower than intended). Attention: Delays 

caused by walking along non-optimal paths etc are not regarded. 

● Sum of “time gained” while walking between start and end of the 

measurement. This is analog to the value above but summed up when 

actually walking faster than desired. 

● Deviation between the pedestrians’ current speeds and the desired 

speeds during walk from start to end. 

Contents and format of evaluation files are shown below. 


Evaluation Types for Simulations of Pedestrians 

The evaluation files are named automatically: The file name is the name of 

the input file and the file extension is either *.RSRP for raw data or *.RSZP 

for compiled data. Those files will be stored in the path where the input file is. 

Inserting a new travel time measurement is done by selecting an existing 

pedestrian area and inserting the start point of the device by right-click. The 

start point will be marked with a red dot. Then select another pedestrian area 

and insert the end point of the device by right-click again. The end point of 

the device will be marked with a green dot. 

After inserting a new travel time measurement device or double-clicking an 

existing one, the details dialog comes up: 

In contrast to properties dialogs of other network elements, all travel time 

measurements have one dialog window in common: They are always shown 

in tabular form. 

You can edit the no. and name of the measurement and the start/end 

locations. 

In the Output column, you can set up the preselection for the Active travel 

times list in the Configuration window. 

Definition 

Define a pedestrian travel time measurement as follows: 

► Click the Pedestrian Traffic mode icon. 

► Click the Travel Time Sections icon. 

Follow the steps outlined in the status bar for pedestrian travel time 

measurement definition. Generally, it can be compared to travel time 

measurement for vehicles, cf. section 11.1. 

Configuration 

Click menu EVALUATION - FILES - [PEDESTRIANS] tab, check option Travel times 

and click the CONFIGURATION button to call the Configuration window: Set 

time data and select defined travel time evaluations as well as the desired 

output data format. 



Results 

Structure of the output data file: 

► File title 

► Path and name of the input file (File) 

► Simulation comment (Comment) 

► Date and time of the evaluation (Date) 

► Version no. with Service pack no. and Build no. (VISSIM) 

► List of all cross section measurements that have been evaluated 

► Brief description of the evaluated data 

► Table with the measured data 

As for Travel times of vehicular traffic, you can create two types of output 

files for pedestrians. 

Example: Compiled data file *.RSZP 

Pedestrian travel time measurement (compiled data) 

File: E:\Programme\PTV_Vision\VISSIM520\Examples\Training\Pedestrians\HR.inp 

Comment: 

Date: Monday, July 28, 2009 9:11:44 AM 

VISSIM: 5.20-00 [16277] 

Time; Trav; #ped; Trav; #ped; No; 

30; 0.00; 0; 0.00; 0; 1; 

60; 0.00; 0; 0.00; 0; 1; 

120; 0.00; 0; 0.00; 0; 2; 

Example: Raw data file *.RSRP 

Pedestrian travel time measurement (raw data) 

File: E:\Programme\PTV_Vision\VISSIM520\Examples\Training\Pedestrians\HR.inp 

Comment: 


Date: Monday, July 28, 2009 9:11:44 AM 



t : Time ped. entered dest. area of travel time measurement [sim.second] 

No. : Travel time measurement number 

PedNo : Pedestrian number 

PedType : Pedestrian type 

TravDist : Distance traveled from start to destination area [m] 

TravTime : Time traveled from start to destination area [s] 

TimeDelay : Time delay [s] while traveling from start to destination area 

TimeGain : Time gain [s] while traveling from start to destination area 

DevSpeed : Differences [km/h] between actual speed and v_des 

t; No.; PedNo; PedType; TravDist; TravTime; TimeDelay; TimeGain; DevSpeed; 

32.2; 15; 409; 200; 83.2; 31.2; 13.7; 0.0; 0.7; 

34.7; 14; 47; 100; 87.8; 34.5; 16.2; 0.0; 0.6; 

35.7; 14; 185; 200; 87.9; 35.2; 13.8; 0.0; 0.5; 

Raw data output: 

Column Description 

t Time pedestrian entered destination area of travel time 

measurement [simulation second] 

No. Travel time measurement number 

PedNo Pedestrian number 

PedType Pedestrian type 

TravDist Distance traveled from start to destination area 

TravTime Time traveled from start to destination area [s] 

TimeDelay Time delay [s] while traveling from start to destination 

area 

TimeGain Time gain [s] while traveling from start to destination area 

DevSpeed Differences between actual speed and desired speed 

7.2.2 Pedestrian Area Evaluations 

Area-based evaluations provide the collection of data gained from userdefined 

sections on walkable elements. 

Generally, it can be compared to data collection for vehicular traffic, cf. 

section 11.3. 

Definition 

Define a pedestrian measurement as follows: 

1. Click the Pedestrian Mode icon. 



2. Click the Measurement Areas icon. 

Follow the steps outlined in the status bar for measurement area definition. 

Right-click in the network calls the list of defined measurement areas: 

Measurement areas are only displayed, if the Measurement Areas mode is 

active. 

As 3D display has no modes, there is currently no way to see 

measurement areas in 3D display. 

To gain correct output data, please check the assigned level by measurement 

area and adjust it accordingly in this grid. 

A visual check for correct placement on the levels can be done in 2D 

display using the level display option, cf. section 7.1.4.6. 

Configuration 

Call the Area Evaluations window as follows: 

1. Click menu EVALUATION – FILES and select the [PEDESTRIANS] tab 

2. Check option Area evaluation 


Additional settings are required for the desired data output and data format: 

● EvaluationNo. (Areas): 

List of defined area 

evalulations (with the 

area numbers in 

parentheses). 

● Click NEW to define a 

new evalulation. 

● Click EDIT for changes 

to an existing one. 


Click CTRL simultaneously to select multiple 

areas for an area evaluation. 


Alternatively, you can use the button GENERATE 1:1 for area evaluation 

definition. 

● GENERATE 1:1: For each single measurement area, a separate area 

evaluation is created (even if the area has already been selected for 

another area evaluation). 

● Time: Define the evaluation period and the length of aggregation 

intervals. 

● Output: Select the desired data format. 

- Raw data: Stores all pedestrians traversing the measurement area in 

chronological order in an *.MERP file (Area evaluation raw data) 

Compiled Data: Stores the selected parameters (using the selected 

aggregate function (mean, min, max, if applicable) in an *.MESP file. 

● CONFIGURATION: In the Area evaluation – Configuration window, the user 

can select the desired parameters and arrange them in the desired order. 

These settings are only regarded for Compiled data output. 

The selected parameters are listed in the Layout of columns section. 

- Use the buttons MOVE UP and MOVE DOWN for the final arrangement 

of columns in the output file (1 st row = 1 st column). 

- Use the buttons to add the selected parameter to the layout 

section (and to remove it from the layout section). 



- For some of the parameters, one of the aggregate functions has to 

be selected: Minimum, Maximum or Mean. 

The Configuration settings file is saved as *.MESPK file. 

Results 

Pedestrian area evaluations are output only if at least one pedestrian input 

has been defined. 

Structure of the output data file: 






► List of all areas that have been evaluated 


► Table with the measured data 

As for Data collections of vehicular traffic, you can create two types of output 

files for pedestrians. 

Parameter Definition Column Header 

Evaluation 

number 

Area evaluation number EvalNo 

Time End of aggregation time interval 

[simulation second] 

t 

Number of 

pedestrians 

Number of pedestrians on 

measurement area(s) 

NumPeds 

Density Density of pedestrians on 

measurement area(s) in [ped/m²] or 

[ped/ft²], as applicable 

Density 

Desired speed Desired speed vDes 

Speed Speed v 

DevSpeed Deviation between actual speed 

and desired speed of pedestrians 

DevSpeed 

Source volume Number of pedestrians who left the 

measurement area(s) 

SourceVol 

AvgXOrientation Average of x values of orientation 

vector 

AvgXOri 

AvgYOrientation Average of y values of orientation 

vector 

AvgYOri 

World coordinate World coordinate z WorldZ 




z 

Total delay time Total time delay [s] on 

measurement area(s) (of 

pedestrians who left measurement 

area(s) during aggr. interval) 

Total distance Total distance traveled on 




Total dwell time Total time [s] spent on 




Total gained time Total time gain [s] on measurement 

area(s) (of pedestrians who left 

measurement area(s) during aggr. 

interval) 

TimeDelay 

TotalDist 

TotalDwell 

TotalGain 

Example: Compiled data file *.MESP 

Underneath the file header, the evaluated areas are listed. 

The second line contains just the number of the particular area evaluation 

(Note: not the number of the defined measurement area(s)) underneath the 

particular block of columns. 

Another line is added for each aggregation time interval. Each of those 

additional lines contains the data gained by area evaluation during this 

interval. 

Area evaluation (compiled data) 

File: D:\Programme\PTV_Vision\VISSIM530\Examples\Training\Pedestrians\HotelRimea.inp 

Comment: 

Date: Friday, October 23, 2009, 1:41:30 pm 

VISSIM: 5.20-04* [20767] 

Area evaluation 1 : Measurement area(s) 1 



AvgXOri : Average of x values of orientation vectors 

AvgYOri : Average of y values of orientation vectors 

Density : Density of pedestrians on measurement area(s) [ped/m²] 

vDes : Desired speed [km/h] 

EvalNo : Area evaluation number 

NumPeds : Number of pedestrians on measurement area(s) 

SourceVol : Number of pedestrians who left the measurement area(s) 



v : Speed [km/h] 

DevSpeed : Deviation of pedestrian speeds [km/h] 

t : End of aggregation time interval [simulation second] 

TotalDelay : Total time delay [s] on measurement area(s) (of pedestrians who left 

measurement area(s) during aggr. interval) 

TotalDist : Total distance [m] traveled on measurement area(s) (of pedestrians who left 


TotalDwell : Total time [s] spent on measurement area(s) (of pedestrians who left 


TotalGain : Total time gain [s] on measurement area(s) (of pedestrians who left 


WorldZ : World coordinate z 

AvgXOri; AvgYOri; Density; vDes; EvalNo; NumPeds; SourceVol; v; DevSpeed; t; TotalDelay; 

TotalDist; TotalDwell; TotalGain; WorldZ; 

; ; Mean; Mean; ; Mean; ;Mean; ; ; 

Mean; Mean; Mean; Mean; Mean; 

0.0502; 0.1603; 0.01; 4.90; 1; 0.0; 4; 1.78; 3.35; 300; 

1.43; 1.11; 2.18; 0.00; 5.12; 

0.0667; -0.1242; 0.00; 4.93; 2; 0.0; 2; 2.79; 2.38; 300; 

0.75; 1.32; 1.60; 0.00; 2.56; 

0.0995; 0.1686; 0.01; 4.71; 3; 0.0; 3; 2.65; 2.25; 300; 

0.67; 1.13; 1.53; 0.00; 0.00; 

Example: Raw data file *.MERP 

In the data block underneath the file header, the set of column headers is 

listed. 

Area evaluation (raw data) 

File: D:\Programmes\PTV_Vision\VISSIM-520\Examples\Training\Pedestrians\Hotel.inp 

Comment: 

Date: Friday, July 10, 2009 2:58:58 PM 




EvalNo : Area evaluation number 

tEnter : Time pedestrian entered measurement area(s) [simulation second] 

tLeave : Time pedestrian left measurement area(s) [simulation second] 


PedType : Pedestrian type 

Dwelltime : Total time [s] pedestrian spent on measurement area(s) 


v : Speed [km/h] 

DevSpeed : Deviation of pedestrian speed [km/h] 

Density : Density of pedestrians on measurement area(s) [ped/m²] 

AvgXOri : Average of x values of orientation vector 

AvgYOri : Average of y values of orientation vector 

WorldZ : World coordinate z 

TimeDelay : Time delay [s] 

TimeGain : Time gain [s] 

Dist : Distance [m] pedestrian traveled on measurement area(s) 

DistNetwork : Distance [m] pedestrian traveled in network so far 



EvalNo; tEnter; tLeave; PedNo; PedType; Dwelltime; vDes; vDes; vDes; v; 

v; v; DevSpeed; Density; Density; Density; AvgXOri; AvgYOri; 

WorldZ; WorldZ; WorldZ; TimeDelay; TimeGain; Dist; DistNetwork; 

; ; ; ; ; ; Mean; Min; Max; Mean; 

Min; Max; ; Mean; Min; Max; ; ; 

Mean; Min; Max; ; ; ; ; 

1; 2.4; 5.4; 87; 100; 3.0; 4.7; 4.7; 4.7; 4.6; 

3.6; 4.8; 0.3; 0.4; 0.2; 0.8; -0.3140; -0.9494; 

5.1; 5.1; 5.1; 0.1; 0.0; 3.8; 6.4; 

1; 3.8; 6.9; 177; 200; 3.1; 4.3; 4.3; 4.3; 4.1; 

3.9; 4.3; 0.2; 0.7; 0.4; 1.0; -0.3583; -0.9336; 

5.1; 5.1; 5.1; 0.1; 0.0; 3.5; 7.1; 

2; 4.3; 7.7; 147; 200; 3.4; 4.0; 4.0; 4.0; 4.1; 

4.1; 4.1; 0.1; 0.6; 0.3; 1.3; 0.0286; 0.9996; 

0.0; 0.0; 0.0; 0.0; 0.1; 3.9; 8.1; 

1; 4.1; 8.0; 85; 100; 3.9; 4.2; 4.2; 4.2; 3.5; 

2.4; 3.7; 0.8; 0.8; 0.6; 1.2; -0.1611; -0.9869; 

5.1; 5.1; 5.1; 0.7; 0.0; 3.8; 7.5; 

2; 5.0; 8.5; 282; 100; 3.5; 4.8; 4.8; 4.8; 4.1; 

4.0; 4.2; 0.8; 0.8; 0.5; 1.0; 0.0017; 1.0000; 

0.0; 0.0; 0.0; 0.5; 0.0; 4.0; 8.6; 

1; 5.0; 9.2; 315; 100; 4.2; 4.3; 4.3; 4.3; 3.0; 

1.9; 3.9; 1.5; 1.0; 0.6; 1.2; -0.4776; -0.8786; 

5.1; 5.1; 5.1; 1.3; 0.0; 3.5; 6.8; 



EvalNo Area evaluation number 

tEnter Time pedestrian entered measurement area(s) 

[simulation second] 

tLeave Time pedestrian left measurement area(s) [simulation 

second] 

PedNo Pedestrian number 

PedType Pedestrian type 

Dwelltime Total time [s] pedestrian spent on measurement area(s) 

vDes Desired speed (in the current unit for speed) 

v Speed (in the current unit for speed) 

DevSpeed Deviation of pedestrian speed (in the currently selected 

speed unit) 

Density Density of pedestrians on measurement area(s) [ped/m² 

or ped/ft² according to the current unit for short distances] 

AvgXOri Average of x values of orientation vector 

AvgYOri Average of y values of orientation vector 

WorldZ World coordinate z 

TimeDelay Time delay [s] 

TimeGain Time gain [s] 




Dist Distance (in the current unit for short distances) that the 

pedestrian traveled on measurement area(s) 

DistNetwork Distance [m] pedestrian traveled in network so far 

7.2.3 Pedestrian Record 

For each pedestrian, the pedestrian protocol *.PP records a data line per 

time step. The evaluation can be limited to a user-defined time interval as 

well as to selected classes of pedestrians. 

Generally, it can be compared to the vehicle protocol, cf. section 11.7. 

Furthermore, many of the pedestrian record output parameters can be 

viewed as pedestrian information in a separate window for each of the 

selected pedestrians while the simulation is running, cf. section 7.2.5. 

Definition 

No additional definition required. 

Configuration 

In order to get the desired output data additional information is needed. This 

can be provided within the Pedestrian Record - Configuration window which 

can be accessed by pressing the CONFIGURATION button via EVALUATION – 

FILES in the [PEDESTRIANS] tab once the option Pedestrian Record is active. 

The Configuration window allows for definition of any combination of the 

parameters of pedestrians. If Database output is not active, each layout line 

results in a column within the output file *.PP. 

The configuration settings will be saved to an external *.PDK file. 


● The Selected parameters 

are displayed 

in the list 

box to the left. 

Use the UP and 

DOWN buttons to 

change the sequence 

of the 

selected data. 

Additional parameters 

can be 

inserted and removed 

by clicking 

the corresponding 

buttons and . 


For the list of parameters provided for selection and a brief description, 

please see below. 

● Database: When active, evaluation output is directed to a database to 

the specified Table Name (rather than to an ASCII text file). The table 

name must not be used for any other VISSIM database evaluations. In 

order to use the database output the database connection needs to be 

configured, cf. section 10.1.3. 

Filter 

Once the pedestrian record parameters have been selected, a filter may be 

applied to capture specific pedestrian classes during the simulation. This can 

be accessed via EVALUATION – FILES – [PEDESTRIANS] tab by pressing the FILTER 

button Once the option Pedestrian Record is active. 

By default, all pedestrian classes are recorded within the simulation period. 

In addition to the selection of pedestrian classes, a time interval for the 

evaluation as well as the resolution of recording are to be defined. If an 

integer > 1 is entered for Resolution, only one time step will be logged for the 

user-defined number of time steps. 



The filter information is stored in a filter configuration file *.PIL. 

Results 

The pedestrian protocol (*.PP) consists of the following: 






► Brief description of output parameters 

► Data block 

The pedestrian record file can contain any of the parameters listed below. 

The table also includes the abbreviations that will be used within the 

pedestrian record file. 

Generally, current unit settings for (short/long)distance/speed/acceleration 

under VIEW - OPTIONS - [LANGUAGE &UNITS] are regarded for evaluation data 

output. 

Please note: The units of those parameters with the particular unit 

mentioned in the column header abbreviation will not change, for example 

V_mps. 

In contrast, the output of the speed in the v column, for example, regards 

whether the metric or the imperial unit has been selected. 

Parameters (such as TotalDist) which can be output with long length and 

with short length simultaneously, always have the particular length in the 

column header. 

For parameters which are returned according to the current Units settings 

(either metric or imperial) the current selection is added to the name of the 

parameter in the Pedestrian protocol - Configuration window and will be 

displayed in the Information line after mouse-click. 


Construction 

Element 

Current 

destination 

Desired speed 

[km/h] 

Desired speed 

[m/s] 

Number of construction element ConstrElem 

Number of current destination 

(construction element) 

CurrentDest 

Desired speed [km/h ] vDes 

Desired speed [m/s] vDes_mps 

Height Pedestrian height [m] Height 

Length Pedestrian length [m] Length 




Level Level number Level 

On ramp Pedestrian on ramp? 0 = no, 1 = 

yes 

Orientation x 

value 

Orientation y 

value 

X value of orientation vector 

(direction of latest movement) 

Y value of orientation vector 

(direction of latest movement) 

OnRamp 

XOri 

YOri 

Partial route Partial route number PartRoute 

Partial routing 

decision 

Pedestrian 

number 

Partial routing decision number PartRoutDec 

Pedestrian number (in the 

Pedestrian Info window header) 

PedNo 

Pedestrian type Pedestrian type number PedType 

Pedestrian type 

name 

Previous 

destination 

Pedestrian type name PedTypeName 

Number of previous destination 

(construction element) 

PT alighting Pedestrian alighting from a PT 

vehicle? 0 0 no, 1 = yes 

PT approaching Pedestrian approaching a PT 

vehicle? 0 = no, 1 = yes 

PT waiting Pedestrian waitinmg for PT? 0 = 

no, 1 = yes 

Queuing area Current queuing area number (0 = 

pedestrian not in a queue) 

Queuing distance Direct distance (short length) to 

begin of current queue 

Queuing time Time spent in last queue [s] (in the 

time step when the pedestrian 

leaves the queue) 

PrevDest 

PTAlighting 

PTApproaching 

PTWaiting 

QueueArea 

QueueDist 

QueueTime 

Queuing total time Total time spent in queues [s] QueueTotalTime 

Remaining 

Distance 

Remaining distance (short length) 

to the next internal destination. 

If the next (intermediate) destination 

is located on the same level 

as the pedestrian, this is the 

distance to this (intermediate) destination. 

If the next (intermediate) 

RemDistance 




destination is on a different level, 

the value returns the distance to 

the stair intended to be used. 

Simulation time Simulation time [s] (not in the 

Pedestrian Info window, but in the 

status bar of the VISSIM window) 

Simulation time of 

day 

Simulation time as time of day 

[hh:mm:ss] (not in the Pedestrian 

Info window) 

Speed [km/h] Speed [km/h] at end of time step v 


t 

TimeOfDay 

Speed [m/s] Speed [m/s] at end of time step v_mps 

Start time Start time [simulation second] StartT 

Start time of day Start time as time of day 

[hh:mm:ss] (not in the Pedestrian 

Info window) 

StartTimeOfDay 

Static route Static route number StatRoute 

Static routing 

decision 

Static routing decision number StatRoutDec 

Time delays Accumulated time delays [s ] TotalDelay 

Time gains Accumulated time gains [s ] TotalGain 

Total distance 

[km] 

Total distance traveled in network 

[long length] 

Total distance [m] Total distance traveled in network 

[short length] 

TotalDist_km 

TotalDist_m 

Total time Total time in network [s] TotalTime 

Width Pedestrian width [m] Width 

World coordinate 

x 


y 


z 

World coordinate x (Pedestrian 

position) 

World coordinate y (Pedestrian 

position) 

World coordinate z (Pedestrian 

position) 

Example: Pedestrian Record file *.PP 

The following extract represents the Pedestrian Record: 

Pedestrian Record 

Worldx 

Worldy 

Worldz


File: D:\Program 

Files\PTV_Vision\VISSIM_520\Examples\Training\Pedestrians\HotelRimea.inp 

Comment: 

Date: Friday, 6. November 2009 2:34:58 PM 



ConstrElem : Number of construction element 

CurrentDest : Number of current destination (construction element) 


v : Speed [km/h] at end of time step 

… 

PedNo; ConstrElem; CurrentDest; vDes; v; 

1; 1; 115; 4.17; 0.56; 

2; 3; 115; 4.98; 2.48; 

3; 4; 115; 4.57; 1.10; 

4; 7; 115; 4.27; 2.48; 

5; 7; 115; 4.20; 2.19; 

6; 10; 115; 4.03; 2.48; 

7; 12; 115; 4.67; 2.48; 

8; 13; 115; 4.59; 2.48; 

9; 20; 115; 4.90; 2.48; 

10; 24; 115; 4.61; 2.48; 

11; 26; 115; 4.97; 2.48; 

12; 27; 115; 4.00; 2.48; 

13; 34; 115; 4.69; 2.48; 

14; 204; 115; 4.98; 3.31; 

7.2.4 Pedestrian Queue Evaluations 

Click EVALUATION – FILES and call the [PEDESTRIANS] tab. Activate the 

Queues option to create a *.PQE file which contains – by time interval and 

selected area – the following compiled values: 

► the number of pedestrians in the queue 

► the length per queue (bee-line) 

Definition 

Only those areas are provided for selection that have checked the option 

Queuing, cf. section 7.1.4.3. 

If orderly queuing of pedestrians in single file is required, a Dwell time 

distribution has to be allocated to the area, cf. section 5.2.6. 

In the Pedestrian Area window, check – and edit, if applicable – these 

properties of one or several selected pedestrian areas. 

The behavior of pedestrians in queues is described in section 5.2.6. 

For each area, the number of queueing pedestrians and the queue’s spatial 

extent are logged. 

In case of areas without orderly queing (i.e. not single file but only stopped at 

a bottleneck), the following applies: 



If a queuing area which is selected for queue evaluation has no dwell time 

distribution selected, all pedestrians who fulfill the three criteria listed below 

are considered to be part of that queue for the queue evaluation until they 

leave this area. 

► The pedestrians have this area as next routing destination (or have 

already arrived on that area). 

► The pedestrians are slower than 0.4 m/s. 

► The pedestrians are either closer than 2 m to the area edge that the 

queue arrow points to or closer than 2 m to another pedestrian who 

belongs to that queue. 

Pedestrians are displayed as red ovals in 2D mode while they are inside 

such a queue. 

Configuration 

No configuration settings required. 

Filter 

In the Queue Evaluation - Filter window, the following settings have to be 

made: 

► Set the time filter 

► Define active areas 

● Time section: 

- Define the length of the evaluation intervals. 

- Shift the start of the protocol, if applicable. 

- Reduce the length of the protocol, if applicable. 

Recording can be shorter than the simulation period, cf. SIMULATION - 

PARAMETERS. 

● Queuing Area Selection section: 

The Passive Areas list contains all areas of the Queuing type. 

- To shift a single area to the Active Areas list, mark it and use the 

button or double-click the area. 



- To shift all passive areas to the Active Areas list, use the > button. 

Results 

A Pedestrian queue file (*.PQE) consists of the following: 


► Path and name of the network file (File) 





► Data block with one column for each parameter 

Example: Pedestrian Queue file *.PQE 

Pedestrian Queue Evaluation 

File: C:\programfiles\PTV_Vision\VISSIM520\Examples\Training\Pedestrians\HR.inp 

Comment: Manual Example 

Date: Wednesday, October 28, 2009, 5:31:39 pm 


t : End of aggregation time interval [simulation second] 

AreaNo : Queuing area number 

PedCount : Number of queuing pedestrians 

Extent : Queue extent [m] 

t; AreaNo; PedCount; PedCount; PedCount; Extent; Extent; Extent; 

; ; Mean; Min; Max; Mean; Min; Max; 

500; 4; 23.8; 0; 46; 20.5; 0.0; 42.9; 

500; 5; 7.7; 0; 25; 5.8; 0.0; 22.5; 

1000; 4; 35.8; 24; 47; 31.5; 19.3; 43.2; 

1000; 5; 13.9; 1; 27; 10.9; 0.0; 24.2; 

1500; 4; 13.9; 3; 25; 10.6; 1.4; 21.2; 

1500; 5; 0.0; 0; 1; 0.0; 0.0; 0.0; 

2000; 4; 57.7; 2; 114; 43.8; 0.5; 67.2; 

2000; 5; 55.6; 0; 111; 41.9; 0.0; 66.3; 



7.2.5 Pedestrian Information 

During a simulation run pedestrian information is available in a Pedestrian 

Information window after double-click on any pedestrian. The information 

shown can be configured by the user. 

Additionally, pedestrian information can be saved to an output file using the 

Pedestrian Record output parameters, cf. section 7.2.3. 

Definition 


Configuration 

Via EVALUATION – WINDOWS... – PEDESTRIAN INFORMATION you can call the 

Pedestrian Information Configuration window: 

The Selected parameters 

are displayed 

within the list box to the 

left. 

Use UP and DOWN to 

change the sequence 

of the selected data. 


can be inserted and 

others can be removed 

by clicking on the corresponding 

buttons 

and . 

The configuration is 

saved to an external 

file (*.PDI). 

Result 

While the simulation is running, switch to the 

single-step mode and double-click on a 

pedestrian for the following: 

► A red dot marks the selected pedestrian. 

► The pedestrian information window 

appears. 

Additionally, if the display mode is set to 3D, 

the viewing position will be changed as from 

the pedestrian’s position, cf. section 7.4. 


7.3 2D Visualization of Pedestrian Traffic 

2D Visualization of Pedestrian Traffic 

Basically, the three options provided for visualization of road users and for 

display of compiled data gained from vehicular or pedestrian traffic are the 

same for vehicles on links and pedestrians on areas and ramps or stairways. 

Also the display types can be allocated to links in the road network and to 

construction elements for pedestrians as well. 

This section describes the options for the visualization of pedestrian flows 

using walkable construction elements. 

For pedestrians, multiple Level of Service schemes allow for various 

evaluations with regard to space or speed rating, cf. section 7.3.3. 

7.3.1 Display Types of Construction Elements 

As for vehicle traffic, display types for construction elements can be defined 

via BASE DATA – DISPLAY TYPES, cf. section 5.5.2 

Via VIEW – OPTIONS – [COLORS] you can enable or disable the usage of the 

display types for screen display of obstacles, areas, ramps and stairways, cf. 


If option Use display type color is not checked in this window, the color 

chosen for Links/Areas will be used for areas and ramps and stairways 

instead. For obstacles, the Land color will be used in this case. 

7.3.2 Display Options for Pedestrians 

Via VIEW - OPTIONS... - [PEDESTRIANS] various options are provided for the 

visualization of pedestrians traversing areas and ramps or stairways. 




● Individual Pedestrians: Each pedestrian is animated separately. 

In 2D mode, pedestrians are displayed as colored, rounded boxes. 

In 3D mode, they are represented by a 3D model from the model 

distribution assigned to the pedestrian type. 

- CONFIGURATION: If option Individual Pedestrians has been checked, 

select the parameter to be displayed, enter the upper class limits to 

set up the classes and assign a color to each class for display of 

Speed or Acceleration of pedestrians in 2D display mode, cf. section 

4.2.2. 

- Interval defines that only every th frame of the visualization will 

be updated. The default value is 1 and corresponds to a frame 

update at every simulation time step. 

● Aggregated values: If this option is active, each polygon (area, ramp, 

stairway or grid cell respectively) is colored instead of display of 

individual pedestrians. For that the CONFIGURATION settings are used. 

- CONFIGURATION: Select the LOS scheme (or the parameter, 

respectively) and define the appropriate color code. Alternatively, you 

can select a parameter (Speed or Density) and set up user-defined 

classes. For details, please refer to section 7.3.3. 

- Update interval: Enter start and end of the interval for data updates. 

The display changes every seconds, then shows 

the result of the last (completed) interval and stays the same for 

seconds (until the new result is displayed). The 

update interval is also regarded for cumulative data display. 

- Area-based: If this option is active, the walkable construction 

elements (areas and ramps/stairs) are used for data collection and 

graphical value display by color. 

- Grid-based: If this option is active, a user-defined grid is created for 

data collection and graphical value display by color that covers the 

walkable elements. Enter the length of the edge of such a mesh to 

define the cell size. 

● No visualization: Neither individual pedestrians nor aggregated values 

are displayed during the simulation. Use this option to maximize the 

simulation speed. 

Click CTRL+Q to activate the next of these three display options during a 

simulation (Individual vehicles / Aggregated values / No visualization). 

If option Aggregated values is selected in the [PEDESTRIANS] tab, press 

CTRL+L to toggle between multiple LOS definitions. The LOS scheme 

being currently used for data visualization is mentioned in the status bar. 



The visualization of traffic requires a substantial amount of computing time. 

Turning off the visualization increases the simulation speed. Another option 

to increase the simulation speed is to increase the interval of frame 

updates for the visualization (Interval). 

7.3.3 2D Display of Aggregated Values for Pedestrians (LOS) 

As an alternative to the display of individual pedestrians, VISSIM can also 

use well-known LOS schemes for display of aggregated values using a color 

code. 

This section describes the display of aggregated values for pedestrian traffic 

on areas, ramps and stairways. 

The color code is used to color each traversed polygon - which is either a 

walkable construction element or a cell of a user-defined grid - according to 

the value computed for this polygon. This value results from the online data 

of the selected parameter. Alternatively to visualization of data gained by 

update interval, also cumulative data display can be selected. 

Selection: The LOS Schemes Provided for Aggregate Value Display 

The two tables below list the LOS schemes and parameters provided in the 

Aggregated Values - Configuration window. You can freely select a color for 

each class. 

► For the schemes, the upper interval limits of the classes are predefined 

by scheme. The colors can freely be allocated to the value classes. 

For each scheme, find a short description attached. 

► For the parameters, you can freely select the upper interval limits to set 

up the classes and assign a color to each class. 

Scheme Walkways Stairways Queuing User-defined 

Fruin 

Fruin states as introduction that "the breakpoints that determine the various 

levels-of-service have been determined on the basis of the walking speed, 

pedestrian spacing, and the probabilities of conflict at various traffic concentrations". 

Numerically the breakpoints are given as density and (alternatively) 

flow. By defining both, density and flow limits, Fruin provides the planner 

with the right strategy, as the level of service concept is meant to assess 

walking quality up to capacity, where above capacity is tried to be avoided in 

any case. 

Weidmann 

Weidmann follows Pushkarev and Zupan and the HCM in stating eight 

criteria to assess pedestrian walkway quality. He refers to eight more 

references to use these criteria to verbalize level limits given as densities. 




Weidmann does not give the way to translate verbalized in numerical limits. 

HBS 

These level limits are very similar to those of HCM; like rounded values, 

when HCM is given in the metric system. The importance of considering 

effective width (or area) is pointed out. Additionally a factor is given to 

calculate an effective density for counterflow situations. VISSIM calculates 

the LOS using the geometric area and does not check for counterflow 

situations. 

HCM 

HCM refers to Fruin as originator of the LOS concept, but the breakpoints 

between the levels are set at clearly smaller values. 

Pushkarev-Zupan 

Pushkarev and Zupan along with Fruin are credited in the HCM as having 

done the base work. 

Polus 

Tanaboriboon- 

Guyana 

 

The breakpoint values for this six-level scheme have been derived from 

measurements in Bangkok. So, if there is an Asian scheme, it is this one. 

This is the only LOS scheme with breakpoint values constantly higher than 

the ones of the walkway LOS of Fruin. 

Teknomo 

In contrast to density-based LOS, this speed-based LOS definition uses the 

opposite sequence (starting with the worst LOS) because with increasing 

speed the LOS becomes better. 

Selection: The Parameters Provided for Aggregate Value Display 


Density 

Speed 


Global 

Settings 

By Display 

Type 

By Construction 

Element 

How the Settings for LOS Visualization are Regarded 


Set the global settings for the entire network via menu VIEW – OPTIONS – 

[PEDESTRIANS] – CONFIGURATION, cf. section 7.3.3.1. 

If option Area-based has been checked for display of aggregated values: The 

LOS scheme selected in the global settings can be overruled by the LOS 

scheme selected for the display type of construction elements. Both settings 

can be overruled by the LOS scheme selected for a particular area or ramp 

or stairway, if applicable. 

If option Grid-based has been checked for display of aggregated values, 

the global settings cannot be overruled by different settings for a selected 

display type or for selected elements. In this case, different LOS schemes 

selected by display type and/or construction element will be ignored. 

If option Area-based has been checked for display of aggregated values, you 

can select a different LOS scheme for a certain display type of areas and 

ramps or stairways via menu BASE DATA – DISPLAY TYPES – [PEDESTRIANS], cf. 


Alternatively, you can select None to exclude all construction elements of this 

display type from the LOS visualization. Their static color/texture will be used 

for display instead. 

The LOS scheme selected for the display type of construction elements is 

overruled by the LOS scheme selected for a particular area or ramp or 

stairway, if applicable. 

If option Area-based has been checked for display of aggregated values, you 

can set a different LOS scheme for a single or multiple construction 

element(s) in the Pedestrian Area properties window, cf. section 7.1.4.3., or 

in the Ramp/Stairway properties window, cf. section 7.1.4.5: 

In the Visualization section, select either Display type or a different LOS 

scheme for Aggregated values display. To exclude a single or multiple 

construction element(s) from LOS visualization, uncheck the option 

Aggregated values. The static color/texture will be used for display instead. 

7.3.3.1 Display Options for LOS of Pedestrian Traffic 

Click VIEW – OPTIONS... to open the Display Options window. 

In the [PEDESTRIANS] tab do the following, cf. section 7.3.2: 

1. Check option Aggregated Values 

2. Enter the Update interval in seconds 

3. Select the spatial basis for the visualization: 

- Area-based: If this option is checked, data is evaluated and LOS is 

visualized by area or ramp or stairway. The global LOS scheme, 

which is to be selected in the associated Configuration window, can 



- 

be overruled by display type LOS scheme and/or by the LOS scheme 

selected for particular areas, ramps or stairways. 

Grid-based: If this option is checked, a user-defined grid will cover 

the network area. The parameter values are computed by grid cell 

and will be indicated by the cell´s color. 

Enter the length of the cell edges as Cell size value (short length 

unit). 

The global LOS scheme, which is to be selected in the associated 

Configuration window, cannot be overruled by any other settings. 


5. Set the options 

The color of a cell or area results from these settings: 

● Scheme: In the list, select the 

desired scheme with predefined 

classes for evaluation 

and with a user-definable color 

code for display, cf. section 

7.3.3. 

Alternatively, parameter Speed 

or parameter Density can be 

selected, for which the classes 

have to be defined accordingly. 

The appropriate unit is displayed 

underneath. 

● Display: Decide, how to 

visualize the aggregated values 

resulting 

scheme. 

from the selected 

These three options are 

provided for each of the 

schemes and both parameters 

and take the user-dfined time 

interval into consideration. 

Thus, visualization is 

performed as long as the 

current simulation second is 

within the range from – until. 

The display of the data is still updated every Update interval, starting with 

simulation second , then + and so on. 

When the current simulation second is outside the range from - until, 

each area or cell is colored as if Aggregated values was not selected. 

- Average (Interval): If this option has been checked, the average 

value of the current interval is visualized and the data will be reset at 

the end of the interval. 



- Average (Cumulative): If this option has been checked, the parameter 

data is not reset every Update interval but continuously 

collected as long as the current simulation second is within the range 

from - until. The current average value is added to the total of the 

previous average values. The resulting sum is visualized. 

- Worst of interval averages: If this option has been checked, the 

averages of all intervals are compared to each other and the worst 

average value is visualized (minimum speed or maximum density). 

● Classes: A class combines a value range and the Color for its 

representation on screen. 

- For provided LOS schemes, the value range by class has been predefined. 

- For the parameters Speed and Density, the classes can be defined 

by the user. 

The upper class limit is always included in the interval. 

To allocate a color to each of the classes, click the colored cell next to 

the particular upper interval limit. 

● DEFAULT CLASSES: Click this button to restore the default settings 

(limits/colors) of the current scheme. 

7.3.3.2 Examples: Aggregated Values of Pedestrian Traffic 

Example 1 



Example 2 


7.4 3D Visualization of Pedestrian Traffic 


Similar to the 3D viewing option “Sitting in the driver´s seat”, the user can 

watch the pedestrian traffic with the eyes of a selected pedestrian. 

This can be done in the single step mode (2D) by double-clicking on the 

pedestrian. In this way, the pedestrian information window is called, cf. 

section 7.2.5. The 3D view from the pedestrian’s position remains active as 

long as the pedestrian information window is open. 

To remain in the 3D mode but watch the pedestrian flows from a different 

position, select another pedestrian’s information window. 



7.5 Simulation of Pedestrians: Preconditions & How to 

This section describes the preconditions which are required for a pedestrian 

simulation and also the internal process of the simulation. 

7.5.1 Preconditions for Simulating Pedestrian Flows 

1. Every external pedestrian movement *.DLL file that is referenced by a 

type of pedestrians must exist at the referenced location. 

2. The *.DLL files must be installed correctly and their dependencies to third 

party *.DLL files must be fulfilled. The latter can be checked using the 

tool „Dependency Walker“ (http://www.dependencywalker.com/). 

3. All pedestrian types must reference an existing and valid external 

pedestrian movement *.DLL file. 

4. The folder PEDESTRIANMODELDATA must exist in VISSIM’s executable 

path even if no pedestrian model *.DLL file uses it. 

5. At least one pedestrian type must be defined including a valid reference 

to an external movement *.DLL (cf. section 7.1.2). 

6. At least one pedestrian composition must be defined. 

7. At least one pedestrian input must be defined and yield pedestrians. 

8. On every pedestrian input, there must be at least one pedestrian routing 

decision. 

9. At every pedestrian routing decision on pedestrian inputs there must be 

at least one route for every pedestrian type that belongs to a pedestrian 

composition on that input. 

10. All sequences of pedestrian areas referenced by any pedestrian route 

must be valid – every (intermediate or final) stop of the route must be 

reachable on walking ground from its predecessor. 

11. Be careful in case of obstacles being located closed to each other: 

Depending on the external movement *.DLL pedestrians might get stuck 

in the alleyway and there might be no walkable trajectory along some 

strategic path. 

7.5.2 How the Simulation Internally Works 

Inserting pedestrians at pedestrian inputs 

On pedestrian areas where pedestrian inputs are defined it is mandatory to 

define routing decisions for pedestrians as well. There must be at least one 

route for every pedestrian type that belongs to the input. Pedestrians without 

a strategic route are not defined and simulation will stop with an error in that 

case. 


Simulation of Pedestrians: Preconditions & How to 

After creation of a new pedestrian, a strategic route is fetched from the 

routing decision according to the type (class respectively) of the pedestrian. 

If there is more than one route, one route is chosen randomly according to 

the ratios of the route distribution. 

The strategic route consists of a sequence of numbers of pedestrian areas 

and ramps. These are copied to the pedestrian’s data structures. From which 

routing decision the route was taken is stored here as well to avoid fetching 

several routes again and again on one and the same routing decision. 

How a pedestrian walks along the strategic route 

A pedestrian always walks towards his nextmost strategic routing point. 

Whether he aims at the exact coordinates of the point or only at the area 

where the strategic point is located in, depends on the external movement 

DLL that is used. 

Once reaching it (i.e. entering the area that contains the point or reaching the 

point itself) the external movement DLL makes the pedestrian wait according 

to the dwell time distribution defined at the area. What the pedestrian “does” 

during this time is determined by the DLL. 

If this was not the end of the pedestrian’s strategic route, he moves on 

towards the next strategic point. If this was the end point of the strategic 

route and if the area, where the pedestrian´s current position is located in, 

contains a routing decision defining routes for this pedestrian (more 

precisely: for the class, the pedestrian belongs to), the pedestrian will get a 

new strategic route and will start moving on along that route. If there is no 

strategic route, the pedestrian will be removed from the scene. 

Between two subsequent strategic routing points there may be several 

possibilities to walk “tactically” (pass-by obstacles left or right, use one of 

several ramps to change to another level, etc). 

Currently, VISSIM computes an internal routing graph consisting of the usersupplied 

strategic points and of the bottoms and tops of all ramps. 

Each vertex A of this graph is connected to each other vertex B as long as 

they are located on the same “walking partition” – i.e. pedestrians can walk 

from A to B without changing level and without “loosing walkable ground” 

inbetween. 

Based on this graph, the shortest path between either two strategic points of 

a pedestrian’s strategic route is determined and used for the tactic 

movement of the pedestrian. 

How routing decisions are applied 

If a pedestrian without route (immediately after creation or at the end of his 

route) enters a walkable area for which a routing decision has been defined 

including routes for the type of the pedestrian and if the pedestrian does not 

already have his current strategic route from this decision, a new strategic 

route will be chosen from the routes defined for the type of the pedestrian. 



As for the initial routes, the number of the decision is stored at the 

pedestrian’s data structure to avoid fetching several routes from one and the 

same decision again and again. 


Parameters of the Social Force Model in VISSIM 

7.6 Parameters of the Social Force Model in VISSIM 

The parameters of the model can be categorized into three groups: 

1. Parameters of the original model (by pedestrian type). 

2. Parameters of the model extensions for VISSIM (by pedestrian type). 

3. Implementation-specific global parameters include all discretization 

parameters: E.g. for models formulated using a continuous time. As 

analytical approaches to solve the differential equations are only possible 

in scenarios of limited size in any respect, time needs to be discretized in 

some way to make a simulation on a computer possible. 

Literature 

The original model was published in the following works. Entry [6] gives an 

overview: 

[1] D. Helbing and P. Molnár (1995). Social force model for pedestrian 

dynamics. In Physical Review E 51(5). 

[2] Helbing, Farkas and Vicsek (2000). Simulating dynamical features of 

escape panic. In Nature 407. 

[3] Helbing, Farkas, Molnár, and Vicsek (2002). Simulation of Pedestrian 

Crowds in Normal and Evacuation Situations. In Schreckenberg and Sharma 

(Editors) Pedestrian and Evacuation Dynamics, Duisburg 2001. Springer 

Berlin Heidelberg 

[4] Werner and Helbing (2003). The Social Force Pedestrian Model Applied 

to Real Life Scenarios. In Galea (Editor) Proceedings of the 2nd Conference 

on Pedestrian and Evacuation Dynamics, Greenwich 2003. CMS Press 

Greenwich. 

[5] Johansson, Helbing, and Shukla (2007). Specification of the Social 

Force Pedestrian Model by Evolutionary Adjustment to Video Tracking Data. 

In Advances in Complex Systems, 10(4):271-288. 

[6] D. Helbing and A. Johansson. Pedestrian, Crowd and Evacuation 

Dynamics. In R.A. Meyers (Editor), Encyclopedia of Complexity and System 

Science. Part 16, p. 6476. Springer, Berlin Heidelberg New York. (2009). 

7.6.1 Model Parameters by Pedestrian Type 

For each type of pedestrians, parameters derived from the original model 

can be set. Furthermore additional VISSIM-specific parameters can be set by 

pedestrian type. 



► tau (τ) 

Tau is the relaxation time, which one can relate to a reaction time or 

inertia, as it couples the difference between the desired speed and 

direction v_0 and the current speed and direction v to the acceleration a: 

a = (v_0 – v) / τ. 

In the folder ..EXAMPLES\TRAINING\PEDESTRIANS\PARAMETER 

DEMONSTRATION you can find training example models specifically 

demonstrating the effect of this parameter. 

► lambda_mean (λ_mean) 

Lambda governs the amount of anisotropy of the forces from the fact that 

events and phenomena in the back of a pedestrian do not influence him 

(psychologically and socially) as much as if they were in his sight. From 

lambda and the angle φ between the current direction of an agent and 

the source of a force a factor w for all social (i.e. non-physical) forces is 

calculated that suppresses the force, if φ ≠ 0 and λ < 1: w(λ) = 

( λ + ( 1 – λ ) ( 1 + cos(φ) ) / 2 ). So, if φ = 0 one has w = 1 and if φ = π 

one has w(λ) = λ. 

In the folder ..\EXAMPLES\TRAINING\PEDESTRIANS\PARAMETER 



► A_soc_isotropic and B_soc_isotropic 

These two parameters together with λ govern one of two forces between 

pedestrians: 

F = A_soc_isotropic w(λ) exp(-d/B_soc_isotropic) n, with d as distance 

between the pedestrians (body surface to body surface) and n as unit 

vector pointing from one to the other. 

► A_soc_mean, B_soc_mean, and VD 

These parameters determine strength (A) and range (B) of the social 

force between two pedestrians. The social force between two 

pedestrians is calculated as F = w(λ) A exp(-d/B) n, if the influencing is in 

front (180°) of the influenced pedestrian, else it is zero. Here w(λ) is the 

factor calculated from λ, which is explained above, d is the distance 

(body surface to body surface) between two pedestrians and n is the 

unity vector pointing from the influencing to the influenced pedestrian. 

Note that if the parameter VD is greater than zero the relative velocities 

of the pedestrians are considered in addition. 

In this case the distance d is generalized to and thus replaced by 

d -> 0.5 sqrt( (d + |(d – (v_1 – v_0) |VD)² - |(v_1 – v_0) VD|²) 

with VD given in [seconds]. Here v_0 is the velocity of the influenced and 

v_1 the velocity of the influencing pedestrian and d points from the 

influencing to the influenced pedestrian with |d| = d. (The “influenced 

pedestrian” is the one for whom the force is calculated.) 



demonstrating the effect of parameter VD. 



► noise 

The greater this parameter value, the stronger is the random force that is 

added to the systematically calculated forces if a pedestrian remains 

below his desired speed for a certain time. Check this effect like this: Let 

a group of pedestrians pass a bottleneck of about 70 cm. With noise=0, 

so-called "arches" will form and stay stable. If the noise value is in the 

range of [0.8..1.4] then one pedestrian will step back after a while and 

another other one will pass. 

► react_to_n 

Only the influences of the n closest pedestrians are considered when the 

total force is calculated for a pedestrian. 




► queue_order and queue_straightness 

These two parameters control the shapes of queues. Use values 

between 0.0 and 1.0. Generally speaking, the greater the parameter 

values the more orderly the queue will be. 

► side_preference 

This parameter determines whether opposing flows of pedestrians prefer 

either the right side or the left side for passing each other. Enter -1 for 

right-side preference or 1 for left-side preference. For uncontrolled 

behavior as hitherto, enter 0. 




7.6.2 Implementation-specific Global Parameters 

In contrast to the parameters above which are to be set by pedestrian type, 

the following parameters take a global effect, i.e. they are not type-specific. 

In case of various behavior parameter files VISSIM will use the parameter 

values set in the parameter file for the pedestrian type with the smallest 

number. 

► grid_size 

By this parameter one defines how far at largest pedestrians influence 

each other. 

The pedestrians are stored in a grid with cells of size grid_size x 

grid_size square meters. Each pedestrian only interacts with the 

pedestrians in the same or adjacent (including over corner) grid cells. 






► routing_large_grid 

This parameter defines the topological grid-size; routing_large_grid x 

routing_large_grid cells become one cell in the superordinate grid. 

The required memory depends on this parameter, but the precision of the 

calculation of distances to destination areas does not. There is no global 

value that fits best in any case. For small-sized scenarios (in a building, 

for example) with numerous small obstacles and numerous walkable 

areas a low value (< 10) is recommended. For large areas and big 

obstacles (e.g. simulation of a district not regarding the details) even 100 

or more can be set. Since we expect the 64 bit edition of VISSIM to be 

used mainly for large-scale projects, the default value is 7 for the 32 bit 

edition and 20 for the 64 bit edition. As long as no memory problems 

occur in a project this parameter value can be kept. Problems that might 

occur can be solved by changes to this parameter without subsequent 

disadvantages. 

► routing_step 

This is one parameter that governs the calculation of the potential. If it is 

large, the potential is more precise, but its calculation needs more time. 

Resonable values are 2, 3, 4 or 5. 

► routing_accuracy 

This is the second parameter that governs the calculation of the 

potential. It can take values in [0.0 .. 1.0] and results in more precise 

potentials, the greater it is. 

► routing_obstacle_dist 

During the calculation of the static potential (aka “distance potential field”, 

“distance look-up table”), grid cells which are close to walls receive a sort 

of “extra distance” atop of their true distance. By this, one can achieve 

that more pedestrians decide to choose a wide corridor instead of a 

narrow one, if there are two corridors from one and the same source to 

one and the same destination with identical walking distance. Generally, 

the pedestrians keep some distance toward walls. With this parameter 

the distance is set to which nearby walls influence the potential field. This 

parameter only has an effect on the calculation of the static potential. It is 

not yet considered in the calculation of the dynamic potential. 




► routing_cell_size 

This parameter defines the distances of fixed data points to be set for the 

calculation of distances to a destination area. The default value is 0. 

15 [m]. This default should only be edited if the model included 

passageways with a width of 50 cm or less since pedestrians will not 

pass these channels during the simulation. Instead, they will stand still 



apparently not oriented into a particular direction as soon as an area 

behind the channel is their next (intermediate) destination area. In this 

case, the value of the parameter can be reduced to 0.1 m. This change 

increases the memory requirements and further reductions might cause 

further problems. Therefore, each project should use the default value 

until reductions are required for trouble shooting purposes. 

► Use_cache 

The pedestrians calculate their desired direction (the direction of the 

desired velocity) as the gradient of a look-up table (physicists also call it 

"potential") of distances toward the destination area. Since obstacles are 

considered in the calculation of this look-up table this calculation is very 

complex and usually takes some time. To reduce the required time, the 

look-up table can be saved to disc by setting use_cache=1; thus, if you 

re-run the simulation without changes to the geometry, the look-up table 

will be read from disc instead of being calculated anew. 

Known bug: From time to time it might happen that VISSIM does not 

realize that the geometry has changed. In this case, a wrong potential 

will be read from disc and pedestrians might walk strangely. To solve this 

problem, set use_cache=0, run the simulation once, and set it back to 

use_cache=1, if applicable. 



7.7 Fields of Application & Requirements 

Over the years, the possibilities of simulating public transport passengers or 

pedestrians have significantly been extended in VISSIM. Since the 

Pedestrians add-on has been implemented you have – for each project – the 

choice whether to apply the Wiedemann model which is included in the 

standard installation or to prefer the detailed Helbing model instead which is 

provided as Pedestrians add-on. 

The various scenarios which can be dealt with require different model data 

as you can see from the tables below. 

Finally you can find a brief introduction to the modelling workflow for the 

microscopic simulation of public transport passengers as pedestrians in the 

network. 

Main differences between the Wiedemann and the Helbing approach 

Obviously, when pedestrians are modeled as a vehicle type (Wiedemann 

approach) and when by this they are bound to move along user-defined 

links, the spatial character of their trajectories is fixed in advance by the user, 

it is an input to the model, not a result (except for the time at which a 

pedestrian crosses which point of the link). If pedestrians can move freely in 

two spatial dimensions (Helbing approach), their trajectories are not fixed in 

advance, but calculated by the model. Therefore this approach is much more 

flexible, detailed and realistic. However, there are situations, in which the 

essential elements of the dynamics are produced by the Wiedemann model. 

An example are projects, where pedestrians have no other role than to 

impose interruptions to vehicular traffic at signalized intersections. 

Level of Interaction: 

Wiedemann Model 

Pedestrians using crosswalks 

in the road network 

Pedestrians 

add-on 

Elements in the VISSIM network 

Not required ► Links 

► Pedestrians as vehicle type 

PT passengers Not required ► PT stops 

► PT lines as vehicle type 

► Stop dwell time distribution or 

number of boarding passengers 


Level of Interaction: 

Helbing Model 

Pure pedestrian flows, 

e.g. 

► Evacuation in case of 

emergency 

► Airport, Hotel etc. 

Pedestrians using crosswalks 

in the road 

network 

Pedestrians as PT 

passengers in the 

network 

Usable elements that are 

provided by the Pedestrians 

add-on 

► Walkable construction elements 

(ramps/stairs and 

areas, platform edges and 

waiting areas included) 

► Multi-storey, if applicable 

► Pedestrians as type/class of 

pedestrians 

► Compositions of pedestrians 

► Area behavior types, if 

applicable 

► Walking behavior parameter 

sets, if applicable 

► Location distributions, if 

applicable 


pedestrians 



applicable 



► Construction elements (areas 

as platform edges or waiting 

areas included) 

► Multi-storey, if applicable 


pedestrians 



applicable 



Fields of Application & Requirements 

Usable elements that 

are provided by the 

VISSIM network 

► None 

► Links as walkable 

space 

► Signalization 

► Conflict areas 

► Detectors 

► PT stops 

► PT lines as vehicle 

type with doors 



7.7.1 Overview: Pedestrians as PT Passengers 

The simulation of pedestrians and the simulation of public transport are 

connected by special modeling elements. Pedestrians can walk to a platform, 

wait until the public transport vehicle arrives and will board the vehicle after 

the alighting people have left the train. Alighters will follow the routes which 

are given to them as soon as they have left a train or bus. 

The scenario can easily be modeled using waiting areas, platform edges and 

the number of boarding and alighting people. 

PT stops, PT vehicles and their belonging public transport lines are modeled 

as before. 

► Waiting areas of a stop are the places where pedestrians wait until the 

arrival of a vehicle of the line they want to board. To define waiting areas 

for a stop, the user has to create a pedestrian area and select Waiting 

area for the Public Transport usage option. A waiting area has to be 

allocated to one or more stops. 

► A platform edge is a pedestrian area that belongs to one or more stops. 

Platform edge has to be selected for the Public Transport usage option. 

Alighting pedestrians walk to the nearest platform edge they can reach 

from their position in the vehicle. If a routing decision has been defined at 

the platform edge, the pedestrians continue their way. Otherwise, they 

are removed from the network. 

It is possible to create a platform edge along a stop automatically. 

Therefore, you have to check the Generate platform edge option in the 

Edit PT stop window. The two options left and right determine the 

position of the platform edge related to the stop. The area attributes are 

set automatically, thus changes in the Pedestrian Area window are not 

required necessarily. 

Default data is created if a pedestrian area is assigned to a PT stop either as 

waiting area or as platform edge and no boarding passenger volumes have 

been defined for this PT stop. 

Those default data is also created for an automatically generated platform 

edge. 

Due to the default data, each pedestrian arriving at the waiting area in the 

time interval 0 – 99999 will board any vehicle of any PT line. 

Alighting pedestrians are created according to the data in the PT Stop Data 

window. 

For each line and each stop event you need to define the percentage of 

alighting passengers. 

Additionally, you have to select a pedestrian composition for the alighting 

passengers in the PT Stop Data window. This composition determines the 

types of pedestrians that will be created inside the vehicle. 

Moreover, the user can define for each stop on which side the pedestrians 

are allowed to board or to alight respectively. You may select either side or 



both sides. The default behavior has no restrictions: all doors on both sides 

can be used for boarding and alighting. 

Boarding pedestrians wait on a waiting area of a particular stop. In order that 

a waiting area can be reached by pedestrians, it has to be defined as a route 

destination. 

Based on the boarding data of a stop, it is determined which lines the 

boarding pedestrians want to travel with. If a vehicle of one of these lines 

arrives at the stop, the boarding pedestrians walk straight to the nearest 

door. Once, all alighting pedestrians have left the vehicle, the boarding 

pedestrians board. 

A vehicle departs from a stop as soon as the departure time is reached and 

nobody has boarded during the last 3 sec. The departure time results either 

from the timetable or from the preset dwell time. For the timetable-based 

departure time the line´s Slack time fraction is considered. 

For boarding passengers as well as for alighting passengers you can define 

the distribution of the passengers to the doors. For boarding pedestrians, 

select the distribution in the Pedestrian areas window, for alighting 

pedestrians set the distribution in the PT stop data window. Use the option 

Late boarding possible to configure how a PT vehicle having a timetablebased 

departure time or a predefined dwell time for departure time 

calculation will handle a never-ending flow of boarding pedestrians. 

If a pedestrian was not able to board the vehicle, e.g. for capacity reasons, 

the pedestrian moves back to a waiting area. 

Default data for boarding pedestrians is also generated for a platform edge 

or waiting area which has been allocated to a PT stop for which no boarding 

passenger share has been entered yet. According to the default data each 

pedestrian who arrives at one of the waiting areas of this PT stop, will board 

the next vehicle of any line serving this stop. 

Another improvement is the possibility to define doors for 2D vehicle models. 

A door is defined by its position (relative to the leading edge), its width and 

one of the vehicle sides. 

For each door you can specify whether it can be used for boarding only or for 

alighting only or for boarding and alighting as well. 

These settings are stored in the Geometry window. 

The properties of doors are derived automatically from the 3D model (if any). 

The user can add or delete doors by using the context menu and modify the 

data directly in the table in the [DOORS] tab. 

If changed values do not match the 3D model a warning appears. 

Nevertheless, you can confirm the new values. The data set in this window is 

used for simulation only, whereas the 3D model values are used for the 

visualization of opening/closing doors in 3D mode. 

If not even a single door has been defined for a vehicle, a temporary door will 

be created at the middle of the vehicle length. This way it is ensured, that 

pedestrians can alight from the vehicle and board the vehicle. To provide this 

information, a warning is logged to the trace file. 



7.7.2 Step-by-Step Instruction: Pedestrians as PT Passengers 

This section describes step by step how to create a public transport interface 

for pedestrians (i.e. a public transport station). All construction elements are 

explained in detail in the manual. You will find links here on occurance. 

1. First create a Link, cf. section 6.3.1.1 

2. Create a Public Transport Stop, cf. section 6.5.1.1 

If you tick one or both of the Generate platform edge boxes, a Pedestrian 

Area is created on the corresponding side of the link that has the 

property Public Transport Usage: Platform Edge. When there is more 

than one Level, VISSIM tries to guess the correct level depending on the 

height of the link. 



If at a stop a Public Transport Usage area is attached, VISSIM calculates 

the occupancy of a train leaving the station not from the numbers that are 

specified as Boarding Passengers, but from the number of passengers 

that have actually boarded the train in the microscopic simulation. 



3. Create a Public Transport Line, cf. section 6.5.2.1 

4. Edit the Line Stop Data, cf. section 6.5.2.5. 

- Activate the stop 

- Alighting percentage: Set the ratio alighting passengers / total 

occupancy 

- Alighting location: Distribute the alighting pedestrians to the doors 

available for alighting 

- Choose which side of the vehicles of the line should be available for 

alighting and boarding 

- Set the timetable-based departure time (fix value) and/or the 

minimum dwell time (dwell time distribution), if applicable. Taking the 

slack time fraction into account, these three values determine how 

long the stop event will last at least. From the timetable-based 

departure time and the slack time fraction the real departure time is 

calculated. The PT vehicle will depart at the later moment in time 

after comparison of this instant and the moment in time that is 

calculated from the minimum dwell time. 

- If the option Late boarding possible is checked the PT vehicle will not 

depart at this instant but stay at the PT stop as long as still 

pedestrians flow in who intend to board the vehicle. Except for a 

break in this flow, only the capacity of the PT vehicle defines the 

upper limit of the PT vehicle’s dwell time (please refer to menu BASE 

DATA – VEHICLE TYPES… - EDIT… - SPECIAL – PT PARAMETERS). 


5. Choose an appropriate 3D Model, cf. section 5.2.5.2. 




6. Edit the doors of the train or bus 

- Number 

- Position 

- Width 

- Z offset 

- Side 

- Usage 


7. Create some more station geometry 




8. Create a Pedestrian Route Decision on the Platform Edge Area and at 

least one Pedestrian Route leading somewhere the alighting passengers 

are meant to walk to, cf. section 7.1.8. 



9. Create an area, where boarding passengers shall wait for the train or 

bus. 



10. Create a Pedestrian Input as source of boarding pedestrians, cf. section 

7.1.7. 


11. Create a Route from this input to the Waiting area 

12. Set the capacity of the tram or bus. 



8 Simulation and Test 

The parameters apply to the simulation of both vehicles and pedestrians. For 

additional parameters for the simulation of pedestrians please refer to 

section 7.5 et seqq. 



8.1 Simulation of Vehicles and Pedestrians 

Use the menu command SIMULATION – CONTINUOUS or SIMULATION – SINGLE 

STEP to start a simulation run. 

Starts the continuous simulation. F5 

Calls the next simulation step in the Single step 

simulation mode; 

Allows also toggling from Continuous to Single Step 

simulation mode during the simulation run. 

Terminates the current simulation run. ESC 

Via SIMULATION - MULTIRUN, the parameters for a multirun simulation can be 

set and the run can be started. 

In order to get a good impression of the possible stochastic spread of 

results it is recommended to run multiple simulation runs with different 

random seeds. 

In case of extensive networks with numerous vehicles, the VISSIM 64 bit 

edition may provide simulation results which differ from those calculated by 

the 32 bit edition due to small differences in internal rounding. 

8.1.1 Simulation Parameters 

Parameters for the next simulation or test run can be set in the Simulation 

Parameters window that is accessible via SIMULATION – PARAMETERS... 


F6

● Comment: Text to identify the 

simulation run. The comment 

line is stored in the input file and 

included in both printouts of the 

network and in output files. 

● Traffic regulations: Specifies the 

standard driving side (e.g. Great 

Britain and Hong Kong use Leftside 

Traffic). It affects the 

driving behavior on motorways 

(overtaking in the fast lane), the 

placement of the opposite 

direction of a link and the 

placement of bus lay-bys. 

● Period: The period of time to be 

simulated. Any warm-up times 

to fill up the network must be 

included here as well. 

Simulation of Vehicles and Pedestrians 

● Start Time: The time shown on the clock at the beginning of the 

simulation. In order for it to be displayed, the Time option needs to be 

selected (see VIEW - STATUS BAR). For Dynamic Assignment applications, 

the Start Time is used to generate the traffic demand of the OD matrices 

at the right time. The time needs to match the settings in the matrix files. 

● Start Date: Can be used to specify a date for signal controllers that have 

a date-dependent logic. This date is passed to the controller DLL. 

● Simulation Resolution: The number of times the vehicle’s position will be 

calculated within one simulated second (range 1 to 10). The input of 1 

will result in the vehicles moving once per simulation second. An input of 

10 results in the vehicles’ position being calculated 10 times per 

simulation second thus making vehicles move more smoothly. We 

recommend 3 or more time steps per simulation second. The change of 

simulation speed is inversely proportional to the number of time steps. 

On a fundamental level the simulation is a numerical integration of the 

system of coupled differential equations. The intended solution would be 

a continuous integration. 

This means that the numerical solution (the simulation) in time steps is 

only an approximate solution of the equation system, which gets worse 

when the length of time steps in the integration process is increased. 

This fundamental level of the simulation on the operational level receives 

"orders" from a supervising level within VISSIM. 

An example for such an order is: "Destination area 1 is reached, the next 

destination area is area 2". 



The larger the time intervals between the communications between the 

operational and the supervising level the more the simulation on the 

operational level can develop into a wrong direction. 

For the simulation of vehicles one can typically allow for a bit larger time 

steps than for the simulation of pedestrians as for pedestrians in their two 

spatial dimensions there are more possibilities (degrees of freedom) to 

run astray. The possibility to choose 1 simulation step per second 

therefore can be fine for a vehicles-only simulation. It can also be fine 

during the building process of a model including pedestrians, but once 

problems occur and for the evaluation and measurement 5 or 10 

simulation steps per second should be set if pedestrians are included in 

the model. 

The interaction between vehicles is subject to changes when changing the 

time steps value and thus the simulation results can be different. Thus we 

strongly recommend not to change this parameter during a simulation run 

or even during a running project. 

The simulation resolution also controls the playback speed of *.AVI files 

recorded with VISSIM. Please take note of this dependency when choosing 

the simulation resolution for a new project. 

If pedestrians are included in the simulation, the Simulation Resolution 

value is not subject to changes during the simulation run. 

● Random Seed: This parameter initializes the random number generator. 

Simulation runs with identical input files and random seeds generate 

identical results. Using a different random seed changes the profile of the 

traffic arriving and therefore results may also change. In this way, the 

stochastic variation of input flow arrival times can be simulated. For 

meaningful results it is recommended to determine the arithmetic mean 

based on the results of multiple simulation runs with different random 

seed settings. 

When using multiple simulation runs with different random seeds, the 

option Generate exact number of vehicles is to be switched on for all input 

flows in the network. 

Instead of running multiple simulation runs with different random seeds, a 

multirun simulation can be started via SIMULATION - MULTIRUN, cf. section 

8.1.3. 

● Simulation Speed: The number of simulation seconds to a real time 

second. If maximum is selected, the simulation will run as fast as 

possible. The change of the Simulation Speed does not affect the results 

of the simulation and can therefore be done at any time during the 

simulation. 

Note: The achieved actual simulation speed depends on the size of the 

network to be simulated and the computer hardware used. 



● Break at: After reaching the time entered here, VISSIM automatically 

switches into the Single Step mode. This option can be used to view 

traffic conditions at a certain time during the simulation without having to 

watch the simulation all the time before. 

● Number of cores: Select the number of processor cores to be used 

during simulation. The maximum number depends on the hardware of 

the computer where VISSIM is run. The selected value is kept for the 

next simulation start. The default value is 1. The number of cores is 

stored in the *.INP file. During a simulation, this parameter is not subject 

to changes. 

The simulation of pedestrians will always use all of the cores specified 

here, even if models with only a single level are simulated. 

8.1.2 Saving the Simulation State (*.SNP) 

A snapshot file (*.SNP) is used to save and restore the current simulation 

state. Thus it is possible to run a certain portion of the simulation (e.g. warmup 

period), save the simulation state and restore it, e.g. in order to look at 

different signalization options from there. 

The snapshot file contains the following data at the current simulation time: 

► all vehicles located on links/connectors and in parking lots including their 

current interaction state (public transport vehicles included) 

► all passengers in PT vehicles and at PT stops 

► the states of priority rules 

► the state of all fixed-time and VAP controllers 

It does not store the following: 

► the state of any other external signal controllers 

► cost and path information from Dynamic assignment 

► the state of route guidance systems 

► any network data 

► display settings 

► evaluation data 

It is not possible to use the snapshot functionality in the following cases: 

► with external signal contollers other than VAP 

► during a Dynamic Assignment (when the cost and/or path file is updated) 

► where evaluation files started before the snapshot file begins 

A snapshot file can only be loaded with the VISSIM version that was used 

to save the *.SNP file. 



If the VISSIM network was changed between saving and loading the snapshot 

file, the behavior of VISSIM is undefined (it might even crash). 

The snapshot file does not yet include simulation of pedestrians data. 

Definition 

To create a snapshot file follow the steps outlined below: 

1. Run the simulation. 

2. Select Single step mode at the time when a snapshot file should be 

created. 

3. Go to SIMULATION – SAVE SNAPSHOT and enter the desired file name. 

To continue a simulation from a snapshot file follow the steps outlined below: 

1. Ensure that the corresponding network file (*.INP) has been loaded and 

no simulation is active. 

2. Go to SIMULATION – LOAD SNAPSHOT and choose the desired file name. 

3. Continue the simulation. 

The simulation then continues as if it was not interrupted. Any evaluations 

that should begin after the start time of the snapshot file will be evaluated as 

usual. 

8.1.3 Multirun Simulation 

Use the multirun simulation feature to automatically run multiple simulation 

runs. 

Typical applications are: 

► Variation of random seed 

► Dynamic Assignment iterations 

► Successive increase of traffic demand with Dynamic Assignment 

In contrast to single simulation runs the particular case-specific parameter 

(e.g. random seed) is changed for every simulation run of a multirun 

simulation. 

For other settings please refer to: 

► Simulation parameters (cf. section 8.1.1) and 

► Dynamic Assignment settings (cf. section 12.8.6). 

For output of the desired evaluation files, these need to be selected and 

configured via EVALUATION - FILES prior to the multirun start. 

For Dynamic Assignment all settings need to be done in TRAFFIC - DYNAMIC 

ASSIGNMENT prior to the multirun start. 




SIMULATION – MULTIRUN... opens the Multirun window where all additional 

settings for the multirun simulation are done. 

● Starting random seed: 

cf. section 8.1.1 Random 

seed. 

● Random seed increment: 

Offset that will be added 

to the random seed for 

every subsequent run. 

The stochastic variation 

is independent of the 

size of the number. 

When using Dynamic 

Assignment this parameter 

should be set to 0. 

For a multirun simulation with different Starting random seed numbers, the 

Random seed increment is decisive. In this case, the particular starting 

random seed value which serves as index of the simulation run is attached 

to the evaluation file *.LDP. 

● Number of runs: Amount of automatic simulation runs to be done. 

Depending on the application 5 to 20 runs are recommended. When 

using Dynamic Assignment more runs might be necessary. 

● Dynamic Assignment Volume Increment (refers only to Dyn. Assignment): 

When using Dynamic Assignment the total demand can be 

increased successively (similar to command line parameter -v). The start 

value is taken from the parameter "Scale total volume to" from the 

Dynamic Assignment (cf. section 12.8.6). For every iteration the demand 

is increased by this value until 100 % is reached. 

Please note, that the start value should not exceed 100% demand. 

● Evaluation files directory: Directory where the evaluation and error files 

are saved. Press to select a different directory. The flag being added 

to the name of the output file by iteration run indicates the actual random 

seed value automatically calculated from the start random seed plus the 

particular difference resulting from the random seed increment by run. 

Since existing files with identical filename are overwritten without 

warning, careful selection of the output folder is recommended. As usual, 

*.BEW and *.WEG files are saved to the project directory containing the 

*.INP file. 

● Create archived cost and path files: If this option is active, existing 

output files *.BEW and *.WEG stored in the same folder as the *.INP file 

will be renamed. Numbers will be added to the filenames prior to creating 

new output files. Thus the data file archive allows for subsequent 

analyses of changes during Dynamic Assignment. You even might start 



calculation from an elder assignment state. 

If this option is active, existing output files *.BEW and *.WEG are 

replaced. 

● CLOSE: Closes the window and stores the current settings internally until 

the VISSIM session is terminated. 

● START: Closes the window, stores the current settings internally and 

starts the multirun. The status bar shows the number of the current run 

and the total number of runs (in parentheses). The evaluation files are 

saved to the directory set in the parameters. 

The settings are saved with the *.INP file. 

If the selected evaluation directory is a sub-folder of the current data 

directory (or the data folder itself), a relative path is saved. Thus, copying 

the *.INP file to a different folder will cause subsequent evaluations to be 

written to a subdirectory of the new folder or to the new folder itself. 

It is not recommended to use the variation of random seeds in combination 

with Dynamic Assignment as ping pong effects may occur. 

To get statistically sound results all vehicle inputs need to have the exact 

volume property enabled (in contrast to stochastic volume). 


Test of Signal Control without Traffic Simulation 

8.2 Test of Signal Control without Traffic Simulation 

VISSIM offers the Test function to analyze a signal control logic’s behavior 

with various detector call scenarios without actually modeling traffic flows. 

Detector calls are generated through 

► interactive mouse clicks or 

► pre-recorded macros. 

The Test function is helpful when debugging a newly developed control logic 

especially if it contains only sporadically used functions such as railroad 

preemption, PT signal priority or queue “flush-out”. VISSIM discriminates 

between the following detector actuations: 

Single 

Actuation 

Repeated 

Actuation 

Continuous 

Actuation 

Increasing impulse (vehicle front) and decreasing impulse 

(vehicle end) within one second 

Increasing and decreasing impulse during every second; 

equivalent to a single actuation each second 

Single impulse increase; impulse decrease only after explicit 

termination of actuation 

8.2.1 Interactive Placement of Detector Calls 

To place detector calls (actuations) follow the steps outlined below: 

1. In VIEW - OPTIONS - [TRAFFIC], activate Individual Vehicles. 

2. In VIEW - NETWORK ELEMENTS activate the display of Detectors. 

3. If you would like to create a Signal/Detector protocol (cf. section 11.9), 

toggle the appropriate options in EVALUATIONS – FILES and/or – WINDOWS. 

4. If the sequence of detector actuations is to be stored for later testing of 

other control strategies, activate the macro functionality using TEST – 

RECORDING. 

5. Start the test function with TEST – CONTINUOUS or TEST – SINGLE STEP. 

Starts the continuous Test run. F5 

Calls the next step in the Single step mode; 

Allows also toggling from Continuous to Single Step 

mode during the Test run. 

6. Activate individual detector calls by clicking: 

- Left mouse button: In Single Step mode, switch from no actuation 

(black) to single actuation (blue) and to repeated actuation (cyan) 

and back to no actuation. 

- Right mouse button: Place (as well as terminate) a continuous 

actuation (purple). 


F6


8.2.2 Using Macros for Test Runs 

Instead of interactively placing every single detector call in every test run, a 

macro file can be used that contains all desired detector calls. The use of 

macro files is recommended in each the following cases: 

► A test run with a fixed set of detector calls is to be evaluated under 

different control strategies. 

► Different, but similar test runs are to be evaluated. 

A macro for a test run can be created in two ways. 

Use one of the options to place the detector calls interactively: 

► option RECORDING 

► the macro editor 

Recording 

To create a macro file for a fixed test run for multiple control scenarios follow 

the steps outlined below: 

1. Select TEST - RECORDING (when reopening the TEST menu, a check mark 

appears at RECORDING). 

2. Interactively place the desired detector actuations with TEST – CONTI- 

NUOUS or TEST – SINGLE STEP, cf. section 8.2.1. 

3. Terminate the test run with STOP. Because of the activated recording 

function, a macro file with the extension *.M_I will be created. 

4. Modify the parameters of the control logic and repeat the same set of 

detector calls with TEST – MACRO – RUN... 

Editing 

To evaluate a control logic with different, but similar test runs, use the macro 

editor as described below: 



1. Create a macro data 

file through interactive 

placement of 

detector calls as 

outlined above. 

2. Create similar test 

macros using the 

macro editor (TEST – 

MACRO – EDIT). The 

Macro Editor window 

appears. 

3. Delete existing actuations 

(Highlight the 

appropriate line and 

press DELETE). 

4. Insert an additional 

actuation: 

Select a signal controller (SC), detector number (Det.), time interval 

(from, until resp. in) and type (Single, Continuous, Repeating) of the 

actuation. Since single actuations only last one second, only one time is 

to be defined. Pressing INSERT: inserts the new actuation before the 

currently highlighted detector call. VISSIM will not automatically sort the 

detector call list. 

5. For editing previously defined actuations (e.g. change time interval), 

delete the existing actuation and create a new actuation. 

6. The test macro can be saved with a different name using the SAVE AS 

command. 

7. If PT call points are supported by the selected control strategy, call 

telegrams can also be included in the macro as special actuations for 

detector type PT Tel. 

Application 

For each test run, please follow the steps outlined below: 

1. Macro file recording (and editing, if applicable). 

2. Adjust control logic parameters to the particular test scenario. 

3. Enable evaluation(s), if applicable. 

4. Start test run via TEST – MACRO – RUN... 

5. Save evaluations, if applicable. 

The files generated during test runs are not named automatically according 

to test number or similar. Be careful when specifying file names. 



When testing VS-PLUS control strategies, usually an SC/Detector protocol 

is generated for each test scenario. It is recommended to name each *.LDP 

file like the particular macro test file (*.M_I) that was used for generating 

the *.LDP file. 

8.2.3 Using Batch Mode Operation for Test Runs 

In addition to manually defined detector actuations, VISSIM can also analyze 

a series of special test cases. 

This feature is especially helpful to answer questions like: 

► How does the tested logic react to exceptional situations such as 

repeated demand for all signal phases with a PT preemption event at a 

certain time? 

► What happens if the preemption event occurs one second later or two 

seconds earlier, etc.? 

The batch mode operation discriminates between signal groups (phases) 

with specific detector actuations (test phases) and signal groups (phases) 

with constant demand or recall operation (recall phases). 

In an output file *.SLO, VISSIM logs all signal changes that occurred during 

the test run. This output file is used to prepare the following analyses: 

Red Time 

Distribution 

Green Time 

Statistics 

Time-Time- 

Diagram 

Waiting times for test phase vehicles depending on the cycle 

second in which the preemption call occurred 

Green time average and distribution for all signal groups 

(phases) depending on preemption time point, required 

green time and volume to capacity ratio 

Diagram showing green time of up to four signal groups 

(phases) against the time of preemption 

VISSIM requires a configuration file *.SLF as input. This file has to be 

created with a text editor outside of VISSIM according to the example shown 

below. Note that VISSIM ignores comments (text following two dashes ‘--‘). 

The presence and sequence of the key commands at the beginning of each 

line is important. 

Example 

The following example analyzes the impact of a light rail preemption event 

between simulation second 1 and 10 on the signal operation. Light rail trains 

place their preemption call via detector #901 and checkout via detector #902. 

The average queue length at the stop line defines the number of vehicles 

usually queued at the beginning of the green interval. It is assumed that the 

PT vehicle is in the middle of the queue and gets an additional delay of 2 

seconds per vehicle in front of it. Detector actuations for the recall phases 

can be set to repeated (ALF/LFD) or continuous (AST/STE). Multiple 



detectors including call sequence and time gap can be defined for call and 

checkout using the following syntax: 

call : ANF {NACH DET }* 

checkout: ABM {NACH DET }* 

-- Configuration File for VISSIM/Test/Loop 

-- 185p98s4.SLF 

LSA 1 -- controller number 

VLZ 120 -- startup time (before preemption event) 

NLZ 240 -- recover time (after preemption event) 

BUM 5 -- number of analyzed cycles (if applicable - otherwise delete this line) 

ASL 1 -- number of nested loops 

ALF 7 -- total number of detectors with repeated demand (recall) 

LFD 1 2 3 4 5 6 8 -- detector numbers with repeated demand (recall) 

-- 

SLF 1 -- Loop 1: 

VON 1 -- start of analysis time window 

BIS 10 -- end of analysis time window 

ANF 901 -- preemption call detector (actuated) 

ABM 902 -- checkout detector 

SGP 204 -- preemption (actuated) signal phase 

FZ1 53 -- travel time from call detector to stop line 

FZ2 3 -- travel time from stop line to checkout detector 

MRL 0 -- average queue length at stop line in vehicles 

Nesting of analysis loops is an option to analyze multiple combinations of 

events. However, this type of analysis requires a substantial amount of 

computing time. 

Overview of the Syntax 

Please note, that German and English commands can be used in the same 

file. 

German Definition English 

LSA Controller No. 1 SCJ 

VLZ Startup time (before preemption event) LDT 

NLZ (Optional) recover time (after preemption event): 

120 s 

CTI 

BUM Total number of analyzed cycles, 

(if applicable, otherwise delete this line) 

NCY 

ASL Total number of nested loops NLO 

AST Total number of detectors with continuous 

demand, followed by STE 

NCA 

STE Numbers of the detectors with continuous 

demand, only following AST 

CAC 

ALF Total number of detectors with repeated demand 

(recall), followed by LFD 

NRA 



German Definition English 

LFD Numbers of detector with repeated demand 

(recall), only following ALF 

RAC 

SLF Loop No. 1 LOOP 

VON Start of analysis time window FROM 

BIS End of analysis time window UNTIL 

ANF No. of preemption call detector (actuated) C_I 

NACH After 0 seconds (followed byt DET in same line) TO 

DET Detector No.; e.g. After 0 s detector 5 as well DET 

ABM No. of checkout detector COD 

SGP Actuated signal phase No. (preemption) SGP 

FZ1 Travel time from call detector to stop line DT1 

FZ2 Travel time from stop line to checkout detector DT2 

MRL Average queue length at stop line in [vehicles] AQL 

8.2.3.1 Red Time Distribution (*.AWZ) 

The red time distribution is a graphical representation of the waiting time for 

each signal group (phase). 

To get a red time distribution follow the steps outlined below: 

1. Via TEST - LOOP – RUN, load an *.SLF file and create a loop output file 

*.SLO. 

2. Create the red time distribution file via TEST - LOOP – ANALYZE – WAITING 

TIMES DISTRIBUTION.... from the *.SLO file. 

VISSIM creates a file with the extension *.AWZ and the following content: 

1 1 * 

2 1 * 

3 1 * 

4 1 * 

5 1 * 

6 1 * 

7 1 * 

8 1 * 

9 1 * 

10 1 * 

1.0 

The first column contains the time of preemption call and the second column 

shows the resulting waiting time for test phase vehicles. The number of stars 

to the right represents the waiting time graphically. The average waiting time 

is shown at the bottom. This example shows that preempting light rail 

vehicles experience one second of delay for every analyzed preemption 

time. 


8.2.3.2 Green Time Statistics (*.AGZ) 


VISSIM generates a green time distribution with and without preemption 

event for all signal groups (phases) specified in the demand file *.BEL. 

VISSIM also calculates green time requirement and volume to capacity ratio 

for all signal groups (phases) according to the specified volume demand. 

To get the green time statistics follow the steps outlined below: 

1. Use an external text editor (e.g. Notepad) to create a demand file (*.BEL, 

see example below) and set parameters accordingly. A demand file is 

required for comparing actual and necessary green times and has the 

following structure: 

-- Intersection Demand File for VISSIM/Test/Loop 

-- 185p98s4.BEL 

LSA 1 -- controller # 

ASL 1 -- # of nested loops 

BELASTUNG 12 -- preempting vehicles per hour 

-- signal phase #/ demand [veh/h] / base green time [sec]: 

SGP 1 BELASTUNG 100 SAETTIGUNG 1770 BASISGRUEN 8 







2. Generate the green time statistics file with the extension *.AGZ via TEST - 

LOOP – ANALYZE – GREEN TIME STATISTICS. Use the previously generated 

loop output file *.SLO. It will have the following content: 

Signal group 1: 

Average green time: 

- without modification = 8.0 s (100.0%) 

- modified by public transport = 14.5 s (181.2%) 

- weighted average = 10.6 s (132.5%) 

Capacity: 

- saturation flow = 1770 veh/h 

- public transport modifications = 12 veh/h 

- flow = 100 veh/h 

- capacity = 156 veh/h 

- degree of saturation = 0.64 

Required green time = 6.8 s 

Distribution of green times: 

13 1 * 

14 7 ******* 

15 0 

16 0 

17 2 ** 



8.2.3.3 Time-Time Diagram (*.AZZ) 

The time-time diagram shows green time against the time of preemption call 

for up to 4 signal groups (phases). VISSIM creates a separate diagram for 

each nested loop in relationship to the call time point of the first loop. 

To get a time-time diagram follow the steps outlined below: 

1. Use an external text editor to create a demand configuration file *.ZZD 

that contains up to 4 signal groups (phases) using the following syntax: 

-- Configuration File for Time-Time Diagram for VISSIM/Test/Loop 

-- 185p98s4.ZZD 

LSA 1 -- controller # 

-- analyzed signal groups (phases): 

SGP 2 5 204 

2. Generate the time-time diagram file with the extension *.AZZ via LOOP – 

ANALYZE – TIME-TIME-DIAGRAM.... Use the previously generated loop 

output file *.SLO. It will have the following content: 

A = 2 

B = 5 

C = 2 + 5 

D = 204 

E = 2 + 204 

F = 5 + 204 

G = 2 + 5 + 204 

10 20 30 40 50 60 

1 BBBBBBBBBBBBB DDDEAAAAAAAAAA 

2 BBBBBBBBBBBBBB DDDEAAAAAAAAA 

3 BBBBBBBBBBBBBCC DDDEAAAAAAAA 

4 BBBBBBBBBBBBBCCC DDDEAAAAAAA 

5 BBBBBBBBBBBBBCCCA DDDEAAAAAA 

6 BBBBBBBBBBBBBCCCAA DDDEAAAAA 

7 BBBBBBBBBBBBBCCCAAA DDDEAAAA 

8 BBBBBBBBBBBBBCCCAAAA DDDEAAA 

9 BBBBBBBBBBBBBCCCAAAAA DDDEAA 

10 BBBBBBBBBBBBBCCCAAAAAA DDDEA 

The first column shows the time of preemption call of the test phase, the 

heading line depicts the cycle time of the resulting timing plan as 

illustrated to the right of each time of preemption using a letter coding 

scheme. Each letter represents a combination of one or more signal 

groups (phases) that show green. The legend at the top of the file shows 

the relation of letters and signal groups (phases). 


9 Presentation 

For presentiations, you can use two types of record files. This chapter 

describes the recording work flows: 

► Animation files, cf. section 9.1 

► 3D Video files, cf. section 9.2 



9.1 Animation 

For the purpose of reviewing simulation runs and ease of presenting those 

runs, VISSIM offers the option of recording simulation sessions - even 

simulations of pedestrians - and saving them as animation files (*.ANI). 

These files can be recorded at any time interval during the simulation and 

played back from any point within the VISSIM network and at any speed 

supported by your hardware. Unlike simulations, animation files can be run in 

forward and reverse direction thus allowing presenters and analysts to replay 

a selected sequence easily. Animation files do not support the runtime 

analysis tools that can be used during and after a simulation. These are 

separate files generated during the simulation. 

Animation files can also be recording with Alternative Link Display for 

vehicular traffic or LOS display for pedestrians. On behalf of that, the 

aggregate parameters display needs to be active during recording (cf. 

section 4.1.1 for vehicles and section 7.3.3 for pedestrians). 

3D signals are not included in the animation file and thus will not show while 

running an animation in 3D mode. In this case recording an *.AVI file is 

recommended. 

Since an animation only replays the graphics the animation runs are much 

faster than the actual simulation. 

9.1.1 Record Animation File 

To record an animation, follow the steps outlined below: 

1. Select PRESENTATION - ANIMATION PARAME- 

TERS... to open the Animation Parameters 

window. 

2. Press NEW… next to the Time Intervals list 

and define an interval to be recorded. 

There may be multiple intervals for a single 

simulation run but they may not overlap. 

3. Press NEW… next to the Areas list to 

activate the main VISSIM window. Draw 

one or more areas by moving the mouse 

while holding down the left mouse button. 

Only vehicles/pedestrians simulated within 

at least one of these boxes will be included 

in the animation file. 

4. Uncheck the option Save vehicle/pedestrian 

positions to record only 

aggregated data instead of individual 

vehicles/pedestrians. Then the animation 

file will not save display information and 

thus will be much smaller. 


Animation 

If option Save vehicle/pedestrian positions is active during the 

recording of aggregated data, the positions will be saved additionally. 

Thus movements can be shown alternatively during the animation run. 

The wording of this option regards the active modules, i.e. without 

pedestrians add-on, only vehicles are mentioned. 

5. Before starting the simulation, PRESENTATION - ANI RECORDING must be 

activated. Then the parameters described above will be saved to the animation 

file during the next simulation run. After the simulation run, the 

RECORDING option will be deactivated automatically. 

When the *.ANI file is recorded, also the colors of those segments are saved 

to file for color-coded display of aggregated values, which are not completely 

located within the user-defined network sections. 

9.1.2 Replay Animation File 

1. Go to PRESENTATION - ANIMATION PARAMETERS... and open the desired 

Animation File. 

2. Choose the Animation Start second and press Ok. 

3. Go to PRESENTATION - CONTINUOUS to start the animation run. You can 

control the animation run from the ‘Run Control’ buttons in the toolbar. 

4. Alternatively you can activate the ‘Animation’ toolbar: Right-click in the 

toolbar area and tick ANIMATION from the context menu. 

Starts the continuous animation. F5 

Calls the next animation step in the Single step 

mode; 

Allows also for toggling from Continuous to Single 

Step animation mode during the animation run. 

Terminates the current animation run. ESC 

Continuous in reverse direction. 

Single-step mode in reverse direction. 

9.1.3 Record ANI.TXT File (optional module) 

Via PRESENTATION - ANI.TXT RECORDING, network data and trajectories of 

cars and pedestrains and also the states of the signal controllers and of the 

dectors are saved to a text file for the import in Autodesk´s 3DS MAX 

software. 

For this add-on, the folder ..\API\3DSMAXEXPORT of your VISSIM 

installation has various subfolders which store a script in Autodesk´s macro 


F6


language for import of the generated data files in 3DS MAX as well as some 

example vehicle models (3D) and instructions and more information. 


9.2 Recording 3D Video files 

Recording 3D Video files 

VISSIM can record a video of a 3D simulation run using the *.AVI data file 

format. To set up VISSIM to record an *.AVI file follow the steps outlined 

below. 

9.2.1 Recording Options 

VISSIM records *.AVI files that will be played at a constant rate of 20 frames 

(pictures) per second. As each simulation time step results in one picture, the 

actual playback speed of the *.AVI file depends on the simulation resolution 

(time steps per simulation second) during the recording: If 10 time steps are 

chosen (recommended value), the playback speed will be twice as fast as 

real time. When using only 1 time step, then the resulting playback speed will 

be 20 times faster than real time. 

Be aware that changing the simulation resolution has an impact on the 

driving behavior and thus might lead to different simulation results. 

There are two options provided additionally to *.AVI file recording: 

► PRESENTATION - 3D-VIDEO - ANTI-ALIASING: Special algorithm to reduce 

“jaggies” (i.e. pixel edges caused by the screen resolution). When this 

option is used, *.AVI file recording is much slower but produces a video 

file of higher quality. 

► PRESENTATION - 3D-VIDEO - STEREO (2 AVIS): Produces two *.AVI files, the 

second one with a slightly different camera location. This feature allows 

for production of a stereoscopic movie (special equipment needed for 

viewing). 

9.2.2 Keyframes 

In order to use different viewing locations within an *.AVI file, a predefined 

set of camera locations may be used. These locations are called keyframes. 

In order to use them for recording an *.AVI file, the keyframes need to be 

defined prior to the recording. 

Keyframes are saved in the VISSIM network file (*.INP). 


In order to define keyframes, the 3D graphics mode needs to be active. 

1. Set the observer position in 3D as desired for the keyframe. 

2. Click PRESENTATION - 3D-VIDEO - KEYFRAMES... to call the Keyframe 

window. It contains a list of all defined keyframes. 



3. Press NEW... to create a new keyframe entry in the list. Define the 

keyframe properties and confirm with Ok. 

4. The 3D view may be changed even while the Keyframe window remains 

open. Doing so allows to create a series of keyframes. Simply repeat 

steps 1 and 3 for every keyframe to be added. 

5. After all keyframes have been created, click OK to close the list of 

keyframes. 


For access to the properties of a keyframe, click PRESENTATION - 3D-VIDEO - 

KEYFRAMES.... For list or data editing, cf. section 9.2.2.3. 


● Starting time: Start time of this keyframe: 

- If option Absolute start times is 

checked in the keyframe list the time 

entry refers to the start of the 

simulation. The keyframe starts as 

soon as the simulation second equals 

the entered starting time. 

- If option Absolute start times is not 

checked in the keyframe list the start 

time is interpreted as the time relative 

to the moment when the AVI 

RECORDING command was activated. 

Changing the Starting time also allows for changing the sequence 

position of the keyframe. 

● Dwell Time: The time the simulation will be viewed without movement 

from the position defined by this keyframe. 

Using the Starting time and Dwell time, VISSIM performs a check whether 

the current keyframe fits into the existing keyframe sequence: Neither for 

the start time nor for the dwell time of a keyframe a value can be set that 

intersects with the dwell time of another keyframe. However, all 

subsequent keyframes may be shifted to accommodate for the new starting 

time and/or dwell time by activating the option Shift subsequent 

Keyframes (see below). 

● Movement defines the type of movement between the camera positions 

of this and the next keyframe: 

- A linear movement results in a change of position at constant speed. 

- A sinusoidal movement uses slower speeds closer to the keyframe 

positions and accelerates between them thus making the movement 

smoother. 

- A linear-sinus movement starts with a constant speed and slows 

down towards the next keyframe. 



- A sinus-linear movement starts with an increasing speed and 

continues with a constant speed towards the next keyframe. 

The latter two options can be used to define intermediate keyframe 

positions with no dwell time to specify the path from one keyframe to 

another while retaining a smooth movement. 

Example: If keyframe 2 is an intermediate keyframe with 0s dwell 

time, then the movements could be defined as: 

Keyframe 1: sinus-linear 

Keyframe 2: linear 

Keyframe 3: linear-sinus 

● Shift subsequent Keyframes: Moves the start times of all subsequent 

keyframes according to the current settings for the selected (new or 

edited) keyframe: 

- When inserting a new keyframe (KF) between two keyframes in the 

existing keyframe sequence, VISSIM checks that the start time of the 

new keyframe is later than the dwell time end of the previous one. If 

so, then VISSIM changes the start times of all subsequent keyframes 

by ∆t = start time new KF + dwell time new KF + movement time 

previous KF - start time next KF. 

By adapting the next KF’s start time accordingly VISSIM ensures that 

the (calculated) movement time to the keyframe following the new 

keyframe is retained. Thus it remains the same as it was before the 

new keyframe was inserted. 

- When editing an existing keyframe, all subsequent keyframes are 

moved to accommodate for the new start and dwell times. I.e., the 

start times of all subsequent keyframes are moved by ∆t = new start 

time - old start time + new dwell time - old dwell time. 

As long as option Shift subsequent Keyframes is checked, an existing 

keyframe cannot be moved before any previous keyframe. 


The list of keyframes can be accessed by selecting PRESENTATION - 3D-VIDEO 

- KEYFRAMES... While the list is visible, only a selection of all VISSIM 

functions, commands and hotkeys is available. Among them are the view 

and simulation commands so that the viewing position can be changed and 

the simulation can be started while the keyframe list is visible. A click on a 

keyframe in the list changes the camera position in the 3D network window. 



● NEW: Creates a new keyframe with the current 3D view. 

● EDIT: Provides access to the properties of the selected keyframe. 

● UPDATE POSITION: Changes the camera position associated with the 

selected keyframe to the current 3D view. 

● DELETE: Deletes the selected keyframe(s). 

● Preview: Clicking the START button calls the display of the camera movement 

through the selected keyframes in the list. This simulates the 

movement during recording of an *.AVI file in the selected speed. The 

preview can be canceled with ESC. 

● Columns: 

- The Movement time between two keyframes is computed automatically 

as the difference between start and dwell times of the current 

keyframe and the start time of the following one. It is not possible to 

insert a keyframe into the list that overlaps with an existing one. 

The type of movement is shown right behind the movement time, it is 

indicated by the starting letter(s) of the corresponding type. 

- The Focal Length (Field of View) column contains current settings by 

keyframe, cf. section 4.3.1.3 

● Absolute Start Times: If this option has been checked, the Start times are 

regarded as absolute simulation times. 

If this option has not been checked, start time data counts from the 

moment in time when the AVI RECORDING command is activated in the 

PRESENTATION menu. Thus the process does no longer automatically start 

from the moment when the AVI RECORDING command is clicked. Via 

menu PRESENTATION – 3D-VIDEO – KEYFRAMES, the start can be delayed 

with a start time entry > 0 s for the first keyframe. 

Thus you can enter Start time = 0 for the first keyframe to start the run 

immediately by clicking the AVI RECORDING command as usually. 



All changes made in the list of keyframes are only permanent if the 

Keyframe window is closed with the OK button. Thus any changes to the 

list can be undone by leaving the window with CANCEL. 

9.2.2.4 How Keyframes Come Into Action 

Basically there are two applications for keyframes: 

► “Storybook” for the recording of *.AVI files 

► Library of predefined perspectives for 3D mode display 

Keyframes as “Storybook” for the recording of *.AVI files 

During the recording of an *.AVI file the keyframes will be run through in the 

order in which they are listed (sorted by start time), starting from the first 

starting time which not necessarily needs to be the start time of the 

simulation. Then the 3D view will change to the first keyframe. If no 

keyframes are present, VISSIM will record the current view of the 3D model. 

If the users changes the view during the simulation that change will be 

recorded. 

Using keyframes without recording an *.AVI file 

The list of keyframes is available also during a simulation run in order to 

provide a means to view the 3D simulation from predefined perspectives. As 

a keyframe is selected in the list, the view changes to its camera position. 

Note: While the Keyframe window is visible, not all of the VISSIM functions, 

commands and hotkeys are available. 

9.2.3 Starting the AVI Recording 

1. If not enabled already, switch to 3D graphics mode. 

2. To start the recording from the beginning, select PRESENTATION – AVI 

RECORDING and start the simulation. If you would like to start the 

recording at a later time during the simulation run, set the start time of 

the first keyframe accordingly. The enabled option is confirmed with a 

check mark. 

3. As the recording is started, you will be prompted for a filename of the 

associated *.AVI file. Select the filename and confirm with OK. 

The *.AVI file needs to be saved to the same directory as the VISSIM 

network file (*.INP). 



4. The Video Compression window 

opens to receive the desired video 

compression codec. It is highly recommended 

to use video compression 

since *.AVI files become 

very large without compression. The 

compression modes available depend 

on the system configuration. 

Some compression modes offer additional configuration to be set in this 

window. 

Be aware that some compression codecs might not be compatible for use 

with *.AVI recording (in contrast to playback). As the behaviour depends 

on the system configuration, the easiest way to check this beforehand is to 

record a short sample *.AVI and try to run it after completion. If the newly 

generated *.AVI file does not run, try a different video codec. 

The video compression used for the *.AVI recording must be installed also 

on every computer where the *.AVI file is to be shown. As video compression 

codecs depend on the Windows installation, it is recommended to 

use a codec that is widely used in standard installations. 

5. Confirm with OK in order for the *.AVI file to be recorded. The *.AVI file is 

now recorded while the simulation is active. 

The selection dialogs for the name of the *.AVI file and for the video codec 

are displayed prior to the simulation initialization which takes more time the 

more pedestrian areas are in the network. 

Recording an *.AVI file can take substantially longer than a normal 3D 

simulation, especially if the Anti-Aliasing option is activated. 


10 Output of Results 

VISSIM offers a wide range of evaluations that result in data displayed during 

a simulation/test run and/or in data stored in text files and/or in a database. 

Due to improvements and enhancements of the driving behavior in newer 

versions the output results may differ from older VISSIM versions. 

The definition and configuration process along with sample results is 

described in chapter 11 by evaluation type. 

For the Pedestrians add-on, the evaluations are described in section 7.2. 

This chapter provides information about enabling evaluations and possible 

runtime errors. 

A complete list of all file types that are associated with VISSIM is contained 

in chapter 13. 



10.1 Enabling Evaluations 

Apart from definition and configuration, evaluations need to be enabled in 

order to produce the desired output. 

files and/or databases or display evaluation data online during a 

simulation/test run. 

The table provides an overview of the various evaluations: 

► Window column: Online display in a window during a simulation/test run 


► Raw data column and Comp. data column: Output of raw data and/or 

compiled data to file (cf. section 10.1.2) 

► MDB column: Output of raw data and/or compiled data to a database (cf. 

section 10.1.3). 

► Config. column and Filter column: For numerous evaluation, customized 

configuration or filter settings can be saved to file for later use. 

Evaluation 

type 

Raw 

data 

Observer *.BEO 

Export *.* 

Comp. 

data 

Config. Filter MDB Window 

Veh. Record *.FZP *.FZK *.FIL 

Veh. 

Information 

*.FZI 

Nodes *.KNR *.KNA *.KNK 

Data 

collection 

Network 

Performance 

PT Wait time *.OVW 

*.MER *.MES *.QMK 

*.NPE *.NPC 

Travel times *.RSR *.RSZ 

Lane change *.SPW *.LCF 

Queue length *.STZ 

Link 

evaluation 

*.STR *.SAK 

Delay *.VLR *.VLZ 

Vehicle inputs *.FHZ 


Evaluation 

type 

Analyzer 

database 

Special 

evaluations 

Paths (Dyn. 

Assignment.) 

Raw 

data 

*.MDB 

*.XLS 

*.XML 

*.PDF 

*.A** 

Convergence *. CVA 

Managed 

lanes 

Signal times 

table 

Distribut. of 

green times 

SC/Detector 

record 

Signal 

changes 

Pedestrian 

Information 

Ped: Area 

evaluation 

Pedestrian 

record 

Ped: Travel 

times 

Comp. 

data 

Enabling Evaluations 

Config. Filter MDB Window 

*.ANC 

*.WGA *.WGK *.WGF 

*.MLE *.MLC 

*.LZV 

*.SZP ** 

*.LDP *.KFG 

*.LSA 

*.MERP *.MESP *.MESPK 

*.PDI 

*.PP *.PDK *.PIL 

*.RSRP *.RSZP 

Ped: Queues *.PQE 

** For the Signal times table window, the output has to be configured via 

menu SIGNAL CONTROL – EDIT CONTROLLER in the [SIGTIMTBLCONFIG] tab and 

can be saved to file there as well. 



10.1.1 Output to Window 

Click menu EVALUATION - WINDOWS to enable the appropriate Window output. 


► VEHICLE INFORMATION...: Configuration 

of the vehicle information 

data that will be displayed when 

double-clicking on a vehicle 

during a simulation run. 

For more details cf. section 

11.6. 

► PEDESTRIAN INFORMATION...: 

Configuration of the pedestrian 

information data that will be 

displayed when double-clicking 

on a pedestrian during a 

simulation run. 


7.2.5 

► SIGNAL TIMES TABLE controls the 

display of the Signal Times 

Table window for each 

controller individually. Inside 

these windows both Detectors 

and Signal Groups can either be 

labeled with their Name or 

Number. 


11.8. 

► SC/DET.RECORD... controls the 

display of the Signal Control 

Detector Record window for 

each controller individually. 

Inside these windows both 

Detectors and Signal Groups 

can either be labeled with their 

Name or Number. 


11.9. 


► SIGNAL CHANGES: Displays a 

chronological list of all phase 

changes of all signal controllers. 


11.10. 

► TRAVEL TIMES: Displays the 

exponentially smoothed travel 

times for each defined Travel 

Time Measurement. 


11.1. 


During a simulation of pedestrians defined as vehicle types who traverse 

links which are pedestrian areas, the travel time measurement results for 

these pedestrians will be displayed in the Travel times window. 

10.1.2 Output to File 

File output is enabled through the Evaluations (File) window which can be 

accessed by EVALUATION – FILES... 

Three tabs are provided: 



[VEHICLES] 

[SIGNAL 

CONTROL] 

[PEDE- 

STRIANS] 

► Evaluations of vehicle 

traffic, cf. chapter 11 

► Evaluations of signal 

control, cf. chapter 11 

► Evaluations of pedestrians, 

cf. section 7.2 

For data output during the simulation run, tick the box adjacent to the 

evaluation option. If applicable, check the configuration and filter settings by 

evaluation type. 



The filenames of the corresponding output files are generated as follows: 

Output file Name of the input file + evaluation type specific output 

file extension 

Configuration 

file 

Filter parameter 

file 

Name of the input file by default + evaluation type specific 

configuration file extension 

Name of the input file by default + evaluation type specific 

filter file extension 

Default names can be replaced by the user. To filenames, the Windows 

filename conventions apply. A filename may contain blanks or specific 

characters such as _-+$.# and the German äÖüß or the French Ç or œ, for 

example. 

For the complete list of VISSIM output files, please refer to section 14.1. 

For output of compiled data, the user can set up a specific configuration. 

Raw data output always includes all of the provided parameters. 

Existing output files of previous simulation runs of the same input file will be 

overwritten without warning. In order to save the existing files it is recommended 

to move them into another directory immediately after the 


10.1.3 Output to Database 

VISSIM also allows to output some data in a database format. Currently 

database output is possible for the following evaluations: 

► Vehicle records 

► Link evaluations 

► Paths (Dynamic Assignment) 

► Travel Times (raw data) 

► Delays (raw data) 

► Signal changes 

► Queue lengths 

► Node evaluations (raw/compiled data) 

► Pedestrian records 

For each activated evaluation type with option Database output checked, a 

special table is created in the database file. 



Furthermore, the database contains the table EvalInfo, which stores the list 

of evaluations selected for database output with the user-defined table name 

assigned to each evaluation. 

Additionally, the VISSIM Analyzer allows for saving a user-defined report to a 

database. 

10.1.3.1 System Requirements 

All SQL:1999-compatible databases are supported. Database connections 

via SQL fit for the 32 bit edition and the 64 bit edition of VISSIM and have 

proved successfully. We recommend to use the gratis MS SQL Server 2008 

Express Edition. Download the latest version from http://www.microsoft.com. 

There, browse for “SQL Server 2008 Express“ and follow the instructions. 

For a successful installation the user must be logged in with administrator 

rights. Database output tests have been performed with Microsoft 

Access and Oracle. 

10.1.3.2 Database Connection 

The database connection is configured in the Evaluations (Database) 

window which is accessed by EVALUATION – DATABASE… These properties are 

saved to the VISSIM network file (*.INP). 

● Create New Access 

Database (necessary 

only when using a new 

Microsoft Access 

database file): Provides 

a shortcut to create a 

new Microsoft 

Access database file 

*.MDB. It is also 

possible to select an 

existing database file. 

This file will then be 

overwritten in order to 

be used for VISSIM. 

Depending on the installed version of Microsoft Access, one of the 

buttons ACCESS 97, ACCESS 2007, or ACCESS 2000/XP is to be used. 


MS Access can only be applied to the 32 bit edition of VISSIM. 


For ACCESS 97 at least the Jet 3.51 OLE DB Provider must be installed on 

the computer. 

For ACCESS 2000/XP at least the Jet 4.0 OLE DB Provider must be 

installed on the computer. 

Option ACCESS 2007 is only provided, if Office 12.0 Access Database 

Engine OLE DB Provider has been installed on the PC. 

● Evaluations Database: Using the DATA LINK PROPERTIES... (see below for 

details), a database “connection string” is generated that will be used to 

create a database connection prior to the start of the simulation. A 

connection can only be established to an existing database. For Oracle 

systems also a user ID needs to be provided. 

● Confirm Overwrite Table: If checked, VISSIM prompts the user to 

confirm overwriting an existing database. 

Data Link Properties 

The Data Link Properties can be accessed by pressing the button DATA LINK 

PROPERTIES in the Evaluations (Database) window. 

[PROVIDER] List of all database providers on the computer. Select the desired provider 

(“Jet” and “Oracle” providers have been tested with VISSIM). 



[CONNECTION] The connection properties 

depend on the provider. 

Only selected properties are 

listed below: 

● Access 

provider) 

2003 (Jet 

- Database name: 

Name of the database 

file (MDB) for the 

- 

VISSIM output. 

User name: Unless a 

specific user name is 

needed use the 

default value. 

● Access 2007 (Access 

Database Engine OLE DB 

Provider) 

- Data source: Name of 

the database source 

file (*.ACCDB). 

- Storage location: 

Name of the storage 

location. 

[ADVANCED] 

& [ALL] 

● Oracle: 

- Server Name: Provides the connection to the Oracle server. 

- User name: An existing user name must be entered. 

- Password. Note: The password provided here will be saved in the 

VISSIM network file as plain text (not encrypted). 

- Allow Saving Password needs to be active. 

Further properties depend on the selected provider. Typically these 

properties can be left at their default values. 

10.1.3.3 Database Output Data 

The database output (what information is to be stored as *.MDB) is 

configured directly in the configuration window of each evaluation type. By 

default, all evaluations are stored in an ASCII text file, not in a database. 

For data configuration and activation of the database output please refer to 

the following sections: 

► Vehicle records: cf. section 11.7 

► Link evaluations: cf. section 11.11 

► Paths (Dynamic Assignment only): cf. section 11.21 


► Travel Times (raw data): cf. section 11.1 

► Delays (raw data): cf. section 11.2 

► Signal changes: cf. section 11.10 

► Queue lengths: cf. section 11.4 

► Node evaluations: cf. section 11.12 

► Pedestrian records: cf. section 7.2.3 

Section 11.24 describes the VISSIM Analyzer. 


Direct data output to a database may reduce the simulation speed. During 

the simulation you can save the output data as text file (ASCII) and import 

this file into a database once the simulation is finished. 

Import example 

Import the *.FZP file in MS Access: 

1. Use a text editor to open the *.FZP file. 

2. In the file, delete all data above the data block. 

3. Save the file, replace the original extension by *.TXT. 

4. In Access, use FILE - NEW to create an empty database. 

5. Click FILE – EXTERNAL DATA - IMPORT to import the text file. 

Make sure, that file type Text files has been selected in the Import window. 

6. Click IMPORT. 

The Text import assistent appears. 

7. Check option With separator and click NEXT. 

8. Check option Semicolon and First row contains names and click NEXT. 

9. Check option New table and click NEXT. 

10. For each column, select the appropriate data type (Double, Integer or 

Text) from the list and click NEXT. 

11. Check option No primary keys and click NEXT. 

12. Click FINISH. 



10.2 Runtime Messages 

During a VISSIM session, messages and warnings are displayed on screen 

to ease user interactions. 

10.2.1 Protocol Window 

In the protocol window, messages, error messages and warnings are listed. 

There are two ways to call the protocol window: 

► Click menu HELP – PROTOCOL WINDOW. 

► Click CTRL+SHIFT+F10. 

● Bring always to front: As soon as a new warning appears, the window 

is displayed on top. 

● CLEAR removes all entries from the list. 

To delete a single entry, mark the row and press DEL. 

● OPEN LOG FILE opens the protocol file VISSIM_MSGS.TXT in a text editor 

on screen. 

● Time: The moment in time when the message was generated. 

● Type: Type of the network object (e.g. Node) 

● ID: The ID of the network object 

● Description: The message in detail. 

If the Type and ID of a network object (e.g. nodes and links) are allocated to 

a message, then you can zoom into this network section. 

The consistency check which is automatically run prior to the start of a 

simulation of pedestrian flows returns warnings and error messages in the 

protocol window. Click one of the warnings which are listed in the protocol 

window: VISSIM will switch to the appropriate editing mode and select the 

particular element while zooming to the network position. This does not work 

as long as the simulation is running. 

The log file VISSIM_MSGS.TXT 

During each VISSIM session, messages are logged to VISSIM_MSGS.TXT. 

This log file is stored in automatically in \DOCUMENTSANDSETTINGS\ 

\LOCALSETTINGS\TEMP\VISSIM\VISSIM_MSGS.TXT. 

It contains system messages which are generated when the VISSIM 

program session is started, and - as a second data block - the individual 


Example 

Runtime Messages 

steps performed during this session as well as detailed messages and 

warnings, which were displayed during e.g. ANM import (and building the 

VISSIM network). 

... 

2008-04-16 14:30:41 System [ANM] Import started. 

2008-04-16 14:30:41 System [ANM] Import network data and routing. 

2008-04-16 14:30:41 Warning SPEED: This attribute is 0 and is set to the default 

value. ANM link 4A: 

2008-04-16 14:30:47 Warning SPEED: This attribute is 0 and is set to the default 

value. ANM link 4B: 

2008-04-16 14:30:48 Warning Multi-leg node has zone connectors attached. Dummy link 

stubs which ignore node geometry are generated. ANM node 10: 

2008-04-16 14:30:49 Warning Multi-leg node has zone connectors attached. Dummy link 

stubs which ignore node geometry are generated. ANM node 40: 

2008-04-16 14:30:50 Warning This node contains lanes that do not have any movements 

defined to or from. ANM node 20: 

2008-04-16 14:30:51 Warning This node contains lanes that do not have any movements 

defined to or from. ANM node 40: 

2008-04-16 14:30:53 Warning Position of PT stop was adjusted. ANM PT stop 10OB: 

2008-04-16 14:30:58 Warning Position of PT stop was adjusted. ANM PT stop 20OB: 

2008-04-16 14:30:59 Warning Position of PT stop was adjusted. ANM PT stop 40WA: 

2008-04-16 14:31:00 Warning Position of PT stop was adjusted. ANM PT stop 40SA: 

2008-04-16 14:31:01 System [ANM] Copy network data file D:\ANM-Dyn\Example.anm to 

D:\ANM-Dyn\Dyn.panm. 

2008-04-16 14:31:02 System [ANM] Copy routes file D:\ANM-Dyn\Example.anmRoutes to 

D:\ANM-Dyn\Dyn.panmRoutes. 

2008-04-16 14:31:02 System [ANM] Import end. 

10.2.2 Error Messages 

This section explains how to deal with errors that may occur, e.g. during a 


10.2.2.1 Fatal Error 

Fatal errors result from an unexpected program state. 

In case you encounter such an error, please follow the recommendations 

mentioned in the message to avoid data loss. 



It is not safe to continue your work with VISSIM unless you close it 

completely and restart VISSIM. If you save your network file (*.INP), do 

choose a different filename as the file might get corrupt or incomplete. 

Check whether the saved file is complete (e.g. by comparing it with a 

backup copy). If it is not complete, use a backup copy of your network file 

(by renaming the backup file *.IN0 to *.INP) once you restarted VISSIM. 

We are constantly improving VISSIM in order to avoid these errors. In order 

to do that we rely on your information once you encountered this error. 

Please contact the VISSIM hotline via the REPORT ERROR button which 

provides direct access to the VISSIM Technical Hotline form. 

Different from the hotline contact via menu HELP - INFO... or directly via 

http://www.ptv-vision.com/hotline_vissim (cf. section 15.3.2), access via the 

REPORT ERROR button automatically copies the required data including the 

error report into the form. 

10.2.2.2 Troubleshooting via VDiagGUI.exe 

If you encounter problems with VISSIM the hotline team may ask you to 

execute the program VDiagGUI.EXE in the EXE\ directory of your VISSIM 

installation. 


► Start the Windows Explorer. 

► Open the directory EXE\ of your VISSIM installation. 

► Start VDiagGUI.EXE through a double click on the file name: 

The window VDiagProGUI opens. 

► Follow the instructions of the support team and open the desired tab 

page. 


[ACTIONS] 


● START VISSIM DIAGNOSTICS: Start VISSIM in the diagnostics mode only 

on hotline team request: Left-click the button. 

The RESET functionality is described in section 3.1.3. 



[HOTLINE 

PACKAGE] 

In this tab, you can select the required files for the VISSIM support team. 

Forward the packed file to PTV AG. 

● Custom files: Select the required project data files. 

- Click ADD FILES to add another file. 

- Click REMOVE to remove a selected file from the list. 

● Diagnostics files: Activate the appropriate options. For detailed 

information on the content stored with each option call the tooltip by 

option via mouse move over the option text. 

● Save path: Enter the file name an select the appropriate format. 

● CREATE: Click this button to create the file which can be forwarded to the 

VISSIM support team. 


[VERSIONS] 


In certain cases you might be asked to check the list for a certain file. 



[LOG] 

In certain cases you might be asked to create a log file: Press the SAVE LOG 

button. 

10.2.2.3 Program Warnings (*.ERR file) 

By default, the error files *.ERR are stored in the folder where the network 

file *.INP has been stored. 

If any non fatal errors or warnings occur during a VISSIM simulation run, the 

corresponding messages are written to a file with the same name as the 

network file but with the extension *.ERR. 

In rare cases, the file VISSIM.ERR is stored in the folder of the *.INP file. 

This may have either reason: 

► You have created and edited a new file, but you have not saved it yet. 

► An error occurred when an *.INP file was read. 

After the simulation run, a message box 

appears, notifying the user of the newly 

created error file. 

SHOW calls the content of the *.ERR 

file. 



For some errors, a message box also 

appears prior to the start of the 

simulation. 

Without option Do not show this 

message, any subsequent error 

messages will be shown. If this option 

is active, all subsequent messages of 

the same kind will be suppressed. 

But still all errors will be logged to the 

error file. 

These are some of the problems/errors that VISSIM reports: 

► A routing decision that is placed too close to the start of a connector. 

► A desired speed decision that might be placed too close to the start of a 

connector. This message does not necessarily point to a problem as a 

simplified method of computing the minimum distance is used. 

► An entry link that did not generate all vehicles as defined by the coded 

input flow because of capacity problems resulting in a queue outside the 

network at the end of the defined time interval. 

► A vehicle that has been removed from the network because it had 

reached the maximum lane change waiting time (default = 60 seconds). 

► A distance too short between the beginning of a routing decision and the 

first connector causing a vehicle to leave its route because it has not 

enough time to stop beforehand. 

► The passage of more than 5 connectors at the same time by a single 

vehicle resulting in a virtual shortening of the vehicle in the visualization. 

► For signal controllers that use information on intergreen and minimum 

green times: Each violation of one of the times defined in VISSIM will be 

reported if it occurs during a simulation run. 

► Pedestrians add-on: On pedestrian areas, the number of pedestrians per 

simulation second exceeds the limit. 


11 Evaluation Types for Simulations of Vehicles 

This chapter provides all information on how to define and configure the 

individual evaluation types and what the results look like. In order to generate 

output data, the corresponding option needs to be enabled (see section 

10.1). 

The output can be produced in the following form: 

► online window representation (e.g. signal time table) 

► a text file can be written 

► a database table can be saved 

Some evaluation types support two or even all options. 

As the text files use semicolons as delimiters they can easily be imported in 

spreadsheet applications (like Microsoft Excel) in order to use them for 

further calculations or graphical representation. 

Generally, current length/speed/acceleration units settings (VIEW - OPTIONS 

- [LANGUAGE & UNITS]) are regarded for evaluation data output. 

Only parameters having the unit explicitly in the name do not regard these 

settings. 

Some of the evaluations allow for output of both, raw data and compiled 

data. 

For raw data output, usually only metric units are used. 

The user-defined configuration is not regarded for raw data output. 

Evaluations of the simulation of pedestrian flows (Travel Times, Pedestrian 

Record, Area Evaluations and Queues) are described in section 7.2. 



11.1 Travel Times 

Each section consists of a start and a destination cross section. The average 

travel time (including waiting or dwell times) is determined as the time 

required by a vehicle between crossing the first (start) and crossing the 

second (destination) cross sections. 

During a simulation run, VISSIM can evaluate average travel times 

(smoothed) if travel time measurement sections have been defined in the 

network. Via EVALUATION – WINDOWS, the travel time records can be 

displayed in a window on the desktop. They can also be stored as an output 

file if option Travel times is ticked via EVALUATION – FILES. 

Definition 

To define a travel time measurement section follow the steps outlined below: 

1. Select the Travel Time Sections mode. 

2. With a single left mouse click select the link for the travel time section to 

start. 

3. Select the desired location for the travel time start section on the 

selected link by clicking the right mouse button. The start cross section 

will be shown as a red bar with link number and coordinate being 

displayed in the status bar. 

4. If necessary, modify the screen view using the zoom commands or scroll 

bars in order to place the destination cross section. 

5. With a single left mouse click select the link for the destination cross 

section. 

6. Select the desired location for the destination of the travel time section 

within the selected link by clicking the right mouse button. The 

destination cross section will be displayed as a green bar and the Create 

Travel Time Measurement window appears. 

7. Set the properties of that section and confirm with OK. 



● No.: A unique number to 

reference this travel time 

section. It is recommended 

to use a numbering scheme 

that is implemented to the 

whole VISSIM network in 

order to easily reference 

the evaluations. 

● Name: Label or comment of 

the travel time segment. 

● From Section / To Section: 

Exact location of the travel 

time segment. 

● Vehicle Classes: Only 

vehicles of the selected 

class(es) will be measured. 

Travel Times 

● Distance between the start and end cross section as determined by the 

shortest route. 

Please make sure, that the resulting distance is sufficient when placing the 

travel time measurement cross-sections. Please note: Vehicles traversing 

both, start and end cross-section within a single time step, are not regarded 

for travel time measurements. 

If this field is blank, VISSIM could not determine a continuous link 

sequence between both cross sections. The cause may be that a 

connector is missing or that one of the cross sections was placed on the 

wrong link (e.g. opposite direction). 

If Dynamic Assignment (optional module) is activated, the shortest distance 

(in contrast to the distance with the minimum no. of links) will be used as 

the distance. However, it can only be computed if both travel time crosssections 

are located either between two nodes or within a node. 

● Visible (Screen): If active, the travel time cross sections are visible 

during the simulation (if travel times have been enabled in the global 

display settings). 

● Label: If active, the label of the travel time section (as enabled in the 

global display settings) is shown. 

● Write (to File): If active, the travel time values for this section will 

appear in the output file. 

● Smooth. Factor (applies only to the window representation of the travel 

times, not to the file): Exponential factor as how a new travel time will be 

weighted before added to the existing average travel time. 



Configuration 

In order to get the desired output format additional information is needed. 

This is to be provided within the Travel Time Measurement Configuration 

window which can be accessed by pressing the CONFIGURATION button in 

EVALUATION – FILES… once the option Travel Time is ticked. The following 

configuration data can be defined: 

● Active Travel Times: Only data for 

the selected travel time sections 

will be collected. 

● Time: The starting and finishing 

time and the time interval of the 

evaluation (defined as simulation 

seconds). 

● Aggregation method: Select here 

whether a vehicle should be 

counted to the evaluation interval 

where it crossed the start section or 

the destination section. 

● Output: Select compiled or raw 

data (ASCII format or database): 

- Compiled Data generates a 

file (*.RSZ) according to the 

times, vehicle classes etc. as 

defined in this window. 

- Raw Data generates a file (*.RSR) where simply every completed 

travel time measurement event will be logged in chronological order. 

- Database: When active, evaluation output is directed to a 

database to the specified Table Name (rather than to an ASCII text 

file). The table name may not be used for any other VISSIM 

database evaluation. In order to use the database output the 

database connection needs to be configured (cf. section 10.1.3). 

Results 

Travel times can be output to 

► a window (cf. section 10.1.1) and/or to 

► a file (cf. section 10.1.2). 

A compiled output text file (*.RSZ) contains: 






► List of all travel time sections that have been evaluated, including the 

distance for the shortest route for that section 


► Table with two columns: 

- travel times (in seconds) by section and time interval 

- no. of vehicles by section and time interval 

Example (*.RSZ file) 

Table of Travel Times 

Travel Times 

File: E:\Programme\PTV_Vision\ISSIM520\Examples\Demo\LRT-Priority.LU\lux3_10.inp 

Comment: Luxembourg, SC 3-10 

Date: Wednesday, May 13, 2009 12:26:34 PM 

VISSIM: 5.20-00 [18711M] 

No. 4071: from link 10049 at 0.6 m to link 10049 at 19.0 m, Distance 18.4 m 

No. 4072: from link 102 at 298.4 m to link 10050 at 33.8 m, Distance 106.8 m 

Time; Trav;#Veh; Trav;#Veh; 

VehC; All;; All;; 

No.:; 4071;4071; 4072;4072; 

60; 132.6; 49; 142.0; 219; 

120; 134.6; 61; 140.4; 249; 



11.2 Delay Times 

Based on travel time sections VISSIM can generate delay data for networks. 

A delay segment is based on one or more travel time sections. All vehicles 

that pass these travel time sections are captured by the delay segment, 

independently of the vehicle classes selected in these travel time sections. 

If a vehicle is detected by more than one of these travel time sections then 

it will be counted multiple times in the delay segment. 

Definition 

A delay time measurement is defined as a combination of a single or several 

travel time measurements; regardless of the selected vehicle classes, all 

vehicles concerned by these travel time measurements are also regarded for 

delay time measurement. As delay segments are based on travel times no 

additional definitions need to be done. For definition of travel time 

measurements please refer to section 11.1. 

A delay time measurement determines - compared to the ideal travel time 

(no other vehicles, no signal control) - the mean time delay calculated from 

all vehicles observed on a single or several link sections. 

Configuration 

In order to get the desired output format additional information is needed. 

This is to be provided within the Delay Segments window which ca be 

accessed by pressing the CONFIGURATION button in EVALUATION – FILES… 

once the option Delay is ticked. The following configuration data can be 

defined: 

● No. [active] (Travel Times): List of all defined delay segments with the 

active state flag x [in brackets]. 

Inactive delay measurements are not regarded for evaluation. 

Selected travel time measurements are shown in parentheses. 


Delay Times 

● Time: Enter the start time and end time and the time interval of the 

evaluation (in simulation seconds). 

● NEW creates a new delay time measurement, 

● EDIT allows for editing existing delay time 

measurements. 

- Each delay segment is to be based on 

one or more travel time measurements; 

use CTRL to select multiple 

travel time sections for this measurement. 

- For the selected delay segment, 

option active has to be (un)checked. 

● DELETE removes the selected delay time measurement from the list. 

Belonging travel time sections are not deleted. 

● Output defines the data output format: 

- Compiled Data generates a text file (*.VLZ) according to the times 

and numbers as defined in this window. 

- Raw Data generates a text file (*.VLR) where every completed 

delay measurement event will be logged in chronological order. 

- Database: When active, evaluation output is directed to a 

database to the specified Table Name (rather than to an ASCII text 

file). The table name must not be used for any other VISSIM 

database evaluations. In order to use the database output the 

database connection needs to be configured (cf. section 10.1.3). 

Results 

This is the format of a compiled output text file (*.VLZ): 






► List of all delay segments that have been evaluated 

► Table with the delay data measured for each section and time interval. 

It contains the following information: 

- Delay: Average total delay per vehicle (in seconds). The total delay is 

computed for every vehicle completing the travel time section by 

subtracting the theoretical (ideal) travel time from the real travel time. 

The theoretical travel time is the time that would be reached if there 

were no other vehicles and no signal controls or other stops in the 

network (reduced speed areas are taken into account). 



The real travel time does not include passenger stop times at PT 

stops or the time vehicles spent in real parking lots. However, the 

loss time caused by acceleration or deceleration before/after a PT 

stop remains part of the delay time. 

- Stopd: Average standstill time per vehicle (in seconds), not including 

passenger stop times at PT stops or in parking lots.. 

- Stops: Average number of stops per vehicle, not including stops at 

PT stops or in parking lots. 

- #Veh: Vehicle throughput 

- Pers: Average total delay per person (in seconds), not including 

passenger stop times at PT stops. 

- #Pers: Person throughput 

Example: Compiled data file *.VLZ 

Table of Delay 

File: E:\Programme\PTV_Vision\VISSIM520\Examples\Demo\LRT-Priority.LU\lux3_10.inp 



VISSIM: 5.20-00 [18711M] 

No. 4082: Travel time section(s) 4082 

Time; Delay; Stopd; Stops; #Veh; Pers.; #Pers; 

VehC; Train;;;;;; 

No.:; 4082; 4082; 4082; 4082; 4082; 4082; 

61; 0.1; 0.0; 0.00; 3; 0.1; 70; 

Total; 0.1; 0.0; 0.00; 3; 0.1; 70; 

Example: Raw data file *.VLR 

Table of Delay 

File: E:\Programme\PTV_Vision\VISSIM520\Examples\Demo\LRT-Priority.LU\lux3_10.inp 



VISSIM: 5.20-00* [18711M] 

Time; No.; Veh; VehTy; Delay; 

118.8; 4092; 2; 402; 6.1; 


11.3 Data Collection 

Data Collection 

Data collection offers the collection of data on single cross sections rather 

than a section or segment. 

Definition 

To define data collection points follow the steps outlined below: 

1. Select the Data collection points mode. 

2. With a single left mouse click select the link for the data collection point 

to be placed. 

3. Define the data collection point with the right mouse button. 

4. Enter a number in the appearing window and set further properties, if 

applicable. 

Click OK to confirm. 

For subsequent changes to data collection points, activate the Data 

collection point mode and right-click outside of the VISSIM network to call the 

selection list containing all data collection points with their numbers and 

names that have been defined in the network so far: Select the desired data 

collection point and click either the ZOOM button or DATA or DELETE to 

continue. 

Configuration 

In order to get the desired output data and format additional information is 

needed. This is to be provided within the Data Collection window which can 

be accessed by pressing the CONFIGURATION button in EVALUATION – FILES… 

once the option Data Collection is ticked. The following data can be defined: 



● Measurem.# (Pts.): Shows 

all defined data collection 

measurements and the 

collection points they are 

composed of. 

The list can be edited by 

using the NEW, EDIT and 

DELETE buttons. Click NEW 

to create a new data 

collection and use EDIT for 

changes to existing ones. 

While editing a measurement, 

use CTRL to select 

multiple travel time sections 

for this measurement. 

Alternatively, either AUTO (ALL) or AUTO (GROUPS) may be used to define data 

collection measurements: 

● AUTO (ALL) generates one measurement for each individual data 

collection point (even if it is included in another data collection 

measurement already). 

● AUTO (GROUPS) automatically combines data collection points which are 

situated within 3m on the same link/connector into one data collection 

measurement. This option is useful when data on multi-lane links should 

be collected for the complete link and not for individual lanes. 

If there are no multi-lane links contained in the network, the result is 

identical to that of AUTO (ALL). 

● Time: The starting and finishing time and the time interval of the 

evaluation (defined as simulation seconds). 

● Output defines the output format of the text file: 

- Compiled Data generates a file (*.MES) according to the times and 

numbers as defined in this window and to the CONFIGURATION 

parameter settings, 

- Raw Data generates a file (*.MER) where simply every data 

collection event will be logged in chronological order (all parameters). 

The file header of this output file also contains the srat time of the 

simulation, if the start date has been set in the simulation parameters. 

● CONFIGURATION... opens the Data Collection - Configuration window that 

allows to select the data and output format of the data collection 

measurements. These settings are only regarded for compiled data. 



The selected data is displayed within the list box to the left (Layout of 

columns). 

- Using the UP and DOWN buttons allow to change the sequence of the 

selected data as it will appear within the compiled output file. 

- The contents of the list box can be changed using the and 

buttons. 

- Depending on the Parameter, both the Function and Vehicle Class 

fields may offer additional specification for the chosen parameter. 

- The data collection can also be restricted to certain Vehicle Classes. 

The configuration will be saved to an external file (*.QMK). 

Results 

This is the format of a compiled output text file (*.MES): 






► List of all cross section measurements that have been evaluated 


► Table with the measured data. 

The output format is determined by the settings in the Data Collection - 

Configuration window. 

Example: Compiled data file *.MES 

Data Collection (Compiled Data) 

File: C:\Program Files\PTV_Vision\VISSIM530\Examples\Demo\LRT.LU\lux3_10.inp 


Date: Dienstag, 12. April 2011 13:18:39 

VISSIM: 5.30-05* [28342] 



Measurement 1031: Data Collection Point(s) 10311, 10312 

Measurement 1032: Data Collection Point(s) 10321 

Measurement 1042: Data Collection Point(s) 10421, 10422 

Measurement 91032: Data Collection Point(s) 910321 

Measur.: Data Collection Number 

from: Start time of the Aggregation interval 

to: End time of the Aggregation interval 

Number Veh: Number of Vehicles 

Occup. Rate: Occupancy rate [%] 

Accel.: Acceleration [m/s²] 

Distance: Total Distance Traveled in the Network [m] 

Speed: Speed [km/h] 

Length: Vehicle Length [m] 

Persons: Number of People 

QueueDel.Tm.: Total Queue delay time [s] 

Measur.;from;to;Number Veh;Occup. Rate;Accel.;Distance;Speed;Length;Persons;QueueDel.Tm. 

; ; ;;;Maximum;Maximum;Maximum;Maximum;Maximum;Maximum 

; ; ;Car;Car;Car;Car;Car;Car;Car;Car 

1031;0;60;0;0.0;0.0;0.0;0.0;0.0;0;0.0 

1032;0;60;0;0.0;0.0;0.0;0.0;0.0;0;0.0 

1042;0;60;7;6.0;3.3;138.7;44.7;4.5;1;24.8 

91032;0;60;0;0.0;0.0;0.0;0.0;0.0;0;0.0 

1031;60;120;3;1.3;0.2;284.0;53.9;4.1;1;55.6 

1032;60;120;0;0.0;0.0;0.0;0.0;0.0;0;0.0 

1042;60;120;4;2.7;3.3;138.7;25.0;4.5;1;48.6 

91032;60;120;0;0.0;0.0;0.0;0.0;0.0;0;0.0 

Example: Raw data file *.MER 

Data Collection (Raw Data) 

File: C:\Program Files\PTV_Vision\VISSIM530\Examples\Demo\LRT.LU\lux3_10.inp 


Date: Dienstag, 12. April 2011 13:18:39 

VISSIM: 5.30-05* [28342] 

Data Collection Point 3131: Link 46 Lane 1 at 179.168 m, Length 0.000 m. 





... 

Data C.P. t(enter) t(leave) VehNo Type Line v[m/s] a[m/s²] Occ Pers tQueue VehLength[m] 

6311 16.95 -1.00 10 17 0 7.9 -2.83 0.05 1 0.0 4.55 

6311 -1.00 17.60 10 17 0 6.0 -2.83 0.00 1 0.0 4.55 

6312 19.90 -1.00 15 11 0 5.3 -2.68 0.10 1 0.0 4.11 

6321 20.03 -1.00 14 14 0 13.5 -0.99 0.07 1 0.0 4.11 

6321 -1.00 20.34 14 14 0 13.2 -0.99 0.04 1 0.0 4.11 

… 





t(enter) Time when the vehicle´s front has passed the cross-section. 

Entry -1 indicates, that this happened before the current time 

step 

t(leave) Time when the vehicle´s end has passed the cross-section. 

Entry -1 indicates, that this has not happened yet. 

VehNo Internal number of the vehicle 

Type Vehicle type (e.g. 100 = car) 

Line PT line 

v Speed (in m/s) 

a Acceleration (in [m/s²]) 

Occ Occupancy: Time (in s) the vehicle has spent on the 

decision point in this simulation second 

Pers Number of persons in the vehicle 

tQueue Total time (in s) the vehicle has spent in congestion 

VehLength Vehicle length (in [m]) 



11.4 Queue Counters and Vehicle Stops 

The queue counter feature in VISSIM provides as output the 

► average queue length, 

► maximum queue length and 

► number of vehicle stops within the queue. 

Queues are counted from the location of the queue counter on the link or 

connector upstream to the final vehicle that is in queue condition. If the 

queue backs up onto multiple different approaches the queue counter will 

record information for all of them and report the longest as the maximum 

queue length. 

The back of the queue is monitored until there is not a single vehicle left over 

on the approach that still meets the queue condition, though other vehicles 

between the initial start and the current end of the queue do no longer meet 

the queue condition (having a speed > End speed). 

Queue length is output in units of length not in number of cars. 

The queue is still monitored as long as there is a “queue remainder” - even 

if the first vehicles directly upstream of the queue counter are not in queue 

condition any more. 

The maximum queue length reaches to the next queue counter located at 

an upstream position. Queue counters created automatically for node 

evalulations are not regarded. 

Definition 

Queue counters can be placed at any position within a link/connector. The 

most suitable position is at the stop lines of a signalized intersection. 

To define queue counters follow the steps outlined below: 

1. Select the Queue Counters mode. 

2. With a single left mouse click select on the link the location of the queue 

counter. 

3. Define the location of the queue counter within the link by clicking the 

right mouse button at the desired location. Queues will be measured 

upstream from this location. 

4. Enter a number in the appearing window and choose OK. 

Configuration 


is to be provided within the Queue Measurement - Configuration window 

(see below) which is accessible by pressing the CONFIGURATION button in 

EVALUATION – FILES… once the option Queue Length is active. 

The following data can be defined: 


● Queue Definition 

defines the queue 

condition: A vehicle is 

in queue condition if 

its speed 

- is less than the 

Begin speed and 

- has not exceeded 

the End speed 

yet. 

Queue Counters and Vehicle Stops 

- Max. Headway defines the maximum distance between two vehicles 

so that the queue is not disrupted. 

- Max. Length defines the max. length of the queue - even if the actual 

queue is longer. This parameter is helpful if longer queues are 

detected in a network of subsequent junctions but the queues are to 

be evaluated for each junction separately. 

● Time: The starting and finishing time and the time Interval of the 

evaluation (defined as simulation seconds). Definition of the aggregation 

interval (in s): If value 600 is entered, the *.STZ file will contain data 

blocks of 600s each, starting from the value entered for from. 

● Analyzer Sample Interval: Enter the number of simulation seconds (e.g. 0 

or 10) for evaluations via Analyzer Report, cf. section 11.24. 





configured (see section 10.1.3). 

The simulation performance depends on the value set for Max. Length. If 

there is a big queue building up in the network, and the Max. Length parameter 

is set to a greater value (e.g. 4 km), the simulation speed will decrease. 

Results 

This is the format of an output text file (*.STZ): 






► List of all queue counters that have been evaluated 



► Table with the queue data measured for each counter and time interval. 

It contains the following information for each queue counter (3 columns) 

and each time interval (one line): 

Parameter Definition Column 

Average 

queue length 

Maximum 

queue length 

Number of 

stops 

Example (*.STZ file) 

Queue Length Record 

Calculation method: The current queue length is 

measured upstream every time step. From 

these values the arithmetical average is 

computed for every time interval. 

Calculation method: The current queue length is 

measured upstream every time step. From 

these values the maximum is computed for 

every time interval. 

Number of stops within queue: Total number of 

events when a vehicle enters the queue 

condition. 

File: e:\programfiles\PTV_Vision\VISSIM520\Examples\example.inp 


Date: Wednesday, May 2, 2009, 5:31:39 pm 


Queue Counter 520: Link 247 At 66.200 ft 




Avg.: average queue length [ft] within time interval 

Max.: maximum queue length [ft] within time interval 

Stop: number of stops within queue 

Time; Avg.; max.;Stop; Avg.; max.;Stop; Avg.; max.;Stop; Avg.; max.;Stop; 

No.:; 520; 520; 520; 531; 531; 531; 532; 532; 532; 534; 534; 534; 

600; 12; 32; 15; 10; 73; 72; 12; 73; 51; 2; 13; 6; 

1200; 12; 52; 19; 5; 37; 58; 7; 49; 34; 2; 20; 7; 

1800; 17; 45; 12; 4; 36; 43; 7; 73; 36; 1; 7; 2; 


Avg 

max 

Stop

11.5 Green Time Distribution 

Green Time Distribution 

VISSIM records the cumulative number of green and red durations as well as 

the mean and average green and red time for each signal group (phase), if 

option Distribution of green times is checked via EVALUATION – FILES. This 

information is useful for evaluations of vehicle-actuated signal controls. 

Definition 


Configuration 

No additional configuration required. 

Filter 

Based on the Period in [Simulation seconds] specified 

via SIMULATION - PARAMETERS, the start of the 

protocol can be shifted and the duration can be 

reduced for recording. 

Results 

This is the format of an output text file (*.LZV): 






► Duration of the evaluation based on filter & simulation parameters (Time) 

► For every signal control a block for the average green times 

► For every signal control a block for the green and red times. The 

- columns represent the individual signal groups (phases) j, 

- rows represent the green and red time durations (up to 120 s) i. 

Every table entry ij indicates how often the signal group (phase) j had a 

green (red) time of i seconds. 

► For every signal control and every signal group (phas): Separate data 

blocks for the distribution of the green and the red times with their 

frequency and mean vaue and a simple graphical visualization. 



For graphical display of green time distributions the import of the *.LZV file in 

a spreadsheet program (e.g. Microsoft Excel) is recommended, especially 

the tabular green times data block. 

Example (*.LZV file) 

Distribution of Signal Times 

File: e:\programfiles\vissim520\example\projekt_1\example.inp 




Time: 0.0 - 300.0 

SC 1, Average Green Times: 

Signal group; t; 

1; 13.7; 

2; 48.4; 

3; 14.2; 

4; 21.5; 

5; 12.9; 

6; 48.1; 

8; 40.0; 

SC 1, Green Times: 

t|SG; 1; 2; 3; 4; 5; 6; 8; 

... 

11; 0; 0; 0; 0; 1; 0; 0; 

12; 0; 0; 1; 0; 2; 0; 0; 

13; 0; 0; 4; 0; 3; 0; 0; 

14; 0; 0; 1; 0; 19; 0; 0; 

... 

SC 1, Red Times: 

t|SG; 1; 2; 3; 4; 5; 6; 8; 

... 

61; 0; 17; 0; 0; 0; 0; 1; 

62; 0; 1; 0; 0; 1; 0; 1; 

63; 0; 1; 0; 0; 0; 1; 0; 

64; 0; 0; 0; 0; 0; 1; 0; 

... 

SC 1, Signal group 1, Green Times: (Mean: 13.7) 

7 3 *** 

8 20 ******************** 

27 10 ********** 

SC 1, Signal group 1, Red Times: (Mean: 88.8) 

21 1 * 

28 1 * 

37 1 * 

38 1 * 

45 1 * 

48 5 ***** 

52 1 * 


86 1 * 

89 1 * 

90 1 * 

91 1 * 

106 1 * 

108 11 *********** 

... 

Green Time Distribution 



11.6 Vehicle Information 

During a simulation run vehicle information is available in a vehicle window 

by double-clicking on any vehicle. The information shown can be configured 

by the user. 

Vehicle information can also be saved to an output file using the Vehicle 

Record (cf. section 11.7 for Parameters). 

Definition 


Configuration 

In order to display the desired vehicle information additional configuration is 

needed. This is to be provided within the Vehicle Information Configuration 

window which is accessible by pressing the VEHICLE INFORMATION... button in 

EVALUATION – WINDOWS… 

The Selected parameters 

are displayed 

within the list box to the 

left. Use UP and DOWN 

to change the sequence 

of the selected 

data. Additional parameters 

can be inserted 

and others can be 

removed by clicking on 

the corresponding buttons 

and . 

The configuration will 

be saved to an external 

file (*.FZI). 

Results 

Double-clicking on a vehicle during a simulation 

run causes the following: 

► the selected vehicle is indicated by a red bar 

► the vehicle information window appears 

Additionally, if the display mode is set to 3D, the 

viewing position will be changed as from the 

driver’s position. 


11.7 Vehicle Record 

Vehicle Record 

Similar to the display of vehicle information in a window any combination of 

vehicle parameters can be saved to an output file. The evaluation can be 

limited to a user-defined time interval as well as to selected vehicles. 

Definition 


Configuration 


is to be provided within the Vehicle Record - Configuration window which can 

be accessed by pressing the CONFIGURATION button in EVALUATION – FILES… 

once the option Vehicle Record is active. The Configuration window allows 

for definition of any combination of the vehicle parameters. If Database 

output is not active, each layout line results in a column within the output file 

(*.FZP). 

The configuration settings will be saved to an external file (*.FZK). 

● The Selected parameters 

are displayed 

in the list 

box to the left. Use 

the UP and DOWN 

buttons to change 

the sequence of 

the selected data. 


can be 

inserted and removed 

by clicking 

the corresponding 

buttons and . 

For the list of parameters provided for selection and a bief description, 

please see below. 

Neither scheduled stops at public transport stops nor stops in parking lots 

are regarded for Number of Stops or Delay times. 

Please note that some parameters will only report correct results if the 

corresponding optional module (such as Dynamic Assignment, Cold 

Emission etc.) is installed. 



● Including parked vehicles (Dynamic Assignment only): Includes 

vehicles that are contained in a parking lot in the evaluation output as 

well. 





configured (see section 10.1.3). 

Filter 

Once the vehicle record parameters are selected, a filter may be applied to 

capture specific vehicles within the simulation. This can be accessed by 

pressing the FILTER button in EVALUATION – FILES… once the option Vehicle 

Record is active. 

In addition to the selection of vehicle classes, also a time interval for the 

evaluation as well as the resolution of recording are to be defined. If an 

integer > 1 is entered for Resolution, only one time step will be logged for the 

user-defined number of time steps. 

If the evaluation should only be done for individual vehicles, their numbers 

are to be added or removed via the buttons, if option Individual Vehicle is 

active. 

By default, all vehicle classes are recorded within the simulation period. 

The filter information is stored in a filter configuration file (*.FIL). 



To calculate the total values for evaluations like Delay and Travel Time for 

the network it is possible to collect data for all vehicles and filter it to get the 

maximum values before the vehicle leaves the network. It is also necessary 

to collect the values from the vehicles remaining in the network at the end 

of the simulation. 

There is one evaluation called Total Time that returns the total time the 

vehicle spent in the network. This value is saved to file only at the last 

second before the vehicle leaves the network. This is also the time step 

that the delay time for that vehicle should be collected. 

For the vehicles still in the network at the end of the simulation their total 

time in the network must be calculated using their start times. 

Results 

The vehicle protocol file *.FZP consists of the following: 








The vehicle record file can contain any of the parameters listed below. The 

table also includes the abbreviations that will be used within the vehicle 

record file. Please note that some parameters will only report correct results 

if the corresponding optional module (such as Dynamic Assignment, 

Emission etc.) is installed. 

Generally, current (short/long)distance/speed/acceleration units set via 

VIEW - OPTIONS - [LANGUAGE &UNITS] are regarded for evaluation data output. 

This does not apply to world co-ordinates which are always recorded in [m]. 

Please note: The units of those parameters with the particular unit 

mentioned in the column header abbreviation will not change. 


Acceleration Acceleration during the simulation 

step 

Delay Time Difference from optimal (ideal 

(theoretical)) drive time (in s) 

Desired Direction Vehicle Info only: Desired Direction 

/ Next Link / Route End Coordinate 

Desired Lane Vehicle Record only: Desired Lane 

(by Direction decision) 


a 

TQDelay 

DesLn



Desired Speed Desired Speed vDes 

Desired Speed 

[m/s] 

Desired Speed [m/s] vDesMS 

Destination Lane Destination lane number of current 

lane change 

Destination 

Parking Lot 

Number of the Destination Parking 

Lot 


DLn 

DPL 

Dwell Time Dwell Time [s] (for Stop signs) DwlTm 

Emissions 

(Evaporation) HC 

Emissions 

Benzene 

Only with Emissions add-on: 

Emissions (Evaporation) 

Hydrocarbon in the current 

simulation step 


Benzene emissions in the current 


Emissions CO Only with Emissions add-on: 

Carbon Monoxide emissions in 

current simulation step 

Emissions CO2 Only with Emissions add-on: 

Carbon Dioxide emissions in the 


Emissions HC Only with Emissions add-on: 

Hydrocarbon emissions in current 


Emissions NMHC Only with Emissions add-on: 

Non-methane Hydrocarbon 

Emissions in the current simulation 

step 

Emissions NMOG Only with Emissions add-on: 

Non-methane organic gas 

emissions in the current simulation 

step 

Emissions NOx Only with Emissions add-on: 

Nitrogen Oxide emissions in 


Emissions 

Particulates 


Particulate Emissions in current 


HC_evap 

Bnzn 

CO 

CO2 

HC 

NMHC 

NMOG 

NOx 

Particulate



Emissions SO2 Only with Emissions add-on: 

Sulfur Dioxide Emissions [mg/s] in 

the current simulation step 

Emissions Soot Only with Emissions add-on: 

Soot emissions in current 


Following 

Distance 

Following distance to the relevant 

leading vehicle before the 


Fuel Consumption Fuel consumption [mg/s] in the 


Fuel Consumption 

[l/100km] 

Fuel consumption [l/100 km] in the 


SO2 

Soot 


Dx 

Fuel 

Gradient [%] Gradient [%] of the current link Grad 

Headway Distance to the next (not necessarily 

relevant) vehicle downstream 

Interaction State Short description of the state in the 

interaction procedure which caused 

the acceleration/deceleration of the 

vehicle in the recent time step; cf. 

also section 5.4.1. 

For a complete list of possible 

states, please see below. 

Fuel100km 

Head 

IntacP 

Lane Change Direction of current lane change LCh 

Lane Number Number of the active lane Lane 

Lateral Position Lateral position relative to middle of 

lane (0.5) at the end of the 


Leading Vehicle Number of the relevant leading 

vehicle that determines the 

following behavior 

y 

lVeh 

Length Length Length 

Link Coordinate Link Coordinate [m] at the end of 

the simulation step 

Link Cost Cumulated Cost Cost 

Link Number Number of the Active Link Link 

Number of Stops Total number of all occasions 

where the vehicle reaches stand- 

x 

Stops



still (speed = 0) except PT dwell 

stops and stops in parking lots 

Occupancy Number of persons/passengers in 

the vehicle 

#Pers 

Origin Parking Lot Number of the Origin Parking Lot OPL 

Power Power [kW] Power 

Preceding Vehicle Number of the next (not necessarily 

relevant) vehicle downstream 

PT: Alighting 

Passengers 

PT: Average Wait 

Time 

PT: Boarding 

Passengers 

PT: Course 

Number 

PT: Current Dwell 

Time 

Number of passengers alighting at 

current stop 

Average Wait Time [s] for a 

boarder at the current stop 

Number of boarding passengers at 

current stop 

LVeh 

StpAlt 

StpWaT 

StpBd 

Number of the course Course 

Dwell Time [s] at current stop (incl. 

slack time) 

PT: Lateness Lateness [s] at the exit from the 

current stop (>0 = late) 

StpDwl 

StpLtns 

PT: Line Number Number of the line Line 

PT: Passenger 

Service Time 

PT: Total Dwell 

Time 

PT: PT stop 

number 

PT: Waiting 

Passengers 

Queue 

Encounters 

Passenger Service Time [s] at 

current stop 

The sum of all the PT stops dwell 

times [s] 

Number of the current PT stop Stp 

Number of passengers waiting at 

current stop 

StpSvcT 

SStpsDwlT 

StpWP 

Total number of Queue Encounters QEnc 

Queue Flag Flag: is vehicle in queue? 

+ = yes, - = no 

Queue 

Queue Time Total Queue Time Thus Far [s] QTm 

Route Vehicle Record only: Route 

number 

Route 

Routing decision Vehicle Record only: Routing RoutDec 




Routing decision 

& Route 

Routing 

Sequence 

decision number 

Vehicle Info only: Routing decision 

number & Route number 

Vehicle Info only: Links, 

Connectors, possibly Parking Lots 

and PT Stops 

Safety Distance Desired safety distance during the 


Simulation Time Vehicle Record only: Simulation 

Time [s] 

Simulation Time 

of Day 

Vehicle Record only: Simulation 

Time as Time of Day [hh:mm:ss] 

Speed Speed at the end of the simulation 

step 

Speed [m/s] Speed [m/s] at the end of the 


Speed Difference Speed relative to the relevant 

leading vehicle before the 

simulation step (>0 = faster) 

Speed Difference 

[m/s] 

Speed relative to the relevant 

leading vehicle [m/s] before the 

simulation step (>0 = faster) 


abx 

t 

ToD 

v 

vMS 

Dv 

DvMS 

Start Time Start Time [Simulation Second] STim 

Target Link Vehicle Record only: Target Link 

(Next Link on the Route) 

Theoretical Speed Theoretical Speed Without 

Obstructions 

Theoretical Speed 

[m/s] 

Total Distance 

Traveled 

Total Time in 

Network 

Trip Chain: 

Activity 

Trip Chain: 

Departure Time 

Theoretical Speed [m/s] Without 

Obstructions 

Total Distance Traveled in the 

Network in [m] 

TLnk 

vTheo 

vTheoMS 

DistX 

Total Time in Network [s] TTot 

Vehicle Info only: Number of 

Activity 

Vehicle Info only: Departure Time 

[simulation second] from Parking 

Lot



Trip Chain: 

Destination Zone 

Trip Chain: 

Minimum Duration 

Trip Chain: 

Parking Lot 

Number 

Vehicle Info only: Number of the 

Destination Zone 

Vehicle Info only: Minimum 

Duration of the Activity 

Vehicle Info only: Number of the 

Parking Lot 

Vehicle Number Vehicle Record only: Number of 

Vehicle 

VehNr 

Vehicle Type Number of the Vehicle Type Type 

Vehicle Type 

Name 

Name of the Vehicle Type VehTypeName 

Weight Weight [mt] (metric tons) Weight 

World Coordinate 

Front X 


Front Y 


Front Z 


Rear X 


Rear Y 


Rear Z 

Vehicle Record only: World 

Coordinate x (Vehicle front end at 

the end of the simulation step) 


Coordinate y (Vehicle front end at 



Coordinate z (Vehicle front end at 



coordinate x (Vehicle rear end at 

the end of the time step) 


coordinate y (Vehicle rear end at 



coordinate z (Vehicle rear end at 


WorldX 

WorldY 

WorldZ 

RWorldX 

RWorldY 

RWorldZ 


List of interaction states 

Status Description 


FREE The vehicle is not affected by any relevant preceding 

vehicle; it tries to stick to the desired speed 

Cf. section 5.4.1: "Free driving“ 

FOLLOW The vehicle tries to follow the preceding vehicle at the 

preceding vehicle’s speed 

Cf. section 5.4.1: "Following" 

BRAKEBX Braking for the desired safety distance (before reaching 

the safety distance range) 

Cf. section 5.4.1: "Approaching" 

BRAKEAX Braking for the desired safety distance (from within the 

safety distance) 

Cf. section 5.4.1: "Braking" 

CLOSEUP Closing up to a standing preceding vehicle or an obstacle 

(signal head, stop sign, priority rule, conflict area...) 

BRAKEZX Target deceleration aiming at an emergency stop position 

(for a lane change) or at the start of a reduced speed area 

BRAKELC Slight deceleration for a lane change when waiting for a 

gap in the upstream flow on the adjacent lane 

BRAKECOOP Cooperative braking in favor of another vehicle that 

intends to change to another lane (set via parameter 

Maximum deceleration for cooperative braking) 

PELOPS Acceleration/deceleration according to an external 

DriverModel DLL 

SLEEP Parameter Temporary lack of attention is just active at 

that moment, neither acceleration nor deceleration is 

recorded (except for emergency braking) 

PASS Acceleration/deceleration to reach the permitted speed 

(due to the lateral distance) for overtaking another vehicle 

which is either on the same lane or on the adjacent lane 



Example *.FZP file 

The following extract shows the vehicle record of vehicles of a selected type: 






t: Simulation Time [s] 

VehNr: Number of the Vehicle 

v: Speed [mph] at the end of the simulation step 

a: Acceleration [ft/s²] during the simulation step 

t; VehNr; v; a; 

1.3; 3; 25.72; 1.19; 

1.4; 3; 25.87; 2.14; 

1.5; 3; 26.06; 2.90; 

1.6; 3; 26.30; 3.55; 

1.7; 3; 26.59; 4.21; 

1.8; 3; 26.92; 4.86; 

1.9; 3; 27.28; 5.23; 

2.0; 3; 27.60; 4.70; 

2.1; 3; 27.89; 4.23; 

2.2; 3; 28.15; 3.81; 

2.3; 3; 28.38; 3.43; 

2.4; 3; 28.59; 3.09; 

2.5; 3; 28.78; 2.78; 

2.6; 4; 18.59; 1.44; 

2.6; 3; 28.95; 2.50; 

2.7; 4; 18.77; 2.58; 

2.7; 3; 29.11; 2.25; 

2.8; 4; 19.00; 3.49; 

2.8; 3; 29.24; 2.02; 

2.9; 4; 19.29; 4.22; 

2.9; 3; 29.37; 1.82; 

3.0; 4; 19.62; 4.87; 

3.0; 3; 29.48; 1.64; 

3.1; 4; 20.00; 5.53; 

3.1; 3; 29.58; 1.48; 

3.2; 4; 20.42; 6.19; 

3.2; 3; 29.67; 1.33; 

3.3; 4; 20.89; 6.84; 

3.3; 3; 29.75; 1.20; 

3.4; 4; 21.36; 6.88; 

... 


11.8 Dynamic Signal Timing Plan 

Dynamic Signal Timing Plan 

The Dynamic signal timing plan (signal times table) offers a graphical display 

of the actual signal setting and detector occupancy. It displays green, amber 

and red times graphically with a horizontal time axis. 

Definition 


Configuration 

To create or edit a signal times table configuration, follow the steps outlined 

below: 

1. Select SIGNAL CONTROL - EDIT CONTROLLERS... 

2. Select the controller to be edited from the list of all coded signal 

controllers. 

3. In the [SIGTIMTBLCFG] tab page, the data can be edited. 

Add line To add a new line to the current Layout of lines table, a new entry has to be 

defined as follows: 

► Left-click the selected value type in the Type (Category) list. 

► Specific data (e.g. SG No.) have to be selected from the neighbouring 

list, if applicable. 

► Add this combination to the current Layout of lines on top of the currently 

marked entry via 

- clicking the button or 

- clicking one of the selected Type (Category) entries twice. 



Delete line To remove a line from the current Layout of lines table: 

Save 

layout 

Read 

layout 

Select line and 

► press DEL or 

► right-click (calls the context menu) and press DELETE then, or 

► left-click the button. 

The configuration file (*.SZP) contains the currently specified Layout of lines. 

When the Signal control window is closed via OK, the layout file is saved 

automatically (with the specified file name) to the folder, where the currently 

used VISSIM network file (*.INP) is stored. It can then be reused for other 

signal controls or different projects. 

To create a new configuration file, a new file name has to be entered for 

configuration file. The VISSIM network file (*.INP) always refers to the 

recently saved configuration file which is automatically opened by default if 

both, the *.INP file and the *.SZP file are stored in the same folder. 

To use an existing configuration file, press and select an existing file. 

When prompted, choose YES, in order for the configuration file to be read. 

Caution: The previous configuration will be overwritten with the new layout 

configuration. 

With external signal control programs, the dynamic signal timing plan can 

also be used to display other information such as the status of stages etc. 

Please refer to the documentation of the individual control program for details 

on the display of this additional data. 

Results 

The signal times are 

shown in one separate 

window for each signal 

control. These windows 

can be activated during a 


The colors indicate the 

current state of the signal 

control. The current 

simulation time step is on 

the right. 

If detectors are shown in the signal times table, the following colors indicate 

the detector occupancy conditions: 

► Change from empty (black line) to light blue: A vehicle passes the 

detector within one time step resulting in an impulse increase and 

decrease within one simulation second. 

► Change from dark blue to light blue: A vehicle leaves the detector and a 

new vehicle is detected within the same time step resulting in an impulse 

decrease and increase within the same simulation second. 


Dynamic Signal Timing Plan 

► Multiple seconds of light blue: multiple events similar to the color change 

black to light blue. 

► Dark blue: A vehicle is detected at the end of the time step. Therefore, a 

change from empty (black) to dark blue represents an arriving vehicle 

that does not leave the detector within the same simulation second; a 

longer dark blue bar represents a vehicle waiting on top of the detector. 

This corresponds to the ‘|’ symbol in the Signal/Detector record. 

Measurement of Time Spans: VISSIM provides a ruler to measure the span 

between two times (e.g. the time between a particular detector call and the 

start of the corresponding green phase). While in single step mode, click with 

the left mouse button in the window, keep the button pressed and move the 

mouse. VISSIM then displays the time span between the current mouse 

position and position where the left button was pressed. 

The width of an SC time step is 4 pixel in case of one SC time step per simulation 

second. In case of two SC time steps per simulation second, the width 

is reduced to just 2 pixel. In case of three or more time steps it will be just 

one pixel. The cycle second is viewed every 10 simulation seconds, even if 

the SC runs with more than one time steps per second. Scaling bars are 

viewed every 5 seconds. If the control *.DLL (or *.EXE) contains the same simulation 

second multiple times, only the first one is used for axis labelling. 

Instead of only 500 time steps at most as known from previous versions, now 

up to 5,000 control time steps are viewed. 



11.9 Signal Control / Detector Record 

Title 

per column 

The SC/Detector record is user-definable record of signal status, detector 

actuations and internal parameters and variables for every signal controller 

with external control logic. This record can be generated for simulation as 

well as for test runs and provides a platform to contain all important 

parameters and variable values. The SC/Detector record can be displayed in 

a window on the desktop and/or stored in an output data file (*.LDP). 

For output to file, please click menu EVALUATION – FILES - [SIGNAL CONTROL] tab 

and check option Signal Control / Detector Record. 

Definition 


Configuration 

To create or edit a configuration of the SC/Detector Record follow the steps 

outlined below: 

1. Select SIGNAL CONTROL - EDIT CONTROLLERS... 

2. Select the controller to be edited from the list of all coded SC. 

3. In the [LDP CONFIG] tab page, data can be edited. 

In the Layout of columns list, a user-definable Title can be specified for the 

selected entry, which will be used instead of the preset VISSIM column 

header in the record file. 

Short title: Tick this option to save space within the header (especially for 

window output). Then for default headers abbreviated column headers are 

used. 


Add 

column 

Delete 

column 

Save 

layout 

Read 

layout 

Recording 

file 

Signal Control / Detector Record 

To add a new column to the current Layout of columns table, a new entry has 

to be defined as follows: 

► Left-click the selected value type in the Type (Category) list. 

► Specific data (e.g. SG No.) have to be selected from the neighbouring 

list, if applicable. 

► Add this combination to the current Layout of columns on top of the 

currently marked entry via 

- clicking the button or 

- clicking one of the selected Type (Category) entries twice. 

To remove an entry from the current Layout of columns table: 

Select line and 

► press DEL or 

► right-click (calls the context menu) and press DELETE then, or 

► left-click the button. 

The configuration file (*.KFG) contains the currently specified Layout of 

columns. When the Signal control window is closed via OK, the layout file is 

saved automatically (with the specified file name) to the folder, where the 

currently used VISSIM network file (*.INP) is stored. It can then be reused for 

other signal controls or different projects. 

To create a new configuration file, a new file name has to be entered for 

configuration file. The VISSIM network file (*.INP) always refers to the 

recently saved configuration file which is automatically opened by default if 

both, the *.INP file and the *.KFG file are stored in the same folder. 

To use an existing configuration file, press and select an existing file. 

When prompted, choose YES, in order for the configuration file to be read. 

Caution: The previous configuration will be overwritten with the new layout 

configuration. 

If option SC/Det. record is checked via EVALUATION - FILES…, the signal/detector 

protocol file is saved to the specified file. 

Results 

The SC/Detector Record may be viewed in a window during a simulation/test 

run and/or written to an output file (*.LDP) (cf. sections 10.1.1 and 10.1.2 

respectively). 

The data types that can be logged in the SC/Detector record depend on the 

signal controller used and can be found in its user manual. 

The SC/Detector record has a tabular layout with a row for each simulation 

second and a column for each traced parameter or variable. 

The SC/Detector Record can display up to 1000 parameters with a maximum 

of 3000 characters per row. 



Example (*.LDP file) 

► File title with date and time of the evaluation 

► Simulation comment 

► SC No., SC files, Program No., Simulation or Test run 


The current values are saved after the the control logics has finished: 

SC/Detector record [2009-07-04 15:10:25] 

Manual Example 

SC 7; Program file: vap215.dll; Import files: l07_d_m0.vap, l07_d.pua; Program No. 1; 

Simulation run 

SSSSSSSSS 

iiiiiiiii 

ggggggggg 

......... 

DDDDDDDDD SSSS 

S CiiiiiiiiiSSSSSStttt 

i ysssssssssttttttaaaa 

m cpppppppppaaaaaatttt 

u lllllllllltttttteeee 

l eaaaaaaaaaeeeeee 

. yyyyyyyyy DDDD 

s s DDDDDDEEEE 

e eSSSSSSSSSEEEEEETTTT 

c cGGGGGGGGGTTTTTT 

o o 5555 

n n 2222551133331122 

d d1231357122312341919 

1.0 1.0III...I............ 

2.0 2.0III...I............ 

3.0 3.0III...I............ 

4.0 4.0III...I............ 

5.0 5.0III...I............ 

6.0 6.0///...I............ 

7.0 7.0///...I............ 

8.0 8.0///...I............ 

9.0 9.0......I............ 

10.0 10.0...IIII............ 

11.0 11.0...IIII............ 

12.0 12.0...IIII............ 

13.0 13.0...IIII............ 

14.0 14.0...IIII............ 

15.0 15.0...IIII............ 

16.0 16.0...IIII............ 

17.0 17.0...IIII............ 

18.0 18.0...IIII............ 

19.0 19.0...IIII............ 

20.0 20.0...IIII............ 

21.0 21.0...IIII............ 

22.0 22.0...IIII............ 

23.0 23.0...IIII............ 


24.0 24.0...IIII............ 

25.0 25.0....III............ 

26.0 26.0....III............ 

27.0 27.0....III............ 

28.0 28.0....III..|......... 

29.0 29.0I...III............ 

30.0 30.0I...III..+|........ 

31.0 31.0I...III...|........ 

32.0 32.0I...III..++........ 

33.0 33.0I...III............ 

34.0 34.0I...III...|........ 

35.0 35.0I...III............ 

36.0 36.0I...III............ 

37.0 37.0/...III............ 

38.0 38.0/....II....|....... 

39.0 39.0/....II............ 

40.0 40.0.....II............ 

41.0 41.0...I.II............ 

42.0 42.0...I.II.....|...... 

43.0 43.0...I..I.....+...... 

44.0 44.0...I..I............ 

45.0 45.0...I..I............ 

46.0 46.0...I..I......|..... 

47.0 47.0.I.I..I......+..... 

48.0 48.0.II...I.......|.... 

49.0 49.0.II...I.......|.... 

50.0 50.0.II...I..|......... 

51.0 51.0.II...I............ 

52.0 52.0III...I..+......... 

53.0 53.0I//...I..||........ 

54.0 54.0I//...I............ 

55.0 55.0I//...I..||........ 

56.0 56.0I.....I...+........ 

57.0 57.0I...III............ 

58.0 58.0I...III...|........ 

59.0 59.0I...III............ 

60.0 60.0I...III....|.....|. 

61.0 61.0/...III....|.....|. 

62.0 62.0/...III..........|. 

63.0 63.0/....II....|.....|. 

64.0 64.0.....II....+.....|. 

65.0 65.0...I.II....|.....|. 

66.0 66.0...I.I.....+|....|. 

67.0 67.0...I.I......+..|.|. 

68.0 68.0...I.......|+..|.|. 

69.0 69.0...I...........|.|. 

70.0 70.0...I.......||....|. 

71.0 71.0...I...II..++|...|. 

72.0 72.0.I.I...II....+...|. 

73.0 73.0.III...II..+|||..|. 

74.0 74.0.III...II..|..|..|. 

75.0 75.0.III...II...||...|. 

76.0 76.0.III...II....||..|. 

77.0 77.0.III...II...||...|. 

... 

Signal Control / Detector Record 



11.10 Signal Changes 

This evaluation provides a chronological list of all signal group (phase) 

changes of all selected signal controllers. 

Definition 


Configuration 

No further configuration required for data output in a window. 

Signal changes data can be output to 

► an output window via EVALUATION – WINDOWS… - Signal Changes:, cf. 


► an output file (*.LSA), cf. section 10.1.2, 

► a database, cf. section 10.1.3. 

Select EVALUATION – FILES… - [SIGNAL CONTROL] tab, activate option Signal 

Changes and click CONFIGURATION to open the Signal Changes - 

Configuration window: 

● Database: When active, 

evaluation output is 

directed to a database to 

the specified Table Name 

(rather than to an ASCII 

text file). 

The Table name must not be used for any other VISSIM database 

evaluations. In order to use the database output the database connection 

needs to be configured (see section 10.1.3). 

Results 

The output file (*.LSA) contains: 






► List of all signal groups 

► Data section containing one line for each signal change event of each 

signal group. The columns contain the following data (from left to right): 

- Simulation time [s] 

- Cycle time [s] 

- SCJ no. 

- Signal group no. 


Signal Changes 

- New signal state 

- Time since last signal change (= length of previous signal display) 

- SCJ type 

- Due to SG (supported only by certain vehicle-actuated controller 

types): Signal group that caused the current signal switch. 

Example (*.LSA file) 

Signal Changes Protocol 





SC 5 SGroup 1 Link 247 Lane 1 At 66.0 















... 

... 

1.0; 1.0; 6; 11; green ; 1.0; VAP ; 0; 

1.0; 1.0; 6; 1; green ; 1.0; VAP ; 0; 

1.0; 1.0; 10; 32; green ; 1.0; VAP ; 0; 

1.0; 1.0; 10; 31; green ; 1.0; VAP ; 0; 

1.0; 1.0; 10; 25; green ; 1.0; VAP ; 0; 

1.0; 1.0; 10; 3; green ; 1.0; VAP ; 0; 

1.0; 1.0; 10; 2; green ; 1.0; VAP ; 0; 

1.0; 1.0; 10; 1; green ; 1.0; VAP ; 0; 

1.0; 1.0; 9; 53; red/amber ; 1.0; VAP ; 0; 

1.0; 1.0; 9; 52; red/amber ; 1.0; VAP ; 0; 

1.0; 1.0; 9; 51; red/amber ; 1.0; VAP ; 0; 

1.0; 1.0; 9; 25; green ; 1.0; VAP ; 0; 

1.0; 1.0; 9; 22; green ; 1.0; VAP ; 0; 

1.0; 1.0; 9; 11; green ; 1.0; VAP ; 0; 

1.0; 1.0; 9; 10; green ; 1.0; VAP ; 0; 

1.0; 1.0; 9; 1; green ; 1.0; VAP ; 0; 

1.0; 1.0; 8; 52; red/amber ; 1.0; VAP ; 0; 

1.0; 1.0; 8; 51; red/amber ; 1.0; VAP ; 0; 

1.0; 1.0; 8; 30; green ; 1.0; VAP ; 0; 

1.0; 1.0; 8; 29; green ; 1.0; VAP ; 0; 

1.0; 1.0; 8; 24; green ; 1.0; VAP ; 0; 



11.11 Link Evaluation 

The link evaluation feature allows the user to gather simulation results based 

on an area of an active link rather than based on individual vehicles. 

Data is collected about vehicles that pass over that lane segment for a userdefined 

time interval. 

The segment length can be specified 

► separately for each active link or connector or 

► in Multiselect mode for all active links/connectors. 

The Link Evaluation window also allows for VISUM Export of VISSIM 

network data, cf. section 6.2.2.2. 

Definition 

For all links and connectors to be included in the link evaluation, 

► the property Link Evaluation needs to be active and 

► the Segment length needs to be defined (cf. sections 6.3.1 and 6.3.2). 

In order to set these properties for multiple links/connectors at the same time 

the Multiselect mode can be used (cf. section 3.3.2 for details). 

Configuration 


is to be provided within the Link Evaluation Configuration window that is 

accessible by pressing the CONFIGURATION button in EVALUATION – FILES… - 

[VEHICLES], once the option Link Evaluations is ticked. The window allows for 

definition of any combination of parameters. 

If Database output is not active each layout line results in a column within the 

output file *.STR. 

The configuration settings will be saved to an external file (*:SAK). 


Link Evaluation 

● The selected parameters (and vehicle classes) are displayed within the 

list box to the left (Layout of columns). 

● Parameters can be inserted and removed by using the buttons and 

- considering the choice of Vehicle Class for certain parameters. For a 

list of all parameters available see below. 

● from/until, Interval: A time period for the evaluation and the aggregation 

interval needs to be defined. 

● Per Lane: If active, data will be evaluated individually for every lane of 

multi-lane links. Otherwise the data will be aggregated for all lanes. 

● Database: If active, evaluation output is directed to a database to the 

specified Table Name (rather than to an ASCII text file). The table name 

must not be used for any other VISSIM database evaluations. In order to 

use the database output the database connection needs to be configured 


Results 

A link evaluation file (*.STR) contains: 






► List of all evaluated vehicle classes 

► List of selected parameters with brief description 

► Data block with a column for each selected parameter: See list below. 



The list below contains the set of parameters available, including the column 

headers that will be used in the link evaluation output file. 

Some parameters will only report correct results if the corresponding 

optional module (such as Dynamic Assignment, Emission etc.) is installed. 

Generally, current (short/long)distance/speed/acceleration units set via 

VIEW - OPTIONS - [LANGUAGE & UNITS] are regarded for evaluation data output. 

Emissions are always output in mg/m/s. 


Density Vehicle density Density 

Emissions Only with Emissions add-on: HC_evap 

(Evaporation) HC Emissions (Evaporation) 

Hydrocarbon in the current interval 

Emissions Only with Emissions add-on: Bnzn 

Benzene 

Emissions Benzene during current 

interval 

Emissions CO Only with Emissions add-on: 

Emissions CO during current 

interval 

CO 

Emissions CO2 Only with Emissions add-on: 

Emissions Carbondioxid during 

current interval 

CO2 

Emissions HC Only with Emissions add-on: 

Emissions HC during current 

interval 

HC 

Emissions NMHC Only with Emissions add-on: 

Emissions HC without Methane 

during current interval 

NMHC 

Emissions NMOG Only with Emissions add-on: 

Emissions Nonmethan Organic 

Gasses during current interval 

NMOG 

Emissions NOx Only with Emissions add-on: 

Emissions NOx during current 

interval 

NOx 

Emissions Only with Emissions add-on: Particulate 

Particulates Emissions Particulates during 


Emissions SO2 Only with Emissions add-on: 

Emissions Sulfurdioxide during 


SO2 




Emissions Soot Only with Emissions add-on: 

Emissions Soot during current 

interval 

Fuel consumption Fuel consumption during current 

interval [mg/m/s] 

Soot 


Fuel 

Lane number Lane number Lane 

Link number Link number Link 

Lost time Delay portion of a vehicle’s total 

travel time on the segment 

Segment end 

coordinate 

Segment start 

coordinate 

LostT 

Segment end link coordinate SegEndC 

Segment start link coordinate SegStC 

Segment end x Segment end (cartesian coordinate 

x) 

Segment end y Segment end (cartesian coordinate 

y) 

Segment start x Segment start (cartesian 

coordinate x) 

Segment start y Segment start (cartesian 

coordinate y) 

SegEndX 

SegEndY 

SegStX 

SegStY 

Segment length Segment length SegLen 

Simulation time Simulation time [sec] t 

Speed Average speed v 

Volume Volume [veh/h] Volume 

Example (*.STR file) 






Vehicle Class: 0 = All Vehicle Types 

Vehicle Class: 10 = Car 

Vehicle Class: 20 = HGV 

Vehicle Class: 30 = Bus 

Vehicle Class: 40 = Train 

Vehicle Class: 50 = Pedestrians


Vehicle Class: 60 = Bike 

t: Simulation Time [s] 

Link: Link Number 

v: Average speed [mph] (Vehicle Class 0) 

Volume: Volume [veh/h] (Vehicle Class 0) 

Density: Vehicle density [veh/mi] (Vehicle Class 0) 

Fuel: Fuel consumption [mg/m/s] (Vehicle Class 10) 

t; Link; v(0); Volume(0); Density(0); Fuel(10); 

... 

60.0; 233; 0.00; 0.00; 0.00; -; 

60.0; 233; 0.00; 0.00; 0.00; -; 

60.0; 233; 0.00; 0.00; 0.00; -; 

60.0; 233; 0.00; 0.00; 0.00; -; 

... 

120.0; 233; 17.60; 151.07; 8.58; -; 

120.0; 233; 22.54; 157.16; 6.97; -; 

120.0; 233; 27.04; 116.04; 4.29; -; 

120.0; 233; 28.44; 119.52; 4.20; -; 

... 

180.0; 233; 28.41; 114.29; 4.02; -; 

180.0; 233; 28.18; 143.61; 5.10; -; 

180.0; 233; 28.12; 181.00; 6.44; -; 

180.0; 233; 29.16; 167.11; 5.73; -; 

... 

240.0; 233; 18.97; 101.75; 5.36; -; 

240.0; 233; 24.70; 119.26; 4.83; -; 

240.0; 233; 28.63; 115.18; 4.02; -; 

240.0; 233; 30.49; 116.47; 3.82; -; 

... 

300.0; 233; 24.63; 277.47; 11.27; -; 

300.0; 233; 27.81; 298.34; 10.73; -; 

300.0; 233; 29.89; 296.68; 9.92; -; 

300.0; 233; 30.91; 295.23; 9.55; -; 

... 


11.12 Node Evaluation 

Node Evaluation 

Node Evaluation is a way of collecting data for a user-defined area within a 

VISSIM network. The evaluations are automatically collected using the node 

boundaries as the evaluation segment definitions. The Node Evaluation is 

designed especially for gathering intersection-specific data without the need 

to manually define all the data collection cross-sections. 

Definition 

For each junction to be evaluated, a node polygon needs to be drawn. 

Cf. chapter 12.3.2 for more information on defining nodes. 

For all nodes to be included in the node evaluation, the property Node 

Evaluation needs to be active. 

Configuration 


is to be provided within the Node Evaluation Configuration window that is 

accessible by pressing the CONFIGURATION button via EVALUATION – FILES… - 

[VEHICLES], once the option Node is ticked. The window allows for definition of 

data to be evaluated by a node evaluation. 

It contains the following lists: 



► Selected Parameters (use and to add or remove a selected parameter) 

► Available parameters (Parameter Selection) 

► Vehicle Class (enabled only for some parameters) 

Use the buttons UP and DOWN to arrange the entries (columns in *.KNA data 

file). 

● Output: Select data type, e.g. as database table, if applicable: 

- Compiled data: Creates an ASCII file *.KNA according to the 

current settings in the window (parameters, vehicle classes etc.). 

If VISSIM is started with command line parameter -s or if the 

simulation run is started via COM with RunIndex set to a value >0, 

the index of the simulation run will be added to the name of the 

output file (*.KNA). 

- Raw data: Creates an ASCII file *.KNR, does not regard userdefined 

parameter settings. 

- Database: If active, evaluation output of compiled and/or raw data 

is directed to a database with the specified Table Name (rather than 

to an ASCII text file *.KNA and/or *.KNR). The table name must not 

be used for any other VISSIM database evaluations. In order to use 

the database output the database connection needs to be configured 


The selected parameters and other settings are saved to a node evaluation 

configuration file (*.KNK) when the window is closed via OK. 

Filter 

The evaluation can be 

switched on/off 

► separately for 

each node via the 

node attributes or 

► via the list of 

Active nodes in 

the Node 

Evaluation – Filter 

window. 

Furthermore, define 

the following parameters 

for delay measurements: 

► the upstream Start of delay segment position, 

► time period (From - Until) and 

► length of the time Interval of the evaluation. 


Results 


The results of a Node Evaluation are grouped by turning movements and 

saved to a file with the extension *.KNA. Each turning relation is named 

using the approximate compass directions (N / NE / E / SE / S / SW / W / 

NW) of its first and last link (at the node boundary) with “North” direction 

facing to the top of the VISSIM network. If a compass with a user-defined 

North direction is active, any output direction data will refer to these settings, 

cf. section 4.1.1. Example: "NE-S" is a movement entering from the North- 

East and leaving to the South. 

The two link numbers can be written to the evaluation file as well to avoid 

ambiguity (two "parallel" turning relations with identical first and last links do 

look identical). All results are aggregated over a user-defined time period for 

time intervals with a user defined length. 

The node evaluation file *.KNA contains the following data: 







► Data block with a column for each selected parameter. 

The data section contains for every time interval: 

- one row per turning relation of each active node and 

- an additional row for the node total (turning relation "All"). 

- an additional row per time interval with node number 0 containing the 

system total. 

The volume, average delay and standing time values as well as the number 

of stops are determined by a delay segment created automatically as a 

combination of new travel time measurements from all possible upstream 

starting points (with user-defined distance, but not extending across an 

upstream node boundary – unless there are more than four branches to side 

roads between the two nodes) to the node exit point of the respective turning 

relation. Also available is the number of passengers and the person delay by 

vehicle class. 

The queue length values are collected by a queue counter created automatically 

and placed at the first signal head or priority rule stop line on the 

link sequence of the turning relation. If there is no such cross section, the 

queue counter is placed at the node entry point. The node evaluation places 

a queue counter on every edge (movement) found inside the node. It is 

placed at the position of the signal head or priority rule stop line that is the 

closest one upstream to the node boundary on the respective edge. 

Neither scheduled stops at PT stops nor stops in parking lots are counted as 

stops. Neither passenger transfer times nor dwell times at STOP signs or the 

time spent in parking lots are counted as delays (though time losses due to 



deceleration/acceleration before/behind PT stops do count for delay 

calculation). 

Edges between nodes are ignored if they contain more than three forks, 

which are defined as a connector starting from a link with another 

connector starting downstream from the same link. This can speed up the 

calculation of the network graph dramatically. 

If there is more than one edge with the same from link and to link then only 

one queue length is recorded. 

The automatically created network elements (travel time sections, delay 

segments, queue counters) are not available for user modifications 

because they exist only during the simulation run. The time periods and 

interval lengths for delay segments and queue counters are set to the 

values defined for the node evaluation (overwriting all others) as soon as 

the user leaves the EVALUATION - FILES... window with the Node evaluation 

activated (a warning message appears if the respective evaluation was 

also activated). 

For Movement data output, all directions refer to the user-defined North 

direction of the compass, if applicable. If the compass is not displayed, Up 

is taken for the North direction. 

Current (short/long)distance/speed/acceleration units set via VIEW - 

OPTIONS - [LANGUAGE & UNITS] are regarded for evaluation data output. 


Average Queue 

Length 

Average Queue Length aveQueue 

Delay time Average delay per vehicle [s] Delay 

Emissions CO Emissions CO [g] EmissCO 

Emissions NOx Emissions NOx [g] EmissNOx 

Emissions VOC Emissions VOC [g] EmissVOC 

From Link Number of the link entering node FromLink 

From Node Number of the previous node 

Node number 0 is recorded if a 

movement has no FromNode. 

Only one of the node numbers is 

recorded for movements with more 

than one FromNode. 

FromNode 

Fuel Consumption Fuel Consumption [gal] FuelCons 

Maximum Queue 

Length 

Maximum Queue Length maxQueue 




Movement Movement (Bearing from-to; the 

North direction depends on the 

current compass settings) 

Movement 

Node Node Number Node 

Number Veh Number of Vehicles Veh 

Person Delay Average delay per person [s] PersDelay 

Persons Number of People #Pers 

Stopped Delay Average stopped delay per vehicle 

[s] 

Stops Average number of stops per 

vehicle 

Time from Start time of the Aggregation 

interval 

Time to End time of the Aggregation 

interval 

tStopd 

Stops 

tStart 

tEnd 

To Link Number of the link leaving node ToLink 

To Node Number of the next node 

Node number 0 is recorded if a 

movement has no ToNode. 

Only one of the node numbers is 

recorded for movements with more 

than one ToNode. 

Example: Compiled data file (*.KNA) 

Node evaluation 





Node: Node Number 

tStart: Start time of the Aggregation interval 

tEnd: End time of the Aggregation interval 

FromLink: Number of the link entering node 

ToLink: Number of the link leaving node 

Movement: Movement (Bearing from-to) 

Delay: Average delay per vehicle [s], Vehicle Class Car 

tStopd: Average stopped delay per vehicle [s], Vehicle Class Car 

maxQueue: Maximum Queue Length [ft] 

ToNode 



Node;tStart; tEnd;FromLink;ToLink;Movement;Delay;tStopd;maxQueue; 

1; 0.0; 300.0; 102; 106; S-E; 0.0; 0.0; 0.0; 

1; 0.0; 300.0; 105; 101; E-S; 0.0; 0.0; 0.0; 

1; 0.0; 300.0; 235; 234; NW-S; 0.9; 0.0; 0.0; 

1; 0.0; 300.0; 237; 234; E-S; 1.6; 0.0; 0.0; 

1; 0.0; 300.0; 237; 239; E-NW; 0.3; 0.0; 0.0; 

1; 0.0; 300.0; 5114; 5114; N-S; 0.0; 0.0; 0.0; 

1; 0.0; 300.0; 0; 0; All; 1.3; 0.0; 0.0; 

3; 0.0; 300.0; 106; 109; W-N; 0.0; 0.0; 256.7; 

3; 0.0; 300.0; 110; 105; N-W; 0.0; 0.0; 195.7; 

3; 0.0; 300.0; 231; 244; S-N; 33.8; 27.2; 65.3; 

3; 0.0; 300.0; 231; 237; S-W; 38.0; 28.5; 65.3; 

3; 0.0; 300.0; 242; 232; NE-S; 0.0; 0.0; 38.8; 

3; 0.0; 300.0; 242; 233; NE-S; 6.2; 2.4; 38.8; 

3; 0.0; 300.0; 247; 237; N-W; 1.1; 0.0; 41.6; 

3; 0.0; 300.0; 247; 233; N-S; 5.2; 1.8; 41.6; 

3; 0.0; 300.0; 248; 244; NE-N; 30.9; 23.8; 367.7; 

3; 0.0; 300.0; 248; 237; NE-W; 12.0; 7.5; 367.7; 

3; 0.0; 300.0; 0; 0; All; 16.3; 11.3; 367.7; 

0; 0.0; 300.0; 0; 0; All; 9.4; 6.1; 367.7; 

1; 300.0; 600.0; 102; 106; S-E; 0.0; 0.0; 0.0; 

1; 300.0; 600.0; 105; 101; E-S; 0.0; 0.0; 0.0; 

1; 300.0; 600.0; 235; 234; NW-S; 0.9; 0.0; 0.0; 

1; 300.0; 600.0; 237; 234; E-S; 2.0; 0.2; 0.0; 

1; 300.0; 600.0; 237; 239; E-NW; 3.2; 1.1; 0.0; 

1; 300.0; 600.0; 5114; 5114; N-S; 0.0; 0.0; 0.0; 

1; 300.0; 600.0; 0; 0; All; 1.7; 0.2; 0.0; 

3; 300.0; 600.0; 106; 109; W-N; 0.0; 0.0; 201.9; 

3; 300.0; 600.0; 110; 105; N-W; 0.0; 0.0; 194.1; 

3; 300.0; 600.0; 231; 244; S-N; 0.0; 0.0; 61.8; 

3; 300.0; 600.0; 231; 237; S-W; 1.0; 0.0; 61.8; 

… 

Example: Raw data file *.KNR 

Node Evaluation (Raw data) 





VehNo; VehType; TStart; TEnd; StartLink; StartLane; StartPos; NodeNo; Movement; FromLink; 

ToLink; ToLane; ToPos; Delay; TStopd; Stops; No_Pers; 

11; 100; 10; 18; 365; 1; 0; 2; SE-SW; 365; 10151; 3; 10; 2; 0; 0; 1; 

16; 100; 15; 20; 358; 1; 0; 3; W-S; 358; 10420; 1; 7; -1; 0; 0; 1; 

20; 100; 17; 25; 365; 1; 0; 2; SE-SW; 365; 10151; 3; 10; 1; 0; 0; 1; 

6; 150; 18; 28; 274; 1; 152; 2; NE-SW; 249; 249; 2; 44; 0; 0; 0; 1; 

27; 100; 20; 30; 365; 1; 0; 2; SE-SW; 365; 10151; 3; 10; 3; 0; 0; 1; 

33; 100; 25; 31; 358; 1; 0; 3; W-S; 358; 10420; 1; 7; -1; 0; 0; 2; 

29; 100; 23; 34; 235; 1; 2; 3; N-S; 234; 234; 2; 59; 1; 0; 0; 2; 

36; 100; 27; 38; 235; 1; 2; 3; N-S; 234; 234; 1; 59; 1; 0; 0; 1; 

14; 100; 24; 38; 274; 1; 152; 2; NE-SW; 249; 249; 2; 44; 4; 0; 0; 1; 

13; 100; 24; 38; 274; 2; 152; 2; NE-SW; 249; 249; 3; 44; 3; 0; 0; 2; 

… 



Column Header Definition 

VehNo Vehicle number 

VehType Vehicle type number 


TStart Simulation time when the vehicle crossed the start 

of the travel time section 

TEnd Simulation time when the vehicle crossed the end of 

travel time section (i.e. the node exit) 

StartLink Number of the link at the start of travel time section 

StartLane Number of the lane at the start of travel time section 

StartPos Link coordinate/Position of the travel time section on 

StartLink 

NodeNo Node number 

Movement Bearing from-to (compass settings) 

FromLink Number of the link entering the node (Note: link 

where the shortest path from the start of the travel 

time section enters the node, this is not necessarily 

the link where the vehicle entered the node.) 

ToLink Number of the link leaving node. (The vehicle really 

did leave the node on this link.) 

ToLane Number of the lane leaving node. (The vehicle really 

did leave the node on this lane.) 

ToPos Link coordinate/Position of the node exit on ToLink, 

i.e. where the link leaves the node 

Delay Delay in seconds (since travel time start section was 

passed) 

TStopd Stopped delay in seconds (since travel time start 

section was passed) 

Stops Number of stops (since travel time start section was 

passed) 

No_Pers Number of passengers 



11.13 Network Performance Evaluation 

Network Performance Evaluation evaluates several parameters that are 

aggregated for the whole simulation run and the whole network to an *.NPE 

file. 

Definition 


Configuration 


is to be provided within the Network Evaluation - Configuration window that is 

accessible by pressing the CONFIGURATION button in EVALUATION – FILES… - 

[VEHICLES], once the option Network Performance is ticked. The window 

allows for definition of data to be evaluated by a node evaluation. 

It contains the following lists: 

► Selected 

Parameters 

(use buttons 

and to 

add/remove a 

selected parameter) 

► Available 

parameters 

(Parameter 

Selection) 

and 

► Vehicle Class 

(enabled only 

for some parameters). 

Use the buttons UP and DOWN to arrange the entries (columns in data file). 

The selected parameters will be saved to a network performance evaluation 

configuration file (*.NPC). 

Scheduled stops at PT stops and stops in parking lots are counted as stops. 

Passenger transfer times and dwell times at STOP signs and the times spent 

parking are counted as delays. 


Filter 

Set a filter with regard to time: 

● from - till simulation second. 

Results 

A network performance evaluation file (*.NPE) contains: 






► Evaluated simulation time (Simulation Time) 

► Data block with a line for each selected parameter. 

Network Performance Evaluation 

The evaluation takes the following into account: 

vehicles that have left the network or reached their destination parking lot 

and also vehicles still being in the network at the end of the analysis interval. 

For output of emission data, the Emissions add-on is required. 

Parameter name in the list 

box 

Parameter legend in the dialog and 

notes 

Number of active vehicles Number of vehicles in the network 

Total number of vehicles in the network at 

the end of the simulation. Does not include 

the already arrived vehicles or the latent 

demand (see below). 

Number of arrived vehicles Number of vehicles that have left the 

network 

Total number of vehicles which have 

already reached their destination and left 

the network during the simulation. 

Latent demand Number of vehicles which could not enter 

the network (from vehicle inputs and 




box 


notes 

parking lots) 

Number of vehicles at the end of the 

simulation waiting to enter the network (in 

a parking lot or input). These are not 

counted as active vehicles. 

Latent delay time Total waiting time of vehicles which could 

not enter the network (immediately) [h] 

Summed up waiting time in vehicle inputs 

and parking lots of all vehicles which could 

not enter the network at their original start 

time. This can include waiting time of 

vehicles which have entered the network 

before the end of the simulation. 

The sum of (latent demand + active vehicles + arrived vehicles) equals the 

total demand from vehicle inputs and matrices during the simulation period. 


box 


notes 

Distance Total Distance Traveled [km] / [mi] 

Travel Time Total travel time [h] 

Average speed Average speed 

Delay Time Total delay time [h] 

Total distance traveled by active and 

arrived vehicles. 

Total travel time of all active and arrived 

vehicles. 

Total Distance / total Travel Time (see 

above) 

Total delay time of all active and arrived 

vehicles. 

The delay time of a vehicle in one time 



box 

Network Performance Evaluation 


notes 

step is the part of the time step which is 

spent because the actual speed is lower 

than the desired speed. It is calculated by 

subtracting the quotient of the actual 

distance traveled in this time step and the 

desired speed from the length of the time 

step. 

Note: Dwell times of bus/trams stopping at 

a PT stop are not included. Parking in any 

type of parking lot is not included. 

Note: Delay time includes stopped delay 

(see below). 

Average delay time Average delay per vehicle [s] 

Total delay time / (active + arrived 

vehicles) 

Stopped Delay Total stopped delay [h] 

Total stopped time of all active and arrived 

vehicles. 

Stopped delay = time when vehicle is 

standing (speed is zero). 

Note: Dwell times of bus/trams stopping at 

a PT stop are not included. Parking in any 

type of parking lot is not included. 

Average stopped delay Average stopped delay per vehicle [s] 

Total stopped delay / (active + arrived 

vehicles) 

Number of Stops Total number of stops 

Total number of stops of all active and 

arrived vehicles. 

A stop is counted if the speed of the 

vehicle was greater than zero at the end of 

the previous time step and is zero at the 

end of the current time step. 




box 


notes 

Average number of stops Average number of stops per vehicle 

Fuel Consumption 

Emissions 

Example (*.NPE file) 

Network Performance 

Total number of stops / (active + arrived 

vehicles) 

Fuel Consumption / Emission [kg] 

Only available if the Emissions module is 

included in the VISSIM license. Please 

refer to section 11.18. 

File: e:\programfiles\ PTV_Vision\Vissim530\example\manual.inp 

Comment: Manual example 

Date: Friday, August 13, 2010, 15:43:02 

VISSIM: 5.30-00* [24926] 

Simulation time from 0.0 to 180.0. 

Parameter ; Value; 

Average delay time per vehicle [s], All Vehicle Types ; 27.221; 

Average number of stops per vehicles, All Vehicle Types ; 0.836; 

Average speed [km/h], All Vehicle Types ; 24.883; 

Average stopped delay per vehicle [s], All Vehicle Types ; 18.564; 

Total delay time [h], All Vehicle Types ; 2.450; 

Total Distance Traveled [km], All Vehicle Types ; 130.606; 

Evaporation [kg], All Vehicle Types ; -; 

Emissions Benzene [kg], All Vehicle Types ; -; 

Emissions CO [kg], All Vehicle Types ; -; 

Emissions CO2 [kg], All Vehicle Types ; -; 

Emissions HC [kg], All Vehicle Types ; -; 

Emissions NMHC [kg], All Vehicle Types ; -; 

Emissions NMOG [kg], All Vehicle Types ; -; 

Emissions NOx [kg], All Vehicle Types ; -; 

Emissions Particulates [kg], All Vehicle Types ; -; 

Emissions SO2 [kg], All Vehicle Types ; -; 

Emissions Soot [kg], All Vehicle Types ; -; 

Fuel Consumption [kg], All Vehicle Types ; -; 

Latent delay time [h], All Vehicle Types ; 0.000; 

Latent demand, All Vehicle Types ; 0; 

Number of Stops, All Vehicle Types ; 271; 

Number of vehicles in the network, All Vehicle Types ; 127; 

Number of vehicles that have left the network, All Vehicle Types ; 197; 

Total stopped delay [h], All Vehicle Types ; 1.671; 

Total travel time [h], All Vehicle Types ; 5.249; 


11.14 Observer 

Observer 

The observer evaluation creates a binary file (*.BEO) to contain all vehicle 

information for every vehicle and every time step. Thus this evaluation 

creates extremely large files within a short simulation period. 

This evaluation remains in VISSIM only for historic reasons. We recommend 

to use the Vehicle record evaluation instead as it is much more flexible. 



11.15 Lane Changes 

This evaluation provides data according to when and where lane changes of 

vehicles happened. 

Definition 


Configuration 


is accessible by pressing the FILTER button in EVALUATION – FILES… - 

[VEHICLES], once the option Lane Change is ticked. 

Filter 

The Lane Change Evaluation Filter window is similar to the Vehicle Record 

Filter window. For further information on the filter definition cf. section 11.7. 

Filter parameters are saved to *.LCF file. 

Results 

For every vehicle captured by the filter definitions, every lane change event 

will be logged into a lane change file (*.SPW). 






► Data block with 

- Time when the lane change starts 

The end of the time step in which the lane change starts is output. If the 

simulation is run with only one time step per simulation second, the lane 

change has started about one second ago at this point in time. 

- Vehicle number 

- Speed [m/s] 

- Link number 

- Number of the old lane 

- Number of the new lane 

and for both the old and new vehicles in front (VF) and the old/new 

vehicles in the back (VB): 

- Vehicle number (0 if not existing) 

- Speed [m/s] 

- Speed Difference [m/s] 


Lane Changes 

- Distance [m] between the rear bumper of the preceding vehicle (VF) 

and the front bumper of the trailing vehicle (VB) 

For lane change data output, metric units are used. 

Example (*.SPW file) 

Lane Change Record 

File: e:\programfiles\vissim520\example\manual.inp 


Date: Friday, June 20, 2009, 15:43:02 


t; VehNr; v [m/s]; Link No.; Lane; New Lane; VF; v VF [m/s]; dv VF [m/s]; dx VF [m]; VB; v 

VB; dv VB [m/s]; dx VB; new VF; v new VF [m/s]; dv new VF [m/s]; dx new VF [m]; new VB; v 

new VB [m/s]; dv new VB [m/s]; dx new VB [m] 

16.40; 22; 15.19; 1;1; 2; 7; 14.55; 0.63; 137.42; 0; -1.00; -1.00; -1.00; 14; 13.68; 1.50; 

71.20; 0; -1.00; -1.00; -1.00; 

22.50; 16; 14.36; 28;2; 1; 0; -1.00; -1.00; -1.00; 0; -1.00; -1.00; -1.00; 4294965278; 

0.00; 14.36; 68.59; 0; -1.00; -1.00; -1.00; 

24.00; 17; 14.16; 28;2; 1; 0; -1.00; -1.00; -1.00; 0; -1.00; -1.00; -1.00; 16; 13.88; 

0.27; 17.07; 0; -1.00; -1.00; -1.00; 



11.16 PT Waiting Time 

This evaluation provides a log file (*.OVW) of all events when a public 

transport vehicle stopped (excluding passenger interchange stops and stops 

at stop signs). 

Definition 


Configuration 


Results 

This is the file format of an output file (*:OVW): 





► Data block: 

- one column for each parameter, and 

- one data line for each event when a public transport vehicle stopped 

for any other reason than a passenger interchange. 

For PT waiting time data output, metric units are used. 

Example (*.OVW file) 

Table of PT waiting times 



Date: Wednesday, May 2, 2009, 15:43:02 


Time VehNo Line Link At Duration 

123 1 218 106 82.97 5 

137 44 2114 272 152.46 45 

159 55 206 106 83.08 12 

233 54 1114 247 58.50 135 

323 242 2114 272 145.77 43 

324 249 202 106 82.97 2 

482 386 218 106 82.86 6 

482 416 107 110 351.65 5 

497 420 2114 272 152.33 31 

518 429 1114 247 58.45 46 

573 501 206 106 82.86 3 


11.17 Vehicle Input 

Vehicle Input 

This evaluation provides a log file (*.FHZ) of all vehicle input events (i.e. 

when a vehicle enters the VISSIM network). 

Definition 


Configuration 


Results 

This is the file format of an output file (*.FHZ): 





► Version no. with Service pack no. and Build no (VISSIM) 


- one data line for each vehicle entering the VISSIM network, and 

- one column per parameter. 

If a dynamic assignment vehicle starts from a parking lot, the number of the 

parking lot is written to the column “Link” (not the link number) and zero to 

the column “Lane”. 

Example (*.FHZ file) 

Table of vehicles entered 



Date: Wednesday, May 2, 2009, 15:43:02 


Time; Link; Lane; VehNr; VehType; Line; DesSpeed; CatTemp; CWTemp; DestPLot; Start Time; 

0.1; 2008; 1; 1; 401; 218; 48.9; 20.0; 20.0; 0; 0.1; 

0.1; 1001; 1; 2; 402; 101; 48.9; 20.0; 20.0; 0; 0.1; 

1.2; 279; 1; 3; 100; 0; 49.1; 0.0; 0.0; 0; 1.3; 

2.6; 273; 1; 4; 100; 0; 48.3; 0.0; 0.0; 0; 2.6; 

3.6; 279; 1; 5; 100; 0; 51.1; 0.0; 0.0; 0; 3.7; 

7.1; 274; 1; 6; 150; 0; 53.7; 0.0; 0.0; 0; 7.1; 

9.2; 275; 1; 7; 100; 0; 51.0; 0.0; 0.0; 0; 9.2; 

9.7; 279; 1; 8; 150; 0; 55.8; 0.0; 0.0; 0; 9.8; 

... 



11.18 Emission Statistics 

Additionally to the VISSIM interface to various external emission calculation 

modules, PTV AG offers the Emissions add-on to VISSIM. For further 

information please contact PTV AG. 

Without this add-on, emission data can be output via Node evaluation. 


11.19 Export 

Once option Export is checked via EVALUATION – 

FILES… - [VEHICLES], the Export Configuration window 

can be accessed via CONFIGURATION. 

The Export Configuration window allows for output of 

dedicated output files for later use in external 

visualization packages: 

● GAIA, 

● VS-pCoq Spy, 

● MISKAM 

● SSAM Trajectory. 

Export 



11.20 Special Evaluations (Discharge rate evaluation) 

The option Special Evaluations contained in the Offline Analysis (File) 

window (EVALUATION – FILES… - [VEHICLES]) enables any evaluations that have 

to be entered within the input file directly. 

In this section the evaluation of the discharge rate (which is the reciprocal of 

the saturation flow) is explained. 

A discharge in most cases will be measured at a stop line of a signal control. 

In order to get reasonable values for the discharge rate the flows that are 

measured need to be saturated (i.e. at least as many vehicles queuing as 

can pass at green time). 

Definition 

For every discharge rate evaluation, a signal head and a data collection point 

at the position of the signal head needs to be defined. 

The discharge rate evaluation is then defined directly in the *.INP file (using a 

text editor) like this: 

EVALUATION TYPE DISCHARGE SCJ 1 SIGNAL_GROUP 2 COLLECTION_POINT 1 

TIME FROM 0.0 UNTIL 99999.0 

In this example, the evaluation refers to the green times of signal group 2 of 

SC 1, and the times are measured at data collection point 1 which needs to 

be located at the corresponding stop line. The time interval is usually set to a 

value at least as large as the simulation period. 

Configuration 


Results 

The result for each discharge rate evaluation will be written to a separate file 

(wit h ascending extensions starting with *.A00, then *.A01, *.A02, etc.). 

A Discharge rate evaluation file (*.A**) contains the following information: 






► Details, e.g. Discharge at SC 10, signal group 4 (data collection point 10422) 


- Each line refers to one green time (one cycle). 

- The 1 st first column contains the simulation time of the start of the 

green time. 


Special Evaluations (Discharge rate evaluation) 

- The 2 nd column is the elapsed time between the start of the green 

time and the arrival of the first vehicle at the data collection point. 

- The 3 rd column is the time gap between both the front ends of vehicle 

#1 (vehicle at 1 st position in the queue) and vehicle #2. Thus it is the 

time vehicle #2 needs to clear its queue position which is the 

Discharge Rate of vehicle #2. 

- The following columns contain all subsequent Discharge Rates 

according to the vehicle positions. 

- Numbers in parenthesis show the number of vehicles passed during 

that green time and their average Discharge Rate (both not including 

the Discharge Rate of vehicle #1 because that time depends on the 

location of the data collection point). 

- Values after parenthesis are the Discharge Rates of vehicles 

crossing the stop line after the green time (during amber or even 

red). 

- The 4 th line from the bottom contains the index of the vehicle’s 

position in the queue for each signal cycle. 

- The 3 rd line from the bottom contains the average Discharge Rates 

for the corresponding vehicle position. 

- The 2 nd line from the bottom contains the number of all vehicles 

measured for that position (higher indices might have smaller 

numbers if the flow is not saturated at all times). 

- The bottom line shows the total number of vehicles and total 

Discharge Rate for the whole evaluation period. 

Example (*.A00 file) 

Discharge Rate Evaluation 



Date: T Wednesday, May 2, 2009, 15:43:02 


Discharge at SC 10, signal group 4 (data collection point 10422) 



901 2.07 2.52 (1: 2.52) 2.14 

989 2.10 2.73 1.73 2.19 1.22 1.77 1.45 2.06 (7: 1.88) 1.37 

1081 2.08 2.61 2.27 2.12 1.49 1.57 1.97 1.59 (7: 1.95) 1.23 2.19 

1169 1.91 2.65 1.90 2.10 2.37 1.48 1.79 (6: 2.05) 2.41 1.44 1.29 

1261 1.95 2.86 2.02 1.80 1.74 1.16 1.59 1.67 (7: 1.83) 1.40 1.99 

1351 2.07 2.65 1.78 1.85 1.42 2.29 (5: 2.00) 5.36 

1442 1.92 2.60 1.97 1.88 (3: 2.15) 1.96 

1529 2.06 2.34 2.04 2.00 1.95 1.61 2.02 1.50 (7: 1.92) 1.57 

1619 2.03 2.86 1.84 2.41 1.34 1.27 2.03 (6: 1.96) 2.15 1.44 1.40 

1709 2.00 2.75 2.09 1.38 1.78 1.69 1.53 1.32 (7: 1.79) 1.61 1.70 

1797 2.06 2.61 1.90 1.93 1.66 (4: 2.02) 2.16 

1889 2.11 2.44 2.01 1.62 1.68 1.84 1.99 1.20 (7: 1.83) 1.41 3.33 

1981 1.90 2.58 1.86 1.56 1.86 2.05 1.37 1.49 (7: 1.82) 1.57 1.62 

2070 2.03 2.54 2.09 1.71 1.62 2.08 1.79 1.68 (7: 1.93) 1.73 

2158 2.05 2.14 2.15 2.18 1.48 1.58 2.12 0.98 (7: 1.80) 2.01 

2249 1.95 2.64 2.14 1.80 1.53 1.34 1.88 1.82 (7: 1.88) 

2341 2.13 2.42 1.87 1.71 1.91 (4: 1.98) 

2429 1.93 2.63 1.80 2.11 1.71 1.97 1.45 1.77 (7: 1.92) 

2521 2.02 2.48 1.75 2.37 1.67 1.42 1.88 1.48 (7: 1.86) 3.86 

2609 2.03 2.57 1.98 1.92 1.72 1.60 1.45 1.75 (7: 1.85) 1.22 2.54 

2701 1.87 2.72 (1: 2.72) 2.00 

2789 2.22 2.48 1.92 1.49 1.74 1.47 1.46 2.05 (7: 1.80) 1.17 

2881 2.00 3.10 1.91 1.73 1.74 1.68 1.50 1.72 (7: 1.91) 1.63 

2972 2.09 3.00 2.67 1.71 1.39 1.97 2.02 (6: 2.13) 1.20 2.15 

----- 1 2 3 4 5 6 7 8 9 10 

----- 2.03 2.62 1.99 1.89 1.68 1.70 1.93 1.66 1.68 2.01 

----- 24 24 24 22 22 20 19 18 16 8 

[173: 1.92] 


11.21 Paths Evaluation 

Paths Evaluation 

The Paths Evaluation file (*.WGA) can only be used with the Dynamic 

Assignment add-on. It is intended to produce results in a user-definable 

format for a Dynamic Assignment run. 

Definition 


Configuration 

For configuration, the Path Evaluation Configuration window can be 

accessed, if option Paths (Dynamic Ass.) is ticked in the Offline Analysis 

(File) window (EVALUATION – FILES… - [VEHICLES]) 

Path evaluation can be output to file (*.WGA) and to a Database table, see 

Table name, if option Database is checked. 

Selected parameters 

are displayed within the 

list box to the left. 

The current selection 

can be edited by 

pressing the and 

buttons. 

The configuration will 

be saved to an external 

file (*.WGK). 

● Database: If active, evaluation output is directed to a database to the 

specified Table Name (rather than to an ASCII text file). The table name 

must not be used for any other VISSIM database evaluations. In order to 

use the database output the database connection needs to be configured 


Filter 

Additionally, the filter information needs to be configured. This is done in the 

Path Evaluation Filter window which is accessed by selecting Paths 

(Dynamic Ass.) in the Offline Analysis (File) window (EVALUATION – FILES...). 



The filter allows for evaluation of 

selected paths only and for a userdefined 

time interval (from/until). 

It can be used either with Parking Lots 

or Zones. 

Whenever one of the two options is 

selected the settings of the nonselected 

option are irrelevant. 

Path evaluation is done only for the 

selected relations. 

The filter configuration is saved to a file 

with extension *.WGF. 

Results 

A Path evaluation file (*.WGA) contains the following information: 







► Data block with output data per path 

Travel time edge: Sum of travel times of edges of the path between two 

parking lots. The travel time of an edge sums up from the travel times of all 

vehicles traversing this edge except input vehicles or public transport 

vehicles. Thus vehicles passing an edge can also be those with different 

origin or destination parking lots. Vehicles which have not yet finished their 

ride through the network are regarded for only those edges they already 

have traversed. 

Travel time path: Travel time for relations from–to parking lots. The 

measurement can only include vehicles which have reached their 

destination parking lot. 

For output of travel times, three variants are provided for either type: 

► Expected: Travel time before simulation run. 

► Determined: Travel time of last run. 

► Smoothed: Travel time after averaging according to the settings in the 

Edge Cost Values window. Access to this window is provided via menu 

TRAFFIC - DYNAMIC ASSIGNMENT which calls the Dynamic Assignment 

window. Here, click the EXTENDED button next to option Store costs. 


Paths Evaluation 


Distance Distance (selected short length unit) Dist 

Link Cost Total of all link cost on the path LinkCost 

Parking Lot 

Destination 

Destination parking lot number DestP 

Parking Lot Origin Origin parking lot number OrigP 

Path number Path number (see legend) PathNo 

Relative Volume Share of the number of vehicles 

started on all paths for this OD pair 

(Veh. Type) 

RelVol 

Time from Time interval start TimeFrom 

Time to Time interval end TimeTo 

Total Cost Total Cost (using the vehicle type's 

coefficients) 

Travel time diff. Percentage difference to travel time 

from previous iteration 

Travel time edges 

(determined) 


(estimated) 


(smoothed) 

Travel time path 

(determined) 


(estimated) 


(smoothed) 

Determined average total of edges’ 

travel times [s] 

Expected average total of edges’ 


Smoothed average total of edges’ 


Determined average path travel time 

[s] 

Expected average travel time for the 

path [s] 

Smoothed average path travel time 

[s] 

Volume Number of vehicles started on the 

path (Veh. Type) 

TotCost 

TravTimeDiff 

DetEdgeTT 

ExpTravT 

SmEdgeTT 

DetPathTT 

ExpPathTT 

SmPathTT 

Volume 

Zone Destination Destination zone number DestZ 

Zone Origin Origin zone number OrigZ 



Example (*.WGA file) 

Path Evaluation 

File: 

D:\Programme\PTV_Vision\VISSIM520\Examples\Training\DynamicAssignment\Detour\Detour.inp 

Comment: Dynamic Assignment routing example 

Date: Thursday, Oct. 22, 4:27:10 pm 


TimeFrom: Time interval start 

TimeTo: Time interval end 

OrigP: Origin parking lot number 

OrigZ: Origin zone number 

DestP: Destination parking lot number 

DestZ: Destination zone number 

PathNo: Path number (see legend) 

Dist: Distance [ft] 

LinkCost: Total of all link cost on the path 

TotCost: Total Cost (using the vehicle type's coefficients) (Vehicle Type 1) 

TravTimeDiff: Percentage difference to travel time from previous iteration 

DetEdgeTT: Determined average total of edges’ travel times [s] 

ExpTravT: Expected average total of edges’ travel times [s] 

SmEdgeTT: Smoothed average total of edges’ travel times [s] 

DetPathTT: Determined average path travel time [s] 

ExpPathTT: Expected average travel time for the path [s] 

SmPathTT: Smoothed average path travel time [s] 

Volume: Number of vehicles started on the path (All Vehicle Types) 

RelVol: Share of the number of vehicles started on all paths for this OD relation (All 

Vehicle Types) 

Path 1, from parking lot 1, to parking lot 3, through node(s): 1 2 3 4 

Path 2, from parking lot 1, to parking lot 3, through node(s): 1 2 9 10 3 4 







… 

TimeFrom; TimeTo; OrigP; OrigZ; DestP; DestZ; PathNo; Dist; LinkCost; TotCost(1); 

TravTimeDiff; DetEdgeTT; ExpTravT; SmEdgeTT; DetPathTT; ExpPathTT; SmPathTT; Volume(0); 

RelVol(0); 

0.0; 300.0; 1; 1; 3; 3; 1; 3324.46; 0.00; 81.55; 

-1.89; 68.91; 81.55; 80.02; 70.82; 84.60; 81.84; 34; 

0.43; 

0.0; 300.0; 1; 1; 3; 3; 2; 4267.44; 0.00; 99.46; 

-2.90; 84.82; 99.46; 96.57; 88.07; 102.10; 99.29; 19; 

0.24; 

0.0; 300.0; 1; 1; 3; 3; 3; 3419.23; 0.00; 82.20; 

-2.35; 72.34; 82.20; 80.28; 74.64; 74.10; 74.21; 26; 

0.33; 

0.0; 300.0; 1; 1; 4; 4; 1; 3325.52; 0.00; 81.21; 

-1.98; 68.45; 81.21; 79.60; 64.77; 81.80; 78.39; 34; 

0.43; 

… 


11.22 Convergence Evaluation 

Convergence Evaluation 

The Convergence Evaluation file (CVA) can be used with the Dynamic 

Assignment module only. For every time interval it contains the distribution of 

changes in volume and travel times of all edges and paths. Therefore volume 

changes are divided into 9 volume classes and travel time changes into 12 

travel time classes. For every class the number of paths/edges are shown 

that have changed in terms of volume and travel time. This data can be used 

to determine whether or not the Dynamic Assignment process has 

converged. For more information please refer to chapter 12. 

If a sequence of simulation runs is executed in batch mode (command line 

parameter -s) the simulation run number (1..n) will be included in the 

*.CVA file name. 

Definition 


Configuration 

This is to be provided within the Convergence Configuration window which is 

accessed by pressing the CONFIGURATION button in EVALUATION – FILES… - 

[VEHICLES], once the option Convergence is active. 

Here the minimum edge 

length can be defined for 

edges to be considered for 

the calculation of travel time 

differences. 

Shorter edges will not be included in convergence detection and evaluation. 

Results 

The results from the Convergence Evaluation are displayed in a text table 

that compares the volumes and travel times on all of the edges and paths 

(longer than defined in the configuration) for each iteration. 

A convergence evaluation file (*.CVA) contains the following information: 






► Data table: 

The table is divided into two blocks: 

- Volume difference 

- Travel time difference 



Each data line of these evaluation blocks refers to one time interval (e.g. 

300.0; 600.0; means: from simulation second 300 to 600) and shows for 

each column the number of edges resp. paths that are contained in the 

corresponding class. The class boundaries are found in the header of 

each block (Class from, Class to), value (Class to) belongs to the class. 

Thus class from 2 to 5 for volume difference on edges means: All edges 

that changed volume by more than 2 up to 5 vehicles are contained here 

(in the example below the value is 7 for time interval 0 to 300). 

Example (*.CVA file) 

Convergence Evaluation 





TimeFrom; TimeTo; Volume Difference; 

(Class from) 0; 2; 5; 10; 25; 50; 100; 250; 500; 

(Class to) 2; 5; 10; 25; 50; 100; 250; 500; ~; 

Edges: 

0.0; 300.0; 12; 7; 4; 0; 0; 0; 0; 0; 0; 

300.0; 600.0; 0; 0; 7; 14; 2; 0; 0; 0; 0; 

Paths: 

0.0; 300.0; 12; 0; 0; 0; 0; 0; 0; 0; 0; 

300.0; 600.0; 7; 2; 1; 2; 0; 0; 0; 0; 0; 

TimeFrom; TimeTo; Travel Time Difference 

(Class from) 0%; 10%; 20%; 30%; 40%; 50%; 60%; 70%; 80%; 90%;100%;200%; 

(Class to) 10%; 20%; 30%; 40%; 50%; 60%; 70%; 80%; 90%;100%;200%; ~; 

Edges: 

0.0; 300.0; 20; 2; 1; 0; 0; 0; 0; 0; 0; 0; 0; 0; 

300.0; 600.0; 21; 2; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 

Paths: 

0.0; 300.0; 12; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 

300.0; 600.0; 12; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 


11.23 Managed Lanes 

Managed Lanes 

Managed lane parameters for the whole network gained during the complete 

simulation run can be output as *.MLE file. 

Definition 

Managed lanes and toll pricing models have to be defined, cf. section 5.6. 

Configuration 

EVALUATION – FILES… - [VEHICLES] – Managed lanes - CONFIGURATION calls the 

Managed lanes evaluation - Configuration window which allows for the 

selection of the evaluation parameters. 

The window contains the following lists: 

► Parameter 

selection 

► Selected 

parameters: 

Shows the 

currently set 

format of the 

output file. 

► Vehicle class 

(applies only to 

some of the 

parameters). 

This configuration is saved as configuration file *.MLC. 

Result 

The manages lanes evaluation file (*.MLE) contains the following data: 






► Number and name of the managed lane 

► Number and name of the managed lane routing decision 



► Brief description of the parameters 

► Data block with one column per parameter 

Example (*.MLE file) 

Managed Lanes Evaluation 


Comment: Base Model 



Managed lanes facility 1: Main Road 

Managed lanes decision 2: MLD Main 

AvsGP : Average speed on general purpose route [mph] 

AvsML : Average speed on managed lanes route [mph] 

FacilityNo : Managed lanes facility number 

Time : Simulation Time [s] 

HOV2 : Toll user class HOV2 

HOV3+ : Toll user class HOV3+ 

SOV : Toll user class SOV 

Revenue : Total toll revenue (at routing decision) 

TTS : Travel time savings [minutes] 

VehGP(All) : Number of vehicles at end of general purpose route, All Vehicle Types 

VehML(All) : Number of vehicles at end of managed lanes route, All Vehicle Types 

AvsGP ; AvsML ; FacilityNo; Time ; HOV2 ; HOV3+ ; SOV ; Revenue; TTS ; VehGP(All); 

VehML(All); 

60.00; 60.00; 1; 0.0; 2.00; 3.00; 2.50; 0.00; 0; 0; 0; 

60.00; 60.00; 1; 200.0; -1.00; -1.00; -1.00; 0.00; 0; 0; 0; 

0.00; 0.00; 1; Total; 2.00; 3.00; 2.50; 0.00; 0; 0; 0; 


11.24 Analyzer Report 

Analyzer Report 

The VISSIM Analyzer is a tool for generating easy to read, filtered reports. 

The Analyzer is to provide a simple way for users to do the following: 

► configure what data they want 

► store the data in a central location and 

► provide report files 

Additionally to the Standard report format, there are also some basic ways to 

extend and enhance these reports. 

11.24.1 Quick Start 

Creating an Analyzer database 

To create an Analyzer database, you must do the following: 

► load a network *.INP 

► set your nodes to the intersections that you are interested in 

► open the EVALUATION menu from the menu bar and select FILES…. 

► tick option ANALYZER DATABASE 

► click the CONFIGURATION button 

- enter the name of the database you want to save the data to 

- click OK to store your filename 

► click OK to confirm and to exit the dialog 

► run your simulation (for multiple simulation runs, cf. section 8.1.3). 

How to run the Analyzer 

In this example, a full report will be generated. 

To use the Analyzer, open the EVALUATION menu from the menu bar and 

select ANALYZER REPORTS.... 

Enter the filename or browse for your database using . The database does 

not have to belong to your current project. 



► Select your Access version. 

► Select the Access database or create a new *.MDB. 

In the Analyzer Database window, you may click DATABASE CONNECTIONS to 

select another database, cf. section 10.1.3.2. 

► Check the connection. 

► Confirm OK. 

Analyzer allows for selection of the reports to be generated. By default, all of 

the reports are checked, however, you can deselect a report by right click on 

the report title and selecting “DeSelect Report” from the pop up-menu. To 

tick a report that has not yet been selected, right click and select “Select 

Report” from the pop up menu. To generate the reports click GENERATE 

REPORTS on the Analyzer Reports dialog window: 

During report generation, Analyzer will inform you of the report that it is 

generating and its progress in generating the report in the Status Bar of the 

dialog. 

Once the reports are finished, Microsoft Excel will open, displaying your 

reports. 

An Options dalog will also open, allowing you to save the reports to file 

(*.XML or *.PDF) or add a header or footer to the reports. 



All the reports are visible as tabs at the bottom of the Excel window as well 

as a blank sheet for editing. 

11.24.2 User Interface In Depth 

In this example, a customized report will be generated. 



Filters 

Report filters 

When first opened, the left window displays options for the user to click on: 

Network 

Information 

Information about the network that created the Analyzer 

Database, including the Database name, the network name 

and location, comments and the number of links, nodes, and 

simulation runs. 

Global Allows you to select filters and apply them to all reports. 

(Global Filter: Location does not apply to the Travel Times 

report, as Travel Time Sections are handled differently than 


nodes) 


Reports Network performance, Delay, Movement Group Delay, 

Travel Times, Travel Time Delay, Queue Lengths, Volumes 


Filters are criteria that allow you to trim your selections from all the data 

collected for Analyzer from the entire network to just the information you are 

interested in. This is done by adding clauses to the database query when 

Analyzer starts processing the reports. These filters include: 

Nodes The nodes (Intersections) or Travel Time Segments that are 

contained in the network. 

Vehicle 

Types 

Random 

Seed 

The types of vehicles in the network that generate data. 

(Note: If a vehicle is not listed in the filter, it generated no 

data which is usable by Analyzer reports.) 

The Random seed values associated with individual 


Time Period Allows user to select a time period in the simulation that they 

are interested in seeing data for. 

The Time Period filter works two ways: 

► If the data is recorded at a particular time, the Time 

Period filter will select only the data that falls within the 

period you selected, or 

► if the data occurs within a range of time, the Time Period 

filter will only select the data whose start and end time 

fall within the period you selected. 

Measures Travel time measures defined in the network. 

(Selection refers only to the Travel Times Report, since 

nodes are evaluated in a different manner.) 

Movement 

Group Delay 

You can select groups of turn volumes and groups of vehicle 

types. The report logs the delays for each combination. 

(Selection refers only to the Movement Group Delay Report) 

By default, Analyzer automatically selects all the objects in the filter. This is 

indicated above the filter selection window by a checkbox. To select 

individual objects in the filter, uncheck the checkbox and make your 

selections. 

In each filter you can select multiple adjacent items using SHIFT + CLICK or 

click & drag. You can also select non-adjacent items by using CTRL + CLICK. 



Selecting filters in Global Filter will allow you to set or reset all of the other 

filters of that type at once (with the exception of Travel Time’s Location filter). 

Each report will then contain the selections made in Global Filter. Changes to 

the report filters will not affect Global Filters. 

Time filters 

Via Global you can set a single time interval which will be regarded for all of 

the reports: Check the option Set values or All: . 

For time interval definition, you need to uncheck the option Set values or 

All: in the Global filter first. Then you need to check it again to use the 

time interval settings for any other report. 

If you click on the Time Period filter, a dialog appears and allows you to 

manually enter the time period that you are interested in. 

This dialog displays the times (in simulation seconds) of the first and the last 

data recorded in your network. 


New 

Interval 

Delete 

Interval 

Edit 

Interval 

New 

vehicle 

group 


1. Make sure, that the option Set values or All: has been unchecked. 

Otherwise you cannot define a time interval by report but just the Global 

one. 

2. In the desired report, select the Time entry. 

3. In the window to the right, right-click to call the context menu: Select 

NEW. 

4. Enter the time span for network data output. 


The new interval appears in the window to the right. 

1. Mark the desired interval. 

2. In the context menu, select DELETE. 

1. Mark the desired interval. 

2. In the context menu, select EDIT. 

Vehicle group filters 

In the Movement Group Delay filter you can define a Vehicle group filter for 

this report. 

For vehicle group definition, you need to uncheck the option Set values or 

All. in the Movement Group Delay filter first. 

1. Make sure, that the option Set values or All: has been unchecked. 

Otherwise you cannot define a new vehicle group. 

2. In the Movement Group Delay filter, select the Vehicle group entry. 

3. In the window in the middle, right-click to call the context menu: Select 

NEW. 

4. In the Enter group name window, enter the name. 


6. In the window to the right, left-click while holding CTRL down to select the 

desired vehicle types. 



Delete 

vehicle 

group 

The marked vehicle types In the window to the right already represent your 

selection. 

1. In the window in the middle, mark the desired vehicle group. 

2. Click DEL or select DELETE in the context menu. 

Loading and Saving Settings 

SETTINGS allows you to save filter selections you’ve made for this database 

as well as saving headers and footers for the generated report (For 

information about setting headers and footers, see below: Adding a Header 

and Footer). To save your settings, make your filter selections and press 

SETTINGS. When the Analyzer Configuration dialog displays, press SAVE, 

select the location and filename you would like to save to and press OK. This 

will also save the header and footer if you apply them to the reports through 

the Analyzer Add Header / Footer dialog. 

You can also load previously saved settings through this window. To load 

settings, press LOAD and browse to your file location, select it and click OPEN. 

When the file is loaded, pick the Settings you want to load. 



The Preview Settings will be displayed in the preview window on the right. 

Select the settings you would like to load and press OK. 

► If you loaded any of the report settings, they will be selected when you 

return to the main Analyzer window. 

► If you loaded the header or footer settings, they will be applied when the 

reports are generated. 

If you load report filter selections for a different database than was used to 

save the settings, Analyzer will select any matches it finds in your current 

database. 

Analyzer uses an *.ANC (Analyzer Configuration) file to store your settings. 

This file can be opened and modified with any text editor. The basic format is 

as follows: 

[Database] 

Database0=C:\Projects\analyzer.mdb 

[Header] 

Header.Left= PTV America[NEWLINE]1128 NE 2nd St. Suite 204[NEWLINE]Corvallis, OR 97330 

Header.LeftPicture= 

Header.Center= 

Header.CenterPicture= 

Header.Right= 

Header.RightPicture= 

[Footer] 

Footer.Left=&D &T 

Footer.LeftPicture= 

Footer.Center= 

Footer.CenterPicture= 

Footer.Right=Page &P of &N 



Footer.RightPicture= 

[Delay.Location] 

Location0=Bannock/10th 

Location1=Bannock/11th 

[Delay.Vehicle Type] 

Vehicle Type0=Car 

Vehicle Type1=HGV 

[Delay.Time Period] 

[Delay.Random Seed] 

Random Seed0=1 

Random Seed1=3 

For Multi-Line headers and footers add [NEWLINE] where you want the 

next line to start. 

Viewing the Database 

If you have Microsoft Access 2003 or later installed, you can view your 

database by clicking on VIEW DATABASE in the main Analyzer window. 

Database table descriptions can be found in the Section: Database Tables. 

Finished Report Options Bar 

After the reports have been generated, a small dialog will display with some 

options for your report. In addition to generating the reports in XLS Format, if 

your Excel Version is 2003 or above you can also export your report to an 

XML format. 

Header and Footer information cannot be exported to XML. 

If you have PDF Creator installed, you can export to PDF format. 

You cannot export or add headers and footers while in Print Preview mode. 

From this dialog, you can also add a header or footer by pressing ADD 

HEADER / FOOTER. Pressing it will give you the following dialog. 



If you have loaded settings from the main window, this will already be 

populated with the contents you loaded. If you chose to save your settings, 

when you press OK, it will write the contents of this dialog to the ANC file. 

Analyzer Header & Footer uses the same symbols Excel does to save and 

apply formating: 

► &P : Page Number 

► &N : Number of Pages in Document 

► &D : Current Date 

► &T : Current Time 

► &G : Graphic 

11.24.3 The Analyser Report Format 

The Analyzer can create multiple main reports and one summary report with 

information about the network file, the database file and selections the user 

has made. The main reports are: 

► Network Performance 

Network 

Performance 

► Delay 

► Movement Group Delay 

► Travel Times 

► Travel Time Delay 

► Queue Lengths 

► Volumes 

● Vehicle class: Name and number. 

● Number of vehicles: List of vehicles inserted during the simulation. 

● Travel time: Total travel time over a travel time measurement for all 

vehicles crossing this measurement. 



Delay 

● Distance: Total distance for all vehicle types and for all defined 


● Delay: Total delay for all vehicle types and for all defined simulation 

runs. 

● Avg speed: Average speed of vehicles passing the travel time 

measurement, based on shortest path and average speed. 

● Avg delay: Average delay per vehicle (in seconds), cf. definition in 

section 11.12. 

● Avg number of stops: Average number of stops per vehicle (in 

seconds). 

● Avg stop delay: Average standstill time per vehicle (in seconds). 

For a network evaluation you may not chose a special selection. This report 

always regards the entire network. 

● Intersection: Node number or name. 

● Approach: The direction of the approach of vehicles to the intersection 

as defined by node evaluation. 

● Movement: The turning movement within the intersection. 

● Delay: The average delay of all vehicles as defined in section 11.12 

● Volume: The number of vehicles recorded through the node as defined 

in 11.12 

● LOS: Level of Service of the intersection based on the Highway 

Capacity Manual (HCM) LOS categorization for signalized intersections 

(Chapter 16). The level of service is based on the signalized intersection 

definition regardless of the type of intersection. Note that 

VISSIM provides total delay as specified by the user for each node 

evaluation, while the HCM LOS designations are based on control 

delay estimated on 15 minute intervals. Refer to Section 10.2 and 

FHWA Publication No. FHWA-HRT-04-040 for more discussion on the 

comparison of simulation delay results to the HCM methodology. The 

table below lists the average delay per vehicle in seconds: 

A ≤ 10 

B > 10 - 20 

C > 20 - 35 

D > 35 - 55 

E > 55 - 80 


Movement 

Group 

Delay 

Travel 

Times 

Travel Time 

Delay 


● Average: Volume weighted Average of delay over all the runs 

● Standard Deviation: Standard deviation of the delay based on raw data 

in the database 

● Min: Minimum delay value of any vehicle as defined in section 11.12 

● Max: Maximum delay value of a vehicle as defined in section 11.12 

● Intersection name: Node names. 

● Intersection number: Node numbers. 

You can select movement groups and vehicle type groups. The report 

contains the delay by combination. 

● Name: User-defined name of the travel time section 

● Travel Time Section: Section number used to uniquely identify the 

travel time section 

● Distance: Shortest path from beginning of travel time section to end 

● Travel Time: Average travel time across a travel time section for all 

vehicles that complete the travel time section 

● Volume: Number of vehicles that complete the travel time section 

● Average: Volume-weighted average of travel time 

● Field Estimate(s): Can freely be filled. 

● Standard Deviation: Standard deviation of travel time based on raw 

data in the database 

● Min: Minimum time taken for any vehicle to complete the travel time 

section 

● Max: Maximum time taken for any vehicle to complete the travel time 

section 

● Average Speed: Average speed of the vehicles that complete the travel 

time section based on shortest path and average speed. 

● 85 th Percentile: 85 th Perzentile of speed. 

● Name: User-defined name of the travel time measurement. 

● Travel time section: Unique number of the travel time measurement. 

● Delay: Delay for all defined simulation runs. 

● Volume: Number of vehicles passing the travel time section. 

● Average: Avg travel time weighted by volume. 

● Standard deviation: Standard deviation of the travel time, based on raw 

data stored in the database. 

● Min: Minimum time measured for a vehicle passing the travel time 



Queue 

Lengths 

Volumes 

Omitted 

Nodes 

section. 

● Max: Maximum time measured for a vehicle passing the travel time 

section.. 





● Max: Maximum movement queue observed at the indicated intersection 

and approach. 

● 95% Queues: The 95 th % highest observed maximum queue. 

● Median (50% Queues): The 50 th % highest observed maximum queue. 

● Average: Arithmetically determined distribution of the maximum queue 

lengths. 

● Standard Deviation: Standard deviation of observed queue length 

based on raw data in the database 





● Run: The number of vehicles at the intersection as defined in section 

11.12. 

● Standard Deviation: Standard deviation of observed queue length 

based on raw data in the database. 

At the bottom of the report, you may see some nodes that have been 

omitted due to lack of data. These nodes did not produce any data useable 

by Analyzer. 

11.24.4 Database Tables 

There are many tables produced in the Analyzer database by VISSIM, and 

Analyzer creates temporary tables that are removed upon completion of 

report creation. For this reason Analyzer requires that you have both read 

and write access to the database file. 

Listed below are the Analyzer tables: 


VEHICLE_DATA 


Iteration Iteration Number 



TStart Time vehicle crosses start of travel time section in 

simulation seconds 


TEnd time vehicle crosses end of travel time section in simulation 

seconds 

StartLink Number of the link at start of travel time section 

StartLane Number of the lane at start of travel time section 

StartPos Link coordinate/Position of the travel time section on 

StartLink (meter/feet according to current Units) 


Movement (Bearing from-to) - use compass settings 

FromLink Number of the link entering node 

ToLink Number of the link leaving node 

ToLane Number of the lane leaving node 

ToPos Link coordinate/Position on the ToLink, link leaving node 

(meter/feet according to current Units) 

Delay Delay in seconds 

TStopd Stop Delay in seconds 

Stops Number of stops 

No_Pers Number of People 

PersDelay Average Delay per person in seconds 



QUEUE_DATA 



SimSec Simulation time (according to the user-defined Analyzer 

Sample Interval, cf. section 11.4) 


Movement (Bearing from-to) - use compass settings 

FromLink Link entering node 

FromLinkPos Link coordinate on the FromLink, link entering node 


QueueLength Queue length in time step (m/ft according to current Units) 

TRAVELTIME_DATA 



Time Simulation time 

TravelTimeSection Travel time section number 



TravelTime Travel time (in seconds) 

Delay Time delay (in seconds) 

SIMULATION 


Comment Simulation Parameters - Comment 

Period Simulation Parameters – Period 

StartTime Simulation Parameters – Start Time in format [hh:mm:ss] 

Speed Simulation Parameters – Simulation Speed [Sim.sec. / s] 

Resolution Simulation Parameters – Simulation Resolution 

RandomSeed Simulation Parameters – Random Seed; If MultiRun is 

active, this is calculated according to MultiRun parameters 

(Starting random seed, Random seed increment) 

BreakAt Simulation Parameters – Break at 

LeftSideTraffic Simulation Parameters - Traffic regulations 


0 = Right-side Traffic, 1 = Left-side Traffic 


RunIndex If MultiRun active: run index starting with 1, else if not: 0 

SearchPaths Traffic – Dynamic Assignment - Search new paths 

0= option not active/checked ([ ]), 1= option is active ([x]) 

VISSIM 


Version VISSIM version as displayed in the VISSIM main window 

Unitdistance1 View – Options – Language&Units (analogous to input 

file): 0 = m, 1 = ft 

Unitdistance2 View – Options – Language&Units (analogous to input 

file): 0 = km, 1 = mi 

Unitspeed View – Options – Language&Units (analogous to input 

file): 0 = km/h, 1 = mph 

Unitaccel View – Options – Language&Units (analogous to input 

file): 0 = m/s 2 , 1 = ft/s 2 

Date Current system date/time 

NetworkFile Input filename with complete path 

NETPERFORMANCE 


Iteration Iteration number 

VehClass 0: Default; is used in case of missing vehicle class 

> 0: Vehicle class number 

NumVehicles Number of vehicles in network 

NumArrived Number of vehicles that have left the network 

TravelTime Total travel time 

Distance Toatl distance 

Delay Total delay 

StoppedDelay Total standstill time 

NumStops Total number of stops 

AvgSpeed Average speed 

AvgDelay Average delay per vehicle 

AvgStoppedDelay Average standstill time per vehicle 

AvgNumStops Average number of stops per vehicle 



NODES 


id Node number 

Name Node name 

ControlType Control type 

Active Is the node active? Yes = 1, No = 0. 

NODELINKS 


Node Node number 

Link Link number 

PARKINGLOTS 


id Parking lot number 

Name Parking lot name 

Link Number of the link where parking lot is located 

LINKS 


id Link number 

Name Link name 

Cost Cost 

Gradient Gradient 

Lanewidth Average lane width (meter/feet according to current Units) 

Length Link length (meter/feet according to current Units) 

NumLanes Number of lanes 

Surcharge1 Surcharge1 

Surcharge2 Surcharge2 

Type Number of the link type 

LINKTYPES 



id Link type number 

Name Link type name 

VehClass 0: default, apply if no vehicle class data available 

> 0: Vehicle class number 

Behavior Driving behavior parameter set number 


VEHICLETYPES 


id Vehicle type number 

Name Vehicle type name 

Category Category (analogous to input file) 

Model Vehicle Model distribution number 

MinLength Length from (meter/feet according to current Units) 

MaxLength Length to (meter/feet according to current Units) 

Width Width (meter/feet according to current Units) 

Occupancy Occupancy 

MaxAccel Number of Max Acceleration distribution 

DesAccel Number of Desired Acceleration distribution 

MaxDecel Number of Max Deceleration distribution 

DesDecel Number of Desired Deceleration distribution 

Weight Number of Weight distribution 

Power Number of Power distribution 

VEHICLECLASSES 


id Vehicle class number 

Name Vehicle class name 




TRAVELTIMEINFO 


id Travel time section number 

Name User-defined name 

FromLink From link 

ToLink To link 

Distance Calculated the same way as in dialog. 

Set to –1.0 if not possible to calculate distance. 


11.24.5 Extras: Export to VISUM network file *.NET 

If the corresponding VISSIM network is open when you run Analyzer, 

Analyzer will try to export your *.INP file to a VISUM *.NET file with two extra 

user-defined node attributes: AnalyzerAvgDelay and AnalyzerLOS. This 

export, along with the LOS.GPA file that came with your VISSIM installation 

will allow you to graphically view the Level of Service of your selected nodes 

(see the example 'Analyzer' for an example graphics parameter file for use 

with VISUM). 

After creating the VISUM input file, open the network *.NET file in VISUM 

and open the graphics parameters (LOS.GPA) file then. 



The network and LOS ratings are based on signalized intersections. 

(Reference chart 1-a) 

11.24.6 Troubleshooting Tips 

Error Messages 

To make sure Analyzer requires little or no supervision during report 

generation, any errors that occur after the “Analyze” button is clicked will be 

written to an error log. If you have loaded an *.INP file, the error log will be 

written to that directory, otherwise it will appear in your EXE directory. 

Below is a list of Analyzer errors and what they mean: 

► Analyzer: You Must have Microsoft Excel 2002 or later installed 

Microsoft® Excel® is either not installed on your computer or is not 

version 10 (2002) or higher. 

► Analyzer: Database is corrupted or not of type mdb, Please check file 

The file that you tried to load is not an Access® database, or has been 

corrupted. 

► Analyzer: Database is incomplete, Please run simulation again 

The database is missing information or information has been modified 

outside of VISSIM. 

► Analyzer: Excel 2002 or later must be open, Please restart Analyzer 

Microsoft® Excel® has been closed or encountered an error during 

report generation. Analyzer cannot display the reports and must be 

restarted. 

► Analyzer: An error has occurred generating one of the reports. See 

AnalyzerErrorLog.txt for details 

You will see this error if a report has encountered a problem. 

► Analyzer: The selected file was not a valid Analyzer Configuration File 

The file was not an .anc file or the contents have been modified and are 

no longer valid as Analyzer Configuration settings. 

► Analyzer: Cannot generate XML while Excel is in print preview 

Excel® is in print preview mode or Excel® 2003 or later is not installed. 

► Analyzer: Please make sure PDF Creator is installed and Excel is not in 

print preview 

This error can mean that Excel® is in print preview and cannot generate 

a pdf, pdf creator is not installed, or pdf creator is installed but the printer 

name has been changed. 

► Analyzer: Excel Is not open, Analyzer cannot apply a header or footer 

Excel® is not open, there is no sheets open to add a header or footer to. 

► Analyzer: Cannot apply header or footer while in print preview. 

Excel® is in print preview mode and is blocking Analyzer from applying a 

header or footer. 

► Analyzer: There is no report open to add header or footer to. 



Excel® is not open and no picture can be applied to the header or footer. 

The following errors may appear in the error log: 

► Analyzer: A Fatal Error has occurred and Analyzer cannot finish your 

reports. 

This error generally occurs if there is a problem communicating with 

excel. Since all reports rely on communication with excel, no further 

report will be generated. 

► [Report Name]: Corrupt Data, Analyzer Cannot Continue Processing the 

[Report Name] Report 

The data in the database is not the data expected by Analyzer. This 

generally occurs when data is modified outside of Vissim. 

► [Report Name]: The Current Database is Read-Only. Please check your 

permissions. 

This error generally occurs when the database has read-only permissions, 

is moved or deleted during Analyzer processing or has been 

locked by another program. 

Performance Tips 

► Close all unnecessary applications. 

► Try reducing the number of selections in your filters. Large numbers of 

selections may cause Analyzer to have to search more of the database. 

► Having a local copy of the database you are trying to access will increase 

the speed that Analyzer can communicate with the database. 


12 Dynamic Assignment 

Without the Dynamic Assignment, routes for the simulated vehicles are 

supplied manually using the network editor. The optional Dynamic Assignment 

module however is designed to model the route choice behavior of 

drivers, thus allowing to model networks without static routes and instead 

using the specification of origin-destination matrices as flow input. In VISSIM 

the assignment is done dynamically over time by an iterated application of 

the microscopic traffic flow simulation. 

The following terminology is used when referred to Dynamic Assignment in 

this chapter: 

► path and route are used as synonyms. 

► cost in its exact meaning denotes financial cost, i.e. the component of 

the general cost that is not travel time and not distance. But cost is often 

used instead of general cost if the context allows for it. 

► general cost is the weighted sum of travel time, distance and cost. The 

general cost is what is used in the route choice model as the utility of the 

routes to choose from. 

► travel time of a route or an edge is the average time the vehicles need 

to travel from the beginning to the end of the route resp. edge in the 

current simulation. 

► smoothed travel time is computed by exponential smoothing of the 

travel times measured in the course of iterations. The smoothed travel 

time is the one that is used in the general cost function. 

► expected travel time is used if we want to express the difference 

between the travel time that is used in the route choice model at trip 

begin (that is the expected travel time) and the travel time that actually 

can be measured after the trip is completed. 



12.1 Introduction 

In the preceding chapters, the simulated vehicles followed routes through the 

network that were manually defined by the user, i.e. the drivers in the 

simulation had no choice which way to go from their origin to their 

destination. For a lot of applications that is a feasible way of modeling road 

traffic. 

However, if the road network to be simulated becomes larger it will normally 

provide several options to go from one point in the network to another and 

the vehicles must be distributed among these alternative routes. This 

problem of computing the distribution of the traffic in the road network for a 

given demand of trips from origins to destinations is called traffic 

assignment and is one of the basic steps in the transport planning process. 

Traffic assignment is essentially a model of the route choice of the drivers 

or public transport users in general. For such a model it is necessary first to 

find a set of possible routes to choose from, then to assess the alternatives 

in some way and finally to describe how drivers decide based on that 

assessment. The modeling of this decision is a special case of what is called 

discrete choice modeling, and a lot of theory behind traffic assignment 

models originates from the discrete choice theory. 

The standard procedure in transportation planning is the so called Static 

Assignment. Static here means that the travel demand (how many vehicles 

want to make trips in the network) as well as the road network itself is 

constant in time. However, in reality travel demand changes significantly 

during the day, and even the road network may have time dependent 

characteristics, e.g. signal control may vary during the day. To consider 

these time dependencies, Dynamic Assignment procedures are required. 

The motivation to include route choice in a simulation model like VISSIM is 

twofold: 

► With growing network size it becomes more and more impossible to 

supply the routes from all origins to all destinations manually, even if no 

alternatives are considered. 

► On the other hand the simulation of the actual route choice behavior is of 

interest because the impact of control measures or changes in the road 

network on route choice are to be assessed. 

The small example DETOUR.INP which can be used as an introduction to 

Dynamic Assignment is enclosed with the VISSIM installation and located in 

..\EXAMPLES\TRAINING\DYNAMICASSIGNMENT\DETOUR\. 


12.2 Principle 

Principle 

The Dynamic Assignment procedure in VISSIM is based on the idea of 

iterated simulation. That means a modeled network is simulated not only 

once but repetitively and the drivers choose their routes through the network 

based on the travel cost they have experienced during the preceding 

simulations. To model that kind of “learning process”, several tasks are to be 

addressed: 

► Routes from origins to destinations must be found. VISSIM assumes that 

not everybody uses the best route but that less attractive routes are used 

as well, although by a minor part of the drivers. That means not only the 

best routes must be known for each origin-destination relation but a set 

of routes. Ideally we would have the set of the k best routes but there are 

no efficient methods to compute this set of routes directly - at least not in 

a way that makes sense for traffic assignment. The solution adopted in 

VISSIM is to compute best paths in each repetition of the simulation and 

thus to find more than one route because traffic conditions change during 

the iteration. During the iterated simulations VISSIM builds a growing 

archive of routes from which the drivers choose. See section 12.6 for a 

detailed description of how routes are computed. 

► The routes must have some kind of assessment on which the drivers 

base their choice. In VISSIM for all routes the so called generalized costs 

are computed, i.e. a combination of distance, travel time and “other” 

costs (e.g. tolls). Distance and costs are defined directly in the network 

model but travel time is a result of the simulation. Therefore VISSIM 

measures travel times on all edges in the network during one simulation 

so that the route choice decision model in the next simulation can use 

these values. 

► The choice of one route out of a set of possible routes is a special case 

of the more general problem called “discrete choice modeling”. Given a 

set of routes and their generalized costs, the percentages of the drivers 

that choose each route is computed. By far the most frequently used 

mathematical function to model that kind of choice among alternatives is 

the Logit model. VISSIM uses a variant of the Logit model to handle 

route choice. See section 12.6.2 for a detailed description. 

The VISSIM road network model is very detailed in order to allow an exact 

reproduction of the traffic flow in a high resolution in time and space. All of 

the three tasks above do not require such a detailed model of the network, 

e.g. the choice which route to take from one side of the city to the other does 

not consider how the intersections actually look like or on which lane the 

vehicles travel. 

Assignment related problems always refer to a more abstract idea of the 

road network where the intersections are the nodes and the roads between 

the intersections are the edges of an abstract graph. The assignment 

procedures can operate much more efficiently on this type of graph and this 

level of abstraction is more appropriate even for the human understanding of 

the problem. 



Example: If we describe to our neighbor the way from its home to a 

restaurant, we tell him a series of intersections, and whether he must 

turn left or right there, but no more details. 

In VISSIM an abstract network representation is built for Dynamic 

Assignment and the user defines the parts of the network model that are to 

be considered as nodes. Normally the user will define as nodes what 

corresponds to the real-world intersections. The process of building the 

abstract network and working with it is described in section 12.3. 

The iteration of the simulation runs is continued until a stable situation is 

reached. Stable here means that the volumes and travel times on the edges 

of the network do not change significantly from one iteration to the next. In 

VISSIM this situation is called convergence and the criteria for convergence 

can be defined by the user. 

The following flow chart illustrates the principle of the Dynamic Assignment 

as explained above. 


Principle of Dynamic Assignment 

Input 

Route 

Search 

Route 

Choice 

Simulation 

& Travel 

Times 

Query 

• Load trip matrix for all OD 

• Build node-edge-graph 

• Convergence criterion 

• Max number of iterations N 

n = 0 

For all edges: set expected travel time = distance 

n = n + 1 

For all OD: Search route with minimum cost 

Add new route to the set of routes 

For all OD: Split demand onto all routes 

For all OD and all vehicles (simultaneously): 

Perform microscopic simulation 

For all edges: Calculate travel time and cost 

n >= N OR Convergence criterion fulfilled 

YES 

End of assignment 

Principle 


NO


12.3 Building an Abstract Network 

12.3.1 Parking Lots and Zones 

When using Dynamic Assignment travel demand is not specified by using 

vehicle inputs on selected links with a given volume but in the form of an 

origin-destination matrix. To define travel demand using an origin-destination 

matrix, the area to be simulated is divided in sub-areas called zones and the 

matrix contains the number of trips that are made from all zones to all zones 

for a given time interval. Thus the dimension of the matrix is: (number of 

zones) x (number of zones). 

To model the points where the vehicles actually appear or leave the road 

network, a network element Parking lot is used. A parking lot belongs to a 

certain planning zone, i.e. trips originating from this zone or ending in this 

zone can start or end at this parking lot. A zone can have more than one 

parking lot. In that case the coming or going traffic can use any of the parking 

lots belonging to a certain zone. The total originating traffic of a zone is 

distributed to its parking lots according to user defined relative flows. One 

parking lot can belong to one zone only. 

The distribution of destination traffic to the parking lots is computed by a 

choice model explained in section 12.7.2. 

Traffic starting at a parking lot is similar to traffic generated by vehicle inputs, 

but the composition of the traffic is not explicitly specified for the parking lot. 

Instead the vehicle composition is defined with the OD matrix that generates 

the vehicles entering at the parking lot. However, the desired speed for the 

vehicles leaving the parking lot is not taken from the distribution defined in 

the vehicle composition with the matrix, but it is taken from desired speed distributions 

defined locally at the parking lot. It is possible to define desired 

speed distributions for different vehicle classes at the parking lot, and there is 

always a default distribution that covers all vehicles that are not included in 

one of these classes. The reason for the local definition of desired speeds at 

the parking lot in contrast to define it globally for the matrix is to provide a 

way to model the correct speed limit on each road where traffic is originating 

from. 

Three types of parking lots are offered, which can be used for Dynamic 

Assignment. The three types show different driving behavior of the vehicles 

entering the parking lot: 

► Zone Connector: Entering vehicles do not slow down and are just 

removed from the network (parked) as they reach the middle of the 

parking lot. Thus the entry capacity is not restricted. This type should be 

used to model origin and destination points where traffic enters or exits 

the network without using real parking. Typically this is the situation at 

the borders of the modeled network. 

► Abstract Parking Lot: On approach of a parking lot vehicles slow down 

until they come to a stop in the middle of the parking lot. Then the vehicle 


Building an Abstract Network 

is removed from the network (parked) and the next one can enter the 

parking lot. This type of parking lot should be used if the road network 

model is detailed enough to represent actual parking lots. The implicit 

entry capacity can cope with up to 700 vehicles per hour and per lane 

due to detailed modeling of the stopping process. 

► Real parking spaces: For parking lots of this type, a parking space 

decision which is located 50 m before the entrance to the parking lot is 

created automatically prior to the simulation start. Numbering of parking 

space decisions starts from 10000. Activate he label display via VIEW – 

NETWORK ELEMENTS – Routing Decision. Select one of the options: 

- Number : Number of the parking space decision (> 10000). 

- Name : Number of the allocated parking lot or group. 

- Parking lot numbers: Numbers of all allocated parking spaces. 

Parking lots of the Real parking spaces type can be grouped freely. The 

automatically created parking space decisions are automatically 

combined for the parking lots belonging to the same group if they are 

located no more than 50 m apart. If a vehicle’s destination is one of the 

parking lots belonging to a group, the vehicle can select any of the 

parking lots belonging to this group. 

Accordingly, the Condition that has been selected for a routing decision 

of the Dynamic type, regards all parking lots belonging to the parking 

lot’s group. 

Example: Parking lot full = The whole parking lot group is full. 

Parking space decisions are created automatically at the simulation start. 

They can neither be listed nor edited interactively. 

Groups can freely be defined for parking lots of the Real parking spaces 

type; they are stored as parking lot property. 

Definition 

To define a parking lot follow the steps outlined below: 

1. Select the Parking Lots mode. 

2. Select a link. 

3. Mark the parking lot by dragging the mouse within the selected link while 

holding down the right mouse button. 

The Create Parking Lot window opens for data input. Set the properties and 

confirm with OK. 


For editing, this window can be accessed with a left button double-click on an 

existing parking lot on a selected link. This section deals only with the 

attributes relevant to Dynamic Assignment. For any other attribute or option 

please refer to section 6.4.5. 



[DYNAMIC 

ASSIGNMENT] 

● Zone: 

Allocated zone 

no. from OD 

matrix. To a 

zone, several 

parking lots 

can be 

allocated. 

● Group (only for 

Real parking 

spaces): 

Freely selectable 

number 

for parking lot 

grouping. Without 

a number = 

the parking lot 

does not 

belong to a 

group. 

● Capacity (only for Abstract parking lots): cf. above. 

For Real parking spaces the value results from the parking lot Length 

and the Length of each space, the displayed capacity is not subject to 

changes. 

● Initial occupancy (only for Abstract parking lots and Real parking 

spaces): The value indicates the parking lot occupancy at simulation start 

which is regarded for destination parking lot choice (also for dynamic 

routing decisions) calculation. Furthermore, it is used to determine if a 

parking lot is full. The initial occupancy should not include vehicles that 

arrive at the parking lot within the simulation period and might leave from 

there later (could be contained in matrices). For Real parking spaces, the 

composition of the initial occupancy is listed. 

● Composition (only for Real parking spaces): For the initial occupancy, 

select the appropriate vehicle composition, cf. section 6.4.1. 

● Rel. flow: Only relevant, if a zone has multiple parking lots: Percentage of 

the zone´s total demand, e.g. value 0 = no demand, (e.g. if a parking lot 

is located on a link having no successor). The values of several parking 

lots per zone are summed up and the total is set = 100%, then the appropriate 

share per parking lot is caluclated. 

● Desired Speeds: Desired speed distributions allocated to vehicle classes. 

Default: just a single vDes-distribution for all classes. 

● Label: When showing labels of all parking lots (see VIEW - NETWORK 


one. Options for parking lot labels: Number, Name, Zone no., Group no., 

Occupancy and Parking Availability. 



When modeling parking lots at the borders of a network, a 

single node on the border can be used for correctly placing both 

the origin and the destination parking lot (see illustration). 

Parking lots must be placed on an edge between two nodes. They may 

also be placed inside of an internal node (a node that is not situated at the 

border of the network). 

No more than one parking lot must be placed between any two nodes or 

within a node. 

A parking lot blocks the road in terms of path search: There are no paths 

that include a link that leads through a parking lot (i.e. where the parking lot 

would be ignored). 

If a parking lot (for destination traffic only) is placed on an outgoing link of 

the network, i.e. a link from which no other parking lots can be reached, 

then the relative flow of the parking lot must be set to zero. Make sure that 

there is at least one node on both sides of the parking lot. 

The cost for each edge where a parking lot is placed on, is determined as 

the average cost of all vehicles traveling into and out of the parking lot. 

CTRL+SHIFT+C sets the relative volumes of all parking lots to the volume 

totals of their paths as contained in the current path file (*.WEG). This can 

be helpful, if a new volume scenario (new matrix and path file) is to be 

applied to a network which was originally exported from VISUM, since 

relative volumes of origin parking lots might fit significantly better this way. 

Potential traps 

If you get an error message similar to "The destination parking lot 10 is part 

of several different edges", typically at least one node is missing or placed 

incorrectly. That results in multiple paths being found between the two nodes 

where the parking lot is placed, and for each path a separate cost is 

evaluated. On rare occasions, this could result in multiple different link costs 

for the same stretch of physical road and thus would lead to a wrong 

distribution of vehicles. 

To solve this problem, locate that parking lot in the VISSIM network and 

ensure, that 

► both, the path diverge point before the parking lot as well as the path 

merge point after the parking lot (in direction of driving) are included in a 

node and 

► both the nodes, where the parking lot is placed in between, are modeled 

correctly in terms of including the path diverge/merging point 



Right clicking outside the VISSIM network in parking lot mode opens a window 

with a list of all parking lots in the network. Then the data of the parking 

lot can be accessed via the EDIT button. Pressing the ZOOM button moves 

the view position to show the selected parking lot in the network. 

12.3.2 Nodes 

The road network model in VISSIM is very detailed with respect to geometry. 

For route choice decisions this level of detail is not required since it does not 

matter to a driver what a certain junction looks like as long as he is allowed 

to perform the turning movements needed to follow his desired route. 

In order to reduce the complexity of the network and thus to reduce 

computing time and storage for paths it is sensible to define some parts of 

the VISSIM network as nodes, i.e. those parts of a network where paths 

could diverge. In general these nodes will be equivalent to what is normally 

described in the real world as a “junction”. Nodes also need to be defined at 

the ends of the links at the border of the network. 

VISSIM provides two types of node definition: 

► as polygon node or 

► as link segments. 

To define a node you may 

► manually create a polygon or 

► import an ANM file from VISUM with segment nodes. 

A polygon node can be converted into a segment node and vice versa. 

Node definition as link segments allows for detailled graphical changes to the 

node or its segments, respectively, cf. section 12.3.2.4. 

Nodes may not overlap. 

When opening a network file *.INP that contains overlapping nodes and 

also if an overlapping node is created, an error message appears. In the 

protocol window (which provides also zoom functionality) the numbers of 

the overlapping nodes are listed, cf. section 10.2.1. 

Identical attributes and options are provided for polygon nodes and 

segment nodes. Also the colors of polygon nodes and segment nodes 

indicate the same state. 

Dynamic Assignment regards polygon nodes and segment nodes in the 

same way. 


In the network file, node data is stored as follows: 

-- Nodes: -- 

------------ 


NODE 3 NAME "Polygon" LABEL 0.00 0.00 

EVALUATION NO 

NETWORK_AREA 4 -513.486 955.289 -496.780 926.808 -433.519 952.277 -448.033 989.795 

NODE 4 NAME "Segments" LABEL 0.00 0.00 

EVALUATION NO 

NETWORK_AREA 

LINK 3 FROM 0.000 UNTIL 21.500 





LINK 26 

LINK 39 

LINK 58 




LINK 344 

LINK 345 

LINK 10003 

LINK 10004 

LINK 10005 

LINK 10006 

LINK 10007 

LINK 10022 

LINK 10106 

LINK 10107 

LINK 10421 

LINK 10484 


1. Select the Nodes mode. 

2. Start to draw a polygon around the area to be defined as a node by 

dragging the mouse while holding down the right mouse button. 

Subsequent points to shape a node can be created by clicking the right 

mouse button. Double-clicking finishes the polygon. 

The Node window opens for data input. Set the properties and confirm with 

OK. 

Definition of overlapping nodes is not permitted. 

Alternatively, nodes can be imported via ANM Import, cf. section 6.2.1.4. 

ANM Import always creates segment nodes. 



You may convert the current node definition (polygon or segments) into the 

respective other node definition, cf. section 12.3.2.5. 

Any conversion is always followed by automatic adjustment of the new 

node definition which can be edited by the user subsequently. 


● No.: Node number 

● Name: Optional name or comment 

● Label: When showing labels of all nodes (see VIEW - NETWORK 


one. 

● Node evaluation: If option Node is checked via EVALUATION – FILES, 

then the node is regarded for evaluation if this option is active. 

● Dyn. Assignment: If this option is active, the node is regarded for the 

network graph during Dynamic Assignment. 

If this option is not active, the node is ignored for the network graph 

during Dynamic Assignment. Nevertheless it can be used for node 

evaluation, as long as the particular option has been set. 

In the Edge selection window only those nodes are displayed for which 

option Dyn.Assignment has been checked, cf. section 12.3.3. 

● User-defined orientations: Check this option to overwrite the 

orientation that is automatically determined from the intersection coordinates 

of the node polygon and the edge leading to the neighboring 

node if this VISSIM orientation does not match reality. 

In the Orientations table, the Neighbor column contains the list of the 

selected node’s neighboring nodes in the network. Select one of the 

table rows and select the appropriate orientation from the drop-down list 



of orientations provided in the Orientation column: N, NE, E, SE, S, SW, 

W, NW. 

This functionality is especially helpful in case of multiple edges leading to 

the same neighboring node since VISSIM might have determined an 

unrealistic orientation. By default, VISSIM uses the most frequently 

appearing orientation in case of numerous edges. In case of just two 

edges to the same node VISSIM uses the one that occurs first in the 

clock-wise list of orientations (see list above). 

The evaluation graph for the computation of the orientations regards only 

the nodes which meet the following two requirements: 

► For each pair of neighboring nodes, option Node evaluation has to 

be checked. If this is not the case for all nodes in the network, the 

resulting graph will be incomplete. 

► The distance between neighboring nodes may not exceed 500 m. In 

case of a longer distance between neighboring nodes we recommend 

to create an additional node in between. 

The evaluation graph for the computation of the orientations is based on 

the current North direction in the network. For your network, you can set 

the North direction via VIEW – OPTIONS - [NETWORK] option Display Compass, 


12.3.2.3 What the Colors Mean 

Standard 

Selection 

In the unselected state, the color code applies to node polygons as well as 

to segment nodes in the network. 

The particular color of a node in the network display indicates certain 

properties of this node. 

Color Meaning in the unselected state 

White Neither option Node evaluation nor option Dyn. assignment has 

been checked. 

Red Option Dyn. assignment has been checked, whereas option 

Node evaluation has not. 

Green Option Node evaluation has been checked, whereas option 

Dyn. assignment has not. 

Black Both options Node evaluation / Dyn. assignment have been 

checked. 

In the selected state, polygon nodes and segment nodes show a different 

behavior. 

Nodes Display in the selected state 

Segment node The segments always appear yellow, regardless of the 



Multi 

Selection 


Nodes Display in the selected state 

segment node´s color in the unselected state. 

Polygon node The vertices of the polygon appear in the appropriate color. 

The node color does not change. 

Polygon nodes and segment nodes are always displayed in black color, in 

the selected state as well as in the unselected state. 

Select the Nodes mode. 

► For data editing, the single-select mode is required. 

► For deleting, also the multi-select mode can be applied. 

The selection list always contains all nodes of any node definition (polygon 

nodes and segment nodes). 

Overlapping nodes may not result from editing a segment node or a 

polygon node. 

Node processing functions provided for either polygon nodes or segment 

nodes only are indicated accordingly. 

Select Single selection 

A node you may pick from the selection list or in the network display: 

► Network display: Left-click at any position within the node 

- Polygon node: inside polygon 

- Segment node: on any segment or inside the invisible rectangular 

box surrounding the node segments 

► List display: Left-click the desired row. 

The selected node is highlighted accordingly, cf. section 12.3.2.3. 

For some of the processing functions, the mouse pointer will change 

appropriately which is decribed with the particular editing function. 

Multi-selection 

Activate the Multiselect mode, span a rectangle to select the nodes roughly 

and (de-)select individual nodes, if necessary, cf. section 3.3.2.1 

Move 

polygon 

Copy 

polygon 

Select a polygon node, the hand symbol will appear while the pointer is 

moved over the node: 

Keep left mouse-button pressed while dragging the node to the desired 

position. Link courses remain unchanged. 

Select a polygon node, the hand symbol will appear while the pointer is 

moved over the node: 

Hold down CTRL and keep left mouse-button pressed while dragging the 

copied node to the desired position. Link courses remain unchanged. 


Edit 

polygon 

Edit 

segments 


Select a polygon node: 

► Add polygon point: On the polygon-defining line, place the pointer 

exactly where you want to add another polygon point. As soon as the 

pointer is no longer shown as a hand, but as a reticle, you may define 

the new point by right-click. 

► Shift polygon point: Place the pointer on the point you want to shift to 

another position. As soon as the pointer is no longer shown as a hand, 

but as a reticle with arrowheads, you may drag the point to the desired 

position while holding the left mouse-key down. The course of the 

polygon is aligned accordingly. 

► Remove polygon point: Place the pointer on the point you want to 

delete from the polygon. As soon as the pointer is no longer shown as a 

hand, but as a reticle with arrowheads, you may drag the point to a 

neighbouring polygon point while holding the left mouse-key down. A 

new line is formed from the former neighbouring polygon lines. The 

course of the polygon is aligned accordingly. 

Select a segment node: 

► Select link: CTRL - Left-click selects the link, where 

- you want to add a segment or 

- the segment you want to edit is located. 

The start cross section is marked dark red and the end crosssection 

is marked dark green in with-flow direction of the link. 

Connectors appear more narrow compared to links. 

► Add segment: Right-click in the selected link to create another node 

segment by adding the selected link completely to the segment node. If 

the link already contains a segment of the node, the length of the 

segment will be set to link length. 

In both cases, the segment length can be edited subsequently. 

► Select segment: Left-click on a cross-section of the segment. The start 

cross section will be highlighted light red (end cross-section: light 

green). 

► Remove segment: Drag the selected cross-section away from the link 

while holding left mouse-key down. As soon as the mouse-key is 

released while the pointer is placed anywhere in the network display 

(but not on the link) the segment is removed from the segment node 

definition. 

To delete a segment with segment length = link length, right-click in the 

selected link. 

► Edit segment length: Drag the selected cross-section to the desired 

position on the link while holding left mouse-key down. 

► Stretch segment to start/end of link: Right-clicking the selected 

cross-section automatically places the selected cross-section on the 

link´s start or end. 

► Set segment length = link length: After right-clicking the selected link 

the length of the link segment will automatically cover the link length 

completely. 



Edit data 

Convert 

Be aware of keeping the consistency of internal relations when editing the 

segments of a node. 

If a link contains two segments belonging to different nodes, these 

segments may not overlap. 

► Select node in 

- Network display: Double-click calls the Node window. 

- List display: Clicking DATA calls the Node window. 

► Any input properties (attributes and options) are subject to changes, cf. 

section 12.3.2.2. 

► Select node in network display, 

► Right-click within node, 

► Confirm CONVERT, cf. section 12.3.2.5. 

Delete Single-selection: 

Select node 


- DEL or 


► or in the selection list; then click 

DELETE. 

Multi-selection: 

► Define network section 

(active elements) 


- DEL or 

- EDIT - DELETE, 

► finally 





- 


12.3.2.5 Converting a Node 

Select 

polygon 

Convert 

Select and 

convert a 

segment 

node 

Follow the outlined steps: 

► Select the node, its polygon points will be highlighted. 

► Place the pointer inside the polygon. 

The pointer has to be a hand symbol. 

► Right-click to call the query and 

► confirm CONVERT. 

The converted polygon is now displayed as 

segments on links covering the original 

dimensions of the original node polygon. 

For further processing you may 

► select a link via CTRL - Left-click or 

► re-convert via right-click. 


Converting 

► a polygon node into a segment node creates exactly the segments 

being located in the former polygon; 

► a segment node into a polygon node enlarges the size of the poygon. 

► Select the node: its segments are 

highlighted in red. 

► Call the query via right-click and 

► confirm CONVERT. 

The node poygon is created. 



Manual 

adjustment 

Position and size of the polygon are determined by position and size of the 

segments: A horizontally-based quadratic polygon with 4 corners is 

calculated. Thus the polygon fully covers all of the segments totally. The 

horizontal bottom line is drawn directly underneath the undermost point of 

all segments and the vertical line to the right is drawn directly to the right 

from the segment point which is located outermost right. The segments 

inside of the polygon do not necessarily match the initial segments. 

From node conversion, overlapping 

nodes might result. In this case, a 

warning will appear. 

► For manual adjustment of a 

polygon definition cf. Edit polygon 

in section ●. 

► For manual adjustment of a 

segment definition cf. Edit 

segments in section ● 

Example Converting a node multiple 

times will cause the following: 

► The size of the node 

polygon will increase. 

► Further segments are 

added to the segment 

definition or the size of the 

segments is stretched, 

respectively. 

12.3.3 Edges 

From the information given by the user’s definition of nodes, VISSIM builds 

an abstract network graph as soon as the Dynamic Assignment is started. 

The graph consists of what we will call “edges” to distinguish them from the 

“links” the basic VISSIM network is built from. 

There are two types of edges: 

► Edges inside nodes (intra-node edges) 

► Edges between nodes 

The semantics of the graph that is built from the nodes is slightly different to 

conventional travel model network graphs (e.g. in software products like 

VISUM or EMME2): 



► There can be more than one edge between two nodes 

► The intra-node edges represent the turning movements but they have a 

real length in VISSIM 

The edges are the basic building blocks of the routes in route search, i.e. a 

route is a sequence of edges. For all the edges travel times and costs are 

computed from the simulation providing the information needed for the route 

choice model. 

The edges automatically constructed by VISSIM can be visualized in the 

following way: 

1. In the Nodes edit mode you can call the Edge Selection window via 

EDIT – EDGE SELECTION... if the network contains at least one node with 

active option for Dyn. Assignment. 

If a node is currently selected in the network when the Edge selection 

window is called, this node will also be selected in the window´s selection 

lists. 

The lists in the Edge selection window contain only those nodes for which 

option for Dyn. Assignment has been checked. 

2. In the window, choose a pair of nodes by selecting the numbers from the 

From Node and To Node lists. 

3. From the top list of all available edges between the selected nodes, 

choose an edge to show its graphical representation in the VISSIM 

network (as a yellow or red band). 



Edge attributes: 

● generated No., 

● vehicle type specific cost Value, 

● Length 

● Volume of the total flow for the 

selected Time Interval 

● Current Closures and the selected 

vehicle type(s) are indicated. 

Edge closures can be defined or discarded 

via 

● Edge closed (for the selected 

edge) 

● OPEN/CLOSE ALL EDGES buttons. 

In the list, an edge can be selected for graphical display in the VISSIM 

network. 

Automatically created VISSIM edges are highlighted in the network display: 

► Yellow = not closed or 

► Red = closed for Dynamic Assignment 

The paths shown in the window result 

from the last iteration where the path file 

was updated. The costs shown are 

taken from the last cost file that was 

written. 

Thus the Edge Selection window only 

then shows the results of the last 

iteration, if both the cost and path files 

were written during that iteration. 

In the Edge selection window, the results of the recent iteration can only be 

displayed if cost and path data was saved to *.BEW and *.WEG file during 

this iteration. 



An edge can be banned completely from being used with Dynamic 

Assignment by selecting the option Edge Closed while the respective 

edge is selected. The edge is then shown in red. 

An edge between nodes is ignored in the Dynamic Assignment if it contains 

more than three connections (possibly across several connectors) from a 

link back to the same link. Cost and path files from VISSIM 5.20 which 

contain such edges cannot be used anymore. 

An edge is ignored in the Dynamic Assignment if it contains more than one 

parking lot extending over all lanes (i.e. zone connectors and abstract 

parking lots on any link and real parking spaces on one-lane links only, cf. 

section 12.3.1). Cost and path files from VISSIM 5.20 which contain such 

edges cannot be used anymore. 

12.3.4 Check Nodes/Edges 

The node/edge structure is checked for errors, such as overlapping nodes. 

For this step, the Nodes editing mode needs to be active. 

Nodes and edges are checked as 

follows: 

1. Click the Nodes editing mode. 

2. Click menu EDIT – CHECK NODES 

/ EDGES 

The node/edge structure is 

checked. 

12.3.4.1 Correction of Overlapping Nodes 

Nodes may not overlap. 

VISSIM will show an error message if a network file *.INP containing 

overlapping nodes is opened or if a node is defined that overlaps the polygon 

of a neighbouring node. 

Solution in VISSIM 

The error message and the numbers of the overlapping nodes are listed in 

the log window. 



1. To open the log window, click menu HELP – 

LOG WINDOW or CTRL+SHIFT+F10. 

2. Click the particular record to place the 

overlapping nodes automatically in the 

middle of the screen. 

3. Move the polygon points in a way that they no longer will overlap. 

4. Click menu EDIT – CHECK NODES/EDGES to perform another check. 

A message will confirm the 

successful build of the node/edge 

structure. 

12.3.4.2 Correction of Multiple Edges Between Two Nodes 

In VISSIM, multiple edges connecting two nodes are permitted for Dynamic 

assignment. 

For export to VISUM, only the shortest edge is regarded. 

VISSIM warnings can be ignored in case of two nodes which are 

connected by multiple links of almost the same length and link sequence. 


In the log window, the error message and the numbers of the involved nodes 

are listed. 



If you do not want to resign those edges, you can do the following: 

1. Click the Node mode. 

2. On the longer edge, right-click to define 

a new node. 

This way you have created two new 

links and their nodes are not identical. 

3. Start the export to VISUM again. 

Call the list of all edges of a Dynamic Assignment via menu EDIT – EDGE 

SELECTION, it is displayed in the Edge selection window, cf. section 12.3.3. 

12.3.4.3 Correction of Unexpected Start/End of Nodes 

Nodes can be created from link segments, cf. section 12.3.2. When building 

a node/edge structure via CHECK NODES/EDGES, an error message is 

displayed if the end or the start of a node cannot be used for the building 

process. VISSIM offers to fix damaged link segments. 


Click OK to confim the error messages. The VISSIM window suggests how 

to rebuild the nodes. 

There are two options provided: 

1. Form a node polygon from link segments. 

2. Edit link segments. 



The buttons serve for node repair: 

► YES: Confirm the suggestion for the particular node. 

► YES TO ALL: Confirm the suggestion for all damaged nodes. 

Changes performed via the YES TO ALL button should be verified in the log 

window subsequently. Each repair action executed by VISSIM is logged to 

the protocol. 

► NO: You do not agree. The node remains damaged. 

► NO TO ALL: This option is not provided. Click CANCEL to terminate the 

repair action. 

► CANCEL: You terminate though not all of the damaged nodes have been 

repaired yet. Repaired nodes are retained, these changes will not be 

discarded. 

Once all nodes have been repaired a 

message confirms the successful build 

of the node/edge structure. 

In rare cases, not all of the nodes are rebuilt automatically. In this case, 

you need to fix those nodes manually. 


12.4 Traffic Demand 

Traffic Demand 

In Dynamic Assignment traffic demand is typically modeled using origindestination 

matrices (OD matrices). Beyond that it is also possible to define 

the demand in a trip chain file. It is also possible to mix both options. 

Furthermore both options can be combined with traffic defined by vehicle 

inputs and static routes (e.g. for pedestrian flows). However, this kind of 

traffic is not affected by the Dynamic Assignment. 

12.4.1 Origin-Destination Matrices (OD matrices) 

The volume of traffic to be simulated in the network is specified as origindestination 

matrices. Such an OD matrix contains the number of trips for 

every pair of planning zones for a given time interval. For a simulation using 

Dynamic Assignment, a number of matrices can be defined, each containing 

demand information for a certain vehicle composition for a certain time 

interval. Time intervals of different matrices may overlap arbitrarily; the 

generated traffic for every moment comprises the vehicles from all the 

matrices that include that moment in their time interval. 

OD matrices are specified in the Dynamic Assignment window that can be 

accessed by selecting TRAFFIC - DYNAMIC ASSIGNMENT... 

Check the option Matrices to 

activate the associated list box. 

Use EDIT, NEW and DELETE to 

define or edit an entry in the list 

box or to remove it from the list. 

A matrix is linked to a given vehicle composition, i.e. the trips of that matrix 

are performed by vehicles randomly generated from the associated vehicle 

composition. As explained in the section Parking lots, the desired speed 

distribution for the generated vehicles is not taken from the composition 

defined with the matrix but is overruled by the desired speed distribution 

defined with the parking lot where the vehicle starts its trip. 

The matrices cannot be edited directly using the VISSIM user interface but 

are stored in text files and can be edited with standard text editors. The 

matrices can be exchanged easily between VISSIM and VISUM via VISUM 

export from VISSIM and ANM export from VISUM. However, these files can 

also be created manually or converted from other transport planning 

systems. 



Matrix file format (*.FMA) 

Below follows the description of the format of OD matrix files (*.FMA). 

► All lines starting with an asterisk (*) are treated as a comment and are 

not mentioned here. 

► Time interval (hh.mm) for which the matrix is valid. 

Examples: 

1.3 reads as 1 hour 3 minutes (and not as 1 hour 30 minutes) 

1.30 reads as 1 hour 30 minutes 

1.50 reads as 1 hour 50 minutes (and not as 1 hour 30 minutes) 

(This format was chosen for reasons of compatibility to other systems.) 

The time information in the matrix is the absolute time of day. Therefore in 

the VISSIM Simulation Parameters the start time needs to match the start 

time used in the desired matrix. 

► Scaling factor. This factor can be used to scale the matrix globally 

► Number of zones 

► Zone numbers of all zones that are used in the matrix 

► Flow data. The data is interpreted as total number of vehicles per time interval 

defined in the header (not necessarily the number of vehicles per 

hour). 

The first line contains all trips from the first zone to all other zones in the 

order given with the definition of the zone numbers. The next line 

contains all the trips from the second zone to all others and so on. 

Example of an OD matrix 

Example reading: From zone 20 to zone 30, 190 trips are defined for the 

period of 1½ hours (from 0:00 to 1:30). 

* time interval [hh.mm] 

0.00 1.30 

* scaling factor 

1.0 

* number of zones: 

8 

* zones: 

10 20 30 40 50 60 70 80 

* number of trips between zones 

0 180 200 170 60 120 150 200 

170 0 190 140 110 160 120 180 

190 250 0 90 130 170 130 100 

200 200 180 0 140 110 110 150 

150 100 120 130 0 30 190 160 

20 180 260 100 10 0 140 170 

140 190 120 100 180 130 0 120 

190 170 90 140 150 160 110 0 


12.4.2 Trip Chain Files 


With Dynamic Assignment it is also possible to supply traffic demand of a 

simulation with trip chains. In contrast to OD matrices a trip chain file allows 

to supply the simulation with more detailed travel plans for individual 

vehicles; however, the coding effort is much higher. 

VISSIM internally works with trip chains only. If OD matrices are used, a preprocessing 

algorithm generates trip chains from these matrices. Thus it is 

possible to mix traffic demand by OD matrices and trip chains in the same 

simulation. 

To provide traffic demand with 

trip chains, in the Dynamic 

Assignment window check the 

option associated with the button 

TRIP CHAIN FILE. Then press TRIP 

CHAIN FILE and select a single 

file with the extension *.FKT. 

A trip chain file contains a set of 

individual-vehicle travel definitions 

(trip chain), each one 

composed of one or more trips. 

A trip chain is associated with a vehicle and identified by three numbers: 

► Vehicle number 

► Vehicle type 

► Origin zone number 

After this “header” one or more trips follow. A trip is defined by a group of 

numbers – four numbers in data format 1.1 or five numbers in data format 

2.1: 

► Departure time 

► Destination zone number 

► World coordinates of the destination (format version 2.1 only) 

► Activity number 

► Minimum stay time 

The departure time of the next trip depends on the arrival time in that zone 

and on the minimum stay period for this activity. The specified departure time 

for the next trip will be taken in account only if the minimum stay time is 

guaranteed: If a vehicle arrives too late the departure time is corrected to the 

sum of the actual arrival time plus the minimum stay time. 

Trip chain file format (*.FKT) 

The trip chain file (*.FKT) is line oriented, i.e. each line specifies a trip chain 

(a sequence of trips for an individual vehicle). The actual trips of a trip chain 

are formatted as groups of columns separated by semicolon: 

► The first three columns specify the vehicle number and type and its origin 

zone. 



► With data format version 1.1, each subsequent group of four columns 

defines one trip within the trip chain. 

► With data format version 2.1, each subsequent group of five columns 

defines one trip within the trip chain. Between the destination zone 

number and the activity number it contains the destination world coordinates. 

- These coordinates in parentheses are used instead of the center of 

the destination zone for the component "Distance from desired zone" 

in the parking lot selection. 

- If the coordinates of the center of a zone should be regarded with 

data format version 2.1, enter [] instead of the world coordinates. 

In the first line of the trip chain file, the data format version number has to 

be set. 

The format description follows in BNF (Backus-Naur-Form). 

Specific version 2.1 entries are gray-shaded: 

::= {} 

::= 

::= {} 

::= 

::= 

::= 

::= 

::= 

::= 

= 

| 

= 

= 

= "," 

= "(" 

= ")" 

= "[" 

= "]" 

::= 

::= 

::= new line 

::= semicolon (;) 

::= positive integer (for example: 23) 


::= floating point number (for example: 3.14) 

Example of *.FKT file in version 1.1 data format 

This example file (*.FKT) contains 11 trip chains. 

1.1 

1; 1; 10; 1; 20; 101; 117; 211; 30; 101; 169; 732; 20; 101; 171; 

2; 1; 10; 4; 20; 101; 255; 334; 30; 101; 147; 815; 20; 101; 124; 

3; 1; 10; 8; 20; 101; 202; 395; 30; 101; 178; 832; 20; 101; 175; 

4; 1; 10; 12; 20; 101; 216; 703; 30; 101; 162; 533; 20; 101; 208; 

5; 1; 10; 16; 20; 101; 164; 601; 30; 101; 251; 1134; 20; 101; 159; 

6; 1; 10; 20; 20; 101; 295; 529; 30; 101; 133; 846; 20; 101; 114; 

7; 1; 10; 25; 20; 101; 248; 262; 30; 101; 256; 987; 20; 101; 117; 

8; 1; 10; 29; 20; 101; 169; 322; 30; 101; 164; 463; 20; 101; 141; 

9; 1; 10; 31; 20; 101; 138; 543; 30; 101; 212; 405; 20; 101; 252; 

10; 1; 10; 35; 20; 101; 296; 205; 30; 101; 160; 802; 20; 101; 221; 

11; 1; 10; 40; 20; 101; 270; 622; 30; 101; 244; 604; 20; 101; 175; 


Example of *.FKT file in version 2.1 data format 

This example file (*.FKT) contains 11 trip chains, with destination world 

coordinates specified for zone 20 only. 

2.1 

1; 1; 10; 1; 20; (113.0,157.0); 101; 117; 211; 30; []; 101; 169; 732; 20; 

(105.0,159.0); 101; 171; 

2; 1; 10; 4; 20; (102.0,160.0); 101; 255; 334; 30; []; 101; 147; 815; 20; 

(128.0,153.0); 101; 124; 

3; 1; 10; 8; 20; (126.0,163.0); 101; 202; 395; 30; []; 101; 178; 832; 20; 

(117.0,182.0); 101; 175; 

4; 1; 10; 12; 20; (128.0,153.0); 101; 216; 703; 30; []; 101; 162; 533; 20; 

(103.0,155.0); 101; 208; 

5; 1; 10; 16; 20; (114.0,174.0); 101; 164; 601; 30; []; 101; 251; 1134; 20; 

(113.0,157.0); 101; 159; 

6; 1; 10; 20; 20; (105.0,159.0); 101; 295; 529; 30; []; 101; 133; 846; 20; 

(120.0,172.0); 101; 114; 

7; 1; 10; 25; 20; (117.0,182.0); 101; 248; 262; 30; []; 101; 256; 987; 20; 

(102.0,160.0); 101; 117; 

8; 1; 10; 29; 20; (119.0,157.0); 101; 169; 322; 30; []; 101; 164; 463; 20; 

(121.0,160.0); 101; 141; 

9; 1; 10; 31; 20; (121.0,160.0); 101; 138; 543; 30; []; 101; 212; 405; 20; 

(119.0,157.0); 101; 252; 

10; 1; 10; 35; 20; (120.0,172.0); 101; 296; 205; 30; []; 101; 160; 802; 20; 

(126.0,163.0); 101; 221; 

11; 1; 10; 40; 20; (103.0,155.0); 101; 270; 622; 30; []; 101; 244; 604; 20; 

(114.0,174.0); 101; 175; 



12.5 Simulated Travel Time and General Cost 

12.5.1 Simulation Period and Evaluation Interval 

The microscopic simulation of the traffic flow is used during the Dynamic 

Assignment to determine travel times in the network. This travel time 

measurement is performed per edge and per evaluation interval. 

In Dynamic Assignment, as opposed to static assignment, travel demand 

and network infrastructure are not assumed to be constant in time. Therefore 

the traffic situation and as a result the travel times will change during the 

assignment time period. To cover these changes the total simulation period 

is divided in smaller evaluation intervals in which travel times are observed 

separately. The appropriate size of the evaluation interval depends on the 

dynamics of the travel demand. The evaluation interval should be smaller 

than the interval in which the demand changes. 

Example: If you have OD matrices with intervals of 1 hour, the evaluation 

interval should not be longer than half an hour. 

As a rule of thumb, evaluation should have at least the double temporal 

resolution of the demand changes. 

On the other side, an evaluation interval below five minutes does not make 

sense because the fluctuation of the values will increase with smaller 

intervals. Especially when signal controls are used the evaluation interval 

must be significantly longer than the cycle times used. 

In most cases, evaluation intervals ranging from 5 to 30 minutes will be 

appropriate. 

12.5.2 Simulated Travel Times 

During a simulation, travel times are measured for each edge in the network. 

All vehicles that leave the edge report the time they have spent on the edge. 

All travel times during one evaluation interval are averaged and thus form the 

resulting travel time for that edge. There is a special treatment of vehicles 

that spend more than one evaluation period on an edge, e.g. during 

congestion. They report their dwell time as well although they have not left 

the edge. That is necessary to get information about heavily congested links 

even if there is - because of congestion - no vehicle able to leave. 

The travel time measured in the current iteration n is actually not used 

directly for route search and route choice in the same iteration. Instead it 

influences next iterations. This behavior is sensible since we normally do not 

want the travel times during 8 a.m. and 9 a.m. on Tuesday to influence route 

choice for the time from 9 a.m. to 10.a.m. the same day but rather to 

influence the same period, i.e. 8 to 9 on the next day. 


Simulated Travel Time and General Cost 

To model a growing experience of travel times the times not only from the 

immediately preceding iteration should be considered but from all preceding 

iterations. 

► However, if you want the older measurements to have less influence, the 

appropriate mathematical method for that is exponential smoothing. The 

user-defined smoothing factor indicates the relative weight of the respective 

recent iteration. 

► Alternatively, MSA (Method of Successive Averages) can be applied 

which assigns as much weight to any recent iteration as to the current 

one by forming the arithmetic mean from all iterations. This way, the 

influence of any further iteration is reduced. As long as no *.BEW file is 

available, the parameter value is set automatically in VISSIM (not userdefined), 

if this option is active. In case of an existing *.BEW file the user 

has to enter the number of iterations calculated for this file. Here, also a 

value below the actual number of current iterations can be entered to 

increase the influence of the next iterations. This is recommended, if the 

path evaluation states that the measured travel times deviate heavily 

from expected travel times, cf. section 11.21. 

The appropriate method can be selected and the parameters can be set via 

TRAFFIC - DYNAMIC ASSIGNMENT via EXTENDED in the Dynamic Assignment 

window, if option Store costs is active. 

If option Store costs is active, the expected travel times for the next iteration 

are stored in the VISSIM cost file (*.BEW) after an iteration of the simulation 

in order to provide a base for the route choice in the next iteration. 

Exponential Smoothing 

If we get a new set of measured values, we compute the smoothed travel 

time as the weighted sum of 

► the old smoothed value (from previous iterations) and 

► the newly measured value (from current iteration). 

That smoothed value represents the travel time that we expect in the next 

iteration. 

Formally: 

T 

n, 

κ 

( 1 α ) T 

n 1, 

κ 

α TO 

n, κ 

i 

= − ⋅ 

− 

i 

+ ⋅ 

i 

where 

K = index of the evaluation interval within the simulation period 

n = index of the assignment iteration 

i = index of the edge 



TO 

n, 

κ 

i 

= measured (”observed“) travel time on edge i for period k in 

iteration n 

T 

n, 

κ 

i 

= expected travel time on edge i for period k in iteration n 

α = constant smoothing factor (user-defined). 

Please note that this kind of smoothed average of travel times includes the 

information of all preceding iterations but the “older” an iteration is, the less it 

influences the measurements of the current iteration. If a smoothing factor of 

0.5 is used, the last iteration n has a weight of 50%, iteration (n-1) has a 

weight of 25%, iteration (n-2) has a weight of 12.5% and so on. 

MSA 

With a new set of measured values, the smoothed travel time is computed as 

the weighted sum of 

► the old smoothed value (from previous iterations) and 

► the newly measured value (from current iteration). 

That smoothed value represents the travel time that we expect in the next 

iteration. 

Formally: 

κ 1 κ 1 

T 

n, 

( 1 ) 

n 1, 

TO 

n, κ 

i 

= − ⋅T 

− 

N n i 

+ ⋅ 

+ 

N + n i 

where 

N = user-defined value 

K = index of the evaluation interval within the simulation period 

n = index of the assignment iteration 

i = index of the edge 

TO 

n, 

κ 

i 

= measured (”observed“) travel time on edge i for period k in 

iteration n 

T 

n, 

κ 

i 

= expected travel time on edge i for period k in iteration n 

1 

= variable smoothing factor resulting from parameter N and the 

N + n 

index of the iteration 

12.5.3 General Cost 

Travel Time is not the only factor to influence route choice. There are at least 

two other major influences: travel distance and financial cost (e.g. tolls). In 

contrast to travel times these factors are not depending on the traffic 

situation and thus have not to be determined by simulation. 


Simulated Travel Time and General Cost 

To cover all three major influences on route choice, for each of the edges in 

the network the so called general cost is computed as a weighted sum: 

general cost = α • travel time + β • travel distance + γ • financial cost + 

Σ supplement2 

The coefficients α, β and γ can be defined by the user. In VISSIM the weights 

are specific to vehicle types and allow the modeling of driver groups with 

different route choice behavior. 

The travel distances are determined by the geometry of the links. The 

financial cost of an edge is the sum of the costs of all links that are contained 

in that edge. The individual cost of a link is computed by multiplying the 

traveled distance on that link by the cost specified as a link attribute plus 

adding supplement1. Supplement2 is an additional cost value per link that is 

not weighted by the factor γ but just added io the general cost of the edge. 



12.6 Route Search and Route Choice 

12.6.1 Routes and their Cost 

A route is a sequence of edges that describes a path through the network. 

Routes in VISSIM’s Dynamic Assignment start and end at parking lots. Since 

normally more than one route exists between an origin and a destination 

parking lot in the network VISSIM has to model the driver’s decision which 

route to take. For the beginning let us assume that the set of available routes 

is known for a certain origin-destination pair. 

As stated in the introduction the route choice is a special case of the discrete 

choice problem. For a given set of discrete alternatives the probabilities for 

the alternatives to be chosen must be determined. For traffic assignment we 

need to define a utility function to assess each route in the set and a decision 

function based on this assessment. 

As discussed in the previous section we know for all edges their general 

costs which are computed from expected travel times, travel distances and 

financial costs. The general cost for a route is then simply defined as the 

sum of the general costs of all its edges: 

C 

R 

= 

∑ 

a∈R 

C 

a 

where 

C = general cost 

R = a route 

a = an edge belonging to R 

12.6.2 Route Choice 

In Dynamic Assignment the drivers have to choose a route when they start 

their trip at the origin parking lot. In this section let us assume that the 

destination parking lot is known and a set of possible routes is already 

known. The problem of how to find routes and choosing the destination 

parking lot is covered in separate sections. 

One basic assumption in VISSIM’s route choice model is that not all drivers 

use the best route but all routes available can be used. Of course more traffic 

should be assigned to “better” routes than to “worse” routes. To assess how 

“good” a route is, we use the general cost of the route as explained in the 

section above. The general cost is obviously the inverse of what is called a 

utility value in discrete choice modeling. So we use as an utility function the 

reciprocal of the general cost: 


U 

= 

1 

j 

C j 

where 

Uj = utility of route j 

Cj = general cost of route j 

Route Search and Route Choice 

The most widely used and thus theoretically best analyzed function to model 

discrete choice behavior is the Logit function: 

μU 

j 

e 

p( 

R j ) = 

μU 

e i 

∑ 

i 

where 


p(Rj) = probability of route j to be chosen 

μ = sensitivity factor of the model (>0) 

The sensitivity factor determines how much the distribution reacts to 

differences in the utilities. A very low factor would lead to a rather equal 

distribution with nearly no regard of utility, and a very high factor would force 

all drivers to choose the best route. 

If we use the Logit function with an utility function defined as above, we end 

up with the situation that the model considers the difference between 5 and 

10 minutes of travel time to be the same as the difference between 105 and 

110 minutes of travel time, since the Logit function is invariant against 

translation and considers only the absolute difference of the utilities. 

Obviously that is not appropriate for deciding route choice, since in the real 

world two routes having travel times of 105 and 110 minutes would be 

considered nearly the same, whereas 5 and 10 minutes are much of a 

difference. The solution adopted in VISSIM is to use the so called Kirchhoff 

distribution formula: 

k 

U j 

j 

k 

∑U 

i 

i 

where 


p(Rj) = probability of route j to be chosen 

k = sensitivity of the model 

p ( R ) = 



Again the sensitivity k in the exponent determines how much influence the 

differences in utility have. In this formula, the relative difference in utility 

determines the distribution, so that we will see only a small difference 

between the 105 and 110 minute routes, whereas the 5 minute route will 

receive much more volume than the 10 minute route. 

Actually the Kirchhoff distribution formula can be expressed as a Logit 

function, if the utility function is transformed to be logarithmic: 

k ⋅ logU 

j 

e 

k ⋅ logU 

e i 

k 

U j 

p( 

R j ) = = 

k 

∑U 

i 

i ∑ 

i 

where Cj is the general cost of route j. 

12.6.3 Route Search 

−k⋅logC 

j 

e 

− k logC 

e i 

In VISSIM we assume that the drivers do not use only the best routes from 

one parking lot to another, but that the traffic volume is distributed among a 

set of available routes. Obviously, one would like to know the set of the n 

best routes for each origin-destination-pair. Unfortunately there is no efficient 

algorithm to simply compute the n best routes but there are algorithms to find 

the single best one. To solve this problem we search for the best route for 

each OD-pair in each iteration of the Dynamic Assignment. Since the traffic 

situation and thus travel times change from iteration to iteration (as long as 

convergence is not reached) we will find different “best” routes in the 

iterations. All routes found (i.e. all routes that have qualified at least once as 

a best route) are collected in an archive of routes and are known in all later 

iterations. These routes are all stored in the path file (extension WEG). 

The criterion for the “best” route is the general cost. That implies that for 

different vehicle types different best routes can be found, because the 

parameters of the general cost function are type-specific. Route search is 

done at the beginning of each evaluation interval and is based on the 

expected general cost for this interval computed from the preceding 

iterations. 

Since in the very first iteration no travel time information from preceding 

simulation runs is available the cost is evaluated by replacing the travel time 

with the distance (in m). Thus for the initial route search also link/connector 

costs are taken into account. For every subsequent iteration the edges in the 

network that have not been traveled by any vehicle have a default travel time 

of only 0.1 second. This way it attracts the route search to build routes 

including unused edges. This method might result in some useless routes 

being found initially but by encouraging vehicles to try new paths the process 

of finding new routes is speeded up. You might want to control the courage 

of the vehicles to discover new routes by adding some weight to the distance 

in the general cost function so that they do not try obvious detours. However, 


= 

∑ 

i


it is generally good to find as many routes as possible. If a route proves bad 

during the following iterations it may be discarded (depending on the 

Extended path settings) and thus does not harm. 

Search for alternative paths 

Optionally, an additional search for alternative paths can be performed using 

stochastic modification of edge evaluations: 

Multiple runs of the shortest path algorithm with (slightly) modified edge 

evaluation parameters will increase the chance to find more alternative 

routes, which should be used though having higher total cost. 

This option can be activated in two ways: Activate 

► ALTERNATIVE PATH SEARCH... separately for each OD pair of zones via EDIT 

– AUTO ROUTING SELECTION in the Paths window, cf. section 12.6.4; or 

► option Stochastic edge penalization for Alternative path search via 

EXTENDED for option Search new paths in the Dynamic Assignment 

window (via TRAFFIC – DYNAMIC ASSIGNMENT), cf. section 12.8.4. 

12.6.4 Route Visualization 

The routes found during the 

iterations of the Dynamic 

Assignment can be visualized 

in the network editor by EDIT – 

AUTO ROUTING SELECTION 

(while the Parking Lots 

mode is active). 



ALTERNATIVE 

PATH 

SEARCH... 

In the Paths window, all known 

routes are listed with their 

general Cost value and length 

(Distance) for the selected OD 

pair. Furthermore it displays 

the number of vehicles 

(Volume) that have used a 

path in the last simulation run 

when a path file (*.WEG) was 

written. 

Since costs are type specific 

and time dependent, a vehicle 

type and an evaluation interval 

need to be selected. If a route 

is selected in the list box, it is 

highlighted in the network 

display as a yellow band. 

The corresponding buttons select which set is listed. 

► For automatic detour detection, the list of paths is separated in sets of 

- “normal” Paths and 

- Detours. 

► If convergence parameters are set, all paths that have not met the 

convergence criteria can be displayed via option 

- Show Non Converging Paths. 

Closed paths (because of edge and connector closures) are listed as well in 

the Path selection window: 

► The closed edges respectively edges containing closed links are 

highlighted in red when the path is displayed. 

► The path's parameters (length, cost, volume) are shown in brackets. 

The path volume is always shown as the sum of all vehicle types. Thus 

selecting a different vehicle type will not change this value. Furthermore 

there might still be vehicles listed for paths where a connector is closed for 

a certain (and not all) vehicle class only. 

If Penalization of the shortest path 

is checked, VISSIM will continue 

after the normal shortest path 

search; further searches with 

changed edge evaluations will be 

run, until either a new path 

without route closures is found or 

the maximum number of passes 

is reached. 



For changes to the evalulations, the evaluations of all edges of the currently 

best path are multiplied by the user-defined factor prior to each further pass. 

The paths shown in the Paths window result from the last iteration where 

the path file was updated. The costs shown are taken from the last cost file 

that was written. Thus the Path window shows the results of the last 

iteration only, if both the cost and path files where written during that 

iteration. 



12.7 Optional Enhancements of the Model 

12.7.1 Multi-class Assignment 

Multi-class assignment is the simultaneous 

assignment of different interacting road user classes 

on the same network. The road user classes in 

general have different route choice behavior and 

they can access different subsets of the road 

network. Examples of user classes are commuters, 

business travelers, local drivers, foreign drivers etc. 

To model different route choice behavior the parameters α, β and γ of the 

general cost function can be defined separately for each vehicle type. Thus it 

is possible to model e.g. drivers that are willing to pay tolls to gain time, and 

other drivers that do not want to pay and accept longer distances or travel 

times. 

The parameters can be set in the Cost Coefficients window that can be 

reached from the vehicle type window by pressing the button COST 

COEFFICIENTS. When defining the coefficients it is important to take into 

account the units of cost components to get the right scale of the result: 

Travel time is in seconds and distance is in meters, Link Cost has no implicit 

unit. So if e.g. link cost is given in Dollar per kilometer and shall have a 

significant influence, the coefficient must be large enough to bring the whole 

term to the same order of magnitude as the travel times in seconds. 

The second aspect of multi class assignment is the selective accessibility of 

the road network, that means that not all different vehicle types are allowed 

in all parts of the network. This feature could be used e.g. to model local 

drivers with full knowledge of the network and foreign drivers who know only 

the major roads. 

In VISSIM access to parts of the network is controlled by the connectors. A 

connector can be closed for selected vehicle classes. The route search will 

then build no routes containing that connector while building routes for that 

vehicle type. See section 6.3.2 for an explanation how to use connectors. 

12.7.2 Parking Lot Selection 

The travel demand given in the OD matrix refers to zones for destinations. In 

the VISSIM network, zones are represented by one or more parking lots. If a 

zone is represented by more than one parking lot, the driver has to choose 

one of them before he chooses the route. 

Parking lot choice is another example of a discrete choice problem, so we 

have to define the set of alternatives, the utility function and the decision 


Optional Enhancements of the Model 

function. To support the choice model, parking lots have a number of 

parameters regarded for selection wich are stored in the [SEL. PARAMETERS] tab, 


Relevant Situations 

Parking lot choice can take place in the following situations: 

► When a vehicle starts a trip at its origin parking lot 

► When a vehicle is forced to review its decision by a dynamic routing 

decision 

► When a vehicle is forced to review its decision by the route guidance 

system 

In all of these situations, the set of valid alternatives and the parameters of 

the utility function may be different. The set of available parking lots for a 

choice decision at departure is simply the set of all parking lots that belong to 

the destination zone and are open at the time of departure. For parking lot 

decisions made because of route guidance or dynamic routing decisions, the 

set of valid parking lots depends on the strategy chosen. See the description 

of these features in their separate sections. 

The utility function of a parking lot is defined as: 

U k, 

s = αk 

, s ⋅ C parking 

+ βk, 

s ⋅ attraction 

+ γ k, 

s ⋅ Ddest 

+ δk 

, s ⋅ Dveh 

+ ε k, 

s ⋅ fs 

where 

Cpark = parking cost 

Ddest = direct distance between parking lot and the destination zone´s 

center of gravity 

Dveh = general cost of best route from current vehicle position 

fs = availability of free parking spaces 

k = index of the vehicle type 

s = index of the decision situation (departure, routing decision...) 

The availability of free places is computed as the ratio of the free places in 

the parking lot in question to the maximum number of free places in all 

parking lots in the choice set. 

The value “distance from the destination zone” might look strange at the first 

glance, since parking lots belong to a zone and zones are not explicitly 

defined as network elements. How can they then have a position? The 

answer to the first question is that in some situations parking lots in other 

zones than the destination zone are considered, e.g. if all parking lots there 

are full. Then of course drivers are looking for near other parking lots. The 

position of a zone is computed from the positions of all parking lots as the 



average of the coordinates. (You can see the computed zone centroids in the 

network editor by using default shortcut CTRL+Z while in mode Parking Lot). 

The coefficients of the utility 

function can be defined for each 

vehicle type in the Parking Lot 

Selection window. The window is 

reached by pressing the button 

PARKING LOT SELECTION in the 

[SPECIAL] tab page of the Vehicle 

Type window. 

Once the utility for all valid parking lots in the choice set is determined, the 

choice probabilities are computed by a Logit function. The sensitivity factor of 

the parking lot Logit model can be set in the Dynamic Assignment window in 

the field labeled Logit Scaling Factor. There is also a field labeled Logit 

Lower Limit, where a threshold can be defined, so that parking lots with a 

utility less than the threshold are not chosen at all. 

12.7.3 Detour Detection 

As described above in the section about route search, the vehicles are 

encouraged to find new routes by trying links that are not yet traveled. This 

may lead to useless routes in the route collection. A route is considered 

useless if it is an obvious detour, and we define an obvious detour as a route 

that can be generated out of an other known route by replacing a sequence 

of links by a much longer sequence (in terms of distance). How much longer 

the replacing link sequence must be to qualify as a detour can be defined by 

the user in the Dynamic Assignment window. E.g. if there is a detour factor of 

2 defined then all routes are checked whether they are just copies of other 

routes with a subroute replaced by another partial route that is at least 

double as long. 

If detour detection is active you can choose in the path visualization window 

whether you want to see the detected detours or the non-detour routes. 

12.7.4 Correction of Overlapping Paths 

For every OD pair the whole demand will be distributed on all available 

routes. The distribution considers the general cost values as defined by the 

decision parameters of the route choice model. A route is assembled by a 

sequence of edges. Two routes are different if their sequence of edges is not 

exactly the same. Therefore two routes may be considered different if they 



differ only by a small section. In this case both routes have about the same 

weight within the distribution, but the overall distribution is biased. This is a 

general problem of Dynamic Assignment and know as the blue/red bus 

paradox. The following graphics illustrate the problem: 

Case 1 

Two routes with identical cost. The trips 

are split 50:50, no problem. 

Case 2 

Three routes with identical costs. Each 

1/3 

route receives one third of the demand 

from A to B, still no problem. A 

1/3 

1/3 

B 

Case 3 

Problem: Actually there are only two 

distinct routes, but because of the slight 

variations at the end, the route search 

finds 3 routes. 

Result: Distribution on 3 routes, but the 

overlapping part of the two similar 

paths contains too much traffic. 

Case 4 

Opposite problem of case 3: Actually 

there are 3 routes but two have a short 

part in common. 

As in case 3 all three routes will get 

about one third of the demand, which is 

much more realistic than in case 3. 


A 

1/2 

1/2 

2/3 

B 

A 

1/3 

B 

2/3 

1/3 

1/3 

1/3 

A 

B 


VISSIM offers an optional extension of the route choice model to correct the 

biased distribution in case of overlapping routes. It is based on the idea of 

the computation of a so called commonality factor of the routes. The 

commonality factor expresses how much of a route is shared with other 

routes. A high commonality factor indicates that a route has many edges in 

common with other routes, and a low commonality factor indicates that a 

route is quite independent of others. The commonality factor is then taken 

into account in the route choice model in way that a high commonality factor 

reduces the probability of the route to be chosen. 

1/3 

1/3


However, the use of the overlapping correction tends to assign more traffic to 

longer routes in certain network situations. Although in general path 

overlapping correction will improve the assignment quality, we recommend to 

use the feature only in combination with restricting the differences in cost of 

the allowed routes. 

12.7.5 Dynamic Routing Decisions 

When Dynamic Assignment is used, the vehicles in the network are on their 

assigned routes and will ignore any standard routing decisions they come 

across. Dynamic routing decisions are used to direct those vehicles that for 

some reason must be rerouted. The idea behind is that a vehicle coming 

across a dynamic routing decision checks whether a certain condition is 

fulfilled at that moment, e.g. its destination parking lot is full. If the condition 

is true for the vehicle a new parking lot choice or a new route choice is 

computed according to a certain strategy. The strategy chosen defines which 

parking lots are in the choice set. 

In the Create routing decision window, 

No. and Type have to be set. 

In the Routes window, the condition 

and strategy as well as additional 

parameters (e.g. option Exclude full 

parking lots) can be set for Routing 

decisions of the Dynamic type, cf. 



Condition selection list: 

Strategy selection list: 


Routing is based on the same general costs of the edges as the route choice 

of the Dynamic Assignment in the current evaluation interval. Much like the 

Dynamic Assignment paths, the dynamic routing paths can be viewed in the 

Paths window. The only difference is that From Routing Dec. has to be 

selected instead of From Parking Lot. 

Call the Paths window via menu EDIT – AUTO ROUTING SELECTION while the 

Routes edit mode is active. 

12.7.6 Route Guidance 

With Dynamic Assignment the vehicles choose their routes to their 

destinations at departure time based on the general cost information 

collected in the preceding iterations of the simulation. However, VISSIM 

offers additionally the possibility to re-route vehicles during their trips based 

on the current traffic situation in the current simulation iteration. This method 

can be used to model vehicle route guidance systems. 



Other than dynamic routing decisions the rerouting caused by the route 

guidance system is not restricted to fixed positions in the road network. 

Instead, the equipped vehicles are rerouted in fixed time intervals. At the 

current state of the implementation, the action triggered by the system is 

always to search the best route from the current vehicle position to the 

destination parking lot. The criteria for the route search is general cost with 

travel times measured in the current simulation. The travel times taken into 

account for the re-routing are not necessarily the most recent travel times but 

travel times measured some time ago (offset). This offset is introduced to 

model the processing time of typical route guidance systems, i.e. the time 

from measurement on the road until the data is available to the route 

guidance equipment in the vehicles. 

Two independent route guidance 

systems are offered for simulation with 

identical functionality. 

Whether a vehicle type is equipped 

with one or both route guidance 

systems can be selected in the vehicle 

type window. The parameters for the 

route guidance system are defined in 

the Route Guidance window. 

It can be accessed via ROUTE 

GUIDANCE in the Dynamic Assignment 

window. 


12.8 Assignment Control 

12.8.1 Path Evaluation File 

Assignment Control 

To analyze the results of the Dynamic Assignment, the most important 

information is to know the paths found, their cost and how it is computed, 

and how much of the traffic volume was assigned to them. This kind of 

information is offered for output in the path evaluation file. Cf. section 11.21 

for a detailed description of the file format and how to configure the 

evaluation. 

12.8.2 Iteration Control 

The Dynamic Assignment is computed by running the simulation for the 

same model repetitively. During the iterations, information about routes in the 

network and about travel times on the edges of the road network is collected. 

This information is stored in two files, the cost file (BEW) and the path file 

(WEG). These files represent the current state of the assignment. The 

names of these files are not generated automatically like most of the 

evaluation files but can be set by the user in the Dynamic Assignment 

window. That way different sets of assignment states can be stored. 

Writing of the cost and path files during simulation can be disabled in the 

Dynamic Assignment window by deactivating the options Store Costs and 

Calculate and Store Paths. This is appropriate for example if the assignment 

has converged and the route choice shall not be changed during the 

following simulations. To prevent accidental overwriting, VISSIM 

automatically deactivates these two options whenever a network file is 

opened which is linked to existing cost and path files. If VISSIM is run from 

the command line in batch mode with a number of runs specified, VISSIM 

will create and/or overwrite these files automatically. 

The number of routes available increases during the iterations. In the first 

iterations, only few routes are known for each origin-destination-pair. This 

may lead to unrealistic congestion on these routes because the volume 

cannot be distributed on enough different roads. This congestion will disappear 

in later iterations when more routes are found but convergence is 

slowed down because of the exponential smoothing of the measured travel 

times. To avoid these start-up congestions it is recommended to load the 

network with less than the full travel demand during the first iterations (e.g. 

10-20%). To continue from there, there are two options: 

1. Delete the cost file and run the next iteration with full demand load. 

Because of the previous iterations, now most of the paths for every OD 

pair are available and thus traffic demand will be distributed over these 

paths. 



2. Increase the demand gradually over the next iterations until the full 

demand is reached. In order to conveniently control this process it is 

possible to scale all OD matrices globally with a factor for the current 

simulation. That factor can be set with the option Reduced Volume [%] in 

the Dynamic Assignment window. 

Using the VISSIM Batch Mode to Run Multiple Iterations 

Since Dynamic Assignment normally requires many simulation iterations it is 

possible to start VISSIM in batch mode and compute several subsequent 

iterations without stopping. Therefore VISSIM can be called from the 

command line with the –s parameter. The number n denotes the number 

of iterations to be computed. 

Example: VISSIM.EXE TEST.INP –S20 

This entry would compute 20 iterations of the network file TEST.INP. This 

feature can be combined with the congestion-avoiding scaling of travel 

demand by using the command line option –v. The number p denotes the 

percentage points by which the scaling factor in the input file is increased in 

each iteration until 100% is reached. 

Example: VISSIM.EXE TEST.INP –S20 –V5 

This entry would compute 20 iterations of the network file TEST.INP and 

increase the traffic demand by 5% in each iteration. E.g. if in TEST.INP a 

reduced volume factor of 20% is defined then in the first iteration the travel 

demand would be scaled down to 20%, in the second iteration increased by 

5% from there (so there will be 25% of the full traffic demand), then 30% and 

so on, and from the 17 th iteration onwards the total travel demand would be 

assigned. Increased volumes will not exceed 100%. If 100% is reached, 

further runs will also be performed with 100%. 

Alternatively to option -s -v, the MULTIRUN functionality is provided in 

the SIMULATION menu, cf. section 8.1.3. 

12.8.3 Convergence Control 

The process of iterated simulation runs to compute the result of the Dynamic 

Assignment can be stopped if eventually a stable traffic situation is reached. 

This is the case when travel times and volumes do not change significantly 

from one iteration to the next. The stability of travel times and volumes must 

be reached for all evaluation intervals from one iteration to the next, not 

necessarily within one simulation period where traffic conditions may change 

from one evaluation interval to the next. 

VISSIM offers an automated test for convergence. The Convergence window 

for the configuration of the convergence test can be accessed by the 

CONVERGENCE button in the Dynamic Assignment window. 

Three different criteria for convergence can be selected and the respective 

tolerance values set: 


● Travel Time on Paths computes 

the change of the travel time on 

every path compared to its travel 

time in the previous run. If this 

change for all paths is lower than the 

user-defined factor, convergence for 

this criterion is detected. 


● For Travel Time on Edges the old and new travel times on edges are 

compared in the same way as described for paths above. 

● For the option Volume on Edges the absolute difference of old and 

new volume on every edge is determined and compared with the userdefined 

number of vehicles. 

It is recommended to use only one out of the three possible convergence 

criteria, preferably the Travel Time on Paths option. Make sure that you set 

the convergence criteria not too tight (e.g. by using all three criteria at the 

same time). Otherwise convergence is never reached. Especially the 

Volume on Edges option might be too tight as it looks for absolute values 

which on heavily loaded links differ more than on low-flow links even 

though the difference in percentage is the same. 

This test for convergence is done at the end of each evaluation interval. If all 

selected convergence conditions are fulfilled for all evaluation intervals a 

message box shows up at the end of the simulation run. In the case of a 

batch run a different message box shows up offering the option to terminate 

the batch run. 

Another way to observe and control convergence during the iteration process 

is offered by the convergence evaluation output file. VISSIM writes to this file 

a statistic evaluation of the differences in travel times and volumes for all 

edges and paths from the preceding to the current iteration. See section 

11.22 for a description of the file format. 

The non converging paths in the last iteration can be displayed within the 

Paths window (EDIT - AUTO ROUTING SELECTION...). A path does not converge 

in a time interval if the travel time percentage difference between the 

previous and the last iteration is bigger than the percentage defined in the 

convergence window. The Paths window displays the previous and the last 

travel time for each time interval where a path is not converging. 

12.8.4 Route Search Control and Local Calibration 

The Dynamic Assignment process can be controlled by the user in several 

ways. Control becomes necessary if the assignment result differs from real 

world observation although the road network and infrastructure are modeled 

correctly. That may happen because for obvious reasons the decision model 



in VISSIM cannot cover the complete range of factors to influence of the real 

drivers decision behavior. 

Thus VISSIM offers several means to control the use of certain parts of the 

network during Dynamic Assignment route choice. 

Surcharges 

One method to model the behavior that some parts of the road network 

attract more or less traffic than expected, the cost of VISSIM links and 

connectors can be increased or decreased using surcharges. Surcharges 

are added to the total cost once per visit of a link/connector section (i.e. not 

per km). A section is delimited by node boundaries. Thus, the surcharge is 

added to the link´s general cost as often as the vehicle enters an edge on 

that link. E.g. in case of a link intersecting with 2 nodes, the surcharge is 

added 3 times, if the vehicle traverses the entire link. 

Define surcharges in the Link Data window by pressing COST in [OTHER]. 

There are two kinds of surcharges: 

● Surcharge 1 is sensitive to the weight for 

financial cost in the vehicle type cost coefficients. 

● Surcharge 2 is simply added to the general 

cost and is independent of the cost coefficients 

of the vehicle type. 

Edge Closure 

A more rigid method of avoiding traffic on certain road sections, is to ban 

certain edges for the use in the Dynamic Assignment routing. 

Edges can be closed in the Edge 

Selection window by 

► selecting an edge and activating 

the option Edge Closed. 

► clicking the appropriate button for 

all edges. 


Closed edges are shown in red color rather than yellow. 


Restricting the Number of Routes 

The number of routes found during the iterations in principle is not restricted. 

Therefore, as long as no special action is done, all routes that have been 

found are stored in the route archive and are used for traffic distribution. As a 

result, to some rather expensive routes some vehicles will still be assigned 

even if in later iterations much better routes are found. To avoid this effect, 

the number of routes that is used for each OD pair can be restricted. There 

are two ways of restricting the number of routes: 

► Defining an upper limit for the number of routes 

► Defining a maximum of cost difference between the best and the worst 

route 

Defining an upper limit may not be appropriate in networks where for some 

OD pairs many alternative routes exist (and shall be used) and for other 

relations only few routes exist. Then the maximum of cost difference 

between the cheapest and the most expensive route may be defined. This 

method is intended to discard unwanted expensive routes that once have 

been the cheapest because some or all edges had no real cost evaluations 

yet (i.e. they were initialized with cost value 0.1). The low initialization values 

encourage the route choice model to assign traffic to routes where no 

vehicles have been traveled yet. Those routes which are found to be much 

more expensive (compared to existing routes) after some vehicles have 

traveled on them for the first time can be discarded from the route archive 

using this method. 

The following action is performed every time the data from a path file is 

loaded (generally speaking at every start of a new iteration): 

For each OD pair separately, out of the set of all available routes VISSIM 

finds the cheapest and the most expensive route. Then every route is 

discarded for which the excess cost (compared with the cheapest route) 

divided by the cost of the cheapest route is higher than the defined threshold 

factor for all evaluation intervals. 

in the Path Search window 

► the threshold factor and 

► the upper limit 

can be defined, if the particular option is active. It is reached by pressing the 

button EXTENDED for option Search new paths in the Dynamic Assignment 

window. 

Furthermore, the following options are provided: 



● Search paths for OD pairs 

with zero volume: If this 

option is selected, new 

paths for "empty parking lot 

relations" are also searched. 

A parking lot relation is 

empty, if no volume is 

required in any of the 

involved OD matrices for the 

zone pair. 

It is recommended to leave this option unselected (default), saving 

considerable amounts of memory in case of sparse traffic demand 

matrices. 

● Stochastic edge penalization for alternative paths search: If this option 

is active, the specified number of stochastic passes will be run after each 

regular shortest path search (at the beginning of each evaluation interval 

during Dynamic Assignment). Prior to each pass, the evaluation of each 

edge in the network is multiplied by a random factor between (1-x) and 

(1+x), where x is the user-defined maximum Spread share for each OD 

pair of zones. 

Alternatively, the search for alternative paths can be perfomed with 

modified edge evaluations for each OD pair, cf. section 12.6.4. 

Route Closure 

Another method to influence the routing in Dynamic Assignment is to 

manually close subroutes (a sequence of links and connectors) in the 

network. A route closure does not guarantee that all routes are blocked 

which include the edge sequence of the route closure. There are two main 

possibilities where a route closure is ignored: 

1. If the route closure is part of the only possible route between two parking 

lots 

2. As long as no other route with less cost was found (in the first iteration 

least cost is determined by shortest distance) 

A route closure should only be used as the last option to restrict a specific 

movement. The better option is to use correct cost parameters and speeds, 

and if necessary, closure of a turning movement (edge inside a node). 

Before using a route closure please make sure that there is no other way to 

model the situation differently. In most cases, a turning movement (edge) 

closure will do the job if the node boundaries are placed differently. 


The subroute to be closed is defined in 

the same way as a static route is 

defined, i.e. they have a starting point 

and a destination point. 

Route closures can be created and 

edited using the Routing Decisions mode 

by selecting Closure in the Create 

routing decision window. For more 

information on Routing Decisions please 

refer to section 6.4.4. 

12.8.5 Generation of Static Routing 


VISSIM offers the possibility to convert the current state of the Dynamic 

Assignment (the routes found and their volumes) into a VISSIM model with 

static routes. It is then possible to use the simulation without the Dynamic 

Assignment module; in other words: the assignment is frozen. 

Vehicle inputs and routing decisions are created from the current data of the 

Dynamic Assignment files (*.WEG, *.BEW, *.FMA). 

Make sure, that the simulation period is a multiple of the evaluation interval 

for Dynamic assignment, since path file and cost file save the data by 

interval and would otherwise be incomplete. 

Vehicle inputs and routing decisions are directly generated from the route 

volumes being stored in the path file: 

► At least one vehicle input per time interval is created for each origin 

parking lot (parking lot with relative flow > 0). Its volume is summed up 

from all volumes of paths listed in the *.WEG file which start from this 

parking lot. 

► One static routing decision is created for each origin parking lot per 

vehicle type group which is a set of vehicle types with identical route 

choice behavior in the Dynamic assignment (identical cost coefficients, 

identical connector closures, identical destination parking lot selection 

parameters etc.). The relative flow of each route to a destination parking 

lot equals the path volume listed in the path file. 

- The identifier of any vehicle input automatically created is 1,000 

times the parking lot number plus the index of the time interval. 



- The identifier of any routing decision automatically created is 100,000 

times the parking lot number plus the index of the vehicle type group. 

Thus, none of the given parking lot numbers may exceed 42949. 

If these numbers exceed the valid range or if a vehicle input or routing 

decision with the same number already exists, the creation of static 

routing will be terminated and an error message will appear. 

► The vehicle compositions are derived from the matrix files. 

The conversion to static routes is done using the button CREATE STATIC 

ROUTING in the Dynamic Assignment window. 

The number of generated static 

routes can be reduced. 

Enable the option 

Limit number of routes 

Set the parameters accordingly. 

Then confirm OK. 

Option Limit number of routes has the following effect: 

First off, all paths are converted into routes with static volumes. Then, the 

number of generated static routes is reduced by comparing both, the absolute 

and the relative minimum volume of each decision cross-section with the 

given threshold and also the number of routes per destination cross-section. 

All routes which do not fulfil all of these three criteria and also their volumes 

will be removed. Decision cross-sections will not be removed, even if all 

routes starting from a decision cross-section have been deleted. 

Parameters provided in the Generate static routes window (these settings 

are only stored during a VISSIM session, they are not saved to file): 

● rel. min. volume: 2 decimal places, value range [0.0..1.0], default = 0.05. 

To each route applies: A static route is deleted, if – in each time interval - 

its relative volume < current rel. min. volume. 

If zero is entered as rel. min. volume, then none of the generated static 

routes will be discarded for this criterion. 

The relative volume per time interval = absolute volume per time interval: 

total volume summed up from all volumes per time interval. 

● abs. min. volume: integer, value range [0..999999999], default = 2. 

To each route applies: A static route is deleted, if its absolute volume < 

current abs. min. volume. If zero is entered as abs. min. volume, then 

none of the generated static routes will be discarded for this criterion. 

● max. number of routes (per destination cross-section): integer, value 

range [0..999999999], default = 10. All routes from a decision crosssection 

to a destination cross-section are taken into consideration. For 

each decision cross-section the number of routes leading to a destination 

cross-section is determined. If several destination cross-sections specified 

for just one decision cross-section are located closed to each other 



on the same link (tolerance ± 1m) these destination cross-sections are 

regarded as if they were a single destination cross-section. 

If the number of routes per destination cross-section > current max. 

number of routes, then the routes with lowest volume totals calculated 

from all volumes per time interval will be removed. 

If an unlikely value is entered, e.g. 999999, then none of the generated 

static routes will be discarded for this criterion. 

12.8.6 Summary of the Dynamic Assignment Parameters 

The Dynamic Assignment window is accessed by TRAFFIC – DYNAMIC 

ASSIGNMENT. In this section only a short summary of the available options is 

presented. A more detailed description of most of the parameters is 

contained in the relevant sections above. 

● TRIP CHAIN FILE: Links to a 

trip chain file (e.g. exported 

from VISEM). 

● Matrices: Contains a link 

to one or more matrix files 

each related to a vehicle 

composition. 

● COST FILE: The file that 

contains the estimated travel 

times for the edges of the 

abstract network graph. 

● PATH FILE: The file that 

contains the route archive of 

the network 

● Check Edges: When 

active, VISSIM checks the 

consistency of the cost resp. 

path file in terms of network 

changes. It is strongly recommended 

to leave this option 

enabled since otherwise 

results of the Dynamic 

Assignment may be inconsistent. 

For large networks 

the Check Edges process 

may take some time. In this 

case it may be switched off if 

it is assured that no changes 

have been done to the 

network structure. 



● Archive files: If this option is active, existing output files *.BEW and 

*.WEG which are stored in the same folder as the *.INP file will be 

renamed. Numbers will be added to the filenames prior to creating new 

output files. 

Archiving of cost and path files saves the existing initial files, too. These 

additional initial archive files (with number zero) are created for the path 

and cost files if the following applies: 

- option Archive files is checked and 

- path and/or cost files exist (when starting the simulation) and 

- there are not any existing archive files in the directory. 

This is done for both a normal continuous simulation and for the first run 

of a multirun series. 

If there are already archive files in the directory then these initial archive 

files are not created because it is assumed that the last archive files 

correspond to the current start path/cost files. 

Thus the data file archive allows for subsequent analyses of changes 

during Dynamic Assignment. You even might start calculation from an 

elder assignment state. 

If this option is not active, existing output files *.BEW and *.WEG are 

replaced. 

● Store Costs: If checked, VISSIM writes a new cost file. 

● EXTENDED: Access to 

- the smoothing factor for cost calculation with regard to former edge 

evaluations or 

- MSA (Method of successive averages), cf. section 12.5.2. 

● Search new paths: If checked VISSIM calculates new shortest paths 

through the network. 

● EXTENDED: Further options to limit the number of routes being found, cf. 


● Store paths (and volumes): If checked VISSIM stores new paths and 

their volumes in the path file. 

If VISSIM is run in batch mode with a specified number of runs VISSIM 

creates or overwrites cost and path files automatically. 

● The Kirchhoff Exponent: Sensitivity parameter of the Kirchhoff 

distribution function used for route choice 

● Logit Scaling Factor: Sensitivity factor for the Logit model used in parking 

lot choice 

● Logit Lower Limit: Defines the cutoff proportion for the parking lot choice 

algorithm. If the benefit proportion of a parking lot is below the limit, no 

vehicles will be assigned to it. 

● Scale Total volume to [%]: This checkbox allows for modification of the 

volume from all OD matrices used for the next Dynamic Assignment run 



either up or down to the given percentage. Values > 100% permitted 

(e.g. for future demand scenarios). 

● Correction of overlapping paths: Corrects the proportions of vehicles 

being assigned if routes share common edges 

● Avoid Long Detours: Paths with long detours (segments that could be 

replaced by shorter distance alternatives from different paths) will not be 

used for vehicle distribution. The factor for deciding when a segment is a 

detour can be defined in the adjacent field. 

● Use VISSIM’s Virtual Memory allows the user to conserve some of the 

memory (RAM) used while running a simulation with Dynamic 

Assignment. If checked, a file is created that holds a reference to the 

vehicles that will eventually enter the network instead of those vehicles 

being generated at the beginning of the simulation and being stored in 

the computers memory until they leave the network. Using the Virtual 

Memory option slows down the simulation but will not tie up as much of 

the systems memory resources. 

● CONVERGENCE: Provides three threshold values to detect convergence of 

the Dynamic Assignment process. 

● ROUTE GUIDANCE: Allows for definition of up to two control strategies to be 

used by vehicles with route guidance (e.g. navigation system). 

● CREATE STATIC ROUTING: Starts the conversion of the current Dynamic 

Assignment results into static routes, cf. section 12.8.5. 



12.9 Initial Solution from VISUM 

As an initial solution for the Dynamic Assignment in VISSIM, the result of a 

static VISUM assignment can be used. This aims on the reduction of the 

number of iterations which are required in VISSIM until convergence is 

reached. The VISUM assignment does not represent the final result but an 

initial solution. 

You can start the VISUM assignment in VISSIM. VISSIM provides two 

possibilities: 

► Automatic VISUM assignment calculation 

► Manual VISUM assignment calculation 

12.9.1 Automatic VISUM Assignment Calculation 

In VISSIM, click menu TRAFFIC - DYNAMIC ASSIGNMENT - VISUM ASSIGNMENT to 

start the automatic VISUM assignment calculation. 

The VISUM assignment is calculated by means of the VISUM Converter 

which is included in your VISSIM installation. Later the routes calculated in 

VISUM will be stored in the automatically created VISSIM path file *.WEG. 

The filename is derived from the PATH FILE entry in the Dynamic Assignment 

window. From an existing path file with the same filename, a backup copy 

*.BAK is generated prior to overriding. 

Please note that your data files *.WEG and *.BAK are be replaced automatically 

in case of multiple assignment calculations. 

A static VISUM assignment in VISSIM requires significantly less time 

compared to a microscopic VISSIM traffic simulation, which is caused by 

the individual vehicles. 

Once the VISUM assignment has been finished, the simulation (even a multirun 

simulation) can be started immediately in VISSIM without any other work 

steps. The first iteration uses the paths which were calculated in VISUM. 

After the first iteration, the path file and the cost file created in VISSIM are 

used. Their file names are retained. 

No assignment can be calculated, if 

the VISSIM network contains nodes 

with a number that exceeds the 

maximum permitted node number in 

VISUM. For assignment calculation in 

VISUM, the VISSIM node numbers 

need to be edited in a way that they 

no longer exceed the maximum 

permitted VISUM node number. 


Initial Solution from VISUM 

During the automatic VISUM assignment calculation, warnings, notes and 

process messages are recorded in the protocol file. Call the protocol file 

window via menu HELP – LOG WINDOW. 

12.9.2 Manual VISUM Assignment Calculation 

The steps of the automatic VISUM assignment calculation can be performed 

manually one by one. This approach allows for additional VISUM network 

editing prior to the calculation. 

Workflow of the manual calculation 

Prior to the Export step it is recommended to run a simulation in VISSIM. In 

this way it can be guaranteed, that the VISSIM network contains paths for all 

OD pairs with demand > 0. 

1. In VISSIM: Export network data and demand data via menu FILE - 

EXPORT – VISUM – NODES/EDGES… for assignment calculation in VISUM, 


2. In VISUM: Open the VISUM version file *.VER that has been created 

during VISSIM export to VISUM. 

3. In VISUM: Perform the desired changes to the network. 

In VISUM, the network topology is not subject to changes, since 

otherwise the import of VISUM routes might fail in VISSIM. 

The network topology is not affected by the following modifications: 

- Editing link attributes (type, length, PrT capacity, v0 PrT) 

- Editing the link polygon course 

- Editing node attributes (type, PrT capacity, t0 PrT, control type) 

- Editing the node geometry/orientations 

- Editing the node coordinates 

- Signal control definition (via Junction Editor). 

The folowing modifications in VISUM could cause the route import in 

VISSIM to fail: 

- Create/Delete nodes 

- Edit node number 

- Create/Delete links 

- Create/Delete connectors 

- Open blocked links (Changes to the TSys setings of links) 

- Open blocked turns (Changes to the TSys settings of turns) 

- Open blocked connectors (Changes to the TSys settings of 

connectors) 

- Create/Delete TSys/Modes/DSeg 

4. In VISUM: Calculate the assignment. 



For more details please refer to the VISUM User Manual. 

5. In VISUM: Start the export of the routes resulting from assignment. 

For more details on VISSIM Export (ANM Export) from VISUM please 

refer to chapter 13 „Using interfaces to exchange data“ in the VISUM 

User Manual. 

Please make sure that only routes (*.ANMROUTES) are exported. Network 

data (*.ANM) and matrix data is not required. 

In VISUM, set the time interval in the ANM - Export parameters window 

according to the Export time interval specified for the VISUM export in 

VISSIM: 

- Export time interval in VISSIM: 


- [TIME INTERVAL] in VISUM: 

Initial Solution from VISUM 

6. In VISSIM: Import the routes for the Dynamic Assignment. 


1. Click menu FILE - IMPORT… - ANM. 

2. In the ANM Import window, uncheck option Import network data. 



3. Select option Dynamic Assignment. 

4. Check option Import routing and select the *.ANMROUTES file that 

was exported from VISUM. 

5. Click IMPORT. 


This messages indicates that 

no errors occured during import. 

VISSIM creates a path file *.WEG that stores the routes calculated in VISUM. 

The filename is derived from the PATH FILE entry in the Dynamic Assignment 

window. From an existing path file with the same filename, a backup copy 

*.BAK is generated prior to overriding. The route import does not change 

VISSIM network data. 

The distribution of the zone’s origin flow to the zone’s parking lots in 

VISSIM regards only the relative flows entered in VISSIM. It does not 

depend on the distribution to the origin zone connectors during the VISUM 

assignment. The result of the VISUM assignment is only used for the 

distribution of vehicles from VISSIM parking lots to the routes that were 

found in VISUM that lead to the particular destination parking lot. 


13 VISSIM Programming Interfaces (API) 

VISSIM provides different Application Programming Interfaces (API) as addon 

modules for the users to automate their workflow and customize their 

VISSIM models with their own applications. 

These add-on modules are not automatically part of every VISSIM license. 

The particular documentation provided by interface is stored in the 

appropriate sub-folder of the main folder (named below) of your 


If you are interested in any add-on, please contact PTV AG. 



13.1 COM Interface 

Occasionally projects will require extensive pre- or post-processing, 

numerous scenarios to be investigated or the application of customized 

control algorithms. 

For these cases VISSIM can be run from within other applications serving as 

a toolbox for transportation planning algorithms. Access to model data and 

simulations is provided through a COM interface, which allows VISSIM to 

work as an Automation Server and to export the objects, methods and 

properties. 

The VISSIM COM interface supports Microsoft Automation, so you can use 

any of the RAD (Rapid Application Development) tools ranging from scripting 

languages like Visual Basic Script or Java Script to programming 

environments like Visual C++ or Visual J++, cf. section 3.5. 

Scripts can also be started from within VISSIM (internal scripting, cf. section 

3.5.1). 

Documentation: 

► \DOC\ENG\VISSIM_COM.PDF 

Examples: 

► \TRAINING\COM\ 


13.2 External Driver Model - DriverModel.DLL 

External Driver Model - DriverModel.DLL 

The External Driver Model DLL Interface of VISSIM provides the option to 

replace the internal driving behavior by a fully user-defined behavior for 

some or all vehicles in a simulation run. 

The user-defined algorithm must be implemented in a DLL written in C/C++ 

which contains specific functions. 

During a simulation run, VISSIM calls the DLL code for each affected vehicle 

in each simulation time step to determine the behavior of the vehicle. VISSIM 

passes the current state of the vehicle and its surroundings to the DLL and 

the DLL computes the acceleration / deceleration of the vehicle and the 

lateral behavior (mainly for lane changes) and passes the updated state of 

the vehicle back to VISSIM. 

The external driver model can be activated for each vehicle type separately 

in the dialog box Vehicle Type by checking the checkbox Use external driver 

model on the tab page External Driver Model and selecting a driver model 

DLL file and optionally a parameter file to be used, cf. section 5.3.1. 


► \API\DRIVERMODEL_DLL\INTERFACE_DESCRIPTION.PDF 

Example file: 

► \API\DRIVERMODEL_DLL\DRIVERMODEL.CPP 



13.3 3dsMaxExport 

The 3dsMaxExport Module allows to export simulation results from VISSIM 

into the format ANI.TXT, cf. section 9.3.1. It is to be imported into the 

modeling, animation and rendering package 3ds Max from Autodesk Inc. In 

3ds Max, the results can be tuned to high end 3D presentations. 


► \API\3DSMAXEXPORT\HOWTO\USERGUIDE.PDF 

► \API\3DSMAXEXPORT\HOWTO\HOWTO3DS.PDF 


13.4 Car2X Module 

Car2X Module 

The Car2X Module allows the implementation and testing of applications that 

use Vehicle-to-Vehicle and/or Vehicle-to-Infrastructure communication. 

The algorithms for the Car2X applications can be written as Python script or 

C++ program. 

It can access data of the vehicles which have the respective equipment flag 

set in the vehicle type and defines when vehicles send messages to nearby 

vehicles and how vehicles react on messages received from other vehicles. 

The wireless communication is modeled in a separate *.DLL, which is part of 

the Car2X module. 


► \API\C2X\VISSIM_C2X.PDF 

Examples: 

► \API\C2X\EXAMPLES\ 



13.5 External Signal Control – SignalControl.DLLs 

Users can also define external signal controllers using the signal controller 

*.DLL and signal controller *GUI.DLL (in C or C++ programming language). 

External signal control can be activated in the Signal Control dialog on the 

tab page Controller (ext.), cf. section 6.7. 

For the defined controllers, in each controller time step VISSIM contacts all 

controller *.DLLs at the end of the current simulation time step. First, the 

current signalization states and detector data of all SCs are passed to the 

respective *.DLLs. Second, the *.DLLs are asked to calculate new desired 

signal states which are subsequently passed back to VISSIM. Depending on 

parameters set by the controller logic, either these signal states are applied 

immediately, or transition states (e.g. amber when switching from green to 

red) are inserted automatically, as defined in the signal group parameters in 

VISSIM. In the next simulation time step the vehicles in VISSIM will cope 

with the new signalization. 


► \API\SIGNALCONTROL_DLLS\SIGNALCONTROL_DLL\SC_ 

DLL_INTERFACE.DOC 

Examples: 

► \API\SIGNALCONTROL_DLLS\EXAMPLES\ 


Emission Calculation – EmissionModel.DLL 

13.6 Emission Calculation – EmissionModel.DLL 

This interface allows to connect an external emission calculation module to 

VISSIM. 

The external emission model is selectable for each vehicle type separately in 

the Vehicle Type dialog by checking the respective checkbox (at the bottom 

of the [SPEZIAL] tab page). 

If this option is checked, VISSIM will call the functions in the 

EMISSIONMODEL.DLL for calculation of emission values used in the vehicle 

record and link evaluation / alternative link display. 


► \API\EMISSIONMODEL_DLL\EMISSIOMODEL.TXT 

Files: 

► \API\EMISSIONMODEL_DLL\ 



13.7 Tolling – TollPricing.DLL 

In VISSIM, user defined Toll Pricing Calculation Models can be implemented 

as COM scripts or specific *.DLL files. 

Such a file *.DLL can be selected in the TollPricing Calculation Models dialog 

if the option COM-Script is activated, cf. section 5.6.2. 

The *.DLL must contain the functions declared in TOLLPRICING.H: Init() and 

Exit() are called from VISSIM at the start respectively end of a simulation run 

and can be used to initialize the *.DLL respectively clean up. CalculateToll() 

is called whenever a new toll price needs to be calculated, i.e. at the start of 

each calculation interval of each managed lane facility, once per user class 

(SOV, HOV2, HOV3+). 

VISSIM passes the number of the managed lane facility, the user class, the 

current simulation time, the travel time savings (in minutes) on the managed 

lane and the average speed on the managed lane (both since the start of the 

last interval) and it expects the new toll price to be stored with the reference 

variable . 


► \ API\TOLLPRICING_DLL\TOLLPRICING.TXT 

Files: 

► \ API\TOLLPRICING_DLL\ 


14 Glossary of Files associated with VISSIM 

Tolling – TollPricing.DLL 



14.1 Simulation Output Files 

Extension Name Content 

*.A00 

: 

*.A99 

Used by 

various 

evaluations 

Output files for various specifically defined 

evaluations. 

*.ANI Animation Contains recorded simulation for playback. 

*.BEO Observation Binary file that includes vehicles position, 

speed and acceleration for each vehicle for 

each simulation second. 

*.EMI Emission 

output 

*.ERR Run time 

warnings 

Contains total emissions in grams for CO 

and NOx. This is not the output of the 

optional warm/cold emissions module. 

Contains warnings of non-fatal problems that 

occurred during the simulation. 

*.FHZ Vehicle Inputs List of all vehicles including time, location 

and speed at their point of entry into the 


*.FZP Vehicle 

Record 

Output 

*.KNA Node 

Evaluation 

Output 

*.KNR Node 

Evaluation 

Raw data 

*.LDP Signal/detector 

record 

*.LOG Simulation 

Log file 

*.LSA Signal 

changes 

*.LZV Signal timing 

log 

*.MDB Database 

output 

Contains vehicle information specified for 

collection by the user in the FZK file in the 

Vehicle Record Configuration window. 

Contains the compiled data output from the 

node evaluation 

Contains the raw data output from the node 

evaluation 

Contains log of signal display changes and 

detector actuations (to be configured using a 

*.KFG file). 

File is created automatically and contains 

real time information about the current 


Example: The number of paths found when 

using Dynamic Assignment. 

Contains all signal changes occurring during 

a simulation run in chronological order. 

Contains green and red times for all signal 

groups (phases) of all controllers. 

Analyzer Reports and other output data 



*.MER Data collection 

(raw) 

*.MERP Data collection 

(raw) 

*.MES Data 

collection 

*.MESP Data collection 

*.MLE Managed 

Lanes 

Evaluation 

*.NPE Network 

Performance 

Evaluation 

Simulation Output Files 

Contains raw data collected at previously 

defined data collection points. 

Area-based output data from simulation of 

pedestrians 

Contains compiled data collected at 

previously defined data collection points. 

Compiled area-based output data from 

simulation of pedestrians. 

Vehicles on routes with/without road toll, 

includes also compiled data. 

Contains the number of vehicles, total 

distance traveled, total travel time, average 

network speed and total network delay. 

*.OVW PT delay PT stop times (excluding times for 

passenger interchange). 

*.PP Pedestrian 

Protocol 

*.PQE Pedestrian 

Queue 

Evaluation 

Evaluation output file from simulation of 

pedestrians 

Evaluation of the number of pedestrians in 

queues and the extension of the queues. 

*.ROU Routes Protocol of route choices for all vehicles 

(generated automatically with observer file). 

*.RSR Travel times 

(raw data) 

*.RSRP Pedestrian 

travel time 

(raw) 

*.RSZ Travel times 

(compiled) 

*.RSZP Pedestrian 

travel time 

(compiled) 

Protocol of completed travel time measures 

in chronological order. 

Raw data from simulation of pedestrians 

Average travel times during a simulation for 

previously defined travel time sections. 

Compiled data from simulation of 

pedestrians 

*.SNP Snapshot file Simulation state. 

*.SPW Lane change 

data 

This file contains information about specific 

vehicles lane changes. 

*.STR Segment data Output from the link segment evaluation 

feature. 




*.STZ Queues Average and maximum queue lengths at 

previously defined queue counters. 

*.TRC Trace Contains trace information as programmed 

in a VAP logic (with optional module VAP). 

*.TXT ANI.TXT file Text file with Network data and vehicle trajectories 

for import in Autodesk´s 3ds Max 

software with the help of a script in Autodesk´s 

macro language. 

*.VLR Delay data 

(raw) 

Protocol of completed delay time measures 

in chronological order. 

*.VLZ Delay data Evaluation of delay data (compiled data) 

*.XLS Excel sheet Analyzer output file according to filter 

settings 


14.2 Test Mode Files 


*.AGZ Green time 

statistics 

*.AWZ Red time 

distribution 

*.AZZ Time-time 

diagram 

Output green time statistics 

Output red time distribution 

Test Mode Files 

Output time-time diagram: Green time as a 

function of preemption call event during 

signal cycle 

*.BEL Demand file Traffic demand for green time statistics 

preparation 

*.M_I Macro Input Manually placed or edited detector calls; 

input file for macro test runs 

*.M_O Macro Output Manually placed detector calls created 

during test run, to be renamed to M_I 

*.SLF Loop file Configuration file to evaluate the impact of 

PT priority/preemption calls 

*.SLO Loop output 

file 

*.ZZD Configuration 

file 

Temporary file created during a loop test run, 

used for creation of green time statistics file, 

red time distribution, etc. 

Configuration file containing signal groups 

(phases) to be evaluated in a time-time 

diagram 



14.3 Dynamic Assignment Files 


*.BEW Cost file Contains the current list of costs for the 

paths through the network 

*.CVA Convergence 

evaluation 

Contains volume and travel time values 

for the current run and previous runs 

*.FMA OD matrix file Contains the origin destination matrix for 


*.WEG Path file Contains the current list of discovered 

paths through the network 

*.FKT Trip Chain File Vehicle input format (demand) for 


*.PCS Export file VS-pCoq Spy export file 

*.SCH Raw Emission 

Data 

*.WGA Path Evaluation 

Output 

*.WGF Path Evaluation 

Filter 

*.WGK Path Evaluation 

Configuration 

Input file for optional emission module 

Contains data collected on Dynamic 

Assignment paths 

Contains a list of (from and to) nodes or 

parking lots data should be collected for 

Contains a list of evaluations that are 

collected for each path 


14.4 ANM Import Files 


*.ANM Abstract 

network model 

ANM Import Files 

Input data file in *.XML format; 

Network export from VISUM 

*.ANMROUTES Route file Input data file in *.XML format; 

Export of routes and route volumes 

from VISUM 

*.PANM Backup copy of the imported *.ANM 

file 

*.PANMROUTES Backup copy of the imported 

*.ANMROUTES file 

*.INP Cf. section 14.5 Output file of the ANM Import 

*.FMA Cf. section 14.3 Output file of the ANM Import for 


*.WEG Cf. section 14.3 Output file of the ANM Import for 




14.5 Other Data Files 


*.ANC Analyzer 

configuration file 

*.BGR Background 

scaling file 

Name and path of the output file *.MDB. 

Scale/Position parameters for the 

background of the VISSIM network. 

*.BMP Bitmap Background graphic (e.g. aerial photo, 

signal plan) or texture (several formats 

are supported) 

*.FIL Filter settings Filter settings for Vehicle protocol 

*.FZI Window 

configuration 

Settings for Vehicle information display 

*.FZK File configuration Settings for Vehicle protocol 

*.GAIA Vehicle position 

export file 

*.HGR Background 

parameter 

(outdated format) 

The GAIA file contains vehicle data to 

be exported to another visualization tool 

Outdated data format: Parameters for 

background image (origin and scale) 

*.INI Initialization Contains position and size of the 

individual output windows, selected 

display options as well as output file 

configurations. 

*.INP Network (Input) Contains all traffic network input data 

(also Public transport and Pedestrians 

add-on data) 

*.IN0 Backup Automatically created backup of *.INP 

file 

*.KFG Configuration Configuration of columns for 

signal/detector record 

*.KNK Node Evaluation 

Parameters 

Contains the parameters for the Node 

Evaluation output file 

*.LCF Filter settings Filter settings for Lane change 

evaluations 



Other Data Files 

*.MLC Configuration Settings for Managed lanes evaluation 

*.MESPK Configuration Settings for Compiled area-based 

evaluation during simulation of 

pedestrians. 

*.NPC Configuration Settings for Network evaluation 

*.PDK Configuration Settings for Pedestrian protocol 

*.PIL Filter settings Filter settings for Pedestrian protocol 

*.PUA VAP start-up 

stages and 

interstages 

VISSIG/CROSSIG/P2 output file: 

Contains definitions of stages, start-up 

stages and (if applicable) interstages for 

signal controllers with VAP logic 

(optional module) 

*.PW1 Parameter file VS PLUS parameter settings 

*.QMK Configuration Settings for Data collection 

*.SAK Configuration Settings for Link evaluation 

*.SIG Fixed time SC 

data output file 

Signal control data file in XML data 

format that is automatically created for 

each fixed time control when an *.INP 

file provided in previous data format is 

opened. 

Only required until the *.INP file is 

saved with the new data format 

*.STG TRENDS control ASCII supply file for TRENDS 

*.SZP Configuration of 

dynamic signal 

timing plan 

*.TZM 

*.DAT 

Export files from 

IVA and SiVIP 

*.V3D VISSIM 3D model 

file 

Configuration of the sequence of signal 

groups (phases) and detectors for 

dynamic signal timing plans 

Fix time programs can be exported from 

IVA and SiVIP in the *.TRADAT format 

(ASCII) for import in VISSIM 

VISSIM 3D modeler output file 

*.VAP VAP logic Description of a user-defined traffic 

responsive signal control logic 

(available only with optional VAP 

module) 

*.VCE VS-PLUS 

in C format 

*.VXB TRENDS data 

supply 

VS PLUS parameter settings in C 

format 

Binary supply data file for TRENDS 

control 




*.WTT Signal control 

interface 

(Internal) interface definition of 

parameters for data exchange between 

VISSIM and an external signal control 

program 


15 Service & Support 



15.1 Online Help 

The VISSIM Online Help consists of the VISSIM User Manual. Use one of 

the following options to call the Online Help during your program session: 

► Menu HELP - ONLINE HELP 

► ALT+H - H 

► F1 

15.1.1 Find topic 

[CONTENTS] Search in table of contents 

► Select and open one of the 

listed chapters by double-click 

first. 

► Select one of the listed 

sections then. 


[INDEX] Search in list of index entries 

► Enter keyword first. 

► Select the entry from listed index 

items (by double-click or via 

DISPLAY) then. 

Online Help 



[SEARCH] Full-text search 

► Enter word(s). 

► Check and modify Search 

options, if applicable. 

► LIST TOPICS: Calls the list of 

relevant topics. 

► Select item from the displayed 

list and call display 

(by double-click or via 

DISPLAY). 

Search options 

● Show previous results: The next search run will only stick to the list of 

items found in the previous search when a new keyword is entered for 

another search run. 

● Match similar words: The search run will not only find identical words, 

but also words with similar spelling. 

● Search titles only: The search will only regard the headlines of the 

manual chapters and their sections. 


15.1.2 Show topic 

Use the buttons to skip to the next or to the previous section. 

Within a chapter, the hyperlinks listed under More can be used. 

Use the scroll icons to navigate in the online help. 

Display options 

► Check/Uncheck the display of tabs: 

- via HIDE/SHOW buttons or 

- via OPTIONS – HIDE TABS / SHOW TABS. 

► Navigate in the Online Help: 

- via BACK/FORWARD buttons or 

- via OPTIONS – BACK/FORWARD. 

► Within a chapter, you may click 

- a hyperlink highlighted in the text or 

Online Help 



- one of the hyperlinks listed under More 

to skip to another topic. 

► SEARCH HIGHLIGHT ON: The search keyword found in the manual text will 

be high¬lighted by a colored bar. Unchecked via SEARCH HIGHLIGHT OFF. 

► Start print output: 

- via PRINT button or 

- via OPTIONS – PRINT...: 

The items to be printed can be selected in the Print items window. 

► OPTIONS menu: The commands 

- HOME, 

- STOP, 

- REFRESH, 

- INTERNET OPTIONS... 

refer to the functionality of Internet Browsers (e.g. Internet Explorer). 


15.2 License Info 

License Info 

For details on your current VISSIM installation you can call the License 

window via menu HELP - LICENSE. 

This window displays the following: 

► the Maximum 

- number of signal controllers permitted, 

- size of the network, 

- number of link types, 

- duration of a simulation, 

- number of pedestrians permitted; 

► a list of available/installed add-on Modules, 

► a list of available/installed Signal Controllers, 

► customer-specific data on the installed VISSIM Version and 

► the path of the VISSIM installation. 

You can model up to 30 pedestrians and run a pedestrian simulation even 

if your VISSIM license does not include the Pedestrians add-on. 



15.3 Contact Info 

In case of problems or requests, please use one of the numerous options for 

instant and direct contact. 

During your VISSIM session, click INFO... in the HELP menu for immediate 

access to 

► the internet presence of PTV Vision, 

► the list of FAQs, 

► the contact form provided for VISSIM Hotline requests or 

► the download page for VISSIM service packs. 

15.3.1 Sales & Distribution 

For more information on software maintenance contracts or contract updates 

and any questions regarding VISSIM license fees, please contact your local 

distributor. 

Alternatively, you may contact PTV AG directly via Info.Vision@ptv.de (information 

and delivery procedures). 


15.3.2 Technical Hotline 

Contact Info 

PTV operates a technical hotline e-mail service for VISSIM that is available 

for 

► program errors of the most recent version. As our software is 

continually being improved, we regret that we cannot provide hotline 

support for older versions of VISSIM. 

► application and modeling assistance for trained users of our clients 

who signed a software maintenance contract. 

Please understand that our hotline cannot provide the skills of a VISSIM 

training course. Neither is it possible that the hotline provides engineering 

skills outside the VISSIM functionality (such as demand modeling or signal 

control design) or project related tasks. If you are interested in one of these 

topics, we are happy to offer you consulting or a dedicated training course 

on that subject at competitive rates. 

In case you have got a maintenance contract with one of our local 

distributors, please contact them for hotline support. All other clients, please 

use hotline@ptvamerica.com (for North America). 

Prior to contacting the VISSIM hotline, please do the following: 

► Refer to your manual, since mostly the required information can be 

found therein. 

► Refer to the FAQ list provided via Internet. It includes numerous helpful 

hints and describes various modeling problems and how to solve them. 

If your maintenance contract is with PTV AG, please help us providing a fast 

and effective hotline service by using the hotline contact form provided via 

http://www.ptv-vision.com/hotline_vissim and complying to the following 

guidelines: 

When posting a mail to the VISSIM hotline, please include the following 

information: 

► Detailed description of the problem and of the actions that have been 

taken beforehand (so that we can reproduce the error) and a 

screenshot (*.JPG) if necessary. 

► All data files which are required to reproduce the error or the problem. 

The following details are automatically stored in the hotline contact form: 

► VISSIM version no. and service pack no. (e.g. 5.30-04), 

cf. also VISSIM window title, 

► Program edition (32 bit / 64 bit) 

► Operating system and service pack no. 

► PTV customer no. 

► Dongle no. 

Thank you for your cooperation. 



15.4 Services 

Website PTV operates an English internet site at http://www.english.ptv.de. Here 

you’ll find additional product information, sample AVI files for download and 

the FAQ and service pack download areas (see below). 

Our colleagues in the U.S. operate another website at 

http://www.ptvamerica.com with some additional features like a user forum 

and a download area for VISSIM 3D models. 

Training PTV offers training classes both for new and advanced users. Classes can 

be arranged as training-on-the-job at whatever location you prefer, or you 

may join one of our set training sessions. Details are available on our 

websites at http://www.english.ptv.de/software/transportation-planning-trafficengineering/trainingevents/ 

and http://ptvamerica.com/trainingevents.html. 

If you are interested in a training-on-the-job and would like to receive an 

offer, please contact either your local distributor or PTV directly at 

Info.Vision@ptv.de. 

Software 

Maintenance 

Service 

Packs 

In order to stay up-to-date with your VISSIM software and to benefit from 

extended services, PTV and some of our distributors offer software 

maintenance contracts. Benefits include 

► Free updates whenever a new VISSIM version is available 

► Download of service packs of the latest VISSIM version 

► E-mail hotline support not only in the case of program errors but also for 

modeling and other problems (for trained users) 

► Access to the extended FAQ section in the internet 

For more information on software maintenance contracts, please contact 

your local distributor. Alternatively, you may contact PTV directly at 

Info.Vision@ptv.de (offers and delivery procedures). 

For all clients with a software maintenance contract, service packs of the 

latest VISSIM version are available for download at 

http://www.english.ptv.de/cgi-bin/traffic/vissim_download.pl. Please note that 

service packs can be used with the latest VISSIM version only. 

In the download area on our website you can also register for an automatic 

e-mail notification whenever a new VISSIM service pack is available 

FAQ At http://www.ptv-vision.com/faq_vissim you can find a wide selection of FAQ 

(frequently asked questions) on VISSIM. 

For all clients with a software maintenance contract, an extended range of 

FAQ is available after entering the password supplied with the program 

license (see letter of delivery). 

Technical 

Hotline 

PTV operates a technical hotline e-mail service for VISSIM, cf. section 

15.3.2.

VISSIM 5.30-05 User Manual

Create successful ePaper yourself

Delete template?

Save as template?