BSC Panel 212a

BSC Panel 212a

9 May 2013

DECC: Update on Electricity Market

Reform

Alice Douglas/ David Osborne9 May 2013

Settlement Agent for FIT Contracts for Difference

Update for BSC Panel

9 May 2013

Alice Douglas

» Both for Contracts for Difference and Capacity Mechanism

» Announced in OJEU for transparency

» No challenges to designation received

» Designation through Code and Licence changes using powers in the Energy Bill – after Royal Assent

BSCCo to be designated as EMR Settlement Agent

Anticipate that Settlement Agent will carry out measurement and

payment functions

Measurement

Receive data

Metered output

Market share

Calculate

payments

Calculate

collateral

Mechanics of payment

Invoicing

Collection of collateral

Monitoring payment

Reconciliation

Data dispute

management

» Contracts for Difference regime in place in 2014Consultation on draft secondary

legislation autumn 2013Secondary legislation introduced to

Parliament early 2014Counterparty to be designated mid

2014CfD payments may be required from

end 2014» System design and set-up: up to 18

months

Challenging timescales to meet

» Clear that BSC Parties should not shoulder the cost of EMR

» Elexon’s enduring CfD settlement role will be funded by the Counterparty (operational costs to be recovered from suppliers)

» Significant set-up cost for CfD systems» DECC will pay a grant to Elexon to

compensate for the work undertaken by Elexon in preparation for its anticipated statutory role

» Potential efficiencies with Capacity Market being considered

BSC Parties will not cover cost of EMR

» Aiming for 4-6 weeks but some risks exist.

» Monthly payments in advance – ‘trued up’ against actual spend

» Milestone payments for work by external contractors.

Grant terms under development

» Monthly reports to DECC and BSC Panel» Fortnightly DECC/Elexon project

management discussions at ‘working level’

» Role of skeleton team for Counterparty Body

» Programme Board for delivery to be established – membership TBC

Governance and transparency

Ofgem: Update on Longer Term

Settlement Reform

Jonathan Amos9 May 2013

Smarter Markets Programme:Electricity settlement project

BSC Panel meeting9 May 2013

Jonathan Amos and Grant McEachran

12

Background – Smarter Markets Programme

Smarter energy markets

Smarter Markets Programme:• Change of supplier• Electricity settlement• Demand-side response• Consumer empowerment and

protection

Other Ofgem and Government policy, as well as industry activity

We aim to have reforms in place as soon as reasonably practicable and by the end of roll-out at the latest

13

Way forward – scoping reform

• Existing issues• Future outcomes

1. SCOPING THE PROBLEM

2. SCOPING THE APPROACH

• Objectives• Scope• Process

Our work will provide a robust platform for progressing any reforms

Conclude by Q1 2014

14

Why do we need to scope out reform?

RISK 1.

Ofgem is best placed to mitigate both risks by scoping reform

Drivers of reform are not fully understood

Incentives of industry may not be sufficiently aligned with those of consumers

RISK 2.

Reform does not deliver for consumers

15

Opportunities to get involved in our work

APR MAY JUN JUL AUG SEP

SET UP

Explain our work & discuss approach to engagement

Relevant forums & bilateral discussions

PROBLEM DEFINITION

Bilateral discussions & workshop

Identify existing issues and future outcomes

APPROACH

Workshop

Discuss scope and objectives

16

Questions

We would welcome views on:• our planned approach to scoping out reform• how we can involve the BSC Panel in our work

17

Report on Progress of Modification

Proposals

Adam Lattimore9 May 2013

19

Modifications Overview

New Issue 46, Issue 47Definition -Assessment P283, P291Report P292With Authority P272, P286

Authority Determined -

Self-Gov Determined -

212a/04P292 ‘Amending

Supplier & Meter Operator Agent

responsibilities for smart Meter

Technical Details’Simon Fox

9 May 2013

21

P292 BackgroundMeter Technical Details

• MTDs record for Smart Meters will record• Physical attributes of the Meter• Smart capabilities of the Meter• Current Configuration of the Meter

• MOAs use MTDs to manage any requested work on site

• NHHDCs use MTDs to validate Meter reading data for Settlement, in particular the mapping of the physical registers on the meter to the logical registers used in profiling to allocate energy to the correct time of use periods

• LDSOs and Suppliers use MTDs to translate Register Read information received on D0010

22

