Balancing Mechanism Reporting Agent

User Requirements Specification

Synopsis

This document describes the user requirements for the Balancing Mechanism Reporting Agent (BMRA) system.

Version

Version 24.0

Effective date

02 November 2023

24/06/2010

16.0

Document rebadged and amended for November 2010 Release (P243, CP1333)

Change Implementation

29/11/2012

17.0

P278 for the November 2012 Release

ISG138/10

16/12/2014

18.0

P295, P291for the December 2014 Release

ISG162/01

05/11/2015

19.0

P305 for the November 2015 Release

ISG172/04

29/06/2017

20.0

P321 Self-Governance– 29 June 2017 Release

P245/05

P329 Alternative – 29 June 2017 Release

ISG194/02

29/03/19

21.0

29 March 2019 Standalone Release – P369

P285/12

11/12/2019

22.0

11 December 2019 Standalone Release – CP1517

ISG220/01

ISG222/03

18/03/2021

23.0

18 March 2021 Standalone Release – P408 Self-Governance

ISG234/02

02/11/2023

24.0

02 November 2023 Standard Release

ISG270/02

Service Description for Balancing Mechanism Reporting

BSCCo

BMRA SD

Balancing Mechanism Reporting Business Process Models

BSCCo

BMRA BPM

Settlement Administration Business Process Models

BSCCo

SAA BPM

Interface Definition and Design - Parts 1 and 2

BSCCo

INTERFACE

Central Registration Agent User Requirements Specification

BSCCo

CRA URS

BMRA & SAA Interface Specification

NETSO

NGC IS

ETSO Balancing Process Results Management Document Implementation Guide Version1.0 Release 0

ETSOVista

ETSO BPRM

Bank

A bank which receives debit and credit instructions from the Funds Administration Agent.

BMRA

Balancing Mechanism Reporting Agent.

BSC Party

Any user of Balancing and Settlement Code services.

BSCCo Ltd

The Balancing and Settlement Code Company.

CDCA

Central Data Collection Agent.

CRA

Central Registration Agent

Credit Agency

A credit agency which provides credit cover data on Traders.

ECVAA

Energy Contract Volume Aggregation Agent.

ECVNA

Energy Contract Volume Notification Agent.

FAA

Funds Administration Agent.

IA

Interconnector Administrator.

IEA

Interconnector Error Administrator

Meter

A physical meter registered within the Balancing and Settlement Code arrangements.

MOA

Meter Operation Agent.

MVRNA

Meter Volume Reallocation Notification Agent

NETSO

National Electricity Transmission System Operator

Public

A member of the general public.

SAA

Settlement Administration Agent.

SVAA

Supplier Volume Aggregation Agent, equivalent to the current Initial Settlement and Reconciliation Agent (ISRA).

TAA

Technical Assurance Agent.

Requirement ID:

BMRA-F001

Status:

Mandatory

Title:

Calculate Balancing Mechanism and Replacement Reserve Volumes

BSC reference:

BMRA SD 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9, BMRA BPM 3.3, CR009, P305, P344.

Man/auto:

Automatic

Frequency:

Once, for each settlement period.

Volumes:

Between 1000 - 5000 BM units. At least 1 FPN data per BM unit. For those BM units that receive bids and offers (estimated 1000), at most 10 Bid-Offer Pairs and 30 Bid-Offer Acceptances per BM unit, per settlement period.

Functional Requirements:

A large number of intermediate calculations are required to produce the balancing mechanism volumes and RR Acceptance volumes. Note that balancing mechanism volumes and RR Acceptance volumes share processes till qAO^kn_ij(t) and qAB^kn_ij(t) are calculated and then subsequently diverge. All calculation steps in this requirement are included here.

1: The value of Final Physical Notification, FPNi_j(t) shall be defined for spot times, t, falling within Settlement Period j by linear interpolation from the values of Point FPN (fFPNit), submitted for that Settlement Period j, for BM Unit i.

2: For any value of Bid-Offer Number, n, the Bid-Offer Volume (qBOⁿ_ij(t)) at any spot time t shall be defined by linear interpolation from the values of Point Bid-Offer Volume (^fqBOⁿ_it) submitted for spot times t in Settlement Period j for BM Unit i.

3: The Bid-Offer Upper Range BOURⁿ_ij(t) at any spot time t shall be defined for Bid-Offer Pairs with positive Bid-Offer Pair Numbers, as follows:

BOURⁿ_ij(t) = FPN_ij(t) + Σⁿ⁺qBOⁿ_ij(t); and

BOUR⁰ _ij (t) = FPN_ij(t)

Where Σⁿ⁺ represents a sum over all positive Bid-Offer Pairs, 1 to n.

The Bid-Offer Lower Range BOLRⁿ_ij(t) at any spot time t shall be defined for Bid-Offer Pairs with negative Bid-Offer Pair Numbers, as follows:

BOLRⁿ_ij(t) = FPN_ij(t) + Σ^n-qBOⁿ_ij(t); and

BOLR ⁰_ij (t) = FPN_ij(t)

Where Σ^n- represents a sum over the range of Bid-Offer Pair Numbers -1 to n.

4: The Acceptance Volume (qA^k_ij(t)) attributable to each Bid-Offer Acceptance, including RR Schedule flagged Acceptances, shall be defined through processing the Point Acceptance Volumes that define the MW output levels that the NETSO requested the BM Unit to operate for certain times within the Balancing Mechanism Window Period.

Linear interpolation shall be used to define the profile of power output in MW expected to be delivered in each Settlement Period within the Balancing Mechanism Window Period as a result of Bid-Offer Acceptance, k.

For spot times within the Balancing Mechanism Window Period prior to the first value Point Acceptance Volume for Bid-Offer Acceptance k, the value of the Acceptance Volume is set to the last calculated value of Acceptance Volume for those spot times. If no such previously calculated value of Acceptance Volume exists, then the Acceptance Volume will be set to the value of Final Physical Notification (FPN_ij(t)) for those times.

Acceptance Volumes are then ordered by reference to increasing values of k.

The diagram below shows a Bid-Offer Acceptance in relation to Point Acceptance Volumes and the Bid-Offer Upper and Lower Ranges.

5: The Accepted Bid-Offer Volumes (qABO^kn_ij (t)) shall be defined in MW of a Bid or Offer from Bid-Offer Pair n accepted as a result of Bid-Offer Acceptance k that is not flagged as relating to an RR Instruction in Settlement Period j from BM Unit i. This is determined as follows:

For n>0,

qABO^kn_ij (t) = Max{Min(qA^k_ij(t), BOURⁿ _ij (t)), BOUR^n-1_ij(t)} - Max{Min(qA^k-1_ij(t), BOURⁿ_ij(t)), BOUR^n-1_ij(t)}

For n<0,

qABO^kn_ij (t) = Min{Max(qA^k_ij(t), BOLRⁿ_ij(t)), BOLRⁿ⁺¹_ij(t)} - Min{Max(qA^k-1_ij(t), BOLRⁿ_ij(t)), BOLRⁿ⁺¹_ij(t)}

Where, from all Bid-Offer Acceptances for which an Acceptance Volume has been determined for Settlement Period j, k- represents that Bid-Offer Acceptance with the Bid-Offer Acceptance Time (T^k-_it) most recently preceding that of Bid-Offer Acceptance k.

If, there is no Bid-Offer Acceptance, for which an Acceptance Volume has been determined in Settlement Period j which has a Bid-Offer Acceptance Time that precedes that of Bid-Offer Acceptance k, the value of qA^k-_ij(t) = FPN_ij(t) for each Acceptance k that is not flagged as relating to an RR Instruction..

6: The Accepted Offer Volume (qAO^kn_ij(t)) and Accepted Bid Volume qAB^kn_ij (t) shall be defined in MW by splitting the positive and negative parts of the Bid-Offer Acceptance Volume.

The Accepted Offer Volume (qAOknij(t)) represents the volume (in MW) of Offer n accepted as a result of Bid-Offer Acceptance k from BM Unit i at spot times t within Settlement Period j. It is the positive part of the Bid-Offer Acceptance Volume, calculated by:

qAO knij(t) = Max {qABOknij(t), 0}

Similarly, the Accepted Bid Volume (qABknij(t)) represents the volume of Bid n accepted as a result of Bid-Offer Acceptance k from BM Unit i at spot times t within Settlement Period j. It is the negative part of the Bid-Offer Acceptance Volume, calculated by:

qABknij (t) = Min {qABO knij(t), 0}

The diagram below represents the volumes of Bids and Offers bought or sold as a result of a Bid-Offer Acceptance.

7: The Period Accepted Offer Volume (QAO^kn_ij) and Period Accepted Bid Volume (QAB^kn_ij) shall be calculated by integrating the Accepted Offer Volume and Accepted Bid Volume over all spot times in the Settlement Period, for each Acceptance k that is not flagged as relating to an RR Schedule.

The Period Accepted Offer Volume (QAO^kn_ij) is determined by integrating the Accepted Offer Volume over all spot times t in Settlement Period j, for each Acceptance k that is not flagged as relating to an RR Schedule. It represents the half-hourly integrated volume of Offer n, in MWh, accepted as a result of Bid-Offer Acceptance k.

The Period Accepted Bid Volume (QABknij) is determined by integrating the Accepted Bid Volume over all spot times, t, in Settlement Period, j, for each Acceptance k that is not flagged as relating to an RR Schedule. It represents the half-hourly integrated volume of Bid n, in MWh, accepted as a result of Bid-Offer Acceptance k.

The Indicative Period RR Accepted Offer Volume (IRRAO^knij) is established by integrating the Accepted Offer Volume over all spot times in the Settlement Period, for each Acceptance k that is flagged as relating to an RR Schedule.

The Indicative Period RR Accepted Bid Volume (IRRAB^kn_ij) is established by integrating the Accepted Bid Volume over all spot times in the Settlement Period, for each Acceptance k that is flagged as relating to an RR Schedule.

