ACE Open Loop and Imbalance forecast

Change Log

Date Version Comments

2019-12-6

Version 0.1 - First draft version presented the Reference Group Meeting (Nordic)

Generally agree on the concept. Some small changes to be done before document is approved

2020-01-17

Version 0.2 Second draft version to be presented the Reference Group Meeting (Nordic)

  • ACE OL Point Value and ACE OL Historic is now based on its own ACEOL_MarketDocument and not Energy_Prognosis_MarketDocument.

  • Since Quality is a business requirement for ACE OL Point Value and ACE OL Historic messages, they are now based on ACEOL_MarketDocument.

  • Additional description has been added to section " ENTSO-E CIM - Codelist QualityTypes" as a guidance to implement quality for ACE OL Point Value and ACE OL Historic messages.

  • Section "ENTSO-E CIM - Codelist BusinessType" is replaced by section Messages implementation and codes"

  • Updated table "Messages implementation and codes" with a column for process types.

2020-02-06

Version 1

  • Got assigned codes for process-, message-, business-types from NMEG. Section "Messages implementation and codes" is update with new values.

  • Updated table for ACE OL Point Value and ACE OL Historic according to new codes and recommendations. See the usage of pointValue_DateAndOrTime.dateTime for the ACE OL Point Value.

  • New XSD for ACEOL_MarketDocument is ready.

  • Imbalance table updated with correct sequence.

  • Included definition of ACE Open Loop done by the functional working group.

2020-02-13

  • Imbalance table had Incorrect description for resolution, now it is according business requirements for Imbalance. with resolution PT5M.

  • Updated imbalance table with default values for required fields and added more information to elements.

2020-03-02

  • Added a section Data types.

  • Updated section Curve types with link to ETNSO-E’s documentation.

  • Receiver.mRID default value for NAP is 50V000000000241J

20-05-12

  • Version 0.2. of ACE OL XSD is ready in new repo. Supporting optional time interval (period.timeInterval), to be used with ACE OL Historic values.

2020-10-08

  • Added own requirements section for all message in a table format.

  • Renamed all Imbalance prognosis to Imbalance Forecast.

2021-01-12

  • Updated and restructured parts to appendices.

2021-04-13

  • Updated xsd for Limits, iec62325-451-2-schedule_v5_2.xsd. Version reference 5.1 to 5.2.

2021-11-08

1. Area Control Error Open Loop (ACE OL) and Imbalance forecast

2. Introduction

It has been decided to design a logical prototyping of how messages should be exchanged between Nordics Common and the TSOs. The message exchanges that are to be modelled as part of the prototype are:

  • ACE Open Loop (ACE OL) Presented in NCC

  • Imbalance Forecast presented in NCC

NCC - ACE OL

1c79d9ac8f1181bc8dab47f139bc1c5a

NCC - Imbalance Forecast

ea09149cf8b3f78f71f0f2f865933a8a

3. Definition of ACE Open Loop (ACE OL)

ACE Open Loop (ACE OL)

ACE OL: ACE Open Loop (ACE OL) is the real-time imbalance of an area in the power system without automatic Frequency Restoration Reserve(aFRR) and manual Frequency Restoration Reserves(mFRR). ACE OL is the imbalance before any operator balancing actions. The imbalance prognosis is the prognosis of ACE OL.

ACE : Area Control Error (ACE) is the real-time difference between scheduled and actual electrical flow in and out of an area in the power grid, taking frequency bias into account. ACE, also named ACE Closed Loop, is the remaining imbalance after all operator balancing actions.

General calculation methodology for ACE OL:

ACE OL = Measured flow - Planned flow - Total regulations
  • The Measured flow is the sum of the measured flow on all interconnectors to an area.

    • The measured flow on one interconnector is the sum of the measured flow on all lines between two bidding zones measured in an agreed reference point.

    • Reference point should be defined as one, or the aggregation of more, physical points in the system. For the connection between DK2-SE4 one physical point is in Sweden and one in Denmark. Points should always be defined in a location where there are measurements, not "in the middle of" , "at the seabed" or similar.

  • Planned flow = Power Plan Trade + Other agreed flow.

    • Power plan trade is the ramped power plan resulting from the Day ahead and intraday market in an agreed reference point.

    • Other agreed flow includes all other scheduled flow between bidding zones that is agreed before the mFRR balancing time frame.

      • Loop transit product 1…n

      • Agreed Supportive Power product 1..n

      • Planned period shift adjustments ("Produksjonsglatting").

  • Total regulations = K*∆f + aFRR + mFRR + other balancing activation – exchanged regulations to other synchronous areas.

    • K*∆f is the frequency response of each area.

      • K[MW/Hz] = planned FCR-N*10 * self-regulation.

        • Planned FCR-N in MW.

        • Self regulation is the response from frequency dependent loads. This could be added to the FCR-N volume to obtain the total K-factor. It should be set in a coordinated way for all TSOs.

      • ∆f is the difference between the target frequency for FCR and the measured frequency.

        • Target frequency for the FCR activation is always 50,00Hz, even if the TSO target frequency can sometimes deviate in relation to time error correction.

        • Measured frequency is the instantaneous frequency value measured per LFC area.

    • aFRR is the amount of aFRR activated within the bidding zone. aFRR setpoint can be used as an estimate if activated volume is not available.

    • mFRR is the amount of mFRR activated within the bidding zone for the Nordic mFRR market.

      • mFRR activated in from the local systems shall be estimated as best as possible to match the activated power. The agreed mFRR activation time can be used as an estimate..

      • mFRR activated by the AOF shall be included in the calculation with the standard product profile.

    • Other balancing activation.

      • EPC – Emergency Power Control.

      • Period shift activation.

        • Kvartersflytting performed by Statnett.

        • Kvartsaffär performed by Svk and Fingrid.

      • FFR – Fast Frequency Reserve activation.

      • LFSM – limited frequency sensitivity mode.

      • "Effektreserv".

      • "Størningsreserv".

    • Exchanged balancing regulation to other synchronous areas.

      • Balancing exchanged between DK1 and the Nordic synchronous area.

        • Activated mFRR balancing exchanged between DK1 and DK2, SE3 or NO2.

        • Netting exchanged between DK1 and DK2/NO2.

        • aFRR exchanged between NO2 and DK1 (before 31.12.2019).

          • aFRR exchanged between DK1 and DK2.

        • Netting exchange through IGCC.