P292 BackgroundLegacy NHH MTD Arrangements

• MOA• install & maintain Meters via site visit when requested by

Suppliers• responsible party for maintaining MTDs, including any

configurations• forward MTDs to any other participant who requires this

information e.g. NHHDCs, MOAs or LDSOs

• Suppliers• responsible for ensuring its appointed MOA carries out the

above

23

P292 BackgroundDECC SMIP Principles

For Smart Meters• Meter Operators

• Will install & maintain Meters via site visit when requested by Suppliers

• Will no longer configure Metering Equipment

• Suppliers• Will be responsible for recording and maintaining the current

configurations of each SMS device• Will, once the SMS is configured, forward on these

configuration settings to any other participant who requires this information e.g. NHHDCs, MOAs or LDSOs

• become the data owner and responsible party for all MTDs

24

• This group met seven times between 27 Feb 12 and 12 Feb 13• Took as its starting point option 2 (of 5) in the Smart Metering

Implementation Programme (SMIP)s ‘Legacy Systems Changes’ paper – Supplier distributes MTD using existing flows

• Also reviewed the SMIP requirement to amend the installation request to include other smart metering equipment and what the response flow should be

• By incorporating other smart equipment in the ‘device details’ flow, and making a distinction between device details (MOA responsibility) and configuration details (Supplier details) and non-smart / smart flows arrived at CP1388 (effectively Option 5 in the ‘Legacy Systems Changes’ paper)

• Issued a consultation on solution elements (e.g. new flows, installation requests/responses) in Oct 12.

P292 Background:BSC-MRA Working Group

25

• E.ON raised P292 to address the need for the BSC to

• reflect the new obligations on MOAs and Suppliers - of Suppliers establishing and sending MTDs; and

• enable the necessary changes to Code Subsidiary Documents

P292Issue

26

• Proposed Solution, amend

• Section S to reflect that Suppliers are responsible for ensuring the establishment and maintenance of MTDs for smart NHH Metering Systems and that these are passed to other parties, rather than MOAs; and

• Section X to include a definition of the Smart Metering Equipment Technical Specification

P292Proposed Solution

27

• Report Phase

• CP1388

• Implementation - June 2014 BSC Systems Release

• The Case for Change - Applicable BSC Objective (d)

• Recommendations - To approve, but not under self-governance

P292Panel’s Initial Views

28

P292Report Phase Consultation Responses (1)

Report Phase Consultation Questions Yes NoDo you agree that the draft legal text, in Attachment A, delivers the intention of P292? 6 2

Do you agree with the Panel’s suggested Implementation Date? 5 3

Do you agree with the Panel’s view that P292 better facilitates the achievement of BSC Objective (d)?

6 2

Do you agree with the Panel’s view that the Proposed Modification shouldn’t be progressed as a self-governance modification?

7 1

Do you agree with the Panel’s views that the Proposed Modification should be approved? 5 3

29

• The majority of respondents agree that the draft legal text delivers the intention of P292 • some minor amendments

• Arguments against proposed legal text• Section L2.4 already sets out the responsibility of the Supplier

for establishing, maintaining and providing MTDs, which it can delegate to its agents

• to capture the concept of compliance at time of installation• the SMETS may undergo changes under the SEC, so the BSC

should also reference the SEC


30

• The majority of respondents support the Implementation Date

• Arguments against • Potentially unknown detailed solution• Alignment with DCC go-live date

• Arguments for• Provides framework to be in place in time for mass roll-out of Smart

Meters• Enables any changes to CSDs to come into effect at the same time


31

• The majority of respondents agree that P292 would better facilitate Applicable BSC Objectives (d)

• Arguments against • Significant costs in system changes, with potentially limited duration• Unknown scope & impact of SEC on Settlement

• Arguments for• Enables Suppliers & NHHMOAs to fulfil future responsibilities• Reduction in number of parties involved in distributing the data• Only one that fitted

• BSC Objective (c)


32

• The majority of respondents agree that P292 shouldn’t be subject to self-governance

• Arguments against • Changes Party obligations• Could result in wasteful use of resources in an appeal to the Authority

• Arguments for• P292 is an enabler to facilitate the change to how current obligations

will be delivered for smart Meters• Transfers obligations, not create new ones


33

• The majority of respondents agree that P292 should be approved

• Arguments against • Already allowed for under Section L• Preferred / wish to be able to discuss alternatives• Not minimal change• Concern over reference to CP1388