For more information on the method used for performing linear interpolation and integration please refer to the BMRA System Specification.

8: The Reserve Scarcity Price (RSVP_j) shall be calculated as:

RSVP_j = LoLP_j * VoLL

where LoLP_j is the Final Loss of Load Probability for the Settlement Period and VoLL is the Value of Lost Load system parameter.

Until 1 November 2018, if the NETSO does not report a Final Loss of Load Probability for the Settlement Period, then:

RSVP_j = 0.

From 1 November 2018, if the NETSO does not report a Final Loss of Load Probability for the Settlement Period, then the BMRA will use the most recent Indicative LoLP as though it were the Final LoLP, else if no Indicative LoLP is available then:

RSVP_j = 0.

If the BMRA uses an Indicative LoLP in the absence of a Final LoLP provided to it by the NETSO, then the BMRA will set the Default LoLP Flag to ‘True’.

9: The STOR Instructed Volume (QSIV^t_j) shall be calculated as follows:

In respect of each Settlement Period that is in a STOR Availability Window, for each accepted Offer or BSAA that is a STOR Action, the STOR Instructed Volume (QSIVtj) shall be equal to the Period Accepted Offer Volume derived from an accepted Offer that is STOR Flagged.

10: The STOR Action Price (STAP^t_j) shall be calculated as follows:

In respect of each Settlement Period that is in a STOR Availability Window, for each accepted Offer that is a STOR action:

STAP^t_j = max(POⁿ_ij, RSVP_j).

In respect of each Settlement Period, for each Balancing Services Adjustment Action that is a STOR action:

STAP^t_j = max(BSAP^m_j, RSVP_j ).

11: The Demand Control Volumes shall be calculated as follows:

The Start Point Demand Control level and End Point Demand Control Level shall be the Demand Control Event Estimates determined at the relevant times and dates notified by the NETSO.

In respect of each Settlement Period, the Demand Control Volume for each Demand Control Event Stage shall be established by linear interpolation from the values of the Start Point Demand Control Level and End Point Demand Control Level.

The System Demand Control Volume (QSDC_j) shall be determined as the sum of the Demand Control Volumes where the Demand Control Volume Notice has the SMAF Flag set to ‘Yes’.

The Balancing Demand Control Volume (QBDC_j) shall be determined as the sum of the Demand Control Volumes where the Demand Control Volume Notice has the SMAF Flag set to ‘No’.

12: Special Cases

Acceptances are processed in the order in which they are issued, with the exception of Acceptances that are flagged as relating to an RR Schedule, which shall be treated as issued at the Gate Closure time of the Replacement Reserve Auction Period to which they relate.

No Acceptance Volume (qA^k_ij(t)) shall be calculated for any spot times, t. where the following criteria are met:

- qA^k_ij(t) is not flagged as relating to a RR Schedule or a RR Instruction; and

- there exists a qA^k*_ij(t) flagged as relating to a RR Schedule; and

- BEGCT < qA^k_ij(t) Bid-Offer Acceptance Time < qA^k*_ij(t) associated Replacement Reserve Activation Time; and

- either:

qA^k-_ij(t) (MW) < qA^k_ij(t) (MW) < qA^k*_ij(t) (MW)

or

qA^k*_ij(t) (MW) < qA^k_ij(t) (MW) < qA^k-_ij(t) (MW)

where qA^k-_ij(t) represents the latest Acceptance Volume relating to the latest Acceptance issued prior to Gate Closure of the relevant Replacement Reserve Auction Period (BEGCT). If no such previously calculated value of Acceptance Volume qA^k-_ij(t) exists, then the Acceptance Volume shall be set to the value of FPN_ij(t) for those spot times; and where qA^k_ij(t) (MW), qA^k-_ij(t) (MW) and qA^k*_ij(t) (MW) represent the associated spot time MW values.

In the example below, a BOA, qA^k-_ij, is requested after BEGCT by the TSO. The BOA falls between an existing BOA, qA^k_ij’ which is equal to the FPN as it was sent prior to BEGCT, and an RR Activation qAk^*_ij.

Non Functional Requirement:

If there is insufficient data to calculate Period Bid and Offer Acceptance Volumes, an exception report shall be sent to the NETSO and BSCCo Ltd.

Interfaces:

BMRA-I001, BMRA-I002, BMRA-I006, BMRA – I036.

Issues:

Man/auto:

Automatic

Frequency:

Once, for each settlement period.

Volumes:

Between 1000 - 5000 BM units. At least 1 FPN data per BM unit. For those BM units that receive bids and offers (estimated 1000), at most 10 Bid-Offer Pairs and 30 Bid-Offer Acceptances per BM unit, per settlement period.

Functional Requirement:

1:

The Period BM Unit Total Accepted Offer Volume shall be calculated as follows for Acceptances that are not flagged as relating to an RR Schedule:

QAOⁿ_ij = Σ^kQAO^kn_ij

The Period BM Unit Total Accepted Bid Volume shall be calculated as follows for Acceptances that are not flagged as relating to an RR Schedule:

QABⁿ_ij = Σ^kQAB^kn_ij

This is the total MWh volume of Offer or Bid n accepted from all Bid-Offer Acceptances k that are not flagged as an RR Schedule.

2:

The Indicative Period RR Total Accepted Offer Volume, for all Acceptances that are flagged as relating to an Indicative RR Schedule, and shall be established as follows:

IRRAOⁿ_ij = Σ^k IRRAO^kn_ij

The Indicative Period Indicative RR Total Accepted Bid Volume, for all Acceptances that are flagged as relating to an Indicative RR Schedule shall be established as follows:

IRRABⁿ_ij = Σ^k IRRAB^kn_ij

Where Σ^k represents the sum over all Acceptances within the Settlement Period for IRRABⁿ_ij and IRRAOⁿ_ij.

The Indicative RR Activation Volume for a Quarter hour J shall be established as follows:

IRRAV_i^J = Indicative Quarter Hour RR Activated Quantity * 0.25

Where J is the Quarter Hour and i is the BM unit.

Non Functional Requirement:

If there is insufficient data to calculate Period BM Unit Total Accepted Bid and Offer Volume, an exception report shall be sent to the NETSO and BSCCo Ltd.

Interfaces:

BMRA-I001, BMRA-I002, BMRA-I006, BMRA-I036.

Issues:

Requirement ID:

BMRA-F003

Status:

Mandatory

Title:

Calculate Estimated Period Balancing Mechanism and Replacement Reserve Bid and Offer Cashflows.

BSC reference:

BMRA SD 9.8, BMRA BPM 3.3, P344

Man/auto:

Automatic

Frequency:

Once, for each settlement period.

Volumes:

Between 1000 - 5000 BM units. At least 1 FPN data per BM unit. For those BM units that receive bids and offers (estimated 1000), at most 10 Bid-Offer Pairs and 30 Bid-Offer Acceptances per BM unit, per settlement period.

Functional Requirement:

A number of intermediate calculations are required to produce the Estimated Period Balancing Mechanism and RR Bid and Offer Cashflows. All calculation steps in this requirement are included here.

1: The estimated BM Unit Transmission Loss Multiplier ETLM_ij shall be calculated for each non-Interconnector BM Unit as:

ETLM_ij = 1 + TLF_ij + ETLMO⁺ for all BM Units that are in Trading Units that are attributable to production accounts,

ETLM_ij = 1 + TLF_ij + ETLMO^- for all BM Units that are in Trading Units that are attributable to consumption accounts.

ETLMO⁺ and ETLMO^- are estimated values for TLMO_j⁺ and TLMO_j^- respectively. They shall be user definable parameters, initially set to zero.

For each Interconnector BM Unit, the estimated BM Unit Transmission Loss Multiplier ETLM_ij shall be set as:

ETLM_ij = 1

irrespective of whether the Interconnector BM Unit is attributable to a production or consumption account.

For each BM unit:

• TLF_ij is the Transmission Loss Factor assigned to each BM Unit, and shall apply to all settlement periods until a change is received from the Central Registration Agent (CRA);

• the BM unit type (production or consumption) shall be received from the Central Registration Agent (CRA) and shall indicate whether the BM unit is attributable to a production or consumption account. (This data will be received from the CRA on a daily basis with the TLF_ij values.)

ETLM_ij is calculated for each BM unit and applies for all settlement periods, until a change to either TLF_ij , ETLMO⁺ or ETLMO^- prompts re-calculation.

Note that, by default, a BM Unit not comprising a Trading Unit with other BM Units shall be considered to be a ‘Sole Trading Unit’ for the purposes of these calculations. The production and consumption status of such a Trading Unit shall therefore be determined using the metered volume of the single BM Unit comprising that Trading Unit.

In respect of each Settlement Period, for each Secondary BM Unit, the Estimated Transmission Loss Multiplier shall be calculated as follows:

ETLM_ij = ETLM_ij(Base)

where ETLM_ij(Base) means the value of ETLM_ij calculated in the Settlement Period for BM Units belonging to the Base Trading Unit in the same GSP Group as the Secondary BM Unit.

2: The Period Acceptance Offer Cashflow CAO^kn_ij shall be calculated as:

CAO^kn_ij = QAO^kn_ij * POⁿ_ij * ETLM_ij.

The Period Acceptance Bid Cashflow CAB^kn_ij shall be calculated as:

CAB^kn_ij = QAB^kn_ij * PBⁿ_ij * ETLM_ij

Where QAB^kn_ij is the Period Accepted Bid Volume; QAO^kn_ij is the Period Accepted Offer Volume; PBⁿ_ij is the Bid Price for the corresponding Bid; POⁿ_ij is the Offer Price for the corresponding Offer; and ETLM_ij is the Estimated Transmission Loss Multiplier for BM Unit i.

