Nordic TSO message exchange model - Ediel Nordic Forum

BRS
(BUSINESS REQUIREMENT SPECIFICATION)
A MODEL FOR THE
NORDIC TSO
SCHEDULING AND ANCILLARY
SERVICES PROCESS
Business process: Nordic TSO Schedules
document exchange
Version: 1.0.A
Status:
Approved by Nordic Ediel
Group (NEG)
Date: February 15 th , 2010

Nordic TSO schedule document exchange model
CONTENT
1 INTRODUCTION .................................................................................................................................................... 3
1.1 BACKGROUND .................................................................................................................................................... 3
1.2 NORDIC ENERGY DOMAIN MODEL .................................................................................................................... 3
1.3 POSSIBLE FURTHER DEVELOPMENTS .................................................................................................................. 3
1.4 PROJECT ORGANISATION .................................................................................................................................... 3
1.5 REFERENCES ...................................................................................................................................................... 4
1.6 TERMS................................................................................................................................................................ 4
1.7 CHANGE LOG ..................................................................................................................................................... 5
2 PLANNING .............................................................................................................................................................. 6
2.1 PLANNING IN THE OVERALL CONTEXT (DOMAIN MODEL) .................................................................................. 6
2.2 BREAKDOWN OF THE SCHEDULING PROCESS WITHIN THE PLANNING PHASE ....................................................... 6
3 OVERVIEW OF THE NORDIC SCHEDULING PROCESS ............................................................................. 8
3.1 SCHEDULE SYSTEM INFORMATION FLOWS .......................................................................................................... 9
3.2 SCHEDULE SYSTEM INFORMATION REQUIREMENTS ............................................................................................ 9
3.2.1 Market schedules ........................................................................................................................................ 10
3.2.2 Operational schedules ................................................................................................................................ 11
3.2.3 Overview of Trading Models ...................................................................................................................... 13
4 HARMONISED ROLES USED IN “EXCHANGE SCHEDULES” ................................................................. 15
5 BUSINESS PARTNER VIEW, EXCHANGE SCHEDULES ............................................................................ 17
6 BUSINESS ENTITY VIEW, EXCHANGE SCHEDULES ................................................................................ 18
6.1 BUSINESS ENTITY VIEW, BUSINESS ENTITIES ................................................................................................... 18
6.2 BUSINESS ENTITY VIEW, BUSINESS ENTITY STATES ......................................................................................... 20
7 PROCESS AREAS WITHIN THE NORDIC SCHEDULING PROCESS....................................................... 22
7.1 PROCESS AREA: EXCHANGE MARKET SCHEDULES ............................................................................................ 22
7.1.1 Process area: Match schedules (Denmark and Sweden) ............................................................................ 23
7.2 PROCESS AREA: EXCHANGE PRODUCTION PROGNOSES (DENMARK)................................................................. 24
7.3 PROCESS AREA: EXCHANGE OPERATIONAL SCHEDULES ................................................................................... 25
7.4 PROCESS AREA: EXCHANGE CORRIDOR AND CUT CORRIDOR SCHEDULES ........................................................ 27
7.5 PROCESS AREA: EXCHANGE ANCILLARY SERVICES, INCLUDING RESERVE RESOURCES .................................... 28
8 BUSINESS DATA VIEW ...................................................................................................................................... 29
8.1 DOCUMENT RELATED TO MARKET SCHEDULES ................................................................................................ 29
8.1.1 Schedule document ..................................................................................................................................... 29
8.1.2 Status request document ............................................................................................................................. 33
8.1.3 Anomaly report ........................................................................................................................................... 34
8.1.4 Confirmation Report ................................................................................................................................... 38
8.2 DOCUMENTS RELATED TO OPERATIONAL SCHEDULES ..................................................................................... 41
8.2.1 Planned resource schedule ......................................................................................................................... 41
8.2.2 Resource Schedule Confirmation Report .................................................................................................... 46
9 BUSINESS RULES ................................................................................................................................................ 48
9.1 SCHEDULE DOCUMENT IN THE NORDIC COUNTRIES.......................................................................................... 48
9.2 BALANCE RESPONSIBLE PARTY DEFINITION .................................................................................................... 48
9.3 GENERAL GROUND RULES ................................................................................................................................ 48
APPENDIX A AN EXAMPLE OF TECHNICAL IMPLEMENTATION ......................................................... 50
Page: 2

Nordic TSO schedule document exchange model
1 INTRODUCTION
1.1 Background
Today the Nordic TSOs exchange documents based on several different formats and standards, such as Ediel
(DELFOR/MSCONS), NOIS XML documents 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
document exchanges towards one common document standard. The project is run as a Nordic project with
the Nordic Ediel Group as the steering group. The aim is to define document exchange models that can be
used for all document exchanges between the Nordic TSOs and Nord Pool Spot.
This document is a Business Requirement Specification (BRS) detailing the document exchanges related to
schedules, prognosis and Ancillary services (reserve resources) in the Nordic countries. The focus of the
document is the business aspects of the document exchanges and the basis for the document is the ENTSO-E
ESS and ERRP Implementation Guides [1], together with the ebIX ® , EFET and ENTSO-E Harmonised role
model [3]. When implementing the BRS, the ENTSO-E ESS and ERRP Implementation guides and the
related ENTSO-E XML schemas should be used.
In addition a show case is made for the Determine Transfer Capacity process [9]. This BRS is based on the
ENTSO-E ECAN Implementation Guide [1], but modified to fit the UN/CEFACT standards:
UN/CEFACT Modelling Methodology (UMM) [4]
UN/CEFACT UML Profile for Core Components (UPCC) [5]
UN/CEFACT XML Naming and Design Rules (NDR) [6]
The BRS for the Determine Transfer Capacity process is accompanied by a Requirements Specification
Mapping (RSM), serving to separate the aspects of requirements of greatest concern to business interests
from those of concern to technical design interests. The RSM is showing the technical implementation
details of the BRS, such as the UMM [4] Business Choreography View and Business Information View and
the XML schemas used for message exchange. The RSM is published as UML models in HTML format and
as a set of XML schemas.
1.2 Nordic Energy Domain Model
A Nordic Energy market Domain model, giving an overall overview of the structure and processes used in
the Nordic Energy market, can be found in [10].
1.3 Possible further developments
Consumption prognoses
o Norway and Sweden: Only internal process within the TSOs.
o Denmark: Internally generated within the TSO. The Consumption responsible parties can
optionally send these prognoses on an hourly basis, the day before.
Weather prognoses
1.4 Project organisation
The project is organised 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: 3

