Process for use of CMOL

There is a common agreement on the use of messages, schemas, to solve the information needs of CMOL in the NBM group.
There are still codes and values that need to be adapted as there are more consumers who have not yet identified all their needs.

Change Log

Ver Changed by Date Changes

1.0

Bent Atle Bjørtomt

2021.03.28

Changed according to feedback 2021.03.26.

  • mFRR Bid TSO-TSO, clarify business requirements for message exchange.

  • mFRR Activation TSO-TSO, clarify business requirements for message exchange.

  • Added use case examples.

  • Sequence diagram updated.

Introduction

Common merit order list, CMOL, is a list of information to be used for operators and other processes. CMOLs intentions is to evaluate the reserve situation. Do we have enough bids to cover the expected imbalance. This gives the operator more control over the current situation.

Definition

Exchange data and present CMOL.

Bids

Definition Description NBM Comments

Exchange data and present CMOL Bids

The information we need could be considered to consist of two parts

Bids:

  • Attributes

    • Probably most of the attributes is necessary. For instance to show real available volume we need to know which bids that are included in an exclusive bid group. Or price calculation module must understand if a bid is skipped in bid selection or not available due to a conditional linking.

    • Attributes: BidId, Price, Volume, Minimum offered volume, Indivisible Bids, Exclusive Group Order, Multipart (Parent/child), Conditional bids, Technical linked bids, Direct marketProductType, Maximum duration, Resting time, Inclusive bids, Connecting bidding area

    • Bid availability
      Available or unavailable
      If a bid is unavailable also the reason for unavailability

Activations:

  • Attributes

    • There might be several, but at least BidID, activation volume, timeInterval, purpose (balancing or system)

    • For price calculation it might also be necessary to exchange sink (receiving bidding area). But it is not decided if this is necessary. If used, it will only be used for activation done without using AOF. (In AOF there is no information on sink for a given activation.)

Requirements

Req.no. Message Sending frequency Resolution Period Area Comments

BR-CMOL-1.0

mFRR Bid TSO-TSO 'CMOL Bid'

D-1,

15 min

D-1

Bidding Zone.

  • Totals for day-ahead are sent in a message exchange, after all bids from BSP have been received.

BR-CMOL-1.1

mFRR Bid TSO-TSO 'CMOL Bid'

Event triggered

15 min

Changes

Bidding Zone.

  • Event based message exchange should only contain changes.

BR-CMOL-1.2 [1]

mFRR Bid TSO-TSO 'CMOL Bid'

Hourly

15 min

Bidding Zone.

  • Hourly based message exchange. Period from the present time to the rest of the day.

BR-CMOL-1.3

  • At a given time before the operating day, all received bids for the next day should be exchanged.

BR-CMOL-1.4

  • When there is a change of a bid, the updated bid should be exchanged (event driven)

BR-CMOL-1.5

  • Should there also be an exchange of all bids after each bid gate closure, to make sure that information is correct even if one update is missing? I think this is done in NOIS.

BR-CMOL-1.6

  • BSP bids as received at 22:00 o’clock the day before

BR-CMOL-1.7

  • DA and more details are revealed as it approach the gate closure of ID.

BR-CMOL-1.8

  • It will be anonymous data.

BR-CMOL-1.9

  • ResourceProvider will not be know according to the requirement of anonymous data.

BR-CMOL-1.10

  • It consists of single bids as given by the BSPs.

BR-CMOL-1.11

  • Validation of data, linking, exclusive bids etc. must be validated by the TSO before it is sent to the common platform.

Activations

BR-CMOL-2.0

mFRR Activation? 'CMOL Activations'

Each hour.

1 min

T-1H, T-0, T+1H.

Bidding Zone.

  • Totals, 12 periods if MTU=15 min, for all activations are included in the message exchange each hour. One file

BR-CMOL-2.1

mFRR Activation? 'CMOL Activations'

Event based.

1 min

changes

Bidding Zone.

  • Only changed/activations are included in the message exchange.

BR-CMOL-2.2

  • Event driven after bid has been selected for activation (with update if BSP is declining or not responding to electronic order)

BR-CMOL-2.3

  • Should there also be an exchange of all activation just before of each MTU to make sure that information is correct even if one update is missing? I think this is done in NOIS.

BR-CMOL-2.4

  • Include Planned Activations

[1] Not yet determined if necessary.

Use Case

The business object CMOL can be used for different purposes. Main reason for CMOL is to provide System Operators with enough information to control and verify system status, but also to perform corrective procedures as necessary. CMOL may have other purposes such as being a data source for calculating prices and Fallback solution.

