Identifying new EV charging station locations based on user trip data

(1)

Bachelor Project

ChargeQuest

^c

Identifying new EV charging station locations based on user trip data

Authors:

A.J.H. Sigtermans (s1914766) J. van Breemen (s2262967)

K.Y. Kliffen (s2369494)

Supervisor:

prof. dr. A. Lazovik

July 2

^nd

, 2015

(2)

1 Project description

This study focuses on the growth of electric vehicle supporting infrastructure. Over the past years, electric vehicle usage has been on the rise, and technologies that have been researched for years start to get ready for the consumer market. The use of electric vehicles is growing rapidly, and the Netherlands currently has one of the highest coverages in both charging stations as well as electric vehicles (of course, in relation to the number of inhabitants) [21]. For example, the Netherlands currently has over 7600 charging stations. That’s the highest number in any of the EU countries, with Germany (a substantially bigger country in terms of both population and area) taking a second place with approximately 3800 charging stations. Though electric vehicles

Figure 1: Charging station coverage in the EU (chargemap.com)

are being adopted quickly, the main bottleneck for massive growth remains the limited range.

Whilst researchers, engineers and car manufacturers focus on increasing battery capacity (with very promising results shown by companies such as Tesla), it is up to local governments, infrastructure providers and electric utility companies to improve the infrastructure for recharging electric vehicles.

This study will focus on helping these last mentioned parties to gather insights on where to place new charging stations, based on the needs of both current electric vehicle drivers, as well as future electric vehicle drivers. By gathering data on driving behaviour (trips), processing it (adding weights and distinguishing variables), and analyse it, new charging station locations will be identified, helping the before mentioned parties to grow the electric vehicle infrastructure in an efficient manner, onwards to a ’global’ coverage, similar to that of fossil fuels.

Though this study focuses on the situation in the Netherlands, which already has a high density of charging stations, it will be of great importance to other countries that are in an earlier stage of electric vehicle infrastructure development. The Netherlands is a good reference case since a

’general’ coverage has already been realised, and efficient and optimised decisions hence are of greater importance. Furthermore, the methods described for identifying charging stations will not only be applicable to supplying electricity (recharging facilities) but can, with the right interpretation and constraints, also be applied on other (renewable) fuels that are not yet broadly available.

(5)

1.1 Domain definitions

As follows from the above introduction, this study will discuss many topics regarding electric vehicles. For context, and to avoid confusion due to different interpretations, some definitions from the electric vehicle domain will be given below. The terms explained here will be frequently used throughout this thesis.

Hybrid Electric Vehicles A Hybrid Electric Vehicle (HEV) combines a conventional internal combustion engine (ICE) with an electric propulsion system. The electric propulsion system is used for either fuel efficiency improvements, or performance improvements. The electricity for the electric motor is provided by a generator linked to the ICE, or a battery that is charged through regenerative breaking.

Plug-in Hybrids Electric Vehicles A Plug-in Hybrid Electric Vehicle (PHEV) is the same as a HEV, except that it’s battery can be charged by external power sources, and hence generally has larger capacity (allowing for some kilometers of pure electric driving). In some cases the car is fully driven by the electric motors, where the ICE only serves as generator to recharge the battery whilst driving. Traditional fuel sources such as petrol are still considered to provide a large amount of the power needed to drive these cars. Battery capacities of PHEV’s are limited, with a typical 30-80 kilometers of full electric range.

Electric Vehicles with Range Extender An Electric Vehicle (EV) with Range Extender (RE, combined sometimes named EV-RE), is an electric car that has a (small) traditional petrol engine that allows to recharge the battery if the driver has used up all of the battery’s capacity. Electricity is considered to be the main power source for these cars, with small fuel tanks for the range extending petrol engine. Battery capacities typically allow for 80-200 kilometers of full electric driving.

Full Electric Vehicles Full Electric Vehicles are vehicles that are powered by an electric motor, that only draws power from the drive battery. There are no other fuel sources than energy involved. Electric vehicles can be recharged, and apply techniques such as regenerative braking to efficiently use their battery charge. Battery capacities typically allow for 150-300 kilometers of fully electric driving, though there are some exceptions either in the low and high range (for example: Tesla currently offers cars with a range of up to 400 kilometers).

Range Anxiety Range Anxiety is the fear to run out of battery capacity before reaching your destination (or a charging station), as experienced by car owners of electric vehicles, i.e.

stranding roadside with no power remaining in the car battery.

Battery When referring to the battery, this study is referring to the battery used to power electric motors (also referred to as ’drive battery’ by some manufacturers). There might be some confusion on this topic as all types of cars also have a (small) battery for on-board computers, starting the engine, etcetera.

1.2 Main goal

(6)

1.3 Research questions

To achieve the before-mentioned goal and answer the main research question, several additional and more specified research questions have been defined. Their answers put together will form a concrete proposal on how to achieve the goal specified. Below, the questions will be specified.

For each question, an overview of the proposed research to answer the question will be given, as well as deliverables described later on in this thesis, related to the question.

The first research question focuses on the gathering of data: what sources are available?

What new methods can be developed to gather data? How can data be gathered from users (what incentives are needed)? This leads to the following research question:

How can we gather data on the need and future need of electric vehicle charging stations from both current, but more importantly, future customers?

To answer this question, first this study will identify the data needed, based on various other studies on driver behaviour, and the other research questions posed. Afterwards, various available data sources will be evaluated, as well as new methods to gather data. Finally, preliminary conclusions will be drawn to determine the data needed and relevant sources and/or methods to gather this data. This will pose as input to the other research questions, and will help to reach the main goal.

The second research question focuses on the processing architecture needed for the data to be gathered, as well as the analysis to be performed on the data gathered. The implementation of the answer to the first research question poses new questions: large amounts of data will be gathered, but where and how to store them? Various factors will have to be taken into account, not only those related to the gathered data, but more importantly factors related to further processing and analysis of the data. This leads to the following research question:

How can we design a data storage and processing architecture that allows for easy processing and statistical analysis of the data gathered?

To answer this question available techniques and platforms will be evaluated. Furthermore, the setup of similar studies will be evaluated and might be used as an example. Also, studies that compare various techniques or platforms will be consulted to draw conclusions on an optimal architecture to support data gathering and analysis. The answer to this question will help build a solid foundation for analysing the data, based on the answers to the third and last research question.

