Evaluation of bus terminals using microscopic …1117116/...LiU-ITN-TEK-A--17/030--SE Evaluation of bus terminals using microscopic traffic simulation Examensarbete utfört i Transportsystem

Department of Science and Technology Institutionen för teknik och naturvetenskap Linköping University Linköpings universitet

gnipökrroN 47 106 nedewS ,gnipökrroN 47 106-ES

LiU-ITN-TEK-A--17/030--SE

Evaluation of bus terminalsusing microscopic traffic

simulationCaroline Askerud

Sara Wall

2017-06-16

LiU-ITN-TEK-A--17/030--SE

Evaluation of bus terminalsusing microscopic traffic

simulationExamensarbete utfört i Transportsystem

vid Tekniska högskolan vidLinköpings universitet

Caroline AskerudSara Wall

Handledare Therese LindbergExaminator Anders Peterson

Norrköping 2017-06-16

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat förickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press seförlagets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

© Caroline Askerud, Sara Wall

Abstract

Traffic simulation is a safe and efficient tool to investigate infrastructural changes as well as trafficconditions. This master thesis aims to analyse a microscopic traffic simulation method for evalua-tion of bus terminal capacity. The evaluation is performed by investigating a case study of the busterminal at Norrkoping travel centre. The analysed method, referred to as terminal logic in thethesis, uses a combination of time based and event based simulation. Through the combination oftime and event, it is possible to capture all movements within the terminal for individual vehicles.The simulation model is built in the software Vissim.

A new travel centre for Norrkoping is under development. Among the reasons for a new travelcentre is the railway project Ostlanken in the eastern part of Sweden. An evaluation of the busterminal is interesting due to a suspicion of overcapacity and the opportunity of redesigning. Toinvestigate both the terminal capacity and the terminal logic, three scenarios were implemented.

• Scenario 1: Current design and frequency

• Scenario 2: Current design with higher frequency

• Scenario 3: Decreased number of bus stops with current frequency

The results from the scenarios confirm the assumption of overcapacity. The capacity was evaluatedbased on several different measures, all indicating a low utilization. Even so, the utilization wasuneven over time and congestion could still occur when several buses departed at the same time.This was also seen when studying the simulation, which showed congestions when several busesdeparted at the same time. The case study established the terminal logic to be useful whenevaluating capacity at bus terminals. It provides a good understanding of how the terminal operatesand captures the movements. However, it was time-consuming to adjust the logic to the studiedterminal. This is a disadvantage when investigating more than one alternative. The thesis resultedin two main conclusions. Firstly, a more optimised planning of the buses at Norrkoping busterminal would probably be achievable and lead to less congestions at the exits. Secondly, theterminal logic is a good method to use when evaluating bus terminals but it is not straight forwardto implement.

Keywords: Microscopic traffic simulation, Vissim, VisVap, Bus terminal, Capacity, time basedsimulation, event based simulation.

i

Sammanfattning

Trafiksimulering ar ett sakert och effektivt verktyg for att undersoka bade infrastrukturforandringarandra trafiksituationer. Syftet med detta examensarbete ar att analysera en mikroskopisk trafik-simuleringsmetod for utvardering av kapaciteten hos bussterminaler. Norrkopings resecentrumanvands som ett praktikfall for att genomfora utredningen. Den analyserade metoden, hanvisadsom terminallogik i examensarbetet, bestar av en kombination av tidsbaserad och handelsebaseradsimulering. Kombinationen av tid och handelse mojliggor att fanga rorelser inom terminalen forindividuella fordon. Simuleringsmodellen ar byggd i simuleringsverktyget Vissim.

Ett nytt resecentrym for Norrkoping ar under utveckling. En av de bakomliggande orsakernatill det nya resecentrumet ar jarnvagsprojektet Ostlanken som ska ga igenom Ostra Sverige. Enutvardering av den nuvarande bussterminalen ar intressant pa grund av att det finns en misstankeatt terminalen har overkapacitet samt att det finns mojlighet att forandra terminelen i och mednya resecentrum. For att undersoka bade kapaciteten hos Norrkopings bussterminal och terminal-logiken formulerades tre olika scenarion.

• Scenario 1: Nuvarande utformning och frekvens

• Scenario 2: Nuvarande utformning men hogre frekvens

• Scenario 3: Minskat antal hallplatser men nuvarande frekvens

Resultaten fran scenariona bekraftar antaget om overkapacitet vid terminalen. Kapaciteten utvarder-ades baserad pa flera olika matvarden som alla indikerade lag utnyttjandegrad. Utnyttjandegradenvar dock ojamn over tid, vilket ledde till att trangsel kunde uppsta nar flera bussar avgick samtidigtfran terminalen. Detta kunde ocksa ses genom att studera simuleringen som visade att det blevtrangsel nar flera bussar avgick samtidigt. Praktikfallet pavisade att terminallogiken ar anvand-bar for att utvardera kapaciteten hos bussterminaler. Terminallogiken tillhandahaller forstaelsefor hur terminaler fungerar och fangar bussarnas rorelser. Dock var det tidskravande att anpassalogiken till den studerande terminalen. Det ar en nackdel om flera alternativ ska undersokas. Ex-amensarbetet resulterade i tva huvudslutsatser. For det forsta borde det vara mojligt att skapaen mer optimerad planering for bussarna som trafikerar terminalen, vilket ocksa borde leda tillmindre trangsel vid utfarterna. For det andra ar terminallogiken en bra metod att anvanda forutvardering av bussterminaler, men den ar inte helt okomplicerad att implementera.

Keywords: Mikroskopisk trafiksimulering, Vissim, Bussterminal, Kapacitet, tidsbaserad simuler-ing, handelsebaserad simulering.

ii

Acknowledgements

Firstly we would like to thank our supervisor Therese Lindberg and examiner Anders Petersonat Linkoping University for their support and feedback during this thesis. We would also like tothank Sweco Society in Norrkoping for the opportunity to perform this thesis, the employees alsodeserves a thank for being welcoming and helpful during the thesis. A special thank at Sweco is toour supervisor, Johan Ericsson, and technical supervisor, Magnus Fransson, for their guidance andsupport throughout the thesis. Ostgotatrafiken, Weidermans buss och Nobina Sverige AB deservesa special thanks for providing us with data and taking the time to answer our questions about thebus terminal

Additionally we would like to thank PTV for letting us use an academic license of the microscopicsimulation software Vissim, which was necessary in order to perform this thesis.

Norrkoping, June 2017

Caroline Askerud and Sara Wall

iii

Contents

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Purpose and research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Planning and designing bus terminals 3

2.1 Planning guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Requirements for bus terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Designing bus terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4 Design alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4.1 Saw-tooth design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4.2 Drive-through . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4.3 Centre platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4.4 Angle berth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Bus terminal capacity 9

3.1 Capacity definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Determination of the capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.1 Using analytical methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.2 Using simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Microscopic traffic simulation 13

4.1 Time vs. event based simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Behaviour models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.1 Car-following model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.2 Gap-acceptance model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3 Required data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4 The simulation software Vissim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.5 Microsimulation of stops and terminals . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.6 Verification, calibration and validation . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Framework for terminal logic 19

5.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2 Operations in Vissim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2.1 Generating buses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.2 Buses entry the terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.3 Bus stops and layover area . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.4 Buses taking a lap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

v

5.3 Operations in VisVap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.3.1 Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3.2 Serve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3.3 Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3.4 Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.4 Implementation of terminal logic operations in VisVap . . . . . . . . . . . . . . . . 24

6 Case study of Norrkoping bus terminal 29

6.1 The current terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2 Technical details for the implementation . . . . . . . . . . . . . . . . . . . . . . . . 30

6.3 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.3.1 Bus movements within the terminal . . . . . . . . . . . . . . . . . . . . . . 31

6.3.2 Peak hour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.3.3 Field observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.4 Implementation of Norrkoping bus terminal . . . . . . . . . . . . . . . . . . . . . . 35

6.5 Modifications of the general terminal logic . . . . . . . . . . . . . . . . . . . . . . . 36

6.6 Model analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.6.1 Verification and validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.6.2 Scenario 1: Current design and frequency . . . . . . . . . . . . . . . . . . . 39

6.6.3 Scenario 2: Current design with higher frequency . . . . . . . . . . . . . . . 39

6.6.4 Scenario 3: Decreased number of bus stops with current frequency . . . . . 40

6.7 Sources of error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7 Result and analysis 41

7.1 Case study of Norrkoping bus terminal . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.1.1 Scenario 1: Current design and frequency . . . . . . . . . . . . . . . . . . . 41

7.1.2 Scenario 2: Current design with higher frequency . . . . . . . . . . . . . . . 44

7.1.3 Scenario 3: Decreased number of bus stops with current frequency . . . . . 47

7.1.4 Capacity evaluation of the numerical results for the case study . . . . . . . 49

8 Discussion 51

8.1 Evaluation of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8.2 Evaluation of the terminal logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

9 Conclusion and further research 55

9.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

9.2 Further research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

References 57

vi

List of Figures

1 The saw-tooth design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 The drive-through design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 The centre platform design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 The angle berth design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5 Flowchart for simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 Illustration of how VisVap and VisVap are connected, with the different inputs andoutputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7 The queue construction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8 The lap queue construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9 Flowchart of the terminal logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

10 Flowchart for VisVap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

11 The different windows in VisVap, one for the flowchart and several for inputs andsubroutines (PTV GROUP, 2014). . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

12 Location of Norrkoping bus terminal. . . . . . . . . . . . . . . . . . . . . . . . . . . 29

13 Design of Norrkoping bus terminal. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

14 Number of arrivals and departures for each minute. . . . . . . . . . . . . . . . . . . 32

15 Number of arrivals and departures per 10 minutes intervals. . . . . . . . . . . . . . 33

16 Number of arrivals and departures per hour. . . . . . . . . . . . . . . . . . . . . . . 33

17 The created network of Norrkoping bus terminal in Vissim. . . . . . . . . . . . . . 35

18 The number of occupied bus stops for the current situation, bus stops at the layoverarea is not included. The total number of bus stops is 12. . . . . . . . . . . . . . . 42

19 The number of occupied bus stops at the layover area. The total number of busstops is 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

20 The number of occupied regular bus stops over time with increased frequency. Thetotal number of bus stops is 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

21 The number of occupied bus stops at the layover area with increased frequency. Thetotal number of bus stops is 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

22 The number of occupied bus stops with current frequency but a third of the bus stops. 47

23 The number of occupied bus stops at the layover area with a third of the bus stops. 48

vii

List of Tables

1 The receive function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2 The serve function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 The release function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 The reset function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Data necessary for the simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6 Type of the gathered data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7 Validation of average waiting times at exits. . . . . . . . . . . . . . . . . . . . . . . 39

8 Utilization of bus stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

9 Number of delays within each time interval. . . . . . . . . . . . . . . . . . . . . . . 43

10 Delay at the terminal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

11 Utilization of bus stops with higher frequency . . . . . . . . . . . . . . . . . . . . . 46

12 Number of delays within each time interval for the increased frequency. . . . . . . 46

13 Delay at the terminal for the increased frequency. . . . . . . . . . . . . . . . . . . . 46

14 Utilization of bus stops with a third of the bus stops. . . . . . . . . . . . . . . . . . 48

15 Number of delays within each time interval with a third of the bus stops. . . . . . 48

16 Delay at the terminal for the current frequency and a third of the bus stops. . . . . 49

17 A summary of the numerical results for the three scenarios. . . . . . . . . . . . . . 50

viii

Abbreviations

HCM2000 Highway Capacity Manual 2000

ITS Intelligent Transport System

OD-matrix Origin-Destination Matrix

Macro Macroscopic

Meso Mesoscopic

Micro Microscopic

PASSION PArallel Stop SimulatION

PT Public Transport

TRAST TRafik for en Attraktiv STad (Transport for an attractive city)

USA United States of America

VAP Vehicle-Actuated-Programming

ix

Terminology

Bus stop A designated place where buses stop for passengers to board oralight from the bus.

Bus terminal A terminal for buses, often placed within or connected to a travelcentre. The bus terminal consists of several individual bus stops andcan have different designs.

Critical-gap The minimum major-stream headway during which a minor-streetvehicle can make a maneuver.

Dwell time The time a vehicle spends at a scheduled stop without moving.

Interchange Change between different public transport modes.

TransLink A division of the Department of Transport and Main Roads inQueensland, Australia.

Travel centre Railway station or railroad station and a junction for different meansof travel.

x

1 INTRODUCTION

1 Introduction

Travel centres, and consequently also bus terminals, have an important role when developing citiesand infrastructure. The railway has worked as an engine for cities for a long time and the publictransport becomes more and more important. Hence, travel centres and bus terminals needs to bewell-functioning in order to achieve sufficient public transport with the station as a link to the city(Trafikverket, 2013).

1.1 Background

In Sweden, there is an infrastructural project towards a new generation of railways, called Ostlanken(East Link project). Ostlanken will go through the eastern part of Sweden, making several au-thorities and municipalities involved in the project. The authority responsible for Ostlanken isTrafikverket (Swedish Transport Administration). Information about the Ostlanken project canbe found at for example Trafikverket (2014), Ostlanken (n.d.) and Nykopings kommun (n.d.). Oneof the cities Ostlanken will pass through is Norrkoping, which makes the municipality of Norrkopinga part of the project. Trafikverket and Norrkoping municipality have different interests regard-ing the outcome of the project. Trafikverket’s main interest is to achieve a good accessibility forOstlanken through Norrkoping, while the municipality focuses on good connections and urbanenvironments for the city. Ostlanken is expected to result in shorter travel times leading to moretravellers using railways for their trips. The reduced travel time will likely lead to more commutersand work opportunities in cities at reach. Norrkoping municipality has plans to build a new travelcentre associated to the Ostlanken project. Travel centre refers to the whole station area, bothtrains and buses. Information about Ostlanken and the new travel centre in Norrkoping can befound at Next:Norrkoping (n.d.).

The current travel centre consists of three different parts. One part is for trains, another is fortrams and city buses and then there is a separate bus terminal for buses going outside of the city.The bus terminal handles public transport in form of express buses between different towns in theregion and also regional buses to rural areas around Norrkoping. The terminal also handles long-distance traffic to other parts of Sweden. The regional public transport provider Ostgotatrafikenis responsible for all traffic at the terminal except the long-distance traffic. Several private buscompanies use the terminal to provide long-distance traffic.

When planning the new travel centre in Norrkoping, there is an opportunity to change the designof the bus terminal. The capacity of the existing bus terminal is unknown, but overcapacity issuspected. Since the travel centre is located near the city centre, it is placed on valuable land. Forcity planners, it can be interesting to use this land for properties, parks or other urban purposes.The possible traffic increase is another reason to aim for a space-efficient terminal. The urbanenvironment in combination with increased demand restricts the possibilities for expanding theterminal in order to fulfil the demand. Therefore, it is of high importance to have a space-efficientbus terminal. In order to decide whether a change of the terminal is desirable, the current terminaland its capacity needs to be evaluated.

To enable an evaluation of the bus terminal, capacity, which is a measure of the utilization, is ofhigh importance and needs to be properly defined. This can be done in several different ways andthus needs to be investigated. This will require a good understanding of terminal functionalities.Microscopic traffic simulation is a tool that can be used to evaluate bus terminals and evaluatecapacity. It provides a high level of detail and can capture details and movements of individualvehicles at bus terminals. Sweco, a Swedish consultant firm, has performed several evaluationsof bus terminals using the microscopic traffic simulation tool Vissim. In excess of being usedby Sweco, Vissim has an additional program called VisVap that can be used to manage vehiclemovements within terminals. These two factors make Vissim an appropriate tool to use to evaluatebus terminals and have been chosen for this thesis.

1

1.2 Purpose and research questions

1.2 Purpose and research questions

Bus terminals can be simulated and evaluated in different microscopic simulation softwares. Swecohas performed evaluations of bus terminals in Vissim in the past. The method that Sweco has usedcan be adjusted depending on the design of the terminal that is being investigated. Therefore, it isinteresting to investigate their general terminal logic and how it can be adjusted to the current busterminal in Norrkoping. When adjusted to Norrkoping bus terminal, the terminal logic is analysedbased on its possibilities to enable capacity evaluations of bus terminals.

The purpose of this thesis is to investigate how the microscopic traffic simulation tool Vissim canbe used to evaluate bus terminals and furthermore, to investigate how the method used by Swecocan be adjusted to Norrkoping bus terminal and thereby also evaluate the capacity.

The contribution of this master thesis is to analyse and investigate a method for using micro sim-ulation to evaluate the capacity of bus terminals regarding utilization and delay. More specificallythe contribution will be an evaluation of using the software Vissim in combination with VisVap toachieve both time and event based simulation. Additionally, this thesis will investigate the termcapacity and how the capacity can be determined for bus terminals.

