OUTAGE BUSINESS PROCESS AND FORMAT - … · 30 18.3 Detailed Network element maintenance scheduling ... Main activities under the definition of outage ... ENTSO-E Outage Business

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

2017-10-27 VERSION 1.0

OUTAGE BUSINESS PROCESS AND FORMAT

– Page 2 of 64 –

European Network of Transmission System Operators for Electricity

ENTSO-E Outage Business Process and Format VERSION 1.0


Table of Contents 2

1 Objective ......................................................................................................................... 8 3

2 Glossary .......................................................................................................................... 9 4

3 Abbreviations .................................................................................................................. 9 5

4 Business process overview ............................................................................................ 10 6

5 Requirements from the OPS .......................................................................................... 12 7

6 Roles and Responsibilities ............................................................................................. 13 8

6.1 TSO(s) ............................................................................................................. 13 9

6.2 DSO/CDSO ...................................................................................................... 14 10

6.3 Facility Owner .................................................................................................. 14 11

6.4 Regional Security Coordinator ......................................................................... 15 12

6.5 Outage Planning Agent .................................................................................... 15 13

6.6 NRAs ............................................................................................................... 15 14

7 High Level Business Process Description ...................................................................... 16 15

8 Definition of Outage coordination regions and relevant assets ....................................... 16 16

9 Development and update of availability plans of relevant assets .................................... 18 17

10 Execution of availability plans ........................................................................................ 24 18

11 Sequence diagram for planned/unplanned unavailabili ties ............................................. 28 19

12 Outage Schedule document ........................................................................................... 29 20

13 Examples of outages ..................................................................................................... 31 21

14 Element information ....................................................................................................... 33 22

15 Examples element information ....................................................................................... 35 23

16 Outage scheduling document contextual model ............................................................. 37 24

16.1 Overview of the model ..................................................................................... 37 25

17 IsBasedOn relationships from the European style market profile .................................... 37 26

18 Outage scheduling document assembly model............................................................... 39 27


18.2 IsBasedOn relationships from the European style market profile ...................... 40 29

18.3 Detailed Network element maintenance scheduling document assembly 30 model .............................................................................................................. 40 31

OutageSchedule_MarketDocument root class ................................. 40 32

Alternative_RegisteredResource ..................................................... 41 33

Reason ........................................................................................... 41 34

RegisteredResource ....................................................................... 42 35

SwitchedBack_Time_Period ........................................................... 43 36

TimeSeries ..................................................................................... 43 37

19 Network outage configuration contextual model ............................................................. 47 38



20 Network outage configuration assembly model .............................................................. 49 41



20.3 Detailed Network outage configuration assembly model ................................... 50 44

Ref_MarketDocument root class ..................................................... 50 45

Domain ........................................................................................... 51 46

– Page 3 of 64 –




Other_MarketParticipant ................................................................. 51 47

Specific_RegisteredResource ......................................................... 51 48

TimeSeries ..................................................................................... 52 49

21 Primitives and Datatypes ............................................................................................... 56 50

21.1 Primitives ......................................................................................................... 56 51

Date primitive ................................................................................. 56 52

DateTime primitive .......................................................................... 56 53

Decimal primitive ............................................................................ 56 54

Duration primitive ........................................................................... 56 55

Float primitive ................................................................................. 56 56

String primitive ............................................................................... 56 57

22 Datatypes ...................................................................................................................... 56 58

22.1 ESMP_DateTimeInterval compound ................................................................. 56 59

22.2 AreaID_String datatype .................................................................................... 56 60

22.3 BusinessKind_String datatype.......................................................................... 57 61

22.4 Characters200_String datatype ........................................................................ 57 62

22.5 ESMP_DateTime datatype ............................................................................... 58 63

22.6 ESMP_Voltage datatype .................................................................................. 58 64

22.7 ESMPBoolean_String datatype ........................................................................ 59 65

22.8 ESMPVersion_String datatype ......................................................................... 59 66

22.9 ID_String datatype ........................................................................................... 59 67

22.10 MarketRoleKind_String datatype ...................................................................... 60 68

22.11 MeasurementUnitKind_String datatype ............................................................ 60 69

22.12 MessageKind_String datatype .......................................................................... 60 70

22.13 PartyID_String datatype ................................................................................... 61 71

22.14 ProcessKind_String datatype ........................................................................... 61 72

22.15 PsrType_String datatype .................................................................................. 61 73

22.16 ReasonCode_String datatype........................................................................... 62 74

22.17 ReasonText_String datatype ............................................................................ 62 75

22.18 ResourceID_String datatype ............................................................................ 62 76

22.19 Status_String datatype ..................................................................................... 63 77

22.20 UnitSymbol datatype ........................................................................................ 63 78

22.21 YMDHM_DateTime datatype ............................................................................ 63 79

80

List of figures 81

Figure 1: High Level Business Process Flowchart Overview .................................................. 11 82

Figure 2: Step 1-Definition and Assessment of the relevant asset lists .................................. 18 83

Figure 3: Planning of Assets Availability ............................................................................... 24 84

Figure 4: Execution of Availability Plans ............................................................................... 27 85

Figure 5: submission process for planned/unplanned unavailabilities .................................... 28 86

Figure 6: submission process for element update information ............................................... 33 87

Figure 7: Network element maintenance scheduling document contextual model .................. 37 88

Figure 8: Network element maintenance scheduling document assembly model .................... 39 89

Figure 9: Network outage configuration contextual model ..................................................... 47 90

Figure 10: Network outage configuration assembly model ..................................................... 49 91

92

– Page 4 of 64 –




List of tables 93

Table 1 – Steps of business process ..................................................................................... 10 94

Table 2 - Main activities under the definition of outage coordination regions and 95 relevant assets step .............................................................................................................. 16 96

Table 3 - Main activities under the development and update of availability plans of 97 relevant assets step .............................................................................................................. 19 98

Table 4 - Main activities under the execution of availability plans step .................................. 25 99

Table 5 - OutageSchedule Market Document ........................................................................ 30 100

Table 6 - create planned outage ........................................................................................... 31 101

Table 7 - modification planned unavailability ......................................................................... 32 102

Table 8 - Ref_MarketDocument ............................................................................................ 34 103

Table 9 - illustrates creation of a new element by TSO PSE. ................................................. 35 104

Table 10 - update / modification des Elements ...................................................................... 36 105

Table 11 - delete “interesting for” Information TSO TenneT NL ............................................. 36 106

Table 12 - IsBasedOn dependency ....................................................................................... 37 107


Table 14 - Attributes of Network element maintenance scheduling document assembly 109 model::OutageSchedule_MarketDocument ............................................................................ 40 110

Table 15 - Association ends of Network element maintenance scheduling document 111 assembly model::OutageSchedule_MarketDocument with other classes ............................... 41 112

Table 16 - Attributes of Network element maintenance scheduling document assembly 113 model::Alternative_RegisteredResource ............................................................................... 41 114

Table 17 - Attributes of Network element maintenance scheduling document assembly 115 model::Reason ...................................................................................................................... 42 116

Table 18 - Attributes of Network element maintenance scheduling document assembly 117 model::RegisteredResource .................................................................................................. 42 118

Table 19 - Attributes of Network element maintenance scheduling document assembly 119 model::SwitchedBack_Time_Period ...................................................................................... 43 120

Table 20 - Attributes of Network element maintenance scheduling document assembly 121 model::TimeSeries ................................................................................................................ 43 122

Table 21 - Association ends of Network element maintenance scheduling document 123 assembly model::TimeSeries with other classes.................................................................... 46 124



Table 24 - Attributes of Network outage configuration assembly 127 model::Ref_MarketDocument ................................................................................................ 50 128

Table 25 - Association ends of Network outage configuration assembly 129 model::Ref_MarketDocument with other classes ................................................................... 51 130

Table 26 - Attributes of Network outage configuration assembly model::Domain ................... 51 131

Table 27 - Attributes of Network outage configuration assembly 132 model::Other_MarketParticipant ............................................................................................ 51 133

Table 28 - Attributes of Network outage configuration assembly 134 model::Specific_RegisteredResource .................................................................................... 51 135

Table 29 - Attributes of Network outage configuration assembly model::TimeSeries ............. 52 136

Table 30 - Association ends of Network outage configuration assembly 137 model::TimeSeries with other classes ................................................................................... 55 138

Table 31 - Attributes of ESMPDataTypes::ESMP_DateTimeInterval ...................................... 56 139

– Page 5 of 64 –




Table 32 - Attributes of ESMPDataTypes::AreaID_String ...................................................... 57 140

Table 33 - Restrictions of attributes for ESMPDataTypes::AreaID_String .............................. 57 141

Table 34 - Attributes of ESMPDataTypes::BusinessKind_String ............................................ 57 142

Table 35 - Attributes of ESMPDataTypes::Characters200_String .......................................... 57 143

Table 36 - Restrictions of attributes for ESMPDataTypes::Characters200_String .................. 57 144

Table 37 - Attributes of ESMPDataTypes::ESMP_DateTime .................................................. 58 145

Table 38 - Restrictions of attributes for ESMPDataTypes::ESMP_DateTime ......................... 58 146

Table 39 - Attributes of ESMPDataTypes::ESMP_Voltage ..................................................... 58 147

Table 40 - Restrictions of attributes for ESMPDataTypes::ESMP_Voltage ............................. 58 148

Table 41 - Attributes of ESMPDataTypes::ESMPBoolean_String ........................................... 59 149

Table 42 - Attributes of ESMPDataTypes::ESMPVersion_String ............................................ 59 150

Table 43 - Restrictions of attributes for ESMPDataTypes::ESMPVersion_String ................... 59 151

Table 44 - Attributes of ESMPDataTypes::ID_String ............................................................. 60 152

Table 45 - Restrictions of attributes for ESMPDataTypes::ID_String ..................................... 60 153

Table 46 - Attributes of ESMPDataTypes::MarketRoleKind_String ........................................ 60 154

Table 47 - Attributes of ESMPDataTypes::MeasurementUnitKind_String ............................... 60 155

Table 48 - Attributes of ESMPDataTypes::MessageKind_String ............................................ 60 156

Table 49 - Attributes of ESMPDataTypes::PartyID_String ..................................................... 61 157

Table 50 - Restrictions of attributes for ESMPDataTypes::PartyID_String ............................. 61 158

Table 51 - Attributes of ESMPDataTypes::ProcessKind_String.............................................. 61 159

Table 52 - Attributes of ESMPDataTypes::PsrType_String .................................................... 61 160

Table 53 - Attributes of ESMPDataTypes::ReasonCode_String ............................................. 62 161

Table 54 - Attributes of ESMPDataTypes::ReasonText_String .............................................. 62 162

Table 55 - Restrictions of attributes for ESMPDataTypes::ReasonText_String ...................... 62 163

Table 56 - Attributes of ESMPDataTypes::ResourceID_String ............................................... 62 164

Table 57 - Restrictions of attributes for ESMPDataTypes::ResourceID_String ....................... 63 165

Table 58 - Attributes of ESMPDataTypes::Status_String ....................................................... 63 166

Table 59 - Attributes of ESMPDataTypes::UnitSymbol .......................................................... 63 167

Table 60 - Attributes of ESMPDataTypes::YMDHM_DateTime .............................................. 63 168

Table 61 - Restrictions of attributes for ESMPDataTypes::YMDHM_DateTime ...................... 64 169

170

171

– Page 6 of 64 –




Copyright notice: 172

Copyright © ENTSO-E. All Rights Reserved. 173

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

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

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

Maintenance notice: 186

This document is maintained by the ENTSO-E WG EDI. Comments or remarks are to be 187 provided at [email protected] 188

mailto:[email protected]

– Page 7 of 64 –




Revision History 189

Version Release Date Comments

1.0 0 2017-09-20 First version

190

– Page 8 of 64 –




1 Objective 191

SO GL requires TSOs to establish a common medium- and long-term outage planning process 192 based on predefined standards with the following key objectives: 193

• ENTSO-E wide harmonization of regionally differing outage planning processes 194

• Harmonised data format for data exchange, which shall be an integral part of the ENTSO 195 for Electricity operational planning data environment 196

– Page 9 of 64 –




2 Glossary 197

ENTSO-E Glossary: see https://www.entsoe.eu/data/data-portal/glossary/Pages/home.aspx 198

3 Abbreviations 199

200

CC region ‘capacity calculation region’ means the geographic area in which coordinated capacity calculation is applied; (Regulation (EU) No 2015/1222)

CDSO Closed Distribution System Operator

DSO Distribution System Operator

FO Facility Owner

SO GL Guideline on electricity transmission system operation

NC Network Code

NRA

National Regulatory Authority

OCR

Outage Coordination Region

OPA Outage Planning Agent

OPDE Operational Planning Data Environment

OPI Outage Planning Incompatibilities

OPS Operational Planning and Scheduling

OWN

owners of the relevant power generating modules and the relevant demand facilities

RSC

Regional Security Coordinator

RSCSP Regional Security Coordinator Service Provider

SGU

Significant Generation Unit

SO System Operator

TSO Transmission System Operator

