plugin-trainingV6.pdf

8/18/2019 plugin-trainingV6.pdf

1/114

Paramics V6.6 Training CourseIntermediate Users

Azalient Plugins

26th May 2010


2/114

Page 2 of 114


3/114

Page 3 of 114

Azalient Plugins : Paramics V6

Background

The Paramics software suite includes a module called Programmer which is acomprehensive development API (Application Program Interface).Programmer allows users to add to, override or replace functionality in the coresimulation software. For example, the API interface could be used tocommunicate to a plugin which has been developed to replace the core carfollowing model.

Since 2002 Azalient have provided plugin software for project related work, suchas modelling of Sydney Harbour Bridge Toll Plaza. Importantly, the development

of these plugins has been structured so they could be used for other non specificprojects and regular updates of the plugin software were provided for each new

release of the Paramics software. This process continued until 2006 with pluginsfor Paramics V5.2.

Several newer versions of the simulation software have been available since2006, however Portrait, the Paramics software developers, changed the API inthese versions. This meant that the RTA/Azalient plugins, developed for ParamicsV5.2 , were not compatible with newer versions. In the most recent release of the

Paramics software, version 6.6, Portrait have changed their API so that Paramics6.6 supports the same API as was available in Paramics 5.2

Therefore it is now possible to run the Azalient plugins with Paramics 6.6,

although a new build of the software was required, due to a change in the linkingmechanism.

This training course is designed to use the Azalient plugins with Paramics 6.6. Itis aimed primarily at RTA project managers to provide technical details onextracting and analysing results produced but the plugin software.

Using Plugins

Paramics API has been developed by Portrait for the C programming language.However, a C to Java conversion plugin (called CeeJazz) has been developed by

Azalient Ltd which allows users to write plugins to Paramics using the Javaprogramming language.

To use Azalient plugins, you will need the CeeJazz software plus Azalienthardware dongle, Paramics software plus Paramics hardware dongle and the JAVAsoftware. Use of the plugins requires the following:

A working version of Quadstone Paramics 6.6 (or later) http://paramics-

online.com Java 1.5.0 http://java.com A valid licensed hardware dongle which can be obtained Azalient

http://paramics-online.com/http://paramics-online.com/http://paramics-online.com/http://paramics-online.com/http://java.com/http://java.com/http://java.com/http://java.com/http://paramics-online.com/http://paramics-online.com/


4/114

Page 4 of 114

Installing Plugins for Paramics 6.6

These are the steps for installing plugins for Paramics 6.6

1. Get a USB hardware key ("dongle") from Azalient. This dongle is in addition to

the Paramics dongle, so you will always need two dongles connected to run theplugins: one for Paramics, one for the plugins.

2. Download the latest software installer package (an EXE file) for the pluginsfrom

http://azalient.com/ftp/Plugins_6.6/

3. Close any Paramics Modeller programs running, then run the plugin softwareinstaller. We recommend that you answer "Yes" to the prompt asking if you wantto "Load plugins with every network?"

4. Start Paramics Modeller. Open an existing network, or create a new one. You

should see the azalient plugin controller window.

5. Select Actions > Show All Plugins on the azalient plugin controller window

6. In the column with the check-boxes, select any combination of plugins requiredfor your network.

7. Reload your network from the Paramics modeller window to activate thoseplugins

List of Azalient plugins for Paramics 6.6

The number of plugins has reduced from those for V5.2 to V6.6. This is for threereasons;

1. The functionality has been duplicated by Portrait and included in Paramics6.6

2. The functionality has been moved to Commuter or3. The functionality requires an extension to the Paramics API, due to the

fact that the OpenGL windowing system has changed.

The full list of available Azalient plugins for Paramics 6.6 is shown below. Theseare currently supplied as a single bundle of 27 plugins.

http://azalient.com/ftp/Plugins_6.6/http://azalient.com/ftp/Plugins_6.6/http://azalient.com/ftp/Plugins_6.6/


5/114

Page 5 of 114

Some plugins are used solely to report model results and do not affect the

operation and behaviour of the simulated traffic. These are referred to as „Reporting Plugins‟ and are described below.

Other plugins change the behaviour of infrastructure such as signal operations

and by implication the movement of traffic through the coded network.

A number of plugins modify the behaviour at a vehicle level, for example, thelane choice of individual vehicles can be altered using the „lane choice‟ plugin.

The following sections set out the different uses of the plugins based on thesebroad categories; Reporting, Operation Infrastructure and Operation Traffic.


6/114

Page 6 of 114

Reporting Plugins

AuditorOverview

The auditor Plugin allows the modeller „or auditor‟ to examine via means of easilyidentified list, all the user-configurable parameters that have been altered fromthe pre-defined default values.

Worked Examples

Example 1: "audit1"

Open new network „Audit1‟ using Paramics Editor, edit the configuration file(Edit>>Core Model Attributes>>Configuration>>Advanced>>Core) and changethe mean reaction time and mean headway values. Using network editor (Edit>>

Editor Palette>>Links) edit link „26:6‟ and enter link cost factor value of 2.4. Do aSave Changes (F12).

The Network auditor can now be switched on via the Azalient controller window,tick the PAU Auditor window and reload the network. Upon opening the auditorwindow within the controller window the auditor program will open a windowinitially showing all the user definable configuration options. Altered parametersare identified by red markers in the status column whilst those unaltered

variables are represented by a green label. See auditor window below


7/114

Page 7 of 114

Within the Auditor window when the second tab (Links) is activated a list of allthe network links and associated speed, cost factors, headway factors, andreaction times are shown. Within the network assignment process it may be thatsome of these values have been changed in order to replicate network behaviour.

These values can be sorted by any of the columns shown by simply clicking onthe header of the appropriate column. In the example below the table has beensorted by speed change and shows that the top link 16:14 has an associated

category speed of 80 which has been changed to 30 km/h (speed change 50km/h). Further down the list you will find link 26:6 where the cost factor as auser change with the new value of 2.4.

Should further investigation of the appropriate network link be required this canbe simply achieved by double-clicking on „link name‟ column, the main network

window will then move directly to the link identified, allowing easy networkauditing. For example, double click on link 20:48. This link is then centred in thescreen and highlighted.


8/114

Page 8 of 114

The figure above shows that speed changes have been made to link 20:48 but

that the rest of the default values remain unchanged for that link.


9/114

Page 9 of 114

Additional Features

File / Save as

An output file is saved showing all the displayed tables. The saved file is produced

in CSV file format and can be named and saved in any appropriate directory ofyour choice. In this file configuration parameters are saved first followed by thelink parameters. All data is saved in a single file. File naming convention, nameand location is left to the user.

Tools / Warnings

This opens a text box window showing all the current warning messages and canbe useful in identifying the cause of network loading problems should they exist.

Tools / Info

This opens a text window showing all the information messages generated.


10/114

Page 10 of 114

Bus Reporter Plugin

Overview

This plugin saves a report file detailing the travel time of each bus, on a link-by-link basis. The plugin can also annotate buses and bus-stops, showing thenumber of passengers on each bus, and the routes that stop at each bus-stop.The annotation can be controlled by two check boxes in the user interface.

Worked Examples

Example 1: "busreporter1"

Open the network „busreporter1‟. In the Azalient plugin controller window selectActions>>Show All Plugins and tick the PBR Bus Reporter plugin (see followingscreen shot). Reload Paramics to activate the plugin.


11/114

Page 11 of 114

Start the simulation running. The Bus Reporter plugin will automatically outputinformation for all bus routes to CSV format files, every 10 minutes of simulationtime. A typical example of an output file is shown below.

For individual buses the start time is reported and for each link on the route thetravel time is shown along with the time that the bus has stopped. The totals fortravel time and stopped time together with numbers of stops are reported oncompletion of the route.

Additional Features

Annotate Buses / Bus Stops

In the plugin controller click on PBR Bus Reporter to activate the Bus Reporter

window (see below).

The above window allows users to annotate buses and bus stops in the main

simulation window. The annotate will show the number of passengers on each bus, andthe routes that stop at each bus-stop.


12/114

Page 12 of 114

Economic Evaluation Plugin

Overview

The Economic Evaluation plugin reports model results including traffic volumes,speeds, travel times, travel distances and stop times for all simulated vehicles, aswell as calculating road user costs for these trips.

Background

Trips in a vehicle by vehicle simulation model can be thought of in three

