wp3 - distributed integration technology development - Edison

EDISON Deliverable D3.1

WP3 – Distributed Integration Technology Development

ELECTRIC VEHICLES IN A DISTRIBUTED AND INTEGRATED MARKET USING SUSTAINABLE ENERGY AND OPEN NETWORKS

WP3 - DISTRIBUTED INTEGRATION TECHNOLOGY DEVELOPMENT Classification: Type: Identifier: Version:

Public Deliverable D3.1 1.07

Editors:

Dieter Gantenbein, Bernhard Jansen, Doug Dykeman (IBM), Peter Bach Andersen, Einar Bragi Hauksson, Francesco Marra, Anders Bro Pedersen (DTU), Claus Amtrup Andersen, Jacob Dall (Eurisco)

Date:

April 30, 2011

© Copyright EDISON Consortium. 2009-2011. All Rights Reserved

Page 1 of 59



EXECUTIVE SUMMARY EDISON: The purpose of the EDISON project is to use aggregators of electrical vehicles (EV) including plug-in hybrid electric vehicles to provide the required balancing power for increasing the usage of wind power in the Danish electricity grid. EVs integrated into the electricity grid are beneficial to the grid by charging and providing feedback in a controlled way. To motivate EV owners to participate in providing these benefits, the integration system must provide methods for time-coupled metering and billing, which allow the owners to benefit from electricity rates that vary throughout the day. Details are found in companion report [EDISON Report D 2.3]. WP3: The purpose of EDISON Work Package 3 (WP3) is the development of a technical solution for intelligent system integration of distributed EVs. These may be plugged into the electricity grid at private homes, or at charging stations in company or public parking lots. Challenge: The main challenge is development of a suitable aggregation technology for low-cost, efficient, plugand-play integration of small-scale distributed energy resources (EVs) into the power system. The technical solution is expected to benefit from the virtual power plant (VPP) technology that is currently being developed for microCHPs, as well as from ongoing demand-response (DR) activities that aim at standardizing interactions to shape power production and consumption. The key issue is how to maintain security of supply in an electricity grid that incorporates a high percentage of green, but fluctuating wind energy and that also has a significant number of mobile EVs, which represent both a challenge and significant storage/regulation potential. The objective of the EDISON system is to provide benefit to both the grid and the users of the grid. Both central and distributed control with grid DSO/TSO and market integration methods, which are also being studied as part of EcoGrid, will be investigated. For EV communication the objective is to define a solution that gives the user a choice of aggregator and degree of grid-support services in order to analyze and enable a range of vehicle-to-grid optimization plans. Objectives: The overall focus is on designing and prototyping a secure server solution, to support the functioning of a wide-area intelligent system spanning geographical distance and various classes of intelligent devices, and potentially generating large amounts of real-time Type="FLOAT32" Ref="EVSE1/MMXU1.TotW.mag.f">0.5 Since REST services put no restrictions on the format used for transporting the data, it is completely at the developer’s discretion to use whatever he/she deems suitable. If a file transfer is needed, which the IEC 61850 standard permits e.g. for transferring configuration files or performing firmware upgrades, binary data could be the preferred option. In the case of the EDISON REST implementation, the basic format chosen is XML because it support relaying of hierarchical data, which means that any portion of the data model could be transferred in a single request. This has some added benefits when clients are discovering devices on the server because it allows them to retrieve the complete setup in a single request, without prior knowledge of the system. The use of IEC 61850 and REST is described by Anders Bro Pedersen et al. in [8].


Page 30 of 59



5.2.2 THE SESSION INITIALIZATION PROTOCOL REST has inherited many of the benefits from the HTTP protocol, but unfortunately also suffers from one of its main drawbacks when used in a de-centralized domain, which is the case with charging spots: it is client/server based. Because many charging spots will be attached to either private internet connections, mobile uplinks or similar temporary Internet connections, one cannot expect them to be reachable at a fixed network address as illustrated in Figure 16. One solution, adopted for the EDISON project, is to use the Session Initiation Protocol (SIP), which was designed for use in IP-based cellular systems to solve such issues. The use of SIP has been explored by Bernhard Jansen et. al in [5].

Figure 16 – Session initiation issues in distributed systems SIP, which dates as far back as 1996, is an open and flexible protocol whose primary purpose is to allow clients to locate and reach each other over the Internet. When a SIP-enabled user agent starts, it contacts a SIP Registrar to register its location. When another user agent on the network needs to reach a particular user agent, it does not need to know the location of the other party in advance. Instead, it simply sends an INVITE message to the SIP Proxy of its SIP Domain. If the inviting user agent and the invitee are in the same SIP domain, the SIP Proxy contacts the location service connected to the SIP Registrar with the name in the INVITE message to look up the contact’s details and then contacts the invited user agent by forwarding the INVITE message. Using the SIP Proxies, the session is negotiated and set up between the user agents who, as a result, are provided with the information needed to create a point-to-point connection. Figures 17-19 illustrate the message sequencing for initializing, re-initializing and closing a SIP session.


