PTV Balance

PTV Balance Manual EN Contents

Copyright and legal agreements

Copyright
© 2022 PTV GmbH, Karlsruhe, Germany
All brand or product names in this document are trademarks or registered trademarks of
the corresponding companies or organizations. All rights reserved.
Legal agreements
The information contained in this documentation is subject to change without notice and
should not be construed as a commitment on the part of PTV GmbH.
Without the prior written permission of PTV GmbH, this manual may neither be reproduced
or stored in a retrieval system, nor transmitted in any form or by any means, electronically,
mechanically, photocopying, recording, or otherwise, except for the buyer's personal use
as permitted under the terms of the copyright.
Warranty restriction
The content accuracy is not warranted. We are grateful for any information on errors.
Imprint
PTV GmbH
Haid-und-Neu-Str. 15
76131 Karlsruhe
Germany
Tel. +49 721 9651-300
Fax +49 721 9651-562
[email protected]
www.ptvgroup.com

Last amended: May 2022 EN-US F

© PTV Planung Transport Verkehr GmbH 2

PTV Balance Manual EN Contents

Contents

1 Introduction .................................................................................................. 5

2 Functionality ................................................................................................. 6
2.1 Architecture and algorithms .............................................................. 6
2.1.1 Main concept 6
2.1.2 Detector positioning and Data gathering 9
2.1.3 Traffic Model 10
2.1.4 Determination of Efficiency and Evaluation of Control
Alternatives 13
2.2 Control Group Definition ................................................................. 24
2.3 Changing the Objective Function .................................................... 25
2.4 Online/Offline-System ..................................................................... 26
2.5 Local Control Possibilities ............................................................... 26
2.5.1 PTV Balance with PTV Epics 26
2.5.2 TRENDS-Kernel with normal TRELAN-Logic 26
2.5.3 Ring-Barrier Controller 26
2.5.4 Dynamic Fixed Time Control 27
2.5.5 Other Methods 27

3 Data Provision ............................................................................................ 28

3.1 Guidelines for using PTV Balance within the PTV Vision suite ........ 29
3.2 Network and Demand Data............................................................. 33
3.2.1 Network Data 33
3.2.2 Demand Data 35
3.3 PTV Balance Parameters and Signal Control Data ......................... 35
3.3.1 Local Parameters and Signal Control Data 35
3.3.2 Global Parameters 40

4 Simulation, Calibration and Operation ..................................................... 42

4.1 Simulation with PTV Vissim ............................................................ 42
4.1.1 Data Provision 42
4.1.2 Display of Additional Data in Signal Times Window 43
4.1.3 Evaluation of Additional Data in Signal Control Detector
Record 44

© PTV Planung Transport Verkehr GmbH 3

PTV Balance Manual EN Contents

5 PTV Balance and Epics Graphical user interface .................................... 45

5.1 Green wave diagram ...................................................................... 46
5.2 Evaluations for aggregated data ..................................................... 48
5.2.1 Results for the coordination group 48
5.2.2 Evaluation results for each controller 51

6 Log Files ..................................................................................................... 52

6.1 Balance_output_YYYY-MM-DD.log.txt............................................ 53
6.2 Bxx_summary_YYYY-MM-DD-log.txt.............................................. 53
6.3 Balance_signals_YYYY-MM-DD-log.txt .......................................... 53

7 Calibration .................................................................................................. 55
7.1 General information ........................................................................ 55
7.2 Guideline for Calibration ................................................................. 55
7.3 Simulation without optimization ....................................................... 55
7.4 Simulation with optimization............................................................ 55
7.5 Observing the simulation ................................................................ 56
7.6 Analysing log Files .......................................................................... 56
7.7 Result evaluation ............................................................................ 56
7.8 Tweaking calibration parameters .................................................... 57

8 The initialisation file Balance.ini ............................................................... 57

8.1 Section Global ................................................................................ 57
8.2 Section Signal Control .................................................................... 58
8.3 Section Logging .............................................................................. 58
8.4 Section Traffic model ...................................................................... 58
8.5 Section Program choice .................................................................. 59
8.6 Section Optimization ....................................................................... 59
8.7 Section Time Conditions ................................................................. 59
8.8 Section GUI .................................................................................... 59

9 Literature .................................................................................................... 61

© PTV Planung Transport Verkehr GmbH 4

PTV Balance Manual EN Introduction

1 Introduction
The adaptive network control PTV Balance (“Balancing Adaptive Network Control method”)
was originally created within the research projects “Munich Comfort” (Friedrich and Mertz
1996) and “Tabasco” (Friedrich et al. 1998). Numerous other projects followed in which the
system and its algorithms were tested, evaluated and improved, most notably the research
project TRAVOLUTION (2006-2009) with the development of a genetic optimization
algorithm. The projects TRISTAR (2013-2015) and Lublin (2015-2016) established PTV
Balance in Poland, where the latter jointly with PTV Optima was established as a
comprehensive traffic management system.
The inner core of PTV Balance consists of four parts:
1. A macroscopic traffic model that estimates flows in accordance with detector data,
2. A control model that emulates the local intersection control,
3. A mesoscopic traffic flow model that calculates the effects of a specific signal plan,
4. And most importantly different optimization algorithms.
Furthermore, it is possible to replace the macroscopic traffic model with external traffic state
estimating programs able to take a whole conurbation into account. For this purpose,
Balance can be embedded into PTV Optima, which is a traffic management platform and
decision support system developed by PTV. The main advantages of this development are
that Optima´s ability to predict traffic, enabling optimization for the near future, not only
proceeding from detectors, e.g. floating car data and ANPR data.
PTV Balance is independent of the local control method used in the field as long as the
local traffic control is able to utilize the frame signal plans calculated by PTV Balance. It’s
ideal partner is PTV Epics, as it provides effective local adaptation, full transit signal priority
and is already integrated with PTV Balance from a technical and a methodological point of
view.
PTV Balance is seamlessly embedded into the environment of the PTV Vision suite. Road
network and traffic demand are modelled in PTV Visum, while data related to signal control
and their parameters are provided within Vissig, a module of either PTV Visum or PTV
Vissim. PTV Balance’s input formats are shared with PTV Vissim and Vissig, the former
being able to fully simulate the effects of Balance control, thus enabling an elegant way of
testing, calibrating and evaluating the effects on the road network.

© PTV Planung Transport Verkehr GmbH 5

PTV Balance Manual EN Functionality

2 Functionality

2.1 Architecture and algorithms

2.1.1 Main concept

The system architecture of Balance is characterized by a two-level-concept, where the
control of the traffic light system is divided hierarchically (see Figure 1).

Figure 1: Two-level Concept of PTV Balance

 An efficient microscopic controlling method takes care of short-term changes in traffic

volume, e.g. during prioritization of public transport, based on the current detector
measurements and signal status. The local controlling system works usually on a
second-by-second basis or on shorter intervals.
 Being a macroscopic system, PTV Balance works on the tactical level of the adaptive
network control, sending framework signal plans to the intersections every 5 minutes.
The framework signal plan defines static and variable areas for the phases of the local
control of all controllers within a group that have the same cycle time. Using local
detection the local control can adjust the variable areas, adapting them to the current
traffic volume. Nevertheless, the framework signal plans provide a basic structure for
the single traffic light system. The green times of the signal groups can be modified
inside this framework.
Any local traffic control system can be applied, as long as it integrates an interface for the
frame signal plans created by PTV Balance. This flexibility was one of the main goals during
the development of PTV Balance, the ability to apply the system quickly without changing
the local traffic light system control. Currently PTV Epics, Trelan/Trends-System (Gevas
Software Systementwicklung und Verkehr Informatik GmbH 2010a/b); the SIEMENS
TL/PDM-System and other controls have been used as local control strategies. Tests with
the American Ring-Barrier controller have also been conducted.
On a network level, Balance as a central system processes the reduction of delays by traffic
adaptive coordination of traffic signals, considering offsets optimization and green waves it

© PTV Planung Transport Verkehr GmbH 6

PTV Balance Manual EN Functionality

also adapts roughly the green times of the different signal groups. A second-by-second
adaptation of the green times is handled in the local controller. If there is no local detection
or traffic responsive control available at the intersection, the Balance framework signal
plans can also be used directly as a fixed-time program.
A PTV Balance System can control all intersections of a town, but it is necessary to divide
them into several control groups, with a maximum size of 40 intersections in each group.
This additional division is required to distinguish different areas of the network with different
traffic related characteristics. One important characteristic is the single Balance selection
of a signal program with an adequate cycle time for all controllers in a group. Performance
issues play an important role, limitation of the search space for optimization is also relevant
to avoid the risk of using a local optimum.

Figure 2: Diagram of the PTV Balance network control architecture

The central database structure in PTV Balance is the network model. The street network is
represented internally as a graph in form of nodes and edges. Figure 3: Example of a
simple network model
illustrates an example of a small network with two intersections.

© PTV Planung Transport Verkehr GmbH 7

PTV Balance Manual EN Functionality

14 24

D41 D51 D45

LZA 5
45 44 43

Fv04
Fv05 Fv06

23 40
Fg51 42 15
D35 D61

13 D31 39 41 D65 25

Fv02
Fv03
Fg52 Fv01

38 36
37

D81 D21 D11

35 34
Fv08

D95
22 33

Fg53 Fv07

32 31
LZA 7
D75 D72 D71

21 11

Figure 3: Example of a simple network model

© PTV Planung Transport Verkehr GmbH 8

PTV Balance Manual EN Functionality

The edges are the central container of the traffic data within the PTV Balance System. The
procedures of the PTV Balance-Controlling system can be divided into five functional
groups:
 Data collection and preparation

 Traffic illustration

 Efficiency determination and evaluation of control alternatives

 Creation of control alternatives

 Data interface

There are more system functions available for control of the internal process, database
access, etc, but these functions are not discussed in this manual. The next chapters will
briefly describe the functional groups mentioned above.

2.1.2 Detector positioning and Data gathering

It is necessary to estimate the current traffic state in the road network as good as possible
before starting the optimization of the signal control. Local detectors collect data about the
traffic situation in form of aggregated or disaggregated measurements for the current
calculation interval. This data is gathered by the controllers and delivered to the central
database. Detectors which are not connected to a traffic light can also be utilized by PTV
Balance, additional kinds of dynamic data of the traffic light system are also collected. For
example, the currently running signal program, the cycle time or different operation modes
of the controller or the detector.
The positioning of detectors for Balance should be done according to the following rules:
1. There should be single- or double-loop detectors on every lane that leads to an
intersection controlled by a traffic light. The distance to the stop line should be at least
20m and not more than 50m. The ideal detector position is 40-50m in front of the stop
line.
2. Every lane must be detected on its own. No detector may cover more than one lane.
3. In case of turn-off lanes, if possible, the detector should also be placed according to
the distances suggested in 1. If the turn-off lane is shorter, the detector should be
placed as far as possible from the stop line on the turn-off lane and able to measure
all turning vehicles. If this is not possible, the second criterion is more important. It
may be necessary to do an on-site inspection to decide this. In addition, single loop
detectors should be placed on the main lanes 50m in front of the stop line.
4. At the borders of the area which is selected for the calculation of the traffic state
(usually the main road network), detectors which measure the outflow may be placed
about 30m behind the stop line if there are big differences between the incoming and
outflowing traffic during the day. This improves the quality of the origin-destination
estimation of the network model.
The detectors which are suggested here are normal single loops which can also be used
for time gap control or counting purposes. It is also an option to use other means of

© PTV Planung Transport Verkehr GmbH 9

PTV Balance Manual EN Functionality

detection, but only if it is guaranteed that cars are reliably counted even under adverse
weather conditions and heavy saturation.
It is usually not necessary to have more or different detectors for Balance than for Epics.
So, if the junction is controlled by PTV Epics, everything should be fine regarding detection
for Balance.

2.1.3 Traffic Model

The PTV Balance-Traffic model builds an internal spatial-chronological representation of
the current traffic situation out of traffic flows measured at different measuring sections. It
consists of three different functional parts which are arranged in two different levels (see
Figure 4):

Figure 4: Diagram of PTV Balance Traffic Model

The first level (see chapter 2.1.3.1) consists of a macroscopic traffic model (Ploss 1993),
called once every optimization. It consists of:
 An OD-Estimation for the determination of the origin-destination relations in the
subnetwork
 A traffic assignment for the allocation of traffic flows to the road edges in the network

The second level (chapter 2.1.3.3) is a mesoscopic traffic flow model, which periodically
generates traffic flow profiles out of the macroscopic traffic parameters of the first level.

© PTV Planung Transport Verkehr GmbH 10

PTV Balance Manual EN Functionality

This takes place during every step of the signal plan-optimization process inside PTV
Balance.

2.1.3.1 Macroscopic traffic model (1. Level)

