OUTAGE BUSINESS PROCESS AND FORMAT

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

2019-09-25 APPROVED DOCUMENT

VERSION 1.1

OUTAGE BUSINESS PROCESS AND FORMAT

– of 64 –

European Network of Transmission System Operators for Electricity

ENTSO-E Outage Business Process and Format VERSION 1.1


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 unavailabilities ............................................. 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 .................................... 38 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

– 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

List of figures 80

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

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

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

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

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

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

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

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

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

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

List of tables 91

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

– of 64 –




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

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

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

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

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

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

Table 8 - Ref_MarketDocument ............................................................................................ 34 101

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

Table 10 - update / modification of the Elements ................................................................... 36 103

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

Table 12 - IsBasedOn dependency ....................................................................................... 38 105


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

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

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

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

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

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

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

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



Table 24 - Attributes of Network outage configuration assembly 125 model::Ref_MarketDocument ................................................................................................ 50 126

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

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

Table 27 - Attributes of Network outage configuration assembly 130 model::Other_MarketParticipant ............................................................................................ 51 131

Table 28 - Attributes of Network outage configuration assembly 132 model::Specific_RegisteredResource .................................................................................... 51 133

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

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

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

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

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

– of 64 –




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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

168

169

– of 64 –




Copyright notice: 170

Copyright © ENTSO-E. All Rights Reserved. 171

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

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

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

Maintenance notice: 184

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

mailto:[email protected]

– of 64 –




Revision History 187

Version Release Date Comments

1 0 2017-09-20 First version

1 1 2019-09-25 Sequence diagrams were updated. New data exchanges between information receiver and System operator.

Approved by SOC.

188

– of 64 –




1 Objective 189

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

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

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

– of 64 –




2 Glossary 195

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

3 Abbreviations 197

198

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

199

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

– of 64 –




4 Business process overview 200

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

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

• Definition of Outage Coordination Regions and relevant assets 206

• Development and update of availability plans of relevant assets 207

• Execution of availability plans 208

A brief description of the aforementioned steps of the Business Process is provided in the next 209 table. 210

Table 1 – Steps of business process 211

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.

212

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

of Outages. 214

215

– of 64 –




216 Figure 1: High Level Business Process Flowchart Overview 217

218

219

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

– of 64 –




5 Requirements from the OPS 220

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

OPS (SO GL) have to be fulfilled. 222

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

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

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

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

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

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

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

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

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

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

timeframes 233

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

plans by all TSOs of the outage coordination region. 235

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

apply the established regional coordination operational procedures. 237

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

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

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

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

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

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

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

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

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

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

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

particular, the methodology shall be based on: 249

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

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

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

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

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

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

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

SGUs; 257

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

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

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

system which connect different control areas. 261

• systematic relevance of all critical network elements. 262

263

– of 64 –




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

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

whether it is or not in operation 266

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

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

269

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

for the following time periods: 271

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

• directly following maintenance of the relevant asset 273

274

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

• communications channels to be used 276

• IT tools and infrastructures 277

• Interoperability issues among the data and files exchanged 278

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

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

282

6 Roles and Responsibilities 283

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

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

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

287

6.1 TSO(s) 288

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

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

and action. 291

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

• Setup of output coordination regions and regional security coordinators 293

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

their region 295

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

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

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

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

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

region 301

1 could be also considered as a special switching state

– of 64 –




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

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

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

systems. 305

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

coordination region, of relevant assets. 307

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

ENTSO-E, OPDE, etc). 309

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

distribution system 311

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

of relevant assets for each outage coordination region. 313

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

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

coordinators) 316

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

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

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

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

the important support role of the RSC. 321

322

6.2 DSO/CDSO 323

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

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

326


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

planning agents and that are not interconnecting different control areas 329

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

system 331

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

incompatibilities 333


335

6.3 Facility Owner 336

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

of the key elements of the power grid. 338


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

their assets 341


– of 64 –




343

6.4 Regional Security Coordinator 344

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

capacity calculation region. 346

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

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

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

• Perform regional outage coordination 350

• Coordinate with other Regional Security Coordinators 351

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

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

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

355

6.5 Outage Planning Agent 356

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

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


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

• Provide indicative availability plans for its relevant assets. 361

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

Outage Planning Incompatibilities 363

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

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

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

time execution 367

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