Nordic TSO schedule document exchange model
Willem Karel D van der Meijden, Energinet.dk, wme@energinet.dk
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
Mikael Kristensen, Energinet.dk, mkr@energinet.dk
Ove Nesvik, EdiSys, ove.nesvik@edisys.no
Roar Grindstrand , Statnett, roar.grindstrand@statnett.no
1.5 References
[1] ENTSO-E implementation guides, see http://www.entsoe.eu/resources/edi/:
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 Harmonised Role Model, ENTSO-E, ebIX ® and EFET, see
http://www.entsoe.eu/resources/edi/
[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] Nordic Ediel Group, BRS for the Nordic TSO Determine transfer capacity model, see
http://www.ediel.org/
[10] Nordic Energy Market Domain Model, see http://www.ediel.org/
[11] Agreement regarding operation of the interconnected Nordic power system (System Operation
Agreement)
http://www.entsoe.eu/fileadmin/user_upload/_library/publications/nordic/operations/060613_entso
e_nordic_SystemOperationAgreement_EN.pdf
1.6 Terms
In this document the term Ancillary services is used for services needed to maintain a stable power system,
typically used for instant handling of changes in consumption and outages in generation and transmission.
The Ancillary services consist of primary, secondary and tertiary reserves, characterised by their activation
time. The term Ancillary services are used as a synonym to Reserve resources, as is used in the ENTSO-E
Scheduling System [1].
The term document is used instead of message, when this is applicable. However when referencing ENTSO-
E document names, the ENTSO-E name will be used, e.g. message, report or document.
The term Market schedules is used instead of the ENTSO-E term Schedules when this is applicable and
Operational schedules is used instead of the ENTSO-E term Resource schedules when this is applicable.
Page: 4

Nordic TSO schedule document exchange model
When the term TSO is used in this document it includes also Nord Pool and Nord Pool Spot.
1.7 Change log
Ver/rel/rev Changed by Date Changes
RFC for Ove Nesvik 20100126 Request for comments for version 1.0.A within NEG.
1.0.A
0.5.D Ove Nesvik 20100120 Changed during and after project meeting January 19 and
20, 2010. This includes, among others:
Correction of maintenance requests to ENTSO-E
Addition of an example of a Planned Resource
Schedule Document for an Operational schedule,
including needed Nordic modifications, see Appendix
A.
0.5.C Ove Nesvik 20100111 Changed during and after project meeting December 15 and
16, 2009. This includes, among others, update of the tables
showing the elements used to identify documents.
0.5.B Ove Nesvik 20091211 Draft document changed not traced.
0.5.A Ove Nesvik 20091208 Draft document changed during and after project meeting
November 11 th 2009.
0.4.A Ove Nesvik 20091012 Draft document. Main changes from previous version:
Addition of a domain model description in chapter 2.1
Update of Business entities in chapter 6.1
Update of Business entity states in chapter 6.2
Update of the model artefacts in chapter 7 to be in line
with the ENTSO-E IGs
Update of the class diagrams in chapter 8 to be in line
with the ENTSO-E IGs
Addition of Attribute usage tables for all class diagrams
in chapter 8 (to be reviewed and filled in)
Addition of change requests to ENTSO-E for each class
diagram in chapter 8
0.3.B Ove Nesvik 20090907 Draft document – Changes not tracked.
0.3.A Ove Nesvik 20090612 Draft document – Changes not tracked.
0.2.A Ove Nesvik 20090424 Draft document – Changes not tracked.
0.1.A Ove Nesvik 20090307 First draft
Page: 5

Nordic TSO schedule document exchange model
2 PLANNING
2.1 Planning in the overall context (Domain model)
The Domain model describes the main business process areas needed to have a well functioning energy
market. The model is important for having a common and agreed understanding on how the energy market
works as a basis for development of common methods for exchange of information.
Figure 1: UseCase diagram: Domain model
For a more elaborated description of the process include in the domain model, see [10].
2.2 Breakdown of the scheduling process within the planning phase
In the rest of this document the Business area (UseCase) Schedule resources from the Business area Plan is
further elaborated.
Figure 2: UseCase diagram: The Nordic planning process
The Determine transfer capacity process is documented in a separate BRS, see [9].
Page: 6

Nordic TSO schedule document exchange model
The Process area Plan, outlined in Figure 2, concerns principally schedules and prognosis supplied by the
different Balance responsible parties and the System operator for a given Market balance area or a group of
Market balance areas. It also deals with the exchange of schedules between two Market balance areas via
System operators and the International system operator. Some of the resulting schedules are afterwards sent
to the Imbalance settlement responsible after validation, to be used in the Settlement process. Furthermore,
the planning phase, include exchanges related to Reserve resources.
Figure 3: Activity diagram: The Nordic planning process
Page: 7

Nordic TSO schedule document exchange model
3 OVERVIEW OF THE NORDIC SCHEDULING PROCESS
Figure 4: UseCase diagram: The Nordic Scheduling process
In Figure 4 the Nordic scheduling process is further decomposed into Business areas and Process areas.
Each of these Business areas and Process areas will be further described below.
The Balance responsible parties, operating within one or several Market balance areas sends schedules and
prognosis to the System operator, ensuring the correct operation of one or several Market balance areas. The
System operator sends the schedules to the International system operator for validation and publication.
The basic principle upon which this phase has been based is that all the trades between two Balance
responsible parties must be notified and coherent. For each Market balance area all the “in” flows should
balance with all the “out” flows. In the case of imbalance, the System operator must manage the imbalance
prior to the operation phase.
Page: 8

Nordic TSO schedule document exchange model
Figure 5: Activity diagram: The Nordic Scheduling process
3.1 Schedule system information flows
The schedule document transmission cycle is composed of the following phases:
1. The initial transmission of the schedule document to the System operator. During this phase the
document is verified for coherence independently of all the schedule documents that have been
transmit by other parties. This phase verifies the coherence of the time series within the document.
The phase ends with the transmission to the sender of a positive or negative acknowledgement of the
time series received and a transmission of the validated schedules to the International system
operator.
2. The matching validation (only in Denmark and Sweden) can be carried out on the time series within
a document once the time series from the complementary parties has been received. If a time series
is found not to match, an anomaly document is transmitted to all the involved parties informing them
of the problem. Time series found to be in error need to be retransmitted via the retransmission of the
applicable schedule document containing the corrected time series.
3. In the third phase the System operator informs the International system operator about relevant
received schedules and prognosis. The International system operator is responsible for publication
of the information.
4. In the last phase the System operator (Denmark and Sweden) or the Balance responsible parties
(Finland and Norway) sends the schedules to the Imbalance responsible parties as input to the
Settlement process.
Related documents are defined according to the UMM Business Data View [4], see chapter 8.
3.2 Schedule system information requirements
The sequence diagrams in Figure 6 and Figure 9 outlines the information that is exchanged between the
different actors in the planning phase of the Nordic energy market scheduling process. The sequence diagram
in Figure 6 outlines the market schedules, which are used in an economic settlement, while the sequence
Page: 9

Nordic TSO schedule document exchange model
diagram in Figure 9 outlines the operational schedules used for operational purposes. The information flows
concern essentially the day-ahead and intraday scheduling process as seen from a Market balance area
administered by a System operator and connected to another Market balance area administered by an
external System operator.
3.2.1 Market schedules
Trade can take place between the Market balance areas and the transmission capacity between the areas is
allocated to the Balance responsible parties by the Transmission capacity allocator, see [9].
The Nordic market is relatively simple compared to the typical market structure in central Europe and
requires a simple subset of the ENTSO-E sequence diagrams, see [1].
In Denmark and Sweden the Balance responsible parties will inform their System operator of the bilateral
trades they have carried out within a Market balance area. In Denmark these purchases and sales will
initially be controlled for coherence and if correct, the Balance responsible parties will be informed by the
System operator that the schedule has been accepted for processing. In the case of error, both the System
operator in Denmark and Sweden will inform the Balance responsible party of the errors through an
anomaly report. The Balance responsible party may then resubmit the schedules with the necessary
corrections. After cut-off time the System operator in Denmark and Sweden will send the schedules to the
Imbalance settlement responsible, to be used in the Settlement process.
In Finland and Norway the Balance responsible parties will send their market schedules directly to the
Imbalance settlement responsible, to be used in the Settlement process.
To close the process, relevant schedules are sent to the Imbalance settlement responsible party. This process
is not covered in this guide.
Page: 10

