Settlement of Dynamically Switched Meters

Transcription

1 Public Settlement of Dynamically Switched Meters PSRG31/01 30 April 2014 Jon Spence

2 Health & Safety 2

3 Objective To review draft consultation on Dynamically Switched Meters Ensure all drivers for change have been captured Ensure all options for change have been identified Ensure consultation questions are fit for purpose 3

4 scope SEC /SMETS Mechanism for switching load with smart Meters DCUSA Operating framework between Suppliers and LDSOs (e.g. DCP204 Smart Metering Related Amendments to Schedule 8 Name is required ). BSC Notification of switch times to SVAA 4

5 Drivers for Change

6 Radio Teleswitch Service clock-switched or teleswitched Regimes can be Welcome to Droitwich Static (clock or RTS) Semi-static (clock or RTS) Dynamic (RTS only) RTS commands can be - Programmed (typically day-ahead) Immediate (e.g. DSR load-shedding, little used) 6

7 Dynamic RTS categories Weather (or wholesale price) based e.g. Heatwise Westerglen Load Management (e.g. managing constraints in the highlands and islands of Scotland) Load shedding / boosting (rarely used, a few minutes at a time, not profiled well) Burghead 7

8 Load control features of SMETS meters Auxiliary Load Control Switch (ALCS) or HAN-connected ALCS (HCALCS) ALCS [n] Calendar where n = 1 to 5, supporting up to 5 types of switched load e.g. water heating, heat pump, electric vehicle charging) Up to 200 time and date based switching rules Ad-Hoc Requests Boost Buttons controlled by consumer via user interface ALCS [n] Calendar only determines load switching times Register switching times are defined in the Tariff Switching Table 8

9 Load control via DCC Dynamic switching can be effected by changing the calendar or issuing ad-hoc requests Supplier needs to synchronise ALCS [n] Calendar and Tariff Switching Table DCC has no concept of SSCs or grouping Metering Systems Suppliers will send multiple unicast messages to smart meters Only Suppliers can update the ALCS [n] Calendar and issue ad-hoc commands to the ALCS/HCALCS LDSOs won t have control of switching in initial design 9

10 Volumetrics NHH MPANS = 29,867,136 Switched Load = 5,209,773 Radio Teleswitch = 1,868,249 Dynamic RTS = 616,163 East Midlands 371,066 London 82,732 South Scotland 83,602 North Scotland 78,719 10

11 Implications of change for Settlement NHH Settlement needs a mechanism for accurately allocating profiled energy to the correct Settlement Periods Switch times are monitored centrally by the Teleswitch Agent and notified to the SVAA by the Teleswitch Agent on a daily basis For Smart Meters, switch times will need to be notified to the SVAA by Suppliers (directly or indirectly) if dynamically switched meters continue to be settled in NHH arrangements. 11

12 Implications for Supplier / Customers Existing RTS arrangements don t readily support tariff innovation (no new RTS regimes created since 2004) Existing RTS arrangements don t readily support Supplier-led DSR. Mechanism for allocating an SSC to an Additional BMU has never been used Dynamic tariffs present an imbalance risk to Suppliers (other than Group Code Sponsor) as switch times not notified in advance Smart arrangements could bring improvements in these areas Many Suppliers have few customers on dynamically switched SSCs, offer mirror tariffs and might struggle with the introduction of an obligation to notify switch times Suppliers currently have dynamic load switching carried out for them, so the switching mechanism is all-new functionality (to support low customer numbers in many cases) 12

13 Implications for LDSOs Some LDSOs can avoid network reinforcement costs by dynamic switching In Scotland the Group Code Sponsors supply 90% plus of dynamically switched customers This may be a viable load for network management, even if other Suppliers decide to move customers to (semi-)static regimes or set up their own SSCs Volume of switchable load may fall, if smart meters lead to new Supplier (perhaps national) products and easier switching Co-ordinating dynamic responses across other Suppliers likely to be challenging Day-ahead co-ordination possible (immediate commands not) Some dynamic switching is automated (rule-based) Although LDSOs can t control load via smart meters under the initial design, the Smart Grid Forum (SGF) Workstream Six is not ruling this out as a future option 13

14 Consultation Question 1 Do you agree with the documented opportunities and risks of moving from the RTS arrangements to the smart arrangements? 14

15 Future Changes Demand Side Response Dynamic Time of Use (e.g. Critical Peak Pricing) Other load types (e.g. EV charging) Universal HH Settlement Smart appliances LDSO access to smart load control functions Remote load control by internet / mobile telephony 15

16 Consultation Question 2 Please provide any views on the potential future changes to remote load management and dynamic Time of Use. To what extent and how should the solution for notifying switching times for current RTS Metering Systems on transition to smart metering, take into account future changes? Are there any additional changes that need to be taken into account in the shorter term? 16

17 Options for Change

18 Static / semi-static regimes CURRENT SMART CLOCK-SWITCHED FIXED ALCS [n] CALENDAR RTS static static static semi-static semi-static dynamic VARIABLE ALC [n] CALENDAR and/or AD- HOC COMMANDS dynamic 18