Page 31 of 59



Figure 17 - SIP INVITE sequence diagram to set up a TLS/IEC61850 session

Figure 18 - SIP re-INVITE sequence diagram to re-establish TLS/IEC61850 session

Figure 19 - Sequence diagram to close a TLS/IEC61850 charging session


Page 32 of 59



Once the session has been initiated and the direct connection established, any type of traffic can be tunneled through. Because SIP builds on many of the same technologies as the HTTP protocol, it is also capable of using an identical security mechanism such as Transport Layer Security (TLS) for encrypting the traffic. Because SIP separates signaling and media transport, the media sessions are created and closed between requests. Most of the resources otherwise associated with keeping multiple connections open can therefore be freed. The SIP Dialog, however, is kept open throughout the entire charging session and allows a quick re-establishment of a media session. As SIP Dialog is connectionless, this is very resource effective. This helps to greatly improve the scalability, and effectiveness, allowing the EVPP to aggregate even more vehicles and keep communication costs low. SIP allows the user agents in the network to be directly connected, but it does not handle barriers such as firewalls and the Network Address Translation (NAT) often found in routers. To overcome these issues, the SIP protocol can be extended with additional technologies, such as the Session Traversal Utilities for NAT (STUN) and the Traversal Using Relay NAT (TURN). Throughout the EDISON project great effort has been put on using standards for communication, such as SIP, TCP/IP, TLS and IEC 61850. In this regard the SIP is well suited to provide control and data communication between EVSE and the EVPP. As mentioned, the use of the RESTful approach helps to facilitate a much more versatile interface to the IEC 61850 server, but like all client-server communication, has some drawbacks, one of which is the ever present issue with firewalls. By combining IEC 61850 and REST with the use of the SIP protocol and NAT traversing techniques such as STUN or TURN, these issues can to a large extent be overcome. In this way IEC 61850 charging spots can be enabled independent of their location or connectivity.


Page 33 of 59


5.3


INTERFACE CONNECTING EV USER TO FLEET OPERATOR (FLEET OPERATOR TO EV USER)

5.3.1 EV USER REQUIREMENTS For intelligent EV charging to be successful, the system must be designed to fulfill the requirements of the EV user. These requirements range from a general target state-of-charge for the EV, to specific requirements such as having the EV at a certain state-of-charge at a specified time. The latter can be important for the user if, for example, he wants to leave exceptionally early the next day or go on a long trip. The EV User has the freedom of choice to select a particular charging strategy. Currently four basic charging strategies are envisioned: 

Smart Charging – Charge according to the load on the grid and availability of green energies. This strategy is most beneficial to the power system.



Immediate Smart Charging – Charge up to certain minimal threshold as fast as possible. After passing the threshold continue with smart charging. There is no benefit for the grid in the first charging phase but beneficial to the power system in the second phase.



Immediate Charging – Charge the battery full in the shortest possible time. There is no benefit for the power system from this strategy.



Vacation Battery Care – This specifies a special charging mode for long term parking of EVs. The EVPP keeps the EB Battery at a specified charging state and charges it full for the end of the vacation battery care period. This strategy is very beneficial for the power system as the battery is connected for a long period, with the only constraint being the end time.

5.3.2 FLEET OPERATOR TO EV USER COMMUNICATION To explore ways of communicating with the user, user interface prototypes, both for desktops and mobile phones, are under development within the EDISON project. The desktop interface has the form of a web site and allows the user to sign his/her vehicles up for fleet operator controlled charging, monitor the charging history and set user specific preferences. The mobile phone interfaces can be divided into two categories: SMS- and Internet-based. The SMS based user interface enables the widest coverage, as most users have at least an SMS capable mobile device. The user then always has the ability to send a status request SMS, e.g. the text “?” to a certain number, to which the fleet operator will reply via an SMS gateway, providing the latest information about the state-of-charge. Additionally, the user might receive an SMS when plugging in the EV, containing an offer for doing smart charging.


Page 34 of 59



