parking monitoring and management solution (pmms) · parking monitoring and management solution...

Parking Monitoring andManagement Solution (PMMS)

Hobi Livio,Hofstetter Fabian,

Liniger SamuelZürich, Switzerland

Student ID: 10-719-938, 09-917-337, 08-913-832

Supervisor: Christos Tsiaras, Dr. Thomas Bocek,Prof. Dr. Burkhard Stiller

Date of Submission: November 24, 2014

University of ZurichDepartment of Informatics (IFI)Binzmühlestrasse 14, CH-8050 Zürich, Switzerland ifi

MA

ST

ER

PR

OJE

CT

–C

omm

unic

atio

nS

yste

ms

Gro

up,P

rof.

Dr.

Bur

khar

dS

tille

r

Master ProjectCommunication Systems Group (CSG)Department of Informatics (IFI)University of ZurichBinzmühlestrasse 14, CH-8050 Zürich, SwitzerlandURL: http://www.csg.uzh.ch/

Zusammenfassung

Durch eine zunehmende Zahl von Autos ist das Finden eines Parkplatzes in Grossstadtrau-men fur viele Autofahrer auf der ganzen Welt eine tagliche Herausforderung. Autofahrer,die auf der Suche nach einem Parkplatz sind, mussen zu Stosszeiten vielfach herumfahren,bis sie einen freien Parkplatz finden. Dieser Prozess (a) kostet viel Zeit und Benzin, (b)generiert unnotige Verkehrslast und (c) beeinflusst die Umwelt negativ durch erhote Emis-sionen. Dieses Master Projekt entwickelte einen Prototypen einer Parking Monitoring andManagement Solution (PMMS), welche Daten uber verfugbare Parkplatze und deren Ta-rife innerhalb eines Gebietes sammelt und aufbereitet. Das Hauptmerkmal des Systems istdas Anzeigen von moglichen freien Parkplatzen auf einer Karte. Zusatzliche Funktionensind eine Schnittstelle zu Zahlungslosungen, Verlangern der Parkzeit, Erinnerung wo dasFahrzeug geparkt ist und Erinnerung wann die Parkzeit ablauft. Diese Funktionen solleneinen Anreiz schaffen, damit Benutzer die Applikation verwenden und mitwirken um dieVerfugbarkeit von Parkplatzen zeigen zu konnen.

Die Applikation ist plattformunabhangig. Die meist verbreiteten mobilen BetriebssystemeAndroid und iOS werden zur Zeit unterstutzt. Eine Erweiterung um Windows Mobilezu unterstutzen ist moglich, da das Multi-Plattform Framework Cordova [1] verwendetwurde. Des Weiteren zeigt das System lokale Park-Regulationen an, welche fur Benutzerdie mit den lokalen Regulationen nicht vertraut sind nutzlich sind. Die Applikation furden Endbenutzer ist mehrsprachig. PMMS bietet Benutzerkontos fur Parkplatzanbieter(engl. Parking Provider, PP) an, welches dem Monitoring von Parkplatzen dient, um zumBeispiel Bussen zu versenden. Diese Schnittstellen konnen von Behorden wie Polizei, oderprivaten Firmen, die Verantwortlich fur Parkplatze sind, genutzt werden.

Das PMMS wurde bezuglich der Effizienz der Suchzeit von Parkplatzen evaluiert. Eswurde eine Simulation durchgefuhrt, um die benotigte Zeit um einen Parkplatz zu findenmit dem System und ohne zu vergleichen. Zudem kann durch das vereinfachte Scannender Fahrzeuge die Kontrollzeit der Parkzonen erheblich beschleunigt werden.

Weiter wurde das System betreffend Energie- und Daten-Verbrauch evaluiert und ent-sprechend optimiert.

i

Abstract

Finding a parking space in urban areas is a daily challenge for drivers across the world,due to the increasing amount of cars. Drivers who are looking for a parking space in peakhours are often forced to drive around city blocks until they spot a free parking place. Thisprocess (a) costs a lot of time and gas for the drivers, (b) generates unnecessary trafficload and (c) affects the environment negatively due to increased emissions. This masterproject proposes the design and prototype of a Parking Monitoring and ManagementSolution (PMMS) that collects and processes data about available parking places andtheir tariffs within an area. The system requires input from driver’s smart phones. Thekey feature of the system is to deliver parking availability estimations on a map. Otherservices, such as interfaces to payment solutions, parking extension time, parking locationreminder, and parking expiration reminder are also provided as an incentive of the userto use the application and contribute on the parking availability system.

The mobile application is platform-independent, thus the major mobile Operating Sys-tems (OS) such as Android and iOS are supported. Currently, the mobile application hasbeen tested on Android and iOS. But the expansion to Windows Mobile is possible, be-cause of the usage of the multi-platform framework Cordova [1]. Furthermore, the systemaims to be used from drivers that are not familiar with parking-related regulations withina location. Thus, the PMMS is designed to handle multilingual interfaces concerning theUser Interface (UI) and information about parking regulations for a given area. Finally,the PMMS has Parking Provider (PP) accounts which will serve parking monitoring pur-poses, such as parking fine issuing when necessary. Those interfaces could possibly beused by authorities, such as police, or private companies that are responsible to monitorparking areas.

The PMMS has been evaluated by its efficiency in terms of the time needed to find a spot.Thus, a simulation was performed to compare the time searching a parking spot withoutthe application with the time using the PMMS. Moreover, the simplified and acceleratedscanning of the vehicles increases the efficiency of the parking controlling.

In addition, the PMMS was evaluated and if necessary optimized concerning energy-consumption and data-efficiency.

iii

Acknowledgments

We would like to thank Prof. Dr. Burkhard Stiller and the Communication SystemsGroup for providing this interesting Master Project. Thanks to Guilherme Machado, whohelped with the setup of the necessary infrastructure and Andri Lareida for the extensivetesting and the provided feedback.

Furthermore, we would like to thank the various friends and colleagues that helped ustranslating the parkITsmart application.

• Chinese: Zhongheng Chen

• Croatian: Marina Seric

• Danish: Elisabeth Hammer, Christos Tsiaras

• English: Burkhard Stiller

• French: Benedict Birrer, Sarina Hobi, Samuel Liniger

• Finnish: Aleksei Mazhelis, Mirja Pulkkinen, Marja Weisskopf, Michael Weisskopf

• Greek: Christos Tsiaras

• Indonesian Lisa Kristiana

• Italian: Nicoletta Salmeri

• Portuguese: Guilherme Sperb Machado, Vanessa de Azevedo Machado

• Romanian: Andrei Vancea

• Russian: Mark Fishel

• Slovakian: Tomas Ludrovan

• Spanish: Julia Breddermann, Ourania Nikolopoulou

Special thanks for the great supervision of Christos Tsiaras. Without the many e-mailsas well as advice from discussions at his office this project would not have been possible.

v

Contents

Zusammenfassung i

Abstract iii

Acknowledgments v

1 Introduction 1

1.1 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Description of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Related Work 5

2.1 Smart Parking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Infrastructure Based Solutions . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Crowdsourcing Approaches . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Mobile Parking Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 PMMS 9

3.1 Project Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Boundary Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Stakeholder Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

vii

viii CONTENTS

4 Architecture 17

4.1 Client-Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Architecture of the Implemented System . . . . . . . . . . . . . . . . . . . 17

4.3 Front-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3.1 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3.2 Framework Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.3 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.4 Back-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.1 Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.5 Inter-Component Communication . . . . . . . . . . . . . . . . . . . . . . . 22

4.5.1 JSON-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Design and Implementation 23

5.1 Controller Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 End-User Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3 Front-End Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.4 Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.4.1 Controller Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.4.2 End-User Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.4.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.5 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.5.1 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.5.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

CONTENTS ix

5.6 Additional supportive Work . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.6.1 RSS-Crawler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.6.2 Capture Spots Application . . . . . . . . . . . . . . . . . . . . . . . 34

5.6.3 Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.6.4 Parking Spot Generator . . . . . . . . . . . . . . . . . . . . . . . . 35

5.6.5 Integration of the Dataset Disabled Spots . . . . . . . . . . . . . . 35

5.7 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.8.1 Database Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Evaluation 37

6.1 End-User Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.1.1 Parking Space Utilization . . . . . . . . . . . . . . . . . . . . . . . 37

6.1.2 Data Usage Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2 Controlling Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2.1 Time Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2.2 Energy Efficiency and Data Usage . . . . . . . . . . . . . . . . . . . 43

7 Summary, Conclusions and Future Work 47

Bibliography 51

Abbreviations 55

Glossary 57

List of Figures 59

List of Tables 61

A Intellectual Property 65

B Installation Guidelines 67

C Contents of the CD 69

x CONTENTS

Chapter 1

Introduction

Finding a parking space in urban areas is a daily challenge for drivers across the world,due to the increasing amount of cars. Among of many different sorts of congestion like thestandard flow congestion, there are also many forms of parking-related congestion [6]. Thiscauses many undesirable problems such as environmental issues, air pollution, noise energyconsumption and parking space shortage [37]. A study conducted between 1927 and 2001in the central business districts of eleven cities on four continents came to the conclusionthat about 30% of the cars in the traffic jam are looking for a parking spot and theaverage time to find a curb space is eight minutes [39]. Summarized the process of findinga parking spot (a) costs a lot of time and gas for the drivers, (b) generates unnecessarytraffic load, and (c) affects the environment negatively due to increased emissions.

This work describes the process of designing and developing a prototype Parking Monitor-ing and Management Solution (PMMS) that collects and processes data about availableparking places and their tariffs within an area. The PMMS follows a crowd-sourced ap-proach where the system will require input from driver’s smart phones and from controllerauthorities. The key feature of the system is to deliver parking availability estimations ona map, based on the data provided by the users. Other services, such as payment solu-tions, parking extension time, parking location reminder and parking expiration reminderare prepared to provide an incentive to the user to use the application and contribute onthe parking availability system. The mobile application is platform-independent, thus themajor mobile Operating Systems (OS) such as Android and iOS are supported. Further-more, the system aims to be used from drivers that are not familiar with parking-relatedregulations of a location. Thus, the PMMS is designed to handle multilingual interfacesconcerning the User Interface (UI) and information about parking regulations for a givenarea. Finally, the PMMS has Parking Provider (PP) accounts that will serve parkingmonitoring purposes, such as parking fine issuing when necessary. Those interfaces canbe used by authorities, such as police, or private companies that are responsible to monitorparking areas.

1

2 CHAPTER 1. INTRODUCTION

1.1 Document Structure

The work is structured as follows: Chapter 2 provides information about related work withfocus on existing end-user applications concerning parking management in Switzerland.In Chapter 3, the whole PMMS eco-system is described. The subsequent chapters discussthe architecture (Chapter 4) and the design (Chapter 5) of the PMMS. In Chapter 6the results of the evaluation of the PMMS regarding to parking spot search time, dataconsumption and energy consumption with a strong focus on the PP’s application arediscussed. It also covers a simulation which shows the benefits of the PMMS in termsof parking space utilization and an estimation on efficiency improvements in parkingmonitoring and management. The work concludes with the Summary and Future work(Chapter 7) in the fields discussed within this work.

1.2 Motivation

Getting a reliable number of the amount of parking spots in city is a challenge that theSwiss City Zurich faces. In 2011 no up to date data were available [41]. However, thecity faces problems with low availability of parking spots and wants to raise the price foran effective utilization [45]. Nowadays it is worthwhile from a financial point of view tosearch a parking spot instead of parking the car in a carpak. Thus, it is proposed by thecity of Zurich to raise the price of parking spots to the level of carparks to avoid cruisingfor parking.

The use of smartphones has been increasing in the last few years [15], which openedmany possibilities to assist humans in every day life. Especially contracts for broadband access on mobile devices increased significantly in the last five years in Switzerland[7]. To overcome the parking problem new technologies such as smartphones can beused. For example to show parking availability and to guide drivers to free parking spots.The increase in broad band access on mobile devices brings up new possibilities such asdisplaying real-time parking data on mobile web maps like Google Maps [13].