The third and last research question focuses on analyzing the gathered data to result in advice on the placement of new charging stations (to achieve the main goal of this study), and builds heavily upon the answers to the two research questions posed in advance. The data gathered represents many individual needs. These will need to be weighted and afterwards clustered to identify new charging station locations as every evidently cannot be addressed in- dividually. This leads to the following research question on analysis:

How can we analyze gathered data, and process it into valuable conclusions that inform local authorities and other service providers with desired charging station locations?

The answer to this question will denote the analysis ’pipeline’ to be used on the data gathered.

As with the two other questions, existing studies will be analyzed. In this case on geographical data analysis and clustering. Various clustering methods will be identified, and compared. The answer to this question will consist of a description of the analysis procedure to follow for the gathered data, as identified by the first research question, using the architecture as outlined

(7)

based on the second research question.

(8)

2 Problem statement

Though the research questions give a good overview of the goals of this study, they are still broad and can be interpreted in many ways. Therefore, this section will focus on defining the problem statement: what is the problem at hand, and what exact question does this study aim to answer.

2.1 Definitions

Many of the terms used in relation to electric vehicles, charging, and renewable and durable initiatives like the ones proposed in this study have a very broad interpretation. Therefore, to correctly define the problem statement, first some definitions will be explicitly specified below.

Each definition will be summed up in one line, with some further explanation as to why this definition is chosen below, for interested readers and more context.

Electric Vehicles

Cars with an electric motor used for its propulsion, that are powered by a battery that can be recharged from an external energy source.

Electric Vehicles (EVs) come in many forms. They share one property that defines them as electric vehicles; that is that electric motors or battery systems in some way assist in the propulsion of a car. That indeed is a very broad term, and therefore, the definition of EVs in this study will be narrowed down. In the problem description, the various types of EVs have already been described. From those definitions, the Full Electric Vehicle would be the most interesting subject in a study that aims to focus on full electric driving. However, both Electric Vehicles with Range Extender as well as Plug-in Hybrid Electric Vehicles (though to a lesser extent) are still capable of drastically reducing CO2-emissions by optimally making use of their battery and it’s range.

Hence, those can be considered when evaluating needs for charging stations. Identifying the points where the batteries of these types of cars need to be recharged, and trying to fulfill this demand by identifying new charging station locations will result in Full Electric Vehicle charac- teristics for these vehicles as well.

Hybrid Electric Vehicles will be disregarded in this study, as they only use technology such as batteries and electric motors to regenerate electricity or drive more efficiently: they are not dependent on recharging and hence not dependent on charging stations, or the location of future charging stations.

Charging stations

Physical location defined by GPS-coordinates, with a defined number of outlets that can be used to recharge Electric Vehicles. A charging station can be either a local charging station (bound to a home, office or other physical location), or an on-route charging station located alongside driving routes that offers fast- charging capabilities.

Charging station is a very wide definition for all sorts of devices, locations and adaptors that can be used to charge electric vehicles. In this study, a charging station is defined as a physical location that offers one or more outlets using which an electric vehicle battery can be charged.

The number of outlets at one charging station can be relevant in terms of capacity, but will be mostly ignored in this study as capacity problems are a problem of its own. The location of charging stations will be identified using GPS-coordinates (latitude and longitude). This study will focus on location and coverage of charging station infrastructure, rather than individual charging station capacity. Also, various standards exist for charging. That is, various connectors or protocols exist that might influence a car’s capability to charge at a certain charging station.

(9)

A standard is however forming[20], and standardisation as well as compatibility will only increase. Again, we will focus on location not technology or other local problems.

A very important difference in charging station outlets is however their possibility to fast charge or not. Furthermore, two types of locations exist for charging stations: charging stations that are located at ‘parking’ or ‘static’ locations, such as homes, offices, city centres. This study will from now on refer to those as ‘local charging station’. And charging station locations that are located on-route, so, along highways, main roads, hubs, or other locations that people (car owners) do not regularly spent large amounts of time. This study will from now on refer to those as

‘on-route charging stations’.

Though some deviations occur, this study will assume that all on-route charging stations are equipped with fast chargers (allowing to indeed recharge on-route), and that local charging stations are either fast chargers (however with limited use at cars will be parked there for a longer time) or ‘regular’ chargers (taking a longer time of 3-8 hours to fully recharge a car battery). Please note that also with ‘regular’ chargers there is a variation in the time needed to fully charge a car, although this also depends on the car itself. All charging times are however considered too long for an on-route stopover.

This study will mainly focus on identifying new locations for on-route charging stations. Though suggestions will be made on the identification of new local charging stations, or how the data gathered can be used for this purpose, the main goal will remain to identify on-route charging stations. This follows from the problem statement defined below; the study focuses on increasing the coverage of charging stations, rather than on local issues.

Trip

A route that is driven by a user, denoted by a start- and endpoint, and intermediate waypoints approximately 250 meters apart. All points consist of GPS-coordinates (latitude, longitude) and a timestamp.

Trips are the basic data element that will be used in analysis done by this study. Trips identify a series of points that together represent an actual driven route. Whereas many datasets only denote single points, with no relation between them, this study proposes to track full routes of users, as the relation between points is relevant for determining new charging station locations.

User driving behaviour

The behaviour of users (car owners) denoted by trips he or she makes.

User driving behaviour is a term that will be mentioned both in the problem statement and various other parts of this study. Of course, this is a term open to broad interpretation. From anything as wide as driving speed, to aggressive or slow driving, etcetera.

(10)

Transition to Electric Vehicles

The increase of electric vehicle use as promoted by governments, as facilitated by infrastructure growth and technical developments, and as accelerated by growing scarcity of fossil fuels and the hence increasing prices of these fuels.

The transition to electric vehicles form part of the underlying motivation for this study, and hence it is denoted here. When referring to it in this study, it represents the plans and goals governments announce and the global awareness of the need to use more electric powered vehicles due to their increase efficiency with respect to petrol fueled cars, and the possibilities of generating energy from renewable sources (whereas these options are limited and still cause CO2-emissions for fossil fuels). The transition includes development of batteries with increased capacity, stimulating people to buy electric vehicles rather than petrol fueled cars, and of course expanding the infrastructure needed to use electric vehicles. The latter is most important in this study, it is what this study aims to contribute to.

2.2 Problem formulation

Given the current coverage of electric vehicle charging stations, and the current ongoing transition to electric vehicles,

