Standardisation of Electronic Data Interchange among Market Players and System operator. Nisheeth Singh, ETRANS Ltd.

Transcription

1 Standardisation of Electronic Data Interchange among Market Players and System operator. Nisheeth Singh, ETRANS Ltd. 1

2 Presentation Agenda Organisation of European Electricity Scene Need for harmonization Role Model and Modeling methodology Standardization achieved so far ETSO Identification code EIC ETSO Scheduling System ESS ETSO Settlement process ESP Work in progress ETSO Reserve Resource Planning ERRP ETSO Capacity Allocation Planning ECAP 2

3 Same quality of power Different Interfaces 3

4 ETSO European Transmission System Operators Information Interchange Standardisation 4

5 The European Union countries have the same legal framework : The European Directive 92/96/EC Competition in generation Unbundling between generation, transmission and distribution Third party access to transmission networks Regulation Opening of the market 5

6 Key figures for the European Union Population : 456 Millions Production capacity : MW Gross electricity generation : Total : 2531 TWh Nuclear : 868 TWh Thermal : 1280 TWh Pumping : 24 TWh Renewable : 359 TWh 6

7 ETSO The European Transmission System Operators organisation Responsible for the TSO implementation of the European open electricity market in cooperation with European Commission Has established several Task Forces to improve information exchanges for the market and to establish common standards TF6 Information Systems has provided an Electronic Highway for TSO/TSO communication TF14 EDI (Electronic Data Interchange) is providing electronic document interchange standards 7

8 ETSO TF 14 The definition and documentation of the data interchange standards required to ensure the operational efficiency of the business processes that are within the scope of ETSO. TF created in the Spring 2001 Documents issued to date: ETSO Modelling Methodology - EMM Electricity Market Role Model ETSO Identification Coding Scheme EIC ETSO Scheduling System ESS Document ESS ETSO Settlement Process ESP Document EAR Work in Progress: ETSO Reserve Resource Process ERRP ETSO Capacity Allocation Process - ECAP 8

9 Why use ETSO standards? Harmonise business scenarios across Europe Easier introduction of new processes More automation and cost effectiveness Better coherence (Error tracking, faster validation, escalation procedures) Improved reliability 9

10 What exchanges are concerned? EDI between: TSO and TSO. TSO and market participants. TSO and DSOs. UCTE operational procedures 10

11 Associated organisations: The Harmonised Electricity Market Role Model

12 Consumer Meter 1..n Meter administrator operates and maintains Meter operator 0..1 Domains: green: dual responsibility Clear ETSO responsibility Red undefined Roles: Clear ETSO responsibility Blue EBix responsibility Business actor dual responsibility connects Role Model Grid operator Is operated by 1 Operates 1. Harmonisation of vocabulary Some control balance RWEnet areas are under another E-ON Seeland (island of and do not report to a RTE Copenhagen) higher control entity than Eltra? Bornholm (DK island the first Elia connected 2. to SE) Definition of terms Tennet belong to different REE control balance areas NGC but the same market Control entity 0..1 balance area 3. Identification of roles and domains UCTE interconnected group 1 Controlled by has 1..n Register 1..n Administrates 1..n 1..n administers meter information for Exchange metering point has 1..n Maintains meters 1..n Metering point Local metering point 0..n 0..n 1..n Meters 0..n Unit 1 Metering point administrator Contains Is composed of Functional group belong to 1..n 1 1..n Metering grid area Is composed of Market balance area 1..n RWEnet E-ON RTE Eltra Elia Tennet REE NGC Part of UCTE is composed of Control area 1..n manages 1..n is composed of (netted) control area exchange schedule (CAX) Control block manages n is composed of (Netted) control block exchange schedule (CBS) Is composed of n Coordination center zone manages 1..n 1..n control area operator Control block operator coordination center operator Production metering point Consumption metering point Balance group sends invoicing information to Controls financially operates (netted) inter area exchange schedule (CAX) (netted) inter block exchange schedule (CBS) Netted inter center exchange schedule (CCT) Billing agent Imbalance settlement responsible may be financially responsible for collects data from must have Sends metering information Market operator controls (netted) balance exchange schedule (CAX) Sends metered data Is balance responsible for Sends validated metered data Deals within declares constraints to Makes contracts with Reports schedules to sends schedules to Sends finalised schedules to provides bids to Provides capacity for Identification Functional domains Metered data collector Metered Data Responsible Metered data aggregator Trades externally with 1 sends schedules to System operator Receives capacity from Local market area Sends data to Balance responsible party sends schedule to Exchanges cross border capacity (CAS) Is composed of Trades internally with sends schedule to Germany Capacity market area Profile maintenance party obtains category profiles from Production responsible party provides available transfer capacity Facilitates Pyrennées (France-Spain) TenneT Auction England - Wales Allocated capacity area Market area Provides access to Supplies to Grid access provider may have grid usage contract with Consumption responsible party Is contracted with Is contracted with Balance supplier Trade responsible party 1 Transmission capacity allocator 1 Operates Operates RTE - RWE border Common capacity area CBT National area Certificate area Has a balance delivery contract with is contracted with has a firm energy contract with Nordpool ETSO CBT Nordpool France Germany Spain Dutch certificat market uses Party connected to the grid Identification Roles of actors Producer Identification geographical domains