Nordic TSO schedule document exchange model
Figure 6: Sequence diagram of prognosis, market schedules and matching documents (ESS)
Comments to the diagram:
Arrow 3, Market schedules from Balance responsible parties to the Imbalance settlement
responsible, used in Finland and Norway, is seen as a part of the Settlement process and will not be
further elaborated in this document.
3.2.2 Operational schedules
The UCTE-System maintains the load-frequency control through the use of primary, secondary and tertiary
control to stabilise the interconnected system.
The NORDEL-system is stabilised primarily through frequency control. Since the NORDEL system is
connected by DC-Links to the UCTE system their different control mechanisms do not influence one
another. Independent from the control philosophies used, system control is done by a number of reserve
products that have become part of a liberalised market in almost all European countries.
Page: 11

Nordic TSO schedule document exchange model
System balancing
System control
Imbalance settlement
UCTE
Primary Control:
Activation criteria:
Deviation of
frequency
Automatic Activation.
Primary Control (FNR):
Activation criteria:
Deviation of frequency
Due to consumption**
Automatic Activation
NORDEL
Primary Control (FDR):
Activation criteria:
Deviation of frequency
due to disturbance**
Automatic Activation
Secondary Control:
Activation criteria:
Deviation of power
and frequency*
Automatic Activation.
Tertiary Control:
Activation criteria
To restore secondary
Reserve Manual
Activation
(SATCR, DATCR)
Secondary Control:
Activation criteria:
Deviation of power
and frequency**
Automatic Activation.
Tertiary Control:
Activation criteria:
To restore primary and
secondary reserve
Manual Activation
* Refer to the UCTE
Operational Handbook
policy 1 for the definition
of power and frequency
error.
** Refer to the Nordel guide
for the definitions of
disturbance and
consumption
Figure 7: UCTE and Nordel operational schedules differences
The reserve control mechanisms in the operational sense of the UCTE-system and the NORDEL system is
outlined in the above diagram.
To correctly handle load/generation balance prognosis it has become essential to exchange an ever-growing
amount of information between all involved parties. So much so that the historical phone operations are no
longer feasible. The open market requirements demand that the non-discrimination of information also plays
its part with added complexity. Amongst the primary requirements is the necessity to provide for energy
reserves in order to respond to unexpected events to keep the electricity system operational.
Three types of reserve are collected together in order to guarantee an operational network:
The primary reserve is instantaneous and is activated automatically as a function of the frequency
or to be more exact, the deviation from 50 Hz. The settings of the generators define how much they
contribute when there is a frequency deviation.
The secondary or fast reserves are reserves that within 15 minutes shall be able to eliminate the
unbalance between generation and load and thus re-establish the primary or instantaneous reserve.
The tertiary or slow reserve shall have such qualities that it can replace the fast reserves.
Economical judgement is taken into account when decision is taken regarding the speed of the slow
reserves. The activation of tertiary reserves is handled manually.
In the future the use of secondary control, LFC (Load Frequency Control), will increase. Secondary control
is used in Sweden, Denmark and planned implemented in Norway by 2011.
Page: 12

Nordic TSO schedule document exchange model
3.2.3 Overview of Trading Models
The ENTSO-E Task Force Balance Management (TF BM) has developed several contractual models which
describe how the trading of balancing services across borders could be facilitated. This section provides an
overview of two of these models, covering the roles and responsibilities of each participant. The involved
participants are the Resource Providers (RP) and the System Operators (SO).
The principal role in these models is that of a Resource Provider which is defined as “A role that manages a
resource object and provides the schedules for it”. A Resource Object is defined as being “A resource that
can either produce or consume energy and that is reported in a schedule”.
The two models that have been developed are:
Model 1 – System Operator - Resource Provider, not used in the Nordic area and not further
described in this document.
Model 2 – System Operator - System Operator
Model 2 (System Operator – System Operator)
The main principle behind model 2 is that System Operators will contract for the provision of balancing
services to each other. Each System Operator will then be responsible for taking the necessary action in his
own area to deliver the balancing service to the other System Operator.
Imbalance Settlement
Arrangements
Imbalance Settlement
Arrangements
Area 1 Area 2
System operator
System operator
Resource provider
Resource provider
Reserve object
Reserve object
Figure 8: Contractual Arrangements for Trading Balancing Services Using Model 2
The key features of this model, as outlined in the diagram in Figure 8, are:
The System Operators of Area 1 and Area 2 are different. They are responsible for balancing their
own area
The Resource Provider’s Reserve Object in Area 1 is physically connected to the network controlled
by the System Operator of Area 1 (same arrangement in Area 2)
Each area has its own set of electricity market rules, including those relating to imbalance settlement
The Resource Provider’s Reserve Object in Area 1 may provide balancing services for the System
Operator of Area 1
Page: 13

Nordic TSO schedule document exchange model
The Resource Provider in Area 1 shall not provide balancing services directly to the System
Operator of Area 2
The System Operator of Area 1 may contract with the System Operator of Area 2 to provide
Balancing Services (and vice versa)
The System Operator of Area 1 is responsible for taking the necessary action in his own area to
deliver balancing service to the System Operator of Area 2 and vice versa.
Figure 9: Sequence diagram of operational schedules
Page: 14

Nordic TSO schedule document exchange model
4 HARMONISED ROLES USED IN “EXCHANGE SCHEDULES”
In Figure 10 and definitions below the relevant parts of the ebIX, EFET and ENTSO-E Harmonised role
model are outlined.
Figure 10: Outline of the Harmonised role model within the scope of Nordic scheduling process
Definitions (from the ebIX, EFET and ENTSO-E Harmonised role model) :
Balance responsible party: A party that has a contract providing financial security and
identifying balance responsibility with the Imbalance Settlement
Responsible of the market balance area entitling the party to operate
in the market. This is the only role allowing a party to buy or sell
energy on a wholesale level.
Additional information:
The meaning of the word "balance" in this context signifies that that
the quantity contracted to provide or to consume must be equal to
the quantity really provided or consumed. Such a party is often
owned by a number of market players. Equivalent to "Program
responsible party" in the Netherlands. Equivalent to "Balance
responsible group" in Germany. Equivalent to "market agent" in
Spain.
Consumption Responsible party: A party who can be brought to rights, legally and
financially, for any imbalance between energy bought and consumed
for all associated metering points.
Additional information:
This is a type of Balance Responsible Party.
Production Responsible party: A party who can be brought to rights, legally and financially,
for any imbalance between energy sold and produced for all
associated metering points.
Page: 15

Nordic TSO schedule document exchange model
Additional information:
This is a type of Balance Responsible Party
Market Balance Area:
Market operator:
System Operator:
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.
The unique power exchange of trades for the actual delivery of
energy that receives the bids from the Balance Responsible Parties
that have a contract to bid. The market operator determines the
market energy price for the Market Balance Area after applying
technical constraints from the System Operator and the bilateral
trade schedules from the Balance Responsible Parties. It may also
establish the price for the reconciliation within a metering grid area.
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).
Note:
Additional obligations may be imposed through local market rules.
Page: 16