The internet based interaction is either in the form of a device specific application or a web site. While device specific applications probably offer the richest user experience and allow for push notifications to the device, a mobile-specific web site can reach a broader spectrum of devices. In the prototypes of these interfaces currently under development, the user can monitor the charging process, see the fleet operator’s current availability prediction for the EV and update the estimated plugout time to meet his/her requirements, while still allowing for smart charging. It is important that the user always understands what the server-side system is allowed to do, and what state-of-charge he/she can expect when the vehicle is needed. Apart from desktop and mobile phone based user interfaces, the EVSE and the EV could also have a user interface, which could offer similar functionality to the mobile phone interface (due to the similar screen size). A solution for these could be to simply host a browser component which displays web pages served by the fleet operator thus allowing for communication with any fleet operator. Alternatively, device-specific applications could be used to communicate with the fleet operator via web services; this would however require standardization of the fleet operator APIs and would make support for different fleet operators difficult. All of the above mentioned user interfaces rely on the fleet operator to provide the data and do therefore not require the EV to have a wireless internet connection.


Page 35 of 59


6


DEMONSTRATION

This section provides examples of how EDISON aims to prove and validate its work through a set of demonstrations. This includes a field test of an EV fleet on the island of Bornholm, testing with Virtual Electric Vehicles, and the use of large virtual fleets simulated in software.

6.1

END-TO-END DEMONSTRATION - FROM EV TO OPERATOR PANEL

The EDISON VPP operator panel has been developed to demonstrate the operation of an EVPP and is implemented as a Microsoft Silverlight web application. A screenshot of the main user interface page is shown in Figure 20.

Figure 20 - EDISON Operator Panel Screenshot


Page 36 of 59



The interface features the following components: ‘1’ is a full list of EVs managed by the EVPP followed by a fleet summery in ‘2’. When an EV is selected in ‘1’, its status and data are displayed in the right portion of the interface. While ‘3’ displays the selected EV’s last known status, ‘4’ displays a subset of the static information on the specific EV. The EV’s location is available to the EVPP when the EV is plugged in and can be seen in ‘5’. The graphs in components ‘6’-‘8’ display information for a selected 24-hour period. Here ‘6’ displays the availability periods of the EV i.e. the periods where the car is parked and plugged in. ‘6’ shows both the recorded and predicted availability of the vehicle, illustrated by the upper and lower horizontal bars. ‘7’ displays the energy prices for the time period and ‘8’ shows the charging schedules which have been generated by the EVPP and are sent out to be executed by the EVSE. The interface screenshot demonstrates that the EVPP can be connected to a set of real or virtual cars each with their own unique patterns and characteristics, and generate charging schedules that optimize grid resources and overall costs. The latter can be seen by comparing prices ‘7’ and charging periods ‘8’ on the screenshot. The EVSE panel is also useful in retrieving and visualizing historical data.

6.2

PHYSICAL DEMONSTRATION ASSETS

The island of Bornholm has been chosen as a test site for demonstrating the technical solutions developed by EDISON. As an island, it is an isolated environment capable of running independently from the surrounding power system and it has a suitable composition of renewable energy sources, which is representative for the whole of Denmark. It is on Bornholm that the ICT architecture and its components will be tested in managing smart charging for EVs of various brands and types. Figure 21 shows the main physical assets that will be used to validate smart charging on the island of Bornholm.


Page 37 of 59



Figure 21 - Physical demonstration assets of EDISON In addition to testing the base EDISON infrastructure and algorithms, since at least one EV brand (Converted Toyota Scion) will support Vehicle-to-Grid (V2G) technology, the EDISON island demonstration can also cover advanced grid services, in which power is delivered back to the grid. Furthermore, Virtual EVs will be used to allow early testing of V2G services as described in Section 6.4. Finally, user fleet-operator selection choice and roaming scenarios can be tested e.g. on the island using different EV and EVSE combinations. Although lessons learned from the physical demonstrations will be an important part of EDISON, the project will also analyze integration scenarios where large numbers of EV’s are in use. For practical reasons this requires simulations, which are the topic of the next section.


Page 38 of 59


6.3


A LARGE-SCALE VIRTUAL FLEET

Potentially large-scale roll-outs of electric vehicles have been predicted within the next few years and already several major automotive manufactures are developing and introducing products that support this, for the most part with uniquevisions for the future, regarding customer needs and standards. For example, a variety of charging socket are currently in use, while some manufacturers are leaning towards battery swapping and others are set on fast charging. On top of all the above mentioned uncertainties, there are also questions that need to be answered regarding the impact of large-scale EV deployment on the power grid. How will the grid handle the extra load? Where and when will this dynamic load be connecting geographically? Where are the potential bottlenecks in the distribution system? How do we prevent them from occurring? Common to all these questions is that they represent potential problems, for which a solution is required before they actually occur. The only way to test proposed solutions in a large scale prior to real deployment is through the use of simulations. For the EDISON project a very flexible EV simulation system was developed as an extension to the IEC 61850 server described earlier. Limited essentially only by computing power, the simulation can be initialized with any number of vehicles and charging spots. Driving patterns and consumption requirements can be configured as required for a particular experiment. Because the simulation runs as an extension of the IEC 61850 server, all devices are automatically made available through the IEC 61850 RESTful interface. As part of the simulation package a series of visualizers were developed, one of which is depicted in Figure 22 showing the simulated vehicles on a map as they move around the island of Bornholm.