13 Role definitions Balance responsible party A party that has a contract providing financial security and identifying balance responsibility with the Imbalance settlement responsible of the market balance area entitling the party to operate in the market. This is the only role allowing a party to buy or sell energy on a wholesale level. Balance supplier A party that markets the difference between actual metered energy consumption and the energy bought with firm energy contracts by the party connected to the grid. In addition the balance supplier markets any difference with the firm energy commitment [of the party connected to the grid] and the metered production. There is only one balance supplier for each metering point. 13

14 Domain definitions Market balance area A geographic area consisting of one or more metering grid areas with common market rules for which the settlement responsible party carries out a balance settlement and which has the same price for imbalance. Market area An area made up of one or more balance areas interconnected through AC or DC links. Trade is allowed between different balance areas with common market rules for trading across the interconnection. 14

15 ETSO Modelling Methodology - EMM for the automation of data interchange of business processes A 5 milestone process 15

16 Information flow approach different An actor Can have ROLES In the same process System operator Balance responsible party Imbalance settlement responsible Control block manager All Roles that are possible may be found in the ETSO Role Model Balance responsible schedule Allocated capacity schedule Control block area schedule Confirmation report Finalised schedule Regulation data Imbalance report Day ahead scheduling Intra day Transits System operation closure Metered data aggregation Imbalance settlement And he may exchange different types of document All documents use 100% compatible XML Schemas and DTDs 16

17 1. Identify Project for development Start Identify area for development S te p 1. Identify new development area Step 2. prepare project plan Milestone 1 Modify project plan No Project accepted? Yes Project approved fo r develo pment Prepare project plan 17

18 2. Define Scope Step 3. model project requirements Step 4. Outline scope within E TS O role model Model project requirements Milestone 2 Scope defined Outline scope Within ETSO role model 18

19 Model business processes 3. Define Business process Step 5. Model business processes Changes to role model yes submit changes Milestone 3 No Business process defined yes Changes accepted? No Step 6. Analyse information requirements A dapt scope to m odifications 19

20 4. Define information requirements Analyse information requirements Milestone 4 Step 6. Analyse information requirements Info rm a tion requirements defined Adapt scope to m odifications Create class diagram All class attributes are mandatory or conditional. For conditional attributes a dependency matrix is mandatory 20

21 5. Approve implementation guide Step 7. Generate XML information model Generate information model Milestone 5 Step 8. Produce implementation guide implementation guide approved Produce implementation guide end 21

22 ETSO Modelling Methodology - EMM for the automation of data interchange of business processes 10 rules to transform UML class diagrammes to XML 22

23 RULE 1: For each UML class name and UML attribute name make the first letter of each word an uppercase letter. All other letters in the word shall be in lowercase. Each word shall then be concatenated together to form the XML name Schedule Message Message identification Message version Message type Process type Schedule classification type Sender identification - Coding scheme Sender role Receiver identification - Coding scheme Receiver role Message date and time Schedule time interval ScheduleMessage MessageIdentification 0..n Schedule time series Senders time series identification Senders time series version Business type Product Object aggregation In area - Coding scheme Out area - Coding scheme Metering point identification - Coding scheme In pa rty - Coding s cheme Out party- Coding scheme Ca pac ity contra ct type Capacity agreement identification Measurement unit ScheduleTimeSeries BusinessType 23