Where should new charging stations be located to match user driving behaviour and hence assist in the adoption of electric vehicles.

To answer this question will be the main goal of this study. Stakeholders involved are the AutoJUICE project, local governments, and private companies involved in the EV market.

Besides locating new charging stations, the answers to this question but more importantly the underlying research will serve to prove how user driving behaviour can be an accurate measure and needs to be incorporated in future infrastructure decisions such as the placement of EV charging stations.

Current coverage refers to the electric vehicle charging stations that already exist. This study uses open data sources on charging stations such as openchargemap.io as a reference for this.

(11)

3 Methods to gather data

The first research question of this thesis focuses on how to gather valuable data, that can later be used to create valuable insights and draw conclusions as to where to place new charging station infrastructure (the main goal of this project). Of course, there are numerous ways in which data can be gathered. However, data can be of different qualities: is it as useful and significant as other data? More importantly, from which group of users is data gathered? In this specific research topic, it is very important to first of all define the target group, or target audience, that will allow to identify new charging station locations. Gathering data from the wrong group of users could lead to useless conclusions (e.g., when gathering data from truck drivers, one would be able to validly determine new charging station locations, those would however be of no value since truck drivers are not in need of charging stations, at this point in time).

Having identified the target group for gathering data, it is of course important to first of all denote what exact data, better said variables, need to be gathered. What variables are needed to make valid conclusions, and answer the research questions posed. Together with the target audience, this forms a concrete description of the data needed.

Furthermore, one has to think of how the data gathering method can actually be performed in reality: though having users input their exact behaviour in to a statistical software package might give the most accurate data, it may not yield much data, as it is too difficult or time consuming for users. Various methods will need to be elaborated.

In this study, three methods of gathering data will be evaluated:

• Existing data sources

• Gathering data through submission systems (inquiry-style)

• Gathering data through tracking applications

(12)

3.1 Data needed

Before going into further detail on either of those methods, it’s important to identify the data one wants to have available: what is the data model an existing data source must be able to comply to, in order for it to be viable data. The main need that will be identified in later parts of this thesis is a route that a car travels along. That includes not only destination and source, but also some waypoints on the route, to be able to describe the route. After all, this research aims to find new charging station locations, and those need to match the actual needs, implying the actual routes driven are to be considered (not just any route from destination to source).

Of course, after clustering data from various drivers, conclusions may be reached where some drivers will need to take alternate routes in order to make their trip using electricity only.

Various other papers and research projects on electric vehicles have questioned what data is needed to form conclusions on driving behaviour, routes, or new charging station locations.

They confirm a data model that saves route data.

The research of Xiaomin Xi, Ramteen Sioshansi and Vincenzo Marano [16] uses regions and states to identify routes. It states that at least routes between these regions as well as a source and destination need to be saved. Additionally, they save trip time, which is relevant as it decreases electric vehicle range. For example, when waiting in traffic jam, the range decreases, which implies a need for a charging station closer than one might expect based solely on the route (distance).

Other papers, such as that of Sung Hoon Chunga and Changhyun Kwon[17], that mainly focuses on using existing data (in this specific case from the Korea Expressway Corporation), suggest looking at routes (destination-origin) only, and discarding shorter routes. They denote the number of vehicles travelling on a certain route rather than registering individual routes.

This system is very similar to a flow system (with a source and sink) and allows for easy math- ematical modelling. It does however lack detail if all roads are to be considered; it only focuses on main highways.

Further research shows that many studies use existing traffic data, proving that this can be useful in the determination of new charging station locations. These are however all studies focused on identifying highway and main road charging station locations only.

Before continuing, it is important to also recall the distinction between two types of charging stations as made in the problem statement, namely that of on-route and local charging stations, and identify which implications their specifications have on the data that needs to be gathered.

On-route charging stations These charging stations are located on-route, and used to extend range of a single route. This will mainly to solely be fast charger charging stations, that recharge the car battery up to 80% in a short amount of time (taking 10 minutes up to 1 hour). The 80% threshold has to do with technical working of batteries and their charging processes, which this research will not further elaborate on as it is out of scope and widely discussed and explained elsewhere. There is no economically viable market for a recharge that takes 5-8 hours (dependent of the car model and battery capacity) on-route (evidently, no car owner would want to be waiting this amount of time at a roadside petrol station).

To indicate future on-route charging station locations information on the route taken is important, as well as the “status” of the car at a given point in that route: what is the remaining range, based on factors such as battery capacity. Together, these information points will allow to identify areas of demand for charging stations (i.e. where car batteries are empty given their starting point with full charge).

Local charging stations These are charging stations that are located at the start- and endpoints of a car owners’ route. They are located in residential areas, at office spaces, and in city

(13)

centres. These charging stations offer cheaper and full recharge of a car battery, though charging can take three up to eight hours. Indicating new locations for such local charging stations can be based on the same data as on-route charging station, however only the start- and endpoints would be of interest in this case. Car status is of less influence, and hence other more simplistic data sources that only indicate locations where EV car owners are present are viable data sources for identifying new charging station locations of this type.

In addition to all that is mentioned above, it is of course important to note that a point would consist of latitude and longitude coordinate, as this has internationally been established as the standard way to indicate a location (and many services like GPS offer us ways to retrieve these points).

In addition to the above, it is important to determine the target audience, from which this study would like to gather data. In this case, that would be both EV driver, as well as future EV drivers, that might buy an electric vehicle. In all cases, the target audience consists of drivers of consumer-size vehicles, not trucks.

Concluding, the data needed can be described as follows:

The data needed to decide where to place new EV on-route as well as local charging stations does not only consists of points, but of an start- and endpoint, and waypoints between these two points, which together represents a trip made by a car owner. Hence, trips consisting of a start- and endpoint, and intermediate points should be collected, where points are denoted by their GPS latitude and longitude coordinates. This data should be collected from both current and future drivers of EVs, where EVs are consumer-sized vehicles. Additional parameters may be added to broaden the possibilities for analysis later on.

(14)

3.2 Existing data sources

Having identified the data needed, data sources now need to be found. First of all, existing data sources are evaluated. Those can be split up into two types of data sources: data sources that gather data for the same purposes (route-tracking), and data sources for other applications that, with the right transformations, might yield the needed data.