classifications:completed trips – vehicles that travel from their origin and arrive at theirdestination during the analysis periodincomplete trips – vehicles that load onto the network and travel part wayto their destination but remain in the system at the end of the analysis

period.unreleased trips – vehicles that cannot load onto the network either due tocongestion or poor coding.

The standard output from most simulation software will report traffic statisticssuch as travel time, for completed trips and for the portion of an incomplete trip

so far completed. Usually this is done by recording the time that a vehicle loadsonto the network, and the time (and distance) when complete or the time (andcurrent position) for the partially complete trips. This means there are noestimates for times (distances) for incomplete trips to finish.

In addition, it is possible that completed/incomplete trips may have been delayed

before loading onto the system (i.e. started as an unreleased trip which after atime managed to load as gaps became available on the network). Again,standard outputs do not measure or report these delays.

To overcome these problems a plugin has been developed which reports

measured statistics as well as calculating estimated travel times and distances forunreleased/partially completed trips.

Main Features

The Economic Evaluation plugin has the following major functions:

All data is generated as formatted Excel files with „locked‟ cell values. Cost is broken down into travel time and VOC (distance and stop cost)

components. Delays and stops are normalised and reported in the overall “Summary”

worksheet. Arbitrary grouping of vehicle types is possible using the "fleets"

mechanism. Vehicle cost tables are read from a specified Central Cost File which may

be password protection. This restricts the user from changing these basicinput costs.

The user can change and input different threshold values for reporting of

trip time and speed variability. The OD sheet contains a table showing the proportion of incomplete trips

from and to each zone, as well as any unreleased trips.


13/114

Page 13 of 114

Worked Examples

Example 1: "EconEval1"

Load the model “EconEval1”. This example shows a small area model with a

simulation time of one hour (starting 08:00). On start-up the Azalient PluginController window appears, showing that two plugins are active, namely, “PRC – Route Choice” and “PLC – Lane Choice”.

From the Azalient Plugin Controller window select “Actions>>Show All Plugins”and toggle the “PEC - Economics” plugin.


14/114

Page 14 of 114

Reload the model.

To open the “Economic Evaluation” window, double click the plugin name “PEC – Economics”.


15/114

Page 15 of 114

In the “Parameters tab, click on „Find‟ and browse to the location for the „CentralCost File‟. For this example, the cost file is called “costs2005.xls” and is stored in

“…\Plugin-training\models\Reporting\Economic Evaluation”.

Type a “Report Title” and “Report Subtitle” and input the trips totals fornormalisation.

Generally the user should use a normalisation total that matches the total

number of trips in the demand matrix.

Select „Save‟, then reload the model. Again open the “PEC – Economics” plugin

and select the „Vehicles‟ tab.


16/114

Page 16 of 114

The vehicle types in the model will be listed down the left hand side of the table.The user can now associate appropriate costs to each vehicle type. The costs are

taken from the „Central Cost File‟ as selected in the “Parameters” tab.

Click on a cell in the „Cost Type‟ column to display the alternative vehicle costtypes.

For each vehicle type select an appropriate cost type. The cost for distance, timeand stops will automatically update and will correspond to those listed in the

“Central Cost File‟.


17/114

Page 17 of 114

Next select the “Times” tab.

“Times” allows the user to specify the time intervals over which data is reportedand summarised.

Click on “Add” to insert a time. By default the plugin will add a 15 minuteinterval from the simulation start time.


18/114

Page 18 of 114

“Add” several intervals.

“Delete” the intervals which you don‟t require reports for and define whether to “Save”, “Clear” or “Save” and “Clear” the data.


19/114

Page 19 of 114

In the above example the economic evaluation results will be saved at 08:30 and09:00 and the information will be cleared at 08:30. This means that two sets of

results will be reported, the first for the 30 minute interval 08:00 to 08:30, andthe second for the 30 minute interval from 08:30 to 09:00.

The following screenshot shows how to specify that economic evaluation resultswill be reported for 08:00 to 08:30 and for 08:00 to 09:00. Note that deselecting

“Clear” at 08:30 means the results will be the accumulated totals from the startof simulation.

The next tab, “Zones”, allows the user to define which zone results are combinedin summary information. For example, in the model provided the user may want

to look specifically at the trips on the motorway section i.e. trips between zones 1and 2. If these zones are toggled in the “Zones” tab (see screenshot below) then

the output from economic evaluation will summarise these trips as „E/E‟, externalto external trips.


20/114

Page 20 of 114

All other trips will be summarised as “E/I”, external to internal (from zones 1 and

2 to zones 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 and 13), or “I/E”, internal to external (tozones 1 and 2 from zones 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 and 13) or “I/I”, internalto internal (all trips between zones 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 and 13).

Note that the use of the terms “external” and “internal” are arbitrary.

The “PT Routes” tab enables users to specify which public transport routes aregrouped together for summary output. This is similar to the “Zones” tab but

relates to fixed public transport routes rather than zones.

PT routes that have been selected (toggled) will be reported in output statistics ina grouping denoted by the letter “S” (marked as being part of the "Study" group).

All other routes will be reported in a grouping denoted by the letter “X” (not partof the "Study" group).


21/114

Page 21 of 114

After inputting all data requirements for each tab, i.e. “Parameters”, “Vehicles”, “Times”, “Zones” and “PT Routes”, select „Save‟ and then reload the model. Nowby running the model the Economic Evaluation plugin will collect model data,calculate statistics (such as costs) and output the model results in spreadsheetformat.

As with the majority of model outputs statistics, the results from the EconomicEvaluation are saved to the model “Log\run-XXX” directory, in uniquely namedfiles. For this example two spreadsheets are saved to the “Log/run-001”

directory and these are named, “economics-001-08-30-00.xls” and “economics-001-09-00-00.xls”. The word „economics‟ identifies these files as output from theEconomic Evaluation plugin while „001‟ shows they have been saved to the “run-

001” directory. The „08-30-00‟ and „09-00-00‟ are timestamps to show thesimulation time these results are associated to.

An example of the output spreadsheet is shown below. The spreadsheet includesat least 7 workbooks namely,

Summary :- An overall summary sheet showing total hourly results and

normalised results for all vehicles. This sheet includes listings of theversions of software used, input user costs, and general informationrelating to the time / location of model runs.All :- A summary sheet for all vehicles (OD plus PT)

OD :- A summary sheet for OD (Origin-Destination dynamic route)vehiclesPT :- A summary sheet for PT (Public Transport fixed route) vehiclesVehicle Costs :- A summary list of vehicle types and associated costtypesParameters :- A summary of user defined input parameters

Assumption & Definitions :- A summary list of assumptions anddefinitions used by the plugin to calculate and output statistics.

The basic summary statistics for count, time, distance, and number of stops areprovided for complete, and incomplete trips as “measured”, and “estimated”

statistics. The measured statistics are taken straight from the model data foreach OD pair while the estimated results include a procedure to assess trip timesand distance for incomplete trips.

The vehicle operating costs are then derived by multiplying the measured andestimated times (distances) by input defined vehicle cost types.

Details of individual worksheets are explained in the document “The RTAEconomic Evaluation Spreadsheet for Paramics Simulation”.


22/114

Page 22 of 114


23/114

Page 23 of 114


24/114

Page 24 of 114


25/114

Page 25 of 114


26/114

Page 26 of 114

Additional Features

The Economic Evaluation plugin for Paramics V6.6 allows for different output

options. These options are listed in the Parameters tab and include “Per-TypeXLS”, “Per-Type CSV”, “OD Detail” and “Calc Std. Dev.”.

These options include more detail in the report, but as a result cause the report

to be much larger. Selecting Per-Type (pages) as XLS or CSV produces a trip-by-trip report of all trips recorded, showing departure time, arrival time, distancetravelled, stops, etc. This is the base information that is used for the calculationof aggregated values in the summary pages of the report. Selecting these optionsdoes not change the values recorded by the plugin, and changes the summaryvalues only marginally, because of rounding.

The “Per-Type” options can output a sheet of results for each vehicle type orgroup of vehicle types (“fleet”).

A "fleet" is an arbitrary group of vehicle types, created using the Fleet Builder

plugin (refer to user documentation on Fleet Builder plugin). For the purposes ofthe Economic Evaluation plugin, a vehicle type should be in exactly one fleet. A

typical setup might have all the "Car" types in a fleet named "Cars", all smalltrucks in a Fleet called "Small Trucks" and so on. Where there are commonly 15

