evaluation of autodesk infraworks 360 and ptv...

Department of Civil and Environmental Engineering

Division of GeoEngineering

Road and Traffic Research Group CHALMERS UNIVERSITY OF TECHNOLOGY

Master’s Thesis BOMX02-17-02

Gothenburg, Sweden 2017

Evaluation of Autodesk InfraWorks 360 and PTV Vissim A comparative study of two traffic simulation software products

Master’s Thesis in the Master’s Programme Infrastructure and Environmental Engineering

SAMANTHA AVRAMOVIC EMELIE JOHNSSON

Replace the shaded box with a picture illustrating the content of the thesis. This picture should be “floating over the text” in order not to change the position of the title below (right clic on the picture choose “Layout” and “In front of text”

MASTER’S THESIS BOMX02-17-02

Evaluation of Autodesk InfraWorks 360 and PTV Vissim A comparative study of two traffic simulation software products


SAMANTHA AVRAMOVIC

EMELIE JOHNSSON



Road and Traffic Research Group

CHALMERS UNIVERSITY OF TECHNOLOGY

Göteborg, Sweden 2017

I

Evaluation of Autodesk InfraWorks 360 and PTV Vissim

A comparative study of two traffic simulation software products


SAMANTHA AVRAMOVIC

EMELIE JOHNSSON

© SAMANTHA AVRAMOVIC, EMELIE JOHNSSON, 2017

Examensarbete BOMX02-17-02/ Institutionen för bygg- och miljöteknik,

Chalmers tekniska högskola 2017




Chalmers University of Technology

SE-412 96 Göteborg

Sweden

Telephone: + 46 (0)31-772 1000

Cover:

Figure depicting the road network of Hisingsleden and Assar Gabrielssons väg modelled in

Autodesk InfraWorks® 360

Chalmers Reproservice / Department of Civil and Environmental Engineering Göteborg, Sweden, 2017

I

Evaluation of Autodesk InfraWorks 360 and PTV Vissim

A comparative study of two traffic simulation software products

Master’s thesis in the Master’s Programme Infrastructure and Environmental

Engineering

SAMANTHA AVRAMOVIC

EMELIE JOHNSSON




Chalmers University of Technology

ABSTRACT

Traffic simulation is an important tool used to analyse and evaluate different traffic situations.

It can be used to analyse queue lengths and traffic flows as well as what effects different road

designs have on a traffic system. PTV Vissim is one of the leading commercial traffic

simulation software products with a high level of detail which can make it time consuming to

set up a model in the software. InfraWorks® 360 is a software used for preliminary engineering

and design with a relatively new traffic simulation tool as an addition to the software. No earlier

comparative studies of the two software products were found and therefore the aim of this study

is to do a general comparison and evaluation of them. Also, a comparison of the simulation

output results was made to see how they correlate with each other. This was done by setting up

a future road design of Hisingsleden in both software products. The model contains an

interchange, two non-signalised intersections and a signalised intersection. Only motor vehicles

were taken into account and a visual calibration was done. The evaluation method evaluates the

software programs in four different categories dealing with topics like: the accuracy and user

flexibility of the program; how time efficient it is to set up a model; how user friendly the

software is and how available information about the program is; what simulation outputs are

available and if they are relevant. The results show that Vissim got a higher score in three of

the four categories: Education, Simulation output and Accuracy/Flexibility. InfraWorks got a

higher score in the Efficiency category mostly due to the fact that many settings are

automatically generated. However, this limits the user flexibility and thus also the model setup

accuracy. Difficulties in setting up a complex road network and unrealistic driving behaviour

were noticed when working with InfraWorks. Therefore, the traffic simulation tool in

InfraWorks can be choice when setting up simple road networks that do not require a high level

of detail or accuracy. It may be a good tool to use to get a basic and quick overview of traffic

flows in different traffic situations. Vissim is a user friendly software with high flexibility. Even

though the user interface is easy to understand it is a complex software with a lot of possibilities

for the user. Therefore, the setup of a model is more complex but the final model is more

accurate and customized according to the user’s requests. Problems and questions regarding

Vissim can often be solved since there is a lot of detailed information available from both

software developers and other users. Vissim is a diverse, accurate traffic simulation tool that

can be used for both simple and more complex traffic situations. Vissim is therefore

recommended to be used for traffic analyses. Differences were observed between the two

programs’ simulation results. It is plausible that the differences mainly depend on the user

settings and the different definitions of functions in the programs. It is important to keep in

mind that the software products are constantly evolving and that updates are being released

continuously. Thus, it is possible that the results may differ in an eventual future study.

Keywords: traffic simulation, PTV Vissim, InfraWorks 360, evaluation, comparison

II

Utvärdering av Autodesk InfraWorks 360 och PTV Vissim

En jämförande studie av två trafiksimuleringsprogram

Examensarbete inom masterprogrammet Infrastructure and Environmental

Engineering

SAMANTHA AVRAMOVIC

EMELIE JOHNSSON

Institutionen för bygg- och miljöteknik

Avdelningen för Geologi och Geoteknik

Väg och Trafik

Chalmers tekniska högskola

SAMMANFATTNING

Trafiksimulering är ett viktigt verktyg som används för analysering och utvärdering av olika

trafiksituationer. Det kan användas för att analysera kölängder och trafikflöden samt vilka

effekter olika vägutformningar har på ett trafiksystem. PTV Vissim är ett av de ledande

kommersiella trafiksimuleringsprogram med hög detaljnivå vilket kan leda till ett tidskrävande

modellbyggande i programvaran. InfraWorks® 360 är ett program som används för vägprojekt

i tidigt skede och har ett relativt nytt trafiksimuleringsverktyg som tillägg till programvaran.

Under en sökning hittades inga tidigare jämförande studier av de två programmen. Därmed är

syftet med denna studie att göra en generell jämförelse och utvärdering av dem. Dessutom

gjordes en jämförelse mellan simuleringsresultaten och hur de korrelerar med varandra. Detta

gjordes genom att sätta upp en framtida modell av Hisingsleden i de båda programmen.

Modellen innehåller en planskild trafikplats, två osignalerade plankorsningar samt en

signalerad korsning. Studien tar endast hänsyn till motorfordon och en visuell kalibrering

gjordes. Metoden som användes för utvärdering av programmen bestod av fyra olika kategorier

som behandlar följande: programmets noggrannhet och användarflexibilitet; hur tidseffektivt

det är att skapa en modell; hur användarvänlig programvaran är och hur pedagogisk den

tillgängliga informationen om programmen är; vilka simuleringsutdata som är tillgängliga och

hur relevanta de är. Utvärderingen resulterade i att Vissim fick högre poäng i tre av de fyra

kategorierna: Inlärningsprocess, Simuleringsutdata och Noggrannhet/Flexibilitet. InfraWorks

fick högre poäng i Effektivitetskategorin, främst på grund av att många inställningar genereras

automatiskt. Detta begränsar dock användarens flexibilitet och därmed även modellens

inställningsnoggrannhet. Vissa svårigheter noterades då ett komplext vägnät byggdes upp i

InfraWorks och ett orealistiskt körbeteende observerades hos fordonen.

Trafiksimuleringsverktyget i InfraWorks kan därmed vara ett bra alternativ vid enkla

vägmodeller som inte kräver en hög detaljnivå eller noggrannhet. Det kan vara ett bra verktyg

att använda för att få en grundläggande och snabb översikt över trafikflöden i olika

trafiksituationer. Vissim är ett användarvänligt program med hög flexibilitet. Även om

användargränssnittet är lätt att förstå är det ett komplext program med många möjligheter för

användaren. Byggandet av en modell blir därför mer komplext men den färdiga modellen blir

mer exakt och anpassad efter användarens önskemål. Problem och frågor som uppstår kring

Vissim kan ofta lösas eftersom det finns mycket detaljerad information tillgänglig från både

programutvecklarna och andra användare. Vissim är ett mångsidigt och noggrant

trafiksimuleringsverktyg som kan användas för både enkla och mer komplexa trafiksituationer.

Vissim rekommenderas därför att användas för trafikanalyser. Skillnader mellan de två

programmens simuleringsresultat observerades. Det är troligt att skillnaderna i huvudsak beror

på användarinställningarna samt de olika funktionsdefinitionerna i programmen. Det är viktigt

att komma ihåg att programmen ständigt utvecklas och att uppdateringar släpps löpande. Det

är således möjligt att resultaten kan skilja sig åt i en eventuell framtida studie.

Nyckelord: trafiksimulering, PTV Vissim, InfraWorks 360, utvärdering, jämförelse

CHALMERS Civil and Environmental Engineering, Master’s Thesis BOMX02-17-02 III

Content

ABSTRACT I

SAMMANFATTNING II

CONTENT III

PREFACE VII

1 INTRODUCTION 1

1.1 Aim 1

1.2 Objectives 2

1.3 Method 2

1.4 Limitations 2

2 STUDY AREA 3

2.1 Interchange A 4

2.2 Intersection B 5

2.3 Intersection C 6

2.4 Intersection D 6

3 INFRAWORKS 360 7

3.1 Road network setup 7

3.2 Non-signalised intersections 7

3.3 Signalised Intersections 8

3.4 Traffic analyst panel 8

3.5 Vehicle demand 9

3.6 Simulation output 9

4 PTV VISSIM 11

4.1 Road network setup 11

4.2 Non-signalised intersections 11

4.3 Signalised intersections 12

4.4 Vehicle demand 12

4.5 Simulation output 13

5 METHODOLOGY 15

5.1 Data collection 16

5.2 InfraWorks 360 17 5.2.1 Road network set up 17 5.2.2 Calibration and validation 19 5.2.3 Simulation output 23

CHALMERS, Civil and Environmental Engineering, Master’s Thesis BOMX02-17-02 IV

5.3 PTV Vissim 23 5.3.1 Road network set up 23 5.3.2 Calibration and Validation 24 5.3.3 Simulation output 26

5.4 Evaluation method 26 5.4.1 Education 27 5.4.2 Simulation output 28 5.4.3 Efficiency 28 5.4.4 Accuracy/Flexibility 29

6 RESULTS 30

6.1 Evaluation results 30 6.1.1 Education 31 6.1.2 Simulation output 32 6.1.3 Efficiency 32 6.1.4 Accuracy and flexibility 33

6.2 Comparison of simulation results 34 6.2.1 Network output 34 6.2.2 Stops 35 6.2.3 Density 35 6.2.4 Delay 37 6.2.5 Travel time 38 6.2.6 Queue length 38

7 DISCUSSION 40

7.1 Model set up 40

7.2 Evaluation 41

7.3 Simulation results 42 7.3.1 Network output 42 7.3.2 Stops 42 7.3.3 Density 42 7.3.4 Delay 43 7.3.5 Travel time 43 7.3.6 Queue length 43

7.4 Further studies 44

8 CONCLUSIONS AND RECOMMENDATIONS 45

REFERENCES 46

APPENDIX 1 – ZONES AND LINK SEGMENTS 48

APPENDIX 2 – INFRAWORKS 360 52

APPENDIX 3 – SIMULATION THEORY 54

APPENDIX 4 – LEVEL OF SERVICE 57

CHALMERS Civil and Environmental Engineering, Master’s Thesis BOMX02-17-02 V

APPENDIX 5 – PTV VISSIM 58

APPENDIX 6 – DATA COLLECTION 60

APPENDIX 7 – INPUT DATA IN INFRAWORKS AND VISSIM 65

APPENDIX 8 – SIMULATION RESULT 67

CHALMERS, Civil and Environmental Engineering, Master’s Thesis BOMX02-17-02 VI

CHALMERS Civil and Environmental Engineering, Master’s Thesis BOMX02-17-02 VII

Preface

In this study, the traffic simulation software products PTV Vissim and Autodesk InfraWorks 360 have been compared and evaluated. This master thesis was conducted at the Department of Civil and Environmental Engineering at Chalmers University of Technology in collaboration with Norconsult AB. The study was carried out during the period of January to May 2017 by the authors Samantha Avramovic and Emelie Johnsson, with support from supervisors Claes Johansson and Gunnar Lannér at the Road and Traffic Research Group at Chalmers University of Technology. We would like to thank all the people working at Norconsult AB for contributing to a positive workplace and a special thanks to our supervisor Johan Hultman who works at the traffic division, your guidance and support has been helpful throughout the study. We also want to thank our opponents Emma Bentström and Khaled Saadeddin for their valuable feedback. Lastly, we would like to thank each other for the many laughs shared together throughout these months. Gothenburg, May 2017 Samantha Avramovic and Emelie Johnsson

CHALMERS, Civil and Environmental Engineering, Master’s Thesis BOMX02-17-02 VIII

CHALMERS Civil and Environmental Engineering, Master’s Thesis BOMX02-17-02 1

1 Introduction

People’s travel possibilities and behaviour is depending on the infrastructure and its design (Trafikverket, 2015). Infrastructure decisions will affect the society during a long time and it is therefore important to evaluate what consequences on accessibility, environment and traffic safety they lead to. Forecasting is an important method to get a picture of how different scenarios affect people’s travel behaviour. It makes it possible to identify both current and future traffic limitations and can thereby serve as a basis for politicians and other decision makers to make appropriate traffic planning decisions. Traffic simulation is an important tool and can be used to complement the forecast to analyse and evaluate effects of a certain road design. Traffic simulations analyse effects on accessibility and the dynamic of traffic situations, like queue building, as well as the possible capacity. This helps decrease the risk for unnecessary costs caused by a too high or too low traffic capacity (Bång, et al., 2014). Simulations are also a good tool to visualise different traffic situations. There are different levels of detail when simulating models; macroscopic, mesoscopic and microscopic (Bång, et al., 2014). Macroscopic simulations describe the traffic as vehicle flow while microscopic simulations describe the movements of single vehicles. The detail level of mesoscopic simulations is in between macro and micro. Different software products are used for the different detail levels. The disadvantages of simulations are that it is often assumed that the studied area is not affected by other parts of the traffic system (Bång, et al., 2014). Also, the accuracy of the results depend on how well the road user behaviour is adapted in the software. This requires accurate in data and well-executed calibration and validation of the modelled traffic situation which can be time consuming depending on the complexity of the model and the experience of the user. There is therefore an interest from users to make traffic simulations more efficient. PTV Vissim is one of the leading commercial traffic simulation software products and in Sweden it is the most used software for microscopic traffic simulations (Bång, et al., 2014). It is possible to create complex models with high detail level which can analyse the integration of private and public traffic. However, it is because of the high level of detail it can be time consuming to build a model in PTV Vissim depending on the complexity of the traffic situation. InfraWorks® 360 is a software by Autodesk used for preliminary engineering and design (Autodesk Inc., 2017a). By using a model builder a model for a specified area of interest can be created quickly. The traffic simulation tool is a relatively new addition to the software for which few studies have been done. From now on PTV Vissim is referred to as Vissim and InfraWorks® 360 as InfraWorks. Earlier comparative studies have been done between Vissim and other traffic simulation software products. Since few studies have been done on simulations in InfraWorks, there is an interest to compare it with the more established simulation software Vissim.

1.1 Aim

The aim for this thesis is to do a general comparison of the two traffic simulation software products PTV Vissim 9 and Autodesk InfraWorks® 360 2017. The thesis compares the accuracy/flexibility, efficiency of the programs as well as the simulation results and the learning process. The comparison was done by simulating the traffic situation at four junctions along Assar Gabrielssons väg and Hisingsleden in Gothenburg, Sweden.

CHALMERS, Civil and Environmental Engineering, Master’s Thesis BOMX02-17-02 2

1.2 Objectives

To describe the aim more specifically, the following questions were developed:

• Does the learning process differ between the two software products?

• Do the software products produce relevant simulation outputs?

• Is it more efficient, i.e. less time consuming, to build a model in InfraWorks

compared to Vissim?

• Do the software products differ in terms of flexibility and accuracy?

• Is there any difference in the traffic simulation results generated from InfraWorks

respectively Vissim?

1.3 Method

A research was primarily conducted to gather available information about InfraWorks, Vissim and traffic simulation in general. A study area was chosen with guidance from Norconsult AB which is further described in chapter 2. Study area. Relevant data such as traffic flows and the amount of turning vehicles were provided by Norconsult AB and additional data was gathered during a site investigation. During this investigation the traffic situation and driver behaviour was also observed. This was used as basis for the visual calibration of the traffic simulation models. A learning period was given each software product as to learn the basics and how it works. Thereafter the model was set up, calibrated and results were retrieved. The software programs were then evaluated by grading certain categories and criteria. A comparison of the simulation output was also done as to see how and if the results correspond.

1.4 Limitations

The model only considered micro simulations and is limited to the chosen study area. A future version of the site was modelled, see chapter 2. Study area. However, no other projects or changes in the traffic situation of Gothenburg were considered. No extensive field investigation was done in order to measure gap distances, velocities or other factors which could influence a simulation model. Due to limited time a visual calibration was made and thus this information was overlooked. One scenario was simulated in the two software programs and only motor vehicles were considered. Pedestrians, cyclists or public transport were not simulated. The data used for vehicle flow was partly provided by Norconsult AB and partly gathered during the site investigation. A correlation between these data was therefore assumed for the amount of turning vehicles. Since the model represents a future situation it was not possible to compare the simulation results with reality. However, the simulation results from the both software products were compared with each other. To be able to do that, the models were built and calibrated as equally as possible by their lowest common denominator. This means that some parts of the model set up in one software could be limited by the available functions in the other software. Also, the simulation outputs that were compared were limited to both the lowest common denominator between the software products and the most typical measures of effectiveness (MOEs). This because of limited time.


2 Study area

In order to evaluate and compare Vissim and InfraWorks a study area in Gothenburg was chosen for model set up and traffic simulation. The chosen area consists of several junctions, both signalised and non-signalised, and has a varying geometry. A diverse site is appropriate to make a general evaluation of the model building possibilities in a traffic simulation software. The study area consists of two main roads: Hisingsleden and Assar Gabrielssons väg which are currently connected via a signalised intersection. They are situated on Hisingen, the North-West part of Gothenburg. Currently Hisingsleden predominately consists of two lanes, one in each direction and leads to several destinations for heavy traffic, such as the Gothenburg harbour and Volvo factories. The Swedish Transport Administration, Trafikverket, intend to rebuild Hisingsleden into a four lane road with two lanes in each direction as well as replace today’s intersections at the road Assar Gabrielssons väg (marked with black in Figure 1) with an interchange. The project, called E6.20 Hisingsleden - Södra delen, of which Norconsult AB is the project planning consultant, is done in order to increase the capacity of the road as well as provide an attractive alternative to the major destinations in the trail's proximity and to relieve Lundbyleden and E6 from heavy traffic (Trafikverket, 2016). The project is preliminary planned to be done by 2022. By rebuilding an intersection to an interchange the traffic safety increases for both protected and unprotected road users. The location of the studied area is marked with black in Figure 1 and a closer overview of the four junctions are shown in Figure 2. In this report the future interchange between Hisingsleden and Assar Gabrielssons väg will be modelled at intersection A in Figure 2 as well as three intersections along Assar Gabrielssons väg.

Figure 1. Overview of parts of Gothenburg with the road Assar Gabrielssons väg marked with a black square (© Lantmäteriet I2017/00429).


Assar Gabrielssons väg stretches approximately 1150 m. For this study 700 m was modelled, stretching from junction A to D in Figure 2. More information about each junction is presented below and further details of the modelled network can be seen in Appendix 1 – Zones and link segments. The road is located in an industrial area consisting of both factories and office buildings with no residential buildings in the surrounding area. This affects the traffic flow in the area and generates a large flow in the morning and afternoon when workers drive to and from the location. Because of it being an industrial area it also influences the volume of heavy goods vehicles (HGV) present in the road network.

Figure 2. Overview of studied area. Junctions at Assar Gabrielssons väg have been marked with letters A-D. (© Lantmäteriet I2017/00429).

2.1 Interchange A

Interchange A connects Assar Gabrielssons väg with Hisingsleden. It is currently a signalised intersection but will be rebuilt into an interchange. For this study the future interchange design was used for modelling interchange A, see Figure 3. There are two lanes in each direction along Hisingsleden with additional ramps leading to Assar Gabrielssons väg. As seen in Figure 3 one of the ramps leads to a bridge crossing Hisingsleden.


Figure 3. Overview of interchange A with both road and bike path. This is the future design of the connection between Hisingsleden and Assar Gabrielssons väg (Trafikverket, 2016).

2.2 Intersection B

A non-signalised intersection connecting Assar Gabrielssons väg with the roads Amazonvägen and RA, see Figure 4. Amazonvägen leads to office buildings and RA to a parking with a loading area HGV. Three lanes lead to the intersection from point 1; a left turn lane, a through lane and a combined through and right turn lane. Both Amazonvägen and RA have one lane leading to the intersection which enables driving to the right, left and straight forward. At point 2, a through lane and a separate left turn lane lead to the intersection.

Figure 4. Overview of intersection B (© Lantmäteriet I2017/00429).


2.3 Intersection C

A non-signalised intersection connecting Assar Gabrielssons väg with the road RV and a parking place referred to as Parking. Figure 5 shows a closer overview of the intersection. There are two lanes leading to the intersection at point 1 and point 2; a separate left turn lane and a combined through and right turn lane. One lane leads to the intersection from Parking and enables driving in all directions. The same conditions applies for road RV.

Figure 5. Overview of intersection C (© Lantmäteriet I2017/00429).

2.4 Intersection D

A traffic dependent signalised three way intersection connects the through road Assar Gabrielssons väg with Gustaf Larsons väg (GL). Figure 6 shows an overview of the intersection design. At point 1 there is a through lane as well as a separate right turn lane. Two separate lanes lead from GL to the intersection, a left and a right turn lane. Point 2 consists of a through lane and a left turn lane.

Figure 6. Overview of intersection D (© Lantmäteriet I2017/00429).


3 InfraWorks 360

InfraWorks is developed by the American corporation Autodesk, Inc. A model created in the software can consist of several data sources and file formats such as raster and vector data (Autodesk Inc., 2017a). A traffic simulation tool was recently added to the software. Once a road network model is created the traffic simulation tool (also known as Traffic analyst panel, TAP can be used to analyse traffic flow and to generate a simulation animation. The tool allows the user to set multiple parameters in order to calibrate the model. It is possible to simulate pedestrians, bicyclists and public transport in InfraWorks. With its cloud capabilities InfraWorks allows the user to share designs and models with other users and computers online. InfraWorks is also compatible with AutoCAD Civil 3D, a software in civil engineering design, which enables an exchange of data between the two programs. This allows the user to first complete a conceptual design in InfraWorks and then finish the detailed design in AutoCAD Civil 3D (Autodesk Inc., 2017b). Buildings, trees and city objects can be added to the 3D-model to create a realistic visualisation.

3.1 Road network setup

A model can be created either manually or by using the Model Builder provided in the software (Autodesk Inc., 2017a). The latter is a tool where the user can specify an area on a map of maximum 200 square kilometres. The Model Builder builds a model out of high-resolution data layers, such as roads, elevation, imagery and buildings for the specified area. The user can choose between different road types according to his or her needs. More about this can be read in Appendix 2 – InfraWorks 360. A created road has a predetermined style chosen by the user. The software provides several road style and the user has the possibility to edit and create own styles (Autodesk Inc., 2017b). The road can consists of a left side, a median and a right side where driving lanes are included in the left and right side. It is possible to change both the horizontal and vertical geometry by adjusting geometry manipulators and elevation points (point of vertical intersections – PVI).

3.2 Non-signalised intersections

An intersection is created by crossing two roads (Autodesk Inc., 2017b). The intersection is automatically generated with lane markings indicating the driving directions allowed for vehicles. By modifying the lane marking the allowed driving directions change. Priority rules in intersections are automatically generated in the modelled road network. Intersections can either be signalised or non-signalised and are possible to change in TAP. There are five different priority rules available to prioritise the traffic flows (Autodesk InfraWorks 360, 2016):

• Free flow - The traffic on the main road has priority and do not need to reduce

their speed when approaching the intersection.

• Yield - The traffic on the main road must cross an opposing stream and must slow

down when approaching the intersection.

• Give way - The approaching traffic must give way, has a Give Way-sign and

therefore slows down accordingly.

• Stop sign - The approaching traffic must stop before crossing the intersection.

• Barred - It is not allowed to make this turn.


The different priority rules are illustrated with different colours in TAP and are shown in Figure 7. Continuous, light blue arrows show the free flow, the light blue, dashed lines shows yield. Give way is shown with blue, dashed arrows and stop with red, dashed arrows. For barred turns there are no arrows and these are therefore not shown in the figure.

Figure 7. Available priority rules for intersections in TAP. From left to right: free flow, yield, give way and stop sign.

3.3 Signalised Intersections

A signalised intersection can be adjusted by a controller in TAP which contains information about the signal control (Autodesk InfraWorks 360, 2016). There is one controller per intersection which means that all signalised movements cannot be controlled by only one controller but it is possible to make the controllers communicate and thereby synchronise. Groups and phases can be adjusted in the controller. A group is a set of turns. All signal heads that display the same signal state at all times belongs to the same group. Here it is possible to set the timing for yellow, red and green time. A phase is a set of signal states for all groups on a controller. The order in which phases come can be changed and the order may contain repeats but all phases must be included at least once. A signalised intersection can also be controlled by an external software. If an external software is used, a phase specification is not needed in TAP (Autodesk InfraWorks 360, 2016).

3.4 Traffic analyst panel

To simulate traffic, a traffic study area must be created which covers the roads that will be analysed (Autodesk Inc., 2017b). The study area can be opened in TAP where more advanced settings can be adjusted, like demand, vehicle types and priority rules in intersections. Some parameters and settings are valid for the whole network while others are only valid for specific parts in the network e.g. specific lanes. For the overall network these are terms, behaviours, vehicles and restrictions. For more info about these see Appendix 2 – InfraWorks 360. On specific lanes there are also other parameters used to control for example lane changing (Autodesk InfraWorks 360, 2016). Hold is the distance from the end of the lane where no more lane changing will occur. Avoidance is possible to turn on and off. If it is on the vehicles scan the area ahead which leads to a more detailed avoidance behaviour but it requires more computing power. Zip can also be turned on and off and if it is on it allows zip-style merging on the lane. It is also possible to increase or decrease the headway on a specific lane by adjusting the headway factor which is multiplied with the headway time set in behaviours. Furthermore, the car following algorithm can be adjusted for specific lanes since one might be applied to highways and another to streets in an urban area. The possible algorithms to choose from are Gipps,


Wiedemann, Fritzsche or a user defined. For more information about these and further traffic simulation theory see Appendix 3 – Simulation theory.

3.5 Vehicle demand

The demand is the number of vehicles that wants to travel and is expressed as number of vehicle trips in the traffic simulation tool in InfraWorks (Autodesk Inc., 2017b). To be able to adjust the demand in TAP there must be demand zones because every trip begin in one origin zone and ends in a destination zone (Autodesk InfraWorks 360, 2016). Demand zones are created where the study area crosses the roads but can also be added within the area. There are three different ways to add demand; directed demand, undirected demand and public transport demand. Directed demand defines a number of trips where both the origin and the destination are known and an origin-destination matrix (OD matrix) is required. The data collection for this is difficult and a full matrix is therefore estimated but it is possible to manually change the results of the created matrix. Because of too many unknown factors, the estimated matrix cannot be known to be correct. Therefore the matrix is usually the largest source of error in the simulation. Undirected demand defines a number of trips from a specific origin but without a specific destination. Turn counts are required when using undirected demand. By default the proportion of the route choice will be equally spread on the different exit options but also an OD matrix can be created based on the undirected demand. The public transport demand lists all the public transport, their departure times and the associated vehicles. If the demand vary over the simulated time, it is possible to create a demand profile (Autodesk InfraWorks 360, 2016). The profile can have any number of intervals but all intervals are of the same length.

3.6 Simulation output

The analysis tool in TAP generates a summary which describes both the completed and incomplete drive distance and time (Autodesk Inc., 2017b). It also shows the number of successfully departed and arrived vehicles as well as unreleased vehicles that could not depart due to congestion. The outputs and their description are presented in Table 1. Table 1. Output parameters obtained by the analysis tool in TAP.

Output parameter Description Unit

Complete drive distance The sum of the distances driven by all vehicles that have arrived to their destination

km

Incomplete drive distance Reported distance driven by vehicles that have not yet arrived to their destination

km

Complete drive time The sum of the time from when the vehicles are created in the model until they arrive

h:m:s

Incomplete drive time Reported time for vehicles that have not yet arrived to their destination

h:m:s

Departures Number of vehicles that have departed from their origin

veh

Arrivals Number of vehicles that have arrived to their destination

veh

Unreleased Number of vehicles that were supposed to departed but did not due to congestion

veh


The intersection analysis gives the delay, maximum queue and the level of service (LOS) which are described for each approaching lane. Table 2 shows the output parameters obtained from the intersection analysis in TAP. LOS is described by a letter from A to F where A equals a low average delay. The definition of LOS can be user defined or based on the American Highway Capacity Manual which is shown in Appendix 4 – Level of service. The delay is a time in seconds and is the sum of the approach delay and the acceleration delay where the approach delay is the difference between the time it takes for a vehicle to cross the intersection compared with the free-flow time. The acceleration delay is the time the vehicle need to accelerate back to the free-flow speed after it has crossed the stop line. Queuing vehicles are travelling at a speed less than the queue threshold speed which is defined as 0.25 times the route speed of the first approaching link. The maximum queue length is based on the queuing vehicles. Table 2. Output parameters obtained by the intersection analysis in TAP.


Delay The average delay for all vehicles in all lanes which is the sum of the approach delay and the acceleration delay

s

Maximum queues The maximum queue length for vehicles travelling in the queue threshold speed

m

A road analysis in TAP counts the number of vehicles that have completed the link, the mean travel time, mean flow, mean speed and the mean density on the link. A summary of the simulation outputs and a description of the road analysis outputs are presented in Table 3. Table 3. Output parameters obtained by the road analysis in TAP.


Vehicles The number of vehicles that have completed the link

veh

Mean travel time The mean travel time on the link h:m:s

Mean flow The mean flow calculated from the count of vehicles during the simulation period

veh/h

Mean speed The mean speed on the link, calculated from the travel time and the link length

km/h

Mean density The mean density on each link veh/m It is possible to run the simulation in InfraWorks instead of in TAP. When running it in InfraWorks the total number of stops as well as information about vehicles can be obtained, e.g. their CO2 and NOx emissions. These results are downloaded as Microsoft Excel files. An animation of the queue lengths is also shown in the InfraWorks model.


4 PTV Vissim

Vissim is developed by the German company Planung Transport Verkehr AG (PTV, 2017). The software is used to analyse and evaluate current and future traffic situations and is also a good tool for visualisation (Fellendorf & Vortisch, 2010). Some of the applications for Vissim are; capacity analysis, comparison of junction designs and traffic control systems (PTV, 2016). The software is behaviour-based and time step oriented. It offers both urban and highway applications and by adding some technical features, Vissim enables simulation of multi-modal flow in one model (Fellendorf & Vortisch, 2010). This include pedestrians, bicyclists and different kind of vehicles like cars, trucks, buses, trams and rails.

4.1 Road network setup

Roads in Vissim are created by links and separate links are connected by connectors which are needed to make a continuous flow between the links and to define turn relations in junctions (PTV, 2016). Together links and connectors create the link network. Figure 8 shows how links and connectors are represented in Vissim, links are blue and connectors violet.

Figure 8. Links, blue lines, are manually connected in Vissim through connectors, violet lines.

To make the simulation as realistic as possible different attributes can be added to both links and connectors, e.g. vehicle routes, priority rules, conflict areas and speed areas (Fellendorf & Vortisch, 2010). There are two different speed areas, desired speed decisions and reduced speed areas. Desired speed decisions are used for permanent change of speed, e.g. by traffic signs that limit the speed, and reduced speed areas are used to temporally reduce the speed in a certain area, e.g. for turning movements. More information about the speed areas is described in Appendix 5 – PTV Vissim.

4.2 Non-signalised intersections

There are three different ways to model right-of-way in non-signalised intersections; priority rules, conflict areas and adding stop signs (PTV, 2016). Conflict areas model conflicts between vehicles on links and connectors. The conflicts that can be modelled are crossing, merging and branching. The areas are shown automatically and are from the beginning passive which do not impact the vehicles. It is possible to activate each area and choose which link that have right of way. Figure 9 show the colours of the different conflict areas. The passive areas are yellow, the major flow which has right of way is green and the minor flow which has to yield is red. If both areas are red it means that the first to reach the conflict area has right of way which is used for branching conflicts.


Figure 9. Priorities in intersections can be changed by editing the conflict areas.

Conflict areas are easy to use and model driver behaviour better than priority rules since the drivers plan how to approach a conflict area. According to PTV (2016), experience is required to model priority rules appropriately and should only be used if conflict areas do not produce desired results. More information about priority rules and stop signs can therefore be seen in Appendix 5 – PTV Vissim.

4.3 Signalised intersections

There are several signal controller add-on modules available for Vissim which enables both fixed time and traffic dependent signals (PTV, 2016). The one used in this thesis is Vissig. The first step to set up a signalised intersection is to create a signal control. A signal control may consist of several signal groups. In an intersection, if two signal heads have an identical signal display they belong to the same signal group. The signal sequence can be changed for each signal group, e.g. red-green or red-amber-green etc., and also the minimum duration of each signal can be edited. Once all signal groups have been defined a signal program is created which gives an overview of how the different signal groups are associated. It is for instance possible to: edit when and how long green times and clearance times should be; edit a second green time; make sure that two crossing signal groups are not green at the same time etc.

4.4 Vehicle demand

In order to simulate traffic flows in Vissim it is necessary to set vehicle volumes for the network. The volumes are entered at links and several inputs can be created. It is possible to have the volumes simulated to either be the exact value or let Vissim select a stochastic volume based on the value entered as to better reflect reality. According to PTV (2016) the volume unit is in vehicles per hour. In order to simulate different groups with similar technical driving characteristics, Vissim provides the user with the possibility to create or use default vehicle types. The provided default vehicle types are; Car, HGV, Bus, Tram, Man, Woman, Bike and the relevant definitions can be seen in Appendix 5 – PTV Vissim. The user can also determine the proportion of different vehicle types in the network by changing the vehicle composition. A route can be applied to a created road network in order to determine certain routing decisions a vehicle makes to get from its start point to its destination. A route can be very short and display a left turn movement at a single junction or it can stretch through multiple links and connectors in the network as to create a certain driving route from one point to another (PTV, 2016). A route can have numerous end points and a static percentage of the vehicle flow entering the route can be set to each point in order to


control the amount of vehicles that travel to the different end points. Routes can be assigned to a specific vehicle class and a vehicle that has started a route must pass the end point of the route before it can take in new routing information.

4.5 Simulation output

Different data can be evaluated in Vissim depending on the network (PTV, 2016). Before running the simulation the wanted data need to be selected and configured. The results are saved as text files but are possible to import into spreadsheet programs such as Microsoft Excel. In Vissim the user define what data is reported, from where in the network and when during the simulation. To define measure points, Data Collection Points are added at a specific position in the road network (PTV, 2016). The points are mainly used to measure the number of vehicles passing the point but they also measure the average speed, average acceleration and the queue delay that occur in a congested state of the road. Vehicle travel time measures is used to measure the average travel time from one origin to a destination defined by the user by a “To section” and a “From section”. To measure queues at specific locations in the network Queue Counters are used. The queue lengths are measured in meters and the outputs are the average queue length, the maximum length and the number of stops a vehicle does. By default the vehicles enters a queue state when the speed is less than 5 km/h and stays in that state until the speed exceeds 10 km/h. However, these values can be modified by the user. The maximum queue length can be as long as the distance to the next upstream queue counter. By using the link segment analysis tool it is possible to obtain results for the specific links. Some of the relevant results that are possible to obtain are presented in Table 4. Table 4. Output parameters obtained by using link segments.

Output parameter Description Unit Density The vehicle density on each link veh/m

Relative delay The total delay/the total travel time for all vehicles in this link segment %

Speed The average speed on each link km/h Volume The volume on each link veh/h

Nodes is another way to evaluate the simulation. Nodes measure different MOEs for an area defined by the user and is used to reduce the complexity of the model since the data collection points do not need to be specified manually (PTV, 2016). However, the nodes should not include more than one intersection. The data that the node collects are presented in Table 5. Also, the nodes report LOS for the intersection. In Vissim the definition of LOS are comparable with the definition in the American Highway Capacity Manual of 2010 and is shown in Appendix 4 – Level of service. Table 5. Output parameters obtained by using nodes evaluation.

Output parameter Description Unit Average queue length An average of all queue lengths on the movement m

Maximum queue length The maximum queue length at any time during the simulation

m

Number of stops The average number of stops per vehicle stops Stopped delay The average standstill time for a vehicle s Delay time Actual travel time - Optimal travel time s


By using Network Performance Vissim report vehicle data for the entire network in one list. The data reported is shown in Table 6. Table 6. Output parameters obtained by using Network Performance evaluation in Vissim.

Output parameter Description Unit Active vehicles Total number of vehicles in the network veh

Arrived vehicles Total number of vehicles that have arrived to their destination and left the network

veh

Speed The average speed in the entire network km/h

Total stops The total number of stops of all vehicles, both active and arrived

stops

Average stops The total number of stops/(Active vehicles + Arrived vehicles)

stops

Travel time The total travel time of all vehicles, both active and arrived

s

Total delay The total delay of all vehicles, both active and arrived s Average delay The total delay/(Active vehicles + Arrived vehicles) s

Total delay stopped The standstill time of all vehicles, both active and arrived

s

Average delay stopped The total delay stopped/(Active vehicles + Arrived vehicles)

s

Distance The total distance driven by all vehicles in, both active and arrived

km

It is also possible to evaluate the environmental impact but it requires vehicle emission data. Vissim provides different methods for this but it was not considered in this thesis.


5 Methodology

The work process when making a traffic simulation study is shown in Figure 10. A data collection is done to collect information about the traffic system and the alternative designs (Bång, et al., 2014). The information needed is network design, traffic volume, routes, priority rules and parameters such as gap distance etc. Traffic measures is needed to be able to calibrate and validate the system. The data is then used when building the base model in a software. This include setting up a road network, intersections, traffic controls and traffic demand. Verification of the base model has to be made to control that the model work as it is supposed to do. When simulating traffic it is important that the traffic flow throughout the network acts in a realistic way which is done by calibrating and validating the model (Bång, et al., 2014). It is an iterative process where the simulation results are compared with real case measures and different parameters (such as safety distances, desired speed etc.) are adjusted to increase the accordance and create reliable outputs. A large number of parameters increases the calibration work very fast and thus it is important for a model to have representative default values on the parameters (Olstam & Tapani, 2004). According to Woody (2006) there are quantitative and qualitative calibration methods where different MOEs are evaluated. Quantitative calibration typically include measurements of travel times, queue lengths and acceleration rates while qualitative is a visual calibration looking at driving behaviour and interaction between vehicles which includes car-following, lane changing and gap acceptance. The processes of these and their algorithms are key components for traffic simulations to be able to replicate driving behaviour and vehicle movements realistically (Elefteriadou, 2014). When the model is validated, an analysis of the results can be done which can be used to analyse the network (Bång, et al., 2014). Typical MOEs used for the analyses are speeds, travel time, stops, delay, density and queue lengths (Fellendorf & Vortisch, 2010).

Figure 10. The different stages in a traffic simulation work process.


5.1 Data collection

In order to simulate the traffic flow on Hisingsleden and Assar Gabrielssons väg data was needed. Norconsult AB provided necessary data collected during earlier executed traffic counts by the sub consultant Trafikia. The data provided was collected during the period 10th -19th of May 2016. A study of the traffic flow on Hisingsleden was done and the flow was measured in points seen in Figure 11. The data provided consists of information about vehicle type, their driving direction as well as their speed. The data showed that the peak hour occurred at 07:30-08:30 in the morning. As seen in Figure 11 no measurements were done at the smaller roads crossing Assar Gabrielssons väg, i.e. intersection B, C and D, and thus no amount of turning vehicles were measured at these intersections. In order to get data about the amount of turning vehicles at these intersections an additional traffic count was made during a field study.

Figure 11. The locations where the traffic count was made 2016 (Trafikia, 2016).

The traffic count was carried out during the span of three consecutive mornings, one morning at each intersection. It was performed during the hour 07:30-08:30 on the following dates:

• Intersection B was counted on Monday the 30th of January 2017,

• Intersection C was counted on Tuesday the 31st of January 2017,

• Intersection D was counted on Wednesday the 1st of February 2017.

Each vehicle's directional choice were noted in charts. No traffic count was done for interchange A since the data was already given by Trafikia. It would have been preferred to count all intersections during the same hour of the same day. However, due to a limited number of participants and a lack of access to equipment such as cameras the traffic count had to be split up over three days. The vehicles were sorted into two categories: personal cars and HGV. Vehicles such as vans, large, medium and small cars were sorted as personal cars while trucks and trailers fell under the category of HGV. Once the data collection was completed calculations were made in order to determine the traffic volume to and from the different zones. The results from the data collection can be found in Appendix 6 – Data collection.


5.2 InfraWorks 360

The first step in working with InfraWorks was to get to know the software interface and different functions based on the available information about the software. The available manual together with tutorial videos provided by the developer were used in an educational purpose. If these did not provide sufficient information to answer questions or resolve problems that arose then material available online and produced by other users were reviewed. If questions or problems still remained they were posted on the InfraWorks forum, a forum created by the developer providing professional help to all users.

5.2.1 Road network set up

In InfraWorks, the model was set up using the Model Builder which imported the elevation, imagery, building and road layers for the area. After inspection of the given layers it was clear that the road network was not connected or designed in a proper way, see Figure 12. Therefore all the imported roads were deleted and a new road network had to be rebuilt manually.

Figure 12. The default road network created using Model Builder was not functional nor representative and had to be remade. The left figure shows intersection C and the right one shows intersection D as created by the Model Builder. A properly connected intersection can be seen in Figure 13.

A road style was created with dimensions of 3.5 m wide lanes and a 3.5 m wide median was added. This was primarily done in order to have a road style with a median wide enough to enable the possibility to create left turn widenings at junctions. As for the road network, Assar Gabrielssons väg was designed together with roads connecting to intersections B, C and D. The roads were modelled according to the background imagery obtained via InfraWorks. During field studies it was observed that the RA and Parking exit had enough space to hold two cars, enabling right turning cars to have their own exit pocket. This was modelled by creating small lane widenings with sufficient space to hold up to two cars and allowing right turns only, see Figure 13. At intersection B it was impossible to create two parallel lanes in the same direction with the left lane merging into the right lane. Thus, the lanes were modelled inverse with the right lane merging into the left which also can be seen in Figure 13.


Figure 13. The final model of intersection B with a lane widening at exit from RA and the right lane merging into the left at road leading from intersection B in East-West direction.

Hisingsleden was modelled with an interchange connecting to Assar Gabrielssons väg. In order to model the interchange a .dwg-file created in Autodesk civil 3D containing the future roadside lines was imported to the software, serving as outlines for the modelled road. This file was provided by Norconsult AB. The roads were drawn inside the outlines but had to be adjusted several times at certain parts in order for the road parts to connect properly with each other. It was particularly hard to connect roads at pointy angles, such as the ramps connecting Assar Gabrielssons väg and the ramps leading to and from the bridge, see right picture in Figure 14. In some cases the modelled road in InfraWorks even had to be adjusted outside the outlines as to make the model work in TAP. Roadside lines shown in TAP did not always cohere with the ones built in InfraWorks which was particularly problematic and noticed at curvy roads, seen in Figure 14. At the Ramp to Hising N (see Appendix 1 – Zones and link segments for zone locations) it was assumed that the error would not impact the results and was therefore remained as in the left picture in Figure 14. The left picture shows intersection B and the right picture shows interchange A.

Figure 14. The modelled road network in InfraWorks (blurry grey roads) and TAP (outlined roads in white) did not always cohere. This created errors when using TAP. It was difficult to connect roads at small angles and improvisations as in the right picture had to be done on the road network.


Using data provided by Norconsult AB, the elevation of the road network could be determined in certain points. This information was mainly used to set up the road elevation at the bridge.

5.2.2 Calibration and validation

Once the model was built in InfraWorks and worked properly in TAP the calibration was managed. Simulations were run iteratively in order to examine if adjustments had a positive impact in the way vehicles were simulated and made their behaviour more similar to the observations made in field. The results from the traffic count as well as the traffic flow data from Trafikia was used to create undirected arrival and departure demand in TAP. An OD-matrix based on the undirected demand was then created. After comparing the resulting OD-matrix with counted and given numbers, changes were done in order to make it cohere better with field observations. The biggest difference was seen in the traffic flow from zone Assar W to zone GL which was corrected from 27 to 120 vehicles (see Appendix 1 – Zones and link segments for zone locations). As for the demand division, i.e. vehicle composition, the shares were approximated after field observations. Also, the vehicle size definition had to be adjusted in order to cohere with the definition in Vissim. Appendix 7 – Input data in InfraWorks and Vissim shows the final OD-matrix, the vehicle composition as well as the vehicle size definitions. In TAP, the 4-way intersections were automatically set as signalised but not the 3-way intersection. This had to be inverted to conform to reality. The priority rules in the non-signalised intersections was set to free flow for the through traffic along Assar Gabrielssons väg as well as for the right turn traffic. The smaller connecting roads were set with yield. When running the simulation it was noticed that the vehicles from the smaller roads were not let through once a queue had built up on Assar Gabrielssons väg and the priority rules were therefore changed for the through traffic on Assar Gabrielssons väg to give way, see Figure 15. When adjusting these priority rules, the through traffic was also tried to be set to yield, but then collisions with the crossing traffic flow occurred. Give way was the only option that made the through traffic give way to the crossing traffic. Even though give way and yield have similar definitions, it was noticed that yield has priority over give way. ). Priority rules were also changed to give way at the off ramps from Hisingsleden and at merging lanes in order to establish a merging behaviour.

Figure 15. The priority rules set in intersection B and C in InfraWorks. From right to left; free flow, give way, yield.

The traffic dependent signalised intersection D was simplified into a time dependent signalised intersection. This was done since it is very complex and time consuming to


model a traffic dependent intersection. Three signal groups were created after field observations, see Figure 16. According to the theory, see section 3.3 Signalised Intersections, it should be possible to put phases in different orders in InfraWorks, e.g. 1, 2, 1, 3, 2. However, this was not possible in practice and each phase could only be used once. This limited the coherence with field observations and a simplified version of the traffic signals had to be used. All groups were set to have a yellow light lasting 3 seconds and a red light lasting 2 seconds before the next green light turns on which varies in the groups accordingly: 40 seconds for group 1 having the largest flow, 10 seconds for group 2 and 15 seconds for group 3. The minimal signal time was set according to Sektion Utformning av vägar och gator (2004).

Figure 16. The different signal groups set in intersection D. From right to left; group 1, 2 and 3.

The link speed was edited manually to correlate with the speed limits on the roads which is 80 km/h on Hisingsleden, 50 km/h on Assar Gabrielssons väg and Gustaf Larsons väg. On the smaller roads leading to the different parking areas, the speed was set between 20-30 km/h. At interchange A there were problems with both lane choice and merging. The vehicles from Bridge to Assar going straight forward did not choose to stay in the lane they were in to travel straight ahead. Instead, they changed to the right lane which can be seen in Figure 17. One possible reason for this is that the light blue stream leading to the left turn lane lacks a straight forward stream. Several tries to add this stream was made but it was not possible, marked with a red arrow in Figure 17.

Figure 17. All vehicles chose to drive to the right instead of straight forward at the dark blue streams. The red arrow shows the lacking stream.

Merging problems were observed at all sections where two lanes merged in to one. Vehicles did not consider each other and thus drove in to one another. Figure 18 shows this problem at two different locations, interchange A and on the road From B to C.


Figure 18. Behaviour problems occurred at all merging lanes, here seen at interchange A and road From B to C.

In order to make the driving behaviour more realistic parameters had to be changed. After each change a simulation was run as to see if and how the change improved the car behaviour. If a parameter did not make a noticeable difference the parameter change was first kept while enabling and changing other parameters as to see if this made any difference. If still no improvement was observed the parameters were set to their default values. The following parameters were tested when trying to calibrate merging lanes:

• Avoidance – It was turned on for the lanes surrounding the merging area.

However, no difference was noticed in the merging area (connector).

• Zip - The tool was tried in order to get vehicles to merge more efficiently. However,

when simulating, it was observed that the parameter had a negative impact

making the vehicles enter each other from behind, creating clusters.

Neither the lane choice problem nor the merging problem were solved. Another main problem occurred at the off-ramp from Hisingsleden to Assar Gabrielssons väg. Many vehicles going to the off-ramp did not change lane until the end of the ramp. This forced the vehicles to stop in the middle lane and the far left lane to be able to change which caused queues as seen in Figure 19 on the next page.


Figure 19. Lacking lane choice led to an unrealistic queue build- up at the off-ramp from Hisingsleden to Assar Gabrielssons väg. This was solved by changing the parameter look links from 4 to 7.

The following parameters were changed in order to calibrate the situation at the off ramps:

• Look links - This parameter solved a main problem. By changing the default value

of 4 to 7 the vehicles made earlier decisions in terms of lanes, solving problems at

the off ramp from Hisingsleden.

• Hold – Defined as a distance from the end of a lane at which no more lane changing

will take place. There was a difference after setting the hold parameter. However,

the improvements were not sufficient for the studied case.

• Driver temperament -These parameters were tested but as already mentioned in

Appendix 2 - InfraWorks 360 they did not make any difference.

• Margin - No difference was noticed when enabling the margin parameter.

This was solved by increasing the look links from 4 to 7. The vehicles did then choose the far right lane from the beginning when they departed from the departure/arrival zone and no further lane chance was needed. It is important to keep in mind that if no improvements or differences were noticed when trying different parameters and settings it does not mean that they do not work, simply that they did not improve the problem at hand when using a visual calibration.


5.2.3 Simulation output

To obtain the simulation output the simulation was run one time in InfraWorks during 30 minutes. The output was generated automatically and no additional settings were needed. The wanted output for this study was limited to the typical MOEs like number of stops, speed, travel time, delay, density and queue lengths. The obtained output was exported as Microsoft Excel files to process the data. The summary of the results included general information about the entire network like the total travel time in the network, the total number of vehicles and the number of stops as well as the average speed in the network. The results from InfraWorks also included specific data for each vehicle such as their origin and destination, their travel time and number of stops. This was used to calculate the average travel time and number of stops for the major flows between the zones listed below.

• Hising S ⇄ Assar W

• Hising S ⇄ GL

• Hising N ⇄ Assar W

• Hising N ⇄ GL

From the road and intersection analysis the density and delay for each link were obtained. The queue lengths were animated in InfraWorks when running the simulation and the maximum queue lengths for the different lanes could be obtained.

5.3 PTV Vissim

As for InfraWorks the first step in working with Vissim was to get to know the software interface and the different functions. The available manual together with examples provided by the developer as well as online tutorial videos by users were used in an educational purpose. When questions and problems arose the main source used for answers was the manual. An online forum created by the developer is available but there was no need to use it since all questions and problems were solved using mainly the manual and in some cases also online video tutorials and research papers by other users. It was also possible to get personal guidance by a Norconsult AB employee, however this help was sparingly used since no equivalent help was available for InfraWorks.

5.3.1 Road network set up

The project plan for the interchange at Hisingsleden was imported as a background image to Vissim. Once the image was resized and positioned according to the given Vissim ground imagery over the area the road network could be built. Hisingsleden and interchange A were primarily built by creating links and connectors according to the imported image. Assar Gabrielssons väg with connecting roads were then built according to the background image available via Vissim. In order to construct a 3-or 4-way intersection connectors had to be manually drawn in each possible travel direction between links. Figure 20 shows a picture of connectors leading to different links in intersection C.


Figure 20. Links are connected to each other by manually setting out connectors between them. The figure shows intersection C

The elevation at the bridge area was changed via z-offset according to the project plan. Roads leading to the bridge had a constant incline/decline as to create smooth vertical curves. The z-offset for Hisingsleden, Assar Gabrielssons väg and the rest of the model had a constant value of 0.

5.3.2 Calibration and validation

Two vehicle demands were set for each zone; one for cars and one for HGV according to the data collection. The demand gave the departed volume of traffic at each zone. By using routes it was possible to determine the arriving traffic to each zone. Two routes were manually set at each intersection and bifurcation, one for cars and one for HGV. After the demand was set traffic control functions were added. Reduced speed areas were added at curved parts such as ramps as well as at turns in intersections. Different reduced speed values were set for cars and HGV vehicles and can be seen in Table 7. The values for left and right turning movements at intersections were based on examples provided by Vissim and values set at other parts in the model were recommended by Norconsult AB. Table 7. The settings for the different reduced speed areas in the model.

Reduced speed area Speed, cars [km/h] Speed, HGV [km/h] Ramps 40 30 Left turn 25 20 Right turn 15 12

Conflict areas at merging lanes and intersections were edited. Examples provided by Vissim were checked in order to set the conflict area priorities correctly. The settings in


intersection B and C are shown in Figure 21. A couple of iterations were run in order to check the behaviour. After the conflict areas were set, the vehicles behaved in a sufficiently realistic way that no priority rules or stop signs had to be added.

Figure 21. The settings for conflict areas in intersection B and C.

Furthermore, a signal control was created for the traffic lights at intersection D. Three signal groups were added and a signal program complying with the one in InfraWorks was created. The signal set up in Vissim is shown in Figure 22 and a more detailed description of the controllers and the duration time of each signal are presented in section 5.2.2 Calibration and validation.

Figure 22. The three signal groups in intersection D and their timing in Vissim.

Unrealistic behaviour was noticed at the off ramps just like in InfraWorks. Instead of keeping to the far right in order to exit the highway, some simulated vehicles drove up to the end of the ramp in the highway before taking the exit, a highly unrealistic situation. In order to resolve this problem the setting lane change was changed for the connector which connects Hisingsleden with the off ramps. This value was changed from 200 m to 500 m which is reasonable according to Fellendorf & Vortisch (2010). In order for the vehicles to react to this change, routes leading from Hisingsleden to the ramp had to start at a distance further away than 500 m and were therefore moved accordingly (Woody, 2006). This decreased the queue build up significantly and in order to delete the few


remaining vehicles coming to a standstill on the highway the waiting time before diffusion was changed from default value 60 s to 20 s. The waiting time before diffusion removes a vehicle from the simulation model after a set time if the vehicle is stuck and cannot continue on its route.


The possible simulation output in Vissim is diverse and it had to be adjusted to be comparable with the output from InfraWorks. The simulation was run during 30 minutes

as in InfraWorks. In Vissim the simulation was run 15 times and the average values were used when processing the data. The network performance results gave general results for the entire network which partly could be compared with the summary results in InfraWorks. To get more specific results in Vissim, measures for link segments, travel times and queues were also configured. From the link segment output it was possible to obtain both density and relative delay for all links. Just like in InfraWorks the travel time was measured for the major flows. Queue counters were added in the model at locations that cohered with queue measure points in InfraWorks, see Appendix 7 – Input data in InfraWorks and Vissim. Also the definition of a vehicle in queue state was changed in order to be similar in the software products. In Vissim the definition of the queue state was set to be between 11 km/h and 12.5 km/h. This means that a vehicle enters the queue state when driving at a speed of 11 km/h and stays in that state until the speed exceeds 12.5 km/h. This because the definition of queue state in InfraWorks is 0.25 times the desired speed which was 50 km/h in the major part of the network. Also, the definition of the maximum queue length were changed in order to measure longer queues than the default values. In Table 8. the changed parameters are shown as well as their default values. Table 8. The adjusted parameters for queue counters and the default values.

Parameter Default value Set value Queue state definition 5-10 km/h 11-12.5 km/h Maximum length 500 m 2000 m

5.4 Evaluation method

Different categories were identified as important for evaluating the programs and to be able to answer the research questions.

• Does the learning process differ between the two software products?

• Do the software products produce relevant simulation outputs?

• Is it more efficient, i.e. less time consuming, to build a model in InfraWorks

compared to Vissim?

• Do the software products differ in terms of flexibility and accuracy?

These categories are; Education, Simulation output, Efficiency; Accuracy/Flexibility. Each category has five different criteria that are given a score of 0-1 divided in an interval of 4 where a higher score indicates a better performance. The scores are then added and a final category score is obtained and presented in a value diagram. Table 9 shows the evaluation table used for assessing the programs.


Table 9. Evaluation table used for assessing InfraWorks and Vissim.

Category Criteria InfraWorks Vissim

Education Quality of manual

Quality of user support provided by developer

Educational material provided by developer

Available tutorials, examples, help, reports by others.

Ease of learning Simulation output It is easy to obtain results Relevance of output data Flexibility for specific user requests Presentation possibilities File formats Efficiency Road geometrics Signalised intersections Non-signalised intersections Parameters Demand Accuracy/Flexibility Road geometrics Signalised intersections Non-signalised intersections Parameters Demand

5.4.1 Education

This category aims to assess each software in terms of how easy it is to learn and use as a beginner. It also assesses how educational and thorough the available material is, produced by the developer and also by other users. This is an important aspect since the user has to know what theories lies behind the software in order to correctly assess and analyse output results. Each criteria in this category is explained below:

• Quality of manuals

Evaluation of available manuals provided by the developer. A higher score is

obtained if the manual is detailed and explanatory in terms of both theory and

practice.

• Quality of user support provided by developer

This criteria assesses the free user support provided by the developers, e.g.

online forums where users can ask questions.

• Educational material provided by developers

This criteria focuses on the quality of tutorials and examples made available by

the developers in an educational purpose. A higher score is given if the

tutorials/examples have a clear and educational structure with different levels

of difficulty, i.e. beginner, intermediate and advanced.


• Available tutorials, examples, help, reports by others

A higher score is given if there is a lot of helpful information, tutorials etc.

available and created by other users.

• Ease of Learning

This criteria evaluates how easy it is to learn the program as a beginner. A bigger

score is given if the user interface is intuitive and if it is easy to remember

different functions and tools.


As a user it is important that relevant outputs can be obtained, the criteria in this category therefore aims to assess how diverse the output from Vissim and InfraWorks is. It also assesses how much flexibility the user has in choosing how the output should be defined and what kind of format it has. The category does not consider how the simulation results differ between the software products. This is done in a separate comparison. Criteria for this category are explained below:

• It is easy to obtain results

A higher score is provided if wanted results are obtained efficiently and with

little effort.

• Relevance of output data

A higher score is given if the output data is relevant for traffic analyses and cover

the most typical MOEs.

• Flexibility for specific user requests

A higher score is obtained if the user has a high possibility to choose and define

the output.

• Presentation possibilities

This criteria evaluates the quality and diversity of visualisation. A higher score is

given for flexible 3D use, available animation recording function and for the

possibility to add city objects. This is important for presenting results and model

in a clear and comprehensive way.

• File formats

Refers to the possible file formats in which the results can be obtained. A higher

score is received if the results can be obtained in relevant formats used by casual

users, e.g. .txt, .xlsx etc. The main focus is to see if it is possible to export data to

Microsoft Excel since it is a program that is frequently used on the Swedish

market.

5.4.3 Efficiency

The efficiency category evaluates how easy and fast it is to set up a road network, intersections and to adjust different parameters in order to calibrate the model and solve problems that occurred during the simulation. The following criteria are evaluated in terms of efficiency:

• Road geometrics

• Signalised intersections

• Non-signalised intersections

• Parameters

• Demand


5.4.4 Accuracy/Flexibility

An important aspect of traffic simulation is that the model is accurately constructed. This means that certain conditions defined by the user should be able to be implemented into the model. It is therefore important that the program is flexible to the user’s need. In this category accuracy and flexibility are evaluated together since these two depend on each other. The following criteria are evaluated in terms of accuracy/flexibility:

• Road geometrics



• Parameters

• Demand


6 Results

The results of this study are presented in this chapter: section 6.1 Evaluation results presents the evaluation results and section 6.2 Comparison of simulation results presents the comparison of simulation results.

6.1 Evaluation results

Scores for each criteria are presented in Table 10. and are motivated below. Each criteria can get a score between 0-1 divided into four intervals. Table 10. The individual score for each criteria and program is presented here.

Category Criteria InfraWorks Vissim

Education Quality of manual 0.25 1.00

Quality of user support provided by developer

0.50 0.50

Educational material provided by developers

0.00 0.50

Available tutorials, examples, help, reports by others

0.25 1.00

Ease of learning 0.50 0.75 Simulation output It is easy to obtain results 1.00 0.25 Relevance of output data 1.00 1.00 Flexibility for specific user requests 0.00 1.00 Presentation possibilities 0.50 0.75 File formats 1.00 1.00 Efficiency Road geometrics 0.75 0.25 Signalised intersections 0.75 1.00 Non-signalised intersections 1.00 0.25 Parameters 0.50 0.50 Demand 1.00 0.25 Accuracy/Flexibility Road geometrics 0.50 1.00 Signalised intersections 0.25 1.00 Non-signalised intersections 0.25 1.00 Parameters 0.25 0.75 Demand 0.75 1.00

The total score for each category and program are compiled in a value diagram, see Figure 23, an overview of the evaluated characteristics for each program. Vissim gained higher scores in three of four categories; Accuracy/Flexibility, Education and Simulation outputs while InfraWorks performed better in the Efficiency category.


Figure 23. Total score for each of the four evaluation categories Education, Accuracy/Flexibility, Efficiency and Simulation outputs.

6.1.1 Education

• Quality of manual

Vissim's manual was very clear and detailed with thorough explanations of both

theory and practical execution. InfraWorks’ manual was basic with lacking

explanation of definitions, underlying theory, units and practical execution.

• Quality of user support provided by developer

Both InfraWorks and Vissim provided user service in form of online forums where

users could ask specific questions. The service only needed to be used for

InfraWorks and the received answers were often referring to the manual which

many times was lacking information. Vissim’s manual was sufficiently thorough

to answer questions that appeared during the study. A research of the online

Vissim forum showed that questions posted by other users were answered. Thus,

no great difference was noticed in the support service provided online by the

developers.

• Educational material provided by developers

Video tutorials were available online for InfraWorks. These were many times

made for older versions of the software and thus not always relevant. The

tutorials were on a basic level. For Vissim, model examples for a variety of traffic

situations were available and gave a good base at how to set up network. However

the approach was not very educational and left the user to figure out the practical

set up.

• Available tutorials, examples, help, reports by others

Video tutorials created by other users exist for InfraWorks, however many of

these were made for older versions of the program and were therefore not always

relevant. They mostly explained basic functions and none were about TAP. As for

0

1

2

3

4

5Education

Simulation outputs

Efficiency

Accuracy/Flexibility

Value diagram

Vissim InfraWorks


Vissim, many tutorials and earlier studies have been done and the available

material was both diverse and applicable.

• Ease of Learning

Many questions arose during the learning period of InfraWorks. The questions

concerned functions in TAP and InfraWorks in general and how these cooperated.

Since available and thorough information was lacking it was difficult to find

answers on the questions and thereby difficult to learn. Although there were more

functions to learn in Vissim and more possible choices available in order to set up

a network, the manual and accessible information was sufficient to answer many

questions that occurred. The user interface was logical and easy to understand.


• It is easy to obtain results

The simulation output in InfraWorks were automatically obtained. Vissim

required more knowledge from the user who had to specify what output to obtain

and add them manually in the network which made the process more complex.

• Relevance of output data

The output data produced by both programs covered the most typical MOEs.

• Flexibility for specific user requests

The output in InfraWorks had no flexibility. It was not possible to generate other

results than the automatically generated one and thus it was not possible to adjust

the output to the user’s requirements. Also, it was not possible to limit the results

to a certain area of the network. The flexibility was high in Vissim. The user could

obtain specific results for a link, stretch or area. The user could also modify some

of the output definitions in order for them to better correspond to the user’s

interest.

• Presentation possibilities

InfraWorks had a visually appealing user interface and provided a detailed 3D

environment with terrain elevations and a draped orthophoto. It was possible to

insert 3D objects such as buildings, light posts, trees and other city objects. Vissim

had a 3D-view available and background pictures could be inserted, however

there was no terrain elevation or city objects available which made the

visualisation simple. Animation recording was available in both programs but

when recording in InfraWorks the vehicles were stationary which is a great

disadvantage when using the recordings for presentations.

• File formats

Both software products generated results that could be exported to Microsoft

Excel.

6.1.3 Efficiency

• Road geometrics

Setting up a simple road network in InfraWorks was efficient and intersections

were generated automatically. However, there were some problems creating a

smooth elevation and connections at small angles. As for Vissim it took a longer

time to set up roads and junctions due to the manual approach of connecting links

with each other.



There were no difficulties or differences in time to create a simple fixed time

traffic signal in neither of the two programs. However, a more complex signal

program was difficult to model in InfraWorks since the phase order was limited.


Setting up a non-signalised intersection in Vissim was more time consuming

compared to InfraWorks. Reduced speed areas, conflict areas as well as priority

rules needed to be added while in InfraWorks most of these were automatically

generated.

• Parameters

It was easy to find relevant parameters and information about their function in

InfraWorks. A drawback in InfraWorks was that many parameters had to be

changed manually for each link. No general setting was discovered for functions

such as look links, hold, zip etc. which can be time-consuming if a parameter

should be applied for the whole system. This also applies to a small extent for

Vissim. Due to the large amount and complexity of the parameters available in

Vissim, more research had to be done to find out which parameter was relevant

to solve a problem.

• Demand

In InfraWorks, the total number of arrivals and departures had to be defined for

each zone. Thereafter an OD-matrix was automatically created. This was both easy

and efficient. For Vissim, two departure demands were created for each zone, one

for cars and one for HGV. Routes had to be created for each intersection with the amount of turning vehicles for each direction. The process was time consuming

compared to the process in InfraWorks.

6.1.4 Accuracy and flexibility

• Road geometrics

Vissim provided great flexibility to the user when setting up a road network. No

obstacles were encountered when modelling the network. As for InfraWorks,

setting up an accurate model was difficult and limitations were encountered when

connecting roads at small angles. There were difficulties in making the network

work properly in TAP. Certain road geometries were impossible to create, such

as a left lane merging into a right lane.


Both programs have the possibility to connect to external software programs in

order to make traffic dependent signal controls. However, this study focused on

the possibilities to model time dependent signal controls. In InfraWorks, complex

phase orders did not work even though the manual stated differently. The

possibility to create a more complex signal program was therefore limited. As for

Vissim it was possible to create more complex signal programs with good

flexibility.


InfraWorks’ non-signalised intersections let the user adjust the priority rules for

crossing traffic flows. However, the automatic model layout in InfraWorks limited

the user’s flexibility to modify other intersection properties, such as speed and

stop lines. Vissim let the user set up conditions in non-signalised intersections


with both conflict areas, priority rules and stop signs which enabled greater

flexibility and accuracy in the driving behaviour.

• Parameters

It was possible to set parameters for specific lanes and stretches in InfraWorks.

Many parameters that were tested did not make a visible change in the driving

behaviour. Parameters such as zip even worsened the driving behaviour and

made it more unrealistic. As for parameters in Vissim some were general for the

whole road network while other were specific to certain links and connectors. All

tested parameters gave a visible change according to their definition and function.

But still some problems could not be solved sufficiently to give a realistic and

accurate driving behaviour.

• Demand

For Vissim the demand settings were both flexible and accurate and could be set

exactly as the calculated demand. According to Autodesk Inc. (2017b) it is possible

to set up the demand according to traffic counts if the vehicles origins and

destinations are known. However this requires hard measured field studies. If the

OD-matrixes based on undirected demand is used instead, the demand can be a

big source of error according to Autodesk Inc. (2017b), which also was

experienced during the study.

6.2 Comparison of simulation results

A comparison of the software products’ simulation results was made to analyse correlations and possible differences between them. Due to the limited output flexibility in InfraWorks, output from Vissim had to be adjusted as to make a comparison possible. In this subchapter, the results are presented in charts. More detailed simulation data can be found in Appendix 8 – Simulation result. This chapter also contains names of zones and links. To get a good overview of the location for each zone and link, see Appendix 1 – Zones and link segments.

6.2.1 Network output

The network output include total and average results for the entire network. The network output is shown in Table 11. A correlation factor, also presented in Table 11, was calculated to ensure that the results do not differ too much. This is important since the network output addresses the entire network and a large difference of these results implies that other results may not be comparable. Table 11. Network output in Infraworks and Vissim. A corelation factor between the two results is also presented.

InfraWorks Vissim Vissim/InfraWorks Total distance [km] 1707.27 2041 1.20 Distance driven per vehicle [km] 1.04 1.22 1.18 Average speed [km/h] 35.50 39.26 1.11 Total no. of active vehicles 165 135 0.82 Total no. of arrived vehicles 1481 1538 1.04 Total no. of stops in the system 2542 3909 1.54


6.2.2 Stops

The average number of stops per vehicle were measured for the major flows as seen in Figure 24. It did not differ much between the two software programs on flows starting at zone Assar W or GL. For the flows starting at Hising S and Hising N a larger difference can be seen.

Figure 24. Total number of stops per vehicle for routes between different zones.

6.2.3 Density

The average density per link for Vissim and InfraWorks is shown in Figure 25. The density is often higher in InfraWorks, especially in the area of the interchange and intersection B, i.e. the links: Off-ramp to bridge, from B to C, Ramp to Bridge, Bridge to Assar, from Hising S, from A to B. The results also show some similarities: the density is high at the same places in the network even though the value of the density differs; in both software products the density is lower at the roads leading from Assar Gabrielssons väg to Hisingsleden and higher at the roads leading to Assar Gabrielssons väg.

0,0 1,0 2,0 3,0 4,0 5,0 6,0 7,0

Assar W to Hising S

Assar W to Hising N

GL to Hising S

GL to Hising N

Hising N to GL

Hising N to Assar W

Hising S to Assar W

Hising S to GL

Number of stops

Ori

gin

-De

stin

ati

on

zo

ne

The average number of stops per vehicle

InfraWorks Vissim


Figure 25. Average density at different links in the network.

0 20 40 60 80 100 120 140

from Amazon

from RV

to RV

Bridge from Assar

to Amazon

Ramp to Hising N

Ramp to Assar

to Parking

from RA

to RA

from C to B

Ramp to Hising S

from D to C

from Parking

Off-Ramp to Assar

to Hising S

from Hising N

On-Ramp to Hising S

to GL

to Hising N

On-Ramp to Hising N

from Assar W

to Assar W

from GL

from A to B

from Hising S

Bridge to Assar

Ramp to Bridge

from B to C

Off-Ramp to Bridge

from C to D

Density [veh/m]

Lin

k

Average density

InfraWorks Vissim


6.2.4 Delay

Figure 26 shows the average delay on each link in InfraWorks and is measured in seconds. Figure 27 shows the relative delay for each link in Vissim and is measured as the percentage of the total delay divided by the total travel time for all vehicles in a link segment. Since they do not have the same definition, they are not directly compared. Instead, a general comparison of the chart trends is done to see whether similarities exist or not. The links are sorted in the same order in both charts. Higher delay values are seen to the right part of both charts and most of the lower values appear in the left and middle part of the charts except for the following link segments: from Amazon, from RV, from RA, from Parking.

Figure 26. The average delay on each link in InfraWorks.

Figure 27. The relative delay on each link in Vissim.

0

10

20

30

40

50

60

fro

m A

maz

on

fro

m R

V

fro

m R

A

to R

V

to R

A

to P

ark

ing

on

ram

p t

o H

isin

g S

to H

isin

g N

on

ram

p t

o H

isin

g N

Bri

dge

fro

m A

ssar

fro

m P

ark

ing

off

ram

p t

o A

ssar

fro

m H

isin

g N

to H

isin

g S

fro

m D

to

C

fro

m C

to

B

ram

p t

o H

isin

g S

fro

m H

isin

g S

Bri

dge

to

Ass

ar

fro

m C

to

D

ram

p t

o H

isin

g N

off

ram

p t

o B

rid

ge

fro

m A

to

B

ram

p t

o A

ssar

fro

m B

to

C

fro

m A

ssar

W

ram

p t

o B

rid

ge

fro

m G

L

Av

era

ge

de

lay

[s]

Link segment

Average delay in InfraWorks [s]

0

10

20

30

40

50

60

70

80

fro

m A

maz

on

fro

m R

V

fro

m R

A

to R

V

to R

A

to P

ark

ing

on

ram

p t

o H

isin

g S

to H

isin

g N

on

ram

p t

o H

isin

g N

Bri

dge

fro

m A

ssar

fro

m P

ark

ing

off

ram

p t

o A

ssar

fro

m H

isin

g N

to H

isin

g S

fro

m D

to

C

fro

m C

to

B

ram

p t

o H

isin

g S

fro

m H

isin

g S

Bri

dge

to

Ass

ar

fro

m C

to

D

ram

p t

o H

isin

g N

off

ram

p t

o B

rid

ge

fro

m A

to

B

ram

p t

o A

ssar

fro

m B

to

C

fro

m A

ssar

W

ram

p t

o B

rid

ge

fro

m G

L

Re

lati

ve

de

lay

[%

]

Link segment

Relative delay in Vissim [%]


6.2.5 Travel time

One of the automatic outputs in InfraWorks was the average travel time for vehicles from one origin zone to a destination zone. It was possible to get the same output in Vissim but it had to be set up manually for each OD-zone as to cohere with InfraWorks. Because of this the travel times were just compared for the major flows;

• Hising S ⇄ Assar W

• Hising S ⇄ GL

• Hising N ⇄ Assar W

• Hising N ⇄ GL

The results of the travel times are shown in Figure 28. The travel times are similar for the two software products but are little longer in InfraWorks. The biggest difference in travel time between the two software products occurs for the vehicles going from Hising S to Assar W and GL.

Figure 28. Average travel time per vehicle between different zones.

6.2.6 Queue length

The result for each measured stretch is presented in Figure 29. A similarity between Vissim’s and InfraWorks’ results can be seen in the chart with longer queue lengths at the top of the chart and shorter queue lengths at the bottom of it. The queue lengths are measured per lane. Therefore, some of the link names have additional endings in this chart. These represent whether the queue length has been measured at the right turn lane (abbreviated as _rt), left turn lane (abbreviated as _lt) or through lane at intersections with several lanes.

0 50 100 150 200 250 300

Assar W to Hising S

Assar W to Hising N

GL to Hising S

GL to Hising N

Hising N to GL

Hising N to Assar W

Hising S to Assar W

Hising S to GL

Time [s]

Ori

gin

-De

stin

ati

on

zo

ne

Average travel time per vehicle

InfraWorks Vissim


Figure 29. Maximum queue length at different links.

0 50 100 150 200 250 300 350 400

from C to B_through

from D to C_lt

Off-ramp to Assar

from B to C_lt

From D to C_through

Ramp to Assar

from C to B_lt

from GL_lt

from Hising S

from GL_rt

from Assar W_through

from Assar W_lt

Off-ramp to Bridge_through

Off-ramp to Bridge_rt

from A to B_rt

from A to B_through

from Bridge to Assar

Ramp to Bridge

from C to D_rt

from C to D_through

from B to C_through

Length [m]

Lin

k

Queue length

InfraWorks Vissim


7 Discussion

To be able to evaluate the aim of the thesis, this chapter discuss different aspects of the study. First, the author’s experiences of working in respective program are discussed. Thereafter, the evaluation results are discussed and lastly the comparison of simulation results are discussed as well as uncertainties and assumptions made that could have affected the results. The chapter ends with suggestions of further studies.

7.1 Model set up

The road model used in this study was chosen due to its geometrical diversity. With intersections, an interchange, traffic lights as well as branching and merging lanes it was considered to be suitable for the study. One can argue that a contemporary road would have been a better choice as it would have made it possible to compare the simulation results from each software with reality. However, this would require detailed field studies to acquire several field data such as queue lengths, gap distance, travel time etc. Due to limited time this was not prioritized and a visual calibration of the model was instead made. Since no similar study has been done before the focus was to make a general comparison of the software products. Problems occurred during the building process and calibration of the model in InfraWorks. As mentioned in chapter 5.2 InfraWorks 360 it was sometimes hard to set up a functional road network in InfraWorks that did not have a typical grid system, e.g. if two roads intersected at a pointy angle. Road geometries such as a left lane merging into a right lane were impossible for the authors to create. A possible reason for these limitations in geometry could be the fact that the software is developed in the United States of America where the grid system has been regularly used for road networks. The software developers might therefore have focused on developing an automatic and efficient way to set up this kind of road system and therefore limited the geometrical possibilities according to certain standards. The software origin country may also influence functions and parameters’ default values. Once the model was connected in InfraWorks it many times failed in TAP and several adjustments of the road network had to be made. Many limitations were also discovered when working with TAP in InfraWorks, e.g.: it was difficult to make the simulation continue for more than 30 minutes, a problem the authors could not solve; functions like zip made the driving behavior more unrealistic; it was not possible to mix the phase order for traffic lights which resulted in a simplification of the signal program. The lack of a detailed manual of InfraWorks many times led to confusion and inhibited the learning process. Definitions were unclear and functions were rarely thoroughly explained. For example, it was experienced that certain settings such as merge were only applied to vehicles while on a road link but not where links connect (referred to as connectors), e.g. branching and merging lanes. It was also unclear how the queue length was measured and whether or not connectors were included in the queue length output, see Appendix 7 – Input data in InfraWorks and Vissim. Questions occurred while working with Vissim but answers were usually found in the manual. Problems with calibrating the driving behavior were experienced but no errors of the program’s functions were noticed as it was in InfraWorks. Since Vissim has been on the market for a longer period of time it is plausible that errors have been corrected and that the software is more stable than InfraWorks. With new versions of InfraWorks being released continuously it is evident that the software is still developing. New add on modules or functions have often been released with the updates. For example, traffic


simulations and TAP is a new addition in InfraWorks and has only been available in the latest versions. It is therefore plausible that InfraWorks will develop with time and be equipped with functions providing more flexibility and accuracy in future updates.

7.2 Evaluation

The evaluation table can be used for users that are interested in a specific criteria. By looking at the scores in Table 10 they can choose the software which best suits their need. A general overview of the software products can be seen in the value diagram, Figure 23. Here it can be seen that Vissim gained higher scores in three of four categories. Vissim got a high overall score in the Education category with high scores for well written manuals and available information. It also got a high score for its intuitive user interface. Earlier studies and tutorials made by other users made it possible to find answers to questions that came up. Due to lack of information (such as thorough and detailed tutorials and a detailed manual) about InfraWorks, a trial and error approach was used to learn the software. Even though the approach was time consuming it was possible to learn the program. An interesting thought is that if the same amount of information and approach would have been used during the learning process of Vissim, the Education results might have differed. It is important to mention that the Education evaluation is only based on the learning process for the authors, who had no earlier experience of traffic simulations. The results might therefore differ in another study. The fact that the base model first was built in InfraWorks and then in Vissim can also have affected the learning process and thus the results since it gave an understanding of traffic simulations and model building. When building the base model in Vissim, basic knowledge and experience was already obtained which can have favoured the learning process for Vissim. InfraWorks was more efficient when building and calibrating a relatively simple grid network since road geometries such as intersections were generated automatically. Also, driving behavior such as speed reduction in curves was also automatically implemented making the model calibration more time efficient. However, it was harder to make the roads connect and work in TAP when the network was more complex. Building and calibrating the model in Vissim was less efficient due to less automatic functions and because of more choices when it came to parameter settings etc. This made Vissim more flexible and also more accurate in many cases. Even though InfraWorks was more efficient, Vissim resulted to be more accurate which probably is more important for most users. Also, since Vissim was more flexible, it became more time efficient than InfraWorks when modelling more complex networks. Result from the simulation output category did not differ much but Vissim gained a higher score. This mainly because the flexibility of the simulation output was bigger in Vissim than in InfraWorks. However, it was easier to obtain the output in InfraWorks. It can be more efficient to use InfraWorks if the user has little experience and wants a basic overview of a traffic situation. The presentation possibilities were also included in this evaluation category and Vissim scored higher with a small margin. This was because of the possibility to record the simulation animations. The visualisation of InfraWorks was however more realistic due to terrain, elevation and possibilities to add city objects such as trees and buildings. This makes it more visual appealing which is favourable when presenting the model. However, this is subjective and depends on the purpose of the presentation.


7.3 Simulation results

Differences were noticed in the programs’ simulation results. Since the parameters and functions in the programs did not always have the same definitions it was difficult to set up two identical cases in the programs. Therefore, it was expected that some differences between the results would occur. The main causes for the differences in results are discussed below.

7.3.1 Network output

The total distance driven in the network is higher in Vissim and the difference may be caused by that the lengths of some roads were modelled longer in Vissim than in InfraWorks, resulting in the vehicles driving a longer distance in Vissim. This is an error made during the model set up. In further studies it is recommended that the roads have the same length. This also affects the distance driven per vehicle. The result for the total number of arrived vehicles (4%) and active vehicles (18%) differs a lot. It might be expected for them to have the same percentage difference. However, since the number of active vehicles is relatively small (165 for InfraWorks and 135 for Vissim) a small variation results in a big percentage difference. The number of stops differs a lot and there are 54% more stops occurring in Vissim. This is further discussed in section 6.3.2 Stops where also the total number of stops on specific flows is discussed.

7.3.2 Stops

The resulting total number of stops per vehicle did not differ much between the two software programs on flows starting at zone Assar W or GL. For the flows starting at Hising S and Hising N however the number of stops were greater in Vissim. The volume of vehicles was a lot greater driving from Hising N and Hising S compared to the volume of vehicles driving from Assar W and GL. This resulted in more congestion in the East-West direction compared to the West-East. Therefore more stops can be seen for Hising S and Hising N. The difference between the resulting number of stops for Vissim and InfraWorks at the flows from Hising S and Hising N probably depends on the merging behaviours in InfraWorks. InfraWorks did not simulate the merging behaviour in a very good way with vehicles seldom coming to a standstill but instead merged into each other. This was not a problem in Vissim, where the vehicles considered each other and gave way if necessary which probably lead to a greater number of stops. This is a possible reason for the difference in results but it may not be the only one. Further studies and more information are needed to conclude why this difference occurs.

7.3.3 Density

The density of a link depends on the length of it which impacted the compared results at links with different lengths in InfraWorks and Vissim. This especially affected the smaller roads leading to and from Assar Gabrielssons väg. This can explain the differences at these roads. The density in the programs differs a lot on the links from Hising S to intersection B. Possible reasons for this are the merging and lane choice problems that occurred at right before intersection B which created longer queues in InfraWorks. Another explanation could be that all vehicles going from Hising S to Assar Gabrielssons väg in


InfraWorks drove in the far right lane from the beginning, created a queue build-up and so increased the density.

7.3.4 Delay

Looking at the charts it can be seen that the largest difference occurs at links from RA and from Parking. Vehicles have a longer delay in Vissim than InfraWorks. A plausible explanation is that vehicles along Assar Gabrielssons väg were set to always give way in InfraWorks (thus vehicles from RA and Parking were prioritized) in order to release these vehicles during queue build-up. If give way would not have been set the delay time at these links would have been high in InfraWorks. For Vissim however, it was possible to set up a more complex network, using conflict areas, making the behaviour more realistic and thus not always prioritizing vehicles from the smaller connecting roads. This explanation can also explain the non-existent/very low delay time results from InfraWorks at links: from Amazon; from RV; to RV; to RA; to Parking. With this in mind, a general and correlating trend can be seen with low delays at the first half of the charts and larger delays at the last third. Some exceptions still occur such as the results for link from C to D which has very high delays in Vissim but not in InfraWorks. These exceptions require a more thoroughly study of the relation between the delays in Vissim and InfraWorks to be explained.

7.3.5 Travel time

The average travel time per vehicle between different zones were in most cases similar in InfraWorks and Vissim. The biggest difference can be seen for vehicles going from Hising S to Assar W and GL where the travel time was longer in InfraWorks. A plausible explanation is the settings in InfraWorks causing all vehicles to enter the system in the right lane if travelling from Hising S to Assar Gabrielssons väg. This created a queue along Hisingsleden and thus the travel time increased. Comparing the travel time results with the average speed, see Table 11, and density a correlation can be seen where the average speed is lower and density higher in InfraWorks, resulting in a longer travel time.

7.3.6 Queue length

Looking at stretches leading from Hising S to Assar Gabrielssons väg, in Figure 29 named as: from Hising S; Off-ramp to Bridge_rt; from Bridge to Assar; Ramp to Bridge, it can be seen that InfraWorks gives longer queue length results than Vissim. This can be explained by the parameter settings which made all vehicles drive from Hising S to Assar Gabrielssons väg entering the network in the right lane instead of changing lane by the off-ramp. Since all vehicles are placed in the right lane in InfraWorks no lane-changing occurs at the end of the off-ramp which, by contrast, occurs in Vissim. This can be a reason for the big difference in results for the stretch Off-ramp to Bridge_through. Vissim gave larger queue length results along the stretches on Assar Gabrielssons väg, East-West direction. The difference between the two results for each stretch can depend on the programs different methods when counting queues; Vissim measured queues from one queue counter to another while it is unclear how queues were measured in InfraWorks. Also, as mentioned before, the merging problems occurring before intersection B, at stretch from A to B, in InfraWorks may have impacted the results. Since the vehicles merged into each other in InfraWorks and did not stop, they should cause less queues which cohere with the results. However, this driving behaviour is not realistic and so Vissim might give a more realistic result.


The queues were longer in Vissim at the stretch from B to C_through where merging problems occurred in InfraWorks when the two-lane road merged into one-lane road. This can be a reason the longer queues in Vissim in the same way as for the situation at the stretch from A to B. Also, it was not possible to design that road section identically in both software products. In Vissim the left lane merged into the right lane as in reality but in InfraWorks, the right lane merged into the left lane. This could have impacted the results depending on the number of vehicles driving in each lane. However, this is uncertain and if it does affect the results it may not be significantly. Even though the differences of the queue length results may depend on different factors, the main factor was probably because of the different queue definitions in each software and the way the queues were measured.

7.4 Further studies

This was a general, comparative study of InfraWorks and Vissim. As mentioned before, no earlier similar study was found between the two software products. It is therefore difficult to tell if similar results would have been achieved in a similar study. The evaluation was only based on the experience of the authors. The results are therefore partly subjective and others might grade the evaluation categories differently. This study was limited to the chosen categories and traffic situation partly due to the limited time. The evaluation could have been more detailed with more categories and more traffic situations. The chosen evaluation categories give a reasonable overview and guideline of the software products and their advantages and disadvantages. This study only considered private vehicles. Further studies could be done for other traffic situations with pedestrians, cyclists, public transport and other road network geometrics such as roundabouts. Also, the possibilities to model more complex traffic lights with external software products, could be further studied. A sensitivity analysis could also be done to evaluate what parameters affects the simulation results most in each software. More detailed and in depth studies could also be carried out where specific parameters or MOEs could be studied and compared. It would also be interesting to compare simulation results from the programs with real field measurements to assess the reliability of the results.


8 Conclusions and recommendations

The purpose of this master thesis was to do a general comparison of the two traffic simulation software products PTV Vissim 9 and Autodesk InfraWorks® 360 2017. An evaluation with various categories and a comparison of the traffic simulation results was made. The results indicate that Vissim is superior in the categories Accuracy/Flexibility and Education. Vissim also got a slightly higher score in the category Simulation outputs. Even though InfraWorks obtained a higher score in the Efficiency category, many problems occurred when setting up more complex models which led to it being time consuming. InfraWorks had many automatic settings which facilitated for the user. Even though this may seem efficient it many times limited the user flexibility and the model’s accuracy. The traffic simulation tool in InfraWorks could therefore be a choice for setting up simple road networks, such as a grid system, that may not require a high level of detail or accuracy. It may be a decent tool to use to get a basic and quick overview of traffic flows in different traffic situations. Vissim is a user friendly software with high flexibility. Even though the user interface is easy to understand it is a complex software with a lot of possibilities for the user. It might therefore be more complex to set up a model but the final accuracy is higher and the model can be better customized according to the user’s requests. The available information about Vissim was detailed and diverse which led to problems and questions being solved quickly. Vissim is considered to be a diverse, accurate traffic simulation tool that can be used for both simple and complex traffic situations. Both software products generate typical measures of effectiveness for traffic analyses. The outputs from InfraWorks were easy to obtain but could not be edited according to user requests since they were automatically generated. As for Vissim, there was a greater flexibility in defining the outputs but this requires a greater knowledge and a certain amount of experience from the user. The comparison show that the simulation results differ between the two programs. Many of the large differences most probably depend on the user settings and the different definitions of functions in the programs. Only a general comparison was done in this thesis and in order to draw any further conclusions about the relation between the results, further studied have to be done. Due to Vissims high flexibility and accuracy to user specific requirements, the model can be set up in a way that better resembles reality compared to InfraWorks. Even though InfraWorks gave similar results that often can be sufficiently accurate for the user, the limited flexibility often reduces the time efficiency in setting up a model. Vissim is therefore recommended for traffic analyses by the authors of this thesis. Even though Vissim generally scored higher in this study it is important to keep in mind that the traffic simulation tool in InfraWorks is relatively new and that updates are being released continuously. It is plausible that the software will be further developed and it is therefore possible that the relation between the evaluation results may be different in a similar future study.


References

Autodesk Inc. (2017a) InfraWorks 360 - Overview. [Online] Available at: http://www.autodesk.com/products/infraworks-360/overview [Accessed 15 02 2017]. Autodesk Inc. (2017b). Autodesk Knowledge Network: InfraWorks 360. [Online] Available at: http://help.autodesk.com/view/INFMDR/ENU/ [Accessed 10 02 2017]. Autodesk InfraWorks 360 (2016) Help - Traffic Analyst Panel. Autodesk Inc. Bång, K.-L.et al. (2014) Handbok för kapacitetsanalys med hjälp av simulering. Trafikverket. Chappell, E. (2014) Autodesk InfraWorks and InfraWorks 360 Essentials. Indianapolis, Indiana: John Wiley & Sons, Inc.. Elefteriadou, L. (2014) An Introduction to Traffic Flow Theory. 84 ed. New York: Springer Science+Business Media. Fellendorf, M. & Vortisch, P. (2010) Chapter 2 - Microscopic Traffic Simulator VISSIM. i J. Barceló, Fundamentals of Traffic Simulation. 145 ed. New York, NY: Springer Science+Business Media. Olstam, J. J. & Tapani, A. (2004) Comparison of Car-following models. Linköping: Swedish National Road and Transport Research Institute. PTV (2016) PTV VISSIM 9 User manual. Karlsruhe: Planung Transport Verkehr AG. PTV (2017) Company Profile, PTV Group, [http://www.ptvgroup.com/en/ptv-group/company-profile/] (2017-05-04) Sektion Utformning av vägar och gator (2004) Vägar och gators utformning, VGU. Borlänge: Vägverket (Publication number 2004:80) Trafikia (2016) Norconsult Trafikmätning: 2016-05-10 - 2016-05-19. Trafikia. Trafikverket (2015) Sampers och trafikprognoser - en kort introduktion. Borlänge: Trafikverket. Trafikverket (2016) Vägplan – E6.20 Hisingsleden, Södra delen – Halvors länk. Göteborg: Trafikverket (Project number 108036) Troutbeck, R. J. & Brilon, W. (1992) Unsignalized intersection Theory. In: Traffic Flow Theory: A State of the Art Report - Revised Monograph on Traffic Flow Theory. Federal Highway Administration. Woody, T. (2006) Calibrating freeway simulation models in Vissim, Seattle, WA: University of Washington.


Appendix 1 – Zones and link segments

An overview of the modelled road network is presented in Figure 1. The different origin/destination- zones are marked with numbers and the different junctions with letters.

Figure 1. Overview of the modelled road network. The numbers represents the different origin/destination-zones and letters the different junctions.

The following figures, Figure 2 to Figure 5, show the names of the different link segments modelled in this thesis.


Figure 2. Links and their names for interchange A.


Figure 3. The link names used in the model at intersection B.

Figure 4. The link names used in the model at intersection C.


Figure 5. The link names used in the model at intersection D.


Appendix 2 – InfraWorks 360

InfraWorks provides three different add on modules – Drainage, Bridge and Roadway design (Chappell, 2014). Drainage Design can be used to model culverts and drainage networks. Analyses such as flood simulations, performance of individual drainage structures are available and rainfall content data can be applied to analysis-driven designs. Bridge Design provides the user with tools needed to model and design bridges in InfraWorks. Roadway Design is used for modelling roads and to perform analyses on the created roadway design; Sight distance analysis makes it possible to identify sight failure and accident zones where sight is limited by obstructions, Corridor and Profile optimization helps identify areas to be avoided and to compute construction or earthwork costs and Traffic Simulation tool makes it possible to analyse traffic flow through intersections. This appendix focuses on roadway design and the traffic simulation tool.

Road network setup There are three different types of roads available in the software: Planning roads, Design roads and component roads (Autodesk Inc., 2017b). Planning roads use spline geometry and are the default roads. Planning roads can be added or imported from an external software to a model. These roads are lightweight and do not support analysis features. Planning roads can be converted into design roads which offer more precise control over road geometry, grades and support modelling and analysis features such as profile and corridor optimization, mobility and traffic simulation as well as sight distance analysis. Design roads can be converted into component roads. Component roads use component parts for road building. Just like design roads, component roads offer more control of geometry and grades and offers the same modelling and analysis options as design roads. Further, component roads also support advanced capabilities such as linear road transitions and super elevation. There are different design road types, highway roads, arterial roads, collector roads and local roads. The roads have different design speed which can be seen in Table 1. (Autodesk Inc., 2017b). The design speed determines the criteria for parameters like minimum and maximum radius, spiral length and tangent length. Table 1. The design road types have different design speeds.

Design road type Design speed [km/h] Highway 110 Arterial 80 Collector 45 Local 30

Traffic analyst panel A term is a defined period in time and are used to define a simulation time and to associate time-varying functions to the correct simulation components (Autodesk InfraWorks 360, 2016). It consists of a start time, end time and a day of the week. There is no limit for the amount of terms that can be put into the model. An example of a time-varying function is a lane restriction for "buses only" during a limited time. Behaviour defines a number of parameters that controls decisions made by each person (Autodesk Inc., 2017b). For example, the temperament of the persons can be changed. Aggression, awareness, patience and familiarity are set by values in a range from zero to 100%. However, today these are not used in the algorithms but may be in the future. Under behaviour it is possible to change parameters like minimum gap, headway, reaction time and lane change gap.


The vehicles in the software are divided into different vehicle types; small car, medium car, large car, van, small truck, large truck, cycle and motorbike (Autodesk InfraWorks 360, 2016). The default definitions of each vehicle type are presented below, in Table 2 but can be adjusted according to user preferences. Table 2. The default values for the different vehicle types in InfraWorks.

Vehicle type Length [m] Width [m] Height [m] Mass [kg] Small car 4.00 1.70 1.45 1275 Medium car 4.40 1.80 1.50 1350 Large car 4.80 2.05 1.50 1500 SUV 5.00 2.05 1.90 2000 Van 5.60 2.10 2.20 2200 Truck 9.00 2.30 2.80 7000

Factors like engine and tire friction can also be changed. The engine defines the maximum speed, acceleration and braking rates as well as emissions of CO2, NOX and PM10. The standard engine data comes from the UK Transport Research Laboratory (TRL) but it is possible to define other engines. The tire friction controls the maximum speed in a turn which is calculated from equation below.

𝑉𝑚𝑎𝑥 = √𝑔𝑢𝑅

𝑔 = 9.81 𝑢 = 𝑡𝑖𝑟𝑒 𝑓𝑟𝑖𝑐𝑡𝑖𝑜𝑛 𝑐𝑜𝑒𝑓𝑓𝑖𝑐𝑖𝑒𝑛𝑡 [0.8 𝑏𝑦 𝑑𝑒𝑓𝑎𝑢𝑙𝑡] 𝑟 = 𝑡𝑢𝑟𝑛 𝑟𝑎𝑑𝑖𝑢𝑠 A restriction is a parameter that can be added to a specific surface like a lane (Autodesk InfraWorks 360, 2016). It is used to control the types of vehicles that move on the surface and can be barred, allowed or mandatory. By restrictions it is also possible to add speed controls that are valid for a specific vehicle type or a specific time of the day.


Appendix 3 – Simulation theory

This appendix provides the reader with general information about car following models, lane changing models and gap acceptance models. Car following models A car following model describes and models a driver's interaction with the preceding vehicle (lead vehicle) in the same lane (Olstam & Tapani, 2004). A vehicle is considered free when it travels at its desired speed and is not constrained by a preceding vehicle. A following vehicle is constrained by the lead vehicle and driving at its desired speed would lead to a collision, thus the car following behaviour begins with the driver decelerating in order to avoid a collision. Car-following models usually use several states in order to describe the follower's behaviour. There are several different car-following models used in simulation programs: Vissim uses the Wiedemann model; InfraWorks lets the user choose between Gipps, Wiedemann and Fritzsche’s model. Both Wiedemann and Fritzsche's models are psycho-physical models where it is assumed that the driver changes his behaviour at certain thresholds, see Figure 1. While Gipps is based on the safety-distance logic where the driver is assumed to always keep a safe distance to the lead vehicle.

Figure 1. A psycho-physical model assumes a driver changes behaviour at certain thresholds. The left figure shows the different thresholds of Wiedemann’s model (PTV, 2016). The right one Fritzsche’s model (Olstam & Tapani, 2004).

The Wiedemann car-following model was first presented in 1974 and has since then been enhanced continuously (Olstam & Tapani, 2004). There are five driving states in the Wiedemann model:

1. Free driving – Driver maintains his desired speed.

2. Following – Driver follows the lead vehicle, accelerating and decelerating

unconsciously.

3. Approaching – Driver's speed adapts to lead vehicle's lower speed. Deceleration

occurs until the speed difference is zero, i.e. when the driver reaches his desired

safety distance.

4. Breaking – If the desired safety distance reduces significantly, for example due to

leading vehicle changing speed abruptly, the driver decelerates noticeably.

5. Emergency – High deceleration is applied as to avoid a collision with preceding

vehicle.


The model developed by Fritzsche (1994) also consists of five different driving states:

1. Danger – driver uses maximal deceleration to extend the headway to the lead

vehicle since the distance between the vehicles is perceived as too small.

2. Closing in – Driver decelerates to obtain the speed of the lead vehicle when the

headway equals the safe gap distance.

3. Following 1 – Driver takes no conscious action

4. Following 2 – Driver notice he is closing in on the lead vehicle but takes no action

due to the large space headway.

5. Free driving – Follower accelerates to obtain desired speed. The driver's inability

to maintain constant speed is modelled with a parameter.

Gipps model classifies vehicles as free or constrained by the vehicle in front. (Elefteriadou, 2014) When free, the driver aims to travel at the desired speed. If constrained by a lead vehicle, the driver adjusts the speed to obtain a safe space headway to the preceding vehicle. The safe space headway is defined as a distance large enough to make it possible for the follower to react to any reasonable action made by the lead vehicle without colliding (Olstam & Tapani, 2004). Car-following is complex and more research needs to be done as to replicate car-following behaviour relatively well for diverse cases and conditions (Elefteriadou, 2014). Some of the factors that may affect car-following behaviour are: road design elements such as lane width or grade; vehicle characteristics such as tire friction and braking ability; driver characteristics such as reaction time; environmental conditions and unfavourable weather. Lane changing models Lane change depends on many different parameters since there are different reasons to change lane and different urgencies to do it (Elefteriadou, 2014). Also, the cooperation with other vehicles in the target lane affects the lane changing. Lane changing models are therefore more complex than car following models. The lane-changing process is not based on analytical relationships but on decision-making steps which are shown in Figure 2.

Figure 2. The different steps in a lane-changing process.

In step 1 the driver considers if the lane change is mandatory or optional to gain some advantage. Reasons for an optional lane change depends on the driver which makes the driver’s characteristics and behaviour important for the lane changing process. Different


criteria to trigger lane change may be modelled for different traffic situations and environments. In step 2 the driver choose a target lane. This is more complex for an optional lane change since there are more parameters to consider. Discrete choice is an approach that is commonly used to model this. It is based on utility maximization where the driver choose the lane that will provide best utility. For the driver to be able to make a lane change the gaps between the vehicles on the target lane have to be sufficient. This is evaluated in step 3. The driver tries to find a gap, consider to accept it, reject it or revaluate the lane chance performance. The acceptable gaps depends on gap acceptance models which therefore is a part of step 3. In step 4 the driver adjust its speed to be able to perform the lane change by accelerating or decelerating. Gap acceptance models Gap acceptance models are used to determine the number of drivers that can utilize a gap of particular size and duration (Troutbeck & Brilon, 1992). If a driver wants to make a lane change or arrives in a conflicting stream at a non-signalised intersection, the driver has to evaluate if the size of the gap between him and an approaching vehicle (or between two vehicles in the case of lane changing) is large enough for the driver to make the desired manoeuvre. The minimum gap needed for the driver to take action is known as the critical gap. Its size varies depending on driver characteristics, the action (e.g. lane changing, right turn and left turn movement) and the time a driver has been waiting in order to make the action; the longer the interval, the more likely it is that the driver accepts a smaller gap. It is difficult to measure critical gaps. Most gap acceptance models are based on operations at non-signalised intersections since the driver alone must decide when it is safe to enter the intersection (Troutbeck & Brilon, 1992). The driver also has to respect the priority rules and the interaction between streams. There are several methods to estimate the critical gap (Elefteriadou, 2014). One of the most used is the maximum likelihood estimation which uses the accepted gap size and the maximum rejected gap size for each driver to estimate the likelihood that the critical gap is bounded by those two values.


Appendix 4 – Level of service

Level of Service (LOS) is one possible output in both InfraWorks and Vissim where the definition of LOS can be based on the American Highway Capacity Manual and is shown in Table 1. Table 1. The definition of LOS based on the American Highway Capacity Manual (PTV, 2016).

LOS Non-signalised intersection [vehicle unit/miles/lanes]

Signalised intersection [vehicle unit/miles/lanes]

A <= 10 <= 10 B > 10-15 > 10-20 C > 15-25 > 20-35 D > 25-35 > 35-55 E > 35-50 > 55-80 F > 50 > 80


Appendix 5 – PTV Vissim

This appendix gives more detailed information about some functions in Vissim. Road network set up There are two different kinds of speed areas, desired speed decisions and reduced speed areas, which can be added on links and connectors. Desired speed decisions are used for permanent change of speed e.g. by traffic signs that limit the speed (PTV, 2016). The vehicle will drive at the desired speed as long as it is not hindered by other vehicles or objects. It is not until when the vehicle enters the desired speed decision section that the acceleration or deceleration begin. Reduced speed areas are used to temporally reduce the speed in a certain area e.g. for turning movements (PTV, 2016). Since it is mostly used to reduce the speed in curves, it is mainly added to connectors but can also be added to links. The vehicle starts the deceleration before entering the reduced speed area so that the speed is reduced at the entering point. When leaving the area the vehicle starts to accelerate to reach the desired speed. Non- signalised intersections When vehicles in a minor flow approach a conflict area, they calculate if the gap in the major flow is big enough. If the gap is not sufficient the vehicles will decelerate and if the gap is sufficient the vehicles continue to drive. This is repeated in every time step and therefore the speed of the vehicles may vary. The vehicles in the major flow drive to not collide with the vehicles in the minor flow. If the major flow notice a vehicle from the minor flow in the conflict area, the major flow will decelerate in order to enter the conflict area when the other vehicle has left. Priority rules are used in non-signalised intersections or when vehicles in different links or connectors need to consider each other. A priority rule consists of one red bar and one or several green bars, see Figure 1. The red one is the stop line for the traffic that has to wait. The green ones are called conflicting markers. The vehicles are limited by either the headway or gap time limit. The gap time limit is primarily used for the minor flow vehicles while the headway limitation must be used to decide if a conflicting vehicle has already reached a certain point (PTV, 2016). The type of flow also impact what limitation is used. The gap time is used at a normal flow and the headway is used for slow-moving traffic.

Figure 1. Priority rules in Vissim; stop line, conflict marker, headway and gap time are seen in the figure (PTV, 2016).


Headway is "defined as a segment starting slightly before both movements merge" according to Fellendorf & Vortisch (2010). The time required for a crossing vehicle to reach the conflict marker is the definition for minimum gap time (PTV, 2016). When vehicles from the minor flow approaching the red stop line they check if the major flow vehicles will reach the conflict marker within the minimum gap time. The minor flow stops at the stop line if the major flow is in the headway area or within the gap time zone which is also shown in Figure 1 (Fellendorf & Vortisch, 2010). Stop signs mean that all vehicles have to stop at an intersection whether there are crossing flows or not. Stop signs can be added with priority rules by locate the stop sign at the same position as the stop line. Vehicle demand The time when a vehicle enters a link is determined stochastically with an average time gap between two vehicles based on the hourly vehicle volume. PTV (2016) states that the entry time may have a greater variability in real life scenarios than what is simulated in Vissim. Vehicles entered in links with multiple lanes will be added in the lane in which the vehicle can drive the longest on its desired speed before reaching a network object such as a priority rule, conflict area or a preceding vehicle. The different vehicle classes used in this thesis are cars and HGV. Their size definitions are shown in Table 1. Table 1. Vehicle classes and their size definitions.

Vehicle classes Length [m] Width [m] Cars 3.75–4.76 1.85–2.07 HGV 10.22 2.5


Appendix 6 – Data collection

This appendix includes data used to determine the traffic demand in the system. Data from the traffic count made by Trafikia the 10th-19th of May 2016 as well as data from the traffic count made by authors in February 2017 are presented. In Figure 1, different measure points are marked showing which roads were investigated during the traffic count 2016. The data from this count were used to determine number of vehicles departed and arrived from the zones Hising S and Hising N. Also measure point 5963 and 5964 determined the total number of vehicles entering Assar Gabrielssons väg from Hisingsleden.

Figure 2 on the following page shows the amount of turning vehicles from Hisingsleden at different hours. The data between the time period 07:30-08:30 was used and thus gave the total number of vehicles departing from Hising S and Hising N.

Figure 1. Data collection points for the traffic count made between the 10th-19th of May 2016 (Trafikia, 2016).


Figure 2. Turning movement data at Hisingsleden and Gustaf Larsons väg made by Trafikia 10th-19th of May 2016 (Trafikia, 2016).


The result from the traffic count made 2017 is shown in Table 1 together with the relevant traffic data from 2016. Table 1. Traffic count results for intersection B, C and D are presented as well as the results by Trafikia. C in the grey row represents cars and H represents HGVs.

Date & Intersection Road ← ↑ → Time C H C H C H

2017-01-31 B Assar Gabrielssons väg

7:30-8:30 West-East 22 5 219 16 4 0

By authors East-West 24 0 1084 7 51 5

Amazonvägen to RA 2 0 0 0 0 0

RA to Amazonvägen 2 10 0 0 9 2

2017-01-01 C Assar Gabrielssons väg

7:30-8:30 West-East 5 0 253 25 8 0

By authors East-West 2 0 1020 16 41 0

RV to Parking 3 0 0 0 2 0

Parking to RV 8 2 0 0 1 0

2017-02-02 D Assar Gabrielssons väg

7:30-8.30 West-East 233 6 201 20 - -

By authors East-West - - 789 9 207 32

Gustav Larsons väg 53 1 - - 92 8

2016-05-10 A Hisingsleden

7:30-8:30 North-South - - 477 73 68 8

By Trafikia South-North 1176 41 803 53 - -

Assar to Hisingsleden 32 9 - - 180 14

Table 2 shows the percentage of the amount of turning vehicles at the different junctions.


Table 2. Percentage of turning vehicles at the different junctions. C in the grey row represents cars and H represents HGVs.

Intersection

Road ← ↑ →

C H C H C H B Assar Gabrielssons väg West-East 9 % 24 % 89 % 76 % 2 % 0 % East-West 2 % 0 % 94 % 58 % 4 % 42 % Amazonvägen to RA 100% 0 % 0 % 0 % 0 % 0 % RA to Amazonvägen 18 % 83 % 0 % 0 % 82 % 17 %

C Assar Gabrielssons väg West-East 2 % 0 % 95 % 100 % 3 % 0 % East-West 0 % 0 % 96 % 100 % 4 % 0 % RV to Parking 60 % 0 % 0 % 0 % 40 % 0 % Parking to RV 89 % 100% 0 % 0 % 11 % 0 %

D Assar Gabrielssons väg West-East 54 % 23 % 46 % 77 % - - East-West - - 79 % 22 % 21 % 78 % Gustav Larsons väg 37 % 11 % - - 63 % 89 %

A Hisingsleden N to S North-South - - 88 % 90 % 12 % 10 % South-North 59 % 44 % 41 % 56 % Assar to Hisingsleden 15 % 39 % - - 85 % 61 %

The percentages was used to calculate the amount of turning vehicles in intersection B, C and D. The calculation results are shown in Figure 3 and Figure 4.

Figure 3. The calculated number of cars + HGV in the West-East direction.


Figure 4. The calculated number of cars + HGV in the East-West direction.

Finally, the total number of departures and arrivals from/to each zone are presented in Table 3. Table 3. The number of arrivals and departures to/from each zone.

Zone Departures Arrivals C HGV C HGV

Assar W 434 26 990 15 GL 145 9 472 29 Parking 9 2 52 0 RA 11 12 73 27 Hising N 545 81 837 64 Hising S 1979 94 668 89 Amazon 2 0 30 0 RV 5 0 8 0


Appendix 7 – Input data in InfraWorks and Vissim

This appendix include some of adjusted parameters in InfraWorks and Vissim in order for the settings to cohere with both each other and reality as good as possible. An OD-matrix was created in InfraWorks, based on the undirected demand i.e. the number of departures from each zone. However, some adjustments had to be made for the amount of turning vehicles to cohere better with the traffic count. The adjusted and final OD-matrix is shown in Table 1. Table 1. OD-matrix in InfraWorks with the vehicle demand for 30 minutes.

GL Parking RV Amazon RA Hising S Hising N Assar W GL 1 1 1 2 39 16 17 Parking 1 3 1 1 RV Amazon RA 1 6 3 3 Hising S 186 17 9 9 35 375 405 Hising N 35 4 3 3 7 189 74 Assar W 120 4 2 2 6 79 10

The vehicle size definition in InfraWorks were adjusted in order to cohere with the definition in Vissim. Table 2 shows the final sizes. Also, the vehicle composition was changed in order to cohere with the traffic count. Since only cars and HGV were counted during the traffic count, assumptions about the other vehicle classes were made based on field observations. The composition is shown in Table 3. Table 2. The adjusted values for different vehicle types in InfraWorks.

Vehicle type Length [m] Width [m] Height [m] Mass [kg] Small car 3.75 1.70 1.45 1275 Medium car 4.26 1.80 1.50 1350 Large car 4.26 2.05 1.50 1500 SUV 5.00 2.05 1.90 2000 Van 5.60 2.10 2.20 2200 Truck 10.22 2.30 2.80 7000

Table 3. The vehicle composition used in the model in InfraWorks.

Vehicle type Division [%] Small car 31.1 Medium car 31.1 Large car 31.1 SUV 0 Van 0 Truck 6.7

Queue lengths were measured in both InfraWorks and Vissim. Since the queue counters can be manually located in Vissim but not in InfraWorks, they were located in Vissim to cohere with the counters in InfraWorks as good as possible. Figure 1 shows approximately how the queues were counted in InfraWorks and Figure 2 shows the location of the queue counters in Vissim.


Figure 1. The queues in InfraWorks. The blue and red parts represents where the queues were measured.

Figure 2. The position of the queue counter in Vissim marked in red.


Appendix 8 – Simulation result

In this appendix the data obtained by the simulations in InfraWorks and Vissim are presented: Table 1 shows the maximum queue length [m] for different links; Table 2 shows the average travel time [s] between zones and per vehicle; Table 3 shows the average amount of stops per vehicle between zones; Table 4 shows the average density per link segment; Table 5 shows the delay per link, for InfraWorks the average delay in seconds and for Vissim the relative delay in percent. Table 1.Maximum queue length.

Link InfraWorks [m] Vissim [m]

From C to B_through 0.0 0.0

From D to C_lt 0.0 0.0

Off-ramp to Assar 10.2 0.0

From B to C_lt 22.4 0.0

From D to C_through 44.0 0.0

Ramp to Assar 48.6 0.6

From C to B_lt 0.0 9.8

From GL_lt 36.9 23.5

From Hising S 137 26.9

From GL_rt 15.8 40.8

From Assar W_through 46.5 58.0

From Assar W_lt 54.4 58.3

Off-ramp to Bridge_through 5.8 88.2

Off-ramp to Bridge_rt 189.7 88.8

From A to B_rt 102.5 122.7

From A to B_through 91.3 123.0

From Bridge to Assar 219.3 143.5

Ramp to Bridge 182.6 153.4

From C to D_rt 95.5 167.3

From C to D_through 154.0 170.1

From B to C_through 279.8 363.9 Table 2. Average travel time per vehicle.

Zones InfraWorks [s] Vissim [s]

Assar W to Hising S 93.86 85.27

Assar W to Hising N 111.56 111.23

GL to Hising S 118.84 116.58

GL to Hising N 154.00 129.88

Hising N to GL 186.07 176.55

Hising N to Assar W 185.46 177.57

Hising S to Assar W 275.71 218.77

Hising S to GL 285.19 226.87


Table 3. Average amount of stops.

Zones InfraWorks Vissim

Assar W to Hising S 0.7 0.5

Assar W to Hising N 0.6 0.5

GL to Hising S 1.0 0.9

GL to Hising N 1.0 0.7

Hising N to GL 3.1 4.6

Hising N to Assar W 2.9 5.1

Hising S to Assar W 3.1 6.0

Hising S to GL 3.2 6.1 Table 4. Average Density per link segment.

Link InfraWorks Vissim

From Amazon 0.00 0.05

From RV 0.00 0.06

To RV 0.00 0.36

Bridge from Assar 0.00 0.73

To Amazon 0.00 0.78

Ramp to Hising N 0.00 0.92


To Parking 0.00 1.98

From RA 0.00 3.54

To RA 17.20 3.68

From C to B 0.00 4.27

Ramp to Hising S 0.00 4.40

From D to C 0.00 4.81

From Parking 0.00 4.86

Off-Ramp to Assar 13.8 6.99

To Hising S 0.00 7.20

From Hising N 23.13 7.22

On-Ramp to Hising S 0.00 8.98

To GL 11.90 9.03

to Hising N 9.80 10.20

On-Ramp to Hising N 0.00 10.63

From Assar W 23.20 16.90

To Assar W 40.00 17.01

From GL 3.90 18.62

From A to B 132.65 24.22

From Hising S 96.65 27.27

Bridge to Assar 81.06 38.37


From B to C 113.17 39.22

Off-Ramp to Bridge 113.30 45.27

From C to D 44.47 45.85


Table 5. Average delay for InfraWorks per link and relative delay for Vissim per link.

Link InfraWorks [s] Vissim [%]

From Amazon 0.00 17.16

From RV 0.00 27.21

From RA 0.00 73.40

To RV 0.18 4.50

To RA 0.29 0.59

To Parking 0.30 2.53

On ramp to Hising S 1.73 3.38

To Hising N 2.21 2.12

On ramp to Hising N 2.82 2.68

Bridge from Assar 3.22 1.25

From Parking 3.50 73.74

Off ramp to Assar 4.95 4.31

From Hising N 4.97 0.37

To Hising S 5.25 1.11

From D to C 5.64 6.57

From C to B 5.81 8.52

Ramp to Hising S 7.32 4.64

From Hising S 10.17 8.27

Bridge to Assar 11.60 38.82

From C to D 12.04 71.96

Ramp to Hising N 12.89 1.96

Off ramp to Bridge 16.08 35.63

From A to B 16.43 47.58


from B to C 21.58 50.63

From Assar W 30.20 42.75


From GL 49.92 62.95

evaluation of autodesk infraworks 360 and ptv...

Documents