Communications Requirements for Smart Grids and Active Demand ADDRESS INTERNATIONAL WORKSHOP ACTIVE DEMAND: THE FUTURE OF ELECTRICITY.

Transcription

1 Communications Requirements for Smart Grids and Active Demand ACTIVE DEMAND: THE FUTURE OF ELECTRICITY Andrew Paice, ABB communication The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/ ) under grant agreement n Outline Goals & Methodology Survey on Future requirements of Smart Grids Architecture Design Methodology Survey Results Key requirements Service Oriented Architecture / Web Services Draft Architecture Actor interactions Service & Connectivity Traffic Matrix 2

2 Goals In the project, the Communications workpackage has the goal of providing A guideline to designing a communications architecture that will enable active demand A guide to testing that the implemented communications system is sufficient to operate a smart grid with active demand Tested prototypes and a design for the field tests The aim of the first communication activity was to: Identify, describe and specify the main requirements on the communication infrastructure data transmission architecture, and data service requirements in order to enable active demand 3 Methodology Survey Partners and members of the GUS will be surveyed regarding: Status of the current communications system Expected developments Specific Smart Grids requirements Use Case Analysis Based on the Use Cases of Deliverable D1.1, the interactions between actors are analyzed down to the individual links to determine the communications requirements 4

3 Survey on future Smart Grids Communications 19 entities answered the survey: ABB, Alcatel-Lucent, Consentec, Current Technologies International (CTI), Elektrizitätswerke des Kantons Zürich (EKZ), ENEL Distribuzione, ENEL Produzione, Electric Power Research Institute (EPRI), Ericsson, Iberdrola, Instituto Tecnológico de la Energía (ITE), KEMA, Landis+Gyr, LABEIN Tecnalia, Vattenfall, Vlaamse Instelling voor Technologisch Onderzoek (VITO), VTT and ZIV They provided details regarding: Interoperability, PHY Media, Scalability, Regulatory Issues, Standardisation, Performance: business / technical, Robustness/availability, Plug & Play, Management, Upgrades, Security, CAPEX & OPEX 5 Key Results / Communications Requirements Flexibility with respect to physical media Last mile likely to be PLC, wireless, or re-routed via Public TeleCom Full interoperability for all network elements To be guaranteed by XML based messaging & CIM standards Secure remote access to all elements of the network Implementation to be compatible with TCP/IP and Web Services Technical & business performance requirements Communication performance should be independent of grid state At Aggregator & E-Box level the network should be self-configuring Network management: Visualization & remote configuration 6

4 Communications Architecture Basis: Service Oriented Architecture 7 Communications Architecture Basis: Service Oriented Architecture & Web Services 8

5 Architecture Design Methodology Based on the requirements & use cases from D1.1 Step 0: Identify the Logical Communication Entities Step 1: Identify the Logical Architecture Analyze the interactions to determine the required Services Determine cardinality, addressing & partitioning Step 2: Map Logical to Physical Architecture Consider Geographical Span & Technologies Consider Performance Issues Determine the resulting network Step 3: Determine completeness Otherwise iterate Steps 1 & 2 9 Abstract Communications Architecture [1...20] 10

6 sd SRP- VRP-SL ( Scheduled Re- Profiling Voltage Regulation Power Flow Control Slow) DSO 1.(detection of possible critical situation process) TSO 2.(determination solutions process) 3.send(AD informations) 4.request(offers to meet its needs) 12.send(matching process results) 13.(checking technical feasibility pr oc ess) 14.(aggregates DSO network at the TSO level process) 15.send(aggregation results) 17.send(acceptance) Context: DSO (requester) checks the consumption/production plans for a certain timeframe (days, weeks, months,?) verifying with its tools (DMS (from or EMS) Actors) the compliance with network operation constraints. Market 16.(checking technical feasibility process) 18.send(acceptance ) The matching process could be launched in the defined Time frame (gate closure) 6.send(offers submission) 9.matching process() Aggregator (from Actor s) 8.send(offers submission) 10.send(matching process results) 11.send(matching process results) The process of the aggregation could be launched in the defined Time frame 5.make offers process() 19.send(AD ac tivati on) Market participants Energy Box 7.make offers process() 20.request(AD activation) Consumer Service and Connectivity Starting from the service description in (D1.1) and some initial general assumptions concerning the network, draft a generic architecture describing the logical end to end connection needed for the implementation of each specific service. 11 Traffic Matrix TSOack Message Payload Short Description From To (n:m) TSO DSO (1:6) Note: Data Lenght (bit) Note Payload (Application Layer) Parameter 256 XML Message Description TimeStamp 64 Standard Reference Sender ID 32 Example: Total 352 Traffic (60;60) (Frequency Periodicity in second; Max Round Trip Time including channel and Telecommunication Interfaces in seconds) Priority L Low; High 12

7 Performance: business 13 Performance: technical 14

8 ADDRESS Scenario & Traffic Matrix Sample Using WEB Services will have big impact on the traffic matrix while assuring the highest level of interoperability Macro Load Areas TSO 2 Mb/s Coordination Info AD Products Validation Scenario TSO 1-5 DSOs Aggregators 1-20 Market Participants Market 1 E-boxes SRP Request Message Payload Short Description Market Participant From To (n:m) Market (1000:1) Note: Request - from different buyers - for a SRP Product Payload (Application Layer) Data Lenght (bit) Note Parameter 256 Description TimeStamp 64 Standard Reference Sender ID 32 Description Service ID 32 Description Service 16 Status requested/supplied Service negotiation gate 64 Time Reference closure Mini mum volume 64 Power reference Requested/supplied power or power curve 256 Description shape Price structure 256 Description Macro Load Areas or 256 Description Load Areas involved Other conditions 256 Description 256 kb/s DSO 32Mb/s Load Areas Sensitivity Matrix (day ahead) Load Profiles 8Mb/s Aggregator 32Mb/s Activation Info AD Products Validation Partecipatio n Info 2Mb/s 64kb/s 6Mb/s Market 4Mb/s results 64kb/s Offer Request results 64kb/s Market Participant Total (Before Market gate (Frequency Periodicity in second; Max Round Trip Time Traffic closure;60) including channel and Telecommunication Interfaces in seconds) Priority L Low; High 64 kb/s E-Box Real Time / Time constraining Data Non Real Time Data Exchange 15 Conclusions & next steps The requirements on the ADDRESS communications infrastructure have been identified by: A survey on the needs of the communications infrastructure An initial analysis of the use cases A service oriented architecture based on web services and standardized XML messages forms the basis for ADDRESS communications The Traffic matrix has been introduced as a tool for estimating & representing the overall performance requirements for a specific scenario Next steps: Communications media will be identified Specific solutions will be developed The requirements and architecture will be refined Communications architectures for the field tests will be developed 16

9 THANK YOU The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/ ) under grant agreement n