The planned and measured flow shall be calculated for interconnectors within the synchronous system(s). "Exchanged regulation" is calculated for DC-lines within the Nordic balancing market area. See also the figure below.

Information on flows shall be exchanged for all interconnectors, both within and out of our areas.

The map does not include the HVDC to Kriegers Flak or the special case of Bornholm.

aceol memo final

3.1. ENTSO-E definition

Calculation of ACE OL

In previously NBM work of implementing the ACE OL, we agreed on a definition for ACE OL.

In this specification we did not include all details. We have selected the ENTSO-E’s detailed definition as a source for how to calculate and it contains detailed specification of what is expected to be a positive value and other details ACE OL should contain.

From Article 17.1.h.

Specification of calculation - ACE OL

The error D = MV - (SV + AR) + BEx

Definitions

Additional Notes

D = imbalance volume

MV = sum of measured flows over all interconnectors

SV = sum of scheduled flows over all interconnectors. It should include all planned exchanges, hence also balancing energy exchanges. HVDC ramping should not be included.

AR = activated reserves within a control area/block. Calculation of AR may be based upon volumes requested for activation by TSO when metered volumes, as actually delivered by the BSP(s), are not known to the TSO by the submission deadline.

AR = RR + mFRR + aFRR + IN - kΔf

BEx = TSO-TSO energy exchange due to balancing and/or other purposes (e.g. emergency energy delivery, redispatching)

IN = Imbalance Netting

kΔf = frequency bias factor * frequency deviation = estimated FCR activation

AR>0 means net up regulation

AR<0 means net down regulation

D>0 means surplus

D<0 means deficit

MV>0, SV>0 means export direction

MV<0, SV<0 means import direction

BEx>0 means that TSO has a surplus of balancing energy compared to its local needs

BEx<0 means that TSO has a deficit of balancing energy compared to its local needs

With reference to GL EB article 54.6, deficit is equivalent to negative imbalance while excess is equivalent to positive imbalance.

Note: By default data shall be published by imbalance area, which in the majority of cases coincide with scheduling area. Imbalance area may differ from scheduling area as foreseen under EB GL article 54.2

4. Deliverables

This section and drawings are based on asynchronous flows. Message semantics are based upon CIM - standards and can be used regardless of a synchronous/asynchronous message flow.

This is the first of a series of message flows, and content may change/expand since this is the first iteration of a small deliverable (ACE OL and ACE OL Imbalance prognosis) in a bigger scope.

Information that is to be shared between all the Nordic TSOs and/or is to be sent to a Common application, are published to Nordic Communication HUB (referred to as "Common"). The local TSOs are responsible the distribution of messages that are to be sent to several external parties (all Nordic TSO and Common Nordic).

The following generic diagram shows the flow of data produced by business application A in TSO 1 that is to be distributed to all TSOs (shown as TSO 2 in the diagram) and the Common application X.

Based on the message type and the "service", the data is sent to Nordic Common, who will know where to distribute the message.

|6facba3d9414ca726d86f9825a6f39b7

5. Message Parts

As a result of work done with deliverable B’s business requirements, it has been decided to divide the ACE Open Loop into three message parts, ACE OL Point value, ACE OL Historic message and ACE OL Limits messages.

The prototype will also include another message, Imbalance Forecast.

All messages are based on a semantic data model and do not necessarily provide guidance on which syntax / technology to use.

  • ACE OL Point value is designed to minimize message size to meet the 10-second resolution (AO-BR-2) and data in real time (AO-BR-3) requirements and consequently to not include a large overhead of information that need to be processed and transported. To support a message with little overhead and the business quality requirement it has been made a new document "ACEOL_MarketDocument" that this message is based on.

  • ACE OL Historic is made to meet the requirements to obtain historical data (AO-BR-4 and AO-BR-5). This message is based on "ACEOL_MarketDocument".

  • ACE OL Limits is made to meet the requirements Limits (AO-BR-6). This message is based on "Schedule_MarketDocument".

  • Imbalance Forecast is based on "EnergyPrognosis_MarketDocument".

This is the selected message parts and how they are exchanged:

4cee1da095f3702850c98f65705e1bd0

6. ACE Open Loop

The requirements for ACE OL can be mapped to a component in the diagram below to show responsibility for fulfilling the requirement. As can be seen in the diagram there needs to be two message types to support the business requirements:

  • ACE OL Point value - Publishes the current ACE OL value for a bidding area to be displayed in the NCC.

  • ACE OL Historic - Publishes historic ACE OL values for a time-period. This will also include any corrected values.