The Period Acceptance Bid Cashflow (CAB^kn_ij) and Period Acceptance Offer Cashflow (CAO^kn_ij) represent the Estimated Transmission Loss adjusted Cashflow relating to BM Unit I for Balancing Mechanism action in Settlement Period j, allocated to Offer or Bid n, as a result of Bid-Offer Acceptance k. Under normal circumstances, the Period Acceptance Bid Cashflow will be negative as QAB^kn_ij is negative and PBⁿ_ij is normally positive.

The Period Acceptance Bid Cashflow and the Period Acceptance Offer Cashflow need to be stored if required for reporting purposes.

3: The Period BM Unit Offer Cashflow (COⁿ_ij ) shall be calculated as:

COⁿ_ij = QAOⁿ_ij * POⁿ_ij * ETLM_ij (=Σ^kCAO^kn_ij)

The Period BM Unit Bid Cashflow (CBⁿ_ij) shall be calculated as:

CBⁿ_ij = QABⁿ_ij * PBⁿ_ij * ETLM_ij (=Σ^kCAB^kn_ij)

These represent the Estimated Transmission Loss adjusted cashflows relating to BM Unit i for Balancing Mechanism action in Settlement Period j, allocated to Offer or Bid n. Under normal circumstances the Period BM Unit Bid Cashflow will be negative.

4: The Indicative Quarter-Hour RR Cashflow for a BM Unit (ICCR_iJ) is defined as:

ICCR_iJ = IRRAV_iJ * IRRAP_J

where IRRAP_J represents the Quarter Hour Indicative RR Activation Price and IRRAV_iJ is the Indicative RR Activation Volume

IRRAV_iJ = Indicative Quarter Hour RR Activated Quantity * 0.25

5: The Indicative Period RR BM Unit Cashflow (ICRR_ij) for a BM unit is calculated as:

ICRR_ij = Σ_J ICCR_iJ

where Σ_J is the sum over all Quarter Hours J within Settlement Period j.

Non Functional Requirement:

If there is insufficient data to calculate Estimated Period Balancing Mechanism Bid and Offer Cashflows, an exception report shall be sent to the NETSO and BSCCo Ltd.

Interfaces:

BMRA-I001, BMRA-I002, BMRA-I006, BMRA-I036.

Issues:

The method used in section 1 for calculating the estimated transmission loss multiplier for each BM unit (ETLM_ij) is as agreed at the BMRA URS workshop of the 28^th January 2000.

Requirement ID:

BMRA-F004

Status:

M

Title:

Calculate Estimated System Buy and Sell Prices

BSC reference:

P217, P305, P344

Man/auto:

Automatic

Frequency:

Once, for each Settlement Period.

Volumes:

Functional Requirements:

1: Identify Short-Duration Acceptances.

The rules for identifying Short-Duration Acceptances are:

a. Acceptances for each BM Unit are grouped into sets of overlapping acceptances (for the avoidance of doubt, if two acceptances are contiguous, i.e. the last spot time of one acceptance matches the first of another, then the two are considered to overlap).

b. The overall duration of the group is computed (earliest spot time of any acceptance in a group to latest spot time of any acceptance in a group).

c. In relation to any Demand Control Volume, the Continuous Acceptance Duration shall be the duration of the period commencing at the Demand Control Event Start Point and ending at the Demand Control Event End Point.

d. If the overall duration is less than the Continuous Acceptance Duration Limit, CADL_d then the Short Duration Acceptance flag for each acceptance in the group is set to show that it is a Short-Duration Acceptance. If CADL_d = 0 then no acceptances are “Short-Duration Acceptances”. CADL_d will be an integer number of minutes from 0 to 30.

Short-Duration Acceptances will be considered to be “CADL Flagged” for the purposes of the System Price Calculation process.

2: Compute Total Volumes:

a. Total Volume of Offers

TQAO_j = Σ_iΣⁿQAOⁿ_ij

where: Σ_i represents the sum over all BM Units;

Σⁿ represents the sum over all accepted Offers

b. Total Volume of Bids

TQAB_j = Σ_iΣⁿQABⁿ_ij

where: Σ_i represents the sum over all BM Units;

Σⁿ represents the sum over all accepted Bids

c. Total Period Applicable Balancing Services Volume

TQAS_j = Σ_iQAS_ij

where: Σ_i represents the sum over all BM Units;

d. Total Balancing Services Adjustment Buy Volume

TBVA_j = Σ^mQBSAB^m_j

where: Σ^m represents the sum over all Balancing Services Adjustment Buy Actions.

e. Total Balancing Services Adjustment Sell Volume

TSVA_j = Σ^mQBSAS^m_j

where: Σ^m represents the sum over all Balancing Services Adjustment Sell Actions.

f. TQSIV_j = Σ^tQSIV^t_j

where: Σ^t represents the sum over all STOR Actions.

g. TQSDC_j = ΣQSDC_j

where: Σ represents the sum over all System Demand Control Volumes.

h. TQBDC_j = ΣQBDC_j

where: Σ represents the sum over all Balancing Demand Control Volumes.

3: Identify “De Minimis Acceptance Volumes”.

Acceptances (including those that are STOR Flagged) with a Total Accepted Volume less than the De Minimis Acceptance Threshold (i.e. where values of |QAOⁿ_ij| < DMAT_d or |QABⁿ_ij| < DMAT_d) are identified as “De Minimis Acceptance Volumes” and are therefore considered to be De Minimis Tagged.

Balancing Services Adjustment Actions (including those that are STOR Flagged) with a Volume less than the De Minimis Acceptance Threshold (i.e. where values of |QBSAB^m_j| < DMAT_d or |QBSAS^m_j| < DMAT_d) are identified as “De Minimis Acceptance Volumes” and are therefore considered to be De Minimis Tagged.

Demand Control Volumes with a volume less than the De Minimis Acceptance Threshold (i.e. where values of |QSDC_j| < DMAT_d or |QBDC_j| < DMAT_d) are identified as “De Minimis Acceptance Volumes” and are therefore considered to be De Minimis Tagged.

De Minimis Tagged System Actions are excluded from the price calculations as they may distort the results.

If DMAT_d is set to 0, then no volumes will be tagged in this way. DMAT_d will always be a positive number or 0.

4: Build Buy and Sell Stacks.

Buy System Actions (QSB^w_j) are considered to be:

i. All those Accepted Offers (QAO^kn_ij) which are not “De Minimis Acceptance Volumes” and not STOR Actions;

ii. All Balancing Services Adjustment Buy Actions (QBSAB^m_j) which are not “De Minimis Acceptance Volumes” and not STOR Actions;

iii. All STOR Instructed Volumes (QSIV^t_j) which are not “De Minimis Acceptance Volumes”;

iv. All System Demand Control Volumes (QSDC_j) which are not “De Minimis Acceptance Volumes”; and

v. All Balancing Demand Control Volumes (QBDC_j) which are not “De Minimis Acceptance Volumes”.

vi. In relation to Replacement Reserve Auction Results, the positive values of Quarter Hour Volume GB Need Met (VGB^J_j) in MWh for each Quarter Hour falling within Settlement Period j determined as below:

VGB^J = GB^J * 0.25

where GB^J represents the Quarter Hour RR Activated Quantity associated to the Quarter Hour GB Need Met for Quarter Hour ‘J’

6. in relation to Replacement Reserve Auction Results, Replacement Reserve Aggregated Unpriced System Buy Actions (IRRAUSB_j) determined for each Settlement Period as below:

IRRAUSB_j = max {(∑ⁿ_i IRRAO ⁿ_ij + ∑ⁿ_i IRRAB ⁿ_ij ), 0}

+ max (∑^J VI ⁿ_j , 0) – max (∑^J VGB ^J_j, 0)

where VI^J represents the Quarter Hour Volume Interconnector Schedule to be determined from the Quarter Hour Interconnector Schedule (I^J) as below;

VI^J = I^J * 0.25

where I^J represents the Quarter Hour RR Activated Quantity associated to the Quarter Hour Interconnector Schedule for Quarter Hour ‘J’

Sell System Actions (QSS^w_j) are considered to be:

i. All those Accepted Bids (QAB^kn_ij) which are not “De Minimis Acceptance Volumes”; and

ii. All Balancing Services Adjustment Sell Actions (QBSAS^m_j) which are not “De Minimis Acceptance Volumes”.

iii. in relation to Replacement Reserve Auction Results, the negative values of Quarter Hour Volume GB Need Met (VGB^J_j) in MWh for each Quarter Hour falling within Settlement Period j determined by the SAA as below:

VGB^J = GB^J * 0.25

where GB^J represents the Quarter Hour RR Activated Quantity associated to the Quarter Hour GB Need Met for Quarter Hour ‘J’

iv. in relation to Replacement Reserve Auction Results, Indicative Replacement Reserve Aggregated Unpriced System Sell Actions (IRRAUSS_j) determined by the SAA for each Settlement Period as below:

IRRAUSSj = min {(∑ⁿ_i IRRAO ⁿ_ij + ∑ⁿ_i IRRAB ⁿ_ij ), 0}

+ min (∑^J VI ⁿ_j , 0) – min (∑^J VGB ^J_j, 0)

The price of a System Action is considered to be (SAP^w_j):

i. In the case of an accepted Offer, the Offer Price POⁿ_ij;

ii. In the case of an accepted Bid, the Bid Price PBⁿ_ij;

iii. In the case of Balancing Services Adjustment Actions, Balancing Services Adjustment Price BSAP^m_j (derived from Cost/Volume, i.e. a £/MWh price);

iv. In the case of a STOR Action, the STOR Action Price (STAP^t_j); or

v. In the case of a System Demand Control Volume or a Balancing Demand Control Volume, the VoLL.

vi. In the case of Quarter Hour Volume GB Need Met, the associated Indicative Quarter Hour Replacement Reserve Activation Price (QHRRAP^J); and