or 20 vehicle types in an urban model, to represent features such as E-Tagownership, taxis, multiple-occupant vehicles etc, it is envisaged that the user willwant to group these types together for the purpose of cost analysis.

It is not necessary to define fleets. If none are defined, there will be one sheet foreach vehicle type.

Displays

The worksheets have been formatted and coloured for ease of use. The colour

key is: Grey: Estimated values for incomplete trips


27/114

Page 27 of 114

Blue: Average values (some with standard deviation) Green: Zone summaries Red: Notes (see below) and highlight for variability outside specified

ranges.

Notes have also been included in worksheet to provide explanations and

definitions. These are identified by a red triangle in the top right corner of theworksheet cell. The tooltip notes are displayed by hovering the mouse over thered triangle (see example below).


28/114

Page 28 of 114


29/114

Page 29 of 114


30/114

Page 30 of 114

Level of Service Plugin

Overview

The Level of Service (LoS) Plugin allows the user to examine intersectionperformance in greater detail and flexibility than with the standard LoSfunctionality within the core Paramics suite. LoS criteria are specified on aperiodic basis with the user defining level of service criteria for (unlimited length)intersection approaches. Output LoS information is reported via means of easilyidentified list files.

LoS Measurement Criteria

Level of service (LoS) is designated as six bands of operational acceptance, eachof these bands is represented by an individual letter of the alphabet. The lettersA-F are most commonly used with A representing the best operation and F the

worst. The table below is taken from the HCM 2000 publication and shows theLoS criteria for a signalised intersection.

HCM 2000

Within the LoS Plugin, the control delay is measured by adding the approachdelay to the acceleration delay for each vehicle and then averaging for all vehicleson that movement.

Approach delay

The approach delay is the difference between the time that a vehicle takes totraverse the entire approach to the intersection and the "freeflow time".

The freeflow time is the time that it would have taken to traverse that approach

under freeflow conditions and no controlling systems. As in Analyser, "freeflowconditions" assume the vehicle is constrained only by the speed limit and its ownmaximum speed, and it will travel at its "freeflow speed" which is the lower ofthese two speeds.

The speed limit may be different on each link on the approach, so the freeflow

time for the approach is the sum of the individual times for each link, calculatedby dividing the link length by the freeflow speed for each link. Where the freeflowspeed changes on the approach, the freeflow time will account for time requiredfor the vehicle to change speed.

Level of Service Control Delay / Vehicle (seconds)

A Less than or equal to 10

B 10.1 to no more than 20.0

C 20.1 to no more than 35.0

D 35.1 to no more than 55.0

E 55.1 to no more than 80.0

F 80.1 and greater


31/114

Page 31 of 114

The change in speed will always happen on the link which has the higher freeflowspeed, and it is assumed that the vehicle will change speed at a constant rate -its maximum acceleration or deceleration rate.

Acceleration delay

The acceleration delay is the time needed by the vehicle to accelerate back up tothe exit freeflow speed after it has crossed the stop line. This is approximated byassuming that the vehicle accelerates at a constant rate (its maximum

acceleration rate) from its current speed up to the exit freeflow speed. The exitfreeflow speed is the freeflow speed on the link before the intersection, becauseany other change in speed that the vehicle might need to make is not caused bythe intersection control.

A network may use intermediate nodes to define geometry on the approach to anintersection, so each approach may be defined as a series of links. In a congestedurban network, it may be difficult to determine automatically where the approach

to an intersection starts, and for this reason, the user will specify a start link foreach approach. The Plugin will build a list of links between each approach startlink and the intersection, and use each list of links to calculate the approach delayon the corresponding approach.

Worked Examples

Example 1: "los1"

This example uses a partially developed network to identify the process and stepsrequired to setup intersections for the reporting of LoS information, based on

criteria specified within the 2000 Highway Capacity Manual (HCM 2000). Thenetwork „los1‟ is partially coded to report los information for two of the networksintersections, Pleasant Avenue / High Street and East Street / High Street.


32/114

Page 32 of 114

i. Open the „los1‟ network and check that the los plugin has loadedcorrectly, as shown by green flag within dialog box. Should the flag bered this will mean that the program has not loaded correctly and anerror trapping window will open on the desktop. In order to view thiswindow it is required that all other desk top windows be minimised.The error message can then be read, the error rectified and the

network reloaded, this (if required) should be repeated until the greenflag appears.

ii. The input data for the intersection LoS is held within the externalspreadsheet which is located in the model directory („los1.xls‟).

iii. Open the „los1.xls‟ spreadsheet and go to the worksheet titled: “Levelof Service” .


33/114

Page 33 of 114

iv. There are four sections to the worksheet titled:a. [Configuration] – defines the period(s) when los data is to be

collected.b. [Definitions] – defines the los criteria to be used.c. [Intersection] – defines and names the intersections to be

evaluated.

d. [Approaches] – defines and names the approaches on which the losdata is to be recorded.

v. Periodic gathering of information is specified in the [Configuration]section in cell B3 in the format HH:MM:SS. In the current example the

network los information is gathered every 15 minutes. This period timeapplies to all intersections in the file and starts at the same time as thesimulation modelling period. For this network the start time is 8:00am,

hence the first reported los data will be for the period from 8:00am to8:15am. At this point the data collection is restarted and collected forthe next 15 minute period (8:15am to 8:30am). This process continuesto the end of the simulation period.

vi. The [Definitions] section shows the levels of service from A to F and

the delays for each period specified in seconds.vii. The [Intersections] section names two intersections where los data is

to be collected and refers to each by its node number. In this examplewe have “Pleasant&High” (node 3) and “East&High” (at node 34).

viii. The last section [Approaches] defines the approaches to each of theabove intersections where the los data is to be collected. In the

example network we have 4 approaches to Pleasant&High and 2approaches to East&High.

ix. The „Level of Service‟ worksheet holds all the information required forextraction of intersection approach levels of service. The worksheetcan be edited to allow for input of different los criteria if required.

Open the Level of Service window by clicking “PLS – Level of Service”.

For intersection „pleasant&high‟ four approaches are shown. However, forintersection „East&High‟ only one approach is displayed (see followingscreenshot).


34/114

Page 34 of 114

The information that is contained in the “los1.xls” spreadsheet (west left,East&High, 30:29, 39:45) is not displayed because approach link 30:29 via 39:45does not exist for intersection arms approaching node 3. In this case the pluginchecks the logic on the input information and ignores incorrect or illogical coding.

Run the simulation to produce level of service output statistics. These are savedto file (eg. „losinfo-08-45-00.csv‟ in the Log directory) as well as displayed in theLevel of Service window (see example below).

Intersection detailing

Each intersection is identified by an optional name, if present these are usedwithin the reporting window and allow easy interpretation of results. The above

table shows the intersection names have been used. For example ‘Pleasant&H igh’ and is followed by the obligatory intersection node number „3‟. In the

[Approaches] section, the required approach information is then detailed bygiving the approach name ‘north-thru’ and the first approach a-node b-node pair‘5:4’ . (In a congested urban network it is difficult for the program toautomatically determine where the approach of an intersection starts and it istherefore up to the modeller to specify the start link for each required approachto an intersection). The plugin will then automatically build an internal list of linksbetween the specified first approach link and the defined intersection, in this casefrom link „5:4‟ to node „3‟ .

However, if on the route from the first approach link (5:4) to the node (3)approaching vehicles have the opportunity to „turn off‟ the approach to node 3,

then the correct „route‟ or direction to the node must be specified. In this

example, when vehicles approach node „10‟ the route splits to two links, namely10:3 and 10:9. The route must be specified by using the „Via*‟ option. So in this


35/114

Page 35 of 114

example the first route from link „5:4‟ to node „3‟ is coded as being via link „10:3‟.This specified „approach‟ refers to all the vehicles that will pass straight throughnode „3‟, hence this approach (or movement) is called „north thru‟ (to indicate thethrough traffic on the north approach). Note that any description may be givenand there is no specific syntax required.

Similarly at the split in the route to node 3, the other approach (or movement) isfor vehicles that will turn “left” at the next junction, hence the second approach(or movement) at node „3‟ is referred to as „north left ‟ and is via link ‟10:9‟.

The 3rd approach is the west approach and as there are no alternative routes tonode „3‟, all that is required is to specify the start link, namely link ‟41:2‟ and toname the movement: „west ‟. Note that the data collected on this approach willrefer to all vehicles on this approach, i.e. left and right turners and does notdistinguish between the two movements. (The „East and High‟ intersection iscoded differently to show how delays for different movements on the sameapproach can be separated). Lastly, the south approach to node „3‟ is coded asoccurring from link 45:32, via link 6:3 and called: „south thru‟.