status 369

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

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

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

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

374

6.6 NRAs 375

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

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

concerning common rules for the internal market in electricity. 378


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

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

382

– of 64 –




7 High Level Business Process Description 383

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

individual steps are further described in the next paragraphs. 385

386

8 Definition of Outage coordination regions and relevant assets 387

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

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

relevant activities are summarized in the following table. 390

391

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 392 assets step 393 394

Definition of Outage Coordination Regions and Regional Security Coordinators 395

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

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

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

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

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

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

Provision of single list of relevant assets 402

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

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

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

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

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

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

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.

– of 64 –




Update of single list of relevant assets 409

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

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

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

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

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

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

all the involved parties. 416

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

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

– of 64 –




419

Figure 2: Step 1-Definition and Assessment of the relevant asset lists 420 421

9 Development and update of availability plans of relevant assets 422

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

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

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

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

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

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

– 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 428 relevant assets step 429 430

Appointment of outage planning agents 431

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

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

asset and informs the respective TSO about that appointment. 434

435

436

437

– of 64 –




Assessment of Long-Term Indicative Plans 438

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

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

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

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

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

outage coordination. 444

445

Provision of year-ahead availability plan proposals 446

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

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

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

calendar year for each of its relevant assets. 450

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

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

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

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

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

plans” 456

457

Assessment of the availability plans for Outage Planning Incompatibilities 458

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

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

actions: 461

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

detected outage planning incompatibilities 463

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

availability plan fulfilling the aforementioned conditions 465

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

remain 467

468

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

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

plan which: 471

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

DSO or CDSO where relevant 473

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

the outage planning incompatibilities 475

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

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

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

where relevant, the DSO or CDSO. 479

480

Provision of preliminary year-ahead availability plans 481

– of 64 –




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

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

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

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

in the distribution and/or closed distribution system 486

487

Validation of year-ahead availability plans 488

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

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

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

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

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

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

CDSO). 495

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

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

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

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

involved in an outage planning incompatibility during the period concerned 500

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

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

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

DSO or CDSO where relevant 504

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

ahead availability plans for all relevant assets 506

507

Final year-ahead availability plans 508

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

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

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

ENTSO for Electricity operational planning data environment 512

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

availability plan for each internal relevant asset. 514

515

Updates to the final year-ahead availability plans 516

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

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

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

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

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

whether the amendment leads to outage planning incompatibilities 522

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

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

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

– of 64 –




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

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

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

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

operational planning data environment 530

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

requested amendment. 532

533

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

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

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

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

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

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

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

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

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

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

on the ENTSO for Electricity operational planning data environment. 544

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

the procedure for amendment 546

547

– of 64 –




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

presented in the next flowchart (Figure 3). 549

550

551

552 553

554 555 556 557 558 559

560

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

– of 64 –




561 Figure 3: Planning of Assets Availability 562

563

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

process 565

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

line 567

10 Execution of availability plans 568

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

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

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

– of 64 –




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

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

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

574


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 575

576

577

Information about the elements with “testing” status 578

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

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

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

• a detailed test plan 582

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

power generating module or a relevant demand facility 584

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

relevant asset is a relevant grid element 586

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

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

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

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

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

592

Handling of Forced Outages 593

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

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

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

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

regulatory authority accordingly. 598

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

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

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

– of 64 –




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

• the reason for the forced outage 603

• the expected duration of the forced outage 604

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

assets for which it is the outage planning agent. 606

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

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

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

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

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

time-limit. 612

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

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

information. 615

616

Real-time execution of the availability plans 617

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

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

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

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

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

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

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

limits. 625

626

627

– of 64 –




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

4: Execution of Availability Plans). 629

630

Figure 4: Execution of Availability Plans 631

632

Notes: 633

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

process 635

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

637

638

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

– of 64 –




11 Sequence diagram for planned/unplanned unavailabilities 639

The following sequence diagram shows the submission process for planned/unplanned 640 unavailabilities: 641 642

643

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

645

System Operator (SO) role may represent following entities: 646

1. TSO, 647

2. DSO, 648

3. CDSO, 649

4. FO, 650

5. OPA 651

652