The following research questions has been formulated to answer the purpose.

• How can Vissim in combination with VisVap, terminal logic, be used to evaluate bus terminalswith respect to capacity?

– How can the model be implemented and verified?

• Which estimations are possible to make about the capacity at Norrkoping bus terminal?

– Furthermore, are there any improvements to be made regarding space or efficiency?

1.3 Delimitations

The simulations in this thesis focuses on bus traffic within a bus terminal. Thus, no car traffic orpedestrians are included in the simulations. The study area is delimited to only include the busterminal at the travel centre in Norrkoping. The simulations are performed in Vissim and no othermicrosimulation tool is used.

1.4 Outline

This thesis is structured as follows. Chapter 2. Planning and designing bus terminals and 3. Busterminal capacity contains a theoretical framework for the thesis. Chapter 2 is about planning,design and localisation of bus terminals. The chapter covers information about where travel centresshould be located in a city, where bus terminals should be located in relation to the rest of thetravel centre and different layout alternatives for bus terminals. Chapter 3. Bus terminal capacity,is about bus terminal capacity. This chapter contains information about how capacity can bedefined and determined for bus terminals.

Chapter 4. Microscopic traffic simulation and 5. Framework for terminal logic contains a de-scription of the method used in the thesis. The fourth chapter contains information about trafficsimulation with focus on microscopic simulation and Vissim. The fifth chapter describes the ter-minal logic, previously used by Sweco.

The terminal logic is adjusted and used in a case study on Norrkoping bus terminal. The casestudy is presented in Chapter 6. Case study of Norrkoping bus terminal. This chapter also includeschanges and additions to Sweco’s logic.

Chapter 7. Result and analysis presents the results from the case study together with an analysisof the results and the terminal logic. Chapter eight and nine contains discussion and conclusionsfrom the thesis.

2

2 PLANNING AND DESIGNING BUS TERMINALS

2 Planning and designing bus terminals

Planning of bus terminals and travel centres in general, is a complex matter within the publictransport area. The discipline is complex since it requires a combination of aspects from bothtransport engineering and urban planning.

2.1 Planning guidelines

There are authorities and public transport companies from several countries that provides guide-lines and handbooks for planning of bus terminals and travel centres. Mostly Swedish guidelinesare covered in this thesis. A handbook from Australia is mentioned as an example of an externalguideline.

The Australian guideline is the Public Transport Infrastructure Manual by TransLink (2016), whichcontains best practises and design principles for public transport infrastructure in Queensland,Australia. The manual clearly states TransLink’s expectations for both new and upgraded publictransport infrastructure within the TransLink network. Several aspects need to be taken intoconsideration when planning for public transport. One aspect mentioned in the manual is the urbandesign. The infrastructure must work with the existing physical and social context, be sustainable,feel safe etcetera. Another handbook about travel centres and station areas is Stationshandbok,provided by Trafikverket (2013). The aim of this handbook is to create better travel centres inSweden; better designed, more functional and more effective for travellers. The handbook is dividedinto several parts, covering the whole station area. Different guidelines and design principles arepresented for each part of the travel centre. For example, the requirements are not the same forthe platform and for the area inside a station building. The handbook has a specific subsectionabout buses and interchanges between different public transport modes. Fast and safe transfersshould be given priority at travel centres. (Trafikverket, 2013)

Sveriges kommuner och landsting (Swedish Association of Local Authorities and Regions), Trafikver-ket and Boverket (National board of housing, building and planning) has created a handbook calledTRAST (Sveriges kommuner och landsting, 2015). The aim with TRAST is to guide planners intheir work towards creating attractive cities, the main focus is on traffic. Kol-TRAST is a com-plementary handbook to TRAST and is immersed within the area of public transport planning(Sveriges kommuner och landsting, 2012). The handbook has a specific section about bus stopsand transfer points, but the focus is more on bus stops in the route network than on bus terminals.

As mentioned above, there are numerous handbooks for public transport planning available. Un-fortunately, many of them focuses more on travel centres in general than on bus terminals. Whenevaluating bus terminal capacity, it is the bus terminal area that is interesting and not the travelcentre or the station area. Nevertheless, information regarding travel centres and single bus stopsmight be useful for terminal capacity due to limited existence of terminal specific information.

There are a couple of handbooks with terminal focus available. One example of such a handbookis RITERM -09, developed by SL (public transport provider in Stockholm, Sweden) (SL, 2009).RITERM -09 is a set of guidelines with main focus on bus terminals and the handbook bringsup fundamental conditions for bus terminals. For example, conditions for localisation, design andfunction of bus terminals. The handbook also describes how bus terminals should be designedwithin SL’s network. This means that some of the conditions in the guidelines are specific for SL,while other information is universal for bus terminals overall.

3

2.2 Requirements for bus terminals

2.2 Requirements for bus terminals

There are several different factors affecting whether a bus terminal is considered adequate. Thefactors is for example information, design or functionality. According to Sveriges kommuner ochlandsting (2012), bus terminals should have both high traffic safety for travellers and good ac-cessibility for public transport vehicles. Conflicts between different means of transport should beminimized and short driving distances should be the aim within the terminal. It is also desired thatpeople with disabilities are taken into consideration when designing walkways and waiting areaswithin the terminal. Other things to take into consideration are possibilities for service, cleaningand management. It is also important that the terminal can stay effective during for example badweather conditions.

It is important to consider required space, dimensioning and functionality when planning a busterminal. The required space for the terminal can depend on for example the traffic load, theroute network and the purpose of the bus lines using the terminal. These aspects can be difficultto know in advance. Sveriges kommuner och landsting (2012) brings up that terminals can bedimensioned considering articulated buses when designing the bus stops and bogie buses whendetermining the geometry within the terminal. This is a technique to determine the required spacewithout knowing the exact demand and usage in advance. When it comes to the functionality,there are several different parts that is necessary for the terminal to be as effective as possible.Functionalities that always should be present and accommodated are: drop-off, layover time andpick-up. Other functionalities can vary depending on the size of the terminal. (Sveriges kommuneroch landsting, 2012)

2.3 Designing bus terminals

The localisation and design of bus terminals and travel centres in general has an important rolefor the transport system and for the urban development. The localisation of bus terminals andtravel centres can be seen as one, since bus terminals normally are a part of travel centres. Sverigeskommuner och landsting (2015) discuss where within the travel centre to place the bus terminal.The recommended placement depends on which kind of bus traffic that is going to use the busterminal. For local traffic, it is recommended to use kerbside bus stop directly outside the entranceto the station or the platform. Therefore, the local buses do not always belong to the bus terminalbut rather have their own bus stops. The regional traffic can be combined with the local trafficand located at the same place if no layover time is needed. Layover time is the time betweendepartures, when the bus has no passengers aboard but not enough time to drive to a garage. Thistime is often spent at a layover area, which can be located close to the bus terminal. If layover timeis necessary, it might be better to place the bus stops for the regular traffic at a specific terminalwhere a layover area is accessible.

Other factors important for the localisation of bus terminals are available space, required spaceand environmental requirements. RITERM -09 presents four questions that could be asked whenbuilding a new terminal or improving an existing one (SL, 2009).

• Which bus lines should use the terminal?

• Which functionalities are required for the terminal and how large area is necessary (need ofspace)?

• How should the terminal area be disposed in order to meet all requests regarding closeness,safety and connections between areas within the travel centre?

• How can the traffic be managed to minimize conflicts?

The answers to these questions are essential in order to obtain an overview over the bus terminals’flows and functionalities, which gives an indication of the location and design needs for the terminal.The flows through the terminal can be determined by investigating the number of arriving anddeparting bus lines at the terminal. The flow affects the required space in several ways. Sincebus lines have different functionalities, the required space can differ. Turning bus lines often hasa common drop-off location and an individual pick-up location. A throughgoing bus line requires

4


two separate bus stops, one in each direction. Turning bus lines may need a space near the busterminal for layover time between arrivals and departures. (SL, 2009)

As mentioned previously, the terminal with bus stops for regional traffic can be placed togetherwith the bus stops for local traffic at the travel centre. The problem can be to allocate spacefor layover time for the regional buses. Sveriges kommuner och landsting (2015) points out thatbus lines does not necessarily need to have the terminal as end destination and thus no layovertime there. If the terminal is just as any stop along the route, there is no need for space for timeregulation. When the terminal is the end of the line and time regulation is required, more spaceis needed and the terminal cannot be placed right outside the entrance. In Trafikverket (2013),docking is proposed as a suitable solution. Trafikverket (2013) emphasis that the travellers andtheir interchanges should have focus when planning bus terminals and travel centres. Furthermore,the design and placement of the bus stops within the terminal should enable interchanges to bemade with a normal walking pace. This means that the bus stops, and the bus terminal, need tobe located near the main walkways from the train platforms. The location should be near the trainplatforms but without compromising the travellers’ safety. It is not recommended that travellersneed to cross a busy street when changing travel mode. It is also important that the bus stops orthe bus terminal is designed in a way that makes it possible for travellers to change between buseswithout crossing bus traffic in an unsafe way.

2.4 Design alternatives

The bus terminal at a travel centre can be designed in several different ways. The different designtypes vary in how the buses should be located within the terminal area, for example where theyshould have their pick-up and drop-off location. Several summaries of design alternatives exist.One is a diploma thesis written by Natterlund and Thomasson (2011), parts of the thesis is basedon SL (2009). The following text about design alternatives for the buses’ loading area (berth) atbus terminals is based on Sveriges kommuner och landsting (2015), SL (2009), Natterlund andThomasson (2011) and Brinckerhoff (2002).

2.4.1 Saw-tooth design

The loading area is designed so that the kerbside gets the shape of a ”saw-tooth”. The busesare placed with an angle against the street, see Figure 1. Saw-tooth design requires less spacethan placing the buses along the kerbside, but it can still require a lot of space depending onthe number of buses. A benefit with this design is that it is easy for the passengers to see thedestination signs on the buses. Another benefit is that it is possible to park the bus close to thekerbside, which enables comfortable boarding and disembarking for passengers. A disadvantagewith this design is that it can be considered as ugly and not urbane. When using the saw-toothdesign, the buses can leave their place at the terminal without reversing. This is an importantadvantage for pedestrian safety and simplifies for the drivers. The saw-tooth design is often usedin combination with another design, in order to reduce the required space.

Figure 1: The saw-tooth design.

5

2.4 Design alternatives

2.4.2 Drive-through

The loading area of a drive-through design is designed so that the buses can drop-off and pick-uppassengers and then ”drive through” the terminal on its way out. There are two different typesof drive-through designs, a straight one and an angled one. The straight drive-through design isillustrated in Figure 2. The main advantage with the design is that it is space efficient. Overall,there are more disadvantages than advantages with this design. The drive-through design can bedangerous for passengers since they need to cross the buses path on their way to the right busstop. The design can also lead to poor overview over the terminal. Despite all the disadvantages,it can be situations when a drive-through design is the only option due to shortage of space.

Figure 2: The drive-through design.

2.4.3 Centre platform

The loading area is located around a centre platform, where all pick-up and drop-off locations arelocated at the platform, see Figure 3. The traffic around the centre platform should be unidirec-tional and the travellers should be able to reach the platform without crossing the buses’ path.This can be ensured by using different levels for the centre platform and for the surrounding traffic.Then, the travellers can reach the platform by for example a tunnel or a bridge. An advantagewith the centre platform design is that it can be a very safe alternative for travellers, since nocrossing of the roadway is required. The safety perspective assumes that different levels are used.Another advantage is that it is easy to transfer since all the buses are located around the platform.A disadvantage with the design is that it can require a lot of space, depending on the size of thecentre platform. If there is a lack of space at the terminal, the outside of the roadway can be usedfor more bus stops. This solution counteracts the safety benefit with this design since it couldinduce more travellers crossing the roadway.

6


Figure 3: The centre platform design.

2.4.4 Angle berth

The design of the loading area makes the buses park with the front end facing the travellers waitingarea when arriving to the bus stop at the terminal. The angle berth design, docking, is illustratedin Figure 4. A benefit with this design is that the travellers get a clear overview of the terminaland can wait inside for their bus. The design is also very safe, when used right. The buses needto gear out from their berth so it is of high importance that travellers do not cross the roadwaybehind the buses. The angle berth design is most suitable for bus lines having the terminal as theirend destination or have layover time at the terminal. Otherwise, it might not be time well spentto drive in and out of the berth. The design is for this reason not recommended for throughgoinglines.

Figure 4: The angle berth design.

7

3 BUS TERMINAL CAPACITY

3 Bus terminal capacity

Capacity evaluation of bus terminals could easily be presumed as a well-developed research area.The interest and value in the field should not be a problem. Municipalities are eager to providegood public transport, but are often restrictive with usage of urban ground. Nevertheless, theavailable research and studies indicates a lack of knowledge in this problem area. There is muchresearch about capacity for bus stops, but not for bus terminals. No specific recommended methodfor determining and evaluating the capacity for bus terminals seem to exist. There are, in general,two types of models that can be used for traffic analysis: analytical models and simulation models.These two types will be presented in more detail in Chapter 4. Microscopic traffic simulation.Both these types can also be used for bus terminal capacity.

3.1 Capacity definition

A first step when discussing how to determine the capacity of a bus terminal is to decide how todefine and measure capacity. The term capacity is quite vague and can be defined in several differentways. Bus stop and bus terminal capacity (Al-Mudhaffar et al., 2016) is an article that focuseson how the capacity can be defined and determined both for bus stops and for bus terminals.For a single bus stop, the capacity can be defined as the maximum number of buses per berthper hour (buses/h). This definition is from a model presented in HCM2000 (The highway capacitymanual) provided by the Transportation Research Board National Research Council (2000) in USA.HCM2000 presents three definitions of capacity: a general one, a definition for vehicle capacityand a definition for person capacity. Broadly speaking, the general definition is that the capacityof a facility is the maximum rate (per hour) which persons or vehicles can be expected to cross apoint or a section of a roadway during a given time period. The definition for vehicle capacity ismost interesting for this thesis however. Vehicle capacity is defined as:

Vehicle capacity is the maximum number of vehicles that can pass a given point during aspecified period under prevailing roadway, traffic, and control conditions. This assumesthat there is no influence from downstream traffic operation, such as the backing upof traffic into the analysis point. (Transportation Research Board National ResearchCouncil, 2000: page 2-2)

The definition above defines the capacity for a single bus stop (Al-Mudhaffar et al., 2016; Trans-portation Research Board National Research Council, 2000). When evaluating the capacity for busterminals, the capacity of all the stops within the terminal need to be taken into consideration.One researcher that has contributed significantly to the research about bus stop capacity is RodrigoFernandez. The article On the capacity of bus transit systems brings up that capacity need to behandled differently for transit stations or terminals than for isolated bus stops (Fernandez andPlanzer, 2002). The authors argue that the capacity for a terminal can be defined as the numbersof vehicles that can be served, or the number or passengers that can be transferred. Again, thecapacity can be defined either for the vehicles or for the passengers. Al-Mudhaffar et al. (2016)provides a definition for bus terminal capacity with focus on vehicles:

Bus terminal capacity can be defined as the total number of buses that can be servedby the terminal per time unit (e.g. hour) at a given frequency ratio for each bus line.(Al-Mudhaffar et al., 2016: page 1770)

3.2 Determination of the capacity

As mentioned in the beginning of this chapter, no recommended method for determining busterminal capacity seem to exist. Several different methods are discussed in research articles, butthe focus are often more on capacity for single bus stops than on capacity for terminals. Mostly,the methods for determining bus stop capacity or bus terminal capacity are divided into analyticalmethods or simulation methods. This classification will therefore be used throughout this chapter.Analytical models for determining the capacity of bus stops are mentioned in several articles andsimulation, the other method, is also brought up. One article that has some focus on capacity

9


for bus terminals is Al-Mudhaffar et al. (2016). Two different methods for estimation of busterminal capacity are presented. The methods are empirical analysis and simulation of bus terminaloperations. The empirical analysis is performed by calculating the capacity for the individual busstops and then adding those capacities together. Simulation of bus terminals can determine theterminal capacity in form of the highest bus flow that the terminal can handle before breakdown.

3.2.1 Using analytical methods

Fernandez and Planzer (2002) presents a way to determine the terminal capacity analytically. Usingthis method, the capacity can conceptually be expressed as shown in Equation (1). The transfercapacity is expressed in vehicles per time unit (e.g. buses/h), assuming each loading position onlyaccepts one vehicle at a time.

Qterminal =α ·N

t0(1)

where:Qterminal = Transfer capacity of the terminalN = Number of loading positions or berthsα = Availability of the loading positionst0 = Occupancy time of each loading position.

