Reference Manual Cube Dynasim 6.11

Version 6
Whats new in version 6
Changes in Files and directories, page 38.

The ability to share categories between different projects with the Categories database, page 52.
The Signal scenario graphic interface has been added.
The ability to establish a complete connection between the client and the Traffic Control System Utopia, page 399.
Import text file for programing classic controller (see Import signal programing, page 316).
New types of flow scenarios:
Empty scenario, page 113,
Aggregate, page 149.
New types of counts:
Traffic count percentage, page 127,
Traffic count in a database, page 129.
New editing features for counts:
Splitting a traffic count, page 133,
Import the values of traffic counts from a text file, page 134.
Reduce computation time and minimize file size while compiling flow boxes based on bitmaps.
For assignment flow, or sub network assignment, it is possible to modify path flow estimation before
assignment.
Transit stops, page 272 now have a randomized probability that the driver will stop.
New editing features for Timetable, page 284.
New panel for simulation scenario allowing to separate, for the same simulation scenario, the calculation of the demand from the replication, from the compilation of the reports. The same flow scenario
shared by different simulation scenarios will be computed only once. Moreover, the Simulation module
in Compute scenario mode, page 408 allows multiple selection of scenarios to be computed in parallel
DYNASIM - REFERENCE MANUAL
WHATS NEW IN
VERSION 6
Whats new in CubeDynasim:

to the demands, the replications and the reports (in one click).
New keyboards shortcuts for displaying and editing simulations objects.

The functionalities of the Animation in the network edit area, page 24 have been enhanced so that the
user can select an existing simulation scenario and directly display all types of error messages for this
scenario.
Parking simulation, the update lot can simulate drivers leaving the parking because they are tired of
looking for a free spot.
Rail simulation, new continuous sideways, allowing multiple hooking-unhooking maneuvers.
Whats new in version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 1
Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Projects and simulation models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Flow scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Network scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Signal scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Public transport scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Edit modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Menu bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Button bars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Network edit area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Status areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Animation in the network edit area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Module entry window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Object entry windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Name field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Integer numeric value field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Color field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Single-choice list field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Multiple-choice list field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Chapter 2
Managing projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Project management window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Files and directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Installing CubeDynasim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Creating a project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Deleting a project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Modifying a project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Adding a simulation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Deleting a simulation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Chapter 3
Vehicle categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Managing categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Graphic representations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Editing 2D representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Editing 3D representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Movement capacities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Categories database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Saving a category. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Import a category. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Chapter 4
Background map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Maps Management window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Background map in DXF format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Background map in bitmap format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Tiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Map Management window for bitmap files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Chapter 5
Layers and network scenarios . . . . . . . . . . . . . . . . . . . . 61

Using layers and network scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Managing layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Network scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Chapter 6
Network origins & destinations . . . . . . . . . . . . . . . . . . . . 67

Origins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Stages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Example of modeling a network origin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Representation of a zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Creating a zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Chapter 7
Road network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Vehicle network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Trajectories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Creating the vehicle network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Editing the handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Editing trajectories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Speed distributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Creating a Percentage distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Creating a Maximum Speed distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Creating a Category distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Pedestrian crossings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Representation of a pedestrian crossing in the edit area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
Creating a pedestrian crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Editing and deleting a pedestrian crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Underpass object and 3D tile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Underpasses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
Representation of an underpass object in the edit area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100
Creating an underpass object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3D tile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Modeling the road network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Modeling weaving lanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104
Modeling an increased/reduced number of lanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Modeling a traffic circle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Chapter 8
Flow module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Flow scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Defining a flow scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Empty scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Generator scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
The Generator scenario edit window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Subnetwork scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

The links/nodes network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Export-Import scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Edit a flow scenario of type Export-Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
Format of the path-flow files to be imported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125
Traffic counts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Traffic count direct entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
Traffic count percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
Traffic count in a database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129
Adding a traffic count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Editing a traffic count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Splitting a traffic count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Import the values of traffic counts from a text file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Estimation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Principle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Examine the results of the estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Analyze the results of the flow calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
Assignment scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Principle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Create an Assignment flow scenario.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Examine the result of the assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Subnetwork Assignment scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Principle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Examine the result of the subnetwork assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Aggregate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Paths: visualization and analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Flow box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Paths on trajectory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .154
Scenario comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Chapter 9
Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Speed link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
Split link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Split link by PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Prohibitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
The different types of prohibitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
Invalid paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168
Prohibitor field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
MP prohibitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Creating a MP prohibitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173
Editing a MP prohibitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Lane changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Insertion gaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Behavior associated with lane satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Lane change distance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Creating a lane change distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Car-following rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Lane change distributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Overview of lane change distributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185
Lane Change Distributions window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Lane change marker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
MP Lane Change Marker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
The break continuity object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
VMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
Chapter 10
Managing conflicting trajectories . . . . . . . . . . . . . . . . . 197

Gap time distributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Creating a gap time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Editing gap time distribution parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Traffic circle insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Left turn across a flow with priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
Stop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Stop line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Representation of the stop line in the edit area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Creating a stop line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Editing a stop line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Adding a condition on a stop line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Yield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
The elements of a yield. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Creating a yield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Editing a yield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209
Use of the yield. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Yield-on-green. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Representation of a YOG in the edit area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Creating a YOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215
Editing a YOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .215
Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Representation of the stop in the edit area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .217
Creating a stop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Editing a stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Strict stop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Representation of a strict stop in the edit area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Creating a strict stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Editing a strict stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Example of how to use a strict stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Stop-if-stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Representation of a stop-if-stop in the edit area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224
Creating a stop-if-stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Editing a stop-if-stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Example of how to use a stop-if-stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Stop-on-red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Representation of an SOR in the edit area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228
Creating an SOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Editing an SOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Example of how to use the SOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
Chapter 11
Data collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

What to measure, and how to measure it. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Deficit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Number of vehicles present . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
Stop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Number of stops per vehicle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Stop state duration per vehicle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
Travel time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239
Travel speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240
Flow by lane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240
Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Inter-vehicle times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Occupancy rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Instant speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242
Green signal duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Red state duration for a signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243

Signal line crossing duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
Vehicle scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Storage of the values measured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
SQL queries, optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248
Installing an ODBC driver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Extracting data using OpenOfficeTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252
Extracting data using ExcelTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254
Tables generated at the end of the simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Representation of data collectors and editing them. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Data collector representation and associated elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Creating a data collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Editing a data collectors geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
The data collector entry window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Creating/Editing/Deleting a group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265
Editing/Deleting a data collector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267
Editing the criteria measured for a group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269
Chapter 12
Public transport module . . . . . . . . . . . . . . . . . . . . . . . . 271

Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Transit stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .272
Tolls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .274
Incidents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Terminus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Public transport scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Public transport module management window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Creating/Editing/Deleting a PT scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Creating/Editing/Deleting a PT line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Creating a timetable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
Edit the schedule of a timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .285
Timetable assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Creating a timetable assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Chapter 13
Signals module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Signals with two states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Signals with three states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .290
Creating and editing a signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Representation of signals in the edit area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Creating a signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Editing a signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Multimarker detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Single-marker detectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Representation of controllers in the edit area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Creating a controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Editing a controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Signal scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .308
Programing controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .308
Editing signal scenarios in CubeDynasim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Classic Programing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Edit states of the signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
Rules between detectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Operations that modify the diagram during a simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
Edit actuated signal operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .322
Examples of signal programs with CubeDynasim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Files generated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Chapter 14
Socket programming. . . . . . . . . . . . . . . . . . . . . . . . . . . 337

DynasimServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
DynasimServer on the server side (external program) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
DynasimServer on the client side (micro simulator) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Editing and naming objects in CubeDynasim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342
Defining the client in CubeDynasim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Simulation in client mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
The Socket library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345
General architecture of the program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Compile and launch the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Managing scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .356
Generate a log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .358
Classes and methods of the Socket library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Controler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .366
Capteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367
QsOu_RegExpCapteur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
QsEt_RegExpCapteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
QsXor_RegExpCapteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .370
QsNo_RegExpCapteur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
QsAcquitte_RegExpCapteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
QsDAGeLt_RegExpCapteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
QsDALt_RegExpCapteur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
QsDALe_RegExpCapteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .373
QsAttGEattMax_RegExpCapteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
QsDaMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .374
NextPhase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
NextPhaseAtTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .377
PointRepos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .379
Adaptativ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
EscamotLigne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
ChgeEtat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Complete example of programming with the Socket library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Utopia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Utopia controllers (CubeDynasim) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .399
Editing and naming objects in CubeDynasim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .400
Defining the CubeDynasim UTOPIA client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Simulation in client mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Chapter 15
Simulation module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

Simulation module in Edit scenario mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Add a simulation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Delete a simulation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .407
Edit a simulation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Simulation module in Compute scenario mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408

Compute the Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Calculate the simulation (in fact the replications). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Generate report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Stop the replications during the calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Modify the autoblock conditions without replicating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Export the simulation scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Simulation module in Results mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Comment a replication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Simulate a replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Delete an animation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .414
Animate a simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Consult the messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Simulation module in Draw mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Chapter 16
Parking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Model development and the simulation of parking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Parking Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Attractor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Create or edit an attractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Aisle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
The parking lot objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Create, edit a parking lot object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Link an aisle to the road network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .434
Clone an aisle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .436
Parking Lots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

Parking Lot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Assign Lot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .440
Update Lot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .443
Count display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

Distribution of lane changing behavior in the parking lot. . . . . . . . . . . . . . . . . . . . . . . . . 448
Modify the appearance of the vehicles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Vehicles present at the beginning of the simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Vehicles parks at a certain parking lot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .450
Chapter 17
Animator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Animation menu bar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .453
Controller Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .453
Animation cursor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .454
View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
2D view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .455
3D view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .459
View of a controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Saving the animator configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464

Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .464
Playing the animation as a continuous loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Chapter 18
DynasimViews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
View scenarios window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Scenario display area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Command area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
View results window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470

Group list area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Edit area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Command area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Chapter 19
License and transfer codes. . . . . . . . . . . . . . . . . . . . . . 475

License code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Export code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Presentation
CubeDynasims graphic editor enables the user to define all aspects of a simulation model; with it, the user
can position objects on a background and define these objects using data entry windows.
Licenses and transfers can be managed via the License and transfer codes, page 475 menu.
The simulation engine is microscopic, stochastic and event-driven. Microscopic simulation helps to consider each moving vehicle according to its behavior and immediate environment. The simulation model is
stochastic because the parameter values (for example, a behavioral parameter) are obtained from statistical
distributions. During the simulated time period, an event (for example, a traffic signal change) can impact a
vehicles motion.
There are different tools for viewing and analyzing simulation results:
1.
2.
3.
4.
5.
The animator, which reproduces vehicle movements calculated by the simulation engine as
graphic animations in two or three dimensions.
The grapher, which displays the statistical results as curves according to criteria measured during
the simulation, such as the travel time or the flow.
Standard tables, obtained from criteria measurements taken during the simulation. They give a
summary view of how the various simulated developments work.
Flow illustrations, obtained from the quantification of the demand.
Signal programs, obtained via the signals module.
PRESENTATION
CubeDynasim is a software application for modeling and simulating the operation of transportation infrastructures including rail and waterways. CubeDynasim includes a graphic editor, a simulation engine and
tools for viewing and analyzing simulation results. These three components are directly accessible via the
CubeDynasim interface.

This chapter breaks down into two parts:
Projects and simulation models, page 11 which gives a definition of the terminology and methodology implemented to develop simulation models in the field of highway infrastructure operation,
User interface, page 13 which describes the main components of the CubeDynasim humanmachine interface, giving access to the simulators various functions.
10
PROJECTS
AND SIMULATION MODELS
Projects and simulation models

A simulation model reproduces the operation of a development. This model is characterized by parameters
referenced in one of the following four categories: Flows, Networks, Signals and Public Transport (PT). The
different parameters are grouped into scenarios, whereby a scenario usually corresponds to a hypothesis to be
tested. A simulation scenario comprises Flow scenarios, page 110, Network scenarios, page 65, possible Signal scenarios, page 308 and Public transport module, page 271 scenarios. A project compiles a set of simulation scenarios that "share" a certain number of parameters (see Projects and simulation
models, page 11).
Flow scenarios
Flow-type parameters quantify the demand of vehicles wanting to use the modeled development. The
CubeDynasim simulator can distinguish three types of quantification in terms of the demand:
In CubeDynasim, a flow basically refers to the quantification of the demand. You can define different
demand quantification hypotheses. A flow scenario corresponds to each of these hypotheses. The flow scenario-based approach makes it easier to study the operation of the simulated development at morning or evening peak times, or even future forecasts.
A simulation scenario necessarily includes a flow scenario (see Flow scenarios, page 110).
Network scenarios
Network scenarios contain all the simulation objects that describe the trajectories taken by the developments
users. This includes the sequence of trajectories, the management of trajectory conflicts, and the positioning
of regulation elements such as signals, detectors, etc.
CubeDynasim uses layers to share a subset of simulation objects among two network scenarios. Simulation objects are thus compiled in layers, and layers are in turn compiled in network scenarios. This technique
makes it possible to reuse portions of the road network common to two different network scenarios.
It must be noted that the networks entry and exit points are common to all the network scenarios in a project.
The entry and exit points serve to establish a connection between the network scenarios, the flow scenarios,
and the public transport (PT) scenarios for the simulation.
The network scenario can be edited/viewed in either logical or geometric modes.
Geometric mode corresponds to a description of the simulation objects determined by a dimension and/or
physical coordinates. The editing of trajectories, trajectory conflicts, the location of traffic signals and detectors, and the definition of data collectors are done in geometric mode.
Simulation objects without dimensions, i.e., trajectory sequences (links) and entry/exit points on the network, are edited in logical mode.
11
PRESENTATION
Quantification of OD-type vehicles:

origin-destination matrix, depending on the vehicle category and the time sample,
OR an estimation of the paths that satisfy a certain number of directional or ad hoc traffic counts,
OR an assignment of an origin-destination matrix resulting from an estimation on a new network,
OR a set of paths defined by a third party software solution,
Quantification by direct movement, applied to pedestrian crossings,
Quantification by frequency, applied to the definition of public transport lines.
P R O J E C T S
AND SIMULATION MODELS
A simulation scenario necessarily includes a network (see Network scenarios, page 65).
Signal scenarios
Signal scenarios are used to simulate different signal timing strategies. This consists in defining - for the simulation - the diagram of signals times and, if necessary, the actuated signal control. As with network scenarios, the signal scenario compiles a set of layers defining the signals to be considered.
A simulation scenario does not necessarily incorporate a signal scenario. The set of layers in the signal scenario must be included in the set of layers in the network scenario of a simulation scenario (see Signal scenarios, page 308).
Public transport scenarios

The public transport scenario is used to quantify the demand according to a line-based logic. For each line
simulated, you define the points of origin and destination in the network, and a stop frequency or stop times.
A simulation scenario does not necessarily incorporate a public transport scenario (see Public transport module, page 271).
12
USER
INTERFACE
User interface
Simulation models are mainly edited in the main window. The main window contains the "tools" used to edit
and view a projects various simulation models. These tools are accessible according to the edit mode in use.
The section describes the following :
Edit modes, page 13,
Menu bar, page 14,
Button bars, page 15,
Network edit area, page 19,
Status areas, page 24,
Module entry window, page 27,
Animation in the network edit area, page 24,
Object entry windows, page 28,
Name field, page 29,
Integer numeric value field, page 31,
Color field, page 31,
PRESENTATION
Single-choice list field, page 32,

Multiple-choice list field, page 33,
Views, page 33.
Edit modes
There are three edit modes that affect the main windows appearance:
Geometric mode is used to edit elements determined by geometric positioning (trajectories, priority rules, etc.), see the "Main CubeDynasim window in geometric mode" (see fig. 1, page 14).
2. Logical mode is used to name and identify the networks incoming and outgoing traffic, the conditioned trajectory sequences, etc., see the "Main CubeDynasim window in logical mode" (see
fig. 2, page 14).
3. Rail mode for editing and model rail network.
1.
The appearance of the main window in CubeDynasim is determined by the current mode. While the objects
differ from one mode to the other (simulation object bar), the general modules (tool bar and module bar) are
present in both modes.
Click the
button on the tool bar to switch to logical mode. Click the
to geometric mode.
13
button to switch CubeDynasim
SER
U
INTERFACE
Menu bar
Tool bar
Object bar
Network
edit area
Module bar
Information area
Message area
Figure 1. Main CubeDynasim window in geometric mode
Menu bar
Tool bar
Object bar
Network
edit area
Module bar
Information area
Message area
Figure 2. Main CubeDynasim window in logical mode
Menu bar
Located at the top of the CubeDynasim main window, the main menu bar offers access to all the CubeDynasim functions. Each menu contains commands and sub-menus. The menu bar has six menus : File, Edit,
Multilane, Distributions, Car-following rules, Report, Parking, View and Help. Menus and their commands
do not change with the edit mode.
To select a menu command:
1.
2.
14
Click the desired menu to display its commands.

Click the desired command, or press Esc to quit select item mode.
USER
INTERFACE
To select a sub-menu:
Select a command containing a sub-menu (indicated by a black arrow).
2. A sub-menu is displayed: click the desired sub-menu command, or press Esc to quit select submenu mode.
1.
Button bars
Button bars offer easy access to the commands used when editing the model. To display a tool-tip describing
the buttons function, rest the mouses cursor on the button.
The CubeDynasim main window contains the following three button bars :
Toolbar, page 15,

Simulation object bar, page 17,
Module bar, page 18.
Toolbar
15
PRESENTATION
The "Toolbar" (see fig. 3, page 16) contains buttons used to modify the status of the Network edit area,
page 19, and to facilitate access to the functions used most frequently. The functions available are always the
same whatever the mode (logical or geometric) in use. They are activated by left-clicking the corresponding
button.
SER
U
INTERFACE
Figure 3. Toolbar
Quick selection to select and display Network scenarios, page 65
Quick selection to select the Flow scenarios, page 110.
Quick selection to select one of the possible Signal scenarios, page 308.
Quick selection to select one of the possible Public transport scenarios,

page 277.
Button for shortcut simulation: Animation in the network edit area, page 24.
Switch to logical edit mode.
Switch to geometric edit mode.
Hide background map

The user can momentarily hide the background map to optimize the display rate, thus making it easier
to edit the model.
Edit mode (see Edit Object mode, page 20).
Pan mode (see Pan mode, page 24).
or
Zoom mode (see Zoom mode, page 20).
Save the model being edited. You can also save it via Menu bar, page 14, by selecting File
> Save.
or
Advanced zoom adjusts the zoom level to display all the elements in the network edit area.
There are three types of advanced zoom: Object zoom on all simulation objects (
zoom on the simulation objects in the current network (
), Network
), and Background Map zoom on the ele-
ments in the background map ( ). These three types of advanced zoom must be distinguished in
order to solve the problem that occurs when updating a background map, which is defined in a new
marker. Here, the objects in the simulation model are no longer positioned on the background map.
You may have the impression that you have lost your changes, since the simulation model is no longer
displayed. By switching from one advanced zoom mode to another, you will see that the position of
the objects in the simulation model and the background map no longer correspond.
By leaving the mouses cursor over the toolbars
button for a few seconds, the advanced zoom
current status is displayed in a tool-tip.
To perform an advanced zoom depending on this status, left-click the
button.
To change the type of advanced zoom :
16
1.
Left-click and hold the
button.
2.
When the sub-menu opens, move the mouses cursor to the appropriate sub-item.
USER
INTERFACE
Simulation object bar
Measure
Invalid path
Lane change
Measure
Pedestrian
VMS
Single lane 2.0
Underpass
3DS tile
Conflict
Signal
Traffic count
Detector
Stop
Timetable
The simulation object bar contains buttons to change the edit area toCreate Object mode, page 19. The
simulation object bars appearance changes depending on whether you are in logical or geometric mode see
The simulation object bar in geometric mode, page 17 and see Simulation object bar in logical mode,
page 17).
Simulation
object
category
titles
Bars initial
state
Other types
of simulation
object by
category
Dstns
Zones
Stages
Links
Origins
Split links
Simulation object
category titles
Bars initial
state
Other types of
simulation object
by category
Figure 5. Simulation object bar in logical mode

The object categories group together one or more types of simulation objects. For example, the Signals category groups the simulation objects Controller, R11v, R12, R13b, R13c, R24, R25, SAC, PEC, vehicle signals
and pedestrian signals. A button on the simulation object bar corresponds to each simulation object category.
A specific icon is associated with each type of object.
To switch the Network edit area, page 19 to create mode to create a type of simulation object whose icon
illustrates one of the buttons on the simulation object bar :
1.
2.
17
Move your cursor to the button in the simulation object bar.

Left-click. The button remains pressed in and the edit area changes to Create Object mode,
page 19.
PRESENTATION
Figure 4. The simulation object bar in geometric mode
SER
U
INTERFACE
For an object category that includes a number of different objects, to change the type of the simulation
object associated with the button on the simulation object bar:
Move your cursor to the button on the simulation object bar.
2. Keep the left mouse button pressed until the drop-down menu containing the various types of possible simulation objects for the associated category is displayed.
3. Keeping the left mouse button pressed, drag the mouse to the menu item corresponding to the
appropriate simulation object.
4. Release the mouse button.
1.
the menu closes,
b. the new icon selected illustrates the button,

c. the button remains pressed in,
d. the edit area changes to Create
Object mode, page 19.
Module bar
The module bar provides access to the module entry windows (see "Module bar", fig.6 p.18).
Figure 6. Module bar

To open a modules entry window:
Click the appropriate module bar icon.
2. The Module entry window, page 27 is displayed.
1.
The contents of the module bar are not affected by the current mode, i.e., logical or geometric.
Search object
This command is used to find/delete an object in the simulation model.
The search can be performed by browsing the list of objects sorted by name, type, or the layer to which
they belong:
1.
Click
to open the "Search object window" (see fig. 7, page 19).
Click the header of the column corresponding to the appropriate sort key; the arrow displayed next
to the columns header represents the sort order. To invert the sort order, click this header again.
3. Browse the list using the scroll bar.
4. In the list of objects, left-click the object searched for to highlight it and zoom in the network edit
area.
5. Click Quit to close the Search object window.
2.
The search can be performed directly from the objects name :

1.
Click
to open the "Search object window" (see fig. 7, page 19).
In the Name Filter field, enter the name of the object or its first letters followed by the * wildcard
character to filter the list.
3. In the list of objects, click the object searched for to highlight it and zoom in the network edit area.
4. Click Quit to close the Search object window.
2.
It is possible to reduce the number of objects displayed by applying a filter on their IDs. A filter is defined as
a set of characters and/or of meta-characters * replacing any set of characters. For example, the filter
WE_*_1 will display objects named WE_1_1, WE_20ze_1 etc. The filter is defined using the field named
Name Filter of the "Search object window" (see fig. 7, page 19).
18
USER
INTERFACE
The Search object window lists all the objects in the model, even those not included in the current scenario.
If you select an object that is not included in the current scenario, the edit window is zoomed, however the
object is not displayed since it does not exist in the current scenario.
Name filter
List of filtered objects
Validation
buttons
Figure 7. Search object window
Network edit area

The network edit area is used to visualize/edit all the projects simulation objects. The Background map,
page 53 and the graphic representation of the simulation objects are displayed in the network edit area. Each
simulation object has a graphic representation according to the object category to which it belongs, its
parameters, and to the current mode - logical or geometric. The user determines the objects position.
The network edit area is displayed in one of five possible modes :
Create Object mode, page 19

Zoom mode, page 20
Continuous Zoom mode, page 20
Edit Object mode, page 20
Pan mode, page 24
The current mode also determines the shape of the pointer when located in the network edit area.
To modify the part of the network displayed in the network edit area, you can use the scroll boxes along the
borders of the display area. You can also use the mouse wheel to move the area displayed vertically, provided
the cursor is inside the scroll area.
Create Object mode
You switch to Create object mode after clicking one of the buttons on the Simulation object bar,
page 17.
19
PRESENTATION
Entry line displaying the selected

object
SER
U
INTERFACE
The mouse pointer changes to
in the network edit area.
The subsequent operations to perform for creating network objects are described in the chapter dealing with
the type of simulation object.
In Create object mode, you can use the following functions:
1. Pan mode, page 24, using the middle mouse button instead of the left button.
2. Continuous Zoom mode, page 20, using the mouse wheel.
Zoom mode
To increase or decrease the scale at which the background map and the simulation objects are displayed :
Switch to zoom mode by clicking the
button on the toolbar. The mouse pointer changes to
2. In the edit area, position the pointer at the center of the area you wish to zoom in on.
3. Left-click to zoom in and right-click to zoom out.
4. The edit area remains centered on the selected point.
1.
Continuous Zoom mode

Switch to continuous zoom mode by clicking the
button on the Toolbar, page 15.
To continuously zoom in or zoom out :

Position the mouse cursor in the edit area away from any network objects.
Click and drag up or down to zoom in or out, or use the mouse-wheel to the same effect, whatever
the pointers status.
3. The scale is modified continuously until the left mouse button is released.
1.
2.
The zoom window function is accessible in continuous zoom mode. The window is delimited by a rectangle,
defined by two opposite corners, either from left to right or from right to left, regardless. The zoom factor is
defined by the minimum height or width ratios between the rectangle and the edit window.
Right-click to define the first corner of the selection rectangle.
2. Drag the mouse to define the rectangle.
3. Right-click again to complete the rectangle that defines the selection window.
1.
In continuous zoom mode, you can use the Pan mode, page 24, function using the middle mouse
button instead of the left button.
Edit Object mode
You enter edit object mode by clicking the
20
in the edit area.
USER
INTERFACE
In edit object mode, you can:
delete or modify a simulation object, or place it in the background or foreground

Switch to edit object mode.
2. Position the pointer on the simulation object to modify. Right-click to display a drop-down menu
containing Modify, Foreground, Background, Delete.
3. Drag to the appropriate menu item keeping the right button pressed.
4. Release, for example, on Modify to display the simulation object entry window.
1.
move a simulation object on the background map

2. Position the pointer on the object to move.
3. Left-click and hold to move the object.
4. Release at the desired location.
1.
select a simulation object

2. Position the pointer on the object to select.
3. Left-click to select the object.
1.
deselect an object or multiselection

1.

Left-click in the edit area away from any object.
perform a multiselection
1.
2.

Keeping the Shift key pressed, left-click the objects displayed in the edit area that you wish to add
to the selection.
perform a multiselection in a rectangle

Keeping the CTRL key pressed, right-click at the point where you want to start your selection
rectangle.
3. Release the mouse button, then drag the mouse to the opposite corner of the selection rectangle.
4. Right-click again once you reach the opposite corner. All objects that are not part of a frozen layer,
and that are completely or partially situated inside the rectangle, are selected (see Using layers
and network scenarios, page 62).
1.
2.
perform a multiselection by path

This consists in selecting a sequence of paths that a vehicle can take during the simulation.
1. Switch to edit object mode.
2. Position the pointer at the start support of the path to select.
3. Right-click to display the drop-down menu associated with the support. Keeping the button
pressed, drag the mouse to the "Select path" menu item.
4. The selection is extended up to the next fork, or to the end of the network. For a fork, a dialog box
is displayed in which you can choose to either stop the selection, or extend it by selecting one or
other of the forks corresponding paths.
21
PRESENTATION
2.
SER
U
INTERFACE
Selected
trajectory
Clicked
handle
Figure 8. Multiselection by path
22
USER
INTERFACE
Multiselection or rectangle multiselection operations invert the selected/deselected states of the

objects.
In other words, for a multiselection by rectangle, all the objects inside the rectangle that are in the
selected state change to the deselected state; the other objects in the rectangle switch from the
deselected state to the selected state.
move a set of objects

Make a multiselection, a rectangle multiselection, or a multiselection by path on the objects to
move.
2. Position the pointer on one of the objects selected (it is highlighted).
3. Keeping the left button pressed, move the mouse as appropriate.
4. Release the button to complete the operation.
1.
modify a set of objects : change the layer, switch to the foreground/background, delete, change the
speed limit.
1. Make a multiselection or a rectangle multiselection on the objects to modify.
2. Position the pointer on one of the objects selected.
3. Right-click and drag the mouse to select the appropriate operation.
rotate a set of objects

Make a multiselection, a rectangle multiselection, or a multiselection by path on the objects to
move.
2. Right-click and select Rotate in the menu.
3. Left-click and hold, then move the mouse to define the angle of rotation.
1.
Make a multiselection or a rectangle multiselection on the objects to clone.

Position the pointer on one of the objects selected.
3. Right-click and drag the mouse to select the Clone menu item and open the corresponding window.
1.
2.
4.
Define the naming rule applied to the cloned objects by filling in the fields according to the following rules :
if possible, replace the old prefixes with the new prefixes, or else concatenate the new prefix and the
original object name,
b. if the name of the cloned object already exists, add the "CL !" prefix.
a
5.
The multiselection now applies to the cloned objects, which cover the old objects. You must move
the selected objects in order to distinguish the original ones from their clones (see move a set of
objects, page 23).
paste the parameters of one path to a set of paths (see Copying/Pasting trajectory properties,
page 91).
You must select an object to change a subset of its geometric characteristics.
For a multiselection, you can move, delete or modify the order in which the selected objects are displayed,
and assign them a common layer.
23
PRESENTATION
clone a set of objects
SER
U
INTERFACE
Pan mode
To enter pan mode, click the
The pointer changes to
To Pan in edit mode:

Switch to pan mode.
2. Position the pointer in the edit area away from any objects.
3. Left-click and drag the mouse.
4. Release when you have finished panning.
1.
In Create Object mode, page 19, Continuous Zoom mode, page 20, and Edit Object mode,
page 20 pan mode is accessible by following the same procedure using the middle mouse button
instead of the left button.
Status areas
The two status areas are located at the bottom of the "Main CubeDynasim window in geometric mode" (see
fig. 1, page 14).
The information area displays parameters specific to the simulation object the mouse is pointing to regardless of the mode of the Network edit area, page 19. Moreover, when pointing to Handles, page 80,
Trajectories, page 81, or Links, page 158, the object will be highlighted in the Network edit area,
page 19.
The message area offers guidance about the appropriate actions and their consequences depending on
CubeDynasims current mode. When creating a simulation object, the message area reminds you of the possible commands.
Animation in the network edit area

CubeDynasim can be used to define, simulate and animate a simulation scenario in the interface. This feature allows you to quickly analyze a situation without having to start a number of replications.
24
USER
INTERFACE
Define a simulation scenario

To define a simulation scenario in the editor, use the quick selects in the Toolbar, page 15 to select the
network and flow scenarios and, optionally, the signal and PT scenarios to define a simulation scenario.
Select a simulation scenario
To select an existing simulation scenario, click on
Click on one of the displayed simulation scenarios. The quick selections of the Toolbar, page 15 are automatically updated.
25
PRESENTATION
Figure 9. Animation in the edit area
SER
U
INTERFACE
Calculate a simulation scenario
Once the scenario has been defined, its status is indicated by a circular indicator to the right of the list of
quick selections.
The
indicator specifies that the scenario has never been simulated and that the animation is therefore
not available.
Click this button to add the scenario to the simulation scenarios in the Simulation module, page 403
and start the scenarios calculation.
The
indicator specifies that the scenario is being calculated and that the animation can already be
displayed in this state.
The
indicator specifies that the scenario has been simulated and is up to date. The animation is avail-
able.
The
indicator specifies that the scenario exists and has been simulated in the past, but that its animation, even if it is available, no longer matches the model.
Click this button to start the simulation and get an updated animation.
Uppercase + left click on the indicator opens the "Messages window" (see fig. 213, page 415).
Animate a scenario in the edit area
The CubeDynasim animator integrated in the edit area has three modes:
the animation for the active scenario, defined by the statuses of the quick selection lists, is not
available.
This mode corresponds to the gray simulation indicator.
the animation for the active scenario is available; click this button to access the animation control
buttons.
the animation for the active scenario is in progress in the models edit area; click this button to close
the animation and go back to the model in edit mode.
To animate a scenario in the models edit area, click the

page 26 is subsequently displayed.
button if available. Integrated animator bar,
Figure 10. Integrated animator bar
Restart: restarts the animation from the simulation start time.

Previous: rewinds the animation in 5-minute increments.
Step: forwards the animation by one quarter of the value of the animation speed.
Play/Pause: plays or pauses the animation.
Next: fast forwards the animation in 5-minute increments (provided the simulation at t + 5 min was animated beforehand).
Time field: this editable text field shows the current time of the animation. You can edit this field to move
to a given moment in time (provided the simulation calculation has finished or is sufficiently complete.)
To change the animation time, click on the hour, minute or second in the field and enter the corresponding value. After a few moments, the animation in the edit area moves to the instant entered.
Speed field: the vehicle animation speed can be modified either via the numeric field (where 1 corresponds to real time, 2 to twice the speed of real time, etc.), or via the speed slider that you can move to the
left to reduce the animation speed, or to the right to increase it.
26
USER
INTERFACE
Module entry window

This section demonstrates how module entry windows work.
Module entry windows are used to edit elements required by the simulation scenarios. In the project, an element is grouped within a homogeneous set of elements. For example, a network scenario is an element; it
belongs to the set of Network scenarios, page 65 defined for the project. You access the module entry
windows via Module bar, page 18.
To display the help associated with a module entry window:
1. Move the cursor over the module entry window.
2. Press F1.
The "Module entry window." (see fig. 11, page 27) comprises three parts :
the Display area, page 27,

the Edit area, page 28,
the Command area, page 28.
Selected
element
Edit
area
Command
area
Figure 11. Module entry window.
Display area
The display area lists all the elements defined for the module being edited. This list comprises various columns corresponding to the elements parameters. Heading labels identify the columns.
The elements are sorted based on the value of one of the columns. An arrow to the right of the column label
indicates the parameter determining the order of the list. An up arrow indicates an ascending sort order, a
down arrow indicates a descending sort order.
27
PRESENTATION
Display
area
SER
U
INTERFACE
To select the parameter which determines the order of the list, click on the parameters column label. To
reverse the order, click the column label again.
The selected element in the list is highlighted. By clicking on an element in the list, you effectively select this
element, and the fields in the edit area are updated according to this elements parameters.
Edit area
The edit area can be used to edit all the fields of the selected element. These depend on the type of element
being edited.
Command area
The command area contains buttons used to switch the Edit area, page 28 to the Display area,
page 27, as well as to delete elements and close the module entry window.
The command area can be used to perform the following operations:
add an element to the set of elements

Edit the fields in the edit area.
2. Click the Add button in the command area.
3. If there is no conflict with elements already entered, the element is added and becomes the
selected element.
1.
delete an element
Click the element to delete in the display area; the element becomes the selected element.
Click the Delete button.
3. The element is deleted from the list.
1.
2.
modify an element
Click the element to modify in the display area; the element becomes the selected element.
2. Modify the values of the fields in the edit area.
3. Click the Apply button to validate the elements modifications.
1.
You can navigate and edit the various fields in the module entry window using the keyboard.
Press the Tab (tabulation) key to move the cursor through the various fields in the Display area,
page 27 and the Edit area, page 28 then through the various buttons in the Command area,
page 28. Press Shift + Tab to navigate in reverse
Use the up and down arrow keys to change the field selected in the Display area, page 27.
When the element is determined by a field whose value must be unique, if the field has the same value
as another element in the list, then the other element will be modified, not the selected element.
Object entry windows

The "Object entry window" (see fig. 12, page 29) is shown when creating or modifying a simulation object.
It is used to edit the parameters of the object.
28
USER
INTERFACE
Figure 12. Object entry window

The window is closed when:
the objects parameters are validated by clicking OK,

the edits are canceled by clicking Cancel.
A field corresponds to each simulation object parameter. The field can be free text fields, numerical values,
choices in a list, or a color.
Name field
All simulation objects are identified by a unique name within the project. These names are used by the editor,
simulation engine and display tools.
An object name is made up of alphanumeric characters. It cannot contain spaces or special characters/
accents.
There are three types of objects, depending on the users level of involvement in naming.
OBJECTS NAMED AUTOMATICALLY AND EXCLUSIVELY BY CubeDynasim

OBJECT TYPE
Links, page 158
Invalid paths, page 168
Priority rules
PREFIXESA
L1, QsLxVideAnd_SLTh, QsLxVide_longueurAnd
Invalid Path_
Stop_, GOG_, Strict_stop_
Managing conflicting trajectories, page 197
29
PRESENTATION
Validate/Cancel
buttons
SER
U
INTERFACE
OBJECTS NAMED AUTOMATICALLY AND EXCLUSIVELY BY CubeDynasim

OBJECT TYPE
Transit stops, page 272
Tolls, page 274
Pedestrian crossings, page 95
PREFIXESA
Transit Stop_
Stop_
PedestrianCross_
a. character string that should not be used to name objects.
OBJECTS NAMED BY THE USER

OBJECT TYPE
Origins, page 69
Destinations, page 74
Stages, page 71
Controllers, page 305
Signals, page 290
Detectors, page 295
SUGGESTED CONVENTIONSA FOR NAMING OBJECTS

< street name > {[N, E, S, W] [N, E, S, W]}{lane no.}_IN
< street name > {[N, E, S, W] [N, E, S, W]}_OUT
< street name > {[N, E, S, W] [N, E, S, W]}{lane no.}_PAL
{scenario_}{controller no._}[B, P, F, CAP] <number>
When using DynasimServer see Editing and naming objects in CubeDy-
nasim, page 342
Data collectors, page 233

a. Elements in { } are optional. The square brackets [ ] define a set in which you must choose a character. N corresponds to North, E to East, S to South, W to West. For the signals and detectors item, D represents a detector, P a
pedestrian signal, V a vehicle signal. The character strings contained in < > are mandatory. IndexX is a counter
incremented by X unit(s).
OBJECTS NAMED AUTOMATICALLY AND RENAMED BY THE USER

OBJECT TYPE
NAMING CONVENTION
Handles, page 80
street
next street1
RN20
next RN21
RN20_1
next RN20_2
Trajectories, page 81
30
Oi#Dj
Oi is the original support, Dj is the target support. They do not have a

common prefix
S (i#j)
Si and Sj are the original and target supports with the same prefix S and
index i and j, of the path
S (Xi#Yj)
SXi and SYj are the original and target supports with the same prefix S
and index i and j, of the path
USER
INTERFACE
The Name field in the simulation object entry window is used to edit its name. By clicking in this field, you
can then enter the appropriate name (see "Simulation object Name field", fig.13 p.31).
Field title
Object name
Text field
Figure 13. Simulation object Name field
Integer numeric value field

The integer numeric value field is used to assign an integer-type parameter. It comprises three parts: the field
title, the entry window which displays the value of the corresponding parameter, and arrows used to modify
the value by increments of 1.
To assign its value, you can:
Click in the field to activate the text entry cursor.
2. Key in the appropriate value on the keyboard.
1.
or increment/decrement it in increments of 1 by right-clicking on the up/down arrow to the right of

the field.
Entry field and current value

Left-click to increment
Left-click to decrement
Field title
Figure 14. Numeric value field
Color field
You can modify the display color of certain simulation objects in the edit area. The color you choose should
represent the objects functional role. This improves the readability of the model displayed in the edit area.
The color codes are:
red for the Road network, page 79 used by all types of vehicles,
magenta for the Road network, page 79 reserved exclusively for public transport,
blue for the Stop line, page 202 and Detectors, page 295,
green for the Prohibitors, page 168 describing the paths,
cyan for the Lane change marker, page 190 dedicated to the assignment of lanes.
When modeling junctions with a large number of complex movements, you are advised to use color codes to
specify each movement category.
The color field is displayed in the entry window as a button in the color currently used by the simulation
object being edited (see Color field, page 32).
31
PRESENTATION
either directly edit the value in the field:
SER
U
INTERFACE
Field title
Color button
Figure 15. Color field
To change the color of the simulation object in its entry window:
Click the Color button to open the Pick a color window (see "Pick a color window", fig.16 p.32).
Select a color.
3. Click OK.
1.
2.
Colors
parameters
New
color
Old
color
Figure 16. Pick a color window
Single-choice list field

The single-choice list field is used to select a value from a finite set of values. It is displayed, depending on
the number of possible values, as a series of option buttons or as a drop-down list.
To assign the value of a "Single-choice list field displayed as a series of option buttons" (see fig. 17,
page 32): click the title corresponding to the appropriate value.
Field title
Selected option button (original)

Series of option buttons
Figure 17. Single-choice list field displayed as a series of option buttons
32
USER
INTERFACE
To assign the value of a "Single-choice list field displayed as a drop-down list" (see fig. 18, page 33):
Click the arrow to the right of the field to display the list of possible values.
2. Click the description in the list corresponding to the appropriate value.
1.
Field title
Arrow to display the list
Selected value (C1_1_R11_1)

List of values
Figure 18. Single-choice list field displayed as a drop-down list
Multiple-choice list field

Use the multiple-choice list field to select any number of values from a list, represented by a list of labels and
option buttons (see "Multiple-choice list field", fig.19 p.33).
Click the values identifier to add/remove it to/from the subset of selected values.
to add all the items to the subset of selected values.
Click the clear-all button

values.
to remove all the elements from the subset of selected
Click the inverse-selection button

items.
to reverse the selected/cleared status of the
Selected element
Elements label
Check-box
Option buttons
Figure 19. Multiple-choice list field
Views
CubeDynasim allows you to graphically analyze the road network according to certain parameters such as
capacity and speed. The views helps to analyze the edited network following the selected parameter.
Depending on the selected parameter, the trajectories are represented in a shade of color that is automatically
calculated between the criterions minimum and maximum values.
33
PRESENTATION
Click the select-all button
SER
U
INTERFACE
Base
Speed
Capacity
Figure 20. Road network views in basic, capacity and speed colors
There are 8 different types of views:
Views/Default Colors: displays the trajectories in the colors edited by the user.
2. Views/Grey Colors: displays all the trajectories in gray color.This view makes it easier to read the
Animation in the network edit area, page 24.
3. Views/Colors from Speeds: the trajectories are displayed in accordance with the value of the lane
speed field. For multi-lane objects, each lanes minimum value is used.
4. Views/Colors from Capacities: the trajectories are displayed in accordance with the value of the
CAPA (Capacity) field.
1.
New views specific to the rail simulation:

Views/Colors from Grade: the rails colors are displayed following their grade.
6. Views/Colors Rails Second Way Speed: the rails colors are displayed following the value of its
parameter Second Speed limit. To display the rails main way speed, select the Views/Colors from
Speeds.
7. Views/Colors from Way: the rails colors are displayed following the value of its parameter Flow
direction.
8. Views/Colors Electrical: the rails colors are displayed following the value of its parameter Electrical.
5.
To select a view:
Click on View of the Menu bar, page 14.
2. Select the appropriate view.
1.
34
Managing projects
A project is identified by its name which is unique for each computer and user.
CubeDynasim groups all the data/results concerning development operation simulations in a project.
This chapter describes:
the operation of the Project management window, page 36, used to handle projects in CubeDynasim,
the Files and directories, page 38, according to the projects and their simulated scenarios.
35
MANAGING PROJECTS
A project groups together a set of data used to simulate a development according to different hypotheses in
terms of flow, network, signal programming and public transport lines.
P R O J E C T
MANAGEMENT WINDOW
Project management window

The project management window is used to :
load a project, page 37,

modify a projects information, page 37,
create a new project, page 37,
delete a project, page 37.
You access the project management window either when you start CubeDynasim, or by selecting
File > New in the Menu bar, page 14.
The "Project Management window" (see fig. 21, page 36) contains three areas: the list area, the edit area and
the command area.
List
area
Edit
area
Command
area
Figure 21. Project Management window

The list of accessible projects and their parameters are shown in the list area.
PROJECT PARAMETERS
LABEL
Project
Date
DESCRIPTION
Project name.
Date you last modified the project.
Version CubeDynasim version used when you last modified the project.
Comment
Text describing the project.
When you start CubeDynasim, the list is sorted in increasing order by date. The selected element displayed
at the end of the list of projects corresponds to the last CubeDynasim project edited and saved.
36
PROJECT
MANAGEMENT WINDOW
From the project management window, you can :
load a project
Double-click the project displayed in the list area.
2. Click the project displayed in the list area, then click Open in the command area.
1.
modify a projects information

Select the project to modify in the list.
2. Modify the Project and Comment fields in the edit area.
3. Click Apply.
4. The projects new characteristics are accepted and shown in the list area. You cannot modify the
Project name when the corresponding project is loaded.
1.
create a new project

Enter a project name and comment (optional).
2. Click Add.
3. If the projects identifier is not already defined in the list, its directories are created (see Creating a
project, page 38).
4. The main CubeDynasim window is opened in geometric mode (see "Main CubeDynasim window
in geometric mode", fig.1 p.14).
1.
delete a project
Select the project to delete in the list.
2. Click Delete.
3. The project is deleted from the list (provided it is not currently loaded), and the file tree structure
is updated (see Deleting a project, page 39).
1.
If the project management window was opened when CubeDynasim was started, you can quit the application by clicking Quit. If the project management window was opened from the menu bar, when you click
Quit, you close the window without quitting CubeDynasim.
37
MANAGING PROJECTS
You cannot undo a project deletion.
F I L E S
AND DIRECTORIES
Files and directories

This section describes how the various files are organized on the hard drive when:
Installing CubeDynasim, page 38,

Creating a project, page 38,
Deleting a project, page 39,
Modifying a project, page 39,
Adding a simulation scenario, page 40,
Deleting a simulation scenario, page 40.
These operations will generally change the organization of the data on the drive when the project is saved.
Installing CubeDynasim
By default, the SetUp wizard installs CubeDynasim in the following directory:
C :\Program Files\Dynalogic\Dynasim.
When you run CubeDynasim for the first time, it creates the edyna project management directory (see Managing projects, page 35). The location of this directory is determined, in order of priority, by :
The % HOME % user variable (to be defined in Windows : Start > Configuration Panel > System, tab Advanced, button Environment Variables),
2. Otherwise, the %user profile % system variable, usually located at
C :\Documents and Settings\User name\edyna.
1.
To
find
the
edyna
directory,
open
Windows
Explorer
and
enter
%HOMEDRIVE % %HOMEPATH %. in the Address field. Windows Explorer opens the directory
containing the edyna directory.
If you move an individual project directory out of the edyna project management directory, the Project
Management window will no longer list the corresponding project.
Creating a project
All the data in the demo1 project is stored in the \edyna\demo1 folder (see "Tree structure of CubeDynasim projects", fig.22 p.39).
The project directory contains the following folders :
edit : contains the models edit files. It also contains in subdirectory bak a backup of these files in their
version prior to the last save,
ico : contains the icon files used for the animation (signals, vehicles, pedestrians),
plans : contains the files used when defining Background map, page 53,
Flow: includes subdirectories storing specific data for each Flow scenarios, page 111,
Report: stores for each scenario, the results of the replication, which is a summary table, a Flow
box, page 152, a Paths on trajectory, page 154, a Scenario comparison, page 155, and diagram signal timings (see Files generated, page 335).
Simul: includes the directories of each simulation scenario (see Module des simulations, page 421).
38
FILES
AND DIRECTORIES
Studies
Study demo
Model
Flow Scenarios
Data computed
flow scenario
Icons for the
animator
Sqlite
database
Maps
Reports for all
scenarios
Comparing flows
Reports for one
scenario
Animation
Figure 22. Tree structure of CubeDynasim projects
Tips for a better usage of CubeDynasim

1) Work locally instead of on a network location.
2) Exclude the project directory of your anti-virus check.
3) Make sure that you have sufficient memory available
The directory also contains files with the *.des extension, used by the simulation results animator.
Do not manually modify the contents of the projects directory.
Deleting a project
From Project management window, page 36, you can delete a project, page 37. When you confirm,
the directory created in C :\*\edyna corresponding to the project is automatically deleted.
Modifying a project
If the project name is modified (see modify a projects information, page 37), the corresponding directory is
renamed.
39
MANAGING PROJECTS
Flow box
Paths on
trajectory
Tables
F I L E S
AND DIRECTORIES
Adding a simulation scenario

When adding a new simulation scenario, CubeDynasim creates three directories named following the names
of its network scenario, flow scenario, signal scenario and PT scenario (see "Simulation module entry window in Edit scenario mode", fig.209 p.406).
in the directory named Simul: idNetwork.idFlow_idSchedule.idSignal.idPT

for example: Simul\Current.Empty_am Peak.Micro.BL23_25
in the directory named Flow: idFlow_idSchedule_idPT

for example: Flow\Current.Empty_am Peak.BL23_25
in the directory named Report: idNetwork.idFlow_idSchedule.idSignal.idPT

for example: Report\Current.Empty_am Peak.Micro.BL23_25
If the simulation scenario has no public transport and/or signals scenario, the corresponding fields do not
appear in the name of the directory created. For example, the directory of a simulation scenario with no signals scenario and no public transport scenario follows the simplified syntax:
idNetwork.idFlow_idSchedule.. .
The name of the directory of a simulation scenario containing solely a Public Transportation scenario follows
the syntax: idNetwork.idFlow_idSchedule..idPT.
Deleting a simulation scenario

When a simulation scenario is deleted from the "Simulation module entry window in Edit scenario mode"
(see fig. 209, page 406), the corresponding directories (placed in Report, Simul and eventually Flow) are
erased. The data will be lost permanently.
40
Vehicle categories
The default vehicle categories are as follows :
Car (CAR)
Truck - 9 meters (TRUCK)
Articulated truck - 13 meters (LONGTRUCK)
Bus (BUS)
Articulated bus (BUS_ART)
Public transport train (TRAMx5)
Long public transport train (TRAMx7)
Pedestrian (PED)
Bike (BIKE)
You can create custom vehicle categories based on these predefined categories.
The chapter deals with the following topics :
41
Managing categories, page 42,

Graphic representations, page 44,
Movement capacities, page 50,
Categories database, page 52.
VEHICLE CATEGORIES
To simulate a transportation system, you must define the properties of the various vehicles that will use this
system. This involves defining each vehicle categorys dimensions (length, width), movement capacities and
method of movement. These properties are used both by the simulation engine and by the animator when it
visually renders the results of the simulation.
ANAGING
M
CATEGORIES
Managing categories
You can create, edit and delete vehicle categories in the Categories window.
To access the Categories window, click the Categories
button on the Module bar, page 18. This window is a Module entry window, page 27. It contains the three properties that represent a vehicle category.
List of
categories
Type of
catgorie
Graphic
representation
Kinematics
capabilities
Command
area
Figure 23. Categories window
42
MANAGING
CATEGORIES
CATEGORY PARAMETERS
LABEL
Name
Type
DESCRIPTION
Unique name of the category, used by other elements in the module, such as Prohibi-
tors, page 168.

Qualifies the demand associated with the category. Three possible choices (see Singlechoice list field, page 32):
1.
Ped: pedestrian-type mobile only accessible via the Pedestrian
crossings,
page 95.
2.
OD : mobiles quantified by Origin-Destination , defined via Flow
scenarios,
page 110.
3.
PT : mobiles associated with Rolling
stock, page 278 in PT lines,
page 278.
4.
5.
6.
7.
Motion
Locomotive: locomotive for rail simulation.

Fret: wagon used for the composition of trains.
Travelers: a passenger car.
Fluvial; ships for waterways simulation.
The method of moving when the simulation results are animated:

Railway: each axle of the vehicle is fixed on the trajectory (see
Road network,
page 79).
2.
Length
Animation 2D
Trailer : only the front axle of the vehicle is fixed on the trajectory (cars, trucks, buses, etc.).
The simulated length of the vehicles, which is calculated automatically. It is the sum of the
elements representing the category in 2D.
Definition
1.
2.
Lengths and widths used by the simulator.

Representation of the vehicles in the category when the simulation results are animated in 2D.
Editing 2D representations, page 44.
Animation 3D
Acceleration
Representation of vehicles in the category when the simulation results are animated in 3D
(see Editing 3D representations, page 47).
Defines the acceleration properties of vehicles in the category (see Movement capacities, page 50).
Emergency Defines the emergency deceleration properties of vehicles in the category (see Movement
deceleration capacities, page 50).
If an event (e.g. signal changes to orange) occurs requiring the vehicle to stop:
1.
2.
3.
The vehicle applies the desired deceleration property if it allows it to respect the event.
Otherwise, the vehicle applies the deceleration property if it allows it to respect the event.
Otherwise the vehicle continues its trajectory and ignores the event.
Desired Defines the desired deceleration properties of vehicles in the category (see Movement
deceleration capacities, page 50).
43
VEHICLE CATEGORIES
1.
RAPHIC
G
REPRESENTATIONS
Graphic representations
You can animate the results of simulations in 2 or 3 dimensions. To do so, you must define coherent category
representations for these two geometric spaces. The representations are defined by lists of graphic files corresponding to the various articulated elements of a vehicle. A car is represented by a single element, whereas
an articulated bus is represented by two elements. For each element, you must define 5 lengths, expressed in
meters in relation to the front of the element (see "Positions of significant points on an articulated truck",
fig.24 p.44).
front
axle
fixation point
rear axle
length of element 1
front axle and fixation
point included
rear axle
length of element 2
Figure 24. Positions of significant points on an articulated truck

Category representations in 2 or 3 dimensions differ both in terms of the types of graphic files involved, and
the possibility of defining several representations of the same category for a 3D representation. In the latter
case, the choice of representations for the animation is determined by a weighted uniform distribution.
Editing 2D representations
To edit a categorys representation in 2D, click the Next button adjacent to the "Animation 2D" property (see
"Categories window", fig.23 p.42). This window is used to add, edit and delete the various graphic elements
that represent the category.
The window displays the categorys complete representation in the display area. The current element is
shown in a blue frame. To select an element, click on its representation in the display area.
The current elements parameters are edited via the edit area (see "Categories window for editing 2D elements", fig.25 p.46).
GRAPHIC ELEMENT PARAMETERS

LABEL
Total length
Length
44
DESCRIPTION
Total length of the category, in meters. This value is automatically updated by the
simulator as you add/remove elements to/from the graphic representation. The
length of the 2D representation is considered by the simulation engine.
Length of the current element, in meters.
GRAPHIC
REPRESENTATIONS
GRAPHIC ELEMENT PARAMETERS

LABEL
Width
DESCRIPTION
Width of the current element, in meters. The simulation engine considers the
largest width of the elements in the 2D category.
AP front
Position of the front axle in relation to the front of the element, in meters.
AP rear
Position of the rear axle in relation to the front of the element, in meters.
AttP back
Position of the point of attachment to the next element, in relation to the front of the element, in meters.
Icon
Defines the graphic file associated with the element selected in the edit area. The files
selected are automatically copied to the projects "ico" directory. The display is adjusted
according to the length and width values entered. The following formats are supported :
1.
2.
Frames/meter
For 2D : xpm, jpeg, gif

For 3D : 3ds
You edit the current element using the windows command area. Click Apply to validate your values.
45
VEHICLE CATEGORIES
Parameters used exclusively for 3D elements.

Defines the animation properties for the selected element relative to the distance traveled,
e.g. the number of 3DS file images displayed per meter traveled. Use it when a part of the
element has to be modified during its movement, e.g. a vehicles wheels, or a pedestrians
arms/legs.
RAPHIC
G
REPRESENTATIONS
Display area
Current element
Edit area
Command area
Current element
Total length of the

category
Geometric properties of
the current element
Icon associated with
the current element
Figure 25. Categories window for editing 2D elements
46
GRAPHIC
REPRESENTATIONS
Proceed as follows to add an element to a category :

1.
2.
3.
4.
5.
6.
7.
8.
Click the Categories

icon on the Module bar, page 18 to open the "Categories window"
(see fig. 23, page 42).
In the list area, select the category whose 2D graphic representation you want to modify.
Click the Next button adjacent to the Animation 2D property. This activates the Categories window for editing 2D elements.
In the display area, click on the element that precedes the element inserted to make it the current
element.
Complete the parameters in the edit area (see Graphic element parameters, page 44).
Click Add.
Click Back.
Click Apply to apply the changes made to the category.
Proceed as follows to delete an element from a category:

1.
2.
3.
4.
5.
Repeat the first 3 steps for adding an element to a category to activate "edit 2D elements" mode.
Click the element in the display area that you want to delete.
Click Delete.
Click Back.
Click Apply to apply the changes made to the category.
To visualize the flow of vehicles in 3D, you must define the categorys representation in this 3D space. Each
category is defined by a non-empty set of representations. In the animation, a vehicles graphic representation is selected at random from the weighted set of representations in its category.
Just like the 2D representation, a 3D representation is defined as an association of elements. 2D and 3D representations of the same category must include the same number of elements. However, they may vary in
terms of their geometric size (length, width), where the geometric sizes used by the simulator remain those
defined for the categorys 2D representation. Each representation is defined by:
1.
2.
47
A weight that affects the likelihood of selecting this representation at random for the animation.
A series of elements that form a 3D representation displayed when the results are animated.
VEHICLE CATEGORIES
Editing 3D representations
RAPHIC
G
REPRESENTATIONS
Proceed as follows to add a 3D representation to a category :

2. In the list area, select the category whose 3D graphic representation you wish to modify.
3. Click the Next button adjacent to the Animation 3D property. This activates the Categories window for editing 3D representations.
1.
List area
containing
the 3D
representations
Edit area
Command
area
Fill in the Weight field.
5. Click the Next button to open the Categories window for editing 3D elements.
4.
48
GRAPHIC
REPRESENTATIONS
List of elements
in the 3D
representation
Edit area for the

current element
6.
This window works like the "Categories window for editing 2D elements" (see fig. 25, page 46).
Use it to add, edit or delete elements in the 3D representation. The differences concern:
a
The format of the graphic files; here they are exclusively in 3ds format.
b. The Frames/meter field (see
7.
8.
9.
10.
11.
49
Graphic element parameters, page 44).

Once you have edited the elements in the 3D representation, click Back to go back to the Categories window for editing 3D representations.
Click Add to add this representation to all the categorys representations.
Click Back to display the "Categories window" (see fig. 23, page 42).
Click Add to validate the new representation.
Click Quit to close the "Categories window" (see fig. 23, page 42).
VEHICLE CATEGORIES
Command
area
OVEMENT
M
CAPACITIES
Movement capacities
A vehicles movement capacities are defined by its acceleration, emergency deceleration and desired deceleration properties. These three types of acceleration are expressed as a function of the vehicles instantiated
speed. For each, you define the maximum and minimum acceleration properties. In fact, the property is
defined by the function f (v) = a, where v is the speed in m/s-1, and a is the acceleration in m/s-2. As the speed
reaches the maximum value, the acceleration approaches zero. For each vehicle generated, the simulator randomly selects an acceleration profile included between the minimum and maximum values.
For each vehicle category, you must define the minimum and maximum acceleration values, the desired
deceleration value and the emergency deceleration value.
ACCELERATION PROPERTIES
LABEL
Speed
Min. acceleration
Mean acceleration
Max acceleration
DESCRIPTION
Reference speed at the basis of which the corresponding acceleration is
applied. Expressed in m/s
Minimum acceleration in m/s2 for the reference speed.
Mean acceleration in m/s2 for the reference speed
Maximum acceleration in m/s2 for the reference speed
Proceed as follows to modify a categorys desired/emergency acceleration/deceleration:

2. In the list area, select the category whose 2D graphic representation you want to modify.
3. To display the "Categories window for editing acceleration properties" (see fig. 26, page 51),
click the Next button adjacent to:
1.
Acceleration to modify the acceleration property.
b. Emergency deceleration to modify the emergency deceleration property.

c. Desired deceleration to modify the desired deceleration property.
4.
To delete a point on the curve :

Click the green line representing the point displayed in the edit area; it becomes the current point, and
its values are displayed in the edit area.
b. Click Delete. The point is deleted, the next point becomes the current point.
a
5.
To edit a point on the curve :

Click the green line representing the point displayed in the edit area; it becomes the current point, and
its values are displayed in the edit area.
b. Edit the parameters displayed in the edit area.
c. Click Apply to validate the points new values.
a
6.
To add a point to the property:

a
Edit the parameters displayed in the edit area.
b. Click Add.
After editing the acceleration property, click Back to go back to the "Categories window" (see
fig. 23, page 42).
8. Click Apply to validate the new movement property for this category.
9. Click Quit to close the "Categories window" (see fig. 23, page 42).
7.
50
MOVEMENT
CAPACITIES
By noting a point on the acceleration properties curve via 4 values (V, Am, A, AM), where V is the speed,
Am is the minimum acceleration, A is the mean acceleration, and AM is the maximum acceleration for
V :
the last 3 points that define the categorys acceleration property must be defined such that: (vm, 0, a0,
a0M), (v, 0, 0, a1M), (vM, 0, 0, 0). Consequently, the vehicles in this category have a speed included
between vm and vM.
Max acceleration curve

Mean acceleration curve
Min acceleration curve
Interval of max speeds
Current speed
edit area
Command area
Figure 26. Categories window for editing acceleration properties
51
VEHICLE CATEGORIES
Current speed point
C A T E G O R I E S
DATABASE
Categories database
CubeDynasim allows to save categories in a database so that they can be imported and used in other projects.
The categories database is named categ.db, and it is saved in the directory named edyna. The database is
only accessible for a certain Windows user account. In order to share categories, users should copy the database in their CubeDynasim study folder.
Saving a category
1.
Click icon
Module bar, page 18, to display Categories window, page 42.
Click in the visualization zone on the category label you want to save.
Click on Export of the command area. If the button is grayed out, the selected category is already
exported to the database.
4. Click on Quit of the command area to close the Categories window, page 42.
2.
3.
Import a category
1.
Click icon
2.
Click on Import of the command area to open Importation of type of vehicles window, page 52.
Click on the List of category area on the label to be imported.
Click on Import type vehicles of the command area. If the button is grayed out, the selected category is already defined in the model.
Repeat those steps if you want to import other categories.
Click on Back close the Importation of type of vehicles window, page 52, and toggle back to
the Categories window, page 42.
Click on Quit of the command area to close the Categories window, page 42.
3.
4.
5.
6.
7.
Module bar, page 18, to display Categories window, page 42.
List of type
of vehicles
2D representation
for the current element
Command area
Figure 27. Importation of type of vehicles window
52
Background map
Background maps establish a link between graphic files and CubeDynasim. The software supports two types
of graphics :
Vector maps with the DXF format, i.e. the graphic data exchange format used by AutoCADTM,
among others.
2. Bitmaps in formats BMP, JPEG and GIF.
1.
Background map files are copied to the projects maps directory (see "Tree structure of CubeDynasim projects", fig.22 p.39).
This chapter describes the following :
Maps Management window, page 54.

Background map in DXF format, page 55,
Background map in bitmap format, page 57.
53
BACKGROUND MAP
A background map contains all the data needed to display the geometry of the development to be tested by
the simulation. The background map is used as a support, both for the editing of the model and for the animation of the simulation results (see Animator, page 451).
APS MANAGEMENT
M
WINDOW
Maps Management window

Click the Maps
button on Module bar, page 18 to access the "Background map entry window" (see
fig. 28, page 54). This window is a Module entry window, page 27. The list area lists the characteristics
(name, format and comment) of all the background maps defined for the project.
BACKGROUND MAP PARAMETERS

LABEL
Name
Format
Comment
DESCRIPTION
The background maps unique identifier, used when editing Network scenarios,
page 65.
Defines one of two possible formats associated with the background map :
BMP:
the background map is defined by a set of bitmap files.
DXF:
the background map is defined from a file in DXF format
Free text for recording additional information about the background map (optional).
To add a background map in DXF format, see Background map in DXF format, page 55. To add a background map in bitmap format, see Background map in bitmap format, page 57.
To modify or delete a background map in the Maps Management window, refer to the use of the Module
entry window, page 27.
List area
Edit
area
Command
area
Figure 28. Background map entry window
54
BACKGROUND
MAP IN
DXF
FORMAT
Background map in DXF format

You can edit a DXF background maps parameters in the "Maps Management window for a background map
in DXF format" (see fig. 29, page 56).
To add a background map in DXF format :
1.
2.
3.
4.
5.
6.
7.
8.
CubeDynasim is unable to read certain DXF elements, such as:

1.
2.
3.
4.
5.
Text.
Hatching lines, which can however be displayed by exploding them.
External references, which can however be displayed by adding then exploding them.
Images.
All objects included in a layer whose name contains characters with accents.
To optimize the background maps display, in the original file you must delete data that does not
directly concern the road network, such as wastewater, electricity and gas systems.
55
BACKGROUND MAP
9.
Click
in Module bar, page 18 to open the "Background map entry window" (see fig. 28,
page 54).
Fill in the Name and Comment fields.
Select the background maps file format by clicking the DXF button in the Format field.
Click Configure to open the "Maps Management window for a background map in DXF format"
Click Browse in the file selection window to select a DXF file. The Layers field listing all the
DXF files layers is updated.
The Layers field is a Multiple-choice list field, page 33 for selecting the layers to display when
editing and animating. Click Visualize to check the display of the background map with the
selected layers.
Click Back to go back to the "Background map entry window" (see fig. 28, page 54).
Click Add to confirm the background maps definition.
Click Quit to close the Maps Management window.
B A C K G R O U N D
MAP IN
DXF
FORMAT
Figure 29. Maps Management window for a background map in DXF format
56
BACKGROUND
MAP IN BITMAP FORMAT
Background map in bitmap format

Tiling
The quality of a bitmap image when displayed is determined by the number of points per meter. A higher
density offers a considerably improved display quality in the various zooms; however, the required memory
space increases proportionately. The modeling and animation require zoom scales varying from 1 pixel/
meter to 4 pixels/meter. To ensure satisfactory image quality and reasonable memory occupancy, CubeDynasim enables you to tile the background map.
For each available scale, the plan of the development is split into tiles. You define each tile by its coordinates in a direct orthonormal marker - unique to the entire project - by a scale factor (see "Tiling of the
development area to simulate", fig.30 p.57), and by a bitmap file in BMP, GIF or JPEG format.
CubeDynasim loads the optimal tile in the memory and displays it according to the zone being edited/animated, as well as the zoom scale factor. When scrolling or changing the zoom scale factor, CubeDynasim
can change the tile displayed in complete transparency. The area of the development you want to simulate is
no longer limited by the computers memory capacity.
X1, Y1
Tile
X0, Y0
Figure 30. Tiling of the development area to simulate
57
BACKGROUND MAP
Editing a background map boils down to editing its tiles.
B A C K G R O U N D
Map Management window for bitmap files

The Map Management window for bitmap files is used to edit all the tiles in a background map defined in
bitmap format. It is a Module entry window, page 27. The list area shows the tiles and their parameters.
TILE PARAMETERS
LABEL
Background map
File
Scale
DESCRIPTION
Name of the tiles corresponding background map. You cannot edit this property
directly in the "Maps Management window for a background map in bitmap format" (see fig. 31, page 59).
Bitmap file corresponding to the tile.
Bitmap image resolution in pixels per meter. Three possible values : 1, 2 or 4.
X0, Y0
Coordinates - in meters - of the tiles top left corner. The coordinates must be expressed
in the same marker for all the projects background maps.
X1, Y1
Coordinates of the tiles top right corner. The application calculates the values depending on the scale and on the tiles X0, Y0 coordinates.
To add a tile to a bitmap background map, proceed as follows:

1.
2.
3.
4.
5.
Click the Maps

button on Module bar, page 18 to open the "Background map entry window" (see fig. 28, page 54).
Fill in the Name and Comment fields.
Select the background maps file format by clicking the BMP button in the Format field.
Click Configure to open the "Maps Management window for a background map in bitmap format" (see fig. 31, page 59).
Add the tiles to the background map as follows:
a
Click Browse in the edit area to display the file selection window, for defining the tiles bitmap file.
b. Complete the tiles other values.

c. Click Add to add the tile to all the background maps tiles.
d. Repeat to add new tiles, otherwise continue.
Click Back to go back to the "Background map entry window" (see fig. 28, page 54).
7. Click Add to confirm the background maps definition.
8. Click Quit to close the Maps Management window.
6.
To modify or delete a tile in the "Maps Management window for a background map in bitmap format" (see
fig. 31, page 59) refer to the use of the Module entry window, page 27.
58
BACKGROUND
List area
Edit area
Commands
area
Figure 31. Maps Management window for a background map in bitmap format
BACKGROUND MAP
59
B A C K G R O U N D
60
Layers and network scenarios
This chapter describes how to associate network portions to recreate the different variants to study. With
CubeDynasim, you characterize - once only - a network portion common to a number of variants, which
themselves group together disjointed network portions.
In CubeDynasim, the developments geometry is built using simulation objects grouped into layers corresponding to the network portions. The network scenarios define sets of layers. In CubeDynasim, they are
the consequence of a geometric alternative.
This chapter presents the following topics :
Using layers and network scenarios, page 62,

Managing layers, page 64,
Network scenarios, page 65.
61
LAYERS AND
NETWORK SCENARIOS
The simulation of an urban development must enable you to measure and disclose the effects of implementing one of the proposed alternatives to interested parties and decision makers. Moreover, the project must
facilitate the adjustment of alternatives when considering the initial simulation results. The projects final
design thus follows an iterative process. The concept of these variants and iterative processes must be integral to the simulation software application. CubeDynasim meets these needs by organizing its data into projects, grouping simulation scenarios resulting from the association of four types of information corresponding
to traffic volumes (see Flow module, page 109), regulation (see Signals module, page 289), the public transport network (see Public transport module, page 271), and the Road network, page 79.
SING
U
LAYERS AND NETWORK SCENARIOS
Using layers and network scenarios

Two models in the same project can share portions of the network. For example, consider a development that
includes several crossroads with traffic signals: you might want a variant in which one of these crossroads
becomes a traffic circle. Associating layers facilitates the modeling of the development and its variants,
while eliminating redundancy.
A network is made up of simulation objects. These objects represent the Road network, page 79, Signals, page 290, Pedestrian crossings, page 95, Transit stops, page 272, Tolls, page 274, Invalid
paths, page 168, priority rules (see Managing conflicting trajectories, page 197), and Detectors,
page 295. The simulation objects, with the exception of Links, page 158 and certain simulation objects
pertaining to Managing conflicting trajectories, page 197, belong to a single layer. Each layer has a
unique name.
Functionally speaking, the layer contains simulation objects that are:
common to at least two same-network scenarios (e.g., layer 2 in figure 32, page 63),
specific to only one network scenario (e.g., layer 6 in figure 32, page 63).
You can only assign simulation objects to layers belonging to the current network scenario.
Simplify matters by creating the necessary layers first, then positioning the elements directly in the
layers rather than subsequently changing the layer.
A network scenario is defined by:
an identifier, unique to the projects set of network scenarios,

a Background map, page 53,
a set of layers.
Via its layers, the network scenario groups together simulation objects that form a geometric network to simulate. You, thus, define any geometric alternatives to the development as network scenarios.
In figure 32, page 63 you can see the implementation of layers and network scenarios to model the different
possible geometries of a T-junction. In this example, the simulation objects representing Road network,
page 79 are placed in six layers. By associating the layers, three networks are built, distinguished by the
number of lanes assigned to various directions of traffic.
62
USING
Layer 1
LAYERS AND NETWORK SCENARIOS
Layer 3
Layer 4
Layer 5
Layer 6
Layer 2
network scenario 1 = Layers 1 + 3 + 4
network scenario 2 = Layers 2 + 5
Figure 32. Layers and network scenarios
63
LAYERS AND
NETWORK SCENARIOS
network scenario 3 = Layers 2 + 3 + 6
ANAGING
M
LAYERS
Managing layers
Click the Layers
button on the Module bar, page 18 to display the "Layer Management window." (see
fig. 33, page 64). This window is a Module entry window, page 27. You cannot delete a layer that does
not yet contain any simulation objects.
LAYER PARAMETERS
LABEL
Name
Frozen
DESCRIPTION
Unique name that identifies the layer; must be unique in the project
Indicates whether you can edit the objects in a layer
Unlocked: you can edit objects in the layer.
Locked: you cannot edit, move or delete objects in the layer.
List area
Edit area
Command
area
Figure 33. Layer Management window.
64
NETWORK
SCENARIOS
Network scenarios
Use the "Network Scenario window." (see fig. 34, page 66) to edit your network scenarios.
Click the Network
button on the Module bar, page 18 to open the Network Scenario window.
This window is a Module entry window, page 27.

The Network Scenario window can also be used to assign the current network scenario whose simulation
objects are displayed in the Network edit area, page 19, and the Background map, page 53, if in the
displayed state (see the Display field). You assign the current scenario by :
adding a new network scenario, which becomes the current network scenario,
deleting a network scenario; the following network scenario, if it exists, becomes the current network
scenario,
selecting a network scenario in the display area; it becomes the current network scenario,
loading a new project (see load a project, page 37): no current network scenario is assigned, all the
simulation objects are represented in the Network edit area, page 19, but there is no Background
map, page 53 displayed.
NETWORK SCENARIO PARAMETERS

LABEL
Name
Layers
DESCRIPTION
Unique name that identifies the network scenario, used by the "Simulation module entry
window in Edit scenario mode" (see fig. 209, page 406).

Layers included in the network scenario.
Multiple-choice list field, page 33
Map Background map, page 53 associated with the network scenario.

Single-choice list field, page 32
Display
Indicates whether the background map associated with the network scenario is displayed when
this scenario becomes the current scenario.
Display background map
Do not display background map
You may choose not to display the map if the background map is a large file.
65
You cannot delete a network scenario until all the simulation scenarios that depend on it have been
removed.
You cannot deselect a layer if it used by a signals scenario, and if there is a simulation scenario that
links the network and signals scenarios.
In the Object entry windows, page 28, if the selected objects belong to a layer that can be dited,
only layers in the current network scenario that can be edited are shown, otherwise all the layers in
this network scenario are shown.
LAYERS AND
NETWORK SCENARIOS
Click the Visualize button to display the background map associated with the current network
scenario.
The background map is also displayed when you quit the Network Scenario window.
ETWORK
N
SCENARIOS
List area
Edit area
Command
area
Figure 34. Network Scenario window.
66
Network origins & destinations
Network exits are the destinations that the vehicles want to reach. These destinations correspond to columns
in origin/destination matrices (see Flow module, page 109). Once a vehicle has reached its destination, it is
removed and no longer impacts the network.
Zones are a set of exits located inside an open space (such as a cone), or a closed space (defined by four
lines).
These four elements are common to all the scenarios in a project. Therefore, they are not associated with a
layer (see Layers and network scenarios, page 61).
Origins, stages and destinations need only to be defined when using a Generator scenario,
page 114, a Subnetwork scenario, page 120 or when defining a PT lines, page 278 for a public
transport scenario.
Their use is only necessary when traffic is being quantified by a flow scenario such as the Generator scenario, page 114 or Subnetwork scenario, page 120.
67
&
Stages are dimensionless storage spaces. No movement is defined for a stage. A vehicle that cannot exit a
stage, blocked by a vehicle in front, cancels its speed instantly. In this case, it will enter the network at zero
speed. Moreover, a vehicle does not accelerate in a stage. Stages are used to store and quantify (see Data collectors, page 233) queues that overflow outside the network. Stages are usually connected between the
origin and the highway object on which vehicles will first appear in the network.
NETWORK ORIGINS
DESTINATIONS
Network entries, called origins, define the points where vehicles enter the simulation. The flow capacity of
an origin is defined by two parameters: the speed of vehicles output from the origin, and the quality of the
roadway. This capacity can also be affected by the presence or absence of a stage at the origin. The demand,
i.e. the amount of flow generated by an entry, is defined when editing origin-destination matrices (see Flow
module, page 109) for each vehicle category (see Managing categories, page 42).

This chapter looks at the following topics :
68
Origins, page 69,

Stages, page 71,
Destinations, page 74,
Zones, page 75.
ORIGINS
Origins
Representation of an origin
In logical mode, an origin is represented by the
any graphic representation in geometric mode.
icon in Network edit area, page 19. It does not have
ORIGIN PARAMETERS
LABEL
Name
DESCRIPTION
Unique name of the origin. You use this name in the associated row of the origin-destination
matrix (see Flow module, page 109).
You are advised to adopt a naming convention as defined for the Name field, page 29.
Percent speed The speed at which a vehicle arrives in the network as a percentage of the maximum speed
of vehicles gen- specific to each vehicle. For a value of 50 % (i.e. 0.5), the vehicle arrives in the network at a
speed corresponding to 50 % of its maximum speed (see "Categories window for editing
erated acceleration properties", fig.26 p.51)
1.
2.
3.
Two-way road (lowest flow capacity),

Slow lane,
Fast lane (highest flow capacity).
This is a Single-choice list field, page 32.
&
Creating an origin
1.
If necessary, switch to logical mode (see "Main CubeDynasim window in logical mode", fig.2
p.14).
2.
Click the Origin
icon in Simulation object bar, page 17 to activate create origin mode.
In the Network edit area, page 19, click the location where you want to insert the origin. This
will display the "Origin entry window" (see fig. 35, page 70).
4. Fill in the Origin entry windows fields.
5. Click OK. The new origin icon is displayed in logical mode.
3.
Editing an origin
The origin is a simulation object that can only be modified or deleted in logical mode (see Edit Object mode,
page 20). Deleting entries can reduce the number of columns in the origin/destination matrices of all the flow
scenarios (see Flow module, page 109).
If the entry in the network is located on a multilane, you must create one origin for each lane.
69
Used to assign headways between vehicles, limiting the origins flow capacity.
There are three choices :
NETWORK ORIGINS
DESTINATIONS
Lane quality
RIGINS
O
Figure 35. Origin entry window
For a high flow-rate origin (greater than 1600 vehicles/hour/lane):

1.
2.
3.
4.
70
do not place any stages,

set a high generation speed (>70%),
set the Lane quality to Fast Lane,
check the flows by positioning Data collectors, page 233 at the entry to the network.
STAGES
Stages
A stage is a dimensionless storage zone positioned between the origin and the first object that defines a trajectory at the entry to the network (see Road network, page 79). If a queue goes back beyond the network,
the vehicles generated wait in the stage. Use Data collectors, page 233 to quantify the queue that overflows beyond the simulated area.
Representation of a stage
Stages are displayed in the network edit area in both logical and geometric mode. In geometric mode, you
can place Data collectors, page 233. on stage objects.
Geometric mode
Logical mode
Figure 36. Representations of the stage in the network edit area
LABEL
Name
Unique name of the stage.

You are advised to adopt a naming convention for stages as defined for the Name field,
page 29.
Storage capacity of the stage, in square meters. Each vehicle occupies a certain surface area
depending on the length and width of its category (see Editing 2D representations,
page 44). When the stage is full, the simulation no longer considers new vehicles generated.
Creating a stage
1.
p.14).
2.
Click the Stage
icon in the Simulation object bar, page 17 to activate create stage mode.
In the Network edit area, page 19, click the location where you want to insert the stage. This
will display the "Stage entry window" (see fig. 37, page 72).
4. Fill in the fields.
5. Click OK. The icon representing the new stage is displayed in logical mode.
3.
Editing a stage
The stage is a simulation object which, once created in logical mode, can be modified or deleted in either
logical or geometric mode, see Edit Object mode, page 20.
When you limit a stages storage capacity, you reduce the simulation time considerably. However, in
the case of a pronounced peak during the simulated time, you risk not being able to take account of
the demand required for the entire simulated time period. Similarly, the Data collectors, page 233
give a number of vehicles present in the queue that is limited by the stages storage capacity.
71
&
Surface
DESCRIPTION
NETWORK ORIGINS
DESTINATIONS
STAGE PARAMETERS
S T A G E S
Figure 37. Stage entry window
72
EXAMPLE
OF MODELING A NETWORK ORIGIN
Example of modeling a network origin

This section shows an example of the modeling of a network origin, both in logical and geometric mode, for
the use case of a Flow scenarios, page 110, of the type Generator scenario, page 114.
For a 3-lane network entry in an urban environment (see "Modeling a network entry", fig.38 p.73), you must
create three origins linked to three stages using Links, page 158. Each stage is connected via a link to one
of the lanes in the Trajectories, page 81 at the entry to the network. The multilane entry is extended so
that you have more than 150 meters between the network entry and the first conflict zones. Extending the
first multilane offers two advantages: the possibility of viewing the queues in the animation, and better simulating - from the motional viewpoint - episodic queues at the entry to the network.
It is important that you place Data collectors, page 233 to evaluate the possible queues that extend up to
the stage, or to make sure that the rates measured on entry to the network are compatible with the quantification of the demand expressed in the Flow scenarios, page 110.
Extended
multilane
Stages
&
Representation in geometric mode

Generators
Stages
Exit
Multilane path in
logical mode
Links
Representation in logical mode
Figure 38. Modeling a network entry
73
NETWORK ORIGINS
DESTINATIONS
Data
collectors
ESTINATIONS
D
Destinations
Representation of a destination
icon in the Network
The destination (or exit) simulation object is represented in logical mode by the
edit area, page 19. The destination has no graphic representation in geometric mode.
Creating a destination
1.
Switch to logical mode (see "Main CubeDynasim window in logical mode", fig.2 p.14).
Click the Destination

icon on the Simulation object bar, page 17 to activate create destination mode.
3. In the Network edit area, page 19, click the location where you want to insert the destination.
This will display the "Exit entry window" (see fig. 39, page 74).
4. Complete the Name field, page 29 used as the column header in the origin-destination matrix edited using the Flow module, page 109, and as the label for the Prohibitor field, page 171.
5. Click Validate : if the name is unique, the icon representing the new destination is displayed in
logical mode.
2.
Editing a destination
A destination (or exit) is a simulation object that must be modified or deleted in logical mode, see Edit
Object mode, page 20. Deleting destinations affects the number of columns in the origin/destination matrices
of all the flow scenarios (see Network origins & destinations, page 67), the appearance of the Prohibitor
field, page 171, the definition of conditions for certain priority rules (see Managing conflicting trajectories, page 197), and the number of lines in the Public transport module, page 271.
Figure 39. Exit entry window
74
ZONES
Zones
A zone object groups one or more destinations within the same geometric space. There are two types of
zones: open zones which are defined by a two-point line segment, and closed zones which are defined by a
three-point line segment. For closed zones, the fourth segment is defined by the first point of the first segment, and the last point of the last segment (see "Open and closed zones", fig.40 p.75). Zones are identified
by a name that will be used when editingInvalid paths, page 168, and the Prohibitor field, page 171.
Exit not in the zone
Exits in the zone
NETWORK ORIGINS
DESTINATIONS
Closed zone defined by three segments
Figure 40. Open and closed zones
ZONE PARAMETERS
LABEL
DESCRIPTION
Name
Unique name of the zone, used by other objects in the simulation model.
You are advised to adopt a naming convention for the zones (see Name field, page 29).
Width
Viewable width of the segments in Network edit area, page 19,
Color
Color of the segments in non-pointed mode, displayed in the Network edit area,
page 19.
Representation of a zone
A zone is represented in both logical and geometric modes. This representation differs depending on whether
or not the mouse is pointing to one of its segments (see "Representation of zones", fig.41 p.76).
For each intersection, you are advised to create as many zones as there are roads leaving the
intersection, and to use the zones when entering conditions (one-way streets, priorities stops, data
collectors, etc.) That way, you can easily expand or change the structure of the model.
75
&
Open zone defined by two segments
Z O N E S
Zone
Zone in pointed mode
Figure 41. Representation of zones
Figure 42. Zone entry window
76
ZONES
Creating a zone
1.
Switch to logical mode (see "Main CubeDynasim window in logical mode", fig.2 p.14).
2.
Click the Zone
3.
In the Network edit area, page 19, click the location of the start of the first segment in the zone
to display the "Zone entry window" (see fig. 42, page 76).
Fill in the fields (see Zone parameters, page 75).
Click OK.
Click in the Network edit area, page 19, to define the start of the second segment.
To create :
4.
5.
6.
7.
button on the Simulation object bar, page 17 to activate create zone mode.
an open zone : right-click the end of the second segment.
b. a closed zone: left-click to mark the start of the third segment, then right-click to position the end of
this third segment.
NETWORK ORIGINS
DESTINATIONS
&
77
Z O N E S
78
Road network
Modeling a roundabout.
Modeling a signal junction.
This chapter is divided into six parts :
79
Vehicle network, page 80,

Speed distributions, page 92,
Pedestrian crossings, page 95,
Underpasses, page 100,
3D tile, page 102,
Modeling the road network, page 104.
ROAD NETWORK
The road networks characterization consists in defining - on a background map - the trajectories taken by the
various users of the simulated system, i.e. the vehicles and pedestrians. These trajectories are defined by their
geometry, and by the users behavior. This chapter describes how to edit the geometry of the networks. The
path of the network and the behavior of the users will be discussed in the subsequent chapter on Paths,
page 157. The parameters of the network objects also affect the movement of the vehicles.
EHICLE
V
NETWORK
Vehicle network
You edit the vehicle network in the Network edit area, page 19 in geometric mode. This involves describing the geometry of the trajectories taken by the vehicles, and their concatenation. The network is described
by two graphic elements: handles and trajectories.
This section describes the different operations concerning handles and trajectories:
Handles, page 80,

Trajectories, page 81,
Creating the vehicle network, page 83,
Editing the handles, page 84,
Editing trajectories, page 86.
Handles
A handle is defined by its position, its orientation and its number of attachment points. Handles are exclusively represented and edited in geometric mode in the network edit area. The handle has as many arrows
representing its orientation as it has attachment points (see "Representation of handles in geometric mode",
fig.43 p.80).
HANDLE PARAMETERS
LABEL
DESCRIPTION
Name
Unique name identifying the handle.
Links
Boolean field that determines whether or not vehicles can concatenate the trajectories associated with the handle. Its value is usually set to Yes. You set it to No when you want to
manually edit the concatenation of the trajectories taken by the vehicles (see Split link,
page 160).
Number of
lanes
Lane spacing
Color
Integer greater than 1 defining the handles number of attachment points. It usually corresponds to the number of lanes of vehicles at this point in the network.
Distance in meters between the handles attachment points. Represents the width of the
lanes on the road network at this point in the network.
Color in which the handles attachment points are displayed (see Color field, page 31).
handle with 3 attachment points

handle with 2 attachment points
handle with 1 attachment point
Figure 43. Representation of handles in geometric mode
80
VE H I C L E
NETWORK
Trajectories
A trajectory is defined between two different handles. It can link one or more attachment points on the handles. A single lane is modeled by a trajectory that links a single attachment point on each handle. A multilane
is modeled by a trajectory that links several attachment points on each handle. In certain conditions, the vehicles can change lanes depending on their behavior, or to reach their destination.
You position the handles, while the application calculates the trajectories between them. The trajectory
results in one or two arcs tangent to the orientations of the handles it links (see "Representations of handles
and trajectories in geometric mode", fig.44 p.81).
Direction of the
vehicles path
Multilane
trajectory
with one arc
Multilane
trajectory
with two arcs
Figure 44. Representations of handles and trajectories in geometric mode
Handles are not represented in logical mode. Trajectories are represented in logical mode, however they cannot be edited in this mode (see "Representations of trajectories in logical mode", fig.45 p.81).
Multilane trajectory
Ends of trajectories
Figure 45. Representations of trajectories in logical mode

The parameters of a multilane trajectory differ from those of a single-lane trajectory in terms of the conditions for changing lanes.
81
ROAD NETWORK
Single lane
trajectory
EHICLE
V
NETWORK
TRAJECTORY PARAMETERS
LABEL
Name
DESCRIPTION
Unique name of the trajectory.
You are advised to either:
1.
Leave the application to name the trajectory when it is created or renamed.
2.
Or adopt a naming convention (see
Objects named automatically and renamed
by the user, page 30).
Layers
The layer associated with the trajectory. Chosen from among the subset of layers in the
current network scenario (see Single-choice list field, page 32).
Width
Width, in meters, of the lanes in the trajectory, displayed in the Network edit area,
page 19. This parameter is not taken into account by the simulation engine.
Color
Number of lanes
Color in which the trajectories are displayed (see Color field, page 31). This parameter
is not taken into account by the simulation engine.
Number of lanes in the trajectory. The number of attachment points on the handles on
either side of the trajectory is necessarily greater than or equal to the number of lanes in
this trajectory.
Parameters specific to each lane

Car-following Car-following rules, page 184 applied to vehicles when traveling along the trajecrules tory (see Single-choice list field, page 32).
Speed at entry
Free speed at the start of the trajectory, expressed as a percentage of the vehicles maximum speed.
The free speed is defined as the vehicles speed when it is not restricted by other vehicles
or by priority rules such as stops and stop lines.
Lane speed
Free speed when traveling along the trajectory, expressed as a percentage of the vehicles
maximum speed.
The vehicle attempts to reach this speed by applying its acceleration or its desired deceleration depending on whether its speed at the start of the trajectory is greater or less than
this speed.
Speed at exit
Free speed at the end of the trajectory, expressed as a percentage of the vehicles maximum speed.
In fact, the free speed at the trajectory exit is the minimum out of the following: the lane
speed, the speed at exit and the speed at entry of the following trajectory. If necessary, the
vehicle applies - in order of preference - its desired deceleration, then its emergency
deceleration.
If there are at least two lanes

Simulated width
Width in meters of a lane in the simulated trajectory. This width is the same for all the
lanes in the trajectory. Two vehicles, the half-sum of whose widths is greater than the simulated width, cannot travel side by side on two adjacent lanes in the trajectory.
Parameters specific to each lane if there are at least two lanes

Lane behavior Behavior associated with lane satisfaction, page 176 adopted by the vehicles
when traveling along the trajectory lane.
(see Single-choice list field, page 32)
Lag gap
82
Distribution of minimum gaps to the vehicle behind on the target lane when changing
lanes (see "Lag and lead insertion gaps", fig.108 p.175).
VE H I C L E
NETWORK
TRAJECTORY PARAMETERS
LABEL
DESCRIPTION
Lead gap
Distribution of minimum gaps to the vehicle in front on the target lane when changing
lanes (see "Lag and lead insertion gaps", fig.108 p.175).
Change distance
Distribution of distances needed to successfully change lanes (see Lane change distance, page 182).
Creating the vehicle network

You can create a series of handles on the fly, whereby the application ensures the geometry of the trajectories
and the naming of the new handles. The trajectory parameters are defined by default. This technique for
editing the road network is recommended when editing axes.
Proceed as follows to create a series of handles on the fly:
1.
If necessary, switch to geometric mode (see "Main CubeDynasim window in geometric mode",
fig.1 p.14).
2.
Click the button
on the Simulation object bar, page 17 to activate create handle mode.

.
Click the position of the first handles right-hand attachment point. This position corresponds to
the roadways right-hand lane that is to be modeled.
4. Use the "First handle entry window" (see fig. 46, page 84) to enter the parameters of the handles
and trajectories, in particular determining the automatic naming of the objects created (see Objects
named automatically and renamed by the user, page 30). This window differs from the window
for entering and editing handles since it is also used both to edit the Handle parameters,
page 80 and to define theTrajectory parameters, page 82. The names of these two additional
fields are :
a Layers : a Single-choice list field, page 32 used to assign the layer of the trajectories from the
3.
subset of the current network scenarios layers.

b. Width : width in meters of the trajectories displayed in the network edit area (0.5 usually represents
the best compromise).
5.
Click Validate in the "First handle entry window" (see fig. 46, page 84). The pointer changes to
in the network edit area while the series of handles is being created.
6.
Drag your mouse to adjust the angle of the handle; it must be tangent to the vehicle trajectory. This
is easier if you move the pointer away from the handle slightly. Left-click to validate the editing of
the handle.
When editing the handles, you can use the Continuous Zoom function via the mouse wheel. Similarly,
you can use the Pan function by pressing and holding the middle mouse button.
Refer to the message area to see which commands are available at each stage in the editing process.
7.
If you want to finish adding new handles :

right-click in the network edit area to switch from create a series of handles mode to create handles mode. The pointer changes to
again.
Else to add a new handle:

a
In the network edit area, click the position of the handles right-hand attachment point.
b. Repeat point 6.
83
ROAD NETWORK
The pointer in the network edit area changes to
EHICLE
V
NETWORK
The values of the last parameters edited when modifying/creating/selecting objects are assigned by
default to the corresponding parameters of a new object. When editing a simulation models
trajectories, it is usually easier to proceed route by route.
Fields specific to
the trajectories
Figure 46. First handle entry window
Editing the handles

Handles are simulation objects that can be edited in Edit Object mode, page 20 depending on the
functions :
delete or modify a simulation object, or place it in the background or foreground, page 21. The handles associated trajectories are also deleted.
move a simulation object on the background map, page 21.

This section describes the operations specific to editing the handles:
Modifying the angle of a handle, page 84,

Adding an attachment point to a handle, page 85,
Removing an attachment point from a handle, page 85.
Modifying the angle of a handle
1.
If necessary, click the
2.
Click
button on the tool bar to switch to geometric mode.
on the Toolbar, page 15 to switch to edit object mode.
Click the handle to modify to display its two selection squares.

4. Position the mouses pointer on the left selection square in the direction of the handle.
5. Click and drag the mouse to obtain the appropriate angle, then release.
6. Unselect the single lane by following the procedure used to deselect an object or multiselection, page 21.
3.
84
VE H I C L E
NETWORK
Old position
New position
Handle selected
New trajectory
Old trajectory
Figure 47. Modifying the angle of a handle
Adding an attachment point to a handle
You can add an attachment point to the left or right of the handle (in the direction of the handle).
2.
Click
Position the mouses pointer on the handle to modify.

4. Right-click and hold; in the menu displayed, drag the mouse to the Add left or Add right item to
add an attachment point to the left or right, respectively.
5. Release the right mouse button.
3.
To quickly add several attachment points to the left of a handle, increase the value of the Number of
lanes field in the Handle entry window, page 86. To change a fields value, see Removing an
attachment point from a handle, page 85.
Removing an attachment point from a handle
You can only delete a handles attachment points from the left (in the direction of the handle).
1.
2.
Click
Position the mouses pointer on the handle to modify.

Right-click and hold; in the menu displayed, drag the mouse to the Modify command to display
the Handle entry window, page 86.
5. Modify the value of the Number of lanes field to adjust it to the appropriate number of attachments.
6. Click OK in the Handle entry window, page 86.
3.
4.
85
ROAD NETWORK
1.
EHICLE
V
NETWORK
Figure 48. Handle entry window
Original handles attachment point
New trajectory
Target handles attachment point

Figure 49. Creating a trajectory between two handles
Editing trajectories
This section describes the operations specific to editing trajectory objects:
Adding a trajectory between two handles, page 87.

Editing the number of lanes in a trajectory, page 88.
Adding a handle or copying a trajectory, page 89.
86
VE H I C L E
NETWORK
Adding a trajectory between two handles

You will sometimes have to link two handles manually, for example, to model the turning movements at a
junction (here, creating on the fly is insufficient). This consists in defining a trajectory between an attachment point on the original handle to an attachment point on the target handle.
1.
2.
Click the
button on the simulation tool bar to activate create trajectory mode. This button is
in the same category of objects as the

button; if necessary, change the simulation object type
associated with the icon (see Simulation object bar, page 17).
3. Click the attachment point on the original handle.
4. Click the attachment point on the destination handle. A single-lane trajectory links the two points.
To establish a multilane between two handles, you must first add a trajectory between two attachment points
(give preference to attachment points as far to the right on the new trajectory as possible). You then increase
this trajectorys number of lanes using the Extend command, or by editing the trajectory entry window (see
Editing the number of lanes in a trajectory, page 88).
Adding a trajectory between two trajectories
CubeDynasim can be used to draw trajectories that link two trajectories without any attachment point. This
can also be done from a trajectory to a handle, or from a handle to a trajectory.
Point of origin of the blue trajectory, modifiable all along

the red trajectory
Figure 50. Trajectories without handles
1.
2.
Click the
button on the simulation objects bar to activate create trajectory mode. The button
is in the same category of objects as the

button; if necessary, change the simulation object type
associated with the button (see La barre des objets de simulation, page 21).
3. Click on the origin trajectory at the point where the trajectories separate.
4. Click on the destination trajectory at the point where the trajectories separate.
Modifying a linked trajectory without handles
You can adjust a trajectory drawn between two trajectories.
1.
2.
Click
3.
Click on the trajectory to edit to display its selection squares.
Click and drag the first (or last) square to move it, as appropriate.
87
ROAD NETWORK
Trajectory between a trajectory and a handle
EHICLE
V
NETWORK
Editing the number of lanes in a trajectory

You always increase or reduce the number of connections associated with a trajectory from the left, in the
direction of the handles. In other words, if you increase the number of lanes by one, the new lane will be the
one farthest to the left on the trajectory. Similarly, if you remove a lane from a trajectory, you remove the one
farthest to the left. The number of lanes in a trajectory is necessarily between 1 and the number of attachment
points available on the left of the trajectory for each associated handle.
To directly edit the number of lanes in a trajectory :
1.
2.
Click
Position the mouses pointer on the trajectory to modify.

Right-click and hold; in the menu displayed, drag the mouse to the Modify command to display
the Handle entry window, page 86.
5. Release the button to open the Multilane trajectory entry window, page 89
6. Change the value in the Number of lanes field as appropriate.
7. Click OK in the Handle entry window, page 86.
3.
4.
Use the Extend command to complete the maximum number of lanes in a trajectory in accordance with the
minimum number of attachment points available on its left on the original and destination handles. This is
the recommended way to increase the number of lanes in a trajectory:
1.
2.
Click
Position the pointer on the trajectory to modify. Right-click and hold; in the menu displayed, drag
the mouse to the Extend command to display the Handle entry window, page 86.
4. Release the button to activate the command. All the available attachment points are connected.
3.
88
VE H I C L E
NETWORK
Right lane
parameters
Left lane
parameters
ROAD NETWORK
Figure 51. Multilane trajectory entry window

Adding a handle or copying a trajectory
Sometimes you have to add a handle, for example, to adjust the road networks geometry.
1.
2.
Click
Position the pointer on the single lane at the appropriate spot, then right-click and drag to select
Add a handle.
4. A new handle is created with the minimum number of attachment points needed to maintain lane
continuity. The handles name is <original handle name including index>_1.
3.
Adding a new handle implies destroying the existing handle and creating two new trajectories. If
Links, page 158 were attached to the trajectory, these will be permanently lost.
89
EHICLE
V
NETWORK
Modifying a trajectorys attachment points

You can modify the attachment points on both the original handle and those on the destination handle. In
fact, this involves shifting the attachment points on the original and/or destination handles to the right or to
the left.
Left origin
shift
Left destination
shift
Right destination
shift
Right origin
shift
Figure 52. Different combinations of attachment point shifts

Proceed as follows to modify the attachment points:
1.
2.
Click
3.
Position the pointer on the trajectory to modify.

Right-click and hold; in the menu displayed, drag the mouse to the appropriate command:
4.
L Orig Shift : left origin shift
b. R Orig Shift : right origin shift

c. L Dest Shift: left destination shift
d. R Dest Shift: right destination shift
90
VE H I C L E
NETWORK
Copying/Pasting trajectory properties

To make it easier to edit models and, in particular, the road network, you can define one trajectorys parameters, then directly copy its values to a selection of trajectories :
1.
2.
Click
If necessary, edit the parameters of the "pilot" trajectory in the Multilane trajectory entry window, page 89.
4. Select Copy to copy its properties:
3.
Place the pointer on the modified trajectory.
b. Right-click and drag the mouse to select Copy in the menu displayed.
Select a set of trajectories (see perform a multiselection, page 21, perform a multiselection in
a rectangle, page 21, perform a multiselection by path This consists in selecting a sequence of
paths that a vehicle can take during the simulation., page 21).
6. Position the pointer on one of the selected trajectories. Right-click and select Paste in the menu
displayed. The parameters of the selected trajectories with the same number of lanes as the pilot
trajectory are modified; those with a different number of lanes are not modified.
5.
ROAD NETWORK
91
S P E E D
DISTRIBUTIONS
Speed distributions
CubeDynasim can be used to define the speed distributions to use in the speed fields of trajectory objects,
thus providing greater flexibility when editing this parameter.
The speed distribution serves to group different speed configurations by vehicle category under a single
identifier.
The "Speed distribution entry window" (see fig. 53, page 92) contains:
the list of distributions

the distributions identifier (i.e. its name)
a series of parameters
SPEED DISTRIBUTION PARAMETERS

LABEL
Name
Type
Speed %
DESCRIPTION
Unique identifier of the distribution
Percentage:
associates a maximum speed percentage (% speed) with the distribution for each category
Maximum Speed:
associates a maximum speed (m/s) with the distribution
Category:
uses a default value (Percentage or Maximum speed, defined beforehand) for all categories except those for which the user is making an association
Value field
a command button area
List of
distributions
Edit field
Distribution
parameters
Command
area
Figure 53. Speed distribution entry window
92
Name
to create
SPEED
DISTRIBUTIONS
Creating a Percentage distribution

A percentage distribution assigns the speed limit of the vehicles applying a percentage, in interval]0;1], to
the maximum speed capacity of the vehicle.
Proceed as follows in the Speed Distributions entry window to create a Percentage distribution :
1.
2.
3.
4.
5.
6.
Open the Speed distribution entry window, page 92.

Specify the name of the distribution in the edit field.
Complete the distributions parameters by selecting its type: Percentage.
Enter a percentage value between 0 and 1. The maximum speed of a vehicle is determined by its
native maximum speed multiplied by this factor. If the coefficient is equal to 1, the distribution has
no impact on the kinematics of vehicle capacity.
Click Add to create the distribution.
Click Quit to close the window.
Creating a Maximum Speed distribution

A maximum speed distribution modifies the kinematics of all the vehicles assigning them the same speed
limit.
1.
2.
3.
4.
5.
6.

Specify the name of the distribution in the edit field.
Complete the distributions parameters by selecting its type: Maximum Speed.
Enter the value of the target speed (in m/s); this will be the same for all vehicles.
Creating a Category distribution

The Category distribution allows to define a speed limit distribution to each category of vehicles. This speed
distribution could be either an already defined Maximum or Percentage speed distribution.
93
ROAD NETWORK
Proceed as follows in the Speed Distributions entry window to create a Maximum Speed distribution:
S P E E D
DISTRIBUTIONS
Proceed as follows in the Speed Distributions entry window to create a Category distribution :
2. Specify the name of the distribution in the edit field.
3. Complete the distributions parameters by selecting its type: Category.
1.
4.
5.
6.
7.
8.
9.
10.
94
Choose the distribution associated by default with all vehicles in the drop-down list.
Click the Associations button.
Associate the category/distribution pair in the drop-down lists.

Click Add to create the association.
Repeat steps 6 and 7 as many times as necessary, then click Back to go back to the previous window.
PEDESTRIAN
CROSSINGS
Pedestrian crossings
The simulation of an urban development requires you to consider the movement of pedestrians, and, more
specifically, their interactions with other modes of transport. CubeDynasim models protected pedestrian
crossings where the pedestrian crossing the road takes priority over the motor vehicles. If a vehicles
motional capacities do not allow it to stop at a pedestrian crossing, the pedestrian gives way to the vehicle.
However, if a vehicle comes to a halt on the pedestrian crossing, the pedestrian continues on his way. In other
words, the pedestrian moving on a crossing does not avoid vehicles at a standstill on the road (see Animator,
page 451).
Pedestrian crossings can be regulated by signals (see "Pedestrian crossings regulated by stop lines", fig.130
p.202), and determined by Pedestrian push-button, page 303.
This section deals with the following topics:
Representation of a pedestrian crossing in the edit area, page 95,

Creating a pedestrian crossing, page 97,
Editing and deleting a pedestrian crossing, page 99.
Pedestrian crossings are simulated objects that are edited and displayed in the Network edit area, page 19,
only in geometric mode.
The pedestrian crossing object takes account of crossings in both directions. To assign the quantification of
the crossings by direction, the main direction is identified by the direction of the arrow representing the
crossing (see "Path taken by pedestrians in the main direction for a direct crossing", fig.54 p.96).
The object comprises the following :
waiting areas represented by green rectangles. They correspond to the place where the pedestrian
can wait in complete safety before crossing the road. This zone is defined as a rectangle whose
depth is set to 3 meters, and whose width you can define. In a simulation, it corresponds to a
dimensionless storage area, like the stage positioned at the entry of the vehicle network (see
Stages, page 71). When you view the animation, the pedestrians are displayed randomly in the
space defined by the waiting area.
2. crossing areas represented by an arrow indicating the main direction, and a series of yellow lines.
Conflicts between pedestrians and vehicles are calculated automatically by the simulation engine
when the model is built; they result from the intersections between the trajectories and the crossing areas of the pedestrian crossing (see "Path taken by pedestrians in the main direction for a
crossing with a refuge", fig.55 p.96).
3. refuge areas which are used to model crossings in several stages. They must not be used for a
direct crossing. They comprise one waiting area per direction and one passage area. A physical
length is associated with the passage area, like the crossing. Here, the time required for a pedestrian to cross the refuge will not be null. The interaction between vehicles and pedestrians is not
considered in the refuge area (see "Path taken by pedestrians in the main direction for a crossing
with a refuge", fig.55 p.96)
1.
95
ROAD NETWORK
Representation of a pedestrian crossing in the edit area
P E D E S T R I A N
CROSSINGS
Wait
Waiting area, main direction
Cross
Crossing area
Waiting area, opposite direction

Figure 54. Path taken by pedestrians in the main direction for a direct crossing
Wait
Waiting area, main direction
Cross
Crossing area
Refuge
Wait
Cross
Refuge
Crossing area
Waiting area, opposite direction
Figure 55. Path taken by pedestrians in the main direction for a crossing with a refuge
96
PEDESTRIAN
Stop line on secondary

waiting area
CROSSINGS
Selection handle for

secondary waiting area
Secondary waiting area
Crossing area 2
Selection handle
for refuge area
Refuge
Crossing area 1
Stop line on main
waiting area
Main waiting area
Conflicting vehicle
trajectories
Selection handle for

main waiting area
Selected state
Creating a pedestrian crossing

Proceed as follows to create a pedestrian crossing :
1.
fig.1 p.14).
2.
Click the
button on the Simulation object bar, page 17 to activate create pedestrian crossing mode.
In the Network edit area, page 19, click the spot where you want to see the main waiting area;
this will display the "Pedestrian crossing entry window" (see fig. 57, page 98).
Fill in the Pedestrian crossing parameters, page 98.
Click OK to edit the pedestrian crossings geometry.
If you want to add a refuge:
3.
4.
5.
6.
Left-click to position the refuges secondary waiting area.
b. Left-click to position the refuges main waiting area.

c. Repeat point 6 as needed.
Otherwise finish the crossing objects entry by right-clicking to position the secondary waiting
area.
All the waiting areas on a pedestrian crossing must be placed at least 1 meter from the roads
trajectories so that the pedestrians who are waiting do not appear to be run over by the vehicles in the
animation.
97
ROAD NETWORK
Figure 56. Representation of a pedestrian crossing with a refuge in selected mode
P E D E S T R I A N
CROSSINGS
PEDESTRIAN CROSSING PARAMETERS

LABEL
DESCRIPTION
Layer
The layer associated with the crossing, selected from the current subset of layers in
the Network scenarios, page 65 (see Single-choice list field, page 32).
No. of Ped. in
Main Direction
Number of pedestrians who use the crossing in the main direction (represented by
the arrows direction) per hour, regardless of the length of the simulation.
Proportion Main
Direction
No. of Ped in
Opposite Direction
Proportion Opposite
Direction
Defines the proportion of the different types of PED (pedestrian) categories that
will comprise the flow in the main direction (see Type, page 43).
Number of pedestrians who use the crossing in the opposite direction (represented
by the arrows opposite direction) per hour, regardless of the length of the simulation.
Defines the proportion of the different types of pedestrians that will comprise the
flow in the opposite direction (see Type, page 43).
Length of Zone of
Visualization
The distance at which a pedestrian will take into account an approaching vehicle in
meters. Beyond this distance, the pedestrian crosses as if there were no vehicle.
Path Width
Width of the pedestrian crossing in meters. Determines the maximum number of

pedestrians who can walk side by side and, therefore, the capacity of the crossing.
Figure 57. Pedestrian crossing entry window
98
PEDESTRIAN
CROSSINGS
Editing and deleting a pedestrian crossing

Pedestrian crossings are simulated objects that are edited and displayed in the Network edit area, page 19,
They are manipulated in Edit Object mode, page 20 depending on the functions to perform :
delete or modify a simulation object, or place it in the background or foreground, page 21.
move a simulation object on the background map, page 21.
You can also modify the position of the waiting areas :
Select the pedestrian crossing by following the procedure to select a simulation object,
page 21.
2. Move the waiting area by clicking and holding its handle (see "Representation of a pedestrian
crossing with a refuge in selected mode", fig.56 p.97).
3. Drag the mouse, then release the button at the end of the waiting area.
1.
ROAD NETWORK
99
NDERPASS
U
OBJECT AND
3D
TILE
Underpass object and 3D tile

This section describes the objects proposed by CubeDynasim to improve the readability of the 2D animations and to integrate the simulation in a 3D space with the:
Underpasses, page 100,

3D tile, page 102.
Underpasses
In 2D animations, the underpass object graphically represents vehicles that pass under a civil engineering
structure (bridge, tunnel, interchange, etc.). In 3D animations, you have to integrate a 3DS model to obtain
the same rendering. Moreover, the underpass object does not affect the results of the simulation.
The underpass object comprises three rectangular segments that can partly overlap. The outer two segments
correspond to the ramp needed to go from a height of 0 to that of the underpass object (see Underpass object
parameters, page 102). The middle segment defines a horizontal plane at the height of the underpass object.
The trajectory, one of whose handles belongs to one of the underpass objects segments, "goes up" this object
only if the trajectorys slope (defined by the heights of its two handles) is less than 20%. Trajectories that fail
to satisfy this condition remain at zero height. If a handle belongs to several underpass objects, it is considered as belonging to the highest.
This section describes the following :
Representation of an underpass object in the edit area, page 100.

Creating an underpass object, page 101.
Representation of an underpass object in the edit area

In the network edit area, an underpass object is displayed in geometric mode only as three semi-transparent
rectangles.
100
UNDERPASS
OBJECT AND
3D
TILE
Underpass object
Zero height handle
Ramp section
Underpass height
handle
Slope > 20%

The trajectory does not
go up the underpass
Crossing section
ROAD NETWORK
Trajectories that
pass below
Ramp section
Trajectories that
pass above
Zero height
handle
Figure 58. Representation of the underpass object when selected
Creating an underpass object

1.
2.
Click the
button on the Simulation object bar, page 17 to activate create an underpass
object mode.
In the Network edit area, page 19, click the location where you want the ramp to start. This
opens the "Underpass object entry window" (see fig. 59, page 102).
Enter the objects parameters (see Underpass object parameters, page 102).
Click OK to edit the underpass objects geometry.
Click the location where you want the top part of the ramp to end (this is also the start of the crossing section).
Click the location where you want the crossing section to end (this is also the start of the second
ramp section).
Right-click at the location where you want the second ramp section to finish; this ends the creation
of the underpass object.
3.
4.
5.
6.
7.
8.
101
NDERPASS
U
OBJECT AND
3D
TILE
Figure 59. Underpass object entry window
UNDERPASS OBJECT PARAMETERS

LABEL
Layer
DESCRIPTION
The layer associated with the underpass object, selected from the current subset of layers
when Network scenarios, page 65 (see Single-choice list field, page 32).
Height
Height of the crossing section in meters.
Width
Width, in meters, below which simulated vehicles will not be visible.
Color
Color of the handles attachment points (see Color field, page 31).
3D tile
To view the movement of vehicles within a virtual model in 3DS TM format, you must position the models
various tiles on the background map of the corresponding network scenario. A tile is defined by a 3DS file
and all the image files defining the textures. The files that make up a tile will be copied to the projects backgrounds folder. You can position several 3DS files with as many tiles as necessary.
When animating the simulation results in a 3D scene, the height of a trajectory is defined by the heights of its
origin and destination handles.
If there is no point corresponding to a trajectorys handle, the handle is positioned at a height of 0 in the animation. In these conditions, you cannot start a trajectory object under a bridge.
For a visual rendering that implements a virtual model, you may need to increase the number of handles (see
Adding a handle or copying a trajectory, page 89).
102
UNDERPASS
OBJECT AND
3D
TILE
3DS TILE PARAMETERS

LABEL
Layer
File
Display
DESCRIPTION
The layer associated with the tile, chosen from the subset of layers in the current Network
scenarios, page 65.
3DS file, absolute path.
Two possible statuses:
Yes: the tile is displayed on the background map.
No: the tile is no longer displayed on the background map, which makes it easier to edit the
simulation model. In this status, the tile is represented by the
icon displayed in the network edit area. To find a 3DS tile with this status, you use the search object utility.
Height
Relative height at which the 3DS tile is positioned. Used to adjust the height of the various
tiles if they have not been defined in the same marker.
Proceed as follows to add a 3DS tile in CubeDynasim:

fig.1 p.14).
2.
Click the
icon on the Simulation object bar, page 17 to activate add 3DS tile mode.
In the network edit area, click the position corresponding to the center of the tile (this position can
easily be adjusted afterwards; an approximate position is sufficient here).
4. Assign the values of the 3DS tile parameters, page 103 displayed in the "3DS tile entry window" (see fig. 60, page 103). Click OK to confirm. The tile is displayed in the network area.
5. To adjust the tiles position, it is best to put it in the background. You can move the tile like any
other simulation object (see move a simulation object on the background map, page 21).
6. To modify the tiles orientation:
a Select the tile (see select a simulation object, page 21).
3.
b. When selected, the tile is displayed with two handles. The position handle is situated at the center of
the tile. The orientation tile is situated on one side of the tile. Click and hold the orientation handle,
then drag to the appropriate orientation.
c. Unselect the tile to adjust its position, if necessary (see
deselect an object or multiselection,
page 21).
Figure 60. 3DS tile entry window
103
ROAD NETWORK
1.
ODELING
M
THE ROAD NETWORK
Modeling the road network

This section describes the various rules to apply when editing the road network. When positioning the road
network, keep in mind that in the animation, vehicles front axles are centered on the lanes in the trajectories.
In the simulation, a vehicle sees the vehicles in front of it when they are on the same trajectory or on one of
its destination trajectories. In order for a vehicle to see vehicles on other trajectories, you have to add priority
rules (see Managing conflicting trajectories, page 197). In fact, editing the road network boils down to
avoiding superimposed trajectories.
Modeling curb lanes
The modeling of curb lanes respects the rule of the directional arrows plotted on the ground. For each configuration, see the "Curb lane examples" (see fig. 61, page 104).
Multilane
Single lane
Figure 61. Curb lane examples
Modeling weaving lanes

To model different geometric configurations, see the "Weaving lane examples" (see fig. 62, page 105).
104
MODELING
THE ROAD NETWORK
Multilane
Single lane
Figure 62. Weaving lane examples
Modeling an increased/reduced number of lanes
Multifile
Monofile
Figure 63. Lane change examples
Modeling a traffic circle

This section describes how to model a traffic circle, in particular the entry to the circle, the circle itself, and
the exit from the circle.
Characterizing the entry to a traffic circle
When characterizing the roads that lead to a traffic circle, you have to consider the drivers behavior. For this
purpose, the traffic circles approach zone is distinguished from the decision zone. The driver slows down in
the approach zone whose length, determined by the vehicles nominal speed, varies between 100 and 150
meters. For the driver, the decision zone corresponds to the decision to directly move onto the circle, or to
give way depending on the traffic. At the start of the decision zone, the vehicle is traveling at an approximate
speed of 30 km/h. The length of the decision zone is set to 20 meters (see "Approach and decision zones",
fig.64 p.106).
105
ROAD NETWORK
Modeling a reduction in the number of lanes is done using multilane objects. Examples of possible lane
change configurations are given in figure 63, page 105.
ODELING
M
THE ROAD NETWORK
Circle
Decision zone
Approach zone
Turning approach zone

Turning exit zone
multilane corresponding to the decision zone

multilane corresponding to the approach zone
Figure 64. Approach and decision zones
The one-lane or two-lane lead-in road to a traffic circle is modeled by the single lane or multilane trajectory
corresponding to the approach zone and the decision zone. The trajectorys Speed at entry, page 82 representing the decision zone is set to 30%. The length of the object modeling the approach zone must be sufficient to allow vehicles to slow down in accordance with their motional capacities, otherwise the deceleration
is transferred to the preceding trajectories by setting the speed at entry to 40% or 50% depending on the geometric configuration. The Lane speed, page 82 parameter for all the lanes in the decision zones trajectory
is set to 30%. For a multilane entry, the turning approach zone is modeled by a trajectory whose Simulated
width, page 82 is reduced to 2 m (so that trucks cannot overtake or be overtaken). The same applies in the
turning exit zone.
When modeling the entry to a traffic circle, you must remember to manage trajectory conflicts (see Insertion
on a traffic circle, page 211), and assign the trajectories according to the vehicle categories and destinations
(see Prohibitors, page 168).
The circle is modeled using trajectories, usually with two lanes. The Lane speed, page 82 parameter is
determined by the circles radius; 30% represents a good compromise. The trajectories end in front of each
circle entry or exit lane. In this case, there are as many handles on the circle as there are entries and exit
lanes.
To model the traffic on the circle, you must define the behaviors (usually no lane changes to the right) and
the paths with Lane change distributions, page 185.
Single-lane circle exits are modeled directly by adding a handle with two attachment points at the circle exit.
You must connect the exiting trajectory to the handles right-hand attachment point, making sure - if possible
- that you avoid the overlap area between the circles trajectory and the exiting trajectory (see "Modeling
one-lane and two-lane circle exits", fig.65 p.107).
106
MODELING
THE ROAD NETWORK
Use the following procedure for modeling two-lane traffic circle exits:
1.
2.
3.
4.
5.
Add a handle in front of the right-hand lane on the circle exit (see Adding a handle or copying a
trajectory, page 89).
Add a handle in front of the left-hand lane on the circle exit (see Adding a handle or copying a trajectory, page 89). Place the two handles as far from each other as possible.
Add a handle with two attachment points for the circle exit.
Add a trajectory between the right-hand attachment point on the handle added in step 1, and the
right-hand attachment point on the handle added in step 2 (see Adding a trajectory between two
handles, page 87).
Left-click and hold on the new trajectory exiting the circle, drag to select 2-lane circle then
release.
ROAD NETWORK
2.) Left-lane handle
3.) Exit handle
1.) Right-lane handle

4.) Add a trajectory
5.) 2-lane circle exit
Figure 65. Modeling one-lane and two-lane circle exits
107
ODELING
M
108
THE ROAD NETWORK
Flow module
Flow scenarios, page 110

We shall describe three types of flow scenarios:
Empty scenario, page 113,

Generator scenario, page 114,
Subnetwork scenario, page 120.
Before moving to the other types of flow scenario, we should first define:
The links/nodes network, page 122.

Then, we are able to explain the principles:
Export-Import scenario, page 124.

The other types of flow scenarios require the editing of
Traffic counts, page 126.

We describe the implementation:
Estimation scenario, page 136,

Assignment scenario, page 141,
Subnetwork Assignment scenario, page 145,
Aggregate, page 149.
We end the chapter by outlining tools for
Paths: visualization and analysis, page 152
109
FLOW MODULE
This chapter describes the flow scenarios and how they are used in CubeDynasim. Following a description
of the general principles of
F L O W
SCENARIOS
Flow scenarios
The microscopic simulation of a projects urban development helps to evaluate how this development works
according to many diverse hypotheses formulated on the quantification of the demand. Thus, you can test
this development at various key moments in the same day in accordance with standard days, or by anticipating changes in the traffic.
The demand is a parameter of the simulation model while the offer is a result of the simulation.
Each assumption made on the demand is associated with a flow scenario. The traffic demand is expressed in
two forms:
As origin-destination matrices established for each vehicle category simulated. If necessary, different matrices are defined by time slot to account for variations in the traffic, including peaks.
2. As quantified paths. These paths are estimated from section or directional traffic counts on a
defined network or imported directly from a third party software.
1.
The flow scenario defines both the simulations start and end times, and the measurement start time for the
data collectors (see Data collector representation and associated elements, page 262). The period between
the simulation start time and the measurement start time serves to preload the network, which is empty when
the simulation beings. You must make sure that the network load period is sufficiently long. It will usually
correspond to twice the travel time of the longest trip through the network.
Defining a flow scenario

The Flow module entry window, page 110 is used to add, edit and remove flow scenarios. It is a Module
entry window., page 27.
Flow scenario
edited
List of flow scenarios
Identification
Calculation method
Schedule
Figure 66. Flow module entry window

Click the
110
icon on the Module bar, page 18 to access the Flow module entry window, page 110.
FLOW
SCENARIOS
You cannot delete a flow scenario if it is associated with a simulation scenario. You must first delete
the associated simulation scenario.
FLOW SCENARIO PARAMETERS

LABEL
Name
Schedule
Type
DESCRIPTION
Free, user-defined character string.
Choice from "AM Peak, PM Peak, Off-Peak". This is the time of day
covered by the scenario. The combination of the "Name of scenario"
and the "Time of day" must be unique. For example, you can define a
number of scenarios with the same name, but differentiated by the time
of day represented.
You can enter the name of your choice to add it to the list of predefined
schedules.
Identify 8 types of flow scenarios following their algorithms:
1.
2.
4.
5.
6.
7.
8.
Simulation start time

Complete simulation
The time the simulation starts, expressed in Time format,
page 112
The time the simulation ends, expressed in Time format,
page 112.
The simulation end time is necessarily greater than the simulation start
time. The maximum duration of a simulation is less than 24 hours,
where the start time is defined at 00:00:00, and the end time at 23:59:59.
A simulation cannot overlap two days.
Measurement start time
The time the simulation starts collecting data, in Time format,
page 112 (see Data collector representation and associated elements, page 262).
It must fall between the simulation start and end times. By default, it is
set to 15 minutes after the simulation start time. In this case, the duration
of the simulation is set to 1 hour 15 minutes to obtain measurements
over one hour.
111
FLOW MODULE
3.
Empty: no vehicles generated (to be used when simulating solely PT, or

rail scenario).
Generator: assignment all or nothing of an OD matrices minimizing
distance or time.
Subnetwork: quantifies the traffic demand based on a flow scenario of
type generator and a network scenario. The simulated network scenario
is necessarily a subset of the network scenario used to compute the
demand.
Estimation: stochastic assignment (logit) under constraints of invalidate path, directional and sectional traffic counts, and road capacity.
Assignment: stochastic assignment (logit) of OD matrices computed by
an estimation scenario, under constraints of invalidate paths, traffic
counts, and road capacity (see above Estimation).
Subnetwork assignment: assigning OD matrices results of an assignment (see above), on a network where the entrance/exit supports are also
included in the beforehand assigned network.
Export/Import: the link-node network computed from the trajectories
network, is imported and used by a third party software for path flow
estimation. This paths and flows are then imported and directly used by
the simulator.
Aggregate: the demand is expressed as an ordered sequence of different
weighted flow scenarios brought to the same period of time.
F L O W
SCENARIOS
Time format
Specify time fields with a character string in hh :mm :ss format, where
hh is the number of hours, between 00 and 23,
mm is the number of minutes, between 00 and 59,
ss is the number of seconds, also between 00 and 59.
For example,17:45 :00 complies with the time format. Midnight is expressed as 00:00:00. Note that
24 :00: 00 is an invalid format.
112
EMPTY
SCENARIO
Empty scenario
A simulation scenario includes a flow scenario as it defines the simulation hours. However, sometimes we
would want to simulate an operation no taking into account the flow of vehicles. For example, while calculating the free motion of the transportation system using the exclusive PT lane, or while conceiving the day
program for railways. For those different situations, we will use the empty flow scenario. By default, while
starting a new study, two empty scenarios are added (see tutorial adding an empty flow scenario).
FLOW MODULE
113
ENERATOR
G
SCENARIO
Generator scenario
The demand is quantified by an ordered set of origin-destination matrices.
The row in an origin-destination matrix associated with a network origin (i.e. entry) is identified by the name
of the corresponding origin (Origins, page 69). The matrixs column is labeled symmetrically in accordance with the name of its associated destination (Destinations, page 74). Thus, the value of a cell in the
matrix defines the average number of vehicles generated by the origin corresponding to the cells row, and
whose destination is the destination corresponding to the cells column.
Origin-destination matrices are defined in accordance with all OD type vehicle categories (see Category
parameters, page 43).
The values of the cells in the matrix express a demand by time unit. A flow scenarios matrices all have the
same time unit, whose value is set by the time sample. In order to modify the quantification of the demand
during the period simulated, you define several matrices for the same vehicle category. The simulation
engine applies the quantification of the first matrix for the duration of the time sample, then, during this same
period of time, applies that of the second matrix, and so on. If the time to simulate established by the schedule is greater than the duration resulting from the product of the number of matrices and the time sample, the
simulation engine continues by re-applying the quantification established by the first matrix, then the second
matrix, etc. For example, if you have a 30-minute time sample, two origin-destination matrices, and a simulated time of 1 hour 15 minutes: the simulation engine applies the first matrix, then the second matrix, and
lastly for 15 minutes the first matrix again.
The quantification data of a flow scenarios demand is compiled in a folder. A folder must contain at least
one sheet. Each sheet in this folder corresponds to one of the flow scenarios origin-destination matrices. A
sheet consists of a tab and a table in which the values of the origins-destinations matrix are stored.
The name of the tab is determined by the type of flow accounted for by its table of numbers, CAR for cars,
TRUCK for heavy vehicles. By moving your mouses cursor over a tab for two seconds, you display the first
time at which this data will be collected in the simulation. The time displayed corresponds to the last values
validated, i.e., either at the addition or the deletion of the scenario, not that being edited. Click with either the
left or right mouse button on a sheets tab to make it the current sheet and subsequently be able to edit its
table.
The origin-destination matrix directly corresponds to the table without its first and last rows/columns, which
you do not directly edit. The first row in the table lists the names of theDestinations, page 74 in the project, thus facilitating the correspondence between the column and its associated exit. The first column in the
table lists the identifiers of the Origins, page 69 ordered according to their correspondence with the
tables rows. The last row and column respectively contain the number of vehicles generated by destination
and by origin (see "Flow module entry window", fig.66 p.110).
You will usually have to prepare the tables to facilitate the importing of data from other applications dedicated to evaluating the quantification of the demand. This consists in reorganizing the rows and columns and/
or in merging the tables rows.
By default, all the Origins, page 69, and all the Destinations, page 74, are listed in the table in alphabetical order. If necessary, you can rearrange the order of the rows and columns in the tables (see Rearranging the rows and columns in a table, page 118).
For an origin (i.e. entry) on a multilane in one of the Trajectories, page 81, there is one Origins,
page 69 per lane and, therefore, as many rows in the raw table. When defining the origin-destination matrix,
you have one row per origin in the network, whether or not this origin contains one or more lanes. In order to
obtain the correspondence between the cells in the origin-destination matrix and those in the tables of a flow
scenario according to their position, you must merge the rows in the table corresponding to the same origin
(i.e. entry) (see Merging the rows in a table, page 118). In this case, the quantity of the generated flow is
equally allocated between the merged origins.
114
GENERATOR
SCENARIO
The operations affecting the order of the rows and columns apply exclusively to all the tables of the current
flow scenario being edited.
To adopt the same distribution of rows and columns for the tables in another flow scenario without
having to repeat the same operations, select the flow scenario already defined, assign the parameters
their new values and add this new flow scenario by clicking the Add button in the Flow module entry
window, page 110.
This section describes the operations that can be carried out on the current flow scenarios sheets:
Adding a matrix, page 116,

Deleting a sheet, page 117,
and also on their table of numbers:
Editing a cell in a sheets table, page 117,
Rearranging the rows and columns in a table, page 118,
Merging the rows in a table, page 118,
Importing/Exporting a table, page 118,
Importing a set of tables, page 118,
Factoring the values in a matrix, page 119.
Any modification to the contents of a flow scenario must be validated by clicking the Apply or Add
buttons in the Flow module entry window, page 110.
The Generator scenario edit window

To edit a Generator flow scenario, select Generator in the Type list and specify the parameters (Name,
Schedule, etc.) in the Flow module entry window, page 110. Click Configure to display the Generator
scenario entry window, page 116.
ORIGIN GENERATOR PARAMETERS

LABEL
Time sample (min)
Defines the time unit for all the matrices in the current scenario
Assignment algorithm
Defines the path calculation method for each origin-destination

Distance: assignment of ODs on the shortest path
Time: assignment of ODs on the fastest path
Category/sample
matrix tree
Tree of matrices by category/sample
Origin-destination
matrix
115
DESCRIPTION
Quantification of each OD for the selected category/sample
FLOW MODULE
ENERATOR
G
SCENARIO
Scenario properties
Sample of matrices
Path coast function
OD matrix for the
CAR category for the
selected schedule (17:45)
Column name (destination)
Row name (origin)
Schedules per category
List of categories
Figure 67. Generator scenario entry window
A Generator scenario assigns the ODs on a single path defined according to the algorithm chosen in
its definition.
Adding a matrix
1.
2.
Click Add to add a new sheet.

Select the category to add in the category entry window. If the category does not exist in the list of
categories in the Generator scenario entry window, page 116, it is added. The associated
schedule is the same as the first schedule of the other existing categories. If the category already
exists, a matrix is added after the previous matrices for the same category. Its name is the last
schedule incremented by the time sample. In the status of the Generator scenario entry window, page 116, adding the new matrix will place a new TRUCK matrix at 08:45:00.
Vehicle category selection list
Working on a matrix
Right-click on the tab of the matrix that you want to edit.
2. This will display the "Menu for managing sheets" (see fig. 68, page 117).
1.
116
GENERATOR
SCENARIO
Selected matrix
Menu for managing

sheets
Figure 68. Menu for managing sheets
MATRIX OPERATIONS
LABEL
Export matrix
Load a matrix file
Multiplies the current matrix by the factor specified in the corresponding dialog
box
Exports the current matrix in text format (see Importing/Exporting a table,
page 118)
Imports the selected matrix from a text file (see Importing/Exporting a table,
page 118)
Modify vehicle type
Changes vehicle categories for the current matrix.
Apply a factor to all

matrices
Multiplies all the flow scenarios matrices by the factor specified in the corresponding dialog box
Load matrices files
Imports all the text files in a directory for the selected matrix category (see
Importing a set of tables, page 118)
Deleting a sheet
Right-click the tab of the sheet to be deleted to display the "Menu for managing sheets" (see
fig. 68, page 117).
2. Drag the mouse to the Delete menu command, then release to delete the sheet.
1.
The deletion of a sheet is irreversible. CubeDynasim does not prompt you to confirm the deletion.
Editing a cell in a sheets table
If the table to edit does not belong to the current sheet, click the tab of its sheet.
Display the cell to edit using the tables scroll bars.
3. Click in the cell to go into edit mode (the cell is displayed with a white background, and a cursor
appears at the end of the value).
4. Edit the value and press Enter to validate.
1.
2.
117
FLOW MODULE
Apply a factor to the

matrix
DESCRIPTION
ENERATOR
G
SCENARIO
Rearranging the rows and columns in a table

Select the row or column you want to move.
Click and hold, then drag the mouse to the appropriate position.
3. Release the mouses button between the two lines or columns where you want to insert the line or
column (the modification is applied to all the matrices in the edited flow scenario.)
1.
2.
Merging the rows in a table

To identify whether a row in a table is the result of a merge:
1.
2.
Position the pointer on the name of the row in the table.

If the row is the result of a merge, after one second a message is displayed indicating the number
of merges corresponding to the row, otherwise no message is displayed.
To merge two rows in a table into one row:

Position the pointer on a category tab, then right-click to open the Row Management window.
Press and hold Ctrl and click each row to merge.
3. Release the Ctrl key and click Merge.
1.
2.
To split a merged row in the table into as many rows:

Open the Row Management window.
2. Select the row to split and click Split.
1.
Importing/Exporting a table
The exchange files handled by the CubeDynasim flow module are text files in ASCII format, containing
integer values separated by the space character in lines ending with a carriage return. You must make sure
that the correspondence between the network entries and the flow scenario table rows, and the network exits
and the flow scenario table columns, are respectively equivalent to those in the exchange files. If the number
of lines in the exchange file is greater than the N rows in the table: CubeDynasim assigns the table values
with the first N lines in the file. For all other cases in which the number of rows or columns differs between
the exchange file and the table: CubeDynasim displays an error message and the import fails. Consequently,
it may be necessary to proceed by Rearranging the rows and columns in a table, page 118, and Merging
the rows in a table, page 118 before carrying out imports.
To import the data in an exchange file in order to initialize the values of one of the flow scenarios table of
numbers being edited:
Click and hold on the tab of the sheet whose table values you wish to assign. This displays the
"Menu for managing sheets" (see fig. 68, page 117).
2. Drag the mouse to select the Import file menu command.
3. Use the file selection window displayed to select the exchange file to import.
1.
To export the table of a sheet in the flow scenario being edited to an exchange file:
Select the Export matrix command in the "Menu for managing sheets" (see fig. 68, page 117) in
the tab of the sheet whose values you wish to save.
2. In the file selection window displayed, specify the files name and location.
1.
Importing a set of tables

With CubeDynasim, you can import all the exchange files contained in a folder and assign them to a category. When importing a folder, all the sheets previously defined for this category are destroyed, then, for
each file in the folder, a sheet is created and inserted in the folder in the alphabetical order of the files
imported. If the import fails because at least one of the files does not respect the format of the exchange files
according to the projects set of entries/exits (see Importing/Exporting a table, page 118), the folder remains
in the state prior to the import.
118
GENERATOR
SCENARIO
To import a folder of exchange files from the flow scenario edited:

If necessary, proceed by Adding a matrix, page 116 and assigning it the vehicle category for
which you wish to define the demand.
2. Click one of the tabs corresponding to the category for which you wish to redefine the demand.
This displays the "Menu for managing sheets" (see fig. 68, page 117).
3. Drag the mouse to the Import several matrices menu command.
4. In the folder selection window displayed, select the folder containing the exchange files to import.
1.
Factoring the values in a matrix

To factor the values (i.e. multiply them by a factor) in the table of one of the flow scenario sheets edited :
Click the tab of the sheet whose values you want to modify. This displays the "Menu for managing
sheets" (see fig. 68, page 117).
2. Drag the mouse to the Multiply the flows of matrix menu command to display the multiplier entry
window.
1.
4.
Enter a real value in the Multiply by field, or use the arrows to increase/decrease the value.
Click OK to confirm. The tables values are subsequently modified.
You can apply this operation to all the tables in the flow scenario edited by selecting ...all the matrices in the
"Menu for managing sheets" (see fig. 68, page 117).
CubeDynasim resets invalid values in the Multiply by field to zero. To make sure the value entered is
valid, press ENTER with the cursor in the edit box; the value applied is now displayed.
119
FLOW MODULE
3.
S U B N E T W O R K
SCENARIO
Subnetwork scenario
The subnetwork flow scenario allows to simulate a subnetwork applying the demand computed on the network. The subnetwork flow scenario must be applied in combination with a Generator flow scenario.The
subnetwork flow scenario assigns his demand accumulating the paths and flows going through the subnetwork.
This feature should be used when we want to edit and develop a large network. We must extract homogeneous subnetworks from the large network. We first calibrate each of the subnetwork before simulating the
entire network. The simulation time for each of the subnetworks is not important, as compared to the simulation time for the entire network. Time saving during the development might be significant. This method does
not consider the interactions with the global network's elements, which are outside the Subnetwork. For
example, a Subnetwork can be an isolated intersection, while a global network can be the entire length of an
avenue (see tutorial Subnetwork scenario).
Adding a subnetwork flow scenario:
1.
Display the Flow module entry window, page 110 clicking
2.
Edit a new name for the flow scenario.

Select Subnetwork out of the drop-down list named Type.
Click Add.
Click Configure to display the "Subnetwork scenario entry window" (see fig. 69, page 120).
Fill in the Subnetwork scenario parameters, page 120.
Click Back.
Click Apply to validate the new parameters of the flow scenario.
Click Quit to close the entry window.
3.
4.
5.
6.
7.
8.
9.
of the Module bar, page 18.
SUBNETWORK SCENARIO PARAMETERS

LABEL
Flow scenario
Network scenario
DESCRIPTION
Name of the Origin flow scenario to assign
Name of the network scenario on which to assign the flow scenario matrix
Reminder of the scenarios

properties
Origin flow scenario to
assign
Network scenario on which to
assign the matrix
Figure 69. Subnetwork scenario entry window
120
SUBNETWORK
SCENARIO
In the case of a type other than generator flow scenario, it is not necessary to create a specific flow
scenario to simulate a subnetwork. In this case, we define directly a simulation scenario combining
the flow and a scenario of geometry which is a subset of the geometry parameter of the global flow
scenario.
FLOW MODULE
121
T H E
LINKS/NODES NETWORK
The links/nodes network

CubeDynasim converts the road network to a simplified links/nodes network. Each node represents an intersection of trajectories on the network, i.e. a point where two trajectories converge or diverge. The link links
two nodes and includes all the consecutive trajectories between the two intersections.
CubeDynasim converts automatically the trajectory network to a links/nodes network. The trajectory network is defined as a set of supports linked by trajectories. The links/nodes network is a set of nodes and
links.
Each node has its own id and geometric coordinates. The id of a node is an unsigned integer. The set of id
defines a continuous set of unsigned integers ([0;N-1] where N is the number of nodes). A node represents
either a convergence, a divergence or a change of parameters between contiguous trajectories.
Links are oriented. Fields A and B define origin node and destination node, respectively. The other fields of
the link measure physical variables such as length, free speed limit for each type of vehicle, and so on. When
computing the links/nodes network, following the geometric configuration, it sometimes is necessary to split
the node to prohibit or preserve some link chains. In this case, we add new nodes and empty links between
those nodes. An empty link is a zero length link. An empty link does not impact the cost of a path going
through the link.
The network includes contact nodes defined at the entrance and at the exit of the network. The id of the contact nodes does not belong to the set of ids of the nodes. The contact nodes establish a border between the
links/nodes network, and the network of a third party software.
For certain flow scenarios (Export-Import, Estimation, Assignment, Subnetwork Assignment), we can display the links/nodes scenario saved as a set of shape files in the directory of the study: Flow\<name of the
flow scenario>\export using software GIS such as QuantumGis to be downloaded at http://www.qgis.org/
(see "A trajectory network and his representation as a network links-nodes", fig.70 p.123). This data can be
viewed using any other GIS solution. Shape files are used as a data exchange format.
Each component of the links/nodes networks is saved in its own layer:
Link: id layer of the links.

Node: id layer of the nodes.
NodePCInD: id layer of the contact points for the network entrance.
NodePCOutD: id layer of the contact points for the network exit.
*_Antilabel: id of the Prohibitors, page 168 layer.
If * is an empty string, the layer gathers the prohibitors applying them to all the types of vehicles
Else * is a vehicle type id, on which the prohibitors are applied.
*_AntilabelMP: id of the MP prohibitor, page 173 layer, applying the pattern of the prohibitors.
If the model does not include any prohibitor, the layers *_Antilabel are not generated.
The same rule applies for the MP prohibitor.
The link layer includes, at least, six fields:
1.
2.
3.
4.
5.
6.
122
A: id of the origin node of the link,

B: id of the destination node of the link,
DISTANCE: length of the link in meters,
NB_FILE: number of lanes,
*: id of the type of vehicle, speed limit on the link expressed in km/h,
CAPA: capacity of the link in Personal Car (PC).
THE
LINKS/NODES NETWORK
The layers Node, NodePCInD, NodePCOutD include the fields:

N: id of the node,
2. X: coordinate of the node in X,
3. Y: coordinate of the node in Y.
1.
The layers of type *_Antilabel include two fields:

1.
2.
A: the origin node id of the prohibited link,

B: the destination node id of the prohibited link.
The layer of type *_AntilabelMP include four fields:

0A: the origin node id of the first link defining the MP prohibitor,
0B: the destination node id of the first link defining the MP prohibitor.
3. 1A: the origin node id of the second link defining the MP prohibitor.
4. 1B: the destination node id of the second link defining the MP prohibitor.
1.
2.
FLOW MODULE
Trajectory network
Shape layers
Network entry PcInD nodes
Network exit PcOutD nodes
Node
Link
Links-nodes network
Figure 70. A trajectory network and his representation as a network links-nodes
It is essential to check the integrity of the links/nodes network.

For example, you should have the same entrance and exit than the one considered during the
modeling process. Thus, the layers nodePcInD and nodePcOutD must be coherent with the
simulation model.
123
E X P O R T - I M P O R T
SCENARIO
Export-Import scenario
The export-import flow scenario allows to exchange data between CubeDynasim and a traffic assignment
software. The purpose is to directly micro-simulate with CubeDynasim the paths and flows results of the
assignment. You should take into account that the assignment network is much larger and includes the microsimulated network.
The CubeDynasim links/nodes network is automatically generated from the geometric network. It is made
up exclusively of nodes and links. Each node has an unique id and 2D coordinates. The node id is an integer.
The node id is not necessarily the same in CubeDynasim and in the traffic assignment software. We switch
from one to another using a translation (choose a value for the translation that insures the uniqueness of the
imported nodes regarding the nodes of the traffic assignment network). Links are one-way. Fields A and B
define origin node and destination node, respectively. The other fields quantify physical variables (length,
free speed, etc.).
The contacts points are specific nodes. They define the crossing points between the network edited in the
traffic assignment software and the CubeDynasim model's links/nodes network. The links connected at a
contact point to a network node have no physical effect (null travel time).
The links connecting the traffic assignment network to contact points are edited with the traffic assignment
software at the first importation of the CubeDynasim network. The links connecting the CubeDynasim network at the points of contact are automatically generated.
Permanently fixing the contact points (i.e. do not change input output of the CubeDynasim network), the
user can edit the trajectory network without having to redo the connections between the two networks during
the subsequent export-import operation.
Edit a flow scenario of type Export-Import

1.
2.
Edit a new Name for the flow scenario.

Select ExportImport out of the drop-down list named Type.
Click Add.
Click Configure to display the "Subnetwork scenario entry window" (see fig. 69, page 120).
Fill in the Subnetwork scenario parameters, page 120.
Click Back.
Click Apply to validate the new parameters of the flow scenario.
3.
4.
5.
6.
7.
8.
9.
Links-nodes network exported is saved in the folder: edyna\<study>\Flow\<flow scenario>\export

The demand must be saved in the folder: edyna\<study>\Flow\<flow scenario>\import
EXPORTIMPORT SCENARIO PARAMETERS

LABEL
Network scenario
Node no.
Contact node no.
124
DESCRIPTION
Name of the network scenario that generates the links/nodes network.
Translation value between CubeDynasim and traffic assignment software.
First contact nodes number.
EXPORT-IMPORT
SCENARIO
EXPORTIMPORT SCENARIO PARAMETERS

LABEL
Export format
Demand duration
DESCRIPTION
Export format of the links/nodes network.
Sampling of the imported demand.
Scenario properties
Network scenario - generates

the Links/Nodes network
Node number definition
First contact node number
Figure 71. ExportImport scenario entry window
Format of the path-flow files to be imported

CubeDynasim reads the results of the traffic assignment software in a text file named according to the following convention: CHEM_[C].TXT where [C] is the name of the vehicle category. For example, the path
file for the type of vehicles named TRUCK, is identified by CHEM_TRUCK.TXT. The path-flow files
imported in CubeDynasim must be located in folder edyna\<study>\Flow\<flow scenario>\import.
Each line of the path-flow file includes six fields separated by spaces or tabulations:
1.
2.
3.
4.
5.
6.
Assignment iteration number (integer greater than or equal to 1).

Path origin node number
Path destination node number
Link origin node number
Link destination node number
Number of vehicles for this path and this iteration (real number). The contribution of this path is
obtained by dividing this amount by the total number of iterations.
Node numbers are expressed in the space of the nodes of the assignment network. Each line of the file is one
link of a path defined for an iteration. The sequence of the lines describes the nodes traversed for each of the
paths.
125
FLOW MODULE
Time sample
T R A F F I C
COUNTS
Traffic counts
The CubeDynasim traffic count object quantifies section or/and directional movements by peak time and
type of vehicles. Directional traffic counts can be expressed as absolute values (where the flow values are
specified for each movement) or as relative values (by allocating a section count to several directions via percentages). They are to be used with estimation an assignment flow scenario.
There are three types of object counts depending on their parameters:
Traffic count direct entry, page 126 represented by the icon
Traffic count percentage, page 127 represented by the icon
Traffic count in a database, page 129 represented by the icon
However, editing operations apply in the same way on all three types of counts.
Adding a traffic count, page 131.

Editing a traffic count, page 132.
Splitting a traffic count, page 133.
Traffic count direct entry

All movements of a traffic count, with direct entry
vehicle.
, is filled in as the number of vehicles for each type of
COUNT PARAMETERS
LABEL
Layer
Tolerance +
Tolerance -
Generate box
Tabs
DESCRIPTION
Traffic count layer.
Greater tolerance of a traffic count is defined by a percentage. After convergence, the maximum number of vehicles associated with a movement is defined as:
VU* <= (1 + Tole+) x VU
where
VU is the number of units of vehicles measured for this movement;
VU* is the number of units of vehicles calculated after convergence.
The lower tolerance of a traffic count is defined by a percentage. After convergence, the
minimum number of vehicles associated with a movement is defined as:
VU* >= (1 + Tole-) x VU
where
Boolean, if Yes, then the traffic count should be taken into consideration while compiling
the Flow box, page 152.
Each tab corresponds to a peak time:
A tab includes, for each type of vehicle, the hourly flow in number of vehicles
1.
2.
Section
for each directional movement numbered from 1 to n.
Import Optional field. Identifier (preferably unique) of the traffic count needed to Import the
Identifier values of traffic counts from a text file, page 134
126
TRAFFIC
COUNTS
COUNT PARAMETERS
LABEL
Width
Color
DESCRIPTION
Display width of the traffic count in the edit zone.
Display color of the handles attachment points (see Color field, page 31).
The tolerances are defined uniquely for all movements, type of vehicles and counting schedules.
Splitting a traffic count, page 133 to assign a specific tolerance for each type of vehicle, if
necessary.
Delete a schedule
Add a schedule
Tolerance fields
Schedule tab
Movement 1 edited
Movement 2
Figure 72. Traffic count direct entry edition
Traffic count percentage

The traffic count percentage
defines a proportional distribution on each of its directions depending on the
number of vehicles counted in section.
In the case of a traffic count percentage, the value of the field Section is expressed in units of vehicles. If the
value is blank, the counting is not being taken into account.
The values associated for each of the directions are percentages. The sum of the inputs should be less than or
equal to 100. If directions do not have values, they will be distributed in proportion to the missing percentage
(100 minus the sum of the direction values entered).
127
FLOW MODULE
Add a type of vehicle

Delete the TRUCK category
Delete the CAR category
T R A F F I C
COUNTS
COUNT PERCENTAGE PARAMETERS

LABEL
Layer
Tolerance +
Tolerance -
Generate box
Tabs
Width
Color
DESCRIPTION
Traffic count layer, to be selected among the set of layers of the current network scenario.
VU* <= (1 + Tole+) x M% x VUS
where
VUS is the number of units of vehicles measured in section;
M% flow is the percentage of the flow section assigned to the direction;
UV* >= (1 - Tole-) x M% x UVS
where
VUS is the number of units of vehicles measured in section;
M% flow is the percentage of the flow section assigned to the direction;
Each tab corresponds to a peak time.
For every type of vehicle, the field named Section defines the hourly flow measured in section expressed in units of vehicles.
A tabulation includes, for each direction (numbered 1 to N), an input column for the percentage of the traffic in sections assigned to this direction.
Display width of the traffic count.
1
2
Figure 73. Traffic count percentage edition
128
Truck
Car
276 PC 10 PC
927 PC 10 PC
TRAFFIC
COUNTS
Traffic count in a database

If values of the counts are compiled in a SQLITE database, these values are directly extracted following simulated hours to set up the simulation model (http://www.sqlite.org). For example, for a flow scenario named
Current, you must create a database named Current.db. The database should be backed up in the folder of
the study, that is in the same location as dynasim.db, the data collector database (see "Files and directories",
fig. p.38).
If you use database counts, the flow scenario should not be named dynasim. In this case there
would be a conflict between the count database and the data collector database.
The database includes two tables, the table of movements and the table of counts.
The table of movements identified MOVEMENT, include 5 fields:
id: primary key
camera: a string naming the point of view
3. letter: a character identifying the movement for a type of vehicle
4. date: date format, defines the day of the recording (not used yet)
5. comment: optional string.
1.
2.
Figure 74. Example of the table MOVEMENT

Each row of the table COUNT shows the passage of a vehicle. The table includes three fields:
id: primary key
movement: extern key, id of the movement figuring in the MOVEMENT table
3. time: time of the passage of the vehicle following the format hh-mm-ss (for example 17-43-01).
1.
2.
SQL for creating the table COUNT:

CREATE TABLE COUNT( 'id' INTEGER PRIMARY KEY, 'movement' INTEGER NOT NULL,
'time' TEXT NOT NULL)
129
FLOW MODULE
SQL for creating table movement

CREATE TABLE MOVEMENT( 'id' INTEGER PRIMARY KEY, 'camera' TEXT NOT NULL,
'letter' CHAR(1) NOT NULL, 'date' TEXT NOT NULL, 'comment' TEXT)
T R A F F I C
COUNTS
Figure 75. Example of the table COUNT
Figure 76. The Data model of the count database
COUNT IN DATABASE PARAMETERS

LABEL
Layer
Tolerance +
Tolerance -
Generate box
Movement
130
DESCRIPTION
Traffic count layer, to be selected among the set of layers of the current network scenario.
VU* <= (1 + Tole+) x VU
where
VU* >= (1 + Tole-) x VU
where
Set the values of the fields CAMERA and LETTER for each of the pairs {movement, type
of vehicle} defined for the traffic count.
TRAFFIC
COUNTS
COUNT IN DATABASE PARAMETERS

LABEL
Tabs
Width
Color
DESCRIPTION
Each tab corresponds to a peak time.
For each (numbered from 1 to n) directional movement, a tab contains a column of the value
of traffic by type of vehicles entry
For each type of vehicle, the field named Section defines the traffic section.
The values are initialized from the database (gray font color).
The user can, if desired, edit the default value (black font color).
Display width of the traffic count.
When a value for a movement has been edited by the user, this value is taken into account for all flow
scenarios.
Value edited by the

end user
Value extracted from
the data base
Figure 77. Traffic count in database edition
Adding a traffic count

Proceed as follows to create a section traffic count point in CubeDynasim:
1.
If necessary, switch to geometric mode using the
2.
Click the
icon on the toolbar.
button on the Simulation object bar, page 17 to activate create traffic count
mode. The pointer in the network edit area changes to
Click the origin trajectory to position the traffic count.

4. Right-click to finalize the section traffic count.
5. Complete the traffic count entry window (you do not have to fill in all the traffic values in each
schedule tab).
6. Click OK to confirm.
3.
131
FLOW MODULE
Movement of the
traffic count
T R A F F I C
COUNTS
Proceed as follows to create a directional traffic count point in CubeDynasim:

1.
2.
Click the
icon on the Simulation object bar, page 17 to activate create traffic count mode.
The pointer in the network edit area changes to

3.
4.
5.
6.
7.
8.

.
Click on the origin trajectory to position the traffic count.

Click on the destination trajectory.
Repeat to add as many destinations as necessary.
Right-click to finalize the directional traffic count.
Complete the traffic count entry window (you do not have to fill in all the traffic values in each
schedule tab).
Click OK to confirm.
Editing a traffic count

Traffic counts are simulation objects that can be edited in Edit Object mode, page 20 depending on the
functions:
Adding a schedule, page 132,

Deleting a schedule, page 133,
Adding a type of vehicle, page 133,
Deleting a type of vehicle, page 133.
All these editing operations occur in the input box of the traffic count. To display this input box:
1.
2.
Switch to edit mode by clicking the
3.
Position the cursor on the count, and then press M to display the input box of the traffic count.
Click OK to validate the editing and close the input box.
4.
Adding a schedule
Click the Add a schedule button to display the list of available schedules, and select the appropriate schedule
in the list.
This operation adds the schedule to all the traffic counts on the model.
132
TRAFFIC
COUNTS
Deleting a schedule
Click on the cross tabulation of the schedule to delete.
This operation removes the schedule and the values of all traffic counts on the model.
Adding a type of vehicle
Click the Add a type of vehicle button to display the list of available types of vehicle, and select the appropriate one from the list.
FLOW MODULE
This operation adds the type of vehicle to all the traffic counts on the model.
Deleting a type of vehicle
Click on the cross next to the name of the type of vehicle to delete.
This operation removes the type of vehicle of all traffic counts on the model.
Splitting a traffic count

We can face a very strong disparity of flows following the type of vehicles on the same traffic count. In this
case, the same tolerance percentage applied to all types of vehicle is irrelevant. For example, if there are
1500 cars and 10 trucks with the same tolerance of 5%, the number of cars included in the interval is [1425;
1757] and the number of trucks included in the interval is [9.5; 10.5]. Then, it is likely that the calculation of
the demand will not converge, given the narrowness of the range of the allowable flow of trucks. It is recommendable to define a tolerance specific for each type of vehicle, which will duplicate the traffic counts per
type of vehicle.
133
T R A F F I C
COUNTS
It is possible to split/duplicate a traffic count following a category while preserving the already edited values.
1.
2.
Switch to edit mode by clicking the
icon on the Toolbar, page 15.
Position the cursor on the traffic count. Hold down the right mouse button, to display the menu.
drag the mouse to select the entry Split Vehicle type.
4. Release the mouse to open the box entry.
3.
Select the layer of the new traffic count among the set of layers of the current network scenario.
6. Click OK to close the box entry and add the new traffic counts.
5.
Figure 78. Count: split type of vehicle
Import the values of traffic counts from a text file

The values of traffic counts (types direct entry and percentage) can be imported from a text file. Each line of
the text file corresponds to a value of the traffic count. Each line has five fields. The fields are delimited by at
least one space. A value containing spaces must be framed by a {}.
134
TRAFFIC
COUNTS
The five fields are:

1.
2.
3.
4.
5.
Import Identifier of the traffic count: the value must be entered via the traffic count edition box.
For example C1_South for the traffic count below.
Peak hour: corresponds to one of the labels on the tabs of the edit box of the traffic count. For
example, in the case below AM Peak.
Type of vehicle: id of the type of vehicle.
Movement: Section for the traffic count section, otherwise the movement number.
Flow: integer value for the number of vehicles or a percentage setting a distribution of movements
(traffic count percentage)
2) Peak hour
3) Type of vehicle
4) Movement
1) Import Identifier
1.
2.
3.
4.
135
Click File on the toolbar.

Click the submenu named Flow Import.
Select the file storing the flow values.

Click Apply to store the new values of the traffic counts.
FLOW MODULE
To directly import the text file storing the values of the traffic counts:
E S T I M A T I O N
SCENARIO
Estimation scenario
A flow scenario of type Estimation calculates the demand following the constraints defined by:
the traffic counts and their tolerances,

the capacity defined for each link on the network,
the parameters setting the multi-path (a subset of paths sharing the same origin and destination),
the maximum number of paths sharing the same origin and destination
the tolerated maximum cost difference between two paths sharing the same origin-destination
the multi-path dispersion coefficient
Within these constraints, the algorithm calculates an estimated flow-path, minimizing the cost function
defined as the sum of travel times. A path is defined as a sequence of links.
The cost function is defined as the sum of the travel time for all the vehicles. Then, the estimation
algorithm seeks to minimize the number of vehicles (while respecting the constraints).
We must, therefore, focus on asymmetric tolerance ranges for the traffic counts.
For example: Tolerance- 1% and Tolerance+ 5%
136
ESTIMATION
SCENARIO
Principle
Build the links/nodes network
Error messages due to the construction of

the paths, page 322
Error messages due to the estimation,

page 321
Reference state
Error messages due to the reference status, page 322
Micro simulation
Errors for the current replication,

page 416
Figure 79. Diagram of a simulation with a flow estimation scenario

Create a flow Estimation scenario:
1.
2.
Fill in the various fields (see Flow scenario parameters, page 111).
Select Estimation out of the drop-down list named Type.
Click Configure to display the "Estimation entry window" (see fig. 80, page 138).
Fill in the Estimation scenario parameters, page 138.
Click Back.
Click Add to validate the new parameters of the flow scenario.
3.
4.
5.
6.
7.
8.
137
FLOW MODULE
Path flow estimation

le rseau
E S T I M A T I O N
SCENARIO
Figure 80. Estimation entry window
ESTIMATION SCENARIO PARAMETERS

LABEL
Network scenario
DESCRIPTION
Network on which the algorithm calculates the estimation to be selected among
all the network scenarios. The network scenario defines the traffic counts, the
links-nodes (via the network of trajectories), the capacity of the links, etc.
Theta
The multi-path dispersion coefficient models the sensitivity of users to the various
costs of paths sharing the same origin and destination.
Maximum iterations
Maximum number of iterations for the calculation of the algorithms convergence.

This setting is used to reduce the calculation time.
Maximum paths
Spread %
Maximum number of paths sharing the same origin and destination.

Maximum cost difference between two paths sharing the same origin and destination. This difference is expressed as a percentage.
To add an Estimation flow scenario, it is necessary to fill in all the parameters.
Examine the results of the estimation

Check that the The links/nodes network, page 122 shares the same sets of inputs and outputs with the trajectory network. In addition, the layers nodePcInD and nodePcOutD must be consistent with the trajectory
network. All the results of the estimation are saved in the import directory: < directory of the study
>\Flow\< id of the flow scenario >\import.
For example: C:\Users\dynasimuser\edyna\Estimation_20m_1h_2h\Flow\Estimation_2h_hps\import.
138
ESTIMATION
SCENARIO
It is necessary to ensure the convergence of the estimation by visualizing Error messages due to the Estimation, page 415 from the simulation module input box, or by directly opening the file text flow_ saved in the
import directory.
The paths for each type of vehicle are saved in a file identified text CHEM_ [C]. TXT following the same
format as the Format of the path-flow files to be imported, page 125 ([C] name of the type of vehicle).
The OD matrices for each of the type of vehicle are stored in files OD_ [C] _ [PCU], where [C] is the name
of the type of vehicle and [PCU] is an integer defining the number of personal car units for this type of vehicle. For example, OD_CAR_1.TXT. Each line of the file corresponds to the number of vehicles, the origin
and the destination. Origin is an id of a contact node entering the network. Likewise, destination is an id of a
contact node exiting the network.
Input or output data of the estimation algorithm are saved in shapefile format, to be easily displayed in map
form. We define [C] as the id of a type of vehicle.
[C] _CS: the layer storing the traffic counts in the section for the type of vehicle [C] connects a link of the
links-nodes network and a flow, constraints for the estimation algorithm. The layer includes of three fields:
A: id of the node entering the link,
2. B: id of the node exiting the link,
3. NB: flow per hour counted on the link.
1.
A: id of the node entering the first link,

B: id of the node exiting the second link,
3. NB: flow per hour counted on the link.
1.
2.
[C] _CSxFLOW: mapping on the links of the links-nodes network, the flows calculated for vehicle type [C]:
A: id of the node entering the link,
2. B: id of the node exiting the link,
3. NB: flow per hour crossing the link.
1.
[C] _CDxFLOW: mapping flow of vehicle type [C] calculated for each movement of the directional counts
that have been filled in and taken into account by the estimation algorithm.
A: id of the node entering the first link,
B: id of the node exiting the second link,
3. NB: flow per hour crossing the two links.
1.
2.
[C] _PATH: for each type of vehicle [C], the paths is associated with a polyline resulting of the connection
of the links used by these paths. To load and select the layer, click on one of the links to see all the paths
using this link (see paths on trajectory). If the number of paths exceeds the shapefile storage capacity, the
layer will not be generated.
Analyze the results of the flow calculation

For flow scenarios of type Estimation and Assignment, it is important to first consult the flow_.err text file
in the import directory or using the interface to display the error messages to check the convergence of the
calculation of traffic.
Load the layers of the network links/nodes saved in the export directory using your favorite GIS software.
139
FLOW MODULE
[C] _CD: the layer of directional counts involves two links of the links-nodes network and the flow of vehicles of type [C] passing through those two links. These flows are a constraint for the estimation algorithm.
The layer includes three fields:
E S T I M A T I O N
SCENARIO
Visualization and labeling of the field NB of layers [C] _CD % xFLOW and [C] _CS % xFLOW to display the convergence of counts.
Figure 81. CubeDynasim trajectory network and traffic counts
Traffic in sections
Section traffic count
Convergence of the section counts
Figure 82. Layers of section traffic counts in the links/nodes network
140
ASSIGNMENT
SCENARIO
Assignment scenario
An Assignment flow scenario assigns on network-2 a matrix origins-destinations results of an Estimation
flow scenario calculated on network-1. In this case, the set of input-output (i.e. entrance and exit contact
nodes) is the same for both networks. The assignment flow scenario is used to assess and take into account
the reports of traffic due to changes to the network.
An important use for this method is evaluating traffic transfers resulting from changes on the road network.
The Assignment scenario transforms all the paths from an Estimation scenario, page 136 into an Origin/
Destination matrix, which it assigns to the new network while taking into account the following:
possible counts and their tolerances

the networks capacity
the assignment scenarios parameters
the maximum number of paths
the spread %
the multi-path scattering coefficient
At the end of the estimation process, it is possible to alter, with an executable program (generally a script in
shell/awk/sed, perl or python), the flow matrices to be assigned.
141
FLOW MODULE
Based on these various elements, the algorithm computes a set of path-flow seeking to minimize a cost function that is defined as the sum of all the travel times.
SSIGNMENT
A
SCENARIO
Principle

the paths, page 322
Path flow estimation on network 1
Error messages due to the estimation,

page 321
Assign the flow on network 2
Error messages due to the assignment,

page 321
Reference state
Micro simulation
Errors for the current replication,

page 416
Figure 83. Schematic diagram of a simulation with a flow assignment scenario
142
ASSIGNMENT
SCENARIO
Create an Assignment flow scenario.

1.
3. Select Assignment out of the drop-down list named Type.
4. Click Add before you change the type setting flow scenario-specific settings.
5. Click Configure to display the Assignment entry window.
2.
7.
ASSIGNMENT SCENARIO PARAMETERS

LABEL
Flow estimation
Name of the reference flow estimation scenario.
Assignment network
Name of the network on which to assign the flows in the flow estimation flow scenario.
Theta
Maximum iterations

Maximum paths
143
DESCRIPTION
Spread %
Before Assignment
This field is optional.

Executable file, which is executed after the calculation of the estimation and prior
to the assignment. This is typically a script that alters OD matrices saved in the
directory tmpexport of the flow scenario. The file is also run in the directory
tmpexport after it has been copied.
FLOW MODULE
Fill in the Assignment scenario parameters, page 143.

Click Back.
8. Click Apply to validate the new parameters of the flow scenario.
9. Click Quit to close the entry window.
6.
SSIGNMENT
A
SCENARIO
You must add the Assignment scenario before configuring it, so that the network list on which to
assign an Assignment scenario is updated.
Examine the result of the assignment

The operating principles and the location of the files are equivalent to the estimation flow scenario (see
Examine the results of the estimation, page 138 and Analyze the results of the flow calculation, page 139).
144
SUBNETWORK ASSIGNMENT
SCENARIO
Subnetwork Assignment scenario

It is possible to roughly edit a network solely to calculate flow and path. The goal is to edit a network trajectory in defiance of the conflict management, data collectors, traffic light timeline, etc. Later, if you want
to simulate a subset of this network, it is necessary to expand the model in this area. After each change to the
subnetwork, the path flow across the network must be calculated again (estimation + assignment throughout
the area) before you can simulate this subnetwork. The calculation time of the assignment penalizes the iterative design of a simulation model. The subnetwork assignment scenario allows, in this case, to limit the calculation time of the demand to the assignment of an OD matrix on the subnetwork to be simulated. The
origins and the destinations of the matrix to be assigned correspond to the inputs and the outputs of the subnetwork. In such a way, we are referring to the contact points between the network and its subnetwork (see
Export-Import scenario, page 124). The subnetwork assignment scenario can also be used to study different
configurations of the same sub-area (new programming of lights, change the geometry etc.).
Put in place a subnetwork assignment scenario:
The steps to update the results of a simulation scenario:
145
FLOW MODULE
1. The input/output supports of the subnetwork belong to the global network (it is recommended to set
them in a frozen layer).
2. The area to be simulated must be continuous and closed (a path on the global network can not enter
and exit more than once the subnetwork).
3. You should be aware that the path flow defined on the global network can be different from the one
defined on the subnetwork (only if the subnetwork includes multi-paths).
S U B N E T W O R K A S S I G N M E N T
SCENARIO
Principle

the paths, page 322
Path flow estimation on network 1
Error messages due to the Estimation,

page 321
Assign the flow on network 2
Calculate the subnetwork OD matrix

Assign it to the subnetwork
Error messages due to the Assignment,

page 321
Error messages due to the Assignment,

page 321
Reference state
Micro simulation
Erreurs pour la rplication courante,

page 435
Figure 84. Schematic diagram of a simulation with an Assignment on a subnetwork flow scenario
A Subnetwork Assignment flow scenario requires the existence of a reference Estimation flow scenario
and an Assignment scenario.
146
SUBNETWORK ASSIGNMENT
SCENARIO
CubeDynasim will update only the data that was changed. During the iterative process of edition of the subarea, the calculation starts with the assignment on the subnetwork.
Create a Subnetwork Assignment flow scenario
1.
3. Select Subnetwork Assignment out of the drop-down list named Type.
4. Click Add before you change the type setting flow scenario-specific settings.
5. Click Configure to display the Subnetwork Assignment entry window.
2.
FLOW MODULE
Fill in the Subnetwork assignment scenario parameters, page 147.

7. Click Back.
8. Click Apply to validate the new parameters of the flow scenario.
9. Click Quit to close the entry window.
6.
You must add the Subnetwork Assignment scenario before configuring it so that the network list on
which to assign an Estimation scenario is updated.
SUBNETWORK ASSIGNMENT SCENARIO PARAMETERS

LABEL
147
DESCRIPTION
Assignment Flow
The name of the Assignment flow scenario applied to network 2. Network 2 is the
field Assignment network, page 143 of the Assignment flow scenario.
Matrix Sub
Network
Subnetwork of the second network from which the OD matrix is extracted (named
subnetwork 2). The supports marking the entrance/exit of this subnetwork define
the set of origin-destination of the subarea to be simulated.
Sub Network
Assignment
Assign the OD matrices extracted from the subnetwork 2 to the subarea to be simulated. The subnetwork 2 and the area to be simulated share the same set of input
and output supports. Inside the contents of the subnetwork 2 and the subarea to
be simulated will be different.
Theta
S U B N E T W O R K A S S I G N M E N T
SCENARIO
SUBNETWORK ASSIGNMENT SCENARIO PARAMETERS

LABEL
Maximum iterations
Maximum paths
Spread %
Before Assignment
DESCRIPTION
This field is optional.
If set, it executes the file before the assignment of the OD matrices (extracted on
the sub-network 2) on the subarea to be simulated. It is generally an executable
file that alters the OD matrices to be assigned.
Examine the result of the subnetwork assignment

The operating principles and the location of the files are equivalent to the estimation flow scenario (see
Examine the results of the estimation, page 138 and Analyze the results of the flow calculation, page 139).
You must check the results for each step of the process.
148
AGGREGATE
Aggregate
The Aggregate flow scenario defines a demand following a suite ordered of time samples sharing the same
duration. Each of these samples is set by one of the flow scenarios and a weighting factor. The demand for a
time sample is calculated according to the flow of its flow scenario. The flow is reduced according to the
length of the sample, and then adjusted by the weighting coefficient.
With the Aggregate flow scenario, it is possible to reproduce the flow variations during the simulation:
either by calculating flow path estimation per time sample (which last at least 30 minutes taking
into account the size of the network), and then aggregating those flow scenarios corresponding to
each counting period.
2. or either by applying different weighting factors on the same flow scenario.
1.
It is worth noting that these approaches do not properly solve the spill back astride traffic counts and extending beyond the duration of the time samples.
FLOW MODULE
149
GGREGATE
A
Create an Aggregate flow scenario:
1.
2.
3.
Select Aggregate out of the drop-down list named Type.
4.
Click Configure to display the Aggregate entry window.
Flow scenario
header
List of
aggregates
Edit zone
Command
zone
5.
6.
7.
8.
9.
Edit the settings displayed in the Edit zone (see "Aggregate flow scenario parameters", fig.
p.150).
Click Add to push back the new edited aggregate to the end of the list.
To add a new aggregate return to step 5.) otherwise, click Back.
Click Add to add the new aggregate flow scenario.
AGGREGATE FLOW SCENARIO PARAMETERS

LABEL
Time sample
Flow scenario
Proportion
150
DESCRIPTION
Duration of the aggregate in minutes. The duration is the same for all aggregates.
This setting is applied to all aggregates.
Flow scenario on which the calculation of the aggregate is based. The flow scenario cannot be of type Generator or Subnetwork.
Percentage of the Flow scenario actually taken into account by the aggregate.
AGGREGATE
It is advisable to create a scenario simulation for each aggregate flow scenario in order to check
any error messages using the GUI. Otherwise, the user must check the errors displaying the files
saved on the hard drive. A flow scenario of type aggregate calculates in parallel each of the flow
scenarios it depends on. If the number of different flow scenarios is important, the system may
spend more time swapping tasks than calculating the different demands. In this case, it is
recommendable to limit the number of flow scenarios calculated in parallel (depending on your
hardware configuration).
FLOW MODULE
151
P A T H S :
VISUALIZATION AND ANALYSIS
Paths: visualization and analysis

For all types of flow scenarios, it is possible to generate graphics files to insert-link in documents, displaying
flow boxes, which quantify directional movements on an area of the network:
"Flow box" (see fig. , page 152)

For flow scenarios of type Estimation, Assignment, Subnetwork Assignment and Export/Import, it is possible to generate files in ShapeFile format illustrating:
Paths on trajectory, page 154,

Scenario comparison, page 155.
Flow box
CubeDynasim can be used to generate, from the traffic calculation, images defined by the user in which the
various directional movements are represented based on Traffic counts, page 126 objects, for which the
Generate box option is selected. The number of images generated by the simulation scenario is unlimited.
Create an image frame:
1.
2.
3.
4.
5.
6.
Open the Traffic box entry window from the Menu bar, page 14: Report > Flow box.
Adjust the size of the main window so that it matches the size of the snapshot image.
Position the edit area to view the part of the network in which to display the traffic (e.g. a crossroads).
Enter the name of the frame in the entry box.
Click Add to save the frame.
To add a new frame go back to step 2.) otherwise, click Quit.
Flow box files are generated during the reports update of the simulation scenario.The generated files are
image files (eps format) for each frame, type of vehicle, and total flow in PCUs.
These files are saved in the subdirectory of the study: Report / simulation scenario / flow/ boxes. The
names of these files comply with the following convention: [TYPE] _ [title].eps.
152
PATHS:
Image frame
Flow box
entry window
Figure 86. Representation of the directional movements resulting from the flow calculation
Visualizing a flow box
From the Menu bar, page 14, open the Traffic box entry window: Report > Flow box.
2. Select the appropriate name.
3. Click Visualize to display the image area in CubeDynasim without resizing the main window.
1.
153
FLOW MODULE
Figure 85. Definition of a flow box
P A T H S :

Modifying a flow box
Open the Traffic box entry window from the Menu bar, page 14: Report > Flow box.
Select the appropriate flow box name.
3. Resize the CubeDynasim window and adjust the models positioning and zoom factor.
4. Click Apply.
1.
2.
Paths on trajectory
The Paths on trajectory is used to generate layers in ShapeFile format quantifying traffic traveling through
one or more points of the network for all type of vehicles and for all vehicles (expressed in PCUs),
For each type of vehicle and for all vehicles expressed in PCUs,CubeDynasim generates two layers:
a layer with all the origins to the crossing point,

a layer from the crossing point to all the destinations.
Creating a path on trajectory
Proceed as follows to create a path on trajectory (see "Representation of a path on trajectory in CubeDynasim", fig.87 p.155) in CubeDynasim:
1.
2.
Click the
icon on the toolbar to switch to geometric mode.
icon on the Simulation object bar, page 17 to activate create path on trajectory
mode. The mouses cursor is displayed as
Left-click on the origin trajectory to position the crossing point on the path.
4. Fill in the path on trajectory entry window.
3.
Name of the path on trajectory

Storage directory and layer name
5.
6.
Click OK to confirm.
Right-click to finalize the path on trajectory, or left-click on one or more trajectories to add one
or more conditions on the path.
Displaying a path on trajectory

The ShapeFile layers generated can be read by any geographic information system management software.
CubeDynasim generates the results of all path on trajectory in the subdirectory Report / simulation scenario
/ flow / paths.
154
PATHS:
Intermediate points
Path on trajectory with

intermediate points
Initial point
Path on trajectory with
a single crossing point
Figure 87. Representation of a path on trajectory in CubeDynasim
The layers generated (in the subfolder named by the layer parameter in the Path on trajectory entry window)
are:
[TYPE]_IN_[layer] which contains all the links covered by users who proceed via the crossing point
[TYPE]_OUT_[layer] which contains all the links covered by users who proceed via the crossing point
on the path on trajectory (and any intermediate points) up to their various destinations, along with the
flows quantification for the TYPE on these links.
Path on trajectory IN
Path on trajectory
crossing point
Path on trajectory OUT

Figure 88. Representation of the paths on trajectories in a GIS software solution
Scenario comparison
CubeDynasim lets you compare the traffic (the demand) between two simulation scenarios.
155
FLOW MODULE
(and any intermediate points) of the path on trajectory from their various origins, along with the flows
quantification for the TYPE on these links.
P A T H S :

Proceed as follows to define a traffic comparison using CubeDynasim:
1.
Open the Compare entry window from the Menu bar, page 14: Report > Compare Flows.
Compared
scenario
Reference
scenario
Select the compared scenario in the Simulation 1 list.

Select the reference scenario in the Simulation 2 list.
4. Define the minimal length of a link on the links/nodes network (see The links/nodes network,
page 122) on which the flow comparisons will be calculated.
5. Click Add.
6. Click Compare to calculate the comparison.
2.
3.
The traffic comparison is recalculated as soon as the Report is generated for one of the two simulation scenarios compared.
For two different networks, CubeDynasim calculates the difference between two links that satisfy the Minimal length, that are both within a 3-meter wide range, and that the two links are oriented in the same direction. The comparison is done according to a geometric criterion.
Figure 89. Loading/unloading of the network obtained by comparing scenarios
156
Paths
PATHS
A vehicle is created by a generator which assigns it a destination corresponding to a network exit. The vehicle travels from the origin to its destination along a series of simulation objects connected in pairs. This
series of objects corresponds to the path taken.
The vehicle calculates its path at the entry to a simulation object. If the result of this calculation offers different possibilities, one is chosen according to the following criteria in order of priority:
a
Minimize the cost of the journey,
b. Find an alternative route, if the road network capacity is exceeded.
Whatever the criterion for calculating the path, CubeDynasim prohibits a vehicle from crossing a link on the
link/node network that has already been taken. In other words, CubeDynasim prohibits looping.
The definition of the paths serves to limit the possible series of objects covered by the vehicles to reach
their destination. This definition involves the following two steps:
Editing of possible sequences of simulation objects, whatever the vehicles destination or category. This sequence is usually directly deduced from the geometric configuration of the objects.
2. Restricting possible series of objects when traveling across the network, according to the vehicles
destination and/or category.
1.
This chapter describes:
the Links, page 158 that define the sequences of simulation objects,
the Prohibitors, page 168 used to edit restrictions according to the vehicle destination and/or category,
the Lane change distributions, page 185 which control lane changes.
157
L I N K S
Links
A link establishes a connection between two simulation objects. For example, a vehicle present in the first
object can continue on its way by taking the second object. In other words, if there is no link between two
objects, the vehicle is not allowed to pass from one object to the other. The different types of simulation
objects that can be connected by a link are as follows :
Origins, page 69: origin only.
2. Stages, page 71: origin and destination.
3. Lanes in Trajectories, page 81.
1.
Links are represented/edited in logical mode in Network edit area, page 19 of the main CubeDynasim
window (see "Main CubeDynasim window in logical mode", fig.2 p.14). A link not pointed to by the mouse
is always represented by an association of segments, where the last segment ends with a green or blue arrow,
depending on the type of link, pointing to the destination object (see "Representation of links in logical
mode", fig.90 p.158). The link generally comprises a single segment. The direction of the arrow is not always
visible depending on the scale factor used to display the logical representation of the simulation objects in
Network edit area, page 19. However, the logical representations of connected objects make it possible to
easily distinguish the origin of the link and its destination. A link has no representation in geometric mode
because there is no physical size associated with a link.
With curve objects, the link is automatically generated in the handle if the link option in the "Handle entry
window" (see fig. 48, page 86) is enabled.
Lane 1 link to exit

Lane 3 link to exit
Stage link to trajectory
Origin link to stage
Figure 90. Representation of links in logical mode

Links are simulation objects that do not reference a layer (see Layers and network scenarios, page 61). However, unlike Origins, page 69, Stages, page 71, and Destinations, page 74, links do not appear in
all the network scenarios. Whether or not a link belongs to a network scenario is determined by whether all
the simulation objects - the links origin and destination(s) - belong to the same scenario.
In a project, you must not create two same-type links with the same origin and the same first
destination.
You must not edit a link which would have the same simulation object as its origin and destination.
158
LINKS
This chapter is split into three parts which describe the three types of links available in CubeDynasim:
Speed link, page 159,

Split link, page 160,
Split link by PCE, page 165.
Speed link
The speed link connects a single origin to a single destination. The links speed percentage is used to impose
a speed limit on vehicles using it. The speed limit is equal to the vehicles absolute maximum speed,
weighted by the speed percentage associated with the link. The vehicle modifies its speed to pass the link
while respecting this speed limit, or failing this, by getting as close to it as possible according to its motional
capacities. While a number of motional conditions apply to a vehicle taking a speed link, the most constraining condition is the one applied to the passing of the link. The motional constraint imposed by the destination
simulation object is not taken into account by the vehicle when it passes the link. The drop in speed between
two single lane simulation objects is generally determined by the angle formed by the connected segments of
the two lanes.
Except for exceptional configurations, modeling by handles/trajectories no longer requires you to use speed
links for the concatenation of trajectories. Moreover, the speed at the trajectorys origin/destination is defined
as one of the trajectorys parameters (see Vehicle network, page 80).
1.
p.14).
2.
Click the
button on the Simulation object bar, page 17 to activate create speed link mode.
In the Network edit area, page 19, click the object at the origin of the link.
To create a link comprising a number of segments, position the cursor and left-click to validate the
segments position.
5. Repeat step 4) until you reach the last segment to create.
6. Right-click on the links destination simulation object.
3.
4.
Editing a speed link

Editing or deleting a speed link is done in logical mode following the procedure described in section Edit
To improve the models readability, you can modify the aspect of the link displayed by moving the logical representations of its origin and/or destination, or, if it is made up of several segments, by modifying the
position of the intermediate points that define the segment. For this purpose, switch to logical mode and proceed as follows :
Select the link by following the procedure to select a simulation object, page 21.
Position the cursor on the handle to be moved (see "2-segment speed link in the selected state",
fig.91 p.160).
3. Keeping the left mouse button pressed, drag the handle to the new position.
4. Release the button when the handles new position is where you want it to be.
5. Deselect the link by following the procedure to deselect an object or multiselection, page 21.
1.
2.
You cannot move a link in the same way as you would move a simulation object (see move a simulation
object on the background map, page 21).
You cannot edit or delete a speed link if it links two objects placed in frozen layers.
159
PATHS
Creating a speed link
L I N K S
Handle
Selected link
Origin single lane
Destination single lane
Figure 91. 2-segment speed link in the selected state
To modify the speed links parameters, you must display the links entry window (see "Speed link entry
window", fig.92 p.160), following the procedure Edit modes, page 13. The value of the Speed percentage field is between 0.001 and 1.0. The Prohibitor OR and Prohibitor AND fields are used to modify the
value of the Prohibitor OR and the Prohibitor AND respectively, in accordance with the operation of a Prohibitor field, page 171.
Figure 92. Speed link entry window
Split link
Edited in the CubeDynasim Network edit area, page 19, the split link actually groups together two links
called the split link and the forward link. You can only distinguish these two links in link edit mode when
defining their Prohibitors, page 168.
The forward link is a Speed link, page 159.
The split link is a speed link that establishes a connection between an origin and a set of N possible destinations, where N is greater than or equal to 2. A condition is associated with each possible destination. The
value of this condition varies during the simulation. The selected destination corresponds to the value of the
most reliable condition, evaluated the moment the vehicle enters the origin object. A condition applies to an
nonempty set of simulation objects, called condition objects. The conditions value at instant t is equal to the
sum of the weighted number of vehicles present in the condition objects. The weighting is specific to each
condition object.
This section describes the split link as follows:
160
Representation of a split link in logical mode, page 161,

Creating a split link, page 161,
Editing a split link, page 161,
Use of the split link: Example 1, page 162,
Use of the split link: Example 2, page 165.
LINKS
Representation of a split link in logical mode
The split links representation in logical mode consists of a blue arrow pointing from the logical representations of the origin simulation objects to the links first possible destination. When your cursor is positioned
on this arrow, the link between the origin and the first destination is represented by a yellow arrow, and the
links pointing to the other destinations by blue arrows (see "Representation of a split link in logical mode",
fig.93 p.161).
2-destination split link

Destination 2
Destination 1
Origin object
Figure 93. Representation of a split link in logical mode
Creating a split link
p.14).
2. Edit the handle to disable the link option.
1.
Click the
4.
In the Network edit area, page 19, click the links origin object.
Add a destination:
5.
. icon on the Simulation object bar, page 17 to activate create split link mode.
Left-click the logical representation of the destination object; if it is a lane in a multilane or a single
lane, click the triangle at the end of its representation.
b. Add a condition to this destination, by pointing to the condition objects logical representation and
left-clicking: if it is a lane in a multilane or a single lane, click indifferently on either of the triangles
at the start or end of it.
a
c. To add a condition, repeat step b.), otherwise finish the entry of your conditions by right-clicking.
6.
7.
Add at least one second destination by repeating step 4.),

Finish by right-clicking in the network edit area.
By default, the all conditions have the same weighting value on creation of the link. To modify this value,
you must edit the split link.
Editing a split link
To edit a split links parameters, in logical mode, follow the procedure described in section Edit Object
mode, page 20, to display its entry window (see "Split link entry window", fig.94 p.162).
161
PATHS
3.
L I N K S
Figure 94. Split link entry window

The Speed percentage for link field applies to all the split links possible connections. You cannot, therefore,
differentiate the vehicles speed from their calculated destination.
In the "Split link entry window" (see fig. 94, page 162), you can weight the condition objects. There are as
many fields as there are condition objects. The name of each field takes the following format: Destination
destination object no. i Weight for condition object no. j. The value entered is a real value greater than
0. The weighting value can be used to model a concentration of vehicles rather than just a number of vehicles. In this case, the weightings must be proportionate to the reverse of the length of the condition object
they relate to.
The Prohibitor OR Split Link by Vehicles and Prohibitor AND Split Link by Vehicles fields both correspond to a Prohibitor field, page 171 used to respectively define the Prohibitor OR and the Prohibitor
AND of the split link.
Similarly, the Prohibitor OR forward and Prohibitor AND forward fields are used to define the forward
links prohibitors.
You cannot edit or delete a split link if the linked objects are all placed in frozen layers.
Use of the split link: Example 1
The split link is used to model turning movements where vehicles come alongside one another. Here, since
the length of the lane modeling the turning movements is usually reduced, changing lanes does not enable
you to take account of this cluster of vehicles. Using concrete examples, we will describe two modeling techniques implementing the split link.
Split links are often used to model an intersection regulated by traffic signals, where a special phase is not
provided for left-turn movements (see "Example 1: Left-turn movement cleared in the clearance time", fig.95
p.163).
To model the junction in figure 95, page 163: you draw the trajectories of the various possible movements
at the junction. Here we will focus on the left turn movement towards the top of figure 96, page 164. This
162
LINKS
Figure 95. Example 1: Left-turn movement cleared in the clearance time
In this example presenting a crossroads with signals, the trajectories modeling antagonistic movements can
overlap. For example, the red single lanes corresponding to the left-turn movement overlap on the green trajectories going from the bottom towards the top of the figure. However, you are generally advised against
overlapping the different trajectories.
163
PATHS
movement is modeled by a series of single lanes in red. It ends with a fork where each branch corresponds to
a waiting zone for vehicles yielding straight ahead. The choice of one or other of the forks branches is made
depending on a condition that translates the number of vehicles present in each branch. The single lane corresponding to the decision on the best destination is short, since the decision must be made as closely as possible to the two branches of the fork. Furthermore, in geometric mode you must edit the Yield, page 206
rules to deal with trajectory conflicts between the priority forward movement and the left turn movement.
L I N K S
Forward movement
Priority movements
Priority rule for
conflicting trajectories
Destination 2
Destination 1
Origin object of the split
link (decision making object)
Left turn movement
Figure 96. Example 1: Geometric view of the modeling of a permissive left turn movement
Forward movement
Destination 1
Destination 2
Split link
link (decision making
object)
Figure 97. Example 1: Logical view of the modeling of a permissive left turn movement
164
LINKS
Editing the model in logical mode consists in describing the sequences of trajectories (see "Example 1: Logical view of the modeling of a permissive left turn movement", fig.97 p.164):
Creating a split link, page 161 whose origin is the decision-making object, and with two destinations corresponding to the two branches of the fork. Destination no. 1 and destination no. 2 have
a single condition object corresponding to destination no. 1 and destination no. 2 respectively.
2. Continue by Editing a split link, page 161, and, using the Prohibitor OR forward field, define a
prohibitor on the forward link for all the vehicles.
1.
Use of the split link: Example 2

The purpose of example 2 is the modeling of a crossroads regulated by traffic signals where left turn movements are cleared in the gaps left by oncoming traffic, and in the clearance time. It involves an Indonesian
left turn, following the illustration in figure 98, page 165. The modeling technique used in this case differs
from that in example 1 through the use of the forward link associated with the split link.
PATHS
Figure 98. Example 2: "Indonesian" left turn movement

As with example 1, you edit - in geometric mode - the trajectories taken by the vehicles. In particular, you
will represent the turning movement coming from the right and heading to the top of figure 98, page 165.
The turning movement is done in two lanes, with a lane reduction to one lane on exiting the intersection. The
trajectories are the sand-colored single lanes. As with the editing of the model in example 1, you deal with
trajectory conflicts usingYield, page 206 rules.
Editing the logical model is much the same as that in example 1. However, the fundamental difference with
example 1 that justifies the use of the forward link is the fact that the split links origin object is taken indifferently by vehicles assigned to the forward and left-turn movements. Once you have created the split link,
you must edit it to define the prohibitor on the forward link for all vehicles turning left, and conversely
define the prohibitor on the split link for all vehicles moving forward (i.e. straight on) (see "Example 2: Logical view of the modeling of an "Indonesian" left turn", fig.100 p.166).
Split link by PCE

The split link by PCE is a Split link, page 160 where the conditions are evaluated on the basis of the sum
of the lengths of the vehicles present in the condition objects, rather than the actual number of these vehicles.
With a split link, the condition evaluated with a truck and a light vehicle gives the same value as two light
vehicles, whereas with a split link by PCE, the two situations are differentiated.
165
L I N K S
Priority movements
Priority rule for

conflicting trajectories
Destination 2
Destination 1
link (decision-making object)
Figure 99. Example 2: Geometric view of the modeling of an "Indonesian" left turn
Destination 2
Destination 1
Split link
Origin object of the split link
(decision-making object)
Figure 100. Example 2: Logical view of the modeling of an "Indonesian" left turn
There is no distinction between the logical mode representations of a split link and a split link by PCE. You
can only distinguish them by the header of the message displayed in the information area when your cursor
is positioned on the links logical representation. For a split link, the message starts with Split link, and for a
split link by PCE, the message starts with Split link by PCE.
To create a split link by PCE, follow the same procedure as for Creating a split link, page 161 by selecting the following in step 2.):
a
either in Menu bar, page 14, select Objects > Links > Split link by PCE,
b. or in Button
bars, page 15, in the links category, click the Split link by PCE
that the icon is the same as that of the split link; only their labels differ).
button (note
You edit a split link by PCE in the same way as for a split link (see Editing a split link, page 161).
166
LINKS
In the case of a network entry defined by the sequence of Origins, page 69, Stages, page 71,
then by a trajectorys path, you must edit two links. A first link from the origin to the stage, then a
second link from the stage to the simulation object (see "Two links required to define a network entry
with a stage", fig.101 p.167). By moving the stage, you ensure that it is connected to the other network
elements if the end of the logical representation of its links follow it.
Poor modeling
A single link
All the objects

are connected
Figure 101. Two links required to define a network entry with a stage
167
PATHS
Stage to lane 2 link

Origin to stage link
P R O H I B I T O R S
Prohibitors
A prohibitor is used to forbid a vehicle from traveling in the network, entry or exit of a simulation object
according to its category and/or destination. The prohibitor is used to force certain paths and, in some
cases, to give preference to - or restrict - a type of trajectory.
A prohibitors parameters are a subset of categories corresponding to the categories selected, and a subset
of Destinations, page 74, corresponding to the selected Destinations, page 74 or Zones, page 75.
These two subsets can be empty.
Prohibitors are applied to the following simulation objects: Links, page 158, and lanes in Trajectories, page 81.
A vehicle satisfies a prohibitor according to two criteria concerning its category and its destination (see
Destinations, page 74).
If a vehicle does not satisfy the prohibitor applied to a trajectory with a single lane, to all the lanes in a multilane or to a link, it cannot take them on its journey through the network to reach its destination. If a vehicle
does not satisfy a prohibitor applied to a lane in a multilane, it can enter or partially travel along this lane, but
it must quit the multilane by another of its lanes for which it satisfies the prohibitor.
This section describes :
The different types of prohibitors, page 168,

the two methods for assigning a prohibitor to a simulation object with :
an Invalid paths, page 168,

a Prohibitor field, page 171.
The different types of prohibitors

All vehicles satisfy any type of prohibitor if none of the prohibitors destinations and vehicle categories are
selected.
There are two types of prohibitor: the Prohibitor AND, and the Prohibitor OR.
A vehicle does not satisfy a Prohibitor AND if its destination is one of the exits selected (or a group of exits
in a zone) for the prohibitor, and if its category is one of the categories selected for the prohibitor.
A vehicle does not satisfy a Prohibitor OR if its destination (or a group of exits in a zone) or its category is
one of the exits/categories selected.
Invalid paths
The AND and OR prohibitors on an invalid path are applied to all the simulation objects likely to be prohibited and which cross the graphic representation of the invalid path.
The invalid path is a simulation object edited in geometric mode. Its graphic representation is only displayed
icon, and a marker
in the Network edit area, page 19 in geometric mode. It is represented by the
defined as a series of joined straight line segments (see "Representation of invalid paths in geometric mode",
fig.102 p.169). Prohibitors are defined on the simulation objects that cross the invalid path marker.
168
PROHIBITORS
Invalid path applied to the

paths single lane
Single lanes affected by an

invalid path
Invalid path applied to one lane in a
multilane trajectory
(green)
Figure 102. Representation of invalid paths in geometric mode
Creating an invalid path

1.
fig.1 p.14).
Click the Invalid path

icon on the Simulation object bar, page 17 to activate create
invalid path mode.
3. In the Network edit area, page 19, click at the spot where you want to see the invalid path icon
to display the "Invalid path entry window" (see fig. 103, page 170).
4. Fill in the fields :
a Layer which is a Single-choice list field, page 32 used to assign the layer to the invalid path.
b. Prohibitor OR and Prohibitor AND both represent a Prohibitor field, page 171 used
respectively to define the Prohibitor OR and the Prohibitor AND applied to the objects that cross
2.
the invalid path.

c. Width to define the width, in geometric mode, of the invalid paths straight segments;
0.5 meters represents a good compromise.
Color field, page 31.

5. Click OK to validate the objects parameters and to position the invalid path segments.
6. Position the cursor at the end of the segment created, then:
d.
to add a new segment, left-click and repeat step 6.)
b. right-click to finish the entry.
169
PATHS
Invalid paths belonging to a layer can be associated with network scenarios to simulate the effect of
different variants of the path.
Figure 103. Invalid path entry window

Editing an invalid path
As with Road network, page 79, objects, you can edit the parameters and geometry of an invalid path, but
To display the invalid path entry window in order to modify its parameters, follow the steps to delete or
modify a simulation object, or place it in the background or foreground, page 21.
To modify the geometry of an invalid path, select the object by following the procedure to select a simulation object, page 21. Position the mouses pointer on a handle, left-click and, keeping the button pressed,
drag it to the appropriate position (see "Invalid path in the selected state", fig.104 p.170).
Handle
Segment
Icon
Figure 104. Invalid path in the selected state
Use a single invalid path to prohibit a set of trajectories: to do so, you edit a single simulation object
when updating the associated prohibitors, for example, when modifying the number of
Destinations, page 74.
170
PROHIBITORS
Prohibitor field
You can define prohibitors on a certain number of simulation object categories (see Paths, page 157). The
prohibitor field is represented by a button identified by Prohibitor AND or Prohibitor OR, corresponding to
the type of prohibitor entered. Proceed as follows to define the prohibitors associated with an object from its
entry window :
Left-click the appropriate prohibitor button to display the prohibitor entry window (see "Prohibitor field as it appears in a simulation object entry window", fig.105 p.171),
2. The prohibitor entry window contains two multi-choice list fields corresponding to the Destinations, page 74 (Destinations), and to the vehicle categories (Category). Depending on the number of exits defined for the project, the destinations field is displayed directly in the prohibitor
entry window or in a window with a scroll bar (see "Prohibitor entry window", fig.106 p.172). The
multi-choice list contains the labels and their corresponding checkboxes. A checkboxs status is
either selected or unselected. You change statuses by left-clicking in the box. Three buttons are
associated with a multi-choice list to modify the status of all the lists checkboxes. By left-clicking
on the button in a multi-choice list:
1.
b.
, you select all the checkboxes

, you reverse the selection/deselection of the checkboxes
c.
, you deselect all the checkboxes
If a Destinations, page 74 object is created, it is added to the list of destinations of all the prohibitor
fields whose status is unselected. Similarly, if a public transport line is created, its corresponding
destination is added to the list of possible destinations with the unselected status (see Public transport
module, page 271).
Prohibitor AND button

Figure 105. Prohibitor field as it appears in a simulation object entry window
171
PATHS
Select the exits and categories to take into account in the definition of your prohibitors by selecting their corresponding checkboxes.
4. Click OK to validate the selection and go back to the simulation object entry window.
3.
List of zones
List of destinations
List of categories
Figure 106. Prohibitor entry window
172
MP
PROHIBITOR
MP prohibitor
A MP prohibitor is defined by an entry marker and a non-empty set of exit markers. A marker of a MP prohibitor applies to all the trajectories of a multilane from the moment it crosses one of its lanes. Paths are forbidden if they cross the entry marker and one of the outputs marker of a MP prohibitor.
Creating a MP prohibitor
1.
fig.1 p.14).
Click the
icon on the Simulation object bar, page 17 to activate Create MP prohibitors
mode.
3. In theNetwork edit area, page 19, click on the trajectory where you want to position the entry
to the MP prohibitor to display the "Invalid path entry window" (see fig. 103, page 170).
a Layer which is a Single-choice list field, page 32 used to assign the invalid path layer.
b. Prohibitor OR and Prohibitor AND both represent a Prohibitor field, page 171 used
2.
d. Color field, page 31.

Click OK to validate the objects parameters.
6. Left click on the trajectories to position the exit markers of the MP prohibitor.
7. Complete the entry by right-clicking in the edit zone.
5.
Editing a MP prohibitor
An MP prohibitor can only be edited in geometric mode.
To display the MP prohibitor entry window, follow the steps as described in the section for delete or modify
a simulation object, or place it in the background or foreground, page 21.
To modify the MP prohibitors geometry:
Select the object by following the procedure for select a simulation object, page 21.
2. Position the mouses pointer on a handle.
3. Left-click and drag it to the appropriate position (see "Invalid path in the selected state", fig.104
p.170).
1.
173
PATHS
respectively to define the Prohibitor OR and the Prohibitor AND applied to the objects that cross the
MP prohibitor.
c. Width to define the width, in geometric mode, of the invalid paths straight segments;
0.5 meters represents a good compromise.
L A N E
CHANGES
Lane changes
There are two types of situations that lead to a lane change :
A lane change imposed by the path the vehicle takes to reach its destination, conditioned by
Insertion gaps, page 175.
2. A lane change due to the vehicles behavior, usually conditioned by Behavior associated with
lane satisfaction, page 176 and Insertion gaps, page 175.
1.
At the entry to the network, a vehicle must respect a minimum distance of 20 meters or a travel time of
3 seconds before changing lanes.
CubeDynasim lets you configure the lane change possibilities available to each vehicle depending on its
destination and on present traffic conditions via the following:
Insertion gaps, page 175, which determine whether the vehicle will be able to change lanes depending on the traffic in its target lane
Behavior associated with lane satisfaction, page 176 defined by :

Current lane satisfaction, page 178, which determines whether or not a vehicle is satisfied with
the traffic conditions in its lane.
Target lane satisfaction, page 180, which determines whether a vehicle wants to change lanes
depending on the traffic in an adjacent lane.
You use the Behavior definition window, page 177 to create or edit the lane change parameters used to
define the behaviors.
To access the Lane Changing Parameters entry window, page 175, click the Multilane menu on the
Menu bar, page 14, select Behaviors then Lane change configuration.
In the Lane Changing Parameters entry window, page 175, you can define :
a custom name
a configuration type
the configuration types parameters:
parameters for Insertion gaps, page 175,
parameters for Current lane satisfaction, page 178,
parameters for Target lane satisfaction, page 180.
174
LANE
CHANGES
PATHS
Figure 107. Lane Changing Parameters entry window
Insertion gaps
A vehicles that wants or needs to change lanes must make sure, in terms of safety, that the vehicles in front
and behind in its target lane are at a sufficient distance from its front and rear bumpers. This is done using lag
and lead insertion gaps to be edited in the "Multilane trajectory entry window" (see fig. 51, page 89), and
which apply to the target lane for vehicles wanting to change lanes.
Lag insertion gap
Lead insertion gap
Target lane
Current lane
Figure 108. Lag and lead insertion gaps

The calculated acceptable gap distances depend on:
the instant speed of the vehicle in the current lane V (t),

the speed of the vehicle in the target lane Vc (t).
The minimum acceptable gap for changing lanes is given by:
175
L A N E
CHANGES
G t = exp C 1 + C 2 Max 0 V c t V t + C 3 Min 0 V c t V t + C 4 n + N 0 C 5
where:
C1 : Constant
C2 : positive speed differences parameter (dV +), i.e. the difference between the instant speed of the vehicle in the current lane V (t) and the speed of the vehicle in the target lane Vc (t),
C3 : negative speed differences parameter (dV -), i.e. the difference between the instant speed of the vehicle in the current lane V (t) and the speed of the vehicle in the target lane Vc (t),
C4 : aggressiveness parameter associated with a random selection n which serves to reflect different
types of driving,
C5 : standard deviation of the normal distribution centered on 0 (normal AND).

You can edit these parameters in the Lane Changing Parameters entry window for current lane satisfaction, page 179.
Behavior associated with lane satisfaction

A lane change not imposed by a vehicles destination depends on the lane satisfaction in the current and adjacent lanes.
The behaviors for lane changes in relation to lane satisfaction are defined in the Behavior entry window,
page 178 via ordered lists of probability pairs :
Current lane satisfaction, page 178,

Target lane satisfaction, page 180.
The behavior assigned to a lane in a trajectory will define the conditions in which the vehicles concerned will
want to move to the target lane. In fact, if a vehicle does not satisfy the lane satisfaction condition on its current lane, but satisfies this condition on the target lane in the first set on the list, it will change lanes, provided
the target lanes Insertion gaps, page 175 allow it to. Otherwise, it will perform the same test with the
next set - if one exists; if not, it will stay in its lane.
You use the Behavior definition window, page 177 to create, edit or delete behaviors. It contains :
a list of behaviors,
an edit area to access the name of the behavior.
176
LANE
CHANGES
List of
behaviors
Name of the
behavior
To define a behavior, open the Behavior definition window, page 177 from the Menu bar, page 14 by
selecting Multilane > Behaviors > Define Behaviors, then :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Give the behavior a name in the Name field.

Click Add to add this behavior.
Click Next to access the Behavior entry window, page 178.
Select the target lane.
Select the Target lane satisfaction, page 180 in the drop-down list.
Select the Current lane satisfaction, page 178 in the drop-down list.
Click Add to add a behavior set.
Repeat from step 3 as many times as necessary.
Click Back to go back to the Behavior definition window, page 177.
Click Apply to confirm the creation of the behavior.
You are strongly advised against modifying the default behaviors. Instead, create new behaviors and
modify their parameters.
177
PATHS
Figure 109. Behavior definition window
L A N E
CHANGES
List of sets
Target lane
Satisfaction
conditions
pair
Figure 110. Behavior entry window

Current lane satisfaction
The current lane satisfaction property defines whether or not the vehicle is satisfied in its current lane. The
level of dissatisfaction with the traffic conditions is represented by a probability based on :
the instant speed of the vehicle V (t),

the desired maximum speed of the vehicle Vl (t).
The probability that a vehicle is not satisfied with the traffic conditions in its current lane is expressed as follows:
1
P t = ---------------------------------------------------------------------------------- C 1 + C 2 V t V l t + C 3 PL + C 4 PA
1+e
where:
C1 : a Constant.
C2 : a dV maximum parameter relative to the difference between the instant speed of the vehicle V (t)
and the desired maximum speed of the vehicle Vl (t).
C3 : an HV penalty parameter, used for vehicles whose length in m exceeds the threshold specified in the
Heavy thr field.
C4 : a tailgate parameter (TG) relative to the distance between the vehicle and the vehicle directly behind
it, used for vehicles whose speed is greater than the tailgate speed threshold specified in the Speed thr
tail field.
A lane change speed threshold (Speed thr) below which vehicles will not want to change lanes.
178
LANE
and:
PL = 1
Heavy Thr field, else
PA = 1
less than 10 m, else
CHANGES
if the length of the vehicle considered is greater than the value specified in the
PL = 0
if the distance between the vehicle considered and the vehicle directly behind it is
PA = 0
Moreover, by default, if a vehicle is not hindered in its lane (lead vehicle more than 150 m in front), it will
not attempt to change lanes. The Prob of FF change and Prob of HV change (0 by default) parameters serve
to define a probability (between 0 and 1) that a vehicle whose length is less than or greater than the value
specified in the Heavy Thr field will attempt to change lanes.
You can edit these parameters in the Lane Changing Parameters entry window for current lane satisfaction, page 179.
PATHS
List of lane change

parameter values
Name of the selected

parameter value
Type of parameter value
Associated parameters
Figure 111. Lane Changing Parameters entry window for current lane satisfaction
179
L A N E
CHANGES
Target lane satisfaction
The target lane satisfaction property defines whether the vehicle wants to change to an adjacent lane. This is
represented by a probability based on:
the instant speed of the vehicle V (t),

the maximum desired speed of the vehicle Vl (t),
the speed of the lag vehicle in the current lane Vp (t),
the speed of the lag vehicle and of the lead vehicle in the target lane: Vcp (t) and Vcs (t) respectively.
The probability that a vehicle will want to change to the target lane is expressed as follows:
1
P t = ------------------------------------------------------------------------------------------------------------------------------ C 1 + C 2 V p t V l t + C 3 V cp t V l t + C 4 V cs t V t
1+e
where :
C1 : a Constant,
C2 : a Dvfront parameter relative to the difference between the speed the vehicle wants to reach Vl (t)
and that of the vehicle in front Vp (t),
C3 : a Dv lead parameter relative to the difference between the speed the vehicle wants to reach Vl (t) and
that of the vehicle in front in the adjacent lane Vcp (t),
C4 : a Dvlag parameter relative to the difference between the speed vehicle V (t) and that of the vehicle
behind in the adjacent lane Vcs (t).
You can edit these parameters in the Lane Changing Parameters entry window for target lane satisfaction,
page 181.
180
LANE
CHANGES
List of lane change

parameter values
Name of the selected

parameter value
Type of parameter value
Associated parameters
PATHS
Figure 112. Lane Changing Parameters entry window for target lane satisfaction
181
L A N E
CHANGE DISTANCE
Lane change distance

By defining Lane change distance parameters, you specify the time a vehicle takes to change lanes and the
minimum distance required. These distributions are accessible via the Menu bar, page 14, by selecting
Multilane > Lane change parameters.
Creating a lane change distribution

Open the Lane change distance entry window, page 183 to create a lane change distribution.
1.
2.
3.
4.
5.
6.
7.
Give the distribution a name.

Specify the HV Threshold beyond which a vehicle is considered as a long vehicle.
Specify the LV Time values for a light vehicle to change lanes.
Specify the LV Minimum Distance for a light vehicle to change lanes.
Specify the HV Time values for a heavy vehicle to change lanes.
Specify the HV Minimum Distance for a heavy vehicle to change lanes.
You are strongly advised against modifying the default distribution. Instead, create a new distribution
and modify its parameters.
182
LANE
CHANGE DISTANCE
List of lane change

distance distributions
Name
HV critical length
LV parameters
PATHS
HV parameters
Figure 113. Lane change distance entry window
183
C A R - F O L L O W I N G
RULES
Car-following rules
CubeDynasim comes with two predefined car-following rules. You can access their parameters and create
new rules.
184
LANE
CHANGE DISTRIBUTIONS
Lane change distributions

Overview of lane change distributions
Lane change distributions define - via the "Lane change marker" (see fig. , page 190) - the Decision
zones, page 187 inferred by lane changes imposed by the destination, and by the networks geometry.
This section defines the Break points, page 185, required to understand how Decision zones, page 187
work, and how they are defined in the Lane Change Distributions window, page 189.
Break points
Lane changes depend on two types of continuity break points that can appear on the network:
Logical break points
Geometric break points
3. A continuity break point defined by the user (see The break continuity object, page 192)
1.
2.
A geometric lane change is detected in those places where a vehicle has to change lanes to comply with the
networks geometry, marking or the conditions in relation to Invalid paths, page 168.
A vehicles number of lane changes is equivalent to the number of geometric break points that remain for
it to encounter before reaching the next logical breakpoint.
185
PATHS
A logical break point is detected when a vehicle is no longer able to change lanes, or no longer needs to
change lanes in the direction of its initial lane change to reach its destination.
L A N E
2x1 lane change
Origin
Destination
1 lane change
Origin
Destination
2x1 lane change
Origin
Destination
2 lane changes
Origin
Destination
3 lane changes
Origin
Destination
2 lane changes
Origin
Destination
Logical break point

Geometric break point
Figure 114. Examples of logical and geometric break points
186
LANE
Decision zones
Decision zones are defined by two distances (see "EC, MLC and RC distances", fig.115 p.187) going back in
the network from the next geometric break point that the vehicle must encounter on its path. Thus, you must
define the following triplet of numbers:
The Extreme Change (EC) position defines the position of the last point at which the vehicle can
change lanes in relation to the next geometric break point.
2. The Mandatory Lane Change (MLC) distance defines the length of the zone in which the vehicle must change to its target lane before reaching its Extreme Change position.
3. The Restricted Change (RC) distance defines, in relation to the start of the Mandatory Lane
Change zone, the length of the zone in which the vehicle will no longer move away from its target
lane.
1.
There are as many target lanes as there are lane changes to perform to join the target lane. The target
lane is the lane adjacent to the current lane in the direction of the lane change.
EC distances
Logical break point

Extreme Change (EC) position

Mandatory Lane Change (MLC) distance
Restricted Change (RC) distance
Figure 115. EC, MLC and RC distances

If the path implies several lane changes, you must define one triplet per lane. If you do not fill in as many
triplets as there are lanes changed, they will be defined by default based on the trajectorys Lane change
distance, page 182 parameters.
The choice of triplet assigned to a vehicle will correspond to the number of lane changes (or the number of
geometric break points) remaining to be done to reach the next logical break point encountered on its path
(see "Examples of logical and geometric break points", fig.114 p.186).
For example, if the profile applied has 3 triplets (RC1, MLC1, EC1), (RC2, MLC2, EC2), (RC3, MLC3,
EC3), they will be applied to the last lane change, the previous lane change, and the second previous lane
change respectively.
187
PATHS
destination lane
L A N E
Example where 2 lane changes are necessary:
(RC2, MLC2, EC2)

(RC1, MLC1, EC1)
destination lane
Logical break point
ECi position
MLCi distance
RCi distance
Figure 116. Assigning triplets to a profile with 3 triplets for 2 lane changes
(RC3, MLC3, EC3)

(RC2, MLC2, EC2)
(RC1, MLC1, EC1)
destination lane
Logical break point
ECi position
MLCi distance
RCi distance
default triplet assigned

(RC3, MLC3, EC3)
(RC2, MLC2, EC2)
(RC1, MLC1, EC1)
destination lane
Logical break point
In keeping with this logic, you must thus have:
EC1 < EC2 < EC3
188
ECi position
MLCi distance
RCi distance
LANE
In the previous example, there is only one logical break point, the Extreme Change positions required are
thus expressed in relation to the end of a single object. In some cases, for a logical break point, the path can
contain geometric break points on different objects. The following example (in which 3 lane changes are
needed to reach the logical break point, and for which a profile with 3 triplets is applied) shows 3 geometric
break points on 2 different objects:
(RC3, MLC3, EC3)

(RC2, MLC2, EC2)
(RC1, MLC1, EC1)
object 2
destination lane
object 1
Logical break point

Figure 119. Path with geometric extreme lane changes on different objects
To better understand this, it can be a good idea to break the paths continuity in order to have unique markers.
By placing single-lane trajectories at the first geometric extreme change, the paths continuity is broken, giving 2 logical break points. Thus, the same profile is applied as follows:
(RC1, MLC1, EC1)

(RC2, MLC2, EC2)
(RC1, MLC1, EC1)
single lanes
destination lane
Logical break point
Figure 120. Example of a break in a paths logical continuity
Lane Change Distributions window

Use the Lane Change Distributions window, page 190 to define a library of lane change parameters applicable via the lane change marker for the entire model.
To create, edit or delete lane change distributions in the Lane Change Distributions window, page 190,
from the Multilane menu, choose Lane Change Distributions.
189
PATHS
In this example, the Extreme Change positions required for the third (EC1) and second (EC2) lane changes
are calculated in relation to the end of object 1, and the Extreme Change position required for the first lane
change (EC3) is calculated in relation to the end of object 2.
L A N E
Creating a lane change distribution:
Proceed as follows to create a lane change distribution:
1.
2.
3.
4.
5.
Open the Lane Change Distributions window, page 190.

Fill in the Name field.
Click Next to go to the distribution parameters.
List of defined
lane change
distributions
Name of the
lane change
distribution
Figure 121. Lane Change Distributions window

Defining a lane change distribution
To define a lane change distribution, open the Lane Change Distributions window, page 189, select the
distribution to define, or create a new one (see Creating a lane change distribution:, page 190), then click
Next. In the Lane Change Distributions entry window, page 191 displayed, define the profiles of the lane
change distribution and their respective weights.
Proceed as follows to define a lane change profile :
Fill in the Weight field to specify the profiles weighting.
2. Define the profiles RC, MLC and EC distances.
3. Confirm either by
1.
clicking Add to create a new profile.

b. clicking Apply to modify the selected profile.
a
To define an additional lane change, repeat steps 1 and 2, then click + Lane to add this lane
change.
5. Repeat steps 1 to 4 as appropriate, then click Back.
6. Click Apply or Add in the Lane Change Distributions window, page 190.
4.
Lane change marker

The lane change marker is used to modify the lane change zones of the vehicles that cross it on their path.
190
LANE
List of profile associated

with a weight
Next-to-last lane change
Last lane change
Lane change parameters
Add/Remove lane
changes
Add a profile
Figure 122. Lane Change Distributions entry window
The lane change markers lane change parameters are applied until :
1.
2.
The vehicle exits the simulated network.

The vehicle crosses another lane change marker.
The marker is a simulation object that you edit in geometric mode. Consequently, it is only displayed in geometric mode in the Network edit area, page 19. It is represented by the
icon and a series of line segments.
Creating a lane change marker
Proceed as follows to create a lane change marker:
1.
fig.1 p.14).
Click the Lane Change Marker

button on the Simulation object bar, page 17 to activate
create lane change marker mode.
3. In the Network edit area, page 19, click the location where you want to place the lane change
marker. This displays the "Lane change marker entry window" (see fig. 123, page 192).
4. Fill in the fields:
a Layer, a Single-choice list field, page 32 to assign the invalid path layer.
2.
b. Conditions, displays the list of zones, destinations and categories to associate with the weaving
parameters.
c. Choose a Lane Change Distribution from the list (see
Lane Change Distributions window,
page 189).
d. Width, defines the thickness of the invalid paths line segments in geometric mode.
e. Color field, page 31.
Click OK to confirm the parameters and position the segments.
6. Position the pointer at the end of the segment created, then:
5.
f.
Left-click and start step 6 again to add a new segment.
g. Right-click to finish the entry.
191
PATHS
The lane change marker affects vehicles depending on their destination or category.
L A N E
Figure 123. Lane change marker entry window

Editing a lane change marker
The procedure for editing a lane change marker is similar to that of a invalid path (see Editing an invalid
path, page 170).
MP Lane Change Marker

The MP Lane Change Marker is used to modify the lane change zones of vehicles that proceed via its entry
and one of its exits.
The MP Lane Change Marker assigns the vehicles by category.
The MP Lane Change Marker's lane change parameters are applied until:
1.
2.
The vehicle exits the simulated network.

The vehicle crosses another lane change marker.
The MP Lane Change Marker is a simulation object that you edit in geometric mode. Its graphic representation is displayed in the Network edit area, page 19 in geometric mode only. It is represented by the
icon and a marker defined as a series of line segments.
The break continuity object

The break continuity object reinitializes the number of lane changes to 0. It will usually have to be used at an
intersection's exit on multilane sections so that vehicles don't have to assign themselves in the intersection
depending on their path in the next intersection.
192
LANE
Creating a break continuity

Proceed as follows to create a break point :
1.
fig.1 p.14).
Click the Break Point

button on the Simulation object bar, page 17 to activate create break
point mode.
3. In the Network edit area, page 19, position the mouses cursor at the spot where you want to
place the break point on the trajectory.
a Layer, a Single-choice list field, page 32 to assign the layer.
2.
b. Width, defines the thickness of the line segments in geometric mode.

5.
c. Color field, page 31.

Click OK to confirm the parameters and to finish editing the object..
PATHS
Figure 124. Break continuity entry window
VMS
The route of the vehicles can be altered during a simulation according to certain conditions and for a certain
time.
At a given point on the network, the users are warned of a change of path. Only vehicles that usually take the
object marked "prohibited" and that can reach their destination via a path that takes the object marked "recommended" will change paths for the time during which the VMS is activated. You can also reduce this set
of vehicles by only taking a percentage of them.
193
L A N E
Proceed as follows to create a VMS object :
1.
fig.1 p.14).
2.
Click the
icon on the Simulation object bar, page 17 to activate create VMS mode.
In the Network edit area, page 19 click on the trajectory on which you want to assign the
change of route in the "VMS entry window" (see fig. 125, page 194),
a Layer, a Single-choice list field, page 32 used to assign the layer.
3.
b. Starting hour: the possible start time of the change of route.

c. Ending hour: the end time of the change of route, i.e. the time of the return to the default route.
d. Inactive message: message displayed outside the period specified by the start and end times.
e. Active message: message displayed during the period specified by the start and end times.
Percent of vehicles affected: percentage of the vehicles that will change routes.
g. Conditions.
h. Width, defines the thickness of the line segments in geometric mode.
f.

5. Click OK to confirm the parameters and position the segments.
6. Left-click on the trajectory of the path to prohibit.
7. Left-click on the trajectory of the path on which to transfer the traffic.
i.
Figure 125. VMS entry window
194
LANE
Old path prohibited while the VMS is activated

New path while the VMS is activated
Change of path applied

Figure 126. Example of how to use the VMS
PATHS
195
L A N E
196
10
Managing conflicting trajectories
Two trajectories conflict if they cross one another, or if they share the same target trajectory. In the real
world, the road user will avoid another vehicle and, consequently, an accident, by respecting the highway
code which lays down the rules to follow regarding a given road sign or the approach to an intersection, for
example. In CubeDynasim, managing conflicting trajectories amounts to modeling the behavior of the road
user applying these rules in the modeled developments environment. This aspect of the modeling is all the
more important given that it will necessarily constrain the way the development works according to the likelihood of vehicles slowing down or stopping to avoid a conflicting situation. This likelihood is also determined by the quantification of the movements, i.e. the hypotheses formulated when establishing the flows
(see Flow module, page 109).
To model conflicting trajectories, CubeDynasim includes priority rules that define a position on a single
lane, or a lane in a multilane, where the vehicles must stop according to the conditions established on other
objects in the network. If the condition is not satisfied, the nearest vehicle stops at this position if its state and
motional capacities allow it to do so, otherwise it continues on its way while issuing a Simulation warnings, page 419, in which case it is the vehicle following it that must try to stop.
Priority rules are simulation objects that are edited in the Network edit area, page 19 in geometric mode.
197
MANAGING
CONFLICTING
TRAJECTORIES
When you come to edit your trajectories, as described in the chapter entitled Road network, page 79, you
will usually need to deal with conflicting movements. This is confirmed when viewing the animation of the
first simulation results: an animation where the vehicles drive on top of one another will discredit your simulation and minimize its communicative impact.

This chapter describes the following topic:
Gap time distributions, page 199, which are parameters associated with certain priorities
and six priority rules:
198
Stop line, page 202,

Yield, page 206,
Yield-on-green, page 214,
Stop, page 217,
Strict stop, page 219,
Stop-if-stop, page 224,
Stop-on-red, page 228.
GAP
TIME DISTRIBUTIONS
Gap time distributions

Gap time distributions are used to define each vehicle categorys insertion time, and to compile these values
under a single name for a given situation.
The "Gap Time Distribution entry window" (see fig. 127, page 199) comprises:
the list of distributions

a name field
a command area
Creating a gap time

Proceed as follows in the Gap Time entry window to create a gap time distribution:
1.
From the Menu bar, page 14, select Gap Time Distribution to display Gap Time Distribution
entry window, page 199 .
MANAGING
CONFLICTING
TRAJECTORIES
Fill in the Name field.

Click Next to access the distributions parameters.
4. Click Add to create the distribution.
5. Click Quit to close the window.
2.
3.
Distribution
display area
Name
to define
Edit area
Command
area
Figure 127. Gap Time Distribution entry window
199
AP
G
TIME DISTRIBUTIONS
Editing gap time distribution parameters

1.
From the Menu bar, page 14, select Gap Time Distribution to display Gap Time Distribution
entry window, page 199 .
2.
Click the name of the distribution displayed in the Distribution area.

Click Next to display the "Gap Time Distribution parameters entry window" (see fig. 128,
page 200).
Select a type of vehicle displayed in the Display Area.
Fill in the Minimum, Mean, Maximum and Standard Deviation fields.
Click Apply to associate these values with the vehicle category.
Start over from step 4.) to edit another category, or click Return to go back to the Gap Time Distribution entry window, page 199.
Click Apply to confirm your changes.
3.
4.
5.
6.
7.
8.
Display area
Parameters
by category
Edit area
Command
Figure 128. Gap Time Distribution parameters entry window
Traffic circle insertion

The Traffic circle insertion parameters, page 200 table defines, for each vehicle category, the insertion
times defined by default in the traffic circle insertion distribution.
TABLE 1. Traffic
circle insertion parameters
Categories
200
Minimum
Mean
Maximum
Standard
deviation
VL
1.50
1.90
2.50
0.40
PL, TC_STD, TC_ART
2.00
2.50
3.00
0.40
GAP
TIME DISTRIBUTIONS
Left turn across a flow with priority

The Left turn parameters, page 201 table defines, for each vehicle category, the insertion times defined
by default in the turn left distribution.
TABLE 2. Left
turn parameters
Categories
Minimum
Mean
Maximum
Standard
deviation
VL
2.50
3.00
3.50
0.40
PL, TC_STD, TC_ART
3.00
3.50
4.00
0.40
Stop
By default, the insertion times for vehicles at a stop are the same as the values of a left turn across a flow
with priority (see Left turn parameters, page 201). However, it is worthwhile creating distributions with longer times depending on the movement after the stop (right turn, left turn, number of lanes to cross, etc.).
MANAGING
CONFLICTING
TRAJECTORIES
201
S T O P
LINE
Stop line
A stop line is always associated with one or more Signals, page 290. The intersection of the stop line with
the lanes of trajectory objects, or with the waiting zones on a Pedestrian crossings, page 95, determines
the movements regulated by the traffic signal associated with this stop line.
If the signal status is blocking, vehicles in a lane that crosses the stop line will stop at this line; it represents
the stop line as implemented on the roadway.
For a stop line applied to lanes in a trajectory, the stop line does not impose a lane change. Thus, in the case
of the "Stop line and lane change on a multilane" (see fig. 129, page 202), there is a risk that the vehicle will
not respect the traffic signal because a trajectory exists that does not cross any of the intersections between
the lanes and the stop line. However, this lane change is not authorized if the signal is red, and if the length of
the vehicle is greater than L.
Stop line
Vehicles trajectory
L
Multilane
Figure 129. Stop line and lane change on a multilane

If a single stop line crosses one of the two waiting zones on a Pedestrian crossings, page 95, the traffic
signal associated with it regulates the crossing of pedestrians in both directions. If the two waiting zones on a
Pedestrian crossings, page 95 each cross their own stop line, the regulated direction is determined by the
line crossing the waiting zone at the origin of the movement (see "Pedestrian crossings regulated by stop
lines", fig.130 p.202).
Stop line
Regulates in indicated direct
Regulates in both directions
Figure 130. Pedestrian crossings regulated by stop lines
202
STOP
LINE
The layer of the stop line corresponds to the layer of the traffic signal with which it is associated (see Using
layers and network scenarios, page 62). When a traffic signal is deleted, all the stop lines associated with it
are also deleted.
This section is split into three parts:
Representation of the stop line in the edit area, page 203,

Creating a stop line, page 204,
Editing a stop line, page 204.
Representation of the stop line in the edit area

The stop line is represented in the Network edit area, page 19 in geometric mode, by a series of straight
segments (see "Two stop lines assigned to a multilane and a pedestrian crossing respectively", fig.131
p.203). As with other simulation objects dealt with in this chapter, it has no representation in logical mode.
The traffic signal identifier associated with it is displayed in the information area, when the mouses cursor
is positioned on the stop line.
Stop line on pedestrian crossing

Figure 131. Two stop lines assigned to a multilane and a pedestrian crossing respectively
203
MANAGING
CONFLICTING
TRAJECTORIES
Stop line on highway
S T O P
LINE
Creating a stop line

If necessary, switch to geometric mode ((see "Main CubeDynasim window in geometric mode",
fig.1 p.14).
2. Activate the create stop lines mode from either of the following:
a The Menu bar, page 14, select Objects > Priorities > Stop line,
1.
b. The Simulation
object bar, page 17 by clicking the
icon.
In the Network edit area, page 19, click the location where you want to start the stop line. The
"Stop line entry window" (see fig. 132, page 204) opens for the stop line object. The Signal name
field (non editable) identifies the signal associated with the stop line.
3.
a
a
Other signals is a list of signals that can be associated with the line; an OR condition connects all the
signals and pedestrian crossings associated with the stop line.
Width corresponds to the thickness of the line displayed in the edit area; a width of 0.5 meters
improve model readability.

5. Click OK in the "Stop line entry window" (see fig. 132, page 204) to position the stop line in relation to the background map.
6. Move the pointer and click to define your segments.
7. Right-click to define the last point.
b.
Name of the signal associated

with the line
Conditions
List of additional signals that

can be associated with the line
Thickness of the line
in the edit area
Color of the line
Figure 132. Stop line entry window
Before creating a stop line, move your mouses cursor over the traffic signal you wish to associate it
with. When the entry window is opened, the Signal name field is pre-entered.
Editing a stop line

As with single lanes, the stop line is characterized by its parameters and its geometry.
You edit the parameter values of a stop line, and move or delete it in geometric mode by following the procedure described in section Edit Object mode, page 20.
204
STOP
LINE
Adding a condition on a stop line

You may be required to add one or more conditions to the stop line to limit the stop's application to a certain
vehicle category or to a set of paths. These two conditions are edited differently.
Condition on the category
Proceed as follows to add a condition on the vehicle category:
Right-click the stop line and select Modify.
Go to the Condition field and select the categories that are to respect this stop line.
3. Click OK twice to confirm and exit stop line edit mode.
1.
2.
Condition on the paths

Proceed as follows to add a condition on a set of paths:
1.
2.
Right-click the stop line and select Add a marker.

Click on one of the trajectories of the route concerned by the stop line.
Direct signal
Right turn stop line

Right turn signal
Marker of the stop line
for the right turn
205
MANAGING
CONFLICTING
TRAJECTORIES
Stop line of the direct signal
IELD
Y
Yield
The yield is a priority rule-type simulation object, edited in the Network edit area, page 19 in geometric
mode. The yield consists of insertion parameters, an approach zone and at least one visualization zone.
This section looks at the following:
The elements of a yield, page 206,

Creating a yield, page 209,
Editing a yield, page 209,
Use of the yield, page 211.
The elements of a yield

The Yield simulation object is represented in geometric mode in the Network edit area, page 19 by the
icon, and a marker marking the end of the approach zone. A marker is a straight segment that is necessarily attached to a lane in a trajectory (see Trajectories, page 81). When the mouses pointer is placed on a
yield, the ends of its visualization zones are represented by markers, and the character string "Yield: Yield_"
followed by a numeric identifier generated by CubeDynasim is displayed in the information area (see
"Representation of a yield with two visualization zones", fig.133 p.206).
End of approach zone marker

Representation of the yield
in geometric mode
Representation of the yield
in geometric pointed mode
Yield icon
End of visualization zone 1 marker
End of visualization zone 2 marker
End of approach zone cursor
Figure 133. Representation of a yield with two visualization zones
206
YIELD
Approach zone
Selected Yield
Conflict zone
MANAGING
CONFLICTING
TRAJECTORIES
Visualization zone
Figure 134. Display of the Visualization zone and approach zone

A visualization zone or approach zone contains an ordered series of trajectories, connected in pairs. It is
characterized by the position of the end of its zone in the first object of the series, and by a zone length used
to mark the start of the zone in relation to its end position. Moreover, vehicles taken into account in the zone
can be limited according to their category and/or destination.
To calculate the trajectories taken into account by the zone of approach, CubeDynasim goes back in
the network starting from the end of approach zone marker over a distance defined by the value in the
length of approach zone field. CubeDynasim contents itself with a single sequence of objects, and does
not detect all the possible trajectories leading to the end of approach zone marker. When editing a
yield, you must take account of this restriction; it does not apply to the visualization zones.
The vehicle traveling in the approach zone draws an insertion time according to a limited normal log
distribution whose parameters, i.e. possible mean, standard deviation and extreme values, depend on the
vehicles category. At an instant t, the insertion gap is the minimum time a vehicle present in one of the
visualization zones has to reach the conflict point. A vehicle is authorized to exit the approach zone or yield
if its insertion time is less than the insertion gap of the rules zones of visualization, otherwise it waits for the
207
IELD
Y
next insertion gap that satisfies this condition. Depending on the values of its insertion time and insertion
gap, a vehicle can exit the zone of approach without stopping.
Yield rules are used to model traffic circle entries, lane changes when exiting a traffic circle, vehicles turning
left to enter an insertion gap, or, in the case of a crossroads regulated by traffic signals, entering the clearance
red, etc.
When editing the yield, CubeDynasim can generate, if appropriate, a counter priority. The counter priority
must signal to the impeding flow (corresponding to the vehicles present in the visualization zone) that a vehicle without priority has moved into the conflict zone. For a vehicle that forces its way into the zone (behavior
represented by a short insertion time in the modeling), the flow with priority reduces its speed, taking into
account the counter priority, thus yielding to this vehicle. The counter priority is actually a set of Strict
stop, page 219 generated by CubeDynasim according to the geometric configuration. There is one strict
stop per visualization zone. The position of the yield for the counter priority is located a fixed distance preceding the point where the trajectories conflict. The priority zone for the counter priority begins after the end
of the approach zone, and ends at the conflict point. If the two trajectories do not cross one another or converge in the 50 meters following the end of the visualization zone, the counter priority is not generated. The
figure "Yield according to different geometric configurations" (see fig. 136, page 209) illustrates the position
of the elements in a yield according to different geometric configurations. However, if the two trajectories
cross a second time within the 50 meters following the visualization zone, a counter priority is generated if
this new conflict zone does not come after a multilane object. This is illustrated in the figure.
Figure 135. Counter priority
If the vehicles at the start of the visualization zone are stopped, the vehicle without priority moves out whatever the values of its insertion time and insertion gap. This behavior in relation to the yield rule is used to
model :
left-turn movements cleared in the clearance times for an intersection with traffic signals,
left-turn movements in gaps left by the flow with priority saturating the downstream conflict zone
managed by the yield (see Stop-if-stop, page 224).
208
YIELD
yield
approach zone
visualization zone
strict priority: priority zone
strict priority: yield
> 50 m
object with priority

object yielding the priority
destination object
Legend
Yield and single lanes
Yield and multilanes
Yield without a counter priority
Figure 136. Yield according to different geometric configurations
Left-turn movements made in red clearance zones can also be modeled using the Yield-on-green,
page 214 object, if the signal has a cross.
Creating a yield
fig.1 p.14),
2. Activate create yield mode from either :
a The Menu bar, page 14, select Objects > Priorities > Yield,
1.
icon.
Move the pointer to the single lane or the lane in the multilane at the end of the approach zone
position, then left-click to insert the approach zone marker.
4. Position at least one visualization zone:
3.
move the cursor to the trajectory at the end of the visualization zone position, then left-click to insert
the visualization zone marker,
b. position a new visualization zone 4.), or proceed to step 5.)
a
5.
Right-click to finish the creation of the yield.
A yield cannot be created on a trajectory which is part of a frozen layer.

However, its approach zone may be created on a trajectory which is part of a frozen layer.
By default, when creating a yield, the counter priority is generated if the geometric conditions permit it, and
the conditions on the visualization and approach zones are unchecked for all the possible exits and vehicle
categories (see Editing a yield, page 209). The values of the distribution parameters specific to each simulated vehicle category and of the lengths of the visualization and approach zones are those of the last yield
edited/created.
When editing yields, make use of the fact that the parameter values assigned in create mode
correspond to those of the last yield edited to subsequently create yields that model the same standard
situation (see Use of the yield, page 211). By proceeding in this manner, you enter the parameters of
the yield in one go for each situation encountered.
Editing a yield
You edit the parameter values of a yield, or delete a yield in geometric mode following the procedure
described in section Edit Object mode, page 20.
The yield entry window is used to modify the layer associated with the object and the corresponding time
distribution, and to limit the number of vehicles considered in the visualization and approach zones.
209
MANAGING
CONFLICTING
TRAJECTORIES
b. The Simulation
IELD
Y
The layer, which is a Single-choice list field, page 32 is used to assign the prioritys layer. In order for it to
belong to a network, the layers of the lanes to which the priority is attached and the layer of the priority must
both belong to all the layers in the network scenario; both must be selected when defining the network scenario (see Network scenarios, page 65).
The Condition for Visualization and Condition for Stop fields each represent a Prohibitors, page 168,
used to define the subset taken into account in the zone of visualization and zone of approach respectively.
The Prohibitor field, page 171 is of the type Condition AND. When modeling an entry in a traffic circle
at a sufficient distance from the previous exit, you will select, via the Condition for Visualization field, the
destinations that do not use this exit (see "Yield entry window", fig.137 p.210). If none of the fields entries
are selected, all the vehicles in the zone are taken into account.
The counter priority may or may not be generated.
The Max distance to conflict is the length in meters up to which a conflict is searched for between the
approach zone and the visualization zone when generating a counter priority.
Select the time distribution in the Gap Time Distribution list (see Gap time distributions, page 199)
Figure 137. Yield entry window

Priorities consist of several markers. By default, in geometric mode, the only marker visible is the stop point
of the vehicle that yields the priority.
You can move the markers along the trajectory to which they are attached. To do so, left-click the marker
displayed by default. To move a marker displayed in the Network edit area, page 19, position the pointer
over the marker to be moved, then click and drag the marker to the desired position. To return to the default
display (with only the approach marker visible), simply click anywhere in the network edit area.
If you wish to modify the trajectory assigned to the end of approach zone marker, or add/remove one of the
end of visualization zone markers, you must delete the yield object and create a new one with the new geometric properties.
210
YIELD
If, to reduce the length of a trajectory object, one of its end points is moved beyond the position of an
end of zone marker assigned to it, this marker becomes coincident with the end point moved. If a
trajectory object is elongated, the absolute coordinates of the end of zone markers assigned to it are
not modified; thus, their coordinates relative to the object are increased by the size of the elongation.
If you modify a trajectorys orientation or position: CubeDynasim moves its markers in order to follow
this trajectory while minimizing their changes of position in relation to the background map.
You must check the position of the markers assigned to a single lane or to a lane in a multilane whose
geometry you have just modified.
The markers may be attached to single-lane or multi-lane trajectories. If a prioritys approach marker is
attached to a trajectory that is removed, the priority is removed. The priority is also removed if all of the
visualization markers are removed.
A priority cannot be edited, moved or deleted if all the single-lane or multilane objects on which
markers are positioned belong to frozen layers.
Use of the yield
Insertion on a traffic circle

On a traffic circle, the priority is given to the circle. To model a traffic circle entry, you need to edit yields.
There are two configurations determined by the number of lanes assigned to the entry to the traffic circle.
In the case of a one-lane insertion on a two-lane traffic circle, you edit one yield with two visualization zones
(see "One-lane insertion on a traffic circle", fig.138 p.211).
Single lane modeling

the traffic circle entry
Stop point of the vehicle
that yields
Traffic circle multilane
End of visualization zone

markers
Figure 138. One-lane insertion on a traffic circle
For a two-lane insertion on a two-lane traffic circle, you edit two yields, each defining two visualization
zones. The geometric location of the various elements in these two priority rules is illustrated in "Two-lane
insertion on a traffic circle" (see fig. 139, page 212). The yield whose approach zone ends on the first lane
or on the second lane in the direction of the moving flow entering the circle corresponds to rule no. 1 or rule
no. 2 respectively.
211
Insertion on a traffic circle, page 211,

Left-turn crossing a flow with priority, page 212.
MANAGING
CONFLICTING
TRAJECTORIES
This section describes how to use the yield to model three standard conflicting configurations, the first two
of which concern a traffic circle :
IELD
Y
Traffic circle multilane
Rule 2: end of lane 1 visualization zone

Rule 2: end of approach zone
Rule 1: end of approach zone
Multilane entering the traffic circle
Figure 139. Two-lane insertion on a traffic circle
The insertion parameters of a yield modeling a traffic circle entry are presented for each category generally
simulated in Table 1, "Traffic circle insertion parameters", page 200 and must be defined in a Time Gap distribution.
The length of the approach zone is determined by the speed limit assigned to the simulation object modeling the entry on the traffic circle. The length of the visualization zone is determined by the speed limit
assigned to the movement of the vehicles on the circle. A length of 30 meters should suffice.
When modeling a traffic circle, remember to limit the traveling speed of vehicles on the circle and on
the approach to the circle.
Left-turn crossing a flow with priority
To model the behavior of a left-turn movement crossing a priority movement, you use a yield if the antagonistic signal does not have a repeater. Otherwise, you use the Yield-on-green, page 214 object. Figure
"Left-turn movements to enter an insertion gap" (see fig. 140, page 213) illustrates the case of a left-turn
movement crossing a two-lane priority flow and grouping three possible trajectories. In this case, the visualization zone is described with three markers. The end of the approach zone is positioned upstream, in the
direction of the flow that yields, at the first conflict with one of the three priority trajectories.
212
YIELD
Priority movements
End of visualization zone markers

End of approach zone marker
Left-turn movement yielding
the priority
Figure 140. Left-turn movements to enter an insertion gap
213
MANAGING
CONFLICTING
TRAJECTORIES
The standard values of the insertion parameters are summarized for each vehicle category in Table 2, "Left
turn parameters", page 201 and must be defined in a Time Gap distribution. The length of the approach zone
is set to 30 meters for a turning movement, whereas the length of the visualization zone is set to 80 meters for
a forward movement (i.e. straight on) in an urban environment. The zone lengths can be adjusted according
to the geometric configuration and especially the vehicle speeds.
IELD-ON-GREEN
Y
Yield-on-green
The yield-on-green (YOG) is a priority rule-type simulation object, similar to a Yield, page 206. Its additional feature is to consider the state of the associated signal which activates the priority rule if, and only if,
the signal (see Signals, page 290) is not red. It comprises an approach zone, a visualization zone and a reference to a signal.
Representation of a YOG in the edit area, page 214,

Creating a YOG, page 215,
Editing a YOG, page 215.
Representation of a YOG in the edit area

In the Network edit area, page 19, a YOG is represented by the
approach zone marker.
icon associated with the end of
In pointed mode (i.e., with the mouse pointing), the icon remains unchanged; however, the stop marker and
the end of visualization zone markers are highlighted (see "Representation of Yield On Green priorities",
fig.141 p.214).
Marker for the end of approach zone

of a YOG priority
Markers for end of visualization zone of

a pointed YOG priority
Marker for the end of approach zone
of a pointed YOG priority
Icon representing a YOG priority
Figure 141. Representation of Yield On Green priorities
214
YIELD- ON- GREEN
Creating a YOG
1.
fig.1 p.14),
2.
Click the
icon on the Simulation object bar, page 17 to activate create YOG mode.
Move the pointer over the signal to associate with a YOG.

Click a trajectory (either a single lane or a lane in a multilane at the end of the approach zone.)
5. Insert one or more visualization zones:
3.
4.
Click the trajectory at the end of the visualization zone,
b. Insert a new visualization zone 5.), or proceed to 6.)

6.
Right-click to finish.
A YOG cannot be created in a single lane or in a lane of a multilane which is part of a frozen layer.
However, all or part of its approach zones can be positioned on a single lane or on a lane in a
multilane which is part of a frozen layer.
To validate the signal associated with the YOG priority created, edit the YOG and Apply the selected
signal so that it is simulated.
You can edit or delete a YOG in geometric mode by following the procedure described in section Edit
Use the "Yield On Green priority entry window" (see fig. 142, page 215) to modify the layer associated with
the object and the parameters of the distributions specific to each vehicle category, to limit the number of
vehicles considered in the visualization zones, and to modify the signal associated with the rule.
The parameters are similar to those of the Yield object (see Editing a yield, page 209).
Distribution of the
insertion parameters
Signal associated with
the YOG priority
Figure 142. Yield On Green priority entry window
215
MANAGING
CONFLICTING
TRAJECTORIES
Editing a YOG
IELD-ON-GREEN
Y
The Signal name field can only be edited the first time this window is opened.
As with the Yield, you can move the markers of the stop or signal priority (see Editing a yield, page 209).
216
STOP
Stop
The stop is a priority rule-type simulation object. The two main differences - whereby one actually results
from the other - that distinguish the stop from the Yield, page 206 are:
the obligation imposed on the vehicle to stop, whatever the values of the insertion times and insertion
gaps, at the position of the stop line,
the absence of an approach zone, replaced by a stop marker representing the position on the trajectory where vehicles yielding the priority will stop.
The stop must be sufficiently distant from the network entry to allow all vehicle types to come to a halt
at this stop given their speed on entry in the network, defined by the Origins, page 69.
Representation of the stop in the edit area, page 217,

Creating a stop, page 218,
Editing a stop, page 218.
Only icons attached to the graphic representations displayed in the Network edit area, page 19 in geometric mode distinguish the two types of priority rules, namely the stop
, and the Yield, page 206 (see
"Representation of a stop in pointed mode with three visualization zones", fig.143 p.217).
End of visualization zone markers
Stop marker
Figure 143. Representation of a stop in pointed mode with three visualization zones
217
MANAGING
CONFLICTING
TRAJECTORIES
Representation of the stop in the edit area
S T O P
Creating a stop
1.
fig.1 p.14),
2.
Click the
button on the Simulation object bar, page 17 to activate create stop mode.
Click a trajectory (single lane or lane in a multilane) at the position where vehicles stop to observe
the stop.
3.
Click on the end of the visualization zone, which is necessarily on the trajectory,
b. Repeat step 4.) to insert a new visualization zone, or proceed to step 5.)
a
5.
Like the Yield, a stop cannot be created in a single lane or in a lane of a multilane which is part of a
frozen layer (see Creating a yield, page 209).
Editing a stop
You can edit or delete a stop in geometric mode by following the procedure described in section :Edit
The parameters edited in the Stop entry window, page 218 define a subset of parameters themselves
edited in the "Yield entry window" (see fig. 137, page 210). Their meaning is the same.
Distribution of
insertion
parameters
Figure 144. Stop entry window

As with the Yield, you can move the markers of the stop (see Editing a yield, page 209).
218
STRICT
STOP
Strict stop
The Strict stop is a priority rule-type simulation object, edited in the Network edit area, page 19 in geometric mode. It consists of a stop marker (like the stop), and visualization zone.
Motional capacities permitting, the vehicle comes to a stop on the marker of a strict stop if at least all or part
of a vehicle is present in the visualization zone. It remains stopped until the visualization zone contains no
vehicles once more.
The strict stop is used, for example, to model intersections where the crossroads must be emptied before
authorizing the passage of a movement regulated by the next phase (see "Use of priority rules to empty an
intersection", fig.148 p.223).
Representation of a strict stop in the edit area, page 219,

Creating a strict stop, page 220,
Editing a strict stop, page 220,
Example of how to use a strict stop, page 221.
In the Network edit area, page 19 a strict stop is represented by the

marker.
icon associated with the stop
In pointed mode, the icon remains unchanged, however the stop marker and the end of visualization zone
markers are highlighted (see "Representation of strict stops", fig.145 p.219).
Marker for the visualization zone

of a pointed strict stop
Marker for the stop of a strict stop

Strict stop icon
Marker for the stop of the
strict stop
Figure 145. Representation of strict stops
219
MANAGING
CONFLICTING
TRAJECTORIES
Representation of a strict stop in the edit area
S T R I C T
STOP
Creating a strict stop

1.
fig.1 p.14),
2.
Click the
button on the Simulation object bar, page 17 to activate create strict stop mode.
Click a trajectory (single lane or lane in a multilane) at the position where vehicles stop to observe
the strict stop.
3.
Click on the end of the visualization zone, which is necessarily on the trajectory,
b. Repeat step 4.) to insert a new visualization zone, or proceed to step 5.)
a
5.
Unlike the Yield or Stop priority rules, the end of visualization zone marker is positioned on, or even
after, the point of conflict corresponding to the intersection of the two trajectories.
A strict stop cannot be created in a single lane or in a lane of a multilane which is part of a frozen
layer (see Creating a yield, page 209).
Editing a strict stop

You can edit or delete a strict stop in geometric mode by following the procedure described in section Edit
Display the Strict Stop entry window, page 221 to edit the four fields:
Layer which is a Single-choice list field, page 32 that determines the layer of the priority; in order
for it to belong to a network, the layers of the lanes to which the priority is attached and the layer of
the priority must both be selected in the definition of the network considered (see Network scenarios,
page 65).
Length of zone of visualization which determines the minimum distance between vehicles for which
a mobile waiting on the strict stop moves out.
Condition for visualization is aProhibitor field, page 171 used to limit the vehicles taken into
account in the visualization zone according to their category or destination.
Counter priority whose value is either Yes or No, according to whether you want to generate a
counter priority as defined for a Yield.
These three fields share the same characteristics as those for Yield and Stop rules.
220
STRICT
STOP
Figure 146. Strict Stop entry window
This section describes the use of a strict stop when modeling an intersection with traffic signals.
Limited by the capacities of an intersection upstream, the flow does not have time to clear the intersection
before the arrival of the antagonistic phase. An operation extract is illustrated in the figure "Use of priority
rules to empty an intersection" (see fig. 148, page 223). At the end of the phase, two trucks are stuck in the
middle of the crossroads (stage 1). The vehicles in the opposing phase start (stage 2), and stop to wait for the
two trucks blocking the intersection. The trucks start off again, leaving the way clear for the other vehicles,
which in turn start off again.
The trucks take the multilane that starts at the top left of the illustration, and travel towards the bottom (see
"Modeling with strict stops", fig.147 p.222). You can see two conflict zones.
The first conflict occurs with the movement from the right. You position two stop points via strict stops on
each lane in the multilane. The descending movement now yields the priority to the movement from the
right. The end of visualization zone cursors of these strict stops are positioned beyond the points of conflict.
These rules also apply in the other direction thanks to the counter priority. The trucks have started out, and
have passed the stop point of the strict stop. Their progress is now protected by the counter priority of the
strict stop. The other vehicles wait for the trucks to go past. With this modeling, and in the event of a general
blocking situation, the movement from the right will be favored to the detriment of the descending movement.
The second conflict occurs between the movement coming from the left and the descending movement. Two
strict stop cursors have been positioned on the two lanes farthest to the left in the multilane coming from the
left. The end of visualization zone cursors are located on the conflict zone. In this configuration, the priority
is given to vehicles already present on the intersection. When implementing a strict stop, you are advised to
favor movements that have already moved out onto the intersection.
In an intersection with traffic signals, the length of the visualization zone must be less than the
distance between the end of visualization zone marker and the stop line; otherwise, the vehicles in the
intersection will stop at the stop marker when they "see" users stopped at the red light.
221
Example of how to use a strict stop
MANAGING
CONFLICTING
TRAJECTORIES
As with the Yield, you can move the markers of the strict stop (see Editing a yield, page 209).
S T R I C T
STOP
Figure 147. Modeling with strict stops
222
STRICT
STOP
Step 1
At the end of the phase with
vehicles present in the
middle of the intersection
The vehicles start off again
Figure 148. Use of priority rules to empty an intersection
223
Step 3
MANAGING
CONFLICTING
TRAJECTORIES
Step 2
The vehicles in the priority
phase move out and wait
for the last of the remaining
vehicles in the previous
phase
S T O P - I F - S T O P
Stop-if-stop
The stop-if-stop is a priority rule-type simulation object, edited in the Network edit area, page 19 in geometric mode. It consists of a stop marker (like the stop), and markers at the start and end of the storage area.
In order for a vehicle to stop at the stop marker, the sum of the vehicle lengths +1 m included between the
marker and the end of the storage area must be greater than the length of the storage area, and the speed of a
vehicle situated in the storage area must be less than its associated threshold speed.
Car engages
Car stops
Car stops
Stop marker
Start of storage area

marker
End of storage area

marker
The stop-if-stop priority is used to avoid a vehicle making a left-turn movement - without priority - from
staying blocked in a queue. In this case, a vehicle caught in the queue stops and yields the way for the leftturning movement. The movement that yields in a fluid situation alternately takes priority in a saturated situation.
This section discusses the following stop-if-stop priority topics:
Representation of a stop-if-stop in the edit area, page 224,

Creating a stop-if-stop, page 225,
Editing a stop-if-stop, page 225,
Example of how to use a stop-if-stop, page 226.
Representation of a stop-if-stop in the edit area

In theNetwork edit area, page 19, the stop-if-stop priority is represented by the
icon, to which the stop
marker is attached (see "Graphic representation of stop-if-stop priorities", fig.149 p.225). In pointed mode,
the stop markers at the start and end of the storage zone are highlighted, and the message followed by a
numeric identifier generated by CubeDynasim is displayed in the information area.
224
STOP-IF-STOP
Representation of a
Stop-if-stop priority
Icne
Representation of a
Stop-if-stop priority in
pointed mode
Stop marker
Start of storage area
marker
End of storage area
marker
Creating a stop-if-stop
1.
fig.1 p.14).
2.
Click the
icon on the Simulation object bar, page 17 to activate stop-if-stop priority
mode.
Click the trajectory (single lane or the lane in the multilane) at the position of the stop marker.
Click the trajectory at the position of the start of the storage area.
Click the trajectory at the position of the end of the storage area.
Click to add as many storage areas as necessary.
Right-click to finish the creation of the stop-if-stop priority.
3.
4.
5.
6.
7.
A stop-if-stop priority cannot be created in a single lane or a lane in a multilane, which is part of a
frozen layer (see Creating a yield, page 209).
When creating a stop-if-stop priority object, you can refer to the message area to know which actions
are possible and their effect (see Status areas, page 24).
Editing a stop-if-stop
You edit or remove a stop-if-stop priority object by following the general procedure described in the section
Edit Object mode, page 20.
225
MANAGING
CONFLICTING
TRAJECTORIES
Figure 149. Graphic representation of stop-if-stop priorities
S T O P - I F - S T O P
You use the "Stop-if-stop entry window" (see fig. 150, page 226) to edit the following parameters:
Layer, a Single-choice list field, page 32 used to determine the prioritys layer. For the priority to
be active both the layer to which the priority is assigned as well as the layer to which the associated
trajectory is assigned must both be selected in the definition of the network (see Network scenarios,
page 65),
Condition for Visualization, a Prohibitor field, page 171 used to limit the number of vehicles
taken into account when evaluating the condition that determines whether to apply the stop-if-stop
priority. This restriction concerns the vehicle destination and/or category considered between the two
markers that define the storage area.
Condition for Stop, a Prohibitor field, page 171 used to limit the number of vehicles taken into
account when evaluating the condition that determines whether to apply the speed
priority. This restriction concerns the vehicle destination and/or category that can stop at the stop
marker.
Length of Zone of Approach, defines the length of the approach zone for vehicles that observe the
condition for stop, i.e. the distance over which the simulation will find out whether a vehicle must
stop at the stop marker, and thus modify its movement.
Speed threshold to enter stop condition : specifies the speed in the storage area that causes
approaching vehicles to wait at the stop line.
Speed threshold to exit stop condition, specifies the speed in the storage area that causes vehicles
stopped at the stop line to continue. Stopped vehicles move forward when storage-area speeds reach
this value or higher.
Figure 150. Stop-if-stop entry window

As with the Yield, you can move the markers of the stop-if-stop (see Editing a yield, page 209).
Example of how to use a stop-if-stop

This section illustrates the modeling of left-turn movements using stop-if-stops to prevent autoblocking (i.e.
gridlock) situations. A gridlock situation is characterized by movements that block each other. It can imply
more than two movements. In the simulation, this leads to queues clustering vehicles that can no longer cross
the conflict zone until the end of the simulation.
226
STOP-IF-STOP
The crossroads modeled is an intersection regulated by traffic signals. The left-turn movements enter gaps in
the conflicting movement and/or in the clearance time (see "Use of the stop-if-stop rule to prevent gridlock
situations", fig.151 p.227).
Vehicles waiting at the

yield
Vehicles waiting at the speed
priority
Vehicles moving out thanks to the

gap left by vehicles blocked
by the stop-if-stop
Movement with priority
The two left-turn movements coming from the right are modeled with purple objects. These movements are
connected with a Split link, page 160 (see the shorter single lane), and regulated by Yields. To limit gridlock situations, you edit a stop-if-stop on each of the two left-turn movements (see "Modeling with stop-ifstop objects", fig.152 p.227).
Speed stop marker
Marker at the start of the

stop-if-stop storage area
Markers at the end of the
stop-if-stop storage area
Movements with priority
Figure 152. Modeling with stop-if-stop objects
227
MANAGING
CONFLICTING
TRAJECTORIES
Figure 151. Use of the stop-if-stop rule to prevent gridlock situations
S T O P - O N - R E D
Stop-on-red
The Stop-On-Red (SOR) is a priority rule-type simulation object, edited in Network edit area, page 19 in
geometric mode. It comprises a stop marker, at least one visualization zone and a reference to one of the
Signals, page 290.
The SOR is similar to the Stop, page 217 priority, whose behavior depends on the state of the associated
signal. If the signal is red, the SOR is active, and approaching vehicles stop at the stop marker. However, if
the signal is green, the SOR priority is disabled.
This section discusses the following topics:
Representation of an SOR in the edit area, page 228,

Creating an SOR, page 229,
Editing an SOR, page 229,
Example of how to use the SOR, page 230.
Representation of an SOR in the edit area
A stop-on-red is displayed in the Network edit area, page 19 using the

icon attached to
the stop marker (see Representation of a Stop-On-Red with two visualization zones, page 228).
When the pointer is positioned on the icon or the stop marker of a stop-on-red rule:
the corresponding stop marker(s) and the marker(s) at the end of the visualization zone(s) are highlighted (see Representation of a Stop-On-Red with two visualization zones, page 228), and the "SOR :
SOR_ " string message followed by a numeric identifier generated by CubeDynasim is displayed in
the information area.
SOR icon
Representation of an
SOR in geometric
mode
Stop marker
Figure 153. Representation of a Stop-On-Red with two visualization zones
228
STOP-ON-RED
SOR icon
Signal associated
with the SOR
Representation of an
SOR in pointed mode
Stop marker
Marker at the end of
the visualization zone
Figure 153. Representation of a Stop-On-Red with two visualization zones
Creating an SOR
fig.1 p.14),
2. Activate create SOR mode via either of the following:
a the Menu bar, page 14, select Objects > Priorities > SOR,
1.
icon.
Click the trajectory at the end of the visualization zone,

b. Insert a new visualization zone, or proceed to step 5).
a
5.
Right-click to finish the creation of the SOR.
An SOR cannot be created on a trajectory which is part of a frozen layer (see Creating a yield,
page 209).
Before creating the SOR, pass the mouse pointer over the signal with which it will be associated; when
you open the entry window, the Signal name field is pre-entered.
To validate the signal associated with the SOR, you must edit the condition for stop and apply the
selected signal in order for it to be simulated.
Editing an SOR
You edit the parameters of an SOR, or remove this priority in geometric mode by following the general procedure described in the sectionEdit Object mode, page 20.
The "SOR entry window" (see fig. 154, page 230) differs from the "Yield entry window" (see fig. 137,
page 210) by the presence of the Signal name parameter used to identify the signal associated with the SOR.
229
MANAGING
CONFLICTING
TRAJECTORIES
b. the Simulation
On the trajectory (i.e. the lane or a lane in a multilane), click where you want the vehicles to stop
at the SOR.
3.
Signal
associated
with the SOR
Figure 154. SOR entry window
The Signal name field can only be modified the first time the entry box is opened.
As with the Yield, you can move the markers of the Stop-On-Red (see Editing a yield, page 209).
Example of how to use the SOR

This section illustrates the use of a Stop-On-Red (SOR) when modeling a T intersection controlled with a
signal. You must edit an SOR priority rule to reproduce the behavior of users turning right who wait for an
acceptable gap in the opposite flow with the right-of-way. In other words, authorize the non-priority rightturn movement when the signal regulating this flow is red (see "Illustration of a right-turn movement when
the signal is red", fig.155 p.230).
Priority vehicle moving in the

visualization zone of
the SOR
Vehicle waiting at the stop
marker of the SOR
Vehicles waiting at the signal
Figure 155. Illustration of a right-turn movement when the signal is red
230
STOP-ON-RED
The entry road, regulated by the F1 signal, is modeled by a two-lane multilane. The left-turn movement is
performed on both lanes, while the right-turn movement is limited to the right-hand lane (see "Modeling with
an SOR priority", fig.156 p.231). When editing the model, you must distinguish right-turning vehicles regulated by the SOR priority from left-turning vehicles regulated by the stop line associated with F1. For this
purpose, you must assign:
All the destinations that can be reached by taking the left turn, in the Condition for Visualization
field in the "SOR entry window" (see fig. 154, page 230),
All the destinations that can be reached by taking the right turn, in the Condition for Stop field in the
"SOR entry window" (see fig. 154, page 230).
You are advised to use zones for defining the destination conditions in the Condition for Visualization
and Condition for Stop fields.
Signal F1 stop line

Multilane modeling the
feeder road
Stop marker
End of visualization zone
marker
Figure 156. Modeling with an SOR priority
231
MANAGING
CONFLICTING
TRAJECTORIES
Signal F1
232
11
Data collectors
After defining these various elements, we will be able to describe how data collectors are implemented with
CubeDynasim.
This chapter discusses the following:
What to measure, and how to measure it, page 234,

Storage of the values measured, page 245,
Representation of data collectors and editing them, page 262.
233
DATA COLLECTORS
Simulating the operation of an urban development implementing microscopic and stochastic models must
not only make it possible to view this operation, but also to quantify it. Measuring an urban developments
operation gives better insight into its complexity by taking into account diverse situations and configurations
that are difficult to identify other than by a quantitative approach. Moreover, the amounts measured make it
easier to objectively compare and evaluate different variants of the same project.
HAT
W
TO MEASURE, AND HOW TO MEASURE IT
What to measure, and how to measure it

What to measure is defined as being the criterion measured. Criteria are measured on time samples. At the
end of each time sample, you can store all the values measured by criterion. However, to limit the amount of
data stored, the values collected are usually summarized by applying statistical processes to them.
The possible processes are as follows:
Actual: last value measured at the end of the time sample. Here, the number of values stored corresponds to the number of time samples taken at the end of the measurement period (see Flow scenario
parameters, page 111).
Cumulative: sum of the values measured at the end of each time sample, increased by the criterions
current value at the end of the simulation. This value is not considered if the end of the simulation is
coincident with the end of the last time sample.
Min: minimum value noted during the time sample.

Max: maximum value noted during the time sample.
Mean: mean value noted during the time sample.
Standard Deviation: standard deviation of the values noted during the time sample.
Percentile: percentile is defined for parameter values between 0 and 1. The median is defined as the
percentile with a parameter value of 0.5. Percentile 1 corresponds to the maximum.
Confidence: confidence interval, the value of the parameter is between 0.6 and 0.999.
Wanted, Simulated and Percentage: processes applied exclusively to the Deficit, page 236 criterion.
CubeDynasim can also store all the values noted during the simulation.
The case may well arise where no values are measured during a time sample. For example, with the Travel
time, page 239, if no vehicles finish their journey during the time sample, no value is noted. To deal with
these cases, you can either:
Not store the value at the end of the time sample.
2. Or store a threshold value (a value that has no meaning in the case of the criterion measured).
1.
CubeDynasim gives preference to the second solution. Thus, when extracting data, the number of values
extracted is always the same in accordance with the measurement time durations (see Flow scenario parameters, page 111) and the sampling time durations, regardless of the values measured. For certain criteria, a
threshold value has had to be defined to identify the absence of a new value during a time sample.
The criterion measured defines both the possible statistical processes, and the type of subnetwork on which
the measurement is applied. This makes it possible to identify four families of criteria:
independent of the network: e.g. the Green signal duration, page 242,
ad hoc: the measurement applies at a single point on a single lane in the traffic, e.g. the Occupancy
rate, page 241,
exits: the measurement applies equally at several points on the network, e.g. the Signal line crossing
duration, page 243,
entry-exit: the measurement requires two non-empty sets of network points (all the subnetworks
entry points and exit points). The information is collected when a vehicle crosses one of the entry
points, the measurement takes effect when this same vehicle crosses one of the exit points. If, along
the way, a vehicle fails to satisfy these two conditions, it is not considered. In this case, the open subnetwork, which does not generate any simulation errors, will be distinguished from the closed subnetwork, which generates a simulation error (see "Trajectories that generate an error for a closed
subnetwork", fig.157 p.235). For a closed subnetwork, these two errors imply messages that can be
viewed via the Simulation module entry window in Results mode, page 413 (see "Trajectories that
generate an error for a closed subnetwork", fig.157 p.235). The open subnetwork does not signal
234
WHAT
these errors; it is only used to avoid interfering with the list of errors. Generally speaking, it is best
to position closed data collectors first, then to analyze any errors produced in order to correct them. In
some cases, the errors are inherent in the configuration of the data collector. Therefore, it is best to use
open data collectors.
Entry points
Exit points
Trajectory that does
not generate an error
Trajectories that generate

an error in a closed
subnetwork
Figure 157. Trajectories that generate an error for a closed subnetwork
For each possible criterion, this section defines the following:
235
the type of subnetwork to define,

the possible statistical processes,
the threshold values (if any),
the unit of measure,
the dependence on the reference state,
the label used for storing the results (see Storage of the values measured, page 245).
DATA COLLECTORS
Some criteria require a reference value, calculated from the reference state. The reference state is obtained
by generating a standard vehicle (i.e. with average capacities for its category) for all combinations (category,
origin, destination) defined by the Flow scenarios, page 110, and by the simulation models possible
Public transport scenarios, page 277. During the calculation of the reference state, only one vehicle at a
time travels through the network. All the signals are in the Green state to ensure an optimum travel time.
Public transport vehicles make their stops according to the average stop time.
HAT
W
Flow
The flow criterion serves to count the number of vehicles that cross one of the subnetworks exit points
during a time sample. Only vehicles that previously crossed one of the subnetworks entry points are
recorded.
Network type : entry-exit
Statistics :
Actual: number of vehicles that left the subnetwork during the measurement period.
2. Cumulative: number of vehicles that left the subnetwork at the end of the measurement period.
1.
Threshold value: 0
Unit of measure: number of vehicles.
Reference state: the criterion does not depend on the reference state.
Label: Flow
Deficit
The deficit represents the variances between the demand and the offer at a given location on the network.
The demand is defined as the number of vehicles wanting to pass during the simulation. It is determined by
the Flow scenarios, page 110 and the Paths, page 157 taken by the vehicles. The offer corresponds to
the flow measured during the measurement period.
Network type: entry-exit
Statistics:
Wanted: demand expressed as a number of vehicles per hour.
Simulated: offer expressed as a number of vehicles per hour.
3. Percentage: percentage of the demand not satisfied.
1.
2.
Threshold value : none

Reference state : the demand is evaluated according to the paths calculated during the reference state
Label : Deficit
236
WHAT
Number of vehicles present

Represents the number of vehicles present in a subnetwork.
Statistics:
1.
2.
3.
4.
5.
6.
7.
Actual: number of vehicles present in the subnetwork at the end of the time sample.
Min: minimum number of vehicles present in the subnetwork during the time sample.
Max: maximum number of vehicles present in the subnetwork during the time sample.
Mean: average of all the values noted during the time sample. A new value for the number of
vehicles present is noted only when a vehicle enters or exits the subnetwork.
Standard Deviation: calculated on the same set of values as for the mean.
Percentile: calculated on the same set of values as for the mean.
Confidence: calculated on the same set of values as for the mean.
Threshold value : 0
Unit of measure : number of vehicles.
Label : Number
Delay
The delay is defined as the variance between the travel time measured, and a reference travel time noted in
ideal traffic conditions. The reference time specific to each Origin - Destination - Category triplet is calculated during the reference state.
Statistics:
1.
2.
3.
4.
5.
6.
7.
8.
Cumulative: sum of the delays measured during the measurement period.

Min: minimum delay measured for a vehicle that left the subnetwork during the time sample.
Max: maximum delay measured for a vehicle that left the subnetwork during the time sample.
Mean: average delay noted during the time sample.
All: the delays for all vehicles that leave the subnetwork are stored.
Threshold value : -100 000.

Unit of measure : seconds.
Reference state : Reference travel times are calculated during the reference state simulation.
Label : Delay
237
DATA COLLECTORS
Reference state : the criterion does not depend on the reference state.
HAT
W
Stop
This criterion accounts for the number of vehicles in the stop state. It depends on two threshold speeds, the
lower threshold speed (LTS) and the upper threshold speed (UTS) respectively. A vehicle is in the stop state:
If, upon its entry in the subnetwork, its speed was less than the LTS, and it has not since reached a
speed greater than the UTS.
2. Or if, since decelerating to the LTS, it has not reached or exceeded the UTS.
1.

Statistics:
Actual: number of vehicles present in the subnetwork in the stop state at the end of the time sample.
2. Cumulative : sum of the Actual values for the measurement period.
1.
Threshold value : 0
Label : Stop
Number of stops per vehicle

This criterion represents the number of times each vehicle has entered the Stop state (see Stop, page 238)
while traveling through the subnetwork. The vehicles state when it enters the network is recorded, if necessary.
Network type : entry-exit
Statistics:
1.
2.
3.
4.
5.
6.
7.
Min: minimum number of stop states counted out of all the vehicles that left the subnetwork
during the time sample.
Max: maximum number of stop states counted out of all the vehicles that left the subnetwork
Mean: average number of stop states counted for all each vehicle that left the subnetwork during
the time sample.
All: the number of stops for each vehicle that left the subnetwork during the measurement period
is stored. Consequently, there are as many values recorded as there are vehicles that left the subnetwork during the measurement period.
Threshold value: -100 000.

Unit of measure: number of stops per vehicle.
Label: Stop by vehicle.
238
WHAT
Stop state duration per vehicle

This criterion represents the total time spent in the Stop state (see Stop, page 238) for each vehicle that leaves
the subnetwork.
Statistics:
1.
2.
3.
4.
5.
6.
7.
Min : minimum duration of the stop state out of all vehicles that left the subnetwork during the
time sample.
Max: maximum duration of the stop state out of all vehicles that left the subnetwork during the
time sample.
Mean: mean calculated for all the stop durations recorded for each vehicle that left the subnetwork during the time sample.
Confidence : calculated on the same set of values as for the mean.
All: the time each vehicle that left the subnetwork spends in the stop state on its way through the
subnetwork is stored.

Label : Stop Time per vehicle.
Travel time
This criterion represents - for each vehicle that leaves the subnetwork - the time elapsed since it first crossed
the subnetworks entry point.
Statistics:
1.
2.
3.
4.
5.
6.
7.
Min: minimum time out of all the travel times recorded for vehicles that left the subnetwork
Max: maximum time out of all the travel times recorded for vehicles that left the subnetwork
Mean: mean travel time recorded for all vehicles that left the subnetwork during the time sample.
All: all the travel times of vehicles that leave the subnetwork are stored.
Threshold value : -100 000

Unit of measure : seconds
Label : Travel Time.
239
DATA COLLECTORS
Threshold value : -100 000.
HAT
W
Travel speed
This criterion represents the average travel speed through the subnetwork. It is obtained for each vehicle by
the quotient of the distance traveled over the Travel time, page 239.
Statistics:
1.
2.
3.
4.
5.
6.
7.
Min: minimal value out of all the travel speeds recorded for vehicles that left the subnetwork
Max: maximum value out of all the travel speeds recorded for vehicles that left the subnetwork
Mean: mean travel speed recorded for all the vehicles that left the subnetwork during the time
sample.
All: all the travel times of vehicles that leave the subnetwork are stored.

Unit of measure : Km/h
Label : Travel Speed.
Flow by lane
This criterion represents the flow on a single lane.
Network type: ad hoc
Statistics:
Actual: flow recorded at the end of the time sample.
2. Cumulative: recorded at the end of the measurement period.
1.
Threshold value : a threshold value does not need to be defined for the Flow by lane criterion.
Label : Flow
Queue
This criterion evaluates the queue, i.e. the distance from a point on the network where the vehicles are in a
stopped state and at an inter-vehicle distance less than a predefined threshold distance. The stop state is
determined by two threshold speeds, as with the Stop, page 238 criterion. The queue is always re-evaluated from its last known position. Thus, when traffic moves in fits and starts, a possible increase in the
queues length can be recorded.
240
WHAT
Statistics:
1.
2.
3.
4.
5.
Actual : length of the queue at the end of the time sample.

In order to optimize calculation times, not all the queue length values are collected; for certain
geometric configurations, statistical processes cannot be applied to all the queue values.
Min: minimum length of the queue during the time sample.
Max: maximum length of the queue during the time sample.
Mean: mean length of the queues measured during the time sample,
Threshold value : 0
Unit of measure : meters.
Label : Back.
Inter-vehicle times

Statistics:
1.
2.
3.
4.
5.
6.
7.
Min: minimum time collected during the time sample.

Max: maximum time collected during the time sample.
Mean: mean time collected during the time sample.
All: all the times collected are stored.

Label : Time intervehicle.
Occupancy rate
Measures the occupancy rate at a given point on the network, i.e. the proportion of time during which a vehicle is present at this point.
241
DATA COLLECTORS
This criterion measures the time between the passing of the rear end of the lead vehicle in a queue, and that
of the front end of the following vehicle, at a given point on the network.
HAT
W

Statistics: Actual is the only value available at the end of the time sample.
Threshold value : 0
Unit of measure : percentage.
Label : Rate.
Instant speed
This involves measuring the speed at which vehicles pass a given point on the network.
Statistics:
1.
2.
3.
4.
5.
6.
7.
Min: minimum instant speed measured during the time sample.

Max: maximum instant speed measured during the time sample.
Mean: mean instant speed measured during the time sample.
Confidence : calculated on the same set of values as for the mean.
All: all the speeds collected are stored.

Unit of measure : km/h.
Label : Speed Instant.
Green signal duration

This involves collecting data on the times during which a signals state is green. If the first and second periods measured are incomplete, the value collected for these two periods is taken from their sum. A period is
considered complete if the measurement starts and ends with a change of signal state.
242
WHAT
Network type: independent of the network

Statistics:
1.
2.
3.
4.
5.
6.
7.
8.
Cumulative: total green duration during the measurement period.

Min: minimum green duration collected during the measurement period.
Max: maximum green duration collected during the measurement period.
Mean: mean green duration collected during the measurement period.
All: all the green durations collected during the measurement period are stored.
Threshold value : 0.
Label : Duration of green.
This involves collecting data on the times during which a signal's state is red (red and yellow). If the first and
second periods measured are incomplete, the value collected for these two periods is taken from their sum. A
period is considered complete if the measurement starts and ends with a change of signal state.
Network type: independent of the network
Statistics:
1.
2.
3.
4.
5.
6.
7.
8.
Cumulative: total red duration during the measurement period.

Min: minimum red duration collected during the measurement period.
Max: maximum red duration collected during the measurement period.
Mean: mean red duration collected during the measurement period.
All: all the red durations collected during the measurement period are stored.
Threshold value: 0.
Unit of measure: seconds.
Label: Duration of red.
Signal line crossing duration

This criterion measures the time elapsed between the change of signal state from red to green, and the crossing of this signals line by the first vehicle.
243
DATA COLLECTORS
Red state duration for a signal
HAT
W

Network type: exits
Statistics:
1.
2.
3.
4.
5.
6.
7.
8.
Cumulative: sum of all the crossing durations measured during the measurement period.
Min: minimum duration collected during the measurement period.
Max: maximum duration collected during the measurement period.
Mean: mean green duration collected during the measurement period.
All: all the crossing durations collected during the measurement period are stored.

Label : Green before crossing.
Vehicle scheduling
Vehicle scheduling serves to track a vehicle's progress in time along a trajectory. The criterion involves 3
fields in the CubeDynasim database:
Vehicle ID (table GroupCollector, value Idf1)
Time t (table Value, value Time)
3. Position X on the trajectory (table Value, value Value)
1.
2.
The trajectory is defined by the origin-destination of the data collector.

Unit of measure: meters.
Label : Space-Time.
244
STORAGE
OF THE VALUES MEASURED
Storage of the values measured

All the measurements collecting during the simulations of the same project are stored in a Dynasim.db file
located on the project root (see Creating a project, page 38), in SQLite 3.x format (http://www.sqlite.org).
SQLite is a library written in C language that provides an SQL database engine. Unlike database servers, it is
not confined to the customary client/server schema since it is integrated directly in the programs, and uses
files. The entire database is stored in a single file. SQLite essentially observes the SQL 92 standard. A
large number of applications or interfaces can be used to extract the data stored in an SQLite database.
This section discusses the following:
Data model, page 245,

SQL queries, optimization, page 248,
Installing an ODBC driver, page 249,
Extracting data using OpenOfficeTM, page 252,
Extracting data using ExcelTM, page 254,
Tables generated at the end of the simulation, page 256.
This section gives a general description of how the data specific to a CubeDynasim simulation project is
organized.
In an SQL relational database, all the data is stored in tables, which can be interlinked. The tables have a certain number of columns, or fields, that describe unique n-tuplets (rows or records). The relations between the
tables are defined according to significant fields called keys. There are two types of keys:
Primary keys: used to identify a single n-tuplet in a table.
2. External keys: an attribute of an n-tuplet which is a primary key in another table. External keys
are thus used to link tables to one another.
1.
In a relational database, the goal is to separate information as much as possible to avoid duplicates and
redundancy, and to prevent the loss of information quality. The data model defines how the measurements
collected are broken down into tables and fields (see "Data model schema", fig.158 p.246)
.
The data specific to a simulation project is broken down into seven tables. The primary key identifiers
always start with "Nid". The external keys have the same identifier as the primary keys they reference in the
original table.
245
DATA COLLECTORS
Data model
S T O R A G E
Figure 158. Data model schema
246
CriterLabel
defines a relationship between a criterion and a primary key
NidCriter
primary key
Label
label of the criterion measured, e.g. Flow
StatLabel
defines a relationship between a statistic process and a primary key
NidStat
primary key
Label
label of the statistic process, e.g. Mean
Para
numeric parameters, e.g. 0.5 for the median
Criteria
defines a primary key for each statistic process-criterion association
NidCriterStat
primary key
NidCriter
external key (table CriterLabel) the defines a criterion
NidStat
external key (table SatLabel) that defines a statistic process
STORAGE
ScSimul
defines a primary key specific to the simulation scenarios
NidSimul
primary key
IdGeom
identifier of the network scenario (Network scenarios, page 65)
IdFlow
identifier of the flow scenario (Flow scenarios, page 110)
IdTL
identifier of the signal scenario (Signal scenarios, page 308)
IdPT
identifier of the public transport scenario (Public transport scenarios, page 277)
GroupCollector
defines a primary key for each data collector in the project
NidGroup
primary key
IdGroup
identifier of the group
IdCollector
identifier of the data collector
IdF1
identifier of the trajectory on which the ad hoc subnetwork is located
Pk
position of the trajectory on which the ad hoc subnetwork is located
247
Replication
defines a primary key for the replications of the project
NidRep
primary key
NRep
replication number. The first simulation scenario replication is numbered 0
NidSimul
external key (able ScSimul), replication simulation scenario
NoBlock
Boolean, if true, the replication does not self-lock (i.e. no gridlock). If the replication is
being calculated, the value is TRUE.
Seed
value of the random seed used for this replication. This value is not initialized for the first
value
NextSeed
value of the random seed used for the next replication. If this field is not initialized, the
replication did not finish
Error
number of errors recorded during the replication
Anim
Boolean: True if an animation corresponding to this replication is available
Value
stores the values noted
NidValue
primary key
NidGroup
external key (table GroupCollector), the values data collector
NidCriterStat
external key (table Criteria), criterion and statistic process
NidRep
external key (table Replication), replication during which the measurement was taken.
Used to find the corresponding simulation scenario
Time
number of seconds since the start of the simulation at moment when the measurement is
taken
Value
measurement value
DATA COLLECTORS
In the GroupCollector table, for the measurements applied on an entry-exit subnetwork, fields IdF1
and Pk are initialized by an empty string.
S T O R A G E
SQL queries, optimization

SQL is used to extract the data stored in the database. This section gives some examples of standard queries
used for this purpose.
To extract all the data in the Value table:
EXAMPLE:
SELECT * FROM Value

Generally speaking, you will want to extract a set of values determined on the basis of the criterion measured, the statistic process, and the simulation scenario. In this case, you must define the joins in accordance
with the Data model schema, page 246:
EXAMPLE:
JOIN Criteria ON Value.NidCriterStat = Criteria.NidCriterStat

JOIN CriterLabel ON Criteria.NidCriter = CriterLabel.NidCriter
JOIN StatLabel ON Criteria.NidStat = StatLabel.NidStat
JOIN Replication ON Value.NidRep = Replication.NidRep
JOIN ScSimul ON Replication.NidSimul = ScSimul.NidSimul
JOIN GroupCollector ON GroupCollector.NidGroup = Value.NidGroup
Depending on the criterion, you will usually have to add a condition to go beyond the threshold values:
EXAMPLE:
Value.Value >-100 000

Similarly, to extract the data from a simulation scenario, you must specify the conditions on the 4 scenario
types, even if they have not all been defined. If the project contains two simulation scenarios that differ
merely by the presence - or absence - of a Public transport scenarios, page 277, and if, when defining the
query, you do not specify a condition on the public transport scenario, you will obtain all the values measured for both scenarios. If the scenario is not defined, the corresponding field is an empty character string.
EXAMPLE:
ScSimul.IdPT =
When extracting flow values, you must distinguish the Flow, page 236 from the Flow by lane,
page 240. The condition is established on the definition of the GroupCollector field. IdF1.
To extract the flows from a subnetwork, the condition is expressed as follows:
EXAMPLE:
CriterLabel.Label =Flow AND GroupCollector.IdF1 =

To extract all the lane flows, the condition is expressed as:
EXAMPLE:
CriterLabel.Label =Flow AND GroupCollector.IdF1 < >

Usually, you will not want to consider values recorded in replications that are self-blocking, that contain
error messages, or that did not reach the end of the measurement period. Here, you must add the conditions
on the fields in the Replication table.
EXAMPLE:
Replication.Error = 0
AND Replication.NoBlock =TRUE
AND Replication.NextSeed > 0
Calculate the average travel speed from all the travel times for all the data collectors in the "CR" group in
simulation scenarios with the "Geom" geometry and the "F" flow scenario:
EXAMPLE:
248
SELECT GroupCollector.IdCollector, AVG (Value. Value) FROM Value
JOIN Criteria ON Value.NidCriterStat = Criteria.NidCriterStat

JOIN CriterLabel ON Criteria.NidCriter = CriterLabel.NidCriter
JOIN StatLabel ON Criteria.NidStat = StatLabel.NidStat
STORAGE
JOIN Replication ON Value.NidRep = Replication.NidRep

JOIN ScSimul ON Replication.NidSimul = ScSimul.NidSimul
JOIN GroupCollector ON GroupCollector.NidGroup = Value.NidGroup
WHERE Replication.Error = 0
AND Replication.NoBlock =TRUE AND Replication.NextSeed > 0
AND Value.Value >-10000
AND ScSimul.IdPT =
AND ScSimul.IdTL =
AND ScSimul.IdGeom =Geom
AND ScSimul.IdFlow =F
AND CriterLabel.Label =Travel speed
AND StatLabel.Label =All
AND GroupCollector.IdGroup =CR
GROUP BY GroupCollector.IdCollector
Installing an ODBC driver
249
DATA COLLECTORS
The ODBC driver enables communication between an SQL database management system and an application. Applications access the driver via a dynamic library. This library is specific to each database system,
and must be installed on the client machine. You must therefore install the ODBC for SQLite driver (download from: http://www.ch-werner.de/sqliteodbc.exe). This operation must be performed in one go.
S T O R A G E
Defining a data source

After installing the driver, you must add a data source for the simulation projects database so that it can be
managed via a client software application.
For example, in Windows XP:
Select Start, Control Panel, Administrative Tools, ODBC Data Source (32 bit).
2. Select the System DSN tab and click Add.
1.
250
3.
Select SQLite 3 ODBC Driver and click Finish.
4.
Choose the data source name (DSN) that will be used by other applications to identify the database.
STORAGE
Define the database files physical location.

6. Select the Dont Create Database option.
7. Click OK.
5.
DATA COLLECTORS
251
S T O R A G E
Extracting data using OpenOfficeTM

OpenOfficeTM is a free, open-source office suite (http://www.openoffice.org) containing six modules. This
section shows you how to extract data from a simulation project and import it to an OOCalcTM sheet, i.e. the
OpenOfficeTM spreadsheet application.
Firstly, you must define an OpenOffice database that accesses the SQLite database (see Defining a data
source, page 250) via ODBC. The OpenOffice database can also be used to store queries.
2.
Run OOBase.
Select the Connect to an existing database option, select ODBC, then click Next.
3.
Click Browse to select a data source.
4.
Click Test Connection, then click Finish.
1.
252
STORAGE
Save the OOBase database in the Save As dialog box.

6. Click on queries to add them to the database. For example, select Create tables using the table
wizard.
5.
8.
253
DATA COLLECTORS
Add all the data model tables.

Define the joins by dragging the primary keys to the corresponding secondary keys (see "Data
model schema", fig.158 p.246).
9. Define queries and save them with an easily identifiable name.
10. Use OOWriter to directly insert the results of your queries written in text documents, or OOCalc
to directly retrieve the data extracted from the database in a spreadsheet.
7.
S T O R A G E
Extracting data using ExcelTM

After defining the simulation projects database as the ODBC data source, you can easily extract data to an
ExcelTM sheet using Microsoft QueryTM. When the database content is modified, the data extracted is directly
updated accordingly.
254
1.
Select the Data tab, then From Other Sources, then From Microsoft Query.
2.
Choose the data source (see Defining a data source, page 250).
3.
Click OK to acknowledge the message displayed.
4.
Click Cancel.
STORAGE
5.
Click Yes.
6.
Microsoft Query starts. In the Add Tables dialog box, click Options....
7.
In the Table Options dialog box, select Tables, Refresh and click OK.
8.
In the Add Tables dialog box, add the following tables: Criteria, CriterLabel, GroupCollector,
Replication, ScSimul, StatLabel and Value by selecting the corresponding table then clicking
Add.
DATA COLLECTORS
255
S T O R A G E
9.
10.
To finish off, click Close.

At this stage, the correspondence calculated by SQL Query between the primary keys and external
keys is incomplete and invalid :
Delete the link connecting the "Label" fields in the "CriterLabel" and "StatLabel" tables by selecting the link then pressing the Del key on the keyboard.
Establish the links by dragging the primary key to the external key for the following:
Table
Table
primary key
external key
Key identifier
Criteria
Value
NidCriterStat
GroupCollector
Value
NidGroup
Replication
Value
NidRep
ScSimul
Replication
NidSimul
You are advised to save the *. sqly file to avoid having to redo these operations. At this stage, use
the SQL Query application to extract the data you are interested in. Click the
button to export
TM
the result of the query to Excel .

The values proposed as search criteria will be inoperative if they contain any accents. In this case, you
must modify the accent character manually.
Tables generated at the end of the simulation

Standard tables are generated at the end of the replications. The tables calculated are saved in files:
in CSV format, using the semicolon " ;" as the column separator.
whose name adheres to the format <group name> <type of table>.csv. For example: CRTravelTime.csv, corresponds to the TravelTime table for all the data collectors contained in the CR group.
saved in directory <project>/<simulation scenario directory>/results (see "Tree structure of CubeDynasim projects", fig.22 p.39).
The rows and columns in the tables generated correspond respectively to the data collectors and criteria
extracted from the replications for the scenario concerned. Only data for which the simulation end time was
reached is accepted (Replication. NextSeed < >), and that did not cause any blocks (Replication. Noblock =
TRUE). However, data from replications that generated errors (no condition expressed on replication, error
when extracting data) is integrated in the tables. You must make sure that any errors have no impact on the
results. You can import these tables dynamically to a document or spreadsheet to apply the appropriate page
layout and format. For each table type, there is a header file in csv format that defines the column headers.
These files are saved in directory <project>/<simulation scenario directory>/<results >/<table name>.csv.
256
STORAGE
This section describes the data for each table type generated:
Group table, page 257

Table of inter-vehicle times, page 257
Table of speed times, page 258
Table of travel times, page 258
and Importing the tables in ExcelTM, page 258

Group table
Statistic
criterion in simulation
Statistic
process
Unit
Demand
Deficit, page 236
Offer
Deficit, page 236

All
Mean
Deficit
Deficit, page 236

All
Mean
Average delay
Delay, page 237

All
Mean
seconds
Maximum delay
Delay, page 237

All
Percentile 90
seconds
Average queue
Queue, page 240

All
Mean
meters
Maximum queue
Queue, page 240

All
Percentile 90
meters
number of vehicles
number of vehicles
DATA COLLECTORS
Table of inter-vehicle times
257
Statistic
Statistic
process
Unit
Mean inter-vehicle time
Inter-vehicle times, page 241

All
Mean
seconds
Inter-vehicle time standard

deviation

All
Standard
Deviation
seconds
Inter-vehicle time percentile 10

All
Percentile
10
seconds

All
Percentile
50
seconds

All
Percentile
90
seconds
S T O R A G E
Table of speed times
Statistic
Statistic process
Unit
Minimum travel time
Travel time, page 239

All
Percentile
10
seconds
Mean travel time

All
Mean
seconds
Maximum travel time

All
Percentile
90
seconds
Mean delay
Delay, page 237

All
Mean
seconds
Delay standard deviation
Delay, page 237

All
Standard
Deviation
seconds
Mean speed
Travel speed, page 240

All
Mean
km/h
Speed standard deviation
Travel speed, page 240

All
Standard
Deviation
km/h
Statistic
Statistic process
Unit
Mean travel time

All
Mean
seconds
Minimum travel time

All
Min
seconds
Maximum travel time

All
Max
seconds
Travel time standard deviation

All
Standard
Deviation
seconds
Travel time percentile 10

All
Percentile
10
seconds
Travel time percentile 90

All
Percentile
90
seconds
Table of travel times
Importing the tables in ExcelTM

Importing the tables to a third-party spreadsheet application such as ExcelTM should:
Facilitate the formatting of the tables (value display format, fonts, borders, graphics, etc.)
Allow post-processing operations on the numeric values.
3. Establish a dynamic link between original csv files. If you need to simulate the scenario again, all
the tables are updated automatically.
1.
2.
258
STORAGE
This section describes the steps for importing the tables in ExcelTM.
Select the Data tab, then From text.
2.
Select the table sheet from the Import Text File dialog box.
3.
Define the original data type as Delimited.
4.
Select Comma as the separator.
DATA COLLECTORS
259
1.
S T O R A G E
260
5.
Click Properties....
6.
Define the external data range parameters: Refresh data on file open, Preserve cell formatting.
STORAGE
261
Click OK in the External Data Range Properties window.
DATA COLLECTORS
7.
R E P R E S E N T A T I O N
OF DATA COLLECTORS AND EDITING THEM
Representation of data collectors and editing them

Data collector representation and associated elements
Measurements requiring ad hoc or entry-exit subnetworks correspond to CubeDynasim data collectors.
They are defined by entry markers and exit markers.
Like the Stop line, page 202, markers comprise a series of line segments. Markers are applied on the lanes
in Trajectories, page 81, and on the Stages, page 71.
The intersections of the entry/exit markers and the elements in the model determine all the entry/exit points
on an entry-exit subnetwork.
The intersections of the exit markers with the lanes in the Trajectories, page 81 define the number of ad
hoc subnetworks.
The data collectors are contained in a group to facilitate the analysis and viewing of the simulation results. A
data collector belongs to a single group, whereas the group can contain an unlimited number of data collectors. The group is referenced by a layer. It is identified by a unique name among all the groups belonging to
the same layer (see Using layers and network scenarios, page 62). This feature means you can have the same
names for a "group-data collector" pair in two different layers, corresponding to the quantification of two different geometric configurations of the same development. The time sample and the criterion-statistics pairs
are also defined for the group.
If a network scenario contains two data collectors with the same Group and Data Collector names, the
simulator will only consider the first one, and will produce a simulation error. This situation is usually
due to a geometry scenario containing two layers with what appears to be the same group.
Data collectors are simulation objects viewed in geometric mode in the Network edit area, page 19. Only
the last exit marker created is displayed to represent a data collector. When you position your cursor on this
marker, all the markers, i.e., the entry and exit markers of the data collector, are displayed on the map. Furthermore, the message in the format: Data collector: <group> <data collector> is displayed in the message
area. The name <group> corresponds to the name of the group associated with the data collector.
Each marker is associated with an icon whose color identifies the markers type. The convention used for
these color codes is that applied to identify the Network origins & destinations, page 67, i.e.
blue for
entry markers, and

red for exit markers. In pointed mode, the straight segments that make up a marker
are displayed in yellow, otherwise they are displayed in blue (see "Representation of data collectors in the
edit area", fig.159 p.263).
262
REPRESENTATION
Last exit marker
Data collector
Multilane
Exit marker icon
Exit markers
Data collectors in pointed mode

with two exits and three entries
Entry marker icon
Entry marker positioned

to take account of
vehicles waiting at the
entry to the network
Stage
Single lane
Figure 159. Representation of data collectors in the edit area
263
DATA COLLECTORS
Entry markers
Creating a data collector

1.
fig.1 p.14).
Click the Data Collector button

data collector mode.
3. Create an entry marker:
2.
on the Simulation object bar, page 17 to activate create
To add a marker, click the location in the Network edit area, page 19 where you want to position the marker icon.
b. Either:
- left-click to add a new segment
- right-click to finish editing the marker.
a
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Either:
- Add a new entry marker 3.) a.),
- Right-click in the Network edit area, page 19 to switch to create exit marker mode.
Create an exit marker by following the procedure described in step 3.) a.).
Either:
- Add a new exit marker 3.) a.),
- Right-click in the Network edit area, page 19 to display the "Data collector entry window
in Group mode" (see fig. 160, page 267).
If necessary, add a group: Creating/Editing/Deleting a group, page 265,
otherwise, in the group list area, select the group with which you want to associate the data collector being created.
Click Data collector to display the "Data collector entry window in Data Collector mode" (see
fig. 161, page 268).
Fill in the fields for the data collector in the edit area (see Data collector parameters,
page 267)., page 268.
Click Add to add the data collector to the list of collectors in the group.
Click Group to display the "Data collector entry window in Group mode" (see fig. 160,
page 267).
Click Apply to apply your changes.
You cannot interrupt the data collector creation process.

When you have finished adding a data collector, the application is in Create data collector entry
marker mode. Clicking in the Network edit area, page 19, will trigger the irreversible procedure for
creating a new data collector. When you have finished creating your data collectors, remember to
change the applications mode, for example, to Edit Object mode, page 20.
To calculate the travel time matrix, position an open data collector for each cell in the origindestination table such that:
1. its entry markers cross the stages connected to the origins corresponding to the row of the cell.
2. its exit markers bisect all the trajectory lanes linked to the exit corresponding to the column of the cell.
Editing a data collectors geometry

This section describes the various operations for modifying a data collectors geometry:
Modifying the position of all the markers associated with a data collector, page 265
Modifying the position of a single marker associated with a data collector, page 265
Modifying the geometry of a marker associated with a data collector, page 265
264
REPRESENTATION
Modifying the position of all the markers associated with a data collector
fig.1 p.14).
2. ActivateEdit Object mode, page 20.
3. Position the pointer on the exit marker displayed in the Network edit area, page 19.
4. Drag to the new position, then release.
1.
Modifying the position of a single marker associated with a data collector

1.
2.
3.
4.
5.
fig.1 p.14).
ActivateEdit Object mode, page 20.
Select the data collector by clicking its exit marker in the Network edit area, page 19.
Position the pointer on the marker to move (it is displayed in yellow).
Drag to the new position, then release.
Modifying the geometry of a marker associated with a data collector

1.
2.
4.
5.
You cannot add or delete:

1. markers to/from a data collector,
2. segments to a marker associated with a data collector.
The data collector entry window

Use the data collector management window to edit all the non-geometric parameters of collectors in the project. This window is accessible:
when creating a data collector,

when editing a data collector,
by clicking the
icon on the Module bar, page 18.
The data collector entry window is a Module entry window, page 27 comprising three statuses used
respectively for:
Creating/Editing/Deleting a group, page 265,

Editing/Deleting a data collector, page 267,
Editing the criteria measured for a group, page 269.
This section describes how to access each of these statuses, the possible operations and the various parameters.
Creating/Editing/Deleting a group
The list area in the "Data collector entry window in Group mode" (see fig. 160, page 267) shows all the
groups defined for the current Network scenarios, page 65.
265
DATA COLLECTORS
3.
fig.1 p.14).
ActivateEdit Object mode, page 20.
Select the data collectors exit marker in the Network edit area, page 19,
Position the pointer on one of the selection squares of the marker to modify.
Drag as appropriate, then release.
GROUP PARAMETERS
LABEL
Name
Sample
DESCRIPTION
Unique name of the group among all groups associated with the current network.
It is saved in the database for the "IdGroup" field in the GroupCollector table.
Measurement sampling duration in seconds.
Layer
The layer associated with the groups data collectors, chosen from all the layers in the current
Network scenarios, page 65 (see Single-choice list field, page 32).
Tables
Defines the type of the Tables generated at the end of the simulation, page 256 for this
group. The criteria and statistics required to establish the selected tables are automatically chosen.
Creating a new group

Click the
button on the Module bar, page 18 to display the "Data collector entry window in
Group mode" (see fig. 160, page 267).
2. Complete the Group parameters, page 266.
3. If necessary, remove any duplicate data collectors by following the procedure below:
1.
Click the Data collectors button and switch to edit group mode.
b. Click Delete to empty the list of data collectors.

c. Click Group to switch back to Group mode.
4.
Click Add to add this new group.
Duplicating a group
Click the
button on the Module bar, page 18 to display the "Data collector entry window in
2. Click the name of the group displayed in the group list area.
3. Enter the groups name. Edit the other fields as appropriate.
4. Click Add to add the group. All its data collectors are duplicated.
1.
Deleting a group
To edit the parameters of an existing group, or to delete it, following the procedure described to modify an
element, page 28, or to delete an element, page 28.
To duplicate a group and all its data collectors in two different geometry scenarios:
1. Create a temporary network scenario with the original layer and the target layer for the duplicated group.
2. Select this new network scenario as the current scenario.
3. Select the group to duplicate in the "Data collector entry window in Group mode" (see fig. 160,
page 267).
4. Select the target layer.
5. Click Add to duplicate the group.
The duplicated group and the original group must have different names if they are intended for the
same network scenario.
266
REPRESENTATION
Group
list area
Group
edit area
Figure 160. Data collector entry window in Group mode
Editing/Deleting a data collector

You use the "Data collector entry window in Data Collector mode" (see fig. 161, page 268) to edit a data
collectors parameters, as well as to delete or duplicate it.
DATA COLLECTOR PARAMETERS

LABEL
DESCRIPTION
Name
Unique name of the data collector among the groups data collectors.
It is saved in the database for the "IdCollector" field in the "GroupCollector" table.
Open
Specifies whether the collection point is open or closed.
Self-locking
test
Determines whether or not this data collector is integrated in the self-blocking test ("autoblock"), defined as follows:
if the flow is null whereas the number of vehicles present is non-null, and for a duration
greater than the self-blocking duration, the replication is marked as being selfblocked for this road.
The criteria (Number of vehicles present, Flow) that define an autoblock are automatically
selected for all the data collectors in the group, even if they are not all selected for the selfblocking test.
Order
Zones
267
Defines the order in which data collectors are displayed in the Tables generated at the end
of the simulation, page 256.

Defines a subset of zones. If the subset is non-empty, only vehicles with a destination inside
one of the zones in the subset are considered by the data collector (see Multiple-choice list
field, page 33).
DATA COLLECTORS
Command
area
DATA COLLECTOR PARAMETERS

LABEL
DESCRIPTION
Destinations
Defines a subset of destinations. If the subset is non-empty, only vehicles with a destination
that belongs to this subset are considered by the data collector (see Multiple-choice list field,
page 33).
Categories
Subset of categories considered by the data collector. If the subset is empty, all the vehicle categories are considered by the data collector a priori (see Multiple-choice list field,
page 33).
If the destinations, zones and categories subsets are not empty, only vehicles that satisfy the
conditions on the destination and the vehicle category will be considered.
Data collector
list area
Data collector
edit area
Command
area
Figure 161. Data collector entry window in Data Collector mode
To edit a data collector in the "Data collector entry window in Group mode" (see fig. 160, page 267) (see the
procedures for Creating a data collector, page 264, or Creating/Editing/Deleting a group, page 265).
1.
2.
3.
4.
5.
6.
In the list area of the "Data collector entry window in Group mode" (see fig. 160, page 267),
select the group associated with the data collector to edit.
Click Data Collectors in the command area to switch the entry window to Data Collector mode.
Fill in the fields for the data collector in the edit area (see Data collector parameters, page 267).
Confirm your entry by clicking:
Add, to add a new data collector
or Apply, to modify the selected data collector,
or Delete, to delete the selected data collector.
Click Data Collectors.
Click Apply to confirm the changes to the data collector for the selected group.
If the identifier of a group or of a data collector is modified, the results calculated up until then for
this data collector are no longer accessible for viewing. You must restart the replications for all the
network scenarios that include the layer associated with this group.
268
REPRESENTATION
Editing the criteria measured for a group

Use the "Data collector entry window in Criteria mode" (see fig. 162, page 269) to define the criteria noted,
and their statistic processes, for each group. The list area contains the criteria as rows, and the associated processes as columns.
Criteria
list area
Command
area
Figure 162. Data collector entry window in Criteria mode
For example, to add the percentile 0.95 of the travel speed to all the values noted for a group:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
269
Click the
button on the Module bar, page 18 to open the "Data collector entry window in
In the list area, select the name of the group to modify.
Click Criteria in the command area to switch the entry window to Criteria mode.
In the criteria list area, click the row corresponding to the Travel speed criterion.
To add or remove statistic processes, click
or
respectively.
To add a percentile : click the Next button opposite the Percentile label to open the "Percentile
entry window" (see fig. 163, page 270).
Enter 0.95 in the Value field, then click Add.
Click Criteria to display the "Data collector entry window in Criteria mode" (see fig. 162,
page 269).
Click Apply to confirm your changes.
Click Back to display the "Data collector entry window in Group mode" (see fig. 160, page 267).
Click Apply to confirm.
Click Quit to close the "Data collector entry window in Group mode" (see fig. 160, page 267).
DATA COLLECTORS
Selected
criterion
edit
area
Figure 163. Percentile entry window
270
12
Public transport module
This chapter describes the following:
271
Stop, page 272,

Public transport scenarios, page 277,
Public transport module management window, page 279,
Timetable, page 284.
PUBLIC TRANSPORT
MODULE
Public transport (PT) structures most urban projects in terms of both their geometry and their operation
mode. Between a current situation and a projected infrastructure, planners and engineers are called on to test
the redeployment of public transport lines, or the insertion of specific bus or tramway sites. CubeDynasim
takes account of these different possibilities through public transport scenarios, which define a set of PT
lines and which are the fourth - optional - component of the simulation scenarios (see Simulation module,
page 403).
S T O P
Stop
A stop is defined by:
The location of its stop line, identified by a stop line marker on a trajectory lane.
2. Its stop time, determined by a parameter distribution law (standard threshold log):
1.
minimum threshold
b. average
c. maximum threshold
d. standard deviation
a
Conditions specifying which lines make their stop at this location.

4. A possible schedule.
5. A probability that the lines specified via a condition make the stop.
3.
Two types of simulation object authorize brief stops on a road:
Transit stops, page 272, which are only active for PT vehicles,
Tolls, page 274, which are active for all types of vehicle.
Transit stops
The transit stop is a simulation object edited in geometric mode. Its graphic representation is displayed in the
Network edit area, page 19 in geometric mode only. It is represented by a stop line marker see Geometric
representation of a transit stop, page 272.
Stop line marker on the lane

(at the start of the stop)
Transit stop
Figure 164. Geometric representation of a transit stop

Creating a transit stop
272
1.
Switch to geometric mode (see "Main CubeDynasim window in geometric mode", fig.1 p.14).
2.
Click the
3.
In the Network edit area, page 19, position the pointer at the location on the trajectory where
the stop line is to be placed (the trajectory concerned switches to pointed mode). Left-click to create the transit stop with the parameters from the last transit stop you edited, and to assign all the
PT lines, page 278 to stop at this stop.
button on the Simulation object bar, page 17 to activate create transit stop mode.
STOP
Editing a transit stop
To edit a transit stop, see Edit Object mode, page 20:
Display the "Transit stop entry window" (see fig. 165, page 273).
2. Place the stop in a layer.
3. Fill in the fields representing an Integer numeric value field, page 31 corresponding to the
parameters of the transit stop distribution rule:
1.
The Stop zone length (m) defines the distance before the stop line where the bus stop begins.
b. The Length of Zone of Approach (m) defines the distance before the stop line during which PT
vehicles can decelerate to stop.

c. Minimum Time (s)
d. Mean Time (s)
e. Maximum Time (s)
f.
Standard Deviation of Time
Assign the stop for the PT lines defined previously (see Creating/Editing/Deleting a PT line,
page 280): all the lines are selected by default.
5. Assign (optionally) a Timetable, page 284. If the PT is ahead of schedule on the timetable, it
will stop for the period defined previously and will wait according to the timetable before setting
off again. If the PT is behind schedule, it will only stop for the period defined by the distribution,
itself defined by the stop parameters.
6. Specify (optionally) a stop probability percentage.
7. Click OK to confirm.
4.
Stop times
(distribution rule
parameters)
PT lines assigned
to the stop
Schedule
Figure 165. Transit stop entry window

If a PT line is created after creating a transit stop, it will not be assigned to this stop. Thus, it is more
practical to create the PT lines first, then the transit stops.
To delete a transit stop, see Edit Object mode, page 20.
A transit stop is effective 20 m before the stop line. If a PT vehicle assigned to the stop stops in the stop zone,
it alights and boards its passengers for the distribution laws stop time. When it starts off again, it will not
273
Stop parameters
PUBLIC TRANSPORT
MODULE
Layer
S T O P
stop at the stop line. Applicable to all the PT vehicles assigned to the stop which enter the stop zone, this feature enables you to correctly simulate the stops of multiple correspondences.
Tolls
The Toll simulation object is used to model a stop at a toll, at a parking lot barrier, on the actual parking lot or
for a delivery. It is edited in geometric mode. Its graphic representation is displayed in the edit area in geometric mode only. It is represented by an icon with a vehicle aside a toll, and by a stop line marker. The toll
object can stop all types of vehicles (see Geometric representation of a toll, page 274).
Toll
Toll stop on the lane
Figure 166. Geometric representation of a toll

Creating a toll
Proceed as follows to create a toll :
1.
2.
Activate edit stop mode from either of the following:
a The Menu bar, page 14, select Objects > Stop > Toll.
b. The Simulation
3.
icon.
In the edit area, position your pointer on the spot on the trajectory where you want to position the
stop line (the trajectory concerned switches to the pointed state), then left-click to create the toll
with the parameters saved beforehand.
Editing a toll
Proceed as follows to edit a toll, see Edit Object mode, page 20:
1.
2.
Display the "Toll entry window" (see fig. 167, page 275).
Fill in the fields that represent an Integer numeric value field, page 31 corresponding to the
parameters of the transit stop distribution rule:
Minimum Time (s)
b. Mean Time (s)
c. Maximum Time (s)
d. Standard Deviation of Time
a
e. Conditions is a Prohibitor
field, page 171, used to define the subset taken into account to
assign the toll to specific destinations or vehicle categories (all by default).
It represents an AND condition between the destinations and the categories.
274
STOP
Layer
Stop parameters
Stop times
(distribution rule
parameters)
Destinations or categories
that stop at the toll
Figure 167. Toll entry window
As opposed to transit stops, if two vehicles concerned by the toll arrive one behind the other at the toll, they
will successively carry out their transaction at the toll line according to the toll time distribution law.
Incidents
The Incident simulation object is used to model the stopping of a vehicle on the road for a set period of time.
Vehicles that arrive at the location of the incident are automatically diverted to the adjacent roads. The first
vehicle to arrive at this location and that satisfies the incident object's stop conditions stops until the end time
specified in the object. For vehicles that arrive at the location thereafter, the simulation proceeds as if there
were one lane less on the multilane where the incident has occurred. Thus, vehicles must change lanes to
continue on their way.
Trajectory
taken during
the incident
period
Incident
Lane removed
during the
incident period
Figure 168. Graphic representation of an Incident
275
PUBLIC TRANSPORT
MODULE
To delete a toll, see Edit Object mode, page 20.
S T O P
Creating an incident
1.
2.
Click the
button on the Simulation object bar, page 17 to activate create incident mode.
In the edit area, position your pointer on the spot on the trajectory where the stop line is to be
placed (the trajectory concerned switches to pointed mode).
4. Left-click to create the incident with the parameters saved beforehand.
3.
Editing an incident
Proceed as follows to edit an incident, see Edit Object mode, page 20:
1.
2.
Display the "Incident entry window" (see fig. 169, page 276).
Fill in the Time fields :
a Incident starting hour: the first vehicle to arrive at the incident that satisfies the stop conditions
stops accordingly.
b.
Incident ending hour.
Conditions is a Prohibitor field, page 171, used to define the subset taken into account to assign the incident to the first vehicle (by destination or vehicle category). By default, the incident is assigned to the first
vehicle that arrives there.
Layer
Incident duration
Conditions for applying the stop
Figure 169. Incident entry window
Terminus
The terminus enables a PT line to turn around. It involves a stop time, and is characterized by the following:
A trajectory.
2. Its stop time, determined by a parameter distribution law (standard threshold log):
1.
minimum threshold
b. mean
c. maximum threshold
d. standard deviation
3.
A new PT line.
The terminus has two handles and a trajectory between them.

The first handle can be seen as a double handle; one in the direction in which the object was created, the
other in the opposite direction. The first origin handle serves to receive a trajectory associated with the PT
road network in the direction of the arrival; the second origin handle serves to initiate a trajectory to the PT
road network in the direction of the departure.
The second handle is never reached by the PT. It defines the trajectory on which it will perform its turnaround.
276
STOP
You must link each Terminus with the Destinations, page 74 object of the PT line that arrives at the terminus via the Speed link, page 159.
The terminus can be associated with a Timetable assignment, page 286 to update the departure times.
Terminus 1
Terminus 2
Geometric mode
East exit
West exit
Terminus 3
Terminus 4
Logical mode
Figure 170. Use of the terminus

Creating a terminus
1.
2.
Click the
3.
Click at the junction point of the 2 lanes on the PT line to open theTerminus entry window,
page 277 and fill in the Name, Layer and Destination fields
button on the Simulation object bar, page 17 to activate create terminus mode.
Figure 171. Terminus entry window

4. Click OK to confirm and continue.
5. Orient the original handle and left-click to confirm your orientation.
6. Move the mouse and left-click to position the end of the way at the terminus.
7. Orient this handle and left-click to finish the terminus
..
The length of the Terminus must be greater than that of the vehicle category using it.
Public transport scenarios

Public transport scenarios are used to define a set of PT lines, i.e. to specify the following for each PT line:
its journey from an entry to an exit,

the rolling stock used and its proportion on the line,
the frequency of the line.
277
New destination to assign to the PT line

that arrives at the terminus
PUBLIC TRANSPORT
MODULE
Terminus name
Layer
S T O P
This section describes:
the Rolling stock, page 278,

the parameters of theHeader, page 278 of a PT scenario,
the parameters of thePT lines, page 278.
Rolling stock
Four categories of rolling stock are available initially: standard bus, articulated bus, 2-car tramway, and 3-car
tramway, described in the table Rolling stock categories, page 278.
TABLEAU 3. Rolling
Name
stock categories
Category
Length
(m)
Standard bus
TC_STD
12
Articulated bus
TC_ART
18
2-car tramway
TRAM
30
3-car tramway
TRAMTR
45
Header
A PT scenario header contains the parameters used to transfer the scenario to the models other components,
in particular to the simulation scenarios.
The headers parameters are as follows:
The scenario name, unique to all the PT scenarios in the study. It is used when defining the "Simulation module entry window in Edit scenario mode" (see fig. 209, page 406),
2. A comment describing the specificities of the scenario.
1.
PT lines
A PT scenario comprises a set of PT lines.
The following parameters define a PT line:
1.
2.
3.
4.
5.
The lines name. It can be reused by other lines with a different destination. For example, for the
lines opposite direction or a line with several destinations.
The lines departure point, which is an Origins, page 69.
The lines arrival point, which is an Destinations, page 74.The name+arrival combination
which specifies the line is unique among all the lines in the PT scenario. It is used when defining
Transit stops, page 272.
The type of rolling stock assigned to the line, which can be single or combined.
The PT generation frequency, which can either be fixed or variable with a random variance (early
or late) in relation to this schedule.
The PT line creates its own origin, and links it with the first object linked to the origin specified at the
lines departure point. Prohibitors, page 168 are ineffective for PT on the link between the
departure point and the object associated with it.
The lines first PT is generated randomly during its first period, even in the case of a fixed frequency:
the replications will not reproduce the same sequence (see Simulation module, page 403).
278
PUBLIC
TRANSPORT MODULE MANAGEMENT WINDOW
Public transport module management window

The PT module management window is used to add, edit and delete PT scenarios.
You access the PT module entry window from either of the following:
The Menu bar, page 14, select Utilities > P.T.,

The Module bar, page 18, click the
icon.
The PT data entry window is a Module entry window, page 27. It consists of two windows, one listing the
PT scenarios and the other listing the PT lines associated with the selected scenario and the data associated
with each line.
The PT Line button switches from the Scenario window to the PT Lines window. Once in the PT Lines window, the Back button switches the window back to the Scenario window.
The parameters of the Header, page 278, and the PT lines, page 278, are respectively displayed in the
PT scenario and PT line list areas.
Creating/Editing/Deleting a PT scenario
To create a PT scenario, proceed as follows in the PT module management window:
1.
in the edit area, fill in the fields corresponding to theHeader, page 278:
a Scenario name: use an alphanumeric name with no special characters or spaces; the first character
must be alphabetic,
Comment: free entry text field.

2. Click Add to add the PT scenario (see "PT management window in PT scenario edit mode",
fig.172 p.279).
a
PT scenario
list area
PT scenario
edit area
Command
area
Figure 172. PT management window in PT scenario edit mode
279
Creating/Editing/Deleting a PT scenario, page 279,

Creating/Editing/Deleting a PT line, page 280.
PUBLIC TRANSPORT
MODULE
This section describes the procedure to follow to edit PT scenarios and PT lines using the PT module management window :
P U B L I C

To edit the parameters of a PT scenario already created, or to delete the scenario, follow the procedures
described to respectively modify an element, page 28, and delete an element, page 28.
You cannot delete a PT scenario if at least one simulation scenario refers to it.
Creating/Editing/Deleting a PT line
To create a PT line from the PT module entry window, proceed as follows
Select the PT scenario which refers to the PT line, then click PT Lines to go to the PT lines edit
page.
2. Fill in the fields in the edit area corresponding to the PT lines, page 278:
1.
Line name, use an alphanumeric name with no special characters or spaces; the first character must
be alphabetic,
b. Origin: Single-choice
list field, page 32 to be selected from the Origins, page 69,

list field, page 32 to be selected from the Destinations,
c. Destination: Single-choice
page 74,
d. Type: multi-choice list containing the four rolling stock categories; check the boxes according to the
rolling stock assigned to the line and the relative weight between 0.00 and 100.00,
e. Distribution: a Single-choice list field,
page 32 used to define the type of distribution used to

determine the frequency of the PT (see 5. for the different possible distributions).
3.
4.
Click on the selected distribution to edit it.

If the distribution selected is:
a Frequency, the "PT Management window in PT line edit mode when defining the Frequency" (see fig. 173, page 281) is displayed; fill in the Headway (min) field: the number of
minutes between vehicles,
b. Delayed Frequency, the "PT
Management window in PT line edit mode when defining the

Delayed Frequency" (see fig. 174, page 282) is displayed; fill in the integer Arrival Rate
(vehicle/hour) field: the number of hourly departures, and the Maximum Delay (min) field: random delay (early or late) in relation to the fixed schedule (useful to account for variations in traffic in
a section of a line some distance from its terminal point),
c. Timetable, the "PT Management window in PT line edit mode when defining the Timetable"
(see fig. 175, page 283) is displayed; choose the timetable to apply.
Click Add to add the PT line.
6. Repeat operations 2 to 5 for all the PT lines associated with the PT scenario.
7. Click on the Back button to return to the PT scenarios edit page, then click Apply to validate the
assignment of the PT lines to the scenario.
5.
Remember to apply the PT lines to the PT scenario before quitting the entry window, otherwise the
definition of the PT lines will not be accepted.
To edit the parameters of an existing PT line, or to delete it, follow the procedure described to respectively
modify an element, page 28, and delete an element, page 28.
280
PUBLIC
PT line
list area
PT line
input area
Command
area
Figure 173. PT Management window in PT line edit mode when defining the Frequency
281
PUBLIC TRANSPORT
MODULE
PT line
frequency
P U B L I C
PT line
list area
PT line
input area
PT line
frequency
Command
area
Figure 174. PT Management window in PT line edit mode when defining the Delayed Frequency
282
PUBLIC
PT line
list area
PT line
input area
Command
area
Figure 175. PT Management window in PT line edit mode when defining the Timetable
283
PUBLIC TRANSPORT
MODULE
PT line
timetable
T I M E T A B L E
Timetable
You use the Timetable tool to define a schedule of departures for a public transport line, i.e. for vehicles in
the PT vehicle category (see Vehicle categories, page 41). In CubeDynasim, the Timetable represents a list
of times for a PT line. You can define a timetable schedule for a day or for part of a day.
Creating a timetable
1.
Access the Timetable entry window, page 284 via the Distribution menu in the Menu bar,
page 14.
2.
Fill in the Name.

Click Next to open the Timetable entry window, page 285.
"Edit the schedule of a timetable" (see fig. , page 285)
Click Add to create a new timetable.
Go back to step 3.) as many times as necessary.
Click Back to go back to the Timetable entry window, page 284.
Click Add to create the timetable.
3.
4.
5.
6.
7.
8.
A timetable can define departures for a whole day, or only for useful simulated periods during the day.
Thus, in the "Timetable entry window" (see fig. 177, page 285), the Timetable defines the departures
between 8 am and 9 am, and between 5 pm and 6 pm.
List of
timetables
Timetable
name
Figure 176. Timetable entry window
284
TIMETABLE
List of
times
Schedule
Figure 177. Timetable entry window
Edit the schedule of a timetable
Fill in the Schedule in HH:MM:SS format.

2. Click Add<
3. Go back to step 1. if another schedule is needed.
1.
Add a suite of schedules

It is possible to add to the list of times, a set of schedules, starting at current schedule and defined at constant
time step. The suite ends at midnight. At least one schedule must have already been defined.
Click on the first element of the suite to be added, displayed in the list of time.
2. Click Multiple Add to display:
1.
3.
4.
Define the time step in minutes and seconds.

Click OK to close the input box, and add the schedules to the list.
Import a file of schedules

A file of schedules is a text file. Each line defines a time following the format HH:MM:DD. All the schedules defines in the file are added to the time table.
Click Import (does not figure in the command area).
2. Select a text file. Click Open to add the schedules to the list of times. The field named Import
File is updated.
1.
285
Add a new schedule
PUBLIC TRANSPORT
MODULE
Display the "Timetable entry window" (see fig. 177, page 285) to edit the schedule of the current timetable.
Edition will end clicking on Return, Apply and Quit.
T I M E T A B L E
Update the contents of an imported file of schedules
It is possible to update the schedules imported from a file (for example if the contents of this file has been
changed). The list of times is cleared, and updated with the new schedules stored in the file.
1.
Click Reload (does not figure in the command area).
Erase all schedules

Click Clear All to empty the list of time.
Timetable assignment
The Timetable assignment object is used on one or more Terminus, page 276 objects to reset the departure time for a line.
If the Timetable assignment object intercepts several Terminus, page 276 objects, the first PT that
arrives in one of the termini is the one that will start off again at the time specified in the corresponding timetable.
If the PT arrives at the terminus object after the time specified in the corresponding timetable, it will comply
with the stop line defined in the Terminus, page 276 object and will start off again as soon as possible.
Terminus 1
Terminus 2
Timetable
assignment
Figure 178. Applying the timetable assignment to two terminus objects
286
TIMETABLE
Creating a timetable assignment

1.
fig.1 p.14).
Click the
button on the Simulation object bar, page 17 to activate create timetable assignment mode.
3. In the Network edit area, page 19, position the mouses pointer at the spot where you want to
place the icon, then left-click to display the "Timetable assignment entry window" (see fig. 179,
page 287).
a Layer which is a Single-choice list field, page 32 used to assign the layer of the invalid path.
2.
b. Schedule to choose a timetable for the model.

c. Width to define the width, in geometric mode, of the invalid paths straight segments; 0.5 meters rep-
resents a good compromise.

5. Click OK to confirm the parameters and position the timetable assignment segments.
6. Position the cursor at the end of the segment created, then :
d.
To add a new segment, left-click and repeat the above procedure.
b. Right-click to finish the entry.
PUBLIC TRANSPORT
MODULE
Figure 179. Timetable assignment entry window
287
T I M E T A B L E
288
13
Signals module
Establishing this strategy consists in selecting and positioning signals, determining which streams of vehicles they regulate, programing the signal plans, and implementing actuated signal control when the traffic
demand varies highly and randomly during the simulated time. Editing a simulation model with CubeDynasim involves the following five stages :
Positioning the Signals, page 290 on the background map.
Editing a Stop line, page 202 for each signal, indicating the regulated trajectories.
3. Grouping objects used to define the programing of a group (i.e. crossroads) in Controllers,
page 305.
4. Entering the signal programs.
5. Defining the actuated signal operations after positioning the Detectors, page 295 on the background map.
1.
2.
The microscopic simulation approach makes it easier to measure the effect of the different regulation strategies envisaged on the operation of the modeled development. CubeDynasim favors the comparison of these
different strategies by dissociating the Network scenarios, page 65 which contain the simulation objects
positioned in the Network edit area, page 19 (e.g. Signals, page 290, the Stop line, page 202, and
Detectors, page 295,) from the actual programing, which is defined in the traffic signal scenario.
This chapter describes how to edit:
289
Signals, page 290,

Detectors, page 295,
Controllers, page 305
Signal scenarios, page 308,
Classic Programing, page 313.
SIGNALS MODULE
An urban developments fluidity is determined, among other things, by the control strategy established and
implemented on the ground.
S I G N A L S
Signals
You can use CubeDynasim to edit two types of signal, distinguished by their representations and the number
of states in the simulation.
Signals with two states

Signals with two states alternate between the blocking and passing states, represented - depending on
the signal type - by the following:
SIGNALS WITH TWO STATES

TYPE
ICON
FUNCTION
PASSING
BLOCKING
STATE
STATE
R12
Pedestrian signal
green
red
R16
Anticipation signal
yellow
off
(gray)
R24
Stop signal
generally used to protect against a level crossing, a tramway crossing, etc.
off (gray)
red
R25
Pedestrian signal to protect against a reserved track public transport

line
off (gray)
red
SAC
Driving aid signal. Represented by an exclamation mark, it usually

precedes the 3-second green light of an R17
yellow
off
SPC
Acceptance signal. Usually represented by a blue diamond shape

that lights up as soon as the controller acknowledges the detection of
a priority vehicle
blue
off
To model an anticipation signal, i.e. one that authorizes the passage either in a directional movement
(R16) or for a vehicle category (R15 modal anticipation signal), you must define the R11v signal and
an R16 signal. The Stop line, page 202 is assigned to the R11 signal with the R16 as an additional
signal.
Signals with three states

For a signal with three states, the red is followed by a yellow, usually set to 3 seconds.
290
SIGNALS
SIGNALS WITH THREE STATES

TYPE
ICON
FUNCTION
PASSING
INTERMEDIATE
BLOCKING
STATE
STATE
STATE
Three-color signal
green
yellow
red
R17
Tramway signal
vertical
white line
white circle
horizontal
white line
R13b
Bus modal three-color signal
green
yellow
red
R13c
Bicycle modal three-color signal
green
yellow
red
R18
Directional signal for a tramway
white triangle
white circle
horizontal
white line
3-color US
Three-color signal - USA
green
yellow
red
Pedestrian
US
Pedestrian signal - USA
green
white hand
white hand
Creating and editing a signal

This section describes the following, while underscoring the possible specificities of both types of signal:
the Representation of signals in the edit area, page 292,

the steps to follow for Creating a signal, page 293,
the steps to follow for Editing a signal, page 294.
291
SIGNALS MODULE
R11
S I G N A L S
C360
F1
F2
F3
C360
F1
FL1
F2
F3
Figure 180. F1 anticipation signal modeled by signals F1 and FL1
Representation of signals in the edit area

Signals are simulation objects displayed as icons representing the signal type in the Network edit area,
page 19 in geometric mode only (see "Representations of signals in the edit area", fig.181 p.292).
PS: 2-color signal icon
VS: 3-color signal icon

Figure 181. Representations of signals in the edit area
SIGNAL PARAMETERS
LABEL
292
DESCRIPTION
Name
Unique name that identifies the signal (Name field, page 29).
Layer
Layer that stores the signal (see Single-choice list field, page 32).
SIGNALS
SIGNAL PARAMETERS
LABEL
DESCRIPTION
Verification
Boolean value:
Yes: generate error reports for the signal each time a change of status does not comply with constraints in terms of the logical concatenation of green/orange/red states
and in terms of the minimum durations.
No : do not generate error reports for the signal.
(see Single-choice list field, page 32).
Green duration
Boolean value :
Yes: measurement of the Green signal duration, page 242 criterion.
No: no measurement of the Green signal duration, page 242 criterion for this
signal.
Remember to select statistic processes for the Green signal duration criteria when
editing the simulation scenario, otherwise no values will be recorded (see Add a
simulation scenario, page 406).
Crossing duration
simulation scenario, page 406).
Creating a signal
1.
Switch to geometric mode if necessary (see "Main CubeDynasim window in geometric mode",
fig.1 p.14).
To enable the signal mode, click on the desired signal

on the Simulation object bar,
page 17.
3. In the Network edit area, page 19, click the location of the signal post to display the signal
entry window.
2.
4.
5.
Fill in the Signal parameters, page 292.

Click OK to create the signal and then close the window.
Go on to create all the signals associated with the same layer so that you only have the end of the
Name field, page 29 to fill in.
293
SIGNALS MODULE
Boolean value:
Yes: measurement of the Signal line crossing duration, page 243 criterion.
No: no measurement of the Signal line crossing duration, page 243 criterion
for this signal.
Remember to select statistic processes for Stop line crossing duration criteria when
editing the simulation scenario, otherwise no values will be recorded (see Add a
S I G N A L S
Editing a signal
Signals are defined by their parameters, by their location, and by their orientation used in 3D viewing.
You edit the parameter values of a signal, or delete a signal, exclusively in geometric mode following the
procedure described in section Edit Object mode, page 20.
The effects of deleting a signal are as follows:
1. all the Stop line, page 202 associated with it are destroyed,
2. the signal is removed from the signal plans of the various signal scenarios it belongs to,
3. the actuated signals, for which it is the base signal, are deleted.
You move a signal following the procedure to move a simulation object on the background map, page 21.
You only define the orientation of the signal if you wish to present the simulation results as a 3D animation
(see 3D view, page 459), because only this representation takes into account a signals orientation. To orient
a signal already created, proceed as follows :
1.
2.
3.
4.
5.
fig.1 p.14).
select the signal by following the procedure to select a simulation object, page 21 to display
the two modification handles respectively corresponding to the position handle, situated in the
middle of the icon representing the signal in geometric mode, and the orientation handle. The
signals orientation is given by the vector whose origin is the position handle, and whose destination is the orientation handle (see "Representation of a selected signal", fig.182 p.294),
Click and hold the orientation handle.
Drag the mouse to move the orientation handle as appropriate.
Release the button to finish.
To associate an VS and an PS on the same post in 3D, position the two signals so that their position
handles coincide, orient the VS to the roadway, and the PS to the pedestrian crossing.
Representation of the signal

Position handle
Orientation of the signal
Orientation handle
Figure 182. Representation of a selected signal
294
DETECTORS
Detectors
With actuated signal control, you can adapt the operation of the signals to traffic conditions. This requires the
implementation of detectors to measure traffic conditions. They are usually detectors positioned on the roadway, radars, pedestrian push buttons, or an onboard emitter on priority vehicles. When modeling, you must
strive to reproduce the way in which a development operates. For this purpose, CubeDynasim offers a number of simulation objects, called detectors, which reproduce the operation of different types of existing detectors.
In CubeDynasim, you create and edit detectors in the Network edit area, page 19 in geometric mode only.
These detectors are distinguished by their graphic representation, and by the Boolean expression that translates their status. They are used when editing actuated signal control parameters.
Deleting a detector effectively removes the Boolean expressions conditioning the application of the
actuated signal operations. If the detector is the only element in an expression, the actuated signal
operation is nevertheless retained, but is no longer accepted during the simulation. No simulation
errors inform you of this.
For presentation reasons, detectors are split into two groups: multimarker detectors and single-marker detectors. Subsequently, there are six types of detectors:
Multimarker detectors
The multimarker detector combines a set of entry markers and exit markers, and a variable indicating the
number of vehicles which, having crossed an entry marker, have not yet crossed an exit marker.
Depending on the networks configuration and the detectors geometry, these different cases generate simulation errors (see Errors for the current replication, page 416):
A vehicle that has crossed one of its entry markers quits the network without having crossed one
of its exit markers: its variable is subsequently decremented.
2. A vehicle crosses one of its entry markers twice without crossing any exit markers: the variable is
incremented once only.
3. A vehicle crosses one of its exit markers without having previously activated an entry marker: the
value of the variable is not modified.
1.
The markers of a multimarker detector are displayed in the Network edit area, page 19 as an association
combining:
1.
2.
295
A set of blue straight segments, or yellow in pointed mode.

An icon respecting the same color code as the data collectors. Blue characterizes an entry marker,
red an exit marker. A vehicle activates the detectors point when it crosses one of its straight
segments.
SIGNALS MODULE
Multimarker detectors, page 295:

the Check-in/check-out with delay, page 296,
the Not check-in/check-out with delay, page 298,
Single-marker detectors, page 299:
the Queuing detector, page 299,
the Presence detector, page 301,
the Passage detector, page 302,
the Pedestrian push-button, page 303.
ETECTORS
D
As with the representation of simulation objects comprising different geometric elements such as the
Yield, page 206, and to avoid overloading the Network edit area, page 19, only the first entry marker
of a multimarker detector is displayed. By positioning the mouses cursor on the entry marker of the check
in/check out detector, corresponding to pointed mode, all its entry and exit markers are displayed (see "Representations of check-in/check-out with delay", fig.184 p.298). Moreover, a message specifying the type of
the detector and its name is displayed in the information area.
To create a multimarker detector in geometric mode after activating create detector mode :
In the Network edit area, page 19, click the location where the first entry marker starts. This
displays the detector entry window.
1.
Name field, page 29, which is a name unique to all the detectors in the study, used when editing
the actuated signal control.
b. Layer which is a Single-choice list field, page 32 used to assign the detectors layer.
a
Select deactivate detector mode, then Front or Rear, corresponding to the front and rear of the
vehicle on the detector.
4. Click OK to continue the entry of the detectors geometry. You can no longer interrupt the creation
process; you must go on to the end.
5. Position the mouse, and:
3.
left-click to add a new segment, then repeat step 5.),
b. right-click to finish the entry of the first entry marker.

6.
Proceed as follows to create a new entry marker, otherwise, proceed directly to step 7.) :
left-click the location where you want to see the entry marker icon in the Network edit area,
page 19,
b. Repeat step 4.),
a
Finish the input of entry markers by right-clicking in the Network edit area, page 19.
8. Create at least one exit marker by following the same procedure as for the entry markers, as in step
5.),
9. Finish the entry of the new check-in/check-out by right-clicking in the Network edit area,
page 19.
7.
Just like the data collectors, it is possible to modify each marker of a detector (see Editing a data collectors
geometry, page 264). It is possible to modify the location as well as the coordinates of any one segment
(refer to the procedure to move a simulation object on the background map, page 21).
Follow the procedure described in section Edit Object mode, page 20 to edit the parameter values of a
multimarker detector, or delete a multimarker detector, from the representation of its first entry marker (in
geometric mode).
To edit the parameters of a multimarker detector, you open the entry window in edit mode by following the
procedure to Edit Object mode, page 20. The multimarker detector entry window in create mode differs
from that in edit mode through the additional Condition field, which is a Prohibitor field, page 171 (see
"Check-in/check-out with delay entry window in create and edit modes", fig.183 p.298). It is used to limit the
vehicles taken into account by the detector, according to criteria concerning the category or destination.
The set of multimarker detectors contains two types of detector:
Check-in/check-out with delay, page 296,

Not check-in/check-out with delay, page 298.
Check-in/check-out with delay
The check-in/check-out with delay is a Multimarker detectors, page 295. The status of the detector is
determined by the number of detected vehicles exceeding a defined threshold. It is possible to define the
probability that the check-in/check-out is effective and passed to the controller, within a predetermined
delay.
296
DETECTORS
CHECK-IN/CHECK-OUT WITH DELAY PARAMETERS

LABEL
DESCRIPTION
Name
Unique name among the set of detectors (see Name field, page 29).
Layer
Layer that stores the detector (see Single-choice list field, page 32).
Prohibitor field, page 171, accessible only in the detector editing mode. It allows
to define a subset of vehicles which can activate the detector.
Deactivate
Specifies the type of output for loop detection. Front: corresponding to the passage
of the front of the vehicle on the loop, Back: corresponding to the portion of the rear
of the vehicle on the loop.
Delay probability
Probability that the check-in is validated and sent to the controller with a delay (see
below Delay duration). For a probability of 0, the information is transmitted without
delay.
Delay duration
Number of seconds if the information is transmitted with delay to the controller (see
Delay probability parameter).
Threshold
Integer greater than 0. The loop is activated when the number of vehicles recorded
present is greater than or equal to the value of the threshold. Default value is set to 1.
To simulate a check-in/check-out detector, as proposed in the previous versions of the software, you
should set a Threshold of 1, and a Delay probability of 0.
The
or
icons are respectively associated with the entry and exit markers of the delay check-in/
check-out displayed in the Network edit area, page 19 (see "Representations of check-in/check-out with
delay", fig.184 p.298).
To create a check-in/check-out with delay detector:
1.
If needed, switch to geometric mode (see "Main CubeDynasim window in geometric mode", fig.1
p.14).
Click
on the Simulation object bar, page 17 to activate create check-in/check-out with
delay mode.
3. Follow the procedure to create a Multimarker detectors, page 295.
4. Fill in the Check-in/check-out with delay parameters, page 297.
2.
297
SIGNALS MODULE
Condition
ETECTORS
D
Edit mode
Create mode
Figure 183. Check-in/check-out with delay entry window in create and edit modes
Entry
detector
Exit
detector
Check-in/check-out with delay
Check-in/check-out with delay in pointed mode
Figure 184. Representations of check-in/check-out with delay

Not check-in/check-out with delay
The Not check-in/check-out is a Multimarker detectors, page 295 whose status is determined by the null
value of the variable indicating the number of vehicles. It is the reverse condition of the Check-in/check-out
with delay, page 296.
The
and
icons are respectively associated with the entry and exit markers of the Not check-in/
check-out displayed in the Network edit area, page 19.

To create a Not check-in/check-out:
1.
Click the
icon on the Simulation object bar, page 17 to activate create check-in/check-out
mode.
3. Then follow the procedure for creating a multimarker detector.
2.
298
DETECTORS
Single-marker detectors
This section describes the characteristics of single-marker detectors via their graphic representation, and
explains how to add, edit and delete these objects.
Single-marker detectors are simulation objects displayed exclusively in geometric mode in the Network edit
area, page 19. They are represented by the association of a color marker with a definable width grouping a
set of straight segments, and an icon representing the type of detector (see "Representation of a queuing
detector", fig.186 p.301). The graphic representation in pointed mode amounts to inverting the color of its
marker, and displaying the detectors type and identifier in the information area.
Single-marker detectors dedicated to vehicles define a detection zone either side of its marker, limited by
its detection length. Any vehicle present in this zone activates the detector.
To create a single-marker detector in geometric mode, proceed as follows after activating create detector
type mode:
In the Network edit area, page 19 click at the spot marking the start of the detectors marker to
display its entry window in edit mode.
2. Fill in the fields concerning the single-marker detectors:
1.
Name field, page 29, unique identifier of the detector, used when editing the actuated signal control,
b. Layer, which is a Single-choice list field, page 32 used to assign the detectors layer.
a
edit area,
page 19, a width of 0.5 meters provides good model readability. This parameters value is not con-
sidered by the simulation engine.

d. Color field, page 31, defines the color of the marker displayed in the Network
edit area,
page 19.
3. Click OK to continue defining the markers geometry.
4. After positioning your mouse, left-click to add a new segment, or right-click to finish the segment
being created, thereby ending the entry of the detector.
The detector is a simulation object whose parameters can be edited in the Edit Object mode, page 20, by
displaying an entry window that differs from the one displayed in create mode by the additional Condition
Prohibitor field, page 171, only for detectors dedicated to detecting vehicles. This Condition field is used
to limit the number of vehicles capable of activating the detector according to criteria concerning the vehicle
destination or category.
You can modify the geometry of a single-marker detector by moving its marker on the background map. To
do so, follow the procedure to move a simulation object on the background map, page 21. You can also
move the ends of segments that define its marker.
To delete a single-marker detector, you apply the procedure described in section see Edit Object mode,
page 20.
The following single-marker detectors are available :
Queuing detector, page 299,

Presence detector, page 301,
Passage detector, page 302,
Pedestrian push-button, page 303.
Queuing detector
The queuing detector is used when implementing an actuated signal control strategy to reduce or eliminate
the risk of queues subsequent to lines of vehicles caused by poor clearance of left-turn movements, congestion on a junction downstream, or illegal parking.
299
SIGNALS MODULE
c. Width: corresponds to the thickness of the marker displayed in the Network
ETECTORS
D
The queuing detector belongs to the category of single-marker detectors dedicated to vehicles. This detector
has a detection length of between 0 and 10 meters, edited in the +/- Detection Area (m) field in the Queuing detector entry window, page 300.
Figure 185. Queuing detector entry window

The condition associated with the queuing detector is not satisfied if the same vehicle remains at a standstill
in its detection zone for longer than the duration specified in the Activation Delay (s) field in the Queuing
detector entry window, page 300. If the marker crosses several trajectory objects, the condition is no longer
valid if at least one vehicle remains in one of its detection zones for longer than the duration specified in the
Activation Delay (s) field.
The queuing detector is positioned:
at the end of the vehicle cluster area for a cluster length that is insufficient for a left-turn movement,
taking into account the cluster of vehicles that will cross the junction before the green light stops, to
bypass a queue formed by a line of vehicles.
The
icon associated with a marker represents a queuing detector displayed in the Network edit area,
page 19 (see "Representation of a queuing detector", fig.186 p.301).
To create a queuing detector:
1.
Click the
icon on the Simulation object bar, page 17 to activate create queuing detector
mode.
3. Follow the procedure for creating a single-marker detector.
2.
300
DETECTORS
Queuing detector icon
Detector marker
Roadway crossing the marker

Figure 186. Representation of a queuing detector
The presence detector is used when implementing:
a retraction to modify the sequential flow of a signal program by deleting a phase if no vehicles are
detected on the corresponding entry,
a relaxing point which consists in freezing the sequential flow of a signal program while waiting for a
variable to change status.
The presence detector belongs to the category of single-marker detectors dedicated to vehicles. This detector
has a detection length of between 0 and 10 meters, edited in the +/- Detection Area (m) field in the Presence detector entry window, page 301.
Figure 187. Presence detector entry window

The condition associated with the presence detector is satisfied if the same vehicle remains in its detection
zone for the duration specified in the Activation Delay (s) field in the Presence detector entry window,
page 301.
301
SIGNALS MODULE
Presence detector
ETECTORS
D
The presence detector is usually set 2 or 3 meters upstream from the Stop line, page 202 associated with
the Signals, page 290 to retract.
The
icon associated with a marker represents a presence detector displayed in the Network edit
area, page 19.

To create a presence detector:
1.
Switch to geometric mode (see "Main CubeDynasim window in geometric mode", fig.1 p.14),
Click the
icon on the Simulation object bar, page 17 to activate create presence detector
mode.
3. Follow the procedure for aSingle-marker detectors, page 299.
2.
Passage detector
The passage detector is used to vary the duration of the green phase on one or more lines between the predefined minimum and maximum durations. It involves comparing the vehicle interval, defined as the time
between two vehicles activating the detector, with a predefined time called the critical interval. If the critical
interval is greater than the vehicle interval, the signal prolongs the green phase by the duration of the critical
interval within the limit of its maximum duration.
The passage detector belongs to the group of single-marker detectors dedicated to vehicles. Its detection
length is set to 0 meters.
The condition of the passage detector corresponds to the following expression: the critical interval is less
than the vehicles interval.
You define the value of the detectors critical interval in the Critical interval field in the Passage detector
entry window, page 303.
The position of the passage detector relative to the stop line it regulates is determined by the value of the
reduced critical interval (reduced by 1 second in general), multiplied by a speed of 10 m/s. For a critical
interval of 3 seconds, you position the detector 30 meters upstream from the signals stop line. The detectors
position also determines the duration of the minimum green phase, corresponding to the time required to
clear vehicles at a standstill between the stop line and the position of the detector. In this case, you choose an
average vehicle length of 5 meters, and a passage time per vehicle of 2 seconds.
The
icon and its marker are displayed in the Network edit area, page 19 to represent a passage
detector.
To create a passage detector:
1.
Click the
icon on the Simulation object bar, page 17 to activate create passage detector
mode.
3. Follow the procedure for Single-marker detectors, page 299
2.
302
DETECTORS
Figure 188. Passage detector entry window
The pedestrian push-button (also referred to as the push-button call marker) is used to insert a pedestrian
phase based on pedestrian calls. It amounts to retracting the pedestrian phase when there is no pedestrian
call.
The push button belongs to the category of single marker detectors dedicated to pedestrians.
The push button is activated when a pedestrian enters one of the waiting areas on a Pedestrian crossings,
page 95, which crosses its marker. The push button is deactivated when its status is queried.
The markers
ton.
icon, displayed in the Network edit area, page 19, represents the pedestrian push-but-
To create a pedestrian push-button:

1.
2.
Click the
3.
Follow the procedure for Single-marker detectors, page 299.
icon on the Simulation object bar, page 17 to activate create push-button mode.
Figure 189. Push-button entry window
303
SIGNALS MODULE
Pedestrian push-button
ETECTORS
D
As with the vehicle signal stop line, the pedestrian signal stop line must cross one of the two waiting areas on
a Pedestrian crossings, page 95, to associate it with both crossing directions (see "Pedestrian crossings
regulated by stop lines", fig.130 p.202).
Push-button icon managing the North crossing

Stage crossing the marker
Detector marker
Push-button icon managing the South crossing

Figure 190. Editing push-button marker
304
CONTROLLERS
Controllers
A controller is used to group - according to a geometric criterion - the physical elements (Signals,
page 290, Detectors, page 295) needed to program signalized intersections.
This section discusses the following:
The Representation of controllers in the edit area, page 305,

The steps to follow for Creating a controller, page 306,
The steps to follow for Editing a controller, page 306.
Representation of controllers in the edit area

Controllers are simulation objects displayed as a transparent colored rectangle in the Network edit area,
page 19, in geometric mode only (see "Representations of signals in the edit area", fig.181 p.292). This rectangle defines the area regulated by the controller.
Figure 191. Representation of a controller
A signal can belong to different controllers. However, only one controller can program that signal in a
particular signal scenario.
A detector can belong to different controllers, and any of these controllers can use the detector
indiscriminately.
305
SIGNALS MODULE
Representation of a
controller defining its
area of regulation
C O N T R O L L E R S
CONTROLLER PARAMETERS
LABEL
DESCRIPTION
Name
Unique name identifying the controller in the project. Used when editing Signal scenarios,
page 308. When using DynasimServer, make sure you follow the naming conventions defined in
chapter Editing and naming objects in CubeDynasim, page 342 (see Name field, page 29).
Layer
The layer associated with the trajectory, chosen from the subset of layers in the current Network scenarios, page 65 (see Single-choice list field, page 32).
Color
Color of the controller in the Network edit area, page 19 (see Color field, page 31). Select a pastel
color to easily read other simulation objects.
Creating a controller
1.
fig.1 p.14).
2.
Click
on the Simulation object bar, page 17 to activate edit controller mode.
In the Network edit area, page 19, click the location where you want to position one corner of
the controllers rectangle.
4. The controller entry window is displayed.
3.
Fill in the Controller parameters, page 306.

Click OK to close entry window.
7. In the Network edit area, page 19, click the opposite corner of the rectangle that defines the
area regulated by the controller.
5.
6.
Editing a controller
You edit a controllers parameters in the controller entry window according to the area it regulates.
You edit the parameter values of a controller, or delete a controller, exclusively in geometric mode following the procedure described in section Edit Object mode, page 20.
You edit a controllers geometry to modify the area it regulates either by moving the corresponding rectangle (see move a simulation object on the background map, page 21) or by moving the opposite corners of this
rectangle.
306
CONTROLLERS
To move the rectangles opposite corners:
1.
2.
3.
4.
5.
6.
fig.1 p.14).
Select the controller to modify.
Click and hold the handle of one corner of the rectangle to move.
Drag the mouse to resize the area as appropriate, then release.
Repeat for the opposite corner.
Click the network edit area outside the controller to deactivate the corner handles.
Moving a controller leads to deprogram all the signals not appearing anymore in the geographic area
of the controller. This will happen for all signal scenarios, including this controller.
Therefore, we strongly recommend to place the controllers in a specific layer, that the user must
freeze.
SIGNALS MODULE
307
S I G N A L
SCENARIOS
Signal scenarios
Signal scenarios define all the controllers, signals and detectors considered in the simulation. They also serve
to define the type of programing associated with each controller. This section describes the data model
behind the concept of the signal scenario, as well as identifying and describing the various elements that
make up a signal scenario.
Topics in this section include:
Header, page 308,

Programing controllers, page 308,
Editing signal scenarios in CubeDynasim, page 309.
Header
The header of a signal scenario contains the parameters used to associate it with the other elements of the
study.
SIGNAL SCENARIO HEADER PARAMETERS

LABEL
Name
Layers
Comment
DESCRIPTION
Unique name identifying the scenario, used for the definition of simulation scenarios.
Set of layers associated with the signal scenario (see Multiple-choice list field, page 33). Covers all the controllers to program for this scenario.
Used to describe scenario specificities as free text (optional).
Only signals that belong to a controller in the signal scenario can be programed. If a signal does not
belong to a controller, but figures in the network scenario, the simulator generates an error. In this
case, stop lines that depend on the non-programed signal are not considered by the simulation.
Programing controllers
Programing controllers boils down to defining the times for each associated signal. CubeDynasim provides
you with three possible programing techniques.
In what is referred to as classic programing, you directly edit the signal diagram (cycle duration, duration
and concatenation of phases) and define actuated signal control operations. You can coordinate the diagrams
of different controllers in the same signal scenario either using the offset (i.e. delay) parameter for a constant
cycle duration, or by editing the coordination points.
Nema programing is used mainly in North America and in certain parts of Asia. Please refer to the corresponding documentation.
The Socket controller establishes a connection between the simulator and an external program. This external
program defines the status of the simulated signals in real time. The simulation model transfers the status of
the detectors to the external program and communication between the two is established on a time base and
via addressing defined in CubeDynasim.
The Utopia controller establishes a connection between the simulator and Urban Traffic Control System
UTOPIA.
308
SIGNAL
SCENARIOS
DIAGRAM PARAMETERS
LABEL
Name
Type
DESCRIPTION
Name that identifies the controller (see Creating a controller, page 306).
Type of diagram to choose out of three possibilities:
1.
2.
3.
Classic, definition of the diagram and actuated signal control directly via the interface.
Nema, definition of Nema programing (North America/Asia).
Socket, an external program transfers the status of the signals to the simulation based on the
status of the detectors.
4.
Utopia Urban Traffic Control System Utopia

to the simulation based on the status of the detectors.
transfers the status of the signals
Specific to Classic Programing

Duration of the cycle, in seconds.
Offset
The simulation duration, in seconds, needed to obtain - the first time - all the controllers
signals in the state expressed at instant
t = 0 on the diagram.
Diagram
Defines, for each controller in the scenario, the signal programing, represented as a time
chart.
Actuated signal
control
Defines the list of operations used to modify - during the simulation - the concatenation
and/or duration of the states defined by the diagram (see Operations that modify the
diagram during a simulation, page 318).
Specific to Nema Programing

Cycle
Duration of the cycle, in seconds.
Offset
Delay in the cycle when the simulation is launched, in seconds.
Coordination
Type of coordination.
Operation
Diagram
Definition of ring & barrier programing.
Specific to Socket Programing

IP address
Port
Inter-com
duration
IP address of the machine on which the server program is run.

Port that communicates with the server.
Number of seconds between two successive signal states sent by the server. Usually 1
second.
Editing signal scenarios in CubeDynasim

You edit signal scenarios in the signal module entry window.
309
SIGNALS MODULE
Cycle
S I G N A L
SCENARIOS
Click the
button on the Module bar, page 18 to display the signal module entry window. This win-
dow can be displayed in two different modes:
Edit signal scenario mode, page 310, to edit signal scenarios,

Edit signal programing mode, page 311, to edit controller parameters.
Edit signal scenario mode
The signal module entry window is opened in edit signal scenario mode for adding, deleting and editing all
the projects signal scenarios (see "Signals module entry window in edit signal scenario mode", fig.192
p.310). In this mode, the window works in the same way as a Module entry window, page 27.
The list area lists theHeader, page 308 of each signal scenario in the project.
The edit area is used to edit the Signal scenario header parameters, page 308 of the current scenario.
Click the Configure button to switch the entry window to "Signals module entry window in edit controller
scenario mode" (see fig. 193, page 312) mode.
It is not possible to remove a signal scenario that is used by a simulation scenario. In this case, the
user must first delete all the simulation scenarios depending on the signal scenario to be removed.
The user can change the set of layers of a signal scenario only if it does not cause incompatibility for
one of the simulation scenarios (for any simulation scenario, the set of layers of its signal scenario
must be included in the set of layers of its network scenario).
Display area
Network edit area
Edit area
Command area
Figure 192. Signals module entry window in edit signal scenario mode
310
SIGNAL
SCENARIOS
Edit signal programing mode

Use the "Signals module entry window in edit controller scenario mode" (see fig. 193, page 312) to edit the
Controller parameters, page 306.
This window works in the same way as a Module entry window, page 27, but with some important differences concerning the display area (referred to as the list area in some entry windows).
The display area lists all the controllers in the current signal scenario. The controllers representation in the
display area differs depending on the type of controller. For a classic controller, this area displays the intersection signal state changes as a time chart, the actuated signal operations, and the list of signals not yet programed or assigned to a controller.
You select the current controller by clicking its name in the display area. The current controller is framed by
a blue border.
The programs for each controller can be viewed in compact or deployed mode (see "Programing display
area", fig.194 p.313). To change from one mode to the other, click the + or - icon next to the controllers
name.
To zoom in on the signal program, left-click while keeping the Shift key pressed. To zoom out, do the same
using the right mouse button.
Click Back to switch to the "Signals module entry window in edit signal scenario mode" (see fig. 192,
page 310). To exit the signal module entry window, you must switch to edit signal scenario mode.
To edit a controllers parameters:
1.
Click the
2.
In the display area, click signal scenario whose controller parameters you want to edit.
Click Configure to switch the "Signals module entry window in edit controller scenario mode"
Switch to edit controller characteristics mode by clicking the controller name in the display area.
The current controller is framed by a blue border.
Update the current controllers parameters (see Controller parameters, page 306).
Click Add to validate the new parameters.
Click Back to switch the "Signals module entry window in edit controller scenario mode" (see
fig. 193, page 312).
Click Apply to apply your changes to the current signal scenario.
Click Quit to close the signal module entry window.
3.
4.
5.
6.
7.
8.
9.
311
button on the Module bar, page 18 to display the signal module entry window.
SIGNALS MODULE
You modify the current controllers parameters in the edit area. The parameters shown vary depending on
the type of controller.
S I G N A L
SCENARIOS
Network edit area
Display area
Edit area
Command area
Figure 193. Signals module entry window in edit controller scenario mode
312
CLASSIC PROGRAMING
Classic Programing
This section describes the programing of Classic controllers, edited directly using CubeDynasim.
In the case of a Classic controller:
The display area of the "Signals module entry window in edit controller scenario mode" (see fig. 193,
page 312) displays int the form of a time-line the states duration and sequences of the signals managed by the controller, actuations, and the list of signals which are not yet programed or assigned to a
controller.
The edit area displays the parameters of the current item selected in the display area.
The command area defines the exchange operations for the edit area to the display area.
Diagram in compact mode

Click to switch to deployed mode
Non-programed signal
programed signal
Controller name
Signal name
Figure 194. Programing display area
To finish any edition operation, click Back of the command area of the "Signals module entry window
in edit controller scenario mode" (see fig. 193, page 312).
Then to validate changes at the signal scenario level, click either Add or Apply of the command area
of the "Signals module entry window in edit signal scenario mode" (see fig. 192, page 310).
It includes the following topics:
313
Edit states of the signals, page 314

Rules between detectors, page 317,
Operations that modify the diagram during a simulation, page 318,
Examples of signal programs with CubeDynasim, page 326,
Edit actuated signal operation, page 322,
Files generated, page 335.
SIGNALS MODULE
Current controller
(classic type)
C L A S S I C P R O G R A M I N G
Edit states of the signals

Depending on the type of signals (two or three states), the fields to edit differ; however, the manipulation
remains the same.
SIGNAL PROGRAMING PARAMETERS

LABEL
DESCRIPTION
State
Used to define whether the signal is single-state (i.e. single-color), or to be programed.

Three possible values:
1.
2.
3.
Programing: the signal must be programed (default value)

All Red: sets the signal to red throughout the simulation (used when programing absolute
tramway)
All Green: sets the signal to green throughout the simulation (used when programing absolute
tramway)
If the State parameter is set to Programing
Minimum
Green
The minimum duration of the signals green state, in seconds. If an actuated signal operation
reduces the green duration below this minimum value, and if the signals Verification
parameter is enabled, the simulation engine issues an error message (see Consult the messages, page 414).
Yellow
Duration
The duration of the yellow state in seconds, exclusively for vehicle signals (two possible values: 3 or 5 seconds). The yellow duration must be constant. It must not be assigned by an
actuated signal operation. If the signals Verification parameter is enabled, and if the yellow
duration is modified during the simulation, the simulation engine issues an error message
(see Consult the messages, page 414).
Start of Green
Number of seconds between the start of the cycle and the signals change to the green (passing) state.
Green
Duration
314
Duration of the signals green state, in seconds.
CLASSIC PROGRAMING
Program a signal
1.
Click the
2.
The current controller is framed by a blue border. Value of the field Type should be Classic.
If necessary, click on the + located after the name of the controller to switch to extended mode.
If necessary, adjust the display, shift + left click to zoom in or shift + right-click to zoom out.
Click the signal shown in the display area, in our example C4_2_R17_1.
3.
4.
5.
6.
7.
Information area
Edit area
Command area
In the Edit area, set the field State to Programing value. Set the values of the other parameters.
Click Apply in the Command area to validate the parameters of the signal, and update the status of
the signal shown in the Display area.
10. Go to 7.) to edit another signal, otherwise click Back in the Command area to switch to "Signals
module entry window in edit controller scenario mode" (see fig. 193, page 312).
11. Click Apply in the Command area to validate the changes in the current signal scenario.
12. Click Quit in the Command area to close the module entry window.
8.
9.
Cancel/delete the signal programing

Starting from the "Signals module entry window in edit controller scenario mode" (see fig. 193, page 312)
1.
2.
3.
4.
5.
6.
Click the signal shown in the Display area, the line corresponding to the current signal is framed
in blue, and the Edit area switches to edit signal mode.
Click Delete in the Command area to delete the current signal programing.
Click Apply in the Command area to validate the parameters of the signal, and update the status of
the signal shown in the Display area.
Click Back in the Command area to switch to "Signals module entry window in edit controller
scenario mode" (see fig. 193, page 312).
Click Apply in the Command area to validate the changes in the current signal scenario.
Click Quit in the Command area to close the module entry window.
It is not possible to delete the signal programing if this signal is a base signal. You must first
delete the Operations that modify the diagram during a simulation, page 318 that depend on it.
315
SIGNALS MODULE
Display area
Import signal programing
It is possible to import from a text file the signal programing for a controller of type Classic. Each line of the
file defines the program of one signal. The line is defined as a sequence of nine fields separated by spaces.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Signal Id (string)
Cycle duration in seconds (unsigned integer)
Start of green in seconds (unsigned integer)
Green duration in seconds (unsigned integer)
Yellow duration in seconds (unsigned integer)
0, unused in the current version
Minimum green duration in seconds (unsigned integer)
For example: C871_2_R11_1 129 58 48 3 0 0 0 6

If the cycle duration defined in the signal importation differs from the Cycle length of the controller,
CubeDynasim will compensate the difference by reducing or lengthening the duration of the signals blocking states.
316
CLASSIC PROGRAMING
To import the signal programing:
1.
Click the
4. Switch to edit controller characteristics mode by clicking the controller name in the display area.
5. Click Import in the Edit area to display the file selection window.
2.
3.
6.
Select the text file to import.
SIGNALS MODULE
The new values are updated and showed in the Display area.
Click Back in the Command area to switch to "Signals module entry window in edit controller
scenario mode" (see fig. 193, page 312).
9. Click Apply in the Command area to validate the changes in the current signal scenario.
10. Click Quit in the Command area to close the module entry window.
7.
8.
Rules between detectors

Actuated signal control actions are performed depending on the status of the equation defined between the
junctions various detectors.
When editing an actuated signal control action, the detector field consists of:
a column of OR conditions between the selected detectors

a column of AND conditions between the selected detectors
an AND condition between the list of OR detectors and AND detectors.
317
List of detectors linked by

an OR condition
List of detectors linked by

an AND condition
Figure 195. Detectors: conditions on the detectors

EXAMPLE:
Take 4 detectors whose boxes are checked as follows:

OR detector: C1_1, C1_2
AND detector: C1_3, C1_4
The resulting equation is therefore: ( C1_1 + C1_2 ) . ( C1_3 . C1_4 )
Operations that modify the diagram during a simulation

Coordination points and actuated signal operations serve to change the duration and concatenation of the
signal phases according to traffic data collected in real time.
Actuated signal operations modify the concatenation and/or duration of the same controllers signal states.
Whether or not an actuated signal operation is considered during the simulation is determined by a Boolean
expression on the status of the Detectors, page 295, in the area regulated by a Controllers, page 305 in
the edit area. The parameters of actuated signal operations are always expressed in relation to the state of the
base signal, which is one of the signals dependent on the controller. Thus, you reduce the number of parameter modifications inferred by a translation of the diagram, a change of cycle, a re-ordering of phases, or a
modification of the duration of a phase not concerned by the actuated signal operation, etc. The base signals
changes of state determine when to apply the actuated signal operation. The base signal also determines the
time reference system, the clock associated with the actuated signal.
Coordination points differ from actuated signal operations in that they only modify the duration of the
states of signals dependent on different controllers. Moreover, the condition for their application is not determined by Detectors, page 295.
This section describes the four actuated signal operations:
Retraction, page 319,

Phase retraction, page 319,
Shift, page 320,
Relaxing point, page 320,

and one non-actuated signal operation which modifies the execution of the signal program, represented by:
Coordination points, page 321.
318
CLASSIC PROGRAMING
Retraction
The retraction is an actuated signal operation used to reduce the duration of the cycle by removing variable
time ranges depending on the state of the detectors.
RETRACTION PARAMETERS
LABEL
Base signal
Start
Duration
Interval
time
One of the controllers signals, used as the base.

Expressed in relation to the start of the signals green state in seconds; defines the moment when
the controller starts to test the state of the detectors.
For a null Offset value, it represents the start of the retracted time range.
Expressed in seconds, corresponds to the maximum duration of the retracted time range. Start
and Start + Duration - Interval time determine the time range during which the detectors are
tested.
Expressed in seconds, defines the time between two retraction attempts.
Minimum time in seconds between the retraction and the next actuated signal operation for this
controller.
Offset
Time in seconds between the satisfaction of the condition established on the detectors, and the
application of the retraction.
Detectors
Subset of Detectors, page 295 associated with the Controllers, page 305. If none of the
detectors are active, the retraction is applied.
If a Shift, page 320 inserts green time in the base signal before the start of the corresponding retraction,
the retraction is always triggered at the same relative position at the beginning of the base signals green
phase. Furthermore, the number of retracted seconds is not increased by the number of seconds inserted. If a
shift inserts green time inside a retracted time range, the maximum retracted time remains constant. If a
Shift, page 320 inserts green time in the base signal after the end of the retracted time range, there is no
effect on the retraction.
You cannot define a retraction whereby the time range to retract overlaps two cycles. In this case, you
must translate the signal diagram to reposition the retracted time range as appropriate. This error is
not signaled, either when editing, or during the simulating of the model.
Phase retraction
The phase retraction is an actuated signal operation used to reduce the duration of the cycle by removing
fixed variable time ranges. The state of the detectors is tested once only in this case.
PHASE RETRACTION PARAMETERS

LABEL
Base signal
Start
319
DESCRIPTION
Expressed in relation to the start of the base signals green phase, in seconds. Defines the moment
when the controller starts to test the detectors. If the Offset value is null, it also represents the
start of the retracted time range.
SIGNALS MODULE
Minimum
DESCRIPTION
PHASE RETRACTION PARAMETERS
LABEL
DESCRIPTION
Duration
Expressed in seconds, defines the maximum duration of the retracted time range. Start and Start
+ Interval time determine the time range during which the detectors are tested
Minimum
Minimum time in seconds between the phase retraction and the next actuated signal operation for
this controller.
Offset
application of the phase retraction.
Detectors
Subset of Detectors, page 295 associated with the Controllers, page 305. If none of the
detectors are active, the retraction is triggered at Start.
Shift
A shift is an actuated signal operation used to remove a time range and insert it elsewhere in the signal program. In this case, the cycles duration remains constant. It is applied to all or some of the controllers signals. It is used to model the line retraction and the adaptivity by line.
SHIFT PARAMETERS
LABEL
Base signal
Start
Duration
DESCRIPTION
Expressed in relation to the start of the base signals green phase, in seconds. Defines the
moment when the controller starts to test the state of the detectors. If the Offset value is null
and the condition on the detectors is satisfied, it also represents the start of the retracted time
range.
Expressed in seconds, defines the maximum duration of the retracted time range. Start and
Start + Interval time determine the time range during which the detectors are tested
Add position
Expressed in seconds in relation to the beginning of the base signals red phase, position in the
cycle where the controller adds the removed time range.
Interval time
Expressed in seconds, defines the time between two shift attempts.
Minimum
Minimum time in seconds between the shift and the next actuated signal operation for this controller.
Offset
application of the shift.
Signals
Detectors
Subset of signals at the crossroads which, in addition to the base signal, are affected by the
shift operation.
Subset of Detectors, page 295 associated with the Controllers, page 305. The shift is
triggered if none of the detectors are active.
For a shift, the retracted time range cannot overlap two cycles.
Relaxing point
The relaxing point is an actuated signal operation that consists in stopping the flow of the signal program
on a detector, usually a Presence detector, page 301 placed near the Stop line, page 202, or the
Pedestrian push-button, page 303. The relaxing point is applied to all the signals at the crossroads.
320
CLASSIC PROGRAMING
RELAXING POINT PARAMETERS

LABEL
Base signal
Start
DESCRIPTION
Expressed in relation to the start of the base signals green phase, in seconds. Defines the position of the relaxing point. Signals stay in this state as long as one of the detectors is not activated.
Interval time
Time in seconds between two detector status checks (corresponds to the systems reactivity).
Detectors
Subset of Detectors, page 295 associated with the Controllers, page 305. The relaxing
point is activated (i.e. the signal program is frozen) if none of the detectors are active.
Coordination points
Coordination points are used to synchronize the signals at different controllers in a signals scenario. You
position rendezvous points on the different controller diagrams. The execution of the signals program is
interrupted at the coordination point until all the controllers reach the same coordination point in their cycles.
LABEL
CP
Start
DESCRIPTION
Unique name of the coordination point.
Position of the coordination point, expressed in seconds since the start of the controllers
cycle.
A coordination point cannot be positioned in a time range removed by a Retraction, page 319, or by
a Shift, page 320. However, it can figure indiscriminately before or after a retracted time range, or
it can be inserted by a Shift, page 320.
321
SIGNALS MODULE
COORDINATION POINT PARAMETERS
Edit actuated signal operation

To add an actuated signal operation:
1.
Click the
2.
If necessary, click on the + located after the name of the controller to switch to extended mode.
If necessary, adjust the display, shift + left click to zoom in or shift + right-click to zoom out.
In the "Programing display area" (see fig. 194, page 313), right-click the signal program you
want to link to an actuated signal operation, preferably the base signal.
Hold to display the actuated signal operations contextual menu.
Drag the mouse to the menu command corresponding to the actuated signal operation you want to
link to your program, then release.
3.
4.
5.
6.
7.
8.
9.
10.
Adjust the actuated signal operations parameters displayed in the edit parameters area.
a
Retraction: Retraction parameters, page 319
b. Phase retraction: Phase retraction parameters, page 319

c. Adaptivity: Shift parameters, page 320
d. Coordination point: Coordination point parameters, page 321
e. Relaxing point: Relaxing point parameters, page 321.
Click Apply to confirm the actuated signal operation parameters.

If necessary, edit other actuated signal operations, or program other signals.
13. You need to confirm your changes to the signal scenario. Click Back in the command area to go
back to the "Signals module entry window in edit signal scenario mode" (see fig. 192, page 310).
14. Click Apply in the command area.
15. Click Quit to close the window.
11.
12.
To delete an actuated signal operation:

1.
2.
3.
4.
5.
322
Select the appropriate operation in the "Programing display area" (see fig. 194, page 313).
Click Delete.
You need to confirm your changes to the signal scenario. Click Back in the command area to go
Click Apply in the command area.
CLASSIC PROGRAMING
To edit an actuated signal operation:
1.
2.
3.
4.
5.
6.
Select the appropriate operation in the Programing display area, page 313.
Modify the parameter values in the edit parameters area.
Click Apply to apply these modifications.
You need to confirm your changes to the signal scenario. Click Back in the command area to go
Click Apply in the command area.
Information
area
Zone
dinformation
Graphic
representation
SIGNALS MODULE
Display area
Edit area
Figure 196. Actuated signal operation edit window for a retraction
323
Information area
Graphic
representation
Display area
Edit area
Figure 197. Actuated signal operation edit window for a phase retraction
324
CLASSIC PROGRAMING
Information area
Display area
Edit area
Figure 198. Actuated signal operation edit window for an adaptivity
Information area
Display area
Graphic
representation
Figure 199. Actuated signal operation edit window for a relaxing point
325
Edit area
SIGNALS MODULE
Graphic
representation
Information area
Display area
Edit area
Graphic
representation
Figure 200. Actuated signal operation edit window for a retraction for a coordination point
Examples of signal programs with CubeDynasim

This section describes the modeling of six sets of signals from their diagrams and their associated actuated
signal operations.
In each case, you define the parameters of the signal scenarios, i.e. declare the coordination points, quantify
and name the crossroads, define the diagrams of these crossroads and the actuated signal operations.
These six programing examples are as follows:
326
Example 1: Retraction and Phase retraction, page 327,

Example 2 : Shifts, page 328,
Example 3 : Relaxing point, page 329,
Example 5 : Coordination points and retractions, page 331,
Example 6 : Retractions and adaptivities, page 333.
CLASSIC PROGRAMING
Example 1: Retraction and Phase retraction
The diagram comprises three retractions (marked var), and one phase retraction (marked esc). These operations depend on the state of the detectors specified on the diagram.
This diagrams operation is modeled using 3 Retraction, page 319, and 1 Phase retraction, page 319.
The table lists the parameter values of each programing. The Interval time of the phase retractions is set to 2
seconds; the green signal durations vary in 2-second increments ;
PHASE RETRACTION AND ADAPTIVITY
Retraction,
page 319
Phase retraction,
page 319
var
b1 OR b2
var
b3 OR b4
va
b5 OR b6
Base Signal
F1
F3
F5
Start
10
Start
Duration
12
Duration
14
Interval time
Minimum
Minimum
Offset
Offset
Detectors
b1, b2
b3, b4
b5, b6
F3
0
SIGNALS MODULE
Detectors
Base Signal
esc
b3 OR b4
b3, b4
esc b3 OR b4
C360
var b1 OR b2
var b3 OR b4
var b5 OR b6
F1
F2
F3
F4
F5
F6
P1a
P1b
P2a
P2b
P5
P6
10
0
327
12
10
7
22
5
29
6
34
3
40
5
43
6
48
4
54
7
58
5
65
70
Example 2 : Shifts
The table describes the possible parameter values for modeling the two shifts represented on the diagram.
Note the Add position parameter, set to 5 seconds for the first adaptivity (instead of 4 seconds). If the position where you add time coincides with a signals change of state, the time is added before the change of
state. Here, we want to add green time to signals F4 and P1b, hence the value of Add position.
LINE ADAPTIVITY
Shift, page 320
shift
b1 OR b2
shift
b3 OR b4
Base Signal
F2
F3
Start
10
Duration
12
Add position
Interval time
Minimum
Offset
F4, P1b, P6
F4, F5, P2a, P6
b1, b2
b3, b4
Signals
Detectors
C362
shift b1 OR b2
shift b3 OR b4
F1
F2
F3
F4
F5
F6
P1a
P1b
P2a
P2b
P5
P6
10
0
328
12
10
7
22
5
29
6
34
3
40
5
43
6
48
4
54
7
58
5
65
70
CLASSIC PROGRAMING
Example 3 : Relaxing point
This table defines the parameters of a relaxing point as defined by the diagram.
RELAXING POINT
Relaxing point, page 320
PR
bp
Base Signal
F1
Start
24
Interval time
Detectors
1
bp
bp
PR
C361
F1
P1
P2
6
329
18
6
24
12
30
18
42
60
SIGNALS MODULE
F2
Example 4 : Coordination points
This diagram defines the coordination point parameters used to model the coordination points and adaptivities see Coordination points and adaptivities no. 4, page 330). The signals are grouped inside two Controllers, page 305 named C1 and C2. In addition, the diagrams modeling requires you to define 3 retractions
(these will not be configured here).
COORDINATION POINTS AND ADAPTIVITIES NO. 4

Coordination points, page 321
C1
CP
Start
C2
CP
Start
0
CP0
63
CP0
36
0
var b1
c1
F1
var b2
var b3 OR
F2
F3
F4
p4
6
0
28
6
6
5
34 39
18
0
c2
F1
F2
25
0
330
5
6 4 5
25 30 36 40 45
5 6
63 68
9
83
CLASSIC PROGRAMING
Example 5 : Coordination points and retractions
This section describes how to model Coordination points and retractions no. 5, page 331. This involves a
signal program with 4 Controllers, page 305 - C0, C1, C2, C3. The controllers are coordinated by 4
Coordination points, page 321 - CP0, CP1, CP2, CP3. For each controller, you model the retractions (var
on the diagram) using Retraction, page 319.
COORDINATION POINTS AND RETRACTIONS NO. 5

CP
Start
CP0
CP3
45
Retraction, page 319

var b1
Base Signal
Start
Duration
C0
Start
CP0
CP1
CP3
32
59
100
C1
Minimum
Offset
CP
Start
C2
CP1
CP2
CP3
41
51
var b3
Base Signal
F2
F3
Start
32
13
Duration
27
16
Interval time
Minimum
Offset
b2
b3
var b4 or b5
Base Signal
F4
Start
29
Duration
10
Interval time
Minimum
Offset
Detectors
331
b1
var b2
Detectors
1
19
b4 or b5
SIGNALS MODULE
CP
Interval time
Detectors
0
F1
COORDINATION POINTS AND RETRACTIONS NO. 5
CP
Start
Retraction, page 319
CP0
CP2
CP3
48
54
C3
var b6
var b7
Base Signal
F6
F7
Start
10
Duration
14
16
Interval time
Minimum
Offset
b6
b7
Detectors
C363
var b1
F1
P1
2
19
12
1
var b2
var b3
F2
P3
F3
P2
32
27
16
13
2
var b4 OR b5
F4
F5
2
25
10
2
var b7
var b6
F6
F7
2
332
16
10
14
CLASSIC PROGRAMING
Example 6 : Retractions and adaptivities
This section defines how CubeDynasim is used to model "Diagram 6: Retractions, adaptivity, and priority
vehicles" (see fig. 201, page 333). This diagram is split into two phases for non-priority vehicles, and two
phases dedicated to priority vehicles, regulated by signals T11 and T12
PR
PR
Var Appel
TC 1 OR 2
Var Appel
TC 1 OR 2
Var Appel
TC 1 AND 2
Var Appel
TC 1 AND 2
F00, F03
F01, F04
F02, F05
F06, F08
F07
F09
F10
6
22
14
3 2 2
10
Phase 2
Phase 1
Figure 201. Diagram 6: Retractions, adaptivity, and priority vehicles

In the absence of priority vehicles, the green lights of signals T11 and T12 are retracted, and only the two
vehicle phases remain unmodified. When a priority vehicle arrives, the duration of the phase regulating the
flow of non-priority vehicles is reduced. The diagram is subsequently executed up to the relaxing point. The
priority vehicle at the crossing of the stop line checks out of the relaxing point. The phase regulating the
movement of priority vehicles ends after taking account of the clearance times in "Diagram 6: Time chart of
the simulated signals" (see fig. 202, page 333).
F00, F03
F01, F04
F02, F05
F06, F08
F07
F09
F10
T11, T12
20
Figure 202. Diagram 6: Time chart of the simulated signals
333
SIGNALS MODULE
T11, T12
The actuated signal operations are determined by two Check-in/check-out with delay, page 296 (Acq_N
and Acq_S) and two Not check-in/check-out with delay, page 298 (AcqNo_N, AcqNo_S) corresponding
to each direction of the traffic. The detector entry markers are positioned upstream of the signal, while their
exit markers are located just after the stop lines. Signals T11 and T12 regulating the passage of priority vehicles have two green light time ranges corresponding to the priority granted at the end of the first and second
phases of non-priority vehicles. In accordance with the technique presented earlier (see Signals, page 290),
these signals are modeled by two signals, T11 and T11b, and T12 and T12b (see "Diagram 6: signals for
CubeDynasim", fig.203 p.334).
F00, F03
F01, F04
F02, F05
F06, F08
F07
F09
F10
T11, T12
T11B, T12B
3
28
3 2 2
20
10
Figure 203. Diagram 6: signals for CubeDynasim

The retractions in the two phases dedicated to priority vehicles are modeled by two Retraction, page 319
whose parameter values are given in Table 4, "Retraction parameters in diagram 6", page 334.
TABLE 4. Retraction
parameters in diagram 6
Start
Durat
ion
T11 ou T12
11
11
Acq_N or Acq_S
T11b ou T12b
13
13
Acq_N or Acq_S
Base signal
Interval
time
Minimum
Offset
Condition
The two adaptivities applied to the phases dedicated to non-priority vehicles are modeled in CubeDynasim
using Retraction, page 319 based on the parameters in Table 5, "Adaptivity parameters in diagram 6",
page 334.
TABLE 5. Adaptivity
Base
signal
334
parameters in diagram 6
Start
Durat
ion
Interval
time
F00
22
AcqNo_N and AcqNo_S
FO6
14
AcqNo_N and AcqNo_S
Minimum
Offset
Condition
CLASSIC PROGRAMING
The parameters of the two Relaxing point, page 320 acknowledged when the priority vehicle crosses the
stop line are defined according to Table 6, "Relaxing point parameters in diagram 6", page 335.
TABLE 6. Relaxing
Base signal
point parameters in diagram 6
Position
Interval time
Condition
T11 ou T11
Acq_N or Acq_S
T11b ou T12b
Acq_N or Acq_S
The simulation issues error messages associated with the changing of the T11, T12, T11b or T12b signals
from the green state to the red state on retraction of the phases dedicated to priority vehicles.
Files generated
Generate report, page 410 includes for each controller programed in classic mode the generation of:
a
an image file of the programing in Encapsulated PostScript format.
b. a text file bringing together the actuated signal operations in the form of LaTex tables.
Those files are saved in the folder project name/Report/simulation scenario/signals/eps.
Dure
de ver
esc2
var3
C1
48"
8"
13"
10"
4
var3
53"
5
var3
48"
6
var3
48"
7
var3
48"
10"
9
1
0
4 1 5
9 13
19
12
36
31
4 1
67 71
Figure 204. Example of image file programing traffic line generated by CubeDynasim
335
4
81
5
85
90
SIGNALS MODULE
esc1
336
14
Socket programming
DynasimServer, page 338: defines the communication protocol between the simulation and the external user program.
The Socket library, page 345 is a C++ library that facilitates the quick implementation of programing the traffic lights.
You can directly connect a simulation to Utopia, page 399 which is a centralized traffic lights control
system developed by the company SWARCO Mizar. For more information, please refer to the manufacturer's documentation
337
SOCKET
PROGRAMMING
This chapter describes the three methods to switch states of the traffic lights during simulation from an external user program. The simulation passes the states of the detectors to the user program. In return, the external
user program sends back the updated status of the traffic lights applied by the simulator. Communication is
defined according to a same time stamp and a TCP/IP connection.
YNASIMSERVER
D
DynasimServer
CubeDynasim lets you establish two-way communication between a simulation and an external program.
The simulation sends the status of the detectors to the external program; this program determines the new
signal state of the signals and sends it to the simulation. Exchanges only concern detectors and signals associated with socket controllers (see Controller parameters, page 306). The frequency at which this data is
exchanged is defined by the controllers Inter-com duration.
In a client-server architecture, the external program works as a server, provided the simulation works like a
client. Thus, a single signal control program can drive different replications of a same simulation scenario. In
other words, it is not necessary to launch several times the same program while replicating a simulation scenario.
This section describes the communication between the simulation engine and an external program which calculates the state of the signals.
DynasimServer on the server side (external program), page 338,

DynasimServer on the client side (micro simulator), page 341.
DynasimServer on the server side (external program)

The external program works like a server; it must define the state of the signals from the status of the detectors sent to it by the current simulation.
The external program and the simulation communicate via an API (Application Programming Interface) that
defines a set of functions in C language. Using C language means, in theory, that this API will work with any
language that supports DLLs. The API consists of a ". h" file that contains the APIs function definitions, and
a DLL that contains the API code.
API functions, page 338,

Sample programming, page 340,
Compiling the server program, page 341
API functions
The API is characterized by 5 C functions. These functions all refer to the Server_C containing the communication server data. For the programmer of the external program, the type Server_C is transparent. It sends
the structure to the API functions without having to manipulate or know this data structure.
The 5 API functions are:
Launch server, page 338,

Receive information from the simulator, page 339,
Request the status of a detector, page 339,
Set signal state, page 339,
Send information to the simulator, page 339.
Launch server
void createDynasimServer (long nPort, void (*program) (Server_C))
nPort : port number to communicate with the server,

program : function pointer, function takes one Server_C parameter and returns a void value.
This function activates the server able to communicate with the simulations. The call is inhibiting; it does not
therefore give you control. For each connection request by a simulation, the program function is run once
and once only.
338
DYNASIMSERVER
Generally speaking, the program function is like a never-ending loop that runs the operations:
request the simulation for the status of the detectors,
2. calculate the new state of the signals,
3. send this new state to the simulation.
1.
For Windows, the server program should only use automatic variables defined on the stack. In other
words, the code of the server must be reentrant.
void createDynasimServerAndExecuteOnce (long nPort, void (*programmation) (Server_C))
Same as createDynasimServer, after a first connection the server program will exit.
Receive information from the simulator
void DynasimServer_receive (Server_C server)
server : type Server_C

Receive information from the simulator such as the current status of the detectors. This call is inhibiting as
long as the simulation has not sent the status of the detectors (e.g. if the simulation has not finished simulating the Inter-com duration since the last call to DynasimServer_receive)

idDetector : unique detector name
Return the status of the detector designated by the parameter idDetector. Return -1 if the detector is not
defined for the simulation model. At each time step, it is first necessary to call once
DynasimServer_receive, then call DynasimServer_getDetector for each of the detectors which is
desired to know the state.
Set signal state
void DynasimServer_setSignal (Server_C server, const char *idSignal, char state)

idSignal : unique signal name
state : signal state: 0 (blocking) or 1 (passing)
This function is used to set the state of a signal. The two possible states are: passing (value 1), and blocking
(value 0). The yellow duration is defined following the type of signal. For an R11 signal (i.e. the change from
green to red) is set to 3 seconds (for this version). For an R12 signal, the yellow duration is obviously null.
The simulator does not check whether the yellow duration is respected for a switch from red to green; If the
signal is not defined for the simulation, this function has no effect. You set the state of all the signals using
the DynasimServer_setSignal function, you then send the state of the signals to the simulation using the
DynasimServer_send function.
Send information to the simulator
void DynasimServer_send (Server_C serveur)
serveur : type Server_C

This function is used to send the current state of the signals to the simulator.
339
char DynasimServer_getDetector (Server_C server, const char *idDetector)
SOCKET
PROGRAMMING
Request the status of a detector
YNASIMSERVER
D
Sample programming
Suppose you want to simulate a model with one signal C1_1_R11_1, and one detector C1_1_ADA_1. The
signal has a 30-second cycle. Beginning at time 0, the signal C1_1_R11_1 is green for 10 seconds, then yellow for 3 seconds. If a vehicle activates the detector on the 9th second, the signals stay in the same state.
After the vehicle deactivates the detector, the signal cycle continues, executing the remaining 21 seconds. It
mimics a relaxing point 9 seconds after the beginning of the cycle. The states are updated every second.
Example of a server in language C

/* include the definition file of the API*/
#include "DynasimServerCAPI. h"
void prog (Server_C svr) {
long localtime = 0 ;
for (;;) {
/* initialize the status of the detectors received from the simulator (the client) */
DynasimServer_receive (svr) ;
if (localtime ! = 9 || DynasimServer_getDetector (svr,"C1_1_ADA_1") ! = 0){
/* increment time */
++localtime ;
}
if (localtime > = 30){
/* end of cycle */
localtime = 0 ;
}
if (localtime > 9){
/* the signal status is blocking if cycle time is beyond 9s */
DynasimServer_setSignal (svr,"C1_1_R11_1", 0) ;
}
else{
/* the signal is in the passing state else */
DynasimServer_setSignal (svr,"C1_1_R11_1", 1) ;
}
/* send the signal status to the simulator (client) */
DynasimServer_send (svr) ;
}/* for */
} /* prog */
int main (int argc, char* argv []) {
/* creates and launches the server which calls the prog at each connection*/
createDynasimServer (15 000, prog) ;
return 0 ;
}
340
DYNASIMSERVER
Compiling the server program
The following files are required to compile the program:
DynasimServerCAPI.h: definitions of the API functions,

DynasimServerCAPI.dll: dynamic library needed to be linked to build the program,
libstdc++-6.dll, libwinpthread-1.dll, libgcc_s_dw2-1.dll: list of the dynamic library needed to execute
the program.
They are located in the CubeDynasim installation directory\socket.By default, the installation directory is:
C:\Program Files (x86)\Citilabs\CubeDynasim. You should copy the dll files in the folder of the executable
program.
DynasimServer on the client side (micro simulator)

This section describes the steps to follow to establish communication between the client (the CubeDynasim
model simulated) and the server (the program defining the signal control, as described above).
These steps are as follows:
Editing and naming objects in CubeDynasim, page 342,
2. Defining the client in CubeDynasim, page 344,
3. Simulation in client mode, page 344.
1.
SOCKET
PROGRAMMING
341
YNASIMSERVER
D
Editing and naming objects in CubeDynasim

You model the signals and detectors in CubeDynasim using the standard techniques. However, you must
adhere to a precise naming convention to allow for their interaction with the API. You must position the
appropriate Controller objects that contain the signals and detectors to be managed. Moreover, you must add
a signal scenario, and define the controller type as Socket.
This section describes the naming convention used for the:
Signals, page 342,

Detectors, page 342.
Signals
The names of the signals must adhere to the following format:
C{controller index}_{signal index}_{type}_{physical index}
where,
{controller index}: index of the controller programming the signal (unsigned integer).
{signal index}: index of the signal of the controller defined by the controller index (unsigned integer).
{type}: type of signal (R+2 characters), to be chosen among :
R11 : three-state signal green, yellow (constant duration 3), red (vehicles),
R12 : two-state signal green, red (pedestrians),
R13: dedicated to bus and two wheels,
R17 : three-state signal (tramway),
R25: to be edited in CubeDynasim with an R12,
RF3: four-state signal green, 3 seconds of flashing green (animated as fixed green), yellow and red.
{physical index}: is a numeric counter that designates the number of linked signals. It authorizes the creation of a set of signals that all have the same concatenation of states. In other words, it is used to position the same signal with different physical positions.
For example: C18_3_R11_1
Detectors
The name used by detectors adheres to the same naming convention principle as that used for signals, with
the following format:
342
DYNASIMSERVER
C{controller index}_{detector index}_{detector type}_{physical index}
where,
{controller index}: index of the controller which is connected to the detector (unsigned integer).
{detector index}: index of the detector (unsigned integer).
{type} detector type (3 characters), to be chosen among
ADA : detects the presence of a vehicle from the moment its front end "enters" the detector to the
moment its rear end "exits" the detector,
BLQ : accumulates the time a vehicle is present (same principle as the ADA). When the cumulated
time reaches 1 second, the detector is activated for 1 second and the cumulated time is reset to 0,
MAC : counts the number of passing vehicles. The count is incremented upon the detection of a passing vehicle. Querying the count resets it to is initial status (0),
MAD : counts the number of passing vehicles, like MAC, but does not reset the count upon querying.
Set to 0 at the start of the simulation,
BAV: detects the front of a passing vehicle. Equivalent to the amount detected by the front of an ADA
detector,
BAR : detects the rear of a passing vehicle. Equivalent to the amount detected by the rear of an ADA
detector,
MAT: records time duration since its last activation.
343
For example: C1_1_ADA_1
SOCKET
PROGRAMMING
{physical index} unsigned integer, generally 1.
YNASIMSERVER
D
Defining the client in CubeDynasim

We need to define a controller of type Socket.
1.
Click
on the Module bar, page 18 to display the signal module entry.
Click the signal scenario to be edited in the display area.

Click Configure to display the "Signals module entry window in edit controller scenario mode"
(see fig. 193, page 312)
4. Click on the name of the controller displayed in the display area. The controller is then framed in
blue.
5. Select Socket for the field named Type.
2.
3.
6.
7.
8.
9.
10.
Assign the Parameters of the controller of type Socket.

Click Apply.
Click Back to display the "Signals module entry window in edit signal scenario mode" (see
fig. 192, page 310).
Click Apply to validate the new parameters of the current signal scenario.
Click Quit to close the signals module entry window.
To define the parameters of the client of a traffic signal controller, you must select the type Socket and define
the parameters:
IP address of the computer hosting the server,
the associated communication port (start at 10000 to avoid conflicts with other hardware or software),
3. (simulated) time frequency in seconds between each data exchange.
1.
2.
Simulation in client mode

1.
2.
Start the sever program on the computer whose IP address is defined in the signals scenario.
Simulate a replication, page 414.
Check the error messages to identify potential connections, or simulation problems.
344
THE SOCKET
LIBRARY
The Socket library

CubeDynasim has a C++ library to program sensors and operations of complex actuated signals by an external program connected to the simulator via the API DynasimServer, page 338.
This section focuses on:
establish Prerequisites, page 345,

describe General architecture of the program, page 349,
"Compile and launch the server" (see fig. , page 355),
"Managing scenarios" (see fig. , page 356),
"Generate a log file" (see fig. , page 358),
"Classes and methods of the Socket library" (see fig. , page 364).
The Socket Library greatly facilitates the establishment and programming of traffic signals.
Before simulating, for each controller of type Classic, CubeDynasim will generate three sets of files in the
folder named Simul/<simulation scenario>/socket:
<id_controller>_enchainement.h: defines the duration and the sequence of the phases for the controller
named id_controller.
The simulation of a signal scenario of type Classic creates in the directory of the simulation scenario a folder
named socket including C++ files defining the programming of the signals and detectors in the Socket
library format:
all the detectors are defined in the file capteur.h

for each controller of the signal scenario:
file C{i}.h defines the controller C{i} and split the time line into N partitions (categorized as phases or
interphases). Each partition is named as C{i}ph{j}, where j is the partition number belonging to the
interval [1 ; N]. The j of a phase is necessarily an odd number. The j of an interphase is an even number.
file C{i}_enchainement.h defines the sequences of the partitions (phases and interphases).
Prerequisites
It is necessary to install the Code::Blocks that includes the C++ 32 bits compiler mingw32-g++ for Windows
(see http://www.codeblocks.org/downloads). You can change IDE, but you still need to use the compiler
mingw32-g++.
345
troller. A time range greater than 6 seconds during which none of the traffic lights changes state will be
considered as a phase. The other time ranges are interphases. The traffic light program must start with a
phase.
SOCKET
PROGRAMMING
capteur.h: contains the definition of all the detectors (in the socket format).
<id_controller>.h: contains the definition of phases and interphases for each controller named id_con-
T H E S O C K E T
LIBRARY
As a first step, we will create a C++ project and set the paths (include files, library simsocket) and the list of
libraries to be used by the project.
Launch CodeBlocks.
2. Create a new project of type Console application.
a File > New > Project
1.
b. Select C++, then click Next.
c. Edit a project name, and the folder of the CubeDynasim study
Name of
the project
Folder of
the study
d. Click Next.
e. Select GNU GCC, then click Finish.
346
THE SOCKET
3.
LIBRARY
Define paths and libraries of the project.

a
Project > Build Option.
We will in fact add 4 paths to ease the programming:

<installation folder of CubeDynasim>\socket\include
<installation folder of CubeDynasim>\socket\include\Architecture\Feux\RegExpCapteur\QSim
<installation folder of CubeDynasim>\socket\include\Architecture\Feux\Programmateur_DynasimClientSocket
347
SOCKET
PROGRAMMING
b. Select tab Search directories, Compiler, then Add to add the path of the .h files of the libsocket.
T H E S O C K E T
LIBRARY
<installation folder of CubeDynasim>\socket\include\Architecture\Logistique\GertrudeReims\QSim\DynasimClient_Socket.
c. Click Linker, Add. Select path <installation folder of CubeDynasim>\socket.
d. Click Linker settings, Add. Add library socket named as simsocket_mingw32.
e.
4.
348
Click again Add to add the library wsock32.
To avoid compilation warnings noticing signed and unsigned integer comparisons: click Compiler
settings, Other options. Add compiler option -Wno-sign-compare.
THE SOCKET
5.
6.
LIBRARY
Click OK.
Save project Maj+Ctrl+S.
Save the project as a CodeBlock template so that you can directly use those settings when starting a
new simsocket project.
File main.cc includes function main that initialize the server, and the function programming that defines the
traffic signal programming. The function named programming is called each time there is a connection to
the server.
Pattern of main.cc
// minimum list of files to include
#include "Server_DynasimClientSocket.h"
#include "Controler.h"
// avoid prefix name class
using namespace DynasimClientSocket;
void programming(Server_DynasimClientSocket *serveur){
// include files that defines the programming of 2 controllers, identified by C1 and C2
#include "C1.h"
#include "C2.h"
CI_ControlS::go(serveur);
}
int main(int argc, char* argv[]) {
Server_DynasimClientSocket serveur(10000, programming);
return 0;
}
349
SOCKET
PROGRAMMING
General architecture of the program
T H E S O C K E T
LIBRARY
The structure of the file defining the controller programming breaks down into:
1.
2.
3.
4.
5.
6.
Definition of the controller and the list of signals driven by the controller.
Definition of the phases defining the states of the signals driven by the controller.
Definition of the detectors that must match the detectors edited in the simulation model.
Definition of the detector conditions.
Definition of the regulation.
Definition of the phases duration and concatenation.
Only 1., 2. et 6. are mandatory.
350
THE SOCKET
LIBRARY
Example programming a traffic signal diagram
as
Ph
1
te
In
e
as
h
rp
2
e
as
h
P
3
t
In
e
as
h
p
er
//Contents of file C1.h programming the signal diagram
// Phase 1
Phase C1ph1("C1ph1", 1,
// signal
1 2 3
0., 1, 0, 0);
// Interphase Phase 2
// signal
1 2 3
0., 0, 0, 0,
4., 0, 0, 1);
// Phase 3
// signal
1 2 3
0., 0, 1, 1);
// Interphase Phase 4
// signal
1 2 3
0., 0, 0, 1,
2., 0, 0, 0);
// ** Definition of the phases concatenations
C1ph1.push_backRegul( * new NextPhase( 70, C1ph2 ) ); // phase 1
-> interphase 2
C1ph2.push_backRegul( * new NextPhase( 5, C1ph3 ) ); // interphase 2 -> phase 3
-> interphase 4
C1ph4.push_backRegul( * new NextPhase( 7, C1ph1 ) ); // interphase 4 -> phase 1
351
// ** Definition phases **
SOCKET
PROGRAMMING
// ** Definition of the controller

Controler C1("C1",3,
"C1_1_R11_1", // signal 1
"C1_2_R11_1", // signal 2
"C1_3_R12_1"); // signal 3
T H E S O C K E T
LIBRARY
Before simulating, for each controller of type Classic, CubeDynasim will generate three sets of files in
the folder named Simul/<simulation scenario>/socket:
1. capteur.h: contains the definition of all the detectors (in the socket format).
2. <id_contorller>.h: contains the definition of phases and the interphases for each controller named id_controller. A time range greater than 6 seconds during which none of the traffic lights changes state will be considered
as a phase. The other time ranges are interphases. The traffic light program must start with a phase.
3. <id_controller>_enchainement: defines the duration and the sequence of the phases for the controller named
id_controller.
352
THE SOCKET
LIBRARY
It is recommended that you create one file for each controller. In our example, the programming of controller
number 1 is stored in file named C1.h. To add a new file to the project, defining the programing of the controller:
From CodeBlocks menu bar, click File > New File...
2. Click C/C++ header, then Go
1.
4.
Fill in the field Filename, then click Finish
Click Next, after selecting Skip this page next time.
SOCKET
PROGRAMMING
3.
353
T H E S O C K E T
5.
354
LIBRARY
The file is created and added to the project. You now must define the programming of the controller 2, and dont forget to include it (#include C2.h) in the programming(...) function defined in
the file main.cc.
THE SOCKET
LIBRARY
Compile and launch the server

To launch the server:
1.
Click button Build and Run
2.
If necessary, fix the compilation errors displayed in red in the window Build messages, and go
back to step 1.
SOCKET
PROGRAMMING
In our example, Phase is not defined, we have to include its definition file. Also, we have to
include the definition file of NextPhase.
3. When the compilation is error free, the server will start automatically. If the Windows Firewall
blocks the execution of the program, allow access to the network.
4. Start the simulation, i.e. the client (see Simulation in client mode, page 344).
5. The traffic signals, the detectors, and the possible errors are listed in the console window.
In our case, signal C1_5_R11_1 is defined in the simulation model, but it is unknown to the server
side. We must add it to the list of traffic lights handled by the controller, and define its state for
each phase (in file C1.h).
6. We can check the signals states during simulation, displayed in the animation view named C1.
Traffic light C1_5_R11_1 is not programmed, it remains red during the entire simulation.
355
T H E S O C K E T
LIBRARY
You can run the server directly without using CodeBlock if programming has not been modified (in
this case the server program does not need to be compiled/built). The title of the console gives the
location and the name of the server to be executed.
Managing scenarios
It is often necessary to test the signal timing plan on different geometrical configurations (network scenario)
and with different demand hypothesis (flow scenario). In these cases, the best practice is to design a project
per scenario. Each project must have its communication port number exclusively assigned.
In cases where the geometry of the junction remains the same while the demand varies (e.g. simulating peak
hours in the morning and in the evening), only the phase durations vary from one scenario to another (i.e. the
definition of the detectors, of the controllers and the signal timing plan remain the same). You should use
constant variables defining the durations of the phases. Files C1_control.h (defining the signals managed by
the controller 1), C1_detector.h (definition of the detectors), C1_prog.h (program depending on the phase
durations) are shared by different scenarios while file C1.h is specific to each scenario.
356
THE SOCKET
LIBRARY
Example of a project architecture for the morning peak hour

------ File contents main.cc in morning peak hour port:10000--...
void programming(Server_DynasimClientSocket *server){
#include "C1.h"
#include "C2.h"
CI_ControlS::go(server);
}
Server_DynasimClientSocket server(10000, programming);
return 0;
}
------ File contents C1.h defining traffic signal plan in the morning --const int C1_dtPh1 = 70; // duration in seconds of phase 1
const int C1_dtPh3 = 38; // duration in seconds of phase 3
357
------ File contents ../C1_prog.h --...

// ** Sequence and duration of the phases
C1ph1.push_backRegul( * new NextPhase( C1_dtPh1, C1ph2 ) ); // phase 1 -> inter 2
C1ph2.push_backRegul( * new NextPhase( 5, C1ph3 ) );
// inter 2 -> phase 3
C1ph3.push_backRegul( * new NextPhase( C1_dtPh3, C1ph4 ) ); // phase 3 -> inter 4
C1ph4.push_backRegul( * new NextPhase( 7, C1ph1 ) );
// inter 4 -> phase 1
...
SOCKET
PROGRAMMING
// file shared by the different scenarios, saved in the parent folder

#include "../C1_control.h"
#include "../C1_detector.h"
#include "../C1_prog.h"
T H E S O C K E T
LIBRARY
Example of a project architecture for the evening peak hour

------ File contents main.cc in the evening port:10001--...
#include "C1.h"
#include "C2.h"
}
Server_DynasimClientSocket server(10001, programming);
return 0;
}
------ File contents C1.h defining traffic signal plan in the evening --const int C1_dtPh1 = 40; // duration in seconds of phase 1
const int C1_dtPh3 = 30; // duration in seconds of phase 3
// file shared by the different scenarios, saved in the parent folder
#include "../C1_control.h"
#include "../C1_detector.h"
#include "../C1_prog.h"
Generate a log file

It is possible to generate a text file which describes the sequence of the phases base on the programming and
the status of the detectors.
Number of
seconds
since the
beginning
of the
simulation
Current
Phase
Phase
duration
in
seconds
New
phase
After 190 seconds of simulation

The controller 1 goes
from phase 1 to phase 2
Phase 1 lasted 70 seconds
Figure 205. Structure of a log file
358
THE SOCKET
LIBRARY
The log file is saved in the folder where the program server is executed (see the title of the console window).
It is named following the pattern LOGPROGFEU_<PID>, where PID is the process id of the program calculating the states of the traffic lights. Thus, each simulation has its own log file.
To generate a log file, you must define an environment variable named LOGPROGFEU. With CodeBlocks,
you should create a new environment defining the variable LOGPROGFEU. You can then simply switch
environments indicating whether a log file will be generated or not.
SOCKET
PROGRAMMING
359
T H E S O C K E T
LIBRARY
To define a new environment:
360
1.
Select Settings > Environment...
2.
Click Environment variables
3.
Click Create to define a new environment name. For example, trace_socket then click OK.
4.
Click Add to edit a new environment variable. Click OK.
5.
You can switch environment from the drop-down list.
THE SOCKET
6.
LIBRARY
Click OK to close the Environment settings entry window.
SOCKET
PROGRAMMING
361
T H E S O C K E T
LIBRARY
It is possible to add LOGPROGFEU (and its value) to the system environment or to the user environment,
which is recommended. In this case, the log file is generated for any executed server program. For example
on Windows 10:
362
1.
Hit Start button
+R at the same time to get the command prompt.
2.
3.
Type sysdm.cpl + Ok.

Click Advanced.
4.
Click Environment Variable.
THE SOCKET
6.
User Variables > New
7.
Fill in the field then click OK three times.
User variables > New
SOCKET
PROGRAMMING
5.
LIBRARY
The log files are never deleted by CubeDynasim. The user must delete the log files using Windows
Explorer.
363
T H E S O C K E T
LIBRARY
The simulator can generate two types of log files.

The file named progout.<random seed>.txt records the states of all the signals at each time step. The first column defines the time in quarter of seconds since the beginning of the simulation. The other columns define
the states of the signals following the order of the controller number and the signal number.
It is possible to generate a log file for each controller recording the states of the signals and the detectors at
each time step. To do so, you need to edit file modele.feux.h saved in the simulation scenario folder. Look for
the command line starting with Timer_DynasimClientSocket and add the list of the controller numbers to
be recorded at the end of this line (each number is separated by a space). The log file name follows the pattern: <controller number>.<random seed>.txt. Those log files are saved in the simulation scenario folder.
Please note that the file modele.feux.h will be generated (overwritten) each time the simulation model is
modified. In this case, that file must be edited again to add the list of controllers to be logged.
It is possible to check whether the status of the signal passed to the simulator complies with the safety
time. To do this, it is necessary to edit a file named modele.matsec to define the safety times following
the format:
<signal 1> <signal 2> <minimum duration in seconds between closing 1 and opening 2 >
The file modele.matsec must be stored in the simulation scenario folder.
Classes and methods of the Socket library

All of the elements of the socket library are defined in the namespace DynasimClientSocket. C++ class are:
364
Controler, page 365,

Phase, page 366
Capteur, page 367
QsOu_RegExpCapteur, page 368
QsEt_RegExpCapteur, page 369
QsXor_RegExpCapteur, page 370
QsNo_RegExpCapteur, page 370
QsAcquitte_RegExpCapteur, page 371
QsDAGeLt_RegExpCapteur, page 371
QsDALt_RegExpCapteur, page 372
QsDALe_RegExpCapteur, page 373
QsAttGEattMax_RegExpCapteur, page 373
QsDaMax, page 374
NextPhase, page 375
NextPhaseAtTime, page 377
PointRepos, page 379
Adaptativ, page 380
Switch, page 384
ChgeEtat, page 385
PC, page 386.
THE SOCKET
LIBRARY
Some basics in the C++ language which are sufficient to program the socket library:
a
a statement always ends with a ;
b. a list of parameters is bounded by ( et ), the parameters are separated by commas ,

c. a string contains at least one character which is delimited by a double quotation marks
d. a real is represented by a sequence of numbers including necessarily a point defining the decimal
number and this in order to distinguish it from an integer (example 0. is necessarily a real)
e. a comment starts with //, and extend to the end of the physical line. A comment is not taken into
account by the compiler. The comment is there to help the reader understand the code.
Controler
To define an ordered set of traffic signal. The last created controller is the current controller. All the phase
definition and programming operations apply to this current controller.
Include file: Architecture/Feux/Programmateur_DynasimClientSocket/Controler.h
Constructor
Parameters:
Code example: define a controller C1 managing 2 signals C1_1_R11_1 and C1_2_R11_1

Controler C1("C1", 2, "C1_1_R11_1", "C1_2_R11_1");
The number of parameters of the constructor must be equal to the parameter number of signals
managed by the controller +2.
If the number of signals (second parameter) is less than the number of signals listed (third
parameter), for example:
Only the first signal will be managed by the controller. The second signal in the list, C1_2_R11_1 is
not programmed. There will be no error message.
If the number of signals (second parameter) is greater than the number of signals listed (third
parameter), for example:
All the listed signals are managed by the controller. However, a message should be displayed in the
console. You must fix the error, it can cause erratic behavior of the server.
Set an offset
oprateur +=(unsigned dms).
Parameter:
offset in seconds: positive integer.

Code example: define a 10 seconds offset for the controller C1
C1 += 10;
365
Each signal ID is a string.
SOCKET
PROGRAMMING
ID of the controller: string

number of signals managed by the controller: unsigned int
ordered list of signal IDs, those IDs match necessarily the IDs of the signals edited in CubeDynasim.
T H E S O C K E T
LIBRARY
The offset is necessarily less than or equal to the duration of the first phase of the controller.
Set the cycle duration of the controller
It is necessary to define the duration of the cycle if you want to maintain a constant cycle duration despite the
actuation. For example, it is necessary to keep a constant cycle time when defining a coordination among
multiple controllers. This method is to be used in conjunction with the method seTcycleRegulSouple of
class NextPhase.
Method: seTcycleReguleSouple(unsigned dcs).
Parameter:
cycle duration in seconds: positive integer

Code example: set the cycle duration at 120 seconds
C1.seTcycleReguleSouple(120);
Code example: define a controller
....
// include Controller definition file
...
Controler C1(
"C1",
// controller id
2,
// number of signals managed by the controller
"C1_1_R11_1", // id of signal 1
"C1_2_R11_1" // id of signal 2
);
C1 += 10; // define an offset of 10 seconds
....
Phase
A phase is defined such as an interval of time during which all the managed signals remain in the same
states. Contrarily, an interphase is the range of time between two phases where some of the signals change
state depending on the security and offset of the crossroads. The phase and interphase are modeled with
objects of type Phase. A new Phase is automatically added to the current controller (last controller created).
A Phase object includes a list of regulation objects (type CIV_Regul) that determine the sequence of the
phases.
Include file: Architecture/Feux/Programmateur_DynasimClientSocket/Phase.h
Phase implements interface CIV_PhForRegul.
366
THE SOCKET
LIBRARY
Constructor
Parameter:
ID phase, used by the log file (name of the phase defined by C{i}ph{j}, with i the controller number and j
phase number of the signal diagram): string
the number of instances which at least one signal changes its state: strictly positive integer (>0)
list of instances which at least one signal changes its state:
number of seconds from the beginning of the phase to apply the new State: positive real number
states of signals following the order of the list of signals of the controller. The number of signals
driven by the controller determines the number of states to define at each change of state: 0 blocking,
1 passing
Code example: declare an interphase including 2 changes of States
A phase contains an ordered list of regulation objects (implementing interface named CIV_Regul). For
example, it can be used to define a sequence of phases after a fixed time period. In this case, at each iteration
it traverses the list of the active phase up to one of the regulation triggers. Therefore, the order of the regulations is often important. You can add regulations in head and tail of the phase list.
Method: push_backRegul(CIV_Regul &regulation).
Add a regulation at the end of the regulation list of the phase
Parameter:
regulation object to be added at the end of the list: reference on a regulation object (CIV_Regul)
Method: push_frontRegul(CIV_Regul &regulation).
Add a regulation at the begin of the regulation list of the phase
Parameter:
regulation object to be added at the beginning of the list: reference on a regulation object (CIV_Regul)
Code example: add a regulation (link to another phase)
-> interphase 2
Capteur
The state of a detector sent by the simulator is retrieved on the server side using objects of type Capteur. The
Socket Library has several types of objects to combine Detectors, page 342 in order to easily express
complex conditions.
367
Add a regulation to a Phase
SOCKET
PROGRAMMING
....
// include Phase definition file
#include "Phase.h"
...
Phase C1ph4("C1ph4",// phase ID same as the object
2,
// two instances of signal state change
0., 0, 0, // start of phase, both signals are blocking
2., 0, 1 // after 2 seconds, signal 2 changes state to passing
);
// end of the list of parameters of the constructor
....
T H E S O C K E T
LIBRARY
Capteur implements interface CIV_QsRegExpCapteur.

Include file: Architecture/Feux/Programmateur_DynasimClientSocket/Capteur.h
Constructor
Parameter:
detector ID same as it has been edited in CubeDynasim: string

Code example: defining a detector
// include Capteur definition file
#include "Capteur.h"
...
Capteur C1_1("C1_1_ADA_1");
...
QsOu_RegExpCapteur
Defines a logical operator OR between a set of objects of type CIV_QsRegExpCapteur.
QsOu_RegExpCapteur implements interface CIV_QsRegExpCapteur.
Include file: Architecture/Feux/RegExpCapteur/QSim/QsOu_RegExpCapteur.h
Constructor
You can use two different constructors differentiated by their parameters.
Parameter Constructor 1: to be used with the method add (see below)
ID of the logical operation: string

Parameters Constructor 2: to be used when the operation is applied on only two arguments (implementing
CIV_QsRegExpCapteur).

first parameter of the operator: reference to CIV_QsRegExpCapteur
second parameter of the operator: reference to CIV_QsRegExpCapteur
Code example: OR with two operands
// include definition file of operator OR
#include "QsOu_RegExpCapteur.h"
...
QsOu_RegExpCapteur C1_1or2 ("C1_1or2", C1_1, C1_2);
...
Add an operand to logical operator OR: QsOu_RegExpCapteur

Method: add(CIV_QsRegExpCapteur &regRexp).
Parameter:
operand to be added: reference to CIV_QsRegExpCapteur.
368
THE SOCKET
LIBRARY
Return: pointer on the logical operator.
Code example: OR with three operands

//include definition file of operator OR
...
QsOu_RegExpCapteur C1_1or2or3 ("C1_1or2or3");
C1_1ou2ou3.add(C1_1)->add(C1_2) ->add(C1_3) ;
...
QsEt_RegExpCapteur
Defines a logical operator AND between a set of objects of type CIV_QsRegExpCapteur.
Constructor
You can use two different constructors differentiated by their parameters.
Parameter Constructor 1: to be used with the method add (see below)

Parameters Constructor 2: to be used when the operation is applied on only two arguments (implementing
CIV_QsRegExpCapteur).

first parameter of the operator: reference to CIV_QsRegExpCapteur
second parameter of the operator: reference to CIV_QsRegExpCapteur
Code example: AND with two operands
// include file definition of operator AND
#include "QsEt_RegExpCapteur.h"
...
QsEt_RegExpCapteur C1_1and2 ("C1_1and2", C1_1, C1_2);
...
Add an operand to logical operator AND: QsEt_RegExpCapteur

Method: add(CIV_QsRegExpCapteur &regRexp).
Parameter:
operand to be added: reference to CIV_QsRegExpCapteur.
369
Include file: Architecture/Feux/RegExpCapteur/QSim/QsEt_RegExpCapteur.h
SOCKET
PROGRAMMING
QsEt_RegExpCapteur implements interface CIV_QsRegExpCapteur.
T H E S O C K E T
LIBRARY
Return: pointer on the logical operator.
Code example: AND with three operands

...
QsOu_RegExpCapteur C1_1or2 ("C1_1or2");
QsEt_RegExpCapteur C1_1or2_andC3andC4 ("C1_1or2_andC3andC4");
C1_1or2_andC3andC4.add(C1_1or2)->add(C1_3) ->add(C1_4); // (C1 + C2) . C3 . C4
...
QsXor_RegExpCapteur
Defines a logical operator EXCLUSIVE OR between a set of objects of type CIV_QsRegExpCapteur.
QsXor_RegExpCapteur implements interface CIV_QsRegExpCapteur.
Include file: Architecture/Feux/RegExpCapteur/QSim/QsXor_RegExpCapteur.h
Constructor
Parameters:

first operand: reference to CIV_QsRegExpCapteur
second operand: reference to CIV_QsRegExpCapteur
Code example: EXCLUSIVE OR with two operands
// include file definition XOR operator
#include "QsXor_RegExpCapteur.h"
...
QsXor_RegExpCapteur C1_1xor2 ("C1_1xor2", C1_1, C1_2);
...
QsNo_RegExpCapteur
Defines a logical operator NOT, applied on an object of type CIV_QsRegExpCapteur.
QsNo_RegExpCapteur implements interface CIV_QsRegExpCapteur.
Include file: Architecture/Feux/RegExpCapteur/QSim/QsNo_RegExpCapteur.h
370
THE SOCKET
LIBRARY
Constructor
Parameters:
ID of the logical operator NOT: string

operand: reference to CIV_QsRegExpCapteur
Code example: operator NOT
// include file definition of operator NOT
#include "QsNo_RegExpCapteur.h"
...
QsEt_RegExpCapteur C1_1and2 ("C1_1and2", C1_1, C1_2);
QsNo_RegExpCapteur C1_no_1and2 ("C1_no_1and2", C1_1and2); // NOT (1 . 2)
...
It mimics a check-in/check-out detector depending on the states of two detectors of type MAD edited with
CubeDynasim. Return true if there is at least one vehicle between the two MAD detectors.
QsNo_RegExpCapteur implements interface CIV_QsRegExpCapteur.
Include file: Architecture/Feux/RegExpCapteur/QSim/QsAcquitte_RegExpCapteur.h
Constructor
Parameters:

object of type Capteur that defines the MAD check-in detector: reference to CIV_QsRegExpCapteur
object of type Capteur that defines the MAD check-out detector: reference to CIV_QsRegExpCapteur
Code example: Check-in/check-out
// include file definition of Check-in/Check-out
#include "QsAcquitte_RegExpCapteur"
...
Capteur C1_1("C1_1_MAD_1");
QsAcquitte_RegExpCapteur C1_1ac2 ("C1_1ac2", C1_1, C1_2);
...
QsDAGeLt_RegExpCapteur
The detector returns 0 if the approach time doesnt belong to the time interval [min; max), otherwise 1. The
values min and max are parameters of the detector (Ge for greater or equal min, and Lt for less than max).
371
SOCKET
PROGRAMMING
QsAcquitte_RegExpCapteur
T H E S O C K E T
LIBRARY
APPROACH TIME: the time required for a priority vehicle to reach a crossroads (more specifically the
stop line). It is calculated by positioning a detector of type MAT upstream the intersection at a
distance that depends on the desired journey time.
If a MAT detector positioned at 30 seconds of the stop line, the approach time is defined by 30 - status
of the MAT detector. Its value is effective when it greater than a threshold (such as -6 seconds). For a
less value we will consider that the priority vehicle already left the junction, or is blocked upstream the
stop line. You should add a check-in/check-out detector to ensure the presence of the vehicle.
QsDAGeLt_RegExpCapteur implements interface CIV_QsRegExpCapteur.
Include file: Architecture/Feux/RegExpCapteur/QSim/QsDAGeLt_RegExpCapteur.h
Constructor
Parameters:

object of type Capteur that defines the MAT detector: reference to CIV_QsRegExpCapteur
distance of the MAT detector in seconds: integer
lower bound of the time interval (greater or equal to min) in seconds: integer
upper bound of the time interval (lower than max) in seconds: integer
Code example: approach time included in the interval

#include "QsDAGeLt_RegExpCapteur"
...
Capteur C1_1("C1_1_MAT_1");
// approach time less than 9 seconds, with a MAT detector located at 34 seconds
QsDAGeLt_RegExpCapteur C1_1ac2 ("C1_0da9", C1_1, 34, -6, 9);
...
QsDALt_RegExpCapteur
Compares two approach time, returns 1 if the first approach time is less than the second approach time (Lt
for less than).
QsDALt_RegExpCapteur implements interface CIV_QsRegExpCapteur.
Include file: Architecture/Feux/RegExpCapteur/QSim/QsDALt_RegExpCapteur.h
Constructor
Parameters:
372

object of type Capteur that defines the first MAT detector: reference to CIV_QsRegExpCapteur
distance of the first MAT detector in seconds: integer
object of type Capteur that defines the second MAT detector: reference to CIV_QsRegExpCapteur
distance of the second MAT detector in seconds: integer
THE SOCKET
LIBRARY
Code example: strict comparison of two approach times

#include "QsDALt_RegExpCapteur.h
...
// 1 if 36-C1_1 < 42-C1_2
QsDAGeLt_RegExpCapteur C1_da1LTda2 ("C1_da1LTda2", C1_1, 36, C1_2, 42);
...
QsDALe_RegExpCapteur
Compares two approach time, returns 1 if the first approach time is less than or equal to the second approach
time (Le for less than or equal).
QsDALe_RegExpCapteur implements interface CIV_QsRegExpCapteur.
Parameters:

Code example: comparison of two approach times

#include "QsDALe_RegExpCapteur.h"
...
// 1 if 36-C1_1 <= 42-C1_2
QsDaLe_RegExpCapteur C1_da1LEda2 ("C1_da1LEda2", C1_1, 36, C1_1, 36);
...
QsAttGEattMax_RegExpCapteur
Returns 0 if the duration of the blocking state of a signal is greater than or equal to a threshold time.
QsAttGEattMax_RegExpCapteur implements interface CIV_QsRegExpCapteur.
Include file: Architecture/Feux/RegExpCapteur/QSim/QsAttGEattMax_RegExpCapteur.h
373
Constructor
SOCKET
PROGRAMMING
Include file: Architecture/Feux/RegExpCapteur/QSim/QsDALe_RegExpCapteur.h
T H E S O C K E T
LIBRARY
Constructor
Parameters:

the controller managing the signal to be tested: reference to Controler
position of the signal in the list of signals of the controller: integer (between 1 and N where N is the number of signals managed by the controller)
threshold of the duration of the blocking state in seconds: real

OPTIONAL
the threshold is increased by a constant time and two approach time: pointer on QsDaMax, page 374
Code example: threshold the duration of the blocking state of a signal
#include "QssAttGEattMax_RegExpCapteur.h"
...
...
// 0 if signal C1_1_R11_1 is in blocking state for at least 70 seconds
QsAttGEattMax_RegExpCapteur.h C1_1rGE36 ("C1_1rGE36", C1, 1, 70);
...
QsDaMax
Returns the maximum duration between a constant time (in seconds) and two approach times. The QsDaMax
can only be used as a parameter of a QsAttGEattMax_RegExpCapteur, page 373. The user can enhance
the socket library to define a new class that implements the interface CIV_QsRegExpCapteur and returns the
value of the QsDaMax test.
Include file: Architecture/Feux/RegExpCapteur/QSim/QsDaMax.h
Constructor
Parameters:
374

constant duration (minimal duration returned): positive integer or 0
THE SOCKET
LIBRARY
Code example: compare the duration of a blocking state of signal and the maximum of two approach
times
#include "QssAttGEattMax_RegExpCapteur.h"
...
...
...
// 0 if signal C1_1_R11_1 is blocking (yellow + red) since at least 10 sec increased from
// the maximum of 15 sec: approach time of C1_1_MAT-20s: approach time C1_2_MAT-50s
QsDaMax daMax ( "daMax", C1_1, 20, C1_2, 50, 15);
QsAttGEattMax_RegExpCapteur C1_1rGE36 ("C1_1rGE36", C1, 1, 70, & daMax);
...
To set the duration of a phase and the phase sequence, you must use object of type NextPhase. It is added at
the regulation list of the Phase using one of the two methods push_backRegul or push_frontRegul of the
phase object.
Two constructors can be used to create an object of type NextPhase depending on wether you want to set
constant duration, or define a sequence with an extension of phase duration conditionned by the status of a
detector (object implementing the interface CIV_QsRegExpCapteur). In addition, the NextPhase class
includes a method to simulate a junction coordination.
NextPhase implements interface CIV_Regul.
Include file: Architecture/Feux/Programmateur_DynasimClientSocket/NextPhase.h
Constructor
Constructor with constant phase duration
duration of the phase in seconds: real positive

next phase: reference to CIV_PhForRegul
375
SOCKET
PROGRAMMING
NextPhase
T H E S O C K E T
LIBRARY
Code example: sequence of phase with constant time duration

#include "Phase.h"
#include "NextPhase.h"
...
...
Phase C1_ph1("C1_ph1", 1, 0.,1,0);
Phase C1_ph2("C1_ph2", 2, 0.,0,0, 5.,0,1 );
...
// phase 2 triggers after 30 seconds
NextPhase C1_30ph2( 30, C1_ph2);
...
// phase 1 switches to phase 2 after 30 seconds
C1ph1.push_backRegul( C1_30ph2 );
...
Constructor with an extension of phase duration
minimum duration of the phase: real positive

phase is extended beyond its nominal time provided the value of the detector is other than 0: pointer to
CIV_QsRegExpCapteur
Code example: Sequence with extension of phase duration
#include "QsAcquitte_RegExpCapteur"
#include "Phase.h"
...
...
...
Phase C1_ph1("C1_ph1", 1, 0.,1,0);
Phase C1_ph2("C1_ph2", 2, 0.,0,0, 5.,0,1 );
...
// phase 2 after 6 seconds if the check-in/check-out detector is activated
NextPhase C1_10ph2( 6, C1_ph2, & C1_1ac2);
...
// phase 1 switches to phase 2 after 30 seconds
...
376
THE SOCKET
LIBRARY
Junction coordination
You can define a condition to offset a phase in relation to a local time base by calling the method reguleSouple of a NextPhase object. This feature requires a prior definition of the cycle duration of the controller (see
Set the cycle duration of the controller, page 366) because the local time base is calculated as the remainder
after division of the time since the beginning of the simulation and the cycle duration
Method: reguleSouple(double mini, double topCoordination).
Parameter:
minimum duration of the phase in seconds: real positive.

value of the coordination marker in seconds: real positive
Code example: junction regulation
#include "Phase.h"
...
NextPhaseAtTime
Define a sequence of phase depending on the simulation time using objects of type NextPhaseAtTime. The
object must be added to the list of the regulation of the Phase (actually of the inter-phase).
The constructor defines the phase duration ans the next phase at the beginning of the simulation. The method
add allows to add sequences of phase depending on the time elapsed since the beginning of the simulation.
The phase duration remains constant during the simulation.
NextPhaseAtTime implements interface CIV_Regul.
Include file: Architecture/Feux/Programmateur_DynasimClientSocket/NextPhaseAtTime.h
377
// readjust the end of the phase at marker 113 sec, with a minimum phase duration of 6 sec
C1_50ph4.reguleSouple(6,113);
...
// phase 3 switches to phase 4 if:
//
duration of phase 3 is 50 sec
// or the instant from the start of the simulation modulo 120s (cycle duration) equals 113sec
//
and phase 3 duration exceeds 6 sec
...
SOCKET
PROGRAMMING
// define cycle duration: 120 seconds

C1.seTcycleReguleSouple(120)
...
Phase C1_ph3("C1_ph3", 1, 0.,1,0);
Phase C1_ph4("C1_ph4", 2, 0.,0,0, 5.,0,1 );
...
// switch to phase 4 after 50 seconds
NextPhase C1_50ph4( 50, C1_ph4);
T H E S O C K E T
LIBRARY
Constructor
Constructor with constant phase duration
duration of the phase in seconds: real positive

Add a sequence of phase depending on the time elapsed since the beginning of the simulation
Method: add(double time, CIV_PhForRegul &nextPhaseAtTime_time).
Parameter:
number of seconds since the beginning of the simulation: real positive.

next phase after time seconds of simulation: reference to CIV_PhForRegul
378
THE SOCKET
LIBRARY
Code example: phase sequence depending on the time elapsed since the beginning of the simulation
#include "Phase.h"
#include "NextPhaseAtTime.h"
...
// Phases from 8:00 until ...
Phase C1_0800_ph1("C1_0800_ph1", 1, 0.,1,0);
Phase C1_0800_ph2("C1_0800_ph2", 1, 0., 0,1);
// Phases from 8:30 until ...
Phase C1_0830_ph1("C1_0830_ph1", 1, 0.,1,0);
Phase C1_0830_ph2("C1_0830_ph2", 1, 0., 0,1);
NextPhaseAtTime C1_next__i12( 3, C1_0800_ph2);

C1_next__i12.add( 1800, C1_0830_ph2);
NextPhaseAtTime C1_next__i21( 6, C1_0800_ph1);
C1_next__i21.add( 60, C1_0830_ph1);
C1_0800_ph1.push_backRegul( C1_next__0800_ph1 );
C1_i12.push_backRegul( C1_next__i12 );
C1_i21.push_backRegul( C1_next__i21 );
...
PointRepos
Object of type PointRepos allows to simulate a relaxing point applied to a phase (see Relaxing point,
page 320). Relaxing point will freeze the sequence of the controller while its detector returns non zero values. In other words, the relaxing point is released when its detector returns a 0.
PointRepos implements interface CIV_Regul.
Include file: Architecture/Feux/Programmateur_DynasimClientSocket/PointRepos.h
379
NextPhase C1_next__0830_ph1( 30, C1_i12);

SOCKET
PROGRAMMING
// Interphases
Phase C1_i12("C1_i12", 1, 0., 0,0);
Phase C1_i21("C1_i21", 1, 0., 0,0);
...
// phase sequence definition
T H E S O C K E T
LIBRARY
Constructor
Parameters:
ID of the regulation to be used by the log file: string

position of the relaxing point in seconds, from the beginning of the phase: real
the detector releasing the relaxing point: reference to CIV_QsRegExpCapteur
Code example: relaxing point conditioning a phase switch
#include "QsAttGEattMax_RegExpCapteur.h"
#include "Phase.h"
#include "PointRepos.h"
...
Controler C1("C1", 3, "C1_1_R11_1", "C1_2_R11_1", "C1_3_R11_1");
...
Phase C1_ph1("C1_ph1", 1, 0., 1,0,0);
Phase C1_ph2("C1_ph2", 2, 0., 0,0,0, 4., 0,0,1);
Phase C1_ph3("C1_ph3", 1, 0., 0,1,1);
Phase C1_ph4("C1_ph4", 2, 0., 0,0,1, 2., 0,0,0);
...
// 0 if signal C1_1_R11_1 is blocking (yellow + red) since 70 sec
QsAttGEattMax_RegExpCapteur C1_rF1_ge_70("C1_rF1_ge_70", C1, 1, 70 );
...
// relaxing point at 10 seconds, released if blocking duration of C1_1_R11_1 >= 70 seconds
PointRepos C1_pr10_rF1_ge_70("C1_pr10_rF1_ge_70",10, C1_rF1_ge_70);
NextPhase C1_10ph4(10, C1_ph4);
// add regulation objects to phase 3
C1_ph3.push_backRegul( C1_pr10_rF1_ge_70 );
C1_ph3.push_backRegul( C1_10ph4 );
...
/*
Preview of a log file for this simulation
70 : C1_ph1, 70 : -> C1_ph2
75 : C1_ph2, 5 : -> C1_ph3
85 : C1_ph3, 10 : C1_pr10_rF1_ge_70 wait
140 : C1_ph3, 10 : C1_pr10_rF1_ge_70 free
140 : C1_ph3, 10 : -> C1_ph4
*/
Adaptativ
Object of type Adaptativ allows to simulate a Retraction, page 319 applied to a phase. It defines a
variable time range applied as long as its detector returns 1. In other words, let [t1;t2) define the time range.
If the current time t is in this time range and the detector returns 0, t will be reassigned to t2.
Adaptativ implements interface CIV_Regul.
Include file: Architecture/Feux/Programmateur_DynasimClientSocket/Adaptativ.h
380
THE SOCKET
LIBRARY
Constructor
Parameters:

lower bound of the time range (t1) in seconds from the beginning of the phase: real
upper bound of the time range (t2) in seconds from the beginning of the phase: real
detector conditioning the variable time range applied: reference to CIV_QsRegExpCapteur
Code example: retraction
// add regulations to phase 3

C1_ph3.push_backRegul( C1_esc6_20_1ac2 );
...
/*
50 : C1_ph1, 50 : -> C1_ph2
55 : C1_ph2, 5 : -> C1_ph3
61 : C1_ph3, 20 : C1_esc6_20_1ac2 adapt
61 : C1_ph3, 20 : -> C1_ph4
68 : C1_ph4, 7 : -> C1_ph1
118 : C1_ph1,50 : -> C1_ph2
*/
EscamotLigne
Object of type EscamotLigne allows to simulate a Shift, page 320 to a phase. The purpose is to remove
time from a signal group and assign it to another signal group. In this case the cycle duration is not modified.
The actuation depends on the state of a detector (object of a type implementing CIV_QsRegExpCapteur). If
381

SOCKET
PROGRAMMING
...
#include "QsAcquitte_RegExpCapteur.h"
...
#include "Phase.h"
#include "Adaptativ.h"
...
// 0 if no vehicle in between C1_1_ADA_1 and CA_2_ADA_1
...
...
Phase C1_ph1("C1_ph1", 1, 0., 1,0,0);
Phase C1_ph2("C1_ph2", 2, 0., 0,0,0, 4., 0,0,1);
Phase C1_ph3("C1_ph3", 1, 0., 0,1,1);
Phase C1_ph4("C1_ph4", 2, 0., 0,0,1, 2., 0,0,0);
...
// retraction if there is no vehicle and 6<= t <20
Adaptativ C1_esc6_20_1ac2("C1_esc6_20_1ac2",6, 20, C1_1ac2 );
T H E S O C K E T
LIBRARY
the moment in the cycle within the time interval and the status of the detector is 0, then the shift is applied to
the subset of signals. For this type of actuation, we need to define two subsets of signals: the subset of signal
for which we will retrieve green duration time, and a subset of signal to which we will add this same time
duration. We will use operators -= ans += of the class EscamotLigne respectively.
EscamotLigne implements interface CIV_Regul.
Include file: Architecture/Feux/Programmateur_DynasimClientSocket/EscamotLigne.h
Constructor
Parameters:

detector conditioning the shift applied: reference to CIV_QsRegExpCapteur
Add a signal to the subset of the retracted signals

operator -=(int nSignal)
Add the signal in position nSignal from the list of signal managed by the controller (nSignal belongs to [1;N]
with N the number of signals managed by the controller) to the subset of signals from which we will retrieve
green time.
Add a signal to the subset of signals on which the time is shifted
operator +=(int nFeu)
Add the signal in position nSignal from the list of signal managed by the controller (nSignal belongs to [1;N]
with N the number of signals managed by the controller) to the subset of signals from which we will add the
shifted time.
382
THE SOCKET
LIBRARY
Code example: shift actuation
// next phase 4 after 20 seconds

// add regulations at phase 3
C1_ph3.push_backRegul( C1_gli06_20_1ac2 );
...
/*
50 : C1_ph1, 50 : -> C1_ph2
55 : C1_ph2, 5 : -> C1_ph3
61 : C1_ph3, 6 : C1 glis 3 -> 1
75 : C1_ph3, 20 : -> C1_ph4
82 : C1_ph4, 7 : -> C1_ph1
132 : C1_ph1, 50 : -> C1_ph2
*/
383
// shift: C1_1 (signal n1 in the controller list) belongs to the subset which time is shifted
C1_gli06_20_1ac2 +=1;
// shift: C1_3 (signal n3 in the controller list) belongs to the subset of retracted signals
C1_gli06_20_1ac2 -=3;
SOCKET
PROGRAMMING
...
#include "QsAcquitte_RegExpCapteur.h"
...
#include "Phase.h"
#include "EscamotLigne.h"
...
// 0 if there is no vehicle in between C1_1_ADA_1 and CA_2_ADA_1
...
...
Phase C1_ph1("C1_ph1", 1, 0., 1,0,0);
Phase C1_ph2("C1_ph2", 2, 0., 0,0,0, 4., 0,0,1);
Phase C1_ph3("C1_ph3", 1, 0., 0,1,1);
Phase C1_ph4("C1_ph4", 2, 0., 0,0,1, 2., 0,0,0);
...
// shift if there is no vehicle AND 6<= t <20
EscamotLigne C1_gli06_20_1ac2("C1 glis 3 -> 1",6, 20, C1_1ac2 );
T H E S O C K E T
LIBRARY
Code example: shift more concisely

...
// shift 6<= t <20 +C1; -C3
C1_ph3.push_backRegul( ((*new EscamotLigne("C1 glis 3 -> 1",6, 20, C1_1ac2)) +=1) -=3);
C1_ph3.push_backRegul( *new NextPhase(20, C1_ph4) );
...
Switch
The Aiguillage class is used to come out of the current phase and enter another phase that differs from the
normal phase sequence (see NextPhase, page 375). The switch is defined on a time interval [t1;t2) of the
phase by a list of pair:
detector (CIV_QsRegExpCapteur)
b. phase (CIV_PhForRegul).
a
The current phase is active between t1 and t2 as long as the status of all the detectors of the list is 1. Once the
detector(s) in the list changes its status to 0, the current phase will switch to the new phase paired with the
first detector with the altered status.
Aiguillage implements interface CIV_Regul.
Include file: Architecture/Feux/Programmateur_DynasimClientSocket/Aiguillage.h
Constructor
Parameters:

the number of switch (of elements in the list of pair): unsigned integer
List of pair {detector, phase} ordered by priority, defined as:
detector object (precede the name with character &): pointer to CIV_QsRegExpCapteur
phase object, write static_cast<CIV_PhForRegul*>(&name): pointer to CIV_PhForRegul
384
THE SOCKET
LIBRARY
Code example: switch to two phases

/*
A phase C1_phTram1 is specific for trams to pass through the intersection
A phase C1_phBus1 is specific for buses to pass through the intersection, blocking the
general traffic and trams.
In phase 1 of the controller defined at "Programming controller 1" (see fig. 207, page 390):
- switch to C1_phTram1 in priority when a tram is detected (detector C1_callT)
OR
- switch to C1_phBus1 when a bus is detected and no tram is presented
(detector C1_callB_and_NoCallT)
*/
...
#include "Aiguillage.h"
...
Aiguillage C1_switchPh1(
"C1 Switch Ph1",
6, 70, // [6 ;70) seconds
2,
// list contains 2 switches
C1_ph1.push_backRegul( C1_switchPh1 );
C1_ph1.push_backRegul( *new NextPhase(70, C1_ph2) );
...
ChgeEtat
In a given phase, the ChgeEtat class is used to modify according to a detector condition - the state of signals depending. The states to be modified only apply on a time range of the phase. The modification of the
signals status applies when the detector status returns 0.
ChgeEtat implements interface CIV_Regul.
Include file: Architecture/Feux/Programmateur_DynasimClientSocket/ChgeEtat.h
Constructor
Parameters:
385

detector triggering the signals status change: reference to CIV_QsRegExpCapteur
// status 0 of detector C1_callB_and_NoCallT switches to phase C1_phBus1

& C1_callB_and_NoCallT, static_cast<CIV_PhForRegul*>(&C1_phBus1)
); // end of the switch definition C1_switchPh1
SOCKET
PROGRAMMING
// status 0 of detector C1_callT switches priority to phase C1_phTram1

& C1_callT, static_cast<CIV_PhForRegul*>(&C1_phTram1),
T H E S O C K E T
LIBRARY
Add a signal the set of signals to be changed

It is necessary to define the set of signals which you want to change the status. Each status change is defined
with a triplet:
the signal,
2. its new status (0 or 1),
3. the time delay after the detectors activation and the status change of the signal.
1.
Thus, the same signal may appear several times in the list of state changes.
Method: add(int nSignal, char state, double delay).
Parameters:
signal position from the list of signals managed by the controller: integer positive
new signal status: 0 blocking, or 1 passing
time delay in second after the detectors activation: real positive
Code example: using ChgeEtat
/*
A phase C1_phTram1 is specific for trams to pass through the intersection
Phase is defined with signals SAC and R17 on red. This phase is activated by the actuation
switch triggered by detector C1_callTi placed at 8s of the stop line. We must open the signals controlling the trams in direction 1 and/or direction 2 depending on the detectors
C1_callT1 and/or C1_callT2.
*/
....
// Include definition file of change status
#include "ChgeEtat.h"
...
ChgeEtat C1_openT1("C1open Tram direction 1", 0, 30, C1_callT1);
C1_openT1
.add(6,1, 4) ->add(6,0, 7)
// SAC_6 open between 4 to 7 after triggered by C1_callT1
->add(3,1, 7) ->add(3,0,19) // R17_3 open between 7 19 after triggered by C1_callT1
->add(6,1,16) ->add(6,0,19); // SAC_6 opens again 3 before shutting down R17_3
C1_phTram1.push_backRegul( C1_openT1 );
....
PC
The PC class defines Coordination points, page 321 among several controllers (Controler). We have to
add the coordination point to all the concerned controllers.
Include file: Architecture/Feux/Programmateur_DynasimClientSocket/PC.h
Constructor
Parameters:

maximum number of controllers to be coordinated: positive integer (greater than 1)
386
THE SOCKET
LIBRARY
Add a phase to the coordination point

After defining a coordination point, you must define its position on each controller. The coordination point is
defined by a set of pairs {phase, position} (position: time in seconds from the beginning of the phase). Transparent to the user, the coordination point is added to the regulation list of the phase. You can add the coordination point in front or at the end of the list of regulations of a phase. The order of the coordination point is
important. For example, if the coordination point is positioned at the end of the phase, it must precede the
NextPhase (phase sequence) in the list of regulations of the phase. After passing the coordination point, we
can then move to the next phase.
Method: push_back(Phase &phase, double whereInPhase).
Add a coordination point at the end of the list of regulations of Phase named phase.
Parameters:
phase where to position the coordination point: reference to CIV_PhForRegul

position of the coordination point (time in second from the beginning of phase): real positive
Method: push_front(Phase &phase, double whereInPhase).
Add a coordination point at the beginning of the list of regulations of Phase named phase.
Parameters:
...
// --- file main.cc preview
#include "PC.h"
...
// --- file C1.h preview
...
PC _Pc("PC", 2); // includes 2 controllers
...
_Pc.push_front(C1_ph1, 12); // coordination point defined on phase 1 of controller 1
...
// --- file C2.h preview
...
_Pc.push_back(C2_ph3, 23); // coordination point defined on phase 3 of controller 2
...
Complete example of programming with the Socket library

Presentation of the junction
This example uses a T-junction (see "Geometry of the junction, position and names of the signals", fig.206
p.389) with a lateral exclusive PT lane that crosses the transversal.
It is programmed in two phases on an 80-second duration cycle (see "Programming controller 1", fig.207
p.390).
387
Code example: coordination point defined on two controllers
SOCKET
PROGRAMMING
phase where to position the coordination point: reference to CIV_PhForRegul

position of the coordination point (time in second from the beginning of phase): real positive
T H E S O C K E T
LIBRARY
There are three detectors by tram direction edited in CubeDynasim (the first in West -> East direction, the
second in the opposite direction), namely:
detector for approach time (aT), C1_10_MAT_1 and C1_11_MAT_1

signal base detector: C1_20_ADA_1 and C1_21_ADA_1
detector to detect the falling edge at the position of stop line: C1_22_BAR_1 and C1_23_BAR_1
The signal scenario is named as socket.
Controller C1 takes the following parameters:
388
THE SOCKET
2
11
12
LIBRARY
Signal R11
Signal R17
Signal R12
Signal R25
89
13
7
15
14
4
56
Figure 206. Geometry of the junction, position and names of the signals
This part covers:
The timing strategy, page 389 implemented,

Main program, page 391, including the LibSocket library and implements the server,
Definition of the controller and the phases, page 392,
Linking CubeDynasim detectors with the detectors of the socket library, page 393,
Variables defining time durations, page 393,
Defining detectors operations (continued file C1.h), page 394,
Signals programming (end of file C1.h), page 397.
The timing strategy

The tramway is compatible with phase 1 of the junction. Implementing its priority is to be done by adapting,
in the preceding cycle, the duration of phases 1 and 2 to offset the junctions execution so that phase 1 coincides with its arrival of the PT at the junction. The calculation must take into account a shift of 8 seconds
between the beginning of phase 1 and the crossing of the PT.
The signal programming is defined in two phases and two interphases. In the interphase 2-1, we define the
actuation operations on signals R25 and SAC to anticipate the opening of signal R17 (at the beginning of
phase 1).
The junctions reactivity constant is defined by the sum of the incompressible times:
linterphase 1-2: 9s
minimum green duration of phase 2: 6s
3. linterphase 2-1: 7s
4. PT crossing stop line 8s after the beginning of phase 1
1.
2.
i.e. 30 seconds.
Phase 1 will therefore be retracted if the PT approach time is 30 seconds between seconds 9 and 42 (duration
of phase 1).
389
SOCKET
PROGRAMMING
Programming
T H E S O C K E T
LIBRARY
Dynamically opens
signals managing PT
phase 1
inter 1-2
phase 2
inter 2-1
Figure 207. Programming controller 1

Interphase 1-2 and the minimum green duration of phase 2 will be executed (9+6), PT will the be at 15 seconds from the junction.
Phase 2 will be retracted entirely once the minimum green has been performed, so that the approach time of
PT is 8s and coincides with the start of interphase 2-1 during which signals R25 and SAC will be opened. So
we will be able to open R17 as the approach time of PT is 0, at the start of green of compatible signals 1 and
2.
390
THE SOCKET
LIBRARY
Main program
File main.cc
#include "Server_DynasimClientSocket.h"
#include "Phase.h"
#include "Adaptativ.h"
#include "ChgeEtat.h"
#include "QsDAGeLt_RegExpCapteur.h"
#include "QsNo_RegExpCapteur.h"
using namespace DynasimClientSocket;

Server_DynasimClientSocket server(10000, programing);
return 0;
}
391
}
SOCKET
PROGRAMMING
// include files for the definition of controller 1, ID C1

#include "C1.h"
T H E S O C K E T
LIBRARY
Definition of the controller and the phases
File C1_control.h
Controler C1("C1",16
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
1*/ ,"C1_1_R11_1"
2*/ ,"C1_2_R11_1"
3*/ ,"C1_3_R11_1"
4*/ ,"C1_4_R17_1"
5*/ ,"C1_5_SAC_1"
6*/ ,"C1_6_SAC_1"
7*/ ,"C1_7_R17_1"
8*/ ,"C1_8_SAC_1"
9*/ ,"C1_9_SAC_1"
10*/ ,"C1_11_R12_1"
11*/ ,"C1_12_R12_1"
12*/ ,"C1_13_R12_1"
13*/ ,"C1_14_R25_1"
14*/ ,"C1_15_R25_1"
15*/ ,"C1_16_R12_1"
16*/ ,"C1_17_R12_1");
//
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
0.00, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0);
//
1 2 3 4 5 6
0.00, 1, 1, 0, 0, 0, 0,
2.00, 0, 0, 0, 0, 0, 0,
5.00, 0, 0, 0, 0, 0, 0,
6.00, 0, 0, 0, 0, 0, 0,
7.00, 0, 0, 1, 0, 0, 0,
7
0,
0,
0,
0,
0,
8
0,
0,
0,
0,
0,
9 10 11 12 13 14 15 16
0, 0, 0, 1, 1, 1, 0, 0,
0, 0, 0, 0, 1, 1, 0, 0,
0, 0, 0, 0, 1, 1, 0, 0,
0, 1, 1, 0, 1, 1, 0, 0,
0, 1, 1, 0, 1, 1, 0, 0);
//
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
0.00, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 0, 1, 1, 1, 1);
//
1 2 3 4 5 6
0.00, 0, 0, 1, 0, 0, 0,
1.00, 0, 0, 0, 0, 0, 0,
2.00, 0, 0, 0, 0, 0, 0,
4.00, 0, 0, 0, 0, 0, 0,
5.00, 0, 0, 0, 0, 0, 0,
392
7
0,
0,
0,
0,
0,
8
0,
0,
0,
0,
0,
9 10 11 12 13 14 15
0, 0, 0, 0, 1, 1, 1,
0, 0, 0, 0, 1, 1, 1,
0, 0, 0, 0, 1, 1, 0,
0, 0, 0, 0, 1, 1, 0,
0, 0, 0, 1, 1, 1, 0,
16
1,
1,
0,
0,
0);
THE SOCKET
LIBRARY
Linking CubeDynasim detectors with the detectors of the socket library
File C1_capteur.h
Capteur C1_B10("C1_10_MAT_1");
Capteur C1_B13("C1_13_ADA_1");
Capteur C1_B14("C1_14_BAV_1");
Capteur C1_B23("C1_23_ADA_1");
Capteur C1_B24("C124_BAV_1");
Variables defining time durations
/* List of the signals

1
2 3
4 5
6
7
8
9 10 11 12 13 14 15 16
R11 R11 R11 R17 SAC PEC R17 SAC PEC R12 R12 R12 R25 R25 R12 R12
List of the phase durations
phase 1: C1ph1 [ 0 - 42 [ -- duration 42s - minimum green duration 6s
phase 2: C1ph3 [ 51 - 73 [ -- duration 22s - minimum green duration 6s
inter1-2: C1ph2 [ 42 - 51 [ - duration 9s
inter2-1: C1ph4 [ 73 - 80 [ - duration 7s
*/
const unsigned C1_dtPh1 =42;
// phase 1 duration in seconds
const unsigned C1_dtMaxProlPh1=29+6+3; // max extension of phase1 for a PT insertion
const unsigned C1_dtMaxPh1=C1_dtPh1+C1_dtMaxProlPh1; // max duration of phase 1
const unsigned C1_dtPh2 =22; // phase 2 duration in seconds
const unsigned C1_dtMaxVerTram=12; // max green duration for PT signals in seconds
const unsigned C1_dtB10 =36; // position in seconds for detector B10
393
#include "C1_control.h"
#include "C1_capteur.h"
SOCKET
PROGRAMMING
File C1.h (beginning)
T H E S O C K E T
LIBRARY
Defining detectors operations (continued file C1.h)
C1.h (continued)
/*
Highest reactivity constant: 1-2 + min(S2) + 2-1 + S1->T
=9 +
6 + 7+
8 =30s
Insert phase PT in phase P1 compatible at second 8
Detection
Detectors at further distance:
35s (10_MAT) at west
36s (20_MAT) at east
At is for approach time
The detector C1o_ApL returns 0 if At <= 30s -> class QsDAGeLt... B10
The detector C1e_ApL returns 0 if At <= 30s -> class QsDAGeLt... B20
Detectors C1o_pec1 and C1e_pec1 return 1 if At initialized -> class QsNo...
Retiming detectors for the At
17s (11_MAT) west
18s (21_MAT) east
Retiming detectors for the At
9s (12_MAT) west
10s (22_MAT) east
*/
QsDAGeLt_RegExpCapteur C1o_ApL("C1o_ApL", C1_B10, C1_dtB10, 0, C1_dtB10+1);
QsDAGeLt_RegExpCapteur C1e_ApL("C1e_ApL", C1_B20, C1_dtB20, 0, C1_dtB20+1);
QsNo_RegExpCapteur C1o_pec1("C1o_pec1", C1o_ApL);
QsNo_RegExpCapteur C1e_pec1("C1e_pec1", C1e_ApL);
QsDAGeLt_RegExpCapteur C1o_Rec1("C1o_Rec", C1_B11, C1_dtB11, 0, C1_dtB11+1);
QsDAGeLt_RegExpCapteur C1e_Rec1("C1e_Rec", C1_B21, C1_dtB21, 0, C1_dtB21+1);
QsNo_RegExpCapteur C1o_pec2("C1o_pec2", C1o_Rec1);
QsNo_RegExpCapteur C1e_pec2("C1e_pec2", C1e_Rec1);
QsDAGeLt_RegExpCapteur C1o_Rec2( "C1o_Rec", C1_B12, C1_dtB12, 0, C1_dtB12+1);
QsDAGeLt_RegExpCapteur C1e_Rec2( "C1e_Rec", C1_B22, C1_dtB22, 0, C1_dtB22+1);
QsNo_RegExpCapteur C1o_pec3("C1o_pec2", C1o_Rec2);
QsNo_RegExpCapteur C1e_pec3("C1e_pec2", C1e_Rec2);
// PT is taken into account and retimed (per direction)
QsOu_RegExpCapteur C1o_pec("C1o_pec");
C1o_pec.add(C1o_pec1) ->add(C1o_pec2) ->add(C1o_pec3);
QsOu_RegExpCapteur C1e_pec("C1e_pec");
C1e_pec.add(C1e_pec1) ->add(C1e_pec2) ->add(C1e_pec3);
394
THE SOCKET
LIBRARY
C1.h (continued)
/*
Ultimate position for the insertion of the PT: end of phase 1
At initialized 42s - 33s (min At) = 9s
retraction of phase1 between 9s and 42s if At=30 -> 9s - 42s in phase C1ph1
retraction of phase2 between 57s and 73s if At=15 -> 6s - 22s in phase C1ph3
t : 9 -retract- 42 -interphase- 51 -min green- 57 -retract- 73 -interphase- 80/0 -min green- 8
At: 30
30
21
15
15
8
0
Definition of At 30s and At 15s
those detectors return 0 if At has the expected value
The positions of the detectors are defined as PT journey times.
*/
// Waiting for PT to check-out at the end of longitudinal phase if At<=29
QsDAGeLt_RegExpCapteur C1o_dA29a( "C1o_dA29a", C1_B10, C1_dtB10, 0, 29);
QsDAGeLt_RegExpCapteur C1e_dA29a( "C1e_dA29a", C1_B20, C1_dtB20, 0, 29);
QsDAGeLt_RegExpCapteur C1o_dA29b("C1o_dA29b", C1_B11, C1_dtB11, -6, C1_dtB11+1);
QsDAGeLt_RegExpCapteur C1e_dA29b("C1e_dA29b", C1_B21, C1_dtB21,-6, C1_dtB21+1);
QsNo_RegExpCapteur C1o_PdF("C1o_PdF", C1_B13);

QsNo_RegExpCapteur C1e_PdF("C1e_PdF", C1_B23);
QsDAGeLt_RegExpCapteur C1o_dA30("C1o_dA30", C1_B10, C1_dtB10, 30, 31);
QsDAGeLt_RegExpCapteur C1e_dA30("C1e_dA30", C1_B20, C1_dtB20, 30, 31);
// blocking the retraction of phase 1 if a PT is already detected: At<=29
QsNo_RegExpCapteur C1_NOdA29("C1_NOdA29", C1_dA29);
QsEt_RegExpCapteur C1_dA30a ("C1_dA30a", C1o_dA30, C1e_dA30);
QsOu_RegExpCapteur C1_dA30
("C1_dA30",
C1_dA30a, C1_NOdA29);
QsEt_RegExpCapteur C1_dA15("C1_dA15");
C1_dA15.add(C1o_dA15)
->add(C1e_dA15)
->add(C1o_PdF)
->add(C1e_PdF);
395
QsEt_RegExpCapteur C1_dA29("C1_dA29");
C1_dA29.add(C1o_dA29a)
->add(C1e_dA29a)
->add(C1o_dA29b)
->add(C1e_dA29b)
->add(C1o_dA29c)
->add(C1e_dA29c);
SOCKET
PROGRAMMING
QsDAGeLt_RegExpCapteur C1o_dA29c("C1o_dA29c", C1_B15, 1, -6, 2);

QsDAGeLt_RegExpCapteur C1e_dA29c("C1e_dA29c", C1_B25, 1, -6, 2);
T H E S O C K E T
LIBRARY
C1.h (continued)
/*
Detectors for the sequence of signal PT in both directions East and West
dA8=8s -> close first R25 in the travel direction
dA8 +2s -> close second R25 in the travel direction
dA8 +5s -> open SAC
dA8 +8s -> open R17, close SAC and SPC
Calculate detector dA8 (returns 0 if PT approach time is less than 8s)
Define detector NOT dA8 to initialize the sequence close-open per stop lines
*/
QsNo_RegExpCapteur C1o_NodA8("C1o_NodA8", C1o_dA8);
QsNo_RegExpCapteur C1e_NodA8("C1e_NodA8", C1e_dA8);
// Define detector OR between NodA8 and the signal base detector
QsOu_RegExpCapteur C1o_OuvrT("C1o_OuvrT", C1o_NodA8, C1_B13);
QsOu_RegExpCapteur C1e_OuvrT("C1e_OuvrT", C1e_NodA8, C1_B23);
396
THE SOCKET
LIBRARY
Signals programming (end of file C1.h)
Signal programming (end of C1.h)

/*
Taking into account signal (SPC - diamond):
we define, on initialization of the At per direction, the opening of the corresponding SPC in
each phase (extended) and interphases
*/
C1ph1.push_backRegul(* (new ChgeEtat("C1 PEC T o", 0., C1_dtMaxPh1, &C1o_pec ))
->add(9, 1, 0) );
C1ph2.push_backRegul(* (new ChgeEtat("C1 PEC T o", 0., 9., &C1o_pec ))
->add(9, 1, 0) );
C1ph3.push_backRegul(* (new ChgeEtat("C1 PEC T o", 0., C1_dtPh2, &C1o_pec ))
->add(9, 1, 0) );
C1ph4.push_backRegul(* (new ChgeEtat("C1 PEC T o", 0., 7., &C1o_pec ))
->add(9, 1, 0) );
// PT check out direction West

C1ph1.push_backRegul(* (new ChgeEtat("C1 Ferm Tram o", 0., C1_dtMaxPh1, &C1_B13 ))
->add(7,0,5)); // close R17 rising edge
// Opening sequence of PT signals for direction East
C1ph1.push_backRegul(* (new ChgeEtat("C1 Ouvr Tram e", 0., C1_dtMaxPh1, &C1e_OuvrT
))
->add(13,0,0) ->add(14,0,2)
// close R25 East and West at (t+2)
->add(5, 1,4) ->add(5, 0, 7)
// open SAC 3s before R17, and last 3s
->add(6, 0, 7)
// close SPC at t=7
->add(4,1,7)
// open R17 at t=7
->add(4,0,7+C1_dtMaxVerTram) // R17 green for C1_dtMaxVerTram
);
// PT check out direction East
C1ph1.push_backRegul(* (new ChgeEtat("C1 Ferm Tram e", 0., C1_dtMaxPh1, &C1_B23 ))
->add(4,0,5)); // close R17 rising edge
397
// Opening sequence of PT signals for direction West

C1ph1.push_backRegul(* (new ChgeEtat("C1 Ouvr Tram o", 0., C1_dtMaxPh1, &C1o_OuvrT
))
->add(14,0,0) ->add(13,0,2)
// close R25 West and East at (t+2)
->add(8, 1,4) ->add(8, 0, 7)
// open SAC 3s before R17, and last 3s
->add(9, 0, 7)
// close SPC at t=7
->add(7,1,7)
// open R17 at t=7
->add(7,0,7+C1_dtMaxVerTram) // R17 green for C1_dtMaxVerTram
);
SOCKET
PROGRAMMING
C1ph1.push_backRegul(* (new ChgeEtat("C1 PEC T e", 0., C1_dtMaxPh1, C1e_pec ))

->add(6, 1, 0) );
C1ph2.push_backRegul(* (new ChgeEtat("C1 PEC T e", 0., 9, &C1e_pec ))
->add(6, 1, 0) );
C1ph3.push_backRegul(* (new ChgeEtat("C1 PEC T e", 0., C1_dtPh2, &C1e_pec ))
->add(6, 1, 0) );
C1ph4.push_backRegul(* (new ChgeEtat("C1 PEC T e", 0., 7, &C1e_pec ))
->add(6, 1, 0) );
T H E S O C K E T
LIBRARY
Signal programming (end of C1.h)

// Open R25 if At>15
//return 1 if At>=16
QsDAGeLt_RegExpCapteur C1o_0dA15( "C1o_0dA15", C1_B11, C1_dtB11, -3, 16);
QsDAGeLt_RegExpCapteur C1e_0dA15( "C1e_0dA15", C1_B21, C1_dtB21, -3, 16);
QsEt_RegExpCapteur C1_0dA15("C1_dA15",C1o_0dA15,C1e_0dA15);
QsEt_RegExpCapteur C1o_ouvrR25("C1o_ouvrR25", C1_0dA15, C1_B15);
QsEt_RegExpCapteur C1e_ouvrR25("C1e_ouvrR25", C1_0dA15, C1_B25);
//Open R25 after the passage of PT in the direction of West-East
C1ph1.push_backRegul(* (new ChgeEtat("C1 ouvr R25 oe", 0., C1_dtMaxPh1,
&C1o_ouvrR25 ))
->add(14,1,0)
->add(13,1,2));
//Open R25 after the passage of PT in the direction of East-West
C1ph1.push_backRegul(* (new ChgeEtat("C1 ouvr R25 eo", 0., C1_dtMaxPh1,
&C1e_ouvrR25 ))
->add(13,1,0)
->add(14,1,2));
// PT actuation: retraction of the antagonistic phases
C1ph1.push_backRegul( * new Adaptativ( "C1 Da=30", 9., C1_dtPh1, C1_dA30) );
C1ph3.push_backRegul( * new Adaptativ( "C1 Da=15", 6., C1_dtPh2, C1_dA15) );
// Define the default phase durations and sequences
// phase 1: 42s extended if At<29
C1ph1.push_backRegul( * new NextPhase(C1_dtPh1, C1ph2, &C1_dA29 ) );
C1ph2.push_backRegul( * new NextPhase(9., C1ph3) );
// interphase 1-2 9s
C1ph3.push_backRegul( * new NextPhase(C1_dtPh2, C1ph4) ); // phase 2: 22s
C1ph4.push_backRegul( * new NextPhase(7., C1ph1) );
// interphase 2-1 7s
398
UTOPIA
Utopia
CubeDynasim lets you establish two-way communication between the simulation and the Urban Traffic
Control System UTOPIA. The simulation sends the status of the detectors to the Traffic Control System
UTOPIA; this system defines the state of the signals and sends it to the simulation. Exchanges only concern
detectors and signals associated with UTOPIA controllers (see Controller parameters, page 306). The information is exchanged at all simulated time steps, asynchronously with the traffic control system.
Utopia controllers (CubeDynasim)

This section describes the steps to establish communication between the client (the CubeDynasim model)
and the Urban Traffic Control System UTOPIA.
These steps are as follows:
Editing and naming objects in CubeDynasim, page 400,
Defining the CubeDynasim UTOPIA client, page 400,
3. Simulation in client mode, page 401.
1.
2.
SOCKET
PROGRAMMING
399
TOPIA
U
Editing and naming objects in CubeDynasim

You model the signals and detectors in CubeDynasim using the standard techniques, however you must
adhere to a precise naming convention to allow their interaction with the Urban Traffic Control System
UTOPIA. You must position the appropriate Controller objects that contain the signals and detectors to be
managed. Moreover, you must add a signal scenario, and define the controller type as Utopia.
This section describes the naming convention used for the:
Signals, page 400,

Detectors, page 400.
Signals
The names of the signals must adhere to the format described in Editing and naming objects in CubeDynasim, page 342.
Detectors
The names used by detectors adheres to the same naming convention principle as used for signals, with the
following format:
C{controller index}_{detector index}_UTO_{physical index}
where ,
{controller index} is a numeric value that designates the number of the crossroads controller with which
the detector is associated,
{detector index} is a numeric value that designates the number of the detectors for the controller managing the crossroad.
This format is similar to the one described in Detectors, page 342 with a detector type set to UTO.
Defining the CubeDynasim UTOPIA client

To configure a controllers client, use the information described in the "Signals module entry window in edit
controller scenario mode" (see fig. 193, page 312).
400
UTOPIA
To define the properties of a UTOPIA controller client, select the Type Utopia, then fill in the following
fields:
1.
2.
3.
4.
5.
6.
Spot IP Address: the IP address of the machine that hosts the Spot server of this controller.
Spot Port: the Spot server associated with communication port.
Spot Id: the Spot Controller identifier.
Proxy Port: the Proxy Spot server associated with communication port.
Proxy Id: the Proxy Spot Controller identifier (usually its value is the sum of 128 and the Spot
Controller ID).
Factor: the speed factor of the Spot server.
The Spot and Proxy ports can be found in PROCESSI.INI file.

The factor indicates the time ratio between simulation and real time. A value of 1 indicates that a second
elapsed time implies a second elapsed in the Urban Traffic Control System UTOPIA, the value 2 indicates
that a second elapsed advance the Urban Traffic Control System UTOPIA time of two seconds.
The speed factor should be as defined in the Spot.ini file.
The simulation and the Urban Traffic Control System UTOPIA are executed in parallel without synchronization. This requires that the simulation runs faster than the Urban Traffic Control System UTOPIA. To ensure
this, it may be necessary to either slow down the control system UTOPIA or decrease the size of the simulated model. The simulation can then, at each time step, wait so that the simulation time flows at the same
speed as the SPOT server.
Simulation in client mode

After defining the various parameters, proceed to simulate in Utopia client mode as in Calculate the simulation (in fact the replications), page 409.
401
SOCKET
PROGRAMMING
Figure 208. Entry window for the CubeDynasim client dedicated to the Utopia controller
TOPIA
U
Because there is no synchronization between the simulation and the Urban Traffic Control System UTOPIA,
make sure that you check the simulation errors to identify any synchronization problems with error
messages such as Simulation too slow for spot simulation time step: followed by the time dura-
tion taken to simulate a time step.
402
15
Simulation module
In order to update a simulation scenario, three steps must be followed in a sequential order:
Demand: path flow calculation. The type of algorithm implemented depends on the type of Flow
scenarios, page 110. The same path flow can be shared by different simulation scenarios. In this
case, there is a single calculation. At the end of the calculation of the demand, depending on the
type of flow scenario, shapefiles might be generated.
2. Simulation: This is, in fact, the calculation of the replications (see below). At the end of the calculation, the criteria measured during the replications are stored in the database Dynasim.db, and the
files read by the Animator, page 451 become available and up to date.
3. Report: formatted result files to insert/link in your report. After each run, the results will be
updated automatically in your linked project report.
1.
The models simulated are microscopic and stochastic, which means that certain parameter values are randomly selected during the simulation.
For example, the arrival of a vehicle in the network is determined by:
1.
2.
One uniform distribution that establishes the type of vehicle and the path.
One uniform distribution that determines the time the vehicle arrives in the network.
The random variable is programmed with a series of numbers that, mathematically, best encompass the possibility space. The results of the simulation are determined by these series of random numbers. What results
would you obtain with a different series of numbers? In this case, are the results of the two simulations sufficiently similar? A negative answer to these questions explains possible model instability, usually associated
with the developments operation being close to saturation.
403
SIMULATION MODULE
A simulation model is the result of a unique combination of six types of scenarios . Two types of scenarios
are mandatory (Network scenarios, page 65 and Flow scenarios, page 110) while the other four types
of scenarios are optional (Signal scenarios, page 308, Public transport scenarios, page 277, rail scenarios and fluvial scenarios).

For example, when studying the impact of the insertion of an exclusive lane with absolute right of way, only
the multiple simulation approach enables you to reconstitute and measure the effect of all the possible cases
of the arrival of priority vehicles by considering their frequencies.
Replicating, or carrying out replications, consists in running the same model several times using different
series of random numbers. To obtain pertinent, reliable measurements from a stochastic model, you must calculate several replications, whatever the type of system simulated. The legitimate query that arises concerns
the possible number of replications needed to obtain pertinent results. The current version of CubeDynasim
does not integrate methods for automatically detecting the minimum number of replications needed. The
methodology adopted amounts to selecting several adequate criteria in the context of the project, and stopping the replications once the confidence intervals calculated for each criteria are deemed sufficiently
reduced.
The results of the replications for each criterion measured are saved in the Dynasim.db database (see Storage
of the values measured, page 245).
You must not take account of the results of replications in an autoblocking situation. An autoblocking situation generally ties in with the priority rules. Vehicles directly or indirectly block vehicles waiting for these
same vehicles. The autoblock is usually due to a modeling error. However, if the number of autoblocks is low
in relation to the number of replications, there is no need to improve the modeling to deal with these few
exceptional situations. A model that has been properly designed, but that creates a large number of autoblocks, usually reveals the developments poor functioning.
Using this model, the simulation engine calculates the movements of each user traveling within the development during the simulated time period. These trajectories are directly used by theAnimator, page 451
which displays user movements on a screen. Furthermore, the simulation engine quantifies criteria limited to
the network areas defined by each Data collectors, page 233. During the course of this calculation, the
simulation engine may well issue certain messages, which you must consult to ensure the consistency and
pertinence of the model.
The simulation module entry window is used to edit, simulate and view the results of simulation scenarios.
To display the simulation module entry window, click the
icon on the Module bar, page 18. This section describes the various functions available in the entry windows four modes:
Simulation module in Edit scenario mode, page 405,

Simulation module in Compute scenario mode, page 408,
Simulation module in Results mode, page 413,
Simulation module in Draw mode, page 421.
For the four modes mentioned above, the user can close the simulation module entry window by pressing
ESC. The entry window always opens in the state it was closed, providing the user a functional continuity
between the sequences of close-open. In other words, if you close the entry window in Results mode, when
you open again the entry window it will be in Results mode.
404
SIMULATION
MODULE IN
EDIT
SCENARIO MODE
Simulation module in Edit scenario mode

The "Simulation module entry window in Edit scenario mode" (see fig. 209, page 406) is a Module entry
window, page 27 containing a list area, an edit area and a command area.
The list area displays for each of the simulation scenarios, defined for this study, the most significant parameters (in the columns).
SIMULATION SCENARIO PARAMETERS

LABEL
Network
Signals
Flow
Name of the Network scenarios, page 65 (see Single-choice list field, page 32).
Name of the Signal scenarios, page 308 (see Single-choice list field, page 32). If the simulation scenario edited does not contain any signal program, select the None character string.
Name of the Flow scenarios, page 110 (see Single-choice list field, page 32).
am Peak ; pm Peak or off Peak, defined with the selected flow scenario.
PT
Name of the Public transport scenarios, page 277. If the simulation scenario edited does
not contain a public transport scenario, select the None character string.
Rail
Name of the rail scenario defining the rail program. If the simulation scenario edited does not
contain a rail scenario, select the None character string.
Fluvial
Name of the fluvial scenario. If the simulation scenario edited does not contain a fluvial scenario, select the None character string.
Multi-run
The different steps in the calculation of a simulation scenario are necessarily in one of five
states:
1.
2.
3.
4.
State has never been calculated.

Pending state. For example, the simulation step is waiting for the demand calculation to
be completed.
Running state.
Update state, because the model has been changed since the last calculation. The
results are accessible but obsolete.
5.
The steps in
the calculation
Comment
Complete state, the results are available and in line with the edited model.
The entry window in Edit mode, as in Compute mode, allows you to know the state of the
steps following the labels of the columns:
F: Flow.
S: Simulations (more exact replications).
R: Report.
Comment entered by the user (optional).
Green Calculate the stats applied to the Green signal duration, page 242 and Red state
duration duration for a signal, page 243 criterion for signals whose Green duration field is
active (see Creating a signal, page 293).
Crossing
duration
405
Calculate the stats applied to the Signal line crossing duration, page 243 criterion for
signals whose Crossing duration field is entered (see Creating a signal, page 293).
SIMULATION MODULE
Schedule
DESCRIPTION
S I M U L A T I O N
MODULE IN
EDIT
SCENARIO MODE
Current
scenario
State of the
calculation
Edit
area
Command
area
Figure 209. Simulation module entry window in Edit scenario mode
The simulation module entry window in Edit mode allows to add, remove, or change the settings of a simulation scenario.
Add a simulation scenario

1.
Click the
2.
If the module entry window is in mode (check the title of the window)
a
icon on the Module bar, page 18 to open the simulation module entry window.
Edit: jump directly to 3.
b. Compute: click on Edit of the command area and then proceed to 3.

c. Results: click on the buttons Calculate, Edit and then proceed to 3.
d. Draw: click on the buttons Outputs, Calculate, Edit and then proceed to 3.
The "Simulation module entry window in Edit scenario mode" (see fig. 209, page 406) is displayed, fill in the values of the Simulation scenario parameters, page 405 in the edit area.
4. Click Add to confirm.
5. Press ESC to close the entry window.
3.
406
SIMULATION
MODULE IN
EDIT
SCENARIO MODE
Delete a simulation scenario

1.
Click the
2.
a
Click on the simulation scenario in the display area of the "Simulation module entry window in
Edit scenario mode" (see fig. 209, page 406).
4. Click on Delete of the command area to display the confirmation window.
3.
Confirm the deletion of the current scenario after verifying that it is indeed the one to be deleted.
By deleting a simulation scenario, all measures collected during simulation, for this scenario, are
removed from the database. The output files of the simulation scenario (for example the animation
files) are also deleted from the disk. However, the demand specific files are deleted, if and only if,
they are not shared by another simulation scenario.
5.
When changing the set of scenarios that defines a simulation scenario, CubeDynasim first creates a new simulation scenario including this new set of scenarios, then it deletes the previous simulation scenario. Editing
the field Comment of a simulation scenario will not change the data of the simulation scenario, or on the calculation state of the simulation scenario.
1.
Click the
2.
a

Edit scenario mode" (see fig. 209, page 406).
4. Edit the parameters of the simulation scenario displayed in the edit area.
5. Click Apply. If the set of scenario has been modified, confirm the deletion of the data of the previous simulation scenario by clicking Yes of the confirmation window
3.
6.
407
Press ESC to close the entry window.
SIMULATION MODULE
Edit a simulation scenario
S I M U L A T I O N
MODULE IN
COMPUTE
SCENARIO MODE
Simulation module in Compute scenario mode

The "Simulation module entry window in Compute scenario mode" (see fig. 210, page 408) allows to perform
operations on a set of selected simulation scenarios. By default, the operation applies to the common simulation scenario.
To select:
a
one scenario: click on the simulation scenario displayed in the list area.
b. a simulation scenario in order to add it to the set of the already selected simulation scenarios:
Ctrl + click on the simulation scenario displayed in the list area.

c. select all simulation scenario: click Ctr + a.
d. a consecutive group of simulation scenarios: click the first simulation scenario, press and hold down
Shift + click the last scenario.
The operations are:
Compute the Flow, page 408,

Calculate the simulation (in fact the replications), page 409,
"Generate report" (see fig. , page 410),
Stop the replications during the calculation, page 411,
Modify the autoblock conditions without replicating, page 411,
Export the simulation scenarios, page 411
States of the
report
States of the
replications
States of the
flow
Figure 210. Simulation module entry window in Compute scenario mode
Compute the Flow

1.
Click the
2.
Edit: click on Calculate and the proceed to 3.
b. Compute: proceed directly to 3.
c. Results: click on the buttons Calculate and then proceed to 3.
d. Draw: click on the buttons Outputs, Calculate and then proceed to 3.
a
Compute scenario mode" (see fig. 210, page 408).
4. Select the set of simulation scenarios of which you want to calculate the demand.
5. Click Flow of the command area.
3.
408
SIMULATION
MODULE IN
COMPUTE
SCENARIO MODE
Calculate the simulation (in fact the replications)

1.
Click the
2.
a
3.
4.
5.
6.
7.
8.
Select the set of simulation scenarios of which you want to calculate the simulation.
Click Simulation in the command area.
Following the status indicator of the simulation in the column entitled S, the "Replication launch
window" (see fig. 211, page 410) opens in mode New or Continue replications.
Fill in the Replication execution parameters, page 409.
Click Multi-Run. The simulation starts when the window is closed (in fact, update the demand if
needed, then simulate).
LABEL
Number
Max number
Autoblock
duration
Ref time
DESCRIPTION
The number of replications you want to simulate
If a replication does not finish, or if an autoblock is detected, a new replication is simulated. In this context, to avoid making infinite calculations, you limit the maximum
number of replications to the sum of the Number and the Max number.
Defines the minimum time, in seconds, during which the autoblock condition must be
satisfied to establish an autoblocked simulation.
Defines the maximum time, in seconds, taken to travel across the network when calculating the reference status. You must define a maximum time to avoid having an infinite
calculation time, for example with a vehicle whose path runs in a loop. An error message indicates the category-origin-destination triplets that have exceeded this maximum
travel time.
In the continue status

Continue

calculate additional replications
delete the replications already calculated, calculate the first replication with no random seed; In this case, all the replications are calculated again.
At the end of the replications, you must Consult the messages, page 414 to correct any modeling
errors.
When running your replications, if the scenarios status is:
1.
OR
and Continue
,
all the data in the scenario (measurements stored in the database, animation data, replication comments, etc.)
will be deleted.
2.
409
SIMULATION MODULE
REPLICATION EXECUTION PARAMETERS
S I M U L A T I O N
MODULE IN
COMPUTE
SCENARIO MODE
When you run the replications, the data needed by the animation is automatically generated for the first repand Continue ), no animation
lication. If you choose to not increase the number of replications (status
data will be generated.
Choose the Autoblock duration carefully. For an autoblock duration set to 60 seconds, for example,
vehicles waiting for more than 60 seconds at the signalized intersection with programmed red phase
for 70 seconds, will be detected as an autoblock situation.
Mode: new replication
Mode: continue with replications
Figure 211. Replication launch window
Generate report
1.
Click the
2.
a

3.
4.
5.
6.
7.
8.
410
Select the set of simulation scenarios of which you want to calculate the report.
Click Report in the command area.
Following the status indicator of the simulation in the column entitled S, the "Replication launch
window" (see fig. 211, page 410) opens in mode New or Continue replications.
Fill in the Replication execution parameters, page 409. If the demand and the replication is up
to date, set the Number of replication to 0.
Click Multi-Run. The simulation starts when the window is closed (in fact, update the demand if
needed, then calculate the replication, finish computing the report files).
SIMULATION
MODULE IN
COMPUTE
SCENARIO MODE
Stop the replications during the calculation

1.
Click the
2.
a
4. Select the set of simulation scenarios of which you want to stop during the simulation (indicated
in the column Simulation of the list area).
by the icon
3.
Click Simulation in the command area.

6. Click Yes in the dialog box to confirm.
5.
7.
Simulations are stopped. The simulation scenarios status

displayed in the list area indicates
that you can view the animation. The animation, however, will probably be uncompleted.
After the calculation of the replications, you may notice that the autoblock conditions turn out to be overly
restrictive. In this case, compute the reports by only running the autoblock test:
1.
Click the
2.
a

4. Select the set of simulation scenarios of which you want to calculate the report. They must have
.
the status
3.
Click Report in the command area to display the Replication execution parameters, page 409.
Set the Number of replication to 0. Adjust the Autoblock duration as appropriate.
7. Click Multi-Run. to generate the report.
5.
6.
Export the simulation scenarios

The export operation formats the simulation results to make them more easily available to the projects participants. All the data is saved by the DynasimViews, page 467 application in a user-defined directory.
DynasimViews makes it easy to browse the various scenarios in order to view the animations and the data
collected. The software applications (DynasimViews, the Animator, page 451, and the grapher) associated with the export data are copyright-free. You can thus copy them as you like. Exporting an animation
requires a token, which corresponds to the generation of a copyright-free animator (see Export code,
page 478).
411
SIMULATION MODULE
Modify the autoblock conditions without replicating
S I M U L A T I O N
MODULE IN
COMPUTE
SCENARIO MODE
Before performing an export, you are advised to fill in the following fields:
1. Comment for the simulation scenario.
2. Comment for the simulations, especially if there are a number of animations.
Your comments will make it easier for users who are not familiar with the scenario names to use the
export.
Proceed as follows to export simulation scenarios:
1.
Click the
2.
a

3.
Select the set of simulation scenarios of which status should be

or
and Markers,
page 464 saved.
5. Click Export on the command area the folder selection windows and then select the export folder.
If this is the first export for your project, you must create a new empty folder. However, you can
select a folder in which data has been exported beforehand, in which case the data from both
exports can be viewed by a single DynasimViews application.
6. Click Open to start the export operation.
7. You can duplicate the export folder on any support you like to distribute these simulation results.
4.
To view the results of the export: run the DynasimViews program in the folder to which the results have been
exported.
To change the logo generated by the export operation and displayed at the bottom left of the main
DynasimViews window, replace the logo.bmp file in the export folder. This logo.bmp file is an image
file with a maximum size of 124x64 pixels, and which must be in bmp format.
412
SIMULATION
MODULE IN
RESULTS
MODE
Simulation module in Results mode

You access the simulation module in Results mode via the Simulation module in Compute scenario mode,
page 408 by clicking Outputs in the command area.
For each replication in the current simulation scenario, the "Simulation module entry window in Results
mode" (see fig. 212, page 413) displays the following in the list area:
SIMULATION PARAMETERS
LABEL
DESCRIPTION
Number
Replication number as defined for the NRep field in the Replication table (see Data model,
page 245)
Errors
Number of errors observed during the simulation. If one of the replications has a non-null
number of errors, you must :
1.
2.
Anim
Three statuses:
the replication cannot be animated
the replication is being calculated, you can start to see the partial animation
the replication can be animated fully
Complete
Block
Seed
Comment

the replication finished at the simulation end time
the replication finished before the simulation end time (e.g. it was interrupted by the
user)
Two possible statuses depending on whether the replication autoblocks (1) or not (0)
Original random seed for the replication
Free text field, used to identify the simulations when exporting the data (see Export the
simulation scenarios, page 411)
Current
replication
List area
Edit area
Command
area
Figure 212. Simulation module entry window in Results mode
413
SIMULATION MODULE
3.
4.
Simulate this replication to view its animation (see Animate a simulation, page 414).
Identify the errors (see Errors for the current replication, page 416), then correct
them by editing the model.
Check that the error is corrected by replicating again and making sure the error has gone.
Calculate the replications again from this modified model. If there are still simulation errors,
repeat the procedure from step 1.).
S I M U L A T I O N
MODULE IN
RESULTS
MODE
At the end of the replication operations, you can switch back to Compute mode by clicking Calculate in the
command area, or press ESC to close the entry window.
In Results mode, the following operations are possible in the simulation module entry window:
Comment a replication, page 414,

Simulate a replication, page 414,
Delete an animation, page 414,
Animate a simulation, page 414,
Consult the messages, page 414.
Comment a replication
When exporting a simulation scenarios various animations, you are advised to add a comment to each in
order to distinguish them.
Select the replication to comment in the list area.
Fill in the Comment free text field.
3. Click Apply to confirm.
1.
2.
Simulate a replication
It may be necessary to simulation another replication to view and better understand the reasons for an error
message, an autoblock, etc. Proceed as follows:
1.
Select the replication to simulate in the list area.
2.
Click Animate. The Animation status changes to
and the Controller, page 453 opens.
Delete an animation
After viewing an animation to better understand an autoblock or any other modeling problem revealed by the
values of the criteria collected, and if this problem ties in with an exceptional event, you must delete the animation data so that it is not considered in an export operation.
1.
In the "Simulation module entry window in Results mode" (see fig. 212, page 413), select the ani).
mation to delete in the list area (Anim parameter on
2.
Click Delete
Animate a simulation
Select the simulation to animate in the list area.
2. Click Animate to open the Controller, page 453.
1.
Consult the messages

Click Messages in the simulation module entry window (in Results mode) to open the Messages window,
containing the messages that apply to the current replication (see "Messages window", fig.213 p.415).
414
SIMULATION
MODULE IN
RESULTS
MODE
Tabs
Display
area
At the end of a simulation scenarios replication calculations, you should open the Messages window to
check the following:
Error messages due to the construction of the paths, page 415,

Error messages due to the Estimation, page 415,
Error messages due to the Assignment, page 416,
Error messages due to the reference status, page 416,
Errors for the current replication, page 416,
Simulation warnings, page 419,
Autoblock messages, page 419,
Paths, page 420.
A message refers to the second lane in the trajectory identified as RN120_OE_10, by naming it
RN120_OE_10!b. Use the format: multilane name indexed by a lowercase alphabetical character,
where a corresponds to the first lane on the right in the direction of travel, b to the second lane,
etc.
Error messages due to the construction of the paths
To access the error messages generated during the estimation, click on the Paths tab.
All or part of a traffic count may not traverse along an existing or authorized path. In this case, it is not considered in the Estimation or Assignment process, and is listed in the flow_.err file with its position on the
links/nodes network and its name in CubeDynasim.
Error messages due to the Estimation
Start by checking the Error messages due to the construction of the paths, page 415 before viewing the
estimation process messages.
To access the error messages generated during the estimation, click on the Estimation tab. This tab specifies
whether or not the Estimation converges.
415
SIMULATION MODULE
Figure 213. Messages window
S I M U L A T I O N
MODULE IN
RESULTS
MODE
If the Estimation does not converge, the traffic counts that diverge from the calculated flow are reported.
The conditions for divergence are as follows:
Upper limit exceeded (CS+)
2. Lower limit exceeded (CS-)
1.
The upper and lower limits are defined in relation to the tolerance percentages specified in the Traffic
counts, page 126. For example, if a traffic count is on 100 vehicles with a tolerance + (%) of 5% and a tolerance - (%) of 0%, the upper limit (CS+) will be 105 vehicles and the lower limit (CS-) will be 100 vehicles.
Any flow outside this range, at this traffic count point, will be reported along with the following information:
1.
2.
3.
4.
5.
6.
7.
The first node of the link where the traffic count is positioned
The second node of the link where the traffic count is positioned
The upper limit (CS+) or lower limit (CS-)
The calculated flow
The flow rate in relation to the value
The vehicle category
The traffic count name in CubeDynasim
If the flow values are not too far from the upper and/or lower tolerance limits, you are advised:
1.
2.
Firstly, to increase the number of maximum iterations in the convergence process.

Secondly, to consider increasing the tolerance on certain traffic counts.
In any case, THE MODEL MUST CONVERGE before carrying out any dynamic simulations.
If the calculated flow exceeds the theoretical capacity of one or more links, a message is shown.
Error messages due to the Assignment
To access the error messages generated during the Assignment, click on the Assignment tab. This tab specifies whether or not the Assignment converges.
An Assignment may well not converge if:
The Assignment network contact points are different from those of the reference Estimation network.
2. The Assignment network is subject to constraints (Invalidate paths, traffic counts to favor certain
paths, etc.) that are incompatible with the flows to be assigned.
3. The Assignment network does not provide any possible paths between certain contact points on
the reference Estimation network.
1.
Error messages due to the reference status

To access the error messages generated when calculating the reference status, click the Reference tab. The
errors are the same as those generated during a replication (see Errors for the current replication, page 416).
There is only one error specific to the reference status. It details the category-origin-destination triplet which
exceeded the maximum travel time allowed to reach the destination. The error can be due to either of the following:
A travel time greater than the reference time (dont forget the stop times, e.g. for public transport).
In this case, you must increase the reference time.
2. A badly defined path on which the vehicle enters into a loop on its path.
1.
Errors for the current replication

Simulation errors are sent by the simulation engine when building the model or during a simulation. They
identify modeling errors. Click the Errors tab in the Messages window to display the current replications
errors in the list area.
416
SIMULATION
MODULE IN
RESULTS
MODE
Simulation errors are saved in a text file named simul_<random seed>.err located in the directory of the
simulated scenario. The message Loading marks the start of the models construction. If the construction
fails, the Error while loading message is displayed, otherwise the Loading done message is obtained.
The message Start of simulation marks the start of the simulation. All model construction errors are displayed before this message. Errors during the simulation are displayed between the Start of simulation and
Complete simulation messages. The error file ends with the number of errors.
Table 7, "Error messages when building the model", page 417, and Table 8, "Error messages during simulation", page 418, suggest possible solutions for each error detected by the simulation engine either when
building the model or during simulation.
TABLE 7. Error
No.
messages when building the model

Examples of error message descriptions
Solutions
The priority zone

whose entry is: OBJ1
at position: POS1
whose exit is: OBJ2
at position: POS2
starts beyond the object with a length L defined on entry
The priority zone

whose entry is: OBJ1
at position: POS1
and whose exit is: OBJ2
at position: POS2
the priority start position is inverted with the priority end
position
the rule is not generated; delete, then edit the rule

again
The yield zone

defined in object: OBJ
at position: POS
starts beyond the end of the object
see error no.8
Signal C38_F1 is not programmed
the Signals, page 290 identified as C38_F1

which belongs to the Signal scenarios, page 308
in the simulated scenario, is not programmed. You
must:
1.
2.
13
20
417
Stop Stop_451
was not created
its stop marker is at less than 50cm
from the beginning of object OBJ1
The entry markers of data collector JOJ do not intersect

any objects
reload the model.

delete, then edit the rule again
if necessary, create a Signal scenarios, page 308,

add the signal to one of the crossroads in the signal scenario.
the stop marker associated with the Stop,

page 217 priority rule is not far enough away from
the beginning of object OBJ1 to be considered by
the simulation. Reposition the stop marker as you
would move a yields end of the approach zone
marker (see Editing a yield, page 209).
Data collectors, page 233 named JOJ does not
intersect any trajectory lane or Stages, page 71.
You must:
1.
2.
delete the data collector,

edit a new data collector that intersects at least one simulation object of the types above.
SIMULATION MODULE
12
1.
2.
S I M U L A T I O N
TABLE 8. Error
102
MODULE IN
RESULTS
messages during simulation

Error messages during simulation
The vehicle: 135 (2245)

whose type is: CAR
whose destination is: RN192_OE_OUT
currently in: RN192_EO_22
has no route leading to this destination
117

whose type is: TRUCKV
crosses another entry marker of detector: C8_BA1
without first crossing one of its exit markers
118

whose type is: TRUCK
crosses an exit marker of detector: C8_BA1
without first crossing one of its entry markers
119
MODE

currently in: RN192_OE_OUT
leaves the network without crossing
an exit marker of detector: C8_BA1
Solutions
The vehicle identified as 135 for the animator, and

2245 for the simulation engine, cannot reach its
destination RN192_OE_OUT when it is in object
RN192_EO_22.
You must check:
1.
2.
3.
The same vehicle crosses two entry markers of a

Multimarker detectors, page 295 without first
crossing one of its exit markers.
You must:
1.
2.
121
122

crosses an exit marker of data collector: JOJ
without first crossing one of its entry markers
A vehicle that crossed one of the entry markers of

the Multimarker detectors, page 295 identified
as C8_BA1 leaves the simulated network without
crossing one of its exit markers.
You must find the path taken by the vehicle
enabling it to reach exit RN192_OE_OUT, then:
1.
2.
125
418
delete the data collector, and edit a new data collector

integrating an exit marker that crosses this path,
edit the data collector to not take into account this type
of vehicle or this destination using its Condition field,
forbid this route using Prohibitors, page 168.
A vehicle crosses the entry markers of a data collector twice without having first crossed one of this
same data collectors exit markers.
Apply the same solutions as for error no. 119,
page 418.
A vehicle crosses an exit marker of a Data collector representation and associated elements,
page 262 identified as JOJ without having first
crossed one of its entry markers.
You must:
1.
1.

leaves the simulated network without crossing
one of the exit markers of data collector: JOJ
check the vehicles route,

check the position of the data collectors marker and, if
necessary, delete it and re-edit it, remembering to redefine the actuated signal operations that depend on it.
A vehicle crosses an exit marker of a Multimarker

detectors, page 295, without first crossing one of
its entry markers.
You must apply the same procedure as in message
no.117, page 418.
3.

crosses another entry marker of data collector: JOJ
without first crossing one of its exit markers
that there is a sequence of trajectories that lead to this

destination from object RN192_EO_22,
that these trajectories share the same handles,
that no Prohibitors, page 168 applied to the destination or type of vehicle forbid this sequence.
modify the data collector (see Editing a data collectors

geometry, page 264) to define its type as open. Only
then is the error no longer signaled,
apply the solutions proposed for error no. 121,
page 418.
A vehicle leaves the network whereas it is still

counted by a data collector. Apply one of the
solutions proposed for error no. 122, page 418
SIMULATION
TABLE 8. Error
MODULE IN
RESULTS
MODE
messages during simulation
Error messages during simulation
Solutions
The vehicle cannot change lanes because there is

too much weaving in relation to the length of the
lane.
128

whose type is: CAR
cannot change lanes
129

whose type is: CAR
choice of lane change distance too close
The lane change position drawn by the vehicle is

too close to the entry of the object, apply the solutions for error no. 128, page 419
301
Signal C8_F1 changes from red to green in: 135 seconds

not complying with the maximum red time of: 120 seconds
The maximum duration of an R11v-type signal is

not respected in the simulation (see error no. 302).
1.
2.
increase the length of the lane change zone: either by

prolonging the lanes in the multilane, or changing the
position of the lane changes,
force lane changes upstream
The minimum green duration edited in the Edit

states of the signals, page 314, is not respected in
the simulation.
302
Signal C8_F1 changes from green to red in: 4 seconds

not complying with the minimum green time of: 6 seconds
1.
Simulation warnings
There is only one warning message possible. It is sent when a vehicles motional capacities and position do
not allow it to stop on an interrupt (Table 9, page 419). Warnings are stored in the file named simul_<random seed>.warn in the simulated scenario directory. To view the file of simulation warnings for the current
replication, click the Warnings tab in the Messages window
TABLE 9. Sample
warning message
122
Description of a warning message
07 h 49 min 25 s (1060.37) WARNING 49 :

The vehicle: 239
whose type is: CAR
whose destination is: JCaraaso_OUT
currently in: RN192_SN1b
with a speed of 38.601 km/h
cannot take into account the interrupt at a distance of 4.16 m (QsCinematikF1S1: cineFinterrupt)
The simulation engine sends an interrupt to stop vehicles able to stop at a point in the network. For example,
a Stop line, page 202 sends an interrupt when its associated signal changes to red. When the simulation
results are displayed in an animation and a vehicle appears to not respect a priority: you must consult the file
of warnings and make sure that a message does not concern the vehicle at the moment the problem was identified. If such a message is found, proceed as follows, depending on the type of priority: prolong the
approach zone, reduce the speed of non-priority vehicles at the conflict approach zone, check the priority
rule conditions (see Managing conflicting trajectories, page 197).
Autoblock messages
To see an overview of all the autoblock messages, click the Autoblocks tab in the Messages window. If there
are no autoblocks, nothing is displayed.
419
SIMULATION MODULE
2.
if the duration of the green assigned to the signals

programming is insufficient, modify it,
if the signals crossroads operates in actuated signal
mode, check that the application of these operations
cannot produce a green duration less than the minimum
green value.
S I M U L A T I O N
MODULE IN
RESULTS
MODE
There are two types of message concerning autoblock situations depending on whether the condition for
detecting an autoblock situation applies:
To at least the autoblock duration: if there is an autoblock, the message specifies the data collector
and the time at which the autoblock is detected.
2. At the end of the simulation, the message indicates the risk of an autoblock by specifying the percentage of the autoblock duration during which the condition is satisfied. A low percentage means
there should be no blocked situation.
1.
The messages specify: the replication number to be able to animate the corresponding replication; the name
of the Data collectors, page 233 and of the crossroads that satisfies the autoblock condition, and the time
at which the autoblock is detected. To correct autoblocks, you must view the animation to understand the
cause (Simulate a replication, page 414 and Animate a simulation, page 414).
Paths
CubeDynasim includes, for Generator scenario, page 114, a tool for viewing all the paths taken by the
vehicles during the simulation according to the category-origin-destination triplet. You must check the paths
to make sure that they correspond to those wanted when editing the model.
To view the paths, click the Paths tab in the Messages window. All the simulated combinations (category,
origin, destination) are displayed in rows in the list area. Select a row to view the path taken by a vehicle category between an origin and a destination in the Network edit area, page 19.
Before checking paths, zoom in on an area and disable the maps background. This provides a better
view of the network you are editing.
Also, the current geometry scenario must correspond to that of the simulation scenario.
Paths tab
Selected path
List of destinations
List of origins
List of categories
Selected path
highlighted
Figure 214. Checking the paths
420
SIMULATION
MODULE IN
DRAW
MODE
Simulation module in Draw mode

In Draw mode, you launch a Graph, page 472 to quickly view the measurements corresponding to criteria collected during the replications.
To activate Draw mode, click the Draw button in the "Simulation module entry window in Results mode"
In the edit area, you can define your Parameters of the curves to draw, page 421. Click Draw to draw the
curves defined according to the values selected in the fields (see Graph, page 472).
PARAMETERS OF THE CURVES TO DRAW

LABEL
Group
Criteria
DESCRIPTION
A Single-choice list field, page 32 used to select a group from all those in the current
simulation scenario. A curve is drawn for each data collector at the selected group.
Contains two Single-choice list field, page 32 to define:
1.
Statistic
A Single-choice list field, page 32 used to select the statistic process applied to each
subset of measurements recorded at the same time for different replications.
List area
Edit area
Command area
Figure 215. Simulation module entry window in Draw mode
421
SIMULATION MODULE
2.
the criterion to choose from a subset of criteria referenced in the database (the selection is
limited to Flow, Number of vehicles present, Travel time and Travel speed)
the statistic process applied in the simulation at the end of the sample period.
S I M U L A T I O N
422
MODULE IN
DRAW
MODE
16
Parking
PARKING
The CubeDynasim parking module enables you to model parking facilities including multi-level parking
facilities. This tool is particularly well adapted for the study of traffic flow at parking facilities in shopping
centers, sport stadiums, office buildings, and so forth. The functionalities of a parking facility are affected by
its geometry layout, the supply and demand of the parking facility, and parking duration. Each of these elements is taken into account by CubeDynasim.
Two tutorials are provided:
Modeling parking.
Modeling parallel parking.
This chapter covers:
"Model development and the simulation of parking" (see fig. , page 424)
Parking Distribution, page 427,
Attractor, page 429,
Aisle, page 431,
Parking Lots, page 438,
"Count display" (see fig. , page 447),
Establishing a model for the simulation of parking:
Distribution of lane changing behavior in the parking lot, page 448,

Modify the appearance of the vehicles, page 450.
The simulation of parking is only compatible with flow scenario type Generator scenario, page 114.
423
ODEL
M
DEVELOPMENT AND THE SIMULATION OF PARKING
Model development and the simulation of parking

A parking lot groups a number of parking stalls. A vehicle parks in a parking stall, either before the beginning of the simulation or during the simulation if the parking stall is visible, attainable, and vacant during the
search of parking. A vehicle parked in a parking stall can travel to one of the Exits of the network. In that
case, the parking stall is vacant again and accessible to other vehicles.
Parking stalls are not all equivalent. The parking stalls next to the entrances of the store or the shopping carts,
are generally more popular. CubeDynasim models the preferences of the vehicles for certain parking stalls
by adding Attractor (for example at the entrance of the store). Furthermore, the choice of a stall is also
determined by its immediate accessibility. Two consecutive vacant stalls are more attractive as compared to a
single, better-located one as it is harder to pull the vehicle into the stall to the extent that the distance that
separates the two options does not go beyond a tolerance threshold.
The parking stalls are grouped into units known as Parking Lots. A parking stall belongs to one and only
one Parking Lot.
The movement of a vehicle can be described in four steps:
Vehicle enters from the street through the parking facility's entry driveway
2. Vehicle selects a Parking Lot at the entrance of the parking facility.
3. Vehicle finds the best vacant and visible stall belonging to the lot.
4. Vehicle parks in the vacant stall.
1.
Obviously, we need to consider certain cases:
if a vehicle cannot find a vacant parking stall in the assigned Parking Lot, we have to decide if the
vehicle continues to search for a stall in the same Parking Lot, tries it luck in another Parking Lot, or
if it gives up and goes back home. In that last case, we need to count the number of vehicles that
left the parking facility that could not park.
if a better parking stall becomes available during the travel toward a preselected stall, the vehicle may
change its parking decision to park in the new stall depending on the distance of that stall from its current location.
To assign a Parking Lot for vehicle, the user adds an Assign Lot, page 440 at the entrance of the parking
facility. To specify the behavior of a vehicle that fails to find a parking stall, it is necessary to add an Update
Lot object at the exits of the Parking Lot, page 438.
424
MODEL
To create a parking model in CubeDynasim:

1.
Define an initial section (named for example Road) that represents the roads to and from the
entrances/exits of the parking lot.
Road scenario in geometry mode
Entrances/Exits of the parking lot
Parking stalls
2.
Switch to logic mode to add the Origins, page 69 and Destinations, page 74 at the entrance
and exit of the parking facility. Do not forget to link the origin and the destination to the trajectories using Speed Link.
Road scenario in logic mode
InParking: Entrance of he parking lot

but exit of the network road
3.
425
Create a Network scenario (named for example Parking) that includes the layers of the Road scenario. Edit the parking (see further down) by adding new objects in the layers of the Parking scenario. Add an Assign Lot, page 440 at the trajectory of the exit of the Road network, which is
also the trajectory of the entrance of the parking facility in the Parking scenario.
PARKING
OutParking: Exit of the parking lot

but entrance to the network road
ODEL
M
Parking Scenario in geometry mode
Assign Lot object at the entrance of the

parking facility and belongs to the Parking
network scenario
Objects only belonging to the
Parking network scenario
Parking Scenario in logic mode
4.
Create a flow scenario using type Generator scenario, page 114 to simulate the traffic flow of
the parking facility. The row of the matrix origin-destination corresponding to the generator
OutParkingis at 0. The column of the matrix origin-destination corresponding to the exit
InParking adds up to an average number of vehicles that arrives at the parking lot via that
entrance during the simulation period.
After defining the entrances to the parking facility, it is necessary to:

define the distributions of parking duration,
define the attractors and parking stalls,
3. group parking stalls into parking lots so that we can adjust parking searching behaviors at different
exits of parking lots,
4. add and define the distributions of the Assign Lot object at the entrance of the parking facility.
1.
2.
It is necessary to assure that the flow of the exit of the parking facility matches the expected flow. To achieve
this, users need to fine tune the parking distribution of duration.
426
PARKING DISTRIBUTION
Parking Distribution
The parking distribution defines the parking durations for vehicles during the pre-loading period (vehicles
already parked at the beginning of the simulation) and vehicles (entering parking facilities) during the simulation period.
THE SETTINGS OF THE PARKING DISTRIBUTIONS

LABEL
Layer
DESCRIPTION
The network layer associated with the distribution. Only one distribution can
be specified for each network layer.
Defines the average time, in seconds, between two vehicles exiting the
parking facility. These times follow an exponential rule. The time and the simulation length define the volume at the exit
Mini Preload
Defines four parameters of the log-normal distribution for the minimal duration of the vehicles parked at the beginning of the simulation (pre-load period).
The distribution is specified by its mean (Avg field) and its standard deviation
(stddev field). The random values will be drawn from the interval defined by
fields of Min and Max.
All four parameters are expressed in seconds.
Max Preload
Defines four parameters of the log-normal distribution for the maximum duration of the vehicles parked at the beginning of the simulation (pre-load period).
The distribution is specified by its mean (Avg field) and its standard deviation
(stddev field). The random values will be drawn from the interval defined by
its fields of Min and Max.
Mini Ingoing
Defines four parameters of the log-normal distribution of the minimal times of

the vehicles entering the parking facility during the simulation. The distribution is specified by its mean (Avg field) and its standard deviation (stddev
field). The random values will be drawn from the interval defined by its fields
of Min and Max.
Max Ingoing
Defines four parameters of the log-normal distribution of the maximal times of

the vehicles entering the parking facility during the simulation. The distribution is specified by its mean (Avg field) and its standard deviation (stddev
field). The random values will be drawn from the interval defined by its fields
of Min and Max.
To create or edit the distributions of parking:

Open the "Parking distribution editor window" (see fig. 216, page 428) from Menu bar,
page 14 > Parking > Distribution Parking.
2. Define the parameters in The settings of the parking distributions, page 427 window, in the
edit.
3. Click on Add to create a new Parking Distribution.
4. Click on Quit to close the box.
1.
427
PARKING
Mean Outgoing
Duration
P A R K I N G D I S T R I B U T I O N
List of
parking
distributions
Parameters
of parking
distribution
Command
area
Figure 216. Parking distribution editor window
428
ATTRACTOR
Attractor
Not all parking stalls have the same attractiveness to vehicles. For example, the parking stalls near the
entrance of the store are generally taken the most. Parking stalls are modeled hierarchically depending on the
provoked interest using the Attractor objects.
An attractor is characterized by its location and weight factor. Users can group multiple attractors by specifying the same attractor name. A specific parking lot can have only one group of attractors. Each parking stall's
attractiveness in this parking lot will be evaluated by all attractors among this group. The evaluation process
is based on the weight factors and distances from each of the attractors in this attractor group.
For example, a supermarket is represented by one attractor positioned at the entrance of the supermarket with
a weight factor and another attractor is added in the middle of the parking lot with a lower weight factor representing where the shopping carts are located. The two attractors have the same name say 'market1' meaning
that they belong to the same group. This group will be assigned to certain parking lot(s). Parking stalls near
the entrance of the supermarket are more attractive since vehicles (people) prefer to park as close to the
entrance as possible. If those are not available, parking stalls around the shopping carts are the second best
option.
The attractor assumes two functions:
The generation of the vehicles at the initial state:
The spatial distribution of users:

The attractor by its geometrical position defines the spatial distribution of the vehicles generated at
the initial state and that enter during the simulation.
THE SETTINGS OF THE ATTRACTOR

LABEL
Attractor
Weight
Mean generated
Std dev generated
Layer
429
DESCRIPTION
Group name which the attractor belongs to.
Relative weight of the attractor compared to all of the attractors in the same
group.
Average number of vehicles parked at the beginning of the simulation.
Variation of the number of vehicles generated at the beginning of the simulation.
The number of vehicles generated is drawn from the rang of [Mean - stddev;
mean + stddev]
Defines the network layer which the attractor belongs to.The layer of the
attractor is not necessarily the same for all the attractors in the group. This feature allows users to test different configurations/positions of attractors by
changing the network scenarios.
PARKING
The attractor specifies the number of vehicles that parked at the beginning of the simulation (which
means, the occupation of the parking facility at the beginning of the simulation). The number of vehicles generated at the initial state (before the beginning of the simulation) is defined by the parameters
(Mean generated and Std dev generated) edited from the last attractor among the attractor group.
TTRACTOR
A
Create or edit an attractor

To create or modify an attractor:
1.
If necessary, switch to geometry mode (see "Main CubeDynasim window in geometric mode",
fig.1 p.14).
2.
Click on the icon
from Simulation object bar, page 17 to activate the create an attractor
mode. The cursor of the mouse appears in the edition zone of the network as
3.
In the Network edit area, page 19, left click at the location where the attractor needs to be
added. This opens the input window of the Attractor object.
Complete The settings of the attractor, page 429.

5. Click OK to confirm the entries.
4.
To search for all of the attractors named bao:
430
1.
Click on the button Object
2.
Type *bao* in the Name Filter to show all of the attractors whose name contain bao.
3.
4.
5.
Click on the attractor of interest.

Click on Search to zoom to the attractor.
Click on Quit to close the window.
AISLE
Aisle
CubeDynasim has different objects representing aisles of parking lots allowing to model for all possible
geometry configurations of parking facilities.
This part covers:
The parking lot objects, page 431,

Create, edit a parking lot object, page 433,
Link an aisle to the road network, page 434,
Clone an aisle, page 436.
The parking lot objects

All the types of parking lot objects are composed of "Graphic elements of a parking lot object in a selected
state" (see fig. 217, page 432):
Aisles devoted to providing immediate access to the parking stalls,

Parking stalls on the right and/or left of the aisle.
LABEL
431
ICON
DESCRIPTION
Angle one lane
One way one-lane aisle between parking stalls on both sides.
Angle 2 lane
One way two-lane aisle between parking stalls on both sides.
Angle 2 way
Two way aisle between parking stalls on both sides.
Parking 2 way
left
Two way aisle between parking stalls on both sides with traffic driving on the
left. For example, like the United Kingdom and Japan.
Parking space
One way one-lane aisle with street-parking stalls.
Parking space 2
One way two-lane aisle with street-parking stalls.
PARKING
THE DIFFERENT TYPES OF AISLE OBJECTS
ISLE
A
Handle of selection at the end of the aisle

Invalid parking stall
Major lane of the aisle

Minor lane of the aisle
Parking stall
Handle of selection of parking stalls
Handle of selection of the beginning of the

aisle
Figure 217. Graphic elements of a parking lot object in a selected state
THE SETTINGS OF AN AISLE OBJECT

LABEL
Name
Name of the aisle object.
Layer
Layer associated to the parking lot object.
Prohibit circulation
432
DESCRIPTION
Determines if the aisle can be used to pass through, or if it can only be used by
vehicles entering or exiting parking stalls. If the prohibit circulation is active,
the aisle will be shown in black. In the case of a two-way aisle, you will see
two settings. Prohibit circulation is for the major lane and Prohibit Circulation 2 is for the minor lane.
AISLE
THE SETTINGS OF AN AISLE OBJECT
LABEL
Consider parking
DESCRIPTION
At the start of the aisle, the vehicle will re-evaluate all the stalls visible to it
and every 20 meter the re-evaluation will be triggered again.
Position of the
parking stall search
when Consider parking
is set
If the parameter Consider parking is set to yes, a parking stall search is added
two trajectories upstream access to the aisle. In case of a two-way aisle, use
Consider Parking 2 to determine if a parking stall search is activated for the
access of the minor lane.
Speed percent lane
Speed of vehicles on an aisle.

Maximal distance separating the best stall (isolated) and two consecutive
vacant stalls. If that distance is shorter than this value, the user chooses "the to
easy maneuver over the disadvantage of the best stall.
Attractor
The group of attractors to be considered when evaluating the parking stalls in

this parking lot.
Lane spacing
Distance to first spot
Distance to first spot 2
Space separation
Both sides
Distance in meters between two lanes for a two-way aisle.

Distance between the beginning of the aisle and the first stall in the major lane
of a two-way aisle.
Distance between the end of the aisle and the last stall in the minor lane for a
two-way aisle.
Width of the parking stalls.
Specify if the parking stalls are available on both sides of the aisle.
Create, edit a parking lot object

To create a parking lot object:
1.
fig.1 p.14).
2.
Click on the icon
of Simulation object bar, page 17 to activate the create angle one lane
mode. The cursor of the mouse is shown in the edition zone of the network as
In the Network edit area, page 19, left click at the location at the beginning of the Angle one
lane object. This opens the input window of the Angle one lane object.
4. Enter the parameters for this object and click OK to confirm.
5. Position and drag the aisle object to the right size and location.
6. Right click to confirm the creation of the aisle object.
3.
433
PARKING
Acceptable distance for

2 contiguous spaces
ISLE
A
To edit a parking lot object:
1.
fig.1 p.14).
2.
Switch to editing mode of the objects by clicking on the Edit icon
from Toolbar, page 15.
Left click on the aisle that needs to be edited.

4. Click on one of the selection handles of the aisle, hold the left button and move the objects of the
selected aisle to align and/or adjust the objects.
3.
To prohibit a parking stall of a parking object:

1.
fig.1 p.14).
2.
Switch to editing mode of the objects by clicking on the Edit icon
from Toolbar, page 15.
Move the pointer of the mouse onto the stall to be prohibited.

4. Right click and select Place inv (place invalid) from menu list.
3.
Link an aisle to the road network

After creating the parking aisles and parking stalls, it is necessary to link them to the trajectories on the road
network.
434
AISLE
To link the exit of the aisle to a support of trajectory on the road network:
1.
fig.1 p.14).
2.
Click on the icon
from Simulation object bar, page 17 to activate the create trajectory
3.
4.
In the Network edit area, page 19, left click on the aisle, and then on the support to be linked.
If it is necessary to adjust the beginning of the new trajectory at the end of the aisle, right click on
the trajectory just created and select Link trajectory at the end of the parking.
Figures below illustrate that the trajectory is linked in the middle of the aisle (left) and the trajectory is linked at the end of the aisle (right).
Before beginning shift
After beginning shift
To link a trajectory support to the beginning of the parking aisle:

1.
fig.1 p.14).
2.
Click on the icon
from Simulation object bar, page 17 to activate the create trajectory
In the Network edit area, page 19, left click on the aisle, then on the support to be linked, and
then on the aisle to be linked.
4. If it is necessary to adjust the beginning of the new trajectory at the end of the aisle, right click on
the trajectory just created and select Link trajectory at the beginning of the parking.
3.
The best practice of creating a parking facility in CubeDynasim is to maintain the connectivity of the parking
aisles and trajectories on the road network. In order to avoid cutting through the parking aisles, users can link
parking aisles with road trajectories from the middle of the aisle. To do that, just directly click on the location
of the parking aisle where the trajectory is to be linked and then select the support as the other point of the
trajectory.
435
PARKING
5.
ISLE
A
Figure 218. Examples of the establishment of a model with the trajectories connected in the middle of parking lot objects
It is necessary to avoid adding objects with priority rules such as stops and stop lines on the parking stall
or aisles.
Clone an aisle
The parking aisles are generally identical or very similar. Therefore, to reduce the modeling efforts, it is useful to have the clone feature in CubeDynasim.
Objects selected and cloned
Original Objects
Figure 219. Duplicated passage
436
AISLE
To clone parking objects:
1.
2.
3.
4.
5.
fig.1 p.14).
Make perform a multiselection, page 21 of the objects to be cloned.
Follow the proceduremove a set of objects, page 23.
Move the cursor onto one of the objects of the multi-selection. Keep the left button pressed while
dragging the objects to the right location in the Network edit area, page 19.
Click at any location of the empty space Network edit area, page 19 to validate the position
of the cloned objects.
It is preferable to first model an aisle, say a perpendicular bay, the turning movements, and the priorities
by keeping the same prefix (for example P3_A0). Then, to clone all its components.
PARKING
437
P A R K I N G L O T S
Parking Lots
CubeDynasim allows to group parking stalls into different parking lots. This feature allows users to model
parking stalls differently due to physical separations, parking duration restrictions, vehicle category restrictions, and so forth.
A parking lot is used to distribute the vehicles at the entrance of the parking facility and to determine the destination of the vehicles leaving the parking lot.
The Assign Lot object is used to manage the vehicle distribution among different parking lots.
This part describes:
Parking Lot, page 438

Assign Lot, page 440
Update Lot, page 443
Parking Lot
The Parking Lot objects group aisles by defining a quadrilateral geographical region.(see "The parking
lots", fig.220 p.439).
After parking, vehicles exit the parking facility and head to a specific destination which is assigned by the
parking lot based on its parameters of destination distribution.
438
PARKING LOTS
Figure 220. The parking lots
THE SETTINGS OF THE PARKING LOT

LABEL
Name
Unique name of the parking lot.
Layer
The layer associated with the parking lot.
Distribution
A list of the Destinations, page 74 with parameters to define the destination distribution for the vehicles that leave the parking lot.
Width
Defines the width of the boundary lines of the parking lot displayed on the network.
Color
439
DESCRIPTIONS
Defines the color of the boundary lines of the parking lost displayed on the
network.
PARKING
Parking lot
Parking lot in edit mode
To create a parking lot
1.
fig.1 p.14).
2.
Click on the icon
from Simulation object bar, page 17 to activate the create a parking lot
In theNetwork edit area, page 19, left click at the location of the first corner of the quadrilateral. This opens the input window of the Parking Lot object.
4. Enter the parameters for this object.
3.
Name of the Parking Lot

Layer associated to the selection
List of the destinations to be assigned
to the vehicles exiting the parking lot
with their relative weights.
Click OK to finish.
Left click at the location of the second corner of quadrilateral on the network.
7. Left click at the locations of the third and fourth corner of quadrilateral on the network to complete the creation of the parking lot.
5.
6.
Assign Lot
When modeling a parking facility, the traffic flow is managed by a Generator type of flow scenario Generator scenario, page 114. The traffic flow has one or several destinations pairing with different entrances to
the parking facility.
Once entering the parking facility, a vehicles goes to a parking lot depending on its behavioral parameters
(which store does the person(s) want to visit? What habits does the person(s) have?, etc).
The Assign Lot object, usually positioned on the trajectory right before the entrance of the parking facility,
determines how vehicles are distributed among all parking lots in the parking facility Parking Lot,
page 438 (see "Assign Lot", fig.221 p.441).
When a vehicle passes the Assign Lot maker, a parking lot will be assigned to it. For each of the parking lots,
we define a weight and an occupancy rate. During the simulation if occupancy rate is greater than the defined
value, that parking lot will not be assigned to any vehicles entering the parking lot until the occupancy rate
drops below the defined value. The occupancy rate is 0 when all of the parking stalls are vacant. If all of the
parking stalls are occupied, that means that the occupancy rate is equal to 1. It is possible to define an occupancy rate to be greater than 1. In that case, even if the parking lot is fully occupied, it will still be assigned
to vehicles entering the parking facility.
For example, there are two parking lots in the parking facility. The first parking lot has a weight of 1, and the
second parking lot has a weight of 2. The second parking lot will be chosen on average 2/3.
440
PARKING LOTS
If none of the parking lots is available, the vehicle exits the network by choosing a destination among a
group of possibleDestinations, page 74. In that case, we list automatically in the database the number of
vehicles that left following the criteria (table criterlabel): No more space <name of the object Affect>.
THE SETTINGS OF ASSIGN LOT

LABEL
DESCRIPTION
Name
Unique name of the Assign Lot object.
Layer
Layer associated with the Assign Lot object.
Condition Multiple-choice list field, page 33 determines the vehicles affected by
the Assign Lot object. The conditions are specified based on vehicle types and/
or Destinations, page 74. If none of the conditions are specified, all of
the vehicles passing through the Assign Lot marker will be affected.
Distribution
List of triplet:
1.
2.
3.
Lot
Weight
Rate
Speed limit of the vehicles that look for a parking stall. If the field is set to 0,
the speed limit has no effect on the parking facility. The speed of a vehicle that
is looking for a parking stall is generally slower compared to a vehicle that
exits the parking lot.
Destinations
Defines a group of the Destinations, page 74, where the vehicles will go
if they fail to find a parking stall.
Width
Color
Defines the line width of the Assign Lot marker displayed on the network.
Defines the color of the Assign Lot marker displayed on the network.
Logic Mode
Geometric Mode
Object exited
associated to the
destination of the
parking facility
Object affect selection
Entrance positioned
ahead of the exit
Objects marker
Figure 221. Assign Lot
441
PARKING
Speed searching parking
To create an Assign Lot object
1.
fig.1 p.14).
2.
Click on the icon
fromSimulation object bar, page 17 to activate the create an assign lot
In theNetwork edit area, page 19, left click at the location where the Assign Lot object needs
to be created.
4. Drag the pointer to create the Assign Lot marker to make it across the road trajectory.
5. Right click to complete the creation of the Assign Lot object. This opens the input window of the
Assign Lot object.
3.
6.
Click on the Distribution button to open the Parking Lot Assignment Distribution window. The
list area shows the list of the triplets {Lot, Weight, Rate} for this parking facility. The edit area is
used to set the values of the triplet and the command area is used to add new triplets or modify/
delete any existing triplets.
List area
Edit area
Command area
Enter values for the parking lot distribution. Click Add to create a new triplet.
Click Quit to close this window.
9. Complete The settings of assign lot, page 441, then click on the OK button to validate the
input.
7.
8.
442
PARKING LOTS
Update Lot
If the user could not find a vacant stall in the assigned parking lot, it is necessary to reconsider the three
options listed below:
try a new search for a vacant stall in the same parking lot,
2. try another parking lot (level etc.)
3. leave without being able to park.
1.
The behavior of the user affected by one of these options is modeled through the Update Lot object. The
decision of choosing one of these options depends on the number of unsuccessful attempts. For example, it is
more likely for a vehicle that has been cycling 10 times in the parking lot to either try another parking lot, or
leave.
The choice of a parking lot is done in two steps:
Choose a parking lot (from the type Distribution of Update Lot, page 443) according to the
parking lot where the vehicle is currently presented and the number of crossings already done in
the current parking lot. If current parking lot is not presented on the list of the possible parking
lots, the vehicle exists the network with a different destination (see the Destination). Also if the
number of crossings completed is strictly greater than all of the Crossing number associated to the
Update Lot defined for current parking lot, the vehicle exits the network. If one and only parking
lot is defined with different 'crossing number', the distribution associated to the smallest one
among all of the crossing numbers greater or equal to the number of crossing already completed
will be chosen.
2. Choose the parking lot according to the distribution of selected sections at 1). If none of the parking lot have been able to be selected due the occupancy rate (defined by Rate), the vehicle has to
exit the network according to the alternative destination draw from the list of Destinations of the
Update Lot object.
1.
LABEL
DESCRIPTION
Name
Unique name of the Update Lot object.
Layer
Layer associated with the Assign Lot object.
Condition Multiple-choice list field, page 33 determines the vehicles affected by
the Update Lot object. The conditions are specified based on vehicle types
and/or the Destinations, page 74. If none of the conditions are specified,
all of the vehicles passing through the Update Lot marker will be affected.
Distribution
List of the pairs:
Destinations
Defines a group of theDestinations, page 74 where the vehicles will go

if they fail to find a parking stall.
Width
Color
443
1.
2.
Lot name of the parking lot,

Crossing number: maximum unsuccessful attempts in searching for the parking
stall.
Defines the line width of the Update Lot marker displayed on the network.
Defines the color of the Update Lot marker displayed on the network.
PARKING
THE SETTINGS OF UPDATE LOT
SETTINGS OF THE DISTRIBUTION OF THE UPDATE LOT 1
LABEL
Lot
Crossing
DESCRIPTION
Parking lot which is affected by the Update Lot object.
Defines number of attempts that vehilces will try before they go to another
parking lot to find a vacant parking stallSettings of the distribution of the
update lot 2, page 444
SETTINGS OF THE DISTRIBUTION OF THE UPDATE LOT 2

LABEL
Lot
Weight
Rate
444
DESCRIPTION
Name of the new parking lot where the vehicles that failed to find parking
stalls will go.
Relative weight of the vehilces that will go to the new parking lot.
Maximum occupancy rate of the new parking lot.
PARKING LOTS
To create an Update Lot object
1.
If necessary, switch to a geometry mode (see "Main CubeDynasim window in geometric mode",
fig.1 p.14).
2.
Click on the icon
of Simulation object bar, page 17 to activate the create an update lot
In theNetwork edit area, page 19, left click at the location where the Update Lot object needs
to be created.
4. Drag the mouse to create the Update Lot marker to make it across the road trajectory.
5. Right click to complete the creation of the Update Lot object. This opens the input window of the
Update Lot object.
3.
PARKING
6.
Click on the button Distribution to open the input box of the distribution of the Update Lot
object.
List area
Edit area
Command area
In the edit area, select a parking lot, then define the maximum number of attempts a vehicle will
try in this parking lot.
8. Click Add, then Next to define the distribution of this parking lot.
7.
445
List area
Edit area
Command area
9.
10.
11.
12.
13.
446
Define the triplets {Lot, Weight, Rate} for the new parking lot that vehicles will go if it fails to
find parking stall after the maximal number of attemptsSettings of the distribution of the update
lot 2, page 444.
Click Apply to confirm the settings, and click Back.
Click Apply.
If you want to add another new parking lot for the vehicles to go, repeat from step 8 again to
update the other parking lots.
Click Quit to complete the edition of the distribution.
COUNT
DISPLAY
Count display
The Count Display object allows vehicles to know the number of vacant stalls of an area defined by a visualization zone. This functionality can be modeled with CubeDynasim..
Visualization zone of the vacant stalls
PARKING
Count display object

Figure 222. Count display
To create a Count Display object
1.
fig.1 p.14).
2.
Click on the icon
from Simulation object bar, page 17 to activate the create a count dis-
play mode. The cursor of the mouse appears in the edition zone of the network as
In theNetwork edit area, page 19, left click at the location where the Count Display object
needs to be added. This opens the input window of the Count Display object.
4. Select the layer associated to the object in the input window and click OK to validate.
5. Define the visualization zone, i.e. a quadrilateral defined by three corners (3 left clicking). If necessary, define a new zone by creating a new quadrilateral.
6. When completed, right click to confirm the creation of the visualization zones of the Count Display object.
3.
7.
447
In theNetwork edit area, page 19, left click on the icon

to show the handles of the Display
Count object and adjust the orientation of the sign with the exterior handle.
ISTRIBUTION
D
OF LANE CHANGING BEHAVIOR IN THE PARKING
Distribution of lane changing behavior in the parking lot

In the parking facility, the distances of changing lanes are shorter than the rest of the road network.
Add a new distribution of changing lanes by following the procedure and settings below:
Click on Multilane from the menu bar and select Lane Change Parameters to open the editor window to define new lane change distributions on the trajectories.
2. If necessary, add a new lane change distribution for parking facility and name it as dist2ChangePark.
3. Specify the parameters for dist2Change park given in the following table:
1.
448
DISTRIBUTION
OF LANE CHANGING BEHAVIOR IN THE PARKING
SETTINGS OF DISTRIBUTION OF CHANGING LANES FOR THE PARKING LOT

NAME
VALUES
Name
dist2ChangePark
HV Threshold
29.53 ft (8,90m)
LV average time (sec)
1,80
LV minimum time (sec)
1,00
LV maximum time (sec)
1,30
LV standard deviation
0,50
LV minimal distance
3.28 ft (1,00 m)
2,50
HV minimum time (sec)
1,50
HV maximum time (sec)
5,00
HV standard deviation
1,00
HV minimum distance
22.97 ft (7,00 m)
Click Add to create this new lane change distribution and click Quit to close the Lane Change
Parameters Management window.
5. Add this distribution to all two-lane trajectories in the parking facility.
4.
449
PARKING
HV average time (sec)
ODIFY
M
THE APPEARANCE OF THE VEHICLES
Modify the appearance of the vehicles

To improve the understanding of the functionality of the parking facility,CubeDynasim allows you to modify
the color of vehicles displayed during the animation:
Vehicles present at the beginning of the simulation, page 450,

Vehicles parks at a certain parking lot, page 450.
Vehicles present at the beginning of the simulation

If there exists a category of vehicles named as VP2 and the flow scenario used to simulate the parking model
include a matrix of 0 trips, CubeDynasim automatically models that category to represent the vehicles
parked during the pre-load period (at the beginning of the simulation).
Vehicles parks at a certain parking lot

CubeDynasim allows you to modify the color of vehicles according to their destination; therefore, you can
distinguish vehicles assigned to different parking lots in the parking facility.
To model this (vehicle color by destination), new vehicle categories named exactly as the names of parking
lots should be added into the model, according to the procedure described at the paragraph To create a new
category, page 450 and by using the file icons VL{1}04, where {i} can vary from c to h.
To create a new category
Go toManaging categories, page 42.
Select the name Car.
3. Modify the name by providing the name of the selected parking lot.
4. Click Add.
1.
2.
Follow the procedure Editing 2D representations, page 44 to change the icon of the vehicle (use, for
example, the file with CubeDynasim VLb04.xpm).
450
17
Animator
ANIMATOR
The animator is an interactive tool used to visually reconstruct the movements of vehicles and pedestrians
calculated by the CubeDynasim simulation engine. It enables you to qualitatively assess a simulation scenarios operation, making it an essential tool for understanding complex phenomena resulting from the operation of road infrastructures. With its demonstrative and instructive qualities, the animator makes it easier to
explain certain operations, and becomes a decision aid system for managers who are not necessarily specialists in traffic-related matters.
This chapter describes the animators three main components, all contained in the same window (see "The
animator", fig.223 p.452), namely:
the Controller, page 453 used to control the reading of simulation results and to access the animators
various functions,
the different View, page 455 which are animator tabs in which vehicle movements are displayed in 2D
or 3D, the signal states for each Controllers, page 305, and the state of rail blocks.
The features allow to:
Saving the animator configuration, page 464 allows to directly skip to instants and locations that best
reveal the operation of the development studied,
Playing the animation as a continuous loop, page 466.
451
Controller
Views
Figure 223. The animator
452
CONTROLLER
Controller
The "Controller" (see fig. 224, page 453) is displayed when you run the animation. It gives access to all the
animators commands.
The controller comprises :
the Animation menu bar, page 453,

the Controller Toolbar, page 453,
the Animation cursor, page 454,
a clock that displays the time simulated to the nearest second.
Figure 224. Controller
The menu bars four menus are displayed at the top of the "Controller" (see fig. 224, page 453) window.
You access a menu command in the same way as that described in the Menu bar, page 14 in CubeDynasim.Use the menu bar to:
Load a Context, page 464: File > Load Context.

Save a Context, page 464: File > Save Context.
Quit the animator: File > Quit.
Display the window for managing Markers, page 464: Marker > Open Marker.
Open a new window to display a View, page 455: View > OpenView.
Playing the animation as a continuous loop, page 466: View > Loop.
Find out the software version: About.
Controller Toolbar
The controller toolbar contains all the functions used to play back an animation.
To activate the button, click its icon.
The animator is either in pause mode or play mode. In play mode, the animation browses the trajectories
file; the clock is incremented according to the animation speed, and the vehicle positions displayed in any
views open are updated. In pause mode, the files playback is interrupted. The label and icon of the fourth
button from the left on the button bar are determined by the animator mode. Thus, Play corresponds to pause
mode, and Pause to play mode.
453
ANIMATOR
Animation menu bar
C O N T R O L L E R
The functions in the toolbar are used to:
Switch to play mode, the animator is in pause mode.
Switch to pause mode, the animator is in play mode.
Restart the animation from the beginning of the simulation. The animator switches to pause
mode.
Play the animation from the previous Markers, page 464.
Play the animation from the next Markers, page 464.
switch to step-by-step mode. Each time you click this button, the animation moves forward by
1 / 4 of the animation speed value, then pauses.
Animation cursor
You use the animation cursor to modulate the animation speed.
It comprises:
the animation speed which is a value representing the ratio between the simulated time and the real
time required to animate this simulated time. For a value of 2, two simulation seconds are animated
for one second. The minimum animation speed is obtained with a value of 0.1. A speed of 1.0 corresponds to a real time reproduction of the simulations,
a speed cursor used to adjust the animation speed.

To modify the animation speed:
1.
2.
Click and hold on the speed slider.

Drag to the left or right to respectively reduce or increase the animation speed.
When the mouses cursor is positioned over the slider, you can also move the mouse wheel up or
down to respectively reduce or increase the animation speed.
Or proceed as follows:
1.
2.
Left-click in the text field that displays the speed.

Enter the appropriate value using the keyboard or the up/down arrows in this text field to reduce
or increase the speed as appropriate.
When you increase the animation speed, you reduce the animations visual quality, especially in terms of fluidity.
You can also control the animation speed using the keyboards arrow keys. Press the left or right
arrow key to increase or reduce the animation speed by increments of 0.1. To change the speed by an
increment of 1.0, press and hold the Ctrl key while pressing the arrow keys.
454
VIEW
View
A view corresponds to a window in which the animator displays the moving vehicles and pedestrians within
a time scale. The icons represent the vehicles and pedestrians moving.You can simultaneously display more
than one view on-screen, thus enabling you to view different areas of the same development at the same
time.
When you open the animator, the 2D view is displayed, since this is the tab selected by default. The animator
also opens the 3D view and all the junction controller views.
You can go from one tab to another, or you can display a new view in another window.
To display a view in the animator:

1.
Click the appropriate view in the tab bar.
To open a view in a new window:

Click View in the menu bar.
Drag the mouse to Open a view to see the available views.
3. Drag the mouse to the appropriate view to open it in a new window.
1.
2.
ANIMATOR
This section describes the three possible views, namely:
the 2D view, page 455,

the 3D view, page 459,
the View of a controller, page 462.
2D view
The mobile displayed in a 2D view are represented by icons exhibited on the Background map, page 53.
The user must assign an icon file to a type of vehicle, using Editing 2D representations, page 44.
The displayed icon depends on following the order of priority:
the destination of the vehicle, if the ID of this destination is also the identifier of one of the type of
vehicles that has been defined,
the type of vehicle.

The 2D view can be in one of three modes:
Zoom.
2. Pan.
3. Pointed mode.
1.
455
IEW
V
The 2D view mode:
can be changed using the "2D view toolbar" (see fig. , page 456),
assign the 2D browsing, page 458.
2D view toolbar
The toolbar includes all functions affecting the 2D view.
Extended zoom
1.
Click
Locate a vehicle among the set of displayed vehicles

1.
Click
2.
Select the vehicle from the drop-down list.

Click Search to focus the view on the vehicle entered.
3.
View the information on the simulation scenario.

1.
Click
. Optional scenarios that are not defined for the simulation scenario are identified by '? '.
2.
Click Quit to close the windows.
Snapshot of the display area

1.
Adjust the view of the area and the moment you want to capture using the 2D browsing,
page 458.
Click
to select the destination file.
3. Confirm the selection to copy the display area to two graphic files, one in PNG format and the
other one in PostScript (better quality).
2.
Switch to continuous zoom (see 2D browsing, page 458)

1.
Click
2.
The state is characterized by the mouse cursor
displayed in the view.
Switch to pointed mode

In pointed mode, the user can display real-time parameters of one or more vehicles.
456
VIEW
INSPECTOR WINDOW PARAMETERS

LABEL
DESCRIPTION
Name
Number associated with the vehicle. The number of a vehicle that has left the network is
assigned to the new arrival. This number is used in the simulation error messages and the
Simulation warnings, page 419.
Type
Vehicle category (see Vehicle categories, page 41).
Destination
Name of the vehicles exit (see Destinations, page 74).
Speed
Current speed of the vehicle, in m.s-1 and km.h-1.
Acceleration
Current acceleration of the vehicle, in m.s-2.
Object
Name of the lane traveled in by the vehicle

Current position of the vehicle in the lane, in meters from the beginning of its path ("beg"), and
meters from the end of its path ("end")
Marker
Time elapsed since the simulation started, in 0.25 of a second.
To display the inspector associated with a vehicle :

1.
If necessary, click
to switch to pointed mode. The pointed mode is characterized by the mouse
cursor
2.
Click the vehicle in the 2D windows display area to open this vehicles inspector window. The
information is refreshed.
3.
Click Close in the Inspector window to close the window. Otherwise, the window remains open
even if the vehicle has left the simulated network.
Switch to pan mode (see 2D browsing, page 458)
457
1.
Click
2.
The pan mode is characterized by the mouse cursor
ANIMATOR
Position
IEW
V
Recording a video
The animator can be used to export video clips in AVI format. While recording, the animator will adjust the
animation speed to maintain a constant stream of 25 images per second.
1.
Set the area and the moment you want to capture using the 2D browsing, page 458.
2.
Click
3.
Select a folder and name the video in AVI format.
4.
Click
5.
Click again
to play the animation in the View (everything shown will be recorded in the video clip)
to stop the recording.
2D browsing
When browsing, the user defines the location and scale of the items displayed in the view.
The animation of the simulated vehicles on a background map is displayed in the 2D view display area. To
modify the portion of the background map displayed, you can resize the window, or use the scroll bars on
either side of the window.
The display area of a 2D view may be in one of the three modes: advanced zoom mode, pan mode or
pointed mode. The mode defines the shape of the mouse cursor positioned in the displayed area respectively:
,
and
.
In advanced zoom mode, you can change the scale of the elements shown in the display area. The zoom in
the display area works in the same way as the zoom in the Network edit area, page 19 (see Continuous
Zoom mode, page 20).
In pan mode, you move the background map in the window without altering the scale of the elements shown
in the display area. Pan mode in the 2D view display area works in the same way as in the Network edit
area, page 19 (see Pan mode, page 24).
To move the displayed area:
1.
Click
to switch to pan mode.
Position the cursor in the view area.

3. Move the mouse while holding down the left button.
4. Release the mouse when you are finished.
2.
458
VIEW
To change the scale:
1.
If needed click
to switch to zoom mode.
Position the cursor in the center of the area that you wish to rescale.
Click left button or right button to zoom in or zoom out.
4. The viewing area is centered at the location of the mouse pointer and display scale is changed.
2.
3.
In advanced zoom mode, you can use Pan mode, page 24, with the middle mouse button or
Ctrl+left button pressed.
3D view
To obtain a reasonable level of animations fluidity when displaying a 3D view, your hardware configuration
must include a 3D graphics accelerator card.
In the display area of a 3D view, mobiles are displayed in three dimensions. As opposed to the 2D view, here
the representation of a vehicle category is not unique, it is chosen from a set of possible representations for
this category.
In a 3D view, there are two types of animation, depending on the background used. You can use a background map in 2 dimensions, or a 3D virtual model in 3DS format.
This section describes the following:
the 3D view window, page 459,

the two types of possible Animator background, page 460,
the 3D navigation, page 462.
3D view window
The "3D view window" (see fig. 225, page 460) comprises a toolbar containing certain tools available in the
2D view toolbar, page 456 and a display area.
The display area lets you modify the users viewpoint (see 3D navigation, page 462).
459
ANIMATOR
The animation of the simulation results displayed in a 3D view corresponds to a real time animation. Thus,
you can modify your viewpoint interactively during the animation according to the three geometric dimensions. There are three navigation modes.
IEW
V
Menu bar
Controller
View tab
Tool bar
Display
area
Figure 225. 3D view window

Animator background
The animator background determines the environment in which the animator displays vehicles and their
movement. In a 3D view, you can represent the movement of vehicles :
on a 2D drawing, read from a DXF file

on a 3D virtual model environment, read from a set of 3DS files.
It is not possible to have a 3D rendering on a background map set from a bitmap file (extension bmp,
jpg etc.).
Transparencies (windows of the cars) are only taken into account in the 3D model (3DS format).
460
VIEW
Animation in a 2D view
ANIMATOR
on a 2D drawing
on a 3D virtual model
Figure 226. Animations of the same simulation in a 2D and 3D view using the various depiction backgrounds
461
IEW
V
3D navigation
The animator has two navigation mode:
free mode,
on board mode.
Free mode
Position the anchor point: double-click the 3D environment display at the desired position.
Move towards the anchor point: left-click and drag up.
Move away from the anchor point: left-click and drag down.
Turn around the anchor point: left-click and drag to the left or to the right.
Lower the viewpoint: right-click and drag up.
Raise the viewpoint: right-click and drag down.
Move the anchor point on a circle, the center of which is defined by the observers position: rightclick and drag to the left or to the right.
On board mode
The viewpoint is set relative to an anchor point that is attached to a mobile. In this case, the viewpoint
moves with the mobile. The mobile drags the viewpoint. The user can change the altitude and the distance of
the viewpoint relative to the linked mobile.
Switch to on board mode: double-right click on the follow-up vehicle.

Exit on board mode: double-right click in the display area avoiding displayed mobile.
Move closer to the follow-up vehicle: left-click and drag up.
Move away from the follow-up vehicle: left-click and drag down.
Turn around the follow-up vehicle: left-click and drag to the left or right. The camera attached to
the follow-up vehicle will automatically return to its position.
Lower the viewpoint: right-click and drag up.

Raise the viewpoint: right-click and drag down.
To obtain a drivers view:
1.
2.
3.
4.
5.
Click
to switch to pause mode.
Double-right click on the target mobile displayed in the display area.
Left-click and drag up to be positioned at the base of the target mobile.
Right-click and drag up in order to get off in the target mobile.
Click
to switch to play mode.
To optimize the 3D rendering we have to threshold the viewing distances. These display settings are
defined in a file in xml format, for each simulation scenario, to be saved in folder edyna/ name of the
study/Simul/simulation scenario/anim.cfg.
The three distances (expressed in meters) to be defined:
1. <FINVEH>500</FINVEH>: beyond 500 m mobile are no longer displayed
2. <DEBLOD>200</DEBLOD>: beyond 200 simplified models of the mobile are displayed.
3. <DEBNODYNTRANS>100</DEBNODYNTRANS>: beyond 100 meters parts of the mobile are not anymore animated (wheels do not turn).
View of a controller
CubeDynasim lets you track the status of the signals of one or more controllers.
From the animators View menu, choose a controller associated with the simulation scenario.
462
VIEW
Menu bar
Controller
Views
Display zone
463
ANIMATOR
Figure 227. Controller view
S A V I N G
THE ANIMATOR CONFIGURATION
Saving the animator configuration

The animators configuration is defined by the number, type and position of the views displayed, and possibly by the simulated moment in time being animated. When presenting simulation results or defining a
model, being able to load animator configurations directly makes using the animator easier. The configurations are saved on the hard drive.
You can save:
either a Context, page 464 which saves only the data pertaining to the views opened,
or a Markers, page 464 which stores the views and the simulated instant.
The context applies to all the simulation scenarios in a project, whereas the Marker only applies to
one simulation scenario.
Context
The context file saves the position and type of the various views currently open. Context files are identified
by their ctx extension.
To save a context:
From the animation menu bar (see "Controller", fig.224 p.453), select File > Save context to display a file selection window.
2. Enter the path and name of the file ending with the ctx extension.
3. Click OK to save the context.
1.
To load a context which has been saved in the context.ctx file:

From the Animation menu bar, page 453: select File > Open context to display a file selection
window.
2. Select the file corresponding to the appropriate context, then click OK. The controller and views
are subsequently positioned in the saved configuration, without modifying the present instant.
1.
Markers
The views displayed and the progress of the animation are saved in Marker files (also referred to as top
files) identified by the .top extension. Given that these files depend on the simulation scenario being animated, they are stored directly in the directory of this scenario (see Adding a simulation scenario, page 40).
Before re-simulating a simulation scenario, all the Marker files in the directory assigned to this
scenario are deleted.
During the animation, Marker files are automatically saved for every 5 minutes of simulated time, with a
filename in the following format: hh_mm_ss.top.
You manage marker files via the "Marker file entry window" (see fig. 228, page 465), displayed by choosing
the Marker menu in the Controller (see "Controller", fig.224 p.453)
464
SAVING
THE ANIMATOR CONFIGURATION
List area
Edit
area
Command
area
The "Marker file entry window" (see fig. 228, page 465) comprises the following three parts:
The list area, listing all the saved Marker files.

The edit area, containing an input field for the name of the current file.
The command area.
This section describes the commands used with marker files:
Load a marker file, page 465,

Save the animators current state in a marker file, page 465,
Delete a marker file, page 465.
Load a marker file
Display the Marker file entry window, page 465.
2. Select the name of the Marker file you want to load.
3. Click Apply. The Marker file entry window, page 465 closes, and the animator opens the views
and simulated instant associated with the selected marker file.
1.
Save the animators current state in a marker file

Enter the name of the new Marker file in the Name field. If you do not add the .top extension to
the name, it is added automatically.
3. Click Add to save the marker file.
1.
2.
Delete a marker file

2. Select the marker file you want to delete.
3. Click Delete.
1.
465
ANIMATOR
Figure 228. Marker file entry window
P L A Y I N G
THE ANIMATION AS A CONTINUOUS LOOP
Playing the animation as a continuous loop

To play a simulation in a continuous loop, from the View menu in the animator, select Loop animation.
466
18
DynasimViews
This chapter describes the functions used in DynasimViews, involving:
the View scenarios window, page 468,

the View results window, page 470,
and the tool used to display the criteria measured as curves:
the Graph, page 472.
467
DYNASIMVIEWS
DynasimViews is an explorer application used to view the simulation results calculated for each configuration of the same development modeled in CubeDynasim. You can use it both to animate the results, i.e., view
the movement of vehicles on a background map, and present the criteria measured during the simulation via
curves. The DynasimViews executable provided is exclusively dedicated to the data you can view. It is copyright free.
IEW
V
SCENARIOS WINDOW
View scenarios window

When you run DynasimViews, the "View scenarios window" (see fig. 229, page 468) is displayed, comprising:
a Scenario display area, page 468,

a Command area, page 468.
Sorted column
Current scenario
Figure 229. View scenarios window
Scenario display area

The scenario display area lists all the configurations simulated, characterized by:
a network scenario that groups all the parameters describing the road network,
a flow scenario that quantifies the demand.
and possibly by:
a signal scenario that establishes the programming of light signals,

a public transport scenario used to quantify the public transport lines that serve the simulated development.
The names of the network, signal, flow and public transport scenarios are respectively displayed in the Network, Signals, Flow and P.T. columns. The period of the day simulated is specified in the Schedule column
where AM Peak represents morning peak hour, PM Peak represents evening peak hour, and Off represents
off-peak hour. The first Comment column lets you comment the configuration simulated.
You can change the display order of the simulated configurations by alphabetical order of one of the field
types displayed in the scenario display area. Clicking a column header displays an arrow indicating the sorts
ascending or descending order. The list is subsequently redisplayed according to the selected sort.
All the operations accessible in the command area apply to the current scenario, which is highlighted in blue
in the display area. To select a current scenario, click the corresponding line displayed in the scenario display area.
Command area
The command area contains three buttons each with its own icon and description. To run the command associated with a button, left-click on either the buttons description or icon.
468
VIEW
SCENARIOS WINDOW
The three command buttons are as follows :
Animation, to start the Animator, page 451 to view the movement of the vehicles in the current scenario,
Outputs, to display the View results window, page 470 for the current scenario,
Quit, to close DynasimViews.
DYNASIMVIEWS
469
IEW
V
RESULTS WINDOW
View results window

The "View results window" (see fig. 230, page 470) is used to select the types of information you want to
display in the Graph, page 472.
When editing the model in CubeDynasim, you will have defined data collectors, i.e. subparts of the simulated network where you want to measure criteria during constant time samples. For example, one of the possible criteria can be defined as the average travel time needed for users to cross the subnetwork defined by
the data collector. Data collectors that are geometrically close are grouped together in a group.
The models simulated are stochastic models. This means that a certain number of values required during the
simulation are obtained according to random distributions. To obtain reliable results, this model category
requires replications, i.e. simulating the same model several times with different sequences of random numbers to understand the different situations possible. In order to summarize the information collected, you
apply a statistical operation such as the average, the percentile, etc.
The "View results window" (see fig. 230, page 470) comprises three parts:
Group list area, page 470

Edit area, page 471,
Command area, page 471.
Group
list
area
Edit area
Command
area
Figure 230. View results window
Group list area

The group list area lists all the groups (i.e., junctions, or crossroads) defined for the current scenario
selected via the View scenarios window, page 468.
To reverse the display order of the groups, click the header of the column.
By clicking one of the groups, it becomes the current group, highlighted in blue.
470
VIEW
RESULTS WINDOW
Edit area
The edit area is used to define the criterion and the type of statistical processing to apply to the values measured during replications.
The edit area is split into two parts respectively containing:
non-editable fields that display the names of the different scenarios that make up the current scenario,
single-choice list fields used to select the criterion and the statistical processing operation to apply to
the replication results data.
In this case, the criterion represents both what you measure and the statistical processing applied to the value
measured during a time sample. Table 10, "Statistics on the sampled measurement according to the criterion
measured", page 471 gives the different possible combinations and their meanings.
TABLE 10. Statistics
Criteria
on the sampled measurement according to the criterion measured

Statistics
Actual
Total number of vehicles that have passed at the end of the time sample
Number of vehicles present
Mean
Mean weighted by the time of the average number of vehicles present
Maximum
Maximum number of vehicles present during the time sample
Travel time
Mean
Mean of travel times measured during the time sample
Mean
Mean of speeds measured during the time sample
Maximum
Maximum speed measured during the time sample
Travel speed
Command area
The command area contains two buttons :
Click Draw, to start the Graph, page 472 which plots the curves of all the current groups data collectors, applying the statistical process to the criterion measured; the statistical process and the criterion measured are both defined in the Edit area, page 471,
Click Back, to go back to the View scenarios window.
471
DYNASIMVIEWS
Flow
RAPH
G
Graph
The Graph window comprises a command area, a plotting area and a Quit button (see "Graph window",
fig.231 p.472). You can have more than one Graph window open at once, for example, concerning the same
zone measured and the same criteria, but for different simulation scenarios.
Command
area
Graph title
Legend
Plotting area
X-axis
Y-axis
Figure 231. Graph window
Click Quit to close the graph window.
The plotting area contains:
the legend defining the curve color code and the identifiers of the data collectors,
the title of the graph repeating the name of the group and the criterion measured,
3. the x-axis representing the simulation time,
4. the y-axis corresponding to the scale of the criterion measured,
5. the actual plotting area.
1.
2.
By positioning the mouses pointer on one of the curves, the curve and its key are highlighted, thus making it
easier to match a curve and the name of its data collector.
To focus on a part of the plot, you must define an area on which you want to focus using a rectangle:
In the plotting area, click and hold one corner of the rectangle that defines the area on which you
want to focus.
2. Drag the cursor to the opposite corner of the rectangle.
3. Release the button; the zone selected is adjusted in the plotting area.
1.
To return to the original display, right-click in the plotting area.
472
GRAPH
The command area is used:
To save the curves in an exchange file in EMF1 format:

Click
in the command area.
2. A file selection window is displayed to select the location and name of the exchange file.
1.
To display the Graph information window, by clicking
Click Quit to close this information window.
DYNASIMVIEWS
1. Enhanced MetaFile is an exchange format used by software running on Windows 98TM, Windows 2000TM and Windows XPTM
473
RAPH
G
474
19
License and transfer codes
1.
2.
3.
4.
5.
Demo mode: the software displays the demo model which is a unique model. The user cannot
save its changes. The user cannot create a new study, or load an existing study. The software goes
into demo mode when it was not possible to find license or valid key.
Temporary key: the dongle can be used for a limited time. After that, it is necessary to associate
it with a license code (see below).
Dongle with license: CubeDynasim requires a dongle (USB key), and its unique license code
(associated with the dongle). The dongle must be detected, and the license code must match the
dongle.
Instructional license: It is a license code that is associated with a College or a University. The
license code can be used for a limited time. The backup models can only be loaded by holders of
this license code. Exports are not available with an education license. The education license does
not require a dongle.
ELA license: Please contact Citilabs at generalsupport@citilabs.com for more information.
The release of a new major version of the software requires a new license code.
Moreover, a second property, the export code, determines the number of export operations available depending on the dongle.
This chapter describes how to edit these two parameters in the "License and export code entry window" (see
fig. 232, page 476). This window is accessible in the Menu bar, page 14 by selecting About > License.
475
LICENSE AND
TRANSFER CODES
CubeDynasim can be in one of the four modes of use:
Software version
ID dongle
Figure 232. License and export code entry window

The two properties to edit are the:
License code, page 477 which must be defined when the software is installed,
Export code, page 478 which must be updated when the export token credit is empty.
476
LICENSE
CODE
License code
The license code comprises a series of hexadecimal characters given to the user by the software provider.
The first time you run CubeDynasim, you must specify the license code of the dongle connected to the USB
port on the computer, depending on the type of dongle.
To do so, run CubeDynasim to access the "Main CubeDynasim window in geometric mode" (see fig. 1,
page 14); if necessary, create a new project, page 37:
1.
2.
3.
4.
5.
6.
When exporting the directory containing the projects (see Installing CubeDynasim, page 38) to a
different computer with its own specific dongle, you must enter the license code again on the target
computer.
When updating CubeDynasim, you do not need to enter the license code again if it is not a major
release.
If you change dongles, you must enter the license code again.
477
Each time you install the software on a new computer, you will need to edit the license code.
LICENSE AND
TRANSFER CODES
Select inMenu bar, page 14: About > License to display the "License and export code entry
window" (see fig. 232, page 476).
The ID of the dongle should be displayed, if not, the dongle was not detected. In this case, check
that the dongle driver is installed.
In the License field, enter the license code.
Click Apply to confirm the new license code.
Click Quit to close the "License and export code entry window" (see fig. 232, page 476).
To ensure that the softwares parameters are correctly defined, save the model via the Menu
bar, page 14, by selecting File > Save. If a dialog box is displayed with the message temporary
key expired, the parameter definition has failed. Make sure that the dongle is connected to the
computer and that the code entered is valid, then restart the process. Should the error persist, contact your software provider.
E X P O R T
CODE
Export code
The success of the export depends on the number of remaining export tokens. The dongle determines this
value via an export code, which is a series of hexadecimal characters, and by the number of export operations already performed. This number is displayed in the Remaining exports field (non-editable) in the
"License and export code entry window" (see fig. 232, page 476). When you have no exports remaining,
contact your software provider to obtain a new export code. You must give your software provider your
license name specified in the Name field in the "License and export code entry window" (see fig. 232,
page 476)
To enter the new export code:
Select inMenu bar, page 14: About > License to display the "License and export code entry
window" (see fig. 232, page 476).
2. Enter the new export code in the Export code field.
3. Click Apply. The Remaining exports field is updated.
4. Click Quit to close the "License and export code entry window" (see fig. 232, page 476).
1.
478

Reference Manual Cube Dynasim 6.11

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Reference Manual Cube Dynasim 6.11

Загружено:

Авторское право:

Доступные форматы

Version 6

Whats new in version 6

Changes in Files and directories, page 38.

DYNASIM - REFERENCE MANUAL

Whats new in CubeDynasim:

New keyboards shortcuts for displaying and editing simulations objects.

Rail simulation, new continuous sideways, allowing multiple hooking-unhooking maneuvers.

DYNASIM - REFERENCE MANUAL

Whats new in version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . 3

DYNASIM - REFERENCE MANUAL

Layers and network scenarios . . . . . . . . . . . . . . . . . . . . 61

Network origins & destinations . . . . . . . . . . . . . . . . . . . . 67

Underpass object and 3D tile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Modeling the road network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Flow module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Empty scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Subnetwork scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

DYNASIM - REFERENCE MANUAL

Traffic counts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Estimation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Assignment scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Subnetwork Assignment scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Lane changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Lane change distance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Car-following rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Managing conflicting trajectories . . . . . . . . . . . . . . . . . 197

DYNASIM - REFERENCE MANUAL

Creating a gap time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Stop line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Strict stop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Data collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

DYNASIM - REFERENCE MANUAL

Red state duration for a signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243

Storage of the values measured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Representation of data collectors and editing them. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Public transport module . . . . . . . . . . . . . . . . . . . . . . . . 271

Public transport module management window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Signals module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Signal scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

DYNASIM - REFERENCE MANUAL

Classic Programing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Socket programming. . . . . . . . . . . . . . . . . . . . . . . . . . . 337

The Socket library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Simulation module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

DYNASIM - REFERENCE MANUAL

Edit a simulation scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Simulation module in Compute scenario mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408

Simulation module in Results mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Simulation module in Draw mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Parking Lots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

Count display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

Saving the animator configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464

Playing the animation as a continuous loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

DYNASIM - REFERENCE MANUAL

View results window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470

License and transfer codes. . . . . . . . . . . . . . . . . . . . . . 475

DYNASIM - REFERENCE MANUAL

DYNASIM - REFERENCE MANUAL

DYNASIM - REFERENCE MANUAL

AND SIMULATION MODELS

Projects and simulation models

DYNASIM - REFERENCE MANUAL

Quantification of OD-type vehicles:

AND SIMULATION MODELS