VAP 2.16 Interface User Manual: PTV Planung Transport Verkehr AG

VAP 2.
16 Interface
User Manual
PTV
Planung
Transport
Verkehr AG
Contents
VAP Interface 5
1 Operating Instructions 7
2 Program Language Elements 9

2.1 General Conventions 10
2.2 Operators 14
2.3 VAP Program Elements 15
2.4 Detector Functions 19
2.4.1 Detector Data Access Functions 19
2.4.2 Functions to Reset Detector Data 21
2.4.3 Test Functions for Public Transport Telegrams 21
2.5 Signal Group Functions 23
2.6 Stages, Interstages, Partial Stages and Partial Interstages 26
2.6.1 Functions for Stages and Interstages 26
2.6.2 Functions for Partial Stages and Partial Interstages 28
2.7 Other Functions 30
2.8 Overview of all VAP-Functions and Commands 33
3 Error Handling 37
4 Interstage Description (*.PUA file) 39
VAP 2.16 Interface © PTV AG 2007 3

VAP Interface
VAP (vehicle actuated programming) is an optional add-on module of

VISSIM for the simulation of programmable, phase or stage based, traffic
actuated signal controls. The control logic is described in a text file using a
simple programming language. During VISSIM simulation runs or in the test
mode, VAP interprets the control logic commands and creates the signal
control commands for the VISSIM network. At the same time, various
detector variables reflecting the current traffic situation are retrieved from the
simulation and processed in the logic.

1 Operating Instructions
The following section describes the minimum requirements for using the VAP
signal control module, how to start the program, and the operating
instructions.
Hard- and Software requirements

► VISSIM Version 4.30 (or higher) must be installed on a PC.
► The files VAP216.DLL and VAP216.WTT have to be installed in the
same directory as the VISSIM executable or in the same directory as the
VISSIM network file (*.INP).
VAP signal controllers in VISSIM

Within VISSIM an existing signal control logic can be set to VAP type using
the menu command sequence SIGNAL CONTROL - EDIT CONTROLLERS. From
the Type listbox choose ‘VAP’. To specify the corresponding files, select the
CONTROLLER (VAP) tab page. The program file needs to be set to
VAP216.DLL. Furthermore a logic file (*.VAP) and a file containing signal
and interstage definitions (*.PUA) need to be selected.
A new VAP SC can be created in the same way as described above by right
clicking in the listbox of existing controllers and selecting NEW. Additionally,
the signal groups, signal heads and detectors need to be defined.
Execution of VAP
During a VISSIM simulation run the VAP logic is usually called once at the
end of each simulation second after the vehicles have been moved. If the
simulation resolution is more than one time step per simulation second, the
controller frequency for VAP can be set to a higher value (1..10) as well
through the VAP declaration VAP_Frequency in the *.vap file. The controller
frequency needs to be an integer factor of the simulation resolution, i.e. the
length of the controller time step needs to be a multiple of the length of a
simulation time step.
Usually the entire program is executed, even when an interstage is running.
This allows detector values to be collected and evaluated during an active
interstage. As an exception, program execution waits at a WAIT_AT-UNTIL
command until the ‘until’-expression is found to be TRUE.

2 Program Language Elements

2.1 General Conventions
Data format
The programming language VAP can process integer and real numbers. The
type conversion is handled internally and therefore invisible to the user. In
the program both data types are converted to double floating point numbers.
The integer number range is limited to the values -2,147,483,639 to
2,147,483,639. Larger integer numbers can only be processed as real
numbers by adding “.0” at the end. Real numbers are stored in the usual 64
bit floating point format. If a variable is passed to a function and the function
expects an integer number, VISSIM will check whether the variable’s decimal
value is zero and if the variable is within the valid range for integer numbers.
If one of these requirements is not met, VISSIM will send a run time error
message and cancel the simulation.
Expressions
When computing arithmetic or logical operators, the usual priority rules
apply:
► Operator precedence: please refer to chapter 2.2.
► Combinations of operators with the same priority are computed starting
from the left.
► In case a special computing sequence is desired, it must be enforced by
the appropriate parenthesis setting.
► If an expression resulting from the combination of a logical operator or a
comparison operator is true, the value of the expression is returned as 1,
otherwise as 0.
► Every expression will be completely evaluated even if the entire
expression is already determined after evaluating parts of the entire
expression (i.e. logical combinations using AND and OR).
► Operands in expressions can be variables, constants and numerical
constants as well as all functions provided by the programming
language.
► Negative expressions must always be enclosed in parentheses.
Comments
Comments must be enclosed by a pair of /* */ signs and can be placed
anywhere within the program text.
Identifiers
There is no distinction between capital and lower case letters. Therefore OK,
Ok, oK, and ok characterize the same variable and IF, If, iF, and if are
recognized as the key word if. It is recommended to keep the spelling
10 VAP 2.16 Interface © PTV AG 2007

General Conventions
convention for variables and key words consistent once it is introduced in the
program text.
Program Header
The first command of a VAP program (in a *.vap file) must consist of the
keyword PROGRAM, the name of the program (as a valid identifier) and a
semicolon.
Controller Frequency
The controller frequency of a VAP program can be defined as first
declaration below the program header. This declaration consists of the
keyword VAP_Frequency, the number of passes through the VAP logic per
simulation second and a semicolon. The controller frequency must be in the
range from 1 to 10 and it needs to be a factor of the simulation resolution
(time steps per simulation second). If this declaration is missing in a VAP
program, the default frequency 1 is used.
Constants
There are two different kinds of constants:
► System constants use the phase or signal group numbers of the phase
interstage description as identifiers and the corresponding phase or
internal VISSIM signal group numbers as their value.
► User defined constants which get a value assigned in the CONST
definition process.
Variables
Variables are automatically defined by their use or the context of their use in
the program text. A program start after compilation resets all variables to
zero. Timer variables are handled differently: Their value cannot be
changed by a regular assignment but by one of the three timer commands
START, STOP, and RESET. Once a timer variable is started, its value is
increased by the length of the controller time step (reciprocal of the controller
frequency) at the start of each pass through the logic.
User Manual © PTV AG 2007 11

Arrays (Vectors) of Variables