The problem with this method is that the equation only describes the terminal capacity conceptu-ally. Both the availability and the occupancy of the loading position need to be calculated beforethey can be used in the formula. The availability of the loading positions can be expressed asthe share of the time that the loading position is free. This share depends on several conditions,for example how the loading positions are allocated to vehicles and which queuing method that isused for entering and exiting a loading position. The occupancy time of the loading positions canbe expressed as a function of the types of vehicles and passengers. Some types of vehicles requirelonger time to be accommodated and loaded than other vehicle types and passengers paying withcash need more time than passengers with bus passes. (Fernandez and Planzer, 2002)

Fernandez and Planzer (2002) discuss the problems with Equation (1) and comes with anotherway to classify the factors affecting terminal capacity. The different types of factors are presentedbelow.

• Physical

Number and layout of the loading positions, facilities for loading and unloading and type ofvehicles.

• Operational

Arrival of vehicles and passengers and use of loading positions.

• Behavioural

Types of drivers and passengers.

10

3 BUS TERMINAL CAPACITY

After establishing that the analytical method in Equation (1) is not fully satisfying, Fernandez andPlanzer (2002) mention the HCM2000 model for calculating capacity as an option, see Equation(2). The HCM2000 model is also presented both in Adhvaryu (2006) and Al-Mudhaffar et al.(2016). The model is an analytical model adjusted for calculating the capacity of single bus stops.

Qbus stop =3600 ·

( g

C

)

tc +( g

C

)

· td + Za · Cv · td

(2)

where:Qbus stop = Maximum number of buses per bus stop per hour (buses/h)g

C= Effective green time per signal cycle (1.0 for no signal at exit)

tc = Clearance time between successive buses (s)td = Average dwell time (s)Cv = Coefficient of variation of dwell times = standard deviation/mean for tdZa = One tail normal variation corresponding to probability that queues will form behind a busstop

The probability that queues will be formed behind a bus stop can also be called failure rate andis derived using statistics. Za represents the area under one tail of the normal curve beyond theacceptable levels of probability that a queue will form. A table with values for Za can be found inthe Highway Capacity Manual (Transportation Research Board National Research Council, 2000:page 27-12).

As for the model presented in Equation (1), there are several factors not covered in the HCM2000model presented in Equation (2). For example, Equation (2) does not consider the time it mighttake for the bus to enter the terminal or the loading area. This can for example be time due todeceleration or turning movements. Another uncertainty is that the risk of queues behind the bus,Za, is calculated assuming normal distributed probabilities. (Al-Mudhaffar et al., 2016)

A main difference between the capacity calculation presented in Equation (1) and the one presentedin Equation (2) is that the first equation is for bus terminals and the second for bus stops. Theavailable articles in this field contains discussions whether the capacity of a bus terminal can becalculated based on the bus stops within the terminal or not. As mentioned in the beginning ofChapter 3.2. Determination of the capacity, the capacity of a bus terminal can be calculated asthe sum of the capacity for the individual bus stops (Al-Mudhaffar et al., 2016). This approachwould make the HCM2000 model in Equation (2) valid and useful for both bus stop capacity andbus terminal capacity.

Both Al-Mudhaffar et al. (2016) and Adhvaryu (2006) mentions that a summation of the individualcapacities is not always a satisfying way to determine the capacity of the whole terminal. Accordingto Al-Mudhaffar et al. (2016), the terminal capacity can be reduced at higher traffic loads due tofactors such as queueing buses, blocked entrances or passengers moving across the terminal. Whenthis is the case, the terminal capacity can be calculated as the sum of the capacity of the individualbus stops multiplied with a factor. The factor is defined as [1 - a reduction rate], where the reductionrate is based on the elements affecting the terminal capacity. Adhvaryu (2006) mentions two mainreasons why estimation of bus terminal capacity differs from estimation of bus stop capacity. Onereason is that the time needed to manoeuvring the bus within the terminal is not covered inmethods developed for bus stops. Another reason is the delay that can emerge due to jaywalkingpassengers in the terminal area. This delay can be of various length depending on the terminaldesign. Adhvaryu (2006) ends up with two conclusions: either bus stop capacity models need to bemodified in order to be able to handle these two factors or a simulation model for estimating busterminal capacity is a better option. Al-Mudhaffar et al. (2016) suggests that the use of a factorcan be a modification of the existing analytical capacity models.

11


Analytical models are easy to use and are not so time-consuming compared to simulation models.However, analytical models are not preferable when analysing complex traffic situations, for exam-ple intersections with more advanced design (Trafikanalysforum, n.d.). The dynamic and stochasticparts of the traffic system can be captured better with simulation models while analytical modelsare better at making rough estimations of for example ”standard” intersections. According toAllstrom et al. (2008), traffic simulation is better than analytical models when it is desired to takea larger part of the traffic system into consideration. Traffic simulation is also better at vehicleactuated signal controls than analytical models.

3.2.2 Using simulation

Simulation can be a better option than analytical models for complex traffic situations. Since norecommended analytical method for calculating bus terminal capacity seem to exist, simulationmight be a suitable solution. There is not so much research available about using simulationto determine bus terminal capacity. One article that mentions microsimulation models for busterminal capacity is Adhvaryu (2006). Adhvaryu (2006) means that a problem with analyticalmodels can be that the results can vary a lot due to gross values used in the formulas. Analyticalmodels often include constants that can be difficult to estimate. When using simulation, observedindividual values could be used instead of gross values which makes it easier to adapt the model tothe specific context. In the article, the microsimulation model PASSION was used to calculate thebus terminal capacity. The output from the simulation model was used to determine the capacity.The capacity was determined using the bus flow (buses/h), the berth capacity (buses/h) and thesaturation (%). Adhvaryu (2006) does not explain how the simulation output is used in order tocalculate the capacity.

Al-Mudhaffar et al. (2016) also mentions microsimulation as a method to determine bus termi-nal capacity. One reason is that analytical equations, for example Equation (2), does not alwaysconsider variance in arrival times. Not considering arrival distributions can cause capacity overes-timation since utilization over time is not included. Equation (1) considers the occupancy time ofeach loading position, t0, but has other drawbacks compared to simulation.

12

4 MICROSCOPIC TRAFFIC SIMULATION

4 Microscopic traffic simulation

When conducting traffic analysis there are two common models to use, analytical or simulationmodels. Analytical models can consist of queueing theory, optimization theory or differentialequations (Olstam, 2005). Simulation models uses several sub-models for describing traffic states(Olstam and Tapani, 2004). Three classes of simulation models exist, microscopic, mesoscopic andmacroscopic. The classification depends on the level of detail describing the traffic state. With itshigh level of details regarding traffic state, micro (microscopic) simulation provide the possibilityto simulate individual vehicles and how they interact with other vehicles. To be able to describeand simulate individual vehicles micro simulation uses sub-models in the form of behaviour models.

Micro simulation is often carried out on a limited area, for example a signalized intersection (Barceloet al., 2010). Traditionally it has been used for conducting evaluations of capacity, level-of-serviceor different design alternatives. Micro simulation can be used both in urban and rural areas.Besides the traditional area of use, Olstam (2005) brings up ITS (Intelligent Transport Systems)as a new age area at that time. Example of use are Intelligent Speed Adaptation and AdaptiveCruise Control systems.

4.1 Time vs. event based simulation

A simulation model can either be time based or event based. The differences between the twoare how the simulation is triggered to move forward. The time based simulation evolves as thetime progresses while event based simulation are modelled as a series of events. The type used insimulation depends to some extend on the chosen software for the simulation (Robinson, 2014).

For time based simulation, the time is divided into time steps of 0.1-1 second. For each time stepthe model is computed and updated, if there are no changes an unnecessary computation has beendone. The computation is based on the specified behaviour of the model, for each computationthe animation of the simulation model is also updated. After each time step the simulation clockis increased with the time step and the models enter the next time step (Robinson, 2014; Olstam,2005). A flowchart of the time based simulation is presented in Figure 5. Robinson (2014) bringsup the difficulties to determining the time step. There is also possible to determine the time stepbased on how long time the activities in the model require. However, activities require differentamount of time. The duration of each time step is suggested in Olstam (2005), who also says thatmicro simulation normally is time-discrete but that event based exist.

Figure 5: Flowchart for simulation.

13

4.2 Behaviour models

According to Robinson (2014), in event-discrete simulation it is only the events that changes thesystem that are simulated. The time between events are not simulated and therefore the eventshappen directly after each other. An event can both be triggered by other events or by thesimulation clock. For event based simulation different approaches exists for example, three-phaseapproach where events are classified either as conditional events or as bound or booked events.

4.2 Behaviour models

As mentioned before, micro traffic simulation enables simulation of individual behaviour and in-teraction between different traffic users and environments. The behaviour of drivers decides theinteraction between vehicles (Barcelo et al., 2010). For example, car-following, lane-changing andgap-acceptance models are used as behaviour models. These are considered the most importantones, but other models exist as well. Which models that actually are used in the simulation de-pends on its’ purpose. For simulation of bus terminals, car-following and gap-acceptance modelsare the primary used behaviour models. The different classes of behaviour models are used indifferent sub-models in the simulation. All sub-models handle specific tasks and behaviours inthe simulation model (Olstam and Tapani, 2004). The simulation software also matters for whichsub-models and behaviour models that are used.

4.2.1 Car-following model

Car-following models describe a vehicle’s interaction to a preceding vehicle in the same lane.Definition of following a vehicle is if the interaction, together with the desired speed, would leadto a collision (Olstam, 2005). The aim of car-following models is the same for all, describe andcontrol the interaction of a following vehicle. However, several classes of car-following models existwith different ways to control the following vehicle. Even though car-following models have existedsince the 1950s there is still ongoing research in the area according to Olstam and Tapani (2004).The authors also bring up that the perfect car-following model may not exist or have not beendiscovered yet.

4.2.2 Gap-acceptance model

The aim of gap-acceptance models is to determine if the gap is adequate for the driver to fit(Olstam, 2005). In some cases, gap-acceptance models can be seen as a module to lane-changingmodels since it can determine if a lane change is possible. Olstam (2005) brings up the safetyaspect, where gap-acceptance models are used to make sure the lane change can be done safely.Apart from being used in lane-changing models, gap-acceptance models are used when vehiclesneed to yield for a larger traffic stream. The needed gap for a driver can be modelled to beindividual.

According to Archer (2005) micro simulation uses a fixed value for critical-gap, which describesthe minimum gap needed to enter another traffic stream. The critical-gap can either be in timeor distance. The value can for example depend on the speed of the road or if a connecting trafficstream must yield or stop before entering. The critical value can be determined by observation orliterature studies.

14


4.3 Required data

Micro simulation is an individual simulation of movements being dynamic and stochastic (Dowlinget al., 2002). Due to the details in micro simulation, a high level of data is needed in order tocreate a good model. The level of data may also depend on how accurate the model needs to beand what is being simulated. Obviously geometric data and geographic data is needed for buildingthe model. California Department of Transportation in USA (United States of America) offers aguideline of required input data for traffic micro simulation. The required input data are presentedin the list below. (Dowling et al., 2002)

• Geometry (lengths, lanes, curvature)

• Controls (signal timing, signs)

• Existing Demands (turn volumes, OD matrix)

• Calibration Data (performance data: speeds, queues)

• Future Demands (turn volumes, OD matrix)

The geometry data can often be collected from building drawings of the studied area. The demanddata for the current situation are best received from a counting station, manual of automatic. Inthe guideline from California Department of Transportation, a method called license plate survey isstated as the best way to obtain traffic volumes over the selected area. Check-points for all possibleroutes in the area are then established and all passing vehicles license number are registered. Themethod can consume a lot of resources but the traffic volumes will be accurate. For the calibrationdata to be useful, it should be collected at the same time as the traffic count is performed. Thecalibration data can consist of several different measures. The measures can be for example ameasure of capacity or other measures of the system such as speed, travel time, queues and delays.Dowling et al. (2002) points out that a field observation can be useful for the calibration in orderto detect issues that have not been considered. Estimations of future demands and travel patternsare best received from local authorities that handles traffic planning. (Dowling et al., 2002)

4.4 The simulation software Vissim

Vissim is a time-discrete and behaviour based software simulation tool for micro simulation. Thesoftware can be used for both rural and urban areas; it can also handle multimodal transportoperations (PTV GROUP, 2014). It is often used to analyse and optimise traffic flows. (Barceloet al., 2010)

There are two options for how traffic is assigned to the network in Vissim, one is static assignmentand the other one is dynamic assignment (PTV GROUP, 2014). A main difference between them ishow the routes are allocated in the network. In the static assignment, the vehicles follow manuallydefined routes and the drivers has no choice which path to follow from origin to destination. Theuser must create both routes and vehicle inputs to use static assignment in Vissim.

In the user manual for Vissim 7 (PTV GROUP, 2014), it is stated that Vissim is based on a trafficflow model and light signal control. The traffic flow model includes car-following models and alane-change model. There are two car-following models included in Vissim which are developed byWiedemann. In 1974 Wiedemann developed a model suitable to use for models of urban traffic,the model is called Wiedemann ’74. There is also a model for freeway traffic without mergingareas, it is named Wiedemann ’99 (Axelsson and Wilson, 2016; Barcelo et al., 2010). The car-following model uses threshold values to determine when to change the behaviour of the driver.The behaviour can only be changed when such value is reached, the change can for example be thevelocity or distance to the preceding vehicle (Olstam and Tapani, 2004). In Barcelo et al. (2010)it is brought up that Vissim performs a lane selection which determines the desired lane to changeto. Before changing lane, the gap to other vehicles need to be enough. The gap size depends onthe speed of the vehicle wanting to change lane and the speed of the approaching vehicle in thelane to change to. Car-following models and gap-acceptance models were discussed in Chapter 4.2.Behaviour models.

15

4.5 Microsimulation of stops and terminals

Vissim is a time based software, but has an additional program called VisVap that can be used toregulate the light signal controls used in Vissim. By using signal controls, it is possible to createevents in the network, one event at each signal head. Signal controls consists of a traffic-dependentcontrol logic unit, which can be modelled by external programs like VisVap. The control unit candetermine the signalling status for all signals in the next time step, thereafter sending the statusback to the Vissim simulation (PTV GROUP, 2014). The signalling status can be determinedby using detectors in the Vissim network. VisVap uses the programming language VAP (Vehicle-Actuated Programming), where it is possible to let signal controls be vehicle actuated. By placingout detectors before a signal head in Vissim, vehicles at the signal head can be detected andthereafter VisVAP can decide when to change the signal light.

4.5 Microsimulation of stops and terminals

Most of the existing micro traffic simulation models are developed focusing on car traffic (Fernandezet al., 2010). These models, oriented mainly around movements of cars, does not provide sufficientlevel of detail for behaviour between public transport vehicles and the surrounding traffic. Hence,the models have limitations when used to simulate public transport. Most commercial trafficsimulation softwares like Vissim and Aimsun (TSS-Transport Simulation Systems, 2017) providespossibilities to simulate public transport by using for example embedded PT stops and PT lines.Simulation of public transport is not the main focus of these softwares and it often fails to simulatebuses in a realistic way (Kramer, 2013).

Many time based models focuses on car-following models and car traffic. To capture behaviour atthe terminal, event based simulation can contribute (Lindberg et al., 2017). Both Kramer (2013),(Lindberg et al., 2017) and (Adhvaryu, 2006) mentions that bus stop operations happen in paralleland that event based simulation might be a solution. In Fernandez (2010), it is mentioned thatsimulation models developed for bus stops in the car network exists. One example of such modelis PASSION, mentioned above. PASSION was developed with the aim to overcome the drawbackswith models focusing on car traffic. The model considers interactions between buses, passengersand traffic at bus stops.

Vissim is a time based software but can capture parallel operations by using VisVap. A combinationof time based and event based simulation is necessary in this thesis due to the bus movements beingtriggered by time but controlled by previous and future events. By using both Vissim and VisVap,it is possible to make the simulation both time based and event based.

4.6 Verification, calibration and validation

It is almost impossible to make an exact imitation of a real system on a computer. Therefore, thesimulation model needs to be verified, calibrated and validated to make sure that the results areaccurate. Sometimes these parts can be time-consuming and must be done more than once.

According to Olstam (2005), using traffic simulation for traffic analysis can be cost-efficient since itoffers a safe way to experiment with traffic systems, both existing ones and systems that are underdevelopment. The experiments can for example regard design or different system alternatives. Sincesimulation models are imitations of real systems, it is of great importance to check the reliabilityof the model. Rakha et al. (1996) explains the difference between verification, calibration andvalidation. Validation checks that the model output correspond to the real system. Calibrationis the process of adjusting the model until it produces output close enough to the desired values.Verification on the other hand, is not related to the real system. The aim of verifying a model isto ensure that the model logic works as desired and as specified by the user. Barcelo et al. (2010)brings up the simulation time when calibrating and validating simulation models. A simulationruns over a predetermined time and therefore, it is assumed that the model and the modelled systemevolves similar during the simulated time period. This assumption is analysed in the validation;the output of the model is compared to observed values of the real system during the same timeperiod. The validation is carried out on a calibrated model with the purpose of checking the logicand behaviour of the model. Also, to make sure the model imitations are correct. If not, thecalibration needs to be redone. (Barcelo et al., 2010)