Nordic TSO schedule document exchange model
5 BUSINESS PARTNER VIEW, EXCHANGE SCHEDULES
In addition to the roles defined in the ebIX, EFET and ENTSO-E Harmonised role model (see 4) the
following partner types have been identified as relevant for the Business area Exchange schedules.
International System Operator: A cooperation of two or more System Operators across national
borders, acting as a System operator for the combined area.
Note:
NOIS will act in the role as International System Operator in the
Nordic countries.
Page: 17

Nordic TSO schedule document exchange model
6 BUSINESS ENTITY VIEW, EXCHANGE SCHEDULES
6.1 Business Entity View, Business entities
In addition to the domains defined in the ebIX, EFET and ENTSO-E Harmonised role model (see chapter 4)
a series of entities have been identified as relevant for the Business area Exchange schedules. These entities
are shown below in two groups:
The entities specially designed for the business documents used in the Scheduling process.
The common (reused) entities, used in the different business documents defined for the Nordic
energy market.
The attributes defined for the entities can be found in the detailed class diagrams shown later in this
document.
Figure 11: Document entities relevant for the Nordic scheduling process
Page: 18

Nordic TSO schedule document exchange model
Figure 12: Common document entities relevant for the Nordic energy market
Page: 19

Nordic TSO schedule document exchange model
6.2 Business Entity View, Business entity states
The lifecycle of a business entity may be described as a flow of business entity states, which represents the
different business entity states a business entity can exist in. Below is shown the lifecycle of some of the
business documents exchanged in the Nordic TSO scheduling process.
Figure 13: Business entity states for Request of matched schedules
Figure 14: Business entity states for Market schedule processes
Page: 20

Nordic TSO schedule document exchange model
Figure 15: Business entity states for Operational schedule processes
Figure 16: Business entity states for Operational schedule confirmation processes
Page: 21

Nordic TSO schedule document exchange model
7 PROCESS AREAS WITHIN THE NORDIC SCHEDULING PROCESS
7.1 Process area: Exchange market schedules
Figure 17: UseCase: Exchange market schedules
The Market schedules are high level (aggregated) schedules, which are sent from the Balance responsible
parties to the Imbalance settlement responsible. They are not used for operation. In Finland and Norway the
Market schedules are sent directly from the Balance responsible parties to the Imbalance settlement
responsible, while the schedules are sent via the System operator in Denmark and Sweden.
Figure 18: Activity diagram: Exchange market schedules
Page: 22

Nordic TSO schedule document exchange model
The Market schedules are sent on hourly basis day-ahead and contain energy values for production and/or
trade. In Denmark it may also contain consumption (optional).
The Market schedules are aggregated per Balance responsible party and Market balance area.
7.1.1 Process area: Match schedules (Denmark and Sweden)
Figure 19: Activity diagram: Match schedules
The matching validation in Sweden is carried out for every received schedule, independent of what is
received from complementary parties, while it in Denmark is carried out once the time series from the
complementary parties has been received or one hour before cut-off time for the market. If a time series is
found not to match, an anomaly document is transmitted to all the involved parties informing them of the
Page: 23

Nordic TSO schedule document exchange model
problem. Time series found to be in error need to be retransmitted via the retransmission of the applicable
schedule document containing all relevant time series, both the corrected, the non-erroneous time series that
were sent with the original document, possibly missing time series and leaving out time series to be removed.
In Denmark the System operator will send a Market schedule anomaly report to the Balance responsible
party, if anomalies apply (regardless of market). In Sweden the System operator will send a Market schedule
anomaly report to the Balance responsible party, if anomalies apply outside the Elspot market (for bilateral
trade). In Denmark the System operator will await corrected schedules and if these are not received within
cut-off time an imposed Market schedule confirmation document is sent to the Balance responsible party. At
cut-off time the schedules (either corrected or imposed) are sent to the Imbalance settlement responsible.
The guard ”Within Swedish market rule " relates to the rule that the party with the highest volume can
correct. If the parties disagree by cut-off time the “lesser rule” applies, i.e. the lesser volume is used. This is
however not reported before the settlement. In Denmark it is always the “lesser value” that is used.
For the Elbas market there is no Market schedule anomaly report. In Denmark however, the imposed Market
schedule confirmation document is sent.
7.2 Process area: Exchange production prognoses (Denmark)
Figure 20: UseCase: Exchange production prognoses
The Business area Exchange production prognosis occurs only in Denmark. The production prognoses are
plans that are not binding for the sender and they are not used directly in settlement and/or operation.
There are two types of prognoses:
Prognoses sent 4 weeks upfront, with expected production per power plant on a weekly resolution.
This prognosis includes free text.
Prognoses sent day-ahead with hourly values.
Figure 21: Activity diagram: Exchange production prognoses
Page: 24

Nordic TSO schedule document exchange model
7.3 Process area: Exchange operational schedules
Figure 22: UseCase: Exchange operational schedules
The Market schedules related to bilateral trade from the Balance responsible parties and the Market operator
(NordPool) are used together with the Operational schedules to calculate Cut-corridor schedules, balance
per Market balance area and binding consumption plans.
Operational schedules can be sent “day-ahead” or intraday. Day-ahead schedules can be sent several weeks
before the operational day and be changed up to the cut-off time the day before. Binding Intra-day schedules
can be sent up to 45 minutes ahead of operation. In Sweden the schedules may be updated up to and
including the operational hour, but these schedules will not be forwarded to the Imbalance settlement
responsible. The Operational schedules contain power values and are sent from the Balance responsible
parties (Production responsible parties) to the System operator for operational purposes. The resolution
varies between the Nordic countries as follows:
Hourly in Denmark, Norway and Sweden. From 2011 all operational schedules will have a 15
minutes resolution
15 minutes resolution in Norway and Sweden. Today 15 minutes resolution is used for information,
the hourly plan is used in the settlement.
Every 5 minutes in Denmark
Page: 25

Nordic TSO schedule document exchange model
Figure 23: Activity diagram: Exchange operational schedules
The extended UseCase Exchange aggregated schedules per Balance responsible party and Market balance
area (see Figure 22), which only is used in Sweden, is included in the activity diagram above.
Page: 26

Nordic TSO schedule document exchange model
7.4 Process area: Exchange Corridor and cut corridor schedules
Figure 24: UseCase: Exchange Corridor and cut corridor schedules
The Corridor and cut corridor schedules are sent from the System operator to the International system
operator and contain the scheduled exchange from the Transmission capacity allocator (Nord Pool) split on
relevant corridors.
A corridor is a group of power cables/lines. Corridors are used in order to give details about individual or
groups of cables. The information is used by the International system operator in balance management to
present details of import/export plans (individual plans display) and to compute surplus/deficit of each
control area. For example, Skagerrak corridor has 3 cables and can be defined as two HVDC corridors
(Skagerrak1-2 and Skagerrak3). The Corridors can be split into three types:
Elspot corridor Corridors between Market balance area within the Nordic market area.
Cut corridor Internal corridor within a Market balance area
External corridor Corridors external to the Nordic market area (in/out of the Nordic market area).
Figure 25: Activity diagram: Exchange Corridor and cut corridor schedules
Page: 27