Initial outage planning data is provided by System operators to their Data Providers (Outage 653 Planning Agent) which submit data to their RSCSP. 654 655 Whenever Data Provider (Outage Planning Agent) sends updates in planned unavailability 656 information, the RSCSP will provide to the interested System Operator (for this particular 657 element) the updated planned unavailability information. 658 659 In the next step the RSCSP will merge all the most up to date unavailability plans (Out of scope 660 of this Implementation Guide) and will provide to all the System Operators participating in the 661 service, the specific TSO merged outage planning with only the information for the elements 662 flagged as interested for each TSO. Apart from this, the RSCSP will also publish a global 663 merged outage planning for RSCSPs and all the interested parties. The global merge includes 664 all the planned unavailability information for all the elements included in the service. 665 666

sd Submit planned unav a i labi l i ty infor mat ion

:System operator :Data provider

«Outage Planning Agent»

Out of scope of this

document

This is only for

interested System

Operators

:Information receiver

«RSC»


This is for all RSCs

and interested parties

participating in the

service

Acknowledgement(Acknowledgement_MarketDocument)

Planned unavailability information

(OutageSchedule_MarketDocument)

SO specific merged outage planning


Global Merged outage planning


Planned data summary()

Merge planned unavailability information()

Planned unavailability


Planned unavailability information


– of 64 –




12 Outage Schedule document 667

Outage Schedule is defined as unavailability information which is exchanged upon the Network 668 Elements. 669 670 RSC or interested parties willing to receive the global merged outage planning will have to 671 subscribe to the service of the EIC code function. 672 673 Each outage schedule document contains fields as described in Table below: 674 675

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 A44=RSC

receiver_MarketParticipant.mRID EIC code of receiver

receiver_MarketParticipant.marketRole.type A04 = SO 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

– of 64 –




day_MarketObjectStatus.status A05 means daytime/daylight day_MarketObjectStatus.status A03 means permanent)

week_MarketObjectStatus.status A03 = deactivate A05 = active

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 alternative grid element.

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 676 677

– of 64 –




13 Examples of outages 678

For better overview in the following tables only the information which is relevant for the process 679 is described in the examples: 680 681


OutageSchedule_MarketDocument

mRID 5bf2f5131d69-4f20-b96a-8f9637caf45

revisionNumber 1

type A78 = Transmission unavailability,

process.processType A36 = Creation

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

sender_MarketParticipant.marketRole.type A04 = SO

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 682 Table 6 describes a planned unavailability of TSO APG for one element in the transmission 683 grid. 684 685 686 687 688

– 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 689

690

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

692

Example files can be requested from the OPC Project group 693

694 695 696 697 698

– of 64 –




14 Element information 699

Element information is sent by System Operator to the Data Provider who submits information 700 to RSCI (using Ref_MarketDocument). 701 702 Network element is considered as part of the grid treated as relevant or non-relevant asset 703 (defined in GLSO) on which the unavailability information is exchanged between Parties within 704 Outage Schedule document. 705 706 Whenever Data Provider (Outage Planning Agent) sends element updates information, the 707 RSCSP will provide to the interested System Operator (for this particular element) the updated 708 element list information. 709 710 In the next step the RSCSP will merge all the most up to date element updates information (Out 711 of scope of this Implementation Guide). Apart from this, the RSCSP will also publish a global 712 merged outage element list for RSCSPs and all the interested parties. The global merge list 713 includes all the merged elements included in the service. 714 715 The following sequence diagram shows the submission process for element update information. 716 717

718 Figure 6: submission process for element update information 719 720

sd Submit element infor mat ions

:System operator :Data provider

«Outage Planning Agent»

Out of scope of this

document

This is only for the

interested System

Operators


«RSC»


This is for all RSCs

and interested parties

participating in the

service

Element Update(Ref_MarketDocument)

Provide new elements information

(Ref_MarketDocument)

Acknowledgement(Acknowledgement_MarketDocument)

Global merged element list(Ref_MarketDocument)

Element update information(Ref_MarketDocument)

Merge element information()

– of 64 –




721 Ref_MarketDocument contain following fields: 722 723


Ref_MarketDocument

mRID Unique ID

type A95 - ConfigurationDocument,

sender_MarketParticipant.mRID EIC code of sender

sender_MarketParticipant.marketRole.type A04 = SO A44 = RSC

receiver_MarketParticipant.mRID EIC code of receiver

receiver_MarketParticipant.marketRole.type A04 = SO 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 A01: Yes A02: No

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 grid element

