fskar transparency reporting...93 acknowledgement business process and contextual model for cim...

European Network of Transmission System Operators

for Electricity

ENTSO-E AISBL • Avenue de Cortenbergh, 100 • 1000 Brussels • Belgium • Tel +32 2 741 09 50 • Fax +32 2 741 09 51 • [email protected] • www.entsoe.eu

FSKAR TRANSPARENCY

REPORTING

IMPLEMENTATION GUIDE

2019-09-10

APPROVED DOCUMENT VERSION 1.0

– of 17 –

European Network of Transmission System Operators for Electricity

FSKAR Transparency Reporting IG Version 1.0


1

– of 17 –




Copyright notice: 2

Copyright © ENTSO-E. All Rights Reserved. 3

This document and its whole translations may be copied and furnished to others, and derivative 4 works that comment on or otherwise explain it or assist in its implementation may be prepared, 5 copied, published and distributed, in whole or in part, without restriction of any kind, provided 6 that the above copyright notice and this paragraph are included on all such copies and 7 derivative works. However, this document itself may not be modified in any way, except for 8 literal and whole translation into languages other than English and under all circumstances, the 9 copyright notice or references to ENTSO-E may not be removed. 10

This document and the information contained herein is provided on an "as is" basis. 11

ENTSO-E DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 12 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 13 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 14 FITNESS FOR A PARTICULAR PURPOSE. 15

This document is maintained by the ENTSO-E CIM EG. Comments or remarks are to be 16 provided at [email protected] 17

NOTE CONCERNING WORDING USED IN THIS DOCUMENT 18

The force of the following words is modified by the requirement level of the document in which 19 they are used. 20

• SHALL: This word, or the terms “REQUIRED” or “MUST”, means that the definition is an 21 absolute requirement of the specification. 22

• SHALL NOT: This phrase, or the phrase “MUST NOT”, means that the definition is an 23 absolute prohibition of the specification. 24

• SHOULD: This word, or the adjective “RECOMMENDED”, means that there may exist valid 25 reasons in particular circumstances to ignore a particular item, but the full implications must 26 be understood and carefully weighed before choosing a different course. 27

• SHOULD NOT: This phrase, or the phrase “NOT RECOMMENDED”, means that there may 28 exist valid reasons in particular circumstances when the particular behaviour is acceptable 29 or even useful, but the full implications should be understood and the case carefully weighed 30 before implementing any behaviour described with this label. 31

• MAY: This word, or the adjective “OPTIONAL”, means that an item is truly optional. 32

33

mailto:[email protected]

– of 17 –




Revision History 34

Version Release Date Paragraph Comments

0 1 2019-07-18 First draft

1 0 2019-09-10 Approved by MC.

– of 17 –




CONTENTS 35

COPYRIGHT NOTICE: ....................................................................................................... 3 36

REVISION HISTORY ......................................................................................................... 4 37

CONTENTS ..................................................................................................................... 5 38

1 OBJECTIVE AND SCOPE .............................................................................................. 6 39

2 REFERENCES ............................................................................................................. 6 40

2.1 NORMATIVE REFERENCES ............................................................................................. 6 41

2.2 OTHER REFERENCES .................................................................................................... 6 42

3 TERMS AND DEFINITIONS .......................................................................................... 8 43

4 THE FSKAR TRANSPARENCY REPORTING BUSINESS PROCESS......................................... 9 44

4.1 OVERVIEW ............................................................................................................... 9 45

4.2 USE CASES ............................................................................................................... 9 46

4.3 DOCUMENT EXCHANGE PROCESSES................................................................................ 11 47

4.3.1 OVERVIEW ................................................................................................................... 11 48

5 GENERAL RULES FOR DOCUMENT EXCHANGE ............................................................ 12 49

5.1 OVERVIEW ............................................................................................................. 12 50

5.2 ENERGYACCOUNT_MARKETDOCUMENT GENERAL OVERVIEW .............................................. 13 51

5.3 BALANCING_MARKETDOCUMENT GENERAL OVERVIEW ...................................................... 15 52

53

List of figures 54

FIGURE 1 - USE CASES ..................................................................................................... 9 55

