See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/261523789

A Distributed In-Transit Processing Infrastructure for Forecasting Electric

Vehicle Charging Demand

Conference Paper · May 2013

DOI: 10.1109/CCGrid.2013.103

CITATIONS

4READS

60

6 authors, including:

Some of the authors of this publication are also working on these related projects:

Multi-Agent Systems and secured coupling of Telecom and Energy grids for next generation smart grid services (MAS2TERING) View project

Clouds4Coordination View project

Rafael Tolosana-Calasanz

University of Zaragoza

52 PUBLICATIONS   406 CITATIONS   

SEE PROFILE

José Ángel Bañares

University of Zaragoza

78 PUBLICATIONS   585 CITATIONS   

SEE PROFILE

Liana Cipcigan

Cardiff University

88 PUBLICATIONS   1,780 CITATIONS   

SEE PROFILE

Omer F. Rana

Cardiff University

606 PUBLICATIONS   8,184 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Liana Cipcigan on 15 September 2015.

The user has requested enhancement of the downloaded file.

Forecasting Electric Vehicle Energy Demand via anIn-Transit Processing Infrastructure

Rafael Tolosana-Calasanz1, Jose Angel Banares1, Liana Cipcigan2,Omer Rana4, Panagiotis Papadopoulos5, Congduc Pham3

1Aragon Institute of Engineering Research (I3A), University of Zaragoza, Spain2Institute of Energy, School of Engineering, Cardiff University, UK

3LIUPPA Laboratory, University of Pau, France4School of Computer Science & Informatics, Cardiff University, UK

5EDF Energy, R&D Centre, London, UK

Abstract—With an increasing interest in Electric Vehicles(EVs), it is essential to understand how EV charging couldimpact demand on the Electricity Grid. Existing approachesused to achieve this make use of a centralised data collectionmechanism – which often is agnostic of demand variation in agiven geographical area. We present an in-transit data processingarchitecture that is more efficient and can aggregate a variety ofdifferent types of data. A model using Reference nets has beendeveloped and evaluated. Our focus in this paper is primarily tointroduce requirements for such an architecture.

I. INTRODUCTION

The introduction of government legislation and the asso-ciated penalties for exceeding certain CO2 emission levelshas encouraged major automotive manufacturers to announceproduction of Electric Vehicles (EVs). Virtually all major carmanufacturers (such as European (BMW, Volvo, Volkswagen,Fiat, Peugeot, Renault), Japanese (Suzuki, Toyota, Nissan,Honda, Mitsubhishi) and American (GM/Chevrolet, Ford))have announced the inclusion of EVs in their productionfacilities and marketing plans. These vehicles are anticipatedto gain an important market share over conventional Inter-nal Combustion Engine (ICE) powered vehicles. Analysison lifecycle CO2 emissions [1] that was published for theBritish government concludes that in the year 2030, EVsmay be able to produce less than 50g/km CO2 emissions,approximately one third of petrol based vehicles. In the samecontext, the Committee on Climate Change recommends thatthe Government should aim for 1.7 million EVs on the roadby 2025 [2]. In order to re-charge their batteries and providetraction, EVs will have to be connected to power networks [3].

From a power system’s (electricity grid) perspective, EVsmay be considered as: (i) simple loads drawing a continuouscurrent from the electricity network; (ii) flexible loads thatmay allow an aggregator company to interrupt or coordinatetheir charging procedure; (iii) storage devices that may allowan aggregator company to request power injections from theirbatteries back to the electricity grid (the latter is knownas Vehicle to Grid (V2G)). A unique characteristic of EVsin terms of power systems is that they are mobile devicesexpected to connect to various locations of electricity networksat different times of a day. Recent studies estimate that by

2030, if the re-charging processes of EV batteries are leftuncontrolled, a significant increase in the electricity demandpeaks is to be expected [4]. Moreover, the impact of EVsis expected to be at the local level where hotspots will becreated that depend on how EVs will cluster within a particulargeographical location, creating a possible overload on thelow voltage distribution networks. Even a small number ofuncontrolled vehicles charging at peak periods could signif-icantly stress the distribution system, slowing EV adoptionand requiring major electricity (generation and distribution)infrastructure investments. Our focus here is on EVs that areused by individuals in a residential or city context, and not onvehicle fleets where charging models can be different.