CMOL UseCase

Use Case 1: Calculate Prices

Pricecalculation module, "PriceCalc":

A complete process and needs for price calculations will be described in a PriceCalc business requirement specifications document. This describes only the parts of CMOL that are exchanged and shared with other processes.

PriceCalc will need information about selected bid (activation) volume, whether it was selected SA(Scheduled Activation) or DA (Direct Activation) or Period Shift, if it was selected by a local or the AOF process and in which auction (or when) it was selected.

Use Case 2: Evaluate the reserve situation

FiftyOne module, for Operators:

The Operator needs to see, how many MW there are available for next SA or DA in a Bidding Zone, and how many MW is selected for SA/DA in each Bidding Zone.

Operator does not need to see whether bid is in selected, ordered or activated state by BSP, only need to know that it cannot be selected in next DA process because it is already used and possibly purpose of unavailability (congestion, system regulation as remedial action or balancing activation). Operator does not need to see whether a bid is unavailable because of conditional link, either only need to see the bid as unavailable or does not see the bid.

Scope

As given by the Use Case section, CMOL will be data source for System Operators, PriceCalculation and to serve a Fallback situation.

Business and Information Objects

Term

CMOL - Common merit order list : Bids with all attributes, activation- and availability status.

Term CMOL

Functional view

CMOL, Common Merit Order list, is the business object which consist of two data objects, mFRR Activation and mFRR Bid. These two data object are realised as artifacts, mFRR Bid TSO and mFRR Activation TSO.

CMOL

Sequence Diagram

CMOL Sequence

Update and Cancelling

Draft

To update or cancel time series previously sent, a new document is sent with the following information:

  • A new unique document mRID (document identification)

  • Fixed revision number (always equal to '1')

  • A newer created date-time than the previously sent document

For mFRR Bid TSO and mFRR Activation TSO updates are done by sending the affected time series with new data. Cancellation of time series is done by sending value 0 for quantity.

To ensure update of the correct time series, the bid identification of the original time series must be used.

To update bids for upcoming MTUs only the updated bids should be sent in a new bid message. There is no need to resend unchanged bids.

Individual bids and a collection of bids can be sent in one or several data exchanges. Update of bids and activation for future MTUs can be done in one or several data exchanges.

Schemas

Several ENTSOE documents have been considered used for CMOL and especially several options for Activation. We have listed schemas that have been up for discussion, crossed the documents that we have chosen are being used for CMOL.

Table 1. Message/document assessments
Message Document/Schema Part of CMOL Reason Pros Cons

mFRR Bid TSO-TSO

ReserveBid_MarketDocument

  • CMOL

Probably most of the attributes is necessary

mFRR Activation

Activation_MarketDocument

  • CMOL

Direct connection to a ReserveBid_MarketDocument within its TimeSeries. Possible to differ between type of activation. Includes order_MarketDocument.mRID which refer to a certain regulation.

Activation Market document solve handling single/individual bid activation. For aggregation purpose without further use of other messages, then this could be enough to send this and let internal system aggregate per bidding zone if needed.

Support 1 min, 5 min, 15 min including Reason code on point values if needed for System/Balance.

• Complete information needed for different purposes.
• Also used for BSPs

• Missing MarketAgreemetId, which is used to identify RunId for an Auction. Resolved by using ReasonCode.

mFRR MOL

MeritOrderList_MarketDocument

  • CMOL

One MOL each ReserveBid_MarketDocument. It contains only bid-reference with its status, not details as start and end time.

• Received from AOF, so support for consuming this is needed anyway.

• MARI implementation use BidTimePeriod as activation period.
• Missing Activation Process, Could be solved Reason.
• Missing Purpose of the regulation , could be solved with Reason.

Activated mFRR

PlannedResourceSchedule_MarketDocument

  • CMOL

Aggregated values, not connected to ReserveBid_MarketDocument.

HistoricalActivation_MarketDocument

  • CMOL

Similar to activation, except for it is dependent of OriginalActivation_MarketDocument

ReserveAllocationResult_MarketDocument

  • CMOL

• Similar document may be provided for BSPs, reporting after the fact.

• Missing Status
• Missing Purpose of the regulation , could be solved with Reason.
• Result document usually provided after something.

Message Definitions

Message definitions and document versions

Dataobject Document Schema version

mFRR Bid TSO

ReserveBid_MarketDocument

7.2

mFRR Activation TSO

Activation_MarketDocument

6.1