• Arguments for• Aligns with SMIP operating model• Drive efficiency, timeliness, accuracy and reduce risk• Allow CSD changes


34

NHHMOAs will be responsible for sending MTDs for Smart Meters to the NHHDC. This will mean that

• The BSC would not be in line with SMIP operating model

• Impact on CPs against CSDs; and

• Supplier to provide configuration details to the NHHMOA / NHHMOA act as a “post box” to provide the MTDs to the NHHDC and Supplier• This in turn will create greater risk to Settlement, as there will be no

defined processes or assurance in place

P292Consequences if P292 is not approved

35

• We invite the Panel to• NOTE the P292 Draft Modification Report and the Report

Phase Consultation responses;• CONFIRM the recommendation to the Authority contained in

the P292 draft Modification Report that P292 should be made as it would better facilitate Applicable BSC Objective (d);

• APPROVE an Implementation Date for P292 (if approved) of 26 June 2014;

• APPROVE the BSC legal text for P292; and• APPROVE the P292 Modification Report or INSTRUCT the

Modification Secretary to make such changes to the report as the Panel may specify.

P292Recommendations

212a/05Request to raise a

Modification: ‘Changes to BSC Section H ‘Audit’ and

BSC Service Description for BSC Audit to reflect current

Practice’David Barber

9 May 2013

37

• The current Balancing and Settlement Code (BSC) Audit contract comes to an end on 30 September 2013

• The new contract for the BSC Audit and

Qualification Service Provider starts on 01 October 2013

• ELEXON is currently undertaking a competitive tender process to appoint the new BSC Auditor and Qualification Service Provider.

Background

38

• The Issue: • As part of the procurement project, ELEXON has reviewed BSC

Section H5 ‘Audit’ and the Service Description for BSC Audit and identified minor changes which require updating to reflect current processes, services and terminology

• Proposed Solution:• To reflect the current processes and services, the minor changes

identified in the Code and Service Description need to be made

Modification Proposal (1 of 2)

39

• PAB recommendation to raise this Modification• Details of the changes provided to the PAB in March for

comment• PAB recommended that the Modification is raised to align the

BSC and the BSC Service Description for BSC Audit with current practice and the new BSC Audit and Qualification Service Provider contract from commencement on 01 October 2013

• Additional minor housekeeping changes• In addition to the changes agreed by the PAB, we have

included minor Housekeeping changes to both BSC Section H and the BSC Service Description

Modification Proposal (2 of 2)

40

• Modification Proposal better facilitates the achievement of BSC Objective (d):• Ensures consistency between the Code, Service

Description and current practice• Ensures that the Code and Service Description align

with the new contract commencing on 01 October 2013

Applicable BSC Objectives

41

• Recommend: Report Phase – approve

• Merits of Proposal are self-evident:• Believe it is self-evident that inconsistencies currently exist in

both the BSC and the Service Description compared to the current process.

• Recommend Implementation Date of:• 1 October 2013 in line with the commencement of the new

BSC Audit and Qualification Service contract.

Proposed Progression (1 of 2)

42

• We are requesting Self-Governance

• We believe Proposal meets Self-Governance Criteria:• No material impact on consumers, competition, the

Transmission System or BSC governance• Corrects inconsistencies between the Code, Service

Description and current practice • No impacts on BSC Parties or those subject to BSC Audit

• Will issue Self-Governance Statement to Authority and seek views of Report Phase Consultation respondents

Proposed Progression (2 of 2)

43

We invite the Panel to:• RAISE the Modification Proposal in Attachment A;• SUBMIT the Modification Proposal directly to the Report

Phase;• AGREE a provisional view that the Modification should be

made;• AGREE a provisional Implementation Date of 1 October 2013

in line with the commencement of the new BSC Audit and Qualification Service Provider contract;

• AGREE the draft legal text in Attachment B;• AGREE the draft changes to the BSC Service Description for

BSC Audit in Attachment C;• AGREE a provisional view that the Modification Proposal

meets the Self-Governance Criteria; and• AGREE that the Draft Modification Report should be issued for

consultation and submitted to the Panel at its meeting on 13 June 2013.

Recommendations

Minutes of Meetings 211, 210, and Actions

ArisingAdam Richardson

9 May 2013

Chairman’s ReportBSC Panel

Andrew Pinder