A key challenge in supporting EV demand forecasting isunderstanding: (i) over what period of the day an EV owneris likely to request charging; (ii) characteristics of the EV (suchas battery being used, distance travelled, etc); (iii) drivingbehaviour of the vehicle user; and (iv) environment factorsthat impact (ii) and (iii). Such information is generally notavailable at a single location, for instance some of thesefactors reside on the EV while others need to be derived fromindependently managed data sources (operated by the weatheror traffic agencies). The information needed to support EVdemand forecasting can therefore consist of (i) heterogeneousdata formats & varying transmission rates; (ii) irregular orbursty data streams; and (iii) variable, difficult to predictprocessing requirements per data stream. The processing ofthese data streams may involve filtering, data correlation andtrends analysis. Processing is also typically stateful, i.e. afterthe processing of a data element, a state must be kept inmemory for processing subsequent data elements. The out-come of stream analysis must be exploited and compared withhistorical load demands (stateless), so that a forecast can beobtained. Identifying how limited network and computationalresources (subject to congestion, failure and performancedegradation) can be applied to stream analysis is an importantchallenge and the focus of the work reported here. Demandforecasting for EV charging is also a time critical process, asvehicle owners may need their battery to be charged withina few hours. Additionally, emergency and unforeseen trafficor weather events may render previous forecasts inaccurate or

unusable, thereby requiring a new forecast to be developed.The underlying network and computational architecture musttherefore support Quality of Service (QoS) constraints to beobserved to support the generation of timely forecasts.

We propose a distributed computing architecture and amodel for supporting EV demand forecasting, which consistsof a number of autonomous stages, where each stage consistsof a combination of data access and regulation, computation,data transfer capability, and a rule-based controller component.The computation stage makes use of a dynamically adaptableresource pool, enabling multiple computational resources to beused (and released) on-demand. To support QoS constraints,we consider: (i) the average throughput per stream; (ii) themaximum allowed burst per stream, and (iii) the need for datadropping – i.e. dropping some data elements if they do notdirectly contribute to demand forecasting. We extend previouswork [5], [6], [7] by integrating an admission control policyin the incoming traffic regulation component, support for bothstateful and stateless stream processing. We have developed aproof of concept prototype of the system with Reference nets(a type of executable Petri nets that support Java actions).

The rest of the paper is organised as follows. In Section II,EV charging requirements are provided. Requirements fordata handling and distributed processing are identified in thissection. In Section III, we present the system architecture formaking the EV demand forecasting application deployableon a shared computing infrastructure. Two experiments areconducted to show the key aspects of the model, with resultsdescribed in Section IV. Previous related work is compared tothis proposal in Section V. Conclusions and future work arediscussed in Section VI.

II. ELECTRIC VEHICLE DEMAND FORECASTING

Figure 1 identifies the overall data management architecturewithin the EV demand forecasting application. Starting fromthe bottom of the figure, there are a number of possiblesources of data that contribute to the forecasting process. Thisincludes: (i) data obtained from vehicles (ii) data obtainedfrom a charging station – such as duration of charging, energyconsumed/used up during charging, type of charger used,desired time of disconnection etc; (iii) data obtained fromexternal data agencies that have a bearing on the chargingrequirement of vehicles. This data is streamed to a number ofnodes, indicated as node Ni in the figure. The architecture foreach node in the system is discussed further in Section III. Akey requirement in this approach is to forecast the total energydemand at a charging point – and subsequently aggregate thisdemand within a particular region.

In our approach, we do not collect the data relating tovehicles, charging points, weather/traffic (identified above) ata central point. Instead, we develop a model for each chargingpoint and then combine the outcome of these models using ourdistributed data management and computation infrastructure.This enables different types of models to be used concurrently,where the complexity of a model depends on the likely rate ofchange at a particular charging point. A residential charging

Fig. 1. Data management architecture within a particular region. The “ag-gregator” is responsible for combining electricity demand within a particulargeographical area.

point is likely to have less demand variation than a chargingpoint within a city. The computational requirement for eachmodel can therefore change based on its location within aparticular geographical area.

A. EV Demand Forecasting Model Requirements

We identify various scenarios that illustrate the requirementson the data management and computational infrastructurerequired for EV demand forecasting in Table I. These scenariosare used to derive the requirements for our system architectureand model. Sensors in this instance may be associated withan EV (such as monitoring current battery charge) or thoseassociated with a charging point (which may be located athomes, commercial buildings or service stations within the cityor along motorways). The simultaneous charging of a numberof EVs will generate a significant load on the electricitygrid and thus some coordination is necessary to distributethis charging requirement over time. Various approaches arepossible to achieve this – such as synchronising charging withtariffs (including the availability of real time pricing signals)identified by the utility company or with the load currently onthe electricity grid. Demand forecasting is therefore essentialto enable the utility company to enable such coordination totake place.

III. SYSTEM ARCHITECTURE