Also, another message is needed to support the ad-hoc need to set some limits:

  • ACE OL Limits - Publishes the current limits that can be set in the system

Show ACE OL requirements

Nr Requirements Value Description/comm Priority

AO-BR-1

Aggregation level

Bidding zone

The value is given in MW for each bidding zone.

A

AO-BR-2

Maximum resolution

10 sec

Up to TSO if the 10 sec value is a value point in time or an average of a finer resolution

A

AO-BR-3

Data in real time

< 30 sec

The time from real time to presentation in NCC.

A

AO-BR-4

Historic data

3 hours

Must see ACE OL for the past X hours. Frequent re-sending for the last hour to be sure that updated values are exchanged

A

AO-BR-5

Correction of historic data

> one week

Must be able to get historic data resent from one week back. E.g if one TSO has been off-line for several hours.

A

AO-BR-6

Limits

Upper and lower limits in MW

In case limits will be dynamic it should be possible to include them in each message. Alert state, emergency state or other for visual presentation (situation awareness). E.g. Alert state for one zone +480 and -230 MW

B

|1ef191fdd8ac86093d4638706cfa571a

Each TSO is responsible for publishing the ACE OL Point value message according to requirements AO-BR1 and AO-BR2. The ACE OL Point value message is to be distributed to all TSOs so that it can be presented in the NCC (AO-BR3).

The ACE OL Point value message model is based on message type "ACEOL_MarketDocument" to support the quality attribute and a minimal overhead (and therefore not too performance consuming), see ref. model:

6.1. ACE OL Point Value

This message will provide real-time values of ACE OL to be displayed in NCC, it will be updated frequently and updates within minimum 10 seconds.

Due to frequent updating, minimal overhead and the requirement to have quality support, it is based on new document, "ACEOL_MarketDocument".

6.1.1. ACE OL Point value - Message Table

To be complete it must satisfy the "ACEOL_MarketDocument".

Version: 1.0 Message: ACE OL Point value Document type: ACEOL_MarketDocument Last updated date: 01.01.2020

No

Level

Name

CIM

Value

Type

Description

Additional Description

Mandatory

1

+

ID

mRID

ID_String

The unique identification of the document being exchanged within a business process flow.

UUID

2

+

Message Type

type

Z35

MessageKind_String

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

Fixed ID for this message type. Value Z35 is a temporarily assigned value from NMEG.

3

Process Type

process.processType

Z12

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

--- The Process associated with an electronic document header that is valid for the whole document.

4

+

From Sender

sender_MarketParticipant.mRID

A01

PartyID_String

The identification of a party in the energy market.

Sender/Originator (In this case TSO) of Message.

Use CodingScheme="A01" for eic codes and use this registry to lookup correct code: https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/]

5

+

Timestamp

createdDateTime

ESMP_DateTime

The date and time of the creation of the document.

Timestamp when ACE is produced.

++

TimeSeries

Node

A set of time-ordered quantities being exchanged.

Repeat max 1 for each Bidding Zone.

6

++

Time series reference

mRID

ID_String

A unique identification of the time series.

7

++

Business Type

businessType

Z77

BusinessKind_String

The identification of the nature of the time series.

Z77 - ACE OL (Area Control Error Open Loop)

8

++

Point Value Curve

curveType

A02

CurveType_String

The identification of the coded representation of the type of curve being described.

A02 - Point

9

++

Bidding Zone

domain.mRID

AreaID_String

The unique identification of the domain.

--- The domain associated with a TimeSeries that provides the identification of the area concerned by the prognosis.

Bidding zone for ACE OL.

Use CodingScheme="A01" for eic codes and use this registry to lookup correct code: https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/]

10

++

Point Value Date Time

pointValue_DateAndOrTime.dateTime

DateTime

Date and time as per ISO 8601 YYYY-MM-DDThh:mm:ss.sssZ.

--- A date and/or time associated with a TimeSeries.

Solves high resolution series.

11

++

ACE OL Value

quantity.quantity

Decimal

The principal quantity identified for a point.

Value of ACE OL. Unit type: MW. TR - 02: Only 1 value for Document type Z35 - ACE OL Point Value.

12

++

Quality

quantity.quality

Quality_String

The quality of the information being provided. This quality may be estimated, not available, as provided, etc..

See additional suggestion for QualityTypes table in section Code lists. E.g. A04 - As provided.

6.1.2. ACE OL Point value - Volume

According to AO-BR-2 the maximum resolution time is 10 sec. This means that each TSO will distribute at least 6 ACE OL Point value messages per minute. These messages will be distributed to 3 TSOs and Nordic common which means that means that message volume for ACE OL Point Value is 6*4 = 24 message/minute (which equals 0,4 msg/sec) will be generated per TSO. There are 4 TSOs that produces ACE OL Point Values messages giving a total for 96 messages/minute (which equals 1,6 msg/sec). It is assumed that peak throughput is at least 4 times average throughput since all TSOs will transfer to the other TSOs and common Nordic at the same time.

ACE OL Point value - Need

As of now we think there is a need to have a separate message for the ACE OL Point value. The reason for its own message it to reduce the throughput for EDX/ECP. Testing and other experiences might make this message obsolete; the ACE OL historic message might be used relatively frequent to serve this purpose.

6.2. ACE OL Historic

ACE OL Historic is all old ACE OL values within a selected period. To be used for different purposes.