An estimation of the matrix (𝑓𝑘𝑙0 ) of the traffic flows [veh/h] from an entry-edge k to an exit-
edge l is processed according to a static weighting-matrix (𝑤𝑘𝑙 ) and to the in- and outflows
at the edges of the network (OD-Estimation). The entropy maximizing algorithm of (Van
Zuylen and Branston 1982) is used for the OD-Estimation.
In the first step, the in- and outflows at the edges on the border of the controlled area are
estimated. This goal is achieved either by using already existing measurements, or by
estimating traffic, based on the historic weighting matrix and the measured values
available.
The matrix of the origin-destination relationships is the input parameter for the traffic
assignment, the distribution of traffic to streets in the network is done using an incremental
multiple-assignment algorithm. Traffic is assigned to the edges in shares of 10%, 20%,
30% und 40%. After every step, a route-searching algorithm is applied, this algorithm
calculates the fastest route according to impedances in the network (e.g. travel times) and
assigns the traffic of this step to the respective edges (All-Or-Nothing Assignment).
The results of the traffic assignment are traffic flows qMod(a) [veh/h] per edge and also a
matrix of the distribution parameters (𝑝𝑎𝑘𝑙 ), that defines which share of the traffic relation
fkl drives over edge a. Therefore, the following correlation exists:

qMod i (a ) =  pakl
i
 f kli
kE lA

Where:
i Step of iteration
a Edge index
k, l Origin/Destination index
E, A Number of entries/exists (Origin/Destinations in the network)
𝑖
𝑝𝑘𝑙 Share of the traffic relation 𝑓𝑘𝑙 which uses edge a (0 … 1,0)
The relative deviation X(a) between traffic model and reality can be calculated using the
estimated traffic flows qMod(a) and the real traffic flows q(a) measured on the edges a in
the network. The deviation is used in combination with the distribution parameters 𝑝𝑎𝑘𝑙 in
order to correct the estimation of the origin-destination relations in an iterative process.
Criteria for the cancellation of the so-called internal iteration are the exceeding of a
previously defined number of iterations or the shortfall below a given value of the standard
deviation between measured and estimated value.
This procedure is repeated until a given number of iterations is reached. The main results
are macroscopic traffic volumes qMod(a) [veh/h] for all edges a of the network, especially
for edges where no measured values are available. Other results comprise the matrix of
the origin-destination relations (𝑓𝑘𝑙 ) in the network and the distribution parameters (𝑝𝑎𝑘𝑙 ).

© PTV Planung Transport Verkehr GmbH 11

PTV Balance Manual EN Functionality

2.1.3.2 Embedding into superordinate traffic models

A superordinate traffic model like PTV Optima can also be embedded instead of the
macroscopic traffic model discussed above. PTV Optima’s model is dedicated to traffic
state estimation based on a wider range of detection sources (e.g. loop detectors, ANPR,
FCD, etc.) being able to calculate the real traffic situation in a network more precisely. As
input PTV Balance requires traffic volumes for every edge and turning rates at the
intersections of the network. The values should be delivered at least every 5 minutes.

2.1.3.3 Mesoscopic traffic model (2. level)

Traffic flow profiles qFl(a,t) [veh/s] are created for all edges based either on data of the traffic model (1.
Level), or a superordinate traffic model and the states of the signal groups in the network given
by the control model. The length of the flow profiles represents the homogeneous cycle time tu
of the control group (see Figure 5: Illustration of the traffic flow profile of the traffic model´s
second level

).

q(t) [veh/s]

ssg1
ssg2

tu t [s]
Figure 5: Illustration of the traffic flow profile of the traffic model´s second level