16


As mentioned, before a validation can take place the model needs to be calibrated. The aim of thecalibration is to fit the model to the data. In Treiber and Kesting (2013) validation is defined asfollowing:

Validation is the process of determining the reliability of a model, i.e., the degree towhich it is an accurate representation of the real world from the perspective of theintended uses. (Treiber and Kesting, 2013: page 333)

There exists more than one validation technique. The common factors with the techniques are:simulation of a model and its prediction and enable comparison with already available data. It iscommon to split the available data into training data for the calibration and validation data forthe model prediction. To be able to perform a good validation, it is ideal that the two datasetsrepresent identical situations. (Treiber and Kesting, 2013) Since the aim of validation is to compareresults of the simulation with the real system, it is almost impossible if the system does not exist.(Kelton et al., 2015) Bang et al. (2014) also brings up that a validation only is possible if morethan one dataset exists.

According to Rakha et al. (1996), there are two objectives when verifying a traffic model: ensurethat the model logic provides expected outputs and verify that the outputs is consistent for a rangeof typical input values. The verification process can be seen as a five step procedure, where thedifferent steps is performed in sequence. The steps regards choice of input parameters, checkingconsistency of input and output parameters and evaluate the output data and model logic.

17

5 FRAMEWORK FOR TERMINAL LOGIC

5 Framework for terminal logic

In this thesis, a method for evaluating bus terminals using micro simulation has been used. Thismethod is presented in this chapter and is developed and provided by Sweco. The chapter explainshow the terminal logic is applied. Operations for the logic, events, needs to be implemented inboth Vissim and VisVap. The first subchapter presents an introduction to the terminal logic. Thenext two subchapters presents the operations for each program. The last subchapter focuses onimplementation of the terminal logic in VisVap.

5.1 Preliminaries

Applying the terminal logic requires implementation both in Vissim and VisVap. The buses areconsidered passive in the terminal logic and are only sent between different queues in the network.The different queues and operations for the buses’ movements within the terminal are built inVissim. Conditions for sending buses between the queues are checked and performed in VisVap.Hence, a network needs to be built in Vissim that uses the output from VisVap as input. Theoutput file from Vissim is used as input file in the signal controller in Vissim. That is how Vissimand VisVap are connected, see Figure 6. The concept behind the terminal logic is general butneeds to be adjusted to the specific terminal that is being studied, since all terminals are unique.

Figure 6: Illustration of how VisVap and VisVap are connected, with the different inputs andoutputs.

Figure 6 shows the input and output data to both VisVap and Vissim. VisVap contains severalfiles with the extension *.vv, one for each subroutine. Three files are input to Vissim, *.vap, *.puaand *.dll. The *.vap file is created when compiling VisVap, the other two are standard files.

19

5.2 Operations in Vissim

5.2 Operations in Vissim

To apply the terminal logic in Vissim, the desired operations for the terminal need to be built inthe model. Since the Vissim model uses the output from VisVap as input, the model needs toenable this kind of input. In order to use the output as input the operations need to exist in bothprograms. The operations require the same functionalities but need to be implemented differently.

Development of the Vissim model, for the terminal logic, is based on how bus stops can be createdin Vissim besides the embedded function. All the driving spaces, including the bus stops, isrepresented by links. The links represents roadways or traffic lanes. Creating bus stops with linksinstead of the embedded bus stops is possible due to signal control. Using signal heads to forcebuses to stop at links representing bus stops creates the same behaviour as normal bus stops. Thisway, each bus stop represents a queue where a bus is held by a signal head. Detectors are usedboth before and after the signal heads in order to detect when to change signal state and let thebuses leave the queue. All signal heads are set to red in the beginning of the simulation, leading tobuses always stopping when arriving to a queue. Figure 7 illustrates how a queue is constructed.

Figure 7: The queue construction. The two blue squares are detectors. The first line, turquoise,ends routes while the last line, pink, assigns new routes. The middle line, red, is a signal head.

Buses are sent between the queues to represent the movements within the terminal. All the partsof a queue have a purpose for sending and receiving the buses. The first detector is used to detectwhen a bus has stopped. The detection of a vehicle starts checks in VisVap regarding the purposeof the stop and the release time from the stop. When the release time is reached, the signal headturns green and the bus departs. The detector after the signal head is used to detect when the bushas departed and the signal state is reset to red. In the figure, the first line is connected to thebuses’ route and illustrates the end point of the previous route. The last line is a decision pointwhere the bus is assigned to a new route. The queues have routes between them, meaning thatwhen the bus is allocated a new queue it follows a predetermined route to that queue. Thus, mostqueues have two points connected to the routes. First one line where the previous route ends andthen another line where the new routes starts.

Queues are used everywhere in the network where a decision is required (i.e. where the bus’ routecan change). Hence, the buses can be described as packages being sent between the queues. Asmentioned, the buses are considered passive throughout the simulation. Depending on the studiedterminal, different operations are needed to represent the system. Operations used to representthe terminal are presented below.

• Generating buses

• Buses entering the terminal

• Holding buses at bus stops and layover area

• Letting the buses exit the terminal

• Taking a lap within the terminal

Different operations are handled differently in VisVap. Each operation is presented below exceptbuses exiting the terminal. That operation only ensure the buses can leave the terminal.

20


The queues can only handle one bus at the time. When a bus is allocated to a route, the queuein the end of that route becomes reserved for this specific bus. Buses wanting to visit the samequeue, may have to take a lap and wait for the queue to become available. Other options for thebuses are either to wait at the current queue or chose another queue.

5.2.1 Generating buses

The first operation is the generation of buses. The buses are created using the vehicle inputfunction in Vissim but are let in to the terminal by the generator queues. Since these queuesinitializes the model, there are no routes ending at the queues. Therefore, the turquoise line inFigure 7 does not exist for the generator queues. The lack of routes ending before the queues forgeneration is unique for this operation. Vehicles do not get assigned generator queues but visitsthe queues due to vehicle input being located at the opposite end of the links compared to thequeue construction. To ensure that there always are buses available for entering the terminal, abuffer of buses is created and waiting at the generator queues.

Buses entrance from the generator queues into the station area are controlled by signal heads andchecks in VisVap. The signal state is set to green when the release time for the waiting bus isreached. The release time is calculated as the time that the bus should be at the desired location,for example bus stop or layover area, minus the driving time to get there. In the generation, therelease time is either the generation time or the current time if the generation time already haspassed.

The main task for generation queues are to create and let buses in to the system. The buses arelet into the system through change of signal state due to release time. Before the bus enters theterminal, it needs to know its purpose of visiting the terminal and which bus stop to visit, thisinformation is predefined in the input data.

5.2.2 Buses entry the terminal

The buses’ purpose is known since it is predefined, but the buses needs to be made aware of theirpurpose. This is done in the entry operation. The entry needs to be located at the entrance of theterminal area. By locating the entry operations close to the entrance, the reservation of bus stopcan be delayed and performed as late as possible leading to the time bus stops are reserved beingminimized. The delay of the reservation is the time to travel the distance between generation andentrance of the terminal. There is another kind of entry operation called lap entry, which will bepresented further in Chapter 5.2.4. Buses taking a lap.

5.2.3 Bus stops and layover area

As mentioned in Chapter 2. Planning and designing bus terminals, bus terminals and their busstops can be designed in different ways. The queues representing bus stops in the terminal logiccan be constructed differently depending on the type of terminal. If the bus line starts or ends atthe bus stop at the terminal, the bus has several alternatives for proceeding. For example, exitingthe terminal or park at the layover area. Throughgoing buses uses the bus stops at the terminal asany other bus stop along the line. They exit the terminal after visiting the bus stop. Buses havingdifferent purposes for visiting the terminal may require different types of queues for the bus stops.The bus stops for throughgoing bus lines can be modelled as pocket bus stops outside the terminaland be in conjunction with the terminal area.

Queues for bus stops and the layover area are built using the queue construction in Figure 7.Since all driving spaces in the Vissim model are constructed by links, it complicates the creationof the layover area. Due to it being a continuous area in reality and not a fixed number of stops.Therefore, the layover area is modelled as a predetermined number of bus stops based on themaximum number of buses expected to fit at the same time.

Each bus stop is represented by a queue. The bus is held at the queue by a signal as long as thebus is supposed to stay at the bus stop (i.e. until their release time is reached). As mentioned, therelease time is calculated in VisVap. The release time for the bus depends on its next event. Forexample, if the next event is to depart from a bus stop and exit the terminal, the bus must wait

21

5.3 Operations in VisVap

for its departure time according to the timetable. If the next event is to park at the layover area,it might be possible to go there directly. Furthermore, if the bus is parked at the layover area andits next event is to pick-up passengers, the bus should wait at the layover area until the time todeparture is enough for boarding and the bus stop is free.

5.2.4 Buses taking a lap

Taking a lap means that the buses drives a lap within the terminal due to their desired next queue,and all alternatives being occupied. The bus takes a lap hoping that the queue will be availableat the next decision point. The next decision queue is the queue for the lap operation where thebus checks if any queue has become available. The already mentioned operation lap entry occursif the bus must start with driving a lap at the terminal, due to bus stops being occupied.

Queues for the lap operations have a slightly different function than the other queues. The aim ofthe queues is to detect and count the number of buses taking a lap and at the same time try toreserve the desired queue. The buses never stop at these queues; the signal turns green immediatelywhen a bus is detected. An extra type of detector is necessary to enable detection of the busestaking a lap, see Figure 8. Hence, the lap queues have two types of detectors, one for tracking thebus lines and one for controlling the signal head. This is not necessary for the other queues sincethe type is determined when the buses are generated and not needed to be detected again. Thelap operations can be used to analyse how often the desired bus stops are occupied.

Figure 8: The lap queue construction. The first square, the purple one, is a detector used totrack the buses.

5.3 Operations in VisVap

As shown in Figure 7, the queues consist of a route, a detector on the queue, a signal head,a decision and a detector after the queue. Different parts of the terminal logic in VisVap areactivated depending on the bus’s location and the simulation time. As mentioned, the queues forthe buses taking a lap has one more detector on the queue than the rest.

All the checks for controlling the queues are performed in VisVap. The terminal logic is dividedinto four different functions: receive, serve, release and reset. A flowchart of the terminal logicis presented in Figure 9. These functions, or modules, are responsible for sending buses betweendifferent queues in the network. More precisely, the functions perform checks to decide to whichqueue and when the buses should be sent. All these functions occur for each queue, presented inChapter 5.2. Operations in Vissim, when they are necessary.

Figure 9: Flowchart of the terminal logic.

22


5.3.1 Receive

Receive can be seen as the first part of the terminal logic. This module starts when a bus arrivesto a queue. When a bus arrives to a queue it has no route, the route ends in the beginning of eachqueue. The vehicle is detected by the detector and information about the vehicle is determined.The receiving module need to determine the queue type and which bus that visits that queue.Which bus it is can either be picked from an array or determined when the bus arrives, dependingon the queue type. When generating buses, the bus line can be determined based on the remainingbuses in the queue. This information is determined in order to find the release time, which startsthe serving module when the release time occurs. The release time indicates when to change signalstate to green and let the bus continue to its next event. The calculations of the release time varybetween queue types. For the generating queues, the release time of the buses is equal to the timewhen the bus is supposed to arrive at the terminal minus the driving time to get there. The queuetypes for the lap function and the entry function, assigns a release time equal to the time whenthe bus is detected at the queue. Queues at bus stops and the layover area finds a predeterminedrelease time when receiving the bus. If the time between arriving to the queue and departure istoo short, a new release time for the queue is calculated ensuring enough time at the queue. Thetime between arrival and departure needs to be long enough to manage the purpose of visiting thequeue. For example, pick-up and drop-off passengers. The release times for the queues are storedin an array and used to trigger other modules of the terminal logic in VisVap.

5.3.2 Serve

Serve is the second part of the terminal logic. The serve module starts when the release time,determined in the previous module, is reached by the simulation time. Before the received bus isserved in purpose of finding the next event for the bus, a range of conditions are checked. Exampleof conditions are if there is time to park and which queue that is most suitable. Queue typesare served differently depending on possible events that can follow. If no appropriate next queueis found, there are different outcomes depending on the queue type. If the current queue is agenerator, the bus takes a lap within the terminal. If the current queue is a lap queue, the bustakes another lap. For the other queues, bus stop or layover area, the bus is held a bit longer.

The last thing that occurs in the serve module is assigning the bus a new status. The assignedstatus depends on the next event for the bus. Example of statues are parking at the layover area,exiting the terminal, disembark or board at a bus stop.

5.3.3 Release

Release is the part of the terminal logic that follows directly after the serve module in VisVap.The bus is assigned its next route leading to the assigned queue in the release function. All thevalues for the bus is known, which bus it is, the current queue and the next queue. Based on thevalues, the bus is allocated a route to the next queue and the signal state turns green. When thesignal is green, the bus can depart from the queue.

5.3.4 Reset

Reset is the last part of the terminal logic. The reset module is activated when the bus reaches thedetector after the queue, see Figure 9. All values connected to the queue is reset in order to makethe queue available again. For example, the route and the release time from the queue are reset.The reset module also changes the signal state for the queue to red. The queue is then availableagain.

23

5.4 Implementation of terminal logic operations in VisVap


In order to provide an understanding for the implementation of the terminal logic in VisVap, anexample of a bus visiting a queue will follow in this chapter. As an addition to the example, aflowchart is created illustrating the different computations needed for the bus. The flowchart ispresented in Figure 10. The boxes with solid blue line represents the four main functions busespass through when visiting a queue. The boxes in the flowchart with dashed blue lines representfunctions or output from the main function they are connected to.

Figure 10: Flowchart for VisVap.

Figure 10 is created to illustrate the different operations and is not from any of the used programs.Figure 11 is from VisVap (PTV GROUP, 2014) and is only constructed in order to present theprogram. The figure does not illustrate a runnable code, the aim is only to present the program,its different windows and function boxes in the flowchart.

24


Figure 11: The different windows in VisVap, one for the flowchart and several for inputs andsubroutines (PTV GROUP, 2014).

The example starts when the current route ends, leading to the bus being received by a new queue.Let say the bus is visiting a bus stop with the purpose of boarding, meaning pick-up new passengers.The purpose of the queue visit depends on the status assigned to the bus at departure from theprevious queue and the purpose of the bus’ visit to the terminal. There are several conditionschecked in the receive function. In Table 1 the functions within receive are presented. Dependingon queue type of the queue the bus arrived to, the checks are activated and performed differently.The output of the receive box are the release time from the queue which activates the other mainfunctions in the flow chart.

Table 1: The receive function

Function Explanation Usage

Detection Detect bus at queue Detect arriving buses and check velocity, needed inother calculations

Time Time to perform theevent

Ensuring there is enough time for the events before thebus is being released

Release time Output from receivefunction

Either calculated with time factors or collected frompredetermined times

For the bus at the bus stop, it is not enough to be detected for the calculations connected to thereceiving of the bus to start. There is also a demand for the velocity to be zero, due to passengersnot being able to board or disembark until the bus opens the doors, which is not possible untilthe bus stand still. When the bus is detected and standing still at the bus stop the calculation ofa release time starts. The bus has the status of boarding, from the previous queue. Due to thestatus board, a time value for how long time it may take for passengers to board are retrieved froman array. The array contains measured boarding times at the studied terminal, for each boardinga new time is collected from the array until all has been used. When all values have been used andmore boarding takes place the array starts form the beginning. Each action requiring a time hasits own array with times, except the layover area. By collecting times over the whole simulationperiod from the arrays, a variation of how long an operation may take is captured. If the time toperform the bus operations, for example boarding, are less than the predetermine exit time, therelease time is set equal to the exit time. If the time are greater than the predetermined time, therelease time is equal to the time when the operations have been finished.

25


The bus in the example has enough time to carry out the operation of boarding passengers andtherefore, the release time from the queue is set equal to the exit time from the terminal.

After the receive operation is finished, the bus waits or performs its operation at the queue untilthe release time is reached. When the simulation searches for the release time, conditions suchas current signal state, which bus visiting the queue and detection of the bus is checked. For theterminal logic to proceed to the functions serve and release, there is a demand on the signal stateneeds to be red, otherwise the logic proceeds to reset. However, for the bus in the example thesignal state of the queue is red, therefore the function serve starts. The wanted output from thisfunction is which queue the bus should visit next. The next queue is determined based on availablequeues and the purpose of the visit. The functions occurring within serve are presented in Table 2.