vii. In the case of Replacement Reserve Aggregated Unpriced System Actions, the price shall be equal to zero.

For each Settlement Period, all System Actions are listed in descending order of price, within the relevant Stack. Unpriced Balancing Services Adjustment Actions are placed at the top of the Buy Stack (as if most expensive) or the bottom of the Sell Stack (as if least expensive), as appropriate. For example:

5: Apply Arbitrage Tagging.

Starting from the most expensive Sell Action and least expensive Buy Action, each System Action is inspected for arbitrage, i.e. where the Sell Action’s price exceeds or is equal to the Buy Action’s price. Where arbitrage exists then equivalent amounts of volume are tagged out from both stacks until arbitrage no longer exists.

Actions with the same price which are on the same stack are combined into a single item for the purpose of Arbitrage inspection. If, for a particular price, only a subset of the combined Buy (or Sell) Actions can be matched, then every Buy (or Sell) Action at that price is tagged to the same degree (a fraction equal to amount matched, for that price, over the total volume available, for that price), rather than tagging some of the individual Actions entirely, and others not at all.

Extending the example from above:

In this example there are two Buy Actions (total volume = 70 MWh, price = £10) matched to a single Sell Action (volume = 7 MWh, price = £25). The two Buy Actions therefore have an amount tagged equal to 7/70 times their volume ( 5 and 2 MWh respectively, for a total of 7 MWh tagged volume)

Unpriced Balancing Services Adjustment Actions are ignored for the purposes of Arbitrage – i.e. once all Priced Actions on a Stack have been Arbitrage tagged then no further Arbitrage tagging can occur.

The process of Arbitrage Tagging will only be carried out for Settlement Dates where the Arbitrage Flag (a dated system parameter) is set.

6: Determine Action Classification

For each Settlement Period, the Buy and Sell Stacks are then updated by applying the following algorithm:

All the First-Stage Flagged and Unflagged System Actions are identified on each Stack. A First-Stage Flagged System Action is one which is either:

a) A Short-Duration (CADL Flagged) Acceptance;

b) A SO-Flagged Acceptance;

c) A SO-Flagged Balancing Services Adjustment Action; or

d) A System Demand Control Volume

A First-Stage Unflagged System Action is one which is not a First-Stage Flagged System Action.

Then, for the Buy Stack, all First-Stage Flagged System Actions with a price which is higher than the most expensive First-Stage Unflagged System Action are classified as Second-Stage Flagged System Actions. And, for the Sell Stack, all First-Stage Flagged System Actions with a price which is lower than the least expensive First-Stage Unflagged System Action are classified as Second-Stage Flagged System Actions.

All Second-Stage Flagged System Actions are considered to be unpriced.

For example:

Buy Stack

Sell Stack

Note that unpriced Balancing Services Adjustment Actions are always classified as Second-Stage Flagged System Actions and therefore always remain unpriced.

7: Apply NIV Tagging

Starting from the least expensive Sell Action and most expensive Buy Action, Actions from the two stacks are matched and tagged until the smaller (in total volume) of the two stacks is completely tagged. Unpriced Actions are included in NIV Tagging. Unpriced Sell Actions are considered to be the least expensive Sell Actions and Unpriced Buy Actions are considered to be the most expensive Buy Action – i.e. where present they are the first Actions to be considered during the NIV Tagging process.

Actions with the same price which are on the same stack are combined into a single item for the purpose of matching. If, for a particular price, only a subset of the combined Buy (or Sell) Actions can be matched, then every Buy (or Sell) Action at that price is tagged to the same degree (a fraction equal to amount matched, for that price, over the total volume available, for that price), rather than tagging some of the individual Actions entirely, and others not at all. Unpriced items are considered to be at the same price for the purpose of NIV Tagging.

In the example from above the Buy Stack is the smaller (having only 70 MWh of total volume, as opposed to 100 MWh on the Sell Stack). The result of this process is that there will be, across the two stacks, a mixture of NIV Tagged and NIV Untagged stack items. Continuing the example from before:

Note that for the £10 price range only 29 out of the 44 available MWh of Sell Actions at that price can be tagged. Therefore each Sell Action in that price range would be tagged by an amount equal to 29/44 of their entire volumes. Expanding the example, and assuming that there are three Sell Actions that make up the 44 MWh:

8: Calculate and Apply Replacement Price

The Replacement Price is calculated from a selection of those untagged items remaining after the NIV Tagging process which are priced System Actions (i.e. Unflagged Second-Stage System Actions). This selection is determined by the Replacement Price Average Reference (RPAR) Volume, and is defined as that volume of the most expensive priced System Action items remaining after NIV Tagging which is equivalent to the RPAR Volume (where necessary only part of an item’s volume will be considered selected in order that the total selected volume is equal to the RPAR Volume). Where the total remaining volume of untagged, priced System Action items is less than the RPAR Volume then all untagged, priced System Action items are selected.

The Replacement Price is calculated as the volume weighed average price of the selected items.

If NIV is positive then:

RP _j = ∑^w' (QSB^w'_j * SAP^w'_j) / ∑^w' QSB^w'_j

and if NIV is negative then:

RP _j = ∑^w' (QSS^w'_j * SAP^w'_j) / ∑^w' QSS^w'_j

Where ∑^w' is the sum over all RPAR Volume selected untagged, priced System Actions.

Where no priced System Action items remain after NIV Tagging then the Replacement Price is the Market Price. If the Market Price is undefined then the Replacement Price is zero.

The actual volume of Actions used to calculate the Replacement Price is defined as the Replacement Price Calculation Volume. If the Replacement Price is derived from the Market Price then Replacement Price Calculation Volume will be considered to be zero.

Once calculated the Replacement Price is assigned to those remaining untagged stack items which are classified as Second-Stage Flagged System Actions, All such affected System Actions are considered to be “Repriced” System Actions.

9: Apply PAR Tagging

Referencing the remaining Buy or Sell Stack (depending on whichever stack has untagged items remaining after NIV tagging), and starting from the most expensive Sell Stack item or least expensive Buy Stack item, Buy or Sell Stack items are tagged until the total remaining priced volume in the stack is not more than the Price Average Reference Volume (PAR_d).

Actions with the same price which are on the same stack are combined into a single item for the purpose of matching. If, for a particular price, only a subset of the entire set of combined Sell Actions (or Buy Actions) can be matched, then every Sell Action (or Buy Action) at that price is tagged to the same degree (a fraction equal to amount matched, for that price, over the total volume available, for that price), rather than tagging some of the individual Sell Actions (or Buy Actions) entirely, and others not at all. For an example which demonstrates the principle of this mechanism see the section describing NIV tagging above.

Continuing the example from above: All items in the Buy Stack are NIV Tagged, and only two items remain untagged in the Sell Stack, leaving a total of 30 MWh untagged volume. For example, if PAR_d was defined to have a value of 20 MWh, this would mean that 10 of the remaining 30 MWh should be PAR Tagged (to leave us with the required 20 MWh), leaving the stacks as follows:

Note that where, after NIV Tagging, the remaining volume is less than or equal to the PAR_d then no items will be PAR Tagged.

10: Calculate Reported Period BM Unit Volumes

It is now possible to calculate the following reported derived values:

a. Period BM Unit Tagged Volume of Offers (QTAOⁿ_ij) and Bids (QTABⁿ_ij) are the amounts of QAOⁿ_ij and QABⁿ_ij respectively which were excluded from the System Price Stacks by De Minimis Tagging, Arbitrage Tagging, NIV Tagging and/or PAR Tagging.

b. Period BM Unit Repriced Accepted Volume of Offers (QRAOⁿ_ij) and Bids (QRABⁿ_ij) are the amounts of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) but which were Classified as Second-Stage Flagged and therefore subject to the Replacement Price.

c. Period BM Unit Originally-priced Accepted Volume of Offers (QOAOⁿ_ij) and Bids (QOABⁿ_ij) are the amounts of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) and were not Classified as Second-Stage Flagged and therefore not subject to the Replacement Price.

11: Calculate Reported Acceptance Volumes

It is now possible to calculate the following reported derived values:

