Demand Control Event Guidance Notes
v 1.0
Effective From Date:
Status:LIVE
Download
Demand Control Event |
Guidance Note |
|
Summary
What is a Demand Control Event?
In the event that National Electricity Transmission System Operator (NETSO) is unable to meet the current demand on the Total System, either through increased generation or reduction in demand, then Demand Control can be used as a last resort. Grid Code Section OC6 ‘Demand Control’1 details the provisions to be carried out to manage the situation. This enables NETSO to instruct Licensed Distribution System Operators (LDSOs) to reduce demand on their distribution systems, through:
Demand disconnection;
Voltage reduction; and
Automatic Low Frequency Demand Disconnection (ALFDD).
Under these provisions, an LDSO would typically be required to reduce demand in blocks of approximately 5% of its total demand, and is required to respond to NETSO’s instruction within five minutes of it being issued. It is usually left to the LDSO to determine how it achieves the instructed reduction by implementing a pre-determined plan agreed between NETSO and the LDSO, which will often be through a combination of demand disconnection and voltage reduction. A Demand Control Event (DCE) is the term given to the period when Demand Control is in effect. The ALFDD process is delivered automatically based on pre-configured demand reduction patterns.
Settlement Adjustment Processes
Settlement Adjustment Processes (SAPs) were implemented in 2015 as part of P305 ‘Electricity Balancing Significant Code Review Developments’2, a Modification that was raised to progress the outcomes of Ofgem’s Electricity Balancing Significant Code Review (EBSCR)3. One of the EBSCR’s key outcomes was the requirement to add Demand Control actions into the calculation of Imbalance prices. P305 introduced the requirement for Elexon, certain BSC Parties and Party Agents to work together to estimate the amount of electricity that would have been Imported or Exported by disconnected customers. The process then makes sure this is reflected in Trading Parties Imbalance volumes, and ultimately the Imbalance charges they pay.
The reason that SAPs were deemed necessary is that a DCE is an urgent emergency action taken by NETSO, not an action voluntarily taken by a Party and its customers, which may cause Parties’ Imbalance volumes to be longer than they might otherwise have been. A longer Imbalance position multiplied by an abnormally high System Price, driven by the DCE, could result in either a significant payment to Parties or a considerable reduction in their Imbalance Charge, compared to if the DCE had not occurred. SAPs were designed to ensure the accurate calculation of Parties’ Imbalance volumes, reflecting the actions they take (or had planned to take) voluntarily. This means that Trading Parties do not benefit, or suffer, from the effects of a DCE that are outside of their control.
The SAPs involve Metering System level estimates being aggregated to Balancing Mechanism (BM) Unit level and included in Trading Parties’ Imbalance Volumes, as though the DCE was the provision of a Balancing Service by the Trading Party.
Who is involved in SAPs?
The Market Participants involved in DCE SAPs are:
Elexon;
Licensed Distribution System Operators (LDSOs);
National Electricity Transmission System Operator (NETSO);
Half Hourly Data Collectors (HHDC);
Half Hourly Data Aggregators (HHDA);
Non Half Hourly Data Collectors (NHHDC);
Non Half Hourly Data Aggregators (NHHDA);
Supplier Volume Allocation Agent (SVAA);
Settlement Administration Agent (SAA);
Central Data Collection Agent (CDCA); and
Registrant.
Where can I find further Information?
Further details can be found in the following BSCPs:
BSCP03 ‘Data Estimation and Substitution for Central Volume Allocation’;
BSCP502 ‘Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’;
BSCP503 ‘Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS’;
BSCP504 ‘Non Half Hourly Data Collection for SVA Metering Systems Registered in SMRS’;
BSCP505 ‘Non Half Hourly Data Aggregation for SVA Metering Systems Registered in SMRS’;
Information about DCEs and the SAPs can be found in the following BSC Sections:
What happens in the event of a DCE?
NETSO
Within 15 minutes of a DCE commencing, NETSO should notify the Balancing Mechanism Reporting Agent (BMRA) and provide the required information about the DCE – including the Demand Control Event ID (DCE ID).
NETSO should notify CDCA of the DCE, and all disconnected Directly Connected BM Units, via the CDCA-I067 flow within 5 Working Days (WDs) of Elexon determining that SAPs should be completed.
Within 25 WDs of Elexon determining that SAPs should be completed, NETSO should send notification of any MSIDs subject to demand side Non-BM STOR instruction, along with estimated volumes of reduction, to SVAA via the P0241 flow.
Elexon
Within 15 minutes of a DCE commencing, the BMRA should receive notification of the DCE from NETSO. Within one WD of this, Elexon should send notice of the DCE via email to all Category A Authorised Persons from BSC Parties and Party Agents to establish the appropriate operational contact. The Category A Authorised Persons will be used as the contact for the rest of the DCE correspondence unless another contact is provided.
Additionally, Elexon will determine the nature of the DCE, and whether the cost of carrying out the SAPs is outweighed by the benefit to Settlement. This must be done in accordance with the Demand Disconnection Event Threshold Rules. The outcome of this calculation determines whether the SAP should be completed or not, and this is then shared with BSC Parties, Party Agents, and BSC Panel Members.
Should the SAP be required, Elexon would receive details of Disconnected BM Units from the Central Data Collection Agent (CDCA). Within two WDs, Elexon is required to estimate BM Unit Demand Disconnection Volume(s), in accordance with BSCP03 Appendix 4.7, for each impacted Settlement Period and BMU. These Demand Disconnection Volume estimates are then sent to the relevant Registrants. If the Registrant agrees with the BSCCo’s estimate(s), the BSCCo will confirm to the Registrant which estimates are to be submitted, and BSCCo then submit these to the CDCA.
Should the Registrant submit alternative estimate(s), Elexon will consider these. If Elexon agree with these alternative estimate(s), it will confirm the use of the alternative estimate(s) with the Registrant and send these to CDCA. Where the BSCCo disagrees with an alternative estimate(s) provided by the Registrant, BSCCo will contact the Registrant to attempt to reach agreement. Where the BSCCo and the Registrant cannot agree an estimate, the Registrant can invoke the disputes procedure.
Elexon must also act on behalf of LDSOs by forwarding on notification of the P0238 flows (MSIDs affected by DCE) to HHDCs, HHDAs, NHHDCs, NHHDAs, and SVAA.
LDSOs
Within 5 WDs of being informed by Elexon that SAPs should be completed, LDSOs must notify the CDCA of the DCE and all disconnected Embedded BM Units through CDCA-I067 flows).
In this same timeframe, the LDSOs also have to send notification of all affected MSIDs to Elexon. This is done by sending P0238 flow(s) via email to the BSC Service Desk. The Demand Control Event ID (DCE ID) determined by the NETSO should be used by all LDSO when compiling and sending a P0238 to Party Agents. Whilst P0238 flow(s) are sent by the LDSO to Elexon, it should be generated as though it is to be sent directly to Party Agents, i.e. the ‘MPID To’ in the header should reflect the various agents that are intended to receive the file. This is because it will be sent on to the appropriate Party Agents by Elexon.
The P0238 contains details of all MSIDs disconnected by the LDSO, i.e. for a single DCE, a single P0238 is sent by each LDSO to all DCs and DAs. An affected MSID is any MSID that an LDSO disconnects due to a DCE. The period of disconnection should match the length of the DCE as reported by NETSO in its Demand Control Imminent Notification(s), regardless of the actual period of disconnection.
This means the ‘Start Date and Time’ and ‘End Date and Time’ in the P0238 reflect the start and end of the entire Demand Control Event, not intermediary stages or actions within an event. The LDSO should report all MSIDs affected by the same event once between the Start and End Date and Time that represent the beginning and end of the whole event, irrespective of whether the LDSO disconnects and reconnects MSIDs multiple times within the same event.
LDSOs should aim for a single, correct P0238 submission. However, should there be an error in the original file, then LDSOs may submit a revised version which should overwrite the previous version and then be circulated. The LDSO should reuse the original Demand Control Event ID when sending an updated P0238.
Note that the Distribution Connection and Use of System Agreement (DCUSA) allows the LDSO to disclose Confidential Information (as defined in the DCUSA) where the LDSO is required or permitted to do so under a Relevant Instrument. The BSC is a Relevant Instrument for the purpose of DCUSA.
HHDC
Within 19WD of receipt of the P0238 flows from Elexon, the HHDCs should estimate HH Demand Disconnection volume and send to HHDA. This should be sent via D0375 Disconnected MSIDs and Estimated Half Hourly Demand Disconnection Volumes. The HHDC should only send a D0375 where it is appointed to at least one MSID listed in the P0238. Where it is not appointed to any affected MSIDs, the HHDC does not need to send a D0375.
Guidance on populating the D0375 can be found in BSCP502 Appendix 4.2.5.
If required, following receipt of D0375 from SVAA, and in time for next Settlement Run, the HHCD should adjust estimated HH Demand Disconnection volume and send to HHDA via an amended D0375.
HHDA
The HHDA should perform checks for data anomalies during Data Aggregation Run(s), as detailed in BSCP503 Appendix 4.3, and send any Exception Reports to HHDCs and Suppliers. These checks should be completed as late as possible, while still meeting SVAA’s Calendar deadlines, to ensure most recent data from SMRS.
After these checks have taken place, the HHDA must aggregate disconnection data in line with BSCP503 Appendix 4.4. Where disconnection volume is zero, it should report aggregated volume as zero. If the HHDA have invalid BM Unit data, then the consumptions of the metering system(s) associated with that BM Unit should be excluded from the aggregation process.
HHDCs should also send aggregated disconnection data in MWh and in clock-time to SVAA and Supplier according to the SVAA’s Calendar. This information should be sent via the D0376 data flow or the D0378 data flow.
Within 1 WD of the aggregation run, the HHDA should identify any invalid MB Unit data to BSC Service Desk and Supplier using the P0035 Invalid Data flow.
By T-6WD, HHDA should send revised aggregated HH meter data in MWh and in clock-time, for MSIDs to which DA is appointed in SMRS to SVAA. This should be sent using D0040 or D0298. Aggregated estimated HH Disconnection Volumes should also be sent, using the D0376 data flow.
As part of the Timetabled Reconciliation Volume Allocation Run(s) for a Settlement Day (post Initial Volume Allocation Run), the SVAA should request any files that have not been received from the Data Aggregator. By T-6 WDs, HHDA should send the requested files to SVAA. If any files fail validation checks, SVAA will inform HHDA; within 2 WDs of notification, the HHDA should send the corrected file to SVAA or notify SVAA that the file is valid.
NHHDC
If profile data is not received the NHHDC should inform SVAA and await receipt of profile data via the BSC Service Desk.
Following receipt of P0238 and D0018, NHHDC should calculate Estimated Annual Consumption (EAC) and Annualised Advances (AA) for MSIDs affected by the DCE using the method detailed in BSCP504 Appendix 4.9. The NHHDC should then send these EAC/AAs to NHHDA via D0019 data flow.
Following receipt of D0375, NHHDC should (if required) recalculate EAC and AAs for MSIDs affected by Non-BM STOR instruction using the method detailed in BSCP504 Appendix 4.9. The NHHDC should then send these EAC/AAs to NHHDA via D0019 data flow.
NHHDA
The NHHDA should use its internal processes to validate relevant data from NHHDC for each Demand Disconnection impacted MSID. This should be done in accordance with SVAA’s calendar for the relevant Settlement Day.
If consumption data is missing, inconsistent or in error, then the NHHDA should use defaults in accordance with the Code. If non-consumption data is different from SMRS data, then SMRS data should be used. The NHHDA should create an exception record containing invalid data details.
EAC/AA should be used for MSID and when applicable, the EAC/AA default method should be used.
Exception Conditions include:
SMRA / NHHDC mismatch of Profile Class, GSP Group, Standard Settlement Configuration, Supplier Registration, Measurement Class, Energisation Status;
Missing EAC/AA for the SVA Metering System resulting in a default EAC being used. In each aggregation run, where there is no valid EAC/AA, the NHHDA shall use a default EAC;
Unmetered SVA Metering System with an AA;
De-energised SVA Metering System with non-zero AA;
Missing standing data - Data Collector Appointments, Profile Class, GSP Group, Standard Settlement Configuration, Supplier Registration, Measurement Class, Energisation Status.
After validating the NHHDC data, NHHCA should carry out aggregation run for Settlement Day(s) including Demand Control Impacted Settlement Periods. Only MSIDs affected by Demand Disconnection should be used to produce a Disconnection Purchase Matrix (DPM), in accordance with the SVA Rules. Where the NHHDA experiences a problem with an MSID during the data aggregation run, as a result of missing Metering System specific data, this MSID need not be included in the DPM. The DPM must continue to be produced, but a Selective Refresh of data must be requested from SMRS for that MSID within 5 WD.
In accordance with SVAA Calendar, NHHDA should send Disconnection Supplier Purchase Matrix File D0377 to SVAA.
As part of the Timetabled Reconciliation Volume Allocation Run(s) for a Settlement Day (post Initial Volume Allocation Run), the SVAA should request any files that have not been received from the Data Aggregator. By T-6 WDs, NHHDA should send the requested files to SVAA. If any files fail any validation checks, SVAA will inform NHHDA and within 2 WDs of notification, the NHHDA should send the corrected file to SVAA, or notify SVAA that the file is valid.
SAA
After SAA receive BM Unit Supplier Take Energy Volume Data Files from SVAA, it must send an acknowledgement confirming receipt of these file(s) to SVAA via the P0183 Stage 2 NETA Acknowledgement Message. If there is an issue with the file, SAA should send details of the problem to SVAA via P0187 SAA Data Exception Report.
SVAA
Within 1WD of receiving P0241 from NETSO, the SVAA should notify DCs and DAs of any MSIDs subject to demand side Non-BM STOR instruction, along with estimated volumes of reduction. Demand side Non-BM STOR MSIDs will only ever be Active Import MSIDs, therefore any estimated reduced volumes reported by the SVAA will be for active import. This should be sent via the D0375 data flow.
Within 1 WD of receiving P0238 from Elexon, the SVAA should send daily profile data for all Settlement Dates with one or more Demand Control Impacted Settlement Periods to NHHDCs via the D0018.
Once SVAA receives D0377 Disconnection Purchase Data Matrix File from NHHDA they should invoke a Reconciliation Volume Allocation Run. Before invoking the run, SVAA should check that the expected DA files have been received, and then load and validate them.
At least 4 working hours before T-6 WD, if any expected files have not been received then SVAA should notify HHDA or NHHDA and ask them to send the file using P0034. If any file fails validation checks then SVAA should ask DA to assess whether the file is valid using P0035. Until the VAR is invoked, any corrected files received should be re-loaded and validated by the SVAA.
Once GSP Group Take data is received from CDCA, the SVAA should send acknowledgement confirming receipt via P0183.
By T-5 WD SVAA should load and validate incoming CDCA data. If CDCA data missing or invalid then default data should be used. The SVAA should then invoke the Timetabled Reconciliation Volume Allocation Run. As part of this, the SVAA should review the Data Aggregator files and check that the expected files have been received.
If any file does not match the expected details then the SVAA should modify the standing data for this Settlement Day only and, where appropriate, re-load and validate data. The SVAA should also inform the BSC Service Desk. If a file is not received as expected then default data should be used. If more than one file is received from the sender, the SVAA will use the file with the latest creation timestamp in the run. The SVA System must store data relating to the latest Settlement and its associated Reconciliation Volume Allocation Run for each Settlement Day, for subsequent reporting.
The SVAA should retrieve all input data for use in Timetabled Reconciliation Volume Allocation Run(s).
If default data is used in the run, then by T-5 WD the SVAA should send relevant notification to each of the parties listed that default data to be used in the Timetabled Reconciliation Volume Allocation Run. This should be done via P0036 for Suppliers, LDSOs, and Panel. If CDCA data is to be defaulted, the SVAA will not report that this data is being defaulted to any of the parties listed in this step.
Following the Timetabled Reconciliation Volume Allocation Run the SVAA should send BM Unit Supplier Take Energy Volume Data Files to the SAA for receipt by 09:00hrs on T-4 WD. This data should be sent via the P0182, P0237, and P0236 data files. By 12:30hrs on T-4 WD the SVAA should send the relevant reports to NETSO via P0210.
By T-3 WD the SVAA should send the remaining Timetabled Reconciliation Volume Allocation Run Report to LDSO via D0030 and D0369, to Host LDSO via D0314 and D0372, and to Suppliers via D0030, D0369, D0043, D0079, D0081, D0082, D0371.
Each LDSO will receive a single D0030 dataflow containing data for customers connected to their Distribution System(s) in all the GSP Groups in which the LDSO is operating. Host LDSOs will additionally receive a D0314 dataflow containing data for all embedded networks operated by other LDSOs in the GSP Group corresponding to their distribution services area. The exception to this is any directly-connected networks which SVAA has been requested to exclude from the report to the Host LDSO. Such a request should be made to the BSC Service Desk, identifying the LLFC(s) corresponding to the directly connected network, at least 5 WDs in advance.
The Disconnection related SVAA reports (i.e. D0369, D0370, D0371, D0372, D0373 and D0374) are designed to allow more than one DCE to be reported for a single Settlement Date. In practice, the SVAA will aggregate all disconnection related volumes and report them against the first DCE of the Settlement Date.
CDCA
The CDCA should forward details of Disconnected BM Units to Elexon using CDCA- I067 within 1 WD of LDSOs or NETSO notifying the CDCA of the DCE, all disconnected Embedded BM Units and/or disconnected Directly Connected BM Units.
Once Elexon submits the estimated BM Unit Demand Disconnection Volume(s) to the CDCA, the CDCA shall submit the estimated data to Settlement and send confirmation to the Registrant and Elexon. This should be done using CDCA-I068 at least 1 WD prior to next Settlement Run.
The CDCA should send GSP Group Take data to SVAA using P0012 by T-6 Working Days.
Registrant
Within 3 Working Days of receiving estimates of Demand Disconnection Volume(s) from Elexon the Registrant should agree or disagree with the estimated values. Where the Registrant disagrees with the estimated values, they may submit their own for consideration. This can be done via the forms in BSCP03 Appendix 4.3 Estimated Demand Control Volume – Part 1 form, which must be signed by an Authorised person, and BSCP03 Appendix 4.4 Demand Disconnection Volume Data Estimation/Substitution Sheet.
Intellectual Property Rights, Copyright and Disclaimer The copyright and other intellectual property rights in this document are vested in Elexon or appear with the consent of the copyright owner. These materials are made available for you for the purposes of your participation in the electricity industry. If you have an interest in the electricity industry, you may view, download, copy, distribute, modify, transmit, publish, sell or create derivative works (in whatever format) from this document or in other cases use for personal academic or other non-commercial purposes. All copyright and other proprietary notices contained in the document must be retained on any copy you make. All other rights of the copyright owner not expressly dealt with above are reserved. No representation, warranty or guarantee is made that the information in this document is accurate or complete. While care is taken in the collection and provision of this information, Elexon Limited shall not be liable for any errors, omissions, misstatements or mistakes in any information or damages resulting from the use of this information or action taken in reliance on it. |