Many existing studies make use of traffic data from governments or navigation- and map suppli- ers. Those can be categorised as non route-tracking data (which can only be used for identifying local charging station locations). These data sources provide information on traffic flows, and individual locations of cars, but not on routes taken by a car. Given this data, assumptions will need to be made on the actual routes (source-destination pairs) car owners take. Hence, this data is only of limited value. Transforming it into some sort of route-form would yield inaccu- rate data, that might even be false.

Much more interesting is data gathered with route tracking in mind. Many applications of such route trackers are already in place, especially in the business-driver market, which is of particular interest for the EV market as well (many business-drivers commute a lot, with the exceptional customer visit, where they will need to recharge on-route or on destination).

Many companies already track vehicles they own, manage or rent for other practises, such as anti-theft, legal requirements (tax-related), fleet management and policy supervision. An overview of these existing external data sources available is given below:

Lease car companies Lease car companies equip some of their cars with tracking software for administrative purposes, or insurance purposes (in the case of expensive or exclusive cars).

Some only allow for location tracking, whilst others in some cases also allow for route tracking.

Large corporations Large corporations tend to track their cars, for both policy supervision (do employees use their cars for the right reasons) and tax-related administration. These companies are also a target group for research on the possibilities of EV-driving. Hence, this would form a great resource of data. Their main goal for collecting data are administrative tax related purposes, which only require a start- and endpoint. Though routes may be guessed from this data, the exact routes taken are not identifiable by this measure.

Hence, the data is again of limited value for on-route charging station locations, though very useful and accurate for local charging station locations.

Insurance companies Insurance companies sometimes request GPS tracking facilities in cars, or give car owners discounts when their car is equipped with such a system. Hence, another great resource of tracking data. The data is linked to a car, so more usable than unlinked traffic data. However, in these systems routes are mostly untracked. However, with correct analysis (detecting differences in movement), this data can be converted to the data model described before.

Tracking apps Many apps have been developed for car owners to track their own routes. Espe- cially amongst small business owners (freelancers), these apps are popular as they allow for easy administration of their driving for tax purposes. This data would match the data need as described previously, and is also linked to individual users.

Concluding, some of these existing service could be used as a basis for route tracking data that reflects user driving behaviour, however, the data is not always accurate, and gathering large amounts of data might be difficult due to privacy or other restricting measures from companies not willing to share their data.

(15)

3.3 Gathering data through submission systems (inquiry-style)

Though existing data sources allow for easy data gathering (the data only needs to be filtered and processed), and hence may yield large quantities of data, the quality of this data can be somewhat poor. Especially since many of the existing data sources don’t register routes, or only a source and destination. For research on the placement of new charging stations, detailed information on a route would be the preferred data source. One way to obtain such data is to ask users to submit this data. This can be done either by offline summaries, however those would require lots of administration. Furthermore, users might render data irrelevant before they submit it, whilst that data (route) would actually be relevant to this study. This is not desired if one wants to get an accurate view of all the routes a car owner takes.

A company called Allego, based in the Netherlands, has created a platform that uses a web portal to gather data. They introduced a service called openbaarladen.nl, which allows local governments (municipalities) to open up a web portal where users can submit their requests and desired locations for new charging stations. This system however only allows users themselves to identify new locations for charging stations, and does not calculate these locations based on actual car owner driving patterns. Questions can be raised as to whether charging station locations requested by users increase the overall coverage of charging station infrastructure. Systems and portals like these might only render new charging station locations that are of use to a single car owner only; not to the infrastructure coverage as a whole. Hence, this type of data would mainly be of use to determining new locations for local charging stations.

Of course, an inquiry or web portal as that designed by Allego could also be designed to allow for user input of routes driven. Many fellow researchers however state in their findings that inquiries on driving behaviour or routes are expensive, may easily produce bias due to the design of the questionnaire or tool, and that it is hard to gather large quantities of data[18].

(16)

3.4 Gathering data through tracking applications

As can be (preliminary) concluded from the previous two sections on data gathering methods, it is hard to gather data needed for identifying new fast (on-route) charging station locations.

Especially those stations are needed to improve the charging station infrastructure, and hence extend electric vehicle range, hoping to overcome the range anxiety of prospective car buyers.

This research would therefore propose a different method, less static than the ones mentioned before, that actively involves the user (car owners and hence prospective EV car buyers) in gathering data. By making use of smartphones many of those car owners carry with them on a daily basis, such as GPS tracking and mobile connectivity, one would be able to collect large amounts of unbiased data on the day-to-day driving behaviour of future electric vehicle drivers. Some main problems come forth when envisioning such a system. First of all, car owners will need an incentive to participate in such research. Secondly, privacy concerns play an important role:

would car owners be willing to give away data on their day-to-day driving behaviour, which could potentially be an infringement on their privacy (after all: a car owners’ driving behaviour can yield great insight in to his or her personal life). Thirdly, one would mainly want to attract users interested in buying an electric vehicle, as they need to be facilitated by the charging station infrastructure.

Two of these problems could be combined to form a solution: by building an app that tracks a car owners’ driving behaviour to analyse whether he/she will be able to use an electric vehicle for daily usage, or whether, with this specific car owners’ driving behaviour, driving electric would be problematic. Whilst informing users, which could form an incentive, valuable data of prospective EV drivers is collected. The routes of these people form exactly the (future) demand for electric vehicle range; they can provide insights in where charging stations should be added, and what routes are in highest ’need’ of additional charging capacity and infrastructure. This way, the app will in the end serve the car owners in two ways: first of all by helping them decide on their car buying decision, and if that decision is buying an EV car, the data supplied by the car owner will help improve the charging infrastructure. This way, both the range anxiety as well as infrastructural problems of EV cars are addresses.

The remainder of this research, including the prototypes developed, will mainly focus on the data collection and analysis of this data to valuable insights in where to place new charging stations. The advice part of the app, that serves as an incentive, will be a topic for further research and development. It does however play an important role in this method (a personalised app) being a viable way of gathering data on driving behaviour/routes.

Lastly, an argument in favor of this app and hence to be addressed in this thesis would be the interest in such an app by commercial parties, which could provide further funding and promotion for such an app. Car dealerships, specifically those selling EV cars, are faced with the concept of range anxiety on a daily basis; (prospective) customers assume they will not be able to perform their regular trips, or will end up stranded halfway, whilst the EV is perfectly capable of completing the trip [19]. Giving customers insight in their driving behaviour may assist in showing the possibilities rather than the limitations of EV driving. This app will help car dealers to show this, and hence, they might be interested in providing further funding for the realisation of this app and ultimately research.