9 May 2013

212a/01ELEXON Report

Peter Haigh

9 May 2013

Distribution Report

David Lane

9 May 2013

National Grid Update

Shaf Ali

9 May 2013

European Update: Ofgem

Lisa Charlesworth

9 May 2013

212a/01aReport from the ISG

9 May 2013

212a/01bReport from the SVG

9 May 2013

212a/01cReport from the PAB

9 May 2013

212a/01dReport from the TDC

9 May 2013

212a/01eReport from the JESG

9 May 2013

212a/01fReport from the PSRG

9 May 2013

212a/02Trading Operations

Report

14 February 2013

212a/03Change Report

14 February 2013

212a/06Scope and Terms of

Reference for Funding Shares Audit

Darren Draper

9 May 2013

BSC Funding Shares Audit Scope

• Funding Shares used to charge ELEXON’s costs to Trading Parties

• Funding Shares Audit required by the BSC

• Panel required to agree scope of Audit

• Scope is limited to calculation of Funding Shares - costs separately audited

• Funding Share data accompanying ELEXON’s invoices can be checked against the website and assistance is always available from the Finance Team

•

• Calculation of Main Funding Shares, SVA (Consumption) Funding Shares, SVA (Production) Funding Shares, and General Funding Shares (on a default basis)

• Calculation of Annual Funding Shares (used by FAA)

• Checking of BSC Cost shares through to invoices

BSC Funding Shares Audit Scope

The Panel is invited to:

• APPROVE the proposed scope of the Funding Shares Audit

Recommendations

212a/07Moving to ‘User Pays’

billing for Data Transfer costs and development of the ELEXON Portal to

deliver DTS FlowsMatthew Wood

9 May 2013

63

• Over the last 2 years there have been significant price increases for those using the DTS, increases which have driven up costs for BSC Parties. These DTS price increases have taken annual spending from (circa) £800k in 2011/12 to £1m in 2012/13.

• ELEXON has the responsibility to look at ways of making operational efficiencies where possible and this has lead to us considering how we can reduce these DTS costs for BSC Parties. This has lead to two areas being considered;

• Firstly the use of an alternative mechanism for providing SVAA sent DTS Flows to parties. This involves parties being able to select to receive DTS Flows via the DTN, the ELEXON Portal, or a combination of both.

• Secondly ensuring that costs incurred through using the DTN are allocated to those who benefit from the service, this has led to the consideration of charging for the services on a ‘user pays’ basis.

212a/07 - Background

64

• ELEXON (through SVAA) incur charges in 2 ways;

• DTS Traffic – monthly charge on a £ per MB basis• Gateway Rental/Maintenance – Annual Charges

• The BSC requires ELEXON to socialise our costs across all Parties by market share including those Parties who do not receive DTS Flows over DTN.

• We have been looking at a way of ensuring that costs incurred for using the DTN are allocated to those benefit from the service, this has lead to the consideration of charging for the services on a ‘user pays’.

• This would mean raising a Modification to the BSC allowing ELEXON to charge the recipients of DTS Flows sent from SVAA on a £ per MB basis, as well as allocating other fixed charges on a proportional basis.

212a/07 - Modification

65

• ELEXON is aware that changing from the existing socialised cost to a ‘user pays’ basis would impact some Parties charges while reducing others’ and removing some Parties charges altogether.

• However we are currently examining the feasibility of using an alternative mechanism for providing SVAA sent DTS Flows to parties.

• At a high level this would involve SVAA operating a ‘Flow Manager’ whereby parties can select to receive DTS Flows via the DTN, the ELEXON Portal, or a combination of both.

• By placing DTS Flows on the ELEXON Portal for collection this would reduce a Parties’ charges under a ‘user pays’ basis.

212a/07 - Innovation

212a/07 - Potential New Process

67

• We invite the Panel to;

• NOTE the work being undertaken by ELEXON to consider a ‘user pays’ Modification and develop our requirements for the alternative delivery mechanism;

• NOTE that ELEXON will engage with BSC Parties and relevant Panel Committees over the next 2 months; and

• NOTE that ELEXON will provide a further update to the Panel in July.

212a/07 - Recommendations

European Network Code Application

Robert Wilson

9 May 2013

Place your chosen image here. The four corners must just cover the arrow tips. For covers, the three pictures should be the same size and in a straight line.

European Network Codes:RfG GB Grid Code Application Options