In this section, we will present our architecture for enablingan elastic, QoS-aware, and scalable distributed streaming sys-tem for EV demand forecasting. The proposed architecturesupports the processing of multiple sources of informationover a shared infrastructure, and consists of a sequence ofnodes that accomplish the computations. Our objective is tomaintaining an end-to-end QoS for each source of information,by enforcing QoS at each node when data is streamed throughthem. Each node is independent of another, and we assumethat (i) data transmissions required for meeting QoS, onaverage, do not exceed the network bandwidth available, (ii)the required processing capability on average does not exceedthe computational power of the available resources.

EV scenario Data management & computation requirementsForecasting demand at a charging point requires handling anumber of concurrent data streams. Each stream can havedifferent characteristics: rate, frequency and sample size. Theinfluence of data within a particular stream on the forecastmay also vary – i.e. some data streams may be of greaterimportance in determining the outcome. Some streams maycome directly from the vehicle or the charging point, whereasothers may need to be derived from data maintained by thirdparties (such as weather and traffic agencies) and filtered todetermine regional characteristics.

Requirement #1. It is necessary to allocate priority todifferent data streams, based on their impact on the predictionoutcome. A resource management strategy needs to be usedthat allocates a greater number of computational resources toprocess high priority streams and alter this dynamically basedon change in stream behaviour. The underlying infrastructuremust be able to support admission control and enable avariable processing rate per stream.

Current demand aggregation is focused on a regional context.Hence, demand identified at charging points within a residen-tial or city area needs to be combined. It may be necessaryto change the granularity of the region being considered tomore accurately reflect a variation in demand and identify thelikely sub-region where such variation occurs.

Requirement #2. The data streams needed to support demandprediction can change – requiring the addition or removal ofparticular streams to enable analysis to take place for differentgeographical areas. A key requirement in this context is theability to dynamically choose the data streams of interest.

Different charging points may exhibit behaviour of varyingcomplexity. For instance, charging points which exist withinresidential areas may have a more regular demand pattern,compared to those that occur within a city where demandcan be influenced by events such as road congestion (due tosporting events, accidents), weather patterns, etc.

Requirement #3. The computational resources needed toforecast demand will depend on the likely rate of changein demand at a particular charging point. It is thereforelikely that a different forecast model would be appropriatefor residential areas compared to a city-based charging point.The infrastructure should therefore provide capability toconsider different forecast modelling capabilities (such aslinear regression, neural networks, bayesian models, etc) toco-exist. In the same context, EV usage patterns in residentialareas are likely to be regular, implying that data rates arelikely to be well defined. Conversely, charging points atshopping centres or public places at city centres are likelyto see varying demand, leading to data capture with periodsof burstiness.

The data used to generate forecast models may have interde-pendencies. For instance, weather data may influence trafficcongestion within a particular area. Similarly, the state ofcharge of a vehicle battery would depend on the type ofbattery being used, the traffic flow within a given area, etc.Therefore, although different data streams are needed, thedependencies between the data streams may influence theforecast outcome.

Requirement #4. The data management system shouldenable mechanisms to provide isolation between streamsand where necessary, to also enable dependencies betweenstreams to be identified. Data streams will also have errorsand involve missing data items. It is therefore necessary whenprocessing these streams to be aware of how one streaminfluences another and how data quality within one streaminfluences another.

Developing a model to forecast EV demand is a time criticalprocess, as the aggregator identified in figure 1 needs torequest electricity from a power generating company onlya limited time prior to its use. To facilitate this, there isa time window within which data from the EV and thecharging point needs to propagate to the computational noderesponsible for developing the forecast.

Requirement #5. With multiple data flows present within thesystem and the need to observe particular time thresholds, itis necessary to develop Quality of Service (QoS) constraintsto limit data loss and latency. Such QoS constraints shouldalso identify bounds on the computational time necessary todevelop the forecast.

TABLE I: Data management and computation requirements for variousEV demand forecast scenarios – with reference to the regional demandaggregation illustrated in Figure 1

ResidentialFeeder

ResidentialFeeder

ChargingPoint

Area 1

Area 2 Area 3

LocalAggregator

Area 4

LocalAggregator

LocalAggregator

LocalAggregator

ChargingPoint

ChargingPoint

RegionalAggregator

Fig. 2. Hierarchical division into sub-areas with local and regional aggrega-tion of demand