The current version of the VAP can process one- and two-dimensional
arrays. These arrays must be defined after the CONSTANTS definition and
before any SUBROUTINE. An array definition requires an identifier followed
by the number of array elements in square brackets. In order to assign
values to individual array elements, these values have to be set in square
brackets, separated by commas (e.g. field[3,4] = [[0, 3, 4.6, 1.23], [1.3, 4, 0,
0.1], [1, 2, 3, 4]]). If no value is assigned to an array element during the
definition, the value 0.0 will be assigned automatically. An array element
(e.g. field [1,4]) can be used anywhere instead of a regular variable. An
index must be a valid expression (e.g. field[i*j+3, field[i,j]]).
Jump labels
Every instruction can be marked with a jump label. Therefore the jump label
identifier must be directly followed (maximum of one blank space) by a colon;
otherwise, the jump label will be interpreted as a variable assignment. A
jump label is only valid within the sub-program or within the main program.
Therefore, all jump labels used in a GOTO or WAIT_AT statement have to
be defined in the range in which they are used.
For jump label identifiers the same rules apply as for variable identifiers.
The valid name range for variable identifiers is identical with the valid name
range of jump label identifiers. As a result, a variable test and a jump label
test can coexist in the same program.
Subroutines
The VAP programming language uses a SUBROUTINE concept. This is
useful for a hierarchical structuring of the control task (Top-Down-Design). It
also allows listing of multiple but identical program sequences only once
within the signal control program. In a VAP program any number of
subroutines may be defined (only limited by RAM space). Any predefined
subroutine can be called inside a program using the GOSUB command.
However, there is no form of recursion allowed. Therefore the currently
active subroutine cannot call itself. Local variables cannot be defined within a
subroutine. All variables are valid in every part of the entire program (global
variables). This feature should have no side-effect if a strict programming
discipline is maintained.
During execution a subroutine can only be ended when the end symbol “.” is
encountered. There is no explicit return command. For that reason, the
definition of a jump label for the program end symbol is allowed in order to
use the GOTO command to end subroutine execution.

General Conventions
The same principle applies for the main program. When the END command
of the program is reached program execution stops for the current controller
time step and will be restarted from its begin in the next controller time step.
Therefore all initializations at the beginning of the program which should be
executed only once have to be protected. A conditional command such as
IF NOT init THEN /*initialization*/ init:=1 END
protects the initializations and will work because all variables are initialized to
zero automatically at the start of the simulation run.
Signal Groups and Detectors

Signal groups and detectors in the VISSIM traffic network are coded as
integer numbers. In VAP the different signal groups and detectors are
referred to using these numbers as arguments in the function calls. Only
31
values within the range 1..2 (2147483648) are valid as arguments of these
functions. In addition, there are internal restrictions regarding the maximum
number of signal groups and detectors. In the current version these values
are set to 999.
Memory restrictions
There is no limitation on the number of program commands or for combined
IF-THEN-ELSE-END constructs and expressions in the programming
language. In practice, the limitation is determined by available RAM space of
the computer hardware. If too complex of an expression is to be compiled,
the compilation process is interrupted with an error message.

2.2 Operators
The following operators are available in VAP:
Operator Meaning
6 (, ) Parentheses
5 NOT logical NOT (unary)
4 AND logical AND (binary)
4 *, / Multiplication, Division
4 %, \ Modulo, integer division
3 OR logical OR (binary)
3 +, - Addition, Subtraction
(binary)
2 =, <>, <, <=, >, >= comparison
1 - sign (unary)
The operator precedence is shown in the first column starting with highest
precedence (6). Parentheses must be used for expressions with unary
operators.

VAP Program Elements
2.3 VAP Program Elements
Assignment
When using an assignment, the variable on the left side of the assignment
symbol ‘:=’ gets the value of the expression on the right side of the symbol
assigned to it.
Example:
switchSignal := 1;
The value 1 is assigned to the variable switchSignal.
GOSUB
The GOSUB command calls the specified SUBROUTINE. After executing
the subroutine, program execution continues with the next command
following the GOSUB command.
Example:
GOSUB CalcSignalState;
train := 2;
…
SUBROUTINE CalcSignalState;
maxGreen := 5;
END.
The program executes the subroutine CalcSignalState (assigning maxGreen
the value 5). Then it returns control to the next command following the
GOSUB command which is the assignment train := 2;.
GOTO
Using the command GOTO, program execution continues at the command
referenced by the jump label identifier following the jump command.
Example:
GOTO CalcSignalState;
…
CalcSignalState: maxGreen := 5;
Program execution continues at the line labeled CalcSignalState.
IF-THEN-ELSE-END
In the conditional statement IF-THEN-END or IF-THEN-ELSE-END, the
expression following the key word IF is evaluated first. If the result is other
than 0, the expression(s) following THEN will be executed. Otherwise, the
program execution will be continued either with the expressions following the
optional ELSE-clause or with the expressions following END if there is no
ELSE-clause.
Example:

IF switchSignal = 1 THEN
maxGreen := 5
ELSE
maxGreen := 10
END;
The variable maxGreen is set to 5 if the variable switchSignal has the value
1. For any other value of switchSignal the variable maxGreen is set to 10.
Timer commands
The timer commands Start, Start_at, Stop and Reset will only affect the timer
variables provided by the programming language. These timer variables are
counters which
► are activated with the commands Start (<timer>) or Start_at (<timer>,
<value>) where the command Start_at can be used to start a timer with
an initial value
► are increased by the length of the controller time step (reciprocal of the
controller frequency) before each pass through the VAP logic
► can be stopped using the command Stop (<timer>) (the timer value is
not reset)
► can be reset to zero using the command Reset (<timer>) (either in
running or stopped mode)
If a variable is used as an argument of a timer command (and therefore
implicitly becomes a timer variable), it cannot be used on the left side of an
assignment in the entire signal control program. Thus it is not allowed to
assign a value to a variable which is already used as a timer variable or to
use a variable which has been assigned a value before as an argument in a
timer command. In both cases the compilation process terminates with an
error message. The maximum number of timer variables is limited to 512.
Example:
IF noTimer = TRUE THEN
Start (gatesDown);
noTimer := FALSE
END;
…
IF gatesDown = 10 THEN
Stop (gatesDown);
Reset (gatesDown);
noTimer := TRUE
END.
If noTimer is true (or 1), the program starts the timer variable gatesDown. To
ensure that the timer is not being restarted during the next program
execution cycle, the variable noTimer is set to FALSE. Thus in the next
execution cycle the expression noTimer = TRUE evaluates to FALSE (or 0).
The timer variable is increased by 1 at the beginning of every controller time
step (assuming the default controller frequency of 1). After 10 controller time
steps (10 simulation seconds), the expression gatesDown = 10 becomes
TRUE and then the program stops the timer gatesDown and resets it to zero.