201

https://www.entsoe.eu/data/data-portal/glossary/Pages/home.aspx

– Page 10 of 64 –




4 Business process overview 202

Each TSO participates in the outage planning and coordination in accordance with the principles 203 described in the OPS (SO GL) in order to monitor the availability status of its relevant assets 204 and coordinate their availability plans to ensure the operational security of the transmissio n 205 system. 206

The Outage Planning and Coordination process consists of the following steps: 207

• Definition of Outage Coordination Regions and relevant assets 208

• Development and update of availability plans of relevant assets 209

• Execution of availability plans 210

A brief description of the aforementioned steps of the Business Process is provided in the next 211 table. 212

Table 1 – Steps of business process 213

STEPS Brief Description

Definition of Outage Coordination Regions and

relevant assets

In this step, TSOs ensure their participation in the outage planning of a specific outage coordination region. Within the Outage Coordination Region, a Regional Security Coordinator (RSC) is appointed and his role is to facilitate, coordinate and perform tasks and provide recommendations for the outage planning process. Next, all TSOs shall jointly develop a methodology at least per synchronous area for the assessment of relevant assets (if not available) and use it to define a common single list of relevant assets.

Development and update of availability plans of relevant

assets

In this step, it shall first appoint Outage Planning Agents (OPA), with the task of planning the availability status of the relevant grid elements: each TSO shall act as the OPA for each relevant grid element it operates, for all other relevant assets, the owner shall appoint (or act as) the OPA. TSOs and OPAs shall then assess the indicative yearly availability plans and provide availability plans proposals for the relevant assets. Next, all TSOs shall assess whether outage planning incompatibilities (OPI) arise from the availability plans. In case of OPIs, all relevant parties should be informed and find a solution to eliminate the OPIs. Once no OPIs remain, the preliminary availability plans can be submitted, validated and then finalized (update in the time between the finalisation of the year-ahead outage coordination and before its real-time execution is also possible.)

Execution of availability plans

When it comes to the real-time execution of the availability plans all parties apply the outage planning. Postponement of outage is also possible in case of forced outages or in case a TSO identifies that an outage can lead the transmission system to a not secure state. Due to the change of the network condition forecasted previously.

214

A high level overview of the Coordinated Outage Planning Process is presented in chapter 13,Examples 215

of Outages. 216

217

– Page 11 of 64 –




218 Figure 1: High Level Business Process Flowchart Overview 219

220

221

TSOsDSO/CDSO/Facility

OwnersRSC OPDE NRAs

START

DefineOutageCoordinationRegions(OCR)andRegionalSecurityCoordinators(RSC)

ProvidetotheRSCsAvailabilityPlansandScenariosforoutage

coordination(takingintoaccountbilateralTSO

coordinationfortie-lines)

Performregionaloperationalsecurity

analyses incoordinationwithotherRSC

ConfirmtheOPIsandtheproposedsolutions

OPIs?

FinalAvailabilityPlans

END

NeedforUpdate?

PreparealternativeAvaialbilityPlansand

Scenarios

ExecutionofAvaialbilityPlans

Yes

No

Yes No

Definecommon listofrelevantassets

Developmentandupdateofavailabilityplansofrelevantassets

Definitionofoutagecoordinationregions andrelevantassets

Executionofavailabilityplans

PerformQualityCheckofavailabilityplan

(relevantassets&timeframe)

Valid?Update inputdatabasedonqualitycheckreport

Yes

No

DetectOPIs&proposesolutions

– Page 12 of 64 –




5 Requirements from the OPS 222

Prior to the outage planning and coordination process, a series of necessary requirements from the 223

OPS (SO GL) have to be fulfilled. 224

First of all, Outage Coordination Regions and Regional Security Coordinators have to be defined and 225

established. This is indeed a requirement, however, is also part of the process itself in case there is the 226

need to update and adjust the regions and the coordinators. 227

In addition, all TSOs and all other relevant roles, shall provide to the regional security coordinator all 228

the information necessary to detect and solve regional outage incompatibilities. If necessary, regional 229

security coordinator shall coordinate its analyses with other regional security coordinators. 230

Moreover, in order to achieve a regional coordination, all TSOs of an outage coordination region shall 231

jointly develop a regional coordination operational procedure, aimed at establishing operational 232

aspects for the implementation of the outage coordination in each region, which includes: 233

• frequency, scope and type of coordination for, at least, the year-ahead and week-ahead 234

timeframes 235

• practical arrangements for the provision of the year-ahead relevant grid element availability 236

plans by all TSOs of the outage coordination region. 237

Each TSO shall participate in the outage coordination process of its outage coordination region and 238

apply the established regional coordination operational procedures. 239

To further facilitate the coordination, each TSO shall provide to the other TSOs, DSOs, facility owners 240

from the same outage coordination region or regions all relevant information at its disposal on the 241

infrastructure projects related to the transmission system, distribution system, closed distribution 242

system, power generating modules, or demand facilities that may have an impact on the operation of 243

the control area of another TSO, DSO, CDSO within the outage coordination region. 244

In order to achieve a common way of assessment, all TSOs shall jointly develop a methodology for each 245

synchronous area, for assessing the relevance for the outage coordination of power generating 246

modules, demand facilities, and grid elements located in a transmission system or in a distribution 247

system, including closed distribution systems. The methodology shall be based on qualitative and 248

quantitative aspects that identify the impact, on a TSO’s control area, of the availability status of each 249

relevant asset, and which are connected directly or indirectly to another TSO’s control area. In 250

particular, the methodology shall be based on: 251

• quantitative aspects based on the evaluation of changes of electrical values (such as voltages, 252

power flows, rotor angle) on at least one grid element of a TSO’s control area, due to the 253

change of availability status of a potential relevant asset located in another control area. That 254

evaluation shall take place on the basis of yearly common grid models. 255

• thresholds on the sensitivity of the electrical values above, against which the relevant assets 256

will be assessed. The thresholds shall be harmonised at least per synchronous area. 257

• capacity of potential relevant power generating modules or demand facilities to qualify as 258

SGUs; 259

• qualitative aspects such as, but not limited to, the size and proximity to the borders of a control 260

area of potential relevant power generating modules, demand facilities or grid elements. 261

• systematic relevance of all grid elements located in a transmission system or in a distribution 262

system which connect different control areas. 263

• systematic relevance of all critical network elements. 264

265

– Page 13 of 64 –




The availability status of a relevant asset shall be one of the following: 266

• “available” where the relevant asset is capable of and ready for providing service regardless of 267

whether it is or not in operation 268

• “unavailable” where the relevant asset is not capable of or ready for providing service 269

• “testing”1 where the capability of the relevant asset for providing service is being tested 270

271

The “testing” status shall only apply when there is a potential impact on the transmission system and 272

for the following time periods: 273

• between first connection and final commissioning of the relevant asset 274

• directly following maintenance of the relevant asset 275

276

Finally, there are additional requirements that have to be fulfilled, like: 277

• communications channels to be used 278

• IT tools and infrastructures 279

• Interoperability issues among the data and files exchanged 280

• Legal issues regarding the availability and security of data, etc 281

However, these are out of the scope of this document and will be only tackled by the relevant 282 parties within the whole project. 283

284

6 Roles and Responsibilities 285

The Outage Planning and Coordination process is a rather complex and time-consuming process in 286

which more than one roles participate. A compilation of the relevant roles and their responsibilities, 287

as these derive from the OPS (GSO GL, Articles 80 and 82-103), is presented below. 288

289

6.1 TSO(s) 290

One of the most crucial roles of the process, is the TSO(s). The TSOs own and operate most of the grid 291

elements, while at the same time are responsible for the security of supply within their area of interest 292

and action. 293

Within the Outage Planning and Coordination Process, their main responsibilities are: 294

• Setup of output coordination regions and regional security coordinators 295

• Develop a regional coordination operational procedure and perform outage coordination in 296

their region 297

• Provide grid scenarios and availability plans of its relevant elements accordingly 298

• Share with other TSOs and other roles all the relevant information at its disposal on the 299

infrastructure projects related to the transmission system, distribution system, closed 300

distribution system, power generating modules, or demand facilities that may have an impact 301

on the operation of the control area of another TSO and role within the outage coordination 302

region 303

1 could be also considered as a special switching state

– Page 14 of 64 –




• Jointly develop a methodology for each synchronous area, for assessing the relevance for the 304

outage coordination of power generating modules, demand facilities, and grid elements 305

located in a transmission system or in a distribution system, including closed distribution 306

systems. 307

• Jointly assess the relevance of grid assets and establish a single list, for each outage 308

coordination region, of relevant assets. 309

• Inform all relevant roles about the single list of relevant assets (TSOs, DSOs, CDSOs, NRAs, 310

ENTSO-E, OPDE, etc). 311

• Coordinate with (C)DSOs the outage planning of internal elements that are part of the (closed) 312

distribution system 313

• Jointly assess the availability plans of the relevant assets and establish a final availability plan 314

of relevant assets for each outage coordination region. 315

• Cope with the outage planning incompatibilities and coordinate to resolve them with the 316

application of the proposed or other solutions (analysis provided by the regional security 317

coordinators) 318

• Inform all relevant roles about the final availability plans of the relevant assets (TSOs, DSOs, 319

CDSOs, NRAs, ENTSO-E OPDE, etc). 320

• Take care of the real time execution of the availability plans of its assets. 321

• Have the decision-making responsibility within Outage Planning and Coordination Process with 322

the important support role of the RSC. 323

324

6.2 DSO/CDSO 325

Similar to TSOs, (C)DSOs also own and/or operate elements in the distribution grid, while at the same 326

time are responsible of the security of supply within their area of interest and action. 327

328


• Plan the availability status of the relevant grid assets for which they perform duties of outage 330

planning agents and that are not interconnecting different control areas 331

• Coordinate with TSOs the outage planning of internal elements that are part of the distribution 332

system 333

• Coordinate with TSOs and Outage Planning Agents to resolve any outage planning 334

incompatibilities 335


337

6.3 Facility Owner 338

The facility owners are the ones who own the power generating and demand facilities, which are some 339

of the key elements of the power grid. 340


• Inform and coordinate with the TSOs and the Outage Planning Agents about the availability of 342

their assets 343


– Page 15 of 64 –




345

6.4 Regional Security Coordinator 346

The regional security coordinator is performing tasks related to TSOs regional coordination, within a 347

capacity calculation region. 348

Within the Outage Planning and Coordination Process, its main responsibilities are: 349

• Prepare an annual report and submit it to ENTSO for Electricity providing information about 350

the number of outage incompatibilities detected during the regional outage coordination 351

• Perform regional outage coordination 352

• Coordinate with other Regional Security Coordinators 353

• Detect and solve regional outage incompatibilities by performing a security assessment and 354

provide the TSOs of the outage coordination region with a list of detected outage planning 355

incompatibilities and the proposed solutions to solve those outage planning incompatibilities 356

357

6.5 Outage Planning Agent 358

The outage planning agent is the entity responsible for planning the availability status of a relevant 359

power generating module, a relevant demand facility or a relevant grid element 360


• The TSO act as the outage planning agent for grid element it operates. 362

• Provide indicative availability plans for its relevant assets. 363

• Provide alternative availability plans for its relevant assets, if requested so by TSOs in case of 364

Outage Planning Incompatibilities 365

• Coordinate with TSOs and DSOs to resolve any outage planning incompatibilities 366

• If needed, launch a procedure for the amendment of the final year-ahead availability plan in 367

the time between the finalisation of the year-ahead outage coordination and before its real-368

time execution 369

• Provide to the TSOs detailed information about all its relevant assets which have a “testing” 370

status 371

• Notify the forced outages of one or more of its relevant assets to the TSO and, if connected to 372

a distribution system or to a closed distribution system, the DSO or the CDSO respectively, as 373

soon as possible following the start of the forced outage (including the reason, the expected 374

duration and if applicable the impact to availability plan of its other relevant assets) 375

376

6.6 NRAs 377

National regulatory authority is a national regulatory authority designated in accordance with Article 378

35(1) of Directive 2009/72/EC of the European Parliament and of the Council of 13 July 2009 379

concerning common rules for the internal market in electricity. 380


• Be informed of the single list of relevant grid assets 382

• Be informed of the availability plans of all relevant grid assets 383

384

– Page 16 of 64 –




7 High Level Business Process Description 385

An overview of the whole process is already presented in chapter 4, Business Process Overview. The 386

individual steps are further described in the next paragraphs. 387

388

8 Definition of Outage coordination regions and relevant assets 389

In order to initiate the Outage Planning and Coordination within an outage coordination region, all the 390

involved parties have to first define all the relevant assets that will take part in the process. The 391

relevant activities are summarized in the following table. 392

393

Activities Responsible

Party

Other

Parties

Deadline/

Frequency

Relevant Articles

SO GL

Definition of Outage Coordination Regions and Regional Security

Coordinators

TSOs RSC

OPA2

- 80

Provision of single list of relevant assets

TSOs NRA

OWN

DSO

CDSO

3 months after the approval of the methodology for defining the relevant assets (PG CSAM)

85, 87