a. The System Total Priced Accepted Volume of Offers (TQPAO_j) and Bids (TQPAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were not Classified as Second-Stage Flagged.

b. System Total Tagged Accepted Volume of Offers (TQTAO_j) and Bids (TQTAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were excluded from the System Price Stacks by De Minimis Tagging, Arbitrage Tagging, NIV Tagging and/or PAR Tagging.

c. System Total Repriced Accepted Volume of Offers (TQRAO_j) and Bids (TQRAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) but which were Classified as Second-Stage Flagged and therefore subject to the Replacement Price.

d. System Total Originally-priced Accepted Volume of Offers (TQOAO_j) and Bids (TQOAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) and were not Classified as Second-Stage Flagged and therefore not subject to the Replacement Price.

12: Calculate Reported Adjustment Volumes

It is now possible to calculate the following reported derived values:

a. Total System Adjustment Volume of Buy Items (TSVA_j) and Sell Items (TBVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively.

b. Total System Tagged Adjustment Volume of Buy Items (TSTVA_j) and Sell Items (TBSVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively which were excluded from the System Price Stacks by De Minimis Tagging, Arbitrage Tagging, NIV Tagging and/or PAR Tagging.

c. Total System Repriced Adjustment Volume of Buy Items (TSRVA_j) and Sell Items (TBRVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) but which were Classified as Second-Stage Flagged and therefore subject to the Replacement Price.

d. Total System Originally-priced Adjustment Volume of Buy Items (TSOVA_j) and Sell Items (TBOVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) and were not Classified as Second-Stage Flagged and therefore not subject to the Replacement Price.

13: The actual Indicative Net Imbalance Volume (NIV) for each Settlement Period can then be calculated as follows:

NIV_j = ∑_w QSB^w_j – ∑_w (-QSS^w_j)

where

Σ_w represents the sum over all System Actions that are not De Minimis System Actions, and not Arbitrage Tagged System Actions.

14: The remaining offers and bid volumes shall be used in the calculation of the Indicative System Buy Price (SBP_j) as follows:

In respect of each Settlement Period, if the Net Imbalance Volume is not equal to zero and is a positive number, and {Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^m {QBSAB^m_j + Σ^tQSIV^t + QSDC_j + QBDC_j + Σ^J {VGB_j^J} + {IRRAUSB_j}} is not equal to zero, then the System Buy Price will be determined as follows:

SBP_j = {BPA_j} +

{Σ_iΣⁿΣ^k {QAO^kn_ij * POⁿ_ij * TLM_ij} + Σ^m {QBSAB^m_j * BSAP^m_j} + Σ^t {QSIV^t_j * STAP^t_j} + {QSDC_j + QBDC_j} * VoLL} } + Σ^J {VGB^J * QHRRAP^J} + {0 * RRAUSB_j } ________________________________________________________________________________________________________________________________________

{Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^m QBSAB^m_j + Σ^t QSIV^t_j + QSDC_j + QBDC_j } + Σ^J {VGB_j^J} + {IRRAUSB_j}

where

Σ_i represents the sum over all BM Units;

Σ^k represents the sum over all Acceptances;

Σⁿ represents the sum over those Accepted Offers that are not De Minimis Tagged and not Arbitrage Tagged Offers and not NIV Tagged Offers and not PAR Tagged Offers;

Σ^t represents the sum over all STOR actions

POⁿ_ij is the Price for the Offer acceptance n, for BM Unit i and Settlement Period j (which may be the Replacement Price);

Σ^m represents the sum over those Balancing Services Adjustment Buy Actions that are not De Minimis Tagged and not Arbitrage Tagged Actions and not NIV Tagged Actions and not PAR Tagged Actions;

Σ^J represents the sum over all Quarter Hour Volume GB Need Met in the Final Ranked Set of System Buy Actions; and

BSAP^m_j is the Price for the Balancing Services Adjustment Buy Action m for Settlement Period j (which may be the Replacement Price); and

BPA_j is the Buy-Price Price Adjustment; and

The System Sell Price SSP_j = SBP_j.

15: The remaining offers and bid volumes shall be used in the calculation of the Indicative System Sell Price (SSP_j) as follows:

In respect of each Settlement Period, if the Net Imbalance Volume is not equal to zero and is a negative number, and {Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^m {QBSAS^m_j} + Σ^J {VGB_j^J} + {RRAUSB_j} is not equal to zero, then the Indicative System Sell Price will be determined as follows:

SSP_j = {SPA_j} +

{Σ_iΣⁿΣ^k {QAB^kn_ij * PBⁿ_ij * TLM_ij} + Σ^m {QBSAS^m_j * BSAP^m_j}} + Σ^J {VGB^J * QHRRAP^J} + {RRAUSB_j * 0} ________ ______________________________________________________________________________

{Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^m QBSAS^m_j} + Σ^J {VGB_j^J} + {RRAUSB_j}

where

Σ_i represents the sum over all BM Units;

Σ^k represents the sum over all Acceptances;

Σⁿ represents the sum over those Accepted Bids that are not De Minimis Tagged and not Arbitrage Tagged Bids and not NIV Tagged Bids and not PAR Tagged Bids;

PBⁿ_ij is the Price for the Bid acceptance n, for BM Unit i and Settlement Period j (which may be the Replacement Price):

Σ^m represents the sum over those Balancing Services Adjustment Sell Actions that are not De Minimis Tagged and not Arbitrage Tagged Actions and not NIV Tagged Actions and not PAR Tagged Actions;

Σ^J represents the sum overall Quarter Hour Volume GB Need Met in the Final Ranked Set of System Buy Actions;

BSAP^m_j is the Price for the Balancing Services Adjustment Buy Action m for Settlement Period j (which may be the Replacement Price); and

SPA_j is the Sell-Price Price Adjustment; and

The System Buy Price SBP_j = SSP_j.

15a: If, for any Settlement Period,

if the Net Imbalance Volume is equal to zero or is a positive number,

if {Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^mQBSAB^m_j + Σ^tQSIV^t + QSDC_j + QBDC_j} + Σ^J {VGB_j^J} + {RRAUSB_j} is equal to zero,

then SBP_j = SSP_j = Market Price (MP_j)

If, for any Settlement Period,

if the Net Imbalance Volume is equal to zero or is a negative number,

if {Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^mQBSAB^m_j} + Σ^J {VGB_j^J} + {RRAUSS_j} is equal to zero,

then SBP_j = SSP_j = Market Price (MP_j)

15b: If, for any Settlement Period,

Σ_sQXP_sj = 0,

where

Σ_s represents the sum over all Index Providers;

QXP_sj is the Market Index Volume for Index Providers and Settlement Period j

Then

if the Net Imbalance Volume is not equal to zero or is a positive number,

if {Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^mQBSAB^m_j + Σ^tQSIV^t + QSDC_j + QBDC_j} is equal to zero,

then SBP_j = SSP_j = 0

if the Net Imbalance Volume is not equal to zero and is a negative number,

if {Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^mQBSAS^m_j} is equal to zero,

then SBP_j = SSP_j = 0

16: The price adjustment parameters shall be set through the automatic interface BMRA-I014, as directed by the NETSO. Note that if no adjustment data has been provided for Settlement Period j then a value of zero will be used for SPA and BPA.

The system parameters like RPAR_d, PAR_d, Arbitrage Flag, DMAT_d, CADL_d and VoLL are received from BSCCo Ltd through the manual flow BMRA-I012.

Market Index Data is received from Market Index Data Providers through the automatic flow BMRA-I015.

Where no Market Index Data has been provided by a Market Index Data Provider, at the point where the Indicative Calculation is carried out, for a given Settlement Period, then the BMRA will generate a warning message (see BMRA-F007).

The BMRA shall, for the purposes of performance reporting, record details of those cases where:

1. A value of zero was used for Market Index Price and Volume for a Settlement Period, for the purposes of the Indicative Calculation

2. A Market Index Provider has failed to supply Market Index Data for any given Settlement Period, such that a default price and volume of zero are used for that Settlement Period, for the purposes of the Indicative Calculation.

The BMRA shall for the purposes of reporting, record a Price Derivation Code (PDC_j) for each Settlement Period. This code will describe how the Indicative SBP and SSP were calculated. The possible values for the code, and their associated meaning, are defined in Appendix G.

Non-Functional Requirement:

Interfaces:

BMRA-I001, BMRA-I002, BMRA-I006, BMRA-I012, BMRA-I014, BMRA-I015, BMRA-I031, BMRA-I036.

Man/auto:

Manual

Frequency:

Ad hoc

Volumes:

N/a

Functional Requirements:

1. When the BMRA is advised of an Outage by the NETSO it shall carry out the following procedures in order to avoid publishing erroneous Settlement data:

a) If an Outage is planned, the BMRA shall receive a prior warning from the NETSO detailing the expected date and time of the Outage. For those unplanned Outages, the BMRA will be informed of the date and time as soon as possible after the Outage has commenced.

b) The BMRA shall inform BSCCo that Settlement calculations shall be suspended during the planned Outage.

c) From the time at which the Outage commenced (if it was planned), or as soon as possible after it commenced (if the Outage was unplanned) the BMRA shall disable its automatic calculation processes. In the case of an unplanned Outage the BMRA shall also send confirmation to BSCCo that calculations have been suspended.

d) During the Outage, the BMRA shall load and report any Bid-Offer and Physical Notification data received from the NETSO as normal.

e) When the Outage has ceased, the BMRA shall receive and load the backlog of Bid-Offer Data issued by the NETSO. Once the backlog has been received and loaded, the automatic calculation processes shall be re-enabled to operate on the first Settlement Period affected by the Outage.

f) The BMRA will then inform BSCCo that calculations have resumed, and confirm the Settlement Periods that have been affected.

2. During an Outage the BMRA reporting service shall continue to operate as normal.

3. In cases where an unplanned Outage has led to the calculation processes being disabled after the first Settlement Period of the Outage (and therefore incorrect data has been published), the BMRA is not required to re-calculate and correct the data on the BMRS once the Outage has ceased. For the avoidance of doubt, note that the BMRA may, at its discretion, re-calculate and correct the data.

4. In the event that the date and time of an Outage changes from that already notified by the NETSO, a further warning shall be issued to the BMRA containing the revised date and time.

Non-Functional Requirements:

Interfaces:

No interfaces are defined for the interactions with the NETSO and BSCCo. These will take the form of email or telephone calls.

Issues:

Man/auto:

Automatic

Frequency:

On demand.

Volumes:

Functional Requirements:

The BMRA shall validate Market Index Data, on receipt, to ensure that the Market Index Volume equals, or exceeds the Liquidity Threshold for the relevant Market Index Data Provider, Settlement Day, and Settlement Period. If the Market Index Volume is non-zero and below the defined threshold, then the BMRA will default the invalid Market Index Volume, and its associated Market Index Price, to zero for that Settlement Period.

The occurrence of below threshold, non-zero Market Index Data is recorded by the BMRA for the purposes of performance reporting.

Unless a specific clock change day Liquidity Threshold has been submitted, then, where a Liquidity Threshold is defined for a range of days that spans a ‘long’ or ‘short’ day, the following rules will be applied:

For a ‘short’ day, having 46 Settlement Periods (i.e. the spring clock change when 1am GMT changes to 2am BST):

• Settlement Periods 1 to 2 (00:00 to 01:00 GMT) of the ‘short’ day take the values of Settlement Periods 1 to 2 (00:00 to 01:00 local time) of the ‘normal’ day data;

• Settlement Periods 3 to 46 (02:00 to 24:00 BST) of the ‘short’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day data;

• Settlement Periods 3 and 4 of the ‘normal’ day data are not used on a short day.

