BRS (BUSINESS REQUIREMENT SPECIFICATION)

Transcription

1 BRS (BUSINESS REQUIREMENT SPECIFICATION) FOR THE NORDIC TSO DETERMINE TRANSFER CAPACITY MODEL SHOW CASE FOR USAGE OF UN/CEFACT STANDARDS Business domain: Energy Business process: Nordic TSO message exchange Version: 1.1.B Status: Show case for UN/CEFACT based message exchange Not for implementation Date: December 16 th, 2009

2 CONTENT 1 INTRODUCTION BACKGROUND ABOUT THIS DOCUMENT TRANSFER CAPACITY ALLOCATION OVERVIEW PROJECT ORGANISATION REFERENCES CHANGE LOG OVERVIEW OF BUSINESS AREAS IN THE NORDIC ENERGY MARKET DETERMINE TRANSFER CAPACITY EBIX, EFET AND ENTSO-E HARMONISED ROLES USED IN DETERMINE TRANSFER CAPACITY BUSINESS PARTNER VIEW, DETERMINE TRANSFER CAPACITY BUSINESS ENTITY VIEW, DETERMINE TRANSFER CAPACITY BUSINESS AREA: DETERMINE TRANSFER CAPACITY PROCESS AREA: PROPOSE TRANSFER CAPACITY PROCESS AREA: NOTIFY TRANSFER CAPACITY BUSINESS ENTITY VIEW, TRANSFER CAPACITY MESSAGE RULES GOVERNING THE TRANSFER CAPACITY MESSAGE Header Document, Identification Header Document, Type Header Document, Creation Header Document, Process Type Header Document, Version Header Party, Sender, Identification Header Party, Sender, Role Header Party, Receiver, Identification Header Party, Receiver, Role Transfer Capacity Notification, Start Transfer Capacity Notification, End Transfer Capacity Notification, Domain Proprietary Information Type Capacity Time Series, Identification Capacity Time Series, Business Type Capacity Time Series, Product Capacity Time Series, In Area Capacity Time Series, Out Area Capacity Time Series, Measure Unit Capacity Time Series, Auction Identification Capacity Time Series, Corridor Rules governing the Time Series Period class Time Series Period, Start Time Series Period, End Time Series Period, Resolution Rules governing the Quantity Observation class Quantity Observation, Position Quantity Observation, Quantity Rules governing the Reason class Reason Status, Reason (Code) Reason Status, Reason (Text) BUSINESS RULES TRANSFER CAPACITY DOCUMENT IN THE NORDIC COUNTRIES DATE AND TIME ACKNOWLEDGEMENT PROCESS BUSINESS PARTNER VIEW, ACKNOWLEDGE BUSINESS DOCUMENT BUSINESS ENTITY VIEW, ACKNOWLEDGE BUSINESS DOCUMENT BUSINESS AREA: ACKNOWLEDGE BUSINESS DOCUMENT Acknowledgement of receipt Acknowledgement of processing Page: 2

3 5.4 BUSINESS ENTITY VIEW, ACKNOWLEDGE BUSINESS DOCUMENT RULES GOVERNING THE ACKNOWLEDGEMENT DOCUMENT Acknowledgement Document, Identification Acknowledgement Document, Creation Acknowledgement Document, Process Type Header Party, Sender, Identification Header Party, Sender, Role Header Party, Receiver, Identification Header Party, Receiver, Role Reference Document, Identification Reference Document, Version Reference Document, Type Rules governing the Reason Status class Reason Status, Reason (Code) Reason Status, Reason (Text) APPENDIX A COMMUNICATION APPENDIX B AN EXAMPLE OF TECHNICAL IMPLEMENTATION B.1 TRANSFER CAPACITY MESSAGES EXCHANGE TO/FROM NOIS B.2 SEQUENCE OF TRANSFER CAPACITY MESSAGES SENT TO/FROM NOIS B.3 BUSINESS RULES FOR TRANSFER CAPACITY MESSAGES SENT TO/FROM NOIS B.3.1 TRANSMISSION CAPACITY PROPOSALS B.3.2 ELBAS CAPACITY B.3.3 CUT CORRIDOR CAPACITY B.3.4 OUT OF NORDEL TRANSMISSION CAPACITY B.3.5 CAPACITY REDUCTION REASONS B.3.6 VALIDATED ELSPOT TRADING CAPACITY TO TSO (OUTPUT FROM NOIS) B.3.7 VALIDATED ELSPOT TRADING CAPACITY TO NORDPOOL (OUTPUT FROM NOIS) B.3.8 ELBAS TRADING CAPACITY TO NORDPOOL (OUTPUT FROM NOIS) B.3.9 ELBAS TRADING CAPACITY TO TSO (OUTPUT FROM NOIS) B.3.10 CAPACITY REDUCTION REASONS NOIS EXPORT APPENDIX C NOIS REASON TEXT CODES APPENDIX D DICTIONARY APPENDIX E COMPARISON BETWEEN ENTSO-E AND NORDIC TSO XML FORMAT E.1 TRANSFER CAPACITY DOCUMENT E.2 ACKNOWLEDGEMENT DOCUMENT Page: 3

4 1 INTRODUCTION 1.1 Background Today the Nordic TSOs exchange messages based on several different formats and standards, such as Ediel (DELFOR/MSCONS), NOIS XML messages based on ENTSO-E IGs and Excel documents. In addition the Nordic TSOs have communications towards other European countries, such as Germany, the Netherlands and Poland, using even more standards, such as NorNed xml and ENTSO-E standards. For efficiency reasons the four Nordic TSOs and Nord Pool Spot have set up a project for migration of the message exchanges towards one common message standard. The project is run as NORDEL project with the Nordic Ediel Group as the steering group. The aim is to define message exchange models that can be used for all message exchanges between the Nordic TSOs and Nord Pool Spot. This document is a show case of a Business Requirement Specification (BRS) detailing the message exchanges related to transfer capacity. The focus of the document is the business aspects of the message exchanges and the basis for the document is the ENTSO-E ECAN IG. The BRS is accompanied by a Requirements Specifications Mapping (RSM), serving to separate the aspects of a requirement that are of greatest concern to business interests from those that are of concern to technical design interests. 1.2 About this document This BRS is based on the ENTSO-E ECAN implementation guide [1], the ebix, EFET and ENTSO-E Harmonised role model [3] and UN/CEFACT Modelling Methodology version 2 (UMM) [4], while the related RSM (HTML model and XML schemas) are based on UN/CEFACT UML Profile for Core Components version 1 (UPCC) and UN/CEFACT XML Naming and Design Rules version 2 (NDR). The intention with the documents is to show how a UN/CEFACT compliant model and related documents may look like. The transfer capacity documents are not expected to be implemented in the near future between the Nordic TSOs. The Nordic TSO Market model project for data exchange is however continuing making BRSs for areas such as scheduling, ancillary services, and bids, which are expected to be implemented in the near future. The related technical documents will be fully based on the ENTSO-E principles for usage of XML. When the term TSO is used in this document it includes also Nord Pool and Nord Pool Spot. 1.3 Transfer capacity allocation overview There are some network grids within the ENTSO-E domain which are affected by structural congestion. Various congestion management methods such as, explicit auctioning, implicit auctioning, explicit auctioning involving two or more System Operators, etc. have been devised and implemented. The prerequisite for each of these methods is a transparent, non-discriminatory capacity allocation process in compliance with European regulations in particular EC 1228/2003. Allocated transmission capacity, which can be on a long-term, daily or intraday basis, is validated during the final day ahead or intraday Scheduling process for cross border transactions. This BRS is focussed on providing the generic information models for the data exchange between the Transmission Capacity Allocator, the System Operators and the International System Operator participating in the capacity market for cross border scheduling in the Nordic countries. The information models in question cover the essential requirements of all the congestion management methods identified above, however limited to those used in the Nordic market. When determining the transfer capacities and margins between the Nordic countries the following three terms are used (see also [9]): Page: 4

