ENTSO-E RG CE IMPLEMENTATION GUIDE · 105 Figure 4 – ENTSO-E RG CE schedule reporting process for compensation schedules ... 144 model::ReportingStatus_MarketDocument with other

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

1

ENTSO-E RG CE Schedule Reporting Process

IMPLEMENTATION GUIDE

2016-11-09

APPROVED DOCUMENT VERSION 2.0

– Page 2 of 58 –

European Network of Transmission System Operators for Electricity

ENTSO-E RG CE Schedule Reporting Process IMPLEMENTATION GUIDE VERSION 2.0


Copyright notice: 2

Copyright © ENTSO-E. All Rights Reserved. 3

This document and its whole translations may be copied and furnished to others, and 4 derivative works that comment on or otherwise explain it or assist in its implementation may 5 be prepared, copied, published and distributed, in whole or in part, without restriction of a ny 6 kind, provided that the above copyright notice and this paragraph are included on all such 7 copies and derivative works. However, this document itself may not be modified in any way, 8 except for literal and whole translation into languages other than Engl ish and under all 9 circumstances, the 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 RG CE-TF SPT with the support of WG 16 EDI. Comments or remarks are to be 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 26 shall be understood and carefully weighed before choosing a different cour se. 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 caref ully 30 weighed before implementing any behaviour described with this label. 31

MAY: This word, or the adjective “OPTIONAL”, means that an item is truly optional. One 32 vendor may choose to include the item because a particular marketplace requires it or 33 because the vendor feels that it enhances the product while another vendor may omit the 34 same item. An implementation which does not include a particular option SHALL be 35 prepared to interoperate with another implementation which does include the option, 36 though perhaps with reduced functionality. In the same vein an implementation which does 37 include a particular option SHALL be prepared to interoperate with another implementation 38 which does not include the option (except, of course, for the feature the option provides.) . 39

mailto:[email protected]

– Page 3 of 58 –




Revision History 40

Version Release Date Paragraph Comments

1 0 2010-09-08 Approval from ENTSO-E RG CE Plenary

1 1 2011-11-15 all Correction of mistypes Modifications for clarification (Revision History see V1R1)

2 0 2016-11-09 all

Revision of complete document, taking into account Guideline on Electricity Transmission System Operation and Operational Handbook Policy 2 XX/2015 Approved by the RGCE Plenary 2016-11-09

– Page 4 of 58 –




CONTENTS 41

Copyright notice: ..................................................................................................................... 2 42

Revision History ...................................................................................................................... 3 43

CONTENTS ............................................................................................................................ 4 44

INTRODUCTION ..................................................................................................................... 8 45

1 Scope .............................................................................................................................. 8 46

2 Normative references ...................................................................................................... 8 47

3 Terms and definitions ...................................................................................................... 9 48

4 The RG CE schedule reporting business process .......................................................... 12 49

4.1 Overall business context .................................................................................. 12 50

4.2 Schedule reporting process sequence .............................................................. 16 51

4.3 Business rules for the RG CE schedule reporting process ................................ 19 52

4.3.1 General rules .................................................................................. 19 53

4.3.2 Dependencies governing the Reporting_MarketDocument .............. 19 54

4.3.3 Dependencies governing the Reporting Status Market 55 Document ....................................................................................... 25 56

4.3.4 Dependencies governing the Reporting Information Market 57 Document ....................................................................................... 26 58

4.3.5 Generic rules and dependencies for the Status Request 59 Market Document ........................................................................... 27 60

5 Contextual and assembly models .................................................................................. 29 61

5.1 Reporting contextual model .............................................................................. 29 62

5.1.1 Overview of the model .................................................................... 29 63

5.1.2 IsBasedOn relationships from the European style market 64 profile ............................................................................................. 29 65

5.2 Reporting assembly model ............................................................................... 31 66



5.2.3 Detailed Reporting assembly model ................................................ 32 70

5.2.4 Datatypes ....................................................................................... 35 71

5.3 Reporting status contextual model ................................................................... 36 72



5.4 Reporting status assembly model ..................................................................... 38 76



5.4.3 Detailed Reporting status assembly model ..................................... 39 80

5.4.4 Datatypes ....................................................................................... 43 81

5.5 Reporting information contextual model ........................................................... 45 82



5.6 Reporting information assembly model ............................................................. 47 86


– Page 5 of 58 –





5.6.3 Detailed Reporting information assembly model .............................. 48 90

5.6.4 Datatypes ....................................................................................... 52 91

6 XML schema.................................................................................................................. 53 92

6.1 Schema structure ............................................................................................. 53 93

6.1.1 Reporting market document schema ............................................... 53 94

6.1.2 reporting status market document schema ...................................... 55 95

6.1.3 Reporting information market document .......................................... 57 96

6.2 Schema description ......................................................................................... 58 97

98

– Page 6 of 58 –




List of figures 99

Figure 1: The ENTSO-E RG CE schedule reporting process use case .................................. 13 100

Figure 2 – ENTSO-E RG CE schedule reporting process for aggregated netted 101 external market schedules .................................................................................................... 14 102

Figure 3 - ENTSO-E RG CE schedule reporting process for aggregated netted 103 external TSO schedules ........................................................................................................ 15 104

Figure 4 – ENTSO-E RG CE schedule reporting process for compensation schedules ......... 15 105

Figure 5 – Schedule reporting process sequence diagram for market schedules ................... 16 106

Figure 6 - Schedule reporting process sequence diagram for TSO schedules ....................... 16 107

Figure 7 – Schedule reporting process sequence diagram for compensation schedules ........ 16 108

Figure 8 - Schedule reporting process sequence diagram for reporting status requests 109 and replies ............................................................................................................................ 17 110

Figure 9 – Request examples ............................................................................................... 18 111

Figure 10 – Reporting contextual model ................................................................................ 29 112

Figure 11 – Reporting assembly model ................................................................................. 31 113

Figure 12 – Reporting status contextual model ..................................................................... 36 114

Figure 13 – Reporting status assembly model ....................................................................... 38 115

Figure 14 – Reporting information contextual model ............................................................. 45 116

Figure 15 – Reporting information assembly model ............................................................... 47 117

118

List of tables 119

Table 1 – Aggregated netted external market schedule dependency table ............................ 20 120

Table 2 – Aggregated netted external TSO schedule dependency table ................................ 21 121

Table 3 – Compensation program schedule dependency table .............................................. 23 122

Table 4 – Reporting status market document dependency table ............................................ 25 123

Table 5 – Reporting information market document dependency table .................................... 26 124

Table 6 – Mandatory attributes of Status request market document ...................................... 27 125

Table 7 – Status request market document dependency table ............................................... 28 126

Table 8 – IsBasedOn dependency ........................................................................................ 29 127

Table 9 – IsBasedOn dependency ........................................................................................ 32 128

Table 10 – Attributes of Reporting assembly model::Reporting_MarketDocument ................. 32 129

Table 11 – Association ends of Reporting assembly 130 model::Reporting_MarketDocument with other classes ......................................................... 33 131

Table 12 – Attributes of Reporting assembly model::Point ..................................................... 33 132

Table 13 – Attributes of Reporting assembly model::Series_Period ....................................... 33 133

Table 14 – Association ends of Reporting assembly model::Series_Period with other 134 classes ................................................................................................................................. 34 135

Table 15 – Attributes of Reporting assembly model::TimeSeries ........................................... 34 136

Table 16 – Association ends of Reporting assembly model::TimeSeries with other 137 classes ................................................................................................................................. 34 138

Table 17 – IsBasedOn dependency ....................................................................................... 36 139


Table 19 – Attributes of Reporting status assembly 141 model::ReportingStatus_MarketDocument ............................................................................ 39 142

– Page 7 of 58 –




Table 20 – Association ends of Reporting status assembly 143 model::ReportingStatus_MarketDocument with other classes ................................................ 40 144

Table 21 – Attributes of Reporting status assembly model::Point .......................................... 40 145

Table 22 – Association ends of Reporting status assembly model::Point with other 146 classes ................................................................................................................................. 40 147

Table 23 – Attributes of Reporting status assembly model::Reason ...................................... 41 148

Table 24 – Attributes of Reporting status assembly model::Series_Period ............................ 41 149

Table 25 – Association ends of Reporting status assembly model::Series_Period with 150 other classes ........................................................................................................................ 41 151

Table 26 – Attributes of Reporting status assembly model::TimeSeries ................................. 41 152

Table 27 – Association ends of Reporting status assembly model::TimeSeries with 153 other classes ........................................................................................................................ 43 154



Table 30 – Attributes of Reporting information assembly 157 model::ReportingInformation_MarketDocument ..................................................................... 48 158

Table 31 – Association ends of Reporting information assembly 159 model::ReportingInformation_MarketDocument with other classes ........................................ 49 160

Table 32 – Attributes of Reporting information assembly model::Point .................................. 50 161

Table 33 – Association ends of Reporting information assembly model::Point with other 162 classes ................................................................................................................................. 50 163

Table 34 – Attributes of Reporting information assembly model::Reason .............................. 50 164

Table 35 – Attributes of Reporting information assembly model::Series_Period .................... 50 165

Table 36 – Association ends of Reporting information assembly model::Series_Period 166 with other classes ................................................................................................................. 51 167

Table 37 – Attributes of Reporting information assembly model::TimeSeries ......................... 51 168

Table 38 – Association ends of Reporting information assembly model::TimeSeries 169 with other classes ................................................................................................................. 51 170

171

– Page 8 of 58 –




INTRODUCTION 172

