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) |
|
2020-02-06 |
Version 1 |
|
2020-02-13 |
|
|
2020-03-02 |
|
|
20-05-12 |
|
|
2020-10-08 |
|
|
2021-01-12 |
|
|
2021-04-13 |
|
|
2021-11-08 |
|
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
|
NCC - Imbalance Forecast
|
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.
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.
|
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:
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 |
|
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.
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. 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/] |
||
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. |
|||
++ |
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. 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/] |
||
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. |
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.
|
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). |
|||
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: |
||||
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.
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 |
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 |
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 |
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. |
|
Each 3rd minute |
PT10S |
Last 6 minutes |
These messages ensure that most corrections are received while keeping the messages short. |
||
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. |
||
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 |
Each 5 minute |
PT5M |
next 2 hours |
||
TR-1 |
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 |
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 |
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