MOBILE ENERGY RESOURCES

Transcription

1 MOBILE ENERGY RESOURCES IN GRIDS OF ELECTRICITY ACRONYM: MERGE GRANT AGREEMENT: TASK 3 DELIVERABLE D1.2 EXTEND CONCEPTS OF MG BY IDENTIFYING SEVERAL EV SMART CONTROL APPROACHES TO BE EMBEDDED IN THE SMARTGRID CONCEPT TO MANAGE EV INDIVIDUALLY OR IN CLUSTERS JUNE 2010

2 REVISION HISTORY VER. DATE NOTES (including revision author) 01 27/06/2010 Step 1 and 3 by F. J. Soares and P. M. Rocha Almeida 02 01/07/2010 By E. Karfopoulos 03 01/07/2010 Step 2 Karfopoulos Evangelos 04 12/07/2010 Step 2 Moutis Panagiotis 05 18/08/2010 Overall report by P. M. Rocha Almeida and F. J. Soares 06 19/08/2010 Overall report by Mohsen Ferdowsi and Kai Strunz Page 2

3 AUTHORS C. L. Moreira David Rua E. Karfopoulos E. Zountouridou F. J. Soares I. Bourithi I. Grau J. A. Peças Lopes L.M. Cipcigan Luís Seca Marios Moschakis P. M. Rocha Almeida P. Moutis P. Papadopoulos R. J. Rei Ricardo J. Bessa S. Skarvelis-Kazakos CONTRIBUTORS A. Dimeas J. Ekanayake J. Wu N. Hatziargyriou N. Jenkins S. Papathanasiou V. Lioliou Page 3

4 APPROVAL Project Coordinator DATE PPC N. Hatziargyriou 21/08/2010 Technical Coordinator INESC Porto J. Peças Lopes 19/08/2010 Work Package Leader TU Berlin Kai Strunz 19/08/2010 Access: Project Consortium X European Commission Public Status: Draft Version Submission for Approval (deliverable) X Final Version (deliverable, approved) Page 4

5 SUMMARY The project MERGE mission is to evaluate the impacts that the integration EVs will have on EU electric power systems regarding planning, operation and market functioning. One of the main objectives of the MERGE project is to address the aspects concerning the extension of existing concepts such as Microgrids (MG) and Multi-Microgrids (MMG) towards the integration of the EV with the grid. The necessary adaptations to the original MG and MMG centralized control hierarchy concepts to include EV as active participants are considered in this document. A complete framework of EV integration in power systems is presented and detailed considering normal operation and the need for an aggregating entity that provides market visibility and controllability to EV. The abnormal and emergency modes of operation are also considered under a conceptual framework for the MG and MMG technical operation. The introduced framework extends the MG and MMG concepts with the adoption of a new entity to handle groups of EV which was designated by Supplier/Aggregator. This entity is the intermediary between EV and the market in normal operation. It also provides support for the abnormal and emergency operations in coordination with the DSO. The Supplier/Aggregator combines the functions of managing DSM operations and retailing of electricity for the EV that it represents in the market. However, there may be created other frameworks, where these responsibilities are separate, involving extra communication channels between the DSM provider and the retailer. The multi-agent control strategy of Microgrids and More Microgrids projects is adapted to better exploit EV as mobile energy resources, focusing on the required agents to integrate EV in the MG concept along with additional functions to be included in the Microgrid Central Controller. The concepts of mobile agents applied to MG with EV are addressed as a natural extension of the original MG and MMG frameworks. Three types of control structures were defined in the scope of an extended framework: Centralized hierarchical control; Multi-Agents System for distributed control; Mobile agents control. The unique characteristics of EV batteries are explored considering several possible charging schemes to enhance the networks operating conditions avoiding the need to reinforce the network. A set of possible EV provided ancillary services was also defined for frequency (primary and secondary reserves provision) and voltage (local and coordinated) control. For each of the services the coordination done by the Electric Vehicles Supplier/Aggregator (EVS/A) was described. Using the developed framework, several charging strategies and possible ancillary services to be provided by EV are addressed. These strategies were considered from the least demanding to the most demanding in a user s perspective. The most basic charging strategy was denominated dumb charging, followed by the fixed-tariff contract, the smart charging and the V2G mode. Page 5

6 Experience gathered from the participation of ICCS/NTUA in EUDEEP and More Microgrids projects in the field of the communication protocols is presented, providing an insight towards the future implementations of MG with EV. The overview of the electric grid standards and requirements related with Power Quality/Electromagnetic Compatibility issues provides the necessary information regarding the integration of EV with MG in different scenarios. Recommendations are derived to enable the adoption of MG-EV concepts emphasizing the similarities that EV have with DER in terms of power quality definitions. Page 6

7 TABLE OF CONTENTS 1 INTRODUCTION CONCEPTUAL FRAMEWORK FOR EV INTEGRATION Introduction Normal System Operation Abnormal System Operation or Emergency Mode Integrated Technical Management/Market Operation Framework for EV Integration into Electric Power Systems MULTI-AGENT CONTROL STRATEGY FOR EV RESOURCES Introduction Multi-Agent Systems (MAS) Enhanced Architecture Java Agent DEvelopment (JADE) Framework Defining Functionalities and Specifications of Agents APPLICATION OF MOBILE AGENTS FOR EV RESOURCES Introduction Mobile Agents Mobile Agent Benefits Requirements Application of Mobile Agents for EV Resources EV CHARGING MODES AND ANCILLARY SERVICES PROVISION Introduction Charging Modes Voltage and Frequency Support Modes LEARNING FROM EXPERIENCE IN COMMUNICATION PROTOCOLS IN GREEK MICROGRIDS Introduction Communication Protocols Used Test Site Topologies and Communication Schemes Experience from the Communication Issues Building on the experience Integrating EV in Microgrids ADAPTING MICROGRID-EV CONCEPTS TO DIFFERENT EUROPEAN GRID STANDARDS RELATED TO POWER QUALITY Introduction Review of European Standards on Power Quality Electric Vehicles and Power Quality Conclusions FINAL REMARKS REFERENCES ABBREVIATIONS...82 Page 7

8 Page 8

9 1 INTRODUCTION This deliverable intends to address all the aspects related to the extension of the existing concepts of Microgrids and Multi-Microgrids, in order to fully integrate EV. To do so, this report is structured in the following sections: 1. INTRODUCTION 2. CONCEPTUAL FRAMEWORK FOR EV INTEGRATION 3. MULTI-AGENT CONTROL STRATEGY FOR EV RESOURCES 4. APPLICATION OF MOBILE AGENTS FOR EV RESOURCES 5. EV CHARGING MODES AND ANCILLARY SERVICES PROVISION 6. LEARNING FROM EXPERIENCE IN COMMUNICATION PROTOCOLS IN GREEK MICROGRIDS 7. ADAPTING MICROGRID-EV CONCEPTS TO DIFFERENT EUROPEAN GRID STANDARDS RELATED TO POWER QUALITY 8. FINAL REMARKS This section describes the main goals of the deliverable and the structure of the document. Section 2 establishes the link between the original MG and MMG centralized control hierarchy concepts and the necessary adaptations to include EV as active elements within this framework. However, in order to do so, a complete framework of EV integration in the power system must be presented and detailed. Initially, it presents the market structure for EV in normal operation and the need for an aggregating entity that provides market visibility and controllability to EV. Only after, the section provides the conceptual framework for the MG and MMG technical operation in abnormal and emergency modes of operation. Section 3 adapts the multi-agent control strategy of the Microgrids and More Microgrids projects to better exploit EV as mobile energy resources. It focuses on the agents required to integrate EV in the MG concept and discusses some additional functions that should be included in the Microgrid Central Controller (MGCC). Section 4 describes the concepts of mobile agents and the potential synergies that can be established by applying these concepts to MG with EV. Due to EV nature the usage of mobile agents is a natural extension of the original MG and MMG frameworks. The requirements for the application of mobile agents in MG with EV are also described. In section 5 the fact that EV batteries are loads with unique characteristics, medium to high power consumption over a given period of time and with some degree of predictability is explored. First, it presents several possible schemes for charging EV batteries to enhance the networks operating conditions avoiding the need to reinforce the network. Second, different ancillary services are defined, when controllability is considered for EV, namely the provision of both voltage and Page 9

10 frequency control. Finally, different strategies for provision of these ancillary services are described. In section 6, the experience gathered from the participation of ICCS/NTUA in EUDEEP and More Microgrids projects in the field of the communication protocols is presented, providing valuable inputs for future implementations of MG with EV. Section 7 presents a review of standards and requirements related with Power Quality/Electromagnetic Compatibility issues. Finally, section 8 highlights the most important conclusions that can be drawn from the presented work. Page 10

11 2 CONCEPTUAL FRAMEWORK FOR EV INTEGRATION 2.1 Introduction The technical management of an electric power system having a large scale deployment of Electric Vehicles (EV) will require, for their battery charging, a combination of: A centralized hierarchical management and control structure; A local control located at the EV grid interface. The simple use of a smart device interfacing the EV with the grid does not solve all the problems arising from EV integration in distribution networks. These interfaces can be rather effective when dealing with the likely occurrence of voltage drops that may be caused by EV charging, by locally decreasing charging rates through a voltage droop control approach. However this local solution fails to address issues that require a higher control level, such as managing branches congestion levels or enabling EV to participate in the electricity markets. For these cases, coordinated control is required and so a hierarchical management and control structure responsible for the entire grid operation, including EV management, must be available. Therefore, the efficient operation of such a system depends on the combination/coordination of local and centralized control modes. The latter control approach relies on the creation of an adequate communications infrastructure capable of handling all the information that needs to be exchanged between EV and the central control entities organized in a hierarchical structure. When operating the grid in normal conditions, EV will be managed and controlled by a new (central) entity the Aggregator whose main functionality will be grouping EV, according to their owners willingness, to exploit business opportunities in the electricity markets [1], [2]. If EV would enter this market individually their visibility would be small and due to their stochastic behaviour rather unreliable. Nonetheless, if an aggregating entity exists, with the purpose of grouping EV to enter in the market negotiations, then the services provided would be more significant and the confidence on its availability much more accurate. In this sense, a conceptual framework capable of dealing with EV presence was adopted, as explained later on this document. It is important to notice that the Aggregator is not responsible for selling electricity to the EV. This service will be provided by the traditional electricity suppliers that offer services to end-users. However, due to economic reasons, it is very likely that the Aggregator and the Supplier will be merged in one single entity. Therefore, in this document, the designation of Electric Vehicle Supplier/Aggregator (EVS/A) was used when describing activities related with both these entities. Even considering the EVS/A existence, a still high degree of uncertainty will exist related to when and where EV will charge, namely in Low Voltage (LV) grids. Due these uncertainties and assuming that networks will evolve towards a decentralized generation paradigm, the existence of a grid monitoring structure, such as the one developed for Microgrids (MG) and Multi-Microgrids (MMG), will be required. This structure will be controlled by the Distribution System Operator (DSO) and should be capable of acting over EV charging in abnormal operating conditions, i.e. when the Page 11