24 RULE 2: A UML class shall be represented as an aggregated XML element. It shall contain all immediately dependent classes Schedule Message Message identification Message version Message type Process type Schedule classification type Sender identification - Coding scheme Sender role Receiver identification - Coding scheme Receiver role Message date and time Schedule time interval 0..n Schedule time series Senders time series identification Senders time series version Business type Product Object aggregation In area - Coding scheme Out area - Coding scheme Metering point identification - Coding scheme In pa rty - Coding s cheme Out party- Coding scheme Ca pac ity contra ct type Capacity agreement identification Measurement unit ScheduleMessage (MessageIdentification, MessageVersion, MessageType, ProcessType, ScheduleClassificationType, SenderIdentification, SenderRole, ReceiverIdentification, ReceiverRole, MessageDateAndTime, ScheduleTimeInterval, ScheduleTimeSeries*) 24

25 RULE 3: A UML attribute shall be represented as an empty XML element that has one XML attribute called v (for value). Schedule Message Message identification Message version Message type Process type Schedule classification type Sender identification - Coding scheme Sender role Receiver identification - Coding scheme Receiver role Message date and time Schedule time interval 0..n Schedule time series Senders time series identification Senders time series version Business type Product Object aggregation In area - Coding scheme Out area - Coding scheme Metering point identification - Coding scheme In pa rty - Coding s cheme Out party- Coding scheme Ca pac ity contra ct type Capacity agreement identification Measurement unit <!ELEMENT MessageIdentification EMPTY> <!ATTLIST MessageIdentification v CDATA #REQUIRED> 25

26 RULE 4: If there is meta data associated with the UML attribute (e.g. a coding scheme) then this shall be represented as an additional attribute within the XML element. Schedule Message Message identification Message version Message type Process type Schedule classification type Sender identification - Coding scheme Sender role Receiver identification - Coding scheme Receiver role Message date and time Schedule time interval 0..n Schedule time series Senders time series identification Senders time series version Business type Product Object aggregation In area - Coding scheme Out area - Coding scheme Metering point identification - Coding scheme In pa rty - Coding s cheme Out party- Coding scheme Ca pac ity contra ct type Capacity agreement identification Measurement unit <!ELEMENT SenderIdentification EMPTY> <!ATTLIST SenderIdentification v CDATA #REQUIRED codingscheme CDATA #REQUIRED> 26

27 RULE 5: Attribute names shall have the first letter of the name in lowercase only. Schedule Message Message identification Message version Message type Process type Schedule classification type Sender identification - Coding scheme Sender role Receiver identification - Coding scheme Receiver role Message date and time Schedule time interval First letter lowercase 0..n Schedule time series Senders time series identification Senders time series version Business type Product Object aggregation In area - Coding scheme Out area - Coding scheme Metering point identification - Coding scheme In pa rty - Coding s cheme Out party- Coding scheme Ca pac ity contra ct type Capacity agreement identification Measurement unit <!ELEMENT SenderIdentification EMPTY> <!ATTLIST SenderIdentification v CDATA #REQUIRED codingscheme CDATA #REQUIRED> Note: Second word first letter put to uppercase 27

28 RULE 6: All associations shall be unidirectional and shall only provide cardinality information for dependent classes and Role information if a generic class is being referenced. Schedule Message Message identification Message version Message type Process type Schedule classification type Sender identification - Coding scheme Sender role Receiver identification - Coding scheme Receiver role Message date and time Schedule time interval 0..n Schedule time series Senders time series identification Senders time series version Business type Product Object aggregation In area - Coding scheme Out area - Coding scheme Metering point identification - Coding scheme In pa rty - Coding s cheme Out party- Coding scheme Ca pac ity contra ct type Capacity agreement identification Measurement unit Document Document Has a producer Has a consumer An association cannot have a name that provides additional semantics to the dependant class. An association class is not permitted. Party Connected To Grid Producer Party 1:1 Connected Consumer 1:1 To Grid The class identification concatenated with the role has to provide the semantics: ProducerPartyConnectedToGrid ConsumerPartyConnectedToGrid 28