Summary of Presentation to JESG17 April 2013

70

Summary Background Assumptions / Starting Point Differences between the ENTSO-E RfG and GB Grid

Code Implementation Options Advantages / Disadvantages Summary Views from JESG Members / Other Options

71

Enabling renewables

Creating clear

connection rules.

Providing harmonisation to benefit

manufacturers.

Creating markets to

reduce risks.

Ensuring security of

supply

A coordinated approach to

system operations.

Greater optimisation to enhance efficiency.

More flexible markets (e.g. balancing).

Enhancing competition

A single market design across Europe

(in all timescales).

Promoting cross border

trade & enhancing liquidity.

Reducing risk for all

market players

3rd Package Intended Benefits

Security of supply

Competitiven

ess

Sustainabilit

y

Introduction to Network CodesDecember 2012

72

ENC High Level Interactions

Market Codes

Capacity Allocation & Congestion

Management

Forward Markets

Balancing

Market Codes


Management

Forward Markets

Balancing


Management

Forward Markets

Balancing

Market Codes

Operational Security

Operational Planning & Scheduling

Load Frequency Control & Reserves

Operational Codes

Requirements for Generators

Demand Connection Code

HVDC

Connection Codes

Poss

ible

mar

ket s

plitti

ng

LCFR provides framework & Balancing takes actions

Balancing across interconnectors

Coordinated planning

Offshore generation

Generator actions

Loss of infeed

Capacity limits

Freq

uenc

y co

ntro

l

Generation / Demand

equivalent rules

Common structures and

issues; different

timescales

Frameworks & application

Demand side

response

73

Development Progress Delivery of the Third Package

CACM FCA EB RFG DCC HVDC OS OPS LFCR

Formal invitation to develop Network Code 21/09/12 21/12/12 Q1/Q2-13

Public Consultation Period Begins* 01/02/13

Public Consultation Closes 03/11/12 07/01/13

Oct-13 Jan-14 04/01/13 Mar-13 Apr-13 Jun - 13

19/12/12 13/10/12ACER opinion published

Comitology Begins

Appr

oval

Deve

lopm

ent

Scop

ing EC invites ACER to develop Framework Guidelines

ACER Public consultation begins

Final Framework Guidelines published

Exte

nsiv

e St

akeh

olde

r En

gage

men

t

Final version submitted to ACER*

74

ENC DevelopmentNetwork Code Content

Requirements for Generators Sets functional requirements which new generators connecting to the network (both distribution and transmission) will need to meet, as well as responsibilities on TSOs and DSOs .

Demand Connection Sets functional requirements for new demand users and distribution network connections to the transmission system, basic Demand Side Response capabilities, as well as responsibilities on TSOs and DSOs.

HVDC Sets functional requirements for HVDC connections and offshore DC connected generation.

Operational Security Sets common rules for ensuring the operational security of the pan European power system.

Operational Planning & Scheduling Explains how TSOs will work with generators to plan the transmission system in everything from the year ahead to real time.

Load Frequency Control & Reserves Provides for the coordination and technical specification of load frequency control processes and specifies the levels of reserves (back-up) which TSOs need to hold and specifies where they need to be held.

Capacity Allocation & Congestion Management

Creates the rules for operating pan-European Day Ahead and Intraday markets, explains how capacity is calculated and explains how bidding zones will be defined.

Balancing Sets out the rules to allow TSOs to balance the system close to real time and to allow parties to participate in those markets.

Forward Capacity Allocation Sets out rules for buying capacity in timescales before Day Ahead and for hedging risks.

Con

nect

ion

Cod

esSy

stem

Ope

ratio

n C

odes

Mar

ket

Cod

es

75

Why is GB application complex?The following needs to be considered for all European Network Codes

(ENCs): Length of the implementation period; Potential requirement to coordinate with adjoining TSOs (and

NRAs); GB Implementation should be consistent across all codes with RfG

being the first. Consideration where the application requires subsequent ENCs to

be implemented in order to facilitate full enforcement; Range of legal instruments which require amendment. The structure of the current GB Grid Code is very different to that

of the proposed ENTSO-E RfG The Generation Thresholds in GB are very different to those is

Europe – there is significant overlap with the Distribution Code

7676

Implementation Option Considerations

Consideration must be given to the following points: All Codes (G Code / D Code) are to be fully consistent with the