12 grid is being operated near its technical limits, or in emergency operating modes, e.g. islanded operation [1], [2]. The technical and market management proposed structures will be thoroughly described in the next sections of this document. 2.2 Normal System Operation The Electric Vehicle Suppliers/Aggregators As discussed in the MERGE Report for WP1.1 entitled Specify Plug-and-Play for EV, Section 1.1 entitled Definitions, the aggregator is defined as an entity responsible for grouping charging demand of a number of EV and offering demand management and other possible services from this aggregated number of EV to the market. It was also mentioned that the aggregator would likely be owned by the supplier companies as it makes it economically a more justifiable business. This is why we will often refer to the combination of these two entities calling it EV supplier/aggregator (EVS/A). In what follows, such an EVS/A is described in more detail. In order to manage a large amount of EV parked in a large geographical area, where Medium Voltage (MV) and LV grids exist, the existence of an EVS/A will be necessary to serve as an interface between EV and electricity markets. These EVS/A will have the capability of grouping EV so that together they represent a load/storage device with the adequate size to participate in electricity markets, in a similar way as described in [3]. It is important to stress that the EVS/A will always take into account the drivers requests, which will provide information about power demand and connection period via the smart meter. In the same regional area, several EVS/A might co-exist and compete to gather as much clients as possible. This competition will be beneficial for the EV owner, who will be able to choose for his EVS/A the company that better fits to his needs. Given the complexity of the information that an EVS/A needs to collect and process, a hierarchical management structure for the activities related with EV aggregation, independent from the DSO, is suggested in this document (Fig. 1). Since each EVS/A develops its activities along a large geographical area, e.g. a country, it will be composed by two different types of entities: the Regional Aggregation Unit (RAU) and the Microgrid Aggregation Unit (MGAU). The RAU is considered to be located at the High Voltage (HV)/MV substation level, with possibly a maximum of costumers, communicating with several downstream MGAU which, by their turn, will be located at the MV/LV substation level, with an expected maximum of about 400 costumers each. The RAU and the MGAU were created in order to decrease communications and computational burden that a real implementation of the concept would require. This will provide the EVS/A preprocessed information regarding groups of EV located in the LV and MV grids. Each EV must have a specific interface unit the Vehicle Controller (VC) to enable bidirectional communication between the EV and the upstream EVS/A. The VC may be located in the smart meter to which EV will be connected. In addition to the VC there is a new type of element, the Cluster of Vehicles Controller (CVC), designed to control the charging of large parking lots (e.g. shopping centres), and fed directly from the MV network. Individual controllers of EV under a CVC management do not have an active VC communicating with higher hierarchical controllers. For normal Page 12

13 operation, the VC will interact with the MGAU and the CVC directly with the RAU [1], [2]. MV Level CVC CVC Regional Aggregation Unit CVC VC LV Level EV Owner Smart Meter VC EV Owner Microgrid Aggregation Unit Microgrid Aggregation Unit Smart Meter VC EV Owner Smart Meter SUPPLIER/AGGREGATOR Microgrid Aggregation Unit Regional Aggregation Unit MV Level CVC CVC CVC VC Smart Meter VC Smart Meter VC Smart Meter LV Level EV Owner EV Owner EV Owner VC EV Owner Microgrid Aggregation Unit Microgrid Aggregation Unit Smart Meter VC EV Owner Smart Meter VC EV Owner Smart Meter VC EV Owner Microgrid Aggregation Unit Smart Meter VC EV Owner Smart Meter VC EV Owner Smart Meter Fig. 1 EVS/A hierarchical management structure Electric Vehicles Supplier/Aggregators Market Activities Fig. 2 presents an overview of the EVS/A market activities, whereas Fig. 3 depicts the procedure that can be followed by these entities for participating in the dayahead market [3]. Regarding Fig. 3, at time step t A the EVS/A forecasts the total EV electrical energy consumption (load), the total battery SOC (divided by client type), and the number of EV plugged (divided by client type) in each hour of day D+1. At time step t P the EVS/A forecasts the spot and balancing prices for the next day. Finally, at time step t B the EVS/A based on the forecasted EV load, SOC, EV availability, and market prices defines the hourly bids for buying and selling electrical energy in the dayahead and ancillary services market. Besides the uncertainty in the market prices, the EVS/A also faces uncertainties in the EV owner s behaviour and preferences. The main sources of uncertainty are: Page 13

14 departure time instant, arrival time instant, distance, and preferences (e.g. when and how much to charge the battery). Electricity Market Operators Fig. 2 Market operation framework for EV integration into electric power systems The total load, EV availability and battery SOC can be forecasted with standard techniques used in load and wind power forecasting. Note that the EVS/A must associate a bid (quantity and price) to a network node. Therefore it must produce forecasts by network node. Based on the forecasts, the EVS/A must define periods where it is possible to manage the charging (load) by moving it from one hour to other. The EV forecasted load gives an estimative of the total required battery SOC of the EV owners, which means that the EVS/A can move this electrical energy along the hours but in the end (when the vehicle is unplugged) the battery SOC should match the EV owner preference. Hence, for the day-ahead bids the EVS/A must do a roughly estimative of the load, and then, with more information, can correct it in the subsequent markets. Page 14

15 Having their buy/sell bids defined, a prior validation by the DSO must exist to prevent the occurrence of severe congestion and voltage problems in the distribution networks. The EVS/A will present their day-ahead proposal to the DSO, which will analyse it to evaluate its technical feasibility. If valid, the EVS/A can proceed to the market negotiation. If not, the DSO will ask the EVS/A to make the changes needed to guarantee a safe operation of the distribution grid in the next day. It is foreseeable that in this case the DSO will have to compensate the EVS/A by this service. The DSO might even request the EVS/A to change further its plans in order to decrease the energy losses in the distribution network. If the market prices of electricity are cost reflective (i.e. include the cost of electricity generation, transmission and distribution), a direct consequence of the hourly energy prices variation will be the flattening of the daily load diagram. As response to the energy prices, EVS/A will naturally perform load shifting in order to provide energy at a lower cost to their clients. They will buy electricity from the market mainly during the night, at lower prices, to charge their clients EV, and they may sell it during the day, at peak hours, taking advantage of their clients EV storage capability. EVS/A will compete directly with electricity retailers for energy acquisition and with Generation Companies (GENCO) for selling energy. Taking advantage of EV capability to provide reserves, EV might offer also in the electricity markets these system s services to the Transmission System Operators (TSO), competing once again with the GENCO. Also with this approach it will be possible to have EV participating in secondary frequency control, through the link TSO EVS/A. Forecasting Tool Forecasting Tool Decision aid Tools Market Closing EV Load, Availability, SOC Forecast Price Forecast Day ahead Bids Ancillary Services Bids Submit bids Application of the day ahead market 24 hrs t A t P Day ahead period (D) t B 10:00 ( 14:00) 0:00 Day of Operations (D+1) Fig. 3 Timeline of day-ahead market and EVS/A market bidding After market closure, the TSO proceeds to the evaluation of the load/generation schedules and, if problems on the transmission system are foreseen, it requests modifications to these schedules until feasible operating conditions are attained. Every day the EVS/A will manage the EV under its domain, according to what was previously defined in the market negotiations and validated by the TSO, by sending Page 15

16 set-points to VC or CVC related with rates of charge or requests for provision of ancillary services. To accomplish successfully such a complex task, it is required that every fixed period (likely to be defined around 15 minutes), the State of Charge (SOC) of each EV battery is communicated to the EVS/A, to assure that, at the end of the charging period, batteries will be charged according to EV owners requests [1], [2]. Parking and new battery supplying are also services that EVS/A can negotiate in other markets, as mentioned in [4] and included in Fig. 2. Nonetheless, these parallel markets negotiations will not be addressed in this subtask. 2.3 Abnormal System Operation or Emergency Mode When grid normal technical operation is compromised, market management can be overridden by the DSO. For these abnormal or emergency conditions, it makes sense to adapt the MG and MMG hierarchical monitoring and management structure, as it already includes a suitable communications infrastructure capable of managing the presence of EV, either individually connected at the LV level or as a cluster of EV (fleet charging station or fast charging station cases) connected at the MV level. This communication can exploit, as described in D1.2, the smart metering infrastructure that can be available locally. In the next sections of this document it will be presented the more relevant MG and MMG concepts, as well as the required improvements to make them suitable to handle EV charging in the desired manner Microgrids and Multi-Microgrids Concepts The MG concept was introduced in the USA by the Department of Energy, who founded the Consortium for Electric Reliability Technology Solutions (CERTS) in 1999 to research and develop new methods, tools and technologies in order to protect and enhance the reliability of the USA electric power system and the efficiency of competitive electricity markets [5]. In European Union the MG concept was first studied in the MICROGRIDS Large Scale Integration of Micro-Generation to Low Voltage Grids funded R&D project [6], which defines the MG as a LV grid where electrical loads coexist with small generation systems and with storage devices. All these elements are managed and controlled by a hierarchical control system as it will be described in the next section. The MG concept developed within the MICROGRIDS project is shown in Fig. 4. This typical LV distribution network might be operated in the normal interconnected mode, when it is connected to the secondary winding of a MV/LV distribution transformer, or in isolated mode, when for some reason there is the need to be disconnected from the upstream MV network. Page 16

17 Fig. 4 MG architecture, comprising micro-sources, storage devices and a hierarchical control and management system [7] Microgrid Hierarchical Control and Management System The MG system in centrally controlled and managed by the Microgrid Central Controller (MGCC), installed in the LV side of the MV/LV distribution transformer, which communicates with controllers located in a lower hierarchical level that, by their turn, control local micro-generation units and storage devices. The Microsource Controllers (MC) controls the microgeneration units while the loads or group of loads are controlled by a Load Controller (LC) [8]. In addition, the MGCC must be able to communicate with the Distribution Management System (DMS), located upstream in the distribution network, contributing to improve the management and operation of the MV distribution system. The MC will have autonomy to perform local optimization of the microgeneration units active and reactive power production, when connected to the power grid, and fast load-tracking following an islanding situation. LC also need to be installed at the controllable loads to provide load control capabilities following demands from the MGCC, under a DSM policy, or in order to implement load shedding functionalities during emergency situations [6], [8]. The MGCC heads the technical and economic management of the MG. During the normal interconnected mode, the MGCC collects information from the MC and LC in order to perform a number of functionalities, being the most relevant the forecasting of local loads and generation. While in emergency mode, an immediate change in the output power control of the MC is required, as they change from a dispatched power mode to one controlling frequency and voltage of the islanded section of the network. Under this operating scenario, the MGCC performs an equivalent action to the secondary control loops existing in the conventional power systems: after the initial reaction of the MC and LC, which should ensure MG survival following islanding, the MGCC performs the technical and economical optimization of the islanded system [6]. Page 17

18 It is expected that several aspects concerning Microgrids, which may be not defined yet, will arise from EV field tests experience providing possible inputs for adapting the envisioned concepts to fully integrate EV. In particular, the MGCC should be prepared to house among other possibilities the following functionalities: Track energy consumption of EV charging at the specific MG; Record average number of charging processes; Track balancing of charging and fluctuating renewable energy availability, if present; Record average energy consumption per charging Multi-Microgrid Hierarchical Control and Management Structure The MMG is related to a higher level structure, formed at the MV level, composed by several LV MG and Distributed Generation (DG) units connected on adjacent MV feeders. The technical operation of such a system requires transposing the MG concept to the MV level where all active elements are controlled by a Central Autonomous Management Controller (CAMC) to be installed at the MV bus level of a HV/MV substation, serving as an interface to the DMS, under the responsibility of the DSO. Each MG is an active cell of the MMG and the MV/LV substations can also be controlled by the CAMC. In fact, the CAMC may be seen as a DMS application that is in charge of one part of the network. It will be responsible for the data acquisition process, for enabling the dialogue with the DMS upstream, receiving information from Remote Terminal Units (RTU) located in the MV network, for running specific network functionalities and for scheduling the different agents in the downstream network [9]. In general terms, this new management architecture is described in Fig. 5. Fig. 5 Control and management architecture of a MMG [9] Page 18