VAP Program Elements
TRACE Command
VAP includes a TRACE command which enables the user to follow and
analyze the signal control program using several different parameters. If
used in the program code, the TRACE command can create a complete
documentation of every executed command and the current value of every
variable. In addition, it can be used to analyze the signal control logic, i.e. to
write the interstage changes to a log file.
The current signal group status and times will not be logged since VISSIM
already provides this data and can display it online (i.e. in a signal timing
window). The VAP signal control program writes all data generated by the
trace command to a file with the same name as the program file and using
the extension *.TRC. This file will be written to the same directory as the
program file. If there is already an existing trace file with the same name, the
new information will be added to the end of the existing file. In certain
conditions (see above) the contents of the trace file can be displayed at
runtime using a VAP system menu command.
During a simulation, the first call of the TRACE command creates a header
line with the current date and time, and the name of the current signal control
program. Every call of the TRACE command displays the current state of the
simulation and the signal control unless this was already done during the
current controller time step. This state contains the cycle second, the
simulation second, the active phase or interstage, and the current phase
second.
In addition, the call of the TRACE command activates the appropriate trace
mode (Exception: trace(variable(<ident>))). The trace logs the simulation
state and the trace information to the trace file in every controller time step
until a NOTRACE command deactivates the trace mode or another TRACE
command switches to another trace mode. If the trace mode is active, a
separation line of ‘=’ signs will be added to the trace file at the end of every
controller time step.
The following parameters are possible for the TRACE command and create
the output described.
COMMAND Activates the trace command mode in which all executed
program commands are listed in the exact execution
sequence.
VARIABLE Activates the trace variable mode in which the value of every
variable used in the program is listed by name at the
beginning of every controller time step before the execution
of the program. Therefore, the listed values are the values at
the end of the previous controller time step. Several TRACE
(VARIABLE) commands can be place anywhere within the
program. Every single command results in a new list of the
current variable values at the time of command execution.
A variation of the VARIABLE parameter is:
variable (<var_ident_1> [, <var_ident_2>]).
This command writes the current value of one or two

variables to the trace file without activating the trace mode.

This option is especially useful if only a few variable values
should be logged.
ALL Activates the trace-all-mode, a combination of the trace-
variable- and the trace-command-mode.
The TRACE command can also be used to debug a signal control program:
1. Before entering a critical part of the program or subroutine all current
values of all variables can be logged using the command sequence
TRACE (VARIABLE); TRACE (COMMMAND). This lists also every
executed program command in the exact sequence as they are
executed.
2. When leaving the critical program part the command sequence TRACE
(VARIABLE); NOTRACE logs the current values of all variables and
deactivates the trace mode.
3. When comparing the two variable listings, the impact of the critical
program part on the variables is instantly visible. In addition, this
procedure creates a chronological listing of the executed program
commands. This listing also shows the exact evaluation sequence of
expressions by parenthesizing the sub-expressions.
The NOTRACE command deactivates the trace mode and writes a line of “+”
signs in the trace file in order to document the end of the latest trace
protocol.
Example:
trace(all);
…
notrace;
As soon as program execution reaches the TRACE(ALL) command, it
creates a trace file and logs all variables and their current values. The
program will also log every executed command to the trace file until it
reaches the NOTRACE command.
WAIT_AT-UNTIL
The WAIT_AT-UNTIL command can be used to assemble a time loop. First
the expression following UNTIL is be evaluated. If its value is zero, program
execution is interrupted for the current controller time step and will continue
in the next controller time step, repeating the evaluation of the expression
following the WAIT_AT command. Otherwise, program execution continues
with the next command.
Example:
WAIT_AT Stage1 UNTIL t_actual = T1;
First the program evaluates the (boolean) expression t_actual = T1. If the
variable t_actual does not equal the variable T1, program execution will be
interrupted at this point and continued here in the next controller time step,
first checking the expression condition again. Otherwise, program execution
continues with the following command.

Detector Functions
2.4 Detector Functions

This section describes functions to get data of detectors which reflect the
current status of the traffic simulation. All detector functions check their
argument, which can be an integer number, a constant, or a variable. The
31
value passed to the function must be within the range [1 .. 2 ]. Also, the
number needs to correspond to a VISSIM detector number in the VISSIM
network to be simulated with this VAP logic. If an argument value is used
that does not meet the above criteria, program execution stops and an error
message is displayed.
2.4.1 Detector Data Access Functions
Detection (<no>)
Returns 1 if the impulse memory of detector <no> is 1 (i.e. a vehicle front
end has been detected) or a vehicle is on the detector. Otherwise it returns
0. This is in contrast to the function Presence which does not recognize a
waiting vehicle on the detector. Using the function Detection resets the
impulse memory of the detector to zero automatically after the current pass
through the VAP logic.
Front_ends (<no>)
Returns the total number of vehicle front ends detected by detector <no>
since the last call of Clear_front_ends. To reset the contents of the internal
detector memory the function Clear_front_ends can be used.
Headway (<no>)
Returns the current time gap at the detector <no>. The returned value is 0 if
the detector is occupied at the end of the current simulation time step.
Otherwise, the returned value is the time gap in seconds since the last
occupancy of the detector.
Example:
gapOut3 := headway (DK3) >= minGap3;
The logical variable gapOut3 is set to TRUE if the headway of detector DK3
is at least as big as minGap3. Otherwise it is set to FALSE.
Headway10 (<no>)
Returns the current headway of detector <no> in tenths of a second (10
times the value of Headway (<no>))

