Traffic Modelling Guidelines
Traffic Modelling Guidelines
Traffic Modelling Guidelines
MAYOR OF LONDON
Edited by
Dr James Smith & Robert Blewitt
Transport for London, September 2010 All rights reserved. Reproduction permitted for research, private study and internal circulation within an organisation. Extracts may be reproduced provided the source is acknowledged. Disclaimer This publication is intended to provide accurate information. However, TfL and the authors accept no liability or responsibility for any errors or omissions or for any damage or loss arising from use of the information provided.
Foreword
Foreword
The capacity of Londons traffic network (both road and footway) is coming under increasing pressure and maintaining the smooth operation of this network is a challenging task. A primary goal of the TfL Traffic Manager is to deliver journey time reliability and it is essential that traffic schemes are developed to a high quality and their impacts on the network are well understood and mitigated with journey time reliability as the ultimate outcome. Traffic modelling plays an increasingly vital role in this objective and these guidelines provide invaluable support. They draw upon expertise from across the industry and form a comprehensive source of best practice. It is TfLs remit to ensure that the effects of all planned interventions on the road network are thoroughly understood before they are implemented. These guidelines are fundamental in achieving this requirement.
Alan Bristow TfL Streets Traffic Director Traffic Manager for TfL
Acknowledgements
The editors would like to thank the following individuals for their support during the creation of this document: John Green Kamran Hussain Ioannis Ioannidis Cyrus Kibuuka Vladimir Vorotovi Glynn Barton Tony Earl Brett Little Jason Robinson Mangal Singh Ajay Tailor Neil Adams Tim Piper Nicola Cheetham Steve Cotton Julie Dye Lorraine Johnson John Lee Chris Lines Steve Miller Pam Turton James Binning David Carrignon Nick Cottman Samya Ghosh Matt Hall Derek Hooper Dr Klaus Nkel Operational Modelling, Traffic Directorate Operational Modelling, Traffic Directorate Operational Modelling, Traffic Directorate Operational Modelling, Traffic Directorate Operational Modelling, Traffic Directorate Network Performance, Traffic Directorate Network Performance, Traffic Directorate Network Performance, Traffic Directorate Network Performance, Traffic Directorate Network Performance, Traffic Directorate Network Performance, Traffic Directorate Traffic Infrastructure, Traffic Directorate Traffic Infrastructure, Traffic Directorate Operations Directorate Network Assurance Borough Projects and Programme Roads Directorate Modal Policy Cycling Better Routes and Places Directorate Group Transport Planning and Policy Enforcement and Policing TRL Ltd Dessau Inc Hyder Consulting Pty Ltd AECOM Ltd Atkins Global Ltd MWH Australia Pty Ltd PTV AG
Contents
Contents
Foreword Acknowledgements Introduction 3 4 12
15
17 19 19 20 20 21 22 23 23 23 24 24 24 25 25 26 26 26 27 27 28 29 29 29 29 30 30 30 31 31 31 32 33 33 33
4.3 5 5.1 5.2 5.3 5.4 5.5 6 6.1 6.2 6.3 6.4 6.5 6.5.1 6.5.2 7 7.1 7.2 7.3 8 8.1 8.2 9 9.1 9.2 9.2.1 9.2.2 9.2.3 9.3 9.4
When to move from Local Modelling to Strategic Modelling Public Transport Considerations Introduction Assessment of Buses Bus Stops Bus Lanes & Pre-Signals Bus Priority (BP) Pedestrian Considerations Introduction Pedestrian Demand and Desire Lines Isolated Pedestrian Crossings Isolated Signalised Pedestrian Crossing Facilities Pedestrian Facilities at Signalised Junctions Full Pedestrian Parallel Pedestrian Cyclist Considerations Introduction Junction Design Inclusion of Cyclists Air Pollution Impacts Introduction TfL Objectives Which Traffic Modelling Software? Why? Introduction Deterministic Models for Traffic Signal Control Isolated Signalised Intersections Isolated Non-Signalised Intersections Networks Micro-simulation Models Assignment Models
34 35 35 35 36 36 37 38 38 39 39 40 40 41 41 42 42 42 43 44 44 45 47 47 48 48 49 49 50 51
PART B
1 2 2.1 2.1.1 2.1.2 2.1.3 2.2 2.2.1 2.3 2.3.1 2.3.2 2.3.3 2.4
MODELLING GUIDANCE
53
55 57 57 58 58 58 59 60 61 61 62 62 63
Introduction Modelling Principles Model Definitions Model Scope Base Model Proposed Model Model Auditing Process Use of Approved TfL Models Network Familiarisation Model Boundary Site Paperwork Online Data Sources Data Acquisition
Contents
2.4.1 2.4.2 2.4.3 2.4.3.1 2.4.4 2.4.4.1 2.4.4.2 2.4.4.3 2.4.5 2.4.6 2.4.7 2.4.7.1 2.4.8 2.4.8.1 2.4.9 2.4.9.1 2.4.9.2 2.4.9.3 2.4.9.4 2.4.10 2.4.10.1 2.4.10.2 2.4.10.3 2.4.10.4 2.5 2.5.1 2.5.2 2.5.3 2.5.4 2.5.4.1 2.5.4.2 2.5.4.3 2.6 2.6.1 2.6.1.1 2.6.1.2 2.6.1.3 2.6.1.4 2.6.2 2.6.2.1 2.6.2.2 2.6.2.3 2.6.3 2.7 2.7.1 2.7.2
Typical Traffic Conditions Site Visits Traffic Count Surveys Passenger Car Unit Private Transport Surveys Cruise Times Journey Times Queue Lengths Flared Approaches Non-Green and Flashing Amber Saturation Flow Use of Calculation Formula RR67 Degree of Saturation Underutilised Green Time Signal Timings UTC Junctions Non-UTC Junctions Demand-Dependent Stages Pedestrian Facilities Public Transport Surveys Bus Route Frequencies Bus Journey Times Bus Stop Usage and Dwell Times Bus Lane Usage Model Development Versions of Modelling Software Base Model Calibration Base Model Validation Proposed Model Development Changes to Junction Design Changes to Traffic Flow Demand Dependency Adjustments Proposed Model Optimisation Initial Optimisation Underutilised Green Time (UGT) Junction Storage Effects Cycle Time Optimisation Junction Performance Optimisation Fine Tuning Balancing the Network Utilisation of Network Capacity Protecting the Network Proposal Evaluation & Impact Assessment Model Reports Calibration Report Validation Report
63 64 65 66 67 67 68 69 69 69 70 71 72 72 75 75 76 77 77 78 78 78 78 79 79 80 81 81 82 84 85 85 86 87 87 89 89 89 90 90 91 91 91 92 92 93
2.7.3 3 3.1 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.4 3.5 3.5.1 3.5.2 3.6 3.6.1 3.6.2 3.6.3 3.6.4 3.6.5 3.6.6 3.6.7 3.6.8 3.6.9 3.7 3.7.1 3.7.2 3.7.3 3.8 3.9 3.10 3.10.1 3.10.2 3.11 3.11.1 4 4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.3 4.3.1 4.3.2 4.3.2.1 4.3.2.2
Proposal Report LinSig Modelling Introduction LinSig Version 3 Appropriate Use of LinSig Skeleton Models Isolated Junctions / Multiple Streams with Single Controller Networks Proposed Design Changes LinSig Modelling Approach Program Settings Junction Details Controller Details Model Build LinSig Model Structure Traffic Flows Routing / Lane Usage Saturation Flows Flare Usage Priority Give-Way Parameters Opposed Right-Turning Vehicles Demand-Dependent Stages Exit-blocking LinSig Output Link Results Cyclic Flow Profile and Uniform Queue Graphs Report Builder LinSig Calibration Requirements LinSig Validation Requirements Developing Proposed Models Cycle Time Optimisation Signal Timing Optimisation Additional LinSig Modelling Issues Sliver Queues TRANSYT Modelling Introduction TRANSYT 13 TranEd Appropriate Use of TRANSYT TRANSYT Modelling Approach Program Settings Model Build TRANSYT Network Structure TRANSYT Labelling Convention Node Numbering Traffic Link Numbering
94 95 95 96 96 96 97 97 97 97 98 98 98 99 99 100 100 101 101 102 102 102 103 103 103 103 104 104 104 105 105 105 105 105 108 108 108 109 109 110 111 112 112 114 115 115
Contents
4.3.2.3 4.3.2.4 4.3.2.5 4.3.3 4.3.3.1 4.3.3.2 4.3.4 4.3.4.1 4.3.4.2 4.3.4.3 4.3.4.4 4.3.4.5 4.3.4.6 4.3.4.7 4.3.4.8 4.4 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.5.1 4.4.5.2 4.5 4.6 4.7 4.8 4.8.1 4.9 4.9.1 4.9.2 4.10 4.10.1 4.10.2 5 5.1 5.1.1 5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.2.7 5.2.8
Pedestrian Link Numbering Exit Link Numbering Priority Link Numbering Node Input Data Signalised Nodes Non-Signalised Nodes Link Input Data Major Links Minor Links Signal-Controlled Links Bottleneck Links Give-Way Links Flared Approaches Pedestrian Links Entry and Exit Links Modelling Techniques Flow Smoothing Adjustment of Start and End Lags Demand-Dependency Exit-Blocking / Underutilised Green Time Opposed Right-Turn Movements at Signals Stop and Delay Weightings Queue Limits Public Transport Calibrated TRANSYT Base Model Validated TRANSYT Base Model Developing Proposed Models Modifying Network Structure TRANSYT Network Optimisation Cycle Time Optimisation Signal Timing Optimisation TRANSYT Output .PRT File Graphical Output VISSIM Modelling Introduction Appropriate Use of VISSIM Developing Base Models Model Boundaries Model Time Periods Data Collection Site Observation Network Layout Traffic Flows and Turning Proportions Traffic Flow Compositions Signal Timings
115 115 115 116 116 116 116 117 117 118 118 118 119 119 120 120 120 121 121 122 122 123 124 125 125 126 126 127 128 128 128 129 129 130 132 132 132 133 133 133 134 134 135 135 135 135
10
5.2.9 5.2.10 5.2.11 5.3 5.3.1 5.3.1.1 5.3.1.2 5.3.1.3 5.3.1.4 5.3.1.5 5.3.1.6 5.3.2 5.3.2.1 5.3.2.2 5.3.2.3 5.3.2.4 5.3.2.5 5.3.2.6 5.3.3 5.3.3.1 5.3.3.2 5.3.3.3 5.3.3.4 5.4 5.4.1 5.4.2 5.4.2.1 5.4.2.2 5.4.2.3 5.4.2.4 5.4.2.5 5.5 5.5.1 5.5.2 5.5.3 5.6 5.6.1 5.7 6 6.1 6.1.1 6.2 6.3 6.4 6.4.1 6.4.2
Saturation Flows Journey Times Cycles and Powered Two-Wheelers Model Building Process Network Simulation Parameters Time Period Simulation Resolution Units Links and Connectors Link Driving Behaviour Traffic Data Vehicle Models, Types, Categories and Classes Functions and Distributions Compositions and Demand Pedestrian Modelling Reduced Speed Areas and Desired Speed Decisions Routing Decisions Control Infrastructure Controller Logic Demand-Dependent Stages Placement of Signal Heads Priority Rules and Conflict Areas Calibration and Validation of Base Models Base Model Calibration Validated Model Requirements Saturation Flows Traffic Flows Demand-Dependency Journey Times Queue Data Considerations During Calibration and Validation Use of Seed Values Error Files Use of Multithreading during Validation Dynamic Assignment Convergence Proposed Models Highway Traffic Assignment Modelling Introduction HTA Modelling in TfL Streets HTA Modelling Software HTA Data Collection Network Development Zones and Connectors Nodes and Links
136 136 136 137 137 137 138 138 138 138 139 140 140 140 141 141 141 142 142 142 143 144 144 144 145 145 146 147 147 147 147 148 148 148 149 149 149 150 151 151 152 152 152 153 153 154
Contents
11
6.4.3 6.4.3.1 6.4.3.2 6.4.4 6.4.5 6.5 6.6 6.6.1 6.6.1.1 6.6.2 6.7 6.7.1
Signalised Junctions Junction Geometry Capacity Considerations Priority Junctions Public Transport Calibration Assignment Realistic Delay using Equilibrium Assignment in Congested Networks Blocking Back Convergence Model Validation Assignment (Route Choice) Validation
155 157 158 159 160 161 161 162 163 163 164 165 166 167
APPENDICES
Appendix I: Underutilised Green Time (UGT) Calculation Appendix II: Proposed Model Optimisation Process Appendix III: Flow comparison (The GEH Statistic) Appendix IV: VISSIM Dynamic Assignment Convergence Methods
171
173 175 179 180
LIST OF FIGURES
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 Figure 15 Figure 16 Figure 17 Figure 18 Figure 19 Figure 20 Transport modelling hierarchy Flow profiles showing normal (blue) and congested (orange) conditions Congested conditions as modelled in LinSig or TRANSYT with UGT Incorrectly reduced saturation flow analogous to UGT applied in Figure 3 Schematic diagram outlining a generalised approach to traffic model development for TfL Development and evaluation of a proposed traffic model for TfL Overview of a proposed approach to traffic model optimisation Relationship between junction delay and degree of saturation Example junction showing arms, links and lanes in LinSig Formation of a sliver queue in a LinSig uniform queue graph The same queue as Figure 10 with a de-sliver threshold of 1.0 PCU The TRANSYT optimisation process, adapted from Binning et al TRANSYT Node and Link labelling system (shown for J05/066) Cyclic Flow Profile graph, as shown in TranEd VISSIM Simulation Parameters for an example model Correct (left) and incorrect (right) connector usage for modelling lane gain or loss Adjustment of timings in VISSIM to account for Red/Amber (R/A) A VISUM main node as on-street (left) and within the model (right) Examples of incorrect and correct network coding using a dual carriageway junction in VISUM A bi-level approach to traffic assignment with operational-level turn delays 22 73 74 74 80 83 88 90 99 106 107 110 114 131 137 139 143 156 158 162
12
Introduction
The Traffic Modelling Guidelines have been produced by the Transport for London (TfL) Streets Traffic Directorate, with contributions from departments across TfL and external industry experts. The following document represents the views and needs of a broad spectrum of traffic model practitioners. The TfL Traffic Director is the TfL Traffic Manager and therefore has a duty to secure the expeditious movement of people and goods (collectively termed Traffic in this document as per the 2004 Traffic Management Act1). One of the key outcomes, and thus indicators, of network performance and expeditious movement of traffic is journey time reliability on the network. TfL Streets Traffic Directorate are dependent on comprehensive modelling and supporting information from clients (including Boroughs and TfL departments) and consultants in order to design, assess, implement and operate traffic schemes effectively. Appropriate, comprehensive and accurate modelling is necessary to ensure traffic schemes can be: Fully assessed for impacts and benefits; Effectively designed to satisfy the original objective and mitigate any adverse impacts; Clarified to avoid confusion or misinterpretation of the design; Effectively and efficiently implemented and operated; and Implemented with an accurate prediction of operation, i.e. no surprises. TfL Streets Traffic Directorate has developed these guidelines to help inform modellers, network operations practitioners and scheme sponsors. They encourage consistency, promote best practice and are intended to deliver improvements in modelling quality. The aim is that this will in turn promote high quality scheme design that delivers and maintains journey time reliability. The previous version of the Modelling Guidelines2 was published in July 2006. This new version has been produced to bring the document up to date and to ensure that guidance is compliant with current best practice. The guidance has also been expanded to include operational highway traffic assignment and pedestrian modelling.
1 2
Great Britain, Traffic Management Act 2004: Elizabeth II, Chapter 18, The Stationery Office, London, 2004. DTO Modelling Guidelines v2.0: Traffic Schemes in London Urban Networks, Directorate of Traffic Operations, Transport for London, 2006.
Introduction
13
The Traffic Modelling Guidelines have now been separated into two parts for ease of use:
Part A
Part A has been written to give a high-level understanding of traffic modelling as it applies in a TfL context. It is designed to be read by a wide audience, both internally and externally, including non-technical project managers and scheme sponsors. It does not assume any prior knowledge of traffic modelling.
Part B
Part B contains technical guidance relating to the use of modelling software. The first chapter covers topics which are common to all types of traffic model. Following this are software-specific sections providing guidance on modelling best practice for the corresponding software. About the Authors This guidance has been edited by the Network Performance department (formerly Urban Traffic Control), within TfL Streets Traffic Directorate. The Network Performance (TD NP) department possesses a high level of technical modelling expertise which has been developed since the 1970s (e.g. Greater London Council (GLC) and Traffic Control Systems Unit). The department (and direct predecessors) have been continuously responsible for the: Operation of Londons traffic control systems; Design, audit and implementation of traffic schemes; and Traffic signal timing reviews. The above activities provide an excellent grounding for developing traffic modelling skills. The department currently includes over fifty engineers who have advanced traffic modelling skills in deterministic (LinSig, TRANSYT), micro-simulation (VISSIM) and highway traffic assignment modelling (VISUM, SATURN). These skills have been developed through a three year training programme, alongside intense practical application. TD NP includes many engineers who are respected as subject matter experts in the traffic modelling field. These key people have contributed significantly to the development and review of these guidelines.
Introduction to Part A
17
Introduction
The Streets Traffic Directorate (TD), within the Surface Transport Division of Transport for London, is responsible for the management and operation of Londons 6,000 traffic signals and their accompanying systems, technologies and equipment. TD is a centre of traffic engineering expertise and uses traffic modelling in many areas: The Traffic Infrastructure section, which uses operational models for signal design and auditing of signal schemes; The Congestion Management team, which develops models in support of signal timing reviews and carries out audits of models developed in support of schemes; and The Intelligence & Traffic System section includes the Surface Transport core Operational Modelling team, which is responsible for the Model Auditing Process (MAP), provides expert modelling support, assesses new modelling software and manages the Operational Network Evaluator (ONE) assignment model. Part A of these Traffic Modelling Guidelines has been written to give a high-level understanding of traffic modelling as it applies in a TfL context. It is designed to be read by a wide audience, both internally and externally, including non-technical project managers and scheme sponsors. It does not assume any prior knowledge of traffic modelling.
18
Part A introduces the background to traffic modelling in London including an outline of the policy considerations, in particular the Traffic Manager duties, and the need to deliver journey time reliability. It covers the reasons why modelling is appropriate, how modelling should be carried out and who is involved. At the core of Part A the modelling hierarchy and interaction between the different modelling levels is explained. The key requirements to produce traffic modelling to a suitable standard are outlined along with a brief description of the presentation and submission process for modelling. Part A then covers the various factors which should be considered when commissioning modelling to support a scheme. The final chapter introduces a range of traffic modelling software and their applications.
19
2
2.1
20
2.2
Legislative Responsibilities
The Traffic Management Act (TMA) 2004 places a Network Management Duty (NMD) on all Local Traffic Authorities (LTAs) in England. In London, LTAs are the Boroughs and TfL. As Londons strategic traffic authority TfL has both a local and strategic NMD. The NMD requires the LTA to: Ensure the expeditious movement of traffic on its own road network; and Facilitate the expeditious movement of traffic on the networks of others. Guidance was produced by the Secretary for State in 2005, but essentially the NMD requires an authority to manage all their activities in such a way as to minimise congestion on the road network. Each LTA must appoint a Traffic Manager whose role includes ensuring that the NMD is fully considered and applied throughout all the authoritys functions. Because congestion and expeditious movement are subjective terms, TD has produced a more practical network performance measure to help clarify the legislative responsibility. This measure is journey time reliability. TD is responsible for this measure across the Transport for London Road Network (TLRN). Journey time reliability is considered by TfL Streets as a good measure for smooth traffic flow, which is a TfL objective, identified by the Mayor of London and documented within the Mayors Transport Strategy3. The Mayors Transport Strategy was published in May 2010 and is available from http://www.london.gov.uk.
2.2.1
21
TD provides independent technical support to scheme promoters, in the form of a Traffic Signal Supplementary Report (TSSR) to enable FPT to make informed decisions when assessing and reviewing schemes. Paramount in any decision is whether the scheme has a detrimental impact on journey time reliability, which is directly correlated with smooth traffic flow.
2.2.2
22
2.3
23
2.3.1
Strategic
Strategic models typically cover very large areas and model the balance of trips between available modes. In order to manage simulation run times the road network is only modelled at an aggregate level of detail. Traveller demand is usually defined in person trips and is derived from demographic census data and observed trip making behaviour from surveys.
2.3.2
Cordon Area
Cordon area modelling also referred to as Highway Traffic Assignment (HTA) or Tactical modelling is usually commissioned to support major development schemes. This type of modelling is designed to predict the impact of area wide road-based trip diversion and route choice. As an alternative, this type of modelling analysis can be used to conduct an operational assessment to indicate the impact of a short-term change on the network. Junction capacity should be coded accurately to ensure that journey times between nodes, and delay within the model, are representative of onstreet conditions. Mode choice behaviour is not explicitly modelled; however the effect of mode choice can be reflected at this level using derived outputs from higher level strategic models.
2.3.3
Micro-simulation
Micro-simulation modelling is able to simulate the movement of individual vehicles travelling within a road network through the accurate replication of driver behaviour. In this regard micro-simulation modelling is distinct from strategic, cordon area and local models within which all vehicles exhibit a common, uniform behaviour. Microsimulation modelling can be applied across all spatial scales but the size of a model is normally restricted by the amount of data required to generate an accurate simulation. Micro-simulation software typically uses a stochastic modelling approach that provides the capability to assess dynamic phenomena, for example selective vehicle priority. They are able to model the impact of variability upon network behaviour, and are therefore capable of representing complex traffic problems, for example the impact of parking or incidents upon the network.
24
2.3.4
Local Area
Local area modelling handles traffic moving through a localised network, ranging in size from an individual junction to multiple junctions. This level of modelling focuses in detail on the capacity of individual links and junctions, and the interaction between them. A high level of accuracy is required relative to cordon area modelling. Junction design models focus predominantly on individual junctions to allow option testing of modifications to geometric layout and signal staging design. These models are sensitive to small changes in junction layout and/or signal control. Both local area and junction design models cannot predict the impact of driver rerouting, nor can they predict changes in travel mode. These effects are critical to understanding the operation of large road schemes and must be modelled by higherorder assignment or strategic models.
2.3.5
Operational
Dynamic real time traffic control systems are not traditionally classed as traffic models but they operate using similar fundamental principles. Operational systems such as the one used in UTC SCOOT4 optimise traffic signals using an online data model. The optimisation method used is similar to that employed by junction design and local area models. Operational models are coded and validated manually to ensure that accurate capacity estimates are generated. These models commonly use live data inputs from carriageway detectors to make decisions regarding the optimisation of network signal timings.
2.3.6
Model Integration
Information can be shared across model levels in order to improve consistency, although this is a manual process in most cases. Two examples of data sharing are: Junctions within a cordon area HTA model can be calibrated against the more accurate performance calculated by a junction design model. In this way the performance of the cordon area HTA model can be tested against the validated local model and if needed can be adjusted to improve realism; and Strategic or Tactical models produce demand flow data for the future/proposed scenario. This demand data can then be used in the local area modelling to assess the local impact upon the road network. Data exchange is typically conducted multiple times to ensure consistency in model data across different software platforms (see Figure 1).
http://www.scoot-utc.com
25
2.4
Modelling Standards
Successful traffic modelling requires experience on the part of the modelling engineer. Many techniques are acquired through trial and error during the development, calibration and validation process. Therefore some of the finer techniques used in traffic modelling are not documented in software manuals. This is especially true for complex situations where a level of pragmatism is often required. It is therefore useful to provide modelling guidance, aimed at experienced practitioners, to document tried and tested practical modelling techniques. Where applicable, traffic modelling should be conducted according to existing standards of best practice set out by: The Highways Agency in the Design Manual for Roads and Bridges (DMRB)5; and The Department for Transport in Transport Analysis Guidance (WebTag)6. In addition to the guidance and advice set out in the above documents, the Traffic Modelling Guidelines provide the experienced practitioner with advice in the completion of the modelling elements of a traffic signal scheme. The Model Auditing Process7 (MAP) defines the standards expected for all modelling of TfL-sponsored schemes submitted to TD. The Traffic Modelling Guidelines indicate recommended Best Practice relating to the approach and methodology of model development in order to reach those standards. While TD will audit the final scheme models and prepare the TSSR, scheme sponsors and their agents have a responsibility to ensure that all scheme models meet the requirements set out within MAP.
2.5
5 6 7
Design Manual for Roads and Bridges, Highways Agency, 1992 (as updated). http://www.dft.gov.uk/webtag/ TD Model Auditing Process: Traffic Schemes in London Urban Networks, v2.2, Traffic Directorate, Transport for London, 2010.
26
2.6
Modelling Expertise
Lack of experience on behalf of the model developer is a common reason for modelling to not successfully pass through TD scheme audit. The scheme sponsor is advised to ensure that the person(s) engaged to develop the modelling related to any scheme meet the following requirements: Considerable modelling experience with the relevant software; Considerable experience in on-site data collection of traffic control parameters including saturation flows, degrees of saturation, lane utilisation identification and wasted green measurement; A good understanding of the capabilities of microprocessor based controllers, particularly with respect to interstage design and phase delays; and Experience of modelling microprocessor based controllers using modelling products such as LinSig and OSCADY PRO. The skills outlined above must exist as a senior audit function prior to delivery of any traffic modelling for TD.
2.7
2.8
27
The base model is altered to produce a set of future do something scenarios in line with scheme proposals. Proposals may be as a result of infrastructure modification, patterns of traffic growth, a change in traffic composition or a number of other interrelated factors. During the development of future scenario models it is necessary to make assumptions regarding traffic behaviour under new proposals, since these cannot be observed or measured in reality. All assumptions made at this stage should be determined following a logical approach. This approach should draw upon available survey data and observations where possible. Often assumptions will depend on the nature of the scheme proposals, in which case an understanding of the wider project is essential. In order that a TfL Auditing Engineer and Network Assurance Engineer understand the reasoning behind these assumptions, it is necessary to document all assumptions with explicit reasoning. Where used, third-party sources of information should be referenced.
2.9
Modelling Boundary
A scheme may have an influence beyond the boundaries of the physically modified area. The scheme designer is thus responsible for determining the extent of the area of impact. The area to be modelled is determined by the area which is deemed to be impacted upon by the scheme proposal. In order to properly assess the scheme proposals the modelling must cover this area. The scheme designer is responsible for ensuring that these wider impacts are considered, discussed and where appropriate mitigated and that any mitigation forms part of the scheme proposals. Failure to model the area of impact and/or failure to provide mitigation against impact will result in modelling which is not fit for purpose. It is the scheme sponsors responsibility to assure TfL (FPT) that the proposed scheme can be accommodated in the network.
2.10
28
2.11
http://tfl.gov.uk/streetspublications
Scheme Considerations
29
3
3.1
Scheme Considerations
Introduction
Meeting specific objectives is necessary for the success of any scheme. However it is equally important that scheme designers, modellers and traffic engineers consider wider strategic transport objectives.
3.2
Overarching Objectives
All design decisions must be made taking account of the requirements and objectives set out by the following: Mayoral Policy; The Network Management Duty as defined in the Traffic Management Act (2004); and The strategic and policy requirements of the local highway authority.
3.3
Interested Parties
There should be coordination and cooperation between interested parties in the design of scheme proposals.
30
All relevant parties should be consulted before undertaking the design of a new junction, or the re-design of an existing junction. Often a scheme sponsor will have a particular focus; however it is the responsibility of the scheme designer(s) to ensure that all junction users are considered. In addition the scheme designer should contact all relevant authorities, who have jurisdiction over the area being impacted by the scheme, to ensure that any concurrent scheme proposals are taken into consideration.
3.4
Scheme Design
The modelling of proposed schemes is assessed by TfL to ensure that it is correct and accurate. In addition to this role TfL must be satisfied that the proposed scheme design makes full consideration of the objectives outlined in section A3.2. The existence of other proposed schemes could impact on traffic flows, junction layout and signal control. Failure to consider these impacts could result in modelling which would not be fit for purpose. Before undertaking any design or modelling work it is strongly recommended that TD is contacted. The scheme sponsor or their consultant can discuss, with the appropriate TD team, the scope of the proposals and the area they affect. As well as strategic objectives there are many local level considerations. The detailed considerations relating to the design of a scheme are outlined below to highlight some of the key areas for discussion.
3.4.1
Junction Layout
The layout of proposed junctions is determined by a wide range of factors. The final design must comply with the appropriate design standards and safety requirements. It must also deliver the best service for all road users that it is possible to achieve within the physical limitations of the site. Often there will be a number of different junction layouts that comply with design standards and safety requirements. In this situation it is necessary to assess the impact of the different options on network capacity, in order to determine which layout delivers the best performance within any assessment criteria. This assessment is critical within the design process, and accurate modelling is required in order to give confidence to any design decisions. The type of modelling software to be used depends on variables such as the size of the network being assessed and the level of congestion present within the study area.
3.4.2
Scheme Considerations
31
UTC SCOOT is a dynamic, demand-responsive traffic management system which controls approximately 40% of the London traffic signal network. UTC SCOOT is an adaptive real time system which continually optimises signal timings to meet traffic demand. The modelling of UTC SCOOT-controlled signals requires a methodology outlined in section B2: Modelling Principles.
3.4.3
3.4.4
3.4.5
24/7 Operation
Scheme designers and traffic modellers should ensure that any scheme design considers impact at all times and highlights any issues that may arise outside of the traditionally modelled peak periods. Consideration should be given to weekend operation, where traffic demand may be similar to that of a weekday but upon a capacity constrained network, for example through the relaxation of parking, waiting and loading restrictions.
32
The smooth operation of the network 24 hours a day, 7 days a week is becoming increasingly important as travel demand in London expands beyond weekday peak times.
3.4.6
Scheme Safety
Road safety is an area of key concern for TfL. Overall scheme objectives should always consider improvements to road user safety. Changes to operations of junctions can have significant influence on the safety of road users, including pedestrians, cyclists and general vehicular traffic. Better Routes and Places Directorate (BR&P) can advise on best practice for modelling road safety factors within a traffic context. The SAFENET modelling tool was useful for networks but is no longer supported by TRL Ltd9. Old versions can, however, still be used and BR&P can discuss specific scenarios with scheme designers.
http://www.trlsoftware.co.uk
33
4
4.1
4.2
34
Proposed scenario modelling should take account of network alterations which influence route choice. Changes to route choice can be generated by the proposed scheme, local traffic management or other influences which can impact the network during scheme appraisal.
4.3
35
5
5.1
5.2
Assessment of Buses
Correct representation of fixed bus routing within a network is important when building an accurate traffic model. Bus timetables and routing maps indicate the frequency of buses and bus type by time of day. Depending upon the focus of the scheme bus journey times within the network may need to be recorded from site visits in order to measure the accuracy of the public transport element of a traffic model. The type of bus (articulated, single-decker or double-decker) has an impact on junction performance, for example, due to their size articulated buses have a potentially greater impact on junction performance relative to other bus models. It is also worth noting that bus acceleration and general speed are normally lower than for general traffic.
36
5.3
Bus Stops
A bus stop is an on-street location allowing for buses to pick up and drop off passengers. A bus stand is a facility which allows passenger pick up/drop off but also provides for terminating bus services to regulate headways and therefore to stop for a longer period. A bus station is an off-street location which allows for services to begin/terminate, passengers to board/alight and acts as a service interchange. The distinction between bus stops, bus stands and bus stations should be included within survey information. In order to accurately replicate bus journey times it is important to account for stop dwell times for each route using the facility. The dwell time can include buses waiting due to driver rest stops, driver changeovers and layovers used to regulate the bus service timetable. It is useful to consider the interaction with general traffic that occurs when a bus is waiting at a stop, for example the modeller should observe whether approaching traffic can pass a stationary bus or whether they give-way to oncoming vehicles. Designers should consider the physical limitations of bus stops/stands and stations. Vehicle storage capacity can be assessed using scale plans combined with site observations to ascertain exact layout and operation. It is important these facilities are modelled correctly as network performance can be inhibited where bus demand exceeds bus stop storage capacity.
5.4
37
5.5
10 Guidelines for Implementing Bus Priority in SCOOT using iBus System, Transportation Research Group, University of Southampton, 2006.
38
6
6.1
Pedestrian Considerations
Introduction
Pedestrian facilities are provided to assist pedestrians in safely crossing the carriageway whilst exercising due care and attention. There are a number of signalised methods for achieving this and an engineer should consider which of these methods can be best applied to individual sites. In order to assess which method is most applicable it is useful to have knowledge relating to pedestrian flow patterns, vehicular degree of saturation and the topographical layout of the network or junction. Software is available to model the interaction between pedestrians and general traffic at crossing facilities. Using this software it is possible to estimate the impact of pedestrians on road network performance or a new traffic scheme on pedestrians. Advice on pedestrian modelling using the Legion software product is covered by the TfL document Street Level Modelling with Legion Best Practice Guide11. Pedestrian models are particularly useful where proposed changes to land use or public transport provision may result in changes to pedestrian flows. Pedestrian behaviour may be affected by changes in total volume of people or their desired route. The results from pedestrian modelling can therefore be used to mitigate these issues and assist in designing appropriate signal schemes.
11 Street Level Modelling with Legion Best Practice Guide, Directorate of Road Network Performance, Transport for London, 2008.
Pedestrian Considerations
39
The design of pedestrian facilities is governed by engineering standards produced by the Department for Transport (DfT). For facilities within London there is additional guidance and standards set out in the TfL document Design Standards for Signal Schemes in London (specification SQA-0064)12. The SQA-0064 document provides essential guidance for traffic modellers involved in the assessment of pedestrian crossing facilities in London. SQA-0064 outlines minimum approved pedestrian crossing times based on crossing distance. All schemes which impact signalised crossings, regardless of whether the proposals physically affect the signal junction, are required to include as part of the scheme a review of all signal crossings to ensure they meet the standards as outlined in SQA-0064.
6.2
6.3
12 Design Standards for Signal Schemes in London, Specification SQA-0064, Issue 1, Directorate of Traffic Operations, Transport for London, 2007.
40
6.4
6.5
Pedestrian Considerations
41
6.5.1
Full Pedestrian
It is believed there are associated benefits to operating a full pedestrian strategy at a junction: Reduced journey time for pedestrians; Increased safety with easier pedestrian understanding; and The junction can cater for a higher number of preferred pedestrian routes. Conversely, practitioners have noted a full pedestrian strategy can pose problems as all vehicular approaches are delayed for longer periods to clear pedestrians from the junction. The increase in delay associated with full pedestrian strategies can generate greater congestion for all other road users apart from pedestrians. In a group of coordinated junctions the common cycle time may be higher than ideal at other junctions which results in increased pedestrian delay. It is also worth noting that higher levels of congestion can increase vehicular emissions with consequent impacts on health so a balance must be sought between competing road users.
6.5.2
Parallel Pedestrian
An alternative to a full pedestrian strategy is to provide parallel pedestrian facilities. This is most easily achieved using staggered crossings where non-conflicting pedestrian movements can operate at the same time as traffic movements. Parallel pedestrian strategies remove the need to simultaneously hold all vehicular approaches to a junction on red. A parallel strategy can improve the performance of the junction by increasing the flexibility by which a traffic signal engineer can reduce delay for particular approaches.
42
7
7.1
Cyclist Considerations
Introduction
The number of cyclists in London is growing, especially during peak periods, and on significant cycle commuter routes often exceed 10% of total vehicle flow13. A growth in cycling is integral to the Mayors vision for London so it is important to consider the role and impact of cyclists upon the network. The magnitude of impact is normally a function of the number of cyclists as a percentage of total traffic. The traffic modeller should consider carefully the effect of a proposed scheme on cycling (and any growth in cycle demand) before selecting the best software for the modelling exercise.
7.2
Junction Design
Schemes are advantageous to cycling if they help cyclists to maintain a steady speed and a direct course without interruption or obstruction from a position where they can be seen by drivers and pedestrians. For this reason the cyclist user experience can benefit from specialist provisions within a scheme. Cycle safety may be improved through the use of Advanced Stop Lines (ASLs), widened carriageways or dedicated
13 London Cycling Design Standards A guide to the design of a better cycling environment, London Cycling Centre of Excellence, Transport for London, 2005.
Cyclist Considerations
43
cycle-lanes. In schemes where specialist provisions are proposed it is important to model the impact that these will have on all road users including public transport. ASLs allow cyclists to position themselves at the front of queuing traffic where they are able remove themselves from conflict with general traffic. Where a scheme predicts a large number of cyclists an ASL can be assessed by traffic modelling. Consideration should be given to providing cycle feeder lanes to ASLs which allow easy access and safer cyclist progression within the carriageway. Further guidance on cycle design can be found in Chapter 4 of the London Cycling Design Standards13.
7.3
Inclusion of Cyclists
The volume of cyclists has a direct impact on the ability of traffic models to accurately represent their influence on network performance. As volume increases, their impact on general traffic behaviour generates issues that can require detailed assessment14. Where the volume of cyclists exceeds approximately 20% of the traffic volume on any one approach they may have a disproportional effect on modelling results and their influence may need further attention15. For this reason it is encouraged to ensure classified traffic surveys explicitly include cyclists. Micro-simulation traffic modelling software is often capable of modelling basic cyclist behaviour. Care should be taken to ensure any model accurately represents both cyclist speed and vehicle overtaking behaviour. Where an engineer uses deterministic traffic modelling software the modeller can only reflect the aggregate impact of cyclists by directly modifying parameters which influence junction performance.
14 Carrignon D, Assessment of the impact of cyclists on heterogeneous traffic, TEC Magazine, July 2009, pp323-325. 15 Mixed Traffic Conditions in Parliament Square Cyclists Impact Assessment Report, London Cycling Centre of Excellence, Transport for London, July 2008.
44
8
8.1
45
Airborne particulate matter. Different metrics are used to define particulate matter17, the most common being PM10 and PM2.5. Greenhouse gases which have an effect on the global environment. The most important of these, due to the total volume of production, is carbon dioxide (CO2). Other pollutants, such as methane (CH4) and nitrous oxide (N2O), are stronger greenhouse gases but are emitted in smaller quantities and are not a focus for TfL. Road traffic is one of the largest sources of CO2. Around 44 million tonnes of CO2 are emitted in London each year, and road transport accounts for 22% of the total production18. The Mayors Climate Change Action Plan sets out a path for the delivery of Londons CO2 targets. In order to meet the Mayors targets CO2 emissions must be reduced by 60% by 2025 (compared with 1990 levels). It is the statutory responsibility of each local authority in the UK to carry out a review and assessment of air quality in its area, and to work towards meeting the objectives defined by the National Air Quality Strategy (NAQS). At locations where it is unlikely that the NAQS objectives will be met, local authorities must declare Air Quality Management Areas (AQMAs), carry out comprehensive monitoring, and develop mitigation plans. As of March 2007, 31 out of the 33 local authorities in London had declared AQMAs. In most cases road traffic has been the principle reason for the AQMA. Indeed, road traffic is the main source of NOx and PM10 in London. Clearly, the efficient management and control of road traffic can play an important role in reducing the emissions of air pollutants. In London, the local authorities and TfL should refer to The Mayors Air Quality Strategy19.
8.2
TfL Objectives
The TfL Surface Transport strategic environmental goal, as set out in the document The Way Ahead20, is to reduce carbon dioxide emissions, to improve air quality, to reduce noise pollution, and to enhance the urban environment. TfLs overarching environmental objectives are divided into three tiers which reflect their importance and the degree to which TfL has an influence upon them:
17 PM10 and PM2.5 relate to particulate matter with a diameter of less than 10 m and 2.5 m respectively. 18 Action Today to Protect Tomorrow The Mayors Climate Change Action Plan, Greater London Authority, 2007. 19 Cleaning Londons Air - The Mayors Air Quality Strategy, Greater London Authority, 2002. 20 The Way Ahead Surface Transports Strategic Direction, Transport for London, 2007.
46
Tier 2
To reduce resource consumption and improve green procurement; To maintain and, where possible, enhance the quality of Londons built environment; To reduce the waste generated by TfLs activities by applying the principles of Reduce, Reuse, Recycle; and To promote the sustainable transport of waste.
Tier 3
To maintain and, where possible, enhance the quality of Londons natural environment; and To reduce consumption of water resources and implement efficiency measures.
47
9
9.1
48
9.2
9.2.1
21 http://www.jctconsultancy.co.uk 22 http://www.trlsoftware.co.uk
49
9.2.2
9.2.3
Networks
In congested urban areas it is necessary to coordinate the movement of traffic in order to generate reliable, repeatable performance. The efficient control of vehicles in a network is usually promoted through the use of linked traffic settings. The most efficient traffic control strategy for an area will be defined by factors outlined in section A3. The optimum settings for coordinated control will vary according to time of day and day of week and for this reason they are usually derived from deterministic network models. This empirical approach approximates network performance based on fixed input variables and thus can provide an engineer the means of controlling urban congestion by minimising vehicle delay. There are two main packages used for the optimisation and evaluation of network signal design TRANSYT and LinSig. TRANSYT TRANSYT, produced by TRL, is widely used for modelling signalised networks within the UK. It is capable of developing optimum fixed signal settings for representative traffic conditions within a network. The development of these settings requires average traffic data to be collected and analysed for each modelled period and placed into an abstract network of links and nodes. TRANSYT optimisation is conducted using an iterative hill climb algorithm which attempts to find optimal signal settings which minimise stops and delay in the network. TRANSYT can be used to optimise a wide variety of networks, from unsignalised intersections to signalised roundabouts. TRANSYT can also be used in conjunction with micro-simulation models, for example a linking product has been developed to communicate with VISSIM (see section A9.3).
50
TD currently believes TRANSYT is suitable for signalised networks which share a common cycle time. LinSig LinSig, produced by JCT Consultancy, can model and optimise networks of several junctions as well as individual junctions (see section A9.2.1). It is designed to model small groups of junctions in detail rather than larger networks, although the latest versions support multiple controllers. It is comparable in approach to TRANSYT but represents the network as a series of geometrically conjoined lanes rather than abstract links. Recent versions have introduced network modelling tools such as delay based traffic assignment and entropy based trip matrix estimation, to provide the signal optimiser with traffic data. TD currently believes LinSig is suitable for small urban networks consisting of signalised junctions which share a common controller.
9.3
Micro-simulation Models
Micro-simulation software is able to model the movements of individual vehicles travelling within road networks. They enable realistic representations of driver behaviour such as lane changing and overtaking. In this regard they are distinct from the models outlined in section A9.2 which use an aggregate representation of traffic where all vehicles exhibit uniform behaviour. Micro-simulation packages do not yet have the ability to optimise traffic signal settings, therefore software such as TRANSYT and LinSig are commonly used in conjunction with micro-simulation modelling. When compared to deterministic models the finer resolution and stochastic approach of micro-simulation software allows better representation of driver and therefore network behaviour. They are the only tools capable of representing complex traffic problems in an offline environment, for example the impact of parking or network incidents. In addition most micro-simulation packages are capable of generating graphics which animate individual vehicles within a network. As a result microsimulation modelling can provide an excellent visual aid when presenting complex traffic phenomena to a non-engineering audience. Micro-simulation models are useful when modelling heavily congested conditions where a network suffers poor performance due to excess queuing from adjoining junctions. In networks where significant congestion is expected, micro-simulation models are likely to accompany an empirical model outlined in section A9.2. The boundary of a micro-simulation model should encompass the extent of the impact of the scheme so may extend further than the boundaries of any accompanying empirical model. The most widely used traffic micro-simulation software within London are VISSIM23 and S-Paramics24, and to a lesser extent AIMSUN25.
23 http://www.ptvag.com 24 http://www.sias.com 25 http://www.aimsun.com
51
TD currently has most of its modelling expertise concentrated in VISSIM. To ensure that analysis, audit and impact assessment can be carried out as quickly as possible TD recommends VISSIM when consultants are building micro-simulation models for TfL Streets. TD can accept micro-simulation models developed using S-Paramics or AIMSUN; however there is not sufficient expert familiarity within TD NP to enable internal model audits and assessment. VISSIM VISSIM, developed by PTV AG, specifically models traffic in urban areas. Vehicles are controlled by psycho-physical parameters defined within a complex traffic model. The parameters controlling vehicle behaviour are verified by PTV using calibrated research conducted at the University of Karlsruhe. VISSIM allows a modeller to implement complex, dynamic forms of signal control, replicating equipment from different manufacturers, and can simulate pedestrian characteristics according to a dedicated social forces behavioural model. VISSIM is a multipurpose simulator with a wide range of applications. The modelling of individual vehicles has allowed VISSIM to become a proxy for realworld scenarios. This has been formalised through the development of an interface between Londons traffic control system and VISSIM26 which allows faster than real time offline testing of traffic management measures.
9.4
Assignment Models
For schemes with considerable or wide-reaching network impacts a highway traffic assignment model can be used in conjunction with the modelling packages outlined in sections A9.2 and A9.3. It is normal for successive iterations to be required with local area models in order to assess the impact of a scheme on traffic volumes and driver route choice (see section A4.3). VISUM23 and SATURN27 are the two packages used by TfL for highway traffic assignment modelling in London. VISUM is developed by PTV AG as a system for travel demand modelling, transportation planning and network data management. It is principally designed for multi-modal analysis which integrates modes of transportation into a single network model. SATURN is a suite of programs developed by the Institute for Transport Studies at the University of Leeds. It is a combination of network analysis programs that combine traffic simulation and traffic assignment to analyse the impact of traffic management on a regional, sub-regional and local scale. A consistent base assignment model should be used for major scheme assessment in London. TfL has produced a set of sub-regional and central London SATURN models which are specifically designed for this purpose. Scheme sponsors and their consultants should contact TfL Policy Analysis for further information.
26 Cottman N, Giszczak A & Jackman G, Desktop traffic control for London: developing UTCVISSIM interface, TEC Magazine, January 2009, pp41-45. 27 http://www.saturnsoftware.co.uk
Introduction to Part B
55
Introduction
TfL Streets Traffic Directorate (TD) is dependent on comprehensive modelling and supporting information from clients (including Boroughs and TfL departments) and consultants in order to effectively design, assess, implement and operate traffic schemes. Appropriate, comprehensive and accurate modelling is necessary to ensure traffic schemes are: Assessed for impacts and benefits; Effectively designed to satisfy an objective; Clarified to avoid confusion or misinterpretation of the design; and Effectively and efficiently implemented and operated. Part B of the Traffic Modelling Guidelines contains technical advice relating to modelling best practice. The first chapter entitled Modelling Principles covers general topics which are common to all types of traffic model. It is recommended that all model developers producing a traffic model within the London area familiarise themselves with the Modelling Principles chapter prior to commencing model development and irrespective of the particular software they intend to use. Part B of the Traffic Modelling Guidelines assumes the reader has an awareness of basic traffic engineering principles, covering traffic signal control, traffic flows and traffic surveys. Specific concepts and terminology that should be understood include
56
phase minima, phase intergreens, phase delays, stage minima, interstage design, cycle time, offset, saturation flow, degree of saturation (DoS), stopline flows, manual classified counts and demand flows. This level of awareness would typically come from introductory courses to traffic signals and industry-standard software packages, combined with experience in the traffic engineering/transport planning field. The remainder of Part B is organised into chapters appropriate to different types of modelling software. The model developer can refer to individual chapters for relevant guidance on the modelling software being used for a specific project. If there are any specialist competencies relating to particular modelling software, these will be stated in the chapter for that package.
Modelling Principles
57
Modelling Principles
This chapter contains key information which should be read and understood by anyone undertaking traffic modelling. The key areas that will be covered include: Model Definitions; Model Auditing Process; Network Familiarisation; Data Acquisition; Model Development; Proposed Model Optimisation; and Model Reports. All model developers are encouraged to familiarise themselves with Part A of the Traffic Modelling Guidelines to ensure that the considerations outlined there will be met by any proposed model.
2.1
Model Definitions
Before building a traffic model it is appropriate to define what is meant by the term model in its most general form: A model can be defined as a simplified representation of a part of the real world ... which concentrates on certain elements considered important for its analysis from a particular point of view.28
28 Ortzar J de D & Willumsen L G, Modelling Transport, 3rd Ed., Ch1, Wiley, London, 2001, p2.
58
It is important to be aware of the simplifications that are made in creating a model and to understand whether they have any significance for the intended analyses. Simplifications can be made by the modeller, either deliberately or inadvertently, during model development or calibration, or can be inherent to the particular choice of modelling software used for a project.
2.1.1
Model Scope
The development of a clear brief can prevent ambiguity and increase the likelihood of producing fit for purpose traffic models. It is important to define the intended purpose and therefore scope for which the traffic model is to be developed. The model developer should be made fully aware of this purpose in order to ensure that the final modelling meets the required criteria. A purpose statement is developed during Stage 1 of the Model Auditing Process (MAP), as discussed in B2.2, to ensure all parties have agreed the scope of the modelling requirements associated with a proposal. The scope of the model will therefore determine which modelling outputs are required from a proposal. A base, proposal and on-street timing traffic model may be created when advancing a proposal from initial design to final on-street implementation (as discussed in section B2.5). It may also be necessary to establish consensus regarding a preferred optimisation strategy and the software required to complete any agreed modelling methodology. The scope of the traffic model as defined in MAP Stage 1 should be clearly stated in accompanying reports and in any discussion or reference to results obtained from the model. The developer should also relate decisions made in the models development process to the requirements of the model, as defined by its purpose.
2.1.2
Base Model
A base model is a model that has been demonstrated to accurately recreate traffic conditions as observed and measured on-street. It should be suitable for use in analysing current network performance and as a benchmark against which other modelling scenarios can be tested.
2.1.3
Proposed Model
A proposed model is a validated base model that has been modified to take account of proposed network changes. These changes can include physical layout, signal timings or predicted developments in traffic demand. By comparing proposed modelling to the original validated base model, the impact of the proposed changes can be determined, allowing informed decisions to be taken based on those impacts. A proposed model may also be modified to verify the signal timings required for onstreet implementation. Where required by project scope, the modified model will indicate exactly how the signalised facility will operate in a microprocessor signal controller under local or central control (see B2.4.9).
Modelling Principles
59
2.2
29 TD Model Auditing Process: Traffic Schemes in London Urban Networks, v2.2, Traffic Directorate, Transport for London, 2010. 30 http://tfl.gov.uk/streetspublications
60
Each stage has unique requirements, as outlined in the documents, however the administration process for dealing with the submission and the communication associated with each stage remains the same. MAP also defines six key roles: Promoter (P): The person responsible for delivering and project managing the proposal. The client for a scheme; Design Engineer (DE): The engineer responsible for creating the modelling for the Promoter. Normally a consultant traffic engineer engaged by the scheme Promoter; Checking Engineer (CE): The engineer responsible for checking and signing off the Design Engineers work as fit for purpose for the Promoter. This is typically a senior consultant traffic engineer engaged by the scheme promoter; TD Signals Auditing Engineer (SAE): The engineer responsible for checking and safety approving the signal infrastructure elements of the proposal. The role is usually undertaken by an experienced signals engineer from within TD TI; TD Model Auditing Engineer (MAE): The engineer responsible for auditing the modelling and assessing the network impact of the scheme. A function usually filled by an experienced signals engineer from within TD NP; and TD Network Assurance Engineer (NAE): The engineer responsible for assessment, then approval/rejection of the Promoters proposal (under the Traffic Management Act). A responsibility fulfilled by an experienced FPT engineer from within TD. For MAP Stages 2, 3 and 5, there are check sheets to be signed off by the DE, the CE and the TD NP MAE. The following key points should be noted: All model submissions should be version controlled; All model submissions should be internally audited by the CE prior to submission; and All formal correspondence and submissions to TD should be sent to the TD MAP Coordinator (TDNPModelling@TfL.gov.uk).
2.2.1
Modelling Principles
61
The model developer accepts responsibility to ensure that the modelling they produce is fit for purpose.
2.3
Network Familiarisation
Before commencing any modelling work or measurement of site data, it is important for the modeller to familiarise themselves with the area to be modelled. It is useful to identify the following information: TfL site number(s). All requests should be directed to the TfL TD Site Data Manager via SFMdatamanagement@TfL.gov.uk; UTC group/region number (if applicable, obtained from TD NP); Time period(s) under consideration; and Date(s) when traffic flow data was collected, if available. The following section details some initial steps that should be taken by the modeller in order to familiarise themselves with the area to be modelled.
2.3.1
Model Boundary
A traffic model should assess the full impact of a scheme on all road users over the impacted area. In general the model boundary should encompass the area within which traffic flows, journey times or delays will be significantly affected by the implementation of the scheme or proposed intervention. This should be agreed during MAP stage 1 for TRANSYT and VISSIM models, as described in B2.2. The impact of a scheme on the surrounding network must be modelled, not simply the individual junction(s) or area of works proposed in the scheme. The model boundary should initially be a matter of judgement by the modeller but should be revised at the outset after consultation with TD. For guidance the model boundary should include junctions that meet any of the following criteria: Traffic flows are expected to change significantly as a result of the proposal; Include proposed physical changes to the road network; Include proposed changes to operation of traffic control; and Are expected to suffer exit-blocking as a result of the proposal or changes to local traffic control strategy. If the model area is part of a CLF or UTC group with a proposed change in cycle time then the whole operational group must be included in any modelling. If there is no proposed change to cycle time then the whole group does not have to be included provided none of the above criteria are met by adjacent junctions to the proposal. It is recommended that Stage 1 meetings occur prior to the scheme being registered on the TD Workbook. This will ensure that all TD requirements are captured by the Promoter and the Design Engineers prior to development of the scheme design.
62
Where the following issues are deemed important to the client it may be necessary to consider use of a highway assignment model, alongside traditional traffic modelling: Routes currently being used, or likely to be used in the future, by traffic will be affected by the scheme; The scheme will provide significant relief to areas; The scheme will generate extra traffic in areas that may be significantly affected; The impact of changes in traffic levels, on both existing and new or improved roads in the area, needs to be assessed; and Economic benefits are to be assessed over the area impacted by the scheme.
2.3.2
Site Paperwork
Once model boundaries have been defined and a list of TfL site numbers has been obtained, the following paperwork should be consulted for all signalised facilities: Current TfL Controller Specifications and Signal Timing Sheets, which detail phasing, method of control, intergreens, phase minimums and phase delays along with other pertinent information relating to the site; Site Layout Drawings (SLDs), detailing junction layout, lane markings and site equipment; and where appropriate SCOOT Link Diagrams, showing link and node structure for SCOOT regions. Detailed drawings, maps and aerial photographs can be used to determine site layout. However, a site visit must be carried out to confirm the accuracy of any material used.
2.3.3
Modelling Principles
63
One of the most useful online tools comes in the form of street-level panorama photography, showing a drivers eye view of the road network using imagery taken with 360 cameras. Examples of these include Google Maps, Streetview and Seety. Using online data sources modellers can quickly check vast amounts of data during model development, from lane markings and parking restrictions to the specific details of road geometry or signage. However, online data sources should not be viewed as an alternative to site visits as material may be out of date and not representative of current on-street conditions. Instead, they offer useful supplemental information which can be confirmed later during site observations.
2.4
Data Acquisition
Once familiar with the modelled network it is necessary to collect the relevant information required to generate an accurate traffic model. Without accurate data a model cannot be correctly developed, calibrated or validated. A common cause of inaccurate data is a lack of understanding and experience on behalf of a person conducting a survey. On-site measurement should be conducted by an experienced traffic engineer who possesses a thorough understanding of modelling concepts and accepted survey methods, as well as experience of developing traffic models.
2.4.1
64
The above list is not exhaustive. Additional time periods may be required depending on specific traffic patterns and flow profiles. The start time and duration of each time period will also vary. When determining a programme for traffic surveys and other site data collection, the modeller should consult with the TfL London Streets Traffic Control Centre (LSTCC) to check that normal traffic control conditions are expected during the planned times for the traffic survey/site visit. This should also be confirmed once on-site. Contingency dates should be set aside in case the scheduled survey has to be cancelled. The LSTCC information desk can be contacted on 020 3054 3096, or via email at LSTCCinformationdesk@TfL.gov.uk.
2.4.2
Site Visits
All models are developed using calibration data, which needs to be collected in the form of site observations and on-street parameter measurement. The quality of the final model, and any analysis derived from it, depends on the data used during model development. The consistent collection of data is paramount in ensuring the accuracy of any traffic model. Data on its own does not provide enough information to develop an accurate model. The correct interpretation of the data requires a thorough understanding of on-site conditions. This understanding can only be acquired through visiting the site. The engineer developing the model should personally visit the site during each period for which a model is being developed. These site visits should include the collection of some of the more complex information which can only be undertaken by an engineer with the appropriate knowledge and experience. As described in sections B2.3.2 and B2.3.3, it is important to verify the accuracy of any drawings or aerial photography used during model development, to ensure their content accurately represents current site layout and appearance. Site-specific parameters should also be recorded for all periods of the day for which the models are being prepared. Common examples of data that can be noted or measured during site visits are: Date, time of day and day of week; Junction/network layout; Link lengths, lane widths and pedestrian crossing distances; Lane/road markings and usage; Cruise times; Saturation flows; Give-way behaviour; Vehicle and/or pedestrian spot counts; Right-turner storage and blocking effects; Flare lengths and usage;
Modelling Principles
65
Vehicle usage of the flashing amber period at Pelican crossings; Fanning and funnelling; Exit-blocking; Bus lanes, hours of operation, bus stop locations and bus stop dwell times; Car parks, street parking and interference during parking manoeuvres; Restrictions on the network (parking/stopping/loading, etc); Speed limits; Roadworks and other incidents, and their impact; Degree of saturation; Journey times (for both private and public transport); and Queue lengths (if required). Whilst many of these parameters can be measured in quantifiable terms, it is also important to record general site observations that capture more subtle behaviour exhibited within the study area. It can be useful to note where traffic behaviour does not reflect street markings or the intended geometric design of a junction, for example where ahead moving vehicles use a dedicated left-turn lane. When measuring data it is necessary to obtain a sufficient number of measurements to give confidence that average values are representative. If practical an average of ten measurements may typically be used. In some cases fewer measurements may be appropriate (e.g. when recording link lengths and crossing distances), and in other cases a higher number of readings may be required, for example where a large variation in values is obtained. Many parameters are time dependent, and should therefore be recorded for each period being modelled, such as effective flare usage which can vary at a site according to differing traffic patterns.
2.4.3
66
In some cases it may be acceptable to use flow-factoring techniques, based on flows recorded during another representative peak, but authorisation should be sought from TD NP MAE before applying this technique. Site visits should be carried out during traffic count surveys to collect pertinent calibration and validation data and ensure site conditions remain typical. These visits are important as journey time, degree of saturation and queue length surveys should ideally be conducted while traffic counts are taking place. Multiple factors, such as traffic management, may have a bearing on survey results and it is important that these are identified in addition to the usual weather and incident reports provided by survey companies. Classified turning count surveys have inherent limitations. Before they are used in a model, a check must be made to see whether traffic leaving one junction arrives at neighbouring junctions. If there is a discrepancy of more than five percent between junctions the modeller should augment the classified counts with short site surveys to determine if there are other major sinks and sources of traffic (e.g. side roads, car park entry and exits) that were not captured in the original survey. If sinks or sources are found, 15-minute spot counts should be conducted to estimate hourly flow rates. Where a discrepancy exists and no sinks or sources are discovered, a 15-minute spot count can be conducted to compare with surveyed flows to see if the original counts are reasonable. To get an accurate spot count, it is recommended that the flow is recorded over a whole number of completed cycles. Analysis of traffic flows across the network as a whole may highlight a particular count site as being in error, for example, if flows at neighbouring survey sites are inexact by a similar value. Where a manual counting error appears to have been made, a general rule is to take the larger flow count from adjacent survey sites as being accurate, as it is more common for errors to result in under-counting than over-counting. This also represents the worst case as far as the network is concerned, as the largest observed flow will be modelled. The TD Performance and Research team (trafficdata@TfL.gov.uk) maintain additional traffic count data for TfL. Sources of data include: TfLs Ad-Hoc Count Database, containing counts performed by the TfL Traffic Survey Team and other stakeholders; TfLs Cordon and Screenline data, part of an ongoing programme of surveys on the central, inner and boundary cordons and the Thames, northern, peripheral and radial screenlines; and TfLs permanent automatic traffic and pedal cycle counter sites.
Modelling Principles
67
Table 1: Passenger Car Unit (PCU) values for various vehicle types. Vehicle Type Pedal Cycle Motor Cycle Passenger Car Light Goods Vehicle (LGV) Medium Goods Vehicle (MGV) Buses & Coaches Heavy Goods Vehicle (HGV) Articulated Buses PCU Value 0.2 0.4 1.0 1.0 1.5 2.0 2.3 3.2*
* Recent research conducted for TfL has suggested this to be an appropriate PCU value for articulated buses36. Where cyclists are present, their volume can have an impact on the calibration and validation of traffic models. As the volume of cyclists change, their impact on traffic behaviour varies in a non-linear manner. It is not appropriate to assign a common PCU value to cyclists where a significant proportion of cyclists and powered two-wheelers are present, as where their volume exceeds approximately 20% of the total volume on any one approach this may have a disproportional effect on modelling results37.
2.4.4
36 Optimising Capacity PCU Factors for Different Vehicle Types, Draft Research Report. Transport for London, 2009. 37 Mixed Traffic Conditions in Parliament Square Cyclists Impact Assessment Report, London Cycling Centre of Excellence, Transport for London, July 2008.
68
acceptable to measure cruise times for vehicles travelling in the opposite direction but this should be noted in accompanying technical reports. Full link measurements cannot be made when the downstream stopline is not visible (e.g. due to a bend or long link). In this case the measurement can be divided into segments using an arbitrary reference point, with segment journey times summed to obtain a total journey time for the link as a whole, or two surveyors can collaborate to chose a particular vehicle and communicate progress along the link between stoplines. It is recommended that ten typical readings are taken to obtain a mean average.
38 Design Manual for Roads and Bridges, Volume 13, Section 1, Part 5, Chapter 11, Department for Transport, 2002.
Modelling Principles
69
2.4.5
Flared Approaches
A flare represents a lane at a stopline that is fully used for only a proportion of the green time, even during fully saturated conditions. A flare therefore only contributes to stopline capacity for a limited period at the start of green, after which it provides no further benefit. A flare can be physical (e.g. increased road space due to widening of the carriageway before a stopline), or effective (e.g. termination of a bus lane or parking area before the stopline). Flares are a common source of modelling error, therefore consideration should be given to if and how they should be modelled. Flare length utilisation must be considered according to the proportion of vehicles using the flare, and effective flare lengths should be entered into deterministic traffic models rather than physical lengths. This data must be collected on-site, as identified in section B2.4.2. Only in circumstances where data cannot be collected on-site should the JCT software LinSat be used to estimate effective flare length usage. The use of LinSat should be highlighted in any accompanying model reports.
2.4.6
70
recorded (in seconds) during site observations for each peak period being modelled. It is recommended that ten readings are taken on-site to obtain a mean average.
2.4.7
Saturation Flow
Saturation flow represents a key measurement of on-street performance and thus the values used within a model must accurately reflect the built environment. Saturation flow, measured in PCU/hr, can be defined as: the maximum flow, expressed in passenger car units (sic), that can be discharged from a traffic lane when there is a continuous green indication and a continuous queue on the approach. 39 Saturation flow is an expression of the maximum capacity of a link as predominantly determined by junction characteristics (geometry, layout, turning radii, visibility etc). The saturation flow input for a model should generally not be altered between models or modelled periods unless physical characteristics are modified, such as changes within a proposed model. Saturation flows should only be altered for each time period where a lane shares more than one turning movement, and site observations have noted that flow patterns vary significantly across the day. Saturation flows are normally required for each individual lane that is modelled, although multiple lanes can be combined into a single measurement if they perform identically in terms of flow, vehicle destination and queue behaviour. Where fully saturated traffic appears to discharge at a rate less than the saturation flow (e.g. due to driver behaviour or exit-blocking), this should not be accounted for by changing the saturation flow in a model. Instead, it is recommended that Underutilised Green Time (UGT) is used to quantify this behaviour, as explained in section B2.4.8.1. It is important that saturation flows are measured accurately. Incorrect saturation flows represent a common source of error which can cause delay during model auditing. It is recommended that a minimum of ten typical readings are taken to obtain a mean average, and that the minimum length of each measurement should be 12 seconds40. Measurements should be conducted using vehicles discharging across the stopline in free-flow and thus unaffected by downstream interference such as congestion or exit-blocking. Conditions need to be sufficiently busy that the link is saturated for an adequate period to allow measurement. The surveyor should be able to recognise the end of saturated conditions during each cycle. In some cases, due to insufficient flow or short green periods, it will not be possible to measure a minimum of 12 seconds of saturated conditions at any time of day. In these circumstances shorter measurements can still be recorded but should be identified in accompanying reports for the TD NP MAE, and their validity should be scrutinised by the CE.
39 Salter R J & Hounsell N B, Highway Traffic Analysis and Design, 3rd Ed, Macmillan, 1996, p292. 40 Binning J, Traffic Software News, TRL, September 2007, No. 43, p2.
Modelling Principles
71
Saturation flow measurements should not include periods of lost time at the start and end of green, as these represent time during which vehicles are accelerating or decelerating and therefore not moving at saturation flow. Lost time parameters can be calculated, but it is unlikely exact values will be known unless recorded using a dedicated survey, it is therefore acceptable to use a default of two seconds start lost time and no end lost time. A common technique to account for start lost time is to ignore the first two vehicles to cross a stopline before recording saturation flow measurements. This prevents accelerating vehicles being counted towards measurements and therefore underestimation of the saturation flow. Situations may occur where satisfactory saturation flow measurement is not possible, for example due to insufficient traffic flows, green time or queuing. These should be assessed on a case by case basis, and identified along with an explanation on the method used to estimate saturation flows. An example method for estimating saturation flow using RR67 is explained in B2.4.7.1.
41 Kimber R M, Macdonald M & Hounsell N B, The Prediction of Saturation Flows for Road Junctions Controlled by Traffic Signals, Transport and Road Research Laboratory, Department of Transport, Research Report 67, 1986. 42 Webster F V & Cobbe B M, Traffic Signals, HMSO, Road Research Technical Paper No. 56, 1966.
72
2.4.8
Degree of Saturation
Degree of Saturation (DoS) is a key parameter for validating traffic models. It is advisable that all traffic engineers have a thorough understanding of DoS and how to accurately measure it on-site. Intrinsic to this understanding is knowledge of the different factors that can influence DoS, both on-site and in a model. This subsection describes the methodology recommended by TfL for measuring DoS. The method is designed to account for Underutilised Green Time (UGT), as defined in section B2.4.8.1, which can be calculated from DoS measurements. A DoS survey should be conducted on all critical approaches for each modelled period. In order to achieve an overall measurement that is representative, data sampling should be distributed across the whole of each period during which DoS is being measured. As described in B2.4.7, multiple lanes can be combined into a single measurement if they behave identically in terms of flows and queuing. To calculate DoS the surveyor is required to measure the period of full traffic demand. Recognising full traffic demand can require experience as at times a gap may develop between vehicles even though full demand is still present, for example where slow moving traffic approaches a stopline but individual vehicles accelerate at different speeds. The surveyor is required to record the time from the beginning of green until the end of full demand, during which they record the number of PCUs that cross the stopline. The end of full demand occurs when there is no further traffic queuing or flowing at the stopline across all lanes being measured.The surveyor then records the number of PCUs that cross the stopline during any subsequent period of low demand. The number of PCUs must be recorded separately during each period of differing demand type. Finally the total length of the green period should be recorded. In summary the following information should be recorded: Time at start of green; Time at start of full demand (if different from start of green); Number of PCUs crossing stopline during full demand; Time at end of full demand; Number of PCUs crossing stopline during low demand; and Time at end of green. This process should be repeated ten times in order to obtain a mean average suitable for model validation. However, for sites which experience large variations in flow it may be necessary to record more samples to generate a representative value.
Modelling Principles
73
pass the stopline during a green period. UGT is measured in seconds per cycle and is calculated from data recorded during DoS measurement. UGT is comprised of two elements: Wasted Green, which describes the period of a cycle during which an approach experiencing full demand receives a green signal but traffic is unable to progress across the stopline, for example due to downstream exit-blocking; and Sub Saturation Flow, which describes the period of a cycle during which an approach receiving a green signal does not fully utilise the available capacity, i.e. for vehicles to proceed at saturation flow. This effect can be caused by a number of factors such as driver behaviour, signal offsets or downstream congestion. At times traffic experiencing sub saturation flow may only be travelling marginally slower than would be the case during unrestricted saturation flow. This may not be noticeable to an on-street observer but its impact will be captured by UGT during data processing. UGT is calculated to quantify situations where congestion-related issues prevent fully saturated discharge. It is derived in a form that can be directly applied to available green time in traffic models such as TRANSYT and LinSig by utilising dummy staging, phase lags and/or bonus green. If a negative UGT value is encountered it may indicate that the initial saturation flow measurement was inadequate and that further measurements are required. A negative UGT value highlights traffic that has been observed to discharge at a rate greater than the measured maximum saturation flow during a DoS survey. Figure 2 illustrates a flow profile measured on-street for a link in two different scenarios. The blue curve shows a flow profile for a stopline during non-congested conditions. The orange curve shows a flow profile for the same stopline, but under congested conditions. The shaded area between the curves therefore represents the reduction in flow across the stopline due to congestion.
Saturation Flow
Flow (PCU/hr)
Time (s)
Figure 2: Flow profiles showing normal (blue) and congested (orange) conditions.
74
Figure 3 illustrates how the shaded area, equal to that in Figure 2, represents the difference in capacity as accounted for by UGT, i.e. the time period during which full saturation flow was not achieved. It also illustrates how these scenarios will be modelled within deterministic traffic models such as TRANSYT or LinSig. UGT calculations are unable to discriminate between time periods where vehicles are slow moving or where vehicles are stationary. This imitates deterministic traffic modelling software such as TRANSYT and LinSig where vehicles are also assumed to be either stopped or moving at a saturated rate of discharge.
Saturation Flow
Flow (PCU/hr)
UGT
Time (s)
Figure 3: Congested conditions as modelled in LinSig or TRANSYT with UGT. It is advisable to apply UGT to model the effects of congestion, as this technique avoids the need for a modeller to iteratively adjust the saturation flow in a model during calibration, and provides quantifiable evidence to justify the approach taken. Whilst it is possible to reduce saturation flows to achieve an effect analogous to the application of UGT (see Figure 4), it is theoretically unsound as the applied saturation flow no longer represents the maximum rate of discharge across a stopline.
Saturation Flow Reduced Saturation Flow
Flow (PCU/hr)
Time (s)
Figure 4: Incorrectly reduced saturation flow analogous to UGT applied in Figure 3. For further details on the calculation of UGT values using data recorded during DoS measurements, refer to Appendix I.
Modelling Principles
75
2.4.9
Signal Timings
Traffic modelling relies heavily on the accuracy of signal timings to correctly represent capacity at signalised intersections. This section briefly describes how signal timing data should be extracted to accurately reflect on-street conditions. Signal timing data must be captured at the same time as other traffic surveys and should therefore be recorded for each modelled period. In general terms the control of traffic signals can be split into two groups, Urban Traffic Control (UTC) and non-UTC. UTC coordinates the operation of junctions over an area through use of timing plans implemented by a central computer. Non-UTC signals operate under local control, where timings are stored locally on each controller and activated according to a pre-defined timetable. UTC traffic signal control can be further classified into fixed time and SCOOT: Fixed time These facilities operate via set plans which change by time of day. Traffic and pedestrian stages within these junctions can be demand-dependent, i.e. if there is no demand then the stage will not run on-street; and SCOOT These facilities operate via an adaptive system which uses an algorithm to constantly optimise the green split, junction offset and group cycle time based on current local traffic demand. Stages at SCOOT sites can be demand-dependent. Furthermore, System Activated Strategy Selection (SASS) or selective vehicle detection (SVD) bus priority are dynamic signal control methods applied within the UTC system for traffic management on the TLRN. When in operation they will vary signal timings across a modelled period. Engineers should identify whether SASS or SVD bus priority is present during network familiarisation. If they are active then it is advised that TD NP be consulted to determine the best approach to capturing average signal timings for modelling purposes.
76
Fixed time signal timings can be extracted directly from UTC as these facilities operate using a constant cycle time with a repeatable sequence of stages and stage lengths. The interpretation of force and reply bit information can therefore be conducted once demand-dependent stage data has been captured, as described in section B2.4.9.3. Once all data has been collated it is necessary for the modeller to translate the stage sequence as defined by the signal timing plan to understand where time has been allocated within an average cycle. UTC timing plans must not be interpreted directly when SCOOT is in operation. SCOOT is an adaptive system which optimises signal timings, meaning stage durations and cycle times fluctuate during the modelled period. It is therefore necessary to generate an average timing plan for each SCOOT junction or region. To create an average plan it is necessary to log dedicated SCOOT messages during the modelled period. The collation of information concerning three variable elements (cycle time, stage length and offset) should provide an average timing plan suitable for modelling purposes. However, multinode relationships may exist within SCOOT to fix stage durations and offsets between separate nodes. Modellers should also be aware that the stage lengths recorded and displayed within SCOOT are the lengths of SCOOT stages rather than UTC stages. For this reason it is a prerequisite to analyse UTC signal timing plans to reconcile differences between UTC and SCOOT staging prior to extracting average SCOOT signal timings. SCOOT has the capability to vary group cycle times which can allow individual facilities the opportunity to double cycle within the operational group. Before collating cycle time information it is necessary to establish whether any signalised facilities were single or double cycling during the modelled period. The modeller can then determine the average cycle time for each SCOOT node. The average UTC stage lengths should then be calculated in proportion to the defined cycle time. Average UTC stage to UTC stage offsets are then calculated and applied to each node according to SCOOT relationships defined within the UTC database.
Modelling Principles
77
78
43 http://www.tfl.gov.uk/maps/ 44 http://www.tfl.gov.uk/timetables/
Modelling Principles
79
Similarly in order to accurately replicate bus journey times it is important to account for the dwell times of routes using the stop. The dwell time can include passengers alighting, buses waiting due to driver rest stops, driver changeovers and extended layovers used to regulate a timetabled bus service. Bus stop dwell times should be measured on-street, for each period being modelled. Measurements should commence once the service has stopped and end once the service is ready to depart (e.g. when a bus service has closed its doors). The level of required detail will vary according to the models purpose and the importance of accurate public transport representation. Where a high level of detail is required, dwell times should be measured for each bus route at every bus stop. Default values should not be used within micro-simulation modelling.
2.5
Model Development
Traffic models are developed to understand how a transport network may react to proposed change. To do this a traffic model is created which represents the existing situation. This model provides the benchmark against which any proposal will be compared. By comparing results between the existing and proposed situation an informed decision can be taken on whether to proceed with the proposal based on the impact it will have on the existing network. Traffic models can be developed once the network familiarisation and data acquisition stages have been completed. Traffic model development often follows a defined sequence to create a common audit trail between model versions (see Figure 5). Generally an initial skeleton model is refined until fully calibrated and validated to produce an audited base model which is eventually developed into a proposed model. However, it is the responsibility of the model developer to generate a robust methodology that generates accurate fit for purpose modelling applicable to MAP, as described in B2.2.
80
Project Scope
Skeleton Model
Figure 5: Schematic diagram outlining a generalised approach to traffic model development for TfL. Accurate traffic modelling can better inform decision making and aid the development of optimal solutions. The following subsection will define different stages of traffic model development, their common use, and factors which require consideration during the development of a scheme proposal. The exact nature of the required modelling elements will be defined by the scope as agreed during MAP Stage 1. The agreed purpose of the modelling will determine whether it is necessary to produce base, proposal and/or final signal timing models.
2.5.1
Modelling Principles
81
It is the responsibility of the modeller to determine the most appropriate version to use before commencing any modelling work. If a model is to be audited by TD according to MAP, it is important to consult with TD NP to confirm the software version currently available within TfL prior to commencing model development. Under no circumstances should software versions change between the calibration of a base model and the production of a proposed model. Even with identical inputs, it is common for different software versions to produce different results. It will invalidate a previously validated model if it is used in a software version different from the one in which it was originally developed.
2.5.2
2.5.3
82
within these guidelines. If a model fails to validate it is often an indication that poor data collection practices were adopted or that further calibration is required. Results for the validation exercise must be taken from a model version which accounts for measured demand-dependency (see 2.4.9.3). Validated TRANSYT and VISSIM models are submitted during MAP Stage 3, as described in B2.2. At the model validation stage any degrees of saturation produced by a model using stopline traffic flows should generally not rise above 100 percent. If instead they represent true traffic demand, as determined from an assignment model or survey well upstream of any queue, then the degree of saturation may exceed 100%. If this is the case validation should focus on comparing the capacity of the link in the model against site-measured spot counts. Possible causes of invalid degree of saturation values in a model include: The measured flow data for a particular link is inaccurate, or has been entered into the model incorrectly; The saturation flow is too low; Signal timings have been entered incorrectly; or One or more demand-dependent stages have not been modelled correctly.
2.5.4
Modelling Principles
83
Scheme Proposals
Every proposal is unique and it is beyond the scope of this document to list all the parameters that may need adjustment. It is the responsibility of the modelling engineer to determine the changes that are required and to justify any applied methodology. Proposed changes that may need to be accounted for within a traffic model include: Physical road layout and geometry; Lane markings and usage; Saturation flows;
84
Methods of control at signalised junctions; Signal timings; Signal staging; Signal hardware; Traffic flows; Traffic compositions; Effective flare usage; and Demand-dependent stage frequencies. When producing a proposed model it is important to consider the traffic management objectives of the scheme. Whilst overall network performance measures should be considered, these should not override considerations detailed in Part A such as local policy requirements or the Mayors Transport Strategy 2010. TD will use modelling output and analysis to make an assessment of the likely impacts of the scheme, and give recommendations to TfL Network Assurance Team via a Traffic Signal Supplementary Report (TSSR). A scheme designer should therefore understand the impact of all changes made to the base model.
45 General Principles of Traffic Control by Light Signals, TAL 1/06, Part 4, Department for Transport, 2006. 46 Design Manual for Roads and Bridges, Volume 8, Section 1, TA16/07, Highways Agency, 2007.
Modelling Principles
85
A proposed model should supply junction design information to a level of detail that allows the production of a Controller Specification. In order to reconcile phase-based signal design with stage based minima and interstage design it is recommended to use LinSig or OSCADY PRO and to supply these models with any submitted proposal. Inclusion of these controller models within a proposal provides a clear indication of how stage minimums and interstage designs were calculated and optimised. Where critical offsets exist within a base model, such as within SCOOT multinodes, it is vital that these are coded accurately. Any fixed relationships should be audited by a checking engineer to ensure correct groupings are carried forward into any proposal. Consideration should always be given to pedestrian linking during junction design. Pedestrian movement can be progressed through a junction by linking pedestrian phases, for example by using an associated parallel stage stream pedestrian crossing. Pedestrian considerations are outlined in Part A but designers should be mindful of optimising phasing and interstage design to maximise an opportunity for pedestrians to move smoothly through the network.
86
2.6
Modelling Principles
87
2.6.1
Initial Optimisation
The initial stage of model optimisation provides an opportunity to assess the performance of a proposal after major design decisions have been implemented, such as those outlined in B2.5.4. The initial optimised signal settings are usually automatically generated through an optimisation algorithm such as those employed within LinSig, OSCADY PRO and TRANSYT to reduce delay or increase capacity. Major design decisions made during proposal development will broadly determine whether it is necessary to influence a software optimiser with weightings and penalties. These can be applied to encourage the optimiser algorithm to produce signal timings which reduce delay or limit queues in particular parts of the proposal. During the initial stages of optimisation it is essential to analyse the impact of signal optimisation by considering modelled queue lengths, platoon progression and overall network or junction performance. This safeguard should enable a modeller to assess whether the fundamental aspects of the design and signal strategy are acceptable. An optimised proposal should only move into the fine tuning stage once the basic performance of the model is fit for purpose. The following subsections highlight issues which may be influential when determining whether a model can progress to a more detailed signal strategy stage.
88
Create PROPOSAL
Modelling Principles
89
90
60
2.6.2
Modelling Principles
91
2.6.3
92
Models can generate a wide range of outputs that provide an indication of the performance of the network. Performance statistics that could be provided include: Degrees of saturation; Link capacities (PCU/hour); Junction practical reserve capacity; Maximum average queue lengths; Cyclic flow profiles (CFP) for critical links (short/highly saturated); Percentage green per junction wasted due to exit-blocking; Average delay per vehicle per link; Average delay per bus per link; Percentage of buses per route waiting more than one cycle to clear nodes; Mean travel time and standard deviation for private and public transport along predefined routes; and Mean pedestrian travel time along pre-defined routes. There may be occasions when it will be necessary for modellers to present the impact of a proposed scheme using a selection of these performance indicators depending on the objectives of the scheme. The selection of performance indicators should be agreed with TD NP and other key stakeholders, e.g. FPT and the local Boroughs, before they are produced.
2.7
Model Reports
Reporting should reflect the logical approach taken by a modeller to resolve the complex and iterative nature of traffic modelling. It should emphasise the sound engineering principles adopted during model development. Without accurate reporting the model development process is hindered by a lack of historical information. The following subsections outline an approach to model reporting which should allow a third party to accurately comprehend the decisions made during the development process from network familiarisation through to proposal evaluation. A traffic model may be developed over a period of months or even years by a number of different engineers. While developing a model the engineer should retain detailed notes that include a record of all assumptions and modelling decisions. These notes should be kept for future reference, and can form the basis for subsequent reporting. It is the responsibility of the engineer and the scheme sponsor to ensure that all reporting is accurate, thorough and sufficient, and that submitted documents are fit for purpose to adequately support accompanying models.
2.7.1
Calibration Report
A calibration report should present all relevant survey data and include a history of model development.
Modelling Principles
93
Model auditing will rely on the report to explain how the model has been calibrated. For this reason the calibration report should focus on presenting traffic model inputs and detailing how the model has been developed to ensure that it represents existing conditions. In particular, the following should be included: The stated purpose of the model; A list of all TfL-referenced sites in the model, with addresses and where required a note detailing any operational relationships (e.g. UTC multinodes and subgroups); Clear notes on site observations and measurements, covering both the physical network and observed vehicle behaviour. Where behaviour is specific to a particular time of day, this should be noted along with how it has been accounted for in the model; Site data highlighting measured saturation flows, cruise times and effective flare lengths; Table of saturation flows for each link in the network, indicating whether values have been measured on-site or calculated. If calculated (e.g. using RR67) a justification describing why measurement was not possible; and Description detailing the extraction method used to obtain signal timings, including source of data (e.g. fixed time UTC plans, CLF timings, or average timings representing SCOOT operation). Specific calibration reporting requirements for TRANSYT and VISSIM are detailed in MAP Stage 2, as described in B2.2.
2.7.2
Validation Report
Validation reports should look in detail at comparisons between calibrated model results and existing conditions. The model developer should detail the validation process, from on-site surveys through to adjustments made within the model. Any decisions made by the model developer should be captured especially where model inputs have been adjusted in order to achieve validation. Validated model results should be tabulated and compared with the surveyed onstreet values for all modelled periods. If there are discrepancies between the model outputs and the on-street conditions then these should be identified, investigated and explained. Specific items that could be included in the validation report are: Details of traffic flows used, when they were recorded and who recorded them and how the peak hour was chosen; Demand-dependency calculations, including source data and how demanddependency has been accounted for in the model; Validation data, such as vehicle journey times or DoS; Relevant site observations not already included in the calibration report, such as give-way behaviour, exit-blocking, flare/non-green usage, parking/loading and bottleneck details; and
94
Evidence of validation, comparing modelled results to on-street observations and measurements. Any discrepancies should be analysed and discussed. Specific validation reporting requirements for TRANSYT and VISSIM are detailed in MAP Stage 3, as described in B2.2.
2.7.3
Proposal Report
The report accompanying any proposed model must give a full description of the proposed scheme and any expected scheme impacts (e.g. any expected changes in demand). The modifications made to the validated base model to develop the proposed model should all be based on these key details. All changes made in order to develop the proposed model should be documented by the modeller, along with the reasoning behind them. Specific items that could therefore be included in the proposal report are: Scheme summary; Scheme objectives/problem; Proposed traffic management strategy; Evaluation of proposal results; Conclusions and recommendations; Design summary sheets; Model source data; Modelling assumptions; Electronic copies of model input file; Electronic copies of skeleton LinSig stage/interstage diagrams; and Model audit trail with full version control. Results of the proposed model should be compared to the validated base model. This should be done for all modelled periods to demonstrate the impact of the proposals on the network. The proposal report should include a discussion of results. It is useful to include a section detailing the impact of any geometric changes as this enables TD to make informed decisions about preferred design options. Version control should be applied to all design documents to avoid ambiguity thus ensuring all parties are aware of the current design status for each proposed model. All data presented with the validated and approved base models should be presented within the proposal. TD will use modelling output and analysis to make an assessment of the likely impacts of the scheme. Data provided with the base and proposed model submissions will be considered when producing the TSSR, therefore it is in the scheme sponsors interest to ensure proposed model submissions are provided with detailed analysis. Specific proposal reporting requirements for TRANSYT and VISSIM are detailed in MAP Stage 5, as described in B2.2.
LinSig Modelling
95
3
3.1
LinSig Modelling
Introduction
This section is designed to assist experienced practitioners when building LinSig models of Londons road network. It is useful to have read the guidance in B2: Modelling Principles prior to reading this section. LinSig, developed by JCT Consultancy Ltd (JCT)48 , can be used for detailed junction design, assessment of scheme proposals and the creation of skeleton models for checking against junction Controller Specifications. It combines geometric layout, traffic and controller modelling to ensure that LinSig accurately reflects the way existing junctions work, and how any design proposals would operate if implemented. In terms of optimisation of junction performance, LinSig allows the modeller to maximise the efficiency of interstage design and is capable of optimising signal timings to either minimise delay or maximise Practical Reserve Capacity (PRC). Additionally, LinSig has a cycle time optimiser, which allows selection of an optimum cycle time by showing how delay and PRC vary against cycle time increments. LinSig has traditionally been used for the design and assessment of isolated signalised junctions, and is used by the majority of UK Highway Authorities, consultants and traffic engineers for this purpose. Since version 2 it has also been capable of modelling small networks, typically representing closely associated junctions and pedestrian
48 http://www.jctconsultancy.co.uk
96
streams running off a single controller. LinSig version 3 is now capable of modelling multiple controllers and therefore larger networks.
3.2
LinSig Version 3
LinSig version 3 offers the possibility of modelling large networks traditionally associated with TRANSYT, however it is not yet widely deployed or used within TD NP for this purpose. An evaluation of LinSig version 3 is being carried out by TD NP to produce an updated MAP. It is expected that the content of this chapter will evolve as more experience is gained modelling large networks in LinSig. The remainder of this chapter is written in relation to LinSig version 2, although much of what is written may still be of relevance to version 3. Network models completed in LinSig version 3 are not currently accepted by TfL and will not be audited by TD. This situation will be reviewed once MAP has been updated to include LinSig.
3.3
3.3.1
Skeleton Models
LinSig models do not have to include any modelling of traffic flows when used solely for the purpose of assessing the phase-stage relationship at a junction. These skeleton models are effectively a control data only representation of the controller. A LinSig skeleton model can be used to assess phase or stage minima and interstage durations. Within a skeleton model the stage sequence should be based on current UTC or CLF timing plans. To get a true picture of the stage minima information it is necessary to reduce LinSig to the minimum cycle time. Skeleton LinSig models are best used to augment junction analysis, for example when full modelling (including flows) will be conducted separately in TRANSYT or VISSIM. TD NP recommends that individual LinSig skeleton models are prepared for all junctions within TRANSYT and VISSIM models. This will benefit both modeller and auditor, as it ensures accurate representation of phases, phase minimums, stages, stage sequence, phase delays and intergreens.
LinSig Modelling
97
The JCT software package TranEd includes a useful function which allows phase/link conversion for TRANSYT. However TranEd does not negate the usefulness of LinSig as an auditing tool, for example, LinSig will allow the correct phase-stage representation of parallel stage streams in separate nodes.
3.3.2
3.3.3 3.3.4
Networks
LinSig is not currently recommended for building large networks (see B3.2).
3.4
98
initial green splits and offsets could potentially improve network performance. The traffic model then reruns using the potentially improved signal timings. If it is shown that these timings were better than previous results LinSig uses these timings to try and predict further improvements. LinSig monitors progress to target optimisation effort at the areas where most improvements are likely to be realised. LinSig does not run the optimisation process for a fixed number of iterations. JCT feel a fixed approach can risk the optimiser terminating early with complex networks, leading to signal timings that do not represent optimal network performance. LinSig instead varies the number of iterations according to the complexity of the network and other issues such as the level of traffic in the network. LinSig will let the optimiser continue where significant improvements are gained with a relatively minor extension of the run time. When the optimiser fails to achieve improvements within an acceptable time the optimisation process will terminate.
3.5 3.5.1
Program Settings
The LinSig program settings for a model can be completed as detailed below.
Junction Details
The Junction Details section should be completed to aid model auditing by including the location of the junction(s), the purpose of the model and the information source used to build the model. Useful information could include: TfL site reference; Scheme title; Location (e.g. identification of intersecting roads); Time period being modelled; and Whether a base or proposed model. For TfL modelling it is compulsory that the source of the controller data used to build the model is specified: Details of controller data source (e.g. Signal Timing Sheet issue number and/or Controller Specification issue number).
3.5.2
Controller Details
For an existing junction, the controller type should reflect the manufacturer of the hardware that is on-street, as identified in the Controller Specification and/or Signal Timing Sheet. For a proposed junction that does not currently exist and for which the hardware to be used is not known, the controller type should be set to generic. It is important that when modelling existing junctions, the phase minimum type is set to controller phase minimums and not street phase minimums.
LinSig Modelling
99
3.6
Model Build
The following section describes some of the steps involved in building a LinSig model and identifies issues requiring consideration. Prior to building a model in LinSig the following information should already have been obtained, as identified in sections B2.3 and B2.4: Site Layout Drawings and SCOOT Link Diagram (if applicable); TfL Controller Specifications and Signal Timing Sheets; Site-measured values for link length, cruise time, flare usage and saturation flow. Where measurement has not been possible, estimates should be used with appropriate justification (e.g. RR67 for saturation flows or extrapolated cruise times if conditions are permanently congested); Stopline traffic flows by turning movement; Determination of average signal timings, either from the UTC system or site measurement; and Site observation of traffic behaviour, particularly lane usage and effective flare length.
3.6.1
1 2
Arm 3 - Main Road (East) Arm 4 - Main Road (East) 3/1
5/1
1 2
4/1 4/2
100
An arm represents a one-way section of road within the modelled network, which should therefore contain at least one link and one lane. Arms play no specific part in the modelling process, but allow individual groups of links and lanes to be graphically manipulated as a single entity. Similarly, arm groups can be created which allow multiple arms to be manipulated as a single entity, for example allowing separate manipulation of all arms at a junction from the arms associated with a stream. It is important from an auditing point of view that each approach arm is correctly labelled with the relevant street name (or similar) as the link numbering system within LinSig is arbitrary. Where arm groups are used these should also be labelled to describe what they are intended to represent, for example using a junction or stream site reference number. A link consists of a group of lanes within an arm, representing an independent stream of traffic passing through the arm that does not impact or interact with other traffic streams on the same arm. A link must always contain at least one lane, and all lanes within the link must share the same green signal (i.e. signal phase). All traffic flows and queuing within a link is assumed to be equally distributed across all full lanes within that link, therefore consideration should be given to whether it is appropriate to group adjacent lanes within the same link. Once all links have been defined, link connectors should be added between upstream and downstream links to represent all possible traffic movements. Each lane that exists, or is seen to function as a separate lane during on-street observation, must be modelled as a separate lane within a modelled link. A lane is defined as either infinitely long or short. A long lane extends sufficiently far back towards the upstream junction that it always behaves as a dedicated lane over the available green time, whereas a short lane represents a flare, only contributing as a full lane for a portion of the available green time. Short lanes must be grouped in a link together with at least one adjacent long lane that it will interact with. Any link within the LinSig model that does not have a link connector leaving the link will be treated as an exit link. Pedestrian phases are not represented as links within the Junction Layout View in LinSig 2, although for auditing purposes they must still be included within the controller model and any associated staging.
3.6.2
Traffic Flows
Traffic flows are assigned to routes using a zone-based origin-destination (O/D) matrix within LinSig, with individual entry and exit arms assigned to the different zones. Traffic flow data for LinSig models should be fully classified turning count data, converted to equivalent PCU values (see B2.4.3.1). For a small group of closely associated junctions an O/D survey should ideally be used if a single junction turning count survey is not suitable. However where this is not possible separate junction turning count surveys should be used and converted into a combined O/D format, utilising manual flow smoothing as detailed in section B2.4.3.
3.6.3
LinSig Modelling
101
to ensure equal flows are assigned across all lanes on individual junction entry links. The modeller should ensure traffic flows have been assigned correctly where multiple route choices are available. If necessary, based on site observation, flows on specific routes may need be manually locked using the Traffic Flows View to get correct link/lane usage before allowing LinSig to allocate flows along other permitted routes. If circular routes are possible within a model, typically for roundabouts but also with closely associated junctions, these routes must be manually checked in the Route List of the Traffic Flows View. If unrealistic routes are generated, i.e. those that are not observed on-street, these should be removed using the Edit Permitted Routes feature. This is similar to the process followed when using another JCT product called FlowRound.
3.6.4
Saturation Flows
Saturation flows should be measured on-street for all critical links, as described in B2.4.7. Saturation flows for links in LinSig are determined from the contribution of all lanes within the link, therefore saturation flows should be directly entered for each lane included in the LinSig model. Where on-site measurement is not possible, RR67 values (described in B2.4.7.1) can be manually calculated and directly entered into the model, or alternatively geometric parameters can be entered into LinSig (lane width, gradient and turning radius) from which RR67 values will be calculated automatically. Any link within the LinSig model that does not have a link connector leaving the link will be treated as an exit link. If saturation flows are directly specified for these links they should be suitably high (e.g. 8000 PCU/hr) so that artificial and unintended queuing does not occur on the exit of the network, which may be the case if default values are used or if the exit link contains an insufficient number of lanes. A recommended alternative is to specify all exit links as being unconstrained (infinite saturation flow) to ensure traffic will incur zero delay when exiting the junction. Where queuing is observed on a downstream exit from a modelled junction then the modelling approach and use of LinSig should be re-assessed. Saturation flows are required for each lane or identically performing group of lanes within the model.
3.6.5
Flare Usage
Flare usage, when applicable, should be included as described in B2.4.5, and entered directly into the model for each period being modelled. It is recommended that modelled flare usage should be within 10% of observed flare usage. Physical flare length in LinSig 2 models is for graphical and reporting purposes. The average effective flare usage should be calculated from site measurements and entered into the model. LinSat should be used to estimate flare usage where site measurement is not possible. Typically LinSat should be used only for proposed models but may be applicable to other situations which should be clearly noted in accompanying reports.
102
3.6.6
3.6.7
3.6.8
Demand-Dependent Stages
The frequency of demand-dependent stage appearance should be measured directly from the UTC system, or through on-street observation in the case of VA sites, as described in B2.4.9.3.
49 Moore P, Simmonite B & Reid D, LinSig Version 2 User Guide & Reference, JCT Consultancy Ltd, V2.4A, Ch 4, 2007, pp144-145.
LinSig Modelling
103
In LinSig, it is possible to account for demand-dependent stage appearance by running the stage sequence for multiple cycle lengths with the demand-dependent stage appearing only once in the total sequence.
3.6.9
Exit-blocking
Exit-blocking can be accounted for in a LinSig base model through the use of dummy stages, where exit-blocked phases are removed to replicate lost capacity. The application of this technique needs to be supported by site observation and empirical data such as Underutilised Green Time (UGT) measurements. It is important to note that the cause of exit-blocking cannot be modelled in LinSig. Where endemic exit-blocking exists within a network, consideration should be given to applying micro-simulation modelling which can represent both the cause and effect of exit-blocking.
3.7
LinSig Output
LinSig offers a variety of output features that can aid in the analysis and reporting of model performance, which are detailed in this section.
3.7.1
Link Results
The link results view allows data and performance statistics to be displayed for every link in the model. The exact data that is displayed is user-customisable, but can contain a mixture of input data (flows, saturation flows, phase letters, link green times etc) and output data (DoS, delay and queue information). As well as identifying performance parameters for individual links, the link results view also displays PRC and delay information for streams or the entire model. Results for individual links can also be further broken down into specific routes through individual links.
3.7.2
104
When a link has a DoS less than 80% the uniform queue is an accurate representation of the average queue on a link, however when operating above 90% the random and oversaturated queue components become more critical and the uniform queue graph should not be relied on to predict queue storage issues.
3.7.3
Report Builder
The Report Builder allows various LinSig modelling information to be extracted and presented in a customisable manner, either for direct analysis or further editing in word processing software. Such information can include graphical views of almost any of the LinSig program views (junction layout, stage views/sequences, signal timings, interstage timings etc) or data in tabular form such as input data or model performance statistics.
3.8
3.9
LinSig Modelling
105
3.10
3.10.1
3.11 3.11.1
106
A sliver queue occurs when vehicles are approaching the back of a discharging queue of traffic. In practice, drivers will typically regulate their speed if they see a queued vehicle in front of them is about to accelerate, whereas in LinSig they are assumed to progress at free-flow speed until they join the back of the stationary queue. This can lead to successive vehicles joining the back of a modelled queue which leads to excessive and unrepresentative queuing behaviour. A modeller can set a de-sliver threshold (in PCUs) in order to prevent the formation of sliver queues. This value is the minimum queue that will actually form on-street meaning LinSig regards anything less than this value as a sliver queue.
LinSig Modelling
107
A modeller can recognise the formation of a sliver queue by examining the LinSig queue data or a uniform queue graph. As Figure 10 illustrates, the data will highlight a small amount of traffic in the queue relative to the total queue length. Figure 11 shows the same link with a de-sliver threshold of 1.0 PCU applied. Where a sliver queue has been identified it is acceptable to enter a de-sliver threshold value of no more than one PCU. It is recommended that values of less than one PCU are used to achieve the desired effect. Where this function has been used it should be clearly stated within the accompanying model report.
Figure 11: The same queue as Figure 10 with a de-sliver threshold of 1.0 PCU.
108
4
4.1
TRANSYT Modelling
Introduction
This section is designed to assist practitioners when building TRANSYT models of road networks located in London. It should be read in conjunction with the guidance contained in B2: Modelling Principles. Whilst this section outlines the modelling requirements of TfL in respect of TRANSYT modelling there will be cases where local conditions or project requirements dictate the use of methods which may be different to those outlined. For more detailed explanations of specific TRANSYT features it is advisable to consult the Help Tips function of TRANSYT.
4.1.1
TRANSYT 13
At the time of publishing the latest version of TRANSYT is version 13. This version contains a number of changes to previous versions, the most significant of which is the addition of a new traffic model, referred to as the Cell Transmission Model (CTM). The intention of CTM is to enable more accurate modelling of queuing behaviour at a stopline.
TRANSYT Modelling
109
TRANSYT CTM functionality has not been fully evaluated by TD NP. Hence at the time of publishing TfL are not accepting models developed in TRANSYT 13 that use CTM. Any modelling developed for TfL in TRANSYT 13 should therefore make use of the traditional Platoon Dispersion Model (PDM) methodology. The remainder of this chapter is written in relation to TRANSYT version 12, although much of what is written will still be of relevance to version 13.
4.1.2
TranEd
It is common practice for TRANSYT 12 and earlier models to be built using TranEd, a JCT software product that provides a graphical interface allowing translation of controller phase information into TRANSYT stage data. The TranEd interface allows the TRANSYT link diagram to be coded graphically as part of the input file. The information contained in this chapter applies equally to both products as the underlying functionality of TranEd is provided by TRANSYT. No preference for either software is expressed or implied within these guidelines.
4.1.3
110
4.2
Initial Signal Settings Network Data & Traffic Flow Delays and stops in network
Traffic Model
Optimisation Procedure
TRANSYT
Figure 12: The TRANSYT optimisation process, adapted from Binning et al50.
50 Binning J C, Crabtree M & Burtenshaw G, TRANSYT 12 User Guide, Application Guide 48 (Issue C), TRL, 2005.
TRANSYT Modelling
111
TRANSYT simulates the arrival and departure patterns of vehicles at stoplines throughout the model network. It uses these patterns known as cyclic flow profiles to determine vehicle stop and delay. TRANSYT assumes that during green queued vehicles discharge at a rate determined by saturation flow until a queue has dissipated. Vehicles discharge at the rate of arrival if they reach a stopline after a queue has disappeared. TRANSYT attempts to offset the arrival of platooned vehicles to minimise the network-wide weighted sum of traffic delays and stops. The software contains a simplified queuing model which means TRANSYT cannot implicitly detect spatial phenomena such as cross junction exit-blocking, however modelling techniques can be applied to overcome this limitation and they are detailed in section B4.4.
4.2.1
Program Settings
TRANSYT program settings need to be specified before commencing model development. Default values for stop and delay should be defined within the model file, and for TfL models these should be: Monetary value of delay = 1420 pence per PCU-hour; and Monetary value of 100 stops = 260 pence. Particular attention should also be paid to the following general settings which influence the TRANSYT traffic model and signal optimiser: Number of Steps in Cycle this should typically be equal to the cycle time; Simulated Time this represents the period in minutes over which the modelled flows are assumed to exist. This is commonly set to 60, as a peak hour is modelled using hourly flow rates. However, if peak flow conditions exist for two hours onstreet, even though only one hour is being modelled by TRANSYT, the simulated time value should be set to 120. This allows accurate calculation of queues and vehicle delay. The default value in TRANSYT is 120s whilst TranEd is 60s; Start/End Effective Green Displacements these represent the period after the beginning of green before vehicles discharge, and after the end of green before vehicles cease to cross the stopline. These should not be changed from default values unless a specific survey is conducted for each stopline within a modelled area; Flow Scaling Factor this should be unchanged from the default value unless modelling a change in flow volume (e.g. looking at predicted increase/decrease in demand or using a flow-factoring technique to model a peak for which specific flow data are not available); EQUISAT for a base model this should be disabled in order to maintain existing timing settings. EQUISAT can be enabled during the optimisation process for proposed modelling; Cruise Times/Speeds this should be set to use cruise times, as measured onstreet and detailed in section B2.4.4.1; Cruise Time/Speed Scaling Factor this should remain unchanged from default unless specifically required for a particular purpose (e.g. a proposed change in speed limit); and
112
Level of Optimisation for a base model, this should be set to No Optimisation. This will provide performance results based on existing timings in the model. Offset and green times/offset optimisation should be used during the optimisation process for proposed modelling.
4.3
Model Build
Prior to building a model in TRANSYT the following information should already have been obtained, as identified in sections B2.3 and B2.4: Site Layout Drawings and SCOOT Link Diagram (if applicable); TfL Controller Specifications and Signal Timing Sheets; Site-measured values for link length, cruise time, flare usage and saturation flow. Where measurement has not been possible, estimates should be used with appropriate justification (e.g. RR67 for saturation flows or extrapolated cruise times if conditions are permanently congested); Stopline traffic flows by turning movement; Determination of average signal timings, either from the UTC system or site measurement; and Site observation of traffic behaviour, particularly lane usage and effective flare length. In addition to collecting the above data, skeleton LinSig models should be produced for all junctions to be modelled in TRANSYT, as detailed in section B3.3.1. These will ensure signal timings are accurately represented, particularly when modelling stage and interstage relationships between phases in LinSig and links in TRANSYT.
4.3.1
TRANSYT Modelling
113
Where multiple lanes exist that do not behave identically they must be treated as separate links, even if they share the same destination, and the traffic flow on each link proportioned according to observed lane usage. TRANSYT has two main types of link major and minor. Major links represent all traffic at a stopline, while minor links can share a stopline with major links to generate a cyclic flow profile for a particular vehicle group. The minor link occupies the same physical road space as the major link, but represents only a proportion of the flow and queue on the major link. Minor links therefore facilitate analysis of vehicle progression through the network by distinguishing between platoons from different sources where in reality they form a single queue at the stopline. Up to eight separate minor classes may be disaggregated from any major link. It is important to note that the choice of which link is the major and minor link is arbitrary as they share all input data and thus have no effect on model output. For this reason model output values from major and minor links should not be summed as by nature there is only one value for DoS and queue length. The use of TRANSYT shared links can be helpful where complex travel patterns occur, such as on signalised roundabouts. Here it is desirable to optimise offsets between entry and circulating traffic so that excessive queuing does not occur on internal links with limited storage capacity, which would interfere with efficient operation of the roundabout. It is also possible to model bus movements with shared links, unless there is a dedicated bus lane which should be modelled with a discrete link. Major and minor TRANSYT link types are further sub-classified by how they operate on-street. Links can be classed as signalised, priority (non-signalised give-way), bottleneck, exit, or pedestrian: Signalised links (for example link 6611 in Figure 13) represent individual traffic streams that are controlled by one or more signalised traffic phases at a junction; Priority links represent traffic streams that are controlled by giving way to an opposing flow. They can either be pure give-way links, modelled as green all the time and only controlled by the opposing flow, or signalised and therefore obeying signal control in addition to giving way to other traffic (as demonstrated by link 6610 in Figure 13, which represents a signalised opposed right-turn); Bottleneck links attempt to represent behaviour which occurs mid-link between intersections, for example: Where platoons progress through a narrowed carriageway; To restrict entry to additional downstream lanes during carriageway fanning; or Due to localised influences such as right-turn bays, loading bays, frequently used bus stops, start of bus lanes or uncontrolled pedestrian crossings; Exit links can be used to represent traffic leaving the network (as shown by link 6699 in Figure 13). Bottleneck links should be used for this purpose using an artificially high saturation flow, typically 8000 PCU/hr, to avoid the creation of unintended and unrealistic queues. If queuing does exist on-street from a downstream intersection outside the modelled network then the modelling approach and use of TRANSYT should be re-assessed; and
114
Pedestrian links represent pedestrian movements controlled by signalised pedestrian phases. Each individual pedestrian phase should be modelled as a separate link, especially where they run in parallel with traffic phases (as shown by links 6650, 6651, 6652 and 6653 in Figure 13). Pedestrian links should use proxy flows, link lengths and saturation flows. All round pedestrian stages may be modelled as a single link even though there are several phases that run in that stage. However, if this approach is employed the modeller should ensure that the largest clearance period is used to determine the stage minima, and that appropriate start and end lags are calculated correctly using a skeleton LinSig model.
4.3.2
6611
6698 6697
6695
Figure 13: TRANSYT node and link labelling system (shown for J05/066).
6696
6651
66
6620 6621
6652
6622
6630
TRANSYT Modelling
115
116
4.3.3
4.3.4
51 Vincent R A, Mitchell A I & Robertson D I, User Guide to TRANSYT Version 8, Report LR 888, TRL, 1980.
TRANSYT Modelling
117
118
TRANSYT Modelling
119
Standard values are typically used for give-way coefficients, representing commonly encountered give-way scenarios. It is also possible to use PICADY to manually calculate give-way coefficients based on junction geometry, or ARCADY can be used for give-way links at roundabouts. Alternatively measured on-site data can be used to plot various opposing and opposed flow rates, from which the intercept and slope can be measured. These values can then be entered into TRANSYT as capacity and slope parameters.
52 LinSat is freely available from the JCT website, via http://www.jctconsultancy.co.uk/Software/LinSat/linsat.php 53 QueProb is accessed from within TRANSYT on the link data input screen for flared approaches
120
4.4
Modelling Techniques
The previous section specified the input requirements for TRANSYT, however it is not always obvious what these values should be or how they should be used. This section provides some basic guidance on appropriate techniques that can be applied with engineering judgement to better model particular scenarios within a base or proposal.
4.4.1
Flow Smoothing
It is not a requirement in TRANSYT for the total flow on a link (the output flow) to exactly match the sum of the contributing flows (the input flows). If the total flow is different from the flow inputs on a link, TRANSYT assumes that the total flow is accurate and will therefore proportionally increase or decrease the upstream flow values in order to achieve the total link flow entered. This methodology works reasonably where link input flows are roughly equal to the output flows. However where there is a significant link flow discrepancy it can lead to inaccurate modelling and result in downstream flows that are in excess of upstream stopline saturation flows. To prevent this, it is desirable to ensure surveyed flows are consistent before entering values into TRANSYT. It is not acceptable to combine flow surveys from different peak periods into the same model. Most TRANSYT models are built using stopline flows from classified traffic count surveys. If a model is to be built using flows from an origin-destination (O/D) survey these will need to be converted into link based flows for entry into TRANSYT. This requires the creation of a lane-flow diagram based on network layout. This can be completed manually or by using bespoke software such as JCTs FlowRound54. Section B2.4.3 highlights basic guidance for reconciling surveyed traffic flow differences within a modelled network.
54 FlowRound (http://www.jctconsultancy.co.uk/Software/FlowRound/flowround.php) is a tool for analysing traffic lane movements on signalised and unsignalised roundabouts.
TRANSYT Modelling
121
4.4.2
4.4.3
Demand-Dependency
TRANSYT simulates only one typical cycle and as such it is not possible to explicitly model demand-dependency. For this reason the appearance of demand-dependent stages are modelled by manipulating signal timings. There are two methods commonly used: A dummy stage can be used in place of the demand-dependent stage in the stage sequence, with its stage length reduced proportionally to the frequency of demand observed. The timing of the dummy stage appearance should then be adjusted to take account of how the time is shared between the preceding and following stages in the event of non-appearance of the demand-dependent stage (see B2.4.9.3). The dummy stage method is discouraged as proposed models are required to have all stages modelled with controller minimum stage lengths in order to optimise junction performance and distribute spare green time; or The manipulation of link start and end lags, to account for the extra green time given to other stages when a demand-dependent stage does not appear. In TranEd, this is specified as bonus green and implemented on the node rather than the link. Bonus green usage is preferred as modelling adjustments can be separated from interstage design. There is a limitation on how much bonus green can be applied as links cannot be active in stages that they are not assigned to in the junction method of control.
122
Demand-dependent stage frequency can significantly affect the amount of green time that links receive, and can vary by time of day. It is recommended that the modeller ensures all modelled adjustments result in appropriate green times. For example, if a junction has been modelled with a pedestrian stage being activated every cycle, when in reality it is only called 50% of the time, then the model is likely to underestimate the capacity available to one or more movements.
4.4.4
4.4.5
TRANSYT Modelling
123
end lag for the opposed link, or in the case of TranEd by the addition of bonus green, as discussed in B4.4.2. The additional time added should be long enough to clear the number of vehicles that are able to store in front of the stopline. It is common to add two seconds per vehicle for opposed movements that do not have an unopposed period, and one second per vehicle if an unopposed period follows (i.e. an early cut off for an indicative arrow stage). The links opposing the opposed flow are usually evident. It is important to be aware of the limitations of TRANSYT, which is only able to consider two opposing links that cannot be separate lanes of the same opposing movement, for instance where an opposed right-turn gives way to multiple lanes of traffic in the other direction. In this situation multiple opposing links should be combined into a dummy link so that a single opposing link can be specified in the opposed link give-way parameters. If it is desirable to keep the flows distinct in the combined dummy link, shared links can be used to separate the flows. TRANSYT cannot model a mutually opposed link, i.e. a link that is opposed cannot itself be specified as opposing another link. As a workaround when mutually opposed movements occur, the saturation flow for one link, usually the one with the lower opposed flow, can be manually adjusted to account for its actual capacity and the other specified as the opposed link. Where an opposed right-turn movement shares a single lane with an unopposed ahead movement, this can lead to interference and blocking. This is modelled in TRANSYT by specifying a proportion of the opposed flow as giving way to nothing (the ahead movement), while the remainder (the opposed right-turn) gives way to the opposing link. This combines the effect of right-turners giving way and the ahead movement discharging at the links saturation flow. It does not account for any vehicles entering the junction without blocking the ahead movement and may therefore slightly underestimate capacity. If an opposed right-turn movement shares a lane with unopposed ahead traffic, but a separate ahead lane also exists, then an allowance should be made for the likelihood of right-turners blocking the shared lane. This reduction in ahead capacity can be achieved in TRANSYT through modification of the saturation flow if the ahead lane is modelled as a single link, or through separating the ahead movement into separate links and allocating flows according to observed lane usage for each modelled period. If a right-turn bay exists that allows some storage of right-turning traffic separate from any ahead lanes, the modelling approach taken depends on whether right-turn traffic will queue back and block the adjacent ahead lane or not. If blocking back does not occur, the right-turn and ahead lanes should be modelled as separate links, however the capacity of the adjacent ahead lane can be reduced to account for the effect of slowing right-turning traffic. If blocking back occurs, the right-turn bay and adjacent ahead lane should be modelled as a single link using the give-way parameters detailed previously, with a proportion of the flow opposed by nothing and the remainder opposed by a specific link.
124
Since TRANSYT will always attempt to minimise the overall network cost (in terms of the PI), these weighting values determine the amount of effort TRANSYT will put into minimising stops and/or delays on the particular link relative to costs elsewhere in the model. Weightings of less than 100% are therefore likely to increase the number of stops and/or delays on the link if this leads to a reduction in cost elsewhere in the model. It should be noted that the default value of 0 in TRANSYT 12 and earlier versions is the same as 100, representing a weighting of 100%. In TRANSYT 13 however, a value of 0 represents a weighting of 0% and 100 represents 100%. In TRANSYT 12 and earlier versions, a weighting of 0% is specified as -9999.
TRANSYT Modelling
125
4.5
Public Transport
Buses should be modelled using minor links where they share the carriageway with general traffic, and major links where they are segregated in dedicated bus lanes. This link structure allows public transport delay and optimisation to be assessed separately from general traffic. Whichever link type is used, the links should be specified as dedicated bus links. Bus links require the entry of two link parameters: Bus link cruise speed, in km/hr (regardless of whether cruise speeds or cruise times are specified in the TRANSYT program options); and The time stationary on each link, representing the dwell time at a bus stop along the link. If no bus stops are present on the link then the stationary time should be left as zero. If more than one bus stop occurs on a link the stationary time should represent the sum of all bus stop dwell times, with an additional contribution representing acceleration and deceleration periods at the additional bus stops (TRANSYT already accounts bus acceleration and deceleration for the first bus stop). Bus dwell times can be as surveyed on-street, or in some cases it may be appropriate to use estimated default values. If bus lanes do not extend all the way to the stopline, a bus set-back is created which allows general traffic to use the short lane in front of the bus lane (e.g. for left-turning vehicles). This should be modelled as a stopline flare, with the bus link start lag increased by the time taken for buses to travel from the end of the effective bus lane to the signal stopline. The bus set-back start lag should be measured for each modelled period as it may vary according to time of day. As TRANSYT is based on average signal timings during a typical cycle, dynamic control strategies like SVD Bus Priority cannot be explicitly modelled. Instead their effect can only be represented by the average signal timings within the model.
4.6
126
4.7
4.8
TRANSYT Modelling
127
During scheme design, model output should be used to assess the schemes effectiveness and if necessary consider suitable design changes prior to full reoptimisation, as described in B2.6.2. Two further inputs instruct TRANSYT how signalised nodes should be optimised: Order of optimisation this notifies TRANSYT of the node order to be used during the hill climb optimisation process; and Node Grouping this facility allows fixed offsets between nodes to be maintained (e.g. for critical offsets within a UTC multinode or CLF subgroup). Offsets for the group are optimised together rather than for individual nodes. Where flows are predicted to change following implementation of a scheme, effective flare length should be estimated using LinSat. Where timings at an existing site are not compliant with SQA-0064 requirements, proposed modelling should include results with existing and existing plus SQA-0064 timings. Cruise times should not be changed to reflect a proposal that is expected to reduce queuing and delay as cruise times represent free-flow conditions. However, cruise times should be re-measured if proposals are expected to involve changes that impact on cruise speed, such as a reduction in parked vehicles, introduction of speed reduction features or stopline-tostopline distances being changed. It is recommended to include proposed skeleton LinSig models with any TRANSYT submission for auditing purposes. Both models should be supplied with LinSig phase/ TRANSYT link relationships detailed for any new proposals.
4.8.1
128
4.9
4.9.1
4.9.2
TRANSYT Modelling
129
Simplifications within the TRANSYT traffic model may mean it does not accurately predict the performance of networks operating close to capacity. As a result, after an initial signal optimisation, the modeller should study output such as the traffic profiles and queue graphs. It is possible to use this information to establish when in the cycle different links are likely to suffer from exit-blocking or poor performance. Once the reasons for a loss of capacity are known new stages in the method of control can be considered and full optimisation can be repeated. In order for a proposal to consider all underlying traffic management requirements within a proposal it may be necessary for the modeller to influence TRANSYT during initial optimisation with appropriate delay, stop and excess queue penalty weightings. They may also find it beneficial to reiterate the hill climb optimisation process by repeating the node list so that each node is optimised twice within the same model cycle. It is important at all stages of optimisation to assess model output to ensure proposed signal timings are fit for purpose relative to the scope of the project and overarching considerations, as outlined in Part A.
4.10
TRANSYT Output
TRANSYT can deliver a number of outputs that provide a modeller insight into model results. These allow analyses of optimised signal timings and their potential impact on-street such as required during proposal fine tuning (phase two within Figure 7). It is possible to define specific routes through a TRANSYT network to examine performance statistics for a particular pathway or vehicle type. The following subsection will outline examples of TRANSYT output which provide insight into stopline queuing, network performance, etc. It will not provide interpretative guidance as this should be developed on a case-by-case basis under advice from experienced TRANSYT practitioners.
4.10.1
.PRT File
TRANSYT is a mathematical model which requires fixed format numerical data to understand input information. All input information is held within the .PRT file. The .PRT file is only available to the modeller after an optimisation cycle has been completed and will display the TRANSYT program version which determines the exact format of input and output data. The .PRT file is the master record which should be referenced when auditing data inputted into a TRANSYT model. TMAP Stages 2 and 3 specify how the .PRT file should be examined during a model audit to extract information relating to optimisation settings, cycle times, traffic flows, saturation flow, mean cruise time, green start and end time. The .PRT also provides numerical output which is of use to a modeller when assessing a proposed set of signal timings. It provides the intermediate and final settings produced during optimisation alongside link predictions for DoS, MMQ (see B4.4.5.2), PI, average excess queue and the separate components of delay (see Figure 8). The .PRT file also displays network data such as total distance travelled, total monetary value for stops and delay, mean journey speed and total network PI. These data should not be used in isolation to assess the merit of proposed signal timings.
130
The .PRT file can be used to identify sources of poor optimisation or network performance. TRANSYT aids the interpretation of the .PRT by flagging potentially problematic links using symbols. TRANSYT will produce a (<) symbol to indicate that flow into that link has been reduced by more than ten percent. This may indicate that an upstream node has become over-saturated and starved the downstream network of demand flow. In this case a modeller can trace upstream from the link being starved to identify the flow bottleneck as TRANSYT output for starved links will not validate against measured data. TRANSYT utilises a (+) symbol to denote where an excess queue has formed in the model. This may indicate that queue lengths have exceeded storage capacity on the link and signal timings may generate blocking back on-street. Modellers can examine links where this symbol is present to check signal offsets are not generating artificial queues and to ensure that adequate stacking capacity exists on the link. TRANSYT calculates link storage capacity as a function of link length and saturation flow. This value can be overwritten by a user defined queue limit as detailed in section B4.4.5.2. To estimate an average excess queue the MMQ of a link is checked against the queue limit/link capacity during each step of the cycle. If the limit is exceeded for a time step the excess queue is noted to generate an average excess queue value which accounts for the duration of time during which blocking back may have occurred.
TRANSYT Modelling
131
The CFP also provides an indication of the Mean Modulus of Error (MME) for each link. MME is a measure of how bunched a travelling platoon is as it progresses along a link, and is an important parameter when deciding whether a particular link should be coordinated with an upstream link. A higher value for MME indicates there are potential benefits to linking signal timings, as platoons remain clearly defined and are therefore more likely to benefit from offset progression. MME is a theoretical concept because TRANSYT can only model platoon dispersion due to different speeds and not mid-link friction caused by parking, loading and minor sinks or sources. A value for MME higher than 0.3 suggests stopline coordination may be effective whilst a value of zero indicates a uniform arrival pattern.
Link 3463 (MME=0.73) Link 811 Link 821 Link 843
2160
2160
1800
1800
1440
1440
1080
1080
720
720
360
360
0 0 12 24 36 48 60 72 84
132
5
5.1
VISSIM Modelling
Introduction
This section is designed to assist experienced practitioners when building VISSIM models of Londons road network. It is important therefore to have read the guidance in B2: Modelling Principles prior to reading this section. This section outlines the approach of TfL in respect of VISSIM micro-simulation modelling. However there will be cases where local conditions or project requirements dictate the use of methods which may be different to those outlined. In these situations, TD should be consulted on the methodology where modelling is being undertaken for, or for approval by, TfL.
5.1.1
VISSIM Modelling
133
Where accurate journey time prediction is important as an improvement measure (e.g. bus priority scheme); and Where it is necessary to visually demonstrate the operation of a scheme, traffic management technique or control strategy for use in a stakeholder consultation or Public Inquiry.
5.2
5.2.1
Model Boundaries
VISSIM is able to model adjacent CLF or UTC groups operating different cycle times. It can therefore assess the impact of scheme proposals which cover two or more traffic control groups. Where blocking back from one group impacts traffic upstream, VISSIM can be used to predict the magnitude and frequency of any operational issues and test proposals for mitigation. When deciding on the VISSIM model boundary the modeller should consider the length of external links (i.e. where vehicles are loaded onto the network). Links must be designed such that there is sufficient capacity for all vehicles to be loaded into the network within the modelled time period, in all scenarios. There are two reasons this should be done: To ensure that any upstream blocking back effects can be easily identified (visually) and mitigated; and To ensure that when measuring scheme performance parameters (e.g. journey time, delay, queue length, average speed) all vehicles are included. If some vehicles are not successfully loaded into the network, the modeller will produce a biased result which may underestimate the capacity impacts of the scheme.
5.2.2
134
5.2.3
Data Collection
Prior to building a model in VISSIM the following information should already have been obtained, as identified in sections B2.3 and B2.4: Network layout (e.g. OS mapping, aerial photography); Familiarity with site operation and driver behaviour; Traffic flows and turning proportions; Traffic flow compositions (i.e. according to vehicle classifications); Bus frequencies; Bus stop locations; Bus stop dwell times; Signal timings and controller logic; Saturation flows; Vehicle journey times; Queue lengths; Mandatory speed limits; and Parking and loading. The following data may also be needed, depending on the purpose of the model: Origin-destination surveys; Speed and acceleration profiles; Bus boarding and alighting survey; Pedestrian flows; and Bus occupancy survey. In addition to collecting the above data, skeleton LinSig models should be produced for all junctions to be modelled in VISSIM, as detailed in section B3.3.1. This will ensure signal timings are accurately represented, particularly when modelling stage and interstage relationships. The remainder of this introductory section provides specific guidance on the collection of some of the above data as necessary for the preparation of VISSIM models.
5.2.4
Site Observation
Micro-simulation models are able to simulate complex interactions between road users and their environment. It is therefore essential that behaviour such as blocking back, lane changing, parking and queuing, which can significantly affect model results, is understood from site visits in order that it can be accurately replicated in the model.
VISSIM Modelling
135
5.2.5
Network Layout
Background drawings on which the VISSIM traffic network is built should be of sufficient detail and accuracy to give information on relevant network elements such as signal stoplines, give-ways, bus stop locations and lane marking arrangements. Before network build begins it is essential that the background datum is scaled correctly. As an additional safeguard it is suggested that a scale marker is included on the background which should be at least 100m in length. Aerial photographs and detailed topographical drawings may be used to supplement Site Layout Drawings, but they should not be used in isolation for building the traffic network. Finally, as described in B2.3.2 and B2.3.3, it cannot be assumed that drawings and aerial photographs are up to date and accurate. Therefore it is necessary to check layout details during site visits to confirm their accuracy.
5.2.6
5.2.7
5.2.8
Signal Timings
Guidance on how to collect and use signal timing data is provided in B2.4.9. Requirements for VISSIM are largely the same as those required for deterministic models, except where it is necessary to model dynamic control logic such as Vehicle Actuation (VA) or SVD bus priority (see section A5.5). Where these forms of dynamic control have a significant influence on the behaviour of models it is advisable to gather information on all junction detection (e.g. traffic detectors, pedestrian push-buttons) and control logic. TD has developed a software interface between VISSIM and an offline version of TfLs UTC system. This interface allows TD engineers to simulate the real behaviour of the UTC system and associated applications including SCOOT, SASS and SVD Bus Priority.
136
5.2.9
Saturation Flows
In most cases, a VISSIM model will be developed to complement an existing validated TRANSYT or LinSig model. Saturation flows from those accompanying models should be used for calibration of the VISSIM model. Guidance on saturation flow measurement is provided in B2.4.7. Although saturation flow is not a direct input to VISSIM, it is not acceptable to rely on the default saturation flow that results from standard driver behaviour parameters. Typically the VISSIM default saturation flows produce models which appear to run too freely. For models with closely spaced signal-controlled junctions it is important to get the rate of discharge (saturation flow) correct across the major stoplines. TD NP Operational Modelling can provide a spreadsheet to compile VISSIM output information and aid collation of saturation flow data. Where a validated TRANSYT or LinSig model is not available, it will be necessary to measure saturation flows for the purposes of calibrating the VISSIM model. Some examples are given below of situations where it is critical to measure saturation flows for a VISSIM model: Approach has extensive queues, i.e. a bottleneck; Approach is an entry into the VISSIM network; There are proposed changes to the layout; and There are proposed changes to the method of control or intergreens. This is not an exhaustive list and it remains necessary for the modeller to exercise good judgement when assessing situations where it is critical to measure saturation flow within VISSIM.
5.2.11
VISSIM Modelling
137
At present the inclusion of two-wheelers in VISSIM should only be used to model their effect on other motorised road users. There is no reliable facility to study the impact of motorised traffic on cycles and powered two-wheelers.
5.3
5.3.1
Network
138
5.3.1.4 Units
The following settings are recommended: Distance: Set to m and km; Speed: Set to mph; and Acceleration: Set to m/s2.
VISSIM Modelling
139
along that link. Alternatively short connectors can be placed within the lane (i.e. they connect a link with itself) allowing routing paths to be specified across those connectors. This is a last resort solution which rigidly enforces queuing behaviour.
Lane merge point Lane merge point
Figure 16: Correct (left) and incorrect (right) connector usage for modelling lane gain or loss.
It is recommended that default link types should be used during base model build. Adding new link types at this early stage complicates the model development process. Further link types can be defined later during the calibration stage as necessary. The number of additional link types used should be kept to a minimum. Bus lanes can be modelled as part of a multi lane link using lane closures. This is preferable to modelling bus lanes as a separate link which excludes taxis and powered two-wheelers, and doesnt allow buses to overtake stationary buses in an adjacent general traffic lane. This approach also allows the same link/connector structure to be used for time periods where the bus lane is not in operation. If the bus lane is not modelled as a separate link, which is most cases, then it is best to have separate connectors for both traffic and bus lanes. This allows vehicles to be explicitly routed into the correct lanes and thus avoid vehicles entering bus lanes during congested periods.
140
5.3.2
Traffic Data
57 Vehicle Speeds in Great Britain 2005, Transport Statistics Bulletin, SB(06)21, Department for Transport, 2006.
VISSIM Modelling
141
58 Helbing D & Molnar P, Social force model for pedestrian dynamics, Phys. Rev. E, 51, 1995, pp 42824286.
142
This will indicate to the MAE during VMAP that the saturation flow has been checked and calibrated. TD NP does not recommend use of RSAs for the creation of artificial queues. Queues form for many reasons, for example exit-blocking, parking, merging behaviour, and these should form in the model as on-street. Desired Speed Decisions (DSDs) are normally used where vehicles move between one mandatory speed limit and another, for instance where entering or leaving a motorway. They are best used in gyratory networks, with DSDs placed across all entries and exits. This will ensure circulatory speeds are appropriate and all vehicles return to normal speeds on exiting. RSAs should be used sparingly within gyratory links as it is difficult to ensure that all vehicles cross the full length of the RSA.
5.3.3
Control Infrastructure
VISSIM Modelling
143
When coding signal plans using the fixed time control logic within VISSIM, an adjustment should be made to account for the fact that VISSIM treats the red-amber periods as green time. Intergreen
Phase A Red R/A 65s 67s Phase B Green Amber 59s 62s Red Green
144
The VAP function TRACE can then be used to generate calibration data which specifies the number of stage appearances relative to the number of demanddependant opportunities. Many VISSIM models will be required to simulate Vehicle Actuated (VA) junctions. Where this is required the modeller should consult with TD Traffic Infrastructure (TI) and refer to Signal Controller Specification documentation.
5.4
VISSIM Modelling
145
5.4.1
5.4.2
146
59 VISSIM 5.10 Manual, PTV AG, pp119-121, 2009 60 VISSIM 5.10 Manual, PTV AG, p315, 2009
VISSIM Modelling
147
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.
148
5.5 5.5.1
5.5.2
Error Files
VISSIM and VAP error files (*.err files) are created when errors exist within the simulation. These files should be thoroughly audited as they may contain indication of errors such as: Minimum green and/or minimum stage lengths violations; Unusual stage change sequences; Vehicles being removed from the network; Vehicles reaching the end of links while still searching for routes; and Vehicles not being loaded onto the network. Ideally, no error files should be produced at the end of the simulation runs. However, small error files with non-critical error messages are acceptable within VMAP.
VISSIM Modelling
149
5.5.3
5.6
Dynamic Assignment
Dynamic Assignment (DA) is a method of routing trips through a network that includes alternative route choices. In many cases, VISSIM models developed for London do not include any real alternative routes and therefore using DA is unnecessary. Where alternative routes do exist, modellers should carefully consider what benefits DA will provide, and then to balance this against the added complexity introduced during base model calibration and option/scheme testing. Modelling option testing using DA will require an iterative process which should significantly increase the amount of required simulation time. In cases where dynamic modelling is justified, a combined static-dynamic assignment is preferred. When using DA, the link connector structure should avoid using multiple connectors between single lanes as this introduces non-existent alternative routes which place an additional burden on the assignment process as well as creating unrealistic and inconsistent queuing behaviour. While it may be necessary to use multiple connectors to enforce particular queuing behaviour upstream of a turning movement this should be employed in addition to route closures for vehicles not making those particular turning movements.
5.6.1
Convergence
Convergence will be deemed to have been satisfactorily achieved when the following criteria have been met over the modelled peak hour: 95% of all path traffic volumes change by less than 5% for at least four consecutive iterations; and 95% of travel times on all paths change by less than 20% for at least four consecutive iterations. These convergence criteria have been based on DMRB acceptability guidelines for highway assignment models and aim to confirm a stable and converged assignment61. Three methodologies which may help a modeller to achieve convergence using DA in VISSIM are outlined in Appendix IV.
61 Design Manual for Roads and Bridges, Volume 12, Section 2, Part 1, Chapter 4, p4/29, Department for Transport, 1996.
150
If convergence has been achieved for four iterations but is then lost in subsequent iterations, a note should be made of the number of iterations when convergence was achieved. Assignment and validation should then be performed with the use of the cost and path files (*.BEW, *.WEG) from the last of the four converged iterations.
5.7
Proposed Models
All proposed VISSIM models are expected to have corresponding approved LinSig or TRANSYT models, which should hold the same network data. Input traffic flows and traffic routes should be the same as in the base model except where major network changes are proposed. Where this is the case the proposed reporting should contain a methodology which details assumptions and all other relevant data used when re-assigning traffic flows from the base. Proposed VISSIM models should also contain optimised signal data derived from a corresponding traffic model. VISSIM is suited to modelling spatial phenomena so it is accepted practice to iterate between VISSIM and the traffic model to achieve a proposed solution, for example during the fine tuning stage of model optimisation identified in B2.6.2. Signal timings may be fine tuned within VISSIM to account for over-saturated conditions following the process outlined in B2.6. Once a solution has been established, final signal timings should be implemented. For audit purposes it is important that signal timings within VISSIM match those delivered with all accompanying modelling. Finalised proposed models should be submitted during VMAP Stage 5.
151
6
6.1
62 http://www.dft.gov.uk/webtag/ 63 http://www.standardsforhighways.co.uk/dmrb/
152
6.1.1
6.2
6.3
153
a cost benefit ratio between the data required for network development and resource available for collection (i.e. people, equipment, etc). It is usually not possible to survey and process data for all links and nodes within a network. HTA modellers are therefore often required to select representative locations for sample surveying. HTA models have unique data requirements which can be broadly classified into: Observational (site visits, cordon/screenline surveys, speed and car-parking surveys); Written (travel diary and household surveys); and Oral (roadside and Telephone interviews).
6.4
Network Development
The modelled HTA network is defined by the area within which link flows, journey times or delays will be significantly affected by the implementation of a proposed scheme. For this reason a HTA network must be sufficient to allow traffic associated with such developments to disperse through the road network in a realistic way. The scale of HTA network can usually be determined by considering the following issues: Routes being affected by the proposal; Opportunities for re-routing leading to changes in origin and/or destination of trips; Decision-making context relating to the nature of trips being made (i.e. long or short distance trips, whether they are mandatory or optional, etc); Areas where significant benefits or disbenefits may be provided by the proposal; Changes in traffic levels on both existing and new/improved roads in the areas affected by a proposal; and The area over which economic benefits are to be assessed. The HTA network should then be developed following a defined and repeatable methodology. All network design decisions should be documented to allow accurate auditing.
6.4.1
154
The concentration of several zone connectors on secondary links may result in unrealistically high volumes on those links. If this results in over-saturation of the secondary link then its capacity must be increased. If it results in over-saturation of any junction within the main-network then the delay calculation for that node should be disabled. This manipulation can introduce an error during the impedance calculation for the secondary link, but the overall effect is less severe than blocking back a large proportion of zone traffic. This would lead to the model underestimating delays in other parts of the network where zone traffic is missing.
6.4.2
64 http://www.ordnancesurvey.co.uk/osmastermapitn/
155
Links in strategic transport planning models are often coded with an effective number of lanes. This is used, for example, where the kerbside lane of a two-lane street is blocked for parking during part of the day. Instead of coding both lanes, the modeller may choose to code only one effective lane. This practice is discouraged for several reasons: Kerbside parking regulations may change throughout the day. If the network is to be used in the future for other time periods (e.g. inter-peak), its lane structure must be revised; Kerbside parking normally affects mid-block link capacity, which should be coded independently from the overall link capacity; In order to accurately represent capacity in urban networks, junctions must be coded accurately. Link/lane structure therefore must correspond with the physical infrastructure in order to derive accurate lane allocations on the approach to junctions; and If at a later stage sub-areas of the models are exported to a micro-simulation, for detailed analysis, the attribute number of lanes translates into the physical width of the street in the simulation. Friction effects from parking manoeuvres may then be explicitly part of the simulation and would therefore be accounted for twice. Where bus lanes exist along a link care must be taken to represent link capacity accurately. We advise that bus lanes are included in the overall number of lanes, but that the link capacity excludes the capacity of the bus lane. However, because taxis can travel in bus lanes, the final capacity of the link for general traffic and taxis must be increased with additional capacity added to the overall link capacity to account for a proportion of taxis travelling in bus lanes. This additional capacity can be road type specific or to a particular link where site observations exist.
6.4.3
Signalised Junctions
Junctions are the dominant source of delay in congested urban networks. It is therefore critical that junctions are coded accurately, and that modelling software correctly simulates the operation and capacity of junctions. HTA modelling software packages will simulate junction capacity using different methods. However, it is common that junction attributes will include data that defines junction geometry and the average method of traffic control. SATURN relies on a propagation of Cyclic Flow Profiles (CFP) for calculation of the actual turn delays within a junction (see Figure 14). The CFP method allows accurate calculation of delay by inherently considering the impact of platoon progression on junction turn interaction. To achieve the correct capacity SATURN regards all turning movements at a junction as assignment links with specific Volume-Delay Functions (VDFs). Unlike conventional assignment link functions, the volume-delay curve within SATURN is not user specified or pre-defined but is calculated by the software using input information on signal settings, turning priorities and saturation flows.
156
VISUM uses a different approach, by using an Intersection Capacity Analysis (ICA) module which is based on the Highway Capacity Manual65 (HCM) method for calculating junction turn capacities and delays within isolated junction models. The HCM methodology treats junctions in isolation and thus disregards the effects of signal coordination. VISUM corrects this within ICA by modifying the junction turn delay based on the link attribute ICAArrivalType, a parameter which describes the nature of traffic platoons. Complex and/or large junctions (e.g. dual carriageway junctions) in navigational networks are often not represented by a single node, but instead by a group of nodes. One individual node then corresponds to only one part of an actual junction and application of the HCM formulae to each of these sub-nodes would yield erroneous results within VISUM. The solution adopted in VISUM is to group all nodes comprising a given intersection into a single main node. This can be illustrated by Figure 18, which shows a four leg intersection with separate carriageways in the eastwest direction. For the purpose of signalling, capacity and delay calculations this has been combined into a single node within VISUM.
Figure 18: A VISUM main node as on-street (left) and within the model (right).
When using the ICA method embedded within VISUM it may not seem necessary to specify free-flow turn time (t0 in VISUM) and capacities for turns. However the bi-level calculation method within VISUM initiates a classical VDF-based equilibrium assignment which requires both free-flow turn time (t0) and turn capacity. It is for this initial assignment that the attributes need to be specified. Experiments have shown using VISUM that converged solutions are quite stable against changes of the initial t0 and turn capacity, so the choice of these values is not critical. Recommended values are: Initial t0 = 10s; and Initial turn capacity = 1500 PCU/hour x effective number of turn lanes. The effective number of turn lanes is given by: 1.0, if the lane is exclusive; or 0.5 or 0.333 if shared with one or two other movements.
157
The procedure used when converting ICA parameters into turn volume delay functions successively overwrites turn capacities with new estimates from ICA. In order to restore initial values and reproduce results, it is necessary to input initial turn capacities as a VISUM User-Defined Attribute (UDA) instead of the in-built turn attribute. ICA calculations for over-saturated junctions may yield very small capacities. While this should not occur in the converged solution, it may happen during the first iterations and can then lead to numerical problems. A reliable countermeasure is to specify a minimum turn capacity, as a UDA, to use as a lower bound for re-estimated capacities. A minimum capacity of 100 PCU/hour has been found to work in practice. The value can be justified since a number of vehicles can be stored in the junction and clear during the subsequent interstage even when the opposing flow is saturated.
158
INCORRECT
N 25303382
25303429
SE
25478624 W 566029774
25803560 NW 566028850 S
CORRECT
N 25303382 25303429 25478624 E
566029774 W 566028850 S
25803560
Figure 19: Examples of incorrect and correct network coding using a dual carriageway junction in VISUM.
159
SATURN uses cyclic flow profiles (CFP) based on turning movements, which consist of four different patterns: IN, ARRIVE, ACCEPT and OUT. The ACCEPT profile is derived independently based on capacity, signal timing and conflicting traffic. The accurate generation of this profile is critical to a model and thus occupies a large proportion of the required coding. The calculation of the saturation flows in SATURN is vulnerable to inconsistency during network coding. This is because modellers must use a level of interpretation when developing a network and thus practitioners may use generic saturation flow values for specific turn types. This may be acceptable for specific networks but the preferred option should be for measured saturation flow values. VISUM also allows users to override the ideal turn saturation flow. It may be necessary to use this feature when the ICA (HCM) method conflicts with more detailed modelling or site observation. In all other cases use of the saturation flow override is discouraged in VISUM as it effectively disables the sensitivity of the model to changes in junction geometry or signal timing. There are two important network attributes that have an important influence on ICA results within VISUM: Link attribute ICAArrivalType describes the nature of traffic platoons. This should be calculated from the platoon progression on each link, and is used in lieu of signal offset values that are not applied within ICA turn delay calculations; and Node attribute Sneakers describes the minimum number of vehicles which will succeed in making an opposed right-turn within each cycle. A single value applies to all movements at the node. For opposed turns with high conflicting flows, the sneakers will be virtually all capacity available for that turn. Care should be taken in setting a realistic value based on the physical storage available within the intersection. Within VISUM it is also recommended to define a lower threshold in a UDA MINCAP which maintains a minimum capacity during ICA re-estimation. The lower threshold must be adjusted to be greater than, or equal to, the base volume. The following approach for this adjustment is suggested: MINCAP = min(MINCAPorig, 1.1 * base volume) where MINCAPorig refers to the original value (e.g. 100). Eq. (1)
6.4.4
Priority Junctions
Priority junctions should be modelled with same level of detail as signalised junctions. Intersection geometry and vehicle gap acceptance is used to calculate capacity at priority junctions. SATURN requires cycle time duration when coding non-signalised junctions. A default parameter (LCY = 75 seconds) will be used if a value is not entered for a particular intersection. It is advised to enter the value for cycle time of the nearest signalised junction, as failure to do so may impact CFPs between adjacent junctions and potentially poor representation of traffic platooning within the network. In VISUM, the main input for priority ICA calculations is the major flow, i.e. the direction of priority. Major flow is technically defined as a pair of node legs. Care should be taken
160
when modelling main nodes or nodes with dual-carriageway approaches. As shown in the example within Figure 19, opposing pairs of one way links must be converted to one node leg (by giving them the same orientation) which then allows the major flow to be defined correctly on those node legs. The ICA calculation of capacity and delays at priority-controlled junctions is primarily based on gap acceptance headways. Critical gap and follow-up gap parameters can be defined by the user or retained as default values provided by HCM. A user-defined override may be required for a roundabout entry as there is no roundabout specific delay model within VISUM. It is advisable that critical gap and follow-up gap values for non-standard priority junctions are estimated within local-scale models such as PICADY and ARCADY (as described in A9.2.2).
6.4.5
Public Transport
Public transport can absorb a proportion of capacity on some network links and turns. The impact of public transport should be carefully considered, particularly on mixed use links with no dedicated public transport lane. This section explains how the capacity effect of public transport is addressed within VISUM. The number of bus trips during the assignment period is used as a preload for all turns, and for those links without a bus lane. In SATURN, a bus-only lane is defined to be a full-length lane from the upstream entry to the downstream stopline. This means bus lanes with set-backs cannot be explicitly modelled within SATURN. This full length lane is used exclusively by any form of public transport being coded as a segregated from general traffic. In VISUM, the assignment procedure can access several link and turn UDAs which are preset during network coding: Link UDAs BUS_LANES: a 0-1 integer attribute which indicates the presence of one or more dedicated bus lanes along the link (1 = present); and BUS_LOAD: the number of buses that pass along the link during the assignment period. Turn UDAs BUS_LOAD: the number of buses that pass along the turn during the assignment period. It is worth noting that BUS_LOAD has a significant effect on available capacity making it important to specify consistent values for all links. It is advisable to include bus routes with their timetables in the same network model used for road traffic assignment. It is then possible to use analysis functions to count and assign the number of buses within each assignment period for each link or turn.
161
6.5
Calibration
Calibration of a HTA model involves altering network parameters (e.g. capacities) and travel demand in an attempt to match modelled data (e.g. traffic flows and journey times) to observed data. This section will not describe the typical parameters used for this exercise (i.e. turn and link counts, journey times and speeds), as the required methodology is not specific to the calibration of HTA models. It is recommended that attention is paid to the location of base data used for calibration and validation to ensure a consistent level of quality across the model study area. One useful approach is to use traffic counts along a series of north-south and east-west screenlines for validation, whilst using counts within the cells formed by those screenlines for calibration purposes. This subsection will cover some of the more specific capacity calibration exercises used by TD when HTA modelling using VISUM. VISUM uses the ICA module for capacity and delay calculation. For the ONE model a number of detailed deterministic models (LinSig/TRANSYT) were used to retrieve capacity delay outputs and overwrite the internal ICA calculation. To do this LinSig/ TRANSYT models were coded with identical traffic flow and timing plans as the ONE model. TRANSYT models were also used to indicate the quality of traffic progression between signals. The ICAARRIVALTYPE parameter was adjusted to accommodate the level of progression. The empirical models provided detail about flared approaches. Capacities were then adjusted according to all the information provided. Delay and DoS from the local scale models were then compared against ICA output. VISUM calibration parameters were then adjusted to align ICA junction performance with the local scale modelling. It is advised that a similar approach be adopted for priority junctions. For junctions of this type the VISUM calibration parameters which require adjustment will be the critical gap and follow up time, as these values fundamentally control the time required for an average driver to accept a gap in oncoming flow and merge with traffic.
6.6
Assignment
Route assignment, route choice or traffic assignment relates to the selection of routes (paths) between origins and destinations in transportation networks. A common assignment procedure within HTA modelling is based on Wardrops Principle of Equilibrium66, where travel cost is assumed to depend on the volume of flow in the network. Using this principle, an assumption is made that all drivers have the same perfect knowledge of routes in the network, and that they all seek to minimise the cost of travel without having any preference for the type of road they use (i.e. main or side road). Multiple user class (MUC) assignment can also be used to achieve equilibrium between modelled supply and demand. This is achieved by biasing certain user classes towards longer (rat run) or shorter (sign posted) routes.
66 Wardrop J G, Some theoretical aspects of road traffic research, Proceedings, Institution of Civil Engineers, PART II, Vol.1, 1952, pp325-378.
162
SATURN can undertake MUC assignment using a similar approach to Wardrop equilibrium. Instead of a single all or nothing assignment SATURN completes one assignment for each user class and updates costs after all user classes have been re-assigned. Hence at the end of the algorithm the fraction of trips assigned to each iterations routes is identical across all classes. SATURN also contains a Stochastic User Equilibrium (SUE) assignment algorithm, but from a practitioners point of view it is advisable to use Wardrop equilibrium assignment within a congested urban network. PTV AG advocates the use of the Equilibrium Lohse procedure67 within VISUM. The Equilibrium Lohse procedure simulates the learning process of road users using the network. Based on an all or nothing assignment, drivers make use of information gained during their previous trip for the new route search. TD believe this is the best methodology for HTA modelling within London using VISUM. This type of assignment was used for the ONE model in combination with Wardrop equilibrium.
6.6.1
Figure 20: A bi-level approach to traffic assignment with operational-level turn delays.
67 Schnabel W & Lohse D, Grundlagen der Straenverkehrstechnik und der Verkehrsplanung, Volume 2, Verlag fr Bauwesen, Berlin, 1997.
163
VISUM and SATURN allow operational-level turn delays and generally use the same approach to overcome the problem as illustrated in Figure 20. After initialisation an iterative loop is generated, which alternates between an assignment using turn VDFs and the calculation of turn delays and capacities using ICA. Executions of the bi-level loop will be called loop iterations, to distinguish them from the equilibrium iterations inside the assignment. Traffic is first assigned to the network within each loop using a small fixed number of equilibrium iterations (typically 5 or 10). The assignment uses turn VDFs which are of the following general form68: tcur (sat) =
Eq. (2)
6.6.2
Convergence
High levels of convergence should be achieved in HTA modelling. This is important because if link flows and their corresponding flow-delay curves are not reasonably consistent then there is little confidence in modelled output, such as link flows, costs, etc. Convergence also provides confidence that any differences in traffic flow between converged base and proposed networks can be ascribed to the effects of the scheme being tested rather than random noise which may arise on the base network if flows were compared from one run of assignment to the next. In VISUM, the bi-level assignment method will be assumed to have converged sufficiently if all of the following criteria have been met: The last batch of equilibrium assignment iterations has reached a gap of 0.001; 95% of assigned turn flows between two successive loop iterations have converged within 1%; 95% of assigned turn flows from the last loop iteration are within 1% of the smoothed flows used for junction capacity analysis; and 90% of turn delays from calibrated turn volume delay functions are within 5% of turn delays calculated from the junction capacity analysis module.
68 Traffic Assignment Manual, Bureau of Public Roads, Urban Planning Division, U.S. Department of Commerce, Washington, DC, 1964.
164
These criteria are assessed after VISUM ICA evaluation. If criteria are not met, new parameters for the turn volume delay functions (and in the case of blocking back, new link capacities) will be estimated from the ICA results and the assignment loop will be re-executed. Concerns regarding convergence are discussed in detail by the DMRB, but TD NP believes the following general guidance should be applied: Convergence in practice needs to be measured in terms of two desirable properties of the flows and costs calculated by the programme: Stability of the model outcomes between consecutive iterations; and Proximity to the assignment objective, (e.g. Wardrop equilibrium) 69 In the context of SATURN, proximity indicators measure the degree to which the assignment sub-model has achieved its stated aim. In the case of equilibrium assignment this means the degree to which Wardrop equilibrium has been achieved. DMRB recommends Delta (a relative measure of excess travel cost) as the proximity measure for Wardrop equilibrium assignment, and states that it must be less than 1%. Proximity indicators should also include a measure for the simulation sub-model and changes in output Cyclic Flow Profiles. Stability indicators measure the change between concurrent model iterations and are of particular relevance within the assignment-simulation loop. DMRB outlines two types of stability indicator: Global indicators, that provide network-wide comparisons of total costs, distances, times and average speeds; and Disaggregate indicators, which provide absolute change in individual link parameters such as flow, cost, time, etc. The most important convergence measure for user equilibrium assignment is the percentage change of traffic flow on the individual links. DMRB states that at least 90% of links should have a flow change of less than 5% and this should be maintained for the final four iterations.
6.7
Model Validation
Network validation data must be independent from data used during calibration. This data independence ensures that validation statistics are a true measure of validation. It is not appropriate to supplement the data used for calibration with validation data in order to improve the quality of model validation. The validity of a HTA model should be assessed by comparing the model volumes and travel times against field observations. It is felt that cordon/screenline counts are a more realistic target than individual turn/link counts.
69 Design Manual for Roads and Bridges, Volume 12, Section 2, Part I, Appendix H, May 1996.
165
Target validation criteria for these data are: 95% of model cordon/screenline flows within a GEH of five compared to observed flows; 95% of all modelled route journey times to be within 15% of observed mean times; and 75% of model turn flows within a GEH of five compared to observed turn flows.
Extended validation criteria using turn flows may be applied where subarea models for detailed design work are planned to be exported from HTA modelling:
95% of model turn flows within a GEH of five compared to observed turn flows; and 95% of model turn flows within 100 (PCU/hour) difference compared to observed turn flows. Accuracy of observed counts must be within 50 PCU/hour or within a GEH of two (see Appendix III). Journey times should be within 10% before validation checks are conducted. However, it is important not to seek to achieve one validation criteria whilst ignoring other equally critical aspects of validation.
6.7.1
166
CLOSING SUMMARY
These Traffic Modelling Guidelines, produced by the Traffic Directorate within TfL Streets, provide overarching guidance on the appropriate standards of traffic modelling required when proposing a traffic signal scheme on Londons urban network. Modelling experts within TfL and across the industry have contributed to this document. Part A provides a high level overview of traffic modelling for a non-technical audience, whilst Part B presents specific advice and standards for practitioners. The document can be read as a whole entity, but can also be used as a reference for particular traffic modelling issues. The content of these guidelines was correct at the time of publishing, based on versions of software that were in everyday use in TfL TD. Since traffic modelling software vendors are continually developing new versions of their software, the intention is to treat this document as an evolving entity. It will continue to be updated in the future to provide best practice advice on new products, concepts and techniques as they are developed and tested in our working environment. All advice provided in the Traffic Modelling Guidelines is non-binding but is directly related to the way TfL operates Londons traffic management systems. This document builds upon the success of the two previous versions, which have been used as guidance during the development of numerous traffic models both in the UK and overseas. The latest version of this document is available to download from: http://tfl.gov.uk/streetspublications We encourage feedback on the advice given in this document. Please address all comments, specifying that they are related to the Traffic Modelling Guidelines Version 3.0, to: TfL Traffic Modelling Guidelines, Network Performance, Traffic Directorate, Surface Transport, Transport for London, 3rd Floor, Palestra, 197 Blackfriars Road, LONDON, SE1 8NJ. TfLModellingGuidelines@TfL.gov.uk
Glossary
167
GLOSSARY
AIMSUN ANPR AQMA ARCADY ASL BP BR&P CE CFP CLF COBA CTM CYOP DE DfT DMRB DoS DSD EQUISAT FlowRound FPT GIS GLA Advanced Interactive Microscopic Simulator for Urban and nonurban Networks, modelling software developed by TSS Automatic Number Plate Recognition Air Quality Management Area Assessment of Roundabout Capacity And DelaY, modelling software developed by TRL Advanced Stop Line (for cyclists) Bus Priority Better Routes and Places Directorate, formerly the London Road Safety Unit Checking Engineer, key role identified in MAP Cyclic Flow Profile Cableless Linking Facility COst Benefit Analysis, described in the DMRB Cell Transmission Model, new traffic model introduced in TRANSYTv13 in addition to PDM CYcle time OPtimisation, a TRANSYT feature used to select an appropriate cycle time for a modelled network Design Engineer, key role identified in MAP The Department for Transport Design Manual for Roads and Bridges Degree of Saturation Desired Speed Decision (used in VISSIM modelling) A TRANSYT feature that provides an initial set of signal timings prior to optimisation, based on equal saturation of critical conflicting links Software for the analysis of spiral traffic lane movements at signalised and unsignalised roundabouts, developed by JCT Forward Planning Team, formerly Network Assurance Team Geographic Information System Greater London Authority
168
HCM HGV HTA ICA ITS JCT LCAP Legion LGV LinSat LinSig LSTCC LTA LTS MAE MAP MGV MME MMQ MOVA MUC NAE NAQS NMD NMG NP O/D ONE OS
Highway Capacity Manual Heavy Goods Vehicle Highway Traffic Assignment Intersection Capacity Analysis (used in VISUM modelling) Institute for Transport Studies, University of Leeds JCT Consultancy Ltd, developer of FlowRound, LinSat, LinSig and TranEd London Congestion Analysis Project Pedestrian modelling software, developed by Legion Ltd Light Goods Vehicle Freely available software developed by JCT, allowing the estimation of effective flare usage based on flow data Modelling software developed by JCT London Streets Traffic Control Centre (within TD) Local Traffic Authority London Transportation Studies, strategic model Model Auditing Engineer, key role identified in MAP Model Auditing Process Medium Goods Vehicle Mean Modulus of Error Mean Maximum Queue Microprocessor Optimised Vehicle Activation Multiple User Class (assignment) Network Assurance Engineer, key role identified in MAP National Air Quality Strategy Network Management Duty (see TMA) TfL Surface Network Management Group Network Performance (within TD), formerly Urban Traffic Control (UTC) Origin-Destination (matrix) Operational Network Evaluator Ordnance Survey (Mapping)
Glossary
169
OSCADY PRO P PI PICADY PCU PDM PRC .PRT PTV QueProb RD RR67 RSA SAE SAFENET SASS SATURN SCOOT SLD SQA-0064 SRN SUE SVD TD
Optimised Signal Capacity And Delay: Phase-based Rapid Optimisation, modelling software developed by TRL Promoter, key role identified in MAP Performance Index, a monetary value used in TRANSYT to assess the cost of stops and delays in a network Priority Intersection Capacity And DelaY, modelling software developed by TRL Passenger Car Unit Platoon Dispersion Model, the traditional traffic model used in TRANSYT Practical Reserve Capacity Output file produced by TRANSYT detailing model results Planung Transport Verkehr (PTV) AG, developer of VISSIM and VISUM TRANSYT feature allowing the estimation of effective flare usage based on flow data TfL Streets Road Directorate Research Report 67, publication by TRL describing a methodology for the prediction of saturation flows Reduced Speed Area (used in VISSIM modelling) Signals Auditing Engineer, key role identified in MAP Software for Accident Frequency Estimation for NETworks, accident modelling software developed by TRL System Activated Strategy Selection Simulation and Assignment of Traffic to Urban Road Networks, modelling software suite developed by ITS Split, Cycle and Offset Optimisation Technique, developed by TRL Site Layout Drawing TfL TD Document, Technical Specification SQA-0064, containing Design Standards for Signal Schemes in London (formerly TTS 6) Strategic Road Network Stochastic User Equilibrium (assignment) Selective Vehicle Detection TfL Streets Traffic Directorate, formerly Directorate of Traffic Operations (DTO)
170
TI TfL TLRN TMA TMAP TranEd TRANSYT TRL TSS TSSR UDA UGT UTC VA VAP VDF VISSIM VISUM VMAP WebTag
Traffic Infrastructure (within TD) Transport for London Transport for London Road Network Traffic Management Act 2004 TRANSYT Model Auditing Process (see MAP) Software developed by JCT to provide an improved graphical user interface for TRANSYT versions 12 and earlier TRAffic Network StudY Tool, modelling software developed by TRL Transport Research Laboratory (TRL Ltd), developer of ARCADY, OSCADY PRO, PICADY, SAFENET, SCOOT and TRANSYT Transport Simulation Systems, developer of AIMSUN Traffic Signal Supplementary Report User-Defined Attribute (used in VISUM modelling) Underutilised Green Time Urban Traffic Control Vehicle Actuation Vehicle Actuated Programming (used in VISSIM modelling) Volume-Delay Function (used in strategic/HTA modelling) Verkehr In Stdten SIMulation (meaning: Traffic In Towns SIMulation), modelling software developed by PTV Verkehr In Stdten UMlegung (meaning: Traffic In Towns Assignment), modelling software developed by PTV VISSIM Model Auditing Process (see MAP) DfT Transport Analysis Guidance
APPENDICES
Appendices
173
174
Where: qd = Total Flow during full demand (PCU) F = Effective Flare Utilisation (PCU) SFF = Saturation Flow (PCU/hr) DoS Formula by means of UGT 3600 qx Tc DoS = x 100 Gt UGT + 1 SFF x Tc 3600 qx Tc DoS = x 100 Gt UGT + 1 F x 3600 SFF x + Tc Tc Where: q = Total Sample Flow (PCU) Gt = Green Time (seconds) UGT = Underutilised Green Time (seconds) TC = Cycle Time (seconds) F = Effective Flare Utilisation (PCU) SFF = Saturation Flow (PCU/hr)
without flare
Eq. (6)
with flare
Eq. (7)
Appendices
175
176
Appendices
177
178
Appendices
179
GEH =
(M C)2 (M + C) 2
Eq. (8)
Where: M = Modelled flow C = Counted (Observed) flow Smaller GEH values indicate a better fit between observed and modelled flows. Below is a sample set of values to demonstrate the use of the GEH statistic compared with a simple percentage difference:
An additional method for the comparison of flows is to plot observed versus modelled flows and carry out a correlation analysis. This method provides an indication of the goodness of fit (R correlation statistic) and clearly indicates whether the model is over or under representing flows.
180
Appendices
181
travel demand that is dynamic should be assigned over a number of iterations to show stable convergence of assignment. DA Method Three The third method utilises external highway assignment software to guarantee convergence. This may be necessary should neither of the first two approaches lead to a stable assignment. Assignment of travel demand is undertaken in VISUM where the path and cost files can be directly exported to VISSIM for further detailed simulation and analysis.
The latest version of this document is available to download from: http://tfl.gov.uk/streetspublications Transport for London, September 2010