Figure 22 – Screenshot from one of the simulation visualizers.


Page 39 of 59


6.4


VIRTUAL ELECTRIC VEHICLES

To further extend our testing capability beyond (limited) EVs and simulation models, virtual EVs have been developed and will be integrated into EDISON. Virtual EVs are not real cars, but have real batteries and controllers such that they provide a realistic platform for testing advanced grid services. A virtual EV system including batteries and the control cabinet for Electricity management is shown in Figure 23.

Figure 23 – Virtual EV including Battery and Control Cabinet

The virtual EV is shown in the reference architecture in Figure 24.


Page 40 of 59



CET-DTU Virtual-EV Figure 24 – Virtual EV in the EDISON Reference Architecture The Virtual EV has the capability to provide regulation energy to the grid in response to a corresponding plan from the EVPP. In this way the ability to test this capability in a realistic way has been accelerated for EDISON. Details of the Virtual EV implementation are shown in Figure 25.


Page 41 of 59



IEC server

The IEC server sends to the IEC Module the charging schedule

IEC Module Virtual COM USB

RS232

Virtual COM USB

EThernet

JSON HTTP TCP IP Ethernet

USB

RS232 RS422

WebBox

BMS

G 2 V

USB

Com channel

Com channel

V 2 G

EThernet

reserved channel

RS485

RS232

RS232 V2G inverter

GRID

Charger

USB

USB

Figure 25 – Virtual EV in the EDISON Reference Architecture


Page 42 of 59



For EDISON demonstrations, the virtual-EV will be an extension of the previous systems in the sense that the previously presented smart charging schedule generated by the EVPP, which incorporates a V2G schedule, can be re-utilized. The present charging schedule is a set of time and charging/discharging set-points that is used to charge the vehicle to optimize overall grid performance and cost. Regulation services are added ‘on top of’ smart charging so that both energy requirements for driving, hourly energy prices and 5-15 min regulation prices are considered by the schedule. In general, the hardware of the virtual-EV can achieve the behavior shown in Figure 26, requiring fixed power for charging, and providing real-time controllable power for V2G.

Power (kW) G2V mode fixed power Deadtime of about 30-40s or less

V2G mode var. power

Figure 26 – Virtual EV Charging Schedule including G2V and V2G


Page 43 of 59


7


CONCLUSION AND FUTURE WORK

Business problem: Design of an energy system for an entire country that will support a large proportion of EVs, plugged into an electric grid, in private homes or at charging stations in company and public parking lots. Challenge: How to maintain security of supply in an electric grid that incorporates a high percentage of green, but fluctuating wind energy and that also has a significant number of mobile EVs, which represent both a challenge and significant storage/regulation potential. Solution Approach: Development of management system to control charging of cars in accordance with the availability of wind energy while enabling optimal use of the electricity grid. Develop simulation and optimization technologies. WP3’s role: Develop a simulation environment to understand dynamics of EVs in the grid. Design and implement algorithms for server side control when charging EVs and using EVs as storage. Development of a server-side management system to control the charging of cars in accordance with the availability of renewable energy aligned with dynamic market prices while enabling optimal use of the electricity grid. Implementation: A suitable and standardized ICT architecture is a vital piece in EV integration and a key part of EDISON. Other research areas such as battery technologies, fast charging and distribution grid impacts are, however, equally important and are covered by partners in the project. Only by covering all topics relevant to society’s transition to electric transportation can EDISON achieve its goals of developing globally applicable solutions that support international standards, supporting an economic, reliable and sustainable energy system, and ultimately, aiding and promoting the cause of the electric vehicle. Status: After having started with real EV attachments at DTU and IBM - for example the DTU Citroen C1 is instrumented with an IEC 61850 Restful Web Services interface and enabled for smart charging - there is also a smart charging spot on the IBM Research Zurich campus, tested with a Think! City EV. We are in the process to extend to a dozen EVs directly on Bornholm island. In all cases, the Edison VPP software generates charging schedules and the actual charging gets logged back to the server-side database, and there are initial user interfaces for the different stakeholders. V2G: The EDISON project will continue with its V2G research and evaluate standards to determine how to best support this type of service. While the IEC 61850 schedules presently used support V2G, the OpenV2G project[9] associated with ISO/IEC 15118 and the V2G project[10] led by Professor Willett Kempton from the University of Delaware, both represent possible alternatives. Website: The progress of EDISON is continuously updated on the project webpage: http://www.edison-net.dk


Page 44 of 59


8


REFERENCES

