AOF Nordic Libra

1. Introduction

LIBRA is IT platform for the European Balancing Energy market for Replacement Reserves and mFRR. The purpose of the platform is to ensure coupling of national balancing energy market(s) and central procurement of balancing energy.

Nordic LIBRA is customized instance of LIBRA platform which provides Activation Optimisation Function (AOF) of mFRR balancing product to Nordic Region.

2. Business process

Nordic Libra AOF sequence

3. Requirements

Here the requirements are set up for the message exchanges, how often and periods they will cover.

Req.no. Message Object Sending frequency Resolution Period Comments

BR-AOF-1

{message-mfr-bid-AOF}

Event, each 15 min

PT15M

2 hours in advance, each message contain one MTU (15 min)

AOF Nordic Libra can get messages 2 hours in advance, but not more than 2 hours .

3.1. Realization of the business process

functional mfrr nordic aof

4. AOF Nordic Libra - General rules

These are rules that only apply to AOF Nordic Libra and mean that messages ending in <name>AOF follow these rules.

4.1. Input data responsibility

Each TSO is responsible for sending data for their corresponding Control Area(s), i.e. all three defined input messages. This must be repeated for each period (15 min). If values are missing when clearing phase starts a value of zero is used.

For connections between Control Areas (Example NO2-DK1) both responsible TSO should send ATC information.

  • If the information isn’t aligned the lowest value is used.

  • If none of the TSOs sends the information zero is used

  • If only one TSO sends the information

    • Default behavior: this value is used

    • (Alternative behavior: zero is used. This is a configuration for the connection in Nordic Libra)

4.2. Document coverage

A document covers a period of 15 minutes.

4.3. Document identification and revision number

The standard way of handling document identification and revision number is used.

  1. Document 1 with id=AAA and revisionNo=1 is received. All information in document 1 is added to data storage.

  2. Document 2 with id=AAA and revisionNo=2 is received. All information from document 1 is removed and all information from document 2 is added.

  3. Document 3 with id=BBB and revisionNo=1 is received. All information in document 3 is added to data storage.

  4. etc…​..

(Order of documents is irrelevant. If Document 2 was received and stored before Document 1 was received, the information in Document 1 would not be used)

This makes some requirements on the TSOs handling of information and documentId when creating input messages to Nordic Libra for a given period (15 min):

  • A new document (new docId) should not contain information already sent in an existing document.

  • To update a document the same docId is used and the revisionNo is incremented. I.e. the TSO must keep a mapping from the information to the docId, f.ex. 'Offers for SchedulingArea-1' ⇒ ' E5C26231D81CCCC456EC4E537FB018BF'.

  • We suggest making the content of a document a 'natural grouping' to make updating simpler. I.e. if first version contains all offers for 'SchedulingArea-1' it is easier to send the same information for version 2.

4.4. Acknowledgement and error handling

From 'Common_Platform_For_Replacement_Reserves_Implementation_Guide_v1.0.pdf' chapter 5.3.1:

"For each electronic data interchange defined in this document, an acknowledgement document, as defined in IEC 62325-451-1, should be generated either accepting the whole received document or rejecting it completely."

This means that the TSO will receive an acknowledgement for each message sent to Nordic Libra. Corresponding the TSO should send an acknowledgement for each message received from Nordic Libra.

4.5. Input - Offer

4.5.1. Offer identification

Bid_TimeSeries.mRID identifies an offer. It should be a generic id and not contain other information like BSP, power station etc. Nordic Libra validates that the id is unique in a document. We strongly suggest avoiding reuse of the id on other offers in the same auction. It is handled by Nordic Libra, but the result returned to the TSO will be unnecessary complex with multiple offers with the same id.

4.5.2. Specifying offered quantity

Type Bid_TimeSeries.divisible Bid_TimeSeries. Period. Point. minimum_Quantity.quantity Not divisible A02 = Not divisible Not used Partly divisible A01 = Divisible < Point. quantity.quantity Fully divisible A01 = Divisible = 0

4.5.3. Grouping of offers

  • 'Technically Linked bids' are NOT supported by Nordic Libra. The field linkedBidsIdentification in the input is ignored. It can be used by the TSO but does not provide any functionality.

  • Exclusive, multipart and 'conditional linked' are mutually exclusive.

  • Associated multipart and exclusive offers must have the same status.

  • Offers part of the same multipart group can’t have the same price