FIGURE 2 - SEQUENCE DIAGRAM FOR FSKAR .................................................................. 11 56

57

List of tables 58

TABLE 1 - ACTOR LABELS AND DESCRIPTIONS ................................................................. 10 59

TABLE 2 - FSKAR TRANSPARENCY REPORTING USE CASES ................................................ 10 60

61

62

63

– of 17 –




1 Objective and Scope 64

This implementation guide serves as a basis for enabling the sharing of data between TSOs 65 and ENTSO-E for transparency purposes. The business motivation for this is contained in EB 66 GL articles 50.3 and 51 (1). These articles together with the business requirement specification 67 document address the data exchanges for Financial Settlement of KΔf, ACE and ramping period 68 (FSKAR). 69

The main objectives of the implementation guide are as follows 70

• To facilitate the harmonisation of the underlying data exchange process for FSKAR. 71

• To ensure a standard for enabling uniform layout for the transmission of FSKAR data 72 between the European electricity market participants and the Transparency platform 73

• By using the information model, ensure that a common interface can be provided 74 between different software solutions. 75

• To serve as one of the building blocks for using Unified Modelling Language (UML) 76 based techniques in defining processes and documents for interchange between actors 77 in the electrical industry in Europe. 78

Specifically, it covers settlement volumes, values and prices as a result of the processes 79 foreseen in FSKAR. 80

81

2 References 82

2.1 Normative references 83

The following documents, in whole or in part, are normatively referenced in this document and 84 are indispensable for its application. For dated references, only the edition cit ed applies. For 85 undated references, the latest edition of the referenced document (including any amendments) 86 applies. 87

• IEC 62325-351:2016, Framework for energy market communications – Part 351: CIM 88 European market model exchange profile. 89

• IEC 62325-450:2013, Framework for energy market communications – Part 450: Profile 90 and context modelling rules. 91

• IEC 62325-451-1:2017, Framework for energy market communications – Part 451-1: 92 Acknowledgement business process and contextual model for CIM European market . 93

• IEC 62325-451-4:2017, Framework for energy market communications - Part 451-4: 94 Settlement and reconciliation business process, contextual and assembly models for 95 European market. 96

• IEC 62325-451-6:2018 Framework for energy market communications - Part 451-6: 97 Publication of information on market, contextual and assembly models for European-98 style markets 99

100

2.2 Other references 101

• EB GL - The EU Commission regulation 2017/2195 of 23 rd November 2017 establishing 102 a guideline on electricity balancing. EB GL articles 50.3 and 51 (1) 103

• The Harmonised Electricity Market Role Model 104

• Detailed Data Descriptions for the purpose of the FSKAR Transparency Reporting 105

https://webstore.iec.ch/publication/25128&preview=1






https://webstore.iec.ch/publication/29116







https://www.entsoe.eu/publications/electronic-data-interchange-edi-library/harmonised-electricity-role-model/

– of 17 –




• Business Requirements Specification for FSKAR Transparency Reporting 106

• All TSOs’ proposal for the determination of LFC blocks for the Synchronous Area 107 Continental Europe 108

https://consultations.entsoe.eu/system-operations/lfc-blocks_ce/supporting_documents/171129_LFC%20blocks%20determination%20Proposal%20Final_for%20public%20consultation.pdf





– of 17 –




3 Terms and definitions 109

ACE: Area Control Error. Means the sum of the power control error (‘ΔP’), that is the real -time 110 difference between the measured actual real time power interchange value (‘P’) and the control 111 program (‘P0’) of a specific LFC area or LFC block and the frequency control error (‘K*Δf’), that 112 is the product of the K-factor and the frequency deviation of that specific LFC area or LFC block, 113 where the area control error equals ΔP+K*Δf 114

BRS: Business requirement specification 115

CIM: Common Information Model, set of standards for modelling data exchanges in an electrical 116 utility enterprise developed under IEC TC 57. 117

EDI: Electronic data interchange 118

ESMP: European Style Market Profile 119

FSKAR: Financial Settlement of KΔf, ACE and ramping period 120

LFC: Load-Frequency Control. 121