Each TSO is responsible for sending an ACE OL Historic message at predefined intervals that includes all ACE OL values recorded the previous 3 hours (AO-BR4). If ACE OL values have been corrected, the ACE OL Historic message will only have the corrected value for that time period and not the original value that was sent in the ACE OL message. It is assumed that correction to ACE OL point values will primarily occur shortly (5-minute time frame) after they have been produced. To ensure that all TSOs show correct ACE OL values in the "near historic" these corrections need to be sent often. The following exchange pattern is therefore proposed:

  • Short term - Historic ACE OL values for the previous 6 minutes are sent every 3 minutes to all TSOs. These messages ensure that most corrections are received while keeping the messages short.

  • Long term - Historic ACE OL values for the previous 3 hours are sent every 2 hours to all TSOs. These messages ensure that any corrections that are made after the initial 5 minutes are received. These messages are longer but are sent less frequently.

  • Corrections - Historic ACE OL values that are corrected after 3 hours need to be sent in a separate ACE OL Historic messages. The implementation strategy in the message producer will dictate how often these messages are send and for which time period. To avoid heavy message load, it is assumed that these messages will be sent seldom.

The rules for how often and for which time periods the ACE OL Historic messages are produced should be configurable and should be based on experience on when corrections occur and the need to have correct ACE OL values available for the TSOs. The values given above are only used to calculate the expected volumes of ACE OL Historic messages (see below)

The proposed data exchange assumes that each TSO stores historic data from the other TSOs locally. There is also an assumption that each ACE OL Historic message has guaranteed "at least once" delivery. This implies that there might be a need of an "Acknowledgement_MarketDocument" messages for ACE OL Historic messages that the receivers send once they have persisted the information. There can be a need for functionality in the message producers to resend ACE OL Historic messages to subscribers where an "Acknowledgement_MarketDocument" message is not received within an acceptable timeout period.

Each ACE OL Historic message is a separate message and does not have a reference to the original message if corrections are applied. This gives the message producer more flexibility in how often and how many time slots are sent in a message. It is assumed that previously received ACE OL values for a time slot will be overwritten when new values are received. This requires that messages are processed in the same order that they are produced otherwise we risk overwriting values with "outdated" data if messages are processed out of order.

6.2.1. ACE OL Historic - Message Table

This table shows selected values used in connection with ACE OL Historic, to be complete it must satisfy the "ACEOL_MarketDocument".

Version: 1.1 Message: ACE OL Historic Document type: ACEOL_MarketDocument Last updated date: 01.01.2020

No

Level

Name

CIM

Value

Type

Description

Additional Description

Mandatory

1

+

ID

mRID

ID_String

The unique identification of the document being exchanged within a business process flow.

UUID

2

+

Message Type

type

Z35

MessageKind_String

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

Fixed ID for this message type. Value Z35 is a temporarily assigned value from NMEG.

3

Process Type

process.processType

Z13

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

--- The Process associated with an electronic document header that is valid for the whole document.

4

+

From Sender

sender_MarketParticipant.mRID

A01

PartyID_String

The identification of a party in the energy market.

Sender/Originator (In this case TSO) of Message.

Use CodingScheme="A01" for eic codes and use this registry to lookup correct code: https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/]

5

+

Timestamp

createdDateTime

ESMP_DateTime

The date and time of the creation of the document.

Timestamp when ACE is produced.

6

+

Period

period.timeInterval

ESMP_DateTimeInterval

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

optional attribute, to be used for faster lookup.

0..]1]

++

TimeSeries

Node

A set of time-ordered quantities being exchanged.

Repeat for each Bidding Zone if needed

7

++

Time series reference

mRID

ID_String

A unique identification of the time series.

8

++

Business Type

businessType

Z77

BusinessKind_String

The identification of the nature of the time series.

Z77 - ACE OL (Area Control Error Open Loop)

9

++

Point Value Curve

curveType

A02

CurveType_String

The identification of the coded representation of the type of curve being described.

A02 - Point

10

++

Bidding Zone

domain.mRID

AreaID_String

The unique identification of the domain.

--- The domain associated with a TimeSeries that provides the identification of the area concerned by the prognosis.

Bidding zone for ACE OL.

Use CodingScheme="A01" for eic codes and use this registry to lookup correct code: https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/]

+

Period

Node

The identification of the period of time corresponding to a given time interval and resolution.

11

+

Resolution

resolution

PT10S

Duration

The definition of the number of units of time that compose an individual step within a period.

Resolution PT10S is given by AO-BR-02

12

+

Time Interval

timeInterval

ESMP_DateTimeInterval

The start and end time of the period.

13

Point

Node

The identification of the values being addressed within a specific interval of time.

14

Position

position

A sequential value representing the relative position within a given time interval.

15

ACE OL Value

quantity

Decimal

The principal quantity identified for a point.

Value of ACE OL. Unit type: MW.

16

Quality

quality

Quality_String

The quality of the information being provided. This quality may be estimated, not available, as provided, etc..

See additional suggestion for QualityTypes table in section Code lists.

6.2.2. ACE OL Historic - Volume

It is that short term messages are sent every 3 minutes while long term messages are sent every 2 hours. This gives a message load of 20,5 messages per hour which will be sent to 3 TSO and Nordic common meaning that each TSO generates 82 messages per hour. For the 4 TSO this gives an average throughput of 82*4 = 168 messages/hour (which is 2,8 msg/min = 0.046 msg/sec). It is assumed that peak throughput is at least 4 times average throughput since all TSOs will transfer to the other TSOs and common Nordic at the same time.