Table 2: The serve function


Find queues Checks available queues Finds possible queues to send the bus to depending onnext purpose

Time to park Investigate time to nextevent

Time before exiting the terminal is larger thanminimum time for park plus time for the next event

Allocationqueues

Possible bus stops Checks possible bus stops for the bus line to use at theterminal

Update infor-mation

Update and determinenext event for the bus

Next queue is determined and the status of the bus isupdated

Possible queues to send the bus in the example to after the passengers have boarded are queueswith queue type exit. However, each time the terminal logic enters the serve function a generalsearch to find available queues in the network are performed. The search does not include thequeue types generator, entry or exit, due to these queue types either not being possible to revisitor always should be possible to visit. The logic continues, in order to investigate if there is timeto park at the layover area. Due to the bus in the example having the status board, it does notmeet the condition to check if there is time to park and the layover area will not be an option asthe next queue. In order to start the check of time to park, the bus needs to have a status anda stop type where the layover area is seen as an option. For buses with passengers aboard, thelayover area will never be an option. As mentioned, the search of available queues are general andperformed for the whole network. However, it is not enough for a queue to be available for a bus tobe assigned the queue, the queue also needs to be allowed for the bus to use. This is because buslines often have specific bus stops they are supposed to use at a terminal. The specific bus stopsare predefined and the logic checks if the queues are allowed for a bus to use. When all informationabout possible queues has been investigated, the bus can be served a new queue and status.

Back to the example bus, which has the status board, meaning the queue is already checked to beallowed. The bus is at a bus stop of queue type dock and for the status board there is only oneoption for this bus, which is to exit the terminal. The next queue for the bus is its predeterminedexit queue, which is specified by the user. Left to do before the bus is finished in the serve functionis to update the status of the bus and collect statistics if desired.

After being served, the bus enters the release function directly. These two functions occur in thesame time step. In release, two important things take place, the bus gets assigned a route to itsnext queue and the signal state changes to green. This means that the bus can leave the bus stop.The functions in release are presented in Table 3.

26


Table 3: The release function


Route Decide andassign

Route to the next queue is decided and assigned to the bus

Signal state Release bus The bus is released from the queue by changing the signalstate to green

Release has the same function for all queue types and earlier assigned statuses and stop types. Ifthe bus does not get a next queue when being served, the functions route and signal state does notoccur. This happens if the next queue and the current queue are the same. Release then assignsthe current queue as the previous, next queue and release time for the bus is reset so the bus canbe received again and assigned a new release time. However, the bus in the example already hasa next queue allocated. Based on that information, a route that takes the bus to its next queuecan be decided for the bus. This route is based on the implemented routes in Vissim. The route isassigned to the bus and the signal state of the visited bus stop is changed to green. Some arraysare updated with data from release, after that update the bus is considered finished in the releasefunction.

The relation between the bus and the queue representing the bus stop ends in the reset box. Beforethe relation can end, it is necessary to ensure that the bus has left the queue and passed the signalhead. The reset functions in Table 4 occurs several time steps after serve and release. Due to thebus needs to have time to start leaving the bus stop.

Table 4: The reset function


Control release Checks that the bushas left

No reset of the queues can start before it is certain thebus has left

Signal state Reset the signal state The signal state is set to red so no bus can passwithout being served

Reset data Make the queueavailable

Data connected to the specific queue and bus is reset

The reset functions are the same for all queue types in the terminal logic. As mentioned before,the function first checks if the bus has passed the signal head. When ensuring that the bus hasleft, the signal state changes directly to red to make sure only the served bus leave the bus stop.The data connecting the bus and the bus stop needs to be reset in order for the bus stop to becomeavailable. The data to reset is the assigned route, the bus visiting the queue and the release timefrom the bus stop.

All functions in the terminal logic have now been visited by the bus and therefore the bus and thebus stop has ended their connection with each other. The example of the bus at the bus stop isfinished, the terminal logic starts all over when the bus reaches its next queue.

27

6 CASE STUDY OF NORRKOPING BUS TERMINAL

6 Case study of Norrkoping bus terminal

In order to evaluate the method terminal logic, a case study has been performed. The chosencase study for this thesis it the bus terminal at Norrkoping travel centre. This chapter presentsthe performed case study and the implementation of the terminal logic. In order to investigatethe bus terminal, information about the current terminal was needed. For example, geographicalplacement, type of terminal and type of traffic.

6.1 The current terminal

The bus terminal in Norrkoping is located at one side of Norrkoping travel centre, which is locatednext to the railway in the northern part of Norrkoping’s city centre. The location of the travelcentre in relation to the rest of the city is illustrated in Figure 12. Furthermore, the figure alsoillustrates where the bus terminal is located in relation to the rest of the travel centre.

Figure 12: Location of Norrkoping bus terminal. (Google maps, 2017)

The public transport system in Norrkoping consists of tram lines, local bus lines, express buses,public transport to rural areas and long-distance traffic. Ostgotatrafiken is responsible for allthe public transport except the long-distance traffic, which is provided by several private buscompanies. As can be seen in the top right corner of Figure 12, there are different locations forpublic transport. The tram lines and the local bus lines uses the location labelled RC (NorrkopingRC tatortstrafik). Express buses, public transport to rural areas and long-distance traffic uses thebus terminal, which is labelled Bus (Norrkoping Central Bus) and marked with red.

The bus terminal has a drive-through design with saw-tooth bus stops, see Figure 13. In the topright corner of the figure, there is a zoomed part which displays the design of the bus stops. Theterminal has three drive-through paths with six bus stops along each path, giving the terminal 18bus stops in total. The path in the bottom of the picture, labelled C, is the only one that is atwo-way path and the other two, A and B, are unidirectional. This means that the buses can usethe two-way path to drive around within the terminal area. The entrance to the terminal is located

29

6.2 Technical details for the implementation

in the roundabout on the right side of the terminal area in the figure. The terminal has two exits,one in the same roundabout as the entrance and one in the bottom left corner of the terminal.Only buses from A and B can use the exit in the roundabout, due to the possibility of using Cwith a two-way path. The layover area is located in the top right corner in the figure and has nospecific marked bus stops. The buses can park wherever they want, according to Ostgotatrafiken13 buses are supposed to fit at the layover area at the same time.

Figure 13: Design of Norrkoping bus terminal. (Google maps, 2017)

6.2 Technical details for the implementation

Several delimitations has been made due to limitations regarding what is possible to implement.Early in the planning process of the thesis, it was decided to use simulation and more specificallythe software Vissim. Hence, no proper evaluation of alternative tools and softwares were conducted.There are analytical models for calculating the capacity of bus terminals, but they have not beeninvestigated further.

The area for the case study is limited to only include the bus terminal and its entrance point andexit points. The traffic on the road outside of the terminal, Norra Promenden, is not includedin the simulation. However, the influence from the outside traffic on the entrance and exit timesare included. The influence is illustrated as the waiting time to exit the terminal and drivingtime to bus stops. Even though the traffic on Norra Promenaden is not included, the road isvisually included in the network. This is because of the terminal logic used in the simulation.Apart from not including car traffic, the model does not include pedestrians and bus passengerseither. This interaction is instead represented by delays in the model. The interaction has beenconsidered during data collection, meaning that the delays caused by the interaction is included inthe measurements from the field study.

When performing simulations there is a time limitation. Since the evaluation is based on capacity,it is desirable to simulate the time period when the highest demand occurs. Therefore, some eventsmay not be discovered or considered in this case study.

Several technical details have been limited when implementing the terminal logic method onNorrkoping bus terminal. In the model, it is assumed that a bus never changes parking spaceat the layover area. When the bus has parked at the layover area, it stays at the same place untilit leaves to visit a bus stop. In reality, a bus can drive forward to a new stop at the layover areawhen it is available. This to enable for other buses to park behind. Another detail with the layoverarea is the number of parking spaces. A fixed number of parking spaces is created at the layoverarea in the model. In reality, there is no marked parking spaces at all.

During field observations it has been discovered that buses stand still at areas not intended forthat purpose. At the terminal, it is possible for a bus to use the space between two bus stops iftheir desired bus stop is occupied. This behaviour is not captured in the model. Instead the bus

30


has to wait for the desired bus stop to become available. The bus waits behind the bus occupyingthe bus stop, which can cause queues. Another driving space behaviour not captured in the modelare buses parking at the reversed lane at C, see Figure 13, leading towards the layover area. Otherbuses has to use the opposite lane to pass the idle bus. This behaviour does not occur in the modelsince no queues are created along the reversed lane at C and therefore it is not possible for busesto stand still there.

Another technical detail is that the terminal has a specific space for taxis and drop-off. This areais not built in the model. Due to congestion, it can happen that bus drivers reverse within theterminal to change exit. This behaviour is delimited from the model. The terminal is used bydifferent types of bus models which are difficult to illustrate in Vissim. Therefore only one busmodel is used in Vissim, with the length of 14.5 meters, to represent the longest buses used at theterminal.

To perform a simulation of the bus terminal, data to represent the terminal is necessary andespecially the buses movements within the terminal. Some data has been received from stakeholdersusing the terminal and some through data collection.

6.3 Data collection

An understanding of the traffic at Norrkoping bus terminal is necessary in order to perform the casestudy. The buses’ movements within the terminal can describe the traffic and provide necessaryunderstanding. Data describing the movements can for example be arrival times and layover times.This kind of data can be received from stakeholders but is often considered as company secrets.Desired data not provided from stakeholders can be gathered by hand through field observations.Some data is compared to the time tables from Ostgotatrafiken, used at the terminal during spring2017. This subchapter presents the data collection for this thesis, which is a combination ofprovided data and data from field observations.

Table 5 describes the data necessary for the simulation and how it was retrieved.

Table 5: Data necessary for the simulations

Type of data Origin

Arrival time to the terminal Ostgotatrafiken

Exit time from the terminal Ostgotatrafiken

Routines regarding the layoverarea

One bus operator and performed measurements at fieldobservations

Driving time between queues Performed measurements

Time for board and disembark Performed measurements

Time at layover area Performed measurements

Times for long-distance traffic Performed measurements

6.3.1 Bus movements within the terminal

As mentioned, the bus movements within the terminal is necessary to obtain an understanding ofthe traffic at the terminal. Furthermore, data for the bus movements is needed as input to thesimulations. In order to use the terminal logic presented in Chapter 5. Framework for terminallogic, data for the movements is necessary to determine when to send the buses between thedifferent queues. The needed data regarding the buses movements are for example time for arrivaland departure but also which bus line the bus belongs to when entering and exiting the terminal.

An efficient way to obtain the required data for the bus movements would be to get the planningfrom the operators responsible for the traffic at the terminal. This planning often contains infor-mation about the buses movements within the terminal. For example, when a bus has drop-off,

31

6.3 Data collection

how long it is parked at the layover area and when it has a new departure from the terminal. Theproblem with this kind of data is that it can be confidential, as mentioned. In this thesis, someplanning data was received from Ostgotatrafiken but not enough to describe the movements. Thereceived data contained information about arrivals and departures of buses but no informationabout the layover area. Therefore, information about the usage of the layover area needed to becollected by field observations. One bus operator provided information that the layover area isused if a bus has 15-35 minutes between its departures. This information can be used to determinewhen a bus in the simulation is supposed to be sent to the queues at the layover area, but it doesnot tell anything about the number of buses using the layover area. Furthermore, this time intervalis only based on information from one operator. Hence, field observations of the layover area isnecessary.

Another shortage with the given data is that it does not include any long-distance traffic. Sincethe long-distance traffic is provided by several private operators and the schedule is different evenbetween the weekdays, this traffic also need to be observed during field observations. Beforeperforming the field observations, the simulation period need to be determined. Since it is thecapacity that is being investigated, the peak hour is most interesting to simulate.

6.3.2 Peak hour

Determining the peak hour at the bus terminal is necessary both in order to decide which timeperiod to simulate and when to perform field observations. The data retrieved from Ostgotatrafikencontained planned arrivals and departures to and from the bus terminal for a whole day. This datais used to analyse how the buses’ movements is distributed over the day, in order to find the peakhour. Arrivals and departures is analysed at the same time, due to they being individual events inthe retrieved planning. Therefore the peak hour is determined based on the maximum number ofevents at the terminal at the same time. Figure 14 illustrates the number of arrivals and departuresduring the day. As can be seen in the figure, there is no obvious peak period. Besides the peakaround 16:30, there are many smaller peaks spread over the day. Hence, the data was aggregatedinto larger time intervals in order to determine a peak hour.

Figure 14: Number of arrivals and departures for each minute.

32


Figure 15 illustrates the number of arrivals and departures aggregated into time intervals of tenminutes. The aggregated data indicates the existence of two peak hours, one in the morning andone in the afternoon. It is still difficult to determine the peak hour more precisely and chosesimulation period.

Figure 15: Number of arrivals and departures per 10 minutes intervals.

The data was aggregated into time intervals of one hour in order to separate the peak hours, seeFigure 16. When aggregating the number of arrivals and departures, it is clear that two peak hoursexists. One peak occurs around 07:00 and the other around 16:00.

Figure 16: Number of arrivals and departures per hour.

33

6.3 Data collection

Based on this analysis of the given data, 15:10-17:10 was determined as the simulation period. Ascan be seen in Figure 16, the peak period is longer in the afternoon. Hence, the peak hour in theafternoon was considered most interesting.

6.3.3 Field observation

Data necessary for the simulations but not given from any of the bus operators, were collected byfield observations. The time period for the field observations was determined based on the analysispresented in Chapter 6.3.2. Peak hour. As mentioned in Chapter 6.3.1. Bus movements withinthe terminal, it is measures describing the buses movements within the terminal that needs to begathered by field observations. The data from the field observations are used as a complement to thegiven data for most of the traffic at the terminal. The long-distance traffic have a variation betweenweekdays. Therefore, it is difficult to use timetables so their movements within the terminal arecompletely based on field observations.

Since the simulations are time based, the gathered data needs to be in time format in order to beused as input. The data measured during field observations are: board times, disembark times,waiting time at exit, time at layover area and driving time between layover area and bus stops.Field observations are performed at several occasions in order to capture variations. All data hasbeen collected on at least two different occasions.

Some of the gathered data are used as average values in the simulations and others are used asarrays in order to capture variance. Table 6 presents used variables and if they are average, varyin an array or a condition.

Table 6: Type of the gathered data.

Data variable Type

Time to exit Array

Driving time between queues Average

Time to board Array

Time for disembark Array

Time at layover area Minimum condition

34


6.4 Implementation of Norrkoping bus terminal

In order to perform the case study, the terminal logic needed to be implemented to Norrkoping busterminal. As mentioned earlier, all terminals are unique and the general terminal logic presentedin Chapter 5. Framework for terminal logic was adjusted both in Vissim and VisVap to representNorrkoping bus terminal. A network model was built in Vissim representing the terminal, seeFigure 17.

Figure 17: The created network of Norrkoping bus terminal in Vissim.

The network was built using the design presented in Figure 13 as background. The picture wasinserted as background in Vissim and set to scale by measuring the length of path B in Google mapsand enter the length of path B in Vissim. The background was used to build the network as closeto reality as possible. The built network is presented in Figure 17, the background is inactivatedin the picture. As mentioned before, all driving spaces were represented by links instead of theembedded stops for public transport (PT stops and PT lines). The blue lines in the figure are linksand the pink ones are connectors, connecting the links to each other. The links and connectorswere drawn along the bus stops and the driving spaces of the background map in order to createthe drive-through design with saw-tooth bus stops. The short turquoise lines represent end pointsfor possible routes in the network while the short crossing pink line represents start points ofroutes. As mentioned in Chapter 6.1. The current terminal the terminal consists of one entrance,two exits, 18 bus stops and 13 parking spaces at the layover area, all represented by queues withdetectors and signal head.

Due to bus terminals being unique not all general functions presented in Chapter 5.2. Operationsin Vissim was needed in order to represent Norrkoping bus terminal. From the general terminallogic the following functions was implemented: generating buses, holding buses at bus stops andlayover area and buses exiting the terminal. Some of the functions needed to be adjusted in orderto fit the Norrkoping bus terminal, this is presented in Chapter 6.5. Modifications of the generalterminal logic The function Buses taking a lap was not implemented, neither was the demand ofreserving the next queue to visit implemented.

35

6.5 Modifications of the general terminal logic

Before the entrance to the terminal, several generating queues were built in the network. Thesequeues are in the bottom right corner in Figure 17. The generation queues created buses of variouscolours, making it easier to distinguish between the buses in the network. In total, 64 queues werebuilt in the network. The terminal logic requires equal dimensions, each queue in the networkneeds to have the same amount of possible queues to visit. The queues were built using mainlythe queue construction in Figure 7. As mentioned, all queues representing bus stops and parkingspaces at the layover area uses the queue construction in Figure 7. All 64 signal heads wereconnected to the same signal controller, which was controlled by VisVap. Hence, no signal schemein Vissim was used for the signal heads. In VisVap, the input data needed to be adjusted torepresent Norrkoping bus terminal. The number of queues, signal heads and detectors needed tobe predefined and correspond to the implemented amount in Vissim. Apart from VisVap knowingthe dimensions of the network in Vissim, the collected data in Table 6 and the planning of busmovements was also implemented in VisVap.