requirements of the ENTSO-E RfG The proposals should be designed in the best interests of all

Stakeholders (Generators, DNOs, Transmission Owners System Operators and conventional customers (including Residential))

Minimise the number of Industry Codes that each party is required to comply with

Ensure contractual arrangements between appropriate parties is in place (Not for RfG implementation but an important factor)

7777

High-level RfG Implementation Options(from options paper)

Option 1 - write new code to cover ENC requirements but retain existing grid code as well. End up with two documents to maintain but on the plus side, it will be easier to interpret for existing non-captured users. Probably less pressure on the codes to converge than some of the other options which is both good and bad.

Option 2 - amend the GB Grid Code to include ENC requirements. Sits between options 1&4 but no separate advantages.

Option 3 - remove all ENC-related provisions from the GB Grid Code and create a stand-alone EU relevant document. End result similar to option 1 but messy realisation.

Option 4 - rewrite the Grid Code completely. A neater solution while potentially time-consuming. Retrospective application will be more of an issue

Option 5 - combine the GB Grid Code and GB Distribution Code. Could be used in conjunction with any of the other options. May be employed later.

Option 6 - amend the GB Grid Code to cross-refer directly to the RfG ENC. Not workable given the required Member State specificity contained within the ENCs

Options 1 & 4 to be taken forwards – which are in the first instance identical.

7878

The Industry Framework / ObligationsTransmission

GenerationLicences

SupplyLicences

DistributionLicences

GridCode CUSC

Bi-lateralAgreements

ChargingStatements

SevenYear

Statement

TransmissionLicence

BSC

1989 Electricity Act2000 Utilities Act2004 Energy Act

STC

TransmissionLicensees

7979

SupplyLicences

DistributionLicences

GridCode

CUSC

Bi-lateralAgreements

ChargingStatements

Licence Condition 10

BSC

1989 Electricity Act2000 Utilities Act2004 Energy Act

DCode

ConstructionAgreements

ConnectionAgreements

LEEMPS

Connectee

The Industry Framework / ObligationsDistribution

8080

Thresholds

Under the ENTSO-E Provisions Type A – C Power Generating Modules are connected below 110kV and ranging in size between 800 W – 30MW.

Type D is any Power Generating Module which is connected at or above 110kV or above 30MW.

In summary Type A – C Power Generating Modules will be connected to the Distribution Network and need to comply with the requirements of the Distribution Code

Type D Generating Modules will either be directly connected and need to comply with the requirements of the Grid Code or Embedded and need to meet the requirements of the Distribution Code and Grid Code.

81

Or putting it another way…GB Generator Banding/Thresholds Existing requirements – as stated in Grid Code and SQSS:

Note: In Scotland, transmission voltages are ≥132kV In England & Wales, transmission voltages are ≥275kV

RfG banding (GB Synchronous Area):

Note: No geographic specificity Much smaller generators captured by code (down to domestic user levels)

SHET SPT NGETSmall <10MW <30MW <50MW

Medium 50-100MWLarge 10MW+ 30MW+ 100MW+

Generator Size

Direct Connection to:

RfG Type Generator Capacity

Connection Voltage

A 800W-1MW <110kVB 1-10MW <110kVC 10-30MW <110kVD 30MW >110kV

82

Implementation Options

Option I – Place all the Type A – D RfG requirements in the GB Grid Code

Option II – Place all the Type A – C RfG requirements in the Distribution Code / Engineering Recommendations and all the Type D RfG requirements in the Grid Code

Option III – Place Type A – D RfG requirements in a set of Engineering Recommendations and reference Grid Code and Distribution Code to this

All options assume that the current Codes would need to be frozen for existing Generators.NB A further outcome, being a compromise between II and III depending on the technical issue may also be possible.

838383

Option I Place all requirements in Grid Code

Grid Code

Type A:800W-1MWand <110kV

European law: European Network Codes

UK law and network codes

Type B:1-10MW

and <110kV

Type D:>30MW

or >110kV

Type C:10-30MW

and <110kV

Distribution Code(shell and reference) Type D, DNO connected

84

Option I Place all requirements in Grid Code

AdvantagesAll Type A – D RfG Requirements reside in one documentRetain structure of existing GB Code and amend Generator clauses to ensure consistency with RfG Approach could be applied to other European Codes (eg HVDC and DCC)Removal of Regional Differences with Scotland