4.5.4. Conditional linked offers

This functionality is used when the availability of an offer is dependent on the activation result for offers in previous MTUs. The logic implemented in NL is as follows: * An offer can be linked to offers in MTU-1 and MTU-2 using their mRIDs * There can be 3 linked offers in MTU-1 and 3 linked offers in MTU-2 * There are no limitations regarding the type of the linked offers (multipart/exclusive etc) * Direct Activation is not used in NL and it has been decided to limit the conditions that can be used in the linking. Only the first two Conditionalities will be supported: A55: bid in MTU0 becomes unavailable in case an associated bid/bids in MTU-1 or MTU-2 was activated A56: bid in MTU0 becomes unavailable in case an associated bid/bids in MTU-1 or MTU-2 was not activated ** The version of the ReserveBidDocument is updated from v7.1 to v7.2 to use the new structure Linked_BidTimeSeries. Example:

</Period>
<Linked_BidTimeSeries>
	<mRID>12341234124141</mRID>
	<status>
		<value>A55</value>
	</status>
</Linked_BidTimeSeries>
<Linked_BidTimeSeries>
	<mRID>12341234124133</mRID>
	<status>
		<value>A56</value>
	</status>
</Linked_BidTimeSeries>
</Bid_TimeSeries>

  • If the mRID doesn’t exist in MTU-1 or MTU-2 at clearing the offer is considered rejected

4.6. Problem Statement Documents

4.7. Change Log

Ver Changed by Date Changes

1

{author}

2024.05.30

PSD document verified ok and removed status text "Draft".

More details can be found here,Suspend AOF Result.

A short overview of the PSD produced by Nordic Libra. The codes used are as follows:

  • type=A34: Escalation

  • type=A35: Trouble shooting

  • code=B11: Cooperation area problem

  • code=A91: Expected data not received

  • code=B18: failure

TSO rule Result in SuspendAOF Event Time of sending To Type expected_MarketDocument Reason

type

processType

code

example

DK:
FI:
NO:
SE:

NO

A control area is disconnected/ decoupled (planned)

T-50

All

A35

A35

A47

B11

<Reason>
<code>B11</code>
<text>CtrlA|NO has been decoupled for delivery period 2021-08-30T08:15:00Z - 2021-08-30T08:30:00Z (UTC).</text>
</Reason>

DK:
FI:
NO:
SE:

YES

A control area is disconnected/ decoupled on-the-fly

change time

All

A35

A35

A47

B11

<Reason>
<code>B11</code>
<text>CtrlA|NO has been decoupled for delivery period 2021-08-30T09:00:00Z - 2021-08-30T09:15:00Z (UTC).</text>
</Reason>

DK:
FI: ATC can be provided by SE.
NO:
SE:

YES

A control area has been implicitly decoupled.

(The ATC has been set to 0 in the input message)

Gate Closure

(std setup T-10)

All

A35

A35

A47

B11

<Reason>
<code>B11</code>
<text>CtrlA|FI has been decoupled for delivery period 2021-08-30T15:45:00Z - 2021-08-30T16:00:00Z (UTC).</text>
</Reason>

DK:
FI: ATC, mFRR Request, mFRR Bids
NO:
SE:

NO

Monitored input not received.
Configurable

Normally the TSO will monitor ATC, mFRR Request, mFRR Bids.

Gate Closure

(std setup T-10)

Input responsible

A34

A31

A47

A91

<Reason>
<code>A91</code>
<text>ATC for interconnector DK1-SE3 was not received.</text>
</Reason>

YES

Gate Closure

(std setup T-10)

Input responsible

A34

A31

A47

A91

<Reason>
<code>A91</code>
<text>ATC for interconnector DK1-SE3 was not received.</text>
</Reason>

YES/NO

Gate Closure

(std setup T-10)

Input responsible

A34

A31

A47

A91

<Reason>
<code>A91</code>
<text>ATC for interconnector DK1-SE3 was not received.</text>
</Reason>

NO?

ACK on monitored output not received