This document was drafted based on IEC 62325 series. In particular, the IEC 62325-450 173 methodology was applied to develop the conceptual and assembly models. 174

1 Scope 175

To operate a large power system like the one of ENTSO-E Regional Group Continental 176 Europe (RG CE) and to create the suitable conditions for commercial electricity tr ade it is 177 necessary to schedule in advance the power to be exchanged at the interconnection borders 178 between the system operators. During daily operation, the schedules are followed by means 179 of the load frequency control installed in each load-frequency control area (LFC area) / load-180 frequency control block (LFC block). Notwithstanding load frequency control, unintentional 181 deviations invariably occur in energy exchanges. For this reason, it is necessary to coordinate 182 the schedule nomination between the system operators and to perform the verification 183 process to ensure that all aggregated netted external schedules within a synchronous area 184 sum up to zero. 185

The objective of this implementation guide is to make it possible for software vendors to 186 develop an IT application to enable the various ENTSO-E RG CE Operators (scheduling area, 187 LFC area, LFC block and coordination center zone) to report the schedule related information 188 for the areas that they manage to all interested parties within the ENTSO-E RG CE network. 189

The implementation guide is one of the building blocks for using UML (Unified Modelling 190 Language) based techniques in defining processes and documents for interchange between 191 the involved actors. 192

2 Normative references 193

The following documents, in whole or in part, are normatively referenced in this document and 194 are indispensable for its application. For dated references, only the edition cited applies. For 195 undated references, the latest edition of the referenced document (including any 196 amendments) applies. 197

IEC TS 61970-2, Energy management system application program interface (EMS-API) –Part 198 2: Glossary 199

IEC 62325-301, Framework for energy market communications – Part 301: Common 200 information model (CIM) extensions for markets 201

IEC 62325-351, Framework for energy market communications – Part 351: CIM European 202 market model exchange profile 203

IEC 62325-450, Framework for energy market communications – Part 450: Profile and context 204 modeling rules 205

IEC 62325-451-1, Framework for energy market communications – Part 451-1: 206 Acknowledgement business process and contextual model for CIM European market 207

IEC 62325-451-5, Framework for energy market communications – Part 451-5: Status request 208 business process and contextual model for CIM European market 209

The ENTSO-E RG CE Operation handbook policy 2 and glossary 210

The ENTSO-E RG CE System operator to system operator Implementation guide 211

The Guideline on Capacity Allocation and Congestion Management 212

The Guideline on electricity transmission System Operation 213

– Page 9 of 58 –




3 Terms and definitions 214

All definitions included in this document reflect the definitions from ENTSO-E– Metadata 215 Repository and latest versions of the guidelines that were available at the time of creation of 216 this document. After finalisation of the guidelines and adaptation of ENTSO-E– Metadata 217 Repository/Glossary the Definitions will be removed. 218

3.1 219 Aggregated netted external schedule 220 A schedule representing the netted aggregation of all external TSO schedules and external 221 commercial trade schedules between two scheduling areas or between a scheduling area and 222 a group of other scheduling areas. 223

3.2 224 Aggregated netted external market schedule 225 A schedule representing the netted aggregation of all external commercial trade schedules 226 between two scheduling areas or between a scheduling area and a group of other scheduling 227 areas; (replaces “summarised market schedules”). 228

3.3 229 Aggregated netted external TSO schedule 230 A schedule representing the netted aggregation of all external TSO schedules between two 231 scheduling areas or between a scheduling area and a group of other scheduling areas; 232 (replaces “timeframe independent schedules”). 233

3.4 234 Bidding zone 235 The largest geographical area within which market participants are able to exchange energy 236 without capacity allocation. 237

3.5 238 Compensation program schedule 239 A schedule representing the exchange of electricity of TSOs related to a compensation 240 program. 241

3.6 242 Control area 243 A coherent part of the interconnected system, operated by a single system operator and shall 244 include connected physical loads and/or generation units if any; 245

3.7 246 Load-frequency control area (LFC area) 247 A part of a synchronous area or an entire synchronous area, physically demarcated by points 248 of measurement of Interconnectors to other LFC areas, operated by one or more TSOs 249 fulfilling the obligations of load-frequency control. 250

3.8 251 Load-frequency control block (LFC block) 252 A part of a synchronous area or an entire synchronous area, physically demarcated by points 253 of measurement of Interconnectors to other LFC blocks, consisting of one or more LFC areas, 254 operated by one or more TSOs fulfilling the obligations of load-frequency control. 255

3.9 256 Coordination center zone 257 The composition of a number of load-frequency control blocks under the responsibility of the 258 same coordination center zone operator. 259

3.10 260 Load-frequency control area operator 261

Responsible for: 262

– Page 10 of 58 –




1. The coordination of exchange programs between its related scheduling areas and for the 263 exchanges between its associated load-frequency control areas. 264

2. The load frequency control for its own area. 265

3. The coordination of the correction of time deviations. 266

3.11 267 Load-frequency control block operator 268

Responsible for 269

1. The load frequency control within its own block and ensuring that its load-frequency control 270 areas respect their obligations in respect to load frequency control and time deviation. 271

2. The organisation of the settlement and/or compensation between its load-frequency control 272 areas. 273

3.12 274 Coordination center zone operator 275

Responsible for: 276

1. The coordination of exchange programs between its related load-frequency control blocks 277 and for the exchanges between its associated coordination center zones. 278

2. Ensuring that its load-frequency control blocks respect their obligations in respect to load 279 frequency control. 280

3. Calculating the time deviation in cooperation with the associated coordination centers 281

4. Carrying out the settlement and/or compensation between its load-frequency control blocks 282 and against the other coordination center zones. 283

3.13 284 Compensation program 285 The compensation of inadvertent deviations is performed by exporting to / importing from the 286 interconnected system during the compensation period by means of schedules of constant 287 power within the same tariff periods as when they occurred (COMP). 288

3.14 289 Domain 290 A delimited area that is uniquely identified for a specific purpose and where energy 291 consumption, production or trade may be determined. 292

3.15 293 External commercial trade schedule 294 A schedule representing the commercial exchange of electricity between Marke t Participants 295 in different scheduling areas. (replaces “market based cross border exchange schedules”) 296

3.16 297 External TSO schedule 298 A schedule representing the exchange of electricity of TSOs between different scheduling 299 areas. 300

3.17 301 Load frequency control 302

See 'Secondary control'. 303

3.18 304 Net position 305 The netted sum of electricity exports and imports for each market time unit for a bidding 306 zone.. 307

– Page 11 of 58 –




3.19 308 Netted area AC position 309

The netted aggregation of all AC external schedules of an area. (replaces ”control program”). 310

3.20 311 Netted area position 312 The netted aggregation of all AC and DC external schedules of an area. 313

3.21 314 Schedule 315 A reference set of values representing the generation, consumption or exchange of electricity 316 between actors for a given time period. 317

3.22 318 Scheduling area 319 An area within which the TSOs obligations regarding scheduling apply due to operational or 320 organisational needs. 321

3.23 322 Synchronous area 323 An area covered by synchronously interconnected TSOs such as the synchronous areas 324 continental Europe, Great Britain, Ireland - Northern Ireland, the Nordic region as well as the 325 power systems of Lithuania, Latvia and Estonia which together are referred to as the Baltic 326 region and which are part of a wider synchronious area. . 327

3.24 328 Secondary control 329 A centralised automatic function to regulate the generation in a load-frequency control area 330 based on secondary control reserves in order: 331

to maintain its interchange power flow at the control program with all other load-332 frequency control areas (and to correct the loss of capacity in a load-frequency control 333 area affected by a loss of production) and, at the same time, 334

(in case of a major frequency deviation originating from the load-frequency control 335 area, particularly after the loss of a large generation unit) to restore the frequency in 336 case of a frequency deviation originating from the load-frequency control area to its 337 set value in order to free the capacity engaged by the primary control (and to restore 338 the primary control reserves). 339

In order to fulfill these functions, secondary control operates by the network characteristic 340 method. Secondary control is applied to selected generator sets in the power plants 341 comprising this control loop. Secondary control operates for periods of several minutes, and is 342 therefore dissociated from primary control. This behaviour over time is associated with the PI 343 (proportional-integral) characteristic of the secondary controller. 344

3.25 345 Unintentional deviation 346 For each energy exchange that has taken place in a given time interval, between a relevant 347 area and its synchronous zone, or between a relevant area and another relevant area in a 348 different synchronous zone, the difference between the actual measured energy exchange, 349 and the scheduled energy exchange and all intentional deviations from that schedule. 350

3.26 351 Virtual scheduling area 352

A scheduling area without generation or consumption. 353

354

– Page 12 of 58 –




4 The RG CE schedule reporting business process 355

4.1 Overall business context 356

This Implementation Guide provides: 357

Standard document formats enabling a uniform layout for the transmission of reporting 358 information between all relevant organisations within the ENTSO-E RG CE hierarchy. 359

A standard enabling a uniform layout for the transmission of reporting information between 360 all relevant organisations within the ENTSO-E RG CE hierarchy 361

A standard enabling ENTSO-E RG CE TSOs to perform the verification process that all 362 aggregated netted external schedules within a synchronous area sum up to zero. 363

This shall ensure a common interface between different software solutions. 364

LFC blocks containing more than one LFC area and LFC areas containing more than one 365 scheduling area may agree on the additional transmission of reporting information to the 366 parent area or block. 367

This Implementation Guide respects the requirements of the ENTSO-E RG CE verification 368 process described in ENTSO-E RG CE operational handbook policy 2. 369

The following schedules are covered in this implementation guide: 370

1) Aggregated netted external schedules; 371