Our architecture relies on the current hierarchical decom-position of an electricity grid into logical zones to supportmonitoring and control, as identified by Serizawa et al. [8].Such a decomposition enables a more scalable means tocontrol and manage a particular part of the power network.We take two perspectives to support load forecasting: (i) anEV and charging point perspective; (ii) a zonal perspective –which enables aggregation across all EV charging in that zone.The first of these corresponds to determining likely chargingregimes for an EV at different times of day, the accuracy ofwhich can vary with the behaviour of the driver, the pricingtariffs for charging currently enforced by the utility companyand other external factors which impact the battery charge(such as weather and traffic congestion events, etc). Figure 2illustrates the sub-division into areas and local aggregation ofdemand within each area. These areas can include residentialfeeders that also aggregate demand from homes and EVcharging points associated with a home (Area 1), to officeblocks (Area 4), city areas (Areas 2 and 3 in the figure)which can include multiple charging points and which canhave variable density of EVs at any given time. A RegionalAggregator then combines demand from each of these localaggregators (as also illustrated in the figure). From an electricalpower grid perspective, charging points within each of theseareas are at the Low Voltage substation level, local aggregatorsat Low to Medium Voltage substation level, and the regionalaggregator at the High Voltage Level. EV charging regimes canrange from: Uncontrolled Regime: EV charging begins as soonas a commuter connects to the charging point. The daily trafficpattern of commuters determines when EV charging will takeplace. Dual Tariff Regime: The utility company introducestwo tariffs – a higher price tariff in the morning when thereis a greater demand for power and a low price tariff atnight. Variable Price Regime: This assumes that the utilitycompany provides real time pricing signals, based on theexistence of smart meters at consumer premises. Hence, a widevariety of possible pricing signals can be produced, leadingto different charging regimes based on demand from thecommuter and pricing information from the utility company.Mixed Charging Regime: In which the above three regimeswere combined in different ways – with different proportionsof commuters charging their vehicles using one of the threeregimes outlined above. In the same way, when considering

EV charging outside residential areas, traffic patterns can beused to infer possible charging regimes. Whereas dual tariffregimes would be appropriate for commuters charging at home– i.e. preference for over night charging when price is low,such a regime would be inappropriate for city charging, wherea spot price would need to be determined when a chargingrequest is made (in the absence of energy storage capability).Our architecture consists of a number of nodes that can receivedata from charging points and local aggregators. We estimatethe total data sizes we need to consider as follows:

• Each EV profile is approximately 1KB – and we as-sume approximately 400 EVs in each area (as illustratedin figure 2). This value is based on the number ofcustomers connected to a secondary transformer in aresidential area, which for the UK generic distributionnetwork is 384 [9]. The EV profile generally consistsof the following parameters: (a) EV battery State ofCharge (SoC); (b) EV battery characteristics – whichare dependent on the manufacturer and the current ageof the battery; (c) Inverter/Charging point efficiency –i.e. how efficient is the overall charging process; (d) TheEV battery utilisation cost; (e) Preferred charging mode;(f) Time of disconnection and SoC; (g) Electricity priceschedule.

• We assume data may be communicated bi-directionally –from a charging point to a local aggregator and froma utility company to a charging point (such as pricesignals).

• Depending on the charging regime being used, it isnecessary to estimate the number of EVs at any particularcharging interval (i.e. the time over which a demandfor energy is made by an EV owner). We assume thatresidential areas have more predictable demand than cityareas (which can change based on time of day or otherevents (weather or congestion related, for instance)).

• Data from an EV can become available when: (i) theEV connects to a charging point within a residential orcity area; (ii) when an EV is within some geographicalproximity to a charging point – which advertises thecurrent tariffs to the EV owner.

A. Architecture

Our architecture consists of a number of nodes locatedwithin each area illustrated in figure 2. These nodes areconnected by networks that can support a variety of differentQuality of Service characteristics (ranging from wired towireless connectivity). A node can be physically hosted at acharging point or may be a data collection resource operatedby a mobile phone network operator. A number of such nodesform our demand forecasting architecture, a key feature ofwhich is that forecasting should not be carried out at a centralpoint in the network (i.e. at local or regional aggregatorsonly). Instead, demand forecasting may be distributed acrossmultiple nodes within a data capture and processing network,with some of the nodes being hosted at different substationlevels of the electricity grid (low, medium and high voltage).

Fig. 3. System Architecture, and the elements of a node

All nodes have a similar architecture, consisting of three keycomponents: (i) a token bucket per data stream – for each typeof data that contributes towards forecasting demand. A datastream can include: EV profile, pricing signals, weather orcongestion events, etc; (ii) a processing unit (PU) componentthat assigns data to computational resources. The numberof processing units allocated to each stream can vary, andare dependent on the urgency needed to process a givendata stream at any given time. We assume that the numberof processing units allocated to a stream are dependent onthe build up of tokens within a particular stream within thetoken bucket associated with the data stream; and (iii) adata transmission service that subsequently forwards partiallyprocessed outcomes to the following node in the network.Figure 3 illustrates this architecture where each stage containsits own controller component. Each node corresponds to Niidentified in figure 1.