Start activation phase

(std setup T-7:30)

All

A34

A34

A47

B11

<Reason>
<code>B11</code>
<text>Acknowledgement for OUT_OFFERS_NEEDS_ACTIVATION_SETTLEMENT sent to 10X1001A1001A264 has not been received.</text>
</Reason>

NO?

Negative ACK on monitored output received

Negative ACK received

All

A34

A66

A47

B11

<Reason>
<code>B11</code>
<text>A66 sent to 10X1001A1001A248 has been negatively acknowledged.</text>
</Reason>

YES

The LOM fails

Clearing

(std setup T-10 ++)

All

A34

A34

A47

B18

<Reason>
<code>B18</code>
<text>Zero results are considered as final results.</text>
</Reason>

YES

The LOM doesn’t return unconstrained(UC) result

Clearing

(std setup T-10 ++)

All

A35

A35

A47

B18

<Reason>
<code>B18</code>
<text>Final results are based on Decoupled solution.</text>
</Reason>

Example

<?xml version="1.0" encoding="UTF-8"?>

<ProblemStatement_MarketDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:iec62325.351:tc57wg16:451-5:problemdocument:3:0" xsi:schemaLocation="urn:iec62325.351:tc57wg16:451-5:problemdocument:3:0 xsd/iec62325-451-5-problem_v3_0.xsd">

<mRID>478b5b4a016a4b118371f551e3ba7874</mRID>

<revisionNumber>1</revisionNumber>

<type>A34</type>

<sender_MarketParticipant.mRID codingScheme="A01">10V1001C--000284</sender_MarketParticipant.mRID>

<sender_MarketParticipant.marketRole.type>A35</sender_MarketParticipant.marketRole.type>

<receiver_MarketParticipant.mRID codingScheme="A01">10X1001A1001A264</receiver_MarketParticipant.mRID>

<receiver_MarketParticipant.marketRole.type>A04</receiver_MarketParticipant.marketRole.type>

<createdDateTime>2021-08-30T08:37:31Z</createdDateTime>

<period.timeInterval>

<start>2021-08-30T08:45Z</start>

<end>2021-08-30T09:00Z</end>

</period.timeInterval>

<expected_MarketDocument.type>A34</expected_MarketDocument.type>

<expected_MarketDocument.createdDateTime>2021-08-30T08:35:00Z</expected_MarketDocument.createdDateTime>

<expected_MarketDocument.process.processType>A47</expected_MarketDocument.process.processType>

<domain.mRID codingScheme="A01">10Y1001A1001A91G</domain.mRID>

<Reason>

<code>B11</code>

<text>Acknowledgement for OUT_OFFERS_NEEDS_ACTIVATION_SETTLEMENT sent to 10X1001A1001A264 has not been received.</text>

</Reason>

<Reason>

<code>B11</code>

<text>Acknowledgement for OUT_OFFERS_NEEDS_ACTIVATION_SETTLEMENT sent to 10X1001A1001A248 has not been received.</text>

</Reason>

<Reason>

<code>B11</code>

<text>Acknowledgement for OUT_OFFERS_NEEDS_ACTIVATION_SETTLEMENT sent to 10X1001A1001A38Y has not been received.</text>

</Reason>

<Reason>

<code>B11</code>

<text>Acknowledgement for OUT_OFFERS_NEEDS_ACTIVATION_SETTLEMENT sent to 10X1001A1001A418 has not been received.</text>

</Reason>

</ProblemStatement_MarketDocument>
Message Definitions

Message definitions and document versions

Dataobject Document Schema version

Input

mFRR-Bid-AOF

ReserveBid_MarketDocument

7.2

mFRR Request AOF

ReserveBid_MarketDocument

7.2

mFRR ATC AOF

Capacity_MarketDocument

8.0

Output

Flows AOF

Schedule_MarketDocument

5.1

Clearing Prices AOF

Balancing_MarketDocument

4.1

mFRR Remaining ATC-AOF

Capacity_MarketDocument

8.0

MOL AOF

MeritOrderList_MarketDocument

7.2

Net Positions AOF

Schedule_MarketDocument

5.1

Problem-Statement-Document-TSO-

ProblemStatement_MarketDocument

3.0