Nordic TSO schedule document exchange model
7.5 Process area: Exchange Ancillary services, including Reserve resources
Figure 26: UseCase: Exchange Ancillary services
The Ancillary services process in the Nordic countries may contain:
Frequency bias
Frequency controlled disturbance reserve (FDR)
Frequency controlled normal operation reserve (FNR)
Unavailable production capacity (only Norway and Sweden)
Available production capacity (only Denmark)
Spinning reserve (only Norway)
Figure 27: Activity diagram: Exchange Ancillary services
Amongst the primary requirements for the System Operators is the necessity to provide for energy reserves
in order to respond to unexpected events to keep the electricity system operational.
Page: 28

Nordic TSO schedule document exchange model
8 BUSINESS DATA VIEW
8.1 Document related to Market schedules
The Schedule document (Market schedule document) is used for market schedules, which later on is used in
the balance settlement process.
8.1.1 Schedule document
8.1.1.1 Class diagram
Figure 28: Class diagram: Schedule document
Page: 29

Nordic TSO schedule document exchange model
8.1.1.2 Attribute usage
Document Attribute Code and description
Balance
Header
responsible Document version Not used
schedule to Document type A01 Balance responsible schedule
System Process type A17 Schedule day
operator Classification type A01 Detail type
(SO)
A02 Summary type
Sender role A08 Balance responsible party (NordPool is seen as a BRP)
Receiver role A04 System operator
Domain
Market balance area (Elspot area)
Subject party Not used
Subject role Not used
Matching period Not used
Time series
Time series version Not used
Business type A01 Production (DK: Non adjustable)
Z01 Production, adjustable (Used in DK)
A04 Consumption (DK: Non adjustable)
Z04 Consumption, adjustable (Used in DK)
A06 External trade
A08 Internal trade (Within a Market balance area)
National rules:
SE: A06 is used for external trade to Poland, Germany and
for NordPool Elspot/Elbas trade between SE and
NO/DK/FI
DK: A06 is used for external trade to Germany and for
NordPool Elspot/Elbas trade between DK and NO/SE
NO: No market schedules are sent to the SO
Product
8716867000030 Active energy
Object aggregation A03 Party
In area Market balance area, usage: see 8.1.1.3
Out area Market balance area, usage: see 8.1.1.3
Metering point Not used
identification
In party Balance responsible party, usage: see 8.1.1.3
Out party Balance responsible party, usage: see 8.1.1.3
Capacity agreement Not used
identification
Table 1: Usage of Schedule document, Balance responsible schedule to System operator
Balance
responsible
schedule to
Imbalance
settlement
responsible
(ISR)
Header
Document Type A01 Balance responsible schedule
Document version Not used
Process Type A17 Schedule day
Classification type A01 Detail type
A02 Summary type
Sender role A08 Balance responsible party (NordPool is seen as a BRP)
Receiver role A05 Imbalance settlement responsible
Domain
Market balance area (Elspot area)
Subject party Not used
Page: 30

Nordic TSO schedule document exchange model
Subject role Not used
Matching period Not used
Time series
Time series version Not used
Business Type A06 External trade non-explicit capacity
A08 Net internal trade (Within a Market balance area)
National rules:
SE/DK: No market schedules are sent from BRP to ISR
Product
8716867000030 Active energy
Object aggregation A03 Party
In area Market balance area, usage: see 8.1.1.3
Out area Market balance area, usage: see 8.1.1.3
Metering point Not used
identification
In party Balance responsible party, usage: see 8.1.1.3
Out party Balance responsible party, usage: see 8.1.1.3
Capacity agreement Not used
identification
Table 2: Usage of Schedule document, Balance responsible schedule to Imbalance settlement responsible
8.1.1.3 Business type dependencies
Business
type
A01
Z01
A04
Z04
A06
A08
Name Area Party
In Out In Out
Production (DK: M
M
Non adjustable)
Production, M
M
adjustable
Consumption
M
M
(DK: Non
adjustable)
Consumption,
M
M
adjustable
External trade M M M M
non-explicit
capacity
Net internal M *) M *) M M
trade
Table 3: Dependency matrix for Schedule document
*)
The In area and the Out area are the same Market balance area
8.1.1.4 National remarks
Norway:
The Norwegian Bulk supply code (B-code) used today will be replaced by an Out party (buyer), an
In party (seller), an In area and an Out area identifying the Market balance area.
8.1.1.5 Required changes to ESS Schedule document
Schedule Document (Schedule Message) class:
Page: 31

Nordic TSO schedule document exchange model
Rename the following elements (to be in-line with ERRP and in general making the ENTSO-E IGs
more consistent):
o In general change the term Message to Document in the ESS guide;
• ScheduleMessage class to ScheduleDocument
• MessageIdentification attribute to DocumentIdentification
• MessageVersion attribute to DocumentVersion
• MessageType attribute to DocumentType
• MessageDateTime attribute to DocumentDateTime
o ScheduleClassificationType attribute to ClassificationType
Split the ScheduleTimeInterval attribute to two elements:
o TimePeriodCoveredStart
o TimePeriodCoveredEnd
Note that the following elements not will be used in the Nordic countries:
o DocumentVersion
o SubjectParty
o SubjectRole
o MatchingPeriod
Schedule Time Series class:
Rename the following elements (to be in-line with ERRP and in general making the ENTSO-E IGs
more consistent):
o SendersTimeSeriesIdentification attribute to TimeSeriesIdentification
o SendersTimeSeriesVersion attribute to TimeSeriesVersion
Change the cardinality of TimeSeriesVersion to optional. [0..1]. The TimeSeriesVersion will not be
used in the Nordic countries.
New code requests:
Business Type
Z01 Production, adjustable (Used in DK)
Z04 Consumption, adjustable (Used in DK)
Page: 32

Nordic TSO schedule document exchange model
8.1.2 Status request document
Document used for requesting matched Market schedules.
Figure 29: Class diagram: Schedule status request document
8.1.2.1 Attribute usage
Document Attribute Code and description
Schedule
status
request
Header
Document Type A01 Balance responsible schedule
Process Type A17 Schedule day
Sender role A08 Balance responsible party
Receiver role A04 System operator
Domain
Market balance area (Elspot area)
Table 4: Usage of Schedule status request document
8.1.2.2 Required changes to ESR ENTSO-E Status request document
Rename the following elements (to be in-line with ERRP and in general making the ENTSO-E IGs
more consistent):
o In general change the term Message to Document in the ESR guide;
• MessageIdentification attribute to DocumentIdentification
• MessageType attribute to DocumentType
• MessageDateTime attribute to DocumentDateTime
Add the following attributes:
o Domain
Page: 33

Nordic TSO schedule document exchange model
8.1.3 Anomaly report
Document used for reporting Market schedules anomalies.
. Figure 30: Class diagram: Anomaly report
8.1.3.1 Attribute usage
Document Attribute Code and description
Anomaly
Header
report Sender role A04 System operator
Receiver role A08 Balance responsible party
Domain
Market balance area (Elspot area)
Time series
Senders document Not used
Page: 34

