Transcript WP4-IntlWS-ABB-Communication Architecture

Communications Requirements for
Smart Grids and Active Demand
ADDRESS INTERNATIONAL WORKSHOP
ACTIVE DEMAND: THE FUTURE OF ELECTRICITY
Andrew Paice, ABB
Paris, June 9th 2010
communication
The research leading to these
results has received funding from
the European Community's
Seventh Framework Programme
(FP7/2007-2013) under grant
agreement n° 207643
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
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
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”
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
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
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
4
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
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
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
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
6
Communications Architecture
Basis: Service Oriented Architecture
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
7
Communications Architecture
Basis: Service Oriented Architecture & Web Services
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
8
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
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
9
Abstract Communications Architecture
E-Box n
[10...100000]
E-Box 1
MARKET
E-Box 1
[10...100000]
E-Box n
[1...20]
Aggregator 1
[1...20]
Producer n
Producer 1
Aggregator n
[1...600]
[1...20]
BRP n
DSO 1
[100...5000]
DSO n
BRP 1
[1...5]
DG n
[5...100]
[10...500]
DG 1
TSO 1
Trader n
TSO n
Retailer 1
Retailer n
Trader 1
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
10
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.
sd SRP-VRP-SL (Scheduled Re-Profiling Voltage Regulation Power Flow Control Slow)
DSO
Market
Aggregator
(from Actors)
(from Actors)
Energy Box
TSO
Market participants
Consumer
(from Actors)
1.(detection of possible critical
situation process)
The matching process
could be launched in
the defined Time
frame (gate closure)
2.(determination solutions process)
3.send(AD informations)
The process of the
aggregation could be
launched in the
defined Time frame
4.request(offers to meet its needs)
5.make offers process()
6.send(offers submission)
7.make offers process()
8.send(offers submission)
9.matching process()
10.send(matching process results)
11.send(matching process results)
12.send(matching process results)
13.(checking technical feasibility
process)
14.(aggregates DSO network at the
TSO level process)
15.send(aggregation results)
16.(checking technical feasibility
process)
17.send(acceptance)
18.send(acceptance )
19.send(AD activation)
20.request(AD activation)
Context: DSO (requester) checks the consumption/production plans for a
certain timeframe (days, weeks, months, ?) verifying with its tools (DMS
(from
Actors)
(from Actors)
or EMS)
the compliance with network operation
constraints.
(from Actors)
(from Actors)
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
11
Traffic Matrix
TSOack
Message Payload Short Description
From  To (n:m)
TSO  DSO
(1:6)
Note:
Data
Lenght (bit)
Note
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
Payload
(Application
Layer)
Low; High
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
12
Performance: business
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
13
Performance: technical
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
14
ADDRESS Scenario & Traffic Matrix Sample
TSO
Using WEB Services will have big
impact on the traffic matrix while
assuring
the
highest
level
of
interoperability
2 Mb/s
Macro
Load
Areas
32Mb/s
AD
Products
Validation
Info
Sensitivity
Matrix
(day ahead)
Note: Request - from different buyers - for a SRP Product
Market
Load Profiles
Data
Parameter
TimeStamp
Sender ID
Service ID
Service
requested/supplied
Service negotiation gate
closure
Minimum volume
Requested/supplied
power or power curve
shape
Price structure
Macro Load Areas or
Load Areas involved
Other conditions
Lenght (bit)
256
64
32
32
Note
Description
Standard Reference
Description
Description
16
Status
64
Time Reference
64
Power reference
256
Description
256
Description
256
Description
256
Description
Total
(Before Market gate
closure;60)
L
…
(Frequency Periodicity in second; Max Round Trip Time
including channel and Telecommunication Interfaces in seconds)
Low; High
64kb/s
AD Product
Request
6Mb/s
Load Areas
64kb/s
Priority
DSO
4Mb/s
Market
Participant
AD Product
results
AD Product
results
8Mb/s
64kb/s
Traffic
2Mb/s
Payload
(Application Layer)
Market Participant 
Market (1000:1)
AD
Products
Validation
Info
256 kb/s
Scenario
TSO
1-5
DSOs
1-600
Aggregators
1-20
Market Participants
1000-10000
Market
1
E-boxes
100000-1000000
Message Payload Short Description
SRP Request
From  To (n:m)
Coordination
Info
Aggregator
AD Product Offer
32Mb/s
AD Product
Partecipatio
n Info
AD Product
Activation
Info
64 kb/s
E-Box
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
Real Time / Time constraining Data
Exchange
15
Non Real Time Data Exchange
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
ADDRESS INTERNATIONAL WORKSHOP
Paris, June 9th 2010
16
THANK YOU
The research leading to these
results has received funding from
the European Community's
Seventh Framework Programme
(FP7/2007-2013) under grant
agreement n° 207643