5 Total Transfer Capacity (TTC) Transmission Reliability Margin (TRM) TTC is the maximum exchange program between two areas compatible with operational security standards applicable at each system if future network conditions, generation and load patterns were perfectly known in advance. TRM is a security margin that copes with uncertainties on the computed TTC values arising from: a) Unintended deviations of physical flows during operations due to physical functioning of loadfrequency regulation, b) Emergency exchanges between System Operators to cope with unexpected unbalanced situations in real time, c) Inaccuracies, e.g. in data collection and measurements. In practice, only the definition a) described above is used in the Nordic countries. The present TRM values for each connection are agreed upon in the System Operation Agreement. Net Transfer Capacity (NTC) The Net Transfer Capacity NTC (trading capacity) is defined as: NTC = TTC TRM NTC is the maximum exchange program between two areas compatible with security standards applicable in both areas and taking into account the technical uncertainties on future network conditions. The TTC between two subsystems is jointly determined by the TSOs on both sides of the interconnection. When determining the capacity on the interconnection between two subsystems, the capacity is calculated by the System Operators on each side of the connection by using computer programs based on coordinated network models. If the values differ, the lowest value is used. The objective is to give the market as high capacity for energy trade as possible taking into account outages and faults in the network. The ability to transmit power shall be calculated for each state of operation. This applies both to transmissions within each subsystem and to exchanges between subsystems. Most frequently, this is achieved by means of a transmission corridor being defined, and static and dynamic simulations determine how much power can be transmitted in any direction through the corridor before thermal overloads, voltage collapse and/or instability arise following a dimensioning fault. In the corridor, an arbitrary number of lines on different levels of voltage can be included. The TTC is the maximum transmission of active power, which is permitted in transmission corridors between the subsystems or individual installations. If the transfer capacity is exceeded, measures must be taken. The transfer capacity is set, using a certain safety margin (stability, voltage etc), at the transmission levels, which will entail network collapse in the event of dimensioning faults. The NTC values between all the subsystems are given to Nord Pool Spot for day-ahead trading (Elspot) in its entirety. The System Operators guarantee the NTC value given for Elspot trading. The remaining cross- Page: 5

6 border transmission capacity available under actual operational conditions after the Elspot notification of planned trading flow is offered to the intra-day market Elbas. Capacities are updated automatically when market trades between parties across borders are made. Market splitting separates the Elbas market areas dynamically when congestion occurs. On the HVDC-connections, the thermal capacity (TTC) is normally used as NTC value in both directions and there is no need for any margin (TRM). However, to be in line with the ENTSO-E ECAN IG, which is the basis for the transfer capacity process described in this document, the terms ATC (Available Transfer Capacity) will be used instead of NTC. Based on the actual calculation principles used for transfer capacities in the Nordic countries the ENTSO-E definition of ATC and the Nordel definition of NTC will coincide. In addition the term OC (Operational Capacity) will be used for available transfer capacity as established during the operational day, i.e. the capacity available after closure of the Elbas market. Figure 1 outlines the generic steps that are required in a capacity allocation process. This BRS defines the data interchanges that will be required to enable such a generic process to operate. The registration and qualification of market participants to enable them to participate in the market is outside the scope of this guide. Figure 1: UseCase of the transmission capacity allocation process in the Nordic market There are two principle activities in such a process. The first step relates to the identification of all available transmission capacity that can be allocated. The available capacity has initially to be agreed between the System Operators through the International System Operator. The main actors in the process are the System Operators, International System Operator and the Transmission Capacity Allocator. The second step covers allocation activity itself and publication (distribution) of the available transmission capacity. Once agreed it is made available to the market participants through the Transmission Capacity Allocator. This BRS defines the information flows required to satisfy these two steps and it is particularly focused on the day-ahead capacity allocation market for implicit auctioning. 1.4 Project organisation The project is organized as a project group within Nordel. Steering group: Nordic Ediel Group (NEG): Christian Odgaard, Energinet.dk, cco@energinet.dk Heli Anttila, Fingrid, Heli.Anttila@fingrid.fi Oscar Ludwigs, SvK, Oscar.Ludwigs@svk.se Tor Åge Halvorsen, Nord Pool, Tor.Halvorsen@nordpool.com Tor Heiberg, Statnett, tor.heiberg@statnett.no Page: 6

7 Convenor: Jon-Egil Nordvik, Statnett, Secretary: Ove Nesvik, EdiSys, Project members: Antti Niemi, Nord Pool Spot, Christian Hoang Huy Le, Statnett, Christian Odgaard, Energinet.dk, Heli Anttila, Fingrid, Jan Owe, SvK, Jari Hirvonen, Fingrid, Jon-Egil Nordvik, Statnett, Ove Nesvik, EdiSys, Roar Grindstrand, Statnett, 1.5 References [1] ENTSO-E implementation guides, see ENTSO-E Modelling Methodology (EMM) ENTSO-E UCTE SO-SO Process ENTSO-E Scheduling System, ESS ENTSO-E Settlement Process, ESP ENTSO-E Reserve Resource Planning, ERRP ENTSO-E Capacity Allocation and Nomination, ECAN ENTSO-E Publication Document, EPD ENTSO-E Status Report, ESR ENTSO-E Acknowledgement process [2] ECP (Energy communication platform) Functional Specifications [3] The ebix, EFET and ENTSO-E Harmonised role model, see [4] UN/CEFACT Unified Modelling Methodology (UMM), see [5] UML Profile for Core Components (UPCC), see [6] UN/CEFACT XML Naming and Design Rules (NDR), see [7] ebix Modelling methodology and process models (EMD), see [8] Ediel Implementation guides, see [9] Principles for determining the transfer capacity in the Nordic power market del/docs/dls/ e.pdf 1.6 Change log Ver/rel/rev Changed by Date Changes 1.1.B Ove Nesvik Textual corrections Update of Nordic codes (Znn codes) 1.1.A Ove Nesvik The status of the document is changed to a Show case for UN/CEFACT based message exchange and an explanatory text is added, see paragraph B Ove Nesvik New SvK logo 1.0.A Ove Nesvik First release Page: 7

8 2 OVERVIEW OF BUSINESS AREAS IN THE NORDIC ENERGY MARKET This chapter gives a brief overview of the structure of the Nordic TSO Domain, i.e. the business areas and process area where the Nordic TSOs are involved and have common message exchanges. The top level of the structure of the Nordic TSO Domain as shown below is based on the ebix Energy market domain model, while the lower parts currently is based on the ECAN IGs from ENTSO-E. Figure 2: Overview of the Nordic TSO Domain In the rest of this document the Business area Determine transfer capacity is further elaborated. Page: 8