For a ‘long’ day, having 50 Settlement Periods (i.e. the autumn clock change when 2am BST changes to 1am GMT):

• Settlement Periods 1 to 4 (00:00 to 02:00 BST) of the ‘long’ day take the values of Settlement Periods 1 to 4 (00:00 to 02:00 local time) of the ‘normal’ day data;

• Settlement Periods 5 to 6 (01:00 to 02:00 GMT) of the ‘long’ day take the values of Settlement Periods 3 to 4 (01:00 to 02:00 local time) of the ‘normal’ day data;

• Settlement Periods 7 to 50 (02:00 to 24:00 GMT) of the ‘long’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day data.

Non-Functional Requirements:

Interfaces:

BMRA-I011, BMRA-I015

Requirement ID:

BMRA-F007

Status:

Mandatory

Title:

Generate Missing Market Index Data Messages

BSC reference:

P78

Man/auto:

Automatic

Frequency:

Once, for each settlement period.

Volumes:

Functional Requirements:

The BMRA shall, for each Settlement Period, identify those Market Index Data Providers which are active for that Settlement Period, but have not submitted Market Index Data by the time that BMRA commences calculating the Indicative System Buy and Sell Prices – i.e. those cases where the calculation will use default values.

A warning message will be generated for each Market Index Data Provider so identified.

The Warning message will include:

Settlement Day

Settlement Period

Market Index Data Provider Identifier

Market Index Data Provider Name

Message detailing that the MIDP has not submitted Market Index Data in time for the Indicative Calculation, and therefore the Market Index Price and Market Index Volume have been defaulted to zero for that MIDP and Settlement Period

Non-Functional Requirements:

Interfaces:

BMRA-I005

Requirement ID:

BMRA-F008

Status:

M

Title:

Process Market Index Data Provider Liquidity Thresholds

BSC reference:

P78

Man/auto:

Manual/Automatic

Frequency:

On demand.

Volumes:

Functional Requirements:

The BMRA shall carry out the following validation on MIDP Liquidity Thresholds:

(a) That there is no impact on retrospective dates;

(b) Where the Action is ‘Insert’, then the effective date range of the Liquidity Threshold record must not overlap with any existing record for that MIDP;

(c) Where the Action is ‘Update’, then the ‘Effective From Settlement Date’ must match the Effective From Settlement Date of an existing Liquidity Threshold record for that MIDP;

(d) Where the Action is ‘Delete’, then the ‘Effective From Settlement Date’ must match the Effective From Settlement Date of an existing Liquidity Threshold record for that MIDP.

Where a Liquidity Threshold record fails validation then it is rejected, and the details of the rejection are reported back to BSCCo.

After applying an update, or set of updates, for a given MIDP, the Liquidity Threshold data for current and future dates is reported back to BSCCo, using the BMRA-I017 flow.

Amendments to Liquidity Thresholds will not be applied to existing Market Index Data.

Non-Functional Requirement:

Interfaces:

BMRA-I016, BMRA-I017

Requirement ID:

BMRA-F009

Status:

M

Title:

Validate Adjustment Data

BSC reference:

P78, P217

Man/auto:

Automatic

Frequency:

On demand.

Volumes:

Functional Requirements:

For Settlement Dates prior to the P217 effective date the BMRA shall validate Adjustment Data, on receipt, to ensure that:

1. One of Energy SVA and Energy BVA must be zero;

2. One of System SVA and System BVA must be zero.

Where this is not the case, then the BMRA will generate an exception to the NETSO (via the BMRA-I010) detailing the reason for the exception, and will not load data for the offending Settlement Period.

For Settlement Dates on or after the P217 effective date the BMRA shall validate the following Adjustment Data items:

Net Energy Buy Price Cost Adjustment (EBCA) (£)

Net Energy Buy Price Volume Adjustment (EBVA) (MWh)

Net System Buy Price Volume Adjustment (SBVA) (MWh)

Net Energy Sell Price Cost Adjustment (ESCA) (£)

Net Energy Sell Price Volume Adjustment (ESVA) (MWh)

Net System Sell Price Volume Adjustment (SSVA) (MWh)

Where they are found to be non-zero, the BMRA will set the values to zero and pass the details of the validation failure to BSCCo.

Non-Functional Requirement:

Interfaces:

BMRA-I014, BMRA-I010

Requirement ID:

BMRA-F011

Status:

M

Title:

Process SO-SO Trades

BSC reference:

CP1333

Man/auto:

Automatic

Frequency:

Continuously

Volumes:

Up to 20 prices per Interconnector per hour (received as one file per Interconnector per hour) plus occasional resends and corrections of data (up to an extra 10% volume)

Functional Requirements:

The BMRA shall carry out the following activities to process and prepare for publication information relating to SO-SO Trades:

1. The BMRA shall use the Resource Provider, Acquiring Area, Connecting Area and Resolution Codes to identify the SO-SO Trade Type to which the SO-SO price in each interval element of BMRA-I025 relates.

2. The effective date and time of each SO-SO price shall be determined from the Time Interval element of BMRA-I025, this time being the start time of the block to which the price relates. For example, a price that relates to 04:00 – 05:00 on 26 June 2011 would be notified with a time of 2001-06-24 04:00:00.

3. Individual Bids and Offers shall be identified using the Contract Identification and Direction elements, with a stack of multiple prices being built up for each block.

4. The currency in which each price is provided shall be determined from the currency element in BMRA-I025, validated against the expected of currencies for that price received in BMRA-I026.

5. The energy price value and quantity associated with each SO-SO trade shall be determined from the Energy Price and Qty elements in BMRA-I025. The quantity shall represent a MWh level while energy price shall represent a price value in the currency relevant for that SO-SO Trade Type (i.e. £/MWh or €/MWh).

6. The previous steps shall result in a set of Bids and Offers each comprising the following data items:

• SO-SO Trade Type

• Effective date and time

• Direction

• Contract Identification

• Quantity

• Energy Price

7. Following successful processing the information shall be published on the BMRS in accordance with BMRA-I005.

Non-Functional Requirement:

Interfaces:

BMRA-I025, BMRA-I026, BMRA-I005

Requirement ID:

BMRA-F012

Status:

M

Title:

Process Settlement Exchange Rate

BSC reference:

P344

Man/auto:

Manual

Frequency:

Daily

Volumes:

Functional Requirements:

The BMRA shall carry out the following activities to process and prepare for publication information relating to the Settlement Exchange Rate:

1. By 16.00 each day, the BMRA shall retrieve the latest average GBP-EUR Exchange Rate from the Exchange Rate provider.

2. The BMRA shall record the latest average exchange rate as the Settlement Exchange Rate for use on the following Settlement Day.

3. Following successful processing, the information shall be published on the BMRS in accordance with BMRA-I037 and shall include:

• Settlement Exchange Rate

• Settlement Day

• Date and time retrieved

3. BMRS Users shall be able to retrieve this information through the API.

4. Where data is not available at the time of initial upload; the BMRA shall repeat the retrieval process a number of times until 16.00 on the given day. Where no data is available by 16:00; the published Settlement Exchange Rate shall default to the value for the previous Settlement Day.

Non-Functional Requirement:

Interfaces:

Operator Interface; SAA-I053

BMRA-I001

Receive Registration Data

I

CRA

Automatic

BMRA-I002

Receive Balancing Mechanism Data

I

NETSO

Automatic

BMRA-I003

Receive System Related Data

I

NETSO

Automatic

BMRA-I004

Publish Balancing Mechanism Data

O

BMR Service User

Automatic

BMRA-I005

Publish System Related Data

O

BMR Service User

Automatic

BMRA-I006

Publish Derived Data

O

BMR Service User

Automatic

BMRA-I007

SAA/ECVAA Balancing Mechanism Data

O

SAA, ECVAA

Automatic

BMRA-I010

Data Exception Reports

O

NETSO, CRA, BSCCo Ltd, MIDP

Automatic

BMRA-I011

Performance Reports

O

BSCCo Ltd

Manual

BMRA-I012

Receive System Parameters

I

BSCCo Ltd

Manual

BMRA-I013

BMRA BSC Section D Charging Data

O

BSCCo Ltd

Manual

BMRA-I014

Receive Adjustment Data

I

NETSO

Automatic

BMRA-I015

Receive Market Index Data

I

MIDP

Automatic

BMRA-I016

Receive Market Index Data Provider Thresholds

I

BSCCo Ltd

Manual

BMRA-I017

Report Market Index Data Provider Thresholds

O

BSCCo Ltd

Manual

BMRA-I018

Receive Credit Default Notices

I

ECVAA

Automatic

BMRA-I019

Publish Credit Default Notices

O

BMR Service User

Automatic

BMRA-I020

Receive BM Unit Fuel Type List

I

NETSO

Manual

BMRA-I021

Receive Temperature Reference Data

I

NETSO

Manual

BMRA-I022

Receive Daily Energy Volume Reference Data

I

NETSO

Manual

BMRA-I023

Receive Wind Generation Registered Capacities

I

NETSO

Manual

BMRA-I024

Large Combustion Plant Directive Spreadsheet

I

BSCCo Ltd

Manual

BMRA-I025

SO-SO Prices

I

NETSO

Automatic

BMRA-I026

SO-SO Standing Data

I

NETSO

Manual

BMRA-I027

Settlement Report

I

SAA

Automatic

BMRA-I028

REMIT Data

I

BMR Service User

NETSO

Automatic

BMRA-I029

Transparency Regulation Data

I

NETSO

Automatic

BMRA-I030

Publish REMIT Data

O

BMR Service User

Automatic

BMRA-I031

Publish Transparency Regulation Data

O

BMR Service User

ENTSO-E

Automatic

BMRA-I034

Trading Unit Data

I

SAA

Automatic

BMRA-I035

Publish Trading Unit Data

O

BMR Service User