8.1

SCIENTIFIC PAPERS WRITTEN IN RELATION TO THE EDISON PROJECT: 1.

2.

3.

4.

5.

6.

7.

8.2

O. Sundström and C. Binding "Charging service elements for an electric vehicle charging service provider" Proc. IEEE Power & Energy Society General Meeting, Detroit, MI, 24-29 July 2011. A. Bro Pedersen, E. Bragi Hauksson, P. Bach Andersen, B. Poulsen, C. Traeholt, D. Gantenbein, B. Jansen "Facilitating a Generic Communication Interface to Distributed Energy Resources: Mapping IEC 61850 to RESTful Services" Proc. 1st IEEE Int'l Conf. on Smart Grid Communications "IEEE SmartGridComm 2010," Gaithersburg, Maryland (IEEE, October 2010) 61-66. B. Jansen, C. Binding, O. Sundström, D. Gantenbein "Architecture and Communication of an Electric Vehicle Virtual Power Plant" Proc. 1st IEEE Int'l Conf. on Smart Grid Communications "IEEE SmartGridComm 2010," Gaithersburg, Maryland (IEEE, October 2010) 149-154. Olle Sundström, Carl Binding "Planning Electric-Drive Vehicle Charging under Constrained Grid Conditions" Proc. 2010 Int'l Conf. on Power System Technology "POWERCON2010," Hangzhou, China (IEEE, October 2010). Olle Sundström and Carl Binding “Optimization Methods to Plan the Charging of Electric Vehicle Fleets " Proc. ACEEE International Conference on Control, Communication, and Power Engineering ( CCPE ), pp. 323-328, Chennai, India, July 28, 2010. Carl Binding, Dieter Gantenbein, Bernhard Jansen, Olle Sundstroem, Peter Bach Andersen, Francesco Marra, Bjarne Poulsen, Chresten Traeholt "Electric Vehicle Fleet Integration in the Danish EDISON Project – A Virtual Power Plant on the Island of Bornholm" Proc. IEEE Power & Energy Society General Meeting 2010, Minneapolis, Minnesota, USA, July 25-29, 2010. Carl Binding, Olle Sundström, Dieter Gantenbein, Bernhard Jansen " Integration of an Electrical Vehicle Fleet into the Power Grid " ERCIM News No. 82, pp. 57-58, July 2010.

RELATED CONSORTIUM REPORTS 8.

9.

“Introducing Electric Vehicles Into The Current Electricity Markets”, EDISON Report D 2.3, May 25, 2010, http://www.edison-net.dk/Dissemination/Reports.aspx. “WP7 EDISON picture document”, EDISON Report WP7, November 11, 2010, http://www.edison-net.dk/Dissemination/Reports.aspx.


Page 45 of 59


8.3


STUDENT PROJECTS 10. Einar Bragi Hauksson and Anders Bro Pedersen: “Enabling distributed energy resources in a virtual power plant using IEC 61850”, DTU Master Project, May 2010. 11. Daniel Volder: “Development of a Virtual Electric Vehicle in .Net using battery simulation”, DTU Special Project, January 2010. 12. Lasse Christensen: “Theoretical and Experimental Implementation of a real-time Virtual Power Plant using Windows Workflow Foundation”, DTU Master Project, September 2010. 13. Rasmus Handler and Nima Zandi: “A user-centered prototyped interface for managing future power consumption”, DTU Special Project, December 2008. 14. Andreas Aabrandt: “Optimization of the charging of electric vehicles”, DTU Special Project, June 2011. 15. Ketan Singla: “A generic User Interface to Electric vehicles”, DTU Master Project, April 2011. 16. Jonas Hansen and Peter Wind: “Roaming in a Virtual Power Plant Environment”, DTU Master Project, March 2011. 17. Bo Petersen: “Visual SCL Editor” DTU Special Project, February 2011. 18. Joachim Skov Johansen: “Design and implementation of an electric vehicle charnging station” DTU Bachelor Project, June 2011. 19. Joannis Moles: “Impact Study of Electric Vehicle (EV) Integration on Local Distribution Grid” DTU Master Project, June 2011. 20. Niamh O’Connell: “Dynamic Tafiffs for the Alleviationo of Grid Congestion from Electric Vehicles” DTU Special Project, May 2011.


Page 46 of 59


8.4


EXTERNAL REFERENCES