Apart from a personalised advise app other tracking applications could of course also be of use. For example, using data supplied directly by cars, or other appliances. Though this would be optimal for data gathering, it would take long times and many parties involved to be able to gather data in this way. Before such technology is integrated into a sufficient amount of cars, many precious time would have passed. Therefore, apps at this point are considered to be the most efficient way to gather data, as they allow for fast implementation.

(17)

3.5 Preliminary conclusions

Based on the findings as elicited above, trip data will need to be collected to allow for all research proposed by this study. The minimal requirement the data (source) will need to fulfil is as follows:

Every datapoint should consists of a start- and endpoint, denoted by GPS-coordinates, preferably with timestamp. In addition, every trip will consist of waypoints that describe the route the car has taken from start- to endpoint. Those points again consist of GPS-coordinates, and preferably a timestamp.

In addition to the above, the trip may be linked to a user to later on provide this user with feedback on his/her trips. This is however not a requirement, and up for further discussion in later parts of this thesis.

Based on the research on existing data and various data gathering methods, this research will further focus on developing an app concept and a corresponding prototype for gathering data.

All this contributes to showing such an app can deliver valuable data, and is in this case to be preferred over other solutions. It will help to form solid conclusions on the location of future charging stations. This research will now further focus on how to realise such an app (the architecture involved), how to analyse the gathered data (clustering), and which conclusions to draw from this analysis.

(18)

4 Requirements

Having identified the data need in the previous section, as well as that an app is the preferred method to gather this data, this section will now focus on eliciting the software requirements for such an app. These requirements will denote an optimal and extended form of such an app, which would be ready for general use and publishing in app stores. Based on these requirements, a subset of requirements will be selected to create a prototype that can first be used to prove the research method of this study, and the analysis that has to be performed after data collection. Based on this study a more extended version of the app as described below could be realised for large-scale deployment. These requirements mainly serve to explain how this study could be realised in practice, and how it would be able to impact society.

Apart from an app to gather data, data also will need to be processed and ultimately pre- sented to stakeholders of the project. To do so, some requirements will be denoted for the system as a whole. This will be requirements on for example data storage and data accessibility.

Furthermore, requirements will be denoted for a web portal that will allow the stakeholders to view analyses and conclusions that are relevant to them. Hence, three main components of the system can be identified:

• An app to gather data

• A platform to store and process this data

• A web portal to review analyses

Putting these three components together yields a system that helps to increase the EV charging station infrastructure by analysing user data. A description of each of the three components will first be given below, afterwards functional and non-functional requirements, as well as use cases and stakeholders will be identified for the system as a whole (as many cross-references and identical parts exist between the three components). Since this thesis is not on software requirements engineering or software development, the requirements elicited here are only meant to give the reader an overview of the intentions and ideas on a platform that will support this research. Hence, no elaborate details on implementation will be given. Various implementations could be based upon this basic set of requirements.

(19)

4.1 Components

An app to gather data

A need for gathering the required data inspired the idea of creating an app that could do exactly that. It was also indicated that users will need an incentive to use this app. Since the motivation for this study is the transition to Electric Vehicles, a good incentive for this app would be one that stimulates that as well. Therefore, this study suggests creating an app that will, alongside gathering data for the analysis of new charging station locations, give users insight in their driving behaviour. It will tell users whether their driving behaviour would be feasible with the current coverage of EV charging stations, and what range their future EV would need to have (what type of EV is best for them). The app will gather data on user trips, and inform users if their day-to-day car use will be possible using an electric vehicle (and how often they would need to recharge). This serves both the interest of gathering data, as well as informing the public of the possibilities of electric vehicles: many future buyers of electric cars have so-called ”range anxiety”; a phenomenon that makes users doubt their freedom of movement when switching to an electric vehicle. Of course, privacy considerations will have to be taken into account when developing such an app. However great the incentive, privacy of users should be respected from both ethical perspectives, as well as the possibility that the privacy issues outweigh the incentive.

A platform to store and process data

After the data has been gathered by the users, it will need to be collected and stored. To do so, a centralised platform needs to be created that can accept data from the app, and support other features of the app as well (such as user identification, and components needed for the advice to be returned to the user). This suggest the implementation of an API to interact with the centralised platform. The platform will need to store the data in a way that it secure, reliable and allows for fast processing. The nature of the data (geospatial) needs to be taken into account.

Also, the platform will need to be scalable since large amounts of data might be gathered and analysed. Finally, the platform will also need to store results from analyses, and be able to serve them on request. This again hints to the implementation of an API, though not only for receiving data, but also for sending data (on request).

A web portal to review analyses

Having gathered data, and being able to store and process it, the last missing piece of the puzzle would be a portal to actually display the results, that helps to make the insights gathered actually turned into decisions and changes towards smarter placement of new charging stations and increasing EV usage. The web portal should allow stakeholders to view data relevant to them, in processed form and in tools that help them make decisions. This will include maps, with options to filters the data displayed. Tools to operate the processing of data, or alter parameters for this processing.

(20)

4.2 Stakeholders

Several stakeholders can be identified for the system. Though some stakeholders may be more relevant to some components, they are not tied to a specific component since they might be indirectly affecting other components of the system.

Prospective EV buyers Car owners of fossil fueled cars will be using the app to get advice on their possibilities of buying a (plug-in) (hybrid) EV. The app will analyse their driving needs, and show them what percentage of their routes could have been made using a (plug-in) (hybrid) EV.

Current EV owners Current EV owners may use the app to supply data. The advice will of course be of less use to them, though data on their trips may help to increase the charging station infrastructure, which will eventually benefit them. It will also help to place the charging stations closer to their actual needs (whilst they know might have to divert their routes).

EV car dealers Besides the prospective EV buyers, EV car dealers are stakeholders as well. To them, the app could serve as the ultimate way of convincing (future) customers of the possibilities of electric vehicle driving. This app is a great tool for car dealers to overcome the range anxiety problem.

Data analysts This group of stakeholders consists of researchers and other parties that are looking for relevant data on the use of (electric) vehicles, in order to provide other parties (stakeholders) with valuable insights on for example charging station infrastructure, as is the case in this research. For them, it’s relevant to be able to access the raw data.