Update of single list of relevant assets

TSOs NRA

OWN

DSO

CDSO

Before 1st of July of each calendar year

86, 88

Table 2 - Main activities under the definition of outage coordination regions and relevant 394 assets step 395 396

Definition of Outage Coordination Regions and Regional Security Coordinators 397

First of all, all TSOs of each capacity calculation region jointly setup a regional security coordinator and 398

establish rules governing its operations or appoint another regional security coordinator to perform a 399

series of tasks, among which the regional outage coordination. Next, the outage coordination regions 400

are defined. In principle, the outage coordination regions within which the TSOs proceed to outage 401

coordination are at least equal to the capacity calculation regions. The TSOs of two or more outage 402

coordination regions can agree to merge them into one unique outage coordination region. 403

Provision of single list of relevant assets 404

TSOs apply the commonly developed methodology for assets relevance evaluation and establish a 405

single list, for each outage coordination region, of relevant assets for the outage coordination. TSOs 406

make available the list of relevant elements of each outage coordination region on the ENTSO for 407

Electricity operational planning data environment (OPDE) and notify at the same time their national 408

regulatory authorities (NRAs). In addition, TSOs also inform all the owners of the elements in the list, 409

such as DSOs, CDSOs, and other facility owners. 410

2 The OPA can be either the TSO, or the (C)DSO, or the Facility Owner, or other. Based on the activity,

different party can be assigned this role.

– Page 17 of 64 –




Update of single list of relevant assets 411

Before 1 July of each calendar year, all TSOs of each outage coordination region jointly re-assess, on 412

the basis of the established methodology, the relevance for the outage coordination of grid elements 413

located in a transmission system or a distribution system including a closed distribution system. Where 414

necessary, all TSOs of an outage coordination region jointly decide to update the list of relevant grid 415

elements of that outage coordination region before 1 August of each calendar year and make the 416

updated list available in the ENTSO for Electricity operational planning data environment and inform 417

all the involved parties. 418

The activities regarding the definition of outage coordination regions and regional security 419

coordinators are presented in the next flowchart (Figure 2). 420

– Page 18 of 64 –




421

Figure 2: Step 1-Definition and Assessment of the relevant asset lists 422 423

9 Development and update of availability plans of relevant assets 424

Following the identification of the relevant elements in the outage planning and coordination process 425

of an outage coordination region, the availability plans of all the relevant assets have to be submitted 426

to the respective TSO(s) of that outage coordination region. The goal is to define the availability plans 427

of all the relevant elements that are considered in the outage planning and coordination for each 428

outage coordination region. The actions to be taken are summarized in the following table. 429

TSOsDSO/CDSO/Facility

OwnersRSC OPDE NRAs

START

Part ofaCCregion?

RSCavailalble?

OCRsMerging?

Initialunique

RSC

EstablishmentorAppointmentofRSC

Mergedunique

RSC

Yes

No

Yes

YesNo

No

DefineListofrelevantassets

EmptyList?

Applymethodologyforassets'relevance

assessment

NeedforUpdate?

Singlecommonlistwithrelevantassets

Informrelevantownerforits assets

inthelist

InformNRASabout thesingle

commonlist

YearlyRe-assessmentof

relevantassets

END

Storageofsinglecommonlistwith

relevantassets

No

Yes

DefinitionofOutageCoordinationRegionsand

RegionalSecurityCoordinators

Provisionofsinglelistofrelevantassets

No

Yes

Updateofsinglelistofrelevantassets

– Page 19 of 64 –





Role

Other

Roles

Deadline/

Frequency

Relevant Articles

SO GL

Appointment of outage planning agents

TSOs OPA, DSOs, CDOs,

NRAs

Before the start of any regional Outage

Coordination

Every year (or more often)

89

Assessment of Long-Term Indicative Plans

TSOs -

2 Years before the year-ahead Outage

Coordination

Repeated every 12 months

93

4,7,15 of Regulation (EU)

No 543/2013

Provision of year-ahead availability plan

proposals OPA TSOs

1st August-initial

1st December-update

Every year

94

Assessment of the availability plans for

Outage Planning Incompatibilities

TSOs RSCs, OPA, DSOs,

CDSOs, NRAs

-

Every year between 1st August and 1st

December

95,96

Provision of preliminary year-ahead

availability plans TSOs

OPA, DSOs, CDSOs

Before 1st November

Every year 97

Validation of year-ahead availability plans

TSOs RSCs, OPA, DSOs,

CDSOs, NRAs

-

Every year between 1st August and 1st

December

80

98

Final year-ahead availability plans

TSOs OPA, DSOs,

CDSOs

Before 1st December

Every year 99

Updates to the final year-ahead availability

plans OPA

RSCs, TSOs, DSOs, CDSOs

Before Real-Time execution

100

Table 3 - Main activities under the development and update of availability plans of 430 relevant assets step 431 432

Appointment of outage planning agents 433

Each TSO acts as the outage planning agent for each relevant grid element it operates. For all other 434

relevant assets, the owner appoints, or acts as, the outage planning agent for the concerned relevant 435

asset and informs the respective TSO about that appointment. 436

437

438

439

– Page 20 of 64 –




Assessment of Long-Term Indicative Plans 440

Two years before the start of any year-ahead outage coordination, each TSO assesses the 441

corresponding indicative availability plans for internal relevant assets, provided by the outage planning 442

agents in accordance with Articles 4, 7 and 15 of Regulation (EU) No 543/2013, and provides its 443

preliminary comments including any detected outage planning incompatibilities, to all affected outage 444

planning agents. Each TSO carries out the assessment every 12 months until the start of the year-ahead 445

outage coordination. 446

447

Provision of year-ahead availability plan proposals 448

Before 1 August of each calendar year, the outage planning agent (other than a TSO taking part in an 449

outage coordination region, a DSO or a CDSO) submits to the TSO(s) taking part in an outage 450

coordination region, and where relevant to the DSO or CDSO, an availability plan covering the following 451

calendar year for each of its relevant assets. 452

In the period between 1 August and 1 December of each calendar year, the outage planning agent has 453

the right to request the TSO(s) to amend the availability plan submitted. The TSO(s) examine the 454

requests for amendment after the year-ahead outage coordination has been finalised: 455

• respecting the order in which the amendment requests were received 456

• following the procedure described in the activity “Updates to the final year-ahead availability 457

plans” 458

459

Assessment of the availability plans for Outage Planning Incompatibilities 460

Each TSO assesses on a year-ahead timeframe whether outage planning incompatibilities arise from 461

the availability plans. When a TSO detects outage planning incompatibilities, it performs the following 462

actions: 463

• inform each affected outage planning agent of the conditions it shall fulfil to mitigate the 464

detected outage planning incompatibilities 465

• the TSO may request that one or more outage planning agents submit an alternative 466

availability plan fulfilling the aforementioned conditions 467

• the TSO repeats the assessment to determine whether any outage planning incompatibilities 468

remain 469

470

Following a TSO’s request, if the outage planning agent fails to submit an alternative availability plan 471

aimed at mitigating all outage planning incompatibilities, the TSO develop an alternative availability 472

plan which: 473

• takes into account the impact reported by the affected outage planning agents as well as the 474

DSO or CDSO where relevant 475

• limits the changes in the alternative availability plan to what is strictly necessary to mitigate 476

the outage planning incompatibilities 477

• notifies its national regulatory authority, the affected DSOs and CDSOs if any, and the affected 478

outage planning agents about the alternative availability plan, including the reasons for 479

developing it, as well as the impact reported by the affected outage planning agents and, 480

where relevant, the DSO or CDSO. 481

482

Provision of preliminary year-ahead availability plans 483

– Page 21 of 64 –




Before 1 November of each calendar year, each TSO provides to all other TSOs, via the ENTSO for 484

Electricity operational planning data environment, the preliminary year-ahead availability plans for the 485

following calendar year relative to all the internal relevant assets. Additionally, each TSO provides the 486

DSO and/or CDSO the preliminary year-ahead availability plan for every internal relevant asset located 487

in the distribution and/or closed distribution system 488

489

Validation of year-ahead availability plans 490

Each TSO analyses whether any outage planning incompatibility arises when taking into account all the 491

preliminary availability plans on a year-ahead timeframe. If a TSO detects an outage planning 492

incompatibility, the involved TSOs of the outage coordination region(s) concerned jointly identify a 493

solution in coordination with the concerned outage planning agents, DSOs and CDSOs, using the means 494

at their disposal, while respecting to the extent possible the availability plans submitted by outage 495

planning agents (which are neither a TSO taking part in an outage coordination region, nor a DSO or a 496

CDSO). 497

In case solution is identified, all TSOs of the concerned outage coordination region(s) update and 498

validate the year-ahead availability plans for all relevant assets. 499

In case no solution is identified, each TSO takes the following actions: 500

• forces to “available” all the “unavailable” or “testing” statuses for the internal relevant assets 501

involved in an outage planning incompatibility during the period concerned 502

• notifies the actions taken to the relevant national regulatory authorities, the affected DSOs or 503

CDSOs, if any, and the affected outage planning agents of the actions taken including the 504

rationale for such actions, the impact reported by affected outage planning agents and the 505

DSO or CDSO where relevant 506

Consequently, all TSOs of the concerned outage coordination regions update and validate the year-507

ahead availability plans for all relevant assets 508

509

Final year-ahead availability plans 510

Before 1 December of each calendar year, each TSO: 511

• finalises the year-ahead outage coordination of internal relevant assets 512

• finalises the year-ahead availability plans for internal relevant assets and upload them on the 513

ENTSO for Electricity operational planning data environment 514

At the same time each TSO provides to its outage planning agent, DSO and CDSO the final year-ahead 515

availability plan for each internal relevant asset. 516

517

Updates to the final year-ahead availability plans 518

The outage planning agent and/or a TSO are able to launch a procedure for the amendment of the final 519

year-ahead availability plan (for the assets they act as outage planning agent) in the time between the 520

finalisation of the year-ahead outage coordination and before its real-time execution. 521

In case of a request for amendment by the outage planning agent, the following actions take place: 522

• the recipient TSO acknowledges the request and assesses as soon as reasonably practicable 523

whether the amendment leads to outage planning incompatibilities 524

• in case outage planning incompatibilities are detected, the involved TSOs of the outage 525

coordination region jointly identify a solution in coordination with the outage planning agents 526

concerned and if relevant, the DSOs and CDSOs, using the means at their disposal 527

– Page 22 of 64 –




• in case no outage planning incompatibility has been detected or if no outage planning 528

incompatibility remains after coordination among the relevant parties, the recipient TSO 529

validates the requested amendment, and the TSOs concerned consequently notify all affected 530

parties, and update the final year-ahead availability plan on the ENTSO for Electricity 531

operational planning data environment 532

• in case no solution is found for outage planning incompatibilities the receiving TSO rejects the 533

requested amendment. 534

535

In case of a request for amendment by a TSO, the following actions take place: 536

• the requesting TSO prepares a proposal for amendment to the year-ahead availability plan, 537

including an assessment of whether it could lead to outage planning incompatibilities and 538

submits its proposal to all other TSOs of its outage coordination region(s) 539

• in case outage planning incompatibilities are detected, the involved TSOs of the outage 540

coordination region jointly identify a solution in coordination with the concerned outage 541

planning agents and, if relevant the DSOs and the CDSOs, using the means at their disposal 542

• in case no outage planning incompatibility has been detected or if a solution to an outage 543

planning incompatibility is found, the concerned TSOs validate the requested amendment and 544

consequently they notify all affected parties, and update the final year-ahead availability plan 545

on the ENTSO for Electricity operational planning data environment. 546

• In case no solution to outage planning incompatibilities are found, the requesting TSO retracts 547

the procedure for amendment 548

549

– Page 23 of 64 –




The activities regarding the development and update of availability plans of relevant assets are 550

presented in the next flowchart (Figure 3). 551

552

553

554 555

556 557 558 559 560 561

562

TSOs DSO/CDSO/FacilityOwners RSC OPDE NRAs

START

Retrieve ListofRelevantElementsandtheirIndicativeAvailabilityPlans

AppointmentofOutagePlanningAgents(OPA)

IndicativeAvailability Plans

Singlecommonlistwithrelevant

OutagePlanningAgent(OPA)

ListofRelevantElementsandtheirIndicativeAvailabilityPlans

Assess OutagePlanningIncompatibilities(OPI)basedonRSCinputs

Incompa-tibilities?

CoordinatewithOPAsaboutthefullfillmentconditionsinorderto

mitigatetheOPIs

Providealternativeplanninginordertofullfillthemitigationsconditions

alternativeplanprovided?

TSOs todevelopalternativeavailabilityplanningtomitigate theOPIs

Informationaboutthedevelopmentof

alternative planningandthereasonsbehind





PlanavailabilitystatusfortheelementsforwhichtheyactasOPAPlanavailability statusfortheelementsfor

whichtheyactasOPA

ProvidePreliminary AvailablityPlans PreliminaryAvailablityPlans

AnalyzeOPIsfor allAvailabilityPlans

GridScenariosforOutage Planning