The bus terminal in Norrkoping is also used by long-distance traffic, this traffic group does not existin the general terminal logic. To obtain an accurate representation they need to be implementedbut as a separate traffic group since they have other demands and behaviour than local and regionalpublic transport. Path C in Figure 7 are only used by long-distance traffic. The bus stops areconstructed with the regular queue construction, see Figure 7.

6.5 Modifications of the general terminal logic

Several aspects from the general terminal logic needed to be modified in order to model Norrkopingbus terminal. As mentioned, some functions were not implemented while others were modified inorder to represent the terminal. All functions regarding how buses are sent between queues are un-changed, however the demands for sending have changed. General modifications and explanationsof why functions have not been implemented will be presented in this chapter. Each function andthe performed modification to it are also presented.

Since the network does not include Norra Promenaden, the road outside the terminal, the buses willgo straight from generation into the terminal area. There is no need for the operation entry to beperformed individually since the buses do not travel in the network before entering the terminal.The function of allocate bus stop is still needed and therefore moved from entry operation togeneration for the case study of Norrkoping.

The operation of buses taking a lap and the function of buses need to reserve their next queue tovisit is excluded for the Norrkoping bus terminal. They are excluded due to not being representativeof the real system. To some extend these two can be seen as connected to each other. In the generalterminal logic it is checked which queues that are available and then given as options for the busis they also are allowed for the bus to use. If no allowed bus stop are available to reserve, the busmay be sent to drive a lap within the terminal. Due to the demand of reserving queues, buses inthe model of Norrkoping was at first sent to drive a lap within the terminal even if this never hadbeen observed during field observations. Therefore the behaviour of driving a lap was consideredunrealistic and was removed.

When removing the lap operation buses had no alternative destination when reservation of nextdesired queue fails. They can stay at their current queue but with the risk of causing secondaryproblems. If the desired bus stop would be occupied it was considered to be more realistic for thebus to wait behind until it becomes available therefore, the check and reservation of queues wereremoved. The buses waiting behind had no position in the logic which created some problems. Itis the queues that has the information of which bus that are visiting them at the moment. Thisinformation is given to the bus stop when the bus is served by the previous queue. Since eachqueue and bus stop only can handle one bus at the time in the general terminal logic, severalbuses cannot be assigned the same queue during the same time. To solve this problem each queuewas extended with virtual queues. Virtual queues is a way of extending the number of positionsin a queue. They do not exist physically in the network but exits in the logic. The changes forimplementing virtual queues are only performed in VisVap, where the queues are extended toinclude more than one position but no extra positions are built in Vissim. By introducing virtualqueues, the information about the bus visiting the queue at the moment was not mixed up with

36


the information regarding the waiting bus (i.e. the bus stops could be aware of buses waitingwithout forgetting the current). Example of information that was mixed up before introducingvirtual queues was purpose of visiting and release time. Another argument for having buses waitbehind instead of driving a lap is that Norrkoping bus terminal is large when it comes to areaand buses seldom spend long time at the bus stops. Therefore it was also considered to be moretime-efficient to wait behind the bus occupying the bus stop than taking a lap around the entireterminal. Since both the lap function and the entry function were removed, the lap entry functionwas removed too.

Even if the reservation of queues is considered unnecessary for the Norrkoping bus terminal, itstill needed to be used for the layover area. If buses wanting to visit the layover area do notcheck available queues, they all will find the queue with the lowest number and choose it as theirdestination. Therefore, the reservation where kept for the layover area to ensure all buses choosesan empty queue as their destination at the layover area. This decision was also made based onhow the terminal logic operates in VisVap to simplify the modifications needed. As for all theother queues the layover area was also extended with virtual queues due all queues in the networkbeing defined in the same array in VisVap. At the layover area the virtual queues caused the sameproblem as occurred without them at bus stop. Therefore a condition was introduced where thelogic continues directly to the next queue at the layover area and not investigate or assign virtualqueues as the next destination.

As mentioned, the terminal has two exits. One exit leads into a roundabout and the other one iscontrolled by a signal head. The two exit queues were modified in VisVap to be constructed moreas the queues for bus stops. In Vissim the queues for exit has the same construction as most ofthe other queues, the construction presented in Figure 7, Chapter 6.1. The current terminal. Thechange from the general logic were done in order to capture the variety in time needed to exit theterminal. In the general terminal logic buses are let out of the terminal as soon as they are detectedat an exit queue. During field observation it was established not to be accurate for the buses at theterminal. For the logic implemented on Norrkoping bus terminal the buses were given a waitingtime at the queue to illustrate the time needed to enter the traffic stream at Norra Promenaden.Since the exits at Norrkoping has different construction the waiting time varies between them andthey are therefore provided with individual arrays containing waiting times to exit the terminal.When detecting a bus at an exit queue, a value is picked from the array. The time for detectionplus the value from the array is the time for when the bus is going to be released form the queueand exit the terminal. For buses to be detected at an exit their velocity needs to be 2 km/h orless. In the general terminal logic the velocity needed to be 0 km/h but this was not consideredaccurate with the real system.

As mentioned earlier the terminal is used by long distance traffic who has different behaviourand demands then the public transport provided by Ostgotatrafiken. There are many differentproviders of long-distance traffic and was therefore considered to be difficult to receive planningof the movements. The method license plate survey, presented in Chapter 4.3. Required data, waschosen as the technique to gather data of the long distance traffic movements at the terminal. Thegathered data was time of arrival, used bus stop and for how long time the bus was visiting thebus stop. Due to the different behaviour of long distance traffic and the data not having varietyas public transport, they were constructed as a separate group in the logic. The bus stops used bylong distance traffic was only provided with exit queue as option of next visit. The long distancetraffic has an uncertainty of when to arrive at the terminal. Therefore they sometimes need tospend longer time at their bus stop without driving to the layover area than the minimum conditionstates. The layover area is not supposed to be used if there are passengers aboard and since noneof the observed long distance buses had Norrkoping as start or end destination the layover areashould not be an option to use. No disembark or board times are used for the long distance trafficsince the time spent at bus stop were measured during field observation. The driving time betweenqueues are the same for the whole network.

37

6.6 Model analysis

6.6 Model analysis

To evaluate the terminal logic and the capacity at Norrkoping bus terminal three experiments wereperformed. The first one was the current situation where it was possible to verify the model againstthe real system. For the other two experiments some modifications to the system was necessary.

Worth mentioning is that the long-distance traffic only influences the results regarding the delay,otherwise it is not included in the result. This applies for all three scenarios. The long-distancetraffic is created separately from the rest of the traffic and would not generate comparable results.Hence, it is considered better to only present numerical results for the bus stops and the layoverarea but with influence from the long-distance traffic.

6.6.1 Verification and validation

Verification and validation of the simulation model was an ongoing process during the wholemodel building. It was possible to verify both the built network with connections and numberingof implemented detectors, routes, signal heads and other building blocks as well as the behaviourof the buses. Since the general terminal logic, presented in Chapter 5. Framework for terminallogic, needed to be adjusted to Norrkoping bus terminal it was important to verify the modelbehaviour. All changes from 6.5. Modifications of the general terminal logic needed to be verifiedin order to make sure the modifications resulted in the indented behaviour and that the behaviourwas consistent with the observed behaviour.

The verification process was carried out in two different ways, verifying model behaviour by lookingat the simulation in Vissim and verifying the VisVap code by using the debug mode in VisVap.Some of the problem presented in 6.5. Modifications of the general terminal logic were discoveredduring verification. By studying the simulations in Vissim graphically, it was possible to determineif a bus used the right bus stop or the right exit for example. During verification of the networkbehaviour, the input data was printed and compared to the behaviour during simulation. Theprinted input data contained generation and exit time, purpose of visit and which bus stop tovisit at the terminal. It was then possible to follow buses in the system to see if events whereperformed at the intended time. When studying the simulation, behaviour not consistent withfield observation was discovered even if the behaviour was correct according to the input data.It was two different kinds off behaviour that was discovered, buses spending too long time atthe bus stops and buses wanting to use the same bus stop at the same time. As mentioned thebehaviours corresponded with the input but not the field observations. To find out if the problemwith buses spending too long time at the bus stops was an input error or a logic code error, boardand disembark times where measured and compared with the input data. When comparing, itwas concluded that the input data was the problem. The received general terminal logic containedtime measurements for a bus terminal in Stockholm which was at first planned to be used in orderto save time. However, the times were not representative for Norrkoping bus terminal and newtimes were collected. The error of two buses wanting to use the same bus stop were corrected byletting the bus with purpose of drop-off passenger arrive early. This decision was made based onchecking Ostgotatrafiken real time update of arrivals, buses with the terminal as end destinationwas normally a few minutes early. Buses wanting to use the same bus stop occurred three timeswhen studying the simulation. All three conflicts were between a bus ending its route and a busstarting a new route. The conflicts were solved by letting the buses with ending routes arrive threeminutes earlier than according to the planning.

The debug mode in VisVap was normally used after an error had been noted after watching thesimulation with no obvious connection to the input data. An example of discovered problem withdebug was the need of virtual queues to ensure bus visiting the bus stop and bus waiting behindwere not mixed up. When running the simulation in debug mode it is possible to follow all stepstaking place within one time step.

As mentioned in Chapter 4.6. Verification, calibration and validation, the gathered data can bedivided into two different data sets and be used for input and validation. It is important that thedata is collected at the same time, then one data set can be used as input and the other one tovalidate the simulation model. The ambition was to validate the time it takes for buses to leave theterminal. From the buses were detected at an exit until they were given green light at the signal

38


head. Therefore, the data for exit times were divided into one input set and one validation set.This was harder than expected and comparing the output with the validation data only showedthat the data has large scattering, which also could be seen in the standard deviation. Hence, veryfew validation results are presented in the thesis. The validation that was performed regarding thewaiting times at the exits was comparison of the average values for output and validation data.The average waiting times are presented for both data sets and for both exits in Table 7. Allwaiting times are presented in seconds.

Table 7: Validation of average waiting times at exits.

Exits Simulation output Validation data

Exit in roundabout 13.59 5.77

Exit with signal head 14.19 16.84

The average waiting times differ more between the output data and the validation data for theexit at the roundabout than for the exit with signal head. There is no obvious reason why and thesimulation model was considered good enough to use.

6.6.2 Scenario 1: Current design and frequency

The first scenario that was simulated dealt with the existing bus terminal in Norrkoping. Thecurrent design and traffic volumes were used in order to evaluate the capacity. This experimentwas performed with the terminal logic implemented for the existing bus terminal based on Chapter6.4. Implementation of Norrkoping bus terminal and 6.5. Modifications of the general terminallogic.

Numerical results were necessary to be able to analyse the simulation output. As mentioned brieflyin Chapter 5.4. Implementation of terminal logic operations in VisVap, it is possible to record andcollect desired statistic through VisVap. The same numerical results were collected for all threescenarios and the numerical output considered interesting is presented in a list in the beginning ofChapter 7.1. Case study of Norrkoping bus terminal.

6.6.3 Scenario 2: Current design with higher frequency

The second scenario had the same design as scenario one, but higher frequency. The aim of thisscenario is to increase the amount of events at the terminal, during the simulation period and, tosee how the terminal reacts. This scenario can be used to evaluate the assumption of overcapacityat the terminal.

Frequency increment was achieved by adding new arrivals and departures between the existingones. If a bus line had one departure per hour in the current scenario, the departure rate wasincreased to one departure each half hour. The same was done for arriving buses. The frequencywas not increased by a certain percentage over all events, but increased individually for each busline. The received data is time table based, meaning they are individual and connected to a certaintime. Therefore, the increase of traffic needed to be performed manually. The long-distance trafficwas not increased at all. The traffic was not doubled, only increased, since new events were addedbetween, before and after the existing ones within the time period. This lead to an increase from66 buses in scenario one to 105 in scenario two.

Modifications performed for this experiment only regarded the input data in VisVap. Since thedesign is the same as in scenario one, no changes in the Vissim network were required.

39

6.7 Sources of error

6.6.4 Scenario 3: Decreased number of bus stops with current frequency

The third, and last, scenario had the same frequency as the first scenario but a different numberof bus stops. The aim of this experiment was to investigate how the design of the bus terminalimpacts the capacity and utilization.

The number of bus stops at the terminal was reduced by a third, leaving twelve bus stops insteadof the previous 18. This is besides the bus stops at the layover area, they were left the samein this scenario. The number of bus stops was reduced by removing two bus stops from eachpath in Figure 13 in Chapter 6.1. The current terminal. Eight of the twelve bus stops are forOstgotatrafiken and three are for long-distance traffic. The last bus stop are reserved to bee usedwhen railway traffic needs to be substituted with buses.

Reducing the number of bus stops at the terminal lead to some bus lines losing their allocated busstops. Hence, these bus lines needed to be assigned new bus stops. When assigning new bus stops,whole bus lines were moved and assigned to the same new bus stops. The purpose was to makesure that a certain bus line always uses the same bus stop, to simplify for the travellers.

Removing bus stops required some effort in Vissim. The unwanted bus stops was removed fromthe network and also the routes to the removed bus stops. The numbering of bus stops was redonein order for the logic to work.

6.7 Sources of error

Several sources of errors might have an effect on the results from the case study. The input dataused in the simulation is constructed based on several different data sets. Some insecurity about thequality of the data may therefore exist. As mentioned, some data is provided from Ostgotatrafiken,other is given directly from operators and some of the data is measured by hand. The data setsconsist of both measured and planned data. The difference in origin makes it difficult to know if thedata is entirely comparable regarding for example dates, times and how the data is produced. Thedata given from Ostgotatrafiken is planned data. Actual data from the operators would probablybe better. Nevertheless, the data is considered good enough to use.

Another source of error related to the input data is the data collection. The data set that ismeasured by hand is collected at several different times and is only measured by two people. Sinceno advanced equipment was used to measure the data and the number of people was few, humanerrors might have occurred during these measures. The data was measured at several differentdays, with the aim to capture variances. This might be a source of error, due to the uncertaintiesrelated to the origin for the rest of the data.

The program VisVap is not straightforward to work with. It is difficult and time-consuming totroubleshoot, since it consists of several different subroutines which is connected to each otherin many ways. Due to the subroutines being connected, troubleshooting is complex since it isdifficult to determine where things happen. Hence, it is difficult to determine if for exampleunwanted behaviours in the model is due to problems with the logic or something else.

The simulated behaviour is not a complete representation of the real system, as with all simulationmodels. The behaviour is correct for when the buses move between different events at the terminal,but how they drive is not entirely correct. Since pedestrians and other vehicles are not simulated,the buses never stops and wait for these types within the terminal. The interactions are capturedin varying driving times. Another factor regarding the simulation is the number of replications, ithas not been investigated. One replication of the simulation in Vissim is assumed to be enoughdue to the variation and input data being implemented in VisVap. The variation in VisVap is inform of arrays with varying input data. There is no probability distributions or random valuesactively implemented in Vissim but it can still exist as default in behaviour models for example.

40

7 RESULT AND ANALYSIS

7 Result and analysis

This thesis have resulted in two different types of outcomes; one part is the result of the case studyat Norrkoping bus terminal and the other part is an analysis of the terminal logic. Both theseparts are important in order to determine how microscopic simulation can be used to evaluate busterminals and answer the research questions presented in 1.2. Purpose and research questions. Thecase study is used both to investigate the capacity at Norrkoping bus terminal and evaluate thegeneral terminal logic. Building, verifying and running the model gave useful insights regardingthe terminal logic and provided numerical results for the capacity at Norrkoping bus terminal. Theevaluation of the terminal logic will be presented in Chapter 8. Discussion.

In order to evaluate the capacity at Norrkoping bus terminal, several numerical measures fromthe model are analysed. The chosen measures regards efficiency, usage and delays at the terminal.Three different scenarios have been simulated to investigate both how the design of the terminaland the departure frequency affects the capacity and the usage of the method.

7.1 Case study of Norrkoping bus terminal

As mentioned in Chapter 1. Introduction, overcapacity at Norrkoping bus terminal is suspected. Inorder to evaluate the capacity and usage of the terminal, the three different scenarios all have thesame evaluation variables. Scenario one represent the present situation regarding design and trafficvolume. In scenario two the traffic volume is increased but the design is unchanged. Scenario threehas the same traffic volume as scenario one but a change in the number of bus stops. A numberof variables were considered interesting when evaluating the scenarios. Variables representing theresult are presented in the list below. Some of the variables consists of a combination of severalnumerical outputs and will be presented together.