[1] Carl Binding, Dieter Gantenbein, Bernhard Jansen, Olle Sundstroem, Peter Bach Andersen, Francesco Marra, Bjarne Poulsen, Chresten Traeholt "Electric Vehicle Fleet Integration in the Danish EDISON Project – A Virtual Power Plant on the Island of Bornholm" Proc. IEEE Power & Energy Society General Meeting 2010, Minneapolis, Minnesota, USA, July 25-29, 2010. Also available as IBM RZ 3761. [2] Jacob Østergaard, Anders Foosnæs, Zhao Xu, Tim Anders Mondorf, Claus Amtrup Andersen, Sven Holthusen, Torben Holm, Maja Felicia Bendtsen, Kim Behnke, "Electric Vehicles in Power Systems with 50% Wind Power Penetration : The Danish Case and the EDISON programme" Presented at: European Conference Electricity & Mobility. Würzburg, Germany, 2009 In: European Conference Electricity & Mobility 2009 [3] The FENIX project (Flexible electricity network to integrate the expected energy evolution), http://www.fenix-project.org/. [4] Shi You, Chresten Træholt, and Bjarne Poulsen, “Generic virtual power plants: Management of distributed energy resources under liberalized electricity market,” in Proceedings of the 8th IET International Conference on Advances in Power System Control, Operation and Management. Hong Kong, China: Institution of Engineering and Technology, 8–11 November 2009. [5] Bernhard Jansen, Carl Binding, Olle Sundström and Dieter Gantenbein "Architecture and communication of an electric vehicle virtual power plant" In IEEE International Conference on Smart Grid Communications, Gaithersburg, MD, USA, September 2010. IEEE [6] Olle Sundström and Carl Binding "Optimization Methods to Plan the Charging of Electric Vehicle Fleets" Proc. ACEEE International Conference on Control, Communication, and Power Engineering (CCPE), pp. 323-328, Chennai, India, July 28, 2010. Also available as IBM RZ 3768. [7] Olle Sundström, Carl Binding "Planning Electric-Drive Vehicle Charging under Constrained Grid Conditions" Accepted at International Conference on Power System Technology, China, October 24-28, 2010. Also available as IBM RZ 3785. [8] Anders Bro Pedersen, Einar Bragi Hauksson, Peter Bach Andersen, Bjarne Poulsen, Chresten Træholt and Dieter Gantenbein "Facilitating a generic communication interface to distributed energy resources", In Proceedings of International Conference on Smart Grid Communications (SmartGridComm), 2010 [9] The OpenV2G Project, http://openv2g.sourceforge.net/ [10] The Vehicle To Grid Project - University of Delaware, http://www.udel.edu/V2G/


Page 47 of 59



th

[11] R.P. Gupta, Substation Automation Using IEC61850 Standard, 15 National Power Systems Conference (NPSC), IIT Bombay, December 2008.

9

APPENDIX A: IEC 61850 EXTENSIONS FOR ELECTRIC VEHICLES

The logical node ZCEV is an extension to IEC 61850-7-420, representing electric vehicles. The logical node describes the static and dynamic status of the electric vehicle and provides information on the location of the electric vehicle as well as user requirements

EV Information ZCEV Data Object Name

Common Data Class

LNName Data System logical node data

Explanation Shall be inherited from logical-node class (see IEC 618507-2)

LN Shall inherit all mandatory data from common logical node classes The data from LLN0 may optionally be used

ID MaxChPwr MaxDcPwr AvlPhases

GeoLoc Status Information ReqPlan

UID ASG ASG ENG

T M/O/C

EV identifier, preferably a GUID Maximum rated charging power Maximum rated discharging power Available connection types Value

Explanation

0

Single-Phase

1

Two-Phase

2

Three-Phase

GEO

The geographic location of the EV

ENS

Required EV Power Plan Value 0 1 2 3 4

Explanation Not applicable / Unknown Immediate Charging Threshold Smart Charging Smart Charging Vacation Battery Care


M O M M M

M

O

M

Page 48 of 59


ConnType

DiscTime ReqSOCDisT ReqSOCLow ReqSOCHigh ReqRtChPwr ReqRtDcPwr Measurements LstFullCap RtCap CurCap SOC CurPwr


ENS

Type of connection (Current) Value

Explanation

0

Single-Phase

1

Two-Phase

2

Three-Phase

M

INS INS INS INS

Expected time of disconnection

ASG ASG

Required Maximum rated charging power Required Maximum rated discharging power

O O O O O O

MV MV MV MV MV

Last full capacity (kWh) Rated capacity (kWh) Current capacity (kWh) State of charge (%) Current Power (kW)

M O O M M

Required SOC at the time of disconnection Required Minimum SOC during connection Required Maximum SOC during connection


Page 49 of 59



10 APPENDIX B: IEC 61850 EXTENSIONS FOR CHARGING STATIONS (EVSE) The logical node ZCHS was created as an extension to IEC 61850-7-420 and represents the electrical parameters of the EVSE (electric vehicle support equipment or charging spot) and other important nameplate information including for example location. The ZCHS logical node describes all relevant status information of the EVSE to allow utilizing systems to adjust to the given boundaries and current status to allow smart charging.