Table 8 - Ref_MarketDocument 724 725

– of 64 –




15 Examples element information 726

In the following tables only the information which is relevant for the process is described 727 including examples: 728 729


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: Yes A02: No

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. 730 731

Example files can be requested from the OPC Project group 732

– of 64 –





Ref_MarketDocument

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



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

endLifetime_DateAndOrTime.date 2016-31-12

733 Table 10 - update / modification of the Elements 734 735 Table 10 illustrates deactivation of an element by using „A37-Modification” and changing the 736 “endLifetime_Datum” for specific time in future. 737 Changes of elements can only be applied by element owning TSO except field “CancelledTS” 738 where each TSO may use A01 for marking element as interesting for his TSO or A02 for marking 739 element as non- interesting for his TSO. 740 741


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

742 Table 11 - delete “interesting for” Information TSO TenneT NL 743 744 Table 11 illustrates how TSO TenneT NL marks element with registeredResource.mRID = 10T-745 PL-SE-000016 by sending process.processType = A39 (Synchronisation) and CancelledTS = 746 A02 (Deactivated), as “non-interesting for” for TenneT NL. 747 748 Example files can be requested from the OPC Project group 749 750 751

– of 64 –




752

16 Outage scheduling document contextual model 753

16.1 Overview of the model 754

Figure 7 shows the model. 755

756

Figure 7: Network element maintenance scheduling document contextual model 757 758

– of 64 –




17 IsBasedOn relationships from the European style market profile 759

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

Table 12 - IsBasedOn dependency 762

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

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

763

764

– of 64 –




18 Outage scheduling document assembly model 765



768

Figure 8: Network element maintenance scheduling document assembly model 769

770

771 772 773

– of 64 –




18.2 IsBasedOn relationships from the European style market profile 774

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

level. 776



Alternative_RegisteredResource TC57CIM::IEC62325::MarketCommon::RegisteredResource

OutageSchedule_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument

Reason TC57CIM::IEC62325::MarketManagement::Reason


SwitchedBack_Time_Period TC57CIM::IEC62325::MarketManagement::Period


778

18.3 Detailed Network element maintenance scheduling document assembly model 779

OutageSchedule_MarketDocument root class 780

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

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

Table 14 shows all attributes of OutageSchedule_MarketDocument. 786

Table 14 - Attributes of Network element maintenance scheduling document assembly 787 model::OutageSchedule_MarketDocument 788

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.

– 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.

789

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

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

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..*]

793

Alternative_RegisteredResource 794

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

Table 16 shows all attributes of Alternative_RegisteredResource. 797

Table 16 - Attributes of Network element maintenance scheduling document assembly 798 model::Alternative_RegisteredResource 799

Order mult. Attribute name / Attribute type Description

0 [1..1] mRID

ResourceID_String

The unique identification of a resource.

800

Reason 801

The motivation of an act. 802

– of 64 –




Table 17 shows all attributes of Reason. 803

Table 17 - Attributes of Network element maintenance scheduling document assembly 804 model::Reason 805

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

806

RegisteredResource 807


Table 18 shows all attributes of RegisteredResource. 810

Table 18 - Attributes of Network element maintenance scheduling document assembly 811 model::RegisteredResource 812


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

813

– of 64 –




SwitchedBack_Time_Period 814

The identification of a time interval or a duration. 815

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

Table 19 shows all attributes of SwitchedBack_Time_Period. 818

Table 19 - Attributes of Network element maintenance scheduling document assembly 819 model::SwitchedBack_Time_Period 820


0 [1..1] timeInterval


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

821

TimeSeries 822

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

Table 20 shows all attributes of TimeSeries. 824

Table 20 - Attributes of Network element maintenance scheduling document assembly 825 model::TimeSeries 826


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.

– 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.

– 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.

827

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

– of 64 –




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

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 electronic 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.

831

832

833 834

– of 64 –




19 Network outage configuration contextual model 835



838

Figure 9: Network outage configuration contextual model 839





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

– of 64 –





Ref_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument


Specific_RegisteredResource TC57CIM::IEC62325::MarketCommon::RegisteredResource


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

844

– of 64 –




20 Network outage configuration assembly model 845



848

849

Figure 10: Network outage configuration assembly model 850



– of 64 –







Other_MarketParticipant TC57CIM::IEC62325::MarketCommon::MarketParticipant