9 3 DETERMINE TRANSFER CAPACITY 3.1 ebix, EFET and ENTSO-E Harmonised roles used in Determine transfer capacity In the figure and definitions below the relevant parts of the ebix, EFET and ENTSO-E Harmonised role model are outlined. Figure 3: Outline of the Harmonised role model within the scope of capacity allocation Definitions (from the ebix, EFET and ENTSO-E Harmonised role model) : Market Balance Area: A geographic area consisting of one or more Metering Grid Areas with common market rules for which the settlement responsible party carries out a balance settlement and which has the same price for imbalance. A Market Balance Area may also be defined due to bottlenecks. Market Area: An area made up of several Market Balance Areas interconnected through AC or DC links. Trade is allowed between different Market Balance Areas with common market rules for trading across the interconnection. Allocated Capacity Area: A Market area where the transmission capacity between the Balance areas is given to the Balance Responsible Parties according to rules carried out by a Transmission Capacity Allocator. Trade between Balance areas is carried out on a bilateral or unilateral basis. System Operator: A party that is responsible for a stable power system operation (including the organisation of physical balance) through a transmission grid in a geographical area. The SO will also determine and be responsible for cross border capacity and exchanges. If necessary he may reduce allocated capacity to ensure operational stability. Transmission as mentioned above means "the transport of electricity on the extra high or high voltage network with a view to its delivery to final customers or to distributors. Operation of transmission includes as well the tasks of system operation concerning its management of energy flows, relibability of the system and availability of all necessary system services." (definition taken from the UCTE Operation handbook Glossary). Page: 9

10 Note 1: Additional obligations may be imposed through local market rules. Note 2: NOIS will act in the role as International System operator in the Determine transfer capacity process. Transmission Capacity Allocator: Manages the allocation of transmission capacity for an allocated capacity area. For explicit auctions: The Transmission Capacity Allocator manages, on behalf of the System Operators, the allocation of available transmission capacity for an Allocated capacity area. He offers the available transmission capacity to the market, allocates the available transmission capacity to individual Capacity Traders and calculates the billing amount of already allocated capacities to the Capacity Traders. Note: Nord Pool Spot will act in the role as Transmission Capacity Allocator in the Determine transfer capacity process in the Nordic countries. 3.2 Business Partner View, Determine transfer capacity In addition to the roles defined in the ebix, EFET and ENTSO-E Harmonised role model (see 3.1) the following partner types have been identified as relevant for the Business area Determine transfer capacity. Definitions: International System Operator: A cooperation of two or more System Operators across national borders, acting as a System operator for the combined area. Nord Pool Spot: NOIS: Nord Pool Spot is a specialisation of the generic role Transmission Capacity Allocator. Nord Pool Spot fixes the allocations through implicit auctioning. is a specialisation of the generic role International System Operator. NOIS is an information system for exchange of operational information between System Operators. 3.3 Business Entity View, Determine transfer capacity In addition to the domains defined in the ebix, EFET and ENTSO-E Harmonised role model (see 3.1) the following business entities have been identified as relevant for the Business area Determine transfer capacity. Transfer capacity: OC: Capacity exchanged between System operators and between System operators and the Transmission capacity allocator. The Transfer capacity can be split into Operational capacity (OC) and Available Transfer Capacity (ATC). Operational capacity exchanged between System operators. The OC is the available transfer capacity as established during the operational day, i.e. the capacity available after closure of the Elbas market. The OC is used for system operation and not for market purposes. The OC Page: 10

11 may be both higher and lower than the ATC. The OC may be negative. ATC: Available Transfer Capacity (ATC) exchanged between System operators and between System operators and the Transmission capacity allocator. The ATC for a certain market cannot be changed after the closure of the relevant market. The ATC may be negative. 3.4 Business area: Determine Transfer Capacity In the Nordic countries the congestion management is handled through implicit auctioning, involving the System Operators. The prerequisite is a transparent, non-discriminatory capacity allocation process in compliance with European regulations in particular EC 1228/2003. Allocated transmission capacity, which in the Nordic countries are on a daily (Elspot) and hourly (Elbas) basis, is validated during the scheduling process for cross border transactions. In addition Operational capacity may be exchanged in the future as an intraday process. This Business Requirement Specification (BRS) is focused on providing the generic information models for the data exchange between the System Operators and the Transmission Capacity Allocator. Needed communication towards the various market players participating in the capacity market for cross border scheduling may be covered on a later stage. Figure 4: UseCase: Determine transfer capacity Figure 4 outlines the steps that are required in a capacity allocation process in the Nordic countries. This BRS defines the data interchanges that will be required to enable such a generic process to operate. In the Nordic countries the first step is identification of all Available Transmission Capacity (ATC) that can be allocated. The available capacity has to be agreed between the System Operators through the UseCase Propose transfer capacity. Once agreed it is made available to the market participants through the Transmission Capacity Allocator, i.e. UseCase Notify transfer capacity. The main actors in the process are the System Operators and the Transmission Capacity Allocator. In the future (today only relevant for the NorNed cable) it may be possible for System Operators to adjust the ATC during the intra-day phase, i.e. determine the Operational Capacity (OC), also this according to the UseCase Propose transfer capacity. This BRS defines the information flows required to satisfy these steps. The Roles that take part in the Determine Transfer Capacity calculation are: System Operators (TSO) who perform all network security calculations and has the overall responsibility for the definition of Available Capacity between Market Balance Areas; Page: 11

12 International System Operator who is an information system for exchange of operational information between the System operators. Transmission Capacity Allocator who provides data on the Already Allocated Capacity (AAC). For Available Transfer Capacity (ATC) the System Operators agree the capacity that is to be offered to the market through the International System Operator and this agreed capacity is transmitted to the affected System Operators and the Transmission Capacity Allocator, who makes the information available to the market. The process is further described in the next chapters. For Operational Capacity (OC) the System operators agree the capacity on an intra-day basis. The Business area Determine Transfer Capacity can be split into to two processes; Propose transfer capacity and Notify transfer capacity: Figure 5: Activity diagram: Determine transfer capacity 3.5 Process area: Propose transfer capacity Figure 6: UseCase: Propose transfer capacity When available and operational transfer capacities are agreed for exchange between the Nordic countries the roles that take part in the process are the System Operators and the International System Operator. When the capacities are agreed between a Nordic country and a non-nordic country the approval process can be run as a bilateral process between a Leading System Operator and a Following System Operator, such as for the NorNed cable. In the rest of this BRS it is assumed that the process is run between Nordic countries. Between a System operator and the International System Operator, plans for TTC are exchanged in order to determine Transfer Capacity for the operation of the cross border connection. As a result of this process ATC is established by the International system operator and thereafter notified to affected parties. It is used to plan operation of the cross border connection. Page: 12

13 The process may be run as TTC, the day before operation or as OC during intra-day. A System Operator sends a proposal for transfer capacity, either TTC or OC, to the International System Operator. Time constraints: TTC: In due time before the market needs the information. OC: When needed, also during the operational day. Figure 7: Activity diagram: Propose transfer capacity 3.6 Process area: Notify transfer capacity Figure 8: UseCase: Notify transfer capacity After agreement of ATC the International System Operator notifies the offered capacity to the Transmission Capacity Allocator, who makes the information available to the market. In addition the International System Operator notifies affected System Operators. The notification process is run the day before operation. Page: 13

14 Figure 9: Activity diagram: Notify transfer capacity Page: 14

15 3.7 Business Entity View, Transfer capacity message In this chapter the details of the Transfer capacity message is defined. Figure 10: Class diagram: Transfer capacity message Page: 15