Governments Local authorities as well as governments or certain departments of governments, are interested in the behaviour and needs of (future) electric vehicle car owners to make decisions on where to invest or facilitate in order the grow the electric vehicle use, and reach sustainability goals. The web portal, that provides insights from the various analyses provides governments with a powerful tool in steering towards the use of electric vehicles.

Electric utility companies Electric utility companies are the main providers of charging stations, or the power that is to be ’sold’ at charging stations. They are very interested in data that could help them decide which new locations for charging stations are most economically viable or could yield interesting results in the (near) future. Or, if they only supply electricity to other exploiters of the charging stations, where needs for electricity grid connections will be in the near future. Hence, they serve as stakeholders that are interested in the conclusions that can be drawn based on the data gathered by the app. They will be using the web portal to be informed of these conclusions.

AutoJUICE project The AutoJUICE project is currently building a platform for electric vehicle infrastructure extensions: they provide services to both electric utility companies as well as governments and centralise the needs of stakeholders as discussed above. The app and analysis components of this research might be integrated with the AutoJUICE platform.

(21)

4.3 Non-functional requirements

The following non-functional requirements can be elucidated for the system as a whole and it’s various components:

Scalability The system should be scalable, meaning that with increasing number of users supplying data (increasing app use), increasing number of requests for analysis of the data, or increasing number of requests for raw data, the components of the system (specifically the centralised platform) should be easy to upscale, in order to process all the requests.

Privacy The privacy of the users supplying data should at all times be guaranteed. That is, one should not be able to trace back a set of data to a given person. The advice app would require to register which routes are from one user, details of the user should however not be stored. Furthermore, data provided to third parties and as used in analyses should be anonymised, meaning that user or app identification should be stripped. As there are several ways of tackling this issue, and as it is such an important requirement, a subsection has been devoted to possible solutions with regards to privacy, at the end of this requirements section.

Performance Though analyses of large quantities of data take time, the system should strive for optimal performance, eliminating weak points in data storage and access wherever possible. This boils down to choosing a storage method that allows for both storing large quantities of data, as well as allowing efficient retrieval of this data later on.

Compatibility The system as a whole should be compatible with as many types as users, both on the input (app) side, as for the output (export from the centralised platform through both the web app as well as export functionalities). This translates to the app being available for at least the three major platforms: iOS, Android and Windows. For the centralised platform, it translates to using industry standards when it comes to technique choices. Fi- nally, for the web portal it translates to applying state of the art web techniques, and implementing the web app to be available on a broad spectrum of devices (responsive).

Openness / accessibility The system, and specifically the centralised platform, should be open.

That is, the data it contains should be easily accessible for third parties, to continue re- searching it. The same requirements as described at ’Compatibility’ apply.

(22)

4.4 Functional requirements

REST API The centralised platform should implement a REST API, allowing apps to provide their data to the platform, and make themselves known to the system. Furthermore, a REST API should be provided to retrieve results or raw data from the platform, preferrably in JSON format, though alternative forms may be supplied. The app should communicate it’s result using the REST API, in JSON format.

Incentive The app should provide an incentive for users. That is, it should not merely gather data, but provide some result or bonus feature to the user. This could either be information supplied, or advice given. This study proposes advice given (see below).

Advice in app The app should provide the user with an advice on his/her abilities to make the trips that are collected with an electric vehicle, and which type of electric vehicle would be best suited for this user. The app could also indicate that EV driving is at this point in time not feasible for the given user. The user should be shown the percentage of trips he or she would have been able to make with an EV without on-route recharging, and the percentage of trips he or she would have been able to make with one or more recharges. Additionally, the user could be shown these specific trips; those might be incidental trips the user might be willing to make with a different mode of transport. Additionally, predictions could be given on when the driving behaviour could be met due to the expansion of either charging station infrastructure or battery capacities (new types of vehicles released).

Maps - plotting points & trips The web portal should allow for points (GPS latitude/longitude combinations) as well as trips (ordered sets of GPS latitude/longitude combinations, represented as polylines) to be plotted on a geographical map. The underlying map should preferably be from a service such as Google Maps that also shows PoIs (Points of Interest), cities and roads. Those points could either be datapoints as entered, or datapoints result- ing from an analysis. The user should be able to select which datapoints he or she wants to view.

Showing user statistics The portal should allow administrators to show statistics on the number of users currently using the system, and the number of trips uploaded to the system.

The number of users consists of two types of users: app users that supply data, and users that use the portal. For those users, statistics on the usage and number of analysis made could be shown.

Downloading data Users of the web portal should be able to download selections (filtered) or full sets of data for further analysis on their own system. They should also be able to download data from the analysis (identified charging station locations). Downloading of this data might occur through either the web portal or through the REST API.

Generating and viewing analyses Users of the web portal should be able to start the analysis process (that will be performed on the centralised platform). The results will afterwards be shown on the web portal. For various analyses some parameters can be set. Though defaults and advices will be given by the ChargeQuest project, the user will be allowed to change those. Such parameters might include the distance a user is assumed to drive on a full battery. The full list of parameters will be further elaborated on in the Analysis section of this study.

Saving analyses The analyses might take quite some time to process. Therefore, results of an analysis, including the parameters used to generate them, might be saved per user of the web portal. This way, a user can quickly retrieve or compare several analyses. A user should be given the option to rerun the analyses if new data comes available (using the same parameters as the saved analyses). A list of saved analyses should be shown to the user.

(23)

4.5 Use cases

Though the above requirements give an overview of the components the system should consist of, the below use cases might give further insight in the envisioned system.

4.5.1 Using the app to collect data on trips Stakeholders involved

Prospective EV buyers, current EV owners, EV car dealers, data analysts Components involved

App, centralised platform Description

A user (car driver) that has the app installed on his or her smartphone wants to gather data to retrieve advice from the app (incentive) and contribute to the research. The user will once have to download and install the app on his or her smartphone, and enable it (accepting that the app might poll the users’ location). Afterwards, the app will continuously monitor the movement, and if it detects that the movement is part of a trip, will start registering a trip. The user can at any given time choose to upload the trips collected until that moment in time, or delete some of the trips before doing so.

Preconditions

• The user in the posession of a smartphone with GPS-capabilities

• The smartphone has a working internet connection

• The user is about to make one or more trips with his/her vehicle Flow of events

1. The user downloads and installs the app

2. The user activates the app and approves it tracking his/her location