B. Handling multiple, heterogeneous data streams

Within a data stream, it is often useful to identify a “dataacceptance rate”, which is often different from the physicallink capacity connecting nodes and which identifies the rateat which a stage can receive and process data. Each nodetries to maintain this acceptance rate as the output rate.We characterise it for each flow by means of three QoSparameters: (i) average throughput (average number of dataelements processed per second), (ii) maximum allowed burst,and (iii) an optional load shedding (data dropping) rate. Wemake the first two parameters match R and b of the tokenbucket respectively. For each data stream, its associated tokenbucket will allow data elements to enter into the PU stageaccording to the R parameter. The token bucket can also accepta burst of b data elements. Subsequently, a data element isforwarded to a First Come First Serve (FCFS) queue buffer ata PU. In addition to regulating access to the PU and enforcingQoS per data stream, the token bucket also achieves streamisolation, i.e. a data burst in one stream does not interfere withanother. The load shedding mechanism acts at the input bufferof the node by discarding the older data elements of a flow ata specified rate. It is only active, however, when triggered bythe PU stage controller component.

IV. EVALUATION

We evaluate the effectiveness of our architecture for thescenarios described in table I. In particular, we demonstratehow adaption of token bucket parameters and the number of

processing elements allocated to each stream can help addresssome of the data management and computation requirementsidentified in table I.

A. Experiment 1: Self-adaptation with different performanceconstraints

This experiment focuses on requirements 1 and 2, i.e. howpriority can be allocated to different data streams (originatingat a charging point or a local aggregator) based on the impactthe data will have on the prediction outcome. In particular, theobjective is to demonstrate how resources can be dynamicallyallocated to process a stream from a more congested area(simulated by a burst in data traffic received from the area),compared to data traffic received from an area with a moreEV charging requirement. It is therefore possible to modifythe rate at which a stream enters a node – by altering tokenbucket parameters, or the subsequent allocation of processingunits to higher priority streams.

Fig. 4. Throughput rate with self-adaptative control and TB at each stage.

We consider two streams – ds1 and ds2, which have beengenerated by two local aggregators – and are received by anode at the regional aggregator, as illustrated in figure 2. ds1 isof a higher priority and therefore must be allocated additionalresources to achieve a processing time target, compared to ds2,which only makes use of resources that are free.

The top graph in figure 4 shows the input rate for ds1 andds2. A burst is produced during interval 60s-120s for ds1

and during interval 600s-660s for ds2. This burst simulatesan increase in demand for charging over this interval withinthe region associated with ds1. The graph in the middle ofFigure 4 shows the throughput for ds1 and ds2 at the first node.It shows ds1’s throughput at the first stage, regulated by thetoken bucket throttling mechanism: the first small peak at time60s is caused by the allowed burst. As the violation persists,the second peak shows how more flexible constraints allow the

addition of 6 resources and the throttling rate is increased until90 tokens/s during the considered interval. The 3rd peak of 200tokens/s is produced to simulate a data inflation – i.e. there is asignificant increase in the amount of data produced (comparedto the size of the input data). The bottom graph shows howthe adaptation to the burst at ds1’s input is propagated atthe second stage, which reacts by introducing 6 additionalresources for ds1 to the second node. Data inflation in ds1

at the first stage triggers the use of 10 additional resources atthe second stage of ds1 until the input buffer of the secondstage is emptied. These graphs also show buffer occupancyat each node on the right y-axis. In this example, the bufferoccupancy threshold to trigger the addition of new resourceshas been set in ds1’s configuration to be a value of 50 tokenswith the resources being returned when the buffer is emptied.The peaks of ds1’s buffer occupancy due to the input burstis controlled in the two stages as additional resources can beintroduced to correct the difference between input and outputrates. However, there are not sufficient resources to absorbds1’s data inflation introduced in the first node. These graphsshow that during the interval where burst and data inflationare produced in ds1 there is no noticeable effects on ds2.

The top graph in figure 4 also depicts an input rate burst inds2. ds2’s requirements only supports the use of free resourcesthat may be used when the wf2 buffer occupancy reaches 50tokens. The middle graph shows how the first node increasesthe token bucket rate to 20 tokens/s (5 tokens/s over the initialR of 15 tokens/s). Looking at ds2’s buffer occupancy at eachnode, when the buffer is emptied R returns to the initial valueand the throughput returns to 10 tokens/s provided by the inputrate. ds2 buffer occupancy at node 1 is over the thresholdidentified in ds2’s configuration, because there insufficient freeresources to absorb the burst and therefore data are buffered.The bottom graph in figure 4 illustrates the same adaptation fords2 at the second node. Until ds2’s buffer occupancy reaches50 tokens, ds2’s token bucket rate is 15 tokens/s. Once thisthreshold is reached,ds2’s token bucket rate is increased until20 tokens/s to use free resources. When the buffer is emptied,R returns to the initial value and the throughput returns to 10tokens/s provided by the input rate. In this case, ds2 bufferoccupancy is under the predefined threshold because the freeresources are sufficient to absorb ds2’s rate adaptation at thefirst node. Again, these graphs show that during the intervalwhere the burst is produced in ds2 there is not noticeableeffects on ds1.