Automatic

BMRA-I036

Receive Replacement Reserve Data

I

NETSO

Automatic

BMRA-I037

Publish Replacement Reserve Data

O

BMR Service User

Automatic

Man/auto:

As required

Frequency:

As required.

Volumes:

As required

Non Functional Requirement:

1: A secure site shall be provided for the systems required to support the Internet web based access of the BMRA Service. The systems and data shall be protected against unauthorised access and corruption of data.

Note: Refer to GEN-N002 for common security requirements

Interfaces:

Issues:

Requirement ID:

BMRA-S001

Status:

Mandatory

Title:

High Grade BMRA Service Availability

BSC reference:

BMRA SD 1.4, 1.5, 1.6, 3.1, 4.2, B5, B6, B7. BMRA SCH 4 Part B section 2.2.3., CP703, P291, P295

Man/auto:

Automatic

Frequency:

See below.

Volumes:

See below.

Non Functional Requirement:

1: The BMRA central system shall receive, store and publish data on the high grade service continually as it is submitted by the NETSO, ECVAA or BMR service users.

2: Published data shall be “pushed” in near to real-time to interested BMR service users over high performance private lines in accordance to service level delivery times.

3: Published data shall be made available to all interested BMR service users at the same time.

4: Published data shall be presented to BMR Service Users as continuous real-time parameterised BM reports/screens, screen trading reports and BM data reports. Published data shall be received by interested BMR service users as a real-time feed and automatically update the relevant screen(s) displaying the data (if it is open). The visual representation of the data (i.e. graph, text) will automatically update to reflect the newly received data values.

5: Published data shall be identifiable at a component level (i.e. bid-offer data) so that BMR service users can select which data component to subscribe and display.

6: Published data shall be available to BMR Service Users:

• Forecast data: forecasts relating to future dates and periods will be available

• System Warnings: warnings will be available for 7 days from receipt

• Credit Default Notices: Level 1 and Level 2 Default Notices will be available as long as the default is in force, or until the associated BSC Party is withdrawn from the BSC. Cleared Notices will be available for 30 days (parameterised) from receipt

• REMIT data messaged will be available for a period of 3 years after the calendar day to which it relates

• Transparency data data will be available for a period of 5 years after its initial receipt

• All other data: data will be available for one year after the Settlement Date to which it relates

7: Drill-down facilities and intuitive on-screen cues shall be used to ensure that all information in the rolling seven day/1 year period can be readily accessed.

8: Published data shall be published on a near real-time message (or programmatic) interface, which may be used for integration with BMR service user proprietary systems.

9: The BMR Service User main screen shall load within 10 seconds (subject to client PC hardware and LAN satisfying minimum specification).

10: If the BMR Service User requests to view a different screen, the requested screen shall display within 1 second of request (subject to client PC hardware satisfying minimum specification).

11: If the BMR Service User requests to subscribe to different data, the requested data shall begin to download within 1 minute of request

12: High grade users will retrieve historical data through the web interface, they shall also have the ability to download BMRA data.

13: Credit Default Notices will be removed from the BMRA Screens when instructed by ELEXON (e.g. when a party is removed from the BSC or when a dispute is upheld). When Credit Default Notices are removed in this way, no explicit message will be sent to BMR Service Users to indicate removal of the notice.

Interfaces:

Issues:

The requirement for pictorial data has been discussed, but a specific requirement has not been agreed. Section 1.4 of the BMRA SD states that short term forecasts may be presented in a graphical or pictorial format. In the absence of an agreed format for pictorial data, short term forecasts shall be presented graphically.

Man/auto:

Automatic/ Manual

Frequency:

See below.

Volumes:

See below.

Non Functional Requirement:

1: Published data shall be made available on a publicly available Internet web site. The availability and performance of this service shall be commensurate with standard Internet web sites.

2 Published data shall be refreshed on the source web page. The BMR Service User shall refresh the screen by manually re-loading the web page.

3: Published data shall be available:

• Forecast data: forecasts relating to future dates and periods will be available

• System Warnings: warnings will be available for 7 days from receipt

• Credit Default Notices: Level 1 and Level 2 Default Notices will be available as long as the default is in force, or until the associated BSC Party is withdrawn from the BSC. Cleared Notices will be available for 30 days (parameterised) from receipt.

• REMIT data data will be available for a period of 3 years after the calendar day t which it relates

• Transparency data data will be available for a period of 5 years after its initial receipt

• All other data: data will be available for one year after the Settlement Date to which it relates

All received and derived data shall be downloadable in a standard format (e.g. comma delimited ASCII file)

4: Low grade users will have the ability to download data and retrieve historical data through the web interface.

5: Credit Default Notices will be removed from the BMRA Screens when instructed by ELEXON (e.g. when a party is removed from the BSC or when a dispute is upheld). When Credit Default Notices are removed in this way, no explicit message will be sent to BMR Service Users to indicate removal of the notice.

Interfaces:

Issues:

Man/auto:

Automatic

Frequency:

As required.

Volumes:

See below.

Non Functional Requirement:

Both the High Grade BMRA Service and the Low Grade BMRA Service shall store all received and derived data on a rolling basis:

• Forecast data: all forecasts relating to future dates and periods will be stored

• System Warnings: warnings will be stored for 7 days from receipt

• Credit Default Notices: Level 1 and Level 2 Default Notices will be stored as long as the default is in force, or until the associated BSC Party is withdrawn from the BSC. Cleared Notices will be stored for 30 days (parameterised) from receipt.

• REMIT data data will be stored for at least 3 years after the calendar day to which it relates

• Transparency data data will be stored for at least 5 years after its initial receipt

• All other data: data will be stored for one year after the Settlement Date to which it relates

Interfaces:

Issues:

Man/auto:

Automatic

Frequency:

As required.

Volumes:

As required

Non Functional Requirement:

1: BMR service software shall be used to provide selective data reports, through on-line screens, to enable BMR Service Users to select, display and download a range of Balancing Mechanism information. Historic access to BM Unit related data shall allow BMR Service Users to retrieve Settlement Period related data relating to multiple BM Units in a single query. A single Settlement Period’s data shall be provided for up to 50 BM Units or up to a whole Settlement Day’s data may be provided for a single BM Unit.

2: The BMRA shall provide an authenticated access facility to allow BMR Service Users to submit REMIT data, ensuring that only users with appropriate permissions are able to do so.

3: BMR Service software shall make use of the most appropriate format, i.e. text, graphical or pictorial, for display of data. (See appendix C for more information.)

Interfaces:

Issues:

Man/auto:

Manual & Automatic

Frequency:

As required

Volumes:

As below.

Non Functional Requirement:

The BMRA shall be sized in accordance with the following volumetric requirements. Required traffic volumes are unknown at present; these will be agreed when the current performance modelling work is completed.

*Concurrent users/connections supported

Interfaces:

Issues:

Man/auto:

Automatic

Frequency:

As required

Volumes:

As below.

Non Functional Requirement:

1: The BMRA central system shall provide a continuous unmanned 24x7 service, to enable support of the high grade BMRA service’s near real-time reporting requirements. All software components of the high grade BMRA service shall run on a very high availability and resilient dual processor architecture which support an automatic fail over capability if either processor node was to fail.

The very high availability architecture shall support no single point of failure, with transparent fail-over of applications, storage and files.

2: The health of all application processes (in the high grade BMRA service) and system resources shall be continuously monitored. On detection of error, a pre-determined set of actions shall be performed. Examples of actions taken can include restarting a failed process and warning of critical resource shortages (disk, memory, CPU).

3: The continuous receipt of inbound data from the NETSO must not be lost or duplicated in the event of a failure.

Interfaces:

Issues:

1.1 - 1.3

Overview sections, therefore no mapping of requirements

1.4

BMRA-S001

1.5

BMRA-S001

1.6

BMRA-S001

BMRA-S002

1.7

GEN-S007

2

Overview section, therefore no mapping of requirements

3.1

BMRA-I002

BMRA-S001

BMRA-S002

4.1

BMRA-S003

4.2

BMRA-S001

BMRA-S003

5.1

BMRA-S002

BMRA-S003

5.2

BMRA-S005

6.1

BMRA-I001

6.2

BMRA-I010

7.1

BMRA-I003

BMRA-I005

BMRA-I010

7.2

BMRA-I014

7.3

BMRA-I012

7.4

BMRA-I004

7.5

BMRA-I002

7.6

BMRA-I002

8.1

BMRA-I012

8.2

BMRA-I012

8.3

BMRA-I012

8.4

BMRA-I012

9.1

BMRA-I006

9.2

BMRA-F001

9.3

BMRA-F001

9.4

BMRA-F001

9.5

BMRA-F001

9.6

BMRA-F001

9.7

BMRA-F001

9.8

BMRA-F001

BMRA-F002

BMRA-F003

BMRA-F004

9.9

BMRA-F004

9.10

BMRA-F001

9.11

BMRA-F001

9.12

BMRA-F001

9.13

BMRA-F004

9.14

BMRA-F001

9.15

BMRA-F001

9.16

BMRA-F001

9.17

BMRA-F002

9.18

BMRA-F004

9.19

BMRA-F004

9.20

BMRA-F004

9.21

BMRA-F004

10.1

GEN-S005

B1

BMRA-S007

B2

BMRA-I001

B3

BMRA-I003

B4

BMRA-I002

B5

BMRA-S001

B6

BMRA-S001

B7

BMRA-S001

B8-15

GEN-N005

GEN-N006

CR 65

BMRA-I013

P8

BMRA-I005

P18A

BMRA-I006

P71

BMRA-I002

BMRA-I004

BMRA-I007

P78

BMRA-F004

BMRA-F004a

BMRA-F004b

BMRA-F006

BMRA-F007

BMRA-F008

BMRA-F009

BMRA-I001

BMRA-I005

BMRA-I006

BMRA-I010