ACE OL Historic - Need

Historic message is used for time series of 6 minutes, 3 hours (AO-BR-04) and 1 week (AO-BR-05).

Time series and resolution will be adjusted as result of later work.

7. ACE OL Limits

In case limits will be dynamic it should be possible to include them in a message. Used for visualization when ACE OL exceed or goes below certain values within a bidding zone. .

Limits are given by Time Series for each Bidding Zone within a TSO area of responsibility.

7.1. ACE OL Limits - Message table

For ACE OL Limits purpose, these values are necessary. To fulfil a complete document, you must follow ENTSO-E’s guidelines provided by the Schedule_MarketDocument.

Version: 1.0 Message: ACE OL Limits Document type: Schedule_MarketDocument Last updated date: 01.01.2020

No

Level

Name

CIM

Value

Type

Description

Additional Description

Mandatory

1

+

ID

mRID

ID_String

UUID

+

Message Type

type

Z36

MessageKind_String

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

Use Z36 for ACE OL Limits.

In case limits will be dynamic it should be possible to include them in each message. Alert state, emergency state or other for visual presentation (situation awareness). E.g. Alert state for one zone +480 and -230 MW

2

+

Process Type

process.processType

Z12

NMEG: The process of exchanging real-time ACE OL values

Z12= ACE OL real-time

3

+

From Sender

sender_MarketParticipant.mRID

PartyID_String

The identification of a party in the energy market.

Sender/Originator (In this case TSO) of Message.

3

+

Date Time Interval

schedule_Time_Period.timeInterval.timeInterval

ESMP_DateTimeInterval

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

--- This information provides the start and end date and time of the schedule time interval.

All time intervals for the time series in the document shall be within the total time interval for the schedule.
The receiver will discard any time intervals outside the schedule period.

++

TimeSeries

Node

A set of time-ordered quantities being exchanged.

5

++

Time Series ID

mRID

ID_String

A unique identification of the time series.

6

++

Warning Type

businessType

Z78 Upper Alert

Z79 Upper Emergency

Z80 Lower Alert

Z81 Lower Emergency

Z82 Upper Warning

Z83 Lower Warning

BusinessKind_String

The identification of the nature of the time series.

NMEG:

A time series concerning the lower limit before a warning is raised.

Alert state, emergency state or other for visual presentation (situation awareness). E.g. Alert state for one zone +480 and -230 MW.

UpperAlert, LowerAlert, UpperEmergency, LowerEmergency, UpperOther, LowerOther.

7

++

Bidding Zone

in_Domain.mRID

AreaID_String

The unique identification of the domain.

--- The area where the product is being delivered.

Limits are given by Time Series for each Bidding Zone within a TSO area of responsibility.

8

++

Curve Type

curveType

A03

CurveType_String

The identification of the coded representation of the type of curve being described.

A03 - see CurveType list in section Code lists.

+

Series_Period

Node

The identification of the period of time corresponding to a given time interval and resolution.

9

+

Resolution

resolution

Duration

The definition of the number of units of time that compose an individual step within a period.

Runs only on time for each interval. PT15M or PT1H

Point

Node

The identification of the values being addressed within a specific interval of time.

10

Position

position

Position_Integer

A sequential value representing the relative position within a given time interval.

11

Max / min ACE OL Value

quantity

Decimal

The principal quantity identified for a point.

Max / Min values for ACE OL.

7.1.1. ACE OL Limits - Volume

The volume is estimated to be very low and can be negligible/insignificant.

ACE OL Limits - Need

There is a need to be able to send updated values for ACE OL limits, but the need is mostly infrequent. It is said it could range from e.g. 3 months down to every 15 minutes.

8. Imbalance Forecast

This is the Imbalance or equivalent to the forecast (Prognosis) of the ACE OL value.

8.1. Imbalance Forecast distribution

The business requirements for the distribution of Imbalance Forecast can be mapped to one or more of the components in the generic diagram to show responsibility for fulfilling the business requirement. The Imbalance Forecast message is used to distribute imbalance Forecast for the various bidding zones in a TSO to the other TSOs.

|943ec2db21946666664bc876962b798a

Each TSO is responsible for calculating Imbalance Forecast for the next 2 hours (IP-BR7) every 5 minutes (IP-BR5) for all bidding zones that the TSO is responsible for (IP-BR1). The Imbalance Forecast message should include a time series for each prognosis type (IP-BR3) (machine learning, planning table etc..) with an associated quality indicator for each time slot (IP-BR2).  It is assumed that each TSO that receives an Imbalance Forecast message stores the data so that analysis of completed prognosis can be performed (IP-BR8).

Using IP-BR5, IP-BR6 and IP-BR7 it is possible to calculate the message volume per hour for each bidding zone.

8.2. Imbalance Forecast - Message table

For Imbalance Forecast purpose, these values are necessary. To fulfill a complete document, you must follow ENTSO-E’s guidelines provided by the "https://docstore.entsoe.eu/Documents/EDI/Library/cim_based/Weather_IG_V1r2.pdf[EnergyPrognosis_MarketDocument]".

Version: 1.0 Message: _Imbalance Forecast Document type: EnergyPrognosis_MarketDocument Last updated date: 01.01.2020

No

Level

Name

CIM

Value

Type

Description