An additional control action is load-shedding, which isprimarily used when it is not necessary to process all datareceived from a charging point – as the demand pattern maybe regular and not all data samples are needed to supportforecasting. Alternatively, a sample strategy (considering everynth sample from the data stream) may be used to approximatecharging demand patterns. In this case, data in the buffer canbe dropped based on the chosen sampling strategy. Figure 5reproduces the previous scenario, but in this case ds1 andds2’s configuration parameters state a threshold of 50 tokensfor their buffer occupancy before the control logic drops data.

Depending on the buffer strategy (e.g FIFO, LIFO, etc) oldestor newest data may be dropped. The graphs in figure 5 showhow buffer occupancy time is shortened and how the numberof resources in use can be reduced.

These previous scenarios show the behaviour of the tokenbucket and control actions to enforce the QoS of each datastream simulating punctual but strong burst to show the waythe system adapt resources and data injection rates. Howeverdata streams may have very irregular data injection rates, asillustrated in Figure 6.

Fig. 5. Throughput rate with self-configuring control and TB at each stageusing load-shedding in case of congestion.

We use the Poisson distribution to control both the prob-ability of having bursts (by defining burst inter-arrival time)and a burst’s duration. We set both the burst inter-arrival timeand the burst’s duration between 1s and 6s. The top graphshows a sample of irregular input rates distribution in time.The graph in the middle shows how ds2’s token bucket isadapting to 20 tokens/s during the intervals shown by thered boxes. As a consequence of this adaptation at the firststage, there are few impacts on the second stage as shown inthe bottom figure where the load-shedding mechanism in thatstage was not triggered.

B. Experiment 2: Processing Demand Surge

In this scenario, we evaluate the influence of varying thedata processing rate on each stream arriving at an aggregatornode. We consider the previous scenario in which two datastreams ds1 and ds2 are executed simultaneously over twoshared nodes. The left part of Figure 7 shows the output ratesof ds1 and ds2 with no addition of resources when data canrequire more processing time (this is typically the case whenfault tolerance mechanism are introduced which can generateextra processing overheads). In this simulation, we can observethat the processing rates for ds1 at the first stage is reduced

Fig. 6. Throughput rate with self-configuring control and TB at each stagein an irregular input rate scenario.

to 5 tokens/s between time 120s and 240s. Resources areprovided to injected tokens assuming all tokens require thesame processing time. However, in this new scenario, tokenscoming from ds1 require more processing time. The graphshows how the throughput of ds1 falls to 20 token/s at time120s, and how this variation affects the other applicationssharing the resources.

Fig. 7. Throughput rate with self-configuring control and TB at each stage.

The right part of Figure 7 now shows the output rates ofds1 and ds2 with the a resource provisioning mechanism thattake into account the variation of data processing rates. Thecontrol loop triggers the addition of new resources when thedifference of input and output rates of ds1 in the first stage isover a given threshold. Without loss of generality, we assumehere that the penalization cost is larger than the additionalresource cost. In this case, the control loop adds two additionalresources to the first stage. At time 240s ds1 recovers itsinitial data processing rate of 10 tokens/s. The control loopreturns resources when the number of resources show morecapacity than the input rate. We can also see that althoughthe fault tolerance mechanism does affects the throughput ofthe other workflows, the impact here is much smaller and themean throughput is maintained. The figures also show that theprocessing rate after this variation is a little over the input ratebecause of the tokens that were built up in the buffer of thePU.

V. RELATED WORK

Research in Data Stream Management Systems (DSMS)and Complex Event Processing (CEP) has evolved separately,despite the fact that both communities share a number of