Nordic TSO schedule document exchange model
version
Senders time series Not used
version
Business Type A01 Production (DK: Non adjustable)
Z01 Production, adjustable (Used in DK)
A04 Consumption (DK: Non adjustable)
Z04 Consumption, adjustable (Used in DK)
A06 External trade
A08 Internal trade
Z08 Trade, unconfirmed (Used in DK)
A24 Total trade
A19 Balance energy deviation
Z05 Net internal trade counterpart (Used in DK)
Z14 TSO adjustment (Used in DK)
Z15 Result of an automatic TSO adjustment (Used in DK)
Z16 Difference (Used in DK)
Product
8716867000030 Active energy
Object aggregation A03 Party
In area Market balance area, usage: see 8.1.3.2
Out area Market balance area, usage: see 8.1.3.2
Metering point Not used
identification
In party Balance responsible party, usage: see 8.1.3.2
Out party Balance responsible party, usage: see 8.1.3.2
Capacity contract Not used
type
Capacity agreement Not used
identification
Reason code At the time series level:
A09 Time series not matching
A27 Cross border capacity exceeded
A28 Counterpart time series missing
A29 Counterpart time series quantity differences
8.1.3.2 Business type dependencies
At the interval level:
Z11 Planned (The information provided has a status of planned)
Z12 Counterpart Imbalance (The information provided has a
status of imbal-ance with a counterpart)
Z13 Internal Imbalance (The information provided has a status
of internal imbalance)
Z15 Forced Adjustment (The information provided has status of
a forced adjustment)
Z16 Forced Adjustment Final (The information provided has
status of a forced adjustment and is final)
Z17 Final (The information provided is final)
Table 5: Usage of Anomaly report
Business
Name Area Party
type
In Out In Out
A01 Production (DK: Non adjustable) M M
Z01 Production, adjustable (Used in DK) M M
A04 Consumption (DK: Non adjustable) M M
Page: 35

Nordic TSO schedule document exchange model
Z04 Consumption, adjustable (Used in DK) M M
A06 External trade M M M M
A08 Internal trade M *) M *) M M
Z08 Trade, unconfirmed (Used in DK) M *) M *) M M
A24 Total trade M M
A19 Balance energy deviation M M
Z05 Net internal trade counterpart (Used in M *) M *) M M
DK)
Z14 TSO adjustment (Used in DK) M M
Z15 Result of an automatic TSO adjustment M M M M
(Used in DK)
Z16 Difference (Used in DK) M M M M
Table 6: Dependency matrix for Anomaly report
*)
The In area and the Out area are the same Market balance area if Internal trade.
8.1.3.3 Required changes to ESS Anomaly report
Anomaly report class:
Rename the following elements (to be in-line with ERRP and in general making the ENTSO-E IGs
more consistent):
o In general change the term Message to Document in the ESS guide;
• MessageIdentification attribute to DocumentIdentification
• MessageDateTime attribute to DocumentDateTime
Split the ScheduleTimeInterval attribute to two elements, see also Maintenance Request:
o TimePeriodCoveredStart
o TimePeriodCoveredEnd
Add the following attributes:
o Domain
Anomaly time series class:
Add the attribute TimeSeriesIdentification. It isn’t necessarily the same Time series that are returned.
Rename the TimeSeriesAnomaly class to AnomalyTimeSeries, to be in-line with ERRP, in general
making the ENTSO-E IGs more consistent and to be in-line with the CC principles of qualifying the
TimeSeries CC:
Rename the following attributes (to be in-line with ERRP and in general making the ENTSO-E IGs
more consistent):
o In general change the term Message to Document in the ESS guide;
• MessageSenderIdentification attribute to DocumentSenderIdentification
• SendersMessageIdentification attribute to SendersDocumentIdentification
• SendersMessageVersion attribute to SendersDocumentVersion
Change the cardinality of the following attributes to optional. [0..1]. The attributes will not be used
in the Nordic countries:
o SendersDocumentIdentification (original SendersMessageIdentification)
o SendersDocumentVersion (original SendersMessageVersion)
o SendersTimeSeriesIdentification
o SendersTimeSeriesVersion
Change the cardinality of the association from the Anomaly time series class to the Reason class
from 1..* to 0..1
Add an association from the Interval class to the Reason class with a cardinality of 0..*
New code requests:
Business Type
Z05 Net internal trade counterpart (Used in DK)
Page: 36

Nordic TSO schedule document exchange model
Z08 Trade, unconfirmed (Used in DK)
Z14 TSO adjustment (Used in DK)
Z15 Result of an automatic TSO adjustment (Used in DK)
Z16 Difference (Used in DK)
Page: 37

Nordic TSO schedule document exchange model
8.1.4 Confirmation Report
The Time Series Confirmation Report is used for reporting confirmed Market schedules.
Figure 31: Class diagram: Confirmation Report
8.1.4.1 Attribute usage
Document Attribute Code and description
Confirmation
Header
Report Document Type A01 Balance responsible schedule
Sender role A04 System operator
Receiver role A08 Balance responsible party
Senders document Not used
version
Domain
Market balance area (Elspot area)
Page: 38

Nordic TSO schedule document exchange model
Subject party Not used
Subject role Not used
Process Type A17 Schedule day
Confirmed schedule time series
Senders time series Not used
version
Business Type A01 Production (DK: Non adjustable)
Z01 Production, adjustable (Used in DK)
A04 Consumption (DK: Non adjustable)
Z04 Consumption, adjustable (Used in DK)
A06 External trade
A08 Internal trade
Z08 Trade, unconfirmed (Used in DK)
A24 Total trade
A19 Balance energy deviation
Z05 Net internal trade counterpart (Used in DK)
Z14 TSO adjustment (Used in DK)
Z15 Result of an automatic TSO adjustment (Used in DK)
Z16 Difference (Used in DK)
Product
8716867000030 Active energy
Object aggregation A03 Party
In area Market balance area, usage: see 8.1.3.2
Out area Market balance area, usage: see 8.1.3.2
Metering point Not used
identification
In party Balance responsible party, usage: see 8.1.3.2
Out party Balance responsible party, usage: see 8.1.3.2
Capacity contract Not used
type
Capacity agreement Not used
identification
Reason code At the time series level:
A09 Time series not matching
A27 Cross border capacity exceeded
A28 Counterpart time series missing
A29 Counterpart time series quantity differences
At the interval level:
Z11 Planned (The information provided has a status of planned)
Z12 Counterpart Imbalance (The information provided has a
status of imbal-ance with a counterpart)
Z13 Internal Imbalance (The information provided has a status
of internal imbalance)
Z15 Forced Adjustment (The information provided has status of
a forced adjustment)
Z16 Forced Adjustment Final (The information provided has
status of a forced adjustment and is final)
Z17 Final (The information provided is final)
Imposed schedule time series
Senders time series Not used
version
Business Type A01 Production (DK: Non adjustable)
Z01 Production, adjustable (Used in DK)
A04 Consumption (DK: Non adjustable)
Z04 Consumption, adjustable (Used in DK)
A06 External trade
Page: 39