There has already been a lot of effort put in this topics to find possible solutions to solvethe parking problem. However, either the approach is very expensive due to investmentsin necessary infrastructure [10][35][22] or the systems suffered from lack of use [12] andtherefore did not work because the needed data basis was not reached. The key goal ofthis work is the optimization of existing space by the use of modern technologies and byoffering a less cost intensive solution. PMMS does not need sensors but by the inputif a car is parked from the PMMS-user’s smart phones, unavailable parking spots canbe displayed. This helps to decrease the cruising for parking, because drivers would notdrive to places that are occupied. To overcome the problem of not having enough usersto collect data, information is also gathered from parking providers which control parkedcars. Thus, this work contributes with a new approach, proposing the involvement ofparking authorities.

1.3. DESCRIPTION OF WORK 3

1.3 Description of Work

This Master Project describes a solution to the parking management and monitoring. Itcovers the design, implementation and evaluation of a PMMS. This system facilitates anavailable parking prediction based on end-users’ announcements and controllers scanningof occupied parking spots. The Master Project puts an emphasis on three core items ofwork, (1) the end-users’ functionality/features, (2) the PP’s functionality/features, and(3) the administrator’s functionality/features.

4 CHAPTER 1. INTRODUCTION

Chapter 2

Related Work

This work is based on research interests in the field of smart parking and Internet ofThings (IoT). The following passages introduce related work in this domain. While in-frastructure based solutions (see Subsection 2.1.1) work with sensors on parking spots toget availability information, crowdsourcing approaches (see Subsection 2.1.2) profit frominformation gathered through the user base of the system. The proposed solution makesuse of existing approaches and shows (1) unavailable parking spots, (2) possible availableparking spots and (3) availability in car parks. To make use of unavailable parking spotsthe system should have information about the arriving and leaving time of a car. Thesetimes can either be gathered by crowdsourcing or estimated. Possible available parkingspots are a side effect of knowing which lots are occupied. Using availability in car parksand other private places improves such a system even further. Section 2.3 discusses thedifferences of the chosen approach to the here introduced ones.

2.1 Smart Parking

Todays technologies make it possible to collect updated real-time parking informationsuch as parking location, capacity, parking fee and current availability of different parkingfacilities, which can be used for a more intelligent parking guidance [37]. This can besummarized under the term “smart parking” that can be considered to be a subgroup of“smart cities” [11].

2.1.1 Infrastructure Based Solutions

There are many different approaches which face the parking problem and contribute tosmart parking. They vary in costs and also in necessary infrastructure. A more infrastruc-ture based approaches are following projects. (1) Deutsche Telekom is running a projectin the Italian city of Pisa together with Kiunsys where sensors on the floor of each parkingspot at the Piazza Carrara are placed. This sensors detect whether the spots are free oroccupied. The information is sent to the city’s server over the mobile network and then

5

6 CHAPTER 2. RELATED WORK

displayed on indication panels to guide drivers to free spaces [10]. There is also a mobileapplication that is guiding drivers to a free spot and can be used for paying the spotdirectly. (2) A similar approach with sensors is followed by SFpark in San Francisco.Again, parking spots are equipped with occupancy sensors. Additionally, the “parkingspot market” is regulated by demand-responsive pricing [35]. (3) ParkNet, is followingan infrastructure based approach as well. But in this case vehicles are equipped withultrasonic sensors to monitor parking availability when driving by [22]. All this solutionshave one major drawback: They are costly due to the required infrastructure.

2.1.2 Crowdsourcing Approaches

A possible way to deal with this issue are crowdsourcing based approaches. The user iscontributing to the system by sharing empty or occupied parking spot information. Themore user such a system has the more reliable the information gets. There are differentsolutions applying this approach, but none has been really successful by now. Google’sopen spot was launched in 2010 [12] but has not been successful because of insufficientusers which are needed to get reliable data [36].

2.2 Mobile Parking Platforms

In Switzerland there are currently two mobile parking-related platforms showing parkingspots to drivers, following a crowdsourcing based approach. ParkU is a solution to find orrent free and cheap parking spaces in the city. It consists of a online parking space marketwhere individuals but also companies can publish their parking spaces and earn money.The available parking spaces are displayed on the website or on the parkU smartphone appfor iPhone and Android [30]. Currently the Swiss cities Aarau, Basel, Bern, Geneva, Lau-sanne, Lucerne, St. Gallen and Zurich and the German cities Berlin, Dusseldorf, Hamburgand Munich are supported. The main features on the drivers’ side are (1) searching forparking spots, (2) booking a parking spot in advance or on the way, (3) payment withoutcoins (PayPal, MasterCard, Visa), (4) archive of already booked spots, (5) synchronizingbooked spots with calendar, (6) registration via facebook or parkU account, (7) possibilityto extend parking duration (if it is provided by the parking provider), (8) possibility tocancel booked spots. On supplier side there is the possibility to provide a parking spot toearn money. Time and duration is up to the provider. There is the possibility to uploada picture of the spot. 33% of the parking fee drawn in by parkU.

Beside these features the following weaknesses were identified:

• No routing to the parking spot

• Only private spots (companies, private persons)

• Inconsistent pricing

• Sometimes the spots are hard to find since they are private

2.3. DIFFERENCES 7

• No parking underground or behind gates

• Possibility that another car is parked on the booked spot

• Possible legal issues since some cities want to ban such apps

Another platform which is similar to parkU is park it [26], where private persons orparking providers can register to offer parking spots. These parking spots can be bookedwith the mobile application. The user can look at the availability of these spots togetherwith the addresses and the prices. The parking spots can be booked for certain time slots.Another feature is, that the app shows other parking spots or car parks with the address,the price and how many spots are available. There is also a navigation feature, showingthe route from the current position to the parking spot. Provision for park it that parkingproviders get is 35 % of the parking fee. Swiss Railway parking is a partner and thereforeit is possible to pay park and rail (P+rail) [34] spots with this platform. However, theparking spots can not be reserved before. Features and Functions of this application are:

• Book parking spots

• Registration with Facebook or parkit account

• Show other parking spots and car parks with the amount of free spots, price (onlyin some cases) and address

• Navigation to parking spot

• Possibility to register with Facebook account

• Possibility to book SBB P+Rail parking spots directly

• Show spots as list or on a map

• Live data of major swiss cities (Zurich, Luzern, St. Gallen, Basel, Bern, Winterthur,Lausanne, Geneva (Beta))

As of September 2014, park it was bought by the Swiss Federal Train (SBB CFF FSS)which integrated and rebranded park it as a new application only for parking spots neartrain stations.

2.3 Differences

The PMMS shows (1) unavailable parking spots, (2) possible available parking spotsand (3) availability in car parks. This is done following a crowdsourcing approach. Toovercome to problem of not having a large user data and thus no data about unavailablespots, the chosen approach makes use of input from the parking providers who have anincentive to control parking. Cars are controlled all the times. Therefore this informationcan be integrated into the PMMS to show unavailability. Furthermore the chosen approach

8 CHAPTER 2. RELATED WORK

integrates all available information about parking spots (i.e. availability in car parks orother public available datasets). The PMMS does not have any costly infrastructure. Itwould only provide the possibility to work with NFC-tags or QR-codes on cars to makethe controlling easier and more efficient for parking providers.

The described solutions, park it and parkU, are parking approaches for a minority of theparking spots in a city, since they just work with private parking respectively parkingspots of the Swiss Federal Train. They are therefore only partial solutions to the parkingproblem. Contrary, the PMMS uses data from different sources and integrates them tothe system to provide the users a single view of the parking situation in a given area.

Chapter 3

PMMS

This chapter describes the PMMS project in a high-level form. The project outline, bound-ary map, stakeholder analysis and risk analysis provide an introduction in the context ofthe project.

3.1 Project Outline

The overall goal of this master project is to design and prototype a Parking Monitoring andManagement Solution (PMMS) that collects and processes data about available parkingplaces and their tariffs. These informations are mainly based on input from PMMS-user‘ssmart phones. To overcome the problem of not having enough users to collect data,information is also gathered from the controlling application.In the context of this master project, parking data about existing parking spots and carparks were collected for the city of Zurich and Basel. Although, the system is designed ina generic approach to be implemented in different cities and countries.

Components The PMMS consists mainly of three components: End-User Application,Controller Application and Administrative functionality. The end-user application is forthe drivers who search a parking spot. Whereas, the controller application is for theparking provider to control parked cars. Finally, the administrative functionality is thebackbone of the PMMS where all the data is stored and the user management is handled.

Features The key feature of the PMMS is a parking availability estimation visualized ona map. Additionally, the systems provides a parking location reminder, parking extensiontime, and parking expiration reminder as an incentive for the user to use the applicationand contribute on the parking availability system.Furthermore, the system provides location-based regulations for different parking zonesto users that are not familiar with the parking regulation.

9

10 CHAPTER 3. PMMS

Project Management The project team of the PMMS project consisted of three stu-dents and one supervisor. The students as developers worked in close collaboration withthe supervisor. Because of the“proof-of-concept“-like project description, the project teamdecided to develop with agile software engineering methods. Small work-packages, weeklymeetings with the supervisors and daily (virtual) meetings of the developers enabled aflexible, fast and efficient development of the prototype.The project planning, work load distribution and collaboration of the development teamwas mainly done with the help of the collaboration platform Redmine [33].

Limitations There are some security concerns arising when developing a smartphoneapplication for car drivers. The development was done under the assumption that driverswho use the application act reasonably and do not use their mobile phone while driving.Furthermore, user search for a parking spot before departure.

3.2 Boundary Map

Research projects and especially proof-of-concept projects are in their nature never-ending. New questions appear as results are generated. Thus, defining the boundaries isan important step towards managing the collaboration‘s project.

“The boundaries of a project are measurable and auditable characteristics thatdefine what belongs to the project and what does not belong to it. Projectboundaries are closely linked to project objectives, they create a holistic per-ception of project work, and they define the content of the project in terms ofexpected results. A clear boundary statement helps direct the things that areapplicable to those areas within the project scope.“ [23]

For the PMMS Master Project, the boundary map that has been identified is illustratedin Figure 3.1. Any task that is out-of-scope, can become the starting point of either anew collaboration, or an extension of this collaboration for the future.

3.3 Stakeholder Analysis

This section aims to identify all possible stakeholders of a parking availability estimationsolution and draw a stakeholder‘s map. The purpose of the stakeholder analysis and thestakeholder‘s map is to (1) visualize the interest, (2) the influence and (3) the attitude ofeach stakeholder involved in the project.The first stakeholders are the Project Team Members (PTM). The interest of thisstakeholder group is very high as well as the influence on the project is essential high.Furthermore, this group has a positive attitude on the project.For any Future Investor (FI), the attitude depends on the quality of the preliminary

3.3. STAKEHOLDER ANALYSIS 11

In-scope Out-of-Scope

Evaluation of existing parking

toolsMarket-Analysis

Parking Availability estimation

Payment solution Implementation

Underground Parkings

Fine Management Implementation

Parking extension time

Parking location remainder

Parking expiration remainder

Android User Application iOS User application

Multi-lingual User Interface

Parking regulation informations

User Management

Identify Illegal Activites

Car Identification (QR-Code, NFC,

manual)

Windows Mobile Phone Application

Android Parking Provider

Application

Evaluation of the prototypes

Report & Presentation of the

solution

Analysis of User Data

Statistical Parking estimations

Parking Area Definition

Define Interfaces:- Payment

- Fine Management

Persistent Data Storage

Figure 3.1: The Boundary Map of the PMMS Master Project

result of the project, such as the demo version. Assuming that there is interest this stake-holder group has high interest, positive attitude and medium influence.Another important stakeholder group is the End-users (EU) group. Therefore, the in-terest and the influence on the project are high because end-users would profit from areliable and energy and time-efficient solution. Since some parking solutions already existon the market, end-users attitude is between neutral and positive.Parking Providers (PP), such as a city, or a municipality, are possible future customersof the PMMS. Thus, they have only low influence on the project. But this will changewhen the PMMS prototype is ready. The interest of the parking providers stakeholdergroup is medium as there is currently no integrated parking management solution on themarket. Finally, the attitude is positive since maximizing parking spot utilization andthus parking provider‘s revenues is aimed.Parking Inspectors (PI) are hired by parking providers and are an important stake-holder with a high interest in this project since their job will become easier and moreefficient. These inspectors definitely have a positive attitude in the project but in theearly phase a low influence.Competitors (CO) are a stakeholder with a medium interest and a low influence on thiswork. Their attitude is of course negative because the competitors may also have similarideas.Payment Solution Provider (PSP) such as credit card firms and PayPal forms thelast stakeholder group. These payment solution providers have a positive attitude on the