LFC area: Means a part of a synchronous area or an entire synchronous area, physically 122 demarcated by points of measurement at interconnectors to other LFC areas, operated by one 123 or more TSOs fulfilling the obligations of load-frequency control. 124

LFC block: Means a part of a synchronous area or an entire synchronous area, physically 125 demarcated by points of measurement at interconnectors to other LFC blocks, consisting of one 126 or more LFC areas, operated by one or more TSOs fulfilling the obligations of load-frequency 127 control. 128

Synchronous Area: Means an area covered by synchronously interconnected TSOs, such as 129 the synchronous areas of Continental Europe, Great Britain, Ireland-Northern Ireland and 130 Nordic and the power systems of Lithuania, Latvia and Estonia, together referred to as ‘Baltic’ 131 which are part of a wider synchronous area (article 2(2) of the Commission Regulation (EU) 132 2016/631 of 14 April 2016 establishing a network code on requirements for grid connection of 133 generators). 134

TP: Transparency Platform 135

TSO: Transmission System Operator. 136

137

– of 17 –




4 The FSKAR Transparency Reporting Business Process 138

4.1 Overview 139

The EU Commission regulation 2017/2195 of 23rd November 2017 (EB GL) establishes a 140 guideline on electricity balancing. It sets out technical, operational and market rules for the 141 electricity balancing markets. It covers the procurement, activation and financial settlements as 142 a result of balancing activities in the market. 143 144 Article 50.3 of this regulation indicates that TSOs shall develop a proposal for common 145 settlement rules for the intended exchanges of energy as a result of the frequency containment 146 process and ramping periods. Article 51(1) states a similar requirement for the uninte nded 147 exchanges of energy. 148 149 A detailed data definition document for exchange of settlement data between TSOs foreseen 150 by EB GL articles 50.3 and 51 (1) was produced. Following this, a Business requirement 151 specification (BRS) containing the different categories of information was also produced. The 152 categories of information submitted are listed below: 153 154

• Settlement of volumes and values for: 155

o Frequency containment energy 156

o Ramping period energy 157

o Unintended energy 158

• Settlement prices 159

160

4.2 Use Cases 161

The use case diagram below identifies the actors and their interactions. 162

163

164

Figure 1 - Use Cases 165 166

– of 17 –




167 Table 1 gives a list of actors involved in the FSKAR Transparency reporting. 168 169

Table 1 - Actor labels and descriptions 170 171

Actor Label Actor Description

Imbalance Settlement responsible The imbalance settlement responsible is tasked with gathering all the required settlement information by the SA, LFC area, LFC block or groups of LFC areas for submission to MIA.

Market information aggregator (MIA) MIA is the role that receives, validates and acknowledges all submitted information to TP. This role will be played by TP.

172 173 Table 2 gives a list of use cases for the FSKAR Transparency reporting. 174 175

Table 2 - FSKAR Transparency reporting use cases 176 177

Use case label Roles involved Action descriptions and assertions

Publish settlement volumes and values for the following energy exchange categories:

• Frequency Containment

• Ramping period

• Un-intended energy

• Imbalance settlement responsible

• MIA

Imbalance settlement responsible sends to the MIA, the exchanges of energy volumes and values. MIA acknowledges the received information.

Publish settlement prices: for the following energy exchange categories

• Frequency Containment

• Ramping period

• Un-intended energy

• Imbalance settlement responsible

• MIA

Imbalance settlement responsible sends to the MIA the settlement prices for energy exchanged. MIA acknowledges the received information.

178

– of 17 –




4.3 Document exchange processes 179

4.3.1 Overview 180

The use cases are supported by the following document exchanges between the Imbalance 181 settlement responsible and the MIA(TP) 182

• Publish settlement volumes and values data use case are supported by the 183 EnergyAccount_MarketDocument. The volumes and values published are for the exchange of 184 energy as a result of frequency containment process, ramping period and un-intended energy. 185 These are reported monthly per LFC area, and may alternatively be reported by LFC block 186 or group of LFC areas. 187

