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
• 1 st : doing the analysis of TSOs, DSOs,VPPs, Resources; Loads,
RES, their Electricity and Balancing Market interfaces and standards
• 2 nd : building up a robust & high performance message bus between all entities
• 3 rd : 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 data analysis forecasting aggregation optimization disaggregation activation optimization
& control monitoring evaluation reporting

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