1 / 55

ENTSO-E Transparency Stakeholder Expert Group Meeting 2 28 February 2013

ENTSO-E Transparency Stakeholder Expert Group Meeting 2 28 February 2013. Agenda. 2. TSEG meeting 1 follow up…. Sent on 4 Feb: The draft minutes comment before Wednesday 13 February. (see next slide) The draft detailed descriptions and comment sheet

odessa
Download Presentation

ENTSO-E Transparency Stakeholder Expert Group Meeting 2 28 February 2013

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ENTSO-E Transparency Stakeholder Expert Group Meeting 228 February 2013

  2. Agenda 2

  3. TSEG meeting 1 follow up….. • Sent on 4 Feb: • The draft minutes comment before Wednesday 13 February. (see next slide) • The draft detailed descriptions and comment sheet • The updated ToR as discussed for final approval. • Asked for proposals for: • Art.5-1-c,“Technical and operational criteria which data providers would need to fulfil when providing data to the central information transparency platform” • Art.5-1-d,”Appropriate classification of production types”. • We would like to ask for you to return your comments in the Excel sheet and proposals before 22nd February, 12 noon to peter.campbell@entsoe.eu which will then be consolidated and discussed at the next TSEG meeting on 28th February in Brussels. Input received after 22 February will not be considered. • All documentation will be published at https://www.entsoe.eu/data/entso-e-transparency-platform/ 3

  4. Terms of Reference

  5. Manual of Procedures: Terms of Reference • ENTSO-E asks for approval of the ToR 5

  6. Draft Manual of ProceduresOverview, scope, aims and readership

  7. Overview • Readership: • Data owners • Data providers • Data consumers • Purpose: • To provide, either directly or by reference: • All information that would be required for a data provider to develop & operate a system to submit data to the platform in accordance with the legislation and with ENTSO-E system definitions • All information that would be required to develop & operate a system to extract data from the platform 7

  8. Scope of the manual of procedures • In scope: • “details and format of the data to be published…” per Art 4 of the regulation • Anything that a 3rd party would need to know to submit or extract such data to or from the platform • Not in scope: • Matters internal to ENTSO-E or its suppliers • Material that would be considered confidential to ENTSO-E or its members 8

  9. Structure • The aim is that the handbook does not duplicate material published elsewhere. If such material is required it is included by reference only. For example reference to definitions in the Regulation on submission and publication of data in electricity markets and in Network Codes, existing standards documentation. • The handbook will be constructed as an on-line resource (which facilitates the cross-referencing of material) but a pdf reference version can be exported for download. • Only the on-line copy will be definitive. 9

  10. Article 5 requirements: • To be developed under open and transparent consultation withstakeholders • To be made available to the public • To be updated when necessary • To be submitted to ACER who will provide an opinion 10

  11. Details and format of the submission of data • Detailed data descriptions (next topic for today) • Implementation Guides: to be produced for each business domain under the Regulation (Load, Generation etc.) • Implementation Guides • Provide XML schemas for encoding of the data • Are developed by the ENTSO-E WG EDI • already in existence for the present www.entsoe.net platform • Currently published through the EDI library on www.entsoe.eu 11

  12. Standardised ways and formats of data communication and exchange… • Connection and submission methods: • Web Services • Market Data Exchange System (MADES) • Secure ftp • Payload expected to be XML documents compliant with the XML schemas of the relevant Implementation Guide 12

  13. Other topics • Management of standing (reference and master) data • Establish data ownership & accountabilities • Devolve responsibility and control as far as possible to data owners • Establish clear procedures for distribution of updates to standing data • Support routes (resolution of technical and business queries) 13

  14. Comments on detailed descriptions

  15. Load Total load per bidding zone per market time unit (6.1.a, 6.2.a) • “Actual” total load • Net generation: • Net or gross: net is suitable but use gross if high accuracy • Real-time measures (SCADA) + estimated dispersed generation • Real-time measurements are enough. No additional measures after H+1 • Storage resources: • Only significant storage resources to be provided • H+1 is obliged by the Regulation. In case of absence of measures, estimation is needed. 15

  16. Load Day-ahead forecast of the total load per market time unit (6.1.b, 6.2.b) • Market time unit harmonization not needed as data is per bidding zone • Replacement: • “The total load refers to the same definition as in Article 6.1.a.”; by • “The day-ahead forecast is calculated (estimated) on the historic load profile on similar days, taking into account the variables that affect electricity demand, such as weather conditions, climate and socioeconomic factors” • Need for national agreements between TSOs and DSOs regarding procurement of information to perform the forecast by TSOs. • Forecasts can be updated is weather conditions changes. 16

  17. Load Week-ahead total load forecast per day (6.1.c, 6.2.c) • Replacement: • “The total load refers to the same definition as in Article 6.1.a.”; by • “The week-ahead forecast is calculated (estimated) on the historic load profile on similar days, taking into account the variables that affect electricity demand, such as weather conditions, climate and socioeconomic factors” • Need for national agreements between TSOs and DSOs regarding procurement of information to perform the forecast by TSOs. • Forecasts can be updated is weather conditions changes. 17

  18. Load Month-ahead total load forecast per week (6.1.d, 6.2.d) • Replacement: • “The total load refers to the same definition as in Article 6.1.a.”; by • “The month-ahead forecast is calculated (estimated) on the historic load profile on similar days.” • Need for national agreements between TSOs and DSOs regarding procurement of information to perform the forecast by TSOs. • Forecasts are not influenced by weather conditions as it is long-term forecast. 18

  19. Load Year-ahead total load forecast per week (6.1.e, 6.2.e) • Replacement: • “The total load refers to the same definition as in Article 6.1.a.”; by • “The year-ahead forecast is calculated (estimated) on the historic load profile on similar days.” • “Rolling year” consistency. • Need for national agreements between TSOs and DSOs regarding procurement of information to perform the forecast by TSOs. • Forecasts are not influenced by weather conditions as it is long-term forecast. 19

  20. Load Planned unavailability of consumption units and Actual availability of consumption units (7.1.a,b, 7.2, 7.3) • Reason for the unavailability have to be clearly defined. To be checked with generation unavailability. • Decision time reporting seems to be needed for monitoring purposes under Transparency Regulation and REMIT. • Replacement of “DP” by “Data Provider” • Need for national agreements between TSOs, DSOs and consumers to report unavailability. • Immediately publication: EMFIP will support it, being “immediately” understood in terms of information systems (probably seconds). 20

  21. Load Year-aheadforecastmargin(8.1, 8.2) • Deletion of "Total load is defined as in Section 2.“ • Only one value will be provided per year. • TSOs are also Primary Owner of the “calculated” data. • Updates of this data: not clear. To be discussed. • No, as it is a year-ahead forecast (recommended). • Yes, as it can change during the year. 21

  22. Generation - Objective of the document Main points raised in the comments received need to be discussed General comments UMM and unavailabilities Production type Criteria for data provider Master data Kind of filing rate of water reservoir and hydro storage plant to be reported 22

  23. Generation – General Comments • Comments on the content and the wording of the regulation • No modification of the regulation is possible. All the comments made on the regulation are rejected. • Location • 2 kind of proposal for describing the location: • GPS coordinates • Country, Town … : lower level of precision • 2 questions to define the relevant level of description: • What is the additional value for the market to know exactly the location of the generation/production unit? • Is there strategic defence restriction which apply for this information ? • =>To be discussed 23

  24. Generation - UMM and Unavailabilities • List of reason for unavailabilities • A Predefined was first drafted in the data description: • maintenance • failure (permitted for changes in actual availability only) • shutdown (permitted for Consumption, Generation and Production Units only) • other • Additional list suggested: • Outage, External factors, redispatch • to be completed • => to be discussed • Change in actual availabilities and unplanned unavailabilities in the same document • In the data description ENTSO-E already suggested to have only one document. • If the actual unavailability have been planned and already reported with the correct available • capacity, it’s not necessary to deliver again the data. • But it is still in discussion inside ENTSO-E • => To be discussed 24

  25. Generation – UMM and Unavailabilities • Free Text for UMM • 2 different requirement for the UMM : REMIT and the draft Transparency regulation • 2 proposal on 2 different levels could be used for publishing open comments • 1) On the unavalaibilities required by the regulation: • The text is related to an outage with a specific period covered • 2) Outside any outage • The text is an open comment not linked directly with an outage. • =>To be discussed • No aggregation for unavailabilities • It was suggested to make aggregation on the unavailabilities (per control area or per • production type) • This aggregation is not required by the regulation. • => Comment rejected 25

  26. Generation - UMM and Unavailabilities • Decision taken to be defined? • In the regulation a planned unavailability is published as soon as possible, but no later than one hour after the decision regarding the planned unavailability is made.” • Some comments suggested to define the decision • Is it necessary to define clearly what is a decision? • =>To be discussed • Example of interval pattern mode • In the data description it is mentioned thatIn some cases, if an unavailability is repeated • several times it could be described with an interval pattern mode.  • For an outage on a generation unit whichisunavailableevery Friday for one year, This outagecouldbe • described in only one document, The periodcovered by the document willbe one year, and the unavailability • of everyfridaywillbedescribed. • It willbeclearlyexplained in the BRS and IG. • =>To be discussion when the BRS will be presented 26

  27. Production Type • Proposal to replace production type by fuel type: rejected • No modification of the regulation is possible. All the comments made on the regulation are rejected. • Proposal received for the production types • To be discussed • Primary owner of data • Owner of production units or operators of production units? • =>To be discussed 27

  28. Criteria for being data provider • Question raised in the comment • Data provider have to belong to the area of the data concerned • => to be discussed 28

  29. Master Data • Which master data to be used in EMFIP • One comment raised that the production name , the install capacity for a generation unit… is not needed to be reported each time if it is a master data • This question is still open in ENTSO-E. It involves lots of questions: • - legal issues : who is responsible for the data, What kind of validation is required from EMFIP • - how to manage the data, • - if some master data are not previously recorded in EMFIP, some data sent could be rejected • -… • To be discussed when the BRS will be introduced 29

  30. Kind of filing rate of water reservoir and hydro storage plant to be reported • Question raised in the comment • What kind of water reservoir and hydro storage to be reported • Proposal from Eurelectric: refer to UNIPED definition 30

  31. Transmission section 31

  32. Transmission section 32

  33. Transmission section 33

  34. Transmission section 34

  35. Transmission section 35

  36. Transmission section 36

  37. Transmission section 37

  38. Balancing • FinalisedBalancing Network Code will be used as basis for terms and definition. • Rules on balancing should be published by TSOs. • All balancing data should be sent by TSOs or Market Operators (primary owners). Market participants (generators, consumers) don’t have to send such data. • Bilateral balancing contracts should be handled the same way as other balancing contracts. • According to the regulation, cross control area balancing and international assistance between TSOs shouldn’t be distinguished only under point 17.1.j and 17.2.i 38

  39. Coffee time

  40. Feedback on data provider technical and operational criteria

  41. Feedback on data provider technical and operational criteria (1) • Technical criteria for data providers: • Communication shall be done by using MADES, web services, SFTP (reference to the detail descriptions) • Information exchange must be done in accordance with formats defined in Implementation Guide (EDI library) • Data provider should be capable to resend data 41

  42. Feedback on data provider technical and operational criteria (1) • Operational criteria for data providers: • Approval by local TSO is needed • Prequalification period is recommended. Prequalification should be done by using EMFIP test platform • Audit by local TSO • Communication in English • Data providers and TSOs should nominate Single Point of Contact (SPoC) for all data related issues. • Market participants should collaborate with TSO in defining data providers for EMFIP in a way to ensure cost efficiency, optimize data flow, avoid duplication of tasks and data flows. Data providers should provide data for substantial (not less than1/3) part of the local market. • The number of data providers for EMFIP should not exceed 200 (this 200 should be proved in “The Proposal concerning the operation of the central information transparency platform and the associated costs”). • Generation units, production units and consumption units should send data to the EMFIP via the local TSO or other data provider approved by the local TSO. The number of data providers to the EMFIP shall be limited and optimised. 42

  43. Monitoring of Local Projects Data providers • ENTSO-E collects information about Local Projects via TSOs • Local projects – on Data provider side • Local Monitoring Dashboard (LMD): • Identified Data providers for each Data item; • Status of the project on Data provider side; • Date, when data is expected to be ready for submission • SPOCs of TSOs (TPCs) provide necessary info for LMD; • Close dialog between TSO and Data provider is needed • Information flow from Data owner to the New TP • has to be defined Aggregators Aggregators Aggregators Aggregators Aggregators GenCo’s Aggregators Aggregators Aggregators Aggregators Aggregators DSOs Aggregators Aggregators Aggregators Aggregators Aggregators PXs, AOs, CAs New TP Aggregators Aggregators Aggregators Aggregators Aggregators TSOs Aggregators Aggregators Aggregators Aggregators Aggregators Aggregators 43

  44. Coffee time

  45. Feedback on Production types • Required in the manual of procedure • To be specified by ENTSO-E • Reviewed by ACER • ENTSO-E approach: • Our goal is to keep it simple • The information must be useful for the market (fuel type vs technology type) • Possible use of existing lists or for coherency in other reporting (e.g. statistical reporting, REMIT…) • List to be clarified and discussed in further meetings • EC • Should not be too detailed but also not too simplistic. • Reasonable mixture between generation technology and fuel. E.g. It is not enough to determine that it is a thermal generation. People would want to know whether it is lignite fired, coal fired or gas fired or fuel oil fired. This would have to be combined with the technologies used. Combined cycle, open cycle, boiler, etc. • An additional indication of CHP may also be interesting 45

  46. What do existing ENTSO-E publications have? • Thermal Nuclear • Fossil • Lignite • Hard coal • Gas • Oil • Mixed fuel • Hydro • Run of River • Storage and pump storage • Renewable • Non Renewable • Other Renewable • Wind onshore • Wind offshore • Solar • Biomass • Not identifiable Existing data in ENTSO-E statistical publications Not detailedenough?? 46

  47. What standards are already published? EECS Rules Fact Sheet 5 TYPES OF ENERGY INPUTS AND TECHNOLOGIES: Technology Toodetailed? 47

  48. What standards are already published? EECS Rules Fact Sheet 5 TYPES OF ENERGY INPUTS AND TECHNOLOGIES: Fuel Type Toodetailed? 48

  49. What is required under REMIT? What will be the requirements under REMIT for UMM (outages)? The ACER Guidance notes (2nd edition, 28 Sept) include the following Annex: 49

  50. A balanced approach 50

More Related