Get documents about "Business Requirement Specification Introduction Letter - DOC
Description
Business Requirement Specification Introduction Letter document sample
Document Sample
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.A
Status: Show case for UN/CEFACT
based message exchange
Not for implementation
Date: November 27th, 2009
Nordic TSO message exchange model
CONTENT
1 INTRODUCTION.................................................................................................................................................... 4
1.1 BACKGROUND .................................................................................................................................................... 4
1.2 ABOUT THIS DOCUMENT .................................................................................................................................... 4
1.3 TRANSFER CAPACITY ALLOCATION OVERVIEW .................................................................................................. 4
1.4 PROJECT ORGANISATION .................................................................................................................................... 6
1.5 REFERENCES ...................................................................................................................................................... 7
1.6 CHANGE LOG ..................................................................................................................................................... 7
2 OVERVIEW OF BUSINESS AREAS IN THE NORDIC ENERGY MARKET ............................................... 8
3 DETERMINE TRANSFER CAPACITY............................................................................................................... 9
3.1 EBIX, EFET AND ENTSO-E HARMONISED ROLES USED IN “DETERMINE TRANSFER CAPACITY”....................... 9
3.2 BUSINESS PARTNER VIEW, DETERMINE TRANSFER CAPACITY ......................................................................... 10
3.3 BUSINESS ENTITY VIEW, DETERMINE TRANSFER CAPACITY ............................................................................ 10
3.4 BUSINESS AREA: DETERMINE TRANSFER CAPACITY ........................................................................................ 11
3.5 PROCESS AREA: PROPOSE TRANSFER CAPACITY ............................................................................................... 12
3.6 PROCESS AREA: NOTIFY TRANSFER CAPACITY ................................................................................................. 13
3.7 BUSINESS ENTITY VIEW, TRANSFER CAPACITY MESSAGE ................................................................................ 15
3.8 RULES GOVERNING THE TRANSFER CAPACITY MESSAGE ................................................................................ 16
3.8.1 Header Document, Identification ................................................................................................................ 16
3.8.2 Header Document, Type ............................................................................................................................. 16
3.8.3 Header Document, Creation ....................................................................................................................... 16
3.8.4 Header Document, Process Type ................................................................................................................ 17
3.8.5 Header Document, Version ......................................................................................................................... 17
3.8.6 Header Party, Sender, Identification .......................................................................................................... 18
3.8.7 Header Party, Sender, Role ........................................................................................................................ 18
3.8.8 Header Party, Receiver, Identification ....................................................................................................... 18
3.8.9 Header Party, Receiver, Role ..................................................................................................................... 19
3.8.10 Transfer Capacity Notification, Start ..................................................................................................... 19
3.8.11 Transfer Capacity Notification, End....................................................................................................... 19
3.8.12 Transfer Capacity Notification, Domain Proprietary Information Type ................................................ 20
3.8.13 Capacity Time Series, Identification....................................................................................................... 20
3.8.14 Capacity Time Series, Business Type ..................................................................................................... 20
3.8.15 Capacity Time Series, Product ............................................................................................................... 21
3.8.16 Capacity Time Series, In Area ................................................................................................................ 21
3.8.17 Capacity Time Series, Out Area ............................................................................................................. 21
3.8.18 Capacity Time Series, Measure Unit ...................................................................................................... 22
3.8.19 Capacity Time Series, Auction Identification ......................................................................................... 22
3.8.20 Capacity Time Series, Corridor .............................................................................................................. 22
3.8.21 Rules governing the Time Series Period class ........................................................................................ 22
3.8.22 Time Series Period, Start ........................................................................................................................ 23
3.8.23 Time Series Period, End ......................................................................................................................... 23
3.8.24 Time Series Period, Resolution .............................................................................................................. 23
3.8.25 Rules governing the Quantity Observation class .................................................................................... 24
3.8.26 Quantity Observation, Position .............................................................................................................. 24
3.8.27 Quantity Observation, Quantity ............................................................................................................. 24
3.8.28 Rules governing the Reason class .......................................................................................................... 25
3.8.29 Reason Status, Reason (Code) ................................................................................................................ 25
3.8.30 Reason Status, Reason (Text) ................................................................................................................. 25
4 BUSINESS RULES ................................................................................................................................................ 26
4.1 TRANSFER CAPACITY DOCUMENT IN THE NORDIC COUNTRIES ......................................................................... 26
4.2 DATE AND TIME ............................................................................................................................................... 26
5 ACKNOWLEDGEMENT PROCESS.................................................................................................................. 27
5.1 BUSINESS PARTNER VIEW, ACKNOWLEDGE BUSINESS DOCUMENT .................................................................. 27
5.2 BUSINESS ENTITY VIEW, ACKNOWLEDGE BUSINESS DOCUMENT ..................................................................... 27
5.3 BUSINESS AREA: ACKNOWLEDGE BUSINESS DOCUMENT .................................................................................. 27
5.3.1 Acknowledgement of receipt ....................................................................................................................... 28
5.3.2 Acknowledgement of processing ................................................................................................................. 29
Page: 2
Nordic TSO message exchange model
5.4 BUSINESS ENTITY VIEW, ACKNOWLEDGE BUSINESS DOCUMENT ..................................................................... 30
5.5 RULES GOVERNING THE ACKNOWLEDGEMENT DOCUMENT.............................................................................. 31
5.5.1 Acknowledgement Document, Identification ............................................................................................... 31
5.5.2 Acknowledgement Document, Creation ...................................................................................................... 31
5.5.3 Acknowledgement Document, Process Type ............................................................................................... 31
5.5.4 Header Party, Sender, Identification .......................................................................................................... 32
5.5.5 Header Party, Sender, Role ........................................................................................................................ 32
5.5.6 Header Party, Receiver, Identification ....................................................................................................... 32
5.5.7 Header Party, Receiver, Role ..................................................................................................................... 33
5.5.8 Reference Document, Identification ............................................................................................................ 33
5.5.9 Reference Document, Version ..................................................................................................................... 33
5.5.10 Reference Document, Type ..................................................................................................................... 33
5.5.11 Rules governing the Reason Status class ................................................................................................ 34
5.5.12 Reason Status, Reason (Code) ................................................................................................................ 34
5.5.13 Reason Status, Reason (Text) ................................................................................................................. 35
APPENDIX A COMMUNICATION ....................................................................................................................... 36
APPENDIX B AN EXAMPLE OF TECHNICAL IMPLEMENTATION ......................................................... 37
B.1 TRANSFER CAPACITY MESSAGES EXCHANGE TO/FROM NOIS .......................................................................... 37
B.2 SEQUENCE OF TRANSFER CAPACITY MESSAGES SENT TO/FROM NOIS .............................................................. 38
B.3 BUSINESS RULES FOR TRANSFER CAPACITY MESSAGES SENT TO/FROM NOIS .................................................. 39
B.3.1 TRANSMISSION CAPACITY PROPOSALS ................................................................................................................ 39
B.3.2 ELBAS CAPACITY ............................................................................................................................................... 39
B.3.3 CUT CORRIDOR CAPACITY ................................................................................................................................. 39
B.3.4 OUT OF NORDEL TRANSMISSION CAPACITY ........................................................................................................ 39
B.3.5 CAPACITY REDUCTION REASONS........................................................................................................................ 39
B.3.6 VALIDATED ELSPOT TRADING CAPACITY TO TSO (OUTPUT FROM NOIS) .......................................................... 39
B.3.7 VALIDATED ELSPOT TRADING CAPACITY TO NORDPOOL (OUTPUT FROM NOIS) .................................................. 39
B.3.8 ELBAS TRADING CAPACITY TO NORDPOOL (OUTPUT FROM NOIS) ...................................................................... 40
B.3.9 ELBAS TRADING CAPACITY TO TSO (OUTPUT FROM NOIS) ................................................................................. 40
B.3.10 CAPACITY REDUCTION REASONS – NOIS EXPORT .......................................................................................... 40
APPENDIX C NOIS REASON TEXT CODES ...................................................................................................... 41
APPENDIX D DICTIONARY ................................................................................................................................. 42
APPENDIX E COMPARISON BETWEEN ENTSO-E AND NORDIC TSO XML FORMAT ........................ 44
E.1 TRANSFER CAPACITY DOCUMENT .................................................................................................................... 44
E.2 ACKNOWLEDGEMENT DOCUMENT.................................................................................................................... 46
Page: 3
Nordic TSO message exchange model
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
Nordic TSO message exchange model
Total Transfer Capacity (TTC) 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.
Transmission Reliability Margin (TRM) 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 load-
frequency 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
Nordic TSO message exchange model
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
Nordic TSO message exchange model
Convenor: Jon-Egil Nordvik, Statnett, jon-egil.nordvik@statnett.no
Secretary: Ove Nesvik, EdiSys, ove.nesvik@edisys.no
Project members: Antti Niemi, Nord Pool Spot, an@npspot.com
Christian Hoang Huy Le, Statnett, christian.le@statnett.no
Christian Odgaard, Energinet.dk, cco@energinet.dk
Heli Anttila, Fingrid, Heli.Anttila@fingrid.fi
Jan Owe, SvK, Jan.Owe@svk.se
Jari Hirvonen, Fingrid, Jari.Hirvonen@Fingrid.fi
Jon-Egil Nordvik, Statnett, jon-egil.nordvik@statnett.no
Ove Nesvik, EdiSys, ove.nesvik@edisys.no
Roar Grindstrand , Statnett, roar.grindstrand@statnett.no
1.5 References
[1] ENTSO-E implementation guides, see http://entsoe.eu/index.php?id=73
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 http://entsoe.eu/index.php?id=73
[4] UN/CEFACT Unified Modelling Methodology (UMM), see http://umm-dev.org/
[5] UML Profile for Core Components (UPCC), see http://www.untmg.org/
[6] UN/CEFACT XML Naming and Design Rules (NDR), see
http://www.uncefactforum.org/ATG/ATG_Home.htm
[7] ebIX Modelling methodology and process models (EMD), see http://www.ebix.org/
[8] Ediel Implementation guides, see http://www.ediel.org/
[9] Principles for determining the transfer capacity in the Nordic power market
http://195.18.187.215/docs/2/LOILGJJBDBKOGFGGPDANMMFOPDBW9DBDGG9DW3571KM/Nor
del/docs/DLS/2008-00049-01-E.pdf
1.6 Change log
Ver/rel/rev Changed by Date Changes
1.1.A Ove Nesvik 20091127 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 1.2.
1.0.B Ove Nesvik 20090616 New SvK logo
1.0.A Ove Nesvik 20090529 First release
Page: 7
Nordic TSO message exchange model
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
Nordic TSO message exchange model
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
Nordic TSO message exchange model
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: Nord Pool Spot is a specialisation of the generic role Transmission
Capacity Allocator. Nord Pool Spot fixes the allocations through
implicit auctioning.
NOIS: 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: 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).
OC: 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
Nordic TSO message exchange model
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 Trans-
mission 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
Nordic TSO message exchange model
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
Nordic TSO message exchange model
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
Nordic TSO message exchange model
Figure 9: Activity diagram: Notify transfer capacity
Page: 14
Nordic TSO message exchange model
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
Nordic TSO message exchange model
3.8 Rules governing the Transfer Capacity Message
3.8.1 Header Document, Identification
Action Description
Definition of element Unique identification of the document for which the time series data
is being supplied.
Description 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.
Size The identification of a document may not exceed 35 alphanumeric
characters.
Applicability This information is mandatory.
Dependence requirements None.
3.8.2 Header Document, Type
Action Description
Definition of element The coded type of the document being sent.
Description 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.
Size The document type value must be exactly 3 alphanumeric characters (no
blanks).
Applicability This information is mandatory.
Dependence requirements None.
3.8.3 Header Document, Creation
Action Description
Definition of element Date and time of the creation of the document. The time must be
expressed in UTC as YYYY-MMDDTHH:MM:SSZ.
Description The date and time that the document was prepared for transmission by the
application of the sender.
Size The date and time must be expressed in UTC as
YYYY-MM-DDTHH:MM:SSZ.
Applicability This information is mandatory.
Dependence requirements None.
Page: 16
Nordic TSO message exchange model
3.8.4 Header Document, Process Type
Action Description
Definition of element The nature of the process that the document is directed at.
Description 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.
Size The process type value must be exactly 3 alphanumeric characters (no
blanks).
Applicability This information is mandatory.
Dependence requirements None.
3.8.5 Header Document, Version
Action Description
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.
Description 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.
Size A version number may not exceed 3 numeric characters.
Applicability This information is dependent.
Dependence requirements Dependent on local market rules and will not necessarily be checked by
the receivers.
Page: 17
Nordic TSO message exchange model
3.8.6 Header Party, Sender, Identification
Action Description
Definition of element Identification of the party that is the owner of the document and is
responsible for its content.
Description 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.
Size The maximum length of a sender’s identification is 16 alphanumeric
characters.
The maximum length of the coding scheme code is 3 alphanumeric
characters.
Applicability Both the identification and the coding scheme are mandatory.
Dependence requirements None.
3.8.7 Header Party, Sender, Role
Action Description
Definition of element Identification of the role that is played by the sender.
Description 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.
Size The maximum length of a sender role is 3 alphanumeric characters.
Applicability This information is mandatory.
Dependence requirements None.
3.8.8 Header Party, Receiver, Identification
Action Description
Definition of element Identification of the party who is receiving the document.
Description 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.
Size The maximum length of a sender’s identification is 16 alphanumeric
characters.
The maximum length of the coding scheme code is 3 alphanumeric
characters.
Applicability Both the identification and the coding scheme are mandatory.
Dependence requirements None.
Page: 18
Nordic TSO message exchange model
3.8.9 Header Party, Receiver, Role
Action Description
Definition of element Identification of the role that is played by the receiver.
Description 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.
Size The maximum length of a sender role is 3 alphanumeric characters.
Applicability This information is mandatory.
Dependence requirements None.
3.8.10 Transfer Capacity Notification, Start
Action Description
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.
Description This information provides the start date and time of the capacity period.
The receiver will discard any time intervals outside the capacity period.
Size The start and end date and time must be expressed as
YYYY-MM-DDTHH:MM:SSZ.
Applicability This information is mandatory.
Dependence requirements None.
3.8.11 Transfer Capacity Notification, End
Action Description
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.
Description This information provides the end date and time of the capacity period.
The receiver will discard any time intervals outside the capacity period.
Size The end date and time must be expressed as
YYYY-MM-DDTHH:MM:SSZ
Applicability This information is mandatory.
Dependence requirements None.
Page: 19
Nordic TSO message exchange model
3.8.12 Transfer Capacity Notification, Domain Proprietary Information Type
Action Description
Definition of element The domain covered within the Capacity Document.
Description 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.
Size The maximum length of this information is 16 alphanumeric characters.
The maximum length of the coding scheme code is 3 alphanumeric
characters.
Applicability Both the identification and the coding scheme are mandatory.
Dependence requirements None.
3.8.13 Capacity Time Series, Identification
Action Description
Definition of element Sender’s identification of the time series instance that uniquely identifies
the Capacity time series within the document being sent.
Description A unique identification of the time series assigned by the sender.
Size The maximum size of a time series identification is 35 alphanumeric
characters.
Applicability This information is mandatory.
Dependence requirements None.
3.8.14 Capacity Time Series, Business Type
Action Description
Definition of element Identifies the nature of the time series.
Description 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
T01: Total Transfer Capacity (TTC)
Refer to ENTSO-E Code list document for the valid list of codes.
Size The maximum length of this information is 3 alphanumeric characters.
Applicability This information is mandatory.
Dependence requirements None.
Page: 20
Nordic TSO message exchange model
3.8.15 Capacity Time Series, Product
Action Description
Definition of element Identification of an energy product such as Power, energy, reactive
power, transport capacity, etc.
Description 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.
Size The maximum length of this information is 13 numeric characters.
Applicability This information is mandatory.
Dependence requirements None.
3.8.16 Capacity Time Series, In Area
Action Description
Definition of element The area where the energy is to be put.
Description 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.
Size The maximum length of the area code is 18 alphanumeric characters.
The maximum length of the coding scheme code is 3 alphanumeric
characters.
Applicability Both the identification and the coding scheme are mandatory.
Dependence requirements None.
3.8.17 Capacity Time Series, Out Area
Action Description
Definition of element The area where the energy is coming from.
Description 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.
Size The maximum length of the area code is 18 alphanumeric characters.
The maximum length of the coding scheme code is 3 alphanumeric
characters.
Applicability Both the identification and the coding scheme are mandatory.
Dependence requirements None.
Page: 21
Nordic TSO message exchange model
3.8.18 Capacity Time Series, Measure Unit
Action Description
Definition of element The unit of measure that is applied to the quantities in which the time
series is expressed.
Description 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.
Size The maximum length of this information is 3 alphanumeric characters.
Applicability This information is mandatory.
Dependence requirements None.
3.8.19 Capacity Time Series, Auction Identification
Action Description
Definition of element The identification of a set of specifications created by the auction
operator.
Description A unique identification of the set of specifications that clearly identify the
auction to which the capacity is addressed.
Size The maximum size of auction identification is 35 alphanumeric characters.
Applicability This information is dependent.
Dependence requirements Local market rules may require this identification.
3.8.20 Capacity Time Series, Corridor
Action Description
Definition of element The identification of corridors between two areas.
Description Used to separate different corridors between two areas, i.e. to separate
different power lines between two Market balance areas.
Size The maximum size of a Corridor is 50 alphanumeric characters.
Applicability This information is dependent.
Dependence requirements Local market rules may require this identification.
3.8.21 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
Nordic TSO message exchange model
3.8.22 Time Series Period, Start
Action Description
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.
Description This information provides the start date and time of the period being
reported.
Size The start date and time must be expressed in compliance with the
following format:
YYYY-MM-DDTHH:MM:SSZ
Applicability This information is mandatory.
Dependence requirements None.
3.8.23 Time Series Period, End
Action Description
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.
Description This information provides the end date and time of the period being
reported.
Size The end date and time must be expressed in compliance with the
following format:
YYYY-MM-DDTHH:MM:SSZ
Applicability This information is mandatory.
Dependence requirements None.
3.8.24 Time Series Period, Resolution
Action Description
Definition of element The resolution defining the number of periods that the time interval is
divided.
Description This information defines the resolution of a single period.
The time interval must contain a whole number of periods as expressed by
the resolution.
Size 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.
Applicability This information is mandatory.
Dependence requirements None.
Page: 23
Nordic TSO message exchange model
3.8.25 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.
3.8.26 Quantity Observation, Position
Action Description
Definition of element The relative position of a period within an interval.
Description This information provides the relative position of a period within an
interval.
Size 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.
Applicability This information is mandatory.
Dependence requirements None.
3.8.27 Quantity Observation, Quantity
Action Description
Definition of element The quantity that represents the capacity for the interval in question.
Description 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.
Size 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.
Applicability This information is mandatory.
Dependence requirements None.
Page: 24
Nordic TSO message exchange model
3.8.28 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.
3.8.29 Reason Status, Reason (Code)
Action Description
Definition of element A code providing the status of the capacity. Currently the following status
has been identified:
X06: Capacity reduction reason (NOIS code)
Description The reason code provides the status of the capacity identified. As many
reason elements as necessary may be used.
Size The maximum length of this information is 3 alphanumeric characters.
Applicability This information is dependent.
Dependence requirements This information is at the interval level to provide related explanatory
information.
3.8.30 Reason Status, Reason (Text)
Action Description
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
Description If the code does not provide all the information to clearly identify the
justification of the allocation then the textual information may be
provided.
Size The maximum length of this information is 512 alphanumeric characters.
Applicability This information is dependent.
Dependence requirements Used only if the reason code is insufficient to identify an error.
Shall always be used together with Reason code X06.
Page: 25
Nordic TSO message exchange model
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
Nordic TSO message exchange model
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: A party sending a business document (originator).
Receiver: 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: 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.
Acknowledgement of processing: 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
Nordic TSO message exchange model
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.
5.3.1 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
Nordic TSO message exchange model
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.
5.3.2 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
Nordic TSO message exchange model
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
Nordic TSO message exchange model
5.5 Rules governing the Acknowledgement document
5.5.1 Acknowledgement Document, Identification
Action Description
Definition of element Unique identification of the acknowledgement of a document that has
been received.
Description 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.
Size The acknowledgement identification may not exceed 35 alphanumeric
characters.
Applicability This information is mandatory.
Dependence requirements None.
5.5.2 Acknowledgement Document, Creation
Action Description
Definition of element Date and time of transmission of the acknowledgement. The time must be
expressed in UTC as YYYY-MM-DDTHH:MM:SSZ.
Description The date and time that the document was prepared for transmission by the
sender.
Size The date and time must be expressed in UTC as:
YYYY-MM-DDTHH:MM:SSZ
Applicability This information is mandatory.
Dependence requirements None.
5.5.3 Acknowledgement Document, Process Type
Action Description
Definition of element The nature of the process that the referenced document is directed at.
Description 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.
Size The process type value must be exactly 3 alphanumeric characters (no
blanks).
Applicability This information is dependent. Should be present if available.
Dependence requirements None.
Page: 31
Nordic TSO message exchange model
5.5.4 Header Party, Sender, Identification
Action Description
Definition of element Identification of the party that is the originator of the acknowledgement.
Description 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.
Size The maximum length of a sender’s identification is 16 alphanumeric
characters.
The maximum length of the coding scheme code is 3 alphanumeric
characters.
Applicability This information is mandatory.
Dependence requirements None.
5.5.5 Header Party, Sender, Role
Action Description
Definition of element Identification of the role played by the originator of the document.
Description The sender role, which identifies the role of the originator within the
document.
Size The maximum length of a sender role is 3 alphanumeric
Characters.
Applicability This information is mandatory.
Dependence requirements None.
5.5.6 Header Party, Receiver, Identification
Action Description
Definition of element Identification of the party who is the recipient of the acknowledgement.
Description 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.
Size The maximum length of a sender’s identification is 16 alphanumeric
characters.
The maximum length of the coding scheme code is 3 alphanumeric
characters.
Applicability This information is mandatory.
Dependence requirements None.
Page: 32
Nordic TSO message exchange model
5.5.7 Header Party, Receiver, Role
Action Description
Definition of element Identification of the role played by the receiver of the document.
Description The sender role, which identifies the role of the originator within the
document.
Size The maximum length of a sender role is 3 alphanumeric
Characters.
Applicability This information is dependent.
Dependence requirements 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.)
5.5.8 Reference Document, Identification
Action Description
Definition of element Unique identification of the document that has been received.
Description This information identifies the document that has been received by the
receiving party. The identification is extracted from the received
document.
Size Receiving document code identification may not exceed 35 alphanumeric
characters.
Applicability This information is dependent.
Dependence requirements If the document cannot be successfully processed this information may not
be available.
5.5.9 Reference Document, Version
Action Description
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.
Description This information identifies the document that has been received by the
receiving party. The identification is extracted from the received
document.
Size Version number may not exceed 3 numeric characters.
Applicability This information is dependent.
Dependence requirements The document version must be provided for all documents being
acknowledged that have a document version attribute.
5.5.10 Reference Document, Type
Action Description
Definition of element The coded type of the document being referenced.
Description The document type is used to identify the type of document being
acknowledged.
Size A document type may not exceed 3 alpha-numeric characters.
Applicability This information is dependent.
Dependence requirements The document type is mandatory in contexts where there is potential
ambiguity about the document being acknowledged.
Page: 33
Nordic TSO message exchange model
5.5.11 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.
5.5.12 Reason Status, Reason (Code)
Action Description
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.
Description 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.
Size The maximum length of this information is 3 alphanumeric characters.
Applicability This information is mandatory after the Acknowledgement level and Time
Interval Error level. It is dependent at Time Series Rejection level.
Dependence requirements 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
Nordic TSO message exchange model
5.5.13 Reason Status, Reason (Text)
Action Description
Definition of element Textual description of a rejection.
Description If the code does not provide all the information to clearly identify an error
the reason text may be used.
Size The maximum length of this information is 512 alphanumeric characters.
Applicability This information is dependent.
Dependence requirements Used only if the reason code is insufficient to identify an error.
Page: 35
Nordic TSO message exchange model
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
Nordic TSO message exchange model
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
Nordic TSO message exchange model
B.2 Sequence of transfer capacity messages sent to/from NOIS
Figure 15: Sequence diagram: NOIS, Transfer Capacity exchanges
Page: 38
Nordic TSO message exchange model
B.3 Business rules for transfer capacity messages sent to/from NOIS
B.3.1 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.
B.3.2 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
B.3.3 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.
B.3.4 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.
B.3.5 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. )
B.3.6 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
B.3.7 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
Nordic TSO message exchange model
Domain will be set as “Nordel”
B.3.8 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”
B.3.9 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
Nordic TSO message exchange model
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
Nordic TSO message exchange model
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 Not yet implemented
flow based market
coupling
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: Signifies that what is auctioned is both the energy itself and transmission capacity
rights together.
Market balance area: Refer to ebIX, EFET and ENTSO-E Harmonised Electricity Role Model definition.
NTC: 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.
TTC: 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.
OC: 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.
Offered Capacity: 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
Nordic TSO message exchange model
one direction, to increase the Offered Capacity in the other direction. This is
generally known as Netting aimed at maximising Offered Capacity.
Prognosis: 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.
Schedule: A Schedule is a plan that is binding and used directly in settlement and/or
operational processes, see also Prognosis above.
System Operator: Refer to ebIX, EFET and ENTSO-E Harmonised Electricity Role Model definition.
Transfer capacity: 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: 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.
TTC: 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
Nordic TSO message exchange model
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
Nordic TSO message exchange model
Transfer Capacity Notification
Document Start Date Time
Capacity Time Interval Time Interval Type
Document End Date Time
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
Time Interval Time Interval Type
End Date Time
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
Nordic TSO message exchange model
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 Type
Version [0..1]
Page: 46
Nordic TSO message exchange model
Type [0..1] Message Type Receiving Document Message Type
Code Type [0..1]
Receiving Payload Identification Type
Name [0..1]
Date Time Receiving Message Date Time
Document [0..1] Type
Time Series Rejection [0..*]
Senders Time Series Identification Type
Identification
Senders Time Series Version Type
Version [0..1]
Time Interval Error [0..*]
Quantity Time Interval Time Interval Type
Status: Reason Status [1..*] Reason [0..*] / [1..*]
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 have 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 Nordic TSOs are only rejecting/confirming on document level and has skipped:
o Receiving Payload Name
o Date Time Receiving Document
o Time Series Rejection class
o Time Interval Error class
Page: 47
Related docs