*NOTE:

There are three important coding things to note here:

1. You will note that the [Approach] names for all the different junctions

are all unique. No two approaches, even though they are located atdifferent nodes, have the same name. For example, the left turn is onthe north approaches at Pleasant&High and East&High are named

„north left ‟ and „west left ‟ to distinguish them from each other. If thisis not done, the plugin will not record data for one of the approaches.(This is known feature in the current version of the LoS plugin and it isalways recommended to define unique names).

2. The description of the P&H south through movement is from link 45:32and via link 6:3. You will note that no “via” description is required atnode 32 where there are a number of alternative „exit‟ links. This isbecause the movements to these links have been banned, hence by

default vehicles can not travel onto these links.3. Referring again to the south approach, you will note that the „via‟

description at node 6 (via 6:3) is required to define the route to node3. This is required in spite of the fact that there is NO alternative route

from link 26:6 to node 3 other than via link 6:3. (Any vehicles turningright at node 6 have no route to node 3, nevertheless, because there isa turning movement choice on the approach link (26:6), the departure

route to the destination node MUST be specified. If it is not specified,no data for this approach will be recorded until the route is correctlyspecified).

Reporting

Level of service information can be accessed in two ways, firstly by double

clicking the ‘reporting – level of service line’ within the Azalient Plugin Controller asecond window is opened showing the level of service for the last period of themodel run for the intersection given in the intersection dialogue box; secondly

reporting files are written in csv format and placed in the log run.nnn directory.

The log csv files can then easily be imported into spreadsheet format for postprocessing analysis if required.


36/114

Page 36 of 114

Additional Features

Windows / Log

In the Azalient plugin controller window, select „Windows>>Log‟. This opens a

text box window showing all the current warning messages and can be useful inidentifying the cause of network loading problems should they exist.

GUI to Code LoS Data

The LoS plugin for Paramics V6.6 allows users to enter intersection and approach

information via a GUI rather than directly to the “Level of Service” worksheet.However, this is restricted in use because of the limitation of the class in theParamics API. For example, to select an intersection users firstly need to open theEditor Palette in Paramics, switch to „Junctions‟ editor and select a node in themain Paramics window. The „Add Intersection‟ option is then active in the LoSplugin GUI window.

After selecting and naming an intersection the user can then select and addapproaches (using the Editor Palette and Links editor).

The process can be time consuming as the user has to switch between differentfeatures in the Editor Palette. Node and link selection options are more restricted

in Paramics V6.6 compared with Paramics V5.2.

If an approach link is selected that requires a „via‟ movement or that has nological connection to the intersection then the GUI produces a warning message

and the approach information is not saved (see example below).

In these cases the „via‟ information has to be coded directing into the „Level ofService‟ worksheet.


37/114

Page 37 of 114


38/114

Page 38 of 114

Network Evaluation Plugin

Introduction

Simulation models produce statistics that are more complex to understand thantraditional macroscopic software. This is because they deal with interactions ofindividual vehicles on a geometrically correct network and not homogeneous flow.The complexity means that there is no one statistic that will adequately representthe performance of a model network and it is therefore appropriate that a range

of statistics is produced, reported and analysed in combination. The standardParamics software produces a number of statistical measures to aid in assessingthe performance of one scheme against a number of alternatives. However, these

statistics are often not enough to allow an accurate assessment to be made,particularly in congested urban networks operating very close to saturation thatmay go into gridlock under certain conditions.

Complete and Incomplete Trips

If only complete trips are studied, which is normal practice using the standard

package, one design scheme which has gone into gridlock may appear to bebetter than another scheme because the trips that completed before the gridlockset in had relatively low trip times. Thus it would be better if there was a method

of measuring each incomplete trip.

The aim of this Plugin is to provide a means of measuring a scheme against itsalternatives, taking into account the effect of incomplete trips.

Unreleased Trips

An extreme type of incomplete trip is an unreleased trip. This is where congestionhas backed up to the point of entry, and there is no space for a vehicle to bereleased into the network. There is very little access to data on unreleased trips

from the Paramics API, only the total number from each zone. Early versions ofthe Plugin attempted to draw conclusions from this number, but this proved to beunsatisfactory. It is better to force all trips to be released, even if these trips waitin a queue that backs up out of the zone. Although this tends to make thesimulation run a little more slowly, this is offset by the greater detail in theresults.

If you think there might be unreleased trips in the network and you want

to account for these, you should extend the zone connectors so that theyare big enough to accept all otherwise unreleased trips.


39/114

Page 39 of 114

Using the Plugin

The Plugin has a tabbed window as its user interface

Tab 1: General Options

These options switch on parts of the Plugin that generate additional data. Usingthese options may cause a reduction in simulation speed.

Save OD Trip Information: Checking this option saves data for all zone to zonetrips which have a non-zero demand. There are 4 rows for per trip pair in thedata file (Complete, Incomplete, Total and a blank line). Bear in mind that if there

are N zones in your network, this may generate as many as N x N x 4 rows, ifthere is demand between each pair of zones. If the number of rows is greaterthan 65536 you may not be able to load the generated file into Excel. The trip

data is saved to a file named tripdata-HH-MM-SS.csv in the Log/run-NNNfolder, where HH-MM-SS is a timestamp corresponding to the simulation time atthe point of saving, and NNN is a number between 001 and 999

Save PT Information: Checking this option generates summary data for allfixed routes (buses, trams, trains etc, collectively referred to as “PT Lines”).There are 3 rows per route (Complete, Incomplete and a blank line). The data issaved to a filed named routedata-HH-MM-SS.csv in the Log/run-NNN folder.

Save Raw Data: Checking this option generates raw data files containinginformation on all trips. It is intended that these files would be loaded into adatabase or other post-processing tool

Total Trips for Normalisation: This is a scaling factor, used to normalise theresults for all trips for any given network. In general, it should be equal to the

total number of trips of all types, including fixed routes. The inclusion of thisfactor makes it easier to directly compare two design schemes. There is aconsiderable amount of randomness in the simulation engine, and it is notpossible to constrain a model to release an exact number of vehicles.


40/114

Page 40 of 114

Tab 2: Timed Events

The Plugin will automatically save the accumulated totals and derived results at

the end of the simulation, but you may wish to save the data at a number ofintermediate points, such as the end of each demand period, or hourly during thesimulation. Use the Add button to add an event and the Delete button to deletethe event on the selected row of the table. By default, the time of the new eventwill follow the pattern of the last two events in the table, i.e. the time of the newevent will be equal to the time of the last event plus the difference in timebetween the last two events. Selecting the Save option causes results to besaved at that time, and selecting the Clear option causes the accumulated totals

to be cleared at that time. The accumulated totals are used for calculatingaverages.

Tab 3: Stops

Save Stops: Selecting this option counts stops for each vehicle, where a stop isdefined as travelling at less than the lower threshold speed. Another stop will notbe counted for a vehicle until it has travelled at more than the higher thresholdspeed. This means that, for example, only one stop will be counted for a vehicle

that slows to a stop at the back of a queue, crawls along in the queue then pullsaway once it reaches the traffic signal or other constraint. Note: Selecting theSave Stops option causes a noticeable degradation in simulation speed in largenetworks. For improved speed of simulation, if you do not need to measure stops,

turn this option off.

Weight: vehicles are paritioned into 3 sets, cars, light trucks and heavy trucks,

according to the weights set here.


41/114

Page 41 of 114

Speed: These thresholds control the counting of stops as described above. Thevalue in the first box must be greater than zero and lower than the value in thesecond box.

Tab 4: Zones

Select the zones that are external (cordon zones) and those that correspond toreal zones in the centre of your network. This partitions the results into four sets:External / External, External/ Internal, Internal/ External and Internal / Internal

Tab 5: PT Routes

This tab shows a list of all PT Routes (bus routes etc). Select the routes that you

want to study. Statistics for the Study routes are shown separately from the otherroutes.

Tab 6: Costs

Enter costs for time, distance and stops, where stop cost is set for each of 3vehicle classes.

Assumptions

Estimated travel time (Te) for incomplete trips is based on scaling up the timetaken to get to the current position (Tc) by the ratio of (estimated trip distance/

measured distance to current position).

i.e. Te = Tc * (De / Dc)