Nordic TSO schedule document exchange model
A08 Internal trade
Z08 Trade, unconfirmed (Used in DK)
A24 Total trade
A19 Balance energy deviation
Z05 Net internal trade counterpart (Used in DK)
Z14 TSO adjustment (Used in DK)
Z15 Result of an automatic TSO adjustment (Used in DK)
Z16 Difference (Used in DK)
Product
8716867000030 Active energy
Object aggregation A03 Party
In area Market balance area, usage: see 8.1.3.2
Out area Market balance area, usage: see 8.1.3.2
Metering point Not used
identification
In party Balance responsible party, usage: see 8.1.3.2
Out party Balance responsible party, usage: see 8.1.3.2
Capacity contract Not used
type
Capacity agreement Not used
identification
Reason code
Table 7: Usage of Confirmation Report
8.1.4.2 Required changes to ESS Confirmation Report
Confirmation Report class:
Rename the following elements (to be in-line with the AnomalyReport and ERRP, and in general
making the ENTSO-E IGs more consistent):
o In general change the term Message to Document in the ESS guide;
• MessageIdentification attribute to DocumentIdentification
• MessageType attribute to DocumentType
• MessageDateTime attribute to DocumentDateTime
o ScheduleTimeInterval attribute to TimePeriodCovered
o ConfirmedMessageIdentification attribute to SendersDocumentIdentification
o ConfirmedMessageVersion attribute to SendersDocumentVersion
Change the cardinality of SendersDocumentVersion to optional. [0..1]. The
SendersDocumentVersion will not be used in the Nordic countries.
Confirmed Schedule Time Series class:
Rename the TimeSeriesConfirmation class to Confirmed Schedule Time Series class
Add the attribute TimeSeriesIdentification with a cardinality of [0..1]. It isn’t necessarily the same
Time series that are returned.
Change the cardinality of SendersTimeSeriesVersion to optional. [0..1]. The
SendersTimeSeriesVersion will not be used in the Nordic countries.
Page: 40

Nordic TSO schedule document exchange model
8.2 Documents related to Operational schedules
The Planned resource schedule (Operational schedule document) is used for operational schedules and
Production prognoses day-ahead.
8.2.1 Planned resource schedule
8.2.1.1 Class diagram
Figure 32: Class diagram: Planned resource schedule
Page: 41

Nordic TSO schedule document exchange model
8.2.1.2 Attribute usage
Document Attribute Code and description
Production
Header
and Document version Not used
consumption Document Type Z01 Operational schedule
schedule Process Type A17 Schedule day
Sender role A04 System operator
A08 Balance responsible party
Receiver role Z03 International system operator
A04 System operator
A05 Imbalance settlement responsible
Domain
Any known area from the Harmonised role model cowering the areas
within the time series level of the document, e.g. Market balance area
(Elspot area), National Area, etc
Subject party Not used
Subject role Not used
Classification type A01 Detail type
A02
Summary type
Time series
Business Type A01 Production
A04 Consumption
Z17 Technical minimum
Z18 Technical maximum
Z19 Total maximum
Z20 Total minimum
Z26 Operational balance
Direction
Not used
Product
8716867000016 Active power
8716867000030 Active energy
Connecting area Not used
Resource object Only used for Classification type = A01, i.e. Station group, regulation
object
Resource provider Not used
Acquiring area Not used
Capacity contract Not used
type
Capacity agreement Not used
identification
In area
Used for all Business types, except consumption schedules, i.e.
Market balance area
Out area
Only used for consumption schedules, i.e. Market balance area
Business type Z01 Hydro
characteristics Z02 Nuclear
Z03 Thermal
Z04 Wind
Z05 Decentralised
National rules:
DK: Z05 is only used in Denmark (aggregated production for
small production units)
Table 8: Usage of Planned resource schedule, Production and consumption schedule
Page: 42

Nordic TSO schedule document exchange model
Ancillary
services
schedule
Header
Document version Not used
Document type Z01 Operational schedule
Process type A17 Schedule day
Sender role A08 Balance responsible party
A04 System operator
Receiver role A04 System operator
A05 Imbalance settlement responsible
Z03 International system operator
Domain
Any known area from the Harmonised role model cowering the areas
within the time series level of the document, e.g. Market balance area
(Elspot area), National Area, etc
Subject party Not used
Subject role Not used
Classification type A01 Detail type
A02 Summary type
Time series
Business type A38 Available generation
Z02 Frequency bias
Z03 Frequency controlled normal operation reserve (FNR)
Z06 Frequency controlled disturbance reserve (FDR)
Z07 Unavailable production
Z09 Spinning reserve
Z10 Fast reserve
Z11 Load frequency control reserves (LFC)
Z12 Total primary reserve
Z24 Peak load resource
Direction
Product
Connecting area
Resource object
Resource provider
Acquiring area
Capacity Contract
type
Capacity agreement
identification
In area
Out area
Business type
characteristics
National rules:
DK: Z02, Z03, Z06 (15 minutes reserve), Z07, Z08, Z09 and
Z11 are used in Denmark
NO: Z02, Z03, Z06, Z07, Z09, Z10, Z11 and Z12 are used in
Norway
SE: Z02, Z03, Z06, Z07, Z10 and Z24 are used in Sweden
Not used
8716867000016 Active power
8716867000030 Active energy
Not used
Only used for Classification type = A01, i.e. Station group, regulation
object
Not used
Not used
Not used
Not used
Market balance area
Not used
Not used
Table 9: Usage of Planned resource schedule, Ancillary services schedule
Page: 43

Nordic TSO schedule document exchange model
Corridor
and cut
corridor
schedules
Header
Document version Not used
Document type Z02 Transmission schedule
Process type A17 Schedule day
Sender role A08 Balance responsible party
A04 System operator
Receiver role A04 System operator
A05 Imbalance settlement responsible
Z03 International system operator
Domain
Any known area from the Harmonised role model cowering at least
either the In areas or Out areas within the time series level of the
document, e.g. Market balance area (Elspot area), National Area, etc
Subject party Not used
Subject role Not used
Classification type A01 Detail type
A02 Summary type
Time series
Business type Z25 Total transmission plan
Direction
Not used
Product
8716867000016 Active power
8716867000030 Active energy
Connecting area Not used
Resource object Only used for Classification type = A01
Resource provider Not used
Acquiring area Not used
Capacity Contract Not used
type
Capacity agreement Not used
identification
In area
Market balance area or National area
Out area
Market balance area or National area
Business type Not used
characteristics
Table 10: Usage of Planned resource schedule, Corridor and cut corridor schedules
8.2.1.3 Business type dependencies
Business
Name Area Business type
type
In Out characteristics
A01 Production M D
A04 Consumption M
A38 Available generation M
Z17 Technical minimum M
Z18 Technical maximum M
Z19 Total maximum M
Z20 Total minimum M
Z02 Frequency bias M
Z03 Frequency controlled normal operation reserve (FNR) M
Z06 Frequency controlled disturbance reserve (FDR) M
Z07 Unavailable production M
Z09 Spinning reserve M
Z10 Fast reserve M
Z11 Load frequency control reserves (LFC) M
Z12 Total primary reserve M
Page: 44