16 3.8 Rules governing the Transfer Capacity Message Header Document, Identification Definition of element Unique identification of the document for which the time series data is being supplied. A Capacity Document for a given set of time series and a given period may have a unique identification assigned by the sender of the document for all transmissions to the receiver. If the same identification number is used a new version number must be given. The identification of a document may not exceed 35 alphanumeric characters. This information is mandatory Header Document, Type Definition of element The coded type of the document being sent. The document type identifies the information flow characteristics. The initial code to be used is: A13: Interconnection capacity A31: Agreed capacity A32: Proposed capacity Refer to ENTSO-E Code list document for valid codes. The document type value must be exactly 3 alphanumeric characters (no blanks). This information is mandatory Header Document, Creation Definition of element Date and time of the creation of the document. The time must be expressed in UTC as YYYY-MMDDTHH:MM:SSZ. The date and time that the document was prepared for transmission by the application of the sender. The date and time must be expressed in UTC as YYYY-MM-DDTHH:MM:SSZ. This information is mandatory. Page: 16

17 3.8.4 Header Document, Process Type Definition of element The nature of the process that the document is directed at. The process type identifies the process to which the information flow is directed. Codes that may be used in this document: A07: Capacity allocation A15: Capacity determination Refer to ENTSO-E Code list document for valid codes. The process type value must be exactly 3 alphanumeric characters (no blanks). This information is mandatory Header Document, Version Definition of element Version of the document being sent. A document may be sent several times, each transmission being identified by a different version number that normally starts at 1 and increases sequentially. The document version is used to identify a given version of a time series set. The first version number for a given document identification shall normally be 1. The document version number, if used, must be incremented for each retransmission of a document that contains changes to the previous version. The receiving system should ensure that the version number for a document is unique in combination with the Header Document, Identification. A version number may not exceed 3 numeric characters. This information is dependent. Dependent on local market rules and will not necessarily be checked by the receivers. Page: 17

18 3.8.6 Header Party, Sender, Identification Definition of element Identification of the party that is the owner of the document and is responsible for its content. The sender of the document is identified by a unique coded identification. This code identifies the party that is the owner of the information being transmitted in the document and who is responsible for its content. The codification scheme used for the coded identification is indicated by the coding scheme attribute. It is a 3 character alphanumeric code. Refer to ENTSO-E Code list document for the valid list of codes. The maximum length of a sender s identification is 16 alphanumeric characters. The maximum length of the coding scheme code is 3 alphanumeric characters. Both the identification and the coding scheme are mandatory Header Party, Sender, Role Definition of element Identification of the role that is played by the sender. The sender role, which identifies the role of the sender within the document. Refer to ENTSO-E Code list document for the valid list of codes. The maximum length of a sender role is 3 alphanumeric characters. This information is mandatory Header Party, Receiver, Identification Definition of element Identification of the party who is receiving the document. The receiver of the document is identified by a unique coded identification. The codification scheme used for the coded identification is indicated by the coding scheme attribute. It is a 3 character alphanumeric code. Refer to ENTSO-E Code list document for the valid list of codes. The maximum length of a sender s identification is 16 alphanumeric characters. The maximum length of the coding scheme code is 3 alphanumeric characters. Both the identification and the coding scheme are mandatory. Page: 18

19 3.8.9 Header Party, Receiver, Role Definition of element Identification of the role that is played by the receiver. The receiver role, which identifies the role of the receiver within the document. Refer to ENTSO-E Code list document for the valid list of codes. The maximum length of a sender role is 3 alphanumeric characters. This information is mandatory Transfer Capacity Notification, Start Definition of element The beginning date and time of the period covered by the document. The capacity start period must be expressed with a UTC time as follows: YYYY-MM-DDTHH:MM:SSZ. This information provides the start date and time of the capacity period. The receiver will discard any time intervals outside the capacity period. The start and end date and time must be expressed as YYYY-MM-DDTHH:MM:SSZ. This information is mandatory Transfer Capacity Notification, End Definition of element The ending date and time of the period covered by the document. The capacity period must be expressed with a UTC time as follows: YYYY-MM-DDTHH:MM:SSZ. This information provides the end date and time of the capacity period. The receiver will discard any time intervals outside the capacity period. The end date and time must be expressed as YYYY-MM-DDTHH:MM:SSZ This information is mandatory. Page: 19

20 Transfer Capacity Notification, Domain Proprietary Information Type Definition of element The domain covered within the Capacity Document. The identification of the domain that is covered in the Capacity Document. The codification scheme used for the coded identification is indicated by the coding scheme attribute. It is a 3 character alphanumeric code. Refer to ENTSO-E Code list document for the valid list of codes. The maximum length of this information is 16 alphanumeric characters. The maximum length of the coding scheme code is 3 alphanumeric characters. Both the identification and the coding scheme are mandatory Capacity Time Series, Identification Definition of element Sender s identification of the time series instance that uniquely identifies the Capacity time series within the document being sent. A unique identification of the time series assigned by the sender. The maximum size of a time series identification is 35 alphanumeric characters. This information is mandatory Capacity Time Series, Business Type Definition of element Identifies the nature of the time series. The nature of the time series for which the product is handled. Codes that may be used in this document: A31: Offered Capacity A25: General capacity information A26: Available Transfer Capacity (ATC) A27: Net Transfer Capacity (NTC) A29: Already Allocated Capacity (AAC) A41: Released AAC Z21: Total Transfer Capacity (TTC) Refer to ENTSO-E Code list document for the valid list of codes. The maximum length of this information is 3 alphanumeric characters. This information is mandatory. Page: 20

21 Capacity Time Series, Product Definition of element Identification of an energy product such as Power, energy, reactive power, transport capacity, etc. This identifies the product for which the time series is reporting. There is a different time series for each product. Refer to ENTSO-E Code list document for the valid list ofcodes. The maximum length of this information is 13 numeric characters. This information is mandatory Capacity Time Series, In Area Definition of element The area where the energy is to be put. The identification of the area where the energy is destined. The codification scheme used for the coded identification is indicated by the coding scheme attribute. It is a 3 character alphanumeric code. Refer to ENTSO-E Code list document for the valid list ofcodes. The maximum length of the area code is 18 alphanumeric characters. The maximum length of the coding scheme code is 3 alphanumeric characters. Both the identification and the coding scheme are mandatory Capacity Time Series, Out Area Definition of element The area where the energy is coming from. The identification of the area where the energy is coming from. The codification scheme used for the coded identification is indicated by the coding scheme attribute. It is a 3 character alphanumeric code. Refer to ENTSO-E Code list document for the valid list ofcodes. The maximum length of the area code is 18 alphanumeric characters. The maximum length of the coding scheme code is 3 alphanumeric characters. Both the identification and the coding scheme are mandatory. Page: 21

22 Capacity Time Series, Measure Unit Definition of element The unit of measure that is applied to the quantities in which the time series is expressed. The unit if measurement used for the quantities expressed within the time series. Refer to ENTSO-E Code list document for the valid list of codes. The maximum length of this information is 3 alphanumeric characters. This information is mandatory Capacity Time Series, Auction Identification Definition of element The identification of a set of specifications created by the auction operator. A unique identification of the set of specifications that clearly identify the auction to which the capacity is addressed. The maximum size of auction identification is 35 alphanumeric characters. This information is dependent. Local market rules may require this identification Capacity Time Series, Corridor Definition of element The identification of corridors between two areas. Used to separate different corridors between two areas, i.e. to separate different power lines between two Market balance areas. The maximum size of a Corridor is 50 alphanumeric characters. This information is dependent. Local market rules may require this identification Rules governing the Time Series Period class There may be several period classes for a time series. The overall time interval covered by the period shall be within the complete capacity time interval. The sum of the periods shall form the union of the complete capacity time interval. The number of periods within a time series as characterized by the resolution must completely cover the period s time interval. A senders minimal resolution must respect market rules. Page: 22