• Publish settlement prices data use case is supported by the 188 Balancing_MarketDocument. The prices are for frequency containment, ramping period 189 and unintended energy exchanges for a given Synchronous area. These are reported 190 monthly per synchronous area. 191

Next figures show a sequence diagram of the documents exchange processes. 192

193

194 195

Figure 2 - Sequence diagram for FSKAR 196 All documents sent by Imbalance settlement responsible will always get an Acknowledgement 197 message response from TP. 198

– of 17 –




5 General rules for document exchange 199

5.1 Overview 200

The document exchange processes of FSKAR Transparency Reporting described in the 201 previous chapter require sending and receiving various ESMP documents. The information to 202 be exchanged is based on the following documents: 203

• Balancing_MarketDocument v4.1 based on IEC 62325-451-6:2018 204

• EnergyAccount_MarketDocument 4.0 based on IEC 62325-451-4:2017 205

• Acknowledgement_MarketDocument v8.0 based on IEC 62325-451-1:2017 Ed. 2 206

207

These ESMP based documents shall be used to carry out the communication tasks 208 209

• Submit - The document contains data to be processed by the receiver. 210

• Reply - It is the acknowledgement sent by the receiver to the sender when receiving a 211 submitted document. 212

Next table gives an overview, which ESMP documents shall be used to carry out the 213 communication tasks of document exchange processes (DEP). The following abbreviations 214 apply 215

• BMD: Balancing_MarketDocument 216

• EAD: EnergyAccount_Marketdocument 217

• ACK: Acknowledgement_MarketDocument 218

219

Table 3 – Document Exchange 220 221

Number Use case Publish document

Reply document Reply conditions

1 Publish settlement volumes and values

EAD ACK EAD fully accepted. Fully rejected due to errors in the EAD.

2 Publish settlement prices

BMD ACK BMD fully accepted.

Fully rejected due to errors in the BMD.

222 223

224

225

– of 17 –




5.2 EnergyAccount_MarketDocument General Overview 226

Following table below shows a description of the different attributes and XSD requirements to 227 be used in the Publish settlement volumes and values use case and the XSD requirements 228 for each one of them. 229

Table 4. 1 EnergyAccount_Market Document 230

Class EnergyAccount_MarketDocument

Attributes Description

Settlement volumes and values

XSD requirements

EnergyAccount_MarketDocument

mRID

Unique identification of

the Energy Account market

Document

Used

Mandatory

revisionNumber

Identification of version that

distinguishes one version from another

Used

Mandatory

type The coded type of a

document

B38 = Settlement document Mandatory

docStatus Document

status A02=Final

Mandatory

process.processType

Identification of the nature of the process

that the document addresses

A57 = FSKAR settlement

Mandatory

process.ClassificationType Process type A01=Detail Mandatory

sender_MarketParticipant.mRID Sender id Used Mandatory

sender_MarketParticipant.marketRole.type Document

sender’s role type

A05: Imbalance settlement responsible Mandatory

receiver_MarketParticipant.mRID Document receiver’s id

Used Mandatory

receiver_MarketParticipant.marketRole.type Document

receiver’s role type

A32: Market Information Aggregator Mandatory

createdDateTime Date and time of document

creation

Used Mandatory

Period.timeInterval

The duration of the settlement period. Always equivalent to

calendar month

The month described by the document

Mandatory

domain.mRID EIC of the

region EIC of synchronous area

Conditional

Time Series

mRID Unique

identification of the time series

Used Mandatory

businessType Business type

A95=Frequency containment reserves

C07=Ramping management (Ramping period)

A44 =Compensation program (un-intended

energy) Mandatory

product Product 8716867000016 = Active power

Mandatory

– of 17 –




objectAggregation A01 = Area A01= Area Mandatory

231

Class EnergyAccount_MarketDocument


Settlement volumes and values

XSD requirements

Time Series

area_Domain.mRID

Area id corresponding to LFC area, LFC, block or group of LFC

areas

Used Mandatory

MarketParticipant.mRID

Identification of TSO

responsible for the area

Not used Conditional

marketAgreement.mRID Identification of the reserve

contract Not used Conditional

measure_Unit.name MWh =

Megawatts hours

MWH = Megawatt hours Mandatory