Additional Description

Mandatory

1

+

ID

mRID

ID_String

The unique identification of the document being exchanged within a business process flow.

UUID or a Unique value

2

+

Message Type

type

B39

MessageKind_String

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

B39 =Imbalance Forecast document.

3

+

From Sender

sender_MarketParticipant.mRID

PartyID_String

The identification of a party in the energy market.

Sender/Originator (In this case TSO) of Message. Use CodingScheme="A01" for eic codes and use this registry to lookup correct code: https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/]]

4

+

sender_MarketParticipant.marketRole.type

A04

MarketRoleKind_String

The identification of the role played by a market player.

Not in use for this purpose. Required field.

5

+

receiver_MarketParticipant.mRID

PartyID_String

The identification of a party in the energy market.

Not in use for this purpose. It is a required field therefore use value

50V000000000241J

(NAP).
CodingScheme="A01".

6

+

receiver_MarketParticipant.marketRole.type

A33

MarketRoleKind_String

The identification of the role played by a market player.

Not in use for this purpose. It is a required field use value A33 = Information receiver.

7

+

Timestamp

createdDateTime

ESMP_DateTime

The date and time of the creation of the document.

Timestamp when Imbalance is produced (original description is when document is created). Expressed in UTC as YYYY-MM-DDThh:mm:ssZ.

8

+

Time interval

time_Period.timeInterval

ESMP_DateTimeInterval

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

This datatype enables to express the start date and time, and the end date and time of a time interval with a specific pattern. This pattern is the YYYY-MM-DDThh:mmZ.

According to IP-BR-7, the period is set to 2 hours.

++

TimeSeries

Node

9

++

Time series reference

mRID

ID_String

A unique identification of the time series.

10

++

Business Type

businessType

C32

BusinessKind_String

The identification of the nature of the time series.

C32 = Area imbalance.

11

++

Bidding Zone

domain.mRID

A04

AreaID_String

The unique identification of the domain.

Bidding zone for Imbalance.

Use CodingScheme="A01" for eic codes and use this registry to lookup correct code: https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/https://www.entsoe.eu/data/energy-identification-codes-eic/eic-approved-codes/]]

12

++

mktPSRType.psrType

B20

PsrType_String

The coded type of a power system resource.

--- The identification of the type of resource associated with a TimeSeries.

Not in use for this purpose. Required field use B20 = Other.

13

++

measurement_Unit.name

MAW

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

MAW = megawatt

14

++

Curve Type

curveType

A01

CurveType_String

The identification of the coded representation of the type of curve being described.

A01=Sequential fixed size block. See also section Curve Types for more information.

So given that we have 5 minutes resolution we will have 24 points covering each a fixed period of 5 minutes within time_Period.timeInterval. E.g. if clock is 1400, the first values is given for time 1400, and the last point is given for 1555 and it will last for the next 5 minutes until 1600.

+

Series_Period

Node

15

+

Resolution

resolution

PT5M

Duration

The definition of the number of units of time that compose an individual step within a period.

Resolution is PT5M and given by IP-BR-04

16

+

Time interval

timeInterval

ESMP_DateTimeInterval

The start and end time of the period.

Point

Node

17

position

position

Position_Integer

A sequential value representing the relative position within a given time interval.

18

Quality

quality

Quality_String

The quality of an object. We need to define own values. Entsoe: The quality of the information being provided. This quality may be estimated, not available, as provided, etc..

See code list section.

19

Imbalance Value

quantity

Decimal

The principal quantity identified for a point.

Value of Imbalance Forecast. Unit type: MW.

+

UncertaintyPercentage_Quantity

Node

The quantity attribute provides the information relative to the percentage quality of the prognosis quantity.

The estimated uncertainty in the Imbalance Forecast. Expressed as a range of uncertainty around the Imbalance Value.

The object expresses the range of uncertainty in the following way:
"It is forecasted to be x% likely that the actual value will be between y MW and z MW"
As a concrete example:
"It is estimated to be 50% likely that the actual value will be between 800 MW and 1100 MW"
There can be multiple of these per Imbalance Value, see the separate example for multiple uncertainty ranges

20

+

Percentage Value

quantity

90 or 50

Decimal

The quantity value. The percentage of uncertainty of the provided quantity.

The uncertainty range around the Imbalance Value, expressed as a percentage (0 – 100).

Example: it is estimated to be 50% likely that the actual value will be between 800 MW and 1100 MW". Then the value = 50.

21

+

Min. percentage Probability Value

minimumPercentage_Quantity.quantity

Decimal

The quantity value.

--- The minimum uncertainity percentage.

The lower bound of the uncertainty range, expressed as a quantity (unit type: MW).

Example: it is estimated to be 50% likely that the actual value will be between 800 MW and 1100 MW". Then the value = 800.

22

+

Max. percentage Probability Value

maximumPercentage_Quantity.quantity

Decimal

The quantity value.

--- The minimum uncertainity percentage.

The upper bound of the uncertainty range, expressed as a quantity (unit type: MW).

Example: it is estimated to be 50% likely that the actual value will be between 800 MW and 1100 MW". Then the value = 1100.

8.3. Imbalance Forecast - Volume