However, if a vehicle has not left its initial zone connector, Dc = 1 (1 metre) sothe estimated travel time will be very large. Therefore the travel time isestimated using this method only if the vehicle has travelled at least 5% of its

trip, by distance.

If the vehicle has travelled less than 5% of its trip, then its travel time will beestimated from the time it has taken to get to its current position plus the mean

recorded travel time, to take account of release delay

i.e. Te = Tc + Tm, where Tm is the mean recorded travel time


42/114

Page 42 of 114

Layout & Format of Results

Raw files

Complete and Incomplete trips are shown in the following format:

Columns are: Type: vehicle type

Matrix: OD matrix Origin Destination Route: Route number. Fixed route vehicles only Passengers: number of passengers. Fixed route vehicles only Start: Simulation time (seconds from midnight ) at which vehicle started Now: Time of recording (completion of trip, or time of snapshot for

incomplete trips) Time: Recorded trip time in seconds (approximately equal to Now-Start,

but may vary because of rounding errors). Distance: Distance travelled by vehicle (m)

Freeflow: Time in seconds that it would have taken the vehicle to travel byits chosen route under freeflow conditions i.e. at the speed limit. Note thatthis does not check if the vehicle is physically capable of travelling at thespeed limit.

Stops: the number of stops made on the trip, where a stop is defined istravelling at less than the stated threshold speed for at least one timestep.


43/114

Page 43 of 114

Unreleased trips are shown as follows:

At each minute of simulation, the total number of unreleased vehicles is shownfor each zone. It is not possible to break this down by matrix, vehicle type ordestination, as this information cannot be extracted through the Programmer API

for unreleased vehicles.

Time Zone 831 Zone 832Zone1003

Zone1004

00:01:00 0 0 0 000:02:00 0 0 0 0

… … … … … 00:13:00 0 0 99 7400:14:00 0 0 120 94

Trip Data (Averaged data for each OD pair)

Left hand section (Measured)

Count: the number of vehicles in each category (Complete, Incomplete

and Unreleased) on this OD trip. The API does not give per-trip data onunreleased vehicles, only per-origin data. Therefore, the value forUnreleased is disaggregated, based on the split of demands from theorigin zone to the destination zone, as a proportion of all demand fromthe origin. in other words, the ratio of the cell to the row total.

Time: the average time taken to get to the point of recording. For

complete trips, the point of recording is the destination. For incomplete

trips, the point of recording is the position of the vehicle when therecording was made, somewhere in transit between origin anddestination. There is no measured time for unreleased trips. Note: the

travel time shown here includes an estimate of the delay experiencedby the vehicle at the origin zone if there were unreleased vehicles at itstime of departure. If


44/114

Page 44 of 114

the current size of the unreleased queue in an originzone is Q vehicles

the measurement period is length P seconds in the measurement period, the number of vehicles

successfully released from that zone is Rthen the release delay D is: D = Q x P / R.

For example, if P = 900 seconds, and Q = 30 vehicles and R = 100 vehicles, thenD = 30 x 900 / 100 = 270 seconds or 4.5 minutes. Thus a vehicle would have towait 4.5 minutes before a gap appeared. This method assumes „first in first out‟

(FIFO) behaviour at the zone, which is not always strictly the case.

Distance: the average distance travelled from the origin to the point of

recording. For complete trips, this is the average trip length. UnlessAON routing is being used, there may be multiple routes to thedestination, so the distance may not correspond with one particular

route. There is no measured distance for unreleased trips.

Speed: the average speed travelled to the point of recording. Thespeed for each vehicle is calculated as the distance travelled divided bythe time taken, including any delays, stops (in congestion or at trafficsignals etc). Thus the average speed may be a very low value, lessthan 1km/h. This is especially true if the network has “locked up”.

There is no measured speed for unreleased trips.

Average Cost: the cost calculated for the average distance and time,

using the A and B coefficients defined in the configuration. That is, cost= A.T + B.D. There is no measured cost for unreleased trips.

Total Cost: the cost calculated for the total distance and time, also

using co-efficients A & B. This cost is equal to the average costmultiplied by the number of vehicles. There is no measured cost forunreleased trips.

Freeflow Time: the average of the times it would have taken each

vehicle to travel by its chosen path at the freeflow speed on each link(the speed limit). There is no measured freeflow time for incomplete orunreleased trips.

Stops: the average number of stops made by a vehicle on this trip. A

stop is defined by the threshold speed in the options section of theinput plugin file. By request, stops are displayed per km, i.e. the stop

count has been normalised by distance. There is no measured stopcount for incomplete or unreleased trips.


45/114

Page 45 of 114

Right hand section (Measured + Estimated) Time: for complete trips, there is no need to make an estimate; the

value shown here is the measured value. For incomplete trips and

unreleased trips, the travel time is derived by dividing the estimateddistance by the estimated speed. This derived time includes a valueresulting from a release delay at the zone of origin, because the

estimated speed is derived from a measured speed, which in turn isderived from a travel time that includes the release delay, as describedabove.

Distance: for complete trips, there is no need to make an estimate; the

value shown here is the measured value. For incomplete andunreleased trips, it is assumed that these will tend to use the same

route as the complete trips, and thus the distance travelled will be thesame. This assumption may not hold if dynamic feedback is enabledas congestion may cause vehicles to take a different route, but using

the distance of the completed trips is the best we can do in this case.

Speed: for complete trips, there is no need to make an estimate; the

value shown here is the measured value. For incomplete andunreleased trips, it is assumed that vehicles will travel at an averagespeed not exceeding that of the average speed recorded for theincomplete trips (the most recent trips).

Average Cost, Total Cost: these are calculated in the same way as

described above for the left hand section.


46/114

Page 46 of 114

Route Data

Data in this table shows counts and averages for fixed route vehicles in the same

general format as for the OD trips in the previous section. There are 3 rows perroute in the data file (Complete, Incomplete and a blank line). It is not possible toextract unreleased counts per route from the simulation through the API. As the

number of unreleased buses per route is not known, the total for each route isnot known. The total number of unreleased buses is shown in the summary file.

Where incomplete trips exist, there is an estimate of the time, distance, speedand resulting cost that would be generated if the trip were to be completed. Themethodology used for fixed route vehicles is exactly the same as describedpreviously for OD vehicles, and does not take passenger stop times or other

specialised factors into account.

If a trip has just started at the time of recording, the vehicle may not havetravelled any distance and thus does not contribute to the totals in the Measured

part of the Incomplete row.


47/114

Page 47 of 114


48/114

Page 48 of 114

Trip Summary


49/114

Page 49 of 114


50/114

Page 50 of 114

The summary table shows the results grouped into 4 subsections tables and asubtotal table for OD trips, and 2 subsection tables and a subtotal table for fixedroute trips. Finally, there is an overall total table. There are no Unreleased orTotal rows for the fixed route vehicle subsections, as this information cannot beextracted from the API, as explained above.

This table shows aggregated values, but there may be different aggregations foreach class of trip, so the figures may not be equal in places you might expect.Consider the average speed in the estimated section for internal/internal trips,highlighted in yellow. The description above says that the speed for unreleased

trips is derived from the speed for incomplete trips, so you might expect the twovalues to be the same. However, the “OD: In/In” category aggregates data froma number of trip pairs, and only some of these have unreleased trips. The

Unreleased row shows the aggregate value for only those trips. In general, tripswhich start at a zone which have unreleased vehicles will have a lower averagespeed than the other trips, because the travel time will include the delayexperienced while queuing to get onto the network at the start of the trip. If youlook in the trip by trip data, you will see that the speed for unreleased vehicle

trips is always the same as the speed of incomplete trips, if there are any, orcomplete trips if not.


51/114

Page 51 of 114

Validator Plugin

Overview

The Validator plugin produces comparisons of modelled and observed data as avisual display through a GUI and/or as output to spreadsheet files. Thesedisplays/reports can be used to verify if the differences in observed to modelledare within acceptable limits i.e. to check the calibration/validation of the model(hence the name “Validator”).

The observed data can be traffic volumes and/or travel times. Observed values

are read and stored in the Validator plugin and are then compared to the modeldata dynamically (as the model is running) and at set intervals (eg. every 30minutes of simulation time).

Travel times are compared for user defined routes (“trails”) through the network

and for travel between two points (a starting point and an end point) where theremay be more than one route (referred to as a “traverse”).