12 CHAPTER 3. PMMS

Table 3.1: Stakeholder Analysis of the PMMS Master ProjectStakeholder Interest Influence AttitudeProject Team Members (PTM) High High PositiveFuture Investor (FI) High Medium PositiveEnd-Users (EU) High High Neutral/PositiveParking Providers (PP) Medium Low Neutral/PositiveParking Inspectors (PI) High Low PositiveCompetitors (CO) Medium Low NegativePayment Solution Provider (SPS) Low Medium Positive

project because they could benefit from the commissions. Due to the small project size,the interest of these firms is low and the influence is medium.

For the PMMS project the stakeholders list is summarized in Table 3.1 and the stake-holders map is illustrated in Figure 3.2. The goal is (a) to increase the interest of everystakeholder as much as possible, and (b) to change, if possible, negative to neutral, oreven to positive, the attitude of stakeholders with high influence.

Low Medium High

Low

Medium

High

Interest

Influence

PTM

EU

PSP

CO

PI FI

PP

Figure 3.2: Stakeholders Map of the PMMS Master Project

3.4. RISK ANALYSIS 13

3.4 Risk Analysis

The risk analysis helps to define the potential problems that might occur, and to thinkof possible measures in advance to eliminate, or reduce the risk. Stakeholders identifiedduring the stakeholder‘s analysis with a negative attitude are also reflected in the riskanalysis. The classification of the risk factor R is based on the probability PBR (Low,Medium, High) and the Impact IMP (Low, Medium, High) of the risk by multiplyingPBR and IMP (cf. Figure 3.3). A-Risks are crucial to the project and should beavoided. B-Risks are dangerous and have to be observed. Finally, C-Risks may be ignoredor at least observed.

Low (1) Medium (2) High (3)

Low

(1)

Med

ium

(2)

High

(3)

Prob

abili

ty (PB

R)

Impact (IMP)

C3

C2

B3

C1

B1

A3

B2

A2

A1A-Risks: AvoidB-Risks: ObserveC-Risks: Observe or Ignore

Figure 3.3: Risk Table

Several risks for the PMMS were identified. The list of potential risks that have beenidentified during the risk analysis phase are summarized in Table 3.2.The first risk is the theft of intellectual property, the main idea, of a rival was identi-fied as an A-risk. To prevent this, the source code will be encrypted and guarded as goodas possible. Thus, the first mover‘s advantage will be used.The lack of end-user interest is another A-risk that should be considered. Thus, a fo-cus on the usability of the system is prioritized through use of standardized technologies.Furthermore, the lack of interest of parking providers is an A-risk. Therefore, thesestakeholders need to be convinced that they will benefit from such solution with additionalincomes and lower maintenance costs.

14 CHAPTER 3. PMMS

The parking regulation authority could also lack of interest in this project becausethey might develop their own systems or because of the diverse local requirements of theregulation authorities. Thus, the authorities will be informed about this generic solutionthat will fit in every context and will provide additional value security and precision inthe parking management.Legal Issues like the privacy of the user data was identified as another A-risk becausethe user data stored in the QR-code or the NFC is publicly accessible. To overcome thisissue, only non-sensitive and publicly available user data such as vehicle color, model,and plate‘s number will be stored. Moreover, lack of existing-parking-spots-relateddata from the parking provider might occur. If so, the initial data population needed willhappen manually to build a working prototype for a small area.There is also a chance of unprecise GPS signal under some circumstances. For thiscase, several alternatives like the use of Google Location Services and the sending of thelocation data as soon as the signal returns can be implemented.Another B-risk is that the NFC is not readable through the front shield. Therefore, itwill also be possible to enter the data manually, or by using a QR-code.Moreover, the QR-code may not be readable through the front shield because of glassreflections. To overcome this, the QR-code may be attached on the outside of the carwith a waterproof sticker or the data can also be entered manually.There is a chance that maybe a project member is not able to work on the projectdue to sickness or other circumstances. Thus, substitutions to each person‘s task will beassigned.The chosen approach could also be technically unfeasible because of certain require-ments. To overcome this risk, the requirements engineering will take place upfront toselect the right technologies to be used. Additionally, if necessary some requirements maybe adapted or changed.Furthermore, the battery consumption on mobile devices has always to be in mindduring the entire project. Thus, a battery efficient framework will be chosen so that end-users will not experience battery draining when using the application.A C-risk is that parking regulations in certain areas is different and only available inthe local language. Thus, a database with all regulations and translation in many lan-guages can be created.Another C-risk is the lack of feasible payment solutions because the mobile paymentis not yet established by end-users in certain areas. As this part is currently out-of-scope,the prototype will use a mock for the payment and provide an interface for future paymentsolutions.

Summarizing, the risk analysis shows that the main risk is the lack of interest of end-users, parking providers and regulation authorities. Thus, an effort has to be put towardsconvincing these three stakeholders to adopt the system. Additionally, protection of theidea and the parking availability estimation algorithm as well as the privacy issues of theend-users have to be considered.

3.4. RISK ANALYSIS 15

Table 3.2: Risks of the PMMS Project

Risk PBR IMP R Priority Possible Cause MeasureIdea theft of ri-val

2 3 6 A2 Competitor stealsidea

First mover advan-tage, network ef-fect, encrypt andguard source code,register trademark

Lack of End-User interest

2 3 6 A2 Bad usability, badmarketing, too hightechnical standards

Focus on usabil-ity, use of standardtechnology

Lack of ParkingProvider interest

2 3 6 A2 Current system isgood enough, no in-tention to invest

Convince parkingprovider with addi-tional incomes andlow maintenancecosts

Lack of ParkingRegulation Au-thority (PRA)interest

2 3 6 A2 PRA develops ownsystem, diverse lo-cal requirements ofregulations author-ities

Generic approachto fit different localrequirements

Legal Issues(Privacy of UserData)

2 3 6 A2 Private user data isstored in NFC/QRwhich is publiclyaccessible

No private userdata on NFC/QR,legal consultant ifneeded

No parking data(e.g. the loca-tion of parkingspots in an area)

2 3 6 A2 The city does notsupport us with thedata or does noteven have such in-formation in appro-priate form

Own elicitation ofsuch data, proto-type for a smallerarea

No precise GPSSignal

2 2 4 B1 Bad signal insidecar, too manybuildings

Send data as soonsignal is available,use of Google Loca-tion Service

NFC not read-able throughfront shield

2 2 4 B1 Special glass, dis-tance

Manual entry, NFCwith strong signal,QR code

Project memberis not able towork on theproject

1 3 3 B2 Sickness, lack ofmotivation

Plan small anddoable work ar-tifacts, definesubstitution

Approach istechnically notfeasible

1 3 3 B3 Requirements thatare not supportedby the mobile tech-nology

Requirements engi-neering up front

16 CHAPTER 3. PMMS

Battery of mo-bile devices istoo weak

1 3 3 B3 Demanding com-putations for QR,NFC or map

Choose battery effi-cient frameworks

Lack of Parkingregulation doc-umentation insome regions

3 1 3 C3 Different regu-lations in everycanton and city,maybe translationsneeded

Database with reg-ulations and trans-lations

QR-codenot readablethrough frontshield

1 2 2 C1 Special glass, re-flections

Manual entry ofcar data possibletoo, waterproofcode outside of carshield

Lack of feasi-ble paymentsolutions

1 2 2 C1 Mobile paymentnot yet established

Work with pay-ment solutionproviders on aprototype, pre-postpay methods

Chapter 4

Architecture

This chapter describes the architecture of the PMMS. It first provides a formal definitionof the chosen architecture and then an overview over the architecture of the final imple-mented system. Additionally, the chapter describes the front-end components and usedframeworks, the back-end architecture and database and finally how the different partscommunicate with each other.

4.1 Client-Server Architecture

This section describes the client-server architecture. Client-server architectures are cen-tralized architectures. As seen in Figure 4.1, a possible client-server architecture consistsof three layers: the user interface, the application and the database layer. Clients usuallyact on the user interface layer and request information from the application server. Theapplication server provides services for the client and if necessary accesses the databaselayer to retrieve requested data. There is no direct connection between the user interfaceand the database [44].

4.2 Architecture of the Implemented System

The system follows a classical client-server architecture. It consists of four different parts:The two front-end applications, the web server and the database. The front-end appli-cations get access to the database through the web server, thus there is no direct linkbetween the database and the end-user (cf. Figure 4.2).

4.3 Front-End

This section describes the components, the reason behind the technology choice and theframeworks used to implement the front-end applications of the PMMS.

17

18 CHAPTER 4. ARCHITECTURE

Figure 4.1: Client-Server Architecture with Three Layers [44]

End-User Application

Overall Architecture PMMS

Parking Provider Application

Back-End Server

Administration Apache Tomcat Web Server Database

Figure 4.2: The Overall Architecture of the PMMS

4.3.1 Components

The front-end applications provide an easy access for the user to the features of thePMMS. Therefore, the front-end applications are the connection between the user andthe back-end of the PMMS.

4.3. FRONT-END 19

There are two different user groups that the PMMS has to serve. First, there are theend-users who search for parking spots. Second, there are the parking inspectors who arehired to control the parked cars in the city.To serve the needs of those two user groups, two mobile applications were implemented.On one side, the end-user application for the needs of the end-users and on the other side,the controller application to satisfy the requirements of the parking inspectors.

4.3.2 Framework Evaluation

The evaluation of the technology to implement the front-end applications was dividedin four steps: Requirements Elicitation, Platform-Framework Selection, UI-FrameworkSelection and Critical Requirements Testing. This procedure was chosen to ensure that(a) all requirements are satisfied and (b) the chosen framework und platform do notdecrease the quality of the system.

1) Requirements ElicitationIn the first step, all requirements were elicited from the project description.For the controller application, one of the main requirements was the capturing of thecars with a NFC-tag and QR-code. Because not every device does support NFC yet,it was decided that the controller application needed to be an Android application.The main requirement of the end-user application was identified as the simple andresponsive search for free parking spaces. Therefore, the integration of a map-functionality was crucial.

2) Platform-Framework SelectionThe second step in the technology evaluation was the choice either to develop theapplications native for android and iOS separately or to use a multi-platform ap-proach.For the controller application, both the native and the multi-platform approachwere found suitable, since the NFC and QR technology is integrated natively andon multi-platform frameworks for Android.The map functionality on the end-user application is the key feature for the user.This functionality was available natively for iOS and Android and also as plugin forthe multi-platform framework.The decision to implement the front-end applications with the multi-platform ap-proach was made because of the single source code for both mobile platforms iOSand Android. Additionally, the developers could profit from the learning curve ef-fects when implementing all applications with the same framework.The Cordova [1] framework was selected because of its wide spread dispersion andits well documented guidelines.

3) UI-Framework SelectionThe third step of the technology evaluation consisted of the selection of an userinterface framework. The basis of this selection was mainly the result of the secondstep. The well documented and multiple times tested collaboration of Cordova andjQuery [18] was selected.


Although, several frameworks exists to work with jQuery and Cordova, the choicefell on jQuery mobile [19] because of the very good integration with jQuery.

4) Critical Requirements TestingThe last step of the technology evaluation consisted of the implementation of amockup with the main requirements identified in step 1. Thus, it was ensured thatthe main features could be implemented with the chosen frameworks.

This four-step evaluation lead to the combination of Apache Cordova, jQuery and jQuerymobile to develop the front-end applications (cf. Figure 4.3).

jQuery mobile

jQuery

Apache Cordova

iOS Android etc.

UI-Framework JS, HTML5, CSS

Web-Framework JS, HTML5, CSS

Platform-Framework Java, Objective-C, ...

Device-APIs

Figure 4.3: The Technology Stack of the Used Frameworks for the Front-End Applications

4.3.3 Frameworks

As mentioned in Section 4.3.2, the choice of frameworks and technologies was based onthe main requirements. The outcome of this evaluation process was the decision to usethe Cordova, jQuery and jQuery mobile frameworks.