23 Time Series Period, Start Definition of element The start date and time of the time interval of the period in question. The time of the start of the period is expressed in UTC with the following format: YYYY-MM-DDTHH:MM:SSZ. This information provides the start date and time of the period being reported. The start date and time must be expressed in compliance with the following format: YYYY-MM-DDTHH:MM:SSZ This information is mandatory Time Series Period, End Definition of element The end date and time of the time interval of the period in question. The time of the end of the period is expressed in UTC with the following format: YYYY-MM-DDTHH:MM:SSZ. This information provides the end date and time of the period being reported. The end date and time must be expressed in compliance with the following format: YYYY-MM-DDTHH:MM:SSZ This information is mandatory Time Series Period, Resolution Definition of element The resolution defining the number of periods that the time interval is divided. This information defines the resolution of a single period. The time interval must contain a whole number of periods as expressed by the resolution. The resolution is expressed in compliance with ISO 8601 in the following format: PnYnMnDTnHnMnS. Where ny expresses a number of years, nm a number of months, nd a number of days. The letter T separates the date expression from the time expression and after it nh identifies a number of hours, nm a number of minutes and ns a number of seconds. For example PT15M expresses a 15 minute resolution. This information is mandatory. Page: 23

24 Rules governing the Quantity Observation class The interval class contains the relative position within a time interval period, the quantities associated with that position. The position must begin with 1 and increment by 1 for each subsequent position forming a series of contiguous numbers covering the complete range of the period. Any leading zeros in a position shall be suppressed. Normally negative values are not allowed in time series quantities. There is however an exception when there has to be a certain energy flow in one direction and no flow in opposite direction. Leading zeros in a quantity shall be suppressed before transmission Quantity Observation, Position Definition of element The relative position of a period within an interval. This information provides the relative position of a period within an interval. The relative position must be expressed as a numeric integer value beginning with 1. All leading zeros must be suppressed. The maximum number of characters is 6. This information is mandatory Quantity Observation, Quantity Definition of element The quantity that represents the capacity for the interval in question. This information defines the quantity that represents the capacity for the interval in question and that is expressed in the Measurement Unit. A decimal point value may be used to express values that are inferior to the defined unit of measurement. The decimal mark that separates the digits forming the integral part of a number from those forming the fractional part. (ISO 6093) shall always be a period (. ). Quantities are normally non-signed values, but might as an exception have a minus if there has to be a certain energy flow in one direction and no flow in opposite direction. The maximum length of this information is 17 numeric characters (decimal mark included). The number of decimal places identifying the fractional part of the quantity depends on local market rules. This information is mandatory. Page: 24

25 Rules governing the Reason class The Reason class may provide any coded or textual information that is necessary to completely describe the conditions of the capacity that is defined. In general the Reason class is only used to identify a period where a curtailment has been carried out Reason Status, Reason (Code) Definition of element A code providing the status of the capacity. Currently the following status has been identified: X06: Capacity reduction reason (NOIS code) The reason code provides the status of the capacity identified. As many reason elements as necessary may be used. The maximum length of this information is 3 alphanumeric characters. This information is dependent. This information is at the interval level to provide related explanatory information Reason Status, Reason (Text) Definition of element Additional textual information providing an additional explanation of the reason code. For exchange to NOIS two 2-digits codes shall be combined in a four-digit code used together with Reason code X06, see Appendix C If the code does not provide all the information to clearly identify the justification of the allocation then the textual information may be provided. The maximum length of this information is 512 alphanumeric characters. This information is dependent. Used only if the reason code is insufficient to identify an error. Shall always be used together with Reason code X06. Page: 25

26 4 BUSINESS RULES 4.1 Transfer capacity document in the Nordic countries The following business rules apply to the Transfer capacity document in the Nordic countries: For the Elspot market the Transfer capacity document is sent to NOIS before 09:00 the day before operation and should be published on the Nord Pool Spot web site within an hour. The message contains values for the whole coming day (24 hours). For the Elbas market the Transfer capacity document is sent latest 45 minutes before the operational hour, but always containing data for a whole day. The volume in the Transfer capacity document is always representing power (MW, without decimals). The Transfer capacities are always between Elspot areas. The Transfer capacity document will always contain two or more time series, i.e. there shall always be separate time series for each direction. The Direction is explicitly given by the In area and Out area. Positive values are used when the direction is from the Out area to the In area. Rules taken from the NOIS documentation: The Sender Identification must be the identification of a known TSO. The Domain must be a known TSO responsibility area (National Area from [3]) managed by the sending TSO. The Domain must cover either the in or the out Elspot area of each capacity time series. The In- and the Out area of each capacity time series must identify a known Elspot- or Cut area. The Corridor identification must be the identification of a known Elspot- or Cut corridor. 4.2 Date and time All time expressions shall be in UTC (UTC+0) time. The day is always expressed in local time, i.e.: o A day is from 23:00 to 23:00 during winter time o A day is from 22:00 to 22:00 during summer time (daylight saving time) o When changing from winter time to summer time there are 23 hours in the time series (from 23:00 to 22:00) o When changing from summer time to winter time there are 25 hours in the time series (from 22:00 to 23:00) Page: 26

27 5 ACKNOWLEDGEMENT PROCESS 5.1 Business Partner View, Acknowledge business document In addition to the roles defined in the ebix, EFET and ENTSO-E Harmonised role model (see 3.1) the following partner types have been identified as relevant for the Business area Determine transfer capacity. Definitions: Sender: Receiver: A party sending a business document (originator). A party receiving a business document (receipient). 5.2 Business Entity View, Acknowledge business document In addition to the domains defined in the ebix, EFET and ENTSO-E Harmonised role model (see 3.1) the following business entities have been identified as relevant for the Business area Determine transfer capacity. Acknowledgement of receipt: Acknowledgement of processing: A message (business signal) rejecting the receipt of a business document with syntactical errors. This technical Acknowledgement of receipt may be either through an XML Acknowledgement document or through another form of communication. A message (business signal) confirming or rejecting the processing of a received business document. 5.3 Business area: Acknowledge business document The main part of this chapter is taken from the ENTSO-E ECAN IG. The acknowledgement process is specifying a generic technical and application acknowledgement document that can be used in all relevant processes. Figure 11: UseCase: Acknowledge business document A document is controlled within the system environment at two levels: 1. It is first controlled at system level to detect syntax errors (XML parsing errors, file processing errors, etc.). 2. It is then controlled at the application level to detect any semantic errors (invalid data, wrong process, etc.). Page: 27

28 If there is a problem encountered at the first level then an Acknowledgment of receipt, i.e. a technical acknowledgement, shall be sent to inform the originator of the problem, if possible. If errors are encountered at the second level or if the application can successfully process the information then an Acknowledgment of processing, i.e. an application acknowledgement, shall be sent to inform the originator of the situation. The Acknowledgement document fits into a general acknowledgement process as outlined in the figure below. Figure 12: Activity diagram: Acknowledge business document With the transmission of all electronic documents between the Nordic TSOs an Acknowledgment of processing is required. Each of the electronic documents received shall follow the procedure outlined in Figure 12. When a document is received it will be verified at the application level to ensure that there are no faults in it that could prevent its correct processing. A document that is valid after this verification shall necessitate the generation of an Acknowledgment of processing accepting in its entirety the document in question. A document that has an error in it shall necessitate the generation of Acknowledgment of receipt or an Acknowledgment of processing that completely rejects the document in question. This acknowledgment sequence is not described in the normal business processes, but it shall be considered an integral part of each transmission Acknowledgement of receipt An Acknowledgment of receipt occurs when an XML document is received that cannot be correctly processed for submission to the application. Such an error could occur for example whenever the XML parser cannot correctly parse the incoming document. Other instances could be the incapacity Page: 28