Ref_MarketDocument TC57CIM::IEC62325::MarketManagement::MarketDocument

Specific_RegisteredResource TC57CIM::IEC62325::MarketCommon::RegisteredResource


855

20.3 Detailed Network outage configuration assembly model 856

Ref_MarketDocument root class 857

An electronic document containing the information necessary to satisfy the requirements of the 858 configuration management process. 859

The Ref_MarketDocument is used to transmit the information necessary to configure the outage 860 planning configuration process. 861

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

Table 24 shows all attributes of Ref_MarketDocument. 864

Table 24 - Attributes of Network outage configuration assembly 865 model::Ref_MarketDocument 866

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)

867

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

– of 64 –




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

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.[]

871

Domain 872

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

Table 26 shows all attributes of Domain. 875

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

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.

877

Other_MarketParticipant 878

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

Table 27 shows all attributes of Other_MarketParticipant. 881

Table 27 - Attributes of Network outage configuration assembly 882 model::Other_MarketParticipant 883


0 [1..1] mRID

PartyID_String

The identification of a party in the energy market.

884

Specific_RegisteredResource 885


Table 28 shows all attributes of Specific_RegisteredResource. 888

Table 28 - Attributes of Network outage configuration assembly 889 model::Specific_RegisteredResource 890


0 [1..1] mRID

ResourceID_String


891

– of 64 –




TimeSeries 892

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

Table 29 shows all attributes of TimeSeries. 896

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


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

– 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.

– 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.

898

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

– of 64 –




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

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.[]

902

903

– of 64 –




21 Primitives and Datatypes 904

21.1 Primitives 905

Date primitive 906

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

DateTime primitive 908

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

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

Decimal primitive 911

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

Duration primitive 913

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

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

time expression and, after it, nH identifies a number of hours, nM a number of minutes and nS a number 916

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

integers. 918

Float primitive 919

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

String primitive 921

A string consisting of a sequence of 8 bit characters. The character encod ing is UTF-8. The string length 922

is unspecified and unlimited. 923

22 Datatypes 924

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

is as follows: 926

22.1 ESMP_DateTimeInterval compound 927

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

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

Table 31 shows all attributes of ESMP_DateTimeInterval. 930

Table 31 - Attributes of ESMPDataTypes::ESMP_DateTimeInterval 931

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.

932

22.2 AreaID_String datatype 933

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

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

scheme for domain identification. 936

Table 32 shows all attributes of AreaID_String. 937

– of 64 –




Table 32 - Attributes of ESMPDataTypes::AreaID_String 938


[1..1] codingScheme

CodingSchemeTypeList

DomainQualification.

[1..1] value

String

Main Core value Space.

939

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

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

Name Constraint Type Expression of constraint

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

942

22.3 BusinessKind_String datatype 943

The coded identification of the business type. 944

Table 34 shows all attributes of BusinessKind_String. 945

Table 34 - Attributes of ESMPDataTypes::BusinessKind_String 946


[1..1] value

BusinessTypeList


947

22.4 Characters200_String datatype 948

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

The string length is restricted to 200 characters. 950

Table 35 shows all attributes of Characters200_String. 951

Table 35 - Attributes of ESMPDataTypes::Characters200_String 952


[1..1] value

String

The string length is restricted to 200 characters.

953

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

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



956

– of 64 –




22.5 ESMP_DateTime datatype 957

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

Table 37 shows all attributes of ESMP_DateTime. 959

Table 37 - Attributes of ESMPDataTypes::ESMP_DateTime 960


[1..1] value

DateTime


961

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

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


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))

964

22.6 ESMP_Voltage datatype 965

The coded identification of a voltage value. 966

Table 39 shows all attributes of ESMP_Voltage. 967

Table 39 - Attributes of ESMPDataTypes::ESMP_Voltage 968

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.

969

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

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


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

value precision INV choice=simple

unit Constant

KVT

– of 64 –





unit Fixed

KVT

972

22.7 ESMPBoolean_String datatype 973

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

Table 41 shows all attributes of ESMPBoolean_String. 975

Table 41 - Attributes of ESMPDataTypes::ESMPBoolean_String 976


[1..1] value

IndicatorTypeList


977

22.8 ESMPVersion_String datatype 978

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

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

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

number. 982