currency_Unit.name EUR = Euro EUR=Euro Mandatory

marketEvaluationPoint.mRID

Identification of an

accounting point

Not used Not used

Series period timeInterval month Month Mandatory

resolution PT15M PT15M Mandatory

Point

position Position within

the time interval

Used Mandatory

In_Quantity.quantity Quantity

going into an area

Used Conditional

If energy is imported

In_Quantity.quality Not used Not used Conditional

out_Quantity.quantity Quantity

going out of an area

Used Conditional

If energy is exported

Out_Quantity.quality Not used Not used Conditional

price.amount

Settlement amount. This

represents the total financial value for the

point in respect to the

time series businessType

. The value may be

negative.

Used

Mandatory

The attribute holds the value of the exchanged energy

232 233

Note: The in quantity and out quantity represent a netted value consequently one of the values 234 must always be equal to zero 235

236

– of 17 –




5.3 Balancing_MarketDocument General Overview 237

Following table shows a description of the different attributes in Balancing_MarketDocument 238 v4.1 to be used in the Publish settlement prices use case and the XSD requirements for each 239 one of them. 240

Table 5. 1 Balancing_Market Document General Overview 241

Class Balancing_MarketDocument

Attrributes Description Settlement prices XSD Requirements

mRID

Unique identification

of the Balancing

Market _Document

Used Mandatory

revisionNumber

Identification of version

that distinguishes one version from another

Used Mandatory

type The coded type of a document

A44=Price document

Mandatory

Balancing_MarketDocument process.processType

Identification of the nature

of the process that

the document addresses

A57 = FSKAR Settlement

Mandatory

sender.mRID Sender ID Used Mandatory

sender.roleType Document sender role

type

A05: Imbalance settlement responsible

Mandatory

receiver.mRID Receiver ID Used Mandatory

receiver.roleType Document

receiver role type

A32: Market Information Aggregator

Mandatory

createdDateTime

Date and time of

document creation

Used Mandatory

docstatus

Identification of condition

or position of a document

with regard to its standing

May be used Optional

Area_Domain.mRID Unique id of domain area

Synchronous area Mandatory

period.TimeInterval

Start and end date time of a given period

interval

The month described by the

document Mandatory

242 243

– of 17 –




244

Class Balancing Market_Document

Attributes Description Settlement prices XSD Requirements

TimeSeries

mRID Time series unique

id Used Mandatory

businessType Identification of the

nature of time series

A95= frequency containment reserves

Mandatory C07=Ramp

management

A44= Compensation programs (un-

intended )

acquiring_Domain.mRID Identification of the acquiring domain


connecting_Domain.mRID Identification of the connecting domain


type_MarketAgreement.type Not used Not used Conditional

mktPSRType.psrType Not used Not used Conditional

currency_Unit.name Currency EUR Mandatory

flowDirection.direction Not used Not used Conditional

Price_measure unit name MWH Not Used Conditional

standard_MarketProduct Not used Not used Conditional

original_MarketProduct Not used Not used Conditional

quantity_Measure_Unit.name Not used Not used Conditional

curveType

Identification of the coded

representation of type of curve

A01=Sequential fixed block

Conditional A03=Variable sized

block

cancelledTS Cancel Times

series

A01=Yes

Conditional Only populated in case data is cancelled

245 246

– of 17 –




247

Class Balancing_MarketDocument


Settlement prices

XSD Requirements

Series_Period timeInterval Month Month Mandatory

resolution Series resolution PT15M Mandatory

Point

position Position within the time interval Used Mandatory

quantity Not used Not used Conditional

secondaryQuantity Not used Not used Conditional

activation_Price.amount The price of the exchanged energy Used Mandatory

procurement_Price.amount Not used Not used Not used

minimum_Price.amount Not used Not used Conditional

maximum_Price.amount Not used Not used Conditional

imbalance_Price.amount Not used Not used Conditional

imbalance_Price.category Not used Not used Conditional

248 Note: The rest of the attributes in point class are optional and they are not used in this 249 business process. 250 251

fskar transparency reporting...93 acknowledgement business process and contextual model for cim...

Documents