3. The app checks for movement and if it identifies it as part of a trip, saves this movement (GPS waypoints)

4. Upon completion of a trip, the app saves the set of waypoints collected as a trip Steps 3 and 4 may be repeated

5. The user may choose to remove certain trips 6. The user starts uploading of the trips from the app

(24)

4.5.2 Getting advice on EV choice Stakeholders involved

Prospective EV buyers, EV car dealers Components involved

App, centralised platform Description

A good incentive for using the app will be to provide users with a personalised advice on whether or not their trips can be completed with an EV, and if so, what type of EV. Alterna- tively, an (EV) car dealer might advice a car owner to use this app to retrieve these insights.

After allowing the app to gather some data over a period chosen by the user, the user might activate the advice option. This will then request information from the server on the users’ trip, and provide statistics on his/her driving behaviour. This will be matched against a number of available EVs.

Preconditions

• The user has uploaded one or more trips to the centralised platform

• The smartphone of the user has a working internet connection Flow of events

1. The user requests a personal advice from the app

2. The centralised platform receives the requests and responds with statistics 3. The app visualises the statistics on the smartphone

4. The app can retrieve available EV cars and their specifications from the centralised platform

5. The app matches the statistics to available EV cars, and shows the result to the user Postconditions

This use case has no implications on the state of the system or data in the system.

4.5.3 Accessing data stored on the platform Stakeholders involved

Data analysts, Governments, AutoJUICE project, Electric utility companies Components involved

Centralised platform, Third party applications Description

To be able to expand the platform, it must is set up as an open API. Other third party applications should be able to connect and request stored information on trip and/or results. This way information can be reused for different purposes

Preconditions

• The storage component contains information on trips and/or results (otherwise yields empty results)

• The third party application uses REST and is implemented to use the API definition as specified

(25)

Flow of events

1. Third party application initialises a connection 2. Third party application performs request

3. The centralised platform executes the request and collects the requested data 4. The third party application receives the results of its request

Steps 1 to 4 may be repeated Postconditions

• The requested data has been send to the third party application

4.5.4 Analysing trip data on the platform, and viewing the conclusions Stakeholders involved

Data analysts, Governments, Electric utility companies, AutoJUICE Components involved

Centralised platform, Web portal Description

A user of the web portal (note: this is a different user than that of the app) can obtain analyses and results via the web portal. After logging in with the supplied credentials, he or she is able to select the analyses available on the centralised platform. The results will consist of indicated new charging station locations on a map. The user can either select existing analyses that have already been performed using suggested parameters, or can choose to alter the parameters.

The list of available parameters will be specified for each analysis later on in this thesis. When running a new analyses, some waiting time might be incurred. Afterwards, the results will be plotted on the map. The user may then choose to select another analysis, or end his or her session.

Preconditions

• The storage component contains information on trips and/or results (otherwise no analysis possible)

• The user has received credentials for the web portal Flow of events

1. The user logs in to the web portal, and selects the viewer component 2. The user can choose to do one of the following:

(26)

4.5.5 Viewing the trips on which data has been gathered Stakeholders involved

Data analysts, Governments, Electric utility companies, AutoJUICE Components involved

Centralised platform, Web portal Description

A user of the web portal (note: this is a different user than that of the app) can obtain an overview of the trips gathered by the system. This gives statistical insights and might allow for insights in the analysis process. After logging in, the user can select the trip viewer. The user might choose to filter the trips, either on date reported or on location. Afterwards, the chosen filtered subset, or the full set if unfiltered, will be mapped. Since these are trips, no individual points will be plotted, but lines between the points a trip consists of. The map will show roads and highways, to allow verification of the plotted trips.

Preconditions

• The storage component contains information on trips (otherwise no trips will be shown)

• The user has received credentials for the web portal Flow of events

1. The user logs in to the web portal, and selects the trip viewer component 2. The user selects the filters he/she wants to apply, or chooses to use no filters

3. The centralised platform retrieves the stored trips and plots those on the map. Steps 1 through 3 may be repeated

Postconditions

This use case has no implications on the state of the system or data in the system.

(27)

4.6 Privacy

When designing an app that tracks users, and gathers large amounts of data, it is important to consider privacy of the users of the app [10].In this case the car owners. In this section some issues and concerns with regards of privacy will be discussed, that can serve as a requirement for the design of the app. Two possible solutions are discussed.

Issues

When dealing with personal information such as locations, one will have to comply with legal authorities such as the Dutch laws about safe keeping of personal data [6]. This has to be kept in mind when storing the data. It might also require extra functionality such as the possibility to delete data under the European Law about the right to be forgotten.

Though one might consider that car owners might be willingly to provide a information in ex- change for the functionality [7]. This already happens with the Android Apps in the Play Store having an all or nothing policy on device permissions. Without accepting all of the permissions, one cannot use the app. Though some users might share their location data in ignorance of the consequences [11].

A privacy preserving solution

One initiative used for location sharing with social networks is called PlocShare [12]. It uses a Public-Private Key concept with an access list to share your location with allowed parties. This can be used to allow that location data from users can be safely shared with the program used to calculate a possible car advice. In the mean time the car owner location data is hidden from third parties and can only be shared if the car owner allows it.

For calculating the advice for the location of new charging poles, data of individual car owners does not have to be shown, just their trips. This method however, does not protect against the shared data being stored. The car owner loses control of their data when they share it with another party.

User choice

Another possible solution is to let the car owner decide what data they would like to share. For this the mobile app should be constantly monitoring the location. This data is then stored on the device. The app generates a notification when some data is collected. (I.E. once a week) This allows for reviewing of the gathered data by the car owner before sending the data to the server.

(28)

Figure 2: Possible data flow diagram

Aside from providing the user with a choice on what they are willing to share, they can remove trips they don’t think are representative for their car usage, such as trips in public transit.

4.7 Conclusions

Though these requirements only give a global overview of the basics that any system supporting a study like this, or in a future larger deployment supporting infrastructure decisions or sustainability goals, the main technical needs can be derived from these requirements. This study will elaborate on them in the next section.

(29)

5 Technical research

The second research question of this thesis focuses on what architecture is needed to store the gathered data, and later on process it. This section will elucidate on the techniques available, that could be used to create such a platform.

Before going into detail on technologies, it is important to denote what such a platform should:

• Serve incoming requests from information sources, such as the mobile app