19 The MMG hierarchical control system can be represented by the block diagram in Fig. 6. The commands needed to modify generation and load are originated in the CAMC. These commands are sent to MGCC, to independent DG units and also to controllable MV loads. MGCC act as an interface between the CAMC and the internal active components of the MG, so that the CAMC doesn t need to have the details of each MG constitution. Fig. 6 Hierarchical control scheme for MMG [9] Enhancement of the Microgrid and Multi-Microgrid Hierarchical Control Structure to Manage EV Charging As referred previously, when grid normal technical operation is compromised, market management will be overridden by the DSO, which will use the MG and MMG hierarchical monitoring and management structure to correct the problems identified. Nonetheless, to make this solution possible, some improvements need to be done to the MG and MMG management structure described above. Within a LV MG, besides controlling loads, microgeneration units and fixed storage devices, the MGCC must be upgraded to control also EV batteries through the VC, as presented in Fig. 7. When considering a MMG environment, an extra element needs to be considered the CVC in order to be possible to manage clusters of EV (fleet charging stations or fast charging stations) connected directly at the MV level. This way, the elements of the MV grid, including clusters of EV, can be technically managed by the CAMC, which is installed in the HV/MV substation. As referred previously, all the CAMC will be under the supervision of a single DMS, which is directly controlled by the DSO. It is important to stress that, in abnormal system operation conditions or in emergency modes, all the technical management and control tasks are a responsibility of the Page 19

20 DSO, being performed by a main control entity, the DMS, and by the other distributed entities, CAMC and MGCC [9]. Fig. 8, which is the upgraded version of Fig. 6, presents the envisaged hierarchical management and control system for EV in a MMG environment. Fig. 7 Structure and elements of a MG that includes EV DMS Control Level 1 CAMC Control Level 2 Control Level 3 MGCC SVC Load DG OLTC CVC MC LC VC Fig. 8 Hierarchical control scheme for a MMG with EV Page 20

21 2.4 Integrated Technical Management/Market Operation Framework for EV Integration into Electric Power Systems Fig. 9 presents the envisaged framework for EV integration into electric power systems, which was developed to merge the electricity markets operation with the networks technical management in an efficient manner [1], [2]. The figure denotes the clear symbiosis existing between both approaches, as well as the synergies between all the entities involved. When operating the grid in normal conditions, EV will be managed and controlled by the EVS/A within a market environment, as described in the right-hand side column of Fig. 9. Nevertheless, due to high uncertainties related to when and where EV owners will charge their vehicles, the existence of a grid monitoring structure will be required, controlled by the DSO, with the capability of acting over EV charging in abnormal operating conditions, i.e. when the grid is being operated near its technical limits, or in emergency operating modes, e.g. islanded operation. This structure, based in the MG and MMG concepts, is presented on the left column of Fig. 9. As depicted in Fig. 9, the RAU is at the same level of CAMC (located at the HV/MV substation level) and the MGAU at the same level of MGCC (located at the MV/LV substation level). If an abnormal or emergency situation occurs, the EV might receive simultaneously two different set-points, one from the EVS/A and other from the monitoring and management structure headed by the DSO. To avoid violation of grid operational restrictions, the DSO signals will override the EVS/A ones, and compensation will be provided to EV. Technical Operation Market Operation CONTROL HIERARCHY PLAYERS Generation System GENCO Electric Energy Reserves Transmission System TSO Reserves Technical Validation of the Market Negotiation (for the transmission system) Distribution System Control Level 1 Control Level 2 Control Level 3 DMS CAMC MGCC DSO MGAU RAU Suppplier/Aggregator Reserves Electric Energy Electric Energy Electricity Supplier Electric Energy Electricity Market Operators Parking Parking Battery Replacement Battery Replacement CVC VC EV Owner/Electricity consumer Parking Facilities Battery Suppliers Electricity Consumer Controls (in normal system operation) Controls (in abnormal system operation/emergency mode) At the level of Communicates with Sell offer Buy offer Technical validation of the market results Fig. 9 Technical management and market operation framework for EV integration into electric power systems Page 21

22 3 MULTI-AGENT CONTROL STRATEGY FOR EV RESOURCES 3.1 Introduction This section is concerned with the definition of the types of agents required to satisfy the specific control requirements as they are set in the subtasks 1, 2 and 3 of the Task 1.3 of the MERGE project. The Multi-Agent control strategy of the Microgrids and More Microgrids projects is enhanced to best exploit the EV as mobile energy resources. The environment of the enhanced architecture includes EVs and the processes that are considered for the control system are: Technical operation of the distribution system and Market participation. The MAS control that was developed in the Microgrids and More Microgrids projects is implemented. This report focuses on the agents required to integrate EV in the MG concept and discusses some additional functions that should be included in the MGCC. The literature on Agents and Multi-Agent Systems is very wide. In the following section, the basic agent principles are provided, in order to clarify the types of agents needed to control a Microgrid-like EV environment. 3.2 Multi-Agent Systems (MAS) MAS are the evolution of distributed control, where two or more physical or virtual (software) entities, namely agents, interact in order to reduce the complexity of a problem, by dividing it into smaller sub-problems. MAS adopt the object-oriented paradigm by keeping the information needed to solve each sub-problem private. Moreover, MAS enhance this paradigm by incorporating control over their actions, encapsulating behaviour, in addition to state [10]. The core unit of MAS, is the agent. Agent can either be a virtual entity, in terms of software component and a computing module (e.g. Microgrid EVS/A, MGCC) or a physical entity which is something that acts in the real world (e.g. electric vehicle controller). An agent is able to perceive its environment through sensors and act in the environment through actuators [11]. The basic properties which define an agent, according to Wooldridge and Jennings [12] are: Autonomy: the ability to operate in order to meet its design objectives without constant guidance from the user. Responsiveness: the ability to perceive the environment and respond to changes. Social Ability: the ability to interact with other virtual or physical agents. Pro-activeness: the ability to reason and initiate its own actions in order to meet its design objectives. These basic characteristics differentiate agents from objects, in the sense that an agent may have the ability to decide upon its actions according to the resources, skills and services that it may possess and access. The evolution of object-oriented programming is presented in Table 1. Page 22

23 Object-Oriented Programming Agent-Oriented Programming How does a unit behave? (code) What does a unit do when it runs? (state) When does a unit run? Local Local External (message) Local Local Local (rules; goals) Table 1 Evolution of object-oriented programming [Adapted from 4] A MAS is comprised of agents which are able to communicate and cooperate influencing each other s decisions and the state of their environment, aiming to meet their own and the system s needs. In order to define the types of agents needed to satisfy the specific control requirements, the Microgrid-EV like environment and its objectives are firstly defined. 3.3 Enhanced Architecture The management framework given in subtask included a new entity, the EV Supplier/Aggregator (EVS/A), which will be responsible for the coordination of charging and discharging of large number of EVs [3], [4]. The EVA will serve as an intermediary between the EVs, the Distribution System Operator (DSO) and the electricity market, as well as a data collector. The EVA characteristics are similar to those of an Energy Service Company (ESCo). Depending on the business framework that will be adopted, the EVA could be an ESCo, or a part of an ESCo. The EVA will participate in the electricity market to buy electricity in order to meet the demands of its customers [14]. Moreover, it will be responsible to manage customers EV battery charging and discharging. This control approach is considered as centralised, since a central processing unit, the EVA, collects the preferences of all EV owners and defines battery charging/discharging set-points, according to its market activities. In this sense, the EVs are not considered as intelligent resources but they are rather reactive with a limited capability of decision making. The EVA aggregates the portfolio of EVs in a large geographical area to create a single operating profile and enable its market participation. This portfolio should comprise EV owner preferences, such as (i) location, (ii) time, (iii) duration and (iv) mode of connection to the grid. In order to reduce the communication and computational requirements, the EVA follows a hierarchical structure comprising of three levels of control. This structure is similar and parallel to the DSO structure as defined in a Multi-Microgrids (MMG) environment (Task 1.3.3). To analyse the control requirements and define the information exchange and interactions between the DSO and the EVA, the management structure of the enhanced system is provided in Fig. 10. It should be noted that more than one EVA may exist in the same distribution system. Page 23

24 To High Voltage Grid Medium Voltage Network EVS/A RAU CVC To Low Voltage Networks MGAU MGAU MGAU Parking Area To Medium Voltage Network MGAU MGAU MGAU MGAU VC Parking Area Low Voltage Network VC Parking Area VC VC VC VC VC VC VC VC VC VC Parking Area VC Key Power Network Electric Vehicle Charging Point RES Communications Control Hierarchy Smart Meter Transformer DMS Distribution Management System EVS/A EV Supplier/Aggregator CAMC Central Autonomous Manag. Controller RAU Regional Aggregation Unit CVC Clusters of Vehicles Controller MGAU MG Aggregation Unit MGCC Microgrid Central Controller VC Vehicle Controller Fig. 10 Hierarchical management structure Page 24

25 Below the EVA, there are two layers of aggregation (Task 1.3.3): The Regional Aggregation Unit (RAU) The Microgrid Aggregation Unit (MGAU) The MGAU manages the charging/discharging of EVs located in its Microgrid. The purpose of the MGAU is to reduce the amount of information transferred to the RAU, by providing the RAU with a single EV load demand profile for its Microgrid. The RAU aggregates the demand profiles of each MGAU in order to send this information to the EVA, which proceeds with its market activities. In addition, these profiles must satisfy the local technical constraints of each Microgrid. The hierarchical control structure proposes that the EVA will be responsible for the wholesale market participation and the DSO for the technical operation (Task 1.3.3). To achieve both objectives, communication between these two players is required. Two different timelines are identified: (i) the day-ahead operation and (ii) the realtime operation [1] Day Ahead Operation Since the EVA could be an ESCo, it is anticipated that the EVA will buy a significant part of the required energy, in the forwards electricity market. These transactions will be based on the EV battery charging demand forecasts. The day before energy delivery, the EVA will be able to fine tune its EV load demand forecast and may prepare bids/offers according to the predicted market behaviour of the following day. This demand will consist of schedules in delivery period time steps. These schedules will be sent to the DSO for validation, which considers the technical constraints of the distribution system. After validation, the EVA can proceed with market negotiations in the wholesale market. The validated schedules are sent to each RAU which disaggregates and distributes them to each MGAU Real-Time Operation During real time and normal technical operating conditions, each MGAU receives signals from the EV regarding their owners charging preferences. The main aim of the MGAU is to manage the EV charging and discharging according to a schedule provided by the RAU. If the day-ahead schedules are modified, each MGAU should receive the updated schedule and act accordingly. The MGAU will regularly report the connected EV charging schedules to the RAU. The RAU collects the aggregated amount of energy that the MGAUs are scheduled to consume. In case this amount is different from the forecasted one, the RAU initiates coordinative actions (such as intra-day balance as explained in the next sections) to reduce possible imbalance penalties. The real-time management of the EVs charging/discharging is done with respect to the local constraints of the distribution system. Each MGCC is responsible for the technical limits (voltage, branch congestions) and will regularly collect the data related to all the EVs connected in its Microgrid. Page 25

26 3.4 Java Agent DEvelopment (JADE) Framework In order to analyse the specifications for the agents needed to satisfy the specific control requirements, the characteristics of the Java Agent DEvelopment (JADE) software platform are discussed. The adaptation of an agent-oriented approach in order to efficiently manage and control distributed resources such as EVs, raises a number of issues that must be solved, such as: Who will be responsible for the life cycle management of the agents (activation, suspension, termination) Who is going to provide yellow-page services How agents will communicate with each other These issues should be considered each time agent-programmers develop a new application. It is therefore convenient to use an agent-oriented middleware, on top of which, a developer would be able to develop his multi-agent application. Such an agent-oriented middleware should provide all the services and facilities concerning the aforementioned issues allowing the developer to consider only the business logic of the multi-agent application. JADE framework is one of the most widespread agent-oriented middleware systems. JADE s basic infrastructure can be further enhanced by add-on modules offering new functionalities and facilities. JADE provides all the facilities required to develop an agent-based application: Distributed runtime environment implementing the life-cycle support features required by agents. This environment should always remain active in order for JADE agents to live and be executed. The core logic of agents themselves. A library of classes that developers can use to implement their agents. A suite of graphical tools that facilitates the debugging, administration and monitoring of the executed agents. Runs on Personal Computers (PCs) and on Java-enabled mobile devices as well. The first software developments that eventually became the JADE platform, started by Telecom Italia (formerly CSELT) in late 1998 and it was motivated by the need to validate the early Foundation for Intelligent Physical Agents (FIPA) specifications [9]. Two years later, in 2000, JADE became open source and was distributed by Telecom under the Library Gnu Public License. This license assures all the basic rights to facilitate the usage of the software: the right to have access to the source code, the right to change the code and improve it. JADE, in terms of software, documentation, example code and guide, can be downloaded though the website: Page 26