• Number of occupied queues

• Maximum number of occupied queues

• Number of occupied queues at layover area

• Maximum number of occupied queues at layover area

• Utilization

• Delays in the system

7.1.1 Scenario 1: Current design and frequency

The first scenario that was simulated was the terminal as it is today, with the current design andfrequency. Due to the long distance traffic not being included, the result only regards the twelvebus stops used by Ostgotatrafiken and the layover area. This applies also for scenario two.

Figure 18 presents the number of bus stops being occupied during the simulation. The number ofoccupied bus stops are illustrated over time, i.e. how many bus stops that are being occupied eachminute during the simulation period. The bus stops at the layover area are not included since theyare analysed separately. As can be seen in the figure, the maximum number of occupied bus stopsis six and occurs 80 minutes into the simulation. The simulation time of 80 minutes corresponds to16:20 in real time. This means that the bus stops highest occupancy around 16:20 has a utilizationof 50 %.

41


Figure 18: The number of occupied bus stops for the current situation, bus stops at the layoverarea is not included. The total number of bus stops is 12.

Figure 18 also illustrates that besides the six occupied bus stops at 16:30, the next highest occu-pancy level is four. This occupancy level occurs several times both before and after 16:30. Fromthe figure, it can be established that the occupancy level of the bus stops is not especially highover time. As mentioned before, only half of the bus stops are occupied when the highest occu-pancy level occurs. This indicates that the terminal has overcapacity both regarding dimensionand utilization. This analysis coincide with findings made during the field observations. At thefield, it seemed like a peak in occupancy occurs around 16:20 and besides that it was quite calmat the terminal.

Figure 19 illustrates the number of occupied bus stops at the layover area over time. The maximumnumber of occupied bus stops at the layover area is seven, which occurs six times. The first threetimes occur after 67 minutes and the other three after 97 minutes. This means that the layoverarea has two peaks for its occupancy level, one around 16:07 and one around 16:37. Duringfield observations, maximum occupancy at the layover area was noted to be eight which does notcoincide with the simulation. This can be due to the lack of provided rules for when the layoverarea should be used. Therefore, data for time spent at the layover area were collected by handwith some difficulties. The difficulties regarded the possibility of measuring all buses with onlytwo persons. The rule for when the layover area should be used was determined based on the busthat spent the least time at the layover. Using the minimum time a bus spent at the layover areacreated a lower bound to use in the simulation.

42


Figure 19: The number of occupied bus stops at the layover area. The total number of bus stopsis 13.

Figure 18 and Figure 19 presented the number of occupied bus stops at the terminal over time.Analysing the number of parallel occupied bus stops is one way of measuring the usage of theterminal. Another way is to analyse the time bus stops are being occupied. Table 8 presentsthe total time the bus stops and the layover area are occupied, respectively. The total time isa summation of the occupancy time for all queues, 12 for the bus stops and 13 for the layoverarea. Therefore, the utilization is described in percentage to be representative regardless numberof queues. Since the time occupied is a summation for all included queues, the total simulationtime also need to be a summation of all the queues. Each queue has a simulation time of 8 000seconds, including warm up, leading to a total time of 96 000 seconds for the bus stops and 104000 seconds for the layover area. As can be seen in Table 8, the utilization of both the bus stopsand the layover area is low for the simulation period.

Table 8: Utilization of bus stops

Bus stops Layover area

Total time occupied (s) 5 249 20 242

Utilization (%) 5 19

Another measure to analyse is the buses delay when departure from the bus stops at the terminal.Table 9 presents the number of delays within time intervals of one minute. The table illustratesthat no buses are more than two minutes late and most of the delays are below one minute. Manybuses has the terminal as their start or end destination and can therefore be waiting at the layoverarea before its departure. As can be seen in Figure 19, there are buses waiting at the layover duringalmost the whole simulation period. This might contribute to the low delays, since the buses areready and waiting for their departures.

Table 9: Number of delays within each time interval.

Time interval (min) 0-1 1-2 2-3 3-4 4-5 > 5

Number of delays 22 4 0 0 0 0

43


Table 10 presents the delay from bus stops expressed in time. The delay is measured each time abus is assigned an exit as their next queue, each time a delay occurs it is summarised into a totaldelay for the system. Since this does not reveal the individual delays, the average value and thestandard deviation is calculated. The average delay is approximately 19 seconds and the standarddeviation is approximate 28 seconds. When analysing these values, it is important to have in mindthat the data used for the simulation is not fully accurate. This is because the data consisting ofseveral sources, as discussed in 6.7. Sources of error.

The standard deviation is not high and the average waiting time is not high either, even whenconsidering the standard deviation. According to the values in the table the maximum averagedelay is less than a minute. This coincides with earlier results about low delays, see Table 9.

Table 10: Delay at the terminal.

Delays (s)

Average 19

Standard deviation 28

Total 771

7.1.2 Scenario 2: Current design with higher frequency

The second scenario had the same design but higher frequency compared to scenario one. Whenincreasing the frequency, new arrivals and departures were added between the existing ones asdescribed in Chapter 6.6.3. Scenario 2: Current design with higher frequency. The method forincreasing the number of arrivals and departures might not correspond to how it would be donein reality. Ostgotatrafiken, as responsible provider, would probably plan the increased frequencybetter when adding to their schedule. Hence, the results in this subchapter needs to be analysedcarefully.

Figure 20 presents the number of occupied bus stops during the simulation. The bus stops at thelayover area are not included, they are presented separately for this scenario too. As can be seen inthe figure, the maximum number of bus stops being occupied at the same time is seven. This is onemore than for the first scenario. When comparing the scenarios, the number of occupied bus stopsis slightly higher in general for the scenario with increased frequency; for exact result see Figure 18and Figure 20. This is reasonable, higher frequency and more buses within the terminal leads toincreased occupancy of bus stops. A factor to remember is the method of increased frequency,it might be possible to decrease the maximum number of occupied bus stops with an optimisedplaned timetable. With the increased frequency, the maximum occupancy level occurs after 110minutes in the simulation. This is at 17:20, compared to 16:20 for the first scenario.

44


Figure 20: The number of occupied regular bus stops over time with increased frequency. Thetotal number of bus stops is 12.

Figure 21 presents the number of occupied bus stops at the layover area for this scenario with higherfrequency. The highest occupancy level at the layover area is eleven, which occurs four times. Thefirst time is after 68 minutes, which is at 16:08 in real time. This peak in occupancy level occursat almost the same time as for the first scenario. This is reasonable since the planning in thisscenario is based on the planning used in scenario one. Buses with similar arrival and departurewill continue to be similar but with a higher frequency. Therefore, the maximum occupancy willoccur at comparable times. As seen in the figure the layover area is occupied by at least one busduring almost the whole simulation. This was the case for the first scenario too, but there are morebuses parked at the layover area in this second scenario. Since the frequency has been increased,there are more buses in the network in general.

Figure 21: The number of occupied bus stops at the layover area with increased frequency. Thetotal number of bus stops is 13.

45


As for the first scenario, it is interesting to investigate the occupancy of the bus stops also in time.Table 11 presents the utilization of the bus stops measured in time, the calculations are performedas in scenario one. The layover area has much higher occupancy level than the bus stops. Thiscan also be seen when comparing Figure 20 and Figure 21. The bars are higher and closer to eachother in the figure for the layover area than for the bus stops, meaning that the occupancy level ishigher at the layover area. When comparing the utilization of this scenario with the first one, thelayover area has the highest increase.

Table 11: Utilization of bus stops with higher frequency




The analysis of the occupancy levels, both in numbers and in time, shows that at least one of thebus stops are occupied most of the simulation period. This indicates that there are many buses inthe network, which can lead to buses occupying bus stops for each other. This might cause delaysdue to both congestion and buses waiting for their desired bus stop. Table 12 presents the numberof delays within time intervals of one minute. With the higher frequency, there are delays up tofive minutes in the network. This was not the case for the first scenario.

However, this scenario is not verified for each event or every movement within the terminal. Theverification for this scenario was more general, checking that all buses are arriving and exiting theterminal. As mention earlier the planning may not have been optimal. The delays in Table 12occurs more often and are higher than the delays in Table 9, for the first scenario. This indicatesthat the overcapacity at the terminal are lowered with the increased frequency. As for all result inthis scenario, the delays might be different with another timetable.

Table 12: Number of delays within each time interval for the increased frequency.



Table 13 presents the delays from a bus stop in time, when wanting to exit the terminal. Theanalysis above was based on the number of buses that was late and between which intervals thosedelays happened. This table contains the average delay for the buses and the standard deviationfor the delays. Moreover, the sum of all delays are collected to illustrate the total delay whenwanting to exit the terminal. The average delay is approximately 61 seconds and the standarddeviation is 63 seconds. Both these values are much higher than for the first scenario but can stillbe considered as relatively low. The standard deviation is higher than the average delay for bothscenarios.

Table 13: Delay at the terminal for the increased frequency.

Delays (s)

Average 61


Total 2 253

46


7.1.3 Scenario 3: Decreased number of bus stops with current frequency

The third and last scenario had the same planning and frequency as the first scenario but a reducednumber of bus stops. Since the total number of bus stops is reduced, the number of bus stops usedby Ostgotatrafiken is reduced too. This means that the results for this scenario regards the eightbus stops used by Ostgotatrafiken and the layover area. Compared to twelve bus stops used byOstgotatrafiken in the first two scenarios.

As for the previous scenarios, the number of occupied bus stops are presented both for the busstops and for the layover area. Figure 22 presents the number of occupied bus stops over time,with current frequency and fewer bus stops. The maximum number of occupied bus stops is six,the same as for the first scenario. This occupancy level occurs after 80 minutes, which is 16:20.The next highest number is four, which occurs at several occasions during the simulation period.

Figure 22 is almost identical to Figure 18 regarding staple sizes and patterns. This is reasonablesince Figure 22 and Figure 18 have the same planning and frequency but different number ofbus stops. The similarities between these figures indicates that it is possible to handle the currentfrequency with reduced number of bus stops. This without compromising with the capacity neededto fulfil the demand. By reducing the number of bus stops, the overcapacity is reduced but notentirely eliminated. The occupation level are higher over time for Figure 20 than for the other twoscenarios. Hence, the increased frequency might affect the capacity more than the design since itleads to higher occupancy levels. The differences in occupancy are very small and as long as theterminal can handle the frequency, high occupancy is not a problem.

Figure 22: The number of occupied bus stops with current frequency but a third of the bus stops.

Figure 23 presents the number of occupied bus stops at the layover area. The maximum number isseven and occurs after 68 minutes and 97 minutes, which is similar to both previous scenarios. Thepeaks occurs at 16:08 and 16:37 in real time. The occupancy at the layover area is very similar tothe first scenario, Figure 18. Both these scenarios has the same frequency and the same amountof parking spaces at the layover area, which should result in similar occupancy. One differencebetween scenario one and three is the number of peaks with the maximum occupancy of seven.There are six peaks in scenario one and only five in scenario three. This might be due to interactionwith other buses or time variation when allocating time for different task from arrays in the inputdata.

47


Figure 23: The number of occupied bus stops at the layover area with a third of the bus stops.

The occupancy measured in time is presented in Table 14. Due to the same frequency, the occu-pancy should be similar to the first scenario presented in Table 8. The total occupation time isvery similar for both the bus stops and the layover area. The main difference between the scenariosis the utilization in percent for the bus stops. The utilization is 8 % for this scenario with fewerbus stops and 5 % for the first scenario with all bus stops. The utilization is only measured forthe bus stops allocated to Ostgotatrafiken. In the first scenario, 12 of 18 bus stops is used forthis purpose, this scenario only has eight bus stops allocated to Ostgotatrafiken. This affects theutilization in percent and enables comparison. The occupied time between the two scenarios aresimilar. However, the total simulation time for bus stops differ due to reduced number of bus stops.

Table 14: Utilization of bus stops with a third of the bus stops.




Table 15 presents the number of delays within the same time intervals as previously. The numberof delays are distributed in the same way as for the first scenario, in Table 9. The number of delaysbelow one minute has increased with two more delays for the third scenario compared to the firstscenario. The result for the other delay intervals are equal between the scenarios. This can beexplained by the decreased number of bus stop. The same amount of buses need to share fewerbus stops, which can create delays.

Table 15: Number of delays within each time interval with a third of the bus stops.



48


The delays for the third scenario are presented in time in Table 16. The average delay is approxi-mately 31 seconds for the third scenario. This delay is a bit higher than de average delay for thefirst scenario, even though the scenarios are similar in many ways. The increased delay for thethird scenario can be due to higher interaction between buses, since the amount of buses is thesame but on a smaller area. The interaction can for example be in form of waiting times whenbuses driving in and out from bus stops. The second scenario has much higher delays than theother two. The higher delays for the second scenario can be due to the increased frequency, moretraffic can create more delays.

Table 16: Delay at the terminal for the current frequency and a third of the bus stops.

Delays (s)

Average 31


Total 767

7.1.4 Capacity evaluation of the numerical results for the case study

In order to analyse the numerical results and use them to evaluate the capacity at the bus terminal,the results should be related to the theory about capacity presented in Chapter 3. Bus terminalcapacity. The chapter mentions two equations for determining the capacity analytically. Thenumerical results received from the simulations does not fit any of this equations completely, whichis understandable due to analytical equations and simulation being different methods. However,some of the simulation output can be related to the equations, for example occupancy time is theterm t0 in Equation (1). Simulation is also mentioned in the chapter as an option when determiningbus terminal capacity. One study that is brought up in Chapter 3. Bus terminal capacity has usedoutput from a simulation model to calculate the capacity of a bus terminal. It is stated that thebus flow (buses/h), the berth capacity (buses/h) and the saturation (%) was used to determine thecapacity but it is unclear how the capacity actually were determined. Similar outputs are receivedfrom the simulation and are used when discussing the capacity of Norrkoping bus terminal.

Based on Chapter 3. Bus terminal capacity, it seems like one possible way to determine the capacityis to use simulation and evaluate the capacity using several different measures. A combination ofmeasures describing the terminal, for example usage of bus stops and delays, can be used to analysethe capacity. If the utilization of the bus stops are low, the interpretation of the utilization canbe overcapacity and unnecessary bus stops at the terminal. Moreover, delays at the terminal canindicate too low capacity even if the capacity is enough based on the bus stop usage. Hence, thecapacity can be considered satisfying when evaluating one measure but not another. Therefore,the measures need to be analysed together in order to come up with a representative evaluation ofthe capacity for the entire terminal.

49


A summary of the results for the three scenarios are presented in Table 17. Based on the paragraphsabove, a combined analyse of these values can provide an idea of the capacity for Norrkoping busterminal.

Table 17: A summary of the numerical results for the three scenarios.

Scenario 1 2 3

Maximum occupied bus stops 6 7 6

Maximum occupied at layover area 7 11 7

Total time occupied bus stop (s) 5 249 8 868 5 121

Total time occupied layover area (s) 20 242 41 396 20 245

Utilization bus stop (%) 5 9 8

Utilization layover area (%) 19 40 19

Average delay (s) 19 61 31

The values for utilization illustrates a large time difference between the usage of the bus stops andthe layover area. Since the buses spend more time at the layover area than at the bus stops, itindicates high waiting times in the system. This can explain the low average delays at the terminal,due to buses waiting at the layover area before their departure. The utilization and occupied timeare especially comparable between scenario one and two, where the number of available stops onlydiffer with one between the layover area and the bus stops. The layover area has 13 constructedstops in the model and the bus stops has twelve.

The high waiting times at the terminal can be due to a non-optimised planning. The maximumoccupied bus stops illustrates that maximum utilization in number for the current situation at theterminal is 50 %. Over time, all bus stops are available at once several times during the simulation.Due to several buses having the same arrival and departure time. By instead planning those eventswith a few minutes in between, the occupation of the bus stops could be more evenly spread overtime but the maximum occupancy would probably decrease. Leading to even more overcapacityand unnecessary bus stops at the terminal. Worth to remember is that the analysis is performedfor a specific time period, the situation can be different at other time periods. However, based onthe values for all three scenarios it can be stated that the terminal has overcapacity.

50

8 DISCUSSION

8 Discussion

The work performed in this thesis is discussed in two steps. Firstly, there is a general discussionbased on learnings obtained when implementing and analysing the case study. After that, theterminal logic is evaluated separately.

8.1 Evaluation of the thesis

The general terminal logic is created to enable the use of time based micro simulation whensimulating and evaluating bus terminals. Since the terminal logic makes it possible to simulatethe buses’ movements within the terminal based on events and not only time, the method is mostlikely better than just time based simulation. No comparison with only time based simulation hasbeen made in this thesis though. Vissim is a time based simulation software, but since VisVap ismade for vehicle actuated signal control it can be used to activate events when a bus is detected.