Charging spot information ZCHS Class Data Object Name

Common Data Class

LNName Data System logical node data

Explanation Shall be inherited from logical-node class (see IEC 618507-2)

LN Shall inherit all mandatory data from common logical node classes The data from LLN0 may optionally be used

ID MaxChPwr MaxDcPwr AvlPhases

GeoLoc Status Information CsState

UID ASG ASG ENS

Chargingspot identifier, preferably a GUID Maximum rated charging power Maximum rated discharging power Available connection types Value

Explanation

0

Single-Phase

1

Two-Phase

2

Three-Phase

GEO

The geographic location of the CS

ENS

Chargingspot state

Value

CsAction

ENS

T M/O/C

0 1 2

M

O

Explanation

0 Not applicable / Unknown 1 No car connected 2 Car connected Chargingspot action

Value

M O M M M

M

Explanation Not applicable / Unknown Charging Discharging


M

Page 50 of 59


ConnType

EVID Settings LockSt


ENS

Type of connection (Current) Value

Explanation

0

Single-Phase

1

Two-Phase

2

Three-Phase

UID

The ID of the currently connected EV

ENG

Chargingspot lock state Value

MaxChrPwr MaxDchPwr Measurements CurPwr

M

O

Explanation

0

Disconnected

1

Connected and unlocked

2

Connected and locked

M

ASG ASG

Maximum charging power Maximum discharging power

M M

MV

Current Power (kW)

M


Page 51 of 59



11 APPENDIX C: USE-CASE: BASIC EV GRID CONNECTION

11.1 BRIEF DESCRIPTION This use case describes the base scenario of connecting an EV to the grid.

11.2 SEQUENCE DIAGRAM

Charging Station (EVSE)

Driver

Fleet Operator (EVPP)

EV

Ancillary Services

DSO

TSO 2. Spot Market Prices (Day Ahead)

3. Physical Connection

Energy Market

Retailer

Generation

1. Spot Market Prices

4. Authentication (tbd) 5. EV State

6. EV State

