Development of VPP as a balancing asset

Development of VPP
as a balancing asset
Presented by:
Ursula Krisper, Elektro
Ljubljana d.d., Slovenian
Utility, Distribution of
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
• Exchange of messages between all entities; homeLP, VPP
• 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
• 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
– 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
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)
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
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)
• Deliverables:
– M24: D3.4.1 - New VPP optimization and control strategies – First
– final version in M36
Task 3.4 - Scope
data analysis
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
• very predictable behavior:
• Plot 4 weeks overlapping: Ind1 (June 2011)
Task 3.4 – Forecasting individual industrial
• 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

similar documents