VAP 216 e

VAP 2.
16
USER MANUAL
PTV Planung Transport Verkehr AG, Karlsruhe, Germany

Contents
1 Introduction 3
2 Operating Instructions 5
3 Program Language Elements 7

3.1 General Conventions 8
3.2 Operators 12
3.3 VAP Program Elements 13
3.4 Detector Functions 18
3.4.1 Detector Data Access Functions 18
3.4.2 Functions to Reset Detector Data 20
3.4.3 Test Functions for Public Transport Telegrams 20
3.5 Signal Group Functions 22
3.6 Stages, Interstages & Partial Interstages 26
3.6.1 Stage Functions 26
3.6.2 Interstage Functions 27
3.6.3 Partial Interstage Functions 29
3.7 Other Functions 30
3.8 Overview of all VAP-Functions and Commands 33
4 Error Handling 37
5 Interstage Description (PUA file) 39
VAP 2.16 User Manual PTV AG 2014 2

1 Introduction
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.

2 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
corresponding VISSIM network file (*.INP).
VAP signal controllers in VISSIM

Within VISSIM an existing signal control (SC) logic can be set to VAP type
using the menu command SIGNAL CONTROL - EDIT CONTROLLERS. From the
Type list, 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 list 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 increased to a value up to 10 times per
simulation second 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.

3 Program Language Elements

Program Language Elements
3.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 variables
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 3.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.
Function arguments need to be numbers, constants or variables but not
composite expressions.
Example variable: Set_des_speed( 1 , 1, desSpeed ) ok
Example expression: Set_des_speed( 1 , 1, desSpeed+1 ) error
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.

General Conventions
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
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 are defined in the CONST section (to be
placed after VAP_Frequency).
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.

Arrays (Vectors) of Variables

VAP can process one- and two-dimensional arrays. These arrays must be
defined in a section starting with the keyword ARRAY which needs to be
placed after the section for CONST 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
values within the range 1..231 (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.

3.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
3.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.

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. It has
been introduced by the previous version of the German RiLSA regulations
but has been deprecated in the latest version. For this reason and in order to
maintain a clear program structure we recommend not to use this command.
Firstly 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.

3.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
value passed to the function must be within the range [1, 231]. 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.
3.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. If a vehicle reaches the detector while
another one is still present on the detector, no new front end is detected.
To reset the contents of the internal detector memory the function
Clear_front_ends must 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>))

Detector Functions
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. If a vehicle leaves the detector while
another one is still present on the detector, no new rear end is detected.
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.

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.
3.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.
3.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>

Detector Functions
The delay is calculated as follows:

Firstly the total distance between the previous and the next stop is
computed (along the PT line's route).
Then the theoretical time for the distance already traveled is computed
as: quotient of the distance traveled since the previous stop divided by
the total distance between stops and multiplied with the expected travel
time between the two stops (taken from the time table, i.e. the difference
between the two departure time values).
Finally the delay is computed as the actual time travelled since the
departure from the previous stop deducted by the theoretical time.
Please note that this value is only a rough interpolation because it ignores
the dwell time at the next stop.
The value PT: Lateness shown in the vehicle information is only updated
as a vehicle leaves the current stop and shows the lateness (in seconds) at
the time of exiting from the current stop.
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>

3.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 a 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 arguments value
always must evaluate to an integer number within the range [1 .. 231].
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:
amber
amber_f (amber flashing)
greenamber
green
green_f (green flashing)
redgreen_f (red-green alternating)
red
red_f (red flashing)
redamber (red and amber together)
off_red (off meaning red)
off (off meaning green)
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.

Signal Group Functions
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.
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.

Signal Group Functions
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.

3.6 Stages, Interstages & Partial Interstages

The stages are defined in the section $Stages in the *.PUA-file (see chapter 4
for a description of the *.PUA file format). This is done by defining at least all
those signal groups that show green in that stage. In addition, also those
signal groups that show red may be defined below.
In VAP a stage is active (i.e. is running) if all the following conditions are
fulfilled:
all those signal groups defined as green in the stage definition currently
show redamber or green
all those signal groups defined as red in the stage definition currently
show amber or red
no interstage is running that contains this stage as either from stage or
to stage.
For the reasons shown above it is possible that more than one stage is
running simultaneously. This is even more likely to happen if the list of
green signal groups of one stage is contained in the definition list of
another stage. To avoid that more than one stage is then running at the
same time, the definition of all signal groups showing red is necessary for
each stage.
Compatibility with VAP versions prior to VAP 2.06:

A logic created with VAP 2.05 (or earlier) may behave differently in the
current version due to the changes in stage definition. This may especially
occur if there are stages defined whose signal group sequence is
contained in another stage.
3.6.1 Stage Functions

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.
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.

Stages, Interstages & Partial Interstages
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.
3.6.2 Interstage Functions

In order to switch from one stage to another, an interstage must be used. An
interstage is identified by the parameters <from_stage> and <to_stage>.
Any_interstage_active
Returns 1 if any interstage (also a partial interstage) is active, otherwise 0.
Interstage (<from_stage>, <to_stage>)

Starts the interstage from stage number <from_stage> to stage number
<to_stage>. The corresponding signal group switch commands are passed
to the VISSIM simulation according to the interstage definition in the *.PUA
file. The <from_stage> must be identical with the stage currently running and
an interstage (<from_stage>, <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 TRUE, 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.
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 TRUE.
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.

Stages, Interstages & Partial Interstages
3.6.3 Partial Interstage Functions

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 (see section 4 for details). This number is used for referencing the
interstage from a VAP program. Both From Stage and To Stage in the
*.PUA can be set to 0 in order to omit the test for the correct starting stage.
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.

3.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_second_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
3.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_luft 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_luft 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_luft 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_luft Phea
Stage_duration Stgt Phasenlaufzeit Phet
Start - Start -
Start_at - Start_at -
Stop - Stop -
T_free Tf T_frei Tf
T_green Tg T_grn Tg
T_green_min Tgmin T_grn_min Tgmin
T_red Tr T_rot Tr
T_red_min Trmin T_rot_min Trmin

Overview of all VAP-Functions and Commands
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

4 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 cannot 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 corresponding message to an error file. This error
file is named VAP216.DLL.ERR 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. If any such error has occurred, VISSIM
displays a message box after the simulation is finished indicating that errors
have occurred.
Besides the error description also the currently executed instruction of the
signal control program and the status of the simulation are logged

Error Handling
(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.

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

done in the interstage definition file (PUA file). This file can be edited
manually or exported from another program (e.g. Vissig by PTV) which
provides this data.
At a minimum, the following information needs to be defined:
definition of all signal groups
definition of all stages
definition of start stage(s)
definition of all interstages (not needed for signal-group-based logics)
The format of the interstage definition file is 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 keywords prior to the comment
section). After this comment section a 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 (in contrast to green begin and red begin).
During the simulation VISSIM automatically includes the redamber time for
a signal group being switched from red to green (according to the red-
amber 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 of a *.PUA file (including format description)
$SIGNAL_GROUPS -------------------------------------------------------------------------
< This section represents a matching table for all signal group identifiers used in
VAP and VISSIM. A signal group (SG, often also called phase) is a group of signal
heads showing exactly the same color at all times.
In VAP, 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 in VISSIM using that number. >
$- - - - - - - - - - - -
K1 1
K2 2

Interstage Description (PUA file)
$IGM -----------------------------------------------------------------------------------
< Optional section to define an intergreen matrix.
The first line (containing column headers) is ignored by VAP. For every SG (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 a signal frame plan. There can be multiple sections of
this type for different signal programs. The format is:
- Keyword $FRAME_PLAN
- program_number: no. of the signal program (as defined in VISSIM-SC-Controller or
using VAP command Set_prog) to which this frame plan belongs. Only one frame plan
may be defined for each signal program.
- Data: 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.>
$- - - - - - - - - - - -
9 44 4
27 33 3
$FRAME_PLAN ------------
program_number: 2
$- - - - - - - - - - - -
9 52 1
21 35 10
$PARAMETER -----------------------------------------------------------------------------
program_number: 1
< Optional section to define any user-defined parameters. There can be multiple
sections of this type for different signal programs. The format is:
- Keyword $PARAMETER
- program_number: no. of the signal program (as defined in VISSIM-SC-Controller or
using VAP command Set_prog) to which this frame plan belongs. Only one frame plan
may be defined for each signal program.
- Data: 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 999) and the
(integer) value of that parameter. >
$- - - - - - - - - - - -
P1 777
P10 3
$PARAMETER -------------
program_number: 2
$- - - - - - - - - - - -
P3 333
P10 0

$STAGES --------------------------------------------------------------------------------
< A stage is defined by
- all signal groups showing green:
- Keyword stage_ following the stage no. (e.g. stage_2)
- List of all green signal groups in that stage
- all signal groups showing red (optional, but highly recommended, especially if
partial interstages are used):
- Keyword red
- List of all red signal groups. >
$- - - - - - - - - - - -
stage_1 K1
red K2
stage_2 K2
red K1
$STARTING_STAGE ------------------------------------------------------------------------
< The stage the logic will start with. When using independent stages wiithin the same
logic, more than one starting stage may be defined. >
$- - - - - - - - - - - -
stage_1
$INTERSTAGE ----------------------------------------------------------------------------
length [s] :3
from stage :1
to stage :2
< Definition of an interstage. There can be multiple sections of this type. Each
interstage that is called from VAP must be defined here. In turn, for every stage
transition not more than one interstage can be defined. The format is:
- Keyword $INTERSTAGE
- Data section 1 including the following keywords:
- interstage_number : <nr> (optional)
This option is useful for applications with partial interstages where such an
interstage is then called by its number. Then the from stage and to stage
values may be set to 0 (meaning not relevant) so that this interstage will
not be considered during the check for running stages.
- length : duration of interstage (in seconds)
- from stage : no. of the stage where the interstage starts from
- to stage : no. of the stage wwhere the interstage leads to
- any commentary (after the keyword to stage until the next $-sign)
- Data section 2: Signal group data. One row for each signal group that is switched
during that interstage. Signal groups that don't change do not have to be included.
The format of each line is: <signal group> <red end> <green end>. The red end and
green end times are relative to the start time of the interstage. The only exeptions
are the two numbers -127 and 127 which are used as symbol for minus infinity and
plus infinity:
-127 means that a signal group is already green before the interstage starts
127 means that a signal group stays green after the interstage ends. >
$- - - - - - - - - - - - - -
K1 -127 0
K2 3 127

Interstage Description (PUA file)
$INTERSTAGE ----------------
Interstage_number : 12
length : 10
from stage :2
to stage :1
$- - - - - - - - - - - - - -
K1 5 127
K2 -127 0
$END -----------------------------------------------------------------------------------
< Keyword to tell VAP that the PUA file is finished. >

VAP 216 e

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VAP 216 e

Uploaded by

Copyright:

Available Formats

VAP 2.

PTV Planung Transport Verkehr AG, Karlsruhe, Germany

3 Program Language Elements 7

5 Interstage Description (PUA file) 39

VAP 2.16 User Manual PTV AG 2014 2

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

VAP 2.16 User Manual PTV AG 2014 3

Hard- and Software requirements

VAP signal controllers in VISSIM

VAP 2.16 User Manual PTV AG 2014 5

VAP 2.16 User Manual PTV AG 2014 7

3.1 General Conventions

VAP 2.16 User Manual PTV AG 2014 8

VAP 2.16 User Manual PTV AG 2014 9

Arrays (Vectors) of Variables

VAP 2.16 User Manual PTV AG 2014 10

Signal Groups and Detectors

VAP 2.16 User Manual PTV AG 2014 11

VAP 2.16 User Manual PTV AG 2014 12

3.3 VAP Program Elements

VAP 2.16 User Manual PTV AG 2014 13

VAP 2.16 User Manual PTV AG 2014 14

VAP 2.16 User Manual PTV AG 2014 15

variables to the trace file without activating the trace mode.

VAP 2.16 User Manual PTV AG 2014 16

VAP 2.16 User Manual PTV AG 2014 17

3.4 Detector Functions

3.4.1 Detector Data Access Functions

VAP 2.16 User Manual PTV AG 2014 18

VAP 2.16 User Manual PTV AG 2014 19

3.4.2 Functions to Reset Detector Data

3.4.3 Test Functions for Public Transport Telegrams

VAP 2.16 User Manual PTV AG 2014 20

The delay is calculated as follows:

VAP 2.16 User Manual PTV AG 2014 21

3.5 Signal Group Functions

Current_state (<no>, <display>)

Desired_state (<no>, <display>)

Intergreen (<no1>, <no2>)

VAP 2.16 User Manual PTV AG 2014 22

Set_sg (<no>, <display>)

Set_sg_direct (<no>, <display>)

VAP 2.16 User Manual PTV AG 2014 23

VAP 2.16 User Manual PTV AG 2014 24

VAP 2.16 User Manual PTV AG 2014 25

3.6 Stages, Interstages & Partial Interstages

Compatibility with VAP versions prior to VAP 2.06:

3.6.1 Stage Functions

VAP 2.16 User Manual PTV AG 2014 26

3.6.2 Interstage Functions

Interstage (<from_stage>, <to_stage>)

VAP 2.16 User Manual PTV AG 2014 27

Interstage_active (<from_stage>, <to_stage>)

Interstage_duration (<from_stage>, <to_stage>)

Interstage_length (<from_stage>, <to_stage>)

VAP 2.16 User Manual PTV AG 2014 28

3.6.3 Partial Interstage Functions

P_interstage (<no>, <sec>)

VAP 2.16 User Manual PTV AG 2014 29

3.7 Other Functions

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

VAP 2.16 User Manual PTV AG 2014 30

Marker_put (<no>, <value>)