TSOs jointlyvalidatetheavailabilityplansforalltherelevantassets

Incompa-tibilities?

IdentifysolutionsforOPI

SolutionFound?

ForceAvailabilityStatus to"available"InformaboutAvailabilityStatus to"availavle" InofrmaboutAvailabilityStatus to"available"

FInalise theAvailablityPlansandInformallrelevantparties

Send toTSO(s)arequestforamendmentoftheavaialbilityplans

AcknowledgetheRequestfor

Amedment

Incompa-tibilities?

Request forUpdate/Amendment?

TSOrequest?

AnalyzeOPIsfor theamendedavailabilityplans

SolutionFound?

Reject/Cancel theamendmentrequest

Proposeamendmend

availabilityplans

END

PerformRegionalSecurityAssessmentand

ProposeSolutions

PerformRegionalSecurityAssessment

andProposeSolutions


andProposeSolutions

Yes No

Yes No

Yes

No

No

Yes

FInalAvailabilityPlans



PreliminaryAvailablityPlans


Validate theAmendmentandUpdatetheFinalAvailablityPlans

FInalandUpdatedAvailabilityPlans





Appointment ofOutagePlannningAgents

AssessmentofLong-TermIndicativePlansProvisionofyear-aheadavailabilityplanproposals

AssessmentoftheavailabilityplansforOutagePlanningIncompatibilities

Provisionofpreliminaryyear-aheadavailabilityplans

Validationofyear-aheadavailabilityplans

Finalyear-aheadavailabilityplans

Updatestothefinalyear-aheadavailabilityplans

YesNo

Yes

No

No

Yes

-availability plans-gridscenarios

-qualitycheck


-qualitycheck

PerformQuality Checkofavailabilityplan(relevant

assets&timeframe)

IndicativeAvailablityPlans

No

Yes

– Page 24 of 64 –




563 Figure 3: Planning of Assets Availability 564

565

Note 1: overlapping of process boxes means that more than one roles are involved in the respective 566

process 567

Note 2: RSCs may be involved in the activities of OPI detection, therefore highlighted with a dashed 568

line 569

10 Execution of availability plans 570

In this final step the goal is the execution of the availability plans of all the relevant elements that were 571

considered in the outage planning and coordination for each outage coordination region. The actions 572

TSOs DSO/CDSO/FacilityOwners RSC OPDE NRAs

START

Retrieve ListofRelevantElementsandtheirIndicativeAvailabilityPlans

AppointmentofOutagePlanningAgents(OPA)

IndicativeAvailability Plans

Singlecommonlistwithrelevant


ListofRelevantElementsandtheirIndicativeAvailabilityPlans

Assess OutagePlanningIncompatibilities(OPI)basedonRSCinputs

Incompa-tibilities?

CoordinatewithOPAsaboutthefullfillmentconditionsinorderto

mitigatetheOPIs

Providealternativeplanninginordertofullfillthemitigationsconditions

alternativeplanprovided?

TSOs todevelopalternativeavailabilityplanningtomitigate theOPIs







PlanavailabilitystatusfortheelementsforwhichtheyactasOPAPlanavailability statusfortheelementsfor

whichtheyactasOPA

ProvidePreliminary AvailablityPlans PreliminaryAvailablityPlans

AnalyzeOPIsfor allAvailabilityPlans

GridScenariosforOutage Planning

TSOs jointlyvalidatetheavailabilityplansforalltherelevantassets

Incompa-tibilities?


SolutionFound?

ForceAvailabilityStatus to"available"InformaboutAvailabilityStatus to"availavle" InofrmaboutAvailabilityStatus to"available"

FInalise theAvailablityPlansandInformallrelevantparties

Send toTSO(s)arequestforamendmentoftheavaialbilityplans

AcknowledgetheRequestfor

Amedment

Incompa-tibilities?

Request forUpdate/Amendment?

TSOrequest?

AnalyzeOPIsfor theamendedavailabilityplans

SolutionFound?

Reject/Cancel theamendmentrequest

Proposeamendmend

availabilityplans

END

PerformRegionalSecurityAssessmentand

ProposeSolutions


andProposeSolutions


andProposeSolutions

Yes No

Yes No

Yes

No

No

Yes




PreliminaryAvailablityPlans


Validate theAmendmentandUpdatetheFinalAvailablityPlans






Appointment ofOutagePlannningAgents

AssessmentofLong-TermIndicativePlansProvisionofyear-aheadavailabilityplanproposals

AssessmentoftheavailabilityplansforOutagePlanningIncompatibilities

Provisionofpreliminaryyear-aheadavailabilityplans

Validationofyear-aheadavailabilityplans

Finalyear-aheadavailabilityplans

Updatestothefinalyear-aheadavailabilityplans

YesNo

Yes

No

No

Yes


-qualitycheck


-qualitycheck

PerformQuality Checkofavailabilityplan(relevant

assets&timeframe)

IndicativeAvailablityPlans

No

Yes

– Page 25 of 64 –




to be taken to are summarized in the following table. It is important to mention that all of the details 573

regarding the execution of availability plans are directly taken from the OPS (SO GL) and it is up to TSOs 574

to align on a common interpretation and level of detail for the requested activities. 575

576


Role

Other

Roles

Deadline/

Frequency

Relevant Articles

SO GL

Information about the elements with “testing”

status

OPA TSOs, DSOs,

CDSOs, Facility Owners

At least one month before the

execution of the availability plans

101

Handling of Forced Outages

TSOs, OPA DSOs, CDSOs, Facility

Owners, NRAs,

During the execution of

availability plans

102

Real-time execution of the availability plans

All - During the execution of

availability plans

103

Table 4 - Main activities under the execution of availability plans step 577

578

579

Information about the elements with “testing” status 580

The outage planning agent of a relevant asset the availability status of which has been declared as 581

"testing" provides the TSO, and if connected to a distribution system including closed distribution 582

systems, the DSO or the CDSO within one month before the start of the “testing” status with: 583

• a detailed test plan 584

• an indicative generation or consumption schedule if the concerned relevant asset is a relevant 585

power generating module or a relevant demand facility 586

• changes to the topology of the transmission system or distribution system if the concerned 587

relevant asset is a relevant grid element 588

The outage planning agent updates this information soon as it is subject to any change. The TSO of a 589

relevant asset, the availability status of which has been declared as "testing", provides the information 590

received by the outage planning agent to all other TSOs of its outage coordination region(s), upon their 591

request. In case the relevant asset is a relevant grid element interconnecting two or more control 592

areas, the TSOs of the concerned control areas agree on the information to be provided. 593

594

Handling of Forced Outages 595

Each TSO assesses the cases where a forced outage endangers its operational security and makes sure 596

that the “available” or “unavailable” status of other relevant assets in its control area can be changed 597

to “unavailable” or “available” respectively. This is valid only where no agreement is reached with 598

outage planning agents regarding solutions to forced outages. The TSO notifies then the national 599

regulatory authority accordingly. 600

The outage planning agent notifies the forced outage of one or more of its relevant assets to the TSO 601

and, if connected to a distribution system or to a closed distribution system, the DSO or the CDSO 602

respectively, as soon as possible following the start of the forced outage. 603

– Page 26 of 64 –




When notifying the forced outage, the outage planning agent provides the following information: 604

• the reason for the forced outage 605

• the expected duration of the forced outage 606

• where applicable, the impact of the forced outage on the availability status of other relevant 607

assets for which it is the outage planning agent. 608

In case a TSO detects that one or several forced outages could lead the transmission system out of the 609

normal state, it informs the affected outage planning agent(s) about the time-limit at which 610

operational security can no longer be maintained unless their relevant asset(s) in forced outage returns 611

to “available” status. The outage planning agents inform the TSO whether they are capable of 612

respecting that time-limit and provide reasoned justifications where they are unable to respect that 613

time-limit. 614

In case of any amendments to the availability plan due to forced outages, the concerned TSO updates 615

the ENTSO for Electricity operational planning data environment (OPDE) with the most recent 616

information. 617

618

Real-time execution of the availability plans 619

When it comes to the real-time execution of the availability plans all parties make sure that the 620

availability plans of their assets are fulfilled. However, in case a TSO identifies that executing an 621

"unavailable” or “testing” status of a relevant asset leads or could lead the transmission system to go 622

out of normal state, it instructs the owner of the relevant asset when it is connected to the 623

transmission system, or the DSO or CDSO if connected to a distribution system or to a closed 624

distribution system, to delay the execution of that "unavailable" or “testing” status of that relevant 625

asset according to its instructions and to the extent possible while respecting the technical and safety 626

limits. 627

628

629

– Page 27 of 64 –




The activities regarding the execution of availability plans are presented in the next flowchart (Figure 630

4: Execution of Availability Plans). 631

632

Figure 4: Execution of Availability Plans 633

634

Notes: 635

• overlapping of process boxes means that more than one roles are involved in the respective 636

process 637

• the grid security assessment could be also assigned to RSC 638

639

640

RealTime ExecutionofAvailabilityPlans

TSOs DSO/CDSO/FacilityOwners OPDE

START



END

Assurethestatusofits elementsbasedontheFinalAvailabilityPlans

Status"Unvailable"or

"Testing"?

Checkiftherelevantgrid-related conditionsarefullfiled(asthesedefinedbyTSOswhensetting

the"unavailable"status)

ConditionsFullfiled?

InstructFacility OwnertocanceltheOutage

InformTSOsforelementsin"testing"

state

InformTSOsforforcedoutages

*Assessthegridsecurity

Secure?

Execute OutagePlanning

InstructtheFacilityOwnertopostponetheOutage

Yes

No

Yes

No

No

Yes

"Testing" ElementsandForcedOutages

– Page 28 of 64 –




11 Sequence diagram for planned/unplanned unavailabilities 641

The following sequence diagram shows the submission process for planned/unplanned 642 unavailabilities: 643 644

645

Figure 5: submission process for planned/unplanned unavailabilit ies 646

647

Systemoperator (SO) role may represent following entities: 648

1. TSO, 649

2. DSO, 650

3. CDSO, 651

4. FO, 652

5. OPA 653

654

Initial outage planning data is provided by System operators to their Data Providers which 655 submit data to their RSCSP. 656 657 658

– Page 29 of 64 –




12 Outage Schedule document 659

Outage Schedule is defined as unavailability information which is exchanged upon the Network 660 Elements. 661 662 Each outage schedule document contains fields as described in Table below: 663 664

Class Attribute Remarks

OutageSchedule_MarketDocument

mRID Unique ID

revisionNumber Consecutive number

type

A76 = Load unavailability A77 = Production unavailability A78 = Transmission unavailability, A80 = Generation unavailability

process.processType

codelist StandardProcessTypeList A31 = week ahead, A32 = month ahead, A33 = year ahead A36 = Creation A37 = Modification A39 = Synchronisation process (to be used for request for report from market participant or for all non-weekly, non-monthly- non-yearly report answers)

sender_MarketParticipant.mRID EIC code of sender

sender_MarketParticipant.marketRole.type A04 = SO

receiver_MarketParticipant.mRID EIC code of receiver

receiver_MarketParticipant.marketRole.type A44=RSC

createdDateTime The creation Time of the document AAAA-MM-DDTHH:MM:SSZ

Schedule_Period.timeInterval The start and end of the unavailable day as AAAA-MM-DDTHH:MMZ

domain.mRID EIC Code of region

TimeSeries

mRID Unique ID

Description Cause of request

businessType

B81 Outage (OUT) B82 Special switching state (SSS), B83 Testing (TEST), --------------------------- B84 AUX (Auxiliary busbar operation), B85 AR (Automatic reclosing), B86 Bbprot (Busbar protection)

project_Name.name ProjectID, unique

caseReference_Names.name Reference CaseID (mRID)

outage_Period.timeInterval The start and end of the planned outage as AAAA-MM-DDTHH:MMZ

lastChange_MarketAgreement.createdDateTime The lastChange Time of the CaseID AAAA-MM-DDTHH:MM:SSZ