29 to correctly identify the sender of the document in relation to the process requested. In such a case an Acknowledgment of receipt can be sent to the document sender providing the information that the XML document in question cannot be correctly processed by the system Acknowledgement of processing In order to implement effective data exchange there are two specific types of Acknowledgment of processing that must be distinguished: a) Data transmission where the originator can be in the market participant type role and recipient can be in an operator type role (such as System Operator, Transmission Capacity Allocator, ). b) Data transmission where originators can be in an operator type role and recipient can be in market participant type role. c) Data transmission where both originator and recipient are in the operator type role. With transmission of type (a) and (c) as described above, the following procedure is to be applied upon reception to verify at the application level that there are no faults in it that could prevent its correct processing: 1) A document that is valid after this verification shall necessitate the generation of an Acknowledgment of processing accepting in its entirety the document in question. 2) A document that has an error in it shall necessitate the generation of an Acknowledgment of processing that can completely reject the document in question. This acknowledgment sequence is not described in the normal business processes, but it shall be considered an integral part of each transmission. With transmission of type (b) as described above, all electronic documents sent by entities in the role of an operator shall be considered as received and correct and the acknowledgement process is not required unless an Acknowledgement document is required by a specific process. Page: 29

30 5.4 Business Entity View, Acknowledge business document In this chapter the details of the Acknowledgement message is defined. Figure 13: Class diagram: Acknowledgement message An Acknowledgement message, either Acknowledgement of receipt or Acknowledgement of processing, is sent to the party to acknowledge reception of the document identified in the acknowledgement. For example an Acknowledgement of processing may be sent to confirm reception of a schedule document immediately after a first level series of validations have been carried out. If an electronic document cannot be successfully processed an Acknowledgement of receipt shall be transmitted to inform the originator that the document in question cannot be processed and consequently cannot be sent to the application for processing. This technical Acknowledgement of receipt may be either through an XML Acknowledgement document or through another form of communication. The originator of the acknowledgement document is the receiver of the document being acknowledged. The receiver of the acknowledgment document is the sender of the document being acknowledged. Generally speaking, the document being acknowledged will have been validated in situ to ensure that it may be correctly processed by the application. The validation can also be carried out against a previous version of the same document (in order to identify an incomplete time series set for example). The Acknowledgement document transmission to the party concerned should not be delayed. Page: 30

31 5.5 Rules governing the Acknowledgement document Acknowledgement Document, Identification Definition of element Unique identification of the acknowledgement of a document that has been received. An acknowledgement document is sent in reply to the receipt of a document. This identification is assigned by the party who is acknowledging the application reception of a document. An acknowledgement is sent for the receipt of every document in the information flow as requiring an acknowledgement. The acknowledgement identification may not exceed 35 alphanumeric characters. This information is mandatory Acknowledgement Document, Creation Definition of element Date and time of transmission of the acknowledgement. The time must be expressed in UTC as YYYY-MM-DDTHH:MM:SSZ. The date and time that the document was prepared for transmission by the sender. The date and time must be expressed in UTC as: YYYY-MM-DDTHH:MM:SSZ This information is mandatory Acknowledgement Document, Process Type Definition of element The nature of the process that the referenced document is directed at. The process type identifies the process to which the information flow is directed. Codes that may be used in this document: A07: Capacity allocation A15: Capacity determination Refer to ENTSO-E Code list document for valid codes. The process type value must be exactly 3 alphanumeric characters (no blanks). This information is dependent. Should be present if available. Page: 31

32 5.5.4 Header Party, Sender, Identification Definition of element Identification of the party that is the originator of the acknowledgement. The originator of the acknowledgement is identified by a unique coded identification. This value should be the same as that found in the receiver identification of the document being acknowledged. The codification scheme used for the coded identification is indicated by the coding scheme attribute. It is a 3 character alphanumeric code. Refer to ENTSO-E Code list document for valid coding scheme codes. The maximum length of a sender s identification is 16 alphanumeric characters. The maximum length of the coding scheme code is 3 alphanumeric characters. This information is mandatory Header Party, Sender, Role Definition of element Identification of the role played by the originator of the document. The sender role, which identifies the role of the originator within the document. The maximum length of a sender role is 3 alphanumeric Characters. This information is mandatory Header Party, Receiver, Identification Definition of element Identification of the party who is the recipient of the acknowledgement. The recipient of the document is identified by a unique coded identification. This should be the same value as the sender of the schedule document. The codification scheme used for the coded identification is indicated by the coding scheme attribute. It is a 3 character alphanumeric code. Refer to ENTSO-E Code list document for valid coding scheme codes. The maximum length of a sender s identification is 16 alphanumeric characters. The maximum length of the coding scheme code is 3 alphanumeric characters. This information is mandatory. Page: 32

33 5.5.7 Header Party, Receiver, Role Definition of element Identification of the role played by the receiver of the document. The sender role, which identifies the role of the originator within the document. The maximum length of a sender role is 3 alphanumeric Characters. This information is dependent. If a document cannot be successfully parsed on entry then the role of the sender may be unknown (e.g. document incorrect vis-a-vis the schema or document file cannot be processed.) Reference Document, Identification Definition of element Unique identification of the document that has been received. This information identifies the document that has been received by the receiving party. The identification is extracted from the received document. Receiving document code identification may not exceed 35 alphanumeric characters. This information is dependent. If the document cannot be successfully processed this information may not be available Reference Document, Version Definition of element Version of the document being referenced. A document may be sent several times, each transmission being identified by a different version number that starts at 1 and increases sequentially. This information identifies the document that has been received by the receiving party. The identification is extracted from the received document. Version number may not exceed 3 numeric characters. This information is dependent. The document version must be provided for all documents being acknowledged that have a document version attribute Reference Document, Type Definition of element The coded type of the document being referenced. The document type is used to identify the type of document being acknowledged. A document type may not exceed 3 alpha-numeric characters. This information is dependent. The document type is mandatory in contexts where there is potential ambiguity about the document being acknowledged. Page: 33

34 Rules governing the Reason Status class If the acknowledgement of a document is without error only one reason element is necessary at the acknowledgement header level. However, if there are errors then there may be as many reason elements as are necessary to describe any errors discovered in the received document. At least one reason element must appear associated with the header part of the document. Acknowledgement documents are always sent on document level in the Nordic countries. If there are errors as many reason elements as necessary may be sent Reason Status, Reason (Code) Definition of element A code providing the acknowledgement status. Currently the following status s have been identified: A01: Message fully accepted A02: Message fully rejected A03: Message contains errors at the time series level A04: Schedule time interval incorrect A51: Message identification or version conflict A52: Time series missing from new version of message A53: Receiving party incorrect A94. Document cannot be processed by receiving system A20: Time series fully rejected A41: Resolution inconsistency A50: Senders time series version conflict A55: Time series identification conflict A56: Corresponding time series not netted A57: Deadline limit exceeded A59: Not compliant with local market rules Other codes may be found in the dedicated Implementation Guides. The reason code provides the status of the acknowledgement. If the receiving document is fully accepted then there is simply a reason code (A01) in the acknowledgement. For errors as many reason elements as necessary may be used. The maximum length of this information is 3 alphanumeric characters. This information is mandatory after the Acknowledgement level and Time Interval Error level. It is dependent at Time Series Rejection level. This information is mandatory after the acknowledgement and the Time Interval Error elements. It is not necessary at the Time Series Rejection level if and only if Time Interval Error elements are identified. Page: 34