Cordova Apache Cordova [1] is a mobile development framework that allows access todevice specific functions and sensors from JavaScript. The framework consists of deviceAPIs for all major mobile platforms like iOS, Android, Blackberry and many more. Thisframeworks offers the possibility to build applications with JavaScript, HTML5 and CSSfor multiple platforms with only one source code.The Cordova framework builds for every chosen mobile platform a native application fromthe JavaScript, HTML5 and CSS source code (cf. Figure 4.4). The resulting applicationis an internal web view of the source code enriched with the functionality of device specificAPIs. This internal web view is basically the device browser showing the webpage. Ac-cordingly, it is not visible for the user that this is not a natively programmed application.Granted, the usage of the web view is on some mobile platforms restricted and may leadto lower performance on demanding tasks compared to native applications [9].

4.4. BACK-END 21

jQuery jQuery [18] is a lightweight JavaScript library which enables the developer tofast and easily traverse and manipulate HTML documents, supports JavaScript eventhandling and simplifies Ajax communication. The library supports the vast majority ofmobile as well as desktop browsers.

jQuery mobile The jQuery mobile [19] framework is a HTML5 user-interface frame-work to build responsive applications and websites mainly for mobile phones and tablets.It is based on the jQuery library and enables the developer to build responsive designsfor multi-platform applications.

JavaScript, HTML5, CSS Apache Cordova

Apple iOS

Google Android

Blackberry, Firefox OS, etc...

Apache Cordova Plugins

Figure 4.4: The Build Process of the Front-End Applications

4.4 Back-End

The back-end consists of two main components: the web server and the database. Theweb server provides services to the end-user applications and accesses the database whenneeded.

4.4.1 Web Server

The PMMS uses an Apache Tomcat [4] for the web services. Apache Tomcat is an open-source web server which supports Java Servlets [17]. Java Servlets provide a simple way toadd Java-written web services on top of the Tomcat server. The server runs two differentJava Servlet applications, one for the controller and one for the end-user application.


4.4.2 Database

To store data, the system uses a MySQL [25] database. MySQL is a very popular, wellsupported and easy usable open-source database management system.

4.5 Inter-Component Communication

The communication between the different components of the PMMS is a key featureof the whole system. The communication should be fast, simple, secure and reliablewith a communication overhead as low as possible because of the following reasons. Afast communication is required for a good user experience. An application that is notresponsive will most likely not be used. The application transmits sensitive user-relateddata such as the address of the user, car details and details of payment instruments.Thus, the communication should be secure which means it should neither be possiblefor a potential attacker to read data nor to alter data. Since the application is used onmobile devices, the communication overhead should be small because data communicationcosts battery and sometimes data transfer is also limited by the mobile network operators(MNO).

4.5.1 JSON-RPC

The communication among the different components is done by JavaScript Object No-tation Remote Procedure Calls (JSON-RPC). There are different frameworks for JSON-RPC. One requirement was the support of Java and JavaScript, because of the commu-nication that takes place between the back-end, that is based on Java Servlets and thefront-end which is JavaScript based. That is the reason why the framework of RitwikSaikia [20] was chosen. JSON is a light-weight data-interchange format where data isaccessible as JSON objects in the JavaScript code [38]. The fact, that this data format isvery light-weight and also easy to process were the reasons why JSON-RPC was choseninstead of other possible communication protocols like XML-RPC [47].

Chapter 5

Design and Implementation

This chapter describes the design, functionality and implementation of the two applica-tions. Furthermore it shows the process of testing, considered security topics and presentssome supportive works of the PMMS.

5.1 Controller Application

This section describes the main features of the controller application of the PMMS. More-over, the testing process and the limitations of the controller prototype are describedbriefly.

5.1.1 Functionality

The functionality of the controller application is based on the following requirements:

• Every Parking Inspector (PI) shall have an account.

• The PI shall be able to check (with QR-code, NFC-tag or manually), if a vehicle isparked and the respective parking fee is paid.

• The PI shall be able to record a fine, attach photos and send the fine to the ownerof the vehicle that is parked illegally.

• The PI shall be able to send a notification that a vehicle was towed away to thevehicle owner.

• User authentication shall be secure.

23

24 CHAPTER 5. DESIGN AND IMPLEMENTATION

User Management The use of the application is only granted to registered users in thedatabase. Thus, the parking provider (PP) has to register each parking inspector (PI).The rational for individual accounts for the PI is that each fine has to be linked with thePI who issued the fine.

Check Vehicles The controller application provides three ways to check if a vehicle isparked legally. First, the parked vehicle can be checked by scanning a NFC-tag attachedbehind the front window. Second, the vehicle can be checked by scanning a QR-codeattached to the front window. In both methods the licenseplate, brand, model, color andthe country where the vehicle is licensed is stored on the NFC-tag resp. the QR-code.The third option to check if a vehicle is parked legally is to enter the licenseplate manually(cf. Figure 5.1).In all three methods, a request is sent to the server where the check is performed and theresult, if the vehicle is parked legally or not, is returned after the check. To prevent fraud,the brand, model, color and license plate are displayed to enable the PI to cross-check theuser information in the database with the reality.

(a) Manual Check (b) NFC Check (c) QR Check

Figure 5.1: UI-Screens - Vehicle Check

Send Fines Once the PI spotted an illegally parked vehicle, he can send a fine im-mediately to the holder of the parked vehicle. The PI may add up to three photos asattachments to the fine. The exact date, time and location of the parked car are auto-matically added to the fine. Still, if the computed address based on the GPS-location isnot correct, the PI may change the address manually (cf. Figure 5.2).After completing the details of the fine, the PI may send the fine details to the serverwhich then sends the fine via email to the holder of the vehicle (cf. Section 5.4.1).

5.1. CONTROLLER APPLICATION 25

All collected fines are saved locally on the device. If the device currently has no receptionor the application servers are not reachable, the PI may send the fines later.

(a) Illegal Parking Alert (b) Send Fine (c) Send Fines Later

Figure 5.2: UI-Screens - Fine Management

Send Notification The PI is able to send a notification via email to the holder of avehicle if the police had to move his car away from the parking space.

5.1.2 Limitations

There exist limitations for the usage of the controller application due to privacy issuesand to protect the system against willful fraud.

Privacy Issues Several issues arrive when applications handle sensitive customer dataover the internet. First, the connection from the application to the server is secured bySSL (cf. Section 5.8). Additionally, only the visible data of the car is transferred to theserver.Second, the data stored on the NFC-tag and in the QR-code is readable for every personwith a smartphone. Thus, data stored on the NFC-tag and QR-code shall not be sensitive.Only data which is viewable for every person passing by the vehicle is stored on thetag/code. In other words, the license plate, brand, model, color and the country wherethe vehicle is licensed are stored on the tag/code.In addition, NFC-tags used in the productive environment are read-only to ensure thatnobody alters or deletes the stored data.


Willful Fraud Users may create their own or copy another NFC-tag or QR-code. Thefirst issue that a user could create his own tag is covered that if the parking inspectorchecks a vehicle that is not registered, the application shows a warning and the parkinginspector has to further investigate the parked vehicle. The issue that a user could copythe tag/code of another user is covered, too. The application indicates the scanned visibleproperties of the car therefore the controller may cross-check for example the color storedin the database with the actual color of the vehicle.

5.2 End-User Application

The End-User Application is the part of the PMMS for the driver. It is a multi-platformapplication which currently supports Android and iOS.

5.2.1 Functionality

The features of the End-User Application consist of (1) the map to show parking lots orthe position of the parked car, (2) parking management, (3) User Profile Management,(4) multilanguage support and (5) location-based regulations.

(a) Default Map (b) Parking Types (c) Occupied Parking Spots

Figure 5.3: UI Screens - Map

Map The map is one of the key features of the application. It is used to show (a)unavailable parking spots and possible available spots, and (b) the position of the parkedcar. The map is implemented as a web-based Google map, where the API version three

5.2. END-USER APPLICATION 27

has been used [14]. This map is initialized once and used for both modes. When themap is loaded the first time, the current position is retrieved and all parking spots in apre-defined area, either available and unavailable, are retrieved from the back-end server.By default only white zone spots and blue zone spots are displayed (cf. Figure 5.3(a)).However, the user has the possibility to select the desired parking spots in a checkboxlist (cf. Figure 5.3(b)). If the checkbox for occupied spots is checked, all other parkingspots get disabled (cf. Figure 5.3(c)). Beside blue zone and white zone spots it is possibleto show parking spots for handicapped people (cf. Figure 5.4(b)) and also car parks (cf.Figure 5.4(a)) can be displayed. The car park pins indicate in which dimension the amountof free parking spots is. If a user clicks on the map for longer than one second, a markeris drawn at this position with the address displayed in an info window (cf. Figure 5.4(c)). When the navigation button is pressed afterwards, the route from the current positionto this marker is calculated. To enhance the visibility of the map, parking spaces areclustered together automatically when the user zooms out.

(a) Car Parks (b) Spots for Handicapped Peo-ple

(c) Tap Position

Figure 5.4: UI Screens - Map

Parking management The parking management is essential for the PMMS to work.By acknowledging when a car has been parked, this occupied spot will be shown on themap. When a driver wants to park the car the corresponding zone has to be selected(cf. Figure 5.5(a)). For parking in a blue zone parking spot the driver does not haveto insert further information. The leaving time is automatically calculated based on theregulations in the current location. On the contrary, for white zone the time when thespot will be left has to be entered. Currently there is no collaboration with car parkproviders. However, a driver still can acknowledge that the vehicle has been parked inorder to show on which spot on which floor in which car park it has been parked (cf.


(a) Select Zone (b) Park in a Car Park (c) Manage Parking

Figure 5.5: UI Screens - Park

Figure 5.5(b)). When a vehicle has been parked it is no longer possible to show parkingspots on the map. Instead of this the time when the parking time ends is shown (cf.Figure 5.5(c)) and it is possible to show where the car has been parked on the map (cf.Figure 5.6(a)). When a car is parked and the parking time is expiring soon a notificationis shown to the user (cf. Figure 5.6(b)). This notification does also appear if the deviceis in standby mode. The timer that triggers the notification is running locally to preventfailing due to lost connections. In the case that the vehicle is parked on a white zone spotit is possible to extend the parking time (cf. Figure 5.6(c)).In the special case that the owner of a car has obtained a blue zone parking card for hisneighborhood, he may automatically park in the blue zone for 24 hours.

Multilanguage The application offers multi-language support. Currently the followinglanguages are supported: Chinese, Croatian, Danish, English, Finnish, French, German,Greek, Indonesian, Italian, Portuguese, Romanian, Russian, Slovakian and Spanish. Eachlanguage is stored as JSON in a javascript file, which is dynamically loaded. On thefirst start the language of the operating system is chosen. If the language is changedin the application settings this language is chosen on every start afterwards. To adda new language to the application the correspondent javascript file has to be added inthe language folder of the source code. Additionally, this new language has to be addedin a JSON object holding all currently supported languages, where the key is the ISO639-1:2002 language code [16] and the language in the respective language.

User Profile A new user may either register a new account with a valid facebookaccount, google account or create a new profile without any connection to these networks


(a) Where’s My Car (b) Parking Exceeded Notifica-tion

(c) Extend Parking Time

Figure 5.6: UI Screens - Parking Management

(a) Login Screen (b) User Profile (c) Parking Regulation

Figure 5.7: UI Screens - Login, Profile and Parking Regulation

(cf. Figure 5.7(a)). The user has to fill in first name, last name, the address and whetherhe owns a parking card for a specific zip code [27] (cf. Figure 5.7(b)). A user has toregister at least one vehicle in order to use the application‘s functionality. Currently,there is no support for paying the parking spots directly. However, the application is


prepared to register credit cards (Visa and Mastercard), login with a PayPal account orto charge in-app balance with a prepayment slip.

Regulations The end-user application allows the user to see regulations concerningthe different parking facilities at specific locations (cf. Figure 5.7(c)). Currently, theregulations for Zurich and Basel are implemented. If the user is in another location,a default regulation for Switzerland is shown. The system is hierarchically designed toenable additional region-specific regulations in the future.

5.2.2 Limitations