27 Fig. 11 Graphical environment of JADE JADE is completely written in Java and JADE programmers work in full Java when developing their agents. Moreover, it is fully compliant with the FIPA, which is a collection of standards relating to software agent technology. Certain models have been developed by FIPA for the agent communication, agent management and agent architecture. Jade agents can also be executed on lightweight devices such as Java based mobile phones or devices running Microsoft.Net Framework [10]. This additional feature is enabled thanks to the Lightweight Extensible Agent Platform (LEAP) addon component developed in 2002 by Motorola, British Telecommunications, Broadcom Eireann, Siemens AG, Telecom Italia and the University of Parma. However, a number of constraints must be taken into consideration when developing mobile agents: i) the limitations of the devices themselves, ii) the limited computational resources and iii) the limited features supported by the Java Virtual Machines on these devices JADE Architecture The main architectural elements of a JADE platform are presented in Fig. 12. Each running instance of the JADE environment is called a Container and provides all the services needed for hosting and executing several agents. Various agent containers can be distributed over a network but still belong to the same JADE-platform. There is a single special container named Main Container, which is unique for each platform. In case a new Main container is launched in the same network this automatically constitutes a different platform. The main container is the first to be launched, it must always be active and all the other containers register with it as Page 27

28 soon as they start. The Unified Modelling Language (UML) diagram in Fig. 13 schematizes the relationship between the main architectural elements of JADE. The main container has the following special responsibilities [15]: Managing the Container Table (CT), which is the registry of the object references and transport addresses of all container nodes composing the platform. Managing the Global Agent Descriptor Table (GADT), which is the registry of all agents present in the platform including their current status and location Hosting the Agent Management System (AMS) and the Directory Facilitator (DF), the two special agents that provide the agent management and white page service, and the default yellow page service of the platform, respectively. Fig. 12 JADE main architectural elements [15] Apart from the main container, JADE provides each normal container with a cache of the GADT and a Local Agent Descriptor Table (LADT) which are managed locally. When an agent living in a container wants to send a message to another agent living in the same or another container, it first searches its LADT for the recipient s location and then, only if the search fails, contacts the main container in order to obtain the proper remote reference. This reference is cached locally for future usages and serves to avoid system-bottlenecks. Because the system is dynamic (agents can migrate, terminate, or new agents can appear) in this case of exception the container is forced to refresh its cache against the main-container. Page 28

29 Fig. 13 Relationship between the main architectural elements [15] Each container is identified by a logical name which is defined by the programmer: by default the name of the main container is Main Container while others are named Container-1, Container-2 etc. However, different names other than default ones can be defined according to users preferences using command-line options. Each agent possesses a unique identity which includes its name and address [15] and is contained within an Agent Identifier (AID), composed of a set of slots that comply with the structure and semantic defined by FIPA. Agents are identified by a unique name with which they can communicate with each other transparently regardless of their actual location. The agent addresses are transport addresses inherited by the platform, where each platform address corresponds to a Message Transport Protocol (MTP) end point in which FIPA-compliant messages can be sent and received. In case an agent programmer wants to implement its own private MTP, he is able to add its own transport addresses to the AID. When the main container is launched, two special agents are automatically instantiated and started by JADE, whose roles are defined by the FIPA Agent Management standard [15]: The Agent Management System (AMS) is the agent supervisor of the entire platform. It is the contact point for all agents that need to interact in order to access the white pages of the platform as well as to manage their life cycle. Every agent is required to register with the AMS (automatically carried out by JADE at agent start-up) in order to obtain a valid and unique AID. The Directory Facilitator (DF) is the agent that implements the yellow pages service, used by any agent wishing to register its services or search for other available services (Fig. 14). The DF also accepts subscriptions from agents that wish to be notified whenever a service registration or modification is made that match some specified criteria. Multiple DFs can be started concurrently in order to distribute the yellow pages service across several domains. These DFs can be federated, if required, by establishing cross-registrations with one another which allow the propagation of agents. Page 29

30 Fig. 14 Yellow Pages Services [15] Agent Behaviour The tasks that an agent has been developed to perform are carried out within a code format which is called behaviour. A behaviour is implemented as an object of a class that extends jade.core.behaviours.behaviour (default JADE class). An agent developer may design an agent to execute a specific task implemented by a behaviour by simply adding the behaviour to the agent s code, either when the agent starts or from within other behaviours. For this purpose, the default JADE method addbehaviour() has been developed. Each class extending Behaviour must implement: the action() method, that actually defines the operations to be performed and the done() method (returns a Boolean value), that specifies the end of a behaviour s execution in order to be removed from the queue of behaviours an agent is carrying out. The execution of a behaviour is triggered by the action() method and runs until it returns. Several behaviours can be executed concurrently. The switch from the execution of a behaviour to the execution of the next one is defined by the programmer. When a behaviour switch occurs the status of an agent does not include any stack information and is therefore possible to save it for a persistent storage for later resumption, or transferring it to another container for remote execution (agent mobility). There are three types of behaviours [15]: One-shot behaviour that completes immediately and whose action() method is executed only once. Cyclic behaviour that never completes and whose action() method executes the same operations each time it is called. Generic behaviour that embeds a status trigger and execute different operations depending on the status. They complete when a given condition is met. Page 30

31 JADE provides two ready-made classes by means of which it is possible to easily implement behaviours that execute certain operations at given points in time [10]: WakerBehaviour : The action() and done() method are already implemented so that the onwake() method (to be implemented by subclasses) is executed after a given timeout expires. After that execution the behaviour completes. TickerBehaviour : The action() and done() method are already implemented so that the ontick() (to be implemented by subclasses) method is executed periodically with a given period. The behaviour runs forever unless its stop() method is executed Agent Communication One of the most important features that JADE agents provide is the ability to communicate. It is based on asynchronous message passing and is implemented in accordance with the FIPA specifications (Fig. 15) [15]. When an agent sends a message to a recipient, this message is stored to the recipient s message queue through the JADE run-time. After the message is stored, the recipient receives a notification. However, when, or if, the agent is going to pick up the message from the queue is defined by the agent developer. Fig. 15 Communication architecture [15] The particular format of messages in JADE is compliant with that defined by the FIPA-ACL message structure and contains the following parameters [15]: Identity of the sender of the message. Identity of the intended receivers of the message. The performative which is type of communicative act indicating what the sender intends to achieve by sending the message. The performative that will be selected depends on the sender s scope. For example, if the sender wants to inform the recipient for a fact, the INFORM performative will be used or if the sender wants the receiver to perform a task the REQUEST performative will be used etc. The content is the actual information that is enclosed in the message Page 31

32 The content language is the syntax that is used to compose a message. The communication between the sender and the receiver can be effective only if a common syntax is adopted. The ontology is the vocabulary of the symbols used in the content. Both the sender and the receiver must speak the same language. For example a German will call an eagle as Adler and Spanish as Aguila. Although they are both describing the same thing they cannot understand each other due to the different vocabulary (ontology). Some additional fields used to control several concurrent conversations and to specify timeouts for receiving a reply such as conversation-id, reply-with, in-reply-to and reply-by. 3.5 Defining Functionalities and Specifications of Agents Having defined the characteristics of the middleware that the agents can be hosted, the following section analyses the specifications of each agent. Each EV owner will be able to choose between the four charging modes that were detailed in Task 1.2.4: Fig. 16 MERGE Project charging modes for EV The specifications for the Vehicle Controller, MGAU and the RAU agents are provided: Vehicle Controller (VC) Agent The Vehicle Controller agent will be able to have various functionalities, such as continuously monitoring the EV battery parameters or/and the driver s behaviour. In this report the functionalities of the VC agent with respect to its communication with the MGAU are presented. The VC agent will be responsible for the communication of the EV owners preferences to the respective MGAU agent. Two cases are identified: The hardware which will host the agent is located on the EV; the VC agent will be always active. The hardware which will host the agent is located in the charging point; the VC agent will be initiated at the time of connection. Page 32

33 In any case, the interaction between the VC and the MGAU will start with a login phase which will assist with billing and security issues. In the JADE implementation, the VC agent will be able to find the MGAU agent responsible for the specific MG through the Directory Facilitator (DF). In the login phase, the agent will register its services and will transfer to the MGAU: The Identification (ID) number of the charging point/ev. The charging mode. The actual State of Charge (SOC) of the EV battery. The connection duration. The desired SOC at the end of the connection duration. If the EV owner chooses an uncontrolled charging mode, the only information that will be transferred, is the actual SOC and the ID of the charging point/ev. During the operational phase (the time that the EV is connected to the charging point) the VC agent will regularly monitor the battery SOC and send it to the MGAU agent at specific time intervals (e.g. 15 minutes). This can be done in JADE with the ready-made class TickerBehaviour. For smart charging or V2G mode the VC agent will receive set-points from the MGAU to adjust the EV battery charging rate. The VC agent will have to pass this on to the battery management system, but it is beyond the scope of this document to discuss this process. The VC agent will always give priority to MGCC signals which will be sent during abnormal/emergency situations (i.e. technical limits of the Microgrid are violated/islanding). At the logout phase, the VC agent will inform the respective MGAU. This behaviour is executed when: The battery is fully charged (except when the EV is in V2G mode) The charging session has finished. The EV owner decides to disconnect. If the EV owner decides to change the charging preferences, the VC agent informs the respective MGAU for this change and transfers the new preferences Microgrid Aggregation Unit (MGAU) Agent The main responsibility of the MGAU is to manage the EV battery charging/discharging according to the day-ahead schedule issued by the RAU. If any changes occur in the schedule, the RAU will send the updated schedule to the MGAU. During normal operation (MG is operating within technical limits) at 15- minute intervals, the MGAU: Sends updated data to the RAU regarding the EV connected in its Microgrid. Page 33

34 Sends updated data to the MGCC regarding the EV connected in its Microgrid. During abnormal/emergency operation, the MGAU receives from the MGCC information regarding the corrective actions taken Microgrid Central Controller (MGCC) Agent Additional Functionality The MGCC contains a catalogue with all the MGAUs operating in its Microgrid with data for each EV connected. The catalogue is regularly updated to ensure that the technical limits of the Microgrid are not violated. In JADE, this catalogue can be maintained by requesting in pre-defined time intervals the services for each EV from the MGAU. The system operation is assessed at a higher level, by the CAMC (Task 1.3.3). During normal operating conditions, the CAMC aggregates the information of all connected EVs from the MGCCs. According to its policy (coordinated voltage support/losses reduction), it may request the rescheduling of EVs charging as a service from the RAU. If an abnormal situation is foreseen, the CAMC sends the appropriate signals to the MGCC. The MGCC decides the management strategy of the EVs under its control, therefore acting as an interface between the CAMC and the VC agents. This could include rescheduling instructions for each EV, to achieve coordinated voltage support, according to the CAMC policy. When the MGCC takes control over the EV management, it should inform the respective MGAU regarding its actions. In the case of an emergency situation, the MGCC agent performs the control by sending set-points to the VC agents in order to restore normal system operation Regional Aggregation Unit (RAU) Agent Day-ahead Operation: As stated in report the RAU is considered to be the core of the EV EVS/A. More than one RAU may be part of an EVA. With the day-ahead market behaviour and EV demand forecasts, the EVA will prepare sell/buy bids on the day-ahead market. Previous to the market negotiation the technical feasibility of the planned schedule within the distribution network will need to be validated by the DSO. The final negotiation in the market needs to be validated by the TSO. After DSO and TSO validation, the RAU disaggregates the day-ahead demand profile and distribute them to its MGAUs accordingly. Real time Operation: During real time operation the RAU agent receives at every predefined time interval (15 minutes), information from the MGAU agents with regards to the connected EV schedules. The MGAUs aggregated portfolio will be compared with the day-ahead predictions. If the charging schedules do not match with the forecasted values, the EVA may fine tune its contract positions by going to the intra-day market (power exchange market in Great Britain). This decision will depend on the mismatch and the forecasted imbalance cost. Page 34