According to IP-BR-5 and IP-BR-6 each TSO should send an Imbalance message with data for 2 hours with a 5 minute interval (24 values) every 5 minutes. This give a message load of 12 messages per hour which will be sent to 3 TSO and Nordic common meaning that each TSO generates 48 messages per hour. For the 4 TSO this gives an average throughput of 48*4 = 192 messages/hour (which is 3,2 msg/min = 0.053 msg/sec). It is assumed that peak throughput is at least 4 times average throughput since all TSOs will transfer to the other TSOs and common Nordic at the same time.

Imbalance Forecast - Need

The imbalance Forecast will be used to determine the mFRR demand per area. The Imbalance Forecast is the prognosis for ACE OL. The Imbalance Forecast should be updated as often as possible, at least every five minutes.

9. Messages implementation and codes

Process Type Description Message Type Description Business Type Description

ACE OL Point Value

Z12 ACE OL real-time

The process of exchanging real-time ACE OL values

Z35 ACE OL

A document to provide Area Control Error Open Loop (ACE OL) values

Z77

ACE OL (Area Control Error Open Loop) for
The Area Control Error Open Loop (ACE OL) is the real-time imbalance of an area in the power system without automatic Frequency Restoration Reserve (aFRR) and manual Frequency Restoration Reserves (mFRR). ACE OL is the imbalance before any operator balancing actions

ACE OL Historic

Z13 ACE OL report

The process of reporting ACE OL values

Z35 ACE OL

A document to provide Area Control Error Open Loop (ACE OL) values

Z77

ACE OL (Area Control Error Open Loop) for
The Area Control Error Open Loop (ACE OL) is the real-time imbalance of an area in the power system without automatic Frequency Restoration Reserve (aFRR) and manual Frequency Restoration Reserves (mFRR). ACE OL is the imbalance before any operator balancing actions

Imbalance Forecast

- not in use -

B39 Imbalance prognosis document

A document to provide the prognosis of energy imbalances for a given period.

C32

Area imbalance - A time series concerning imbalance between planned consumption, production and exchange in an Area.

ACE OL Limit

Z12 ACE OL real-time

The process of exchanging real-time ACE OL values

Z36 Limits

A document specifying limits, such as max. or min. values.

Z78 Upper Alert

A time series concerning the upper limit before an alarm is raised

ACE OL Limit

Z12 ACE OL real-time

The process of exchanging real-time ACE OL values

Z36 Limits

A document specifying limits, such as max. or min. values.

Z79 Upper Emergency

A time series concerning the upper limit before an emergency is raised

ACE OL Limit

Z12 ACE OL real-time

The process of exchanging real-time ACE OL values

Z36 Limits

A document specifying limits, such as max. or min. values.

Z80 Lower Alert

A time series concerning the lower limit before an alarm is raised

ACE OL Limit

Z12 ACE OL real-time

The process of exchanging real-time ACE OL values

Z36 Limits

A document specifying limits, such as max. or min. values.

Z81 Lower Emergency

A time series concerning the lower limit before an emergency is raised

ACE OL Limit

Z12 ACE OL real-time

The process of exchanging real-time ACE OL values

Z36 Limits

A document specifying limits, such as max. or min. values.

Z82 Upper Warning

A time series concerning the upper limit before a warning is raised

ACE OL Limit

Z12 ACE OL real-time

The process of exchanging real-time ACE OL values

Z36 Limits

A document specifying limits, such as max. or min. values.

Z83 Lower Warning

A time series concerning the lower limit before a warning is raised

10. Requirements

This section contain a summary of Business requirements(BR) and technical requirements (TR). IP-prefix is name for Imbalance prognosis and has its origin from FiftyOne. AO-prefix is local for this project, ACE OL.
Future changes will be done here in this document, and IP prefix will be obsolete.

Req.No. Message Sending frequency Resolution Period Comments

Just a summary of above defined requirements

ACE OL Point

The point value for each 10 second.

I.e each 10th second.

None

None

There is a question if this value will be if the value represent the current point value in the 10th second or whether it is an average from the previous 10th second. Eivind Lindeberg Please clarify.

ACE OL Historic

Each 3rd minute

PT10S

Last 6 minutes

These messages ensure that most corrections are received while keeping the messages short.

ACE OL Historic

Each 2 hour

PT10S

Last 3 hours

These messages ensure that any corrections that are made after the initial 5 minutes are received. These messages are longer but are sent less frequently.

ACE OL Historic

Event triggered

P10S

as provided

Corrections : The implementation strategy in the message producer will dictate how often these messages are send and for which time period. To avoid heavy message load, it is assumed that these messages will be sent seldom.

IP-BR-5, IP-BR-6, IP-BR-7

Imbalance Forecast

Each 5 minute

PT5M

next 2 hours

TR-1

ACE OL Point

Not supported

Not Supported

Due to message size optimization to reduce the ECP/communication load it must not include a period but use value and date time attribute in Time Series.

11. Abbreviations

Acronym Term Definition

ACE

Area Control Error

Area Control Error (ACE) is the real-time difference between scheduled and actual electrical flow in and out of an area in the power grid, taking frequency bias into account.  ACE, also named ACE Closed Loop, is the remaining imbalance after all operator balancing actions.

ACE OL

Area Control Error Open Loop

ACE Open Loop (ACE OL) is the real-time imbalance of an area in the power system without automatic Frequency Restoration Reserve(aFRR) and manual Frequency Restoration Reserves(mFRR). ACE OL is the imbalance before any operator balancing actions. The imbalance Forecast is the prognosis of ACE OL.

BRP

Balance Responsible Party

A market participant or its chosen representative responsible for its imbalances

BSP

Balancing Services Provider

