Transcript Development of VPP as a balancing asset

eBADGE WP3:
Development of VPP
as a balancing asset
Presented by:
Ursula Krisper, Elektro
Ljubljana d.d., Slovenian
Utility, Distribution of
Electricty
Workshop, Amstedam
WP3, the aims
• 1st: doing the analysis of TSOs, DSOs,VPPs, Resources; Loads,
RES, their Electricity and Balancing Market interfaces and standards
• 2nd: building up a robust & high performance message bus between
all entities
• 3rd: developing forecasting, optimisation and control strategies 4 VPP
agregation, activation in order to comply the requirements of
Integrated Balancing Market
• M1-M36, leader: XLAB
• other partners: SAP, EL, Sauper, TS, CG, RSE
Market-level communication: General
Requirements
• Exchange of messages between all entities; homeLP, VPP
commands
• Home Energy Hub (one end user; each of 1kW)
• VPP in the role of control (HEH & end users)
• Balancing service providers (BSP) send capacity/energy bids to
TSOs, TSOs send activation requests to BSPs, BSPs may
acknowledge/reject
• International balancing Market: TSO-to-TSO model, TSOs send
balancing requests to super-TSO
• Security
• Reliability; mostly synchronous communication
Market-level comm.: existing standards
• OpenADR 2.0
– Building‘s Code, USA/California, example: DR for the HVAC systems
– Fully automatic, grid and also price based DR
– Entities: VTN (Virtual Top Node as Master)=VPP
– VEN (Virtual End Node as Slave); Aggregator's needs covered by many
VENs
– Long activation messages, HEH‘s prediction/forecast not foreseen
• IEC 60870-5-101, 60870-5-104, 61850; popular in EU
– Not supporting all VPP‘s information Types
– Some projects used it; not suitable for market involvement
Other existing “smart grid” standards
• OPC (Open Platform Communication)/OPC UA
– does not define semantics
• Open Smart Grid Protocol, binary standard for Smart meters
– binary, extremely complex (8 bytes need 40 Boolean predefined fields),
not extensible
• In D 3.1.2 are shortly described Energy market Standards
Multi-level communication: example
market-level
HEH-level
out of scope (illustration only)
HEH-level communication: requirements
Messages between VPP and HEH:
• VPP sends load report requests to HEH
• VPP send activation request (increase/decrease load) to HEH
• HEH sends acknowledgement or rejection to VPP or modify
• VPP requests status report from HEH
• Other messages…. Device capabilities
Efficiency (bandwidth, CPU)
Extensibility
Security (slightly less important than on market level)
eBADGE – The Developed Data Model
• 31 message types on HEH-level, 9 on market-level
– Not HTTP-based
– Use good practices from OpenADR 2.0
– Message bus should provide gateways for some existing standards
• Technical choices
– JSON-based
– ext_ field name prefix reserved for vendor extensions
• Not set in stone – we may have to adopt something else later!
WP3, Communication Description
•
Analysis, Design and Implementation of the eBADGE Message
Bus
•
Objective: "To design and implement a robust and high
performance message bus between the components and
stakeholders, where the chosen open standard will be used as
the message data format.”
•
Two way communication b. VPP and DR devices,
•
Centralized point of comm. for all involved entities
•
RabbitMQ was selected as most appopriate „message broker“
for covering all the needs of data exchange
•
Hgsdhgasjdgajdhgjagdjgdgsdgksd 3.2. page 14 and page 22
Task 3.4 – Overview; the third WP task
• Goal: Design and implementation of new VPP data analysis,
optimization and control strategies
• Involved partners:
– Cybergrid
– Elektro Ljubljana
– SAP (Task leader)
– XLAB
• Deliverables:
– M24: D3.4.1 - New VPP optimization and control strategies – First
version
– final version in M36
Task 3.4 - Scope
resources
metering
forecasting
aggregation
optimization
disaggregation
activation
monitoring
evaluation
reporting
data analysis
forecasting
optimization
&
control
Task 3.4 - Forecasting
• First task is to estimate the Baseline Load (load that would be
observed in absence of an external Demand Response event) for:
– Individual households
– Individual industrial consumers
• Usage:
– Fair compensation for curtailment
– Possible input for the electricity pricing in exchange
• Input: hourly historical load data for each consumer for last 4 weeks
• Output: 1- day ahead hourly forecasts
Task 3.4 – Forecasting individual industrial
users
• very predictable behavior:
• Plot 4 weeks overlapping: Ind1 (June 2011)
Task 3.4 – Forecasting individual industrial
users
• Training set: 28 days, test set (forecast): 1 day
• Many statistical methods good accuracy: MAPE on test set: 5-10%
Task 3.4 – Forecasting individual households
• very unpredictable behavior:
• Plot 4 weeks overlapping: Dom15 (May 2013)
Task 3.4 – Forecasting individual households
• all statistical methods – bad accuracy:
• MAPE:30%- 80%, in extreme cases over 100%!
(for 15-min measurement: 1100%)
Task 3.4 – Forecasting groups of households
• But: behavior of household – groups again predictable
• MAPE for shown case: 7,3 % on test set
Load forecasting
• performs well on
– industrial users
– groups of residential users
• For forecationg R-programming / R- statistical package is used
– as web service
– in eBadge cloud
– integrated with CyberGrid's VPP software
• used regularly for baseline calculations in the pilot
• The Future Steps: Forecasting separete devices shall bring better
results, instead of forecating the whole household consumoption