The project description proposed the implementation of a reporting system that allows auser to indicate that another driver has parked illegally. This functionality has not beenimplemented because of concerns about legal issues.The scalability of the servers are with our test cases reliable. Though, the main per-formance bottleneck was identified as the devices limited resources to handle the mapfunctionality. To overcome these issues, clustering was implemented which enabled aresponsive user experience.

5.3 Front-End Testing

Testing of a software is essential to evaluate whether the requirements are satisfied by theapplication or not [24]. This section describes the levels, artifacts and devices which wereused to test the front-end applications.

Levels Four different levels of testing were performed. First, unit tests of the isolatedfeatures were performed during the development phase. In a second phase when develop-ment was nearly finished, the front-end applications were tested in an integration test withthe PMMS system environment. In a third step after the completion of the development,the whole PMMS system was tested in a system test. When all the issues found in thesystem test were solved, a final acceptance test prior to the publication of the applicationswas performed.

Artifacts To ensure that all features would be tested, a test plan and protocol wereused. The test plan consisted of entries for each functionality where the input and theexpected output of an action was described. Every test was documented in the testprotocol and if in any action the desired output was not achieved, the issue was reported.

5.4. WEB SERVER 31

Devices The prototypes were tested on two devices. The first device was a brand-newSamsung Galaxy Note 3 (N9005) operating Android 4.4 “KitKat“. The second device wasa HTC One (M7) running a Android 4.4.3.Both devices are equipped with a NFC chip to write and read NFC tags. Moreover, bothdevice’s cameras are substantially fast and qualitatively good which enables the scanningof the QR-code and the ability to attach photos to fines.

5.4 Web Server

This section describes the different web services. The web service part of the systemis divided in the controller server part and the end-user server part. Furthermore, thissection shows how the back-end web services were tested.

5.4.1 Controller Server

The Controller Server consists of eight Java Packages. They provide services to fulfil therequirements of the Controller Application.

Server Package This is the main servlet [17]. It is responsible to handle most requestsfrom the controller application (file transfer is done in a separate servlet). The JSON-RPC framework [20] automatically calls the corresponding classes and methods based onthe incoming requests. It also controls if the HTTP request header contains the rightauthorization name and value.

Database Package The database package handles all accesses to the database. Itcontains a helper class for all other classes.

Fine Package The fine package handles all incoming fine requests. It parses the finewhich is sent as a JSON object, inserts the fine into the database and initializes a mailtask to send the bill, fine information and pictures directly to the owner of the car.

LicensePlate Package This package checks whether a car is parked legally or not. Itcontrols if the car is in the database and if it is currently parked (meaning that the endtime of the parking is in the future). If the car is illegally parked it means it is currentlynot in our database table of occupied spots. Since it is now known that the parking spotis occupied we can insert the car into the table for e.g. one hour (this is an assumptionwhich has to be updated and improved, once more data is available). It is very importantto know that this is the main resource of unavailability information, since car controllingis done periodically and almost all the time.


Mail and Notification Packages These two packages are currently used to send emailsto users. They have two use-cases: Notifying a user that it’s car has been towed away orto send a fine with the bill to the user.

User Package The user package handles the login of the controller. Since passwordsare stored as MD5 hashes the incoming password is also hashed and then cross-checkedwith the password in the database.

File Transfer Package This package is responsible for the requests which uploadspictures of illegally parked cars. It is an own servlet [17]. The pictures are stored on thefile system of the server.

The Controller Server is built modularly, meaning that the different packages have pur-poses which match the various functional requirements. Therefore it is also easy to adaptto new or changing requirements and the modularity of the packages enhances the re-usability.

5.4.2 End-User Server

The End-User Server is divided into four main packages which are totally separated fromthe Controller Server.

End-User Package It contains the servlet [17] responsible to handle all incoming re-quests from the end-user application. The JSON-RPC framework [20] automatically callsthe corresponding classes and methods based on the incoming requests.

Database Package The database package handles all accesses to the database neededby the end-user application. It contains a helper class for all other classes.

Geolocation Package This package is responsible for the parking management. Itlooks up and sends free and occupied spots to the user, handles find my car requests,parking requests, leave spot requests, it extends parking and also supports parking witha parking card.

User Package This package handles user login and registration and the user profiledata. The profile includes demographic information about a user as well as it’s cars withcar details (e.g. type, color etc.).

As stated in 5.4.1 the End-User Server is also built modularly, which allows it to easilyadd or change parts to the system.

5.5. DATABASE 33

5.4.3 Testing

The server functionality has been tested using JUnit tests [21] as well as with black-boxtesting during the inter-component and work-flow oriented testing. These tests have beenrepeated several times to ensure new or changed parts do still work properly. Due tothe low user base the system was only tested with four users which concurrently use theapplications. An extensive test with a large user base is open for future work. The testinghowever showed that the performance issues are more likely to take place on the user-sidewhere rendering of the map takes a long time and where there can be the problem ofunstable or slow internet connection, especially when a user is moving.

5.5 Database

The MySQL [25] database is divided into three different parts: The parking management(using prefix pm), the user application (prefix ua) and the controller application (prefixca).

5.5.1 Tables

The parking management contains a table with information about car parks (in Zurichand Basel, pm carpark). For every car park there exists an entry in another table(pm freecarparkspace) about how many spots are currently free. Furthermore there isa table which stores known parking spots, their coordinates, address and type (blue,disabled, white). Then there exist two different tables for occupied spots: occupiedknown and occupied unknown spots, where known respectively unknown refers to thefact whether the end-user parked on (or near) a parking spot which is in our database ornot. Both tables store the user, vehicle information, start and end time and coordinates.

The user application has three tables. One table(ua log) corresponds to a log which keepstrack of the main activities a user does (e.g. user xyz logged in on time stamp abc etc.).Then there is one table with user information (ua user) and one with information aboutvehicles (ua vehicle).

The controller application uses five tables. There is a log (ca log) which stores activities ofthe controller (e.g. user xyz controlled car with plate abc), a table where fines are stored(ca fine), two tables which store the parked cars which are illegally parked (ca occupiedlotand ca occupiedunknownlot) and a table which stores information of the controller user(ca parkingprovider).

5.5.2 Privacy

This section is about the privacy issues of the data stored in the database. In general auser is owner of his data. The parking data is therefore stored locally on the user devices.


However, to show unavailability and to make controlling possible the PMMS needs tohave real time data. This conflict of goals will be solved in a productive environmentas follows: The old data in the occupied spot tables get cleared every day. Before thathappens anonymized parking data is stored in another table for future analysis of thebehavior and improvement of the used algorithms.

5.6 Additional supportive Work

Besides the two main parts of the PMMS, there are other outcomes of this work. Thissections describes the additional works which have been done and that are worth men-tioning.

5.6.1 RSS-Crawler

The RSS crawler is a Java project which is used to crawl real-time availability data of thecar parks in Zurich [29] and Basel [28]. This data was used to evaluate the availability incar parks in Zurich. This was done by crawling the data every five minutes for two weeks.The evaluation showed an interesting overview of the car park usage in Zurich and wasused to come up with different scenarios in the simulation in Section 6.1.1.

Furthermore, this data is also used in the end-user application to show real time data ofthe car parks in Zurich and Basel on the map.

5.6.2 Capture Spots Application

One problem of the system consists of the fact that there is no parking zone data available.Therefore, an additional application was developed to capture parking spots. It allowsto gather parking spaces (white and blue zones) by walking past the spot and enteringthe type of it. Since the GPS modules on smart phones are not perfectly accurate, thespots have to be aligned afterwards. Considering that currently the map in the end-userapplication only shows clusters, this would still be a solution to gather spots. Howeversome improvements are open for future work (automatic alignment, map integration etc.).

5.6.3 Website