important similarities and challenges such as scalability, faulttolerance and performance. Data Stream Management Systems(DSMS) shifted the paradigm of Database Management Sys-tems as the need for efficiently processing streamed datasetsin real-time or nearly in real-time arose. In general, DSMSsfocus on performance by restricting the language in which theycan be programmed to graphs of operators with well-definedsemantics [10]. This allows these systems to automaticallyrewrite or compile the specified stream pipelines to a moreefficient version. Scalability and query distribution were con-sidered in Aurora [11], Borealis [12] and Stream Cloud [13].Additionally, QoS support in DSMS has been a critical require-ment [10] and a number of complex scheduling strategies andheuristics have been developed. When the data streams arriveto the system at an expected rate with low variability, nearoptimal scheduling strategies have been proofed to enforceQoS for multiple data streams successfully. In contrast, in casethe data streams arrive with unpredictable and variable bursts,the scheduling heuristics consist of complex combinationsof strategies that may not always show satisfactory QoSenforcement [10]. For that reason, these systems incorporateload shedding strategies – i.e. discarding of data elementsfrom a stream where the loss of some data elements isacceptable. In our approach, we want to avoid the complexityof scheduling strategies for dealing with variable data rates anddata bursts. Hence, we rely on estimations of average inputrates for data streams, a token bucket model for regulatingdata access to the computational resources, on the elasticProcessing Unit Component (increase / decrease of the numberof computational resources) and on the autonomous behaviorof each node.

DSMSs have little or no support to express events as theoutcome of continuous queries nor further support to formcomplex events. CEP has seen a resurgence in the last fewyears, though the need for events, rules, and triggers wasaccomplished more than two decades ago. Examples of CEPare SPADE/IBM InfoSphere Streams, Esper and DROOLSFusion [14]. The main difference between existing CEP andstream processing systems is that in the former each eventis processed at arrival time, while stream processing systemsinvolve accumulating a data set over a time (or count – i.e.when a certain number of events have arrived) window andprocessing it at once. Event processing systems assume thatthe incoming events are not bursty and do not generally con-sider the presence of queues/buffers between event operators.Additionally, most CEP have little support for QoS require-ments, except for the MavEStream system [10] that integratesCEP into a QoS-driven DSMS system. Again, MavEStreamsystem enforces QoS by complex scheduling heuristics thatmay not always perform suitably under bursty conditions.Additionally, this lack of QoS support in CEP has also beenrecently considered in the literature: in [15] several micro-benchmarks were proposed to compare different CEP enginesand assess their scalability with respect to a number of queries.Various ways of evaluating their ability to changes in loadconditions were also discussed. Regarding scalability, which

has not received much attention in CEP, some event processinglanguages extend production rules to support event processingand provide run-time optimizations by extending the Rete [16]or Treat [17] algorithms to scale with the number of queries.In [18] the importance of scalability for CEP is recognisedand event processing is partitioned into a number of stages.At each stage resources can process all of the incoming eventsin parallel under peak input event traffic conditions. Howeverthis approach does not provide a run-time adaptation, does notinvolve queues and buffers and assumes the best-effort strategy(as is usual in CEP).

VI. CONCLUSIONS

EV charging imposes a load on electricity distributionnetworks which are already operated close to their loadinglimit. Hence, a more efficient management of the energywill be required and electricity distribution and generationinfrastructures will be turning into Smart Grids. This involvesdemand forecast methods, state estimation techniques and real-time monitoring, leading to communication and control ofresidential and city areas taking place at a fine granularity.Identifying charging schedules for EVs that take into accountuser demand, electricity grid capacity and cost considerationscan often require dealing with large-scale data in real-time,from multiple distributed third-party sources. When considerfiner grained analysis of the sources of energy consumption inthe EV context, it is necessary to obtain data from the vehiclesalong with data from charging points.

In this paper, we analyse the computational requirements forEV electricity demand forecasting and propose a system modeland an architecture. Our model can support different sourcesof information, such as data streams coming from sensorsor historical data (i.e. past load demand) from databases.Our focus here is on EVs that are used by individuals in aresidential or city context, and not on vehicle fleets wherecharging models can be different. We envision that informationneeded to support EV demand forecasting will consist of (i)heterogeneous data formats & transmission rates; (ii) irregu-lar/bursty data streams; and (iii) variable, difficult to predictprocessing requirements per data stream. The processing ofthese data streams may involve filtering, data correlation andtrends analysis. The underlying network and computationalarchitecture must therefore support Quality of Service (QoS)constraints to be observed to support the generation of timelyforecasts. We propose a distributed computing architecture anda model for supporting EV demand forecasting, which consistsof a number of autonomous stages, where each stage consistsof a combination of data access and regulation, computation,data transfer capability and a rule-based controller component.We envisage that these kinds of applications will certainlygrow given the trend on smart cities and other near-real timesurveillance applications, especially involving stream analysisand coorelation from a variety of different data sources. Theproposed distributed computing architecture, along with themodel that consists of a number of autonomous stages, arefully compatible with a multi-tenancy, shared Cloud environ-

ment – enabling multiple data streams to be processed usingthe same elastic infrastructure.

REFERENCES