Observed count information can be compared for individual turns, individual links,multiple links (screenlines), and for locations where traffic loads/disappears onthe network (zones). Flows along trails and for traverses may also be comparedto observed data.

Worked Examples

Example 1: "valid1" (basic setup)

Load the network “valid1” click on the Azalient CeeJazz Plugin window and selectActions>>Show All. Click on the „Requested‟ toggle for Validator Plugin and reloadnetwork.


52/114

Page 52 of 114

If you have a valid license for the Validator plugin then the following window willbe displayed.

Double click on the plugin name, “PVD – Validator”, to raise the Azalient Validatorwindow.

The observed / modelled comparisons are displayed in a table which is refreshed

every second or every minute of simulation. There is one tab for each

link flow turn flow

zone flow (i.e. cordon flow) screen line flow traverse flow trail flow traverse time trail time

Select “File>>Save” and reload the network. This creates the basic input filecalled “Valid1.xls” and saves this to the network directory. In the spreadsheetthere is a workbook called “Validation” with column data for columns A to AJ.

Details of information stored in this worksheet are contained in the followingworked example.

Then select “Tools>>Flows…” to activate the Add Observed Flows window.


53/114

Page 53 of 114

At the top of this window a dropdown menu is displayed, listing the periodsdefined for the model. The periods are defined in the Paramics file called “profile”.If you now click on “Add Link Flow…” a warning window appears.

Click OK and in the main Paramics window select Edit>>Editor Palette and therLinks coding options. Click the right mouse button over a link you have observedtraffic flows.

After selecting an appropriate link return to the Add Observed Flows popup

window and click “Add Link Flow…”. The “Add Link Flow” window will be redrawnand will display as follows:

Enter an hourly flow rate value in the appropriate text box and select OK. Oncethe flow rate is entered the Azalient Validator window is refreshed to show theinput information for the selected link.

Selecting “File>>Save” saves this information to the “valid1.xls” file in theworksheet “Validation”.


54/114

Page 54 of 114

Repeat the above procedure to “Add Turn Flows…” (select an approach link thenenter the flow rate by turn, with flow rates are separated using commas eg

„12,30,16‟ and click OK). This information will only be saved by clicking on “File>>Save” in the Azalient Validator window. Reload the network to refreshand display the new input data for Turn Flow.

“Add Zone Flow” by selecting a zone in the main Paramics window (click withright mouse button while cursor is within a zone boundary) and enter the hourly

flow (in and out of zone separated by a comma).

Select OK then click on “File>>Save” followed by reloading the network, to save

input data to the “valid1.xls” file.


55/114

Page 55 of 114

Example 2: “valid2” (display of flow data)

Using Paramics load the network named “valid2”. Click on the Azalient CeeJazzPlugin window and double click on Plugin name “PVD – Validator” to activate theAzalient Validator window. The following window will appear.

Select “Tools>>Intervals…” to check the „Reset interval‟ and „File save interval‟.These should both be set to 1 hour (see screenshot below).

If the settings are different click on the pointer and drag/drop at the appropriateposition (1:00 hours:minutes) and select OK to save these values.

Start the model run (Simulate>>Start or Start Simulation icon). The simulationis set to run for one hour (simulation time). As the simulation runs the display in


56/114

Page 56 of 114

the Azalient Validator window will continually change. For example, the Link Flowfor link 6y:6x has an observed value of 37 vph shown in Observed column and asthe simulation progresses the Count value increases as vehicles pass along thislink. As the count increases the Validator software recalculates the Modelledvalue as an hourly rate and calculates the absolute difference (Diff), thepercentage difference (%) and the GEH values. As a further visual aid this

display colours the cell values for Diff and % (light blue to show a modelled flowgreater than an observed flow and yellow to show modelled less than observed).Positive and negative values are also shown, respective to these values. Inaddition, the GEH statistics are coloured for different ranges of values as follows:

GEH value between 0 to 5 – displayed as green

GEH value between 5 to 10 – displayed as amber GEH value greater than 10 – displayed as red

These ranges of values are referenced to the UK TRL guidelines on modelcalibration (DMRB, Volume 12 Section 2 Part 1). In general the guidelines specifythat individual GEH values less than 5 are acceptable, between 5 and 10 require

further analysis (explanation) and above 10 are outside tolerable statisticalrequirements.

The guidelines also provide criteria for screenline flows, individual flows (link andturn flows) with different magnitudes and comparisons of journey time data.

Please refer to DMRB Volume 12 Section 2 Part 1 Table 4.2 for details regardingacceptability criteria.

At the end of the simulation period the Azalient Validator window display will beas follows for Link Flow, Turn Flow and Zone Flow tabs.


57/114

Page 57 of 114

Example 3: “valid2” (screenlines and traverses)

Reload Valid2 network. Click on “PVD – Validator” to activate the AzalientValidator window. Select “Tools>>Screen Lines…”.


58/114

Page 58 of 114

“Add…” to activate the Add Screen Line window.

Type a screenline name (e.g. „S1-northbound‟) in the available text box and

select OK. The Screen Line Links window will appear. In the main Paramicswindow right click over a link you wish to add as part of the screen line (while inEditor Palette>>Links) and in the Screen Line Links window select add. Continueuntil all links associated with the screen line have been selected and added.

Select OK on the Screen Line Links window followed by OK on the Screen Lines

window. The Screen Flow tab in the Azalient Validator window will be displayedas follows:

Note that the Observed cell value for screenline “S1-northbound” is zero. The

user now has to enter a value by clicking in the text cell and typing the requiredvalue for observed hourly count. Please ensure that after typing the value thatthe „return‟ key is pressed. This will enter the value in the cell and selectingFile>>Save will write this value to the input XLS file.

A similar process should be carried out to enter observed data for a traverse.Firstly, select Tools>>Traverses…” and in the Traverses window click “Add…”.


59/114

Page 59 of 114

The add function will not be enabled unless a link is selected in the main Paramicswindow (a warning will be displayed as shown below).

Select OK, then return to the main Paramics window and in the EditorPalette>>Links option, select a start link. Again select Add in the Traverseswindow to activate the Add Traverse window. Add a traverse name and select OK.

After selecting OK a message is displayed in the main Paramics window similar tothe following.

Adding Traverse: trav1-EW

Link 1: 2:7 Link 2: (select now)

In the main Paramics window navigate to another link and right click to select thesecond traverse link. The Traverses window will be similar to the following.

Select OK then „File>>Save‟ and reload the model to refresh the saved data. TheTraverse Flow tab in the Azalient Validator window now contains the description

of the input traverse. As with screenlines, you will need to click and type a flowvalue in the Observed text cell (enter hourly flow and remember to press return


60/114

Page 60 of 114

key). Select File>>Save to write the input data to the „valid2.xls‟ file. Use asimilar procedure to input a traverse time (time in seconds).

The comparison of travel times includes additional statistics such as Mean, Std.Dev (standard deviation), Lower Qt (lower quartile), Median, and Upper Qt (upperquartile).

The observed flows and travel times for trails can also be input using this methodwith the definition of a trail being coded using the Trail Maker Plugin. Please refer

to separate documentation for a detailed description.

Additional Features

Observed Data

Observed data for flow counts and travel time can be read from a number of files.Some of these files are common to Estimator, while others are new to Validator.

Estimator Data

linkflow e.g. 3600 vehicles per hour on link A:B turnflow e.g. 1200 vehicles per hour on turn movement A to B to C cordonflow e.g. 400 vehicles in and 500 vehicles out per hour, for zone 5

Validator-Specific Data

screenflow the flow across a set of links, as defined by a screen line. traverseflow the flow "across" a traverse, derived from a count of all

vehicles recorded at the in-gate and also at the out-gate

traversetime the travel time for all vehicles crossing the traverse trailflow the flow along a trail, derived from a count of all vehicles which

have traversed all of the links in a trail in the correct sequence. trailtime the travel time along a trail, for all vehicles that follow the trail

Screen lines defined in Estimator can be re-used, but it is also possible to define ascreen line directly by selecting a set of links. Screen lines defined in this way donot need to have a physical screen line drawn on the network as in ParamicsEstimator.

If files named “linkflow”, “turnflow” etc. (or “linkflow.1”, “turnflow.1” seefollowing expalnations) are contained in the network directory then the Validatorplugin will convert these so they are read into the input “...xls” file. This

conversion will be carried out when the model is first loaded in Paramics Modellerprovided the Validator plugin is active. During the conversion process copies of

the original files are placed in a sub-directory of the Paramics network directory,called “convertedToXLS”.