29 RULE 7: The cardinality of a dependent class shall be expressed at the XML aggregate level with the relevant XML syntax for cardinality (I.e. for DTDs + (required and repeatable); * (conditional and repeatable)). Schedule Message Message identification Message version Message type Process type Schedule classification type Sender identification - Coding scheme Sender role Receiver identification - Coding scheme Receiver role Message date and time Schedule time interval 0..n Schedule time series Senders time series identification Senders time series version Business type Product Object aggregation In area - Coding scheme Out area - Coding scheme Metering point identification - Coding scheme In pa rty - Coding s cheme Out party- Coding scheme Ca pac ity contra ct type Capacity agreement identification Measurement unit ScheduleMessage (MessageIdentification, MessageVersion, MessageType, ProcessType, ScheduleClassificationType, SenderIdentification, SenderRole, ReceiverIdentification, ReceiverRole, MessageDateAndTime, ScheduleTimeInterval, ScheduleTimeSeries*) 29

30 RULE 8: Aggregate and non-aggregate XML elements may have a conditional qualifier? (Conditional, zero or one) associated with it. Schedule Message Message identification Message version Message type Process type Schedule classification type Sender identification - Coding scheme Sender role Receiver identification - Coding scheme Receiver role Message date and time Schedule time interval 0..n Schedule time series Senders time series identification Senders time series version Business type Product Object aggregation In are a - Coding scheme Out area - Coding scheme Metering point identification - Coding scheme In party - Coding scheme Out party- Coding scheme Ca pac ity contra ct type Capacity agreement identification Measurement unit 1 Period TimeInterval Resolution 0..1 Reason Reason code Reason text The period cardinality is fixed at one for the schedule message All time periods Dependent be transmit attributes ScheduleTimeSeries (SendersTimeSeriesIdentification, SendersTimeSeriesVersion, BusinessType, Product, ObjectAggregationType, InArea?, OutArea?, MeteringPointIdentification?, InParty?, OutParty?, CapacityContractType?, CapacityAgreementIdentification?, MeasurementUnit, Period, Reason?) (described with dependency matrixes) or classes 30

31 RULE 9: The preferred XML syntax structure is the Schema. RULE 10: A compatible XML DTD shall be derived from the Schema making use of Schedule Message the ETSO core component library. Message identification Message version Message type Process type Schedule classification type Sender identification - Coding scheme Sender role Receiver identification - Coding scheme Receiver role Message date and time Schedule time interval 0..n Schedule time series Senders time series identification Senders time series version Business type Product Object aggregation In area - Coding scheme Out area - Coding scheme Metering point identification - Coding scheme In pa rty - Coding s cheme Out party- Coding scheme Ca pac ity contra ct type Capacity agreement identification Measurement unit <!ELEMENT ScheduleMessage (MessageIdentification, MessageVersion, MessageType, ProcessType, ScheduleClassificationType, SenderIdentification, SenderRole, ReceiverIdentification, ReceiverRole, MessageDateAndTime, ScheduleTimeInterval, ScheduleTimeSeries*)> <xsd:element name= ScheduleMessage > <xsd:sequence> <xsd:element name= MessageIdentification type= ecc:identificationtype /> <xsd:element name= MessageVersion type= ecc:versiontype /> <xsd:element name= MessageType type= ecc:messagetype />.... <xsd:element ref= ScheduleTimeSeries minoccurs= 0 maxoccurs= unbounded />.. 31

32 EIC Energy Identification Code 32

33 EIC System Codification scheme under ETSO responsibility Assignment and management of the codes shall be carried out by ETSO approved issuing offices. Each issuing office is assigned a 2 character identification code An issuing office will assign codes to any recognised energy organisation who respect a minimum set of requirements. ETSO will assign TSO identification codes and area codes used in inter TSO data interchange 33

34 Issuing Office EIC Type of code (Party, area, meter) Check character Issuing Offices (as of February 2003) AA X ABCDEFGHIJKL 10: ETSO C Fixed length of 16 characters Examples: 10XELTRA T 10X M 11: VDN 12: ETRANS 13: A&B 14: APCS Identification 15: Mavir 16: REN 18: REE 34

35 EIC - ETSO Identification scheme ETSO Steering committee recommends that all parties in the electricity market are identified either by the EAN or the EIC coding scheme In future we shall only have these two schemes instead of a coding scheme per country as today This will result in less errors in data interchange EIC will soon substitute the present DVG coding scheme in Germany, Austria, Luxembourg and Switzerland Other countries will follow when they introduce the new scheduling system 35

36 Producer looking to play on the market How it works step by step Fill out code request Submit code request Request Issuing office Inform requestor of allocated code Allocate code Verify request Local database Inform ETSO ETSO Centralised database 36