35 Reason Status, Reason (Text) Definition of element Textual description of a rejection. If the code does not provide all the information to clearly identify an error the reason text may be used. The maximum length of this information is 512 alphanumeric characters. This information is dependent. Used only if the reason code is insufficient to identify an error. Page: 35

36 Appendix A COMMUNICATION The Nordic TSO will base the communication on SOAP 1.2, extended to be compatible with ECP (Energy Communication Platform), [2]. This includes usage of SOAP with extensions from ebms and ECP, as follows: Figure 14: Class diagram: ECP (Energy Communication Platform) The SOAP version 1.2 header is extended with the following elements from ebms version 3.0: to from messageid timestamp And with the following ECP extensions: ultimate receiver process security data priority payload encryption time to live Page: 36

37 Appendix B AN EXAMPLE OF TECHNICAL IMPLEMENTATION B.1 Transfer capacity messages exchange to/from NOIS Message exchanges to/from NOIS are in this appendix presented as an example of where the transfer capacity message will be used in the Nordic countries. The Nordic TSOs Energinet.dk, Fingrid, Statnett and Svenska Kraftnät are sending day-ahead proposals for transmission capacity to NOIS related to different needs, i.e. Transmission Capacity Proposals for the Elspot market (for ELSPOT corridors), Elbas Capacity, Cut Corridor Capacity, Out of Nordel Transmission Capacity and Capacity Reduction Reasons for ELSPOT corridors. NOIS validates the received transfer capacities and distribute validated ELSPOT and Elbas trading capacities to the TSOs and NordPool Spot. The validated ELSPOT trading capacities are always on day-ahead basis, while the validated Elbas trading capacities may be on both day-ahead and intra-day basis. In addition the Capacity Reduction Reasons are sent to NordPool Spot from NOIS on operator request. The transfer capacity document is based on the ENTSO-E ECAN capacity document, but extended with the corridor identification information, since more than one corridor can be defined between two areas in the NOIS data model. In the Sequence diagram shown below, Svenska Kraftnät (SvK) is used as example of a Nordic TSO. The same message exchange scenario is however valid also for the other Nordic TSOs Energinet.dk, Fingrid and Statnett. Page: 37

38 B.2 Sequence of transfer capacity messages sent to/from NOIS Figure 15: Sequence diagram: NOIS, Transfer Capacity exchanges Page: 38

39 B.3 Business rules for transfer capacity messages sent to/from NOIS B.3.1 B.3.2 B.3.3 B.3.4 B.3.5 B.3.6 B.3.7 Transmission Capacity Proposals Transmission Capacity Proposals are sent in day ahead by TSO s for ELSPOT corridors. The Transmission Capacity Proposals must cover a full day. The sender identification must be the identification of a known TSO. The domain area must be a known ELSPOT area managed by the sender TSO. The domain area must be equal to the in or the out ELSPOT area of each capacity time series. The in and the out area of each capacity time series must identify a known ELSPOT area. The corridor identification must be the identification of a known Elspot corridor. Elbas Capacity Elbas Capacity is sent in day ahead by TSO s. Elbas Capacity must cover a full day. The sender identification must be the identification of a known TSO. The domain area must be a known ELSPOT area managed by the sender TSO. The domain area must be equal to the in or the out area of each capacity time series. The in and the out area of each capacity time series must identify known Elspot areas Cut Corridor Capacity Cut Corridor Capacity documents are sent in day ahead by TSO s. The Cut Corridor Capacity must cover a full day. The sender identification must be the identification of a known TSO. The domain area must be a known control area managed by the sender TSO. The in and the out area of each capacity time series must identify known cut areas The corridor identification must be the identification of a known cut corridor. Out of Nordel Transmission Capacity Out of Nordel Transmission Capacity documents are sent in day ahead by TSO s. The Out of Nordel Transmission Capacity must cover a full day. The sender identification must be the identification of a known TSO. The domain area must be a known control area managed by the sender TSO. The domain area must be equal to the in or the out area of each capacity time series. The in and the out area of each capacity time series must identify a known control area. The corridor identification must be the identification of a known external corridor. Capacity Reduction Reasons Capacity Reduction Reasons are sent in intra-day to NOIS by TSO s for ELSPOT corridors. The Capacity Reduction Reasons must cover a full day. The sender identification must be the identification of a known TSO. The domain area must be a known ELSPOT area managed by the sender TSO. The domain area must be equal to the in or the out ELSPOT area of each capacity time series. The in and the out area of each capacity time series must identify a known ELSPOT area. The quantity values will be ignored by NOIS: as per TSO request, NOIS will use the latest physical capacity proposal that has been submitted by the TSO ( This value is stored in NOIS db. ) Validated ELSPOT trading capacity to TSO (Output from NOIS) Validated trading capacity is sent to TSO s in day ahead. The Validated trading capacity must cover a full day. domain area is a known control area of the TSO Validated Elspot trading capacity to NordPool (Output from NOIS) Validated Elspot trading capacity is sent to NordPool in day ahead. The Validated trading capacity must cover a full day. Page: 39

40 B.3.8 B.3.9 Domain will be set as Nordel Elbas trading capacity to NordPool (Output from NOIS) Elbas trading capacity is sent to NordPool in day ahead or in intraday. The trading capacity must cover a full day. Domain will be set as Nordel Elbas trading capacity to TSO (Output from NOIS) Elbas trading capacity is sent to TSO s in day ahead or in intraday when it is required by TSO. The Validated trading capacity must cover a full day. Domain area is a known control area of the TSO B.3.10 Capacity Reduction Reasons NOIS export Capacity Reduction Reasons are sent to NORDPOOL from NOIS on operator request. The Capacity Reduction Reasons must cover a full day. The sender identification is NOIS identification The domain area is left empty The in and the out area of each capacity time series must identify a known ELSPOT area. Page: 40

41 Appendix C NOIS REASON TEXT CODES NOIS Reason text codes, first 2 digits NOIS Reason text codes, last 2 digits 10 Normal capacity (100 MW tolerance) 10 No bottleneck causing reduction 11 Planned outage on cross-border connection 11 The Skagerrak interconnection (NO1-DK1) 12 Network failure on cross-border connection 12 Sørlandssnittet (southern part of Norway, internal NO1) 13 Thermal limitation on cross-border 13 Flesakersnittet + Hallingdalssnittet (West/North of the connection Oslo area, internal NO1) 14 Internal congestion due to planned outage 14 Haslesnittet (NO1-SE) 15 Internal congestion due to network failure 15 The cut between middle part of Norway and SE (NO2-SE) 16 Internal congestion due to stability 16 The cut between northern part of Norway and Sweden (NO3- SE) 17 Internal congestion due to regional power 17 The cut between southern and middle part of Norway (NO1 balance and NO2) 18 Increased reliability margin 18 The cut between middle and northern part of Norway (NO2 and NO3) 19 Unavailable system protection 19 The interconnections between Finland and Sweden (FI-SE) 20 Reduced amount of operational reserves 20 Cut P1 in Finland (internal FI) 21 Constrained regional power balance 21 Cut 1 in Sweden (internal SE) 22 Step by step restriction 22 Cut 2 in Sweden (internal SE) 90 Not available 23 Cut 4 in Sweden (internal SE) 99 Other reasons 24 The West coast corridor in Sweden (internal SE) 25 The Kontiskan interconnection (SE-DK1) 26 The Øresund interconnection (SE-DK2) 27 The Kontek interconnection (DK2-KT) 28 Cut B in Jutland (internal DK1) 90 Not available 99 Other connections Page: 41