61/114

Page 61 of 114

Periodic Networks

Observed flow and travel times may change over the course of the model. LikeEstimator, the Validator plugin can accept data in files with numeric suffixes

indicating the period. For example, trailflow.1 and trailtime.1 would be the files

for observed flow and time for all trails for period 1. As with other files that usethis convention, if a file with the correct extension for a period is not found, the

next choice will be a file of the same name with no extension. That is, in period 3,if linkflow.3 is not found, but linkflow is found, then the latter will be loaded.

As described in the previous section, periodic files such as “linkflow.2” areautomatically converted and saved to the “azalient.xls” on start up of ParamicsModeller.

CSV Files

To make it easier to edit the observed data using a spreadsheet, such as MS

Excel, the data files can be in CSV format. The order in which the plugin looks forfiles in period 3 is

linkflow.3.csvlinkflow.3linkflow.csvlinkflow

Note that if Estimator files are used as input eg. „linkflow.1‟ then File>>Save willsave CSV versions of these files.

Symbols

A symbolic name can be associated with any link or any zone. These names,referred to as Symbols, make it easier to relate the link and zone modeldescriptions (eg. link 213:88) to street names or similar references.

To code symbolic names select “Tools>>Symbols…” in the Validator pluginwindow. The Symbols window is displayed. In the main Paramics window select

using the right mouse button either a link or zone, and click “Add…” in theSymbols window. The Input window appears and you can use this to enter asymbolic name.

Continue adding symbol names.


62/114

Page 62 of 114

Click OK then in the Azalient Validator window select “File>>Save”. This will savethe symbolic names to “valid2.xls” file (in wooksheet named “Validation”). Thesymbolic names are then displayed in the Azalient Validator window.

For turn flows [L], [A] and [R] are used to identify “left”, “ahead” and “right” ifthere are no specific symbolic names for the outbound links.


63/114

Page 63 of 114

The values in each column in the Validator Plugin window may be sorted eitherascending or descending by clicking on the column name (see example belowwhere Observed is sorted in descending order). This is helpful for displaying, forexample, the major differences or sorting the worst GEH values.

Vehicle Types

Data can be collected for all vehicles, or for a subset, by vehicle type.

Select “Tools>>Vehicles…” from the Validator window.

To show flow and travel time comparisons for car types 1 to 3 click in the Countbox and press OK (see above). After running the model the following data isdisplayed.


64/114

Page 64 of 114

If you compare this to the previous displayed volumes you will see, for example,

on link 5y:5x the count has dropped from 45 vph to 31 vph. In essence thismeans that 31 vehicles are types 1 to 3. The remaining are other vehicle types.

Please note that if only selected vehicle types are used then the observed countdata should be consistent with the particular vehicle types i.e. it may benecessary to have more than one set of input observed counts.

DISPLAYS

Viewing Display Layers

Additional information can be drawn on the main display using the View optionsfrom the Azalient Validator window.

Note that the screen line location will only be drawn if the file “screenlines” hasbeen defined using Estimator. This file contains point locations which connect todraw a line which represents the screenline.

All other displays “Link Flows”, “Turn Flows”, and “Symbols” can be toggled on/offand are shown on the main Paramics window.

It is also possible to display items which have been selected in the AzalientValidator window. For example, click on the tab “Screen Flow” and then select theLocation name S1-northbound (see following screenshot).

In the main Paramics window the links associated with this screenline will bedisplayed (see following screenshot).


65/114

Page 65 of 114

Individual links, turns and zones can be displayed in a similar manor by selectingthe appropriate tab (eg. “Link Flow”) and then clicking on the individual Location.

Output Files

The contents of all tables are automatically saved (with file suffix A) to CSV

format files, at the end of each save interval and also at the end of eachdemand period (files have suffix P). The tables can also be saved manually using

“File>>Save Comparisons” when required (files have suffix M). Finally, the tablesare saved at the completion of the simulation (files have suffix X).

The CSV files are saved in the “Log/Run-NNN folder for the current run.

The modelled counts are cleared at the end of each reset interval and at theend of each demand period, or manually as mentioned above.


66/114

Page 66 of 114

Behaviour Plugins

Lane Choice Plugin

Overview

The Lane Choice Plugin controls which vehicles use which lanes.

DVUs in the Paramics core simulation look two nodes ahead to decide their routebut only look to the next hazard to decide which lane to use. This can cause

problems when there are very short links in a model and when in reality, driversmay be choosing lanes well ahead of time (for example, on approach to a tollplaza).

The Lane Choice Plugin allows you to set the range of lanes used on a link and/or

the next lane value based on user defined trip and/or link criteria.

Trip Criteria define which vehicles a given rule will apply to based on their tripproperties:

vehicle type applies to an individual vehicle type or restriction (types andrestrictions must previously be defined in Paramics)

origin applies to vehicles which have travelled from the specified zone orsector

destination applies to vehicles travelling to the specified zone or sector familiarity applies to either familiar or unfamiliar drivers beacon applies to all vehicles based on a beacon and the beacon state

(these are defined using the Lane Control Plugin)

Link Criteria define which vehicles a given rule will apply to based on linkproperties:

open lanes applies to all vehicles on the link if the specified lane state isactive

current lane applies to all vehicles in the specified lane current next lane applies to all vehicles on the link which have the

specified next lane value exit index applies to all vehicles on the link which have the specified exit

index

next exit index applies to all vehicles on the link which have the specifiednext exit index

The Outcome applies to vehicles which match the criteria specified in Trip Criteriaand Link Criteria:

Next Lane sets the next lane value of the vehicles (ie the lane into whichthe vehicle will turn on the next link)

Low Lane and High Lane sets the range of lanes the vehicle should useon the current link

The […] button allows a percentage allocation to be set for each lane onthe link (percentages must add to 100).


67/114

Page 67 of 114

Worked Examples

Example 1: "lane-choice1" (without Lane Choice Plugin)

The example model shows a simple network where vehicles are travelling from

Zone 1 to Zones 2 and 5. Yellow vehicles go to Zone 2 (vehicle type 1) and pinkvehicles go to Zone 5 (vehicle type 2).

The Lane Choice Plugin is not used in this model. Signposting extends 50.0

metres with signrange 1.0 metre, from node 7. Vehicles load onto link 1:2 atZone 1 randomly distributed across the two lanes.

Now consider the pink vehicles which will eventually turn left at node 7 into Zone5. They are deciding their route two nodes ahead. They first become aware thattheir route will take a left turn into Zone 5 when they reach point A (two nodeslook ahead). However they don‟t know that they must use the left lane to makethat turn until 50 metres before the turn when they pass the signposting at PointB. At this point pink vehicles start forcing their way into lane 1 to make the leftturn. However, due to the high traffic volumes, these vehicles have difficulty

finding appropriate gaps and in some instances continue in lane 2, eventuallymaking the left turn from lane 2 instead of lane 1.


68/114

Page 68 of 114

Extending the signposting further back will allow more time (increases thepossibility of finding a gap) for pink vehicles to move into the left lane, howeversignposting cannot extend beyond another hazard (eg intersection). In the next

example, the Lane Choice Plugin is used to move the pink vehicles into the leftlane well in advance of making their left turn.

Example 2: lane-choice2 (using Lane Choice Plugin)

In example 2, the Lane Choice Plugin is used to gradually move the pink vehiclesto the left lane well before they make their turn:

On the first link 2:6, the Plugin forces all pink vehicles already in lane 1 to

stay in lane 1 and forces 55% of the pink vehicles in lane 2 into lane 1 On the second link 6:5, the Plugin forces all pink vehicles already in lane 1

to stay in lane 1, and forces 70% of the pink vehicles in lane 2 into lane 1 On the third link 5:7, the Plugin forces all pink vehicles already in lane 1 to

stay in lane 1 and forces 100% of pink vehicles in lane 2 into lane 1.

Open the network “lane-chice2”, click „azalient plugin controller‟, select “PLC – Lane Choice” from the Actions > Show All drop down menu by ticking the box.Reload the network, click „azalient plugin controller‟ and double click “PLC – LaneChoice” to open the “Lane Choice” plugin window which looks like this:


69/114

Page 69 of 114

The plugin will now be used to gradually move vehicles over as described above:

Select the first link 2:6 by right-clicking on the link while in the EditorPalette>>Links option. The selected link will now appear in the „Selected Link‟window of the Lane Choice plugin.

