Base models must demonstrate that they replicate observed conditions to a sufficiently high level of accuracy, as described in B2.5.2 and B2.5.3.
VISSIM has a useful feature which can assist with traffic flow calibration and validation, called the ‘node evaluation’ file. All critical junctions can be defined as nodes, from which VISSIM can collect multiple pre-defined parameters for every turning movement, vehicle type and time period. Such parameters can include traffic flow by vehicle type, average delay by vehicle type, average queue lengths per link and maximum queue lengths per link.
5.4.1 Base Model Calibration
Calibrated models are submitted during VMAP Stage 2. This is subdivided into the creation of a skeleton model during VMAP Stage 2a, followed by a final calibrated model in VMAP Stage 2b.
A calibrated VMAP Stage 2b VISSIM model should have as a minimum:
Appropriate and correct traffic flow data from on-street surveys, in accordance with the scope and purpose of the models;
Correct public transport data collected from reliable sources, and modelled accurately. The level of detail of public transport modelling is dependent on the purpose of the models;
All the correct, on-street signal control data with representative signal timings for the network during the period under consideration;
Accurately modelled priority rules that result in correct reflection of existing on-street conditions in the models;
Reduced speed areas placed at appropriate places in the network, and used as a mechanism to calibrate saturation flows; and
The correct, appropriate link structure which would replicate traffic behaviour on-street.
Calibration can be a lengthy and time consuming exercise. If not approached correctly the process can lead to a situation where one calibration task results in the required output for one parameter at the expense of another and the developer may get caught in a loop making little progress. To avoid this, a calibration strategy should be developed.
The following is an overview of a standard calibration strategy:
Decide which model parameters are certain and which are uncertain and may need adjustment;
Error check to ensure that all input parameters are correct;
Adjust global and link specific capacity parameters;
Adjust global and link specific demand and route choice parameters; and
Fine tune model to better match observed travel times, queue lengths, driving behaviour, etc.
In addition, the animation features of VISSIM can be used during calibration to identify irregularities in driver behaviour that may adversely affect model operation.
5.4.2 Validated Model Requirements
Validated base models are submitted during VMAP Stage 3. TD NP will require the following outputs to be reported to indicate that a model has been calibrated and is validated.
5.4.2.1 Saturation Flows
VISSIM does not require an input value for saturation flow. Instead saturation flow is derived from other input parameters. There are two alternative ways to influence the rate at which vehicles travel over signal-controlled stoplines. These are, by modifying the ‘driver behaviour’ model or by using ‘Reduced Speed Areas’ (RSAs).
RSAs should be used where there are local inconsistencies in saturation flow rate.
Where saturation flows appear to be modelled incorrectly uniformly across the network, it may be appropriate to adjust the parameters of the global ‘driver behaviour’ models. Modellers should exercise caution when changing the parameters of the ‘driver behaviour’ model as this may change behaviour in unexpected locations.
A ‘driver behaviour’ model is associated with a link type and therefore a parameter change will affect all the links for which that model is associated.
As mentioned in B5.3.1.6, for London urban networks the Wiedemann 74 ‘Driver Behaviour’ model should be used. The parameters of Wiedemann 74 that influence saturation flow are the ‘average standstill distance’, ‘additive part of safety distance’
and ‘multiplicative part of safety distance’. The VISSIM manual provides idealised example scenarios to demonstrate the effect changing these parameters has on saturation flow59. However these are specific idealised examples and the parameters given cannot be assumed to give the correct saturation flow for individual cases.
RSAs influence saturation flow by changing the speed range of specific vehicle classes along a defined length of road, usually across the stopline.
Modellers should calibrate stopline saturation flows by systematically changing the RSAs and driver behaviour parameters and comparing the model against observed saturation flows. They should use the combination of parameters that result in time headways in under-saturated conditions that closely match values measured on-site.
During the process of calibration, time headways can be studied in two ways:
Special evaluation files as described in the VISSIM manual60; or
By producing output from a VAP routine that records and reports ‘headways’ across detectors that can be placed on top of stoplines.
Special evaluation files should be filtered to remove measurements that do not correspond to saturated conditions (i.e. very large headways). TD NP can supply a spreadsheet which aids the filtering of vehicle headway data.
Wherever saturation flows have been measured on-street, providing the model is a fair representation of on-street conditions, it should be possible to measure saturation flows from the VISSIM model. An inability to collect saturation flow data across a stopline in VISSIM where it was successfully collected on-street should be an indication that the model is not performing as desired.
All observed and modelled saturation flows should be tabulated and the percentage error between the two values reported. According to MAP v2.2, modelled saturation flows values should be within 10% of observed values, or values used in any corresponding validated and approved TRANSYT or LinSig modelling.
59 VISSIM 5.10 Manual, PTV AG, pp119-121, 2009 60 VISSIM 5.10 Manual, PTV AG, p315, 2009
5.4.2.2 Traffic Flows
Modellers should use the GEH parameter (see Appendix III) to demonstrate that traffic flows within the model (i.e. internal mid-links, stoplines and individual turning movements) match traffic counts to an acceptable level of accuracy.
MAP v2.2 recommends that, when comparing modelled flow to observed flow volumes, modellers should aim for GEH values less than five. However, TD NP advocates GEH values of less than three for all important/critical links within the model area. Results should be reported to include data showing all observed and modelled flows together with calculated GEH values. Modelled flows should be averaged over multiple seeds, as described in section B5.5.1.
All entry links into the network are required to show modelled flows within 5%
of observed flows. This requirement should be achieved since vehicle flows on external links are direct input values and ensures that all assigned vehicle flows are being successfully loaded into the network during the peak modelled period.
5.4.2.3 Demand-Dependency
All demand-dependant stages within the network should show a frequency of at least 90% of that observed on-street. The average count should be reported and supplied along with any generated VAP TRACE files for each simulation run.
5.4.2.4 Journey Times
Modelled journey times should be averaged over multiple seeds, as described in section B5.5.1, and be within 15% of surveyed on-street journey times according to MAP v2.2.
Journey time output should be presented as the cumulative journey time obtained by all vehicles that follow individual journey time segments as well as complete journey times for vehicles that follow the entire journey time surveyed route.
5.4.2.5 Queue Data
Queue survey data, whilst not a validation criterion, is useful when determining bottlenecks within the network. It can be used as a measure of the model’s performance and for direct comparison with scheme proposals. Modelled and surveyed queues should be compared and presented in accompanying reports.
It should be noted that VISSIM measures queue lengths according to a set of parameters based on vehicle speeds and headways. Changing these parameters will result in different queue lengths being reported where in fact queues have not actually changed. TD NP advises that the default queue configuration parameters are used.