35 If the forecasted and the actual demand are different, the RAU may decide to modify the MGAUs demand portfolios (intra-balance) in order to meet its contract. The RAU will request from the MGAU the amount of power that can be reduced or increased during the specific time period. After receiving the information from the MGAU agents, the RAU will modify and send to the MGAU agents the updated demand profiles in order to minimize balancing penalties. Prior to the MGAUs profile modification, the new schedules will be sent to the respective CAMC for validation. The functionalities of each agent are summarised in Table 2. Agent Vehicle Controller Agent (VC) Microgrid Aggregation Unit Agent (MGAU) Microgrid Central Controller Agent (MGCC) Regional Aggregation Unit Agent (RAU) Cluster of Vehicles Controller Agent (CVC) Description Control and monitoring of EV parameters; communicate these parameters to the MGAU. Receive set-points from the MGAU/ MGCC, depending on the operating mode (normal/emergency). Aggregate the EV requirements. Assign charging schedule to EVs according to their preferences and states, following schedules issued by the RAU. Prior to the set-point notification, the schedules are send to the RAU to validate through the DSO that abnormal conditions will not arise. If validated, sends the set-points to the EVs. During emergency mode sends set-points to EVs. Day-ahead Distributes next-day agreed schedules to MGAUs. Every 15 minutes Receives updated schedule from the MGAUs and aggregates demand portfolio. Compares aggregated demand portfolio with dayahead schedule. Fine tunes demand portfolio. Manages the EVs according to the services contracted with the RAU. Table 2 Types of agents Intra-balance The centralised approach to the system intra-balance is described in the previous section. However, a more decentralised approach can also be followed. Both approaches require the following procedure and the differences are explained in Table 3: At a specified time interval the RAU agent sends requests to MGAU agents for their demand portfolios. MGAU agents request the Vehicle Controller agents for their SOC. Page 35

36 According to VC replies, MGAU agents create a single profile and send it back to the RAU agent. The RAU agent aggregates all MGAU profiles and compares the aggregated portfolio with the day-ahead profile. Centralised If there is a significant discrepancy, the RAU agent requests MGAU agents for their power reduction/increase capabilities for the specific time step. The MGAU agents calculate their power reduction/increase capability based on the EV owner preferences and send it back to the RAU agent. The RAU agent receives the MGAUs capabilities and defines new MGAU schedules. The RAU agent communicates the changes to the CAMC for the validation of the new schedule. The CAMC agent replies either validating the new schedule or not. If validated by the CAMC, the RAU agent communicates the changes to the relevant MGAU agents. The MGAU agents adjust the EV set-points according to the changes and send them back to the VC agents. De-centralised If there is a significant discrepancy, the RAU agent communicates the amount of this difference for the specific time interval to the MGAU agents, and initiates the MGAUs negotiation period. The MGAU agents calculate their power reduction / increase capability based on the EV owner preferences. According to their capabilities they negotiate collaboratively to cover for the overall discrepancies. At the end of the negotiation period, the MGAU agents send the final portfolio to the RAU agent. The RAU agent aggregates the portfolios and communicates the changes to the CAMC for the validation of the new schedule. The CAMC agent replies either validating the new schedule or not. If validated by the CAMC, the RAU agent sends confirmations to the MGAU agents. The MGAU agents adjust the EV set-points according to the changes and inform the VC agents. Table 3 Comparison between centralised and de-centralised approach for intrabalance Page 36

37 4 APPLICATION OF MOBILE AGENTS FOR EV RESOURCES 4.1 Introduction The liberalization of the energy market gives rise to the development of new companies (ESCos, data measuring companies, EVS/A etc.) providing different types of services (RES forecast, load forecast, consumption profile etc.). Currently, most of these services are built using traditional design techniques called client (end-user) server (companies) in which a single powerful computer system (server) holds data to be shared over the network and less powerful computer systems (clients) access the server using the network [17]. In such applications the server holds the data and executes the application code in any kind of server-based language whereas the client is responsible for the graphical user interface. In the future the number of these services and the amount of data transmission will rapidly increase. Thus, what we know as distributed system applied in the MG concept should be expanded. In the past, the term distributed system was mainly used to describe a network of several computer systems with separated memory that are connected to each other by a dedicated network [17]. The computers used in such a distributed system are almost homogenous, which means that they have the same type of processor and the same type of operating system. The network is more or less static: Computers are only rarely switched off, network connections between hosts are always reliable and provide constant bandwidths and each computer has a fixed IP address. This type of network is still typical for most applications and thus it is also applied to the MG concept. However, such a typical network should be expanded in case of a distributed MG- EV concept due to the characteristics of EV (mobile resources being connected to different places and experience the same quality of services). Two major requirements should be met in such a distributed MG-EV concept: i) pervasive computing and ii) nomadic computing [17]. (i) Pervasive computing means that everything might become a node in a distributed system. In a fully distributed MG-EV concept, EV are supposed to have the intelligence to learn from their environment and take decision on their own for the cycle (charging/discharging) of the batteries. EV will have the ability to fulfil their own charging management policy, such as maximization of their profits due to bidirectional energy transaction between battery and electrical grid (V2G concept) or maximization of battery s life avoiding frequent and deep discharging of the batteries etc. Such a distributed intelligence presupposes that EV are equipped with an embedded system for the development of an agent based control concept. These computer systems are characterized by limited resources especially in regard to memory and processing power. These small computer systems should also be able to communicate with other energy market actors (aggregator, energy suppliers, home energy management system etc.) in order to exchange information and data. The communication efficiency of all these transactions, with respect to the bandwidth and latency, will be dependent on the communication method that will be employed. The characteristics of each method are not the concern of this section. Page 37

38 (ii) Nomadic computing means that users are moving from place to place, they are connecting to different charging points but they must still experience the same quality of services and functionalities. These new requirements for the distributed MG-EV concept can be served through mobile agent technology. Mobile agents are a special type of mobile code which is a technique in which code is transferred from the computer system that stores the code files to the computer system that will execute the code [17]. Mobile agents are analysed in more detail in the next section. 4.2 Mobile Agents Mobile agent is a piece of software that performs activities on user s behalf when given instructions and it is able to move from one computer to another autonomously and continue its execution locally on the destination computer [18]. In order to better understand what mobile agent is, it is convenient to define the characteristics of software agents and identify which ones of them differentiate mobile agents from other types of software agents. Software agents can be classified in terms of a space defined by three dimensions of intelligence, agency and mobility (Fig. 17) [19]. Agency Service Interactivity Application Interactivity Data interactivity Representation of user Asynchronicity Message Passing Remote procedure Remote execution Weak migration Strong migration Mobility Preferences Reasoning Intelligence Planning Learning Fig. 17 Space of Software Agents [19] The first dimension, intelligence, is rooted in artificial intelligence research and dates back to the fifties [19]. In this approach the agent was able to apply techniques of symbolic artificial intelligence in order to fulfil a given task or to recover when it was stuck. These intelligent agents can be classified according to their capabilities to Page 38

39 express preferences, beliefs and emotions and according to their ability to fulfil a task by reasoning, planning and learning techniques. The second dimension, agency, is the degree of autonomy and authority vested in the agent and can be measured at least quantitatively by the nature of the interaction between the agent and other entities of the system [19]. At a minimum an agent must run asynchronously. A more advanced agent can interact with data, applications, services or other agents. According to their capabilities, agents are called autonomous, collaborative, cooperative or negotiating agents. The third dimension of software agent research, mobility, has emerged in the nineties and is motivated by the rise and rapid growth of a networked computing environment and the need for techniques to exploit this huge resource [19]. The goal within this dimension of software agent research is remote action and mobility of data and computation. The five different levels of mobility, as presented in Fig. 17, classify agents into two categories: stationary and mobile agents. Weak and strong migrations are the characteristics that differentiate mobile from stationary agents. Mobility is an orthogonal property of agents- that means not all agents are mobile. An agent can just stay stationary somewhere and communicate with its surroundings by conventional means, such as various forms of remote procedure calling and messaging. Agents that cannot move are called stationary agents. Stationary agent executes only on the system where it begins execution. If it needs information that is not on that system or needs to interact with an agent on a different system, it typically uses a communication mechanism such as remote procedure calling (RPC b) [20]. In contrast, a mobile agent is not bound to the system where it begins execution. The mobile agent is free to travel among the hosts in the network. Created in one execution environment it can transport its state and code with it to another execution environment in the network, where it resumes execution. Mobile agent is not bound to the system where it begins execution. It has the unique ability to transport itself from one system in a network to another. The ability to travel allows a mobile agent to move to a system that contains an object with which the agent wants to interact and then to take advantage of being in the same host or network as the object [20]. In distributed systems, such as Microgrids and Microgrid-EV concept, communication can be supported by various ways. Message Passing is the first paradigm proposed, which lets the different actors within a Microgrid to communicate by explicitly sending and receiving messages [19]. Various concepts have been proposed for asynchronous and synchronous message passing. Especially the asynchronous type of message passing is very flexible and hence supports a great variety of communication patterns. However, in large fully distributed applications, where the amount of information and data to be exchanged is great enough, such an approach seems to be complex and programs are hard to analyse and debug. A level higher than message passing, communication can be supported by remote procedure call (RPC) [19]. To communicate, processes call remote procedures rather than explicitly sending or receiving messages. The mechanism that supports RPC is the client-server interaction. The client-actors request to server-actors, which Page 39

40 execute the requested procedure and then return the results. Both asynchronous and synchronous calls can be supported in this level as well. A prerequisite for an RPC to work correctly is that the called procedure is available on the respective remote node. This requirement, however, limits the usability of the RPC concept in large open distributed systems. However, sometimes it is desirable to ship a procedure to a remote node and execute there, e.g. a client might move an application-filter to a remote database to access and compress data locally [19]. This flexibility is an extension of RPC and it is provided by the concept of remote evaluation (remote execution) 1. While remote evaluation only allows for code mobility the concept of a mobile agent supports process mobility, i.e. software executions may migrate from node to node of a network. In this concept not only the code but also the state information of the agent can be transferred to the destination. The code is the object oriented context, the class code necessary for agent to execute. The state refers to attribute values of the agent that help it determine what to do when it resumes execution at its destination. An agent s state is subdivided into data state and execution state. The first includes the agent s global parameters and instance variables while the latter comprises the local variables and the active thread. There are two types of migration as shown in Fig. 18: the weak migration and the strong migration. Remote Procedure Call (RPC) Weak Mobility Mobile Computation Strong Mobility Mobile Code Mobile State Fig. 18 Different combinations of mobile capabilities [21] With strong migration, the mobile agent is able to capture the entire agent state (consisting of data and execution state), clone and transfer itself together with the code to the destination host, where it automatically continues its execution locally at the point they stopped before migration. In heterogeneous environments, the migration process must be done transparently requiring a global model of agent state and a transfer-syntax as well. Moreover, an agent system must provide functions to externalize and internalize agent state. The size of the agent state to be transferred is important since large amount of data can harm the operation of the 1 Stamos, J. and Gifford, D. K., Remote Evaluation. ACM Trans. Programming Languages and Systems 12(4): (1990) and Stamos, J. and Gifford, D. K., Implementing Remote Evaluation. IEEE Trans. Software Engineering 16(7): (1990) Page 40