42 Appendix D DICTIONARY AAC: Already Allocated Capacity is the total amount of allocated transmission rights, whether they are capacity or exchange programmes depending on the allocation method. Allocated capacity market: A market area where the transmission capacity between the balance areas is given to the Balance Responsible Parties according to rules carried out by a Transmission Capacity Allocator. Trade between balance areas is carried out on a bilateral or unilateral basis. ATC: Available Transmission Capacity is the part of NTC that remains available, after each phase of the allocation procedure, for further commercial activity. ATC is given by the following equation: ATC = NTC-AAC. The ATC is exchanged between System operators and between System operators and the Transmission capacity allocator. The ATC for a certain market cannot be changed after the closure of the relevant market. The ATC may be negative. Explicit auctioning: Signifies that what is auctioned is the transmission capacity rights to transfer energy. Allocation type Implicit Auction Explicit Auction Flow based ENTSO-E Europex flow based market coupling Not yet implemented ATC based Market coupling, ECAN V1 e.g. Belpex All bilateral auctions, e.g. Market splitting, Energinet.dk - E.ON. e.g. Nord Pool Coordinated auctions, e.g. CEPS, VE-T, PSE-O, E.ON, SEPS E.G. TSO Auction B.V. Implicit auctioning: Market balance area: NTC: TTC: OC: Offered Capacity: Signifies that what is auctioned is both the energy itself and transmission capacity rights together. Refer to ebix, EFET and ENTSO-E Harmonised Electricity Role Model definition. Net Transfer Capacity is defined as NTC = TTC TRM and corresponds to the maximum exchange between two areas compatible with security standards applicable in both areas and taking into account the technical uncertainties on future network conditions. The Total Transfer Capacity is the maximum exchange program between two areas compatible with operational security standards applicable at each system if future network conditions, generation and load patterns were perfectly known in advance. Operational capacity is exchanged between System operators. The OC is the available transfer capacity as established during the operational day, i.e. the capacity available after closure of the Elbas market. The OC is used for system operation and not for market purposes. The OC may be both higher and lower than the ATC. The OC may be negative. Is a part of or equivalent to the ATC that will be offered by the Transmission Capacity Allocator to the market. Depending on Market Rules, the calculation of the Offered Capacity may include the consideration of firm exchange programs in Page: 42

43 one direction, to increase the Offered Capacity in the other direction. This is generally known as Netting aimed at maximising Offered Capacity. Prognosis: Schedule: System Operator: Transfer capacity: A prognosis is a plan that is not binding for the sender and is not used directly in a settlement and/or operational process, see also Schedule below. A Schedule is a plan that is binding and used directly in settlement and/or operational processes, see also Prognosis above. Refer to ebix, EFET and ENTSO-E Harmonised Electricity Role Model definition. Capacity exchanged between System operators and between System operators and the Transmission capacity allocator. The Transfer capacity can be split into Operational capacity (OC) and Available Transfer Capacity (ATC). Transmission Capacity Allocator: Manages, on behalf of the System Operators, the allocation of available transmission capacity for an Allocated capacity area. He offers the available transmission capacity to the market, allocates the available transmission capacity to individual Capacity Traders and calculates the billing amount of already allocated capacities to the Capacity Traders. TRM: TTC: Transmission Reliability Margin is a security margin that copes with uncertainties on the computed TTC values arising from: a) Unintended deviations of physical flows during operation due to the physical functioning of load-frequency regulation b) Emergency exchanges between SOs to cope with unexpected unbalanced situations in real time c) Inaccuracies, e.g. in data collection and measurements. Total Transfer Capacity is the maximum exchange program between two areas compatible with operational security standards applicable at each system if future network conditions, generation and load patterns were perfectly known in advance. Figure 16: Transfer capacity definitions The figure above describes a simplified calculation of the TTC. In addition there might be other elements, such as FDR (Frequency controlled Disturbance Reserve). Page: 43

44 Appendix E COMPARISON BETWEEN ENTSO-E AND NORDIC TSO XML FORMAT E.1 Transfer capacity document This chapter shows the differences between the ENTSO-E and Nordic TSO Transfer capacity document. Figure 17: Class diagram: ENTSO-E Transfer capacity document Nordic TSO ENTSO-E Data element Type Data element Type Header: Header Document Capacity Document Identification Identifier Document Identification Type Identification Type Message Type Document Type Message Type Code Creation Date Time Creation Date Time Message Date Time Type Process Type Code Process Type Process Type Version [0..1] Numeric Document Version Version Type Page: 44

45 Transfer Capacity Notification Document Start Date Time Document End Date Time Capacity Time Interval Time Interval Type Domain Proprietary Information Type Identifier Domain Area Type [0..1] Sender: Header Party Identification Identifier Sender Identification Party Type Role Role Code Sender Role Role Type Receiver: Header Party Identification Identifier Receiver Identification Party Type Role Role Code Receiver Role Role Type Capacity Time Series [0..*] Capacity Time Series [0..*] Identification Identifier Time Series Identification Type Identification Business Type Business Type Business Type Business Type Code Product Energy Product Product Energy Product Type Code In Area Identifier In Area Area Type Out Area Identifier Out Area Area Type Measure Unit Unit Of Measure Measure Unit Unit Of Measure Type Code Auction Identification [0..1] Identifier Auction Identification Identification Type Type Corridor [0..1] Identifier Interval: Time Series Period [1..*] Period [1..*] Start Date Time End Date Time Time Interval Time Interval Type Resolution Measure Resolution Resolution Type Time Series: Quantity Observation [1..*] Interval [1..*] Quantity Quantity Qty Quantity Type Position Numeric Pos Position Type Status: Reason Status [0..*] Reason [0..*] Reason Reason Code Reason Code Reason Code Type Reason1 [0..1] Text Reason Text Reason Text Type The following differences have been identified: The Nordic TSOs are using UN/CEFACT data types, while ENTSO-E uses their own. The Nordic TSOs has taken the Sender and Receiver out of the Header Document (Capacity Document) class to be able to use the UN/CEFACT ACCs Document and Party. The Domain and Version elements in the Header Document (Capacity Document) are optional between the Nordic TSOs and mandatory within ENTSO-E. The Auction Identification element in the Capacity Time Series class is optional between the Nordic TSOs and mandatory within ENTSO-E. Auction Identification is not used in the Nordic countries. The Corridor element in the Capacity Time Series class is an extension used between the Nordic TSOs. The ENTSO-E elements Capacity Time Interval and Time Interval in the classes Capacity Document and Period are split into Start and End elements between the Nordic TSOs, to be in line with UN/CEFACT rules. Page: 45

46 E.2 Acknowledgement document This chapter shows the differences between the ENTSO-E and the Nordic TSO Acknowledgement document. Figure 18: Class diagram: ENTSO-E Acknowledgement document Nordic TSO ENTSO-E Data element Type Data element Type Acknowledgement Document Acknowledgement Document Identification Identifier Document Identification Type Identification Creation Date Time Document Date Time Message Date Time Type Process Type [0..1] Code Sender: Header Party Identification Identifier Sender Identification Party Type Role Role Code Sender Role Role Type Receiver: Header Party Identification Identifier Receiver Identification Party Type Role [0..1] Role Code Receiver Role [0..1] Role Type Reference Document Identification [0..1] Identifier Receiving Document Identification Type Identification [0..1] Version [0..1] Numeric Receiving Document Version [0..1] Version Type Page: 46