Additionally to the applications, there is a website with information about the project(http://www.parkitsmart.com). The website provides information about the end-user ap-plication, a demo page of the map with hard coded data, an about part, short presentationof the team and some links.The webpage is implemented with the open-source content management system Word-press [46]. It is hosted on a virtual server running an Apache Server, located at the CSGgroup of the University of Zurich.

5.7. ADMINISTRATION 35

5.6.4 Parking Spot Generator

This is a simple program which generates random parking spots in a certain area. Thiswas used to test different features and also performance.

5.6.5 Integration of the Dataset Disabled Spots

The city of Zurich has a publicly available dataset about spots for disabled people [8].This program was created to insert these disabled spots into the database to make themavailable in the end-user application.

5.7 Administration

Most of the administration of the PMMS takes place directly on the server (MySQLdatabase, Apache Tomcat Server). The Apache Tomcat Server has however a web basedinterface to manage the deployment of the web applications. The content of the websitecan also be administered through the web based interface.

5.8 Security

Secure communication is essential in the PMMS, where among other data sensitive profiledata of users is transported. To provide secure end-to-end communication between thePMMS components, the Secure Socket Layer (SSL) is used. It allows web servers andclients the communication over a secured connection and provides confidentiality usingsymmetric encryption and message integrity using a message authentication code [42].Authentication means, that during the initial attempt to communicate with the serverover a secure connection, the server presents a set of credentials to the client, as proofthat the servers is who and what it claims to be [5]. This set of credentials is in the formof a certificate. Stallings writes, that a certificate consists of a public key plus a user ID ofthe key owner, with the whole block signed by a trusted third party. Typically, the thirdparty is a certificate authority (CA) that is trusted by the user community [42]. However,it is not necessary that a certificate is created by a CA. If an administrator just wants toensure that the data is transmitted encrypted and no one can eavesdrop the connection, a“self-signed”certificate can be created. Therefore java provides a command-line tool calledkeytool [5]. Such certificates are not officially registered with a well-known CA. ApacheCordova does not recommend the use of such certificates because it allows any servercertificate to be considered valid by the device, which makes the connection vulnerableto man-in-the-middle attacks [3]. In this work “self-signed” certificates were only used fordebugging purposes, because of the vulnerabilities mentioned before and the fact that iOSdevices do not allow such certificates by default. That is the reason why for this work afree (Class 1) certificate with 128/256-bit encryption provided by StartCom [43] has beencreated.


5.8.1 Database Security

Since the PMMS deals with sensitive data, the database should be as secure as possible.The system takes care of the database security in three different ways: Protection againstSQL injection, passwords saved as MD5 hash strings and different MySQL user accountsfor the controller and the end-user.

The risk of a SQL injection [40] is minimized by not directly inserting the parameters intothe SQL query. Instead the functions provided by Java are used to set the attributes ofa query. They make sure the integrity of the attributes are safe. Example 5.1 shows thisfunctionality in Java.

Listing 5.1: Example of Java Function to prevent SQL Injections

St r ing name = ”Max ”;Statement statement = ”SELECT ∗ FROM ua user ” +

”WHERE ua username = ? ”;//Makes sure the St r ing a t t r i b u t e name i s i n s e r t e d// as a St r ing with quotes at the beg inning and endstatement . s e t S t r i n g (1 , name ) ;

The different MySQL user accounts for the controller and the end-user have exactly therights they need to perform their queries. This means for example that an end-user is notallowed to even read the table which contains fines (and which is therefore sensitive).

Chapter 6

Evaluation

This chapter evaluates the two applications in terms of (a) parking space utilization anddata usage for the end-user application and (b) time efficiency, energy efficiency and datausage for the controller application.

6.1 End-User Application

The evaluation of the end-user application is divided into two parts: (1) a simulation toshow how the PMMS would improve the parking space utilization and (2) the data usageevaluation. Part (1) was conducted to indicate that the PMMS is able to save time, fueland minimize car emissions using information about availability of parking spots. Part(2) is implementation specific. It points out that the communication between the serverand the end-user application uses little data and thus that the chosen communicationapproach with the JSON-RPC framework [20] is suitable for the used purposes.

6.1.1 Parking Space Utilization

An improvement of the parking space utilization results in revenues for (1) the user whichsaves time and reduces car emmissions, (2) the state and or city which has a lower con-gestion rate and (3) the environment which is exposed to less car emissions. By providinginformation about areas with free spots the PMMS is able to increase the parking spaceutilization. A possible way to model and to evaluate this environment is to compare arandom routing to a parking spot with a routing where availability information is given.It can be argued that a driver who does not have any information about the parking spotsin a target area drives around randomly until a spot is found. On contrast, a driver withinformation about the closest free parking spot will directly head to that spot. Based onthis Hypothesis 1 is deducted.

Hypothesis 1 Drivers that search for a spot randomly have to cruise longer than driverswith parking spot availability information.

37

38 CHAPTER 6. EVALUATION

In order to justify Hypothesis 1 a simulation has been performed to estimate the time forcruising for parking randomly and the time finding parking spots with parking availabilityinformation.

Simulation

The simulation models a part of a city using a grid where every cell has either a free parkingspot or is occupied. The cells contain a free parking spot with a certain probability whichis parametrizable. Multiple cars start at random positions and head to random goalpositions. The cars move in a turn-based fashion from one cell to an adjacent cell. Forsimplicity diagonal movements are not allowed. There exist two parameters which modelthe time it takes to make one move: (1) duration by car and (2) duration by foot (cf.Equation 6.1). The turn-based mode enables the possibility to simulate the routing ofmultiple cars at the same time. This makes the simulation more realistic. If for exampletwo cars are heading to the same free spot only the first arriving car is able to park thereand thus the second car has to look for another parking spot.

Timetotal = TimebyCar + TimebyFoot (6.1)

Both conducted scenarios share two common parameters: (1) the grid size and (2) theduration it takes to move from one location to a neighbor location by foot. Furthermorethe scenarios differ in three parameters:

1. The average speed of the cars

2. The percentage of cells with a free parking spot

3. The amount of cars which are looking for a parking spot

Scenario one represents a typical situation in a city center where cars are driving slowly,only a few parking spots are available and the amount of cars looking for a parking spotis high. Table 6.1 shows the scenario of one square kilometer in the city center of Zurichat noon. The parameters are set based on assumptions and information gained from theanalysis of the car park data of Zurich.

In contrast, scenario two covers a situation outside the city center in the morning wherecars can drive faster, the amount of free spots is high and the number of cars looking fora spot is low. Table 6.2 shows the parameters for the second scenario outside of the citycenter of Zurich at ten in the morning.

The two scenarios were executed multiple times and over all iterations the average timeto reach the goal positions was computed. Every iteration uses a new random grid whereevery cell has a free spot based on the probability of free spaces. The starting and goalpositions are also randomly chosen. Since this randomness influences the average time toreach the parking spots the scenarios were executed 100 times. Within each scenario theparameters stated in Table 6.1 and 6.2 were the same for every iteration.


Table 6.1: Scenario 1: One Square Kilometer in the City Center of Zurich at NoonParameter Value JustificationDuration to move bycar

0.2 time units 30 km/h by car, 0.2 minutes for 100meters

Percentage of freespaces

20% The average of free spaces at noonin all car parks in Zurich is 45%, atZurich Central it is 35%. Blue andwhite zones are less common to havefree spots. Therefore 20%.

Number of cars 10 100 fields, around 20 free spaces, 10cars at the same time

Assumptions For the simulation the following assumptions were made:

• General

The size of the grid is 100 (10x10) where one cell equals 100 meters.

The speed of cars is higher outside of the city center.

The percentage of free spaces is lower in the city center.

There are more cars looking for a parking spot in the city center.

The duration to walk to an adjacent cell is 1.5 time units (assuming that aperson walks 4 km/h by foot, 1.5 minutes for 100 meters).

• Random Routing

Cars are driving around randomly without any information.

If a free spot is found the car is parked and the remaining way is walked.

• Routing with Information

The car drives directly to the closest spot to the goal and walks the rest.

If the closest spot to the goal of a driver gets occupied, the cars head to thenext closest one.

Example with Information Figure 6.1 shows an example simulation with two carswhere the car at Start 1 wants to go to Goal 1, the car at Start 2 wants to go to Goal 2and both know where there are free spaces. Initially, both cars want to park at the freespace between the two goals since it is the closest. After five moves, car two is at position(1) and car one has parked at the closest position. Car two realizes this and thereforelooks again for the closest parking spot to its goal. This example shows how multiple carsat the same time can influence the average time of all cars to reach their goal positionswhich makes the simulation more realistic.


Figure 6.1: Example Simulation with two Cars

Table 6.2: Scenario 2: One Square Kilometer Outside the City Center of Zurich at 10.00in the Morning

Parameter Value JustificationDuration to move bycar

0.12 time units 50 km/h by car, 0.12 minutes for 100meters

Percentage of freespaces

70% There are areas where people fromoutside of the city are either parkedin the city to do something, or workthere during the working hours.

Number of cars 5 There only few people looking for aspot at 10.00 am.

Results and Discussion The results of this simulation can be seen in Table 6.3. Itshows that the routing with information about the availability of parking spots is around3.5 to 7.7 times faster than the random routing. This provides strong evidence thatHypothesis 1 is valid. The random approach parks at the first free spot and walks therest, while the more advanced approach looks for the closest free parking spot and parks


there if it is still available at the time of arrival. In the scenario in the city center thedifference between the two approaches is not as high as in the second scenario since thenumber of free spaces is very small, which means that even when the car is parked onthe closest spot there can be a long distance to walk or it could already be occupied byanother car.

Table 6.3: The Result of the Simulation (The Ratio Determines the Benefit of the Ap-proach with Availability Information Compared to the Random One)

Scenario Mean Time Units -Random

Mean Time Units- With AvailabilityInformation

Ratio

Scenario 1 11.12 3.2 3.48Scenario 2 9.89 1.29 7.67

Limitations The simulation shows a remarkable difference between the two approaches.This, is however, not very surprising considering that a random routing is compared toa routing with perfect information. The random routing assumes that drivers park onthe first free parking spot they encounter. This is however not very realistic if they knowthat there are a lot of free spaces closer to the goal (like in scenario two). For futurework, a more sophisticated model or a field test would be appropriate. The results in thissimplified simulation give evidence that it is possible to save time, fuel and minimize caremissions using information about availability of parking spots.

6.1.2 Data Usage Evaluation

This subsection documents the process and the findings of the evaluation of the data that isconsumed by the end-user application. The google maps engine consumes definitely mostdata. This cannot be changed since it lies in the nature of a map provider to consumedata to load new map fragments based on the user‘s input. These map fragments thatwere loaded were of the type roadmap.

Scenario The scenario to measure the data usage of the end-user application was totrigger each action which consisted of an interaction with the server and then measurethe exchanged data packets size.An interesting finding were the different packet sizes for the occupations status of differentparking types. However, this measure depends on the available parking spaces in thedatabase. Hence, the scenario took place in the region of Oerlikon where a large amountof parking spaces are defined.

Results Data Usage The measured results of the data usage are consolidated in Ta-ble 6.4. Retrieving the parking status of all parking spaces consumes by far most of thedata. Other actions as parking or loading user settings consume only few data.


Table 6.4: Data Packet‘s Size Exchanged between End-User Application and Server (inBytes)

Action Sent (B) Received (B)Login 144 18Load car 152 38Load blue zone 180 217632Load white zone 180 3642Load parking spots 180 614Load occupied 180 614Park at blue zone 224 18Park at white zone 218 18Park at car park 134 18Leave parking 134 18

However, the gathered results of this study are not stable because the amount of data usedto load the parking states varies with the amount of parking spaces available in the currentview of the map. Nevertheless, the optimization of loading only the parking spaces in thecurrent view increased the performance compared to load all existing parking spaces.Moreover, nowadays high volume data plans for mobile phones are standard and cheaplyavailable. Which means that the data usage of the application is not a problem for theend-user.

6.2 Controlling Application

The evaluation of the controlling application is divided in time efficiency evaluation whichconsiders the time saving in controlling cars with the application instead of the ordinarychecking and the energy and data usage evaluation.

6.2.1 Time Efficiency

This section focuses on the performance of the controller. One goal of the PMMS isto increase the productivity of a PI using the controller application compared to a PIchecking the ordinary way. The less time a PI needs to control a car, the more cars canbe controlled and more money can be generated respectively less money has to be spenton controlling.

To make a rough estimation about the efficiency difference the following assumptions weremade:

• The PI is about to control a 100 meter long street with blue zone spots on onestreet side (5 meters per parking spot, 20 spots) which are all occupied.

• The PI walks with 4 km/h (1.5 minutes for 100 meters).

6.2. CONTROLLING APPLICATION 43

• Checking whether a car is legally parked takes 3 seconds with the applicationusing NFC-tag or QR-code.

• Checking whether a car is legally parked takes 5 seconds the ordinary way(locating the blue zone card, checking the arrival time).

• 10% of cars are parked illegally (therefore two illegal parked cars).

• Sending a fine takes at most 30 seconds (changing of current address, sendingthree pictures) with the application.

• Sending a fine takes at most two minutes (manual capturing of the user data,depositing fine etc.) without the application.

The total time is calculated as followed:

TotalT ime = WalkingT ime+(CheckingT ime×#Spots)+(#IllegalParkedCars×FineT ime)

Thus, the time used to control the 20 cars without the application is:

TotalT imewithoutApplication = 90s + (5s× 20) + (120s× 2) = 430 seconds.

The time used to control the 20 cars with the application is:

TotalT imewithApplication = 90s + (3s× 20) + (30s× 2) = 210 seconds

Result and Discussion This rough estimation shows that using the controlling appli-cation takes about half of the time than doing it the ordinary way. Most of the parametersare however assumptions (especially the ones controlling manually) and have to be dis-cussed and adjusted with PIs. Furthermore, walking takes a crucial amount of time whichhas not been improved by the PMMS. At one point the PMMS will have gathered a cer-tain amount of data such that it could improve the route of the PIs and therefore alsosave time on the way. Additionally the PMMS is less likely to make errors (such as wrongspelling of license plate or sending a fine to a car which is legally parked) than humanbeing which would improve the precision.

6.2.2 Energy Efficiency and Data Usage

The controller application was evaluated with a special focus on the energy consumptionand the measurement of the transferred data. For the reason that the controller has tobe on the road the whole day to control cars and his mobile phone should have enoughbattery for a day. Moreover, the transferred data is a cost factor for the parking providerthat should be optimized. A field test was conducted where the battery consumption andthe data usage was measured.


Scenario The goal of the evaluation was to measure how much data each operation inthe controller application generates and how the battery consumption in the long-termusage is characterized.The scenario used to demonstrate a typical usage of the controller application was a 10minute field test where the parking inspector controlled several vehicles by scanning theNFC-tag, reading the QR-code and entering the license-plate manually.The scenario was performed two times with a Samsung Galaxy Note 3 mobile phone. Atfirst, the test round was conducted with mobile data enabled and in the second roundthe scenario was performed with Wireless LAN. We assume that there will be city-wideWLAN coverage in major cities which can be used for controlling purposes. Anothermore present time approach would be that the parking inspector carries a mobile WLANrouter.

Results Energy Consumption The evaluation of the power consumption was con-ducted with an Android application to measure the battery consumption of certain ap-plications called “PowerTutor 2” [32]. The evaluation of the results revealed that theLCD-screen of the smart phone has the biggest power consumption of the whole applica-tion. In the scenario with 3G, the LCD consumed 58%, the 3G 33% and the CPU 9% ofthe power.In the scenario with WLAN, the LCD used 76%, the WLAN 6% and the CPU 18% of thepower (cf. Figure 6.2).

58% 33%

9%

Energy Consump.on 3G

LCD

3G

CPU

76%

6%

18%

Energy Consump.on WLAN

LCD

WIFI

CPU

Figure 6.2: Visualized Energy Consumption

These results indicate that the LCD screen is clearly the largest power consumer. More-over, the WLAN module obviously consumes less energy than the 3G module. The usageof a portable WLAN access point instead of the build in 3G-module would therefore de-cline the battery usage. Another possibility would be to deactivate the 3G module andonly operate with 2G. Further tests regarding the power consumption of the 2G moduleand the additional time needed to send the data would be necessary.Furthermore, there is a tradeoff between a big LCD screen which consumes more energybut provides better usability. One solution to overcome this tradeoff would be a mobilebattery charger where the parking inspector could charge the mobile phone during the

6.2. CONTROLLING APPLICATION 45

breaks. Nonetheless, the LCD screen is needed for the PI to cross-check the properties ofthe scanned vehicle.

Results Data Usage The results of the evaluation of the data usage indicate, thatthe mobile application does not consume unnecessary data. The only remarkable dataconsumption is present when the controller attaches photos to fines. All other actions doonly consume less than 1 kilobyte of data (cf. Table 6.5).The current image resolution is set to 50% of the capable quality that the mobile phone’scamera offers. If necessary, this could be set to a higher value to gain better images withthe tradeoff that the sending of a fine with photos takes longer time and more data issent.

Table 6.5: Data Packet‘s Size Exchanged between Controller Application and Server (inBytes)

Action Sent (B) Received (B) File transfer (B)Login 146 18Manual check 202 22QR check 400 22NFC check 400 22Send fine 588 22Send fine with 1 photo 630 22 16625Send fine with 2 photos 676 22 33250Send fine with 3 photos 720 22 49875Send notification 338 22

Chapter 7

Summary, Conclusions and FutureWork

The outcome of this Master Project is a prototype Parking Monitoring and ManagementSolution (PMMS). The key feature of the system is to deliver parking availability estima-tions on a map, based on the data provided by the users and parking inspectors (PI).The developed prototype of the PMMS consists of two front-end applications and a back-end system. The end-user application is publicly available in the Google Play Store forAndroid and in the Apple AppStore for iOS. The multilingual end-user application is ableto show unavailable parking spots on a map, show the local parking regulations and letsthe user park his car. Moreover, a payment mock-interface was developed for demonstra-tion purposes.The controller application is able to check if a vehicle is parked legally by scanning anNFC-tag, QR-code or by entering the license plate manually. If the vehicle is parkedillegally, the PI may send a fine to the holder of the vehicle which is automatically sentby email.To assess the developed system, a simulation to evaluate the parking spot utilization wasmodelled and conducted. The results of this simulation show that the search of a parkingspot with a system that shows parking spot availability is approximately 3.5 to 7.7 timesfaster than a random search.One goal of the PMMS is to increase the productivity of a PI using the controller appli-cation compared to a PI checking the ordinary way. Based on estimations, the increasedproductivity of the PI with the application shows that using the controlling applicationto check cars takes about half of the time than doing it the ordinary way.

In conclusion, the main goal of the Master Project to create a prototype PMMS wasaccomplished. The existing prototype satisfies all given requirements and provides ad-ditional features like a user profile and a car management, too. The evaluation of thesystem shows that both key stakeholder groups, the car drivers and the parking inspec-tors, benefit from the PMMS.Although, no data about existing parking spots were available, the system is able to workwith manually entered parking spots, spots from the available data set for disabled people

47

48 CHAPTER 7. SUMMARY, CONCLUSIONS AND FUTURE WORK

in Zurich, spots gathered with the implemented Capture Spots Application and with livedata from car parks in Zurich and Basel. The system is open for new parking spot dataprovided either by parking providers or from other sources in the future.

The development of this prototype was also confronted with some challenges. The firstchallenge was faced in the limited performance of the Cordova framework when handlinga lot of data points on a map. Several iterations and optimization steps were needed toenable an acceptable user experience when searching for a parking spot. The key to speedup the map functionality was to only show clusters of parking spots and not display everyspot separately.In retrospective, the Cordova framework may not be fully suitable for complex operationson a map. The native implementation for iOS and Android may make the user experiencemore smooth; especially on older devices.Another issue was discovered during the final testing of the controller application was thedifferent quality of GPS signals on different devices. On some devices like the SamsungGalaxy Note 3 the accuracy of the GPS signal is very high while on other devices likethe HTC One (M7) the accuracy is low and unstable. Since this is a device specific issue,a wide-spread evaluation of different devices regarding the GPS accuracy is proposed forthe future.Another challenge that arose during the development of the Master Project was the recentupdate of Apple devices to iOS 8. Especially the Cordova plugins had and still have issuesconcerning the compatibility of the Cordova framework with iOS 8. The plenty updatesand changing environment of the Cordova framework and its plugins need constant focusand care for keeping the project up to date with the newest version of the device and OSAPI’s.Multi-platform application developing faces several problems. By using the Cordovaframework it was at least possible to work with a single code base. However, differentplatforms and also different devices make testing hard, especially on devices in unstableenvironments (e.g. weak internet or GPS signals).

There are several issues that may be resolved in future work. Firstly, a possible way toincrease the usability of the end-user application is the native implementation. Moreover,additional regulations for more cities and communities may improve the quality of theend-user application. Accordingly, additional data about parking spaces in Zurich andother cities would improve the estimation of available parking spots.Another topic for future work is scalability testing of the application with real worldparking spot data of a whole city and with a larger user base. Although the PMMS isdeveloped in a generic approach to fit different needs in different regions, the adaption ofthe system in other countries would demand changes in the front-end applications. Forexample, zip codes and license plates in some countries consist only of numerics while inother countries letters are present, too. Furthermore, the whole payment system has tobe integrated. Additionally, a field test in a small city or area would test the feasibilityof the implemented prototype and probably reveal new and changing requirements.

After the completion of this Master Project, three Master Thesis’ will extend and scien-tifically strengthen the PMMS. The first thesis will improve the parking prediction of the

49

PMMS by implementing a prototype device in the car which handles the parking statusautomatically. The second thesis will identify techniques that would decrease cruising forparking through a parking spot availability prediction model. Lastly, the third thesis willprovide a tool that facilitates an easy management of public parking spots and provideoptimization techniques concerning the public parking spots distributions respecting city’sand canton’s regulations and registered cars density in a given location.

50 CHAPTER 7. SUMMARY, CONCLUSIONS AND FUTURE WORK

Bibliography

[1] Apache Cordova: https://cordova.apache.org, Visited in September 2014.

[2] Apache Cordova Plugins Registry: http://plugins.cordova.io/#/, Visited in Oc-tober 2014.

[3] Apache Cordova: Security Guide, http://docs.phonegap.com/en/3.5.0/

guide_appdev_security_index.md.html , Visited in October 2014.

[4] Apache Tomcat: http://tomcat.apache.org/ , Visited in October 2014.

[5] Apache Tomcat 7: SSL Configuration HOW-TO, http://tomcat.apache.org/

tomcat-7.0-doc/ssl-howto.html , Visited in September 2014.

[6] R. Arnott, T. Rave and R. Schob: Alleviating Urban Traffic Congestion, MIT PressBooks, 2005.

[7] Bundesamt fur Kommunikation BAKOM: Amtliche Fernmeldestatistik 2012,http://www.bakom.admin.ch/dokumentation/zahlen/00744/00746/index.

html?lang=de , Visited in September 2014.

[8] Dataset of Disabled Spots in Zurich: https://www.stadt-zuerich.ch/pd/

de/index/dav/themen_projekte/behindertenparkplaetze/kreis_1_23_

plaetze.html , Visited in November 2014.

[9] S. Diwakar: Titanium vs Phonegap vs Native application development,http://www.sapandiwakar.in/api-research-study-iphone-and-android-

applications/ , Visited in October 2014

[10] eNewsletter , Visited in October 2014.

[11] T. Giuffre, S.M. Siniscalchi and G. Tesoriere: A novel architecture of parking man-agement for smart cities. Procedia - Soc. Behav. Sci. 53, 16-28, 2012

[12] A. Goodwin: Open Spot app helps Android users find parkinghttp://www.cnet.com/news/open-spot-app-helps-android-users-find-parking/ , Visited inOctober 2014.

[13] Google Maps: http://www.maps.google.com , Visited in September 2014.

[14] Google Maps Javascript API v3: https://developers.google.com/maps/

documentation/javascript/?hl=en , Visited in November 2014.

51

https://cordova.apache.org

http://plugins.cordova.io/#/

http://docs.phonegap.com/en/3.5.0/guide_appdev_security_index.md.html

http://docs.phonegap.com/en/3.5.0/guide_appdev_security_index.md.html

http://tomcat.apache.org/

http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html

http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html

http://www.bakom.admin.ch/dokumentation/zahlen/00744/00746/index.html?lang=de

http://www.bakom.admin.ch/dokumentation/zahlen/00744/00746/index.html?lang=de

https://www.stadt-zuerich.ch/pd/de/index/dav/themen_projekte/behindertenparkplaetze/kreis_1_23_plaetze.html



http://www.sapandiwakar.in/api-research-study-iphone-and-android-applications/

http://www.sapandiwakar.in/api-research-study-iphone-and-android-applications/

http://www.cnet.com/news/open-spot-app-helps-android-users-find-parking/

http://www.cnet.com/news/open-spot-app-helps-android-users-find-parking/

http://www.maps.google.com

https://developers.google.com/maps/documentation/javascript/?hl=en

https://developers.google.com/maps/documentation/javascript/?hl=en

52 BIBLIOGRAPHY

[15] IDC: Worldwide Mobile Phone Market Forecast to Grow 7.3% in 2013 Driven by 1 Bil-lion Smartphone Shipments, http://www.idc.com/getdoc.jsp?containerId=

prUS24302813 , Visited in September 2014.

[16] ISO 639 language codes http://www.iso.org/iso/home/standards/language_codes.htm , Visited in November 2014.

[17] Java Servlets http://www.oracle.com/technetwork/java/index-jsp-

135475.html , Visited in October 2014.

[18] jQuery http://jquery.com/ , Visited in October 2014.

[19] jQuery mobile http://jquerymobile.com/ , Visited in October 2014.

[20] JsonRpc: https://github.com/RitwikSaikia/jsonrpc , Visited in October2014.

[21] JUnit: http://junit.org/ , Visited in November 2014.

[22] S. Mathur, T. Jin, N. Kasturirangan, J. Chandrasekaran, W. Xue, M. Gruteser andW. Trappe: Parknet: drive-by sensing of road-side parking statistics, ACM MobiSys,2010.

[23] E. McConnell: Boundaries, Deliverables And Requirements As Key ComponentsOf Project Scope, http://www.mymanagementguide.com/project-boundaries-project-deliverables-and-project-requirements-as-key-components-of-

project-scope/ , Visited in October 2014

[24] G. J. Myers, C. Sandler and T. Badgett: The Art of Software Testing, John Wiley& Sons, 2011.

[25] MySQL Database http://www.mysql.com/ , Visited in October 2014.

[26] Park it http://www.parkit.ch , Visited in September 2014.

[27] Parkkarten & Bewilligungen, Stadt Zurich: https://www.stadt-zuerich.ch/pd/de/index/dav/parkkarten_bewilligungen.html , Visited in October 2014.

[28] Parkleitsystem Basel http://www.parkleitsystem-basel.ch/stadtplan.php ,Visited in September 2014.

[29] Parkleitsystem Zurich http://www.pls-zh.ch/ , Visited in September 2014.

[30] Parku http://www.parku.ch , Visited in September 2014.

[31] Project Webpage http://parkitsmart.com/ , Visited in October 2014.

[32] Power Tutor 2 https://play.google.com/store/apps/details?id=com.

henny.PowerTutor2&hl=de , Visited in November 2014.

[33] Redmine http://www.redmine.org/ , Visited in October 2014.

[34] SBB P+Rail http://www.sbb.ch/en/station-services/car-bike/parking/parking-at-the-station.html , Visited in October 2014.

http://www.idc.com/getdoc.jsp?containerId=prUS24302813

http://www.idc.com/getdoc.jsp?containerId=prUS24302813

http://www.iso.org/iso/home/standards/language_codes.htm

http://www.iso.org/iso/home/standards/language_codes.htm

http://www.oracle.com/technetwork/java/index-jsp-135475.html

http://www.oracle.com/technetwork/java/index-jsp-135475.html

http://jquery.com/

http://jquerymobile.com/

https://github.com/RitwikSaikia/jsonrpc

http://junit.org/

http://www.mymanagementguide.com/project-boundaries-project-deliverables-and-project-requirements-as-key-components-of-project-scope/



http://www.mysql.com/

http://www.parkit.ch

https://www.stadt-zuerich.ch/pd/de/index/dav/parkkarten_bewilligungen.html

https://www.stadt-zuerich.ch/pd/de/index/dav/parkkarten_bewilligungen.html

http://www.parkleitsystem-basel.ch/stadtplan.php

http://www.pls-zh.ch/

http://www.parku.ch

http://parkitsmart.com/

https://play.google.com/store/apps/details?id=com.henny.PowerTutor2&hl=de

https://play.google.com/store/apps/details?id=com.henny.PowerTutor2&hl=de

http://www.redmine.org/

http://www.sbb.ch/en/station-services/car-bike/parking/parking-at-the-station.html

http://www.sbb.ch/en/station-services/car-bike/parking/parking-at-the-station.html

BIBLIOGRAPHY 53

[35] SFpark http://sfpark.org , Visited in October 2014.

[36] I. Sherwin: Google Labs’ Open Spot: A Useful Application That No One Useshttp://www.androidauthority.com/google-labs-open-spot-a-useful-

application-that-no-one-uses-15186/ , Visited in October 2014.

[37] JH. Shin and HB. Jun: A study on smart parking guidance algorithm, TransportationResearch Part C: Emerging Technologies, 2014.

[38] S. Shin: Introduction to JSON (JavaScript Object Notation), http://www.cse.

iitd.ac.in/~cs5090250/JSON.pdf , Visited in October 2014.

[39] D. Shoup: Cruising for parking, Access, 2007.

[40] SQL Injection, http://www.w3schools.com/sql/sql_injection.asp , Visitedin November 2014.

[41] Stadt Zurich Tiefbau- und Entsorgungsdepartement: Wirtschaftliche Be-deutung von Parkplatzen in der Stadt Zurich, Press Conference of 13.May 2011, https://www.stadt-zuerich.ch/content/dam/stzh/ted/

Deutsch/taz/Mobilitaet/Publikationen_und_Broschueren/Parkierung/

MM_WirtschaftlicheBedeutugParkplaetze.pdf , Visited in November 2014.

[42] W. Stallings: NETWORK SECURITY ESSENTIALS: APPLICATIONS ANDSTANDARDS, 5th Edition, Prentice Hall, 2013.

[43] StartSSL, https://www.startssl.com/ , Visited in October 2014.

[44] A.S. Tanenbaum and M. van Steen: Distributed Systems: Principles and Paradigms(2nd Edition), Prentice-Hall Inc., Upper Saddle River, NJ, USA, 2006.

[45] Weisung des Stadtrats von Zurich an den Gemeinderat: Motion von Gian von Plantaund Markus Knauss betreffend Strassenparkplatze in der Innenstadt, Preiserhohungfur eine lenkungswirksame und effiziente Nutzung http://www.gemeinderat-

zuerich.ch/Geschaefte/detailansicht-geschaeft/Dokument/644ffb82-

d1e1-4520-9a73-5b892e537a2e/2014_0306.pdf , Visited in November 2014.

[46] Wordpress, https://wordpress.org/ , Visited in November 2014.

[47] XML-RPC, http://www.w3.org/2000/03/29-XML-protocol-matrix/ , Visitedin October 2014.

http://sfpark.org

http://www.androidauthority.com/google-labs-open-spot-a-useful-application-that-no-one-uses-15186/

http://www.androidauthority.com/google-labs-open-spot-a-useful-application-that-no-one-uses-15186/

http://www.cse.iitd.ac.in/~cs5090250/JSON.pdf

http://www.cse.iitd.ac.in/~cs5090250/JSON.pdf

http://www.w3schools.com/sql/sql_injection.asp

https://www.stadt-zuerich.ch/content/dam/stzh/ted/Deutsch/taz/Mobilitaet/Publikationen_und_Broschueren/Parkierung/MM_WirtschaftlicheBedeutugParkplaetze.pdf



https://www.startssl.com/

http://www.gemeinderat-zuerich.ch/Geschaefte/detailansicht-geschaeft/Dokument/644ffb82-d1e1-4520-9a73-5b892e537a2e/2014_0306.pdf



https://wordpress.org/

http://www.w3.org/2000/03/29-XML-protocol-matrix/

54 BIBLIOGRAPHY

Abbreviations

API Application Programming InterfaceCA Certificate AuthorityCO CompetitorsCPU Central Processing UnitCSG Communication Systems GroupCSS Cascading Style SheetGPS Global Positioning SystemHTML Hypertext Text Markup LanguageHTTP Hypertext Transfer ProtocolID IdentificationIoT Internet of ThingsJSON JavaScript Object NotationLAN Local Area NetworkLCD Liquid-Crystal DisplayMD5 Message-Digest Algorithm 5MNO Mobile Network OperatorNFC Near Field CommunicationPI Parking InspectorPMMS Parking Monitoring and Management SolutionPP Parking ProviderPSP Payment Solution ProviderP+rail Park and RailRPC Remote Procedure CallRSS Rich Site SummarySBB Schweizerische BundesbahnenSQL Structured Query LanguageSSL Secure Socket LayerUI User InterfaceWLAN Wireless Local Area NetworkXML Extensible Markup Language

55

56 ABBREVIATONS

Glossary

Android A mobile operating system based on the Linux kernel and currently developedby Google.

Apple AppStore Digital distribution platform for mobile applications on iOS, devel-oped and maintained by Apple Inc.

Application Programming Interface Defines functionalities that are independent oftheir respective implementations, which allows definitions and implementations tovary without compromising each other.

Apache Cordova An open-source mobile development framework that enables softwareprogrammers to build applications for mobile devices using JavaScript, HTML5,and CSS3.

Apache Tomcat Open-source web server and servlet container developed by the ApacheSoftware Foundation.

Authorization Authorization is the decision whether an entity is allowed to perform aparticular action or not, e.g. whether a user is allowed to login in the PMMS.

Blue Zone Parking Parking spot in Switzerland without charge for a limited duration.

Cascading Style Sheet Style sheet language used for describing the look and format-ting of a document written in a markup language.

Certificate Authority Entity that issues digital certificates.

Global Positioning System Space-based satellite navigation system that provides lo-cation and time information.

Google Play Store Digital distribution platform for mobile applications on Android,operated by Google.

Hypertext Text Markup Language Standard markup language used to create webpages.

Identification Act of finding out who someone is.

Internet of Things Interconnection of uniquely identifiable embedded computing de-vices within the existing Internet infrastructure.

57

58 GLOSSARY

iOS Mobile operating system developed by Apple Inc. and distributed exclusively forApple hardware.

jQuery Cross-platform JavaScript library designed to simplify the client-side scriptingof HTML.

jQuery Mobile Touch-optimized web framework based on a JavaScript library.

JavaScript Dynamic computer programming language mostly used for the implementa-tion of client-side scripts to interact with the user.

JSON An open standard format using human-readable text to transmit data objectsconsisting of key-value pairs.

Master Project Large teamwork project of 2 to 4 students working on a subject whichis closely related to one of the research groups at the department of informatics (ifi).

MD5 Hash Cryptographic hash function producing a 128-bit hash value commonly usedto verify data integrity.

MySQL Widely used open-source relational database management system.

NFC-Tag Near Field Communication is a form of short-range wireless communication.NFC-Tags are stickers with a chip that can be programmed and then be read fromNFC readers.

Parking Provider Authority or Company that offers parking spaces.

Parking Inspector A member of a traffic control department or agency issuing ticketsfor parking violations.

Payment Solution Provider A Payment Solution provider offers (web) shops onlineservices for accepting electronic payments (E.g credit card).

QR-Code Quick Response Code is a trademark for a type of matrix barcode. A barcodeis a machine-readable optical label that stores information.

Rich Site Summary Often called Really Simple Syndication, are standard web feedsto publish frequently updated information. (E.g blog entries, news headlines, audio,video).

Redmine A flexible project management web application.

JSON-RPC A remote procedure call is an inter-process communication that allows acomputer program to cause a subroutine or procedure to execute in another addressspace. JSON-RPC is a remote procedure call protocol encoded in JSON.

SBB CFF FFS Abbreviaton in German, French and Italian of the Swiss Federal Rail-ways.

SBB P+Rail Parking spots offered by SBB to park the car and to change to the train.

59

Secure Socket Layer Standard security technology for establishing an encrypted linkbetween a server and a client. It provides security services between TCP (Trans-mission Control Protocol) and applications that use TCP.

Smart City Conceptual view of a city that promotes the use of information and com-munication technologies (ICTs) to engage with citizens.

User Interface Space where interactions between humans and machines occur.

White Zone Parking Type of parking spot in Switzerland. White park areas areequipped with parking meters. Depending on the location, a limited or unlimitedduration is allowed.

Wordpress Web software to create a beautiful website or blog.

3G 3G is the short form of third Generation, which stands for the third generation ofmobile telecommunications technology.

60 GLOSSARY

List of Figures

3.1 The Boundary Map of the PMMS Master Project . . . . . . . . . . . . . . 11

3.2 Stakeholders Map of the PMMS Master Project . . . . . . . . . . . . . . . 12

3.3 Risk Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 Client-Server Architecture with Three Layers [44] . . . . . . . . . . . . . . 18

4.2 The Overall Architecture of the PMMS . . . . . . . . . . . . . . . . . . . . 18

4.3 The Technology Stack of the Used Frameworks for the Front-End Applications 20

4.4 The Build Process of the Front-End Applications . . . . . . . . . . . . . . 21

5.1 UI-Screens - Vehicle Check . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2 UI-Screens - Fine Management . . . . . . . . . . . . . . . . . . . . . . . . 25

5.3 UI Screens - Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.4 UI Screens - Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.5 UI Screens - Park . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.6 UI Screens - Parking Management . . . . . . . . . . . . . . . . . . . . . . 29

5.7 UI Screens - Login, Profile and Parking Regulation . . . . . . . . . . . . . 29

6.1 Example Simulation with two Cars . . . . . . . . . . . . . . . . . . . . . . 40

6.2 Visualized Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . . 44

61

62 LIST OF FIGURES

List of Tables

3.1 Stakeholder Analysis of the PMMS Master Project . . . . . . . . . . . . . 12

3.2 Risks of the PMMS Project . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6.1 Scenario 1: One Square Kilometer in the City Center of Zurich at Noon . 39

6.2 Scenario 2: One Square Kilometer Outside the City Center of Zurich at10.00 in the Morning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.3 The Result of the Simulation (The Ratio Determines the Benefit of theApproach with Availability Information Compared to the Random One) . 41

6.4 Data Packet‘s Size Exchanged between End-User Application and Server(in Bytes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.5 Data Packet‘s Size Exchanged between Controller Application and Server(in Bytes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

63

64 LIST OF TABLES

Appendix A

Intellectual Property

All rights of the source code of the PMMS are reserved to Livio Hobi, Fabian Hofstetter,Samuel Liniger, Christos Tsiaras, the Communication Systems Group (CSG) and theUniversity of Zurich.

65

66 APPENDIX A. INTELLECTUAL PROPERTY

Appendix B

Installation Guidelines

To install the end-user application, follow the link to the Google Play Store or the AppleAppStore:

• Android: https://play.google.com/store/apps/details?id=uzh.csg.pmms

• iOS: https://itunes.apple.com/us/app/parkitsmart/id937344967?l=de&ls=

1&mt=8

67

https://play.google.com/store/apps/details?id=uzh.csg.pmms

https://itunes.apple.com/us/app/parkitsmart/id937344967?l=de&ls=1&mt=8

https://itunes.apple.com/us/app/parkitsmart/id937344967?l=de&ls=1&mt=8

68 APPENDIX B. INSTALLATION GUIDELINES

Appendix C

Contents of the CD

Zusfsg.txtGerman version of the abstract of this thesis.

Abstract.txtEnglish version of the abstract of this thesis.

MasterProjectReport.pdfDigital copy of this report

PMMS prototype/

• 1 End-User Application - Source code of the parkITsmart application

• 2 Controller Application - Source code of the controller application

• 3 Back-End System - Source code of the back-end servlets used by the end-user andcontroller applications including unit tests.

• 4 Additional Supportive Work -Source code of the RSS crawler, capture spots appli-cation and the parking spot generator.

• 5 Evaluation Source -Source code of the simulation

• 6 Presentations - Intermediate and final presentation

• 7 Related Work - Folder which contains related work papers and publications

• 8 Report Source - Written report source files including figures as sources

• install-guide.txt - Step-by-step guide to install the prototype on different devices

• accounts.txt - List of accounts and credentials used in the system

69

parking monitoring and management solution (pmms) · parking monitoring and management solution...

Documents