41 network due to extreme delays. Thus, attention should be paid to the amount of transferring information which should be kept at the lowest possible levels. Such difficulties have led to the development of the so-called weak migration scheme. With the weak migration, the programmer is able to decide which variables are going to be included in the agent state and thus to control the amount of exchanged data. The disadvantage of this method is the fact that agent programs become more complex since the programmer should define in the code how agent state should be encoded and where to continue execution after migration. 4.3 Mobile Agent Benefits Although mobile agent technology sounds exciting, our interest in mobile agents should not be motivated by the technology but rather by the benefits agents provide for the creation of distributed systems. There are several good reasons for adopting mobile agent technology [19], [22]: Reduce network load and overcome communication latency At first glance, mobile agents seem to cause additional load to the network in terms of execution state and code transfer. However, in distributed application where the communication process is complicated, multiple interactions to accomplish a task are required and security issues are under consideration, mobile agent technology can reduce network latency. Instead of exchanging a great number of messages through the network in order to accomplish a task (message passing communication), mobile agents allow the programmer to package a conversation and dispatch it to the destination host. Moreover, when there is a sequence of service requests, each request should be issued by a separate remote procedure. With mobile technology, this sequence of service requests can be packed in an agent and sent to the destination host reducing the communication latency. Furthermore, mobile agents can reduce the flow of raw data in the network. When there is need of transferring a large volume of data from a database which is stored in a remote host, mobile agents offer the ability to process the data locally in the remote host and return only the result. The concept is: move the computations to the data rather than the data to the computations [22]. RPC based approach Application Service Mobile Agent based approach Application Service Fig. 19 Mobile Agent for network load reduction [22] Page 41

42 Dynamic protocols When data exchange between two hosts is needed, certain protocols should be implemented. There are standard protocols which should be shared between receiver and sender hosts for the initialization of the transfer. After that, each host has its own protocols that should be implemented to properly code outgoing data or interpret incoming data. In case a protocol is missing, it must be installed manually. Mobile agents permit the automatic installation of the appropriate protocols that enable a particular interaction. Asynchronous and autonomous execution In the asynchronous communication, the individual requests of a task are processed asynchronously, so the client performing this task must be available to receive and react on incoming replies. In case of mobile clients, keeping them always connected and alive is not efficient. This problem can be overcome by embedding the task into a mobile agent which is dispatched into a stationary server in the network and executes itself locally. This mobile agent is independent of the creating process and can operate asynchronously and autonomously. At a later time, when the mobile device is reconnected, it will collect the agent. There must be only one semantic of an agent and the network must guarantee that the agent will never be lost, even in case of communication and node failures. Distributed and Heterogeneous Computing Mobile agents can also serve as the basis for general-purpose distributed and heterogeneous computing. Because mobile agents are generally computer and transport-layer-independent and are dependent only on their execution environment, they provide optimal conditions for seamless system integration and the necessary infrastructure for communication between the tasks in a heterogeneous environment [22]. In distributed computing, mobile agents migrate to remote hosts in order to execute locally their schedule task. At any time, further agents can be assigned to the task due to independent compilation and initiation of agents. Applications for agent-based distributed computing are parallel algorithms with a reasonable low communication overhead compared to its computation requirements and particle or object based simulations [19]. 4.4 Requirements Mobility and autonomy are the fundamental characteristics of mobile agents. Without mobility they would not be mobile agents but static ones; without autonomy they would not be agents at all, but directly manipulated applications [23]. In order to meet the requirements of agent mobility (transmission of agent s code and state) there are high demands on programming languages and runtime environments for mobile agents. Some essential requirements are presented below [22], [24], [25]: Page 42

43 Mobility The language must provide a mean to identify the code of an agent and there must be a language primitive or library function to initiate transmission of the agent. The remote host should be able to recognise mobile code (mobile agents) and execute received agents that meet the local security requirements. The primitives for agent mobility can either be integrated into the agent language or provided by the operating system. Heterogeneity Mobile agent system must support heterogeneous environment, which means that any agent that is launched in a runtime environment should be able to execute in any other one. Performance The performance of mobile agent applications can be evaluated in terms of execution time and allocated resources. Mobile agents transfer their code and state during migration and thus they require a certain amount of overhead which depends on the size and execution speed of the agent. This overhead should be kept as small as possible. Security In order to prevent unauthorized access to remote hosts, i.e attacks from viruses and worms, mobile agent system must provide its own security model either by restricting the language or by executing the agents behind firewalls provided by the operating system. Stand-Alone Execution When mobile agents migrate from a host to another, they must transfer all the necessary code and their state in order to be able to execute on the remote host without further connection with the originating site, unless it is required by the application. Environment-Awareness Once the migration is completed, the agent should use only the services and resources on the remote host in order to accomplish a task. Thus, mobile agent should be able to interact with the appropriate services and resources. These interactions should be controlled by the agent language. In more advanced agent based applications where the distributed environment is continuously changing, the agent may be able to find out what services and resources are available on its current host and match them with the services and resources needed to fulfil its mission. Page 43

44 Independent Compilation Sometimes, in agent based applications several agents may need to cooperate in order to accomplish a task. In this case, the agent language should not require that all the agents must be compiled together. 4.5 Application of Mobile Agents for EV Resources The concept of mobile agents has surfaced concurrently in a board range of research areas, namely communication systems, distributed systems, operating systems, networks, computer languages and distributed artificial intelligence. In this section, a new concept of how mobile agent technology could be implemented for the connection of EV to the grid is going to be presented. The V2G concept of plug-in EV resembles much to the behaviour of electric batteries connected to the grid either as distributed generation or storage. The major difference is the fact that EV are not stationary resources. The network where the EV are connecting demands a nomadic computing, meaning that EV moving from place to place must be able to connect to different charging points and still experience the same quality of services and functionalities. Such a concept requires that each EV has the know-how of bi-directional power flow exchange with the grid, the intelligence to take decisions according to the environment (battery s state of charge, market prices, system status etc.), and the adequate computational resources in order to execute the desired tasks. In other words, the knowledge, the intelligence and the computation should be inside the car. This requires an embedded system that will allow different charging strategies and market participation. The embedded systems have generally limited computational resources. In order to meet the computational needs of the V2G concept, enhanced embedded systems are required, increasing the cost of the EV as well. This can be avoided if the computation is transferred outside the EV. This idea can be implemented by utilizing the mobile agent concept. Fig. 20 presents the proposed mobile agent concept for EV resources. According to this concept, there is an EVS/A which is responsible for the connection of the EV to the electrical grid [3], [4]. The EVS/A serves as an intermediary keeping the relevant information (i.e. EV and owner s details) about the end-user that enables EV s market participation and billing process [1], [14]. In this case the EVS/A is the representative of the EV in the energy market. The EVS/A may hold in addition information regarding services offered by other parties (e.g. load and wind forecasting). Mobile agent technology will enable the local process of great volumes of data instead of transferring them from a host to another, resulting in the reduction of network load. In the case that the employed business model dictates that the EVS/A which is responsible for the Charging Point (CP) differs from the EVS/A which is responsible for the HCP, a procedure similar to mobile phone roaming may be followed. However, whichever assumption is defined does not affect the proposed mobile agent concept, because the concept s requirements at this level are similar to yellow-page services (i.e. a database with customers and services details). Page 44

45 Aggregator Identification of the EV and the CP Charging Point (CP) Sending information (EV and CP id) Migration of the agent End of migration Information & Request Stationary Agent Changing CP Home CP Fig. 20 Application of mobile agent concept for EV resources At local level, there is a stationary agent which is part of the home energy management system. This agent keeps all the knowledge and the intelligence that enables the control of the charging/discharging process of the EV s batteries at local level. This agent is executed in a computational environment which provides the adequate resources to complete any task with no latency. The development of the control strategy is not the scope of this section. Once the EV leaves the house, the batteries will discharge depending on the travelled distance, traffic and the user driving profile. Thus, there would be a need for battery charging at a new charging point. In case the battery s SOC is more than enough to meet the driving needs of the EV user, without exceeding charging/discharging safety degradation limits, the batteries can support the grid by providing energy. This V2G operation requires adequate knowledge and intelligence which the stationary agent being part of the EV owner s home energy management system has. This knowledge and intelligence must somehow migrate from the home to the new charging point. Mobile agent technology enables such a migration. When the EV is connected to the new charging point, an identification message is sent to the EVS/A. This message contains the EV s identity and the charging point location (i.e. charging point IP-address). After receiving this information, the EVS/A sends the exact location of the new charging point to the stationary agent, where the knowledge and the intelligence should be transferred. Once the stationary agent receives the destination, it clones itself and the clone migrates to the requested destination. After the process has finished, the clone agent returns to its base and updates the old data. Note that this migration would require some necessary infrastructure (i.e. embedded computer and agent platform) to be installed in the smart meter which will be housed in each charging point. Page 45

46 5 EV CHARGING MODES AND ANCILLARY SERVICES PROVISION 5.1 Introduction EV batteries are loads with unique characteristics, medium to high power consumption over a given period of time and with some degree of predictability. Such features can either be disregarded and EV are faced as regular loads, or they can be exploited and then EV charging strategies might be defined, to take advantage of their unique characteristics. Section 5.2 describes several possible charging methods that might be implemented in order to use EV to enhance the networks operating conditions avoiding the need to reinforce the network. Different ancillary services can be defined when controllability is considered for EV, namely the provision of both voltage and frequency control. Section 5.3 exposes different strategies for these ancillary services provision. In both sections the management and control architecture described in section 2 must be present in order to enable the fluxes of information needed to trigger the defined EV control functionalities. 5.2 Charging Modes Depending on the type of application, EV controllability may vary and, therefore, several control schemes may be adopted. There are different solutions, presented extensively in the MERGE Report for WP1.1 in section 7.1.2, which may arise according to EV owners needs, namely: Charging stations dedicated to fleets of EV: This solution presents high controllability potential if EV can be charged in slow charging mode, as fleets of vehicles (such as buses or trucks) typically have very well-known mobility patterns. When fast charging is required, charging management cannot be performed. Fast charging stations: As dedicated fast charging stations, this solution is not suitable for control actions due to the need of having a full charge in the minimal time span. Battery swapping stations: For this solution, controlled charging procedures may be defined depending on the existing battery stock on the station. Both slow and fast charging methods can be used depending on the specific demand patterns and on the available stock per station. Domestic or public individual charging points for slow charging: This solution is the most suited for controlled charging as EV parked in these places will remain there for longer periods (overnight stays if it is a residential area or during working period while in industrial/commercial areas). There are two main types of charging that require different charging rates: Slow charging. Fast charging. Page 46

47 Concerning slow charging and depending on the battery SOC and capacity, a full charge might take 1 h to 8 h [1]. Within this charging alternative, there are four options, depicted in Fig. 21, two passive or uncontrolled and two active or controlled. Each of these will be explained in section 0. When in slow charging mode, given that EV are connected to the grid during a considerable amount of time, they might provide several system services, like reserves delivery, peak power or load shifting [2], [4]. Regarding fast charging, a full charge might take 10 min to 1 h. Due to the urgent needs from the user of this type of service no controllability is envisaged and so this will not be developed on this report. Dumb Uncontrolled Fixed tariff-based Smart Controlled V2G Fig. 21 Slow Charging Modes of Operation In section of the MERGE Report for WP1.1, the charging levels are classified into level 1, 2, and 3. The charging types referred to as slow charging refers to level 1 and the fast charging refers to level 3. However, level 2 can also be considered as a fast charging regarding the above description. For the purpose of this deliverable, slow charging corresponds to level 1 and fast charging includes both level 2 and Slow Charging Dumb Charging This is a no control mode where EV can be freely operated having no restrictions or incentives to modulate their charging. Therefore, EV are regarded as normal loads, like any other appliance. In this mode, commonly referred to as dumb charging, it is then assumed that EV owners are completely free to connect and charge their vehicles whenever they want. The charging starts automatically when EV plug-in and lasts until its battery is fully charged or charge is interrupted by the EV owner. In addition, electricity price is assumed to be constant along the day, what means that no economic incentives are provided to EV owners in order to encourage them to put their vehicles charging during the valley hour when the grid operating conditions are more favourable to an increment in the energy consumption. Page 47