19 Static /semi-static regimes No BSC changes required On smart installation, ALCS [n] Calendar and Tariff Switching Table can be aligned to: existing RTS SSC (terminologically inexact and lose differential between RTS and smart) an existing clock-switched SSC a new clock-switched SSC (via MDD change) Constrains flexibility Benefits of dynamic switching are lost 19

20 Consultation Question 3 Do you believe that any changes are needed to the BSC or BSCPs to accommodate static/semi-static switching using DCC-serviced smart Meters? 20

21 Randomisation Some LDSOs have noted a greater concern with (semi-)static switching than dynamic Clock-drift, though unintentional, avoids load peaks from static clock-switched meters Smart meters will keep good time and can be synched to the DCC clock Smart meters have a Randomised Offset a random number of seconds up to a Randomised Offset Limit Randomised Offset Limit is configurable up to 1799 seconds (up to but excluding 30 minutes) Need to strike a balance, in setting Randomised Offset Limit, between meeting network management needs and accurate Settlement 21

22 Consultation Questions 4 and 5 Does the randomisation functionality of SMETS Meters alleviate the risk that accurate time-keeping presents to network management (e.g. load spikes)? Please describe any other measures that you believe may be required and the Settlement implications of such measures. Should the Randomised Offset Limit be constrained by industry governance to a value lower than the maximum of 1799 seconds (<30 minutes)? If so, should this be a BSC constraint? What would be an appropriate threshold for the BSC to apply? 22

23 High level options for dynamic switching (1 and 2) OPTION 1 - DO NOTHING a mix of: static/semi-static Elective Half Hourly SSCs reflect operating windows (accept errors) OPTION 2 - MANDATE HALF-HOURLY Avoids NHH profiling issues No industry processes for DCC-service Half hourly Ofgem s Settlement Reform workstream looking at universal (or wider) HH Timing issues in terms of roll-out of first ALCS/HCALCS 23

24 Option 3 co-ordinated dynamic switching Group Code Sponsor/RTS Access Provider Internet portal (or other method) DCC ENA Supplier BBC smart meter RTS meter SVAA 24

25 Option 3 co-ordinated dynamic switching No change to BSC / SVAA system Will only work while the RTS infrastructure / Teleswitch Agent remain in place but buys time to introduce universal Half Hourly Doesn t work for immediate commands (although used rarely) Doesn t readily support new dynamic SSCs some dynamic switching may be automatically triggered i.e. driven by bespoke calculation tools feeding into the RTS scheduling RTS SSCs will include non-rts smart meters No differentiation between RTS and smart meters 25

26 Option 4 amend the process for notifying switch times Group Code Sponsor/RTS Access Provider DCC ENA Supplier BBC smart meter RTS meter SVAA 26

27 Option 4 Amend the process for notifying switch times Dynamic SSCs become Supplier specific SVAA receives existing D0277 flow and new flow from each Supplier each day during roll-out When no RTS meters are left, only the new Supplier flows will be received Suppliers notify times from Tariff Switching Table (registers) rather than ALCS [n] Calendar (load) SVAA will need to carry out completeness checks (based on MDD) and chase missing Supplier notifications SVAA will need to apply defaulting rules at Supplier-SSC level Would require a Modification Proposal Supplier specific SSCs could result in high numbers of SSC changes (in the shorter term) 27

28 Standard Settlement Configurations Description count MDD Allowed by format 10,000 In use 738 Available 9,262 RTS SSCs All RTS SSCs 391 Dynamically Switched 98 With associated MPANs 77 Supplier SSC combinations 1,323 Supplier SSC combinations with greater than 100 MPANs

29 Consultation Questions 6 and 7 Please provide comments on the relative merits/drawbacks of the four short-to-medium term options described in Options for Change Section 3. What is your preferred option and why? Are there any other options that we should consider? 29

30 Option 4 variants Responsibility for notifying switch times: Suppliers Group Code Sponsors Central agent Daily Notification v Notification on Change: Daily notification closer to existing RTS arrangement, but contains redundancy Notifying calendar changes or ad-hoc commands, less data, but increased complexity for SVAA Collating Switch Times: Suppliers notify intended switch times Monitoring and interpretation of DCC requests 30 Insert: Document title

31 Consultation Questions 8 and 9 Who should be responsible for notifying switch times and why? How should switch times be notified? Is the Data Transfer Service appropriate for multiple notifications in short timescales? If not, what other communication methods should be considered? 31

32 Consultation Question 10 Should the Supplier (or notification agent) provide daily switch times or only notify switch times by exception? 32

33 Consultation Question 11 Do you agree that notifying intended switch times by Suppliers would be more practical and cost-effective than interpreting individual commands to/responses from smart Meters? Please describe any alternative methods of collating switch times. 33

34 Next Steps

35 Next Steps ELEXON to apply comments from today s meeting ELEXON to issue to PSRG for review (how long?) ELEXON to update with review comments 4 week [?] consultation Reconvene PSRG to review responses Report to the SVG 35

36