Occup_rate (<no>)
Returns the smoothed occupancy rate of detector <no> (for more information
on smoothing see the ‘detectors’ section in the main VISSIM manual).
Occup_rate results in a value within the range [0..1]. The smoothing factors
can be adjusted individually for each detector within the VISSIM detector edit
window.
Example:
IF Occup_rate (DK1) <= 0.5 THEN
increase1 := TRUE
END;
The logical variable increase1 is set to TRUE if the occupancy rate of
detector DK1 does not exceed 0.5 (50%).
Occupancy (<no>)
Returns 0 if no vehicle is detected by detector <no> at the end of the current
simulation time step. Otherwise, the function returns the time in seconds
since the arrival of this vehicle.
Example:
Call1 := Occupancy (DK1) >= 1;
In this example the logical variable Call1 is set to 1 if detector DK1 has been
occupied for at least 1 second.
Occupancy10 (<no>)
Returns the occupancy time of detector <no> in tenths of a second (10 times
the value of Occupancy (<no>)
Presence (<no>)
Returns 1 if the impulse memory of detector <no> is 1 (i.e. a vehicle front
end has been detected). Otherwise it returns 0. This is in contrast to the
command Detection which additionally recognizes a vehicle waiting on the
detector. Using the function Presence resets the impulse memory of the
detector to zero automatically after the the current pass through the VAP
logic.
Rear_ends (<no>)
Returns the total number of vehicle rear ends detected by detector <no>
since the last call of clear_rear_ends. To reset the contents of the internal
detector memory the command Clear_rear_ends can be used.
Veh_length (<no>)
Returns the length [m] of the last vehicle that was detected by detector <no>
since the last pass through the VAP logic. If no vehicle was detected in this
time span the function returns 0.

Detector Functions
Velocity (<no>)
Returns the speed [m/s] of the last vehicle that was detected by detector
<no> since the last pass through the VAP logic. If no vehicle was detected in
this time span the function returns 0.
2.4.2 Functions to Reset Detector Data
Clear_front_ends (<no>)
Clears the number of detected vehicle front ends on detector <no>. This
command resets the contents of the internal detector counter. It is useful e.g.
after using the command Front_ends.
Clear_rear_ends (<no>)
Clears the number of detected vehicle rear ends on detector <no>. This
command resets the contents of the internal detector counter. It is useful e.g.
after using the command Rear_ends.
2.4.3 Test Functions for Public Transport Telegrams

Every VISSIM transit (Public Transport) vehicle defined on a transit route
that was assigned to send PT telegrams creates such a PT telegram upon
arrival at a Calling Point (special type of detector). This telegram is
transmitted to all(!) external signal controllers defined in the VISSIM network.
Thus the signal control logic needs to test if a PT telegram is relevant for this
controller or not.
The following list shows all available functions for retrieving information from
a PT telegram:
Tele_calling_point (<no>)
Returns the calling point number from telegram <no>
Tele_count
Returns the number of telegrams received in the current simulation time
step.
Tele_course (<no>)
Returns the course number from telegram <no>

Tele_delay (<no>)
Returns the delay in seconds from telegram <no>
Tele_line (<no>)
Returns the line number from telegram <no>
Tele_man_direction (<no>)
Returns the code for manual direction from telegram <no>
Tele_passengers (<no>)
Returns the number of passengers from telegram <no>
Tele_prio (<no>)
Returns the priority value from telegram <no>
Tele_route (<no>)
Returns the route number from telegram <no>
Tele_tram_length (<no>)
Returns the tram length from telegram <no>

Signal Group Functions
2.5 Signal Group Functions

Note: Throughout this manual and also in VISSIM the term ‘signal group’ is
used as the smallest logical unit in a signal control. The current state of a
signal group is shown through one or more signal heads all showing the
same color at the same time. A stage is compiled from a certain amount of
signal groups. In some countries a signal group is referred to as ‘phase’.
In order to retrieve data and change states of signal groups, VAP provides
several functions. Whenever the argument <no> is used, either an integer
value, a constant or a variable has to be provided. The argument’s value
31
always must evaluate to an integer number within the range [1 .. 2 ].
Additionally the number needs to correspond to a VISSIM signal group
number in the VISSIM network to be simulated with this VAP logic. If an
argument value is used that does not meet the above criteria, program
execution stops and an error message is displayed.
Current_state (<no>, <display>)

Returns 1 if the current state of signal group <no> is <display>, else 0.
The parameter <display> can be set to one of the following:
Red red Amber amber Green green
Red_f (flashing red) Amber_f amber_f Green_f (flashing
red_f (flashing amber) green) green_f
Redamberredamber Greenamber Redgreen_f redgreen_f
Off_rot off_red Off greenamber (red-green alternating)
(off meaning ‘red’)off
Desired_state (<no>, <display>)

Returns 1 if the last desired state (set by either Interstage or Set_sg) of
signal group <no> is <display>, else 0. See Current_state for a list of
possible values for <display>.
Intergreen (<no1>, <no2>)

Returns the intergreen time between signal group <no1> and signal group
<no2>. The intergreen matrix must be defined in the *.PUA file.
Remaining_intergreen (<no>)
Returns the time (in seconds) until signal group <no> can get green
according to the intergreen matrix. If a conflicting signal group is green, the
maximum intergreen time between such a signal group and signal group
<no> is returned, reduced by the red-amber time of signal group <no>.
(Minimum green times are not taken into account.) The red-amber time of
signal group <no> is not included in the return value, i.e. the signal group
cannot be set to green before the return value is zero (and will then change
to red-amber first if its red-amber time is more than zero). Signal state

changes during the current time step are taken into account. If no matrix is
defined, 0 is returned.
Set_sg (<no>, <display>)

Sets the display of signal group <no> to <display> including all transitions
(e.g. amber before red) and provides all minimum display times defined in
VISSIM. For possible values for <display> see command Current_state.
Set_sg_direct (<no>, <display>)

Sets the display of signal group <no> immediately to <display> without any
transitions and disregarding minimum display times. For possible values for
<display> see command Current_state.
Sg_green (<no>)
Switches signal group <no> to green. If it is not green already, the red-amber
time as defined in VISSIM is automatically inserted before.
Sg_red (<no>)
Switches signal group <no> to red. If it is not red already, the amber time as
defined in VISSIM is automatically inserted before.
For a signal control based on signal groups (i.e. switching single signal
groups rather than stages) only the four functions shown above should be
used since any combination of signal group based commands together with
interstages may lead to malfunction of VAP. However, a PUA file still needs
to be compiled for definition of all the signal groups and at least one stage
(which defines the state of the signal groups to start with). There is no need
to define any interstages.
T_free (<no>)
Returns the time elapsed since the end of red of signal group <no> (i.e. the
current green time plus red-amber time). If the signal group is neither green
nor red-amber, the function returns 0.
T_green (<no>)
Returns the current green time of signal group <no>. The green time does
not include any red-amber time. If the current signal status of signal group
<no> is other than green, the function returns 0.
Example:
maxOut5 := T_green(5) >= maxGreen5;
The variable maxOut5 is set to TRUE if the current green time of signal
group 5 is at least as big as maxGreen5.

Signal Group Functions
T_green_min (<no>)
Returns the minimum green time of signal group <no> as defined in the
signal group parameters in VISSIM (SIGNAL CONTROL - EDIT CONTROLLERS -
SIGNAL GROUPS).
Example:
minCheck3 := T_green(3) >= T_green_min(3);
This example calls two functions and compares their return values. First the
current green time of signal group 3 is evaluated using the function
command T_green(3). Then the minimum green time for signal group 3 is
checked using the function T_green_min(3). If the current green time of
signal group 3 is at least as long as its minimum green time, the variable
minCheck3 is set to TRUE.
T_red (<no>)
Returns the current red time of signal group <no>. The red time does not
include any amber time. If the current signal state of signal group <no> is
other than red, the function returns 0.
Example:
call4 := T_red(4) >= 10;
The variable call4 is set to TRUE if the current red time of signal group 4 is
at least 10 seconds.
T_red_min (<no>)
Returns the minimum red time of signal group <no> as defined in the signal
group parameters in VISSIM (SIGNAL CONTROL - EDIT CONTROLLERS - SIGNAL
GROUPS).
Example:
IF T_red(5) >= T_red_min(5) THEN
newCall5 := TRUE
END;
Using an IF-clause this example calls two signal group functions and
compares their return values. If the current red time of the signal group 5 is
at least as long as the minimum red time for signal group 5 the variable
NewCall5 is set to TRUE.
T_stop (<no>)
Returns the time elapsed since the end of green of signal group <no> (i.e.
the current red time plus amber time). If the signal group is neither red nor
amber, the function returns 0.
Test_intergreen (<no>)
Returns 1 if all intergreen times towards signal group <no> are completed in
order to change the signal group to green.

2.6 Stages, Interstages, Partial Stages and Partial

Interstages
2.6.1 Functions for Stages and Interstages

In VAP stages are represented as Integer values. To reference a stage
either its Integer value or the keyword stage_x (where x is to be replaced by
the stage number) can be used. Within the *.PUA-file (definition of stages
and interstages) only the stage_x option may be used.
In the current version of VAP only stage numbers within the range of [1 ...
999] are permitted.
Any_interstage_active
Returns 1 if any interstage is active, otherwise 0
Interstage (<from_stage>, <to_stage>)

The INTERSTAGE command in the signal control program forces the
interpreter to start the interstage from stage number <from_stage> to stage
number <to_stage>. The corresponding signal group switch commands are
passed to the VISSIM traffic simulation according to the interstage definition
in the *.PUA file. The used <from_stage> must be identical with the stage
currently running and the interstage from stage number <from_stage> to
stage number <to_stage> must be defined in the interstage definition table in
the *.PUA file. If this interstage is not defined, program execution terminates
with a runtime error message. When the interstage has been started then the
program will be continued directly after the interstage command. If no other
command is to be executed in the same controller time step, an explicit
GOTO command has to be used to jump to the program end.
Example:
IF gatesDown=10 THEN
Interstage(2,3)
END;
If the evaluation of the expression gatesDown=10 is TRACE, the program
will start the interstage to switch from stage 2 to stage 3. Therefore stage 2
currently needs to be running.
Interstage_active (<from_stage>, <to_stage>)

Returns 1 if the interstage from stage number <from_stage> to stage
number <to_stage> is currently running, otherwise it returns 0.

Stages, Interstages, Partial Stages and Partial Interstages
Example:
IF Interstage_active(2,3) THEN
change := TRUE
END;
In this example the program checks if the interstage from stage 2 to stage 3
is currently active (the expression IF interstage_active(2,3) THEN is
equivalent to IF interstage_active(2,3)=TRUE THEN). If the interstage is
active the program sets the variable change to TRACE.
Interstage_duration (<from_stage>, <to_stage>)

Returns the current duration of the interstage from stage number
<from_stage> to stage number <to_stage> at the end of the current
simulation time step. This is the time elapsed since the interstage started. If
the addressed interstage is not running, the function returns 0.
Example:
IF Interstage_duration(2,3) >= 15 THEN
startStageChange := TRUE
END;
In this example the program checks the duration of the interstage from stage
2 to stage 3. If it is active for at least 15 seconds, the variable
StartStageChange is set to TRUE. If the interstage from stage 2 to stage 3
was not active, the function Interstage_duration(2,3) would return 0.
Interstage_length (<from_stage>, <to_stage>)

Returns the defined length of the interstage from stage number
<from_stage> to stage number <to_stage> as it is defined in the *.PUA file. If
this interstage is not defined, the function returns 0.
Example:
fP1 := forceoff1 - T_green_min(1) - Interstage_length(4,1);
The value for the variable fP1 is calculated by subtracting from the variable
forceoff1 the minimum greentime of signal group 1 and the length of the
interstage from stage 4 to stage 1.
Stage_active (<no>)
Returns 1 if stage <no> is currently running. A stage is regarded as active
only if all its green signal groups are either red-amber or green and all its red
signal groups are either amber or red and if there is no active interstage
referring to this stage as ‘from_stage’ or ‘to_stage’.
Example:
IF Stage_active(3) THEN
Interstage (3, 4)
END;
The example above checks whether stage 3 is currently running. If so, the
program starts the interstage from stage 3 to stage 4.

Stage_duration (<no>)
Returns the current duration of stage <no> at the end of the current
simulation time step. This is the time elapsed since the end of the previous
interstage process that triggered this stage. If the addressed stage is
currently not running, the function returns 0.
Example:
WAIT_AT gatesUp := TRUE;
…
UNTIL Stage_duration(4) >= 25;
In the example above, the program waits at the WAIT_AT command until
stage 4 is running for at least 25 seconds. As soon as this happens the
program continues with the first command after WAIT_AT.
2.6.2 Functions for Partial Stages and Partial Interstages

Partial interstages are interstages which can run simultaneously with other
interstages and neither need a specific ‘from_stage’ nor ‘to_stage’ to be
defined. They are not referenced by <from_stage> and <to_stage> but by a
unique number.
To define partial interstages an optional line containing the keyword
‘interstage_number’ and the corresponding value have to be entered in the
*.PUA file. This number is being used for referencing the interstage from
within a VAP program. In this case both for ‘From Stage‘ and ‘To Stage‘ in
the *.PUA file ‘0’ can be defined in order to omit the test for the right starting
stage.
To provide more information on the stages for each stage, in addition to the
‘green’ signal groups also the ‘red’ signal groups may be defined in the
*.PUA using the keyword Red:
Red <Sg-name> <Sg-name> .. <Sg-name>
For a description of the *.PUA-File see Chapter 4.
A stage is regarded as active only if all its ‘green’ signal groups are either
red-amber or green and all its ‘red’ signal groups are either amber or red
and if there is no active interstage referring to this stage as ‘from_stage’ or
‘to_stage’.
Compatibility with earlier versions of VAP: A logic created and simulated

with VAP 2.05 (or earlier) may behave differently in the current version due
to the changes in stage definition (see above). This may especially occur if
there are stages defined whose signal group sequence is contained in
another stage. Then it is possible that more than one stage is running at
the same time.

Stages, Interstages, Partial Stages and Partial Interstages
P_interstage (<no>, <sec>)

Calls the interstage number <no>, starting in its second <sec> (usually 0).
There is no test of the status of any signal groups, neither if there are
collisions with other active interstages. The transitions defined in the
interstage are executed regardless of any condition.
P_interstage_active (<no>)
Returns 1 if interstage number <no> is active, otherwise 0
P_interstage_duration (<no>)
Returns the current second of the interstage number <no> according to its
definition in the *.PUA file. If the interstage was called with a starting second
other than 0, then the returned value is not the elapsed time since that call!.
If the interstage is not active, the function returns 0.
P_interstage_length (<no>)
Returns the length of the interstage number <no> as defined in the *.PUA
file. If this interstage is not defined the function returns 0.

2.7 Other Functions
Cycle_second / T
Returns the current second within the signal cycle which is a value within the
range [controller time step .. cycle time].
Example:
t_actual := T - offset;
IF t_actual < 0 THEN
t_actual := t_actual + Tc
END;
The example above demonstrates the use of the functions
T (=Cycle_second) and Tc (=Cycle_time) to calculate the ’local’ time taking
into account the offset to the master controller. The variable t_actual is
assigned the difference between the cycle second and the value of the
variable offset. After this assignment it is tested if the t_actual is negative. In
that case the cycle time is added to t_actual.
Cycle_time_between (<begin>, <end>, <operator type>)

Returns 1 if the current cycle second is between <begin> (b) and <end> (e),
otherwise 0. <operator type> determines the exact meaning of "between":
operator type meaning
0 b<t<e
1 b < t <= e
2 b <= t < e
3 b <= t <= e
If b > e, the interval "stretches across the cycle end", i.e. the function returns
TRUE if the cycle second is (depending on the operator type) greater than b
and smaller than e.
Cycle_time / Tc
Returns the cycle time of the currently addressed signal control. The cycle
time can be defined in the appropriate signal control edit window in VISSIM
(SIGNAL CONTROL - EDIT CONTROLLERS) .
Example:
See example for Cycle_second.
In_Frame (<no>)
Returns the elapsed time since the start of the frame of line <no> in the
current frame plan (according to the currently active program number). If this
frame is currently not active, the function returns -1.

Other Functions
Marker_get (<no>)
Returns the value from input channel number <no> (written by another
controller to the connected output channel in the previous controller time
step).
This function is used to send integer data between two signal controllers.
Therefore in VISSIM a connection between the two signal controls
(input/output channel) needs to be established using the menu command
SIGNAL CONTROL – COMMUNICATION…
Marker_put (<no>, <value>)

Writes the value <value> to the output channel number <no>. This value can
be read from the connected input channel of the other SC in the next time
step using Marker_get (<no>).
This function is used to send integer data between two signal controllers.
Therefore in VISSIM a connection between the two signal controls
(input/output channel) needs to be established using the menu command
SIGNAL CONTROL – COMMUNICATION…
Parameter (<no>)
Returns the value of parameter <no> as defined in the *.PUA file (for the
active signal program).
Prog_active
Returns the number of the signal program [1..16] currently active. The signal
program can either be selected in VISSIM or set in the VAP logic using the
command set_prog (<no>).
Record_value (<var_no>, <value>)

Passes <value> to VISSIM in order to be displayed in the signal/detector
protocol with the heading ’Variable No. <var_no>’. <value> may be a
number, a variable or a function. Timer functions can not be used directly as
<value>. To send the value of a timer, a new variable needs to be assigned
its value. Then this variable can be used in Record_value.
Example:
IF Interstage_duration (2, 3) >= 5 THEN
Record_value (23, interstage_duration (2, 3))
END;
In this example the interstage duration of the Interstage from Stage 2 to
Stage 3 is passed to VISSIM if it is at least 5 seconds. In the VISSIM
signal/detector protocol it will then be displayed as variable 23.
Set_cycle_second (<new_value>)
Sets the current second in the cycle to <new_value> [1 .. 999]. This value is
sent to VISSIM for display in the signal times table window and the

signal/detector record (LDP) after the pass through the control logic. This
function should be called in each controller time step by every signal control
which has a variable cycle time. Additionally a condition needs to be defined
when the variable cycle time is to be reset (for example at the start of a
certain stage or signal group).
Example:
cycle_timer : = cycle_timer + 1;
Set_cycle_second (cycle_timer);
Every controller time step VAP sends the value of cycle_timer to VISSIM as
the current cycle time.
Set_des_speed (<desSpDecNo>, <vehClassNo>, <desSpDistrNo>)

Assigns the desired speed distribution <desSpDistrNo> to the vehicle class
<vehClassNo> in the desired speed decision <desSpDecNo>.
This function changes the corresponding desired speed decision in VISSIM
permanently. Thus if the network file (*.INP) is saved afterwards it will
contain the changed value! Therefore it is recommended to always initializing
all the desired speed decisions that are used in the logic when the logic is
first executed.
Set_prog (<no>)
Sets the number of the active signal program to <no> [1..16]. This
information is also transmitted to VISSIM. To retrieve the currently running
signal program, use Prog_active.
Set_route (<routDecNo>, <routeNo>, <flow>)

Sets the relative flow of route <routeNo> of the routing decision
<routDecNo> in the current time interval (or the next one, if no interval is
currently active) to <flow> (only the integer part is transmitted, decimal digits
are lost).
This function changes the routing decision in VISSIM permanently, so if the
network file (*.INP) is saved afterwards it will contain the changed value!
Thus those values should always be initialized within the VAP logic.
Set_stop_time_dist (<stopNo>, <vehClassNo>, <timeDistrNo>)

Assigns the dwell time distribution <timeDistrNo> to the vehicle class
<vehClassNo> at the stop sign <stopNo>
Sqrt (<value >)

Returns the square root of <value>. <value> must be >= 0.

Overview of all VAP-Functions and Commands
2.8 Overview of all VAP-Functions and Commands

The table below shows the syntax of all available VAP functions and
commands in alphabetic order. Function parameters have been omitted. For
most functions/commands there is a long and a short name available. All
identifiers within the same row are interchangeable (also English/German)
since they represent the same function/command.
English German
long name short long name short
name name
Any_interstage_active Aia Ein_pü_läuft Epua
Clear_front_ends Cfe Loesche_vorderkanten Lvk
Clear_rear_ends Cre Loesche_hinterkanten Lhk
Current_state Cst Signalbild Bild
Cycle_second_between Csb Umlaufsekunde_- Tzw
zwischen
Cycle_second T Umlaufsekunde T
Cycle_time Tc Umlaufzeit Tu
Desired_state Dst Sollbild Soll
Detection Det Anmeldung Anm
Front_ends F_e Vorderkanten Vka
Headway Hdw Zeitluecke Ztl
Headway10 Hdw10 Zeitluecke10 Ztl10
In_frame InFr Im_rahmen ImRa
Intergreen Intg Zwischenzeit Zz
Interstage Ist Pü Pue
Interstage_active Isa Pü_läuft Pua
Interstage_duration Isd Pü_laufzeit Put
Interstage_length Isl Pü_dauer Pud
Marker_get MGet Marke_lesen MLes
Marker_put MPut Marke_setzen MSet
Occup_rate Occr Belegungsgrad Bgd
Occupancy Occt Belegungszeit Bzt
Occupancy10 Occt10 Belegungszeit10 Bzt10
P_interstage Pis Tpü Tpue

English German
name name
P_interstage_active Pisa Tpü_läuft Tpua
P_interstage_duration Pist Tpü_laufzeit Tput
P_interstage_length Pisl Tpü_dauer Tpud
Parameter Par Parameter Par
Presence Call Anforderung Anf
Prog_active PAct Prog_aktiv PAkt
Rear_ends R_e Hinterkanten Hka
Record_value Recval Protokolliere_wert Recw
Remaining_intergreen Rig Rest_zwischenzeit Rzz
Reset Rst Reset Rst
Set_cycle_second Sett Setze_umlaufsekunde Setze_t
Set_des_speed Sdsp Setze_vwunsch Svwu
Set_prog Sprg Setze_prog Sprg
Set_route Srou Setze_route Srou
Set_sg Ssg Schalte_sg Ssg
Set_sg_direct Ssgd Schalte_sg_direkt Ssgd
Set_stop_time_dist Sst Setze_Stop_Zeitvert Sst
Sg_green Setg Sg_freigeben Sgfrei
Sg_red Setr Sg_sperren Sgsperr
Sqrt - Sqrt -
Stage_active Stga Phase_läuft Phea
Stage_duration Stgt Phasenlaufzeit Phet
Start - Start -
Start_at - Start_at -
Stop - Stop -
T_free Tf T_frei Tf
T_green Tg T_grün Tg
T_green_min Tgmin T_grün_min Tgmin
T_red Tr T_rot Tr
T_red_min Trmin T_rot_min Trmin

English German
name name
T_stop Ts T_sperr Ts
Tele_calling_point TeCPt Tele_meldepunkt TeMP
Tele_count TeCnt Tele_anzahl TeAnz
Tele_course TeCrs Tele_kurs TeKur
Tele_delay TeDel Tele_fahrplanlage TeFpl
Tele_line TeLin Tele_linie TeLin
Tele_man_direction TeDir Tele_rvh TeRVH
Tele_passengers TePas Tele_personen TePer
Tele_prio TePri Tele_prio TePri
Tele_route TeRou Tele_route TeRou
Tele_tram_length TeLng Tele_zuglaenge TeLng
Test_intergreen Tig Zwischenzeit_pruefung Zzp
Trace - Trace -
Veh_length v_l Fz_laenge f_l
Velocity V Geschwindigkeit V

3 Error Handling
Compilation Termination
VAP terminates the compiling process when the first error is detected in the
source code, sending an appropriate error message. The parser always
compares the currently read symbol with all possible syntactically correct
symbols. If it cannot find any similarities it displays an error message which
points to the next sign. However, often the error occurs in context with the
last read symbol. Therefore the error message might not be accurate. Still it
points out the exact position where the error occurred even if the position of
the cause of the error has been passed already. A typical example is the
message: “… expected symbol: .”. In most cases it indicates that the
semicolon at the end of the expression is missing.
Check of variables
The VAP programming language has no explicit variable agreement;
variables are defined implicitly by their definition. As a result, i.e. typing
errors in identifier names can not be recognized in contrast to many other
programming languages. At the end of the program compilation process VAP
checks the usage of variables as follows:
► It is checked whether all referenced variables of the source code have
been defined. Thus VAP ensures that all variables used in expressions
or as a function or command argument are assigned a value. If a
variable is used in the program without having a value assigned, the
compiler displays a warning message.
► Furthermore VAP examines whether variables are defined in the
program but never referenced. In this case, another warning message is
displayed for all such variables. Timer variables are handled differently
since they only become timer variables when used as an argument of a
timer command. Therefore, they are considered defined but not
referenced.
The checks mentioned above can help to detect possible programming
errors.
Error Log File

If errors occur during the execution of the signal control program, the
interpreter will write the appropriate message to an error file. This error file is
named SCJXY.ERR (where xy identifies the number of the respective VAP
instance, starting at 0) and is located in the same directory as the *.VAP file.
If a file with this name already exists, this file will be overwritten; otherwise a
new file will be created.

3 Error Handling
Besides the error description also the currently executed instruction of the
signal control program and the status of the simulation are logged
(depending on the type of error). After an error occurred, the simulation can
only be continued after its correction and recompilation of the signal control
program.
Infinite Loops
As a measure to detect accidentally programmed infinite loops, the number
of instructions executed per simulation second is counted and compared with
the maximum number of instructions allowed. If this maximum is exceeded,
program execution stops and an error message are displayed. In the current
version the maximum is set to 200,000 program commands per interpreter
call.

4 Interstage Description (*.PUA file)
The definition of signal groups, intergreens, stages, and interstages is to be

made in the interstage definition file (*.PUA). This file can be edited manually
or exported from another program which provides this data. As an example,
the program CROSSIG from PTV AG offers an export function to create
*.PUA files.
At a minimum, this file contains the following information:
► definition of all signal groups
► definition of all stages
(signal group based logic: one stage per signal group)
► definition of start stage(s)
(signal group based logic: a stage represents a signal group)
In addition, stage based control logics require the definition of all the
interstages.
The format of the interstage definition file is being described within the
comment lines of the sample file below. The file is divided into several
sections, all starting with a keyword (e.g. $SIGNAL_GROUPS). Within a section, all
lines between the keyword and the next ‘$’ sign is regarded as comment
lines (exception: In the $INTERSTAGE definition there are some command lines
within the comment section). After this comment section the data section
follows until the next keyword is encountered.
The signal group timings for the definition of interstages are regarded as
red end and green end times.
During the simulation VISSIM automatically includes the redamber time for
a signal group being switched from red to green (according to the redamber
time defined for that signal group in VISSIM). Similarly, VISSIM
automatically includes the amber time for a signal group being switched
from green to red (according to the amber time defined for that signal group
in VISSIM).
Example
$SIGNAL_GROUPS-------------------------------------------------
< A signal group (also called ‘phase’) is a group of signal heads showing
exactly the same color at all times. The label of a SG (e.g. ‘K1’) must start
with a letter. The number in the second column is the VISSIM number of that
signal group. All signal groups must be defined within VISSIM using that
number. >
$--------------------------------------------------------------
K1 1
K2 2
$IGM--------------------------------------------------

< Optional section to define an intergreen matrix.

The first line (containing column headers) is ignored by VAP. For every
signal group (same sequence as defined in the $SIGNAL_GROUPS section)
one line with its name and the intergreen times needs to be defined. ‘-127’ is
the code for compatible signal groups.>
$--------------------------------------------------------------
K1 K2
K1 -127 3
K2 5 -127
$FRAME_PLAN ---------------------------------------------------
program_number: 1
< Optional section to define signal frame plans.
In its header the number of the respective signal program (as defined in
VISSIM or using Set_prog) must be defined after the keyword
Program_number. (Only one frame plan may be defined per program
number.)
After the second $-line there can be any number of frame plan lines, each
one containing first the unique line number (referred to by the function
In_frame) and then the start and the end of the frame. These times refer to
the current cycle second. If the time is equal to the frame end time, the frame
is considered inactive.>
$--------------------------------------------------------------
8 44 4
27 33 3
$FRAME_PLAN ---------------------------------------------------
program_number: 2
$--------------------------------------------------------------
8 52 1
27 35 10
$PARAMETER--------------------------------------------------
program_number: 1
< Optional section to define any user-defined parameters.
In its header the number of the corresponding signal program (as defined in
VISSIM or with the command Set_prog) must be defined after the keyword
program_number.
The following data (after the second $-line) are parameters for this program
(not more than one set of parameters for each program number). After the
second $-line there can be any number of lines, each containing a parameter
name (consisting of the letter P and a number between 1 and 1000) and the
(integer) value of that parameter.>
$--------------------------------------------------------------
P1 777
P10 3
$PARAMETER--------------------------------------------------

program_number: 2
$--------------------------------------------------------------
P1 333
P10 0
$STAGES--------------------------------------------------------
< A stage is composed of one or more signal groups that all show ‘green’ at
the same time. To define a stage enter the stage definition keyword (e.g.
stage_1 for stage 1) and then simply enter a list (blank-separated) of all the
signal groups showing ‘green’ in that phase. Additionally there is an option to
define all signal groups showing ‘red’ in the line below (preceded by the
keyword ‘red’). >
$--------------------------------------------------------------
stage_1 K1
red K2
stage_2 K2
red K1
$STARTING_STAGE------------------------------------------------
< The stage the logic will start with.>
$--------------------------------------------------------------
stage_1
$INTERSTAGE1---------------------------------------------------
length [s] :3
from stage :1
to stage :2
---------------------------------------------------------------
< Any number of interstages can be defined. However, from one stage to
another, only exactly one interstage may be defined. After the last interstage
definition, the $END keyword must follow.
The definition of an interstage starts with the three keywords ‘length [s] :‘,
‘from stage :’ and ‘to stage :’ and the corresponding values (see above). An
optional line containing an interstage number may be entered above the
‘length’ line (e.g. interstage_number : 11). This option is to be used with
partial interstages and then the ‘from stage’ and ‘to stage’ values may be set
to 0 (meaning ‘not relevant’). Such an interstage is then called by its number.
Then (after the $-line) there is one row for each signal group being switched
within that interstage. The timings needed for each signal group are red-end
(‘tBegin’) and green-end (‘tEnd’) relative to the start time of the interstage. If
a signal group is already green before the interstage starts, ‘-127’ is used as
tBegin. If a signal group stays green after the interstage ends, "127" is used
as tEnd. Signal groups that don't change their color in a particular interstage
do not have to be included. >

signal group tBegin tEnd

$--------------------------------------------------------------
K1 -127 0
K2 3 127
$INTERSTAGE2---------------------------------------------------
length [s] : 10
from stage :2
to stage :1
---------------------------------------------------------------
- optional comment lines, e.g.:
signal group tBegin TEnd
$--------------------------------------------------------------
K1 5 127
K2 -127 0
$END-----------------------------------------------------------

VAP 2.16 Interface User Manual: PTV Planung Transport Verkehr AG

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

VAP 2.16 Interface User Manual: PTV Planung Transport Verkehr AG

Transféré par

Droits d'auteur :

Formats disponibles

VAP 2.

2 Program Language Elements 9

4 Interstage Description (*.PUA file) 39

VAP 2.16 Interface © PTV AG 2007 3

VAP (vehicle actuated programming) is an optional add-on module of

VAP 2.16 Interface © PTV AG 2007 5

Hard- and Software requirements

VAP signal controllers in VISSIM

VAP 2.16 Interface © PTV AG 2007 7

VAP 2.16 Interface © PTV AG 2007 9

2.1 General Conventions

10 VAP 2.16 Interface © PTV AG 2007

User Manual © PTV AG 2007 11

Arrays (Vectors) of Variables

12 VAP 2.16 Interface © PTV AG 2007

Signal Groups and Detectors

User Manual © PTV AG 2007 13

14 VAP 2.16 Interface © PTV AG 2007

2.3 VAP Program Elements

User Manual © PTV AG 2007 15

16 VAP 2.16 Interface © PTV AG 2007

User Manual © PTV AG 2007 17

variables to the trace file without activating the trace mode.

18 VAP 2.16 Interface © PTV AG 2007

2.4 Detector Functions

2.4.1 Detector Data Access Functions

User Manual © PTV AG 2007 19

20 VAP 2.16 Interface © PTV AG 2007

2.4.2 Functions to Reset Detector Data

2.4.3 Test Functions for Public Transport Telegrams

User Manual © PTV AG 2007 21

22 VAP 2.16 Interface © PTV AG 2007

2.5 Signal Group Functions

Current_state (<no>, <display>)

Desired_state (<no>, <display>)

Intergreen (<no1>, <no2>)

User Manual © PTV AG 2007 23

Set_sg (<no>, <display>)

Set_sg_direct (<no>, <display>)

24 VAP 2.16 Interface © PTV AG 2007

User Manual © PTV AG 2007 25

2.6 Stages, Interstages, Partial Stages and Partial

2.6.1 Functions for Stages and Interstages

Interstage (<from_stage>, <to_stage>)

Interstage_active (<from_stage>, <to_stage>)

26 VAP 2.16 Interface © PTV AG 2007

Interstage_duration (<from_stage>, <to_stage>)

Interstage_length (<from_stage>, <to_stage>)

User Manual © PTV AG 2007 27

2.6.2 Functions for Partial Stages and Partial Interstages

For a description of the *.PUA-File see Chapter 4.

Compatibility with earlier versions of VAP: A logic created and simulated

28 VAP 2.16 Interface © PTV AG 2007

P_interstage (<no>, <sec>)

User Manual © PTV AG 2007 29

2.7 Other Functions

Cycle_time_between (<begin>, <end>, <operator type>)

30 VAP 2.16 Interface © PTV AG 2007

Marker_put (<no>, <value>)

Record_value (<var_no>, <value>)

User Manual © PTV AG 2007 31

Set_des_speed (<desSpDecNo>, <vehClassNo>, <desSpDistrNo>)

Set_route (<routDecNo>, <routeNo>, <flow>)