eBADGE WP3: Development of VPP as a balancing asset

1. eBADGE WP3: Development of VPP as a balancing asset Presentedby: Ursula Krisper, Elektro Ljubljana d.d., SlovenianUtility, DistributionofElectricty Workshop, Amstedam

2. WP3, the aims • 1st: doingthe 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: developingforecasting, optimisationandcontrolstrategies 4 VPP agregation, activation in order to complytherequirementsofIntegratedBalancing Market • M1-M36, leader: XLAB • otherpartners: SAP, EL, Sauper, TS, CG, RSE

3. Market-level communication: General Requirements • Exchange of messages between all entities; homeLP, VPP commands • Home Energy Hub (one end user;eachof 1kW) • VPP in the role ofcontrol(HEH & endusers) • Balancing service providers (BSP) send capacity/energy bids to TSOs, TSOs send activation requests to BSPs, BSPsmayacknowledge/reject • Internationalbalancing Market: TSO-to-TSO model, TSOs send balancing requests to super-TSO • Security • Reliability; mostly synchronous communication

4. Market-level comm.: existing standards • OpenADR 2.0 • Building‘s Code, USA/California, example: DR for the HVAC systems • Fully automatic, gridandalsoprice 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

5. Otherexisting “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

6. Multi-level communication: example market-level HEH-level out of scope (illustration only)

7. HEH-level communication: requirements Messagesbetween VPP and HEH: • VPP sends load reportrequests 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 • Othermessages…. Device capabilities Efficiency (bandwidth, CPU) Extensibility Security (slightly less important than on market level)

8. eBADGE – TheDevelopedData Model • 31 messagetypes 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!

9. 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.” • Twowaycommunication b. VPP and DR devices, • Centralizedpointofcomm. forallinvolvedentities • RabbitMQwasselected as most appopriate „messagebroker“ forcoveringalltheneedsofdataexchange • Hgsdhgasjdgajdhgjagdjgdgsdgksd 3.2. page 14 andpage 22

10. Task 3.4 – Overview;thethird 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

11. Task 3.4 - Scope resources metering forecasting data analysis forecasting aggregation optimization optimization & control disaggregation activation monitoring evaluation reporting

12. 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

13. Task 3.4 – Forecasting individual industrial users • very predictable behavior: • Plot 4 weeksoverlapping: Ind1 (June 2011)

14. Task 3.4 – Forecasting individual industrial users • Training set: 28 days, test set (forecast): 1 day • Many statistical methodsgoodaccuracy: MAPE on test set: 5-10%

15. Task 3.4 – Forecasting individual households • very unpredictable behavior: • Plot 4 weeksoverlapping: Dom15 (May 2013)

16. Task 3.4 – Forecasting individual households • all statistical methods – badaccuracy: • MAPE:30%- 80%, in extremecasesover100%! (for 15-min measurement: 1100%)

17. Task 3.4 – Forecasting groups of households • But: behavior of household – groups again predictable • MAPE for shown case: 7,3 %on test set

18. Loadforecasting • performswell on • industrialusers • groupsofresidentialusers • Forforecationg R-programming / R- statisticalpackage is used • as webservice • in eBadge cloud • integratedwithCyberGrid's VPP software • used regularlyforbaselinecalculations in the pilot • TheFutureSteps: Forecastingseparetedevicesshallbringbetterresults, insteadofforecatingthewholehouseholdconsumoption