48 For scenarios of large EV deployment, this approach will provoke technical problems in the generation system and on the grid (potential large voltage drops and branch overloads). The only way to tackle the foreseen problems provoked by EV is then to reinforce the existing generation system and grid infrastructures and plan new networks in such way that they can fully handle EV grid integration. Yet this is a somewhat expensive solution that will require high investments in network infrastructures Fixed-Tariff Charging As in the previous approach, the dual tariff policy assumes that EV owners are completely free to charge their vehicles whenever they want. However, as electricity price is assumed not to be constant along the day, existing some periods where its cost is lower. This method is based on that existing already in many countries where during valley hours, normally during the night, electricity price is lower. However, as this is not an active management strategy, the success of this method depends on the EV owner willingness to take advantage of the policy, thus only part of the EV load eventually would shift towards valley hours. This approach could have been included in the controlled EV charging/discharging approaches but, as this type of control is not directly imposed to EV, it is considered an uncontrolled charging approach. It should be taken into account that the economic signals provided to EV owners with the fixed-tariff policy might have a perverse effect in scenarios characterized by a high integration level of EV. It might happen that a big number of EV connect simultaneously in the beginning of the cheaper electricity periods, making the grid reach its technical limits Smart Charging The smart charging strategy envisions an active management system, where there are two hierarchical control structures, one headed by an EVS/A and other by the DSO. When operating the grid in normal conditions, EV will be managed and controlled exclusively by the EVS/A, whose main functionality will be grouping EV, according to their owners willingness, to exploit business opportunities in the electricity markets. The EVS/A will monitor all the EV connected to the grid and its state, providing power or requesting from them the services that it needs to cope with what was previously defined in the market negotiations. This is accomplished by sending setpoints to vehicles controllers related with rates of charge or requests for provision of ancillary services. To accomplish successfully such a complex task, it is required that every fixed period (likely to be defined around 15 minutes), the State of Charge (SOC) of each EV battery is communicated to the EVS/A, to assure that, at the end of the charging period, batteries will be charged according to EV owners requests. However, due to high uncertainties related to when and where EV owners will charge their vehicles, the existence of a grid monitoring structure will be required, controlled by the DSO, with the capability of acting over EV charging in abnormal operating conditions, i.e. when the grid is being operated near its technical limits, or in emergency operating modes, e.g. islanded operation. In these situations, EV Page 48

49 might receive simultaneously two different set-points, one from the EVS/A and other from the monitoring and management structure headed by the DSO. To avoid violation of grid operational restrictions, the DSO signals will override the EVS/A ones. This type of EV charging management provides the most efficient usage of the resources available at each moment, enabling congestion prevention and voltage control, while avoiding the need to invest largely in network reinforcements V2G This approach is an extension of the previous one where, besides the charging, the EVS/A controls also the power that EV might inject into the grid. In the V2G mode of operation, both EV load controllability and storage capability are exploited. From the grid perspective, this is the most interesting way of using EV capabilities given that besides helping managing branches congestion levels and voltage related problems in some problematic spots of the grid, EV have also the capability of providing peak power in order to make the energy demand more uniform along the day and to perform primary frequency control. Nevertheless, there are also some drawbacks related with the batteries degradation. Batteries have a finite number of charge/discharge cycles and its usage in a V2G mode might represent an aggressive operation regime due to frequent shifts from injecting to absorbing modes. Thus the economic incentive to be provided to EV owners must be even higher than in the smart charging approach, so that they cover the battery damages owed to its extensive use. 5.3 Voltage and Frequency Support Modes When EV are regarded as active elements within the electricity grids, several usages for EV controllability and storage potential can be envisaged. These services may vary according to the specificities of the different types of networks, mainly between: Interconnected systems Isolated systems (both the power systems of small islands and occasional islanding of parts of the interconnected grids) Overall, there are two main areas of intervention by EV resources: voltage and frequency control. Each of those can have two types of triggering methods. The first natural possibility would be the reaction of controllers installed at the EV power electronic inverter level, set as additional local control loops, whereas the second option is based on a coordinated control. The latter relies deeply in a proper communication infrastructure with an adequate management structure. In this sense, the extension of MG and MMG concepts provide the required framework for the creation of hierarchical control architecture. Fig. 22 is a schematic representation of the pictured operation modes. As it will be explained in the next subsections, primary frequency control by EV is suited for weak systems under the previously defined category of isolated systems, as opposed to secondary frequency control that is appropriated for larger systems, for instance, Multi-Microgrids isolated from the upstream network or interconnected networks, such as those present on the UCTE control areas. Being voltage control a Page 49

50 problem related to distribution grids it is applicable in both interconnected and isolated systems. Local voltage control has a faster response than coordinated control. Nonetheless, local control is not optimized and so coordinated control actions can correct overreactions from the decentralized control. Local Control Voltage Control Coordinated Control Primary Control Frequency Control Secondary Control Fig. 22 Voltage and Frequency Control Strategies Voltage Control Battery charging of EV will increase the power demand in distribution networks. It is anticipated that a high EV uptake will cause significant voltage drops on distribution feeders [26], [27]. Two types of voltage control are discussed: (i) local voltage control and (ii) coordinated voltage control Local Control Local voltage control is easiest method to implement when voltage control is required, yet the quickest to respond. Its implementation is based on a droop control action that reacts to voltage deviations and redefines the EV active power setpoints. With this method, however, an optimal solution may not be achieved and eventually EV may be forced to operate below their admissible power rating for each grid condition. Therefore, local voltage control should be complemented with a coordinated control action that after a large voltage disturbance may correct the actions of the local actuators. Depending on the type of grid, different settings may be defined for the local controller. As EV participating in voltage control are individually connected to the LV grids, or in clusters of EV to the MV, voltage control actions are processed differently from the conventional techniques. In these networks, reactive power control is not sufficient to maintain efficient system operation, especially in LV networks where the X/R index is low. If voltage sags occur, it has been shown that they cannot be corrected efficiently by injecting reactive power. In the present case it is more efficient to reduce the load or inject active power. Therefore, the local control action is based on Page 50

51 a droop that controls active power according to voltage deviations that may result from normal or abnormal operation of the grid. Fig. 23 shows a possible implementation of a droop control for voltage. A dead band may exist to prevent EV from reacting to small voltage deviations. In fact, when dealing with interconnected grids, this dead zone is expected to be between 0.9 and 1.1 p.u., whereas in weaker systems it will be from 0.95 to 1.05 p.u.. The zero crossing voltage, V 0, is the point at which EV start injecting power into the grid in order to increase voltage, when working in V2G mode. This operation zone can be truncated, when a controllable load mode is being used, such as smart charging, and when V 0 is reached EV stop consuming active power. P P max V min V 0 EV consumption V P min Dead Band P Injection P Consumption Fig. 23 Voltage control droop for EV Similarly to what is shown further in section , local voltage control must be remunerated using the conceptual framework presented in (subtask report). A time delay may also be included in the control chain to prevent the control system to command changes in the charging procedure when transient voltage droops take place due to grid disturbances Coordinated Control The hierarchical control system defined in (subtask report) must be considered for voltage control in distribution systems comprising large EV, DG and microgeneration penetration, using communication and control possibilities that will become available in future distribution networks. High penetration of controllable EV can be exploited in order to help the global management of the distribution system. The voltage problems that may arise from their presence, if uncontrolled, and those that come from the presence of large amounts of DG and microgeneration lead to the development of an effective voltage control scheme based on active and reactive power control since the decoupling between active power and voltage is not valid in LV networks. In the case of LV grids with microgeneration, the possibility of controlling active power injected by microgeneration units and/or the active power consumed by EV is envisaged, since Page 51

52 this is the most effective way of controlling voltage at the LV level under these conditions, as explained in section This coordinated voltage control procedure is proposed by enhancing the one described in [26] that included optimizing operating conditions by using DG, installed at the MV level, Microgrid and OLTC transformer control capabilities. In Multi- Microgrid systems, it is necessary to address the problem of voltage control at both the MV and the LV levels. To ensure a coordinated operation, a global voltage control algorithm should be run at the MV level and the solution obtained tested at the LV Microgrid level in order to evaluate its feasibility. The enhanced voltage control procedure assumes that EV are also included as controllable loads or even as storage elements that can change their active power consumption/injection level according to the system needs. Once again, EV owners willing to participate should be remunerated for the service they are providing. This coordinated voltage control will be a procedure followed by the DSO at the CAMC level. Therefore, data regarding each EV should be gathered by the CAMC in order for the voltage control algorithm to consider the preferences of each EV owner. The EV data required for coordinated voltage control is presented in Table 4, comprising charging point related data and the EV owner preferences data. Charging Point Related Data Charging point Identification Number (ID) Customer Preferences Data Charging mode Network location Maximum charging rate Actual SOC of EV battery Connection duration Desired SOC at the end of the connection duration Table 4 EV related data required for coordinated voltage control Each MGCC will regularly collect the data presented in Table 4 related to each EV managed. The data from all MGCCs will then be gathered at the CAMC level, where the coordinated voltage control algorithm is implemented (subtask report). Based on this algorithm the EVs charging will be rescheduled taking into consideration the EV owners preferences and in accordance with the technical constraints in the distribution network [29]. As in normal operation is the EVS/A that controls EV charging, via the RAU and the MGAU, this methodology implies that both MGCC and MGAU collect regularly duplicated data from EV. However, it should be referred that other methodologies might be implemented, namely in what concerns the duplicated EV information gathered by the MGCC and the MGAU. Instead, the relevant data from EV might be collected only by the MGAU which will regularly send the data presented in Table 4 to the MGCC. The rest of the process remains unchanged. Page 52

53 5.3.2 Frequency Control Primary Control As mentioned in the introduction of section 5.3, the participation of EV in primary frequency control is useful in situations where the electricity grids are weak, i.e. grids where the deviations between generation and load are felt at the level of EV: Electricity grids of small islands Unintentional or scheduled islanding of Microgrids Unintentional or scheduled islanding of Multi-Microgrids In order to provide this service, the framework described in subtask 1.3.3, which extended the concepts of Microgrids and Multi-Microgrids must be considered. First, EV owners will communicate their willingness to participate in primary reserve delivery to the EVS/A via the MGAU. Then, once this communication is established, the EV will be flagged as primary reserve provider and the control will be locally activated. When leaving the service provision, the EV again sends a signal to the EVS/A and, if within a new regulatory framework where this service can be paid, the EV will get remunerated according to the period of time when the service was provided. Regarding the control for EV participating in primary frequency control, a proper electronic interface control should be adopted, different from a simple diode bridge usually adopted for these purposes. Being the system frequency an instantaneous indication of the power balance in the island network, it must therefore be used to adapt the active power charging/discharging of the EV batteries. A frequency control droop loop, [7], can then be adopted to adjust the active power set-point of an EV inverter interface (Fig. 24), which is an integrant part of the VC. In this way, a smart EV grid interface, capable of responding locally to frequency changes, is adopted, instead of a dumb battery charging solution. Fig. 24 Control loop for EV active power set-point To this conventional control method, a dead band, where EV do not respond to frequency deviations, should be added to guarantee longevity of the batteries and thus a beneficial synergy between parties, the grid operator/evs/a and the EV owners. This dead band, as well as the slopes of the droops, should be defined according to the composition of the system, as well as the EV owners willingness to help with system frequency regulation. After several tests for these case studies, a 0.1 Hz dead zone was used and a MW/Hz droop was defined. Page 53