2) Aggregated netted external market schedules; 372

3) Aggregated netted external TSO schedules; 373

4) Compensation program schedules; 374

5) Netted area AC position; 375

6) Netted area position. 376

The schedules 2, 3 and 4 are used in the ENTSO-E RG CE verification process to ensure that 377 within a synchronous area they sum up to zero (see Figure 1). 378

The 1st

schedule corresponds to the aggregation of schedules 2 and 3. 379

The coordination center zone operators of ENTSO-E RG CE will use the Verification Platform 380 to perform the ENTSO-E RG CE verification process. 381

– Page 13 of 58 –




382

383

Figure 1: The ENTSO-E RG CE schedule reporting process use case 384

For bilateral exchanges between two scheduling areas, p rior to the start of the ENTSO-E RG 385 CE reporting process it is first of all necessary for all TSOs operating a scheduling area to 386 agree on the external commercial trade schedules with their counterparts. 387

When the schedules have been agreed each TSO operating a scheduling area reports the 388 agreed schedules in aggregated and netted form to the verification system. This information 389 will then be used by the LFC area operators, LFC block operators and coordination center 390 zone operators to carry out the necessary checks on data pertaining to their respective areas 391 to ensure overall information coherence. 392

TSOs operating a scheduling area, LFC area operators and LFC block operators report to the 393 verification system the compensation programs for the corresponding application date. These 394 compensation programs will be put into place on the application date corresponding to the 395 compensation period, in their respective areas in order to compensate the ENTSO-E RG CE 396 unintentional deviations which occurred during the previous (corresponding) calculation 397 period. This information is used by the coordination center zone operators, load-frequency 398 control block operators, and, when applicable, by the LFC area operators respectively to 399 verify that the compensation program is being implemented as requested. 400

During the course of the day emergency procedures may be put into place to counteract 401 congestion or a problem in the network. Whenever this happens the TSOs operating a 402 scheduling area immediately post using the verification system an aggregated netted external 403 TSO schedule. This enables the LFC area and LFC block operators to modify their load 404 frequency control programs and for the coordination center zone operators to ensure that the 405 ENTSO-E RG CE region correctly balances out. 406

uc Use case RG CE v er if ica t ion pr ocess

Repor t aggr ega ted

netted exter na l

mar ket schedules

Repor t aggr ega ted

netted exter na l TSO

schedules

Repor t compensa t ion

pr ogr am schedules

Request and

r eceiv e r epor t ing

infor mat ion

Pr ov ide aggr ega ted

netted exter na l

schedules

P r ov ide

compensa t ion

pr ogr am schedules

P r ov ide netted AC

posit ionLFC a r ea oper a tor

(from

ENTSO-E

roles)

LFC block oper a tor

(from

ENTSO-E

roles)

Mar ket Infor mat ion

Aggr ega tor(from

Reporting

roles)

Coor dina t ion center

zone oper a tor(from

ENTSO-E

roles)

Infor mat ion

r eceiv er(from

Roles)

P r ov ide aggr ega ted

netted exter na l

mar ket schedules

P r ov ide aggr ega ted

netted exter na l TSO

schedules

P r ov ide netted

a r ea posit ion

Note:

Information receiver may be:

- system operator;

- LFC area operator;

- LFC block operator;

- coordination center zone operator;

- interested parties (e. g. Common Grid Model, RSCIs, …).

Sy stem oper a tor

(from

Roles)

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

«flow»

– Page 14 of 58 –




Schedules provided from centralised mechanisms (such as Market Coupling) which produce 407 as output external schedules based on net position (in combination with a virtual scheduling 408 area) can be considered as “reference schedules” that highly simplify the Scheduling process: 409

“SO-SO-Matching“, as currently defined, will not be required in this specific case, 410

The reporting process is still required. The schedule reported by a TSO operating a 411 scheduling area can be directly compared to the reference schedule from the centralised 412 mechanism. 413

Note concerning virtual scheduling areas: 414

Scheduling areas participating in a centralised mechanism that uses a virtual scheduling area to support 415 scheduling in net position (e.g. market coupling, compensation of unintentional deviation) have a virtual 416 border with the virtual scheduling area. The sum of all imports of this virtual scheduling area is equ al to 417 the sum of all exports of this virtual scheduling area. 418

In special cases the virtual scheduling area may also contain the exchange of other virtual scheduling 419 areas (e.g. netted area AC position of a load-frequency control block may contain schedules related to a 420 virtual scheduling area for compensation of load-frequency control block).. 421

422

Figure 2 – ENTSO-E RG CE schedule reporting process for 423 aggregated netted external market schedules 424

425

– Page 15 of 58 –




426

Figure 3 - ENTSO-E RG CE schedule reporting process for 427 aggregated netted external TSO schedules 428

429

Figure 4 – ENTSO-E RG CE schedule reporting process for 430 compensation schedules 431

– Page 16 of 58 –




The examples shown in Figure 2, Figure 3 and Figure 4 are merely indications of the posting 432 of schedules to the verification system. They are not exhaustive. 433

4.2 Schedule reporting process sequence 434

435

436

Figure 5 – Schedule reporting process sequence diagram for market schedules 437

438

Figure 6 - Schedule reporting process sequence diagram for TSO schedules 439

440

441

Figure 7 – Schedule reporting process sequence diagram for compensation schedules 442

sd Sequence diagr am RG CE v er if ica t ion - Mar ket sequenceg

System operator

(from Roles)

Market Information

Aggregator

(from Reporting

roles)

Aggregated netted external market schedules(Reporting_MarketDocument)

Acknowledgement of reception(Acknowledgement_MarketDocument)

Aggregated netted external market schedules status report(ReportingStatus_MarketDocument)Day

aheadand

intraday

sd Sequence diagr am RG CE v er if ica t ion - TSO sequence

System operator

(from Roles)

Market Information

Aggregator

(from Reporting

roles)

Aggregated netted external TSO schedules(Reporting_MarketDocument)


Aggregated netted external TSO schedules(ReportingStatus_MarketDocument)

Day ahead

and intraday

sd Sequence diagr am RG CE v er if ica t ion -complete sequence

LFC area operator

(from ENTSO-E

roles)

LFC block operator

(from ENTSO-E

roles)

Coordination center zone

operator

(from ENTSO-E

roles)

Information receiver

(from Roles)

Market Information

Aggregator

(from Reporting

roles)

System operator

(from Roles)



Aggregated netted external market schedules status report(ReportingStatus_MarketDocument)

Request aggregated netted external market schedules(StatusRequest_MarketDocument)

Aggregated netted external market schedules(ReportingInformation_MarketDocument)


Aggregated netted external market schedules(ReportingInformations_MarketDocument)



Aggregated netted external TSO market schedules(Reporting_MarketDocument)


Aggregated netted external TSO market schedules status(ReportingStatus_MarketDocument)

Request aggregated netted external TSO schedules(StatusRequest_MarketDocument)

Aggregated netted external TSO schedules(ReportingInformation_MarketDocument)





Compensation schedule(Reporting_MarketDocument)


Compensation schedule status(ReportingStatus_MarketDocument)










Calculate and

valdate results()Compensation and net position information(ReportingInformation_MarketDocument)

Compensation and net position information(ReportingInformations_MarketDocument)

Compensation and net position information(ReportingInformation_MarketDocument)


Request information concerning domain, dataset or referenced date/time(StatusRequest_MarketDocument)

Acknowledgement of negative regeption

(Acknowledgement_MarketDocument)

Requested content reply(ReportingInformation_MarketDocument)

Predefined request triggers document emission due to change(ReportingInformation_MarketDocument)

Predefined request triggers document emission due to change or time limit(ReportingInformation_MarketDocument)

sd Sequence diagr am RG CE v er if ica t ion -complete sequence

LFC area operator

(from ENTSO-E

roles)

LFC block operator

(from ENTSO-E

roles)

Coordination center zone

operator

(from ENTSO-E

roles)


(from Roles)

Market Information

Aggregator

(from Reporting

roles)

System operator

(from Roles)



Aggregated netted external market schedules status report(ReportingStatus_MarketDocument)




Aggregated netted external market schedules(ReportingInformations_MarketDocument)



Aggregated netted external TSO market schedules(Reporting_MarketDocument)


Aggregated netted external TSO market schedules status(ReportingStatus_MarketDocument)



















Calculate and

valdate results()Compensation and net position information(ReportingInformation_MarketDocument)

Compensation and net position information(ReportingInformations_MarketDocument)



Request information concerning domain, dataset or referenced date/time(StatusRequest_MarketDocument)

Acknowledgement of negative regeption

(Acknowledgement_MarketDocument)

Requested content reply(ReportingInformation_MarketDocument)

Predefined request triggers document emission due to change(ReportingInformation_MarketDocument)

Predefined request triggers document emission due to change or time limit(ReportingInformation_MarketDocument)

Day ahead

– Page 17 of 58 –




443

444

Figure 8 - Schedule reporting process sequence diagram for reporting status requests 445 and replies 446

The sequence diagrams in Figure 5, Figure 6, Figure 7 and Figure 8 outline the information 447 that is provided using the verification system. It is used by the different actors in the ENTSO-448 E RG CE SCHEDULE Reporting process. 449

The initial sequence (Figure 5) covers the reporting of the aggregated netted external market 450 schedule by the system operator. The document reported contains the respective data for one 451 given border. The reception of the submission is acknowledged by the verification system if it 452 can be parsed. 453

Once the verification system has verified an aggregated net ted external market schedule for a 454 specific border, both of the involved TSOs operating a scheduling area (sender and 455 counterpart) will receive result of the validation process in a reporting status market 456 document. This reporting status market document includes all available time series related to 457 the specific border and process. 458