A market participant with reserve-providing units or reserve-providing groups able to provide balancing services to TSOs

CIM

Common Information Model

NCC

National Control Center

TSO

Transmission 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. In the Nordic synchronous area, there are four TSOs: Svenska kraftnät, Fingrid, Energinet.dk and Statnett.

Code lists

Some selected tables where changes may be required. These are based on ENTSO-E codelist V67 with new suggestions as given by code ZXX.

ENTSO-E CIM - Codelist QualityTypes:

Code Title Description NBM - clarification of code NBM - presentation in user interface

A01

Adjusted

The contents of the object have been adjusted

To be used for values that have been corrected or adjusted manually.

Corrected value
(may be presented as "good" value)

A02

Not available

The contents of the object are not available

To be used when values cannot be provided, e.g. due to missing inputs.

Missing value

A03

Estimated

The contents of the object are estimated.

To be used for measured values where an estimate is provided instead of the measurement. To be used for calculated values based on complete inputs but when one or more of the inputs are estimated.

Estimated value
(may be presented as "good" value)

A04

As provided

The contents of the object are as provided.

To be used for good/normal values, e.g. calculated values based on complete inputs, forecasts based on complete inputs, and real measured values.

Normal (good/measured) value

A05

Incomplete

The contents of the object are calculated based on incomplete data.

To be used for calculated values when one or more of the inputs are incomplete.

Uncertain value

ENTSO-E CIM - Codelist CurveType:

Included to provide information, no need for change.

Code Title Description

A01

Sequential fixed size block

The curve is made of successive Intervals of time (Blocks) of constant duration (size), where the size of the Blocks is equal to the Resolution of the Period.

A02

Point

The curve is made of successive instants of time (Points).

A03

Variable sized Block

The curve is made of successive Intervals of time (Blocks) of variable duration (size), where the end date and end time of each Block are equal to the start date and start time of the next Interval. For the last Block the end date and end time of the last Interval would be equal to EndDateTime of TimeInterval.

A04

Overlapping breakpoint

The curve is made of successive Intervals of time of variable duration (size), where the end date and end time of each interval are equal to the start date and start time of the next Interval.

A05

Non-overlapping breakpoint

This curve is a restriction of the curve type A04, i.e. overlapping breakpoints. The restriction is that a single Period is allowed.

1. Data types

Following section contain more detailed information about certain data types used in this document.

1.1. Date Time

Date and time are expressed using the standard XML format for date and time: YYYY‑MM‑DDTHH:MM:ssZ, formatted using the universal time standard UTC by adding a 'Z' behind the time - like this: 2018-06-14T22:00:00Z. Where Z is the zone designator for the zero UTC offset.

In this document there are three types of date.

1.1.1. DateAndOrTime

This attribute is used for ACE Open Loop Point Value to support higher resolution than given by ESMP_DateTimeInterval in the timeInterval attribute for the Period.

Cardinality Name Attribute type Description

0..1

date

Date

The date as "YYYY-MM-DD", which conforms with ISO 8601

0..1

time

Time

The time as "hh:mm:ss.sssZ", which conforms with ISO 8601.

0..1

dateTime

DateTime

Date and time as per ISO 8601 YYYY-MM-DDThh:mm:ss.sssZ. This is used for ACE Open Loop Point Value

1.1.2. ESMP_DateTime

Cardinality Name Attribute type Description

1..1

value

DateTime

Expressed in UTC as YYYY-MM-DDThh:mm:ssZ

1.1.3. ESMP_DateTimeInterval

Entso-e definition of ESMP_DateTimeInterval.

Cardinality Name Attribute type Description

1..1

start

YMDHM_DateTime

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

1..1

end

YMDHM_DateTime

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

Daylight saving time

  • In winter the period is from 23:00 UTC to 23:00 UTC

  • In summer the period is from 22:00 UTC to 22:00 UTC

  • On the date of the change from winter to summer time, the period is from 23:00 UTC to 22:00 UTC. This change occurs on the last Sunday in March at 01:00 UTC

  • On the date of the change from summer to winter time, the period is from 22:00 UTC to 23:00 UTC. This change occurs on the last Sunday in October at 01:00 UTC

1.2. mktPSRType

The identification of the type of resource associated with a TimeSeries. This is not in use but required by EnergyPrognosis_MarketDocument model.

Cardinality Name Attribute Description

|Name |Type |value |AssetTypeList

The coded type of a power system resource. Use B20 = Other

1.3. revisionNumber

The identification of the version that distinguishes one evolution of a document from another. The revision number is not used and shall always be equal to '1' [footnote].

Cardinality name Attribute type Description

1..1

revisionNumber

ESMPVersion_String

The revision number is not used and shall always be equal to '1'.

1.4. mRID

The document reference and Time series is given by the mRID, and must be unique and based on UUID.

Cardinality Name Attribute Description

1..1

value

String

A unique identification of the Time Series and the document being exchanged within a business process flow. Use UUID to make it unique.

2. Document identification and revision number

The document identification must be unique over time for the sender in question. Furthermore, the document identification shall be based on UUID. The revision number is not used and shall always be equal to '1'.

2.1. Update principles

In general, a new received document for a given period/area(s) will always completely replace a previous received document. Update of any time series within this period/area(s) is done by sending a new document honouring these rules

  • A new document mRID (document identification)

  • The same revision number (always equal to '1')

  • A newer created date-time

  • The same period/day and domain as for the data being updated