54 As EV batteries, under a V2G concept, can either absorb or inject active power, a saturation block with upper and lower limits must be added. A block providing the steady-state set-point of active power must also be included, working as an offset to the droop. This block represents EV normal consumption status. Fig. 25 shows schematically the droop configuration that can be implemented for the EV grid interface control strategy. For frequency deviations larger than the defined dead band, the EV battery will respond according to one of the given slopes. If frequency suffers a negative deviation then the battery charging will, first, reduce its power consumption and, if frequency decreases further, it will inject power into the grid. On the contrary, if there is a positive deviation then the battery will increase the power absorbed from the grid. P P max f neg f 0 EV consumption f P min Dead Band P Injection P Consumption Fig. 25 Droop control for VC Secondary Control The management of EV charging for secondary frequency control purposes can also be envisaged, as mentioned before, in large interconnected systems or isolated systems such as Microgrids or Multi-Microgrids. In secondary frequency control, the Automatic Generation Control (AGC) operation is the centrepiece in the control hierarchy. In a scenario characterized by large scale EV deployment, the TSO, who is responsible for the AGC, will acquire in the electricity markets the secondary reserves that it needs from GENCO and/or EVS/A. If a sudden loss of generation or load increase takes place in a control area, the AGC exploits the available secondary reserves, set up by the market, by sending set-points to the participants in the secondary frequency regulation service. If EV EVS/A are participating in this service, the AGC will send set points to adjust loads from these EVS/A that afterwards will send set-points to the EV willing to provide this service. The set-points EV will receive from the EVS/A will lead to a load charging adaptation for the period of time the AGC requires this service. In order to provide secondary reserves, EV must be an active element within the power system. Typically, reserves market participants would be the transmission company, providing buying bids, and generation companies, selling bids. If EV Page 54

55 would enter this market individually their visibility would be small and due to their stochastic behaviour rather unreliable. Nonetheless, if an aggregating entity exists, with the purpose of grouping EV to enter in the market negotiations, then reserve quantities would be more significant and the confidence on its availability much more accurate. In this sense, the conceptual framework that extends the concepts of Microgrids and Multi-Microgrids presented in (subtask report) should be considered. To perform AGC operation with EV, some modifications, presented in Fig. 26 [30], need to be introduced in conventional AGC systems in order to make the regulation of EV power consumption/output possible in response to deviations of system frequency, f i, in relation to its reference, f REF, and of the tie-lines active power flow, Pif i, in relation to the interchanges scheduling, Pif REF. As in the conventional AGC, B is the frequency bias that measures the importance of correcting the frequency error, when compared with the correction of the interchange power error; ki is the gain of the integral controller; Pe ini m is the current dispatch for machine m, fp m its participation factor and Pref m its new active power set-point value. Pa ini k is the current load of EV EVS/A k (entity whose importance will be further developed in this section) and fp Ak and Pref ak the EVS/A k participation factor and new active power set-point. These control functionalities to be provided by EV are intended to keep the scheduled system frequency and established interchange with other areas within predefined limits. ini Pe 1 ini Pe m ini Pa 1 m ini Pe i Pa i= 1 i= 1 k ini i ini Pa k Fig. 26 AGC operation in the presence of EV EVS/A Page 55

56 6 LEARNING FROM EXPERIENCE IN COMMUNICATION PROTOCOLS IN GREEK MICROGRIDS 6.1 Introduction The participation of ICCS/NTUA in EUDEEP 2 and More Microgrids 3 projects has offered field experience of the communication protocols used among the participants of multi-agent-based Microgrids. Following, the protocols used, the topology of the systems realized and the experience gained will be briefly presented. 6.2 Communication Protocols Used In the More Microgrids project due to the special geographical features of the site of the Microgrid later described, IEEE (Wi-Fi) communication protocol has been used. In the EUDEEP project due to the fact that the Microgrid realized was a Virtual Power Network situated in different sites of great distance among them. The sites were interconnected using two different approaches. In the first a Local Area Network based on Ethernet over Unshielded Twisted Pair was used and in the second the Internet access was chosen as the connecting technology. The aforementioned solutions will be briefly described in the next subsections IEEE Communication Protocol IEEE defines one medium access control (MAC) and several physical layer (PHY) specifications for wireless connectivity for fixed, portable, and moving stations within a WLAN. It also offers regulatory bodies, a mean of standardizing access to one or more frequency bands for the purpose of local area communication [31]. A Wireless Local Area Network (WLAN) consisting of one or more Access Points (APs) and zero or more portals in addition to the Distribution System (DS) realizes a communication among the aforementioned participants through the wireless medium (WM) WLAN Components Station (STA) A station refers to a general device that is able to connect to a WLAN. Basic Service Set (BSS) The Basic Service Set is the simplest type of a WLAN which can be composed of as little as only two communicating STA [31]. 2 EUDEEP : 3 More Microgrids : Page 56

57 Distribution System (DS) A system used to interconnect a set of basic service sets (BSS): consist of successfully synchronized STA and integrated LANs to create an extensive service set (ESS), is defined as a DS [31]. Access Point (AP) AP is any entity that has STA functionality and provides access to the distribution services via the WM [31]. Portal Any logical point where a service that enables delivery of MAC service data units (MSDU) between the DS and a non-ieee local area network (LAN) exists is called portal. A wireless Ethernet bridge usually serves the role of the portal in a WLAN [31] WLAN Modes of Operation Ad-Hoc or Peer-to-Peer Mode Connection among computers and workstations connected with a wireless network interface card through the WM in complete absence of any AP realizes the ad-hoc or peer-to-peer mode of a WLAN. The BSS resulting from the above mode is addressed as an Independent BSS. Fig. 27 represents an image of the simplest adhoc mode-based WLAN [32]. Fig. 27 Ad-hoc WLAN consisting of two workstations Infrastructure Mode In the infrastructure mode all computers and workstations communicate with their overlaying AP which also offers access to other both wired and wireless LANs. When infrastructure mode is used either a BSS or an ESS can be realized with Page 57

58 either a single or multiple APs respectively. An example of an infrastructure modebased WLAN can be seen in Fig. 28. Fig. 28 Infrastructure WLAN consisting of two APs connected through wired LAN [32] WLAN Router For a small ad-hoc WLAN a router serves a number of purposes, the most important of which is the assignment of specific internet protocol (IP) address to each participating workstation through the Dynamic Host Configuration Protocol (DHCP) server. DHCP simplifies network administration because the software keeps a log of IP addresses and in doing so, allows an administrator to add computers to a network without conflicts. When connected to the Internet, the WLAN router may also serve as the AP and the Portal [33] Internet Protocol The Internet Protocol (IP) is the primary protocol in the Internet Layer of the Internet Protocol Suite and serves the delivery of datagrams which are which distinguished protocol packets from a source host to a destination host. The source and destination hosts are characterized only by their unique MAC addresses. The IP defines algorithms and forms for host addressing and datagram encapsulation [34] IP Routing and Addressing When the destination of a datagram is directly connected to a host or a shared network then it is sent directly to the destination. Otherwise the host sends the Page 58

59 datagram to a default router, and lets the router deliver the datagram to its destination as shown in Fig. 29. This simple scheme handles most host configurations. Addressing refers to the methods through which hosts are assigned IP addresses and how sub-networks of IP host addresses are divided and grouped together [34]. Fig. 29 Internet Protocol Suite in operation between two hosts connected via two routers and the corresponding layers used at each hop Ethernet Protocol Ethernet is a set of technologies covered by the IEEE standard and supporting the development and structure of LANs. The three most common data rates used over Ethernet are the 10base-T Ethernet for a transfer rate of 10 Mbps, the Fast Ethernet of 100 Mbps transfer rate and the Gigabit Ethernet of 1000 Mbps data rate [35] LAN Components Ethernet-based LANs consist of network nodes and interconnecting media. The network nodes are either of terminal or communicating nature as following explained. Page 59

60 Data Terminal Equipment (DTE) Devices that are either the source or the destination of data frames are called DTEs and are typically devices such as PCs, workstations, file servers, or print servers that, as a group, are all often referred to as end stations. Data Communication Equipment (DCE) Intermediate network devices that receive and forward frames across the network are addressed as DCEs and may be either standalone devices such as repeaters, network switches, and routers, or communications interface units such as interface cards and modems. As interconnecting media for Ethernet-based networks copper and optical fibber cables are used. In the framework of this report only the Unshielded Twisted Pair of the class of the copper cables will be later presented in the subsection of Equipment [35]. Ethernet Network Topologies Although LANs can take numerous different configurations there are three basic interconnection structures serving as building blocks of any other more complex LAN. Point-to-Point In the point-to-point interconnection only two network units are involved, and the connection may be DTE-to-DTE, DTE-to-DCE, or DCE-to-DCE. The cable in pointto-point interconnections is known as a network link. Coaxial Bus In the coaxial bus topology numerous segments are connected among them including any number of workstations. Individual segments could be interconnected with repeaters, as long as multiple paths do not exist between any two stations on the network. Star In the star topology the central network unit is either a multiport repeater (usually addressed as hub) or a network switch. All connections in a star network are pointto-point links implemented with either copper or optical fibber cable Equipment Repeaters and Hubs For signal degradation and timing reasons, Ethernet segments in coaxial topology have a maximum size which depends on the medium used. An Ethernet repeater Page 60

61 takes the signal from one Ethernet cable and repeats it onto another cable, thus allowing additional length to the segment at hand. If a collision is detected, the repeater transmits a jam signal onto all ports. The primary advantage of cabling in a star topology is that only faults at the star point will result in a badly partitioned network, and, hence, network vendors began building repeaters having multiple ports, thus reducing the number of repeaters required at the star point. The aforementioned devices became known as "Ethernet hubs" [35]. Bridges Bridging was developed in order to communicate at the data link layer while isolating the physical layer. With bridging, only well-formed Ethernet packets are forwarded between segments, thus isolating the collisions domains. Bridges detect devices through their MAC addresses, since the target address in not know beforehand which triggers a flooding and examination mechanism in order to allow the bridge to build a matching table. When the bridge is unable to match the MAC with the destination address packet cannot be forwarded [35]. Unshielded Twisted Pair Cable Most common interconnecting media in the Ethernet are cables that contain insulated copper wires twisted together in pairs for the physical layer connection. The most widely used standards for the twisted pair cables are 10BASE-T, 100BASE-TX, and 1000BASE-T, running at 10 Mbps, 100 Mbps and 1000 Mbps transfer rates respectively. Eight position modular connectors are used, also called RJ45. The cables used are four-pair twisted pair cable and according to the standards, they all operate over distances of up to 100 meters. 6.3 Test Site Topologies and Communication Schemes Gaidouromantra (Kythnos Island) Test Site For the More Microgrids project the Gaidouromantra rural installation as this can be seen in Fig. 30 has been used. In order to connect the agent-based load controllers installed on each of the houses participating in the Microgrid, a WLAN over IEEE was set up as this can be seen in Fig. 31. Page 61

62 Fig. 30 Gaidouromantra rural installation Fig. 31 Installation communication scheme An image of the load controllers is given in Fig. 32. The WLAN router (inside the system house) and its antenna (outside the system house) setting up the WLAN of the test site can be seen. The DHCP server of the router was used to assign IP addresses to the agents and some internet access for data collection through 3G network was also applied, hence, giving to the router the role of a portal. Page 62

63 Fig. 32 Agent-based load controllers installed NTUA (Attiki), CRES (Attiki) and Meltemi (Attiki) Test Sites The analogical laboratory of power systems in the National Technical University of Athens (NTUA), the photovoltaics laboratory of the Centre for Renewable Energy Sources (CRES) and a shop in Meltemi camp (Rafina city area) consisted the test site for a Microgrid realized in the framework of the EUDEEP project. The distances among the three locations are of some kilometres and therefore the implemented Microgrid concept was that of a Virtual Power Plant. The three locations were connected over the internet while the load and production controllers in each location were connected through a LAN set-up on Ethernet over UTP. The communication diagram is shown in Fig. 33. Fig. 33 Agent-based Microgrid as a virtual power network for the EUDEEP project Page 63