A similar sequence (Figure 6) occurs when the TSO operating a scheduling area transmits the 459 aggregated netted external TSO schedule to the verification system. 460

The third sequence (Figure 7) set covers the reporting of the ENTSO-E RG CE compensation 461 program schedules to the verification system. 462

The whole process is reiterative and may evolve throughout the day. 463

Any schedule changes that occur require immediate posting on the verification system. 464

A fourth sequence is shown in Figure 8 and deals with the request of Information receivers for 465 information concerning a domain or a predefined dataset and the reply from the verification 466 system. 467

An information receiver can be: 468

a system operator; 469

a LFC area operator; 470

sd Sequence diagr am RG CE - Sta tus r equest

Market Information

Aggregator

(from Reporting

roles)


(from Roles)

Event triggered transmissions

Request information concerning domain or dataset (StatusRequest_MarketDocument)


Requested content reply(ReportingStatus_MarketDocument or ReportingInformation_MarketDocument)

Predefined request triggering document emission due to an information change

(ReportingInformation_MarketDocument)

Predefined request triggering document emission due to a time limit

(ReportingInformation_MarketDocument)

– Page 18 of 58 –




a LFC block operator; 471

a coordination center zone operator; 472

an interested parties (e. g. Common Grid Model, RSCIs, …). 473

The information* will be provided: 474

on request using the status request market document; 475

if changes in the values of a domain in a dataset occur (event triggered); 476

at a predefined point in time in a dataset (time triggered). 477

*Remark concerning "the provision of information": The verification system will send the 478 information to the involved TSOs and also make available the information in order to allow the 479 TSOs to retrieve it. 480

A status request may identify for a given time interval and process type: 481

a domain and optionally a referenced date/time and business type. 482

a dataset and optionally a referenced date/time. 483

The verification system shall provide the information relative to the domain or dataset for the 484 designated time interval as available at the referenced date/time, if provided. 485

Figure 9 provides an example of such requests. 486

487

Figure 9 – Request examples 488

The requests will always be satisfied by the verification system with the provision of a 489 reporting status market document or a reporting information market document containing one 490 or all of the following: 491

Aggregated netted external market schedules. 492

Aggregated netted external TSO schedules. 493

Aggregated netted external schedules. 494

Compensation program schedules. 495

Netted area AC position; 496

– Page 19 of 58 –




Netted area position 497

4.3 Business rules for the RG CE schedule reporting process 498

4.3.1 General rules 499

For each electronic data interchange defined in this document, an acknowledgement 500 document, as defined in IEC 62325-451-1, should be generated either accepting the whole 501 received document (with the exception of the status request market document that does not 502 require it since the reply is made with the document containing the requested content ) or 503 rejecting it completely. 504

The reporting market document shall contain 2 time series per scheduling area border. DC-505 links and controllable AC-links will be reported separately using additional “path” -information. 506 One time series provides the input to the area and the other provides the output from the 507 area. 508

The reporting status market document shall contain 4 time series per scheduling area border. 509 DC-links and controllable AC-links will be reported separately using additional “path” -510 information. There are 2 time series per TSO operating a scheduling area. 511

The reporting information market document shall contain 2 time series per domain. DC-links 512 and controllable AC-links will be reported separately using additional “path” -information. 513

4.3.2 Dependencies governing the Reporting_MarketDocument 514

The reporting market document is used to provide all the information related to the ENTSO-E 515 RG CE verification process. 516

The information provided in a reporting market document concerns: 517

Aggregated netted external market schedule; 518

Aggregated netted external TSO schedule; 519

Compensation program schedules. 520

The dependencies are listed in the following paragraphs. 521

– Page 20 of 58 –




4.3.2.1 Aggregated netted external market schedule 522

Table 1 – Aggregated netted external market schedule dependency table 523

Day ahead Intraday

Reporting_MarketDocument

type B16 = Aggregated netted external market schedule document

process.processType A01 = Day ahead A18 = Total intraday

sender_MarketParticipant.marketRole.type A04 = System operator

receiver_MarketParticipant.marketRole.type A32 = Market information aggregator

A15 = load-frequency control block operator

A14 = load-frequency control area operator

domain.mRID / codingScheme A scheduling area border identified with an EIC Y code. codingScheme = A01

subject_Domain.mRID / codingScheme A scheduling area of the originator of the market schedule identified with an EIC Y code. This identification shall be found in either the in_Domain.mRID or the out_Domain.mRID of the time series.

codingScheme = A01

TimeSeries

businessType B61 = Aggregated netted external market schedule;

product 8716867000016 = Active Power.

in_Domain.mRID / codingScheme A scheduling area where the product is being delivered identified with an EIC Y code.

codingScheme = A01.

out_Domain.mRID / codingScheme A schedulingarea where the product is being extracted identified with an EIC Y code.

codingScheme = A01.

connectingLine_RegisteredResource.mRID Required if DC link or controllable AC link

quantity_Measure_Unit.name MAW

curveType A03 = Variable block

Series_Period

resolution PT1M = 1 minute

524

Table 1 provides the dependencies for the aggregated netted external market schedules. 525

There shall be a single reporting market document per scheduling area border per process. 526 The scheduling area border is identified in the domain.mRID attribute. The scheduling area 527 that is the subject of the document is defined in the subject_Domain.mRID attribute. 528

Reporting market documents providing schedules from centralised mechanisms (such as 529 Market Coupling) which produce as output external schedules based on net position in 530 combination with a virtual scheduling area shall provide a single reporting market document 531 containing all scheduling area borders of the virtual scheduling area. The virtual scheduling 532 area is identified in the domain.mRID attribute and the subject_Domain.mRID attribute. 533

Two reporting market documents will be provided per sender per border per ENTSO-E RG CE 534 day: 535

One document containing the day ahead values (required in order to provide the day 536 ahead situation for the day). This shall have a unique document identification and a 537 process type of “Day ahead” (A01). Any evolutions to this schedule shall be carried out 538 through the creation of a new version. The new version will replace the previous version. 539

– Page 21 of 58 –




A day ahead document is required for every border even if there are no market 540 nominations for the border (see ENTSO-E RG CE Operation Handbook Policy 2). 541

One document containing the intraday values. This will have a unique document 542 identification and shall have a process type of «Intraday Total» (A18). This shall include 543 the updated values of the values already provided in the day ahead document. The 544 Time_Period.timeInterval and the timeInterval_DateTimeInteval shall always cover the 545 complete period. Any evolutions to this schedule shall be carried out through the creation 546 of a new version. The new version will replace the previous version. 547

Note: An aggregated netted external market schedule that uses the Curve Type “A03” with a resolution of 1 minute 548 shall report the Interval classes which shall respect the constraint that a change in the block value can only occur 549 based on the bilaterally agreed resolution boundary that has been used in the system operator to system operator 550 matching. 551

4.3.2.2 Aggregated netted external TSO schedule 552

Table 2 – Aggregated netted external TSO schedule dependency table 553

Aggregated netted external TSO schedule


type B17 = Aggregated netted external TSO schedule document

process.processType A01 = Day ahead

A18 = Total intraday



A15 = load-frequency control block operator

A14 = load-frequency control area operator

domain.mRID / codingScheme A scheduling area border identified with an EIC Y code.

codingScheme = A01

subject_Domain.mRID / codingScheme The scheduling area of the originator of the market schedule identified with an EIC Y code.

This identification shall be found in either the in_Domain.mRID or the out_Domain.mRID of the TimeSeries.

codingScheme = A01

TimeSeries

businessType B62 = Aggregated netted external TSO schedule



codingScheme = A01.

out_Domain.mRID / codingScheme A scheduling area where the product is being extracted identified with an EIC Y code.

codingScheme = A01.


quantity_Measure_Unit.name MAW = Mega watts


Series_Period


554

Table 2 provides the dependencies for the aggregated netted external TSO schedules. 555

There shall be a single reporting market document per scheduling area border per process. 556 The scheduling area border is identified in the domain.mRID attribute. The scheduling area 557 that is the subject of the document is defined in the subject_Domain.mRID attribute. 558

– Page 22 of 58 –




Reporting market documents providing schedules from centralised mechanisms which 559 produce as output external schedules based on net position in combination with a virtual 560 scheduling area shall provide a single reporting market document containing all scheduling 561 area borders of the virtual scheduling area. The virtual scheduling area is identified in the 562 domain.mRID attribute and the subject_Domain.mRID attribute. 563

In the case where external TSO schedules are agreed, reporting market documents are 564 expected per sender per border per ENTSO-E RG CE day: 565

One document shall contain the day ahead values (required in order to provide the 566 day ahead situation for the day). This shall have a unique document identification and 567 a process type of “Day ahead” (A01). Any evolutions to this schedule shall be carried 568 out through the creation of a new version. The new version will replace the previous 569 version. 570

A day ahead document is not required for a border if there are no external TSO 571 schedules for the border. 572

One document shall contain the intraday values. This will have a unique document 573 identification and shall have a process type of «Intraday Total» (A18). This shall 574 include the updated values of the values already provided in the day ahead document. 575 The Time_Period.timeInterval and the timeInterval_DateTimeInteval shall always 576 cover the complete period. Any evolutions to this schedule shall be carried out through 577 the creation of a new version. The new version will replace the previous version. 578

– Page 23 of 58 –




4.3.2.3 Compensation program schedules 579

Table 3 – Compensation program schedule dependency table 580

TSO operating a scheduling area to

load-frequency control area

operator

Load-frequency control area

operator to load-frequency control