BMRA-I011

BMRA-I014

BMRA-I015

BMRA-I016

BMRA-I017

CP703

BMRA-I018

BMRA-I019

BMRA-S001

BMRA-S002

BMRA-S003

CP736

BMRA-I006

BMRA-I011

CP975

BMRA-I001

P219

BMRA-I003

BMRA-I005

P220

BMRA-I003

BMRA-I005

P226

BMRA-I024

P243

BMRA-I003

BMRA-I005

CP1333

BMRA-F011

BMRA-I025

BMRA-I026

P291

BMRA-I028

BMRA-I030

BMRA-S001

BMRA-S002

BMRA-S003

P295

BMRA-F010

BMRA-I029

BMRA-I031

BMRA-S001

BMRA-S002

BMRS-S003

P321

BMRA-I034

BMRA-I035

Trading Unit Data

Publish Trading Unit Data

P344

BMRA-I036

BMRA-I037

Replacement Reserve Data

Publish Replacement Reserve Data

2-14 days ahead (TSDFD) Transmission System demand forecast

5.1.3 TSDFD

6.1.3

By 1500hrs each day

Data for D+2 to D+14

Tabular and graphic (½ hour average MW value for the peak of the day)

2-14 days ahead (NDFD) National demand forecast

5.1.2 NDFD

6.1.3

By 1500hrs each day

Data for D+2 to D+14

Tabular and graphic (½ hour average MW value for the peak of the day)

2-52 weeks ahead (TSDFW) Transmission System demand forecast

5.1.3 TSDFW

6.1.2(b)

By 1500hrs each Thursday

Data for Week+2 to Week+52

Tabular and graphic (½ hour average MW value for the peak of the week)

2-52 weeks ahead (NDFW) National demand forecast

5.1.2 NDFW

6.1.2(a)

By 1500hrs each Thursday

Data for Week+2 to Week+52

Tabular and graphic (½ hour average MW value for the peak of the week)

2-14 days ahead (SPLD) National surplus forecast

5.1.1 OCNMFD

6.1.4

By 1600hrs each day

Data for D+2 to D+14

Tabular and graphic (½ hour average MW value for the peak of the day)

2-52 weeks ahead (SPLW) National surplus forecast

5.1.1 OCNMFW

6.1.2A(c)

By 1600hrs each day

Data for Week+2 to Week+52

Tabular and graphic (½ hour average MW value for the peak of the week)

2-156 weeks ahead (SPLY) National surplus forecast

5.1.1 OCNMF3Y

6.1.4B(d)

By 1600hrs each day

Data for Week+2 to Week+156

Tabular (½ hour average MW value for the peak of the week)

2-14 days ahead National Generating Plant Demand Margin

16.2.1 OCNMFD2

6.1.4(e)

By 1600hrs each day

Data for D+2 to D+14

Tabular and graphic (½ hour average MW value for the peak of the day)

2-52 weeks ahead National Generating Plant Demand Margin

16.2.1 OCNMFW2

6.1.2A(e)

By 1600hrs each day

Data for Week+2 to Week+52

Tabular and graphic (½ hour average MW value for the peak of the week)

2-156 weeks ahead National Generating Plant Demand Margin

16.2.1 OCNMF3Y2

6.1.4B(e)

By 1600hrs each day

Data for Week+2 to Week+156

Tabular (½ hour average MW value for the peak of the week)

Output Usable Data

National 16.1.2

NOU2T14D 6.1.4(a)

NOU2T52W 6.1.2 (a)

NOU2T3YW 6.1.4B(a)

By 1600hrs each day Data for D+2 to D+14

By 1600hrs each day Data for Week+2 to Week+52

By 1600hrs each day Data for Week+2 to Week+156

Download (½ hour average MW value for the peak of the day)

By Fuel Type 16.1.3

FOU2T14D 6.1.4A(b)

FOU2T52W 6.1.2A(b)

FOU2T3YW 6.1.4B(b)

By 1600hrs each day Data for D+2 to D+14

By 1600hrs each day Data for Week+2 to Week+52

By 1600hrs each day Data for Week+2 to Week+156

Graphic and download (½ hour average MW value for the peak of the day)

By Fuel Type and BM Unit 16.1.4

UOU2T14D 6.1.4A(c)

UOU2T52W 6.1.2A(c)

UOU2T3YW 6.1.2A(c)

By 1600hrs each day Data for D+2 to D+14

By 1600hrs each day Data for Week+2 to Week+52

By 1600hrs each day Data for Week+2 to Week+156

Download (½ hour average MW value for the peak of the day)

Initial Day ahead National demand forecast (NDF)

5.2 NDF

6.1.5(a)

By 0900hrs each day

Data for the following Operational Day (D+1)

Tabular and graphic (½ hour average MW values).

Initial Day ahead transmission system demand forecast (TSDF)

5.2 TSDF

6.1.5(b)

By 0900hrs each day

Data for the following Operational Day (D+1)

Tabular and graphic (½ hour average MW values).

Initial Day ahead Zonal transmission system demand forecast (TSDF)

5.2 TSDF

6.1.5(c)

By 0900hrs each day

Data for the following Operational Day (D+1)

Tabular, graphic and pictorial (½ hour average MW values).

Initial National Day ahead Indicated Margin (MELNGC)

5.3 MELNGC

6.1.6(a)

By 1200hrs each day

Data for the following Operational Day (D+1)

Tabular or graphic (½ hour average MW values).

Initial National Day ahead Indicated Imbalance (IMBALNGC)

5.3 IMBALNGC

6.1.6(b)

By 1200hrs each day

Data for the following Operational Day (D+1)

Tabular or graphic (½ hour average MW values).

Initial National Day ahead Indicated Generation (INDGEN)

5.3 INDGEN

6.1.6(c)

By 1200hrs each day.

Data for the following Operational Day (D+1)

Tabular or graphic (½ hour average MW values).

Initial National Day ahead Indicated Demand (INDDEM)

5.3 INDDEM

6.1.6(d)

By 1200hrs each day.

Data for the following Operational Day (D+1)

Tabular or graphic (½ hour average MW values).

Updated Day ahead National demand forecast (NDF)

5.3.1 NDF

6.1.6(e)

By 1200hrs each day

Data for the following Operational Day (D+1)

Tabular or graphic (½ hour average MW values).

Updated NETSO Transmission System Demand Forecast (TSDF)

5.3.1 TSDF

6.1.6(f)

By 1200hrs each day

Data for the following Operational Day (D+1)

Tabular or graphic (½ hour average MW values).

Current Day and Day Ahead Updated Market Information (MELNGC, IMBALNGC, INDGEN, INDDEM, NDF and TSDF)

National 5.3.1

NDF 6.1.8(a)

MELNGC 6.1.8(b)

IMBALNGC 6.1.8(c)

INDDEM 6.1.8(d)

INDGEN 6.1.8(e)

TSDF 6.1.8(k)

By 0200hrs Data for 0200D to 0500D+1

By 1000hrs Data for 1000D to 0500D+1

By 1600hrs Data for 0500D+1 to 0500D+2

By 1630hrs Data for 1630D to 0500D+1

By 2200hrs Data for 2200D to 0500D+2

Tabular, graphic and pictorial (½ hour average MW values).

Current Day and Day Ahead Updated Market Information (MELNGC, IMBALNGC, INDGEN, INDDEM and TSDF)

Zonal 5.3.2

TSDF 6.1.8(f)

MELNGC 6.1.8(g)

IMBALNGC 6.1.8(h)

INDDEM 6.1.8(i)

INDGEN 6.1.8(j)

By 0200hrs Data for 0200D to 0500D+1

By 1000hrs Data for 1000D to 0500D+1

By 1600hrs Data for 0500D+1 to 0500D+2

By 1630hrs Data for 1630D to 0500D+1

By 2200hrs Data for 2200D to 0500D+2

Tabular, graphic and pictorial (½ hour average MW values).

Initial National Demand Out-turn (INDO)

7.0 INDO

6.1.13

Within 15 minutes of the end of the settlement period

Data for previous Settlement Period

Tabular and graphic

Initial Transmission System Demand Out-turn (ITSDO)

7.0 ITSDO

6.1.13

Within 15 minutes of the end of the settlement period

Data for previous Settlement Period

Tabular and graphic

System warnings (SYS_WARN)

SYSWARN

n/a

Within 15 minutes of issue to MCUSA signatories

n/a

Textual

SO-SO Prices

SOSO

n/a

By 15 minutes before the start of each hour

Data for next hour

Tabular

Temperature (TEMP)

14.0 TEMP

6.1.15

By 1700hrs each day

Data for the previous Operational Day (D-1)

Tabular and graphic

Reference Temperature (REFTEMP)

N/A

6.1.16

By 1700hrs each day

Data for the previous Operational Day (D-1)

Tabular and graphic

Wind Generation Forecast (WINDFOR)

15 WINDFOR

6.1.17

By 1700hrs each day

Data for D to D+2

Tabular and graphic

Instantaneous Generation by Fuel Type (FUELINST)

12 FUELINST

6.1.18

Every 5 minutes

Data for previous 5 minutes

Tabular and graphic

Half Hourly Generation by Fuel Type (FUELHH)

12.FUELHH

6.1.19

Within 15 minutes of the end of the settlement period

Data for previous Settlement Period

Tabular and graphic

Non-BM STOR (NONBM)

16 NONBM

6.1.22

Within 15 minutes of the end of the settlement period

Data for previous Settlement Period

Tabular and graphic

System Frequency (FREQ)

13 FREQ

6.1.23

Every 2 minutes

Data for previous 2 minutes

Tabular and graphic

Initial National Demand Out-Turn Daily (INDOD)

7 INDOD

6.1.21

By 1700hrs each day

Data for the previous Operational Day (D-1)

Tabular and graphic

Reference Initial National Demand Out-Turn Daily (REFINDOD)