Nordic TSO schedule document exchange model
Z24 Peak load resource M
Z25 Total transmission plan M M
Table 11: Dependency matrix for Planned resource schedule
8.2.1.4 Required changes to ERRP Planned resource schedule
Planned Resource Schedule Document class:
Change the cardinality of DocumentVersion to optional, [0..1]. The DocumentVersion will not be
used in the Nordic countries.
Add the following attributes need in the Nordic countries:
o ClassificationType
Planned Resource Time Series class:
Change the cardinality of the following attributes to optional, [0..1], since these attributes not will be
used in the Nordic countries:
o ConnectingArea
o RecourceProvider
Add the following attributes, which are needed in the Nordic countries:
o InArea, used for most Business types. Note that the Connecting area could have been used
instead of In area for all Business types except for Total transmission plan. Since In area is
needed for the latter Business type the element is preferred used for all.
o OutArea, used for scheduled exchange between areas
o BusinessTypeCharacteristics, i.e. characteristics of a Business type, such as Hydro, Nuclear,
Wind …
New code requests:
Business Type
Z02 Frequency bias
Z03 Frequency controlled normal operation reserve (FNR)
Z06 Frequency controlled disturbance reserve (FDR)
Z07 Unavailable production
Z09 Spinning reserve
Z10 Fast reserve
Z11 Load frequency control reserves (LFC)
Z12 Total primary reserve
Z17 Technical minimum
Z18 Technical maximum
Z19 Total maximum
Z20 Total minimum
Z24 Peak load resource
Z25 Total transmission plan
Document Type:
Z01 Operational schedule
Z02 Transmission schedule
Role Type:
Z03 International system operator
Business Type Characteristics:
Z01 Hydro
Z02 Nuclear
Z03 Thermal
Z04 Wind
Z05 Decentralised
Page: 45

Nordic TSO schedule document exchange model
8.2.2 Resource Schedule Confirmation Report
Figure 33: Class diagram Resource Schedule Confirmation Report
8.2.2.1 Attribute usage
Document Attribute Code and description
Resource
Header
Schedule Document version Not used
Confirmation Document Type A18 Confirmation report
Report Process Type A17 Schedule day
Sender role A04 System operator
Page: 46

Nordic TSO schedule document exchange model
Receiver role A08 Balance responsible party
Domain
Any known area from the Harmonised role model cowering the
areas within the time series level of the document, e.g. Market
balance area (Elspot area), National Area, etc
Subject party Not used
Subject role Not used
Classification type A01 Detail type
A02 Summary type
Time series
Business Type A01 Production
A04 Consumption
Direction
Not used
Product
8716867000016 Active power
8716867000030 Active energy
Connecting area Not used
Resource object Only used for Classification type = A01, i.e. Station group,
regulation object
Resource provider Not used
Acquiring area Not used
Capacity contract Not used
type
Capacity agreement Not used
identification
In area
Used for all Business types, except consumption schedules, i.e.
Market balance area
Out area
Only used for consumption schedules, i.e. Market balance area
Business type Not used
characteristics
Table 12: Usage of Resource Schedule Confirmation Report
8.2.2.2 Business type dependencies
Business
type
Name
Area
In Out
A01 Production M
A04 Consumption M
Table 13: Dependency matrix for Resource Schedule Confirmation Report
8.2.2.3 Required changes to ERRP Resource Schedule Confirmation Report
Resource Schedule Confirmation Report class:
Change the cardinality of DocumentVersion to optional, [0..1]. The DocumentVersion will not be
used in the Nordic countries.
Add the following attributes need in the Nordic countries:
o ClassificationType
Page: 47

Nordic TSO schedule document exchange model
9 BUSINESS RULES
9.1 Schedule document in the Nordic countries
The following business rules apply to the Transfer capacity document in the Nordic countries:
TBD
Rules taken from the NOIS documentation:
TBD
9.2 Balance Responsible Party definition
The term Balance Responsible Party is used throughout this implementation guide and has two meanings:
1. It identifies a Legal entity that has a contract within a Market Balance Area (as is defined in the Role
Model).
2. It identifies the entity that a Balance Responsible Party must ensure is in balance in the scheduling
system.
In general in the schedule document the first definition is used in the document header and the second
definition is used in the time series header. These headers are defined elsewhere in this document. Local
market rules use these definitions with different terms. The following examples will help clarify these
definitions:
Definition 1 will generally correspond to the identification of the entity behind the codes used in the
“Sender Identification” attribute in the document header, for example:
o A Balance Responsible Party.
o A third party responsible for the transmission of schedules on behalf of a Balance
Responsible Party.
Definition 2 will generally correspond to the identification of the entities behind the codes used in
the “In Party” and “Out Party” attributes in the time series header.
9.3 General ground rules
The process flow assumes that a certain number of basic rules are respected. This does not include the
specific rules that have been defined in an interchange agreement. These basic rules are:
1. The last valid schedule document received before cut-off time is the valid schedule.
2. A time series shall be sent for each unique combination of the product, business type, object
aggregation, in area, out area, metering point identification, in party, out party, capacity contract type
and capacity agreement identification.
3. Resending of schedules:
Denmark: All time series in a document must be sent in all retransmitted documents. If a Market
schedule is left out, it is interpreted as the time series will be deleted. If an Operational
schedule is left out the document is rejected.
Finland: TBD
Norway: If changes to a time series, it is enough to resend the changed time series. However, in the
case of errors, the whole document (all time series in a document) will be rejected. There
shall always be a whole day-and-night in a schedule.
Sweden: If changes to a time series, it is enough to resend the changed observations. In case of
errors only the observations in error are rejected.
4. All version numbers shall be positive integer values and leading zeros shall be suppressed.
5. All scheduling documents received shall have an acknowledgement (acceptance, rejection or errors).
6. All the time series information that has been validated in phase 1 (validation at document level) for
formal correctness may be used to balance their complementary time series as soon as these become
available.
7. All the times related to energy products in the documents are expressed in Coordinated Universal
Time (the acronym of which is UTC) in compliance with ISO 8601. This is restricted to YYYY-
MM-DDTHH:MMZ in order to remain in conformity with XML schema requirements.
Page: 48

Nordic TSO schedule document exchange model
8. All the time intervals in the documents are expressed in compliance with ISO 8601 This is restricted
to YYYY-MM-DDTHH:MMZ/YYYY-MMDDTHH:MMZ. The time interval has an inclusive start
time and an exclusive end time and is expressed in minutes (i.e. 00:00Z to 00:00Z is exactly a 24
hour period).
9. The time interval defined in the period class shall always be a multiple of its resolution.
10. For a schedule document the time interval of a period class shall always be equal to the Schedule
time interval.
11. Negative quantities for a time series are only permitted for certain categories of time series.
12. An Operational schedule cannot be cancelled or deleted. However it is possible to send zero-value
schedules.
13. It is preferred that the quantity for a Balance responsible time series in a day-ahead and an intraday
schedule is given in power units’ as the average value over the time interval, i.e. MW (code MAW).
If the quantity time interval does not correspond to a multiple of 60 minute intervals, converting
average power to energy will often result in rounding errors. If this is the case, it is recommended
that energy units of measure are used.
14. Whenever a coded value within a document is associated with a coding scheme, the coding scheme
must always be supplied. The coding scheme is an independent attribute with a size of 3
alphanumeric characters.
Page: 49

Nordic TSO schedule document exchange model
Appendix A AN EXAMPLE OF TECHNICAL IMPLEMENTATION
The XML document shown below is an example of how a Nordic Operational schedule document may look
like with the modifications specified earlier in this document for the ENTSO-E Planned Resource Schedule
Document.
:::::
Page: 50