The mesoscopic traffic flow model takes into account the influence of traffic lights, travel
times and the dissolution of queues by means of changing speeds on the vehicle groups.
Therefore, the outflow zFl(a,t) at the end of an edge a is defined as follows:
0
𝑖𝑓 𝑡ℎ𝑒𝑟𝑒 𝑖𝑠 𝑛𝑜 𝑟𝑒𝑙𝑒𝑎𝑠𝑒 𝑎𝑡 𝑝𝑜𝑖𝑛𝑡 𝑖𝑛 𝑡𝑖𝑚𝑒 𝒕
𝑠𝑠𝑔
𝑖𝑓 𝑠𝑔 𝑖𝑠 𝑟𝑒𝑙𝑒𝑎𝑠𝑒𝑑 𝑎𝑡 𝒕 𝑎𝑛𝑑
𝑧𝐹𝑙(𝑎, 𝑚𝑜𝑑 𝑡 𝑢(𝑡 + 𝑡𝑟)) =
𝑡ℎ𝑒 𝑞𝑢𝑒𝑢𝑒 𝑙(𝑎, 𝑡) + 𝑞𝐹𝑙′(𝑎, 𝑡) > 𝑠𝑠𝑔
{𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒 𝑙(𝑎, 𝑡) + 𝑞𝐹𝑙′(𝑎, 𝑡)
With the estimated average travel time on the edge:
tr(a) = len(a) / v(a) [sec]
With the given whole-number length of the interval L:
𝐿 = (𝑘(𝑎) ∙ 𝑙𝑒𝑛(𝑎)) 𝐷𝐼𝑉 𝑣(𝑎)

Platoon dispersion is modelled over the length of two intervals 2L by applying a moving
average.
t+L
1
qFl' (a, t ) =
2L + 1
 qFl(a, t' )
t '=t − L

Where:
t Periodical base of time [1... tu (sec)]

© PTV Planung Transport Verkehr GmbH 12

PTV Balance Manual EN Functionality

sg Index of signal group sg, controlled by edge a

ssg Saturation of signal group sg [veh/s]
l(a, t) Queue length [veh] on edge a at point in time t
k(a) Calibration of the dissolving
len(a) Length [m] of edge a
v(a) Estimated average speed [m/sec] on edge a
DIV Whole-number division
The periodic traffic flow model q(a, t) at the beginning of an edge results from the additive
connection of the outflows zFl(a´, t) of the incoming edges a´. These outflows are
distributed to the following edges, according to their share of the whole traffic volume:

𝑞𝐹𝑙(𝑎, 𝑡) = ∑ 𝑝(𝑎′, 𝑎) ⋅ 𝑧𝐹𝑙(𝑎′, 𝑡)

𝑎′∈𝐼𝑛(𝑎)

The distributing factors p(a´, a) contain the share [0...1,0] of the total traffic volume on edge
a, which comes from edge a´. This share is calculated by using the traffic volumes (qMod)
which were defined in the first level of the traffic model:
𝑞𝑀𝑜𝑑(𝑎′) 𝑞𝑀𝑜𝑑(𝑎)
𝑝(𝑎′, 𝑎) = ⋅
∑𝑎̄ ∈𝐼𝑛(𝑎) 𝑞𝑀𝑜𝑑(𝑎̄ ) ∑𝑎̄ ∈𝑂𝑢𝑡(𝑎′) 𝑞𝑀𝑜𝑑(𝑎̄ )
Where:
In(a) Number of entry edges of edge a
Out(a´) Number of exit edges of edge a´
qMod(a) Modelled traffic volume [veh/h] on edge a
At the beginning of the traffic flow modelling process, the flow profiles are initialized for the
cordon edges. where an equally distributed flow profile is assumed:
qMod(a)
qFl(a, t ) = for t = (1...tu)
3600
Starting from the edges at the network entrances, this procedure is executed periodically
for all edges in the network. At the end of this process the traffic flow profiles qFl are defined
for all edges in the network. Flow modelling is processed for every edge of the sub-network
during every step of the optimization. Usually, there are more than a thousand optimizations
steps developed during every PTV Balance-call. Therefore, the traffic flow model has to be
implemented very efficiently.

2.1.4 Determination of Efficiency and Evaluation of Control

Alternatives
With the help of the effect model, the impact of the control alternatives is calculated for the
next time step. The control alternatives are evaluated by a performance index, the relevant
variables for its calculation are the weighted vehicle waiting times, number of stops of
vehicles and queue lengths.

𝑃𝐼(𝑥, 𝑦) = ∑ (𝛼𝑠𝑔𝐷(𝑥, 𝑦, 𝑠𝑔) + 𝛽𝑠𝑔𝐻(𝑥, 𝑦, 𝑠𝑔) + 𝛾𝑠𝑔𝐿(𝑥, 𝑦, 𝑠𝑔))

𝑠𝑔∈𝑆𝐺

Where:

© PTV Planung Transport Verkehr GmbH 13

PTV Balance Manual EN Functionality

SG Number of signal groups in the sub-network

sg, sg, sg Emphasis of waiting time/ stops/ queue-lengths for
signal group sg
D, H, L Vehicle waiting times/ stops/ queue-lengths for signal
group sg
x Vector of control variables
y Vector of traffic related variables
The variables of efficiency are generated by two models where every second a high-
resolution mesoscopic model calculates the deterministic share by assuming a steady
maximum speed and saturation flow. The stochastic part is determined at the stop lines by
a macroscopic queue model that takes into consideration overloads (see Figure 6).

Figure 6: PTV Balance Effect model

The deterministic part of the effect model is based on the flow profiles of the traffic model
qFl(a, t), cycle time and signal states of the controllers zust(sg,t). It calculates the impact
of the adjacent control alternatives in a numerical simulative way. The calculation for every
second enables the modelling of the traffic related impact of green time-lengths and offsets
between adjacent signal groups.
The optimization of green times of a signal group in a traffic network always has an impact
on the signal groups which are located downstream. Therefore, the optimization of the
green time is calculated for the whole subnetwork at the same time. Although this holistic
solution requires a lot of computing capacity, compared to a heuristic procedure, it
considers all relations between the signals and links in the network.
For this it is necessary to use the flow profiles of the links which lead out of the subnetwork,
as input variables for the signal groups which are located downstream. As described in
chapter 2.1.4.3, the traffic flow profiles of the entry-links of a subnetwork are initialized with
equally distributed profiles. If there is a traffic flow profile available for an exit-link of an
adjacent subnetwork, the equally distributed profile will be overwritten. This guarantees that
the traffic lights at the links of the subnetworks get realistic traffic flow profiles.
The deterministic effect model is built similar to models in the well-known planning system
TRANSYT (Robertson 1969) and the adaptive control SCOOT (Hunt et al. 1981). A
simulation of the impact of the controllers on the traffic flow is processed in order to get the
efficiency variables: vehicle waiting time, number of stops and mean queue-length. Traffic
is not modelled as single vehicles (microscopic modelling) but with help of the macroscopic
parameter traffic volume. However, this parameter is available for every second
(mesoscopic modelling). The applied formulas are described in the following sub-chapters.

© PTV Planung Transport Verkehr GmbH 14

PTV Balance Manual EN Functionality

2.1.4.1 Delay calculation

The signal group-related vehicle delay 𝐷𝑠𝑔 results from the sum of the queue lengths 𝑙𝑠𝑔 (𝑡)
which denote the vehicles that have stopped during time frame T. 𝑙𝑠𝑔 (𝑡) is defined as the
sum of the inflows 𝑄𝑠𝑔 (𝑡) at an origin or entrance (demand process) and the outflows
𝑍𝑠𝑔 (𝑠𝑝, 𝑡) at an exit or destination (service process) until the point in time t:
𝑇−1 𝑇−1

𝐷𝑠𝑔 (𝑠𝑝) = ∑ 𝑙𝑠𝑔 (𝑡) = ∑(𝑄𝑠𝑔 (𝑡) − 𝑍𝑠𝑔 (𝑠𝑝, 𝑡))

𝑡=0 𝑡=0

Where:
SG Number of signal groups
sp Evaluated signal plan
Qsg Sum of vehicles which entered signal group sg until t
Zsg Sum of vehicles which left signal group sg until t
Dsg Sum of vehicles waiting times at signal group sg
during time frame T
The following formula defines the request process Q:
𝑡

𝑄𝑠𝑔 (𝑡) = ∑ 𝑞𝑠𝑔 (𝑡´) [𝐹𝑍]

𝑡´=0

With qsg(t) = inflow [veh/s] to signal group sg at time t.

The inflow profile 𝑞𝑠𝑔 (𝑡) is the input parameter for the effect model as described above.

2.1.4.2 Vehicle stops calculation

The following formula represents the sum of vehicles Hsg, forced to stop due to the creation
of a signal plan with length t at the signal group sg.
𝑇

𝐻𝑠𝑔 (𝑠𝑝) = ∑ ℎ𝑠𝑔 (𝑠𝑝, 𝑡)

𝑡=0

Where:
sp Evaluated signal plan
hsg Sum of vehicles forced to stop at signal group sg at
time t
A vehicle must stop if it reaches the end of a queue or the stop line while the inflow is
greater than the outflow, normally when the signal is red. Therefore, the stops hsg at point
in time t are defined as follows:
𝑞𝑠𝑔 (𝑡), 𝑖𝑓 𝑡 > 0 𝑎𝑛𝑑 𝑄𝑠𝑔 (𝑡) > 𝑍𝑠𝑔 (𝑠𝑝, 𝑡)
ℎ𝑠𝑔 (𝑠𝑝, 𝑡) = {
0, 𝑒𝑙𝑠𝑒

2.1.4.3 Queue length calculation

In case of queue lengths, time related-, current-, average- and maximum lengths are
distinguished. Current queue length 𝑙𝑠𝑔 is calculated by the difference between the
incoming and the outgoing traffic:

© PTV Planung Transport Verkehr GmbH 15

PTV Balance Manual EN Functionality

𝑙𝑠𝑔 (𝑠𝑝, 𝑡) = 𝑄𝑠𝑔 (𝑡) − 𝑍𝑠𝑔 (𝑠𝑝, 𝑡) for 𝑡 = [0, . . . , 𝑇 − 1]

The average queue length L and the maximum queue length Lmax can be derived from
the formula mentioned above:
𝑇−1
𝐿𝑚𝑎𝑥𝑠𝑔 = 𝑚𝑎𝑥𝑡=0 (𝑙𝑠𝑔 (𝑠𝑝, 𝑡))

𝑇−1
1
𝐿𝑠𝑔 = ∑ 𝑙𝑠𝑔 (𝑠𝑝, 𝑡)
𝑇
𝑡=0

The maximum queue length is important for the protection of congestion spaces and to
prevent congestion into reaching preceding intersections. The maximum queue length is
applied in the performance index of PTV Balance.

2.1.4.4 Stochastic deviations modelling

The analytic queuing model of (Kimber and Hollis 1979) is used to include stochastic
deviations resulting from capacity overloads in the calculation. It only requires the degree
of saturation of an entry as a macroscopic input parameter. It is calculated by the average
traffic volume qMod of an entry and the cycle time-related green time of the signal groups
𝑡𝑔𝑟𝑠𝑔 [sec]:
∑𝑎∈𝐴 𝑞𝑀𝑜𝑑(𝑎) 𝑡𝑢
𝑟(𝑠𝑔) = ⋅
𝑡𝑔𝑟𝑠𝑔 ⋅ 𝑠𝑠𝑔 3600

Where:
A Number of edges controlled by signal group sg
r Degree of saturation
tu Cycle time [sec]
ssg Saturation of signal group sg [veh/s]
The results of the macroscopic effect model are the waiting times and average queue
lengths created by the random deviations of the traffic flow. They are added to the waiting
times of the deterministic effect model (Figure 7: Schematic waiting times with deterministic
and stochastic model
). The sum of both models serves as input for the performance index.
The formulas for the stochastic waiting time 𝑊𝐾𝐵 per signal group sg are defined as follows:
1
𝑊𝐾𝐵,𝑠𝑔 = (√𝑃2 + 𝑄 − 𝑃)
2
1 𝑔0 − 𝐶
𝑃 = (1 − 𝑟) ∗ 𝑇 −
2 𝑞
𝑇 𝑔0
𝑄 = 2𝐶 (𝑟 + 2 ∗ )
𝑞 𝑞𝑇
Where:
r = r(sg) Degree of saturation
g0 Starting queue length before signal group
C Constant (usually C=0,4 in PTV Balance)

© PTV Planung Transport Verkehr GmbH 16

PTV Balance Manual EN Functionality

q Capacity of the signal group (saturation flow

respecting green share) [veh/s]
T Time frame (usually 300 seconds in PTV Balance).
The stochastic delay is added to the deterministic delay for each signal group.
70

65

60

55

50

45
total waiting time
40

35

30
waiting time
25
stochastic model
20

15
waiting time
10
deterministic model overload area
5

0
0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 1,1 1,2 1,3 1,4

saturation r

Figure 7: Schematic waiting times with deterministic and stochastic model

The control model of the PTV Balance network control optimizes the following parameters:
 Length of the green times (split)

 Chronological location of the green times according to their equal cycle time (offsets)

 Length of cycle time

PTV Balance was originally designed to use a Hill-Climbing (HC) optimization algorithm. In
2008 an additional optimization procedure was developed and implemented in the German
research project TRAVOLUTION: The Genetic Algorithm (GA). An important advantage of
a Genetic Algorithm is its ability to optimize all control parameters at the same time. The
other advantage is its tendency to avoid local optima by applying a parallel search
throughout the solution space. The research project TRAVOLUTION showed the significant
improvement GA generates on the optimization quality in terms of a better performance
index in Balance and, more importantly, on the road. It also consumes more calculation
time, which is not a big issue in a real-world traffic centre, but slows down the speed when
used jointly with micro-simulation, e.g. PTV Vissim. Therefore, both algorithms are still
contained in Balance. The user can choose between them through an entry in the
initialization file. The GA in Balance is protected by a patent.

2.1.4.5 Calculation of split and offset

The Balance control model creates framework signal plans for all traffic lights in the
subnetwork every 5 minutes and then sends them to the controllers. A framework signal
plan (FSP) contains the length (split) of the green times of all signal groups of the traffic
light system and their chronological location (offset) according to the cycle time which is
equal for all objects in the control group. Both control variables are optimized together in

© PTV Planung Transport Verkehr GmbH 17

PTV Balance Manual EN Functionality

an integrated approach, which calculates a framework for the starting points of the
interstages for every possible periodical stage in the cycle (see Figure 8).

Figure 8: Split and offset calculation inside PTV Balance control model

The base for the optimization is the modelling of the relevant control parameters in the
control model, which are:
 The signal groups (index and type)

 The definition of stages (index, belonging signal groups)

 The definition of interstages (index, start-/target- stage, on-/off- switch points of the
signal groups, index of belonging signal groups)
 The signal programs (index, cycle time, type)

 Program-related framework conditions (minimum/maximum green times of signal

groups, earliest and latest starting points of interstages)
The optimization itself is processed for each intersection as a search in the solution space,
which is defined by the parameters described above. At first, a valid initial solution is
created with the current fixed-time program of the traffic light. A valid solution is represented
by a periodical stage cycle. This describes a vector, which consists of the indexes of the
interstages and their starting points:
𝑝ℎ𝑎𝑏 = ((𝑝𝑢1 , 𝑇1 ), (𝑝𝑢2 , 𝑇2 ), … , (𝑝𝑢𝑛 , 𝑇𝑛 ))
Where:
pui Index of interstage i
Ti Starting point of interstage i [1 ... tu] (sec)
n Length of stage cycle, number of stage transitions
Starting with the initial solution 𝑝ℎ𝑎𝑏0 , the control model creates continuously new solutions
by changing the local parameters. The starting points are increased for each interstage of
the cycle (Figure 9), the modification is interpreted in a way that allows the following
solutions 𝑝ℎ𝑎𝑏𝑖 to be also valid. This means, that the solutions are compliant with the
framework conditions and therefore give a valid signal plan for each traffic light controller.

© PTV Planung Transport Verkehr GmbH 18

PTV Balance Manual EN Functionality

Figure 9: Example of the modification of a cycle

The stage cycle is transformed into a signal plan sp by the control model. It describes the
states of the signal groups during the cycle time of the control group:
𝑠𝑡𝑎𝑡𝑒(𝑠𝑔1,1) . . . 𝑠𝑡𝑎𝑡𝑒(𝑠𝑔1, 𝑡𝑢)
𝑠𝑝 = ( . ... . )
𝑠𝑡𝑎𝑡𝑒(𝑠𝑔𝑚, 1) . . . 𝑠𝑡𝑎𝑡𝑒(𝑠𝑔𝑚, 𝑡𝑢)
Where:
sgi Signal group i
m Number of signal groups
state (sg, t) State [free, blocked] of signal group sg at point in time
t in signal plan sp
Traffic-related impacts of the solutions can be calculated by the traffic model because the
states of the signal groups in relation to cycle time are given by the signal plan. The
solutions can be evaluated by the effect model according to the given performance index
PI (see chapter 2.1.4). The goal of the optimization model is to find the optimal solution
according to the PI.
Unfortunately, the problem of traffic network optimization is very complex and not
mathematically solvable. Simple optimization strategies, like the gradient procedure or
linear optimization lead often to suboptimal results or are not applicable at all. Because of
this, the global optimum can only be found by an exhaustive search of the solution space.
This procedure will not work if there are too many input parameters (number of
intersections, number of stages per intersection, etc.) because the size of the solution
space grows exponentially with the number of input parameters, reflecting on the grow of
the calculation time to infinity regardless of the speed of the computer.

Calculation with the Hill-Climbing Algorithm

The Hill-Climbing approach is a heuristic procedure which moves the starting times of
interstages in the cycle and calculates the performance index of the resulting signal plan.
Only solutions which are better than the previous one are accepted. This is done iteratively

© PTV Planung Transport Verkehr GmbH 19

PTV Balance Manual EN Functionality

for all stages and all controllers. The performance index is always calculated for the whole
network at once, so changes that deteriorate downstream traffic will be rejected. This
procedure corresponds to the Hill-Climbing Algorithm (Domschke and Drexl 1998), which
is also used by many other adaptive network control procedures like SCOOT (Hunt et al.
1981) and TRANSYT (Robertson 1969).
The procedure mentioned above is executed multiple times for each intersection of the
respective control group with a limited number of calculation steps, until no improvement
can be achieved anymore. The best solution for each traffic light, according to the
performance index, is implemented within the framework signal plan FSP and sent to the
local controllers. At local site, stages can also be extended or skipped according to local
detection.

Calculation of split and offset with the Genetic Algorithm

The Genetic Algorithm was conceived in the Bavarian research project TRAVOLUTION
and tested in the city of Ingolstadt with 50 intersections. It proved an improvement of over
10% in terms of delays and stops in comparison to the Hill-Climbing Algorithm, and over
20% compared to the vehicle-actuated control that was previously implemented on site.
The whole optimization workflow is illustrated in Figure 10, consisting of the following main
components:
 Traffic and Effect Models

 Objective function

 Optimization procedure

The traffic model creates an internal representation of the current traffic state out of the
measured traffic volumes. The effect model, which is based on the traffic model, determines
the efficiency variables, which in turn are the input parameters for the objective function.
The result of this function is the fitness of an individual, which means a scalar quality value
for a control alternative (signal plans of the network). The fitness in turn is the input variable
for the optimization procedure for the signal plans of the whole network and determines the
best control alternative (best strategy) for the current traffic flow. All main components and
the framework signal plan FSP represent the traffic adaptive network control PTV Balance,
which delivers a new framework signal plan every 5 minutes (tactical level). Based on that,
the local control of the traffic light at each intersection reacts with short-term changes of
the traffic flow every second (operational level).

© PTV Planung Transport Verkehr GmbH 20

PTV Balance Manual EN Functionality

Figure 10: Online optimization procedure

The coding of the control parameters has significant meaning for the quality and the
functional ability of the optimization. In case of an evolutionary algorithm, coding means
the translation of signal plans to the individual. In case of a given problem, the following
framework conditions are relevant for coding:
 Conditions of the planning (allowed cycle times, allowed cycle procedures)

 Necessary framework conditions (intergreen times, minimum green times)

 Framework conditions of the local traffic-dependent control

The framework conditions for the time interval control are illustrated in Figure 11. The
framework signal plan for the local measurement-based time-gap control is defined by the
T-Time Limits (TiA, TiB). The latest starting points of the interstages TiB are optimized for all
traffic lights in the control area. An interval [TiBmin, TiBmax] is defined for TiB in order to assure
the functionality of the local control.

© PTV Planung Transport Verkehr GmbH 21

PTV Balance Manual EN Functionality

Figure 11: T-Time Limits of the local control

The optimization procedure GALOP (GALOP-Online – ein Genetischer Algorithmus zur

netzweiten Online-Optimierung der Lichtsignalsteuerung, Braun and Kemper 2008)
represents the control alternatives of the so-called coding of individuals. An individual has
the following expression:
{𝜙, (𝜎1 , 𝜔1 , 𝜊1 , 𝜃11 , . . . , 𝜃1𝑚1 ), (𝜎2 , 𝜔2 , 𝜊2 , 𝜃21 , . . . , 𝜃2𝑚2 ), . . . , (𝜎𝑛 , 𝜔𝑛 , 𝜊𝑛 , 𝜃𝑛1 , . . . , 𝜃𝑛𝑚𝑛 )}

It contains a gene φ for cycle time as well as n “chromosomes” for the m intersections of
the network which are to be optimized. Every chromosome consists of multiple genes: one
gene σ for the definition of the stage cycle, one gene ω for the global offset, one gene ο for
the local offset, as well as m genes ϴ for the stage durations respectively, the starting
points of the interstages. Every gene has a real value between 0 and 1.
The genes remain inactive for the local and the global offset in the version of the algorithm
which is implemented in TRAVOLUTION, a special sequential coding was developed
because of the offset limits and framework conditions of the local traffic dependent control.
Its principle is described in (Braun and Kemper 2008) and (Braun 2008), it is protected by
patents. Besides the necessary framework conditions, like the adherence of intergreen
times, it also integrates the framework conditions of the local traffic-dependent control. The
achievement was to create only valid individuals in each optimization.
The arrangements of the operators of the evolutionary algorithm and their parameterization
have a great influence on the quality of the optimization procedure. The operators must be
aligned to the coding because one individual represents all intersections in the network. An
intersection in the individual is illustrated as a set of genes (one chromosome). During the
recombination, single genes from the parents-individual are used for the creation of
offspring-individuals by default. The recombination-operator was developed concerning the
probability that a recombination will also be applied to the complete chromosomes
(intersections). A mutation takes only place inside T-Time limits. Therefore, the length of
the steps can either be adjusted individually for each gene or for the whole individual,
making possible on-demand adaptation.

© PTV Planung Transport Verkehr GmbH 22

PTV Balance Manual EN Functionality

The Hill-Climbing Algorithm can only optimize the control parameters sequentially in contrary to the
Evolutionary Algorithm, which optimizes all control parameters at the same time. Therefore, the created
control alternative depends on the chosen order. As soon as no better control alternative can be found for a
control parameter in one direction, the search will be continued for another direction. Figure 12: Comparison
of the fitness development of GA and HC

Figure 1 illustrates an example of the differences in behaviour between the Hill-Climbing

Algorithm and the Evolutionary Algorithm in an identical network with identical traffic
volumes.

400000

350000

300000
Index
(Gütewert)

HC
Performance

250000
GALOP
(Best)Fitness

200000

150000
Beste

100000

50000

0
0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000
EvaluatedBewertete Steuerungsalternativen
alternatives/Objective function calls

Figure 12: Comparison of the fitness development of GA and HC

Figure 1: Comparison of the development of the fitness of the GA and the HC

The Hill-Climbing Algorithm starts with the signal plans of the basic control that already
have a good quality. Contrary to the evolutionary algorithm which begins with a random
initial population. The best individual of the first generation (after 175 evaluated individuals)
does not reach that quality yet. However, the Hill-Climbing Algorithm stops after 2.404
evaluated control alternatives with a quality value of 241.742, because it can´t find a better
control alternative (probably stuck in a local optimum). Instead, the evolutionary algorithm
reached a fitness of 236.556 after 2.300 individuals in the 18th generation. The evolutionary
algorithm reaches a fitness of 186.559 after 80 generations and 10.050 control alternatives.

2.1.4.6 Calculation of the ideal cycle time

The calculation of the ideal cycle time is done for all controllers of a control group at the
same time to achieve an equal cycle time within the group. However, the adaptation is
processed slower and in larger intervals than the changing of the split and offset
parameters, because a change of cycle time usually requires synchronization at the local
controllers. This can take several cycles to avoid disruptions on traffic, therefore frequent
changes should be avoided.

© PTV Planung Transport Verkehr GmbH 23

PTV Balance Manual EN Functionality

Moreover, this adaptation can only be processed in discrete steps, because the selection
of signal programs with a given cycle time is done at intersection level. Only a limited
number of signal programs can be supplied for each controller. Therefore, Balance
determines the signal program that has the nearest but bigger cycle time to the current
ideal cycle time.
The switching procedure for the traffic-dependent selection of the signal plan calculates
automatically the required cycle time out of the saturation ratio of the signals with an
optimized signal plan from Balance. Considering the green time tgr and the saturation ratio
µ for a signal group, the additional green time ∆𝑡0 necessary to reach a desired saturation
α (e.g. 90%) with the same cycle time is determined as follows:
𝜇
∆𝑡0 = (𝛼 − 1) 𝑡𝑔𝑟

If the green time is increased by this value, the cycle time also changes, so it is necessary
to adjust the green share again to reach the desired value. This leads to the following
formula for the cycle time change Δt for a whole intersection:
∑ ∆𝑡𝑖,0 𝑡𝑢
∆𝑡 =
𝑡𝑢 − ∑ 𝑡𝑖,𝑔𝑟 − ∑ ∆𝑡𝑖,0

With ti,gr the green time of the critical signal group in stage i and ∆𝑡𝑖,0 as the additional green
time for stage i (tu is the current running cycle time). The intersection with the biggest value
of Δt in a control group is the most critical intersection and thus, determines the necessary
cycle time as tu+Δt. Consideration of the available signal programs and their cycle times
allows to choose the signal program that has minimum cycle time longer than the desired
one. Thresholds can be applied for the number of repetitions of this calculation, before an
actual switch is done in the field. These thresholds can be set differently for switching into
longer or shorter signal programs.

2.2 Control Group Definition

For network control several control areas marking the traffic light systems which should be
controlled in one go should be defined. These control areas are defined according to the
following guidelines:
 Distance between intersections

 Different cycle times

 Coordination areas

There shouldn’t be more than 40 intersections in one signal control, and as few as 1 is
permitted, if the intersection is separated from its surrounding. The greater the number of
intersections, the more degrees of freedom in the optimization, enhancing the risk to stick
to a local optimum.
The maximum distance between the traffic light systems which belong to one control area
should be in the range of 700-1200m. A larger distance prevents possible coordination,
because the queue dissolving processes increase with a larger distance.
Different cycle times in a control area prevent the coordination of the respective traffic light
system. Coordination is still possible to some extent if the different cycle times are multiples

© PTV Planung Transport Verkehr GmbH 24

PTV Balance Manual EN Functionality

from each other, e.g. 60s and 120s. No coordination and therefore no good optimization of
the network can be processed if the cycle times are not uniform.
In order to guarantee a good optimization, it is important not to divide coordination areas
by a control area. A coordination area should be integrated into the control area because
in general, coordination areas already fulfil the first two conditions: distance between
intersections and uniform cycle times.
The groups are defined statically, according to geographical issues and traffic-related
coherence. Because of the queue dissolving process, it is useless to add traffic light
systems which are far away from the group. Moreover, it must be regarded, that traffic light
systems of a group must run in the same cycle time. The defined groups are checked and
calibrated before the actual operation in the street by simulation and quality management
plans. The entire system changes when adding a signal controller, therefore the control
group would have to checked and calibrated again after the addition of a controller, in order
to guarantee an error-free operation of the group. Because of that, integration of a
completely dynamic change of the group compositions would not make sense. But, as
Balance is able to collect the road links that are belonging to a coordination area on itself,
it is perfectly possible to change the group membership of signal controllers without
changing the road network itself.

2.3 Changing the Objective Function

A dynamic change of the objective function is realized by additional master-weights. The
single summands of the objective function are multiplied with additional factors WD, WH,
WL, which are valid for the whole group. Therefore, either single impacts can be
disregarded by a factor 0 or different combinations of impacts can be regarded.

𝑃𝐼(𝑥, 𝑦) = ∑ (𝛼𝑠𝑔𝐷(𝑥, 𝑦, 𝑠𝑔) ⋅ 𝑊𝐷 + 𝛽𝑠𝑔𝐻(𝑥, 𝑦, 𝑠𝑔) ⋅ 𝑊𝐻 + 𝛾𝑠𝑔𝐿(𝑥, 𝑦, 𝑠𝑔)

𝑠𝑔∈𝑆𝐺
⋅ 𝑊𝐿 )
Where:
SG All signal groups in the subnetwork
sg, sg, sg Weights of waiting times/stops/queue lengths of signal
group sg
D, H, L Vehicle waiting times/stops/queue lengths
WD, W H, W L Master-weights of waiting time/stops/queue length
x Control parameters vector (signal plan of each
intersection)
y Traffic parameters vector (traffic volumes)
These factors can be changed dynamically by the user to create an optimization of the
objective function with the respective weights. The following optimization possibilities are
available for the user:
 Minimization of the number of stops

 Minimization of delay times (same as minimizing travel times)

 Minimization of queue lengths (same as maximizing traffic flow)

© PTV Planung Transport Verkehr GmbH 25

PTV Balance Manual EN Functionality

Please note that, in order to simplify things, Vissig allows to set just one weight per signal
group. This weight is internally distributed between vehicles, stops and queue lengths. The
setting of the Master-weights is possible via the Balance.ini.

2.4 Online/Offline-System
In previous chapters, network control was mentioned in combination with the live-, online-
system respectively. However, it is also possible and useful to build the network control in
an offline system. PTV Vissim (PTV GmbH 2022a) serving as simulation software. PTV
Balance is integrated into Vissim systems as a DLL-file. The data provision of PTV Balance
is created by Network-XML-Files which are exported from the data provision tool PTV
Visum and by a signal controller data-file shared with PTV Epics and Vissig. In this case,
data provision itself is similarly done to data provision for the online system. Further
information about this topic can be found in chapters 3 and 4.1.
The offline system offers multiple ways to test the behaviour of the network control because
functionality of the network control is not affected. It is possible to test conceivable changes
and calibrate the whole system including network control. It is important to test changes at
an intersection inside the offline mode before they are applied in the online system,
because changes at one intersection of the network control could have an impact on the
whole system. Therefore, it is important to test changes of weighting, objective function,
control or the network itself in a simulation.

2.5 Local Control Possibilities

2.5.1 PTV Balance with PTV Epics

It is possible to operate the network control PTV Balance with PTV Epics. PTV Balance as
network-wide system takes the task of overall coordination and traffic control. While the
model-based system PTV Epics will assume local holistic optimization on the nodes
including public transport. Thus, traffic-dependent control is realized within seconds and
can react very quickly to changes in traffic.

2.5.2 TRENDS-Kernel with normal TRELAN-Logic

A further possibility is to combine rule-based traffic-dependent control by means of
TRELAN-Logic (Gevas software Systementwicklung und Verkehrinformatik GmbH 2010b)
with the network control PTV Balance. Every 5 minutes the frame signal times on which
local traffic-dependent control is based are optimized by PTV Balance. Public transport is
considered only by the local control.

2.5.3 Ring-Barrier Controller

The North American Ring-Barrier control system was already equipped with PTV Balance
as a superordinate network control system. This has been tested in a simulation study and
in real-live environments.

© PTV Planung Transport Verkehr GmbH 26

PTV Balance Manual EN Functionality

2.5.4 Dynamic Fixed Time Control

In network control it is also possible to bypass the local control function and to use a so-
called dynamic fixed time. The earliest and latest starting points of the interstages as part
of the frame are reduced to one point. If the local control is set in a way that the
requirements of PTV Balance are strictly adhered, a dynamic fixed time control is switched
that changes the green times and offsets every 5 Minutes. There is no local traffic
dependency needed. This control method is a valid option if transit signal priority is not
used and traffic demand is rather static.

2.5.5 Other Methods

The network control PTV Balance can be coupled with many local control systems, so
connections with other methods are open. It has e.g successfully been applied at many
intersections in Taiwan, using the Taiwan Version 3 protocol to access the local controllers.

© PTV Planung Transport Verkehr GmbH 27

PTV Balance Manual EN Data Provision

3 Data Provision
The PTV Vision suite allows data provision for PTV Balance in a seamless way for
simulation and calibration. This data provision consists of the following parts:
 A network model of the road network and the traffic demand
PTV Visum provides these information in anm and anmroutes format. This step uses
the same standard export and import functionalities that are used to convert a PTV
Visum model to PTV Vissim.
 Parameters of PTV Balance and signal control data

 Local parameters e.g. signal control data and parameters that are intersection
related.
The signal controller mode “Epics/Balance-Local” is used to provide signal control
data. This signal controller is available in PTV Visum and PTV Vissim. Vissig, PTV
Balance and PTV Epics use the same sig-data format that can be shared between
the different models. Since PTV Visum 2022 and PTV Vissim 2022, the sig-files
have been integrated in ver-files, anm-files and inpx-files. Specifically in the
simulation context PTV Balance and PTV Epics utilize this data and do not require
sig-files anymore. If sig-files are required (e.g. for the field data provision of an
operational PTV Epics), these can be exported from the GUI of Vissig or
Epics/Balance-Local.
 Global parameters e.g. optimization algorithm
Global parameters for PTV Balance are provided using the traffic signal controller
“Balance-Central” in PTV Vissim.
For details regarding PTV Vissim, PTV Visum or PTV Epics please refer to their respective
manuals (PTV GmbH 2022a/b/c).

Modelling in PTV
•Network Model Vissim •Simulation for
•Traffic Assignment testing and
•ANM/ANMROUTES-Export •Finetuning of the calibration
simulation model
•Provision of signal control
data for PTV Balance/Epics •Provision of
signal control Simulation of PTV
data for PTV Balance and Epics
Modelling in PTV Balance/Epics and/or
Visum Field Data Provision

Figure 13: Data provision workflow in the PTV Vision suite

© PTV Planung Transport Verkehr GmbH 28

PTV Balance Manual EN Data Provision

Hint: PTV Balance is a network controller that optimizes signal plans generally every five
minutes. It has local and global parameters. It requires a local signal controller to apply the
optimized signal plans. Therefore, PTV Balance is modelled with two types of signal
controllers: “Epics/Balance-local” and “Balance-Central”. The local controller
“Epics/Balance-local” can accomplish several tasks. It can be solely an executor of PTV
Balance, it can be local traffic signal optimization PTV Epics and it can be a combination
of both.

For guidelines on using PTV Epics and PTV Balance within the PTV Vision suite, please
see chapter 3.1.

3.1 Guidelines for using PTV Balance within the PTV Vision
suite
This chapter provides guidelines for data provision for PTV Balance and PTV Epics within
the PTV Vision suite. The guidelines are a recommendation, there are other means of
handling the related tasks and the necessity of specific steps depends on the actual project.

Step 1: PTV Visum - Base model

Provide a suitable base model in PTV Visum in terms of:
 Supply with hourly capacities on links and turns, vehicle restrictions, free flow speeds
etc. and public transport if required for simulations with PTV Epics.
The network needs to be suitable for anm export/import, for example:
 connectors must not be connected to nodes that represent a physical intersection

 every node must not have more than one connector per direction

 every zone must not have more than one connector per direction

 Demand matrices for the relevant days and times of day for which PTV Balance shall
be designed and calibrated (e.g. Mon-Fri morning peak, Mon-Fri mid-day, Sat/Sun
morning peak etc.).
Ideally, these matrices have already been assigned and are corrected with
TFlowFuzzy for hourly counts (see PTV GmbH 2022b “Matrix correction using
TFlowFuzzy”). See also Step 3: PTV Visum - assignment specifics.

Step 2: PTV Visum - PTV Balance (and PTV Epics) data provision
Hint: Use the Add-In “Pre-process Balance/Epics” in order to create specific user defined
attributes for PTV Balance and load an appropriate layout for the junction editor.

1. Set the PTV Visum project directory for “External control” to the directory of the
“.ver” file.
2. Provide detailed information for all nodes that shall be controlled by PTV Balance
using the junction editor. For any of these nodes:
 Create a signal control of type “Epics/Balance local”

 Edit the signal control “Epics/Balance local” (see chapter 3.3.1 and PTV GmbH
2022b “Editing a signal control in Vissig”).

© PTV Planung Transport Verkehr GmbH 29

PTV Balance Manual EN Data Provision

 Add only signal groups and return to the PTV Visum junction editor

Hint: In the next steps signal groups will be assigned to lane turns. After this step, the GUI
of “Epics/Balance local” will draw direction arrows for the specific signal groups, making
further steps much easier.

 Define the geometry of legs, lanes, lane turns and crosswalks

 Assign signal groups to the corresponding lane turns

 Add detectors to lanes, assign the appropriate signal control and channel
number
Hint: Log-in detectors for public transport prioritization for PTV Epics can be at a long
upstream distance from the node of the signal control. It is possible that the link
approaching the signalized node is too short and the detector is located on a further
upstream link. In that case, add the detector to the appropriate upstream node and make
sure that the assigned signal control of the detector is correct.

 Verify that the allowed traffic systems of turns and lane turns are consistent

 Edit the signal control “Epics/Balance local”

 Define intergreen matrices, stages, signal programs, etc.

 Define parameters for PTV Balance and PTV Epics (can be also done after Step
5: in PTV Vissim)
Hint: When signal control design is started from scratch (i.e. no fixed time signal programs
available) you can use the PTV Visum procedures “Signal cycle and split optimization” and
“Signal offset optimization” (PTV GmbH 2022b) to quickly create proper initial signal
programs for a large number of intersections (see Step 3: PTV Visum - assignment
specifics).

3. Define signal coordination groups and assign signal controllers to these groups.
4. After finishing the data provision of all signal-controlled nodes, run the Add-In “Pre-
process Balance/Epics” again. This updates the saturation flow rates with respect to
the updated lane turns.
5. Use the network check “Viability for Balance / Epics” and make sure that all checks
are “ok”.

Step 3: PTV Visum - assignment specifics

PTV Balance requires an anm export with an anmroutes file containing routes. An
anmroutes file can contain matrices and/or routes. The latter describing an assignment
result from PTV Visum. This means that one must calculate an assignment in PTV Visum
and export the results via an anmroutes file containing routes to PTV Vissim and PTV
Balance. This is a very comfortable way of defining vehicle inputs and vehicle routes in
PTV Vissim. The following is valid for anmroutes-routes, where specifically the interaction
of anmroutes-matrices and time validities is different.
There is no general limitation to the assignment method. However, the following points are
of importance:

© PTV Planung Transport Verkehr GmbH 30

PTV Balance Manual EN Data Provision

 Impact of signal control

This can either be considered directly by an assignment with ICA or by suitably
derived capacities on turns e.g. from an assignment with ICA (see PTV GmbH 2022b
“The procedure of assignment with ICA”).
 Time validity of the demand
Static assignments do not consider whether a demand matrix contains the demand for
1 or for 24 hours, though certainly the capacities of the network must correspond.
What is of importance for PTV Vissim as well as for PTV Balance is that the demand
information of the anmroutes file is connected to an appropriate time interval (see PTV
GmbH 2022b “Saving an abstract network model”).
In general, it is perfectly fine to use a static assignment that e.g. assigns a 3 hour
demand matrix and map this to a simulation time interval of three hours in PTV Vissim.
However, that way it will neither be possible to use an assignment with ICA, that
requires hourly values nor will it be possible to represent a demand in PTV Vissim that
changes over time e.g. one hour with low demand, then one hour with high demand
and then again one hour with low demand. In order to represent this, an assignment
with the Dynamic User Equilibrium should be used (see PTV GmbH 2022b
“Parameters of Dynamic User Equilibrium (DUE)”). On the other hand, DUE cannot
directly consider the impact of signal control on turn capacities.
In order to consider both impacts of signal control on capacities and a fluctuation in demand
over time, a combination of assignment with ICA and DUE is recommended. The former
providing turn capacities for the latter and the latter providing the actual input for PTV
Vissim and PTV Balance. If a simulation time of one hour is sufficient and demand
fluctuations over time are not of interest, then skip sub-steps 5 and 6 in the
recommendation below.
1. In Calculate → General procedure settings → Prt settings → Assignment set
Save paths to As connections.
This allows PTV Visum to save the routes of an assignment in the anmroutes file.
2. Optional: Use an assignment without blocking back and TFlowFuzzy to correct the
demand matrices (see PTV GmbH 2022b “Matrix correction using TFlowFuzzy”).
3. Use an assignment with ICA for the peak hour demand (see PTV GmbH 2022b
“The procedure of assignment with ICA”).
4. Optional:
 Use “Signal cycle and split optimization” and “Signal offset optimization” (see
PTV GmbH 2022b) to provide new or update existing fixed time signal plans.
 Recalculate the assignment with ICA to respect the updated signal plans.

Hint: While it seems tempting to set up an iterative process around sub-steps 2 to 4, this
has to be avoided, as it is likely that this process has a positive feedback loop and will yield
an unrealistic result.

5. Use the ICA capacities “ICAFINALCAP” as turn capacities. Apply a minimum turn
capacity of 100 [veh/h].

© PTV Planung Transport Verkehr GmbH 31

PTV Balance Manual EN Data Provision

6. Use the DUE assignment to calculate the final output for PTV Vissim and PTV
Balance.

Step 4: PTV Visum - anm/anmroutes export

1. Export the network and the assignment result as anm and anmroutes files.
For general information on anm/anmroutes export see PTV GmbH 2022b “Saving
an abstract network model” and for PTV Balance specific parameters see chapter
3.2.1 and 3.2.2.

Hint: In order to simulate large networks with several signal coordination groups in a timely
manner in PTV Vissim, create different signal coordination groups in Visum and assign the
signal controllers to the groups they belong to. Each PTV Balance instance will
automatically derive the road network surrounding the controllers that belong to its
coordination group.

In order to simulate several demand scenarios, repeat the process starting from Step 3:
PTV Visum - assignment specifics but only export the anmroutes file and specify a suitable
name.

Step 5: PTV Vissim - anm/anmroutes import

1. Import only the anm-file in PTV Visum (see PTV GmbH 2022a “Importing ANM
data”)
2. Check the result of the anm import and fine tune the network as desired. Typical
tasks are:
 Check detector positions.

 On connectors that reduce additional lanes after an intersection, check if Route

→ Lane change: is short enough to make the vehicles use the additional lanes.
 Depending on the maximum cycle time, adjust the Waiting time before
diffusion of the Driving Behaviours.
 Check conflict areas and positions of links, connectors and crosswalks.
Specifically, large intersections are likely to require corrections.
 If desired, apply cosmetic changes e.g. number of splines on connectors, fix the
splines on links (besides “inside intersection corrections”, typically links feeding
the network that lead to an intersection with a central island require fixing) etc.
Take note that, besides slightly changing the lengths of links and connectors,
these changes do not affect the quality of the simulation.
3. Add a signal controller of type “Balance-Central” and provide parameters (see
chapter 3.3.2).
4. Save, this is your “base” network in PTV Vissim.
5. Import the anmroutes files as desired.

© PTV Planung Transport Verkehr GmbH 32

PTV Balance Manual EN Data Provision

Hint: The import of the anmroutes file can be repeated as long as the node structure in the
inpx-file remains stable. This swaps the entire demand and allows a comfortable way of
handling different demand scenarios within one inpx-file. In order to keep track of the results
use the comment of the Simulation Runs list.

It is also possible to “split” and maintain several inpx-files for every demand scenario,
though this makes updates of the network for several inpx-files more tedious.

Step 6: PTV Vissim - simulation and calibration

1. Simulate and calibrate (see chapter 4)
 Make sure that PTV Vissim behaves realistically (precisely due to anm based
network generation).
 Fine tune PTV Balance and/or PTV Epics parameters.

Hint: For PTV Balance the input file that describes the network is the anm file. Therefore
changes to the network, e.g. saturation flows for PTV Balance, adding detectors (or
correcting the position in terms of placing the detector on another link) etc. or anything
that is stored in the anm file needs to be applied in PTV Visum requiring a new export of
the anm file (consequently the import in PTV Vissim).

This does not apply to PTV Epics.

3.2 Network and Demand Data

3.2.1 Network Data

An anm file created with PTV Visum describes the network data (links, turns, number of
lanes, detectors etc.), PTV Vissim can import this file. The anm file is a parameter of the
signal control Balance-Central.
The anmroutes file is used in the same way as for an export to PTV Vissim (see PTV GmbH
2022b “Saving an abstract network model”). In addition to that, it is required to define
attributes describing the saturation flow for links and turns for the anm export in PTV Visum.
The saturation flow corresponds to the capacity of a link or turn with no signal control.
The PTV Visum Junction Editor and Control add-on is required to model signalized
intersections in the required level of detail.
To define the additional parameters in PTV Visum:
1. Open anm export parameters on File → Export → Vissim (ANM)
2. Click on Further settings.
3. In Signal controls click on the button next to Attribute defining the coordination
group.
4. Choose any attribute.
Fill the chosen attribute with the corresponding values.

© PTV Planung Transport Verkehr GmbH 33

PTV Balance Manual EN Data Provision

Element Description

Attribute defining the Numerical attribute that assigns the signal control to a signal control group.
coordination group [-] PTV Balance optimizes all signal controllers of one group together. To
design control groups base yourself on the topology of the network and
runtime restrictions (depending on network size and computational power
usually up to 40 signal controllers are feasible).
It is possible to provide several signal control groups in the same anm file.
Use the global parameters of PTV Balance in PTV Vissim (see chapter
3.3.2) to optimize a specific group together with PTV Vissim.

5. In Settings for other objects click on the button next to either Attribute defining
the saturation flow rate of links or Attribute defining the saturation flow rate of
turns.
6. Choose any attribute.
Fill the chosen attribute with the corresponding values.
Element Description

Attribute defining the Saturation flow of the link with respect to the number of lanes, share of
saturation flow rate of links HGV, slope, etc. standard value is 1800 x number of lanes x reduction
[veh/h] factors.

Attribute defining the Saturation flow of the turn with respect to the number of lanes, share of
saturation flow rate of turns HGV, slope, direction (right turns tend to require a lower speed than
[veh/h] straight turns) etc. standard value is 1750/1850/1800 (right/straight/left) x
number of lanes x reduction factors.

© PTV Planung Transport Verkehr GmbH 34

PTV Balance Manual EN Data Provision

3.2.2 Demand Data

An anmroutes file describes the demand data, create this file with PTV Visum. PTV Vissim
can import this type of files too. The anmroutes file is a parameter of the signal control
Balance-Central.
The anmroutes file is used in the same way as for an export to PTV Vissim (see PTV GmbH
2022b “Saving an abstract network model”).
The anmroutes file must contain only Routes. In PTV Visum Calculate → General
procedure settings → Prt settings → Assignment set Storage of paths to Save as
connections. This allows PTV Visum to save the routes of an assignment in the anmroutes
file.
Hint: A static assignment in PTV Visum does not have any information about the time.
Therefore, if exporting the result of a static assignment, make sure that the demand and
the Simulation time interval in the ANM export parameters fit together. PTV Vissim and
PTV Balance will respect these settings.

In order to test how PTV Balance reacts to unplanned changes in demand it is possible to
use different anmroutes files for PTV Vissim and PTV Balance.

3.3 PTV Balance Parameters and Signal Control Data

3.3.1 Local Parameters and Signal Control Data

PTV Balance related parameters are provided with the GUI of the signal controller
Epics/Balance-local that is an extended version of Vissig. This manual will only address
additional data relevant for PTV Balance. Sections that are not covered are not required by
PTV Balance.
PTV Balance requires a stage-based design.
1. In PTV Vissim from the Signal Control menu, choose → Signal Controllers.
The Signal Controller list opens.
2. Right-click on the entry of your choice.
3. From the shortcut menu, choose Edit or Add.
The Signal Control window opens.

© PTV Planung Transport Verkehr GmbH 35

PTV Balance Manual EN Data Provision

4. In the Type field, select > Epics/Balance-Local

5. Edit the desired data:
Element Description

Debug mode If active, then the local controller creates log-files. Detailed log-files are
created in the subfolder Epics_Log of the directory of the inpx-file. This
significantly increases runtime.

All other elements Please refer to help on Fixed Time control.

6. Click on Edit Signal Control.

The SC Editor opens.

© PTV Planung Transport Verkehr GmbH 36

PTV Balance Manual EN Data Provision

3.3.1.1 Signal groups

As required for any stage based fixed time control modelled with Vissig.

3.3.1.2 Intergreen matrices

As required for any stage based fixed time control modelled with Vissig.

3.3.1.3 Stages
As required for any stage based fixed time control modelled with Vissig.

3.3.1.4 Stage assignments

As required for any stage based fixed time control modelled with Vissig.

3.3.1.5 Stage sequence editing

As required for any stage based fixed time control modelled with Vissig.

3.3.1.6 Signal programs

As required for any stage based fixed time control modelled with Vissig.
Additionally, PTV Balance requires the provision of signal program and stage dependent
parameters that define priorities and constraints for the optimization.

Overview of signal program parameters

PTV Balance has parameters concerning time and duration constraints of stages and
allowed interstages. These parameters are signal program dependent and are set to

© PTV Planung Transport Verkehr GmbH 37

PTV Balance Manual EN Data Provision

default values during the automatic creation. Some of the default values are derived from
the fixed-time signal program (e.g. original start of an interstage).
These parameters govern the optimization function of PTV Balance.
Hint: Every parameter for PTV Balance comes with a tooltip providing an explanation of its
meaning. In addition, there are numerous plausibility checks with explanations.

When you have the license for PTV Balance and PTV Epics and you want to use only PTV
Balance, then activate EPICS parameters → BALANCE fixed-time control to force PTV
Epics to follow the results of PTV Balance exactly.

Setting signal program interstage parameters

1. Select a stage-based signal program on the signal programs list.
2. Expand the Navigator.
3. Select BALANCE parameters.

4. Make the desired changes of the Interstage parameters

Element Description

Interstage Interstage can be added, removed and changed (see hint).

Earliest Start Cycle second [s] defining the earliest possible start of the
corresponding interstage.

Original Start Cycle second [s] defining the original start, typically as defined by the
underlying fixed time signal program, of the corresponding interstage.

Latest End Cycle second [s] defining the latest possible start of the corresponding
interstage.

Notes Free text.

© PTV Planung Transport Verkehr GmbH 38

PTV Balance Manual EN Data Provision

Hint: The interstages of PTV Balance and the underlying fixed time signal program may
be different.

This is mainly of concern for real-word data provision, where the underlying fixed time
signal program may be used as a fallback by the local controller. As a fallback option the
underlying fixed time signal program must use all stages even e.g. non-regular PuT
prioritization stages. Specifically, these non-regular stages are not useful to be considered
in the optimization of PTV Balance.

The PTV Balance interstages are set according to a newly created underlying fixed time
signal program but can be changed manually.

Adding an interstage of a signal program

1. In the Interstage-parameters table, right-click on any table cell.
2. From the context menu, choose Add and select the interstage. The interstage must
be previously created for it to appear as an option.

Removing an interstage of a signal program

1. In the table, right-click the desired row.
2. From the context menu, choose the entry Delete.

Resetting interstage parameters of a signal program

1. In any table right-click the desired cell or column.
2. From the context menu, choose either Reset values of table or Reset values of
column ... This reset either the whole table or the corresponding column to the
default values.

Setting signal program signal-group conditions

1. Select a stage-based signal program on the signal programs list.
2. Expand the Navigator.
3. Select BALANCE parameters.
4. Make the desired changes of the Signal-group conditions
Element Description

Signal Group Nr. Non-editable as defined in signal groups.

Signal Group Name Non-editable as defined in signal groups.

Minimum Green The minimum length of the corresponding signal group [s].

Maximum Green The maximum length of the corresponding signal group [s].

Weight The weight reflects the importance of the signal group for the objective
function of PTV Balance.
Of specific concern is the relation of the weights of the different signal
groups. If you want to put specific emphasis on a direction of interest or
if you experience queues in front of a specific signal group, increase
this weight in relation to the other signal groups.

Notes Free text.

© PTV Planung Transport Verkehr GmbH 39

PTV Balance Manual EN Data Provision

3.3.1.7 Interstages
As required for any stage based fixed time control modelled with Vissig.

3.3.1.8 Daily signal program lists

Optional, but as required for any stage based fixed time control modelled with Vissig.

3.3.2 Global Parameters

Global parameters are set by a signal control of the type Balance-Central. This signal
control is not associated with any signal groups or signal heads. It is a virtual signal control,
which represents the core of PTV Balance. There must be only one instance of such a
signal control.
1. From the Signal Control menu, choose → Signal Controllers.
The Signal Controller list opens.
2. Right-click the entry of your choice.
3. From the shortcut menu, choose Edit or Add.
The Signal Control window opens.

4. In the Type field, select → Balance-Central

5. Edit the desired data:

© PTV Planung Transport Verkehr GmbH 40

PTV Balance Manual EN Data Provision

Element Description

Network Data : The anm-file describing the network.

Demand Data: The anmroutes-file describing the demand.

Debug mode If active, then PTV Balance creates log files (see chapter 4.1.2). The
level of detail of the log files can be set in the Balance-Central Editor.
This influences the number of produced log files. This increases runtime.

All other elements Please refer to help on Fixed Time control.

6. Click on Parameters
The Balance-Central Editor opens.

7. Edit the desired data.

Categories group the parameters.
The bottom of the figure displays a short description of the currently selected
parameter.

© PTV Planung Transport Verkehr GmbH 41

PTV Balance Manual EN Simulation, Calibration and Operation

4 Simulation, Calibration and Operation

Testing the efficiency of an adaptive signal control like PTV Balance is nearly impossible
without a modern simulation environment like PTV Vissim. It is the only way to check
whether all parameters are chosen and calibrated well and if all detectors are correctly
defined.
On the other hand, simulation is never 100 percent exact. Therefore, going from simulated
network to real-world road network must be done with care, at least for some approaches
recalibration might be necessary .

4.1 Simulation with PTV Vissim

4.1.1 Data Provision

The microscopic traffic flow simulation PTV Vissim provides the possibility to test PTV
Balance without access to any online system. PTV Vissim uses the same import/input
format for network and demand data as PTV Balance providing a quick setup-test
environment. PTV Visum, PTV Vissim and PTV Balance all share signal control related
data through the sig-data model.
PTV Visum and PTV Vissim are the recommended way for data provision and calibration.
See chapter 3.1 for guidelines on how to set up a PTV Balance project with the PTV Vision
suite.

Figure 14: Network in PTV Visum

© PTV Planung Transport Verkehr GmbH 42

PTV Balance Manual EN Simulation, Calibration and Operation

Figure 15: Network in PTV Vissim using anm-export and import functionalities

4.1.2 Display of Additional Data in Signal Times Window

You can show the current signal states and detector states during a simulation or during
interactive tests of signal control logic in a window. In there, the green times, yellow times
and red times are represented graphically along a horizontal time axis for each selected
signal control.
For details on the standard attributes and configuring the signal times window please refer
to the Vissim user manual (PTV GmbH 2022a).
PTV Balance allows you to show the additional attributes described below.

Result of evaluation of signal times tables and additional PTV Balance attributes
If you select Evaluation → Window → Signal times Table, a window opens where all
created signal controllers appear, out of these each selected signal control is shown in a
separated window during a simulation or a test run of the signal times table.
The colours indicate the current state of the respective signal group. The state of the current
time step is represented at the right edge of the window.

Figure 16: Signal Times Table representation in PTV Vissim

© PTV Planung Transport Verkehr GmbH 43

PTV Balance Manual EN Simulation, Calibration and Operation

If the signal times table also contains PTV Balance frame signal plan BAL-FSP, the colours
indicate the desired signal state of PTV Balance. BAL-FSP does only differ red and green
states and it is subject to the local control whether the frame signal plan is respected or
not.
If the signal times table also contains PTV Balance queues BAL-Qu, the colours indicate
the queue state of the PTV Balance simulation model.
Queue colour Description of the queue state

nothing No queue

black line 1-3 vehicles in queue

black frame 4-6 vehicles in queue

black line and black frame 7-8 vehicles in queue

solid black >8 vehicles in queue

Hint: These attributes are not available before PTV Balance calculated an actual
optimization. On the first call to PTV Balance, the network is empty, detectors have not yet
delivered any data and therefore this initial call does not yield optimization results.

4.1.3 Evaluation of Additional Data in Signal Control Detector

Record
You can use the SC detector record to check control logic of external control procedures.
For each SC, you can show a freely configurable, precise record of the SC values and
detector values as well as internal parameters of the control procedure.
For details on the standard attributes and configuring the signal control detector record
please refer to the Vissim user manual (PTV GmbH 2022a).
PTV Balance allows you to show the additional attributes described below.

Result of the SC detector record evaluation, additional PTV Balance attributes

Value type Meaning

BAL-FSP PTV Balance Frame Signal Plan

BAL-FSP does only differ red and green states and it is subject to the local
control whether the frame signal plan is respected or not.
State of frame signal plan:
 . red
 I green

BAL-Qu PTV Balance Queue

Bal-Qu indicates the queue state of the PTV Balance simulation model:
 0-9 vehicles in the queue
 X more than 9 vehicles in the queue

© PTV Planung Transport Verkehr GmbH 44

PTV Balance Manual EN PTV Balance and Epics Graphical user interface

Hint: These attributes are not available before PTV Balance calculated an actual
optimization. On the first call to PTV Balance, the network is empty, detectors have not
yet delivered any data and therefore this initial call does not yield optimization results but
shows the road network in grey.

5 PTV Balance and Epics Graphical user interface

PTV Balance and PTV Epics are distributed with PTV Vissim and their own data
visualization tool “PTV Balance and Epics network view”. This tool is browser-based and
shows the results of PTV Balance and some information of PTV Epics and many internal
data, it is a useful tool for understanding and calibrating PTV Balance, and can also be
used for real-world deployments. It opens automatically when a simulation is started in
Vissim which contains a signal controller of type “Balance central” that has activated the
check box “debug mode“ in its signal controller parameters.

Figure 17: Graphical User Interphase with PTV Balance and PTV Epics control

Right after the start of the simulation the Balance GUI can only show the network, but after
the first optimization run it shows the results of the Balance calculation for each link,
controller and signal. The GUI is mouse sensitive and shows the data of the object under
the mouse cursor. The button in the right upper corner allows to lay an Open Street Map
under the network, if the coordinates fit. The button below allows to change the language.

© PTV Planung Transport Verkehr GmbH 45

 PTV Balance Manual EN PTV Balance and Epics Graphical user interface

Calculation results
for object at
mouse position
Summary of
optimization run
Color
explanation for
object at
mouse position

Visualize the
Choose what to performance index
display on the and choose past
map optimization runs

Figure 18: Detailed functionalities of the Graphical User Interphase

Clicking on a signal group will display the flow profile that Balance calculated for this
signal: For each second in the cycle, it displays:
1. If it is green or red
2. When red, it shows the number of cars
waiting at the stop line
3. When green, it shows the number of cars
passing through the stop line
This allows to check the quality of coordination
as Balance calculated and compare this with the
Vissim “reality”.
The example to the left shows a signal group
with a queue length of 10 cars in total at the
beginning of green. These vehicles have passed
the stop line after 10 seconds of green. Then
there is a gap of 10 seconds. Finally, a platoon
arrives from the upstream intersection and
passes the stop line. Most cars arrive after 20
seconds of red time.
Clicking on an intersection (represented by a
square on the overall view) allows to see the
frame signal plan that Balance calculated as
Figure
Figure
4: Signal
19: Signal
group-based
group-based
Flow Flow
profileprofile
optimal.

5.1 Green wave diagram

The graphical user interface allows to view coordination diagrams, so-called green waves.
These diagrams show how the cars would be able to move through the network on pre-
configured routes.

© PTV Planung Transport Verkehr GmbH 46

PTV Balance Manual EN PTV Balance and Epics Graphical user interface

Figure 20: Green wave diagram

You can view these diagrams by clicking on “route” objects in the user interface. They are
visualized by semi-transparent link objects to the right of the normal links, see Figure 20.

Figure 21: Routes in the user interface

Balance calculates the green wave diagrams when it optimizes, so it’s not possible to
change them dynamically. You define these routes in a text file, which must have the

© PTV Planung Transport Verkehr GmbH 47

PTV Balance Manual EN PTV Balance and Epics Graphical user interface

name “Routes.conf” and reside in the folder with the anm- and anmroutes-files. The
format of this file is as follows.

“Name-of-route”, <ctrlId>-<signalId>, <ctrlId>-<signalId>, ….

Here “ctrlId” is the number of the controller, and “signalId” is the port number of the signal
group, as defined in the Vissig-supply. An example is in Figure 22.

"Group-1_S-N_Expressway", 11-6, 12-6, 13-5, 14-5

"Group-1_SE-N_Urban", 4-2, 5-4, 6-3, 3-3
"Group-1_N-S_Expressway, 14-2, 13-1, 12-2, 11-2
"Group-1_N-S_Urban", 3-2, 6-1, 5-2, 4-3
"Group-1_5-12", 5-1, 12-8

Figure 22: Example for file Routes.conf

5.2 Evaluations for aggregated data

Balance runs continously over the day every 5 minutes. In order to assess the quality of
optimization and see its effects, there is now to possibility to do an ongoing evaluation of
green time shifts and saturations for all intersections and signals. You can enable this
feature by setting the variable START_PYTHON_EVALUATION in Balance.ini to “true”.
This will run an evaluation of the log file “Balance_signals_log.txt” every 5 minutes and
present the results in the graphical user interface. You can also find the generated images
in the log folder, subfolder “Analysis results”. There are results for the whole group and
results for each intersection.

5.2.1 Results for the coordination group

The group results can be visualized from the lower left corner of the overall results tab.

Figure 23: coordination group results

Clicking on one of the small images gives you evaluations for the whole group at once.

© PTV Planung Transport Verkehr GmbH 48

PTV Balance Manual EN PTV Balance and Epics Graphical user interface

5.2.1.1 Saturation of controllers (Figure 24).

This shows box plots for the saturations of all signals in your coordination group. You can
find evidenz here if the calibration parameter “Saturation flow rate” for this signal is not well
adjusted to reality. Figure 25 gives an overview of box plots in general.

Figure 24: Box plots for saturation of controllers

Box plots
1. Minimum : the lowest data point excluding any outliers.
2. Maximum : the largest data point excluding any outliers.
3. Median (Q2 / 50th Percentile) : the middle value of the dataset.
4. First quartile (Q1 / 25th Percentile) : also known as the lower quartile q (0.25), is the median of
n
the lower half of the dataset.
5. Third quartile (Q3 / 75th Percentile) : also known as the upper quartile q (0.75), is the median of
n
the upper half of the dataset .
Figure 25: Explanation of Box plots
© PTV Planung Transport Verkehr GmbH 49
PTV Balance Manual EN PTV Balance and Epics Graphical user interface

5.2.1.2 Green time of controllers

This shows how the green times are changing for each controller and signal group in the
coordination group over the day.

Figure 26: Green time of controllers in coordination group

5.2.1.3 Green time difference of controllers

This shows box plots of the differences of the green times that Balance calculated for each
signal group, in comparison to the green times of the fixed time plans as detailed in Vissig.
The chart allows to evaluate how far Balance deviates from the fixed time plans.

© PTV Planung Transport Verkehr GmbH 50

PTV Balance Manual EN PTV Balance and Epics Graphical user interface

Figure 27: Green time difference of controllers

5.2.2 Evaluation results for each controller

Clicking on a node in the user interface shows
a panel with the signal plan as optimized by
PTV Balance. In the lower half of this panel
you find a small diagram which reads
“Saturation of signal groups” (Figure 28).
Clicking on it will present you a diagram that
contains at once the saturations (expressed
as “current traffic flow divided by capacity”)
and the green times for all signal groups and
lanes of this link. The content of the diagrams
is explained in Figure 29.
Figure 28: Diagram for saturation of signal
groups

© PTV Planung Transport Verkehr GmbH 51

PTV Balance Manual EN Log Files

Figure 29: Saturation of signals explanation

6 Log Files
PTV Balance provides several log files. These contain warnings, errors and results of the
simulation. The log files are an important tool to identify errors in the data provision process
and for calibration.
The level of detail of the log files can be set in the Balance-Central editor. This influences
the number of produced log files which are created in the subfolder of the directory of the
inpx-file. The folder has the name of the anmroutes file with suffix BAL_Log.
PTV Balance creates a new log file for every calendar day and appends information to
existing log files for every optimization. Most log files provide a short explanation of its
content and their first two columns display the current time and simulation time.
PTV Balance creates numerous log files of the following schemes and types:
 Balance_LOGTYPE_YYYY-MM-DD_log.txt

 LOGTYPE identifies the type of the log file. The most important types are described
below.
 YYYY-MM-DD represents the current day.

 Genetic algorithm files (sav files and last files)

These are used internally to manage the genetic algorithm.

© PTV Planung Transport Verkehr GmbH 52

PTV Balance Manual EN Log Files

6.1 Balance_output_YYYY-MM-DD.log.txt
It is the main log file, including error messages, warnings and information of the initialization
and the optimization.
The first two columns display the time stamp and the log level. The third column denotes
the Balance group that created the message, followed by the message text. A log level of
5 indicates an error and usually prevents an optimization. Messages of log level 4 indicate
a warning and usually do not prevent an optimization but impact the achievable quality of
the results.

6.2 Bxx_summary_YYYY-MM-DD-log.txt
This file provides an aggregated summary of every optimization run for group Bxx (with xx
being the group number). The summary is divided in the following parts:
 Optimization
Static information about the optimization algorithm and parameters.
Dynamic information about the achieved results and the reason for termination of the
optimization.
 Signal control
Overview of all signal controllers, active signal program, cycle time and saturation of
every signal controller. The latter helps to identify critical spots for calibration.
 Input data
Number of known and active detectors. When PTV Balance is used in combination
with PTV Vissim, these numbers should be identical.
 Traffic state
The top ten least and most saturated signal groups. The latter helps to identify critical
spots for calibration.
 OD estimation
The top nine signals with the biggest deviation between measured and modelled traffic
flows. Helps to identify critical spots for calibration.

6.3 Balance_signals_YYYY-MM-DD-log.txt
An important file for the calibration is the file Balance_signals_YYYY-MM-DD-log.txt. This
file shows the internal state of PTV Balance’s microscopic traffic model.
Column header Description

Time Current time [hh:mm:ss]

Simulation time Current simulation time [hh:mm:ss]

Group Number of the traffic control group

SPR Active signal program

LSA Unique ID of the traffic light system

FVSGR Signal group name

© PTV Planung Transport Verkehr GmbH 53

PTV Balance Manual EN Log Files

Column header Description

Link Unique ID of this object type

LinkGisID Unique ID of this object type

Lanes Number of lanes

Tgr [s] Green time demanded by PTV Balance, based on the latest T-Times

OrigTgr Original green time as set on the signal program

TgrMin The minimum value for the green time as supplied in Vissig

TgrMax The maximum value for the green time as supplied in Vissig

Cycle Time Length of cycle [s]

GreenStart The start of green time in the cycle

GreenEnd The end of green time in the cycle

Q[veh/h] Measured traffic volume

Qmod [veh/h] Traffic volume calculated by the traffic model

QAdded [veh/h] Additional flow according to green time of last optimization interval. See
parameter RECTIFY_LINKLOAD_ESTIMATION

Queue length [veh] Mean queue length

Queue lengthDet [veh] Mean queue length from the deterministic model

Queue lengthSto (KiHo) [veh] Mean queue length from the stochastic Kimber/Hollies model

Residual queue [veh] Added queue from Kimber/Hollies model to deterministic traffic model. See
parameter USE_RESIDUAL_QUEUES

Delay [s/tInt] Total delay during the calculation interval of the objective function

Delay [s/veh] Mean delay per vehicle

DelayDet [s/veh] Mean delay per vehicle from the deterministic model

DelaySto (KiHo) [s/veh] Mean delay per vehicle from the stochastic model

Saturation [-] Saturation of the signal group

MaxCap [veh/h] Maximum capacity of the lane

NumberStops [/TCyc] Number of stops during a cycle time

ShareStopingVeh [-] Share of the stopping vehicles

PI(SGrelated) Performance index of the objective function, related to the signal group

Average speed [km/h] Average speed [km/h]

LOS Level of Service

OffsetOpt 0 if no optimisation of the offset was done for this group, 1 otherwise

TargetLinks Unique ID of the destination link related to that sg

FixedTime 1 if these results are for the fixed time values (and not for the optimized
ones), 0 if not. Fixed-time values are only written when the Debug-level is 1.

PI Overall performance index

Dets The port numbers of the detectors that are feeding this signal group

© PTV Planung Transport Verkehr GmbH 54

PTV Balance Manual EN Calibration

7 Calibration

7.1 General information

In order to calibrate PTV Balance it is necessary to know the determining factors and their
effects. If the data provision is correct, the following parameters allow improving the
performance of PTV Balance:
 Saturation flows of the edges and turning movements:
Saturation flows of the edges are a major factor in the calculation of delay. Saturation
flows represent the capacity of a link or turn considering HGV share, turning ratio,
width, steepness etc. but not green shares of a signal control. The anm file defines
saturation flows for links and turns and can be changed using PTV Visum. For
calibration purposes, one must consider that in general the real saturation flow is
unknown. Therefore, careful deliberation and ideally measurements are helpful,
especially for turning movements.
 Weights for waiting time, queue length and number of steps for every signal group:
Weights are used in the objective function of PTV Balance (chapter 2.1.4). Specific
local circumstances or objectives to emphasize specific directions within the
optimization are modelled with these weights. In order to get effects from the change
of weights at an intersection, all signal groups and the scale of their effects must be
considered.

7.2 Guideline for Calibration

In order to assist the calibration process, the following chapters provide an outline of a
structured approach. In general, calibration is an iterative process and it is advised not to
apply many changes at once.

7.3 Simulation without optimization

Generally, there should always be a with- and without-comparison. The simulation runs
should always be started with different random seeds and at least 5 repetitions to guarantee
a solid data base with different traffic situations for assessment.
Bigger traffic related changes like morning-, off- or evening-peak should be simulated in
different scenarios. The signal programs can be analysed separately, because usually
different signal programs are used during the different scenarios.

7.4 Simulation with optimization

At the beginning, the simulation with optimization is not processed with different simulation
random seeds until a useful result is achieved. A soon as a positive result is achieved with
a certain random seed, simulation runs with other random seeds can be tested.
Because PTV Balance is a network control, delay, travel times and numbers of stops of the
whole network should also be observed and evaluated during any simulation run. The traffic

© PTV Planung Transport Verkehr GmbH 55

PTV Balance Manual EN Calibration

parameters which should be captured during the simulation are varying according to the
control objectives. Because there is a vast amount of possibilities for the analysis of those
data offered in the simulation, almost every objective of the control can be achieved with
these analysing methods. The analysis can be generated and visualized by PTV Vissim
and can be used for evaluation of the network control. Depending on the objective of the
control, it may also be useful to analyse certain edge sections apart from the others using
additional parameters which can be integrated into the calibration.

7.5 Observing the simulation

PTV Vissim offers many parameters for evaluation of the network´s control performance.
However, one should not only rely on these parameters, but also observe the simulation
visually, as it is possible that the overall results are improving due to a queue on one of the
entrances of the network. In conclusion, if less vehicles drive into the road network, the
overall result gets better. If there are errors in the data provision or the optimization, the
reason can be easily located by observing the simulation in a heavily congested network.

7.6 Analysing log Files

For details on content of the log files please refer to chapter 4.1.2.

Balance_output_YYYY-MM-DD.log.txt
The main log file must be checked for messages of log level 4 and 5 that either negatively
affect or prevent an optimization.

Balance_signals_YYYY-MM-DD-log.txt
The values for traffic volume, demanded green time, delay, queue length and number of
stops should be compared to the values which have been calculated in the simulation. If
there are significant differences, check the data provision. If the traffic volume is also
plausible, the actual calibration can be started.

Bxx_summary_YYYY-MM-DD-log.txt
The summary of every optimization allows for a quick identification of critical spots.
Signal controllers and signal groups with the highest saturation should be examined in the
simulation. If the behaviour of the simulation is plausible then these are the most promising
locations to focus the calibration.
Large deviations between measured and modelled vehicle flows indicate either potential
errors in detector data provision (wrong location or vehicles not travelling over a detector)
or a low quality of the provided demand matrix.

7.7 Result evaluation

Result evaluation depends on the objective. PTV Vissim provides various possibilities to
measure global indicators (e.g. total delay time) or to focus on more specific indicators (e.g.
delay time for public transport busses, pedestrians or travel times along a specific

© PTV Planung Transport Verkehr GmbH 56

PTV Balance Manual EN The initialisation file Balance.ini

direction). Suitable indicators must be defined and observed to evaluate changes in the
optimization parameters.

7.8 Tweaking calibration parameters

The following circumstances require special attention:
 Mixed lanes
Tweaking saturation flows of edges is especially important if there are right turning
vehicles and straight driving vehicles on the same lane. If the right turning vehicles
progress independent of the straight turn, an estimation of the saturation traffic volume
is difficult. If PTV Balance estimates waiting times significantly different from the
simulation this indicates the need to adjust saturation flows.
 Left turns
Left turns with separate short lanes that are signalized in separate stages can block
the straight turns and thus deserve special attention.
 If single directions of the signal groups are estimated wrong, it is recommended to
change the weight of the waiting time in order to perform a specific adaptation of the
signal group respective to their direction. It is important to consider the scale of the
other weights of this intersection.
 If coordination is one of the most important objectives, the weight for number of stops
should be changed at the respective signal groups. Every intersection should be
checked one by one considering the objectives, and the weights should be changed
accordingly. This is an iterative process because changes at a single intersection can
have effects on the whole network.

8 The initialisation file Balance.ini

The initialisation file contains parameters that change the overall behavior of Balance, set
the log-level and much more. The parameters are read before each run of the optimization,
so you don’t usually need to restart Balance after a change. This is only required when you
set parameters that change the network, because Balance reads the whole network supply
(anm- and anmroutes-file and/or sig-files) just once at startup. The file has parameters
divided by sections, where each section is set in square brackets at the start - [Global].
This file is common to all Balance coordination groups, but if you want to set parameters
different for each group, you can do so by adding a section [Bxx] with xx the number of the
group and setting the parameter there – it will override the global one.

8.1 Section Global

START_INTERVAL: Determines after how many seconds Balance runs the optimization. Should be a
multiple of 60 seconds. Typically 300 seconds.
FLOWINPUT_SYSTEM: If set to true, Balance expects link flow values from PTV Optima or other
systems.
FLOW_INPUT: For testing purposes, assign a fixed flow value (in veh/h) to each lane. Only active when
FLOWINPUT_SYSTEM=True

© PTV Planung Transport Verkehr GmbH 57

PTV Balance Manual EN The initialisation file Balance.ini

USE_DEZ_INPUT: If set to false, Balance will not use any detector values. This is only useful when
Balance gets flow input values from a superordinated system like PTV Optima.
STATIC_SPR: Use this number as the running signal program regardless of other data. Set to -1 to use
real data!
REQUEST_INTERVAL: determines the maximum age of detector values in [s] that Balance uses
COORDINATION_GROUP: the number of the coordination group that Balance should optimize as
defined by Visum in the ANM file. -2: optimizes all Controllers
CROP_CONTROLGROUP_LINKS: delete links from Balance network that are not necessary
MAXDISTCOORDNODES: when deleting links from the network, in which distance should nodes be
considered neighbour (nodes further away from other neighbours might be considered isolated by
Balance
FRIDAY_IS_WEEKEND: This parameter defines if the weekend is considered Friday and Saturday (true)
or Saturday and Sunday (false)

8.2 Section Signal Control

LSA_NOT_ACTIVE: Comma-separated list of controller ids that will not be used and optimized by
Balance
LSA_FIXED: Comma-separated list of controller ids that will be treated as fixed by Balance
DET_NOT_ACTIVE: comma-separated list of detector ids that will not be used by Balance. Detector id
is 1000*controllerid+channel number, e.g. 123001 for detector 1 at controller 123

8.3 Section Logging

PRODLOGFILE_LEVEL: Determines the number and kind of log messages and status files that Balance
produces (lower values results in more log messages, between 1 and 6)
START_PYTHON_EVALUATION: start after each optimization run a python evaluation script that
checks the signals-log and prints charts with saturation and green times
LANGUAGE: can be set to DEU (German), ENG (English) or POL (Polish)

8.4 Section Traffic model

MEAS_ACCEPT: Skips optimization if share of detectors delivering flows is lower than this value [%]. If
set to 0, Balance will run even if there are no detector values.
TRAFFICMODEL_ITER: Number of OD estimation and traffic assignment iterations (outer loop of OD
estimation)
VANZUYLEN_ITER: Number of OD estimation iterations in the Van-Zuylen/Willumsen algorithm
IDENTITY_MATRIX: Use uniform matrix as starting value for OD-estimation (one car/h from each
entry to each exit)
KIMBERHOLLIS_ALGORITHM: Use the algorithm by Kimber and Hollis to react on high saturation
levels by adding stochastic delay and queue
PLATOON_DISPERSION_ALGORITHM: Disperse car platoons over time
RECTIFY_LINKLOAD_ESTIMATION: Uses the last measured flow in comparison to the last calculated
green time to adjust the start queue lengths

© PTV Planung Transport Verkehr GmbH 58

PTV Balance Manual EN The initialisation file Balance.ini

8.5 Section Program choice

ENABLE_PROGRAMCHOICE: Allow Balance to choose the signal program with the cycle length best
fitted to the traffic demand
DESIREDSATURATIONLONGER: Level of saturation that should be reached before changing into a
longer cycle time [0.9]
DESIREDSATURATIONSHORTER: Level of saturation before a change to a shorter cycle time is
considered [0.6]
MAXALLOWEDCYCLETIME: Maximum cycle time that Balance may consider [300]
MINREPETITIONSDOWNCYCLE: Number of times a change to a shorter cycle time was proposed
before it is actually done [3]
MINREPETITIONSUPCYCLE: Number of times a change to a longer cycle time was proposed before it is
actually done [2]
PC_DISABLED_WEEKDAY: Disable the program choice on weekdays. Time intervals for disabling are
given as hh:mm-hh:mm separated by commas. E.g. 07:30-9:30, 16-19
PC_DISABLED_WEEKEND: Disable the program choice on weekends. Time intervals for disabling are
given as hh:mm-hh:mm separated by commas. E.g. 07:30-9:30, 16-19
PC_FALLBACK_PROGRAM: if the program choice should not run in this time interval, this program is
chosen instead.

There are also parameters that define values for each day, PC_DISABLED_MONDAY and
so on.

8.6 Section Optimization

MAX_OPT_LOCAL: Number of local optimization iterations (default: 10) for hill-climbing algorithm
MAX_OPT_GLOBAL: Number of global optimization iterations for hill-climbing algorithm(default: 10)
MASTER_WEIGHT_STOPS: this value is multiplied to all weights on number of stops (default: 1)
MASTER_WEIGHT_QUEUE: this value is multiplied to all queue length weights (default: 1)
MASTER_WEIGHT_DELAY: this value is multiplied to all delay weights (default: 1)
THRESHOLD_MIN_PERFORMANCE_IMPROVEMENT: if the relative improvement after the last
optimization loop is smaller than this value, optimization is stopped (hill-climbing Algorithm). Default:
0.01 [0-1]
USES_GENETIC_ALGORITHM: if value is true, Balance uses the genetic algorithm for optimization. If
not, it uses the hill-climbing algorithm

8.7 Section Time Conditions

ORIGINAL_T_CONDS: use only the original interstage starting times if true. This disables the
optimization and sets Balance to send only the fixed time plans from the Vissig supply. Usually used
during calibration process.

8.8 Section GUI

WEB_PORT: The port number (standard: 8000) that the GUI Web page will use on this
computer to show the Balance calculation results.
START_WEBSERVER: Defines if Balance should start the web server. Should be set to true.

© PTV Planung Transport Verkehr GmbH 59

PTV Balance Manual EN

© PTV Planung Transport Verkehr GmbH 60

PTV Balance Manual EN Literature

9 Literature
Braun, R. (2008). Ein echtzeitfähiger Evolutionärer Algorithmus zur netzweiten
Optimierung der Lichtsignalsteuerung. München: Dissertation am Lehrstuhl für
Verkehrstechnik, Technische Universität München.
Braun, R., Kemper, C. (2008). GALOP-Online – ein Genetischer Algorithmus zur
netzweiten Online-Optimierung der Lichtsignalsteuerung. Forschungsgesellschaft für
Straßen- und Verkehrswesen, HEUREKA '08, Optimierung in Verkehr und Transport -
Tagungsband . Köln: FGSV Verlag, ISBN 978-3-939715-48-1.
Domschke, W., Drexl, A. (1998). Einführung in Operations Research. Berlin: Springer, 4.
Auflage.
Domschke, W., Klein, R., Scholl, A. (1996). Taktische Tabus, Tabu -Search - Durch
Verbote schneller optimieren. c`t - Magazin für Computertechnik, Heft 12/1996, S.326-332.
Forschungsgesellschaft für Straßen- und Verkehrswesen (2009). Handbuch für die
Bemessung von Straßenverkehrsanlagen. Köln.
Friedrich, B., Mertz, J. (1996). Abschlußbericht Munich COMFORT Arbeitsbereich 444,
Städtische Verkehrssteuerung. München: Fachgebiet Verkehrstechnik und
Verkehrsplanung, TU-München.
Friedrich, B., Mertz, J., Ernhofer, O., Clark, M., Toomey, C., McLean, T., et al. (1998).
TABASCO Deliverable 9.4: Urban Traffic Control with PT Priority: Final Evaluation Report.
Brüssel.
Gevas software Systementwicklung und Verkehrinformatik GmbH (2010a). TRENDS,
Version 5.0, Benutzerhandbuch. München.
Gevas software Systementwicklung und Verkehrsinformatik GmbH (2010b).
openTRELAN, Version 5.0, Benutzerhandbuch. München.
Gevas software Systementwicklung und Verkehrinformatik GmbH (2012a).
Benutzerhandbuch DRIVERS. München.
Gevas software Systementwicklung und Verkehrinformatik GmbH (2012b).
Benutzerhandbuch Nonstop. München.
Gevas software Systementwicklung und Verkehrsinformatik GmbH (2012c). Projekt Tristar,
Anforderungsspezifikation Detektorpositionierung und betriebliche Aspekte der Detektion.
München.
Hunt, P. B., Robertson, D. I., Bretherton, R. D., Winton, R. I. (1981). SCOOT, A Traffic
Responsive Method of Coordinating Signals, TRRL Report No. LR 1014. Crowthorne UK:
Transport and Road Research Laboratory.
Kimber, R. M., Hollis, E. M. (1979). Traffic Queues and delays at road junctions. TRRL
Laboratory Report 909.
Ploss, G. (1993). EIn dynamisches Verfahren zur Schätzung von Verkehrsbeziehungen
aus Querschnittszählungen. München: Fachgebiet Verkehrstechnik und Verkehrsplanung,
TU München.
PTV GmbH (2022a). PTV Vissim manual. Karlsruhe.

© PTV Planung Transport Verkehr GmbH 61

PTV Balance Manual EN Literature

PTV GmbH (2022b). PTV Visum manual. Karlsruhe.

PTV GmbH (2022c). PTV Epics manual. Karlsruhe.
Robertson, D. I. (1969). TRANSYT, A traffic Network Study Tool. TRRL Report No. LR 253
. Crowthorne, UK: Transport and Road Research Laboratory.
Van Zuylen, H. J., Branston, D. (1982). Consistant Link Flow Estimation from Traffic
Counts. Transportation Research B. Vol. 16B.

© PTV Planung Transport Verkehr GmbH 62