Table 42 shows all attributes of ESMPVersion_String. 983

Table 42 - Attributes of ESMPDataTypes::ESMPVersion_String 984


[1..1] value

String


985

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

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


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

988

22.9 ID_String datatype 989

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

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

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

capacity auction identification, market agreement identification, etc. 993

- a party (originator of the exchange) that provides a unique identification in the framework of a 994

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

Table 44 shows all attributes of ID_String. 996

– of 64 –




Table 44 - Attributes of ESMPDataTypes::ID_String 997


[1..1] value

String


998

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

Table 45 - Restrictions of attributes for ESMPDataTypes::ID_String 1000



1001

22.10 MarketRoleKind_String datatype 1002

The identification of the role played by a party. 1003

Table 46 shows all attributes of MarketRoleKind_String. 1004

Table 46 - Attributes of ESMPDataTypes::MarketRoleKind_String 1005


[1..1] value

RoleTypeList


1006

22.11 MeasurementUnitKind_String datatype 1007

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

be in compliance with UN/ECE Recommendation 20. 1009

Table 47 shows all attributes of MeasurementUnitKind_String. 1010

Table 47 - Attributes of ESMPDataTypes::MeasurementUnitKind_String 1011


[1..1] value

UnitOfMeasureTypeList


1012

1013

22.12 MessageKind_String datatype 1014

The coded type of a document. 1015

Table 48 shows all attributes of MessageKind_String. 1016

Table 48 - Attributes of ESMPDataTypes::MessageKind_String 1017


[1..1] value

MessageTypeList


– of 64 –




1018

22.13 PartyID_String datatype 1019

The identification of an actor in the energy market. 1020


scheme for market participant identification. 1022

Table 49 shows all attributes of PartyID_String. 1023

Table 49 - Attributes of ESMPDataTypes::PartyID_String 1024


[1..1] codingScheme



[1..1] value

String


1025

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

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



1028

22.14 ProcessKind_String datatype 1029

The coded identification of the nature of process. 1030

Table 51 shows all attributes of ProcessKind_String. 1031

Table 51 - Attributes of ESMPDataTypes::ProcessKind_String 1032


[1..1] value

ProcessTypeList


1033

1034

22.15 PsrType_String datatype 1035

The coded type of a power system resource. 1036

Table 52 shows all attributes of PsrType_String. 1037

Table 52 - Attributes of ESMPDataTypes::PsrType_String 1038


[1..1] value

AssetTypeList


1039

– of 64 –




22.16 ReasonCode_String datatype 1040

The coded motivation of an act. 1041

Table 53 shows all attributes of ReasonCode_String. 1042

Table 53 - Attributes of ESMPDataTypes::ReasonCode_String 1043


[1..1] value

ReasonCodeTypeList


1044

22.17 ReasonText_String datatype 1045

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

Table 54 shows all attributes of ReasonText_String. 1047

Table 54 - Attributes of ESMPDataTypes::ReasonText_String 1048


[1..1] value

String


1049

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

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



1052

22.18 ResourceID_String datatype 1053

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


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

Table 56 shows all attributes of ResourceID_String. 1057

Table 56 - Attributes of ESMPDataTypes::ResourceID_String 1058


[1..1] codingScheme



[1..1] value

String


1059

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

– of 64 –




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



1062

22.19 Status_String datatype 1063

The identification of the status of an object. 1064

Table 58 shows all attributes of Status_String. 1065

Table 58 - Attributes of ESMPDataTypes::Status_String 1066


[1..1] value

StatusTypeList


1067

22.20 UnitSymbol datatype 1068

A code to identify an analog measurement. 1069

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

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

unique within a business context such as capacity auction identification, marke t agreement 1072

identification, etc. 1073

Table 59 shows all attributes of UnitSymbol. 1074

Table 59 - Attributes of ESMPDataTypes::UnitSymbol 1075


[1..1] value

UnitSymbol


1076

1077

22.21 YMDHM_DateTime datatype 1078

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

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

Table 60 shows all attributes of YMDHM_DateTime. 1081

Table 60 - Attributes of ESMPDataTypes::YMDHM_DateTime 1082

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.

1083

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

– of 64 –




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


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

1086

1087

OUTAGE BUSINESS PROCESS AND FORMAT

Documents

Transcript of OUTAGE BUSINESS PROCESS AND FORMAT