UPTECSTS11033
Examensarbete 30 hp April 2011
A Framework for How to Make Use of an Automatic Passenger Counting System
John Fihn
Johan Finndahl
Teknisk- naturvetenskaplig fakultet UTH-enheten
Besöksadress:
Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0
Postadress:
Box 536 751 21 Uppsala
Telefon:
018 – 471 30 03
Telefax:
018 – 471 30 00
Hemsida:
http://www.teknat.uu.se/student
Abstract
A Framework for How to Make Use of an Automatic Passenger Counting System
John Fihn & Johan Finndahl
Most of the modern cities are today facing tremendous traffic congestions, which is a consequence of an increasing usage of private motor vehicles in the cities. Public transport plays a crucial role to reduce this traffic, but to be an attractive alternative to the use of private motor vehicles the public transport needs to provide services that suit the citizens requirements for travelling.
A system that can provide transit agencies with rapid feedback about the usage of their transport network is the Automatic Passenger Counting (APC) system, a system that registers the number of passengers boarding and alighting a vehicle. Knowledge about the passengers travel behaviour can be used by transit agencies to adapt and improve their services to satisfy the requirements, but to achieve this knowledge transit agencies needs to know how to use an APC system.
This thesis investigates how a transit agency can make use of an APC system. The research has taken place in Melbourne where Yarra Trams, operator of the tram network, now are putting effort in how to utilise the APC system. A theoretical framework based on theories about Knowledge Discovery from Data, System Development, and Human Computer Interaction, is built, tested, and evaluated in a case study at Yarra Trams.
The case study resulted in a software system that can process and model Yarra Tram's APC data. The result of the research is a proposal of a framework consisting of different steps and events that can be used as a guide for a transit agency that wants to make use of an APC system.
Sponsor: Yarra Trams & RMIT ISSN: 1650-8319, UPTEC STS08 000 Examinator: Elísabet Andrésdóttir Ämnesgranskare: Arnold Pears
Handledare: Georges Couenon & Margaret Hamilton
Popul¨arvetenskaplig beskrivning
En v¨axande befolkningsm¨angd och ett ¨okat anv¨andande av privata motorfordon har lett till att de flesta moderna st¨ader idag har allvarliga problem med trafikstockningar, ett problem som p˚averkar b˚ade milj ¨on och ekonomin negativt. F ¨or att minska mo- tortrafiken i st¨aderna och eliminera trafikstockningarna beh ¨over fler m¨anniskor re- sa kollektivt. Detta f ¨oruts¨atter att kollektivtrafiken ¨ar ett attraktivt alternativ till att anv¨anda privata motorfordon. Kollektivtrafiken beh ¨over uppfylla m¨anniskors behov av r ¨orlighet och anpassas efter deras resebehov inne i st¨aderna.
F ¨or att kunna anpassa tj¨anster inom kollektivtrafiken efter det behov som finns, beh ¨ovs information om hur passagerare anv¨ander kollektivtrafiken. Operat ¨orerna beh ¨over snabbt och st¨andigt ˚aterkoppling p˚a passagerares behov f ¨or att dynamiskt kunna an- passa tj¨anster inom kollektivtrafiken. Ett system som automatiskt kan r¨akna antalet passagerare ¨ar det som p˚a engelska ben¨amns Automatic Passenger Counting (APC) system. Genom sensorer monterade ovanf ¨or d ¨orrarna p˚a ett fordon kan ett APC-system registrera antalet passagerare som stiger p˚a och av fordonet.
Datan som samlas in av ett APC-system m˚aste dock lagras och behandlas innan den kan omvandlas till information som kan vara anv¨andbar f ¨or operat ¨oren. Detta ¨ar en omfattande process och erfarenheter fr˚an organisationer som tidigare implementerat och anv¨ant sig av APC-system visar p˚a komplexitet vad det g¨aller att omvandla data fr˚an APC-systemet till anv¨andbar information. Det har ¨aven visat sig att organisatoris- ka faktorer haft en betydande p˚averkan p˚a huruvida operat ¨oren lyckats anv¨anda sig av APC-systemen. Det finns i dagsl¨aget ingen guide eller ramverk f ¨or hur en organisa- tion kan g˚a tillv¨aga f ¨or att anv¨anda sig av ett APC-system. Detta examensarbete syftar d¨arf ¨or till att ta fram ett ramverk som kan anv¨andas som en guide f ¨or en organisation som vill anv¨anda sig av ett APC-system.
En organisation som nyligen b ¨orjade implementera APC-system och som idag arbetar med att g ¨ora dessa system anv¨andbara ¨ar Yarra Trams, operat ¨or av sp˚arvagnstrafiken i Melbourne, Australien. Detta examensarbete ¨ar utf ¨ort i Melbourne och som en del av arbetet har en fallstudie utf ¨orts hos Yarra Trams. Ett teoretiskt ramverk har byggts upp av relevanta teorier, d¨ar valet av teorier baserats p˚a olika organisationers erfarenheter av APC system. De teorier som varit i fokus ber ¨or hantering av data, systemutveckling samt m¨anniska- datorinteraktion. Det teoretiska ramverket har testats i fallstudien hos Yarra Trams och utv¨arderats genom att analysera resultaten och erfarenheterna utifr˚an teorin.
Resultatet av studien ¨ar ett ramverk best˚aende av olika steg och riktlinjer som kan anv¨andas av en organisation som vill b ¨orja anv¨anda sig av ett APC-system. Del av resultatet ¨ar ocks˚a en mjukvaruapplikation anpassad f ¨or Yarra Trams som de kan anv¨anda f ¨or att omvandla data fr˚an APC-systemen till anv¨andbar information.
Acknowledgement
This thesis is the result of a masters degree project on the Master of Science in So- ciotechnical Systems Engineering Program at Uppsala University. The project has been performed in Melbourne and has been carried out by the authors of this thesis.
First, we want to thank Arnold Pears, our subject reviewer at Uppsala University, that introduced us to Margaret Hamilton, our supervisor at Royal Melbourne Institute of Technology. This was the very first seed of our project. Further, we want to thank Margaret Hamilton, that let us be part of RMIT and helped us with all practical things around the project. We also want to thank Georges Couenon, our supervisor at Yarra Trams, that contributed with his knowledge and critically reviewed our work. They have all given us valuable feedback on our work. We also want to thank the staff, both at Yarra Trams and RMIT, that supported and encouraged us in our work.
Finally, we want to thank our families for all their support.
Thank you!
John Fihn and Johan Finndahl Uppsala April 26, 2011
Contents
Glossary 7
1 Introduction 8
1.1 Problem Formulation . . . 8
1.2 Research Objective . . . 9
1.3 Research Approach . . . 9
1.4 Limitations . . . 9
2 Theoretical Background 11 2.1 Automatic Passenger Counting Systems . . . 11
2.1.1 Integration with an Automatic Vehicle Location System . . . 12
2.1.2 APC data . . . 13
2.2 Knowledge Discovery from Data . . . 14
2.3 Cross Industry Standard Process for Data Mining . . . 14
2.4 Software System . . . 15
2.4.1 Software Development . . . 16
2.5 Sociotechnical Systems . . . 16
3 Methodology 18 3.1 Structure of the Research . . . 18
3.2 Information Gathering . . . 19
3.3 Operationalisation . . . 20
4 Theoretical Framework 23 4.1 Business Understanding . . . 23
4.1.1 Establish Objectives and Functionality of the Software System . . 23
4.2 Data Understanding . . . 24
4.2.1 Design of the Software System . . . 25
4.3 Data Preparation . . . 25
4.3.1 Develop Software System for Data Preparation . . . 26
4.4 Modelling . . . 26
4.4.1 Develop Software System for Modelling . . . 27
4.5 Evaluation . . . 28
4.5.1 Evaluate Software System . . . 28
4.6 Deployment . . . 29
5 Case Study 30
5.1 Business Understanding . . . 30
5.1.1 The Automatic Passenger Counting System Project . . . 31
5.1.2 The Automatic Passenger Counting System . . . 32
5.1.3 Software System for APC Data . . . 34
5.2 Data Understanding . . . 35
5.2.1 Design of the New Software System . . . 39
5.3 Data Preparation . . . 40
5.4 Modelling . . . 42
5.4.1 Home . . . 43
5.4.2 View Data . . . 44
5.4.3 Reports . . . 47
5.5 Evaluation . . . 50
5.5.1 The Prototype Software System . . . 50
6 Analysis 52 6.1 Business Understanding . . . 52
6.2 Data Understanding . . . 54
6.3 Data Preparation . . . 55
6.4 Modelling . . . 56
6.5 Evaluation . . . 57
7 Conclusions 58 7.1 Future Research . . . 60
Bibliography 62 Appendix 65 A Requirements 65 A.1 Forward Traceability . . . 65
Functional . . . 65
Non Functional . . . 68
A.2 Backward Traceability . . . 69
List of Figures
2.1 APC system components . . . 12
2.2 CRISP-DM model . . . 15
3.1 Theoretical framework . . . 21
5.1 Actors within public transport in Melbourne . . . 31
5.2 Yarra Trams information systems . . . 33
5.3 Explanation of run and trips . . . 36
5.4 Prototype software system design . . . 39
5.5 Screenshot of Home 1 . . . 43
5.6 Screenshot of Home 2 . . . 43
5.7 Screenshot of View Data 1 . . . 44
5.8 Screenshot of View Data 2 . . . 44
5.9 Screenshot of View Data 3 . . . 45
5.10 Screenshot of View Data 4 . . . 46
5.11 Screenshot of View Data 5 . . . 46
5.12 Screenshot of View Data 6 . . . 47
5.13 Screenshot of Reports 1 . . . 47
5.14 Screenshot of Reports 2 . . . 48
5.15 Screenshot of Reports 3 . . . 48
5.16 Screenshot of a report exported to Excel . . . 49
List of Tables
2.1 APC/AVL data sample . . . 135.1 Fictive APC data sample with errors . . . 37
5.2 Explanation of the headers in table 5.1 . . . 37
Glossary
APC
Automatic Passenger Counting system, a system used in public transport for counting passengers boarding and alighting a vehicle.
AVL
Automatic Vehicle Location system, a system used in public transport that iden- tifies a vehicles position.
AVM
Automatic Vehicle Monitoring system, a system used in public transport for monitoring a vehicle in service.
CRISP-DM
CRoss Industry Standard Process for Data Mining, methodology for knowledge discovery from data projects.
DoT
Department of Transportation, coordinates all public transport in the state of Victoria in Australia.
ITS
Intelligent Transportation System, the umbrella term for information technolo- gies like APC, AVL and AVM systems that is used in public transport.
KDD
Knowledge Discovery from Data, process for extracting information from large data sets.
KDR
Operates the tram network in Melbourne under the name of Yarra Trams.
Metlink
A partnership of Melbourne’s train, tram and bus operators.
Route
A collection of stops that is served by a vehicle, a route starts with a terminus and end with another terminus.
Run
A collection of planned trips for a certain vehicle.
Trip
A vehicles journey from one terminus to another terminus where it serves certain stops along the way, usually on one route.
UCD
Data Control Unit, an onboard computer for an APC system that receives and stores data.
Chapter 1
Introduction
Cities around the world have grown with an incredible speed during the last century and more than half of the human population are today living in urban areas. This coupled with an increasing ownership in the number of motor vehicles has meant that most of the modern cities are facing tremendous traffic congestions. This urbanisation trend is not expected to stop in the near future, instead the situation is anticipated to get worse and more widespread. Traffic congestion is a high cost for both the economy and the environment, and has become a major problem in our society. To alleviate the traffic congestion in the cities more people need to be able and willing to travel on public transport; the lifeline of today’s modern cities.
The public transport must be an attractive alternative to using private vehicles. It must meet peoples’ requirements for mobility and suit their travel behaviour. Since urban areas are dynamic, the public transport has to be managed in the same way. For dynamic traffic management, it is important to get rapid feedback from the network and to understand the entire transit system. Increasing demands on public transport put pressure on transit agencies to improve their operations and services. New in- formation technology such as Intelligent Transportation Systems (ITS) can be used to meet higher demands on public transport. One ITS technology with the potential to improve operations and services within public transport is the Automatic Passenger Counting (APC) system. The APC system counts passengers alighting and boarding a vehicle, and can be used to get knowledge about the passengers’ journey. With this knowledge it is possible to understand the demands and make adjustments for the future, but several steps must be taken before the knowledge can be obtained and decisions made.
1.1 Problem Formulation
A study from the Transportation Research Board (2008) emphasises the complexity of getting knowledge from an APC system. It indicates that the main issues are as- sociated with the preparation and modelling of the data from the APC system, and that a processing and reporting software is essential. This is not the whole problem and a software system is not sufficient to get complete knowledge. The complexity of
knowledge discovery from the data is broader. Another study from the Transportation Research Board (2006) points out that the APC system poses numerous organisational challenges, and Gonzalez-Aranda et al. (2008) find the underlaying problem in knowl- edge discovery projects as a lack of methodology.
One transit agency currently dealing with the complexity of an APC system is Yarra Trams in Melbourne, Australia. Melbourne has the world’s largest tram network with 250 km of track, almost 500 tram vehicles, and with around 180 million passenger trips taken each year. Up to 80% of the tram network share the road space with other vehicles like cars (Yarra Trams, 2009b). Yarra Trams has recently started to investigate the feasibility with the APC system in the tram network and are now putting a lot of effort in how to utilise the APC system.
1.2 Research Objective
The purpose of the research for this thesis is to propose a framework for how a transit agency can make use of an APC system.
1.3 Research Approach
The research will be approached by the following steps:
• Build a Framework
A framework will be built based on theoretical studies concerning characteristics identified in the problem formulation.
• Test the Framework
The framework will be tested by applying it in a case study at Yarra Trams to find out how it can be used to provide Yarra Trams with useful information from the APC system.
• Analyse the Framework
Using the results of the case study, the framework will be analysed to make con- clusions about how a transit agency can apply the framework to make use of an APC system.
1.4 Limitations
This research aims to propose a framework for how a transit agency can make use of an APC system. This framework is tested for one transit agency, and concerns one spe- cific organisation. This organisation only operates tram vehicles and the framework
will thereby only be tested for conditions in this specific environment. This implies that different conditions can appear when an organisation operates other vehicles in another environment. However, this research focus on problems that can be seen as general for a transit agency that intends to utilise an APC system. The research will not cover details that are specific for Yarra Trams only. System development will be a major component of this research, but since the software solutions are customised for Yarra Trams and may not suit the general case, code and documentation in full will not be presented. Due to the time frame for this research, it will not be possible to confirm whether Yarra Trams can improve future operations and services by applying the proposed framework.
Chapter 2
Theoretical Background
This chapter describes Automatic Passenger Counting (APC) systems and relevant Intelligent Transportation Systems (ITS) within public transportation. After this, the chapter introduces theoretical concepts that are relevant for this research and gives a background to chapter four, in which the theoretical framework is composed. The process for obtaining knowledge from data is introduced and the role that software development plays in the process is outlined. Finally the relationship between technology and humans is defined.
2.1 Automatic Passenger Counting Systems
APC systems are used to count passengers in public transport. There exist different APC technologies and they can be divided into two categories: static and on-board systems. The static systems are installed in stations and the on-board systems are em- bedded in vehicles. In technical terms the on-board APC system is a module installed inside a vehicle and a central computer in an office used for storage of the APC data.
The on-board module consists of sensors and an on-board computer that converts and stores the information registered by the sensors into passenger counts. An on-board APC system is shown in Figure 2.1. The most common technique for counting in APC systems is infra-red (IR) sensing. Other techniques used are: pressure-sensitive mats, horizontal beams and cameras. The IR sensors are mounted above each door and are only active to register passengers boarding and alighting when the doors are open.
The stored counts are transferred from the on-board computer to the central computer at a regular time for storage. Most analysis of APC data requires a moderate data sample, which can be met with APC systems installed on 10-15 % of a transit agency’s total vehicle fleet (Furth, Hemily, Muller and Strathman, 2006, p. 6; 18; 21).
Figure 2.1: The figure shows an onboard APC system components and how they are connected.
2.1.1 Integration with an Automatic Vehicle Location System
Some of the usual ITS and technologies within public transportation are: Automatic Vehicle Location (AVL) systems, Geographical Information Systems (GIS), Passen- ger Information Systems (PIS), and Automated Fare Payment systems (Ubaka and Glotzbach, 2006, p. 2-4). An APC system can be integrated with other ITS, which makes the data outcomes richer. The most common is to integrate an APC system with an AVL system (Furth et al., 2006, p. 3).
An AVL system determines the vehicles position at a certain time by the use of ei- ther the Global Positioning System (GPS) or an odometer (Saavedra, 2010, p. 2). De- pending on which level of intensity of position data that is needed, there are different techniques to collect data. The most common is to get polling records or stop records.
Polling records is when a central computer continuously requests a vehicle’s position, which mainly is used for getting a high frequency of data points like real-time infor- mation. Stop records provides the position of a vehicle and the time when it arrives at certain stops, this is the type of record that is used when an AVL system is integrated with an APC system (Furth et al., 2006, p. 17-19). An example of a data record from an APC system integrated with the time and stop location from an AVL system is shown in Table 2.1. The table shows the number of passengers boarding (Ins) and alighting (Outs) the vehicle during the time period from 7:06:47 until 7:36:59. This vehicle makes 10 stops during this time with a total of 48 passengers boarding and 48 alighting. The vehicle arrives from a previous trip at the terminus 7:06:47, starts a new trip 7:07:12
and arrives at the end terminus of that trip at 7:36:46. A new trip starts 7:36:59.
Arr Time Dep Time Stop Ins Outs Route Number
7:06:47 7:07:12 1 28 0 55
7:13:48 7:14:36 2 4 0 55
7:14:52 7:15:05 3 4 4 55
7:19:13 7:19:22 4 1 1 55
7:20:20 7:20:34 5 0 15 55
7:25:17 7:25:28 6 6 4 55
7:27:07 7:27:16 7 0 2 55
7:32:49 7:35:16 8 3 6 55
7:35:51 7:36:17 9 2 8 55
7:36:46 7:36:59 10 0 8 55
Total 48 48
Table 2.1: This table shows an APC/AVL data sample from a central computer.
APC data combined with AVL data are richer and can be used to analyse delays, pas- sengers waiting time, and passenger load on a vehicle. The data can also be analysed by looking at average load and waiting time to better understand how customers ex- perience the services. This is useful to improve scheduling and customer services.
Integrated APC/AVL data is a better base for analysis with aim to alleviate traffic con- gestions. One common problem with an integration is the matching between AVL and APC data, often due to bad quality in the data (Furth et al., 2006, p. 2; 19-20; 25-28).
2.1.2 APC data
The accuracy of an APC system can vary and the data are affected by various type of errors. When it comes to error handling it is necessary to distinguish between sys- tematic and random errors. Systematic errors occurs when an APC system constantly counts incorrectly, which can be predictable after the errors have been identified. Ran- dom errors are harder to identify since they occur randomly. To be able to identify all the errors it is important to validate the APC system by comparing “actual” counts with the counts registered by the APC system. The most common method for collect- ing the “actual” counts is to manually count passengers. It is important to understand that the manual counts also can contain errors, but it is necessary to represent reality as accurate as possible to be able to validate the APC system. A valid APC system counts passengers with an accuracy of ≥ 95%, which is measured by combining the error for one trip of boarding and alighting passengers. Since the accuracy of an APC system is not perfect it is necessary for the APC data to undergo statistical processing (Iris-GmbH Infrared & Intelligent Sensors, 2005). Statistical processing is especially important to apply before calculating the load of a vehicle, as errors tend to accumu- late when aggregating the counts (Furth et al., 2006, p. 55).
The total number of passengers that has boarded a vehicle during a trip must be equal to the total number of passenger that has alighted the vehicle during a trip. This means
that the load of a vehicle is supposed to be zero at the end of a trip. In some cases the load calculated from the APC data is not equal to zero at the end of a trip, which usually depends on systematic errors in the APC system. Due to this, the data have to be corrected (Furth et al., 2006, p. 5-6; 54-55).
2.2 Knowledge Discovery from Data
Knowledge Discovery from Data (KDD) is a process used to discover and presen infor- mation from data to achieve knowledge. KDD is usually associated with Data Mining, since both terms refers to information extraction from data. A way of separating the two terms is to use Data Mining to describe a class of methods based on statistics, mathematics, and artificial intelligence that can be used to extract information from data. KDD describes the whole knowledge discovery process (Han and Kamber, 2006, p. 7). Data Mining is with this view a step within the KDD process, where algorithms and techniques are executed with the aim to explore and extract hidden patterns from data to achieve knowledge (Fayad, Grinstein and Wierse, 2002, p. 278; 300).
2.3 Cross Industry Standard Process for Data Mining
CRoss Industry Standard Process for Data Mining (CRISP-DM) is another process for discovering and presenting information from data. It was developed during the late nineties by a consortium of representatives from different companies active within the Data Mining area. CRISP-DM does not just describe a class of statistical methods, it de- scribes the life cycle of a knowledge discovery from data project and is both applicable in general and at a more specific level (Chapman, Clinton, Kerber, Khabaza, Reinartz, Sharer and Wirth, 2000, p. 3-4; 9; 13-14). The different phases in the CRISP-DM process are presented below and in Figure 2.2.
• Business Understanding
The first phase aims to give an understanding of the business and the purpose of the KDD project. This phase builds the foundation for the upcoming phases.
• Data Understanding
The data understanding phase aims to give an understanding of the data and to identify data quality issues.
• Data Preparation
The data preparation phase aims to make sure that the data are of the right qual- ity before it can be used.
• Modelling
In the modelling phase various modelling techniques are applied on the data to extract information and knowledge.
• Evaluation
The evaluation phase is performed to make sure that the outcomes after mod- elling the data achieves the business objectives.
• Deployment
The deployment phase is performed when the modelling of the data satisfies both the business requirements and the purpose of the project. In this phase the developed model is implemented in the organisation.
Figure 2.2: The CRoss Industry Standard Process for Data Mining (CRISP-DM) model.
The arrows indicate in which order the steps are supposed to be performed. In some cases it can be necessary to go back to previous step, for example when working with Data Understanding it can be necessary to go back to Business Understanding. The outer arrow means that even if the project is deployed it must be maintained and remain dynamic (Chapman et al., 2000, p. 3-4; 9; 13-14).
2.4 Software System
To manage and analyse large amount of data it is essential to have a software system.
A software system is a set of instructions that when executed on a computer provides the user of the software system with functions. (Agarwal, Tayal and Gupta, 2008, p. 4) It is possible to acquire a software system by either buying or developing a solution.
When acquiring a solution it is important that the solution can fulfil the organisation’s
requirements for the software system. If the requirements cannot be fulfilled by a bought solution it is preferable to develop a customised solution (Krishnamurthy and Saran, 2008, p. 155-158). A customised solution can on the other hand put higher expectations on the organisation, as it requires a higher level of expertise in software development (Furth et al., 2006, p. 7).
2.4.1 Software Development
There are many different ways of developing a software system. If the general objec- tive for the system is defined but the requirements for functionalities are less detailed, it is preferable to begin developing a prototype system(Agarwal et al., 2008, p. 41). A prototype system is an initial version of a software system that is used to demonstrate concepts, try out design options, and find out more about the problem and the possi- ble solutions for the real system. An acknowledged benefit of prototypes is that stake- holders and decision makers can experiment with the system and thereby get a better understanding for the final system. This reduces and gives a better control of the costs and involves the users more closely with the design of the system (Sommerville, 2011, p. 45). A prototype is not supposed to be a fully functional system. After the proto- type has been developed it can either be discarded or re-used for the formation of the real system (Krishnamurthy and Saran, 2008, p. 132-134). The prototype development can be performed in four steps (Sommerville, 2011, p. 45-46):
• Establish prototype objectives
In the first step the objectives of the prototype are declared.
• Define prototype functionality
In the second step the functionalities of the prototype are decided.
• Develop prototype
When the objectives and functionalities are determined, the prototype can be developed.
• Evaluate prototype
In the last step the prototype is evaluated and the requirements are refined for continuing with the prototype or to start the development of the real system.
2.5 Sociotechnical Systems
The term Sociotechnical Systems (STS) was originally created in the context of organ- isational development and work design. It was introduced in 1960 as a result of the insight that organisational outcomes are affected by both social and technical factors.
The new concept challenged the technology determinism, which saw the technology as autonomous and something humans needed adapt to (Mat and Silva, 2005, p. viii).
The new comprehension was that an organisation consists of both social and techni- cal systems. The humans in the organisation represents the social system, and the tools and techniques they are using represents the technical system. Those two sys- tems are not independent and must be seen and managed as one system (Griffith and Dougherty, 2002, p. 205). The accumulation of computers at the workplace led to new views and extensions of the STS area. One growing field that considers the STS per- spective is Human Computer Interaction (HCI), which attempts to understand and improve the interaction between human and computers (Mat and Silva, 2005, p. ix).
Chapter 3
Methodology
This chapter describes the methodology behind the research of this thesis. It gives a background of the research and explains how the theoretical framework was shaped and why. This chap- ter declares how the theoretical framework has been applied in the case study, and how the information has been collected.
3.1 Structure of the Research
The research has been carried out by the authors of this thesis. It has been a part of one of Yarra Trams ongoing projects that undertakes a feasibility study to determine the viability of introducing an Automatic Passenger Counting (APC) system on the tram network in Melbourne. Feedback to the research have come from the supervisors and the subject reviewer of this thesis.
The initial step in the research was to become familiar with Yarra Trams ongoing APC project. To understand the APC project it was necessary to first study Yarra Trams organisation and their operations and services. Thereafter it was possible to study the APC project, and identify which departments within the organisation that was in- volved in the APC project. A deeper study about APC systems was performed with the aim to get an insight into the complexity of an APC system, and to understand the role of the APC project within Yarra Trams organisation. By this, a better understand- ing of the research was achieved. After the initial step, it was possible to understand how the objectives of the thesis could be approached, and a literature study of the rele- vant fields began. The theoretical framework was shaped from the knowledge gained during the literature study.
With the objectives of the thesis in mind and the theoretical framework as a guide, the case study started. Since this research aims to result in a framework that can be applied in general APC projects, a case study approach was chosen to get an in-depth understanding for a real life phenomenon and the contextual conditions. The case study followed the structure of the theoretical framework were each phase consisted of different events.
A software system was developed as part of the case study. This system development was part of the framework and was performed solely by the authors of this thesis. The development could have been performed with more involvement from the stakehold- ers and been more iterative. Requirements for the software system could have been reviewed by all stakeholders. The reason it was not performed this way was a lack of resources and planning.
In the two last phases of the framework, the result from the APC project are supposed to be evaluated and deployed. The evaluation phase could not be performed in full and was only based on feedback from the project manager, which means that feedback from the different departments and users are not included in the report. The coverage of fulfilled requirements compared with gathered and prioritised requirements was considered when the result from the project was evaluated. Because of the status of the project and the timeframe for this research, it has not been possible to perform the deployment phase. The final step of the research was to analyse the theoretical framework from the results of the case study.
Another part of the case study was a manual validation survey of an APC system on a new tram type, which was performed by Yarra Trams with the assistance from the authors of this thesis.
3.2 Information Gathering
The empirical information for this research was collected during the case study at Yarra Trams. The case study was designed to collect information about Yarra Trams as an organisation and not the involved individuals, as the research aims to describe how an organisation can make use of an APC system. Multiple sources of information was chosen and used during the case study to get a better and complete understanding of the case.
• Interviews
Interviews were chosen as the main source of information with the aim to get a better understanding for the organisation. Focus interviews are preferable when there is a need for open-ended conversations. If there is a need for more detailed information it is good to perform in-depth interviews (Yin, 2008, p. 107). Be- cause of the complexity of the APC project it was hard to know all the questions in forehand, focus interviews were therefore performed during several meetings at Yarra Trams office. Beside the focus interviews, two in-depth interviews were performed with an Market Analyst and an Research Analyst from the Market- ing Department at Yarra Trams. The purpose of the in-depth interviews was to gather requirements for the software system. The in-depth interview approach was chosen because more detailed information about their requirements on a software tool was needed, whereas it was possible to collect requirements from the other departments through documents and focus interviews.
• Documents
To corroborate and complement the information from a case study it is important to use organisation specific documents (Yin, 2008, p. 103). Documents from Yarra Trams related to the case study were the second main source of information and was used to provide the case study with complementary information.
• Physical Artefacts
Another source of information was physical artefacts in terms of data collected by different IT systems at Yarra Trams. This information was essential, as the understanding for the data that Yarra Trams collects was an important part of the case study.
• Participant-Observation
The last source of information was collected with the participant-observation approach, which is when the observer assumes a role and participates in the situation that is being studied (Yin, 2008, p. 112). This was done during a survey together with Yarra Trams. The purpose of the survey was to validate a newly installed APC system, which implied to manually count all the passengers that boarded and alighted a tram during several trips. This was done to get a better understanding of Yarra Trams services and the APC technology, as well as to understand the difficulty of counting passengers.
3.3 Operationalisation
There is no guide for how an organisation should tackle the entire process when they want to make use of an APC system. The goal of this thesis is therefore to propose a framework, which can be used as a guide when an organisation want to make use of an APC system. To approach the research it was important to first get knowledge about the nature of the problems related to an APC system. Only with this knowledge it was possible to know how to tackle the problem. This knowledge was achieved by studying transit agencies’ experiences from earlier APC projects. With this insight it became clear that the APC project has a close relation to the process of Knowledge Discovery from Data (KDD), since the task of an APC system is to collect data and the organisation’s desire is to make use of that data. Research about the KDD process proved to give a better understanding for the characteristics of a knowledge discovery project.
Two other processes considering knowledge discovery from data were also identified:
CRoss Industry Standard Process for Data Mining (CRISP-DM), and Sample Explore Modify Modelling Assess (SEMMA) process. When comparing KDD, CRISP-DM and SEMMA, it was CRISP-DM that was the most complete and suitable process for this research. The reason was because CRISP-DM has a wider perspective and takes or- ganisational factors into consideration. CRISP-DM has been adopted with success by various industry companies, which also had an affect on the decision to apply it in this research.
It is important to be aware of that CRISP-DM is a methodology for knowledge dis- covery projects, and not specifically adapted for an APC project. This means that CRISP-DM does not focus on specific problems related to an APC system. CRISP- DM was therefore determined to only be used as the base in the framework for this research. Knowing the problems associated with an APC system and the complex- ity of knowledge discovery projects, served as encouragement to add new theory on the foundation of CRISP-DM. The theory that has been used from CRISP-DM is the process structure. The process structure consist of six different phases, each phase representing one step in the process of a knowledge discovery project. The core of each phase has been reused and complemented with additional theory about system development, KDD, Data Mining, Human Computer Interaction (HCI), and STS.
As a software system proved to be an essential component to make use of an APC system, theory about system development was added. One important aspect when developing a software system, especially when the system will mediate complex in- formation, is the interaction between the user and the system. Previous research con- firms that human interaction is an essential part to successfully discover knowledge from data and that visualisation can bring benefits when modelling the data (Fayad et al., 2002, p. 191). The HCI field has complemented the framework with aspects about the design of the interface of the software system.
It has been shown that many factors affect the outcomes of an APC project and hard- ware, software, and personnel issues have to be identified and resolved (Boyle, 2008, p. 4). The interaction between technical and social factors must be taken into consid- eration and theory from the field of STS was therefore added in the framework.
The framework consist of the same six phases as CRISP-DM, but each phase has two layers. The bottom layer includes theory from KDD, Data Mining and STS, and is the foundation in each phase. The top layer represent aspects regarding the software system including HCI, which is an important part and has to be built upon the foun- dation. The first phase in the framework is Business Understanding and the process continue in the order that the arrows indicate. The framework is illustrated in Figure 3.1. Each box in the figure represents a phase in the process of making use of an APC system.
Figure 3.1: The theoretical framework.
Findings from earlier APC studies indicates a need for identification of factors that can prevent or ensure success in APC projects. There is a need for examination of success- ful strategies of how to make use of APC systems. (Boyle, 2008, p. 4) By applying the theoretical framework and evaluating the result, it was possible to tell whether it was successful or not to apply the framework. The framework was applied in a case study and the factors that affected the result were identified and analysed. The framework aims to serve as a guide for how an organisation can make use of an APC system.
Chapter 4
Theoretical Framework
This chapter describes the theoretical framework, each section representing one phase in the framework. Every section is divided into two parts; one part explaining the fundamentals of the phase, and the other part focusing on the software system.
4.1 Business Understanding
The initial phase in the process to make use of an APC system is to understand the business objectives. This is a fundamental step that has to be performed before defin- ing the objectives of the APC project. Information about the business and its primary objective has to be gathered and understood. This needs to be done to clarify what the business should accomplish with the APC project. The business requirements for the APC project might differ, but the essential is that they all reflects the business objec- tives. When the business requirements are established it is possible to determine the objectives of the APC project. With a clear objectives it is possible to get an overview of the resources needed for the project in terms of personnel, finances, data, comput- ing resources, and software systems (Chapman et al., 2000, p. 13-19; 38). According to Gonzales-Aranda et al. (2008) the most critical factor to successfully extract and pro- vide an organisation with valuable information is to get a clear understanding of the business.
4.1.1 Establish Objectives and Functionality of the Software System
When the project objectives are clear they have to be considered as a foundation on which the objectives and functionalities of the software system needs to be based on.
To determine the objectives and functionalities it is necessary to clarify the system requirements. This work is divided into following steps (Agarwal et al., 2008, p. 54- 57):
• Requirement Gathering
The system requirements need to be gathered from the stakeholders. This has to be a communication process that involves both developers and stakeholders, since all must agree on and understand the requirements. The system require- ments has to be in line with the the business requirements (Krishnamurthy and Saran, 2008, p. 59-61).
• Requirement Analysis
All system requirements are analysed to confirm their relevance to the goal and objectives of the APC project. Requirements have to be prioritised and classi- fied into the categories: functional and non-functional. Functional requirements define functionality and behaviour of the system. Non-functional requirements specifies criteria regarding the property of the system (Agarwal et al., 2008, p.
54-57).
• Requirement Documentation
The system requirements need to be documented in both a natural language, without technical terms, and a detailed technical specification, including the user requirements translated into system requirements in technical terms. This spec- ification usually includes links between the requirements so it is possible to fol- low their relations (Sommerville, 2011, p. 96).
• Requirement Review
Requirement review is a manual process where both stakeholders and devel- opers confirm that the documented requirements does not contain anomalies (Agarwal et al., 2008, p. 58-59).
• Requirement Management
After the requirements have been reviewed and agreed it is important that they are managed, in case of changes. If any changes in the requirements are agreed and reviewed, they must be controlled (Agarwal et al., 2008, p. 58-59).
When a prototype system is preferable for the APC project, the prototype objectives and functionality needs to reflect the system requirements that has been prioritised in the requirement analysis step. The prototype system is not supposed to fulfil all the system requirements (Sommerville, 2011, p. 45-46).
4.2 Data Understanding
The data understanding phase aims to give an understanding for all data that are in- volved in the APC project. Without insight in the data it is hard to know which knowl- edge that can be extracted from the data. It is important that the process is adopted in an interactive way, and in this phase the concerned people within the project needs to interact with the data to better understand the property and quality of the data (Han and Kamber, 2006, p. 36). It is initially important to get an overview of the data and
confirm that all data needed to satisfy the business requirements are represented. Be- fore proceeding in the process, a deeper understanding for the quality and format of the data must be reached. The quality of the data must be verified, which includes awareness of completeness and errors (Chapman et al., 2000, p. 13-14; 21-22).
4.2.1 Design of the Software System
While an understanding for the data increases and the functionality for the prototype system has been determined, the work with the prototype system design can begin (Sommerville, 2011, p. 46). The system design declares the practical implementation and involves decision making about technologies, modules, and components for the system. The design of the system must cover all aspects related to the required func- tionality (Furth et al., 2006, p. 80). The IT environment in the organisation, with exist- ing systems and skills, has an impact on the options when it comes to system design (Krishnamurthy and Saran, 2008, p. 45; 94-95).
It is the understanding of the business and the requirements on the software system that will guide the design of the database. The database design clarifies the structure of how the data is going to be stored (Davidson, 2008, p. 3). A relational database is to prefer since it is constructed to store data records in different tables, and bind information that belong together. Each table consists of a set of unique columns to separate the different information within the data, this is also known as data attributes (Davidson, 2008, p. 7-11).
4.3 Data Preparation
Before the data are suitable to be modelled it must be of the right quality and format.
To success with data preparation it is of great importance that the previous phase has given a complete picture of the data. In this phase the issues identified in the data understanding phase have to be arranged. This usually implies to correct data, integrate data from different sources, transform or reduce data. The data preparation is divided into the following steps (Chapman et al., 2000, p. 24-25) (Han and Kamber, 2006, p. 37; 48-51; 61-62; 67-72):
• Select Data
The data with identified issues have to be selected.
• Clean Data
The second step is to fix quality problems in the data, which involves differ- ent techniques and algorithms depending on the quality problem. Missing val- ues can be fixed by either adding constants for representing an unknown value, adding the most probable value, or adding the mean value of the existing values for that attribute.
• Construct Data
Depending on how the data are going to be modelled, it can be necessary to transform or complement the data with new attributes. It can also be necessary to aggregate or normalise data.
• Integrate Data
In this step, datasets that needs to be integrated are combined and merged to new datasets. As different departments within the organisation can use differ- ent ways to describe items, and the same values can be stored in different data sets, issues like redundancy, inconsistency, and conflicts between values must be identified and arranged. It can be necessary to go back one step with the com- bined dataset.
• Format Data
The final step is to make sure that the data have the right format. This can in- clude changing order in the dataset or more syntactic changes such as removing characters or trimming data values.
4.3.1 Develop Software System for Data Preparation
Data preparation can be done manually but as that is a non-effective and time-consuming method, a software system is essential to prepare vast amount of data (Han and Kam- ber, 2006, p. 61-62). The software system is shaped based on the system design, created during the Data Understanding phase.
The selected data can be stored in a database or databases. Thereafter algorithms for both the cleaning and the construction steps can be developed and applied. In the integration step the software system can access, merge, and store data from different sources. When the dataset is stored the reformatting can be done by applying algo- rithms (Han and Kamber, 2006, p. 37; 48-51; 61-62; 67-72).
4.4 Modelling
When all data are prepared it is possible to model the data. The purpose of modelling the data is either to describe or predict situations. Algorithms and techniques to model the data are chosen based on the business objectives (Witten and Frank, 2005, p. 83).
To get deeper insight and knowledge about some phenomena, analytical methods can be applied on the data (Haluzov, 2008, p. 24).
4.4.1 Develop Software System for Modelling
Beside the software system used for preparing data, it is important to have a software system that can model and visualise the data for the organisation. The formula of how to model the data are derived from the system requirements (Chapman et al., 2000, p.
27). When modelling the data it is important to consider representation, interaction, and integration. The user should be able to interact with the model see it in a context (Fayad et al., 2002, p. 212).
As the outcomes from the modelling usually support decision making, the software system must be accurate and reliable, and present the output in a clear and well- explained way. The software system should improve the users’ task performance and reduce their effort. This can sometimes mean that there has to be a trade-off between a systems functionality and usability. There must be a fit between the information needed and presented, which put a high demand on communication between devel- opers and users. The software system should be designed for an enjoyable and satisfy- ing interaction and represent the real-world, so it provides affordance to capture real- world knowledge. The richness of the visualisation, interactivity, and adaptability of the interface affect the users experience of the system (Te’ eni, Carey and Zhang, 2007, p. 32; 197-201; 240-243).
The information gained from modelling the data is not sufficient to obtain knowl- edge. Visualisation is the graphical communication of information, which plays a cru- cial role in helping the users understand the information and get knowledge (Fayad et al., 2002, p. 6, 23). Visualisation requires a well organised interface with ordered placement, regular patterns, consistent forms, and a balanced distribution of white space and elements on the screen. The idea is to make it easier for the user to un- derstand unfamiliar and abstract things, otherwise it might be hard to get a complete picture of the entire data set and understand the relations within it (Te’ eni et al., 2007, p. 208) (Fayad et al., 2002, p. 88). It is important to present the information with the user in mind. The requirements and the perceptual capabilities of the user must be considered. (Fayad et al., 2002, p. 21; 206) A good way to succeed with this is to in- volve the user in the development of the software system and design the interface in iterations (Sommerville, 2011, p.45). Guidelines for the design of the user interface are presented below (Te’ eni et al., 2007, p. 208; 258-287):
• Colour is effective when designing an interface, but it has to be used with care and conservation. The usage of different colours is a good way to call attention to specific information, differentiating information types, and grouping similarity.
Symbolic colours should be used in a way so it reflects its meaning.
• Objects should be represented so the user can interact with them in a way that is related to reality.
• When it comes to data input it is effective to provide the user with predetermined values, but only if the values are known and if they are few. One rule is to
minimise the users effort to fill in data, but when the user needs to fill in data, the user should be guided by information about expected values.
• Graphs are powerful communicators for quantitative information to summarise data, show trends, show relationships in data, and show deviations. All this is useful to support decision making.
.
A common way to communicate the knowledge gained from the data to the organ- isation is to use reports. The reports can be designed and delivered by the software system and has to be approached with the same rules as the design of the user interface (Krishnamurthy and Saran, 2008, p. 259).
4.5 Evaluation
When the data have been modelled, the outcomes are a base for the evaluation. The outcomes have to be compared with the business requirements and the purpose of the project (Chapman et al., 2000, p. 14). The outcomes have to be evaluated from a broader perspective and can only be fully understood if social, psychological, environ- mental, and technological systems are evaluated as a whole (Griffith and Dougherty, 2002, p. 205). After the outcomes have been understood and the entire process is evaluated, the next step has to be decided. It can either be to deploy the results from the APC project or to move back in the process to be able to improve the outcomes (Chapman et al., 2000, p. 60).
4.5.1 Evaluate Software System
To decide if the prototype is going to be discarded or re-used for development of the real system, it has to be evaluated (Krishnamurthy and Saran, 2008, p. 134). The prototype evaluation should be done by the prototype objectives in mind and not the objectives for the whole APC project. It is important that the evaluation is given the time needed so the users can learn how to use the system before feedback is given (Sommerville, 2011, p. 46). The feedback should be a guide for future design and development of the system (Te’ eni et al., 2007, p. 135).
After the evaluation is done, the next step has to be decided. It can either be to start de- veloping the real system or to go back in the process and continue with the prototype.
(Agarwal et al., 2008, p. 42)
4.6 Deployment
When a decision to deploy the outcomes from the project has been taken it needs to be implemented in the organisation. A strategy for the deployment must exist and it is important that the gained knowledge extracted from the data becomes part of the day-to-day business (Chapman et al., 2000, p. 32-33). The deployment involves installing the real software system, transferring data from existing system, establishing communications with other systems, and maintenance of the software system. During this step it is also important to prepare user documentation and training (Sommerville, 2011, p. 281).
Chapter 5
Case Study
In this chapter the performed case study at Yarra Trams is described. The case study was performed and structured based on the phases in the theoretical framework. Each section in the chapter represents one phase of the framework and explains how the framework was applied.
5.1 Business Understanding
The Victorian State Government under the Department of Transport (DoT) coordinates all public transport in the state of Victoria, where the capital city is Melbourne (The De- partment of Transport, 2011a). To promote public transport in Melbourne, there exist a partnership named Metlink between all tram, train, and bus operators in Melbourne.
The responsibilities of the partnership is to provide customers with information and services, and to instigate research in order to improve public transport (Metlink, n.d.).
The partnership has a joint solution for fare collection were the same smart card can be used for paying on trams, trains, and buses.
All tram services in Melbourne’s tram network are today operated under the trad- ing name Yarra Trams, owned by the Victorian State Government (Yarra Trams, n.d.).
The operator of Yarra Trams is responsible for operation of trams, customer service, management of staff, and maintenance of vehicles, tracks, and stations. The current operator of Yarra Trams is KDR, a consortium consisting of Keolis and Downer EDI Rail. KDR is contracted by the Government since 2009. The partnership is initially agreed for eight years, with the possibility for another seven years of extension (The Department of Transport, 2011b). The relation between the actors in Melbournes pub- lic transport are shown in Figure 5.1.
The motto of KDR is to ”think like a passenger”. This means to see things from the passengers perspective. Only by this approach KDR can offer the best service at ev- ery stage of a journey. KDR thinks that informed passengers use the network more efficient and strive to provide the passengers with information they need to make the right choices (KDR, 2011).
Figure 5.1: Actors within public transport in Melbourne.
5.1.1 The Automatic Passenger Counting System Project
Under the franchise agreement in 2009, Yarra Trams committed with the DoT to under- take a feasibility study to determine the viability of introducing Automatic Passenger Counting (APC) systems on trams. APC systems were already installed on 9 trams when the agreement was conducted. Yarra Trams has been through several APC trials during the last 30 years. Different technologies have been tested on single trams, but Yarra Trams has chosen not to go any further than the test phase, due to accuracy and technical issues. It was not until 2008 that APC technology was installed on multiple trams and left continuously in operations. The goal with the APC system is to establish more reliable data of the passenger usage on the tram network to assist Yarra Trams organisation in service, planning, tram procurement, and rationalisation of tram stops.
This data aims also to provide Metlink and DoT with better and more accurate infor- mation about the passenger usage of the trams in Melbourne (Yarra Trams, 2010, p.
2; 9-10). Currently there is a manual patronage survey twice a year that collects data about the passenger usage of the tram network (Yarra Trams, 2009a). This informa- tion serves as decision basis for the fundings Yarra Trams receives from DoT for their operations (Couenon, 2010).
The objective of the APC project is to find out how to make use of the APC system.
The stakeholders in the APC project within Yarra Trams are the Operations, Marketing, Maintenance, and IT departments. The Operation department is in charge of planning and analysis of the tram services, and management of traffic offences. The Marketing department is responsible for growing the patronage and revenue of Yarra Trams as well as improving the overall customer experience. The IT department is responsible for the development and maintenance of Yarra Trams information systems. The Main- tenance department is responsible for maintaining the tram vehicles and the tram net- work. Whereas the Operations and Marketing departments are interested in the APC
system for improving planning and services, the Maintenance and IT departments are responsible for the APC on a hardware and software level (Yarra Trams, 2009a).
The following main business requirements were identified (Yarra Trams, 2009a):
• The Marketing department needs to provide management with quantitative in- formation about the usage of the tram network.
• The Operations department needs information about the load on the tram vehi- cles as base for changes in the timetable and fleet allocation.
• The IT department needs the APC system and its components to be compatible with the existing IT environment, both on a hardware and software level.
• The Maintenance department needs information about the status of the APC sys- tem.
To fulfil these requirements it is not possible to rely on data from the ticketing system since it only shows how many passengers that validate their ticket. Because of the smart card system, a passenger does not need to validate their ticket when changing from one to another vehicle. Another problem with using data from the ticketing system is that it does not contain information about the amount of joyriders (Couenon, 2010).
5.1.2 The Automatic Passenger Counting System
Yarra Trams has a total of 487 tram vehicles in their fleet, which consists of 8 different types of tram vehicles (Yarra Trams, 2009b). Yarra Trams has tested and approved the APC system on 3 different types of tram vehicles, where the latest tram type was validated in the end of 2010. Before the tram type gets approved the data from the APC system must be validated. It gets approved only if the average accuracy is greater than 95%. There is today a total of 10 trams equipped with APC systems in operation, which represents 2% of their tram fleet. If the APC system would be installed on all trams of the type that has been approved, the APC system would cover 230 trams, 47% of Yarra Trams fleet (Couenon, 2010).
The supplier of the APC systems is the French company Acorel. The selection of this company was based on Acorel’s previous successful experiences with APC systems on other tram networks. (Yarra Trams, 2010, p. 12-13) Acorel supplies both hardware and software for APC systems, where the hardware is the physical counting system that is installed in each tram vehicle, and the software is a data analysis tool to be used in the office by the organisation. Yarra Trams has tested the software tool and chosen not to acquire it, because it is not suitable for their organisation (Couenon, 2010).
Yarra Trams information systems related to the APC system are shown and described in Figure 5.2.
Figure 5.2: Yarra Trams information systems related to the APC system.
• Automatic Passenger Counting (APC) System The APC system consists of IR sensors built into the tram roof above each door, an onboard computer named UCD (Data Concentration Unit), and a central computer for the APC system at Yarra Trams office. Each IR sensor uses a combination of dual active and passive IR sensing. The active sensing consist of two IR light curtains to be reflected by the passengers as they board or alight and gets registered by the sensor. The pas- sive sensing is used to detect the thermal energy emitted by passengers (Yarra Trams, 2010, p. 40)(Acorel, 2010). The IR sensors are coupled with door switches and are only active to register the passengers boarding and alighting when the doors are open. Each sensor is connected to the UCD, and the registrations are transferred to the UCD and converted and stored as counts. All counts are stamped with additional information from the AVL system, such as time, stop location, route, vehicle number, and service number. Once a day, the onboard data are transferred to a central computer at Yarra Trams office. This is done by General Packet Radio Service (GPRS) technology through a modem. When the central computer retrieves the data it generates Comma- Separated Value (CSV) files and stores them in a database (Yarra Trams, 2009a) (Couenon, 2010).
• Automatic Vehicle Monitoring (AVM) System
This system is used for monitoring and communication with trams in service.
AVM collects realtime data about the trams from the AVL system and stores it in a database (Yarra Trams, 2009a).
• Automatic Vehicle Location (AVL) System
This is a positioning system that provides information about a tram’s position.
The position is based on coordinates from the Global Positioning System (GPS) and a distance measured by the odometer on the tram (Yarra Trams, 2009a).
When the tram is surrounded by tall buildings it can be problematic to get the correct GPS coordinates. The AVL then uses the odometer to estimate the po- sition based on how far it has travelled. The AVL system receives information about which service a tram operates from the AVM system (Yarra Trams, 2009c) (Couenon, 2010).
• Hastus
This is a system used for scheduling of tram services. Hastus gets offline feed- back from the AVM system on how well actual services fitted with the scheduled services (Couenon, 2010).
• Tram Tracker
This is a prediction system that predicts when a tram is going to serve a specific stop. The predictions are based on realtime data from AVM and offline scheduled data from Hastus. Each stop in the tram network has an unique number, which are stored in a database (Yarra Trams, 2009a).
• Maximo
This is an asset management system used to keep track on information about a tram vehicle. The system gets information from the AVM system and it can include the status of a vehicle. Based on this, the system generates work orders for maintenance (Couenon, 2010).
5.1.3 Software System for APC Data
To make use of the data collected by the APC system, it is for Yarra Trams necessary to have a software system (Couenon, 2010). The different needs for a software sys- tem that was agreed after communication between stakeholders, developers, and the project manager are summarised below. The requirements that were prioritised for the prototype system by the project manager are marked in bold (Yarra Trams, 2009a) (Chabas, 2010) (Holmes, 2010) (Couenon, 2010) (McRobbie, 2010). General function- ality are prioritised before specific functionality, and functionality less resource de- manding with high relevance for the business are also prioritised. For the complete document over the software requirements that were confirmed, classified, and priori- tised after being analysed, see appendix A.
• System requirements from both Marketing and Operations:
– Provide information about which tram stops that serves the most passen- gers.
– Provide information extraction for alighting, boarding, and passenger load, by filtering of date, time, route, stop, vehicle, and run/trip.
– Provide visualisation in form of graphs to the extracted information.
– Provide a comparison between the actual load of a route with the load ca- pacity for that route.
• System requirements from both Marketing and Maintenance:
– Provide the quality of the data to see accuracy and track the status of the APC system.
• System requirements from Marketing:
– Provide extracted information to be exported into different formats.
– Provide information in reports with data and graphs, generated by the software tool.
– Provide the coverage of the actual data sample compared to the total data sample.
• System requirements from Operations:
– Provide a forecast of the future passenger load on the tram network.
– Provide information about service punctuality according to the scheduled time.
• System requirements from IT:
– Be accessible for all users through a web based user interface.
– Be developed in the Microsft .NET platform.
5.2 Data Understanding
The tram network that Yarra Trams operates consists of almost 1800 unique stops, which are served by 28 routes. All routes have one up and one down direction with different stops. Yarra Trams is planning the tram services in “runs”, where one run represents the schedule for one tram. The run schedule declares at which time the tram is in service and which route it operates. One run consists of several trips, were
Figure 5.3: One run consisting of six trips taken by one tram.
one trip represents a tram’s journey from a start terminus to an end terminus of a route (Couenon, 2010). The relation between run and trips is illustrated in Figure 5.3.
Yarra Trams approved APC systems count passengers with a maximum error of±5%
for each sensor per stop. This means that the total error on one stop can contain a larger error than±5% when the data from all sensors are summarised (Yarra Trams, 2009a).
It is only when the average error is calculated for a longer time period that the total error is within±5% per stop (Yarra Trams, 2010).
The validation of the APC system that was conducted in the end of 2010 for a new tram type was done by comparing the counts from a manual survey with the counts from the APC system installed on that tram vehicle. The result from the validation showed that the total error of the installed APC system on stop level ranged from - 7% to +16%, and the average error for the whole validation survey was +3%. This means that the APC system is approved for the tram type as it is within ±5%, but a statistical approach of correction must still be taken before the data are useful (Yarra Trams, 2011).
Table 5.1 shows a fictive example of APC data merged with AVL data, representing one trip taken by one tram. The data in the selection represents some of the identified issues, which are described further down. Explanation of the headers in Table 5.1 can be found in Table 5.2.
Vehicle Time Stop Ins Outs Route Stop Type Direction Run
002122 9:04:48 0001 0 1 055 1 0 E007
002122 9:05:19 9999 2 1 055 0 2 E007
002122 9:07:42 0003 0 1 055 0 0 E007
002122 9:09:50 0004 2 0 055 0 0 E007
002122 9:10:19 0004 0 1 055 0 0 E007
002122 9:10:58 0004 0 0 055 0 0 E007
002122 9:12:20 0006 1 0 0 0 0 E007
002122 9:13:05 0007 0 1 055 0 0 0
002122 9:13:40 0008 0 1 055 0 0 E007
002122 9:17:02 0009 3 1 055 0 0 E007
002122 9:18:51 0010 1 0 067 0 0 E007
002122 9:21:08 0011 0 1 055 0 0 E007
002122 9:22:16 0012 0 1 055 0 0 E007
002122 9:22:51 0013 8 6 055 1 1 E007
Total: 17 15
Table 5.1: Fictive APC data sample with errors.
Name Description
Vehicle Tram identification number.
Time Time of arrival.
Stop Stop identification number.
Ins Number of passengers boarding the tram.
Outs Number of passengers alighting the tram.
Route Route identification number.
Stop Type Indicates whether it is a normal stop or a termi- nus stop. Stop Type = 0 is a normal stop and Stop Type = 1 is a terminus stop.
Direction Gives the direction of the trip. Direction = 0 is the up direction and Direction = 1 is the down direction.
Run Run identification number.
Table 5.2: Explanation of the headers in table 5.1.
The quality issues illustrated in Table 5.1 are described below:
• The sensors may fail to register passengers at stops. The sensors may also count passengers several times if they are standing in the doorway when the doors are opened. This results in a difference between the total Ins and Outs in the end of a trip.
• The APC system may not recognise at which stop the tram has stopped, this results in Stop = 9999.