block operator

Load-frequency control block operator to

coordination center operator


type A56 = Compensation program schedule

process.processType A01 = Day ahead


A14 = Load-frequency control area operator

A15 = Load-frequency control block operator


A32 = Market information aggregator

A32 = Market information aggregator

domain.mRID / codingScheme The load-frequency control area identified with an EIC Y code.

codingScheme = A01

The load-frequency control block identified with an EIC Y code.

codingScheme = A01

The coordination center zone identified with an EIC Y code.

codingScheme = A01

subject_Domain.mRID / codingScheme The scheduling area of the originator of the compensation program schedule identified with an EIC Y code.


codingScheme = A01

The load-frequency control area of the originator of the compensation program schedule identified with an EIC Y code.


codingScheme = A01

The load-frequency control block of the originator of the compensation program schedule identified with an EIC Y code.


codingScheme = A01

TimeSeries

businessType A44 = Compensation program



codingScheme = A01.

A load-frequency control area or load-frequency control block where the product is being delivered identified with an EIC Y code.

codingScheme = A01.

A load-frequency control block or coordination center zone where the product is being delivered identified with an EIC Y code.

codingScheme = A01.

out_Domain.mRID / codingScheme A scheduling area where the product is being extracted identified with an EIC Y code.

codingScheme = A01.

A control area or load-frequency control block where the product is being extracted identified with an EIC Y code.

codingScheme = A01.

A load-frequency control block or coordination center zone where the product is being extracted identified with an EIC Y code.

codingScheme = A01.



– Page 24 of 58 –





Series_Period


581

Table 3 provides the dependencies for the compensation schedules 582

There shall be only one reporting market document for compensation per area. This shall 583 have a unique document identification and a process type of “Day ahead” (A01). Any 584 evolutions to this schedule shall be carried out through the creation of a new version. The 585 new version will replace the previous version. The domain.mRID attribute shall be the area 586 where the area being reported belongs. The area shall be identified in the 587 subject_Domain.mRID attribute. 588

Reporting market documents providing schedules from centralised mechanisms which 589 produce as output external schedules based on net position in combination with a virtual 590 scheduling area shall provide a single reporting market document containing all scheduling 591 area borders of the virtual scheduling area. The virtual scheduling area is identified in the 592 domain.mRID attribute and the subject_Domain.mRID attribute. 593

594

– Page 25 of 58 –




4.3.3 Dependencies governing the Reporting Status Market Document 595

Table 4 – Reporting status market document dependency table 596

Day Ahead Intraday

ReportingStatus_MarketDocument

type B18 = Reporting status market document


sender_MarketParticipant.marketRole.type A32 = Market information aggregator

receiver_MarketParticipant.marketRole.type A04 = System Operator



A16 = Coordination center zone operator

A33 = Information receiver

domain.mRID Used if no dataset_MarketDocument information provided

time_Period.timeInterval This information provides the start and end date and time of the period covered by the document.

TimeSeries

businessType A44 = Compensation program schedule

B61 = Aggregated netted external market schedule

B62 = Aggregated netted external TSO schedule


in_Domain.mRID / codingScheme An area where the product is being delivered identified with an EIC Y code.

codingScheme = A01.

out_Domain.mRID / codingScheme An area where the product is being extracted identified with an EIC Y code.

codingScheme = A01.




Series_Period


Reason

code This information may be provided at three levels.

At the header level to indicate if no information to a status request is available. The following code shall be used:

B08 = Data not yet available.

At the Time series level to provide the following information:

A28 = Counterpart time series missing

A29 = Counterpart time series quantity differences

A63 = Time Series modified

A88 = Time series matched

At the Point level to provide information on a given quantity. The following codes shall be used:

A43 = Quantity increased

A44 = Quantity decreased

Other reason codes according to ENTSO-E code list

597

Table 4 provides the dependencies for the reporting status market document. 598

– Page 26 of 58 –




4.3.4 Dependencies governing the Reporting Information Market Document 599

Table 5 – Reporting information market document dependency table 600

Day Ahead Intraday

ReportingInformation_MarketDocument

type B19 = Reporting information market document


sender_MarketParticipant.marketRole.type A32 = Market information aggregator

receiver_MarketParticipant.marketRole.type A04 = System Operator



A16 = Coordination center zone operator

A33 = Information receiver

domain.mRID Used if no dataset_MarketDocument information provided.

Identified with an EIC Y code (codingScheme = A01).

time_Period.timeInterval This information provides the start and end date and time of the period covered by the document.

Doc_Status The identification of the condition or position of the document with regard to its standing. A document may be intermediate or final.

A01 = Intermediate

A02 = Final

TimeSeries

businessType A44 = Compensation program schedule



B63 = Aggregated netted external schedule

B64 = Netted area AC position

B65 = Netted area position.


in_Domain.mRID / codingScheme An area where the product is being delivered.


out_Domain.mRID / codingScheme An area where the product is being extracted.





Series_Period


Reason

code This information may be provided at three levels.

At the header level to indicate if no information to a status request is available. The following code shall be used:

B08 = Data not yet available.

At the Time series level to provide the following information:

A28 = Counterpart time series missing

A29 = Counterpart time series quantity differences

A63 = Time Series modified

A88 = Time series matched

At the Point level to provide information on a given quantity. The following codes shall be used:

A43 = Quantity increased

A44 = Quantity decreased

– Page 27 of 58 –




Other reason codes according to ENTSO-E code list

601

Table 4 provides the dependencies for the reporting information market document. 602

603

4.3.5 Generic rules and dependencies for the Status Request Market Document 604

The Status Request Market Document is specified in IEC 62325 – 451-5. In this specification 605 the attributes described in Table 6 are mandatory. 606

Table 6 – Mandatory attributes of Status request market document 607

Attribute name / Attribute type Description

mRID The unique identification of the document being exchanged within a business process flow.

type The coded type of a document. The document type describes the principal characteristic of the document.

A59 = status request for a status within a process (status request for a reporting status market document)

B20 = status request for a reporting information market document.

(status request of reporting information market document)

sender_MarketParticipant.mRID The identification of a party in the energy market. --- Document owner.

sender_MarketParticipant.marketRole.type The identification of the role played by a market player. --- Document owner. --- The role associated with a MarketParticipant.

receiver_MarketParticipant.mRID The identification of a party in the energy market. --- Document recipient.

receiver_MarketParticipant.marketRole.type The identification of the role played by a market player. --- Document recipient. --- The role associated with a MarketParticipant.

createdDateTime The date and time of the creation of the document.

608

Table 7 provides the dependencies for the status request market document relevant for the 609 reporting process. 610

The attribute instance component defines the nature of the request through the use of two 611 attributes: 612

“attribute” that contains a keyword identifying the name of an attribute that is used to 613 identify what is being specified. In the context of the reporting process the following 614 attributes shall be used: “type”, “domain.mRID”; “dataset.mRID”, “referenced.dateTime”, 615 “processType” and/or “businessType”.. 616

“attributeValue” that provides the content of the specified attribute. It is a string value that 617 represents a copy of the element tag of the electronic document for which the status is 618 being requested. 619

– Page 28 of 58 –



Table 7 – Status request market document dependency table 620

Document type Domain status request Requested time interval Dataset status request referenced date time

ProcessType BusinessType

AttributeInstanceComponent

attribute The attribute value shall equal “type”

The attribute value shall equal “domain.mRID”

The attribute value shall equal “requested_Period.timeInterval

The attribute value shall equal “dataset.mRID”

The attribute value shall equal “referenced.dateTime”

The attribute value shall equal “ProcessType”

The attribute value shall equal “BusinessType

attributeValue The identification of the type that is covered in the reporting information market document. It shall correspond to one of the following:

A59 = status information

B20 = Reporting information

The status information shall provide information about the result of the verification process on a scheduling area border.(4 time series per domain).

The reporting information shall provide information about the scheduling data based on “positively verified” schedules.(2 time series per domain)

The identification of the domain that is covered in the status request document. Depending on the reporting context it will correspond to one of the following:

A Scheduling area;

A Scheduling area border;

A Load-frequency control area;

A Load-frequency control area border;

A Load-frequency control block area;

A Load-frequency control block area border;

A Synchronous area.

The identification shall be an EIC Y code.

This name shall not be provided if a dataset identification is present.

This name shall be provided if a dataset identification is not present.

The identification of the period that is to be covered in the reply, for example a given schedule day.

The time interval is mandatory.

The time interval shall conform to the following pattern:

YYYY-MM-DDThh:mmZ/ YYYY-MM-DDThh:mmZ

The identification of an individually predefined data set in a data base system (e. g. the verification system).

The identification shall be up to 35 alphanumeric characters.

This name shall not be provided if a domain is present.

This name shall be provided if a domain is not present

The point of time for which the data is requested from the data base system (e. g. the verification system).

The date and time shall conform to the following pattern:

YYYY-MM-DDThh:mm:ssZ

This name shall only be provided if required.

A01 = Provide Day ahead values only.

A18 = Provide latest available verification data based on day ahead and intraday

Not present if a dataset identification is present.

Mandatory if an identification of a domain is present

A44 = Compensation program schedule



B63 = Aggregated netted external schedule

B64= Netted area AC position

B65 = Netted area position

This information will only be provided for document type B19 = Reporting information market document

621

– Page 29 of 58 –




5 Contextual and assembly models 622

5.1 Reporting contextual model 623

5.1.1 Overview of the model 624

Figure 10 shows the model. 625

626

Figure 10 – Reporting contextual model 627

5.1.2 IsBasedOn relationships from the European style market profile 628