• Provide storage to large amounts of location information

• Provide fast access to queries, including queries using location information

5.1 API

Some of the functionality of the centralised platform can be offered as an API, to be precise, a Representational State Transfer (REST) API. This is a software architecture style consisting of guidelines and best practises for creating scalable web services[27].

It uses a lightweight payload (body of a request containing extra information) in JSON format on top of HTTP. The request from mobiles consist only of two options: uploading information on driven trips and requesting advice based on the driven trips. These requests can be done in parallel and therefore scaling would not be a real problem. Real world applications of load bal- ancing are a common practice[9]. Since REST is based on HTTP, it can be implemented by most platforms which are capable of making internet connections. There exist a lot of web servers, application servers and specialised applications which use REST as a means to communication.

It can also be implemented on top of existing services such as a web server with PHP. This does not require any special third party libraries.

The REST API can be implemented by adding server side computations to verbs of HTTP (GET, PUT, POST and DELETE). With both PUT and POST it is possible to send a payload of information to the REST API with the information to be inserted. One example of a large API using REST is the Twitter API[32]. It uses the API to enable developers to communicate with its services. This allows for third party apps and integration with other services.

Since REST can be used with most modern web platforms. It might be wise to combine the REST API with the portal. This allows for one machine to serve two purposes.

(30)

5.2 Storage methods

A key component of the architecture is the storage. Both the front end and the analysis server are perfectly horizontally scalable. The storage however must provide these facilities for larger spatial data sets. This type of data has special requirements which will be discussed first. When storing this spatial data several options come to mind. In this section the two major distinct storage methods; relational and non-relational (NoSQL) will be evaluated.

(Geo)spatial databases

The methods discussed about data gathering all deliver coordinates as data points. A database has to provide functionality to perform queries based on this spatial database. Some databases already feature such operations, these are called spatial databases. A spatial database is a database specially equipped to store data with a geometric component and to retrieve results using topological and distance-based queries [3]. Non-Spatial databases would use indexes to look up values, though this approach is often not optimal for spatial data storage. Spatial database instead use a spatial index to store this information to speed up the operations on geographical data stored in this database. An index which would be suitable to this project would be a sphere index. This sphere index takes into account for the distance between coordinates on the earth. Another benefit of using spatial databases is that it has build in functions for comparing different spatial fields. This allows for queries to quickly look up coordinate points close to a given point.

Relational spatial data storage

Relational storage consist of row based entities. An object model is divided over multiple tables each having one or more entries per object. Spatial fields are stored in a similar manner as normal primitive fields. Four popular relational database systems with a spatial implementations are: MySQL, PostGIS, Oracle Spatial and IBM-DB2 Spatial [4]. MySQL[14] and PostGIS are open-source and therefore free while the other two solutions are closed source applications.

The open source versions are discussed.

MySQL

MySQL is an open source relational database which is developed by Oracle. MySQL has built-in functionality for storing geospatial data inside regular database fields. Geospatial types can be retrieved in both binary and text formats. In MySQL these types are stored in binary format, but need to be translated to a text format to be used in queries. Indexes can be placed on these fields, empowering the build in functions to issue queries for near locations.

PostGIS

PostGIS is similar to MySQL, but has specialised components for spatial data. It is an exten- sion for the PostgreSQL database software which is an open source alternative to the corporate developed MySQL. Similar to MySQL, it has the ability to store geometry directly in fields. It has build in functionality to perform operations on them and can be directly compared inside queries used to look up locations near a requested location. It also has capabilities to define spatial indexes.

In both relational storage methods, size is an issue. Tables with thousands of rows have poor performance[4][2]. Considering the amount of collected location points, this might be an issue.

(31)

Non-Relational spatial data storage

NoSQL or Not Only SQL differs from the relational storage method that tends to store data in a tabular form. NoSQL storage units consist of Document oriented storage. This means that in the data storage design a complete object can be stored in a document, instead of rows which have relations to each other in a database. NoSQL comes best in place when the geographical and other data collected will have a high frequency of change, high variety of structure or high volume. Relational database tend not be able to provide the needed efficiency in terms of performance and scalability[1] [2]. Two open source NoSQL databases will be discussed:

Accumulo and MongoDB.

Accumulo

Apache’s Accumolo is a mapping system inspired by Google’s big-table design. In this big-table design key-pairs are stored that contain for every data object a row key, a column key, and a time stamp. Values themselves are represented by byte-arrays[3]. An example of this key-value storage is shown in the image below.

Figure 3: Key-Pair storage example[3]

Accumolo builds on this principle and enables a back-end for these systems. It is built upon Hadoop, Zookeeper and Thrift. Look ups can be based on these keys to search for certain results. One could for example try to filter on a certain period in time, and could combine other factors such as key identifiers to retrieve a subset of results. Unfortunately it has no build in functionality for spatial data.

MongoDB

MongoDB[8] is one of the most popular NoSQL databases. It is a document oriented Database.

It’s written in C++ and has an interface to many programming languages. MongoDB has built- in functions to handle geospatial queries. It is possible to specify an index on coordinates. These have to be formatted in GeoJSON[28], an open format to specify coordinates and other points.

The format is able to define several geometric values such as points, shapes and line strings.

It uses the same JSON language used by MongoDB to format the different types. MongoDB provides concurrent access, and only locks at a field level of a document. It supports dynamic queries, just like relational database systems [2].

Downsides of NoSQL

Identifying new EV charging station locations based on user trip data

Bachelor Project

ChargeQuest

Identifying new EV charging station locations based on user trip data

Authors:

A.J.H. Sigtermans (s1914766) J. van Breemen (s2262967)

K.Y. Kliffen (s2369494)

Supervisor:

prof. dr. A. Lazovik

July 2

, 2015

Contents

1 Project description

1.1 Domain definitions

1.2 Main goal

1.3 Research questions

2 Problem statement

2.1 Definitions

2.2 Problem formulation

3 Methods to gather data

3.1 Data needed

3.2 Existing data sources

3.3 Gathering data through submission systems (inquiry-style)

3.4 Gathering data through tracking applications

3.5 Preliminary conclusions

4 Requirements

4.1 Components

4.2 Stakeholders

4.3 Non-functional requirements

4.4 Functional requirements

4.5 Use cases

4.6 Privacy

4.7 Conclusions

5 Technical research

5.1 API

5.2 Storage methods