positiveOffset_ConstraintDuration.duration P[yY][mM][dD][T[hH][mM][s[.s]S]

negativeOffset_ConstraintDuration.duration P[yY][mM][dD][T[hH][mM][s[.s]S]

noRestitution_ConstraintDuration.type String “N”

maximumRestitution_ConstraintDuration.duration P[yY][mM][dD][T[hH][mM][s[.s]S]

dayTimeRestitution_ConstraintDuration.duration P[yY][mM][dD][T[hH][mM][s[.s]S]

nightTimeRestitution_ConstraintDuration.duration P[yY][mM][dD][T[hH][mM][s[.s]S]

weekEndRestitution_ConstraintDuration.duration P[yY][mM][dD][T[hH][mM][s[.s]S]

marketObjectStatus.status

A35 = preliminary A36 = planned A09 = cancelled (CAN)

coordination_MarketObjectStatus.status

A29 = Pre processed (requested) A34 = rejected A37 = confirmed

measurement_Unit.name MAW

unavailableCapacity_Quantity.quantity The quantity value.

day_MarketObjectStatus.status

A03 = deactivate / permanent A05 = active / daily (Usage day_MarketObjectStatus.status A05 means daytime/daylight day_MarketObjectStatus.status A03 means permanent)

week_MarketObjectStatus.status A03 = deactivate A05 = active

– Page 30 of 64 –




saturday_MarketObjectStatus.status A03 = deactivate A05 = active

sunday_MarketObjectStatus.status A03 = deactivate A05 = active

Reason reason.code A95 =Complementary information B29 = Special Condition

reason.text remarks and Special condition

RegisteredResource

mRID maxLength 60 codingScheme= "A01" - EIC

name longname

pSRType.psrType

A01 = TIE (tieline), A02 = LINE (internal OHL or cable), A04 = GEN (generating unit), A05 = LOAD (consumption unit), A08 = BUB (busbar), A09 = CAP (capacitor), A10 = IND (inductor), A11 = PPL (Power plant connection) B22 = DCL (DC-Link), B23 = SUB (Substation), B24 = TRA (Transformer),

pSRType.powerSystemResources.highVoltageLimit ([0-9] + ((\. [0-9] *)) unit always "KVT"

pSRType.powerSystemResources.lowVoltageLimit ([0-9] + ((\. [0-9] *)) unit always "KVT"

Alternative_RegisteredResource mRID

EIC or CGM code of the alternate gridelement

SwitchedBack_ Period timeInterval

The start and end where the gridelement is online during the outage as AAAA-MM-DDTHH:MMZ

Table 5 - OutageSchedule Market Document 665 666

– Page 31 of 64 –




13 Examples of outages 667

For better overview in the following tables only the information which is relevant for the process 668 is described in the examples: 669 670


OutageSchedule_MarketDocument

mRID 5bf2f5131d69-4f20-b96a-8f9637caf45

revisionNumber 1

type A78 = Transmission unavailability,

process.processType A36 = Creation

sender_MarketParticipant.mRID 10XAT-APG------Z


receiver_MarketParticipant.mRID 10X1001A1001A450

receiver_MarketParticipant.marketRole.type A44=RSC

createdDateTime

The creation Time of the document AAAA-MM-DDTHH:MM:SSZ

domain.mRID 10YAT-APG------L

TimeSeries

mRID AT__15000768

Description maintenance

businessType B81 = OUT

project_Name.name AT_ProjectID001

caseReference_Names.name AT__15000700

outage_Period.timeInterval 2015-12-18T06:00:00Z / 2015-12-23T16:00:00Z

lastChange_MarketAgreement.createdDateTime 2015-11-19T07:47:00Z

positiveOffset_ConstraintDuration.duration PoD

negativeOffset_ConstraintDuration.duration PoD

noRestitution_ConstraintDuration.type N

maximumRestitution_ConstraintDuration.duration PoD

dayTimeRestitution_ConstraintDuration.duration PoD

nightTimeRestitution_ConstraintDuration.duration PoD

weekEndRestitution_ConstraintDuration.duration PoD

marketObjectStatus.status A36 = planned

coordination_MarketObjectStatus.status A37 = confirmed

measurement_Unit.name MAW

unavailableCapacity_Quantity.quantity 0

day_MarketObjectStatus.status A05 = daily (Usage)

week_MarketObjectStatus.status A05 = active

saturday_MarketObjectStatus.status A03 = deactivate

sunday_MarketObjectStatus.status A03 = deactivate

Reason reason.code

A95 =Complementary information

reason.text Umbau Mastausleger, Seilzug und Reckzeit

RegisteredResource

mRID 10T-AT-CH-00002V codingScheme “ A01”

name Słupsk-Starno HVDC

registeredResource.pSRType.psrType A01 = TIE (tieline),

pSRType.powerSystemResources.highVoltageLimit 400 unit always "KVT"

Alternative_RegisteredResource mRID 10T-AT-CH-00001X

SwitchedBack_ Period timeInterval

2015-12-19T06:00Z / 2015-12-19T16:00Z

Table 6 - create planned outage 671 Table 6 describes a planned unavailability of TSO APG for one element in the transmission 672 grid. 673 674 675 676 677

– Page 32 of 64 –





OutageSchedule_MarketDocument mRID

034486f72ba6-4d20-9eb9-f66b8f39a808

process.processType A37 = Modification

createdDateTime 2015-11-20T11:11:11Z

Schedule_Period.timeInterval

Start 2015-12-18T06:00Z

End 2015-12-22T16:00Z

domain.mRID 10YAT-APG------L

TimeSeries

mRID AT__15000768

outage_Period.timeInterval

Start 2015-12-18T06:00Z

End 2015-12-22T16:00Z

lastChange_MarketAgreement.createdDateTime 2015-11-20T11:11:11Z

marketObjectStatus.status A36 = planned

coordination_MarketObjectStatus.status A37 = confirmed

Period timeInterval

Start 2015-12-19T06:00Z

End 2015-12-19T12:00Z

Table 7 - modification planned unavailability 678

679

Table 7 illustrates a modification („A37“) of Case ID „AT__15000768“. 680

681

Example files can be requested from the OPC Project group 682

683 684 685 686 687

– Page 33 of 64 –




14 Element information 688

Element information is sent by System Operator to the Data Provider who submits information 689 to RSCI (using Ref_MarketDocument). 690 691 Network element is considered as part of the grid treated as relevant or non-relevant asset 692 (defined in GLSO) on which the unavailability information is exchanged between Parties within 693 Outage Schedule document. 694 695 The following sequence diagram shows the submission process for element update information. 696 697

698 Figure 6: submission process for element update information 699 700

sd SQ-Pr ov ide/Submit element infor mat ions

System operator

(from Roles)

Information receiver

(from Roles)

Data provider

(from Roles)

Information receiver

(from Roles)

Out of the scope of

this document.

Note:

This Information

Receiver is RSCSP

provide new element

information

(Ref_MarketDocument)

Element update information

(Ref_MarketDocument )

provide new element

inforamtions


merge element

information()

ACK / nACK

(Acknowledgement_MarketDocumen

IEC 62325-451-1)

Element Update


– Page 34 of 64 –




701 Ref_MarketDocument contain following fields: 702 703


Ref_MarketDocument

mRID Unique ID

type A95 - ConfigurationDocument,

sender_MarketParticipant.mRID EIC code of sender


receiver_MarketParticipant.mRID EIC code of receiver

receiver_MarketParticipant.marketRole.type A44 = RSC

createdDateTime

The creation Time of the document AAAA-MM-DDTHH:MM:SSZ

process.processType

A36 (Creation), A37(Modification), A38(Deactivation process), A39(Synchronisation process).

TimeSeries

registeredResource.mRID EIC or CGM code of the gridelement

registeredResource.name String - global Element longname

registeredResource.location.name free text,200 letters, no restrictions

registeredResource.pSRType.psrType

A01 = TIE (Tieline), A02 = LINE (OHL), A04 = GEN (Generation), A05 = LOAD (consumption unit), A08 = BUB (busbar), A09 = CAP (capacitor), A10 = IND (inductor), A11 = PPL (powerplant-Line) B22 = DCL (DC-Link), B23 = SUB (Substation), B24 = TRA (Transformer),

registeredResource.pSRType.powerSystemResources .highVoltageLimit

Voltage Level ([0-9]+((\.[0-9]*)), unit always "KVT"

registeredResource.pSRType.powerSystemResources .lowVoltageLimit

Voltage Level ([0-9]+((\.[0-9]*)), unit always "KVT"

CancelledTS Boolean

description String - local Element longname

owner_MarketParticipant.mRID Responsible TSO, EIC code of the TSO

startLifetime_DateAndOrTime.date YYYY-MM-DD

endLifetime_DateAndOrTime.date YYYY-MM-DD

implementation_DateAndOrTime.date YYYY-MM-DD

active_Measurement_Unit.name MAW

installedGeneration_Quantity.quantity value

installedConsumption_Quantity.quantity value

installedReactive_Quantity.quantity value

reactive_Measurement_Unit.name MAW

Multipod_RegistredResource.mRID Element EIC which is used for the unique identification of the multipod

Domain mRID

EIC code of the Planning Region

Coordination_MarketParticipant mRID EIC code of the TSO

Interested_MarketParticipant mRID EIC code of the TSO

Specific_RegisteredResource mRID

EIC or CGM code of the specific gridelement

Table 8 - Ref_MarketDocument 704 705

– Page 35 of 64 –




15 Examples element information 706

In the following tables only the information which is relevant for the process is described 707 including examples: 708 709


Ref_MarketDocument

mRID d29e3d9f2e63-4752-9b68-283c975bd739

type A95

sender_MarketParticipant.mRID 10XPL-TSO------P

sender_MarketParticipant.marketRole.type A04


receiver_MarketParticipant.marketRole.type A44


process.processType A36

TimeSeries

registeredResource.mRID 10T-PL-SE-000016

registeredResource.name Słupsk-Starno HVDC

registeredResource.location.name “locationname”

registeredResource.pSRType.psrType A01


400

CancelledTS A01

description Słupsk-Starno HVDC

owner_MarketParticipant.mRID 10XPL-TSO------P

startLifetime_DateAndOrTime.date 2016-01-04

endLifetime_DateAndOrTime.date 2099-12-31

implementation_DateAndOrTime.date 2016-01-04

active_Measurement_Unit.name MAW

installedGeneration_Quantity.quantity 0.0

installedConsumption_Quantity.quantity 0.0

installedReactive_Quantity.quantity 0.0

reactive_Measurement_Unit.name MAW

Multipod_RegistredResource.mRID not used

Domain mRID 10YPL-AREA-----S

Coordination_MarketParticipant mRID 10XPL-TSO------P

Interested_MarketParticipant mRID

10XAT-APG------Z, 10XCH-SWISSGRIDC, 10XCZ-CEPS-GRIDE, 10XDE-EON-NETZ-C, 10XDE-ENBW--TNGX, 10XDE-RWENET---W, 10XDE-VE-TRANSMK, 10XHR-HEP-OPS--A, 10X1001A1001A329, 10X1001A1001A361, 10XRO-TEL------2, 10XPL-TSO------P, 10XSI-ELES-----1.

Specific_RegisteredResource mRID Not used yet

Table 9 - illustrates creation of a new element by TSO PSE. 710 711

Example files can be requested from the OPC Project group 712

– Page 36 of 64 –





Ref_MarketDocument

mRID 6c6241978036-4d30-959f-3ac00ea365ec



TimeSeries registeredResource.mRID 10T-PL-SE-000016

endLifetime_DateAndOrTime.date 2016-31-12

713 Table 10 - update / modification des Elements 714 715 Table 10 illustrates deactivation of an element by using „A37-Modification” and changing the 716 “endLifetime_Datum” for specific time in future. 717 Changes of elements can only be applied by element owning TSO except field „CancelledTS” 718 where each TSO may use A01 for marking element as interesting for his TSO or A02 for marking 719 element as non- interesting for his TSO. 720 721


Ref_MarketDocument mRID

339eb1f19145-4b74-93d8-b6b7a0c804b5

type A95

sender_MarketParticipant.mRID 10X1001A1001A361

sender_MarketParticipant.marketRole.type A04


receiver_MarketParticipant.marketRole.type A44



TimeSeries registeredResource.mRID 10T-PL-SE-000016

registeredResource.name Słupsk-Starno HVDC

registeredResource.pSRType.psrType A01


400

CancelledTS A02

owner_MarketParticipant.mRID 10XPL-TSO------P

startLifetime_DateAndOrTime.date 2016-01-04

Domain mRID 10YPL-AREA-----S

722 Table 11 - delete “interesting for” Information TSO TenneT NL 723 724 Table 11 illustrates how TSO TenneT NL marks element with registeredResource.mRID = 10T-725 PL-SE-000016 by sending process.processType = A39 (Synchronisation) and CancelledTS = 726 A02 (Deactivated), as “non-interesting for” for TenneT NL. 727 728 Example files can be requested from the OPC Project group 729 730 731

– Page 37 of 64 –




732

16 Outage scheduling document contextual model 733

16.1 Overview of the model 734

Figure 7 shows the model. 735

736

Figure 7: Network element maintenance scheduling document contextual model 737 738

17 IsBasedOn relationships from the European style market profile 739

Table 12 shows the traceability dependency of the classes used in this package towards the 740 upper level. 741

Table 12 - IsBasedOn dependency 742

Name Complete IsBasedOn Path

Alternative_RegisteredResource TC57CIM::IEC62325::MarketCommon::RegisteredResource

ConstraintDuration TC57CIM::IEC62325::MarketManagement::ConstraintDuration

Domain TC57CIM::IEC62325::MarketManagement::Domain

LastChange_MarketAgreement TC57CIM::IEC62325::MarketManagement::MarketAgreement

MarketObjectStatus TC57CIM::IEC62325::MarketManagement::MarketObjectStatus

MarketParticipant TC57CIM::IEC62325::MarketCommon::MarketParticipant

– Page 38 of 64 –





MarketRole TC57CIM::IEC62325::MarketCommon::MarketRole

Measure_Unit TC57CIM::IEC62325::MarketManagement::Unit

MktPSRType TC57CIM::IEC62325::MarketManagement::MktPSRType

Name TC57CIM::IEC61970::Base::Core::Name

NoRestitution_ConstraintDuration TC57CIM::IEC62325::MarketManagement::ConstraintDuration

OutageSchedule_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument

Process TC57CIM::IEC62325::MarketManagement::Process

Quantity TC57CIM::IEC62325::MarketManagement::Quantity

Reason TC57CIM::IEC62325::MarketManagement::Reason

RegisteredResource TC57CIM::IEC62325::MarketCommon::RegisteredResource

SwitchedBack_Time_Period TC57CIM::IEC62325::MarketManagement::Period

SwitchingBack_MarketObjectStatus TC57CIM::IEC62325::MarketManagement::MarketObjectStatus

Time_Period TC57CIM::IEC62325::MarketManagement::Period

TimeSeries TC57CIM::IEC62325::MarketManagement::TimeSeries

VoltageLevel TC57CIM::IEC61970::Base::Core::VoltageLevel

743

744

– Page 39 of 64 –




18 Outage scheduling document assembly model 745



748

Figure 8: Network element maintenance scheduling document assembly model 749

750

751 752 753

– Page 40 of 64 –




18.2 IsBasedOn relationships from the European style market profile 754

Table 13 shows the traceability dependency of the classes used in this package towards the upper 755

level. 756



Alternative_RegisteredResource TC57CIM::IEC62325::MarketCommon::RegisteredResource

OutageSchedule_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument

Reason TC57CIM::IEC62325::MarketManagement::Reason


SwitchedBack_Time_Period TC57CIM::IEC62325::MarketManagement::Period


758

18.3 Detailed Network element maintenance scheduling document assembly model 759

OutageSchedule_MarketDocument root class 760

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

This document is to be used to exchange the information to coordinate the maintenance 763 scheduling for network elements that may affect more than one system operators (e.g. such as 764 crossborder lines). 765

Table 14 shows all attributes of OutageSchedule_MarketDocument. 766

Table 14 - Attributes of Network element maintenance scheduling document assembly 767 model::OutageSchedule_MarketDocument 768

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 depending upon the document type.

A31 = week ahead,

A32 = month ahead,

A33 = year ahead

A36 =Create

A37 = Modification

A39 = Synchronisation (to be used for request for report from market participant or for all non-weekly, non-monthly- non-yearly report answers)

4 [1..1]

sender_MarketParticipant.mRID

PartyID_String

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

– Page 41 of 64 –




Order

mult.


5 [1..1]

sender_MarketParticipant.marketRole.type

MarketRoleKind_String

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

6 [1..1]

receiver_MarketParticipant.mRID

PartyID_String

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

7 [1..1]

receiver_MarketParticipant.marketRole.type


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

8 [1..1]

createdDateTime

ESMP_DateTime

The date and time of the creation of the document.

ENTSO-E date and time format

Date and time formats shall be used according to the ENTSO-E standards described chapter 4.3.10 in the ESS-Guide (see https://www.entsoe.eu/fileadmin/user_upload/edi/library/schedulev2r3/documentation/ess-guide-v2r3.pdf)

9 [0..1]

schedule_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 schedule time interval.

10 [1..1]

domain.mRID

AreaID_String

The unique identification of the domain. --- The Domain associated with an electronic document header; it is used for report filtering.

769

Table 15 shows all association ends of OutageSchedule_MarketDocument with other classes. 770

Table 15 - Association ends of Network element maintenance scheduling document 771 assembly model::OutageSchedule_MarketDocument with other classes 772

Order mult. Class name / Role

Description

11 [0..*] TimeSeries

TimeSeries

The timesseries related to a maintenance of a network element. Association Based On: Network element maintenance scheduling document contextual model::OutageSchedule_MarketDocument.[] ----- Network element maintenance scheduling document contextual model::TimeSeries.TimeSeries[0..*]

773

Alternative_RegisteredResource 774

A resource that is registered through the market participant registration system. Examples 775 include generating unit, load, and non-physical generator or load. 776

Table 16 shows all attributes of Alternative_RegisteredResource. 777

Table 16 - Attributes of Network element maintenance scheduling document assembly 778 model::Alternative_RegisteredResource 779

Order mult. Attribute name / Attribute type Description

0 [1..1] mRID

ResourceID_String

The unique identification of a resource.

780

Reason 781

The motivation of an act. 782

– Page 42 of 64 –




Table 17 shows all attributes of Reason. 783

Table 17 - Attributes of Network element maintenance scheduling document assembly 784 model::Reason 785

Order mult. Attribute name / Attribute type

Description

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.

More specific information about the outage can be provided here such as information about substations

786

RegisteredResource 787


Table 18 shows all attributes of RegisteredResource. 790

Table 18 - Attributes of Network element maintenance scheduling document assembly 791 model::RegisteredResource 792


0 [1..1] mRID

ResourceID_String


1 [1..1] name

String

The name is any free human readable and possibly non unique text naming the object.

The long name for the grid element has to be provided.

The following naming convention should be used for new grid elements:

-- Substation: Voltage level (optional), name

-- Line: Voltage level (optional), Subst. 1, Subst.2, Subst. X , name (optional)

-- transformer: Voltage levels (optional), Subst., name

512 in future

2 [0..1] pSRType.psrType

PsrType_String

The coded type of a power system resource. --- The identification of the type of resource associated with this RegisteredResource.

3 [0..1] pSRType.powerSystemResources.highVoltageLimit

ESMP_Voltage

The bus bar's high voltage limit --- The identification of the type of resource associated with this RegisteredResource. --- The voltage level of the RegisteredResource having the MktPSRType.

- For an internal overheadline or cable (LINE): xxx

4 [0..1] pSRType.powerSystemResources.lowVoltageLimit

ESMP_Voltage

The bus bar's low voltage limit. The lower voltage value for a transformer. --- The identification of the type of resource associated with this RegisteredResource. --- The voltage level of the RegisteredResource having the MktPSRType - For a transformer (TRA): xxx/xxx

793

– Page 43 of 64 –




SwitchedBack_Time_Period 794

The identification of a time interval or a duration. 795

These time intervals are the one when although in the maintenance period the network element 796 is available for operation. 797

Table 19 shows all attributes of SwitchedBack_Time_Period. 798

Table 19 - Attributes of Network element maintenance scheduling document assembly 799 model::SwitchedBack_Time_Period 800


0 [1..1] timeInterval


The start and end date and time for a given interval.

801

TimeSeries 802

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

Table 20 shows all attributes of TimeSeries. 804

Table 20 - Attributes of Network element maintenance scheduling document assembly 805 model::TimeSeries 806


0 [1..1] mRID

ID_String

A unique identification of the time series. This mRID provides the case identification.

1 [0..1] description

String

The description is a free human readable text describing or naming the object. It may be non unique and may not correlate to a naming hierarchy. This provides the description of the cause of the maintenance.

2 [1..1] businessType

BusinessKind_String

The identification of the nature of the time series.

B81 = (OUT)planned maintenance,

SSS,

3 [0..1] project_Names.name

String

Any free text that name the object. --- The project identification for the outage, it it exists. If multiple cases belong to the same project, one common project ID for these cases shall be determined by the requesting TSO. This information is additional to case ID.

4 [0..1] caseReference_Names.name

String

Any free text that name the object. --- All names of this identified object. If two cases affect each other and the status of one turns to "approved", then the status of the other shall be changed to "cancelled" and the caseID of the other case shall be entered here for tracking purposes.

If two cases affect each other and the status of one turns to "approved", the status of the other must be changed to "cancelled" and the case ID of the other case must be entered here for tracking reasons.

5 [1..1] outage_Period.timeInterval


The start and end date and time for a given interval. --- The total period of the outage for the RegisteredResource.

– Page 44 of 64 –





6 [1..1] lastChange_MarketAgreement.createdDateTime

ESMP_DateTime

The date and time of the creation of the agreement. --- Information about the last change on the outage agreement. This is given by local tool as soon as a dataset is created or updated.

Given by local tool as soon as a dataset is created or changed.

7 [0..1] positiveOffset_ConstraintDuration.duration

Duration

The duration of the constraint. --- The constraint duration for the process described in the TimeSeries. The number of days to delay the maintenance scheduling period.

8 [0..1] negativeOffset_ConstraintDuration.duration

Duration

The duration of the constraint. --- The constraint duration for the process described in the TimeSeries. The number of days to anticipate the maintenance scheduling period.

9 [0..1] noRestitution_ConstraintDuration.type

String

The type of the constraint. --- The constraint duration for the process described in the TimeSeries. If the type attribute has a value equal to No then there shall be no restitution time duration. Otherwise, the type attribute shall not be used.

field for value = “N” only

10 [0..1] maximumRestitution_ConstraintDuration.duration

Duration

The duration of the constraint. --- The constraint duration for the process described in the TimeSeries. The maximum delay to give back the network element under maintenance if required.

"max" field is the must field and must be always filled with a value (N or a time).

If the other "restitution time [h]" fields are filled as well the maximum value of these fields must be put into the "max" field as well.

11 [0..1] dayTimeRestitution_ConstraintDuration.duration

Duration

The duration of the constraint. --- The constraint duration for the process described in the TimeSeries. The time delay to give back during day time period the network element under maintenance if required.

12 [0..1] nightTimeRestitution_ConstraintDuration.duration

Duration

The duration of the constraint. --- The constraint duration for the process described in the TimeSeries. The time delay to give back during night time period the network element under maintenance if required.

13 [0..1] weekEndRestitution_ConstraintDuration.duration

Duration

The duration of the constraint. --- The constraint duration for the process described in the TimeSeries. The time delay to give back during week end period the network element under maintenance if required.

14 [1..1] marketObjectStatus.status

Status_String

The coded condition or position of an object with regard to its standing. --- The status of the maintenance scheduling identified by the mRID (case-study). The status may be roughly planned, planned in details or cancelled. IT is always filled even if coordination is not necessary for this element.

– Page 45 of 64 –





15 [0..1] coordination_MarketObjectStatus.status

Status_String

The coded condition or position of an object with regard to its standing. --- The coordination status; it could be merged, modified, or confirmed. This attribute is used for coordination by both the requester TSO and the requested TSO.

This field is used for coordination by both, the requester TSO and the requested TSO.

Field must be filled if for an element the field “Coordination” in the reference data is not empty; otherwise the field must be left blank.

The requester TSO fills in all information "REQ", confirm "CON" or reject "REJ".

If a change is wished, the requested TSO has to call the TSO who started the coordination process to agree to start a new coordination process (i.e. put the status back to "REQ")

16 [0..1] measurement_Unit.name

MeasurementUnitKind_String

The identification of the formal code for a measurement unit (UN/ECE Recommendation 20). --- The unit of measure for the unavailable capacity. The unit may be MW for generation units or load and MVar for compensation means.

17 [0..1] unavailableCapacity_Quantity.quantity

Decimal

The quantity value. The association role provides the information about what is expressed. --- The quantity information associated to a TimeSeries. The unavailable capacity induced by the maintenance of the network element. This may be a generation unit, a load or a compensation mean.

Enter the unavailable capacity in MW for generation units/consumers and in Mvar for compensation elements (IND, CAP).

18 [1..1] day_MarketObjectStatus.status

Status_String

The coded condition or position of an object with regard to its standing. --- When attribute has the "Active" value, the maintenance is only done during day ligth time.

To be marked with "A05" if the outage or special switching state is repeated every day referring to the specified times or marked with "A03" if outage is continuously

19 [0..1] week_MarketObjectStatus.status

Status_String

The coded condition or position of an object with regard to its standing. --- When attribute has the "Active" value, the maintenance is only done from Monday to Friday included.

20 [0..1] saturday_MarketObjectStatus.status

Status_String

The coded condition or position of an object with regard to its standing. --- When attribute has the "Active" value, the maintenance s done on Saturday.

21 [0..1] sunday_MarketObjectStatus.status

Status_String

The coded condition or position of an object with regard to its standing. --- When attribute has the "Active" value, the maintenance s done on Sunday.

807

Table 21 shows all association ends of TimeSeries with other classes. 808

– Page 46 of 64 –




Table 21 - Association ends of Network element maintenance scheduling document 809 assembly model::TimeSeries with other classes 810

Order

mult.

Class name / Role Description

22 [0..*] Reason

Reason

The coordination status of the case-study. The status may be requested, rejected or confirmed. Association Based On: Network element maintenance scheduling document contextual model::Reason.Reason[0..*] ----- Network element maintenance scheduling document contextual model::TimeSeries.[]

23 [1..*] RegisteredResource

RegisteredResource

The identification of the network elemen-t object of the maintenance scheduling. Association Based On: Network element maintenance scheduling document contextual model::TimeSeries.[] ----- Network element maintenance scheduling document contextual model::RegisteredResource.RegisteredResource[1..*]

Enter the code which is used for the unique identification of this grid element.

24 [0..*] Alternative_RegisteredResource

Alternative_RegisteredResource

The identification of a resource associated with a TimeSeries. When used, this list contains alternative network element for the maintenance schedule. Association Based On: Network element maintenance scheduling document contextual model::Alternative_RegisteredResource.Alternative_RegisteredResource[0..*] ----- Network element maintenance scheduling document contextual model::TimeSeries.[]

If at least two elements are used alternatingly, both elements belong to the same case ID and an "X" is required in this column.

For "alternating" at least two elements must be used under one case ID. The first (upper) element is the element that should be handled as switched off during grid calculations.

25 [0..*] SwitchedBack_Time_Period

SwitchedBack_Period

The time interval associated with a TimeSeries within an elec tronic document. When such time intervals are provided, they states that during the maintenance period, the network elements will be back for operation during these time intervals. Association Based On: Network element maintenance scheduling document contextual model::SwitchedBack_Time_Period.SwitchedBack_Period[0..*] ----- Network element maintenance scheduling document contextual model::TimeSeries.[]

Enter all dates for when the unavailability does not exist.

811

812

813 814

– Page 47 of 64 –




19 Network outage configuration contextual model 815



818

Figure 9: Network outage configuration contextual model 819





DateAndOrTime TC57CIM::IEC62325::MarketManagement::DateAndOrTime


Location TC57CIM::IEC61968::Common::Location

MarketParticipant TC57CIM::IEC62325::MarketCommon::MarketParticipant

MarketRole TC57CIM::IEC62325::MarketCommon::MarketRole

Measure_Unit TC57CIM::IEC62325::MarketManagement::Unit

MktPSRType TC57CIM::IEC62325::MarketManagement::MktPSRType

Multipod_RegisteredResource TC57CIM::IEC62325::MarketCommon::RegisteredResource

Other_MarketParticipant TC57CIM::IEC62325::MarketCommon::MarketParticipant

Owner_MarketParticipant TC57CIM::IEC62325::MarketCommon::MarketParticipant

Process TC57CIM::IEC62325::MarketManagement::Process

Quantity TC57CIM::IEC62325::MarketManagement::Quantity

– Page 48 of 64 –





Ref_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument


Specific_RegisteredResource TC57CIM::IEC62325::MarketCommon::RegisteredResource


VoltageLevel TC57CIM::IEC61970::Base::Core::VoltageLevel

824

– Page 49 of 64 –




20 Network outage configuration assembly model 825



828

829

Figure 10: Network outage configuration assembly model 830



– Page 50 of 64 –







Other_MarketParticipant TC57CIM::IEC62325::MarketCommon::MarketParticipant

Ref_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument

Specific_RegisteredResource TC57CIM::IEC62325::MarketCommon::RegisteredResource


835

20.3 Detailed Network outage configuration assembly model 836

Ref_MarketDocument root class 837

An electronic document containing the information necessary to satisfy the requirements of the 838 configuration management process. 839

The Ref_MarketDocument is used to transmit the information necessary to configure the outage 840 planning configuration process. 841

The Ref_MarketDocument is also used to transmit modifications that evolve the initial 842 configuration information over time. 843

Table 24 shows all attributes of Ref_MarketDocument. 844

Table 24 - Attributes of Network outage configuration assembly 845 model::Ref_MarketDocument 846

Order

mult.


0 [1..1]

mRID

ID_String

Unique identification of the configuration document being exchanged within a given business process flow.

1 [1..1]

type

MessageKind_String

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

2 [1..1]

process.processType

ProcessKind_String

The identification of the nature of process that the document addresses.

3 [1..1]

sender_MarketParticipant.mRID

PartyID_String

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

4 [1..1]

sender_MarketParticipant.marketRole.type


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

5 [1..1]

receiver_MarketParticipant.mRID

PartyID_String

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

6 [1..1]

receiver_MarketParticipant.marketRole.type


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

7 [1..1]

createdDateTime

ESMP_DateTime

The date and time of the creation of the document.

ENTSO-E date and time format

Date and time formats shall be used according to the ENTSO-E standards described chapter 4.3.11 in the ESS-Guide (see https://www.entsoe.eu/fileadmin/user_upload/edi/library/schedulev2r3/documentation/ess-guide-v2r3.pdf)

847

Table 25 shows all association ends of Ref_MarketDocument with other classes. 848

– Page 51 of 64 –




Table 25 - Association ends of Network outage configuration assembly 849 model::Ref_MarketDocument with other classes 850

Order mult. Class name / Role Description

8 [1..*] TimeSeries

TimeSeries

Association Based On: Network outage configuration contextual model::TimeSeries.TimeSeries[1..*] ----- Network outage configuration contextual model::Ref_MarketDocument.[]

851

Domain 852

A domain covering a number of related objects, such as market balance area, grid area, borders 853 etc. 854

Table 26 shows all attributes of Domain. 855

Table 26 - Attributes of Network outage configuration assembly model::Domain 856

Order mult. Attribute name / Attribute type

Description

0 [1..1] mRID

AreaID_String

The unique identification of the domain.

The domain where the ResourceObject associated with a TimeSeries resides.

857

Other_MarketParticipant 858

The identification of the party that provides the information concerning the resource object 859 defined in the time series. 860

Table 27 shows all attributes of Other_MarketParticipant. 861

Table 27 - Attributes of Network outage configuration assembly 862 model::Other_MarketParticipant 863


0 [1..1] mRID

PartyID_String

The identification of a party in the energy market.

864

Specific_RegisteredResource 865


Table 28 shows all attributes of Specific_RegisteredResource. 868

Table 28 - Attributes of Network outage configuration assembly 869 model::Specific_RegisteredResource 870


0 [1..1] mRID

ResourceID_String


871

– Page 52 of 64 –




TimeSeries 872

A time series shall exist to describe a specific production unit, generating unit, transmission 873 asset or consumption unit. It conveys the data related to the configuration of the defined 874 information. 875

Table 29 shows all attributes of TimeSeries. 876

Table 29 - Attributes of Network outage configuration assembly model::TimeSeries 877


0 [1..1] registeredResource.mRID

ResourceID_String

The unique identification of a resource. --- The identification of a resource associated with a TimeSeries. The network element to be configured.

1 [1..1] registeredResource.name

String

The name is any free human readable and possibly non unique text naming the object. --- The identification of a resource associated with a TimeSeries. The network element to be configured.

The long name for the grid element has to be provided.

The following naming convention should be used for new grid elements:

-- Substation: Voltage level (optional), name

-- Line: Voltage level (optional), Subst. 1, Subst.2, Subst. X , name (optional)

-- transformer: Voltage levels (optional), Subst., name

512 in future

2 [0..1] registeredResource.location.name

Characters200_String

The name is any free human readable and possibly non unique text naming the object. The location of the element for the outage. --- The identification of a resource associated with a TimeSeries. The network element to be configured. --- Location of this power system resource.

specification of the location of the unavailable grid element

free text, no restrictions

3 [1..1] registeredResource.pSRType.psrType

PsrType_String

The coded type of a power system resource. --- The identification of a resource associated with a TimeSeries. The network element to be configured. --- The identification of the type of resource associated with this RegisteredResource.

4 [1..1] registeredResource.pSRType.powerSystemResources .lowVoltageLimit

ESMP_Voltage

The bus bar's high voltage limit --- The identification of a resource associated with a TimeSeries. The network element to be configured. --- The identification of the type of resource associated with this RegisteredResource. --- The voltage level of the RegisteredResource having the MktPSRType

- For an internal overheadline or cable (LINE): xxx

– Page 53 of 64 –





5 [0..1] registeredResource.pSRType. low_PowerSystemResources.highVoltageLimit

ESMP_Voltage

The bus bar's low voltage limit --- The identification of a resource associated with a TimeSeries. The network element to be configured. --- The identification of the type of resource associated with this RegisteredResource. --- The voltage level of the RegisteredResource having the MktPSRType. - For a transformer (TRA): xxx/xxx

6 [0..1] cancelledTS

ESMPBoolean_String

An indicator stating that the TimeSeries, identified by the mRID, is withdrawn as well as all the values sent in a previous version of the TimeSeries in a previous document.

7 [0..1] description

String

Any other information about the network element defined by the mRID of the RegisteredResource. The description is a free human readable text describing or naming the object. It may be non unique and may not correlate to a naming hierarchy.

8 [1..1] owner_MarketParticipant.mRID

PartyID_String

The identification of a party in the energy market. --- The party who provides the information related to the RegisteredResource outage.

TSO that is responsible for reference data maintenance and can send cases (outage planning/availability data for this element).

Exception:

If the element type is TIE more than one TSO can be listed here. The following rules are applicable:

- The TSO, that is listed first is responsible for reference data management

- All TSOs listed under "responsible" can send cases (outage planning/availability data for this element).

- All TSOs listed under "responsible " must be listed under "coordination" as well. (Important for filtering purposes and for coordination process via OPC)

9 [1..1] startLifetime_DateAndOrTime.date

Date

The date as "YYYY-MM-DD", which conforms with ISO 8601. --- The date when the network element was put in service.

10 [0..1] endLifetime_DateAndOrTime.date

Date

The date as "YYYY-MM-DD", which conforms with ISO 8601. --- The date when the network element will be withdrawn of service.

11 [0..1] implementation_DateAndOrTime.date

Date

The date as "YYYY-MM-DD", which conforms with ISO 8601. --- The date of application of the information provided. This identifies the date of the effective implementation of the information provided in the time series. In the case of a creation this signifies that the object will be operational at this date. In the case of modification this signifies that the changes will be operational at this date. In the case of a deactivation this signifies that the deactivation will be effective at this date.

– Page 54 of 64 –





12 [0..1] active_Measurement_Unit.name


The identification of the formal code for a measurement unit (UN/ECE Recommendation 20). --- The unit for active generation or consumption.

13 [0..1] installedGeneration_Quantity.quantity

Decimal

The quantity value. The association role provides the information about what is expressed. --- The quantity information associated to a TimeSeries. For a generating unit, the installed generation capacity.

- Capacity in [MW] for generation and consumption units

- Capacity in [Mvar] for compensation elements such as CAP and IND

- negative sign ("-") must be used for consumption units and IND; generation units and CAP are given as positive value

14 [0..1] installedConsumption_Quantity.quantity

Decimal

The quantity value. The association role provides the information about what is expressed. --- The quantity information associated to a TimeSeries. For a consumption unit, the installed consumption capacity.

15 [0..1] installedReactive_Quantity.quantity

Decimal

The quantity value. The association role provides the information about what is expressed. --- The quantity information associated to a TimeSeries. For a unit, the reactive capacity.

16 [0..1] reactive_Measurement_Unit.name


The identification of the formal code for a measurement unit (UN/ECE Recommendation 20). --- The unit for reactive power.

17 [0..1] multipod_RegisteredResource.mRID

ResourceID_String

The unique identification of a resource. In the ESMP context, the "model authority" is defined as an authorized issuing office that provides an agreed identification coding scheme for market participant, domain, measurement point, resources (generator, lines, substations, etc.) 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 a resource associated with a TimeSeries. The network element which is within the multipod.

Enter the element ID which is used for the unique identification of the multipod.

878

Table 30 shows all association ends of TimeSeries with other classes. 879

– Page 55 of 64 –




Table 30 - Association ends of Network outage configuration assembly 880 model::TimeSeries with other classes 881

Order

mult.

Class name / Role Description

18 [1..*] Domain

Domain

The domain where the resource object associated with a TimeSeries resides. Association Based On: Network outage configuration contextual model::Domain.Domain[1..*] ----- Network outage configuration contextual model::TimeSeries.[]

19 [0..*] Other_MarketParticipant

Coordination_MarketParticipant

The list of parties who are involved in the coordination outage process Association Based On: Network outage configuration contextual model::Other_MarketParticipant.Coordination_MarketParticipant[0..*] ----- Network outage configuration contextual model::TimeSeries.[]

20 [0..*] Other_MarketParticipant

Interested_MarketParticipant

The list of parties that are interested in information about outage of the network element object of the TimeSeries. These parties shall be notified that a case or a change to a case for an element was uploaded/inserted. Association Based On: Network outage configuration contextual model::Other_MarketParticipant.Interested_MarketParticipant[0..*] ----- Network outage configuration contextual model::TimeSeries.[]

21 [0..*] Specific_RegisteredResource

Specific_RegisteredResource

The identification of a resource associated with a TimeSeries. The list of network elements that have a specific relationship to the network element object of this configuration. Association Based On: Network outage configuration contextual model::Specific_RegisteredResource.Specific_RegisteredResource[0..*] ----- Network outage configuration contextual model::TimeSeries.[]

882

883

– Page 56 of 64 –




21 Primitives and Datatypes 884

21.1 Primitives 885

Date primitive 886

Date as "YYYY-MM-DD", which conforms with ISO 8601. 887

DateTime primitive 888

Date and time as "YYYY-MM-DDThh:mm:ssZ", which conforms with ISO 8601 UTC time zone. 889

Note: the time within ESMP is expressed in UTC. 890

Decimal primitive 891

Decimal is the base-10 notational system for representing real numbers. 892

Duration primitive 893

Duration as "PnYnMnDTnHnMnS" which conforms to ISO 8601, where nY expresses a number of years, 894

nM a number of months, nD a number of days. The letter T separates the date expression from the 895

time expression and, after it, nH identifies a number of hours, nM a number o f minutes and nS a number 896

of seconds. The number of seconds could be expressed as a decimal number, but all other numbers are 897

integers. 898

Float primitive 899

A floating point number. The range is unspecified and not limited. 900

String primitive 901

A string consisting of a sequence of 8 bit characters. The character encoding is UTF-8. The string length 902

is unspecified and unlimited. 903

22 Datatypes 904

The list of datatypes used for the Network element maintenance scheduling document assembly model 905

is as follows: 906

22.1 ESMP_DateTimeInterval compound 907

This datatype enables to express the start date and time, and the end date and time of a time interval 908

with a specific pattern. This pattern is the YYYY-MM-DDThh:mmZ. 909

Table 31 shows all attributes of ESMP_DateTimeInterval. 910

Table 31 - Attributes of ESMPDataTypes::ESMP_DateTimeInterval 911

mult. Attribute name / Attribute type Description

[1..1] start

YMDHM_DateTime

The start date and time of the interval with a minute resolution.

[1..1] end

YMDHM_DateTime

The end date and time of the interval with a minute resolution.

912

22.2 AreaID_String datatype 913

The coded identification of a domain, i.e. balance area, grid area, etc. 914

In the ESMP context, it is an authorized issuing office that provides an agreed identification coding 915

scheme for domain identification. 916

Table 32 shows all attributes of AreaID_String. 917

– Page 57 of 64 –




Table 32 - Attributes of ESMPDataTypes::AreaID_String 918


[1..1] codingScheme

CodingSchemeTypeList

DomainQualification.

[1..1] value

String

Main Core value Space.

919

Table 33 shows all restrictions applied to the attributes of AreaID_String. 920

Table 33 - Restrictions of attributes for ESMPDataTypes::AreaID_String 921

Name Constraint Type Expression of constraint

value maxLength OCL inv: self->MaxLength(18)

922

22.3 BusinessKind_String datatype 923

The coded identification of the business type. 924

Table 34 shows all attributes of BusinessKind_String. 925

Table 34 - Attributes of ESMPDataTypes::BusinessKind_String 926


[1..1] value

BusinessTypeList


927

22.4 Characters200_String datatype 928

A string consisting of a sequence of 8 bit characters. The character encoding is UTF -8. 929

The string length is restricted to 200 characters. 930

Table 35 shows all attributes of Characters200_String. 931

Table 35 - Attributes of ESMPDataTypes::Characters200_String 932


[1..1] value

String

The string length is restricted to 200 characters.

933

Table 36 shows all restrictions applied to the attributes of Characters200_String. 934

Table 36 - Restrictions of attributes for ESMPDataTypes::Characters200_String 935



936

– Page 58 of 64 –




22.5 ESMP_DateTime datatype 937

In ESMP, the dateTime shall be expressed in UTC as YYYY-MM-DDThh:mm:ssZ. 938

Table 37 shows all attributes of ESMP_DateTime. 939

Table 37 - Attributes of ESMPDataTypes::ESMP_DateTime 940


[1..1] value

DateTime


941

Table 38 shows all restrictions applied to the attributes of ESMP_DateTime. 942

Table 38 - Restrictions of attributes for ESMPDataTypes::ESMP_DateTime 943


value pattern OCL inv: self->Pattern(((([0-9]{4})[\-](0[13578]|1[02])[\-](0[1-9]|[12][0-9]|3[01])|([0-9]{4})[\-]((0[469])|(11))[\-](0[1-9]|[12][0-9]|30))T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9])Z)|(([13579][26][02468][048]|[13579][01345789](0)[48]|[13579][01345789][2468][048]| [02468][048][02468][048]|[02468][1235679](0)[48]|[02468][1235679][2468][048]|[0 -9][0-9][13579][26])[\-](02)[\-](0[1-9]|1[0-9]|2[0-9])T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9])Z)|(([13579][26][02468][1235679]|[13579][01345789](0)[01235679]|[13579][01345789 ][2468][1235679]|[02468][048][02468][1235679]|[02468][1235679](0)[01235679]|[02468][1235679][2468][1235679]|[0-9][0-9][13579][01345789])[\-](02)[\-](0[1-9]|1[0-9]|2[0-8])T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9])Z))

944

22.6 ESMP_Voltage datatype 945

The coded identification of a voltage value. 946

Table 39 shows all attributes of ESMP_Voltage. 947

Table 39 - Attributes of ESMPDataTypes::ESMP_Voltage 948

mult. Attribute name / Attribute type

Description

[1..1] value

Float

Main Core value Space. The value is expressed as a simple precision and no mantisse.

[1..1] unit

UnitSymbol

The unit of the value, the UN/CEFACT recommendation 20 is used as coding scheme of the unit.

949

Table 4041 shows all restrictions applied to the attributes of ESMP_Voltage. 950

Table 40 - Restrictions of attributes for ESMPDataTypes::ESMP_Voltage 951


value pattern OCL inv: self->Pattern(([0-9]+((\.[0-9])*)))

value precision INV choice=simple

unit Constant

KVT

– Page 59 of 64 –





unit Fixed

KVT

952

22.7 ESMPBoolean_String datatype 953

The attribute is a Boolean, either 0 or 1 value, "No" or "Yes", or two values defined in a code list. 954

Table 41 shows all attributes of ESMPBoolean_String. 955

Table 41 - Attributes of ESMPDataTypes::ESMPBoolean_String 956


[1..1] value

IndicatorTypeList


957

22.8 ESMPVersion_String datatype 958

In ESMP, the coded value is restricted to digits. 959

A code that distinguishes one evolution of an identified object from another. Information about a 960

specific object may be sent several times, each transmission being identified by a different version 961

number. 962

Table 42 shows all attributes of ESMPVersion_String. 963

Table 42 - Attributes of ESMPDataTypes::ESMPVersion_String 964


[1..1] value

String


965

Table 43 shows all restrictions applied to the attributes of ESMPVersion_String. 966

Table 43 - Restrictions of attributes for ESMPDataTypes::ESMPVersion_String 967


value pattern OCL inv: self->Pattern([1-9]([0-9]){0,2})

968

22.9 ID_String datatype 969

A code to uniquely distinguish one occurrence of an entity from another. 970

In the ESMP context, the code is defined either by: 971

- an emitting company that provides an agreed identification unique within a business context such as 972

capacity auction identification, market agreement identification, etc. 973

- a party (originator of the exchange) that provides a unique identification in th e framework of a 974

business exchange such as document identification, time series identification, bid identification, ... 975

Table 44 shows all attributes of ID_String. 976

– Page 60 of 64 –




Table 44 - Attributes of ESMPDataTypes::ID_String 977


[1..1] value

String


978

Table 45 shows all restrictions applied to the attributes of ID_String. 979

Table 45 - Restrictions of attributes for ESMPDataTypes::ID_Str ing 980



981

22.10 MarketRoleKind_String datatype 982

The identification of the role played by a party. 983

Table 46 shows all attributes of MarketRoleKind_String. 984

Table 46 - Attributes of ESMPDataTypes::MarketRoleKind_String 985


[1..1] value

RoleTypeList


986

22.11 MeasurementUnitKind_String datatype 987

The coded identification of a unit of measure that is applied to a quantity. The measurement units shall 988

be in compliance with UN/ECE Recommendation 20. 989

Table 47 shows all attributes of MeasurementUnitKind_String. 990

Table 47 - Attributes of ESMPDataTypes::MeasurementUnitKind_String 991


[1..1] value

UnitOfMeasureTypeList


992

993

22.12 MessageKind_String datatype 994

The coded type of a document. 995

Table 48 shows all attributes of MessageKind_String. 996

Table 48 - Attributes of ESMPDataTypes::MessageKind_String 997


[1..1] value

MessageTypeList


– Page 61 of 64 –




998

22.13 PartyID_String datatype 999

The identification of an actor in the energy market. 1000


scheme for market participant identification. 1002

Table 49 shows all attributes of PartyID_String. 1003

Table 49 - Attributes of ESMPDataTypes::PartyID_String 1004


[1..1] codingScheme



[1..1] value

String


1005

Table 50 shows all restrictions applied to the attributes of PartyID_String. 1006

Table 50 - Restrictions of attributes for ESMPDataTypes::PartyID_String 1007



1008

22.14 ProcessKind_String datatype 1009

The coded identification of the nature of process. 1010

Table 51 shows all attributes of ProcessKind_String. 1011

Table 51 - Attributes of ESMPDataTypes::ProcessKind_String 1012


[1..1] value

ProcessTypeList


1013

1014

22.15 PsrType_String datatype 1015

The coded type of a power system resource. 1016

Table 52 shows all attributes of PsrType_String. 1017

Table 52 - Attributes of ESMPDataTypes::PsrType_String 1018


[1..1] value

AssetTypeList


1019

– Page 62 of 64 –




22.16 ReasonCode_String datatype 1020

The coded motivation of an act. 1021

Table 53 shows all attributes of ReasonCode_String. 1022

Table 53 - Attributes of ESMPDataTypes::ReasonCode_String 1023


[1..1] value

ReasonCodeTypeList


1024

22.17 ReasonText_String datatype 1025

The textual explanation of an act as a string of characters. 1026

Table 54 shows all attributes of ReasonText_String. 1027

Table 54 - Attributes of ESMPDataTypes::ReasonText_String 1028


[1..1] value

String


1029

Table 55 shows all restrictions applied to the attributes of ReasonText_String. 1030

Table 55 - Restrictions of attributes for ESMPDataTypes::ReasonText_String 1031



1032

22.18 ResourceID_String datatype 1033

The identification of a resource object in the energy market. 1034


scheme for resources (generator, lines, substations, etc.) identification. 1036

Table 56 shows all attributes of ResourceID_String. 1037

Table 56 - Attributes of ESMPDataTypes::ResourceID_String 1038


[1..1] codingScheme



[1..1] value

String


1039

Table 57 shows all restrictions applied to the attributes of ResourceID_String. 1040

– Page 63 of 64 –




Table 57 - Restrictions of attributes for ESMPDataTypes::ResourceID_String 1041



1042

22.19 Status_String datatype 1043

The identification of the status of an object. 1044

Table 58 shows all attributes of Status_String. 1045

Table 58 - Attributes of ESMPDataTypes::Status_String 1046


[1..1] value

StatusTypeList


1047

22.20 UnitSymbol datatype 1048

A code to identify an analog measurement. 1049

A code to uniquely distinguish one occurrence of an entity from another. 1050

In the ESMP context, the code is defined by an emitting company that provides an agreed identification 1051

unique within a business context such as capacity auction identification, market agreement 1052

identification, etc. 1053

Table 59 shows all attributes of UnitSymbol. 1054

Table 59 - Attributes of ESMPDataTypes::UnitSymbol 1055


[1..1] value

UnitSymbol


1056

1057

22.21 YMDHM_DateTime datatype 1058

In ESMP, the date and time is expressed as "YYYY-MM-DDThh:mmZ", which conforms with ISO 8601 1059

UTC time zone. This date and time is without the seconds. 1060

Table 60 shows all attributes of YMDHM_DateTime. 1061

Table 60 - Attributes of ESMPDataTypes::YMDHM_DateTime 1062

mult. Attribute name / Attribute type

Description

[1..1] value

DateTime

The date and time as "YYYY-MM-DDThh:mmZ", which conforms with the ISO 8601 UTC time zone.

1063

Table 61 shows all restrictions applied to the attributes of YMDHM_DateTime. 1064

– Page 64 of 64 –




Table 61 - Restrictions of attributes for ESMPDataTypes::YMDHM_DateTime 1065


value pattern OCL inv: self->Pattern(((([0-9]{4})[\-](0[13578]|1[02])[\-](0[1-9]|[12][0-9]|3[01])|([0-9]{4})[\-]((0[469])|(11))[\-](0[1-9]|[12][0-9]|30))T(([01][0-9]|2[0-3]):[0-5][0-9])Z)|(([13579][26][02468][048]|[13579][01345789](0)[48]|[13579][01345789][2468][048]|[02468][048][02468][048]|[02468][1235679](0)[48]|[02468][1235679][2468][048]|[0-9][0-9][13579][26])[\-](02)[\-](0[1-9]|1[0-9]|2[0-9])T(([01][0-9]|2[0-3]):[0-5][0-9])Z)|(([13579][26][02468][1235679]|[13579][01345789](0)[01235679]|[13579][01345789][2468][1235679]|[02468][048][02468][1235679]|[02468][1235679](0)[01235679]|[02468][1235679][2468][1235679]|[0-9][0-9][13579][01345789])[\-](02)[\-](0[1-9]|1[0-9]|2[0-8])T(([01][0-9]|2[0-3]):[0-5][0-9])Z))

value TruncationOrReduced INV choice=gYearMonthDayHourMinute

1066

1067

Documents

OUTAGE BUSINESS PROCESS AND FORMAT - … · 30 18.3 Detailed Network element maintenance scheduling ... Main activities under the definition of outage ... ENTSO-E Outage Business