[1] BERR and DfT, “Investigation into the scope for the transport sectorto switch to electric vehicles and plug-in hybrid vehicles,” Available at:http://www.bis.gov.uk/files/file48653.pdf, Tech. Rep., February 2008.

[2] F. McMorrin, R. Anderson, I. Featherstone, and C. Watson, “Plugged-in fleets: A guide to deploying electric vehicles (EVs) in fleets,” TheClimate Group, Tech. Rep., February 2012.

[3] P. Papadopoulos, “Integration of electric vehicles intro distributionnetworks,” Ph.D. dissertation, Cardiff University, 2012.

[4] P. Papadopoulos, O. Akizu, L. Cipcigan, N. Jenkins, and E. Zabala,“Electricity demand with electric cars in 2030: comparing Great Britainand Spain,” Proceedings of the Institution of Mechanical Engineers, PartA: Journal of Power and Energy, vol. 225, no. 5, pp. 551–566, 2011.

[5] R. Tolosana-Calasanz, J. A. Banares, and O. F. Rana, “Autonomicstreaming pipeline for scientific workflows,” Concurr. Comput. : Pract.Exper., vol. 23, no. 16, pp. 1868–1892, 2011.

[6] R. Tolosana-Calasanz, J. A. Banares, C. Pham, and O. F. Rana, “End-to-end qos on shared clouds for highly dynamic, large-scale sensing datastreams,” in To appear in Proc. of 1st International Workshop on Data-intensive Process Management in Large-Scale Sensor Systems (DPMSS2012): From Sensor Networks to Sensor Clouds, 2012.

[7] ——, “Enforcing qos in scientific workflow systems enacted over cloudinfrastructures,” Journal of Computer and System Sciences, 2012.

[8] Y. Serizawa, E. Ohba, and M. Kurono, “Present and future ict infrastruc-tures for a smarter grid in japan,” in Innovative Smart Grid Technologies(ISGT), 2010, jan. 2010, pp. 1 –5.

[9] S. Ingram, S. Probert, and K. Jackson, “The impact of small scale em-bedded generation on the operating parameters of distribution networks,”UK Department of Trade and Industry (DTI), Tech. Rep., 2003.

[10] S. Chakravarthy and Q. Jiang, Stream Data Processing: A Quality ofService Perspective Modeling, Scheduling, Load Shedding, and ComplexEvent Processing, 1st ed. Springer Publishing Company, Incorporated,2009.

[11] M. Cherniack, H. Balakrishnan, M. Balazinska, D. Carney,U. Cetintemel, Y. Xing, and S. Zdonik, “Scalable DistributedStream Processing,” in CIDR 2003 - First Biennial Conference onInnovative Data Systems Research, Asilomar, CA, January 2003.

[12] D. J. Abadi, Y. Ahmad, M. Balazinska, U. Cetintemel, M. Cherniack, J.-H. Hwang, W. Lindner, A. S. Maskey, A. Rasin, E. Ryvkina, N. Tatbul,Y. Xing, and S. Zdonik, “The Design of the Borealis Stream ProcessingEngine,” in Second Biennial Conference on Innovative Data SystemsResearch (CIDR 2005), Asilomar, CA, January 2005.

[13] V. Gulisano, R. Jimenez-Peris, M. Patino-Martinez, and P. Valduriez,“Streamcloud: A large scale data streaming system,” in DistributedComputing Systems (ICDCS), 2010 IEEE 30th International Conferenceon, june 2010, pp. 126 –137.

[14] O. Etzion and P. Niblett, Event Processing in Action, 1st ed. Greenwich,CT, USA: Manning Publications Co., 2010.

[15] M. R. N. Mendes, P. Bizarro, and P. Marques, “A performance study ofevent processing systems,” in TPCTC, ser. Lecture Notes in ComputerScience, R. O. Nambiar and M. Poess, Eds., vol. 5895. Springer, 2009,pp. 221–236.

[16] C. L. Forgy, “Rete: A fast algorithm for the many pattern/many objectpattern match problem,” Artificial Intelligence, vol. 19, no. 1, pp. 17–37,1982.

[17] D. P. Miranker, “Treat: A better match algorithm for ai productionsystem matching,” in AAAI, K. D. Forbus and H. E. Shrobe, Eds.Morgan Kaufmann, 1987, pp. 42–47.

[18] G. T. Lakshmanan, Y. G. Rabinovich, and O. Etzion, “Astratified approach for supporting high throughput event processingapplications,” in Proceedings of the Third ACM InternationalConference on Distributed Event-Based Systems, ser. DEBS ’09. NewYork, NY, USA: ACM, 2009, pp. 5:1–5:12. [Online]. Available:http://doi.acm.org/10.1145/1619258.1619265

View publication statsView publication stats