Click on the [Edit] button to see the list of rules for the selected link. Note thatthe [Edit] button only becomes active after a link has been selected.

Click on the “Add New” icon (top right) to open the “New Rule” window. This

window will be used to define the lane choice “rules” that will apply to link 2:6.


70/114

Page 70 of 114

Select:

“Car: 2” from the „Vehicle Type‟ drop down menu in the „Trip Criteria‟section,

“1” from the „Current Lane‟ drop down menu in the „Link Criteria‟section,

“1” from the „Low Lane‟ drop down menu in the „Outcome‟ section, and “1” from the „High Lane‟ drop down menu in the „Outcome‟ section.

The New Rule window should now look like this:


71/114

Page 71 of 114

Click OK. These choices force vehicles on link 2:6 that are in lane 1 to remain inlane 1.

To add another rule, click the “Add New” icon again to raise the “New Rule”window to add another rule to link 2:6. This time, select vehicle type „Car: 2‟,current lane „2‟ and in the „Outcome‟ section select Low Lane 1 and High Lane 2.Then click on […] to raise the “Split” window. Use the up/down arrows to allocatea percentage split to the two lanes previously selected (i.e. lane 1 and lane 2).

This will force vehicles on link 2:6 that are in lane 2 to split between lanes 1 and2 in the proportions 55% and 45% respectively. The “Split” window should looklike this:

Click OK and the “New Rule” window will be updated as follows:


72/114

Page 72 of 114

Click „OK‟, and click „Apply‟ and „OK‟ in the “Lane Choices Rules For Link 2:6”window. This will save these lane choice rules for link 2:6 in the „...xls‟spreadsheet in a worksheet called „LaneChoice‟.

Rules are added to the second link 6:5 in the same manner, except with adifferent percentage split for vehicles in lane 2. When completed, the „LaneChoice Rules‟ for link 6:5 should look like this:

The third link 5:7 has similar rules with 100% of pink traffic in current lane 2forced into lane 1. The „Lane Choice Rules‟ for link 5:7 should look like this:

Running the model with the Lane Choice Plugin, you can see that the pinkvehicles gradually move to the left lane so that by the time they turn left intoZone 5, they are all in the left lane.

Operationally this means that there is less disruption of traffic in the immediatearea of the left turn into Zone 5 and that the lane discipline for left turners ismuch improved.

The „xls‟ spreadsheet will now contain the data for the Lane Choice plugin in thefollowing format:

The spreadsheet can also be manually edited to change the lane choice rules.Note that the spreadsheet must be closed when the GUI is used to define the lane

choice rules.


73/114

Page 73 of 114

Exercise:

Code Lane Choice rules so that vehicles travelling to Zone 2 along link 7:3 willmove across and stay in lane 2 only.

Additional Features

Lane Choice rules can be defined that control the lane usage for groups ofvehicles, groups of trips and lane control options such as tidal flow.

Defining Vehicle Type Groups by Restriction

In Paramics a restriction applies to one or more types, and thus restrictions canbe used to create groups of vehicle types. For example, restriction 1 could bedefined to apply to vehicle types 3, 8, and 9. Restrictions are defined in ParamicsModeller using the Restriction Manager (Edit>>Core Model Attributes >>Restrictions). Refer to the Paramics Modeller User Guide for examples anddocumentation for coding restrictions.

Note, restrictions can be defined purely for the purpose of grouping vehicle types.This means that lane or link restrictions do not necessarily need to be coded forLane Choice rules to apply.

Defining Origin and Destination Zone Groups by Sector

It may be useful to create groups of zones, to collectively address all vehicles

travelling to or from a region larger than a single zone. The Paramics Sectorsfeature can be used to achieve this. Sectors are defined using the tools available

in the Paramics Modeller Network Editor (refer to Paramics Modeller User Guide).

If Sectors have been defined for a model these will be listed in the Trip Criteriadrop down menus for Origin and Destination. They can then be selected, in asimilar manner to Zones, as Trip Criteria rules.

Defining Beacon States

A beacon can be coded in Paramics Modeller but has no effect on driver behaviourwithout the definition of a rule. These rules can be defined using the LaneControl Plugin and are related to the state of the beacon.

If a beacon is selected in the Lane Control rule, that rule will apply to vehicleswhen the beacon state (also entered in the Lane Control Rule) matches thebeacon state in the model.

Rule Order & Cascading Logic

The order of definition of rules for each link is significant. A vehicle will becontrolled by the last rule which matches its parameters. This can make the ruledefinitions seem complex, but it is not a requirement that this cascading logic is

used. If rules are defined such that each vehicle matches only one rule (or norules) then the order of rule definition is irrelevant.

http://y/063074_Plugin_Training_Docs/plugin%20training%20docs%20examples/plugins-docs/3-Behaviour/Lane%20Choice/Glossary.htm%23restrictionhttp://y/063074_Plugin_Training_Docs/plugin%20training%20docs%20examples/plugins-docs/3-Behaviour/Lane%20Choice/Glossary.htm%23sectorhttp://y/063074_Plugin_Training_Docs/plugin%20training%20docs%20examples/plugins-docs/3-Behaviour/Lane%20Choice/Glossary.htm%23sectorhttp://y/063074_Plugin_Training_Docs/plugin%20training%20docs%20examples/plugins-docs/3-Behaviour/Lane%20Choice/Glossary.htm%23restriction


74/114

Page 74 of 114

For example, if you have a 6-lane link, and you want type 1 vehicles to use eitherlane 1 or lane 6, and you want this to happen such that vehicles that enter thelink in lanes 1 to 3 use lane 1, and those entering the link in lanes 4 to 6 use lane6 then this can be defined as:

link A:B type 1 lane 1 range 1 to 1link A:B type 1 lane 2 range 1 to 1link A:B type 1 lane 3 range 1 to 1

link A:B type 1 lane 4 range 6 to 6link A:B type 1 lane 5 range 6 to 6link A:B type 1 lane 6 range 6 to 6

The order of definition of these rules does not matter, because they do not

overlap, and each vehicle can match only one rule at a time. However, if you arecomfortable with the idea of cascading logic, you can define the rules as follows:

link A:B type 1 range 1 to 1link A:B type 1 lane 4 range 6 to 6 ## overrides rule 1link A:B type 1 lane 5 range 6 to 6 ## overrides rule 1link A:B type 1 lane 6 range 6 to 6 ## overrides rule 1

In this case, fewer rules are defined, but at the expense of the rules being morecomplex for a human to understand.

Displays

Lane choice rules will be displayed on the network in the colour of your choice.All shows all lane choice rules, None shows no lane choice rules, Selected

shows lane choice rules according to the filters below. The lane choice rules

displayed can be filtered by Vehicle Type, Origin, Destination, or Familiarity.

A description of each rule will be displayed in text towards the end of each link forwhich there are rule definitions. If there are multiple rules for a link, the text willbe prefixed by a count of the form (1/4) to indicate how many rules are defined

and which one is currently being displayed (in this case, rule 1 of 4). If there aremultiple rules on a link, you can scroll through the rules by clicking on the “Next”button in the “Lane Choice” window. When you click back in the main Paramicsnetwork window, the text and display will be updated. Rules may overlap, andbecause of this, you cannot view all rules for a link at the same time.

The lane choice rule display shows a lane range as a shaded colour, in the colour

you select. You may need to turn off the display of restrictions or other displaysin the main Paramics window in order to see the shading clearly. The rule displayshows next lane rules by joining stop lines with a single line, similar to the

standard Paramics next lane display. The display does not currently show whenthe Split function is used.

http://y/063074_Plugin_Training_Docs/plugin%20training%20docs%20examples/plugins-docs/3-Behaviour/Lane%20Choice/Glossary.htm%23next_laneshttp://y/063074_Plugin_Training_Docs/plugin%20training%20docs%20examples/plugins-docs/3-Behaviour/Lane%20Choice/Glossary.htm%23next_lanes


75/114

Page 75 of 114

Route Choice Plugin

Overview

The Route Choice Plugin controls which routes vehicle vehicles use by specifyingwhich exit vehicles must use when approaching an intersection.

The routes vehicles take to their destination are determined in the Paramics coresimulation based on perceived costs from the vehicle‟s location to its destination.The routes may change through the simulation based on perturbation values andthrough the use of the feedback function. However, in certain circumstances it

may be necessary to control the routes vehicles use by specif

plugin-trainingV6.pdf

Documents

Transcript of plugin-trainingV6.pdf