Compute optimal charging plan 8. (")

7. Charging Plan

9. Confirmation 10. Modifications

Recompute optimal charging plan 12. (")

11. Charging Plan

13. Confirmation

The following steps are illustrated in this use case: 1.

The Retailer receives the spot market price from the energy market.

2.

The spot market price is forwarded to the Fleet Operator.

3.

The EV is connected to the Charging Station for charging.


Page 52 of 59



4.

The EDISON authentication protocol is carried out between the EV (driver) and the Fleet Operator.

5.

The EV state information is reported to the Charging Station.

6.

The EV state information is forwarded to the Fleet Operator.

Compute Optimal Charging Plan: Based on reported and stored data for the EV in question, the Fleet Operator computes an optimal charging plan. 7.

The charging plan is forwarded to the Charging Station.

8.

The Charging Station forwards the charging plan to the EV.

9.

The Fleet Operator sends a confirmation of the charging plan to the EV driver.

10. The Driver can request changes to the charging plan if it is not acceptable. This could be done immediately or at a later time. Charging Plan Optimization-Grid Congestion Avoidance: Based on the modifications requested by the Driver, the Fleet Operator computes a new optimal charging plan. 11. The revised charging plan is forwarded to the Charging Station. 12. The Charging Station forwards the plan to the EV. 13. The Fleet Operator sends a confirmation of the charging plan to the EV driver.


Page 53 of 59



12 APPENDIX D: USE-CASE: GRID SCALABILITY

12.1 BRIEF DESCRIPTION EVs supply their trip history and state information when they are connected for charging. Based on this information the Fleet Operator forecasts its needs, and negotiates load curves with the Retailer and DSO such that the power and grid constraints are respected. The charging plans are distributed to the Charging Stations and EVs. A subsequent adjustment by the Retailer or DSO may result in new charging plans being computed and distributed.



Page 54 of 59




Driver

Ancillary Services

DSO


EV

TSO 2. Spot Market Prices (Day Ahead)

3. Physical Connection

Energy Market

Generation

Retailer 1. Spot Market Prices

4. Authentication (tbd) 5. Trip History 6. Trip History 7. EV State

Data collection and storage EVPP Forecasting

8. EV State

9. Load Curve Boundaries 10. Preferred Load Curve

Load Curve Optimization

11. Preferred Load Curves 12. Grid Constraints

...

Charging Plan Optimization

Grid Congestion Avoidance

Preferred Load Curves 13. Congestion Cleared

14. Selected Load Curve 16 (")

15. Charging Plan

17. Confirmation

18. Adjustment Charging Plan Re-optimization 21. (")

19. Renegotiate Load Curves

20. Charging Plan 22. Adjustment

Charging Plan Re-optimization

23. Renegotiate Load Curves 24. Renegotiate Load Curves

26. (")

25. Charging Plan


Page 55 of 59




The Retailer receives the spot market price from the energy market.

2.

The spot market price is forwarded to the Fleet Operator.

3.

The EV is connected to the Charging Station for charging.

4.

The EDISON authentication protocol is carried out between the EV (driver) and the Fleet Operator.

5.

The EV reports its trip history to the Charging Station.

6.

The Charging Station forwards the trip history to the Fleet Operator.

7.

Similarly the EV state information is reported to the Charging Station.

8.

The EV state information is forwarded to the Fleet Operator.

Data Collection and Forecasting: Based on reported and stored data for the EV in question, the Fleet Operator predicts the requirements for the EV and its overall needs. 9.

Based on its overall needs the Fleet Operator proposes Load Curve Boundaries to the Retailer.

10. The Retailer selects the preferred load curve, which is returned to the Fleet Operator.. Charging Plan Optimization-Grid Congestion Avoidance: The Fleet Operator computes optimal charging plans for its EV fleet and forwards the resulting load curves to the DSO. If the proposed load curves would result in grid congestion, the DSO imposes additional grid constraints on the Fleet Operator, which computes a revised plan respecting those constraints. When a plan is proposed that does not lead to congestion, the DSO signals that the congestion has been cleared (the plan is OK). 11. The Fleet Operator forwards load curves based on its computed plan to the DSO. 12. The DSO imposes additional constraints if the proposed load curves would result in grid congestion. 13. Once load curves are proposed that do not result in grid congestion, the DSO indicates that the congestion condition has been cleared. 14. The selected load curve is reported by the Fleet Operator to the Retailer. 15. The computed charging plan is forwarded by the Fleet Operator to the Charging Station. 16. The Charging Station forwards the charging plan to the EV.


Page 56 of 59



17. The Fleet Operator sends a confirmation of the charging plan to the EV Driver, who could react if the plan were not acceptable (see the previous use case). 18. At some later time, an adjustment in the load curves may be requested by the Retailer. Charging Plan Re-Optimization: If the adjustment received from the Retailer necessitates changes, the process to optimize and distribute the charging plans is repeated by the Fleet Operator. 19. If required, the load curves are renegotiated with the DSO (see flows 11 – 13). 20. Revised charging plans will be sent to all Charging Stations impacted by the adjustment. 21. The charging plans are forwarded to the EVs. 22. At some later time, an adjustment in the load curves may be requested by the DSO. Charging Plan Re-Optimization: If the adjustment received from the DSO necessitates changes, the process to optimize and distribute the charging plans is repeated by the Fleet Operator. 23. If required, the load curves are renegotiated with the Retailer (see flows 9 – 10). 24. If required, the load curves are renegotiated with the DSO (see flows 11 – 13). 25. Revised charging plans will be sent to all Charging Stations impacted by the adjustment. 26. The charging plans are forwarded to the EVs.


Page 57 of 59



13 APPENDIX E: USE-CASE: V2G DYNAMICS

13.1 BRIEF DESCRIPTION The TSO issues a request for regulation power. The EVPP Fleet Operator responds according to the capabilities offered earlier. The charging plan for a subset of the EVs is modified such that they supply power to the market.



Driver

Ancillary Services

DSO


EV

TSO

Energy Market

Retailer

Generation

1. Offer Regulation Power 2. Offer Regulation Power

EVs Connect and Receive Charging Plans as Usual

3. Request Regulation Power 4. Request Regulation Power Renegotiate Load Curves Charging Plan Re-optimization

5. Charging Plan

Renegotiate Load Curves

(") 6. Metering Data


The Fleet Operator offers regulation power (specific amounts for specific times of day) to its Retailer.

2.

The Retailer forwards the regulation power offer to the Ancillary Services market.

EVs will connect to the system and receive charging plans as usual (not shown in this use case).


Page 58 of 59



3.

At a later time, the TSO sends a request for regulation power to the Retailer that offered the regulation power.

4.

The Retailer forwards the regulation power request to the Fleet Operator.

Charging Plan Re-optimization: Based on the regulation power request, the Fleet Operator will compute new charging plans for some of the EVs in its fleet, in particular instructing a subset of the EVs to supply power to the grid. This may involve renegotiating the load curves with the Retailer and DSO (given the timing constraints of supplying regulation power, this should not normally be required). 5.

The Fleet Operator forwards new charging plans to all EVs impacted by the change. This will cause the requested EVs to supply power to the grid for a specified period.

6.

The Retailer meters the supplied power and reports this to the TSO.

--- END OF DOCUMENT ---


Page 59 of 59