As mentioned, the terminal logic consists of several different functions, for example generating,layover area and departure from bus stops. The functions control different behaviours in themodel. Hence, the terminal logic needs to be adjusted to the studied terminal. It was quite time-consuming to adjust the terminal logic to Norrkoping bus terminal. When implementing the logicat Norrkoping bus terminal, a lot of time was spent on trying to make the lap function work.Before the implementation problem with the lap function was solved, it was realised the functionwas not needed.

Implementation and adjusting the terminal logic in VisVap to Norrkoping bus terminal were abig and time-consuming part of this thesis even if a finished general code of the terminal logicwas provided. It took time to understand the program, how different parts were connected andwhich possible adjustments to make in order to obtain an accurate behaviour. One part with theimplementation in Vissim that was a bit difficult was using the signal control function which isthe connection to VisVap. It is important that the numbering in Vissim of detectors, signal headsand the signal group correspond with each other and also correspond with the number in VisVapin order to enable the connection.

A disadvantage with VisVap is that the program is sensitive and not straight forward to workwith. Firstly, the terminal logic in VisVap consist of several subroutines which makes it difficult tofollow the logic and determine where different changes are made. Another difficulty is that manyof the operations are controlled by counters. VisVap goes through all queues in the network beforecontinuing to the next time step. This showed to be a problem when applying the terminal logicto Norrkoping bus terminal. When adjusting the terminal logic to the terminal in Norrkoping, therequirement of reserving the desired queue was excluded. Not reserving the desired queue workedsince the buses only had one bus stop to chose from. However, not for the layover area where allthe stops are alternatives for the buses to use if they are available. When the buses did not needto reserve their desired queue, all buses were allocated to the same queue at the layover area. Thebuses were allocated to the queue with the lowest number, even if other stops at the layover areawere available. This lead to unnecessary and unrealistic queuing at the layover area. Thus, thereserve function were reintroduced at the layover area.

During the implementation of the terminal logic, the model was verified and validated in orderto represent the real system as detailed as possible. Beforehand, no specific method was decidedfor the verification process since there are little information about verification for this type ofassignment available. Each created bus is given an individual number when implementing theplanning in VisVap. However, that number is not possible for Vissim to keep track of during thesimulation which makes the verification more difficult. It is up to the user to visually keep trackof the buses to see if the behaviour is correct and occurs at the right time. It is possible to choosewhich data to collect and write to a file during simulation. During the verification and validation,it was discovered that some of the received planning data did not coincide with field observations.In the planning data, buses were to use the same bus stop at the same time which does not occurin reality. This occurred when one bus had the purpose of drop-off passengers and the other topick-up. Since punctuality is very important and often met at start and end destinations, it isassumed to exist a buffer for the end points in the planning. In order to solve the problem with

51

8.2 Evaluation of the terminal logic

several buses wanting the same bus stop at the same time, the bus with its end destination atthe terminal is moved in time. The bus’ arrival at the terminal is moved to occur earlier thanaccording to the planning. This is due to the assumption of a buffer and the fact that the bus isusually early according to the real time updating system used by Ostgotatrafiken.

The simulation does not provide one specific numerical value to answer the research questionregarding capacity. This is mainly due to capacity being difficult to define and determine, sincethere are many aspects to consider. The analysis that can be made of the capacity at Norrkopingbus terminal consists of several measures that together describes the capacity in form of how wellthe terminal operates.

8.2 Evaluation of the terminal logic

An analysis of the terminal logic is performed in order to answer the first research question pre-sented in Chapter 1.2. Purpose and research questions and evaluate Vissim as a tool for busterminal investigations. Both advantages and disadvantages with the terminal logic has beendiscovered, which will be analysed in this chapter.

The main advantage with the terminal logic is that it provides the possibility to simulate busterminals in an event based way, using micro simulation. As mentioned, the combination of eventbased and time based simulation enables capturing real behaviour at the bus terminal. Severalactivities at the terminal can occur in the same time step and are activated based on time controlledby events. Using queues and treating the buses as packages makes it possible to send buses betweenthe queues based on events instead of time. This can be considered as an advantage with theconcept behind the terminal logic rather than an advantage with the terminal logic implementedin Vissim and VisVap. Using Vissim and VisVap can also be seen as an advantage since Vissim isa commercial software and provides useful animations. Hence, both the concept itself and the useof Vissim and VisVap can be seen as advantages. The concept, the terminal logic, might be usefulin some other software as well.

The usage of Vissim and VisVap have both advantages and disadvantages. As mentioned, Vissimis commercial so it is fairly easy to access. The fact that Vissim has VisVap as an additionalprogram enables the vehicle actuated part of the terminal logic. VisVap is created to be used forsignal control in Vissim, but it is possible to use signal control for other purposes than traditionalsignalized intersections. When implementing the terminal logic, the signal control is used to holdbuses at events. Using the program for other purposes than what is intended can create difficulties.For example, many controls are required to make sure that only one bus passes the signal headduring green time, something that would not be needed at an intersection. The general terminallogic needs to be adjusted to the terminal that is being studied, which can be another difficulty.Several modifications need to be done both in Vissim and VisVap in order to create a representativesystem. Some adjustments are easier than other, for example building the layout of the network inVissim so it represents the chosen terminal. Other changes are more complex, both in Vissim andin VisVap. In Vissim, it was difficult to implement the routes between the queues since all queueswith a decision of a new route needed to be possible to revisit. Vissim requires that all possibleroutes are predefined and VisVap requires equal dimensions between decision of new route and endpoints for the routes. VisVap is sensitive regarding the implementation of data and it is importantwith dimensions of arrays and counters ending when the arrays ends.

The terminal logic is good to use for testing a specific scenario with a known planning regardingthe buses’ movements within the terminal. All entrance and exit times together with the purposeof visit needs to be implemented individually for all created buses. Moreover, the terminal logic islimited when wanting to test alternative volumes like increasing the frequency with 50 %. All thenew events due to the increased frequency need to be added manually to the input data, which istime-consuming and the new events may not be easy to plan in a realistic way. If the planning ofthe bus movements within the terminal is known in detail, it is easy to use the terminal logic andfollow the bus movements to verify a correct behaviour.

52

8 DISCUSSION

Overall, the used method contributes when evaluating the capacity at Norrkoping bus terminal.Therefore, the method terminal logic is considered effective for this kind of evaluations despite itsdrawbacks during implementation. For an experienced user the implementation would probablynot be so time-consuming and the drawbacks with the method can have less impact on the work.

53

9 CONCLUSION AND FURTHER RESEARCH

9 Conclusion and further research

This chapter answers the research questions presented in Chapter 1.2. Purpose and research ques-tions, it also underlines the conclusions and contribution of the thesis. Furthermore, some proposalsfor further research are given.

9.1 Conclusion

Simulation is a useful tool when evaluating capacity, due to difficulties when analysing utilizationover time using analytical methods. A combination of time and event based simulation is necessaryin order to capture movements at a terminal realistically. In this thesis, a method using bothtime and event based simulation, the terminal logic, has been investigated and implemented atNorrkoping bus terminal. This was done in order to evaluate the terminal logic and investigatehow the provided logic could be adjusted to Norrkoping bus terminal. The thesis has showed thatit is possible to implement the terminal logic to Norrkoping bus terminal and use it to evaluatethe capacity. By implementing and using the terminal logic, it has been possible to establish theexistence of overcapacity at the terminal. It has also been possible to show that the planning canoperate with fewer bus stops, which confirms that the terminal could be functional on a smallerarea. The current planning, when several buses departs at the same time, leads to congestion anddelays when all buses are supposed to exit the terminal. Since the road outside the terminal isfrequently used, it takes longer time than necessary for the buses to exit. With a more optimisedplanning, more overcapacity would probably be discovered which strengthen the argument thatthe terminal could operate on a smaller area.

Implementing the terminal logic illustrated the possibility to use Vissim as a tool for bus terminalevaluations. It is possible to use Vissim for this kind of evaluations due to the combination of timeand event based simulation. The combination was provided by using both Vissim and VisVap.Since Vissim is a micro simulation software, it provides a high level of detail which makes it possibleto follow individual buses in the network. The high level of detail also simplifies verification andvalidation of the behaviour.

The terminal logic is useful to capture movements within a terminal and thereby evaluate thecapacity. It is time-consuming to perform changes and adjust the terminal logic to terminals withdifferent designs. Hence, the terminal logic might be more useful to evaluate capacity of a specificcase than to use it to compare several scenarios with each other.

The contribution of this thesis is an evaluation of a method using time and event based microsimu-lation to evaluate the capacity of bus terminals. The method, the terminal logic, has been evaluatedin several ways which together makes the contribution of the thesis. One part of the evaluation wasto document the terminal logic and its functions. The terminal logic was adjusted and implementedfor Norrkoping bus terminal which made it possible to analyse and document the required adjust-ments. The literature review regarding research within the area of using simulation to evaluatecapacity of bus terminals, showed the importance of this thesis and the terminal logic. Simulationis an appropriate tool to evaluate capacity at terminals and the combination of time and eventis necessary to capture the movements. Hence, the contribution can be seen as: documenting,implementing on a real case and analysing the method in relation to existing research.

9.2 Further research

Further research can be both to improve existing functions and add new functions to the logic.The improvements are possible both for the general terminal logic and for the terminal logicimplemented at Norrkoping bus terminal.

In the given terminal logic, the buses need to reserve their desired queues. It would be a good ideato add the possibility of not reserving queues as an option to use in the logic. Reserving is necessaryfor some bus terminal designs, for example the angle berth design where reversed movements arenecessary. If buses were to wait behind it would not be possible for the first bus to leave the busstop, different bus terminal designs are illustrated in Chapter 2.4. Design alternatives.

55

9.2 Further research

The terminal logic implemented at Norrkoping bus terminal can be improved in several ways. Aproblem with the logic that was detected for scenario two, is that congestion is created when twobuses wants to use the same bus stop at once and at the same time other buses wants to pass touse other bus stops further ahead. Often other bus stops were available and therefore it would beuseful if the buses had more than one bus stop as an alternative. As mentioned when discussingthe reserve function, the queue with the lowest number is first detected and since the logic doesnot check if it is available the buses are assigned this queue. A desired improvement would be toenable buses to use more than one bus stop but still not need to reserve queues.

The behaviour at Norrkoping bus terminal could have been more accurate if the data collectionwould be improved. One improvement would be retrieving the entire planning data from theoperators with all bus movements. Another way to improve the data would be to perform alicense plate survey, which is presented in Chapter 4.3. Required data. The planning would providethe planned behaviour at the terminal while the license plate survey would capture the actualbehaviour.

Further work can also be to use the terminal logic to evaluate other design alternatives forNorrkoping bus terminal. Then, it is important to consider the time required to perform theevaluations. Since it is time consuming to adjust the terminal logic. It can also be interesting totake other perspectives into account when analysing the results form the simulations. For example,the bus operators can be interested in the number of kilometres driven at the terminal.

56

REFERENCES

References

B. Adhvaryu. Design of bus station: a case study of brighton. Traffic Engineering and Control, 47(5):182, 2006.

A. Al-Mudhaffar, A. Nissan, and K.-L. Bang. Bus stop and bus terminal capacity. TransportationResearch Procedia, 14:1762–1771, 2016.

A. Allstrom, J. J. Olstam, and T. Thorsson. Analys av modeller for berakning av framkomligheti korsningar, 2008.

J. Archer. Indicators for traffic safety assessment and prediction and their application in micro-simulation modelling: A study of urban and suburban intersections. PhD thesis, KTH, 2005.

E. Axelsson and T. Wilson. Microscopic simulation as an evaluation tool for the road safety ofvulnerable road users, 2016.

J. Barcelo et al. Fundamentals of traffic simulation, volume 145. Springer, 2010.

P. Brinckerhoff. Geometric design guide for transit facilities on highways and streets–phase i,interim guide, 2002. URL http://design.transportation.org/Documents/Chapter5.pdf.

K.-L. Bang, J. Olstam, J. Kohler, J. Wahlstedt, J. Andersson, and A. Tapani. Handbok forkapacitetsanalys med hjalp av simulering, 2014.

R. Dowling, P. J. Holland, and P. A. Huang. California department of transportation guidelinesfor applying traffic microsimulation modeling software. way, 3:3–2, 2002.

R. Fernandez. Modelling public transport stops by microscopic simulation. Transportation ResearchPart C: Emerging Technologies, 18(6):856–868, 2010.

R. Fernandez and R. Planzer. On the capacity of bus transit systems. Transport Reviews, 22(3):267–293, 2002.

R. Fernandez, C. E. Cortes, and V. Burgos. Microscopic simulation of transit operations: policystudies with the mistransit application programming interface. Transportation Planning andTechnology, 33(2):157–176, 2010.

Google maps, 2017. URL https://www.google.se/maps/place/Norrk\unhbox\voidb@x\

bgroup\accent127o\penalty\@M\hskip\z@skip\egroupping. [Online; accessed 24 April 2017].

W. D. Kelton, R. Sadowski, and N. Zupick. Simulation with ARENA. McGraw-Hill Education,2015.

D. Kramer. simulation based evaluation of public transport stop designs, 2013.

T. Lindberg, A. Peterson, and A. Tapani. A simulation model of local public transport accessat a railway station. In 7th International Conference on Railway Operations Modelling andAnalysis (RailLille2017), Lille, April 4-7, N. Tomii, I.A. Hansen, J. Rodriguez, P. Pellegrini,S. Dauzere-Peres, D. De Almeida (eds), pages 922–943, 2017.

Next:Norrkoping. Butangen och nytt resecentrum, n.d. URL http://next.norrkoping.se/

butangen/. [Online; accessed 17 April 2017].

Nykopings kommun. Ostlanken, n.d. URL http://nykoping.se/Bo-bygga-och-miljo/

Stadsplanering-och-byggprojekt/Ostlanken/#. [Online; accessed 17 April 2017].

J. Natterlund and S. Thomasson. Resecentrum i ideskedet underlag till handbok for tidig planeringav resecentrum och bussterminaler. B.S. thesis, Chalmers University of Technology, 2011.

J. Olstam. A model for simulation and generation of surrounding vehicles in driving simulators.PhD thesis, Institutionen for teknik och naturvetenskap, 2005.

J. J. Olstam and A. Tapani. Comparison of car-following models. Technical report, 2004.

57

REFERENCES

Ostlanken. Ostlanken nykoping-Ostgotalanken ab, n.d. URL http://www.ostlanken.se/hem.[Online; accessed 17 April 2017].

PTV GROUP. Ptv vissim 7 user manual. Germany: PTV GROUP, 2014.

H. Rakha, B. Hellinga, M. Van Aerde, and W. Perez. Systematic verification, validation andcalibration of traffic simulation models. In 75th Annual Meeting of the Transportation ResearchBoard, Washington, DC, 1996.

S. Robinson. Simulation: the practice of model development and use. Palgrave Macmillan, 2014.

SL. Riterm -09 riktlinjer for utformning, 2009. URL http://b2b.sl.se/Global/Pdf/Rapporter/

riktlinjer_for_utformning_av_bussterminaler.pdf. [Online; accessed 2 February 2017].

Sveriges kommuner och landsting. Kol-trast: Planeringshandbok for en attraktiv och effektivkollektivtrafik. [elektronisk resurs], 2012. ISBN 978-91-7164-842-6.

Sveriges kommuner och landsting. Trafik for en attraktiv stad: Underlag, utgava 3. [elektroniskresurs], 2015. ISBN 978-91-7585-275-1.

Trafikanalysforum. Analytiska trafikmodeller, n.d. URL http://www.trafikanalysforum.se/

analytiska-trafikmodeller. [Online; accessed 20 February 2017].

Trafikverket. Stationshandbok [Elektronisk resurs]. Borlange, 2013. ISBN 978-91-7467-474-7.

Trafikverket. Where the future begins, 2014. URL http://www.trafikverket.se/

contentassets/f6898301b7384fbe988ae505382252f6/ostlanken_engelsk_folder_2014.

pdf. [Online; accessed 30 January 2017].

TransLink. Public transport infrastructure manual, 2016. URL https://

publications.qld.gov.au/dataset/495a8be2-9658-4965-90c8-de0506b0c886/resource/

754c26a4-2e22-42ff-8fe6-3814dfd38bf4/download/ptimallparts.pdf. [Online; accessed30 January 2017].

Transportation Research Board National Research Council. Highway capacity manual. TRB Busi-ness Office, 2000.

M. Treiber and A. Kesting. Traffic flow dynamics. Traffic Flow Dynamics: Data, Models andSimulation, Springer-Verlag Berlin Heidelberg, 2013.

TSS-Transport Simulation Systems, 2017. URL https://www.aimsun.com/aimsun/. [Online;accessed 3 May 2017].

58