DisadvantagesHigh volume of current Small Power Stations would need to access the Grid

Code and other industry codes, resulting in complexity and high administrative burden

Contractual complexityGrid Code becomes very cumbersomeInteraction with DNO’s requires further examination

Legal text has been developed for a number of examples associated with this Option

85

Examples Prepared – Option I(All obligations Type A – D included in Grid Code)

Frequency Range – No substantial change required to GB Code other than change to definitions.

Voltage Range – No substantial change required to GB Code other than Glossary and Definitions although there is a consistency issue relating to voltages between 110kV and 132kV.

Voltage Waveform Quality – No change required to GB Code – Quality of Supply issues are not captured in the ENTSO-E RfG

Power Output with Falling Frequency – Code amended to cater for all Type A – D Power Generating Modules. The section on HVDC has been removed although this would need to be re-inserted when the HVDC Code is implemented into the GB Grid Code.

Black Start – Minor amendments introduced, largely relating to the Glossary and Definitions.

Fault Ride Through – Substantial re-write of the existing GB Code. Detailed example written on the basis that all the requirements.

868686

Option IIPlace Type A - C requirements in D Code / ER and Type D in Grid Code

Grid Code

Engineering Recommendation(similar to G59)




Type B:1-10MW

and <110kV

Type D:>30MW

or >110kV

Type C:10-30MW

and <110kV

Distribution Code(shell and reference)

ER(similar to G83)

Type D, DNO connectedDCRP

GCRP

87

Option II Place Type A - C requirements in D Code / ER and Type D in Grid Code

Advantages Retain structure of existing GB Code and amend Generator

clauses to ensure consistency with RfG Approach could be applied to other European Codes (eg HVDC and

DCC – see slide 19) Removal of Regional Differences with Scotland Contractual structure remains similar to current arrangements Clear definition of which code applies to which party

Disadvantages Small number of Users would need to access both G Code and D

Code as per current arrangements, but small number of Users believed to be affected.

888888

Grid Code(shell and reference)




Type B:1-10MW

and <110kV

Type D:>30MW

or >110kV

Type C:10-30MW

and <110kV

Distribution Code(shell and reference)

ENC Requirements – separately defined & with joint DC/GC governance

DCC HVDC SO codes etcRfG

Option IIIPlace Type A - D requirements in ER and G Code / D Code operate as a Shell / Reference

Type D, DNO connected

89

Option IIIPlace Type A - D requirements in ER and G Code / D Code operate as a Shell / Reference

Advantages Avoids some Generators from having to read both G Code and

D Code

Disadvantages Places both the G Code and D Code as a shell in respect of

Generator Requirements. This is current D Code practice but not G Code.

90

Pros and Cons

Colour code:Red – difficult or increases complexity

Amber – some issues

Green - straightforward

Option I: Place all Requirements in GC

Option II: Place Type A - C requirements in DC / ERs,

Type D stays in GC

Option III: Place all Type A - D requirements in ERs;

GC / DC operate as Shells / Reference

Ease of use - users Small generators have to refer to GC with high costs and admin

Clarity of which doc applies to which party will be OK

Probably easier for users

Ease of use - TSO/DNOs DNOs need to refer to GC Little change to current Harder - as multiple docs to maintain and coordinate

Number of documentsSingle document - and removes

need for DC references

Small number of users (type D, DNO connected) would need to refer

to both DC/GC

Multiple documents but does keep all users in either DC or GC

Retains existing codes structureYes, but GC becomes more

cumbersome through extension to more users

YesNo. Fundamental changes and

multiple documents

Retains contractual structure Increases complexity for D-connected gens

Yes Makes it simpler in principle

Applicable to other ENCsYes, straightforward although multiple changes will be reqd Yes, really as is

Yes, and can build in more annexes to DC/GC 'shells' fairly simply

DNO/SO/TO interactions require examination Yes - to cover D-connected usersYes - but requirements should

cascade fairly neatlyInteractions probably straightforward

and covered in DC/GC 'shells'

Removes regional differences with Scotland Yes Yes Yes

Approach

Issue

9191

Views from JESG Members invited:

Thoughts on options - which are preferred? Are there further options? What mechanism for effecting changes to the GB

codes should be used? What strategy is required to handle interactions

between the GB codes? What governance arrangements should be

considered? What major risks or pieces of work can be identified?

Next Meeting:13 June 2013