37 Issuing office responsibilities Ensure that allocated codes are stable over time. Provide the following minimum services: Verify in the centralized website database that a company has not already been allocated a code Ensure that only one EIC code is allocated to an organisational function or entity. Capture all the standard details concerning a party Supply all allocated codes and the standard information to the centralized website database. Manage the local code list (inquiry, suspension and modification). 37

38 To become an issuing office Each country TSO or European association, which directly or indirectly is a part of the European internal market for energy, can have an EIC issuing office. The issuing office can either be a separate legal body or a part of an existing body. To qualify as an issuing office the applicant must issue an application to the ETSO secretary general describing: Name and address of the legal body Documentation of EIC being required either according to the national legislation, market rules or by a majority of the market participants 38

39 10 ETSO Central Issuing Office 11 VDN German Issuing Office 12 ETRANS Swiss Issuing Office 13 A+B Austrian Issuing Office 14 APCS Austrian Issuing Office 15 MAVIR Hungarian Issuing Office 16 REN Portuguese Issuing Office 17 RTE French Issuing Office 18 REE Spanish Issuing Office 19 PSE Polish Issuing Office 20 CEGEDEL Luxembourg Issuing Office 21 EDIGAS Gas Industry Issuing Office 22 ELIA Belgian Issuing Office 23 EFET Trader association Issuing Office 24 SEPS Slovakian Issuing Office 26 GRTN Italian Issuing Office 27 CEPS Czech Republic Issuing Office 28 ELES Slovenian Issuing Office 29 DESMIE Greek Issuing Office Local Issuing Offices for EIC 30 TRANSELECTRICA Romanian Issuing Office 31 HEP Croatian Issuing Office * 32 NEK Bulgarian Issuing Office 33 MEPSO Issuing Office of FYROM 34 EPS Serbian Issuing Office * 35 EPCG Montenegrian Issuing Office * = opening soon Update

40 ESS ETSO Scheduling System 40

41 ESS business process Day ahead or intra-day schedules sent by BRPs to TSO ESS After cutoff TSO informs each BRP of schedules that will be taken into consideration Acknowledgement TSO Matching takes place Anomaly report CUT-OFF TSO acknowledges each schedule received Acknowledgement Anomaly report ESS If mismatches TSO may inform both BRPs of problem to be resolved BRP1 Confirmation report Confirmation report BRP2 TSO: Transmission System Operator 41 BRP: Balance Responsible Party

42 ESS - XML implementation Day ahead or intra day schedules Acknowledgment Anomaly report Confirmation report Based on a core component repository Respecting ebxml recommendations 100% compatible Schemas and DTDs 42

43 ETSO ESS Implementations Austria Germany Switzerland Luxembourg Hungary Poland Czech Republic (TSO-TSO) Slovakia (TSO TSO) France Slovenia (March 05) Croatia (in test) Romania (in test) 43 Update

44 ESP ETSO Settlement Process 44

45 Aggregation of Billing confirmation agent information by AREA and PARTY and regulation data Detailled meter information for the grid area by meter Aggregated billing information by BRP EAR ESP business process DSO Aggregated and adjusted meter information by BRP for the area??? ETSO Settlement Process Scope Detailled meter information by BRP and meter EAR Aggregated meter data, schedules, regulation data and deviations by BRP MDA??? EAR ISR EAR ESS TSO Detailled schedule information by IN and OUT PARTY and AREA sent using ESS procedure Confirmation Report BRP TSO: Transmission System Operator BRP: Balance Responsible Party DSO: Distribution System Operator MDA: Meter Data Aggregator ISR: Imbalance Settlement Responsible 45

46 ESP - XML implementation Energy Account schedules Confirmed schedules Regulation data Settlement Accounting point data Acknowledgment Based on a core component repository Respecting ebxml recommendations 100% compatible Schemas and DTDs 46

47 The ESS shall be the core of The ETSO System Operation Exchange Standard ESOES ESOES will be developed by ETSO/UCTE 47

48 ETSO TF14 Work in progress ETSO Reserve Resource Planning ERRP Run in synergy with the BM TF To provide the infrastructure to enable the provision of the daily reserve resource planning requirements (Primary, Secondary and Tertiary reserves). ETSO Capacity Allocation Process ECAP Run in synergy with the NACM TF To provide a generic model for the data exchange between the Transmission Capacity Allocator, the TSOs and the various market players participating in the capacity market for cross border scheduling 48

49 Thank You 49