Table 8 shows the traceability dependency of the classes used in this package towards the 629 upper level. 630

Table 8 – IsBasedOn dependency 631

Name Complete IsBasedOn Path

ConnectingLine_RegisteredResource TC57CIM::IEC62325::MarketCommon::RegisteredResource

Domain TC57CIM::IEC62325::MarketManagement::Domain

MarketParticipant TC57CIM::IEC62325::MarketCommon::MarketParticipant

MarketRole TC57CIM::IEC62325::MarketCommon::MarketRole

Measure_Unit TC57CIM::IEC62325::MarketManagement::Unit

Point TC57CIM::IEC62325::MarketManagement::Point

Process TC57CIM::IEC62325::MarketManagement::Process

Reporting_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument

Series_Period TC57CIM::IEC62325::MarketManagement::Period

Time_Period TC57CIM::IEC62325::MarketManagement::Period

cla ss Repor t ing document model

«ABIE»

Repor t ing_Mar ketDocument

+ mRID :ID_String

+ revisionNumber :ESMPVersion_String

+ type :MessageKind_String

+ createdDateTime :ESMP_DateTime

«ABIE»

Mar ketRole

+ type :MarketRoleKind_String

«ABIE»

P r ocess

+ processType :ProcessKind_String

«ABIE»

Time_Per iod

+ timeInterval :ESMP_DateTimeInterval

«ABIE»

Doma in

+ mRID :AreaID_String

«ABIE»

TimeSer ies

+ mRID :ID_String

+ businessType :BusinessKind_String

+ product :EnergyProductKind_String

+ curveType :CurveType_String

«ABIE»

Measur e_Unit

+ name :MeasurementUnitKind_String

«ABIE»

Ser ies_Per iod


+ resolution :Duration

«ABIE»

Point

+ position :Position_Integer

+ quantity :Decimal

«ABIE»

Mar ketPa r t icipant

+ mRID :PartyID_String

«ABIE»

Connect ingLine_Register edResour ce

+ mRID :ResourceID_String

+Time_Period

1..1

+Subject_Domain 1..1

+Sender_MarketParticipant

1..1

+Receiver_MarketParticipant

1..1+Process

1..1

+In_Domain 1..1

+Domain 1..1

+Out_Domain 1..1

+ConnectingLine_RegisteredResource 0..1

+Quantity_Measure_Unit

1..1

+TimeSeries 1..*

+Period 1..*

+Point 1..*

+MarketRole 1..1

– Page 30 of 58 –





TimeSeries TC57CIM::IEC62325::MarketManagement::TimeSeries

632

– Page 31 of 58 –




5.2 Reporting assembly model 633



636

Figure 11 – Reporting assembly model 637



class Repor t ing assembly model

«MBIE»

TimeSer ies

+ mRID :ID_String



+ in_Domain.mRID :AreaID_String

+ out_Domain.mRID :AreaID_String

+ connectingLine_RegisteredResource.mRID :ResourceID_String [0..1]

+ quantity_Measure_Unit.name :MeasurementUnitKind_String


«MBIE»

Ser ies_Per iod



«MBIE»

Repor t ing_Mar ketDocument

+ mRID :ID_String



+ process.processType :ProcessKind_String

+ sender_MarketParticipant.mRID :PartyID_String

+ sender_MarketParticipant.marketRole.type :MarketRoleKind_String

+ receiver_MarketParticipant.mRID :PartyID_String

+ receiver_MarketParticipant.marketRole.type :MarketRoleKind_String


+ time_Period.timeInterval :ESMP_DateTimeInterval

+ domain.mRID :AreaID_String

+ subject_Domain.mRID :AreaID_String

«MBIE»

Point


+ quantity :Decimal

+TimeSeries 1..*

+Period 1..*

+Point 1..*

– Page 32 of 58 –







Reporting_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument



642

5.2.3 Detailed Reporting assembly model 643

5.2.3.1 Reporting_MarketDocument root class 644

An electronic document containing the information necessary to satisfy the requirements of a 645 given business process. 646

The reporting market document is to be used to report aggregated netted external market 647 schedules, aggregated netted external TSO schedules and compensation program schedules. 648

Table 10 shows all attributes of Reporting_MarketDocument. 649

Table 10 – Attributes of Reporting assembly model::Reporting_MarketDocument 650

Order mult. Attribute name / Attribute type Description

0 [1..1] mRID

ID_String

The unique identification of the document being exchanged within a business process flow.

1 [1..1] revisionNumber

ESMPVersion_String

The identification of the version that distinguishes one evolution of a document from another.

2 [1..1] type

MessageKind_String

The coded type of a document. The document type describes the principal characteristic of the document.

3 [1..1] process.processType

ProcessKind_String

The identification of the nature of process that the document addresses. --- The process dealt with in the document.

4 [1..1] sender_MarketParticipant.mRID

PartyID_String

The identification of a party in the energy market. --- The sender of the document.

5 [1..1] sender_MarketParticipant.marketRole.type

MarketRoleKind_String

The identification of the role played by a market player. --- The sender of the document. --- The role associated with a MarketParticipant.

6 [1..1] receiver_MarketParticipant.mRID

PartyID_String

The identification of a party in the energy market. --- The recipient of the document.

7 [1..1] receiver_MarketParticipant.marketRole.type


The identification of the role played by a market player. --- The recipient of the document. --- The role associated with a MarketParticipant.

8 [1..1] createdDateTime

ESMP_DateTime

The date and time of the creation of the document.

9 [1..1] time_Period.timeInterval

ESMP_DateTimeInterval

The start and end date and time for a given interval. --- This information provides the start and end date and time of the period covered by the document.

– Page 33 of 58 –





10 [1..1] domain.mRID

AreaID_String

The unique identification of the domain. --- The identification of the domain that is covered in the reporting market document. Depending on the reporting context it will correspond to one of the following: - a scheduling area; - a scheduling area border; - a control area; - a control area border; - a control block area; - a control block area border; - a synchronous area.

11 [1..1] subject_Domain.mRID

AreaID_String

The unique identification of the domain. --- The subject domain corresponds to the area being reported by the reporting market document.

651

Table 11 shows all association ends of Reporting_MarketDocument with other classes. 652

Table 11 – Association ends of Reporting assembly model::Reporting_MarketDocument 653 with other classes 654

Order mult. Class name / Role Description

12 [1..*] TimeSeries

TimeSeries

The time series that is associated with an electronic document. Association Based On : Reporting contextual model::Reporting_MarketDocument.[] ----- Reporting contextual model::TimeSeries.TimeSeries[1..*]

655

5.2.3.2 Point 656

The identification of the values being addressed within a specific interval of time. 657

Table 12 shows all attributes of Point. 658

Table 12 – Attributes of Reporting assembly model::Point 659

Order mult. Attribute name / Attribute type

Description

0 [1..1] position

Position_Integer

A sequential value representing the relative position within a given time interval.

1 [1..1] quantity

Decimal

The principal quantity identified for a point. The quantity of product scheduled for the position within the timeInterval.

660

5.2.3.3 Series_Period 661

The identification of the period of time corresponding to a given time interval and resolution. 662

Table 13 shows all attributes of Series_Period. 663

Table 13 – Attributes of Reporting assembly model::Series_Period 664


Description

0 [1..1] timeInterval


The start and end time of the period.

1 [1..1] resolution

Duration

The definition of the number of units of time that compose an individual step within a period.

– Page 34 of 58 –




665

Table 14 shows all association ends of Series_Period with other classes. 666

Table 14 – Association ends of Reporting assembly model::Series_Period with other 667 classes 668


2 [1..*] Point

Point

The Point information associated with a given Series_Period.within a TimeSeries. Association Based On : Reporting contextual model::Series_Period.[] ----- Reporting contextual model::Point.Point[1..*]

669

5.2.3.4 TimeSeries 670

A set of time-ordered quantities being exchanged in relation to a product. 671

Table 15 shows all attributes of TimeSeries. 672

Table 15 – Attributes of Reporting assembly model::TimeSeries 673


0 [1..1] mRID

ID_String

A unique identification of the time series.

1 [1..1] businessType

BusinessKind_String

The identification of the nature of the time series. The businessType identifies the trading nature of an energy product.

2 [1..1] product

EnergyProductKind_String

The identification of the nature of an energy product such as power, energy, reactive power, etc.

3 [1..1] in_Domain.mRID

AreaID_String

The unique identification of the domain. --- The area where the product is being delivered.

4 [1..1] out_Domain.mRID

AreaID_String

The unique identification of the domain. --- The area where the product is being extracted.

5 [0..1] connectingLine_RegisteredResource.mRID

ResourceID_String

The unique identification of a resource. --- The identification of the DC link (s) or controllable AC link(s) between areas.

6 [1..1] quantity_Measure_Unit.name

MeasurementUnitKind_String

The identification of the formal code for a measurement unit (UN/ECE Recommendation 20). --- The unit of measure which is applied to the quantity in the Point class.

7 [1..1] curveType

CurveType_String

The identification of the coded representation of the type of curve being described.

674

Table 16 shows all association ends of TimeSeries with other classes. 675

Table 16 – Association ends of Reporting assembly model::TimeSeries with other 676 classes 677


8 [1..*] Series_Period

Period

The time interval and resolution for a period associated with a TimeSeries. Association Based On : Reporting contextual model::TimeSeries.[] ----- Reporting contextual model::Series_Period.Period[1..*]

– Page 35 of 58 –




678

5.2.4 Datatypes 679

The list of datatypes used for the Reporting assembly model is as follows: 680

ESMP_DateTimeInterval compound 681

AreaID_String datatype, codelist CodingSchemeTypeList 682

BusinessKind_String datatype, codelist BusinessTypeList 683

CurveType_String datatype, codelist CurveTypeList 684

EnergyProductKind_String datatype, codelist EnergyProductTypeList 685

ESMP_DateTime datatype 686

ESMPVersion_String datatype 687

ID_String datatype 688

MarketRoleKind_String datatype, codelist RoleTypeList 689

MeasurementUnitKind_String datatype, codelist UnitOfMeasureTypeList 690

MessageKind_String datatype, codelist MessageTypeList 691

PartyID_String datatype, codelist CodingSchemeTypeList 692

Position_Integer datatype 693

ProcessKind_String datatype, codelist ProcessTypeList 694

ResourceID_String datatype, codelist CodingSchemeTypeList 695

YMDHM_DateTime datatype 696

697

– Page 36 of 58 –




5.3 Reporting status contextual model 698



701

Figure 12 – Reporting status contextual model 702










Original_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument

Original_TimeSeries TC57CIM::IEC62325::MarketManagement::TimeSeries

OriginalSender_MarketParticipant TC57CIM::IEC62325::MarketCommon::MarketParticipant



class Repor t ing sta tus document model

«ABIE»

Repor t ingSta tus_Mar ketDocument

+ mRID :ID_String




«ABIE»

Mar ketRole


«ABIE»

P r ocess

+ processType :ProcessKind_String

«ABIE»

Time_Per iod


«ABIE»

Doma in


«ABIE»

TimeSer ies

+ mRID :ID_String




«ABIE»

Measur e_Unit


«ABIE»

Ser ies_Per iod



«ABIE»

Point


+ quantity :Decimal

«ABIE»



«ABIE»



«ABIE»

Or igina l_Mar ketDocument

+ mRID :ID_String



«ABIE»

Or igina lSender _Mar ketPa r t icipant


«ABIE»

Reason

+ code :ReasonCode_String

+ text :ReasonText_String [0..1]

«ABIE»

Or igina l_TimeSer ies

+ mRID :ID_String

+Quantity_Measure_Unit

1..1

+Reason

0..*

+Reason 0..*

+Original_MarketDocument

1..1

+OriginalSender_MarketParticipant 1..1

+MarketRole 1..1

+Point 1..*

+Period 1..*

+Original_TimeSeries 1..1

+ConnectingLine_RegisteredResource0..1

+Time_Period

1..1

+TimeSeries 0..*

+Out_Domain 1..1+In_Domain 1..1

+Original_Domain

1..1

+Domain 0..1

+Process

1..1


1..1


1..1

+Reason

0..*

– Page 37 of 58 –





Reason TC57CIM::IEC62325::MarketManagement::Reason

ReportingStatus_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument




707

– Page 38 of 58 –




5.4 Reporting status assembly model 708



711

Figure 13 – Reporting status assembly model 712



class Repor t ing sta tus assembly model

«MBIE»

TimeSer ies

+ mRID :ID_String

+ original_MarketDocument.mRID :ID_String

+ original_MarketDocument.revisionNumber :ESMPVersion_String

+ original_MarketDocument.originalSender_MarketParticipant.mRID :PartyID_String

+ original_MarketDocument.createdDateTime :ESMP_DateTime

+ original_MarketDocument.original_Domain.mRID :AreaID_String

+ original_MarketDocument.original_TimeSeries.mRID :ID_String






+ quantity_Measure_Unit.name :MeasurementUnitKind_String


«MBIE»

Ser ies_Per iod



«MBIE»

Repor t ingSta tus_Mar ketDocument

+ mRID :ID_String










+ domain.mRID :AreaID_String [0..1]

«MBIE»

Reason



«MBIE»

Point


+ quantity :Decimal

+Reason

0..*

+TimeSeries 0..*

+Period 1..*

+Reason 0..*

+Reason 0..*

+Point 1..*

– Page 39 of 58 –








ReportingStatus_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument



717

5.4.3 Detailed Reporting status assembly model 718

5.4.3.1 ReportingStatus_MarketDocument root class 719


The reporting status market document is to be used to report the status of aggregated netted 722 external market schedules, aggregated netted external TSO schedules and compensation 723 program schedules on a given border. 724

Table 19 shows all attributes of ReportingStatus_MarketDocument. 725

Table 19 – Attributes of Reporting status assembly 726 model::ReportingStatus_MarketDocument 727


0 [1..1] mRID

ID_String



ESMPVersion_String


2 [1..1] type

MessageKind_String



ProcessKind_String

The identification of the nature of process that the document addresses. --- The process dealt with in the document.


PartyID_String




The identification of the role played by a market player. --- The sender of the document. --- The role associated with the market participant.


PartyID_String




The identification of the role played by a market player. --- The recipient of the document. --- The role associated with the market participant.


ESMP_DateTime





– Page 40 of 58 –






AreaID_String

The unique identification of the domain. --- The identification of the domain that is covered in the reporting status market document. Depending on the reporting context it will correspond to one of the following: - a scheduling area; - a scheduling area border; - a control area; - a control area border; - a control block area; - a control block area border; - a synchronous area.

728

Table 20 shows all association ends of ReportingStatus_MarketDocument with other classes. 729

Table 20 – Association ends of Reporting status assembly 730 model::ReportingStatus_MarketDocument with other classes 731

Order mult. Class name / Role

Description


TimeSeries

The time series that is associated with an electronic document. Association Based On : Reporting status contextual model::ReportingStatus_MarketDocument.[] ----- Reporting status contextual model::TimeSeries.TimeSeries[0..*]

12 [0..*] Reason

Reason

The Reason associated with the electronic document header providing different motivations for the creation of the document. Association Based On : Reporting status contextual model::ReportingStatus_MarketDocument.[] ----- Reporting status contextual model::Reason.Reason[0..*]

732

5.4.3.2 Point 733



Table 21 – Attributes of Reporting status assembly model::Point 736


Description

0 [1..1] position

Position_Integer


1 [1..1] quantity

Decimal

The principal quantity identified for a point. The quantity of the product scheduled for the position within the time interval.

737

Table 22 shows all association ends of Point with other classes. 738

Table 22 – Association ends of Reporting status assembly model::Point with other 739 classes 740


2 [0..*] Reason

Reason

The Reason information associated with a Point providing motivation information. Association Based On : Reporting status contextual model::Point.[] ----- Reporting status contextual model::Reason.Reason[0..*]

– Page 41 of 58 –




741

5.4.3.3 Reason 742

The motivation of an act. 743

Table 23 shows all attributes of Reason. 744

Table 23 – Attributes of Reporting status assembly model::Reason 745


0 [1..1] code

ReasonCode_String

The motivation of an act in coded form.

1 [0..1] text

ReasonText_String

The textual explanation corresponding to the reason code.

746




Table 24 – Attributes of Reporting status assembly model::Series_Period 750


Description




1 [1..1] resolution

Duration


751


Table 25 – Association ends of Reporting status assembly model::Series_Period with 753 other classes 754


2 [1..*] Point

Point

The Point information associated with a given Series_Period.within a TimeSeries. Association Based On : Reporting status contextual model::Series_Period.[] ----- Reporting status contextual model::Point.Point[1..*]

755




Table 26 – Attributes of Reporting status assembly model::TimeSeries 759


0 [1..1] mRID

ID_String


– Page 42 of 58 –





1 [1..1] original_MarketDocument.mRID

ID_String

The unique identification of the document being exchanged within a business process flow. --- The identification of an electronic document that is at the origin of the TimeSeries.

2 [1..1] original_MarketDocument.revisionNumber

ESMPVersion_String

The identification of the version that distinguishes one evolution of a document from another. --- The identification of an electronic document that is at the origin of the TimeSeries.

3 [1..1] original_MarketDocument.originalSender_MarketParticipant.mRID

PartyID_String

The identification of a party in the energy market. --- The identification of an electronic document that is at the origin of the TimeSeries. --- The sender of the original document that is at the origin of the time series.

4 [1..1] original_MarketDocument.createdDateTime

ESMP_DateTime

The date and time of the creation of the document. --- The identification of an electronic document that is at the origin of the TimeSeries.

5 [1..1] original_MarketDocument.original_Domain.mRID

AreaID_String

The unique identification of the domain. --- The identification of an electronic document that is at the origin of the TimeSeries. --- The identification of the domain that was in the original reporting market document header.

6 [1..1] original_MarketDocument.original_TimeSeries.mRID

ID_String

A unique identification of the time series. In the ESMP context, the "model authority" is defined as a party (originator of the exchange) that provides a unique identification in the context of a business exchange such as time series identification, bid identification, ... Master resource identifier issued by a model authority. The mRID is globally unique within an exchange context. Global uniqueness is easily achieved by using a UUID for the mRID. It is strongly recommended to do this. For CIMXML data files in RDF syntax, the mRID is mapped to rdf:ID or rdf:about attributes that identify CIM object elements. --- The identification of an electronic document that is at the origin of the TimeSeries. --- The identification of the time series that was in the original reporting market document.


BusinessKind_String

The identification of the nature of the time series.

8 [1..1] product



– Page 43 of 58 –






AreaID_String



AreaID_String



ResourceID_String

The unique identification of a resource. --- The identification of the DC link (s) or controllable AC link(s) between areas.

12 [1..1] quantity_Measure_Unit.name


The identification of the formal code for a measurement unit (UN/ECE Recommendation 20). --- The unit of measure which is applied to the quantity in the Point class.

13 [1..1] curveType

CurveType_String


760


Table 27 – Association ends of Reporting status assembly model::TimeSeries with 762 other classes 763


Description


Period

The time interval and resolution for a period associated with a TimeSeries. Association Based On : Reporting status contextual model::TimeSeries.[] ----- Reporting status contextual model::Series_Period.Period[1..*]

15 [0..*] Reason

Reason

The reason information associated with a TimeSeries providing motivation information. Association Based On : Reporting status contextual model::Reason.Reason[0..*] ----- Reporting status contextual model::TimeSeries.[]

764

5.4.4 Datatypes 765

The list of datatypes used for the Reporting status assembly model is as follows: 766










– Page 44 of 58 –









ReasonCode_String datatype, codelist ReasonCodeTypeList 781

ReasonText_String datatype 782



– Page 45 of 58 –




5.5 Reporting information contextual model 785



788

Figure 14 – Reporting information contextual model 789






Dataset_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument








Referenced_DateAndOrTime TC57CIM::IEC62325::MarketManagement::DateAndOrTime

class Repor t ing infor mat ion contextua l model

«ABIE»

Repor t ingInfor mat ion_Mar ketDocument

+ mRID :ID_String




+ docStatus :Action_Status

«ABIE»

Time_Per iod


«ABIE»

P r ocess

+ processType :ProcessKind_String «ABIE»



«ABIE»

Mar ketRole


«ABIE»

Doma in


«ABIE»

TimeSer ies

+ mRID :ID_String




«ABIE»

Measur e_Unit


«ABIE»



«ABIE»

Refer enced_Da teAndOr Time

+ date :Date

+ time :Time [0..1]

«ABIE»

Dataset_Mar ketDocument

+ mRID :ID_String

«ABIE»

Ser ies_Per iod



«ABIE»

Point


+ quantity :Decimal

«ABIE»

Reason



+Measurement_Unit

1..1

+Process

1..1


1..1


1..1

+MarketRole 1..1

+In_Domain 1..1 +Out_Domain 1..1

+Time_Period

1..1

+TimeSeries 0..*

+Reason

0..*

+ConnectingLine_RegisteredResource

0..1

+Referenced_DateAndOrTime

0..1

+Dataset_MarketDocument

0..1

+Period 1..*

+Point 1..*

+Reason 0..*

+Reason 0..*

+Domain 0..1

– Page 46 of 58 –





ReportingInformation_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument




794

– Page 47 of 58 –




5.6 Reporting information assembly model 795



798

Figure 15 – Reporting information assembly model 799






class Repor t ing infor mat ion assembly model

«MBIE»

Repor t ingInfor mat ion_Mar ketDocument

+ mRID :ID_String










+ domain.mRID :AreaID_String [0..1]

+ dataset_MarketDocument.mRID :ID_String [0..1]

+ docStatus :Action_Status

+ referenced_DateAndOrTime.date :Date [0..1]

+ referenced_DateAndOrTime.time :Time [0..1]

«MBIE»

TimeSer ies

+ mRID :ID_String






+ measurement_Unit.name :MeasurementUnitKind_String


«MBIE»

Ser ies_Per iod



«MBIE»

Point


+ quantity :Decimal

«MBIE»

Reason



+TimeSeries 0..*

+Period 1..*

+Point 1..*

+Reason 0..*

+Reason

0..*

+Reason 0..*

– Page 48 of 58 –






ReportingInformation_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument



804

5.6.3 Detailed Reporting information assembly model 805

5.6.3.1 ReportingInformation_MarketDocument root class 806


This document provides all the information relating to a status request made by an interested 809 party concerning aggregated netted external schedules, aggregated netted external market 810 schedules, aggregated netted external TSO schedules, compensation program schedules, 811 netted area position schedules and netted area AC position schedules. 812

Table 30 shows all attributes of ReportingInformation_MarketDocument. 813

Table 30 – Attributes of Reporting information assembly 814 model::ReportingInformation_MarketDocument 815


0 [1..1] mRID

ID_String



ESMPVersion_String


2 [1..1] type

MessageKind_String



ProcessKind_String

The identification of the nature of process that the document addresses. --- The Process dealt within the document.


PartyID_String




The identification of the role played by a market player. --- The sender of the document. --- The role associated with a MarketParticipant.


PartyID_String




The identification of the role played by a market player. --- The recipient of the document. --- The role associated with a MarketParticipant.


ESMP_DateTime





– Page 49 of 58 –






AreaID_String

The unique identification of the domain. --- The identification of the domain that is covered in the reporting information market document. Depending on the reporting context it will correspond to one of the following: - a scheduling area; - a scheduling area border; - a control area; - a control area border; - a control block area; - a control block area border; - a synchronous area.

11 [0..1] dataset_MarketDocument.mRID

ID_String

The identification of an individually predefined dataset in a data base system (e. g. Verification Platform). --- The identification of information in the reporting information market document that is related to a predefined dataset.

12 [1..1] docStatus

Action_Status

The identification of the condition or position of the document with regard to its standing. A document may be intermediate or final.

13 [0..1] referenced_DateAndOrTime.date

Date

The date as "YYYY-MM-DD", which conforms with ISO 8601. --- The reference date and time for which the reporting information market document information is to be provided.

14 [0..1] referenced_DateAndOrTime.time

Time

The time as "hh:mm:ss.sssZ", which conforms with ISO 8601. --- The reference date and time for which the reporting information market document information is to be provided.

816

Table 31 shows all association ends of ReportingInformation_MarketDocument with other 817 classes. 818

Table 31 – Association ends of Reporting information assembly 819 model::ReportingInformation_MarketDocument with other classes 820


Description


TimeSeries

The time series that is associated with an electronic document. Association Based On : Reporting information contextual model::ReportingInformation_MarketDocument.[] ----- Reporting information contextual model::TimeSeries.TimeSeries[0..*]

16 [0..*] Reason

Reason

The Reason associated with the electronic document header providing different motivations for the creation of the document. Association Based On : Reporting information contextual model::ReportingInformation_MarketDocument.[] ----- Reporting information contextual model::Reason.Reason[0..*]

821

5.6.3.2 Point 822



– Page 50 of 58 –




Table 32 – Attributes of Reporting information assembly model::Point 825


Description

0 [1..1] position

Position_Integer


1 [1..1] quantity

Decimal

The principal quantity identified for a point. The quantity of the product scheduled for the position within the time interval.

826

Table 33 shows all association ends of Point with other classes. 827

Table 33 – Association ends of Reporting information assembly model::Point with other 828 classes 829


2 [0..*] Reason

Reason

The Reason information associated with a Point providing motivation information. Association Based On : Reporting information contextual model::Point.[] ----- Reporting information contextual model::Reason.Reason[0..*]

830

5.6.3.3 Reason 831

The motivation of an act. 832

Table 34 shows all attributes of Reason. 833

Table 34 – Attributes of Reporting information assembly model::Reason 834


0 [1..1] code

ReasonCode_String

The motivation of an act in coded form.

1 [0..1] text

ReasonText_String

The textual explanation corresponding to the reason code.

835




Table 35 – Attributes of Reporting information assembly model::Series_Period 839


Description

0 [1..1] resolution

Duration





840


– Page 51 of 58 –




Table 36 – Association ends of Reporting information assembly model::Series_Period 842 with other classes 843


2 [1..*] Point

Point

The Point information associated with a given Series_Period.within a TimeSeries. Association Based On : Reporting information contextual model::Series_Period.[] ----- Reporting information contextual model::Point.Point[1..*]

844



In the ESMP profile, the TimeSeries provides not only time-ordered quantities but also time-847 ordered information. 848


Table 37 – Attributes of Reporting information assembly model::TimeSeries 850


0 [1..1] mRID

ID_String



BusinessKind_String

The identification of the nature of the time series.

2 [1..1] product




AreaID_String



AreaID_String



ResourceID_String

The unique identification of a resource. --- The identification of the DC link(s) or controllable AC link(s) between areas.

6 [1..1] measurement_Unit.name


The identification of the formal code for a measurement unit (UN/ECE Recommendation 20). --- The unit of measure associated with the quantity in the point class.

7 [1..1] curveType

CurveType_String


851


Table 38 – Association ends of Reporting information assembly model::TimeSeries with 853 other classes 854


Description


Period

The time interval and resolution for a period associated with a TimeSeries. Association Based On : Reporting information contextual model::TimeSeries.[] ----- Reporting information contextual model::Series_Period.Period[1..*]

– Page 52 of 58 –





Description

9 [0..*] Reason

Reason

The reason information associated with a TimeSeries providing motivation information. Association Based On : Reporting information contextual model::TimeSeries.[] ----- Reporting information contextual model::Reason.Reason[0..*]

855

5.6.4 Datatypes 856

The list of datatypes used for the Reporting information assembly model is as follows: 857

Action_Status compound 858















ReasonCode_String datatype, codelist ReasonCodeTypeList 873

ReasonText_String datatype 874


Status_String datatype, codelist StatusTypeList 876


878

– Page 53 of 58 –




6 XML schema 879

6.1 Schema structure 880

6.1.1 Reporting market document schema 881

882

– Page 54 of 58 –




883

– Page 55 of 58 –




6.1.2 reporting status market document schema 884

885

– Page 56 of 58 –




886

– Page 57 of 58 –




6.1.3 Reporting information market document 887

888

– Page 58 of 58 –




889

6.2 Schema description 890

Refer to the provided XSD files for details. 891

Documents

ENTSO-E RG CE IMPLEMENTATION GUIDE · 105 Figure 4 – ENTSO-E RG CE schedule reporting process for compensation schedules ... 144 model::ReportingStatus_MarketDocument with other