Capacity Allocation And Congestion Management (CACM)

1y ago
372.86 KB
21 Pages
Last View : 3d ago
Last Download : 1y ago
Upload by : Pierre Damon

Capacity Allocation and CongestionManagement (CACM) Code OverviewPlace your chosenimage here. The fourcorners must justcover the arrow tips.For covers, the threepictures should be thesame size and in astraight line.JESG – 25 January 2012CACM Code UpdateWilliam

Introduction Background Market structure: Day ahead Capacity calculation Intraday Impact on GB Current topics of discussion How to get involved NOTE – currently writing the code, therefore can still change 2

Speaker Notes The presentation is based around the AEP informationpack that was send round on the 5th December thatcontained the draft Day Ahead code and a descriptionof the Capacity Calculation code. One note of caution with all of this is that thispresentation covers the current state of play, howeverit is a dynamic environment and things can and dochange!3

Background Create Pan-European electricity market by removing barriers for crossborder trading subject to network constraints Minimal disturbance to current market rulesDay aheadmarket(Auctions)Forward marketIntradayMarket(Continuousmarket)Balancing, Real TimeHarmonised gate closurePhysical market4

Speaker Notes Describes background as to why the push to introduceCACM, ie create a single European wide electricitymarket by trying to remove barriers for cross bordertrade. This is to be done with minimal disturbance toexisting market rules. However CACM only impacts the day ahead andintraday markets. The balancing and futures market isto be covered by other codes. The target model is that the day ahead market is anauction, but the intraday market is continuous.5

Day ahead structureMarketParticipantsPX(MO)Capacities11.00 a.m.CETOrders12.00 rithm)ResultsCapacityCoordinatorComm. ExchangeCalculatorMarket nbidding zonesCentralCounter Party6

Speaker Notes The AEP info pack had draft day ahead network code.The draft network code sets out the structure of themarket. This slide shows the structure in diagram form.Down the Y axis you have time, with the closer to thebottom, the closer to realtime. Along the x axis youhave the different market entities, ie Market Particpants,Power Exchanges (PX) and TSOs. The purple boxesshow each function or task that has to be performedand the black lines indicate the inputs/outputs from thetask. If the purple box is on the blue line, it denotes thatthe function is a PX responsibility, if it is on the red lineit is a TSO responsibility.7

Speaker Notes The first task is to calculate the network capacities available between markets. Thisis done by the Capacity Coordinator function, which is a TSO responsibility. Itpasses this information to the market operator. The market operator is a functionthat is assigned to the PXs. The Market operator takes the network capacityinformation, takes market participants bids and offers (orders) and then followinggate closure (12:00 CET/CEST), runs a market coupling algorithm to solve themarket. It passes these results (net positions and prices for each bidding area) tothe commercial exchange calculator and the market information Aggregator. The commercial exchange calculator turns the market positions into flows betweenmarket areas. It sends this information to the market information aggregator. Themarket information aggregator is responsible for publishing to the market all marketresult data. This is assigned as a TSO responsibility. Finally, both the commercialExchange calculator and the Market Information Aggregator send their informationto the Central Counter Party. This is a TSO function that is responsible for securing and facilitating the tradescross border. Ie if a GB customer buys power from the German power market, theCentral Counter Party facilitates the trade so the GB party does not need to providecollaterals etc. and it is invisible to the GB party where the electricity is comingfrom/selling to.8

Capacity calculation structureMarketParticipantsTSO(SO)Plant availabilityTechnical dataSchedulesPricesNetwork topologyGeneration/DemandSO actionsMerging EntityCommon Grid ModelCoordinatedCapacity Calculator(one entity perregion)Validationwith TSOsCapacities9

Speaker Notes This slide shows the structure of the capacity calculation function. The structure is that market participants supply information to theTSO. (note that within GB, it is not envisaged that this will requiremarket participants to provide any more information than theycurrently supply). TSOs then combine this information with forecast network topologyand a generation and demand scenario. TSOs then send this combined background to the commonEuropean merging entity. This combines the data submissionsfrom all TSOs into a common grid model. The common grid modelis then sent to the Coordinated Capacity Calculator. The Coordinated Capacity Calculator (one per region), models thenetwork and identifies the capabilities between market areas.10

Intraday coupling structureMarketParticipantsID Gate pacityCoordinatorCapacityupdateGCTID Gate ClosureSOBCMMComm. ExchangeCalculatorResultsmax. 1 hPublicationTransactionsbetweenbidding zonesTimeframe: Real TimeCentral CounterParty11

Speaker Notes The first sight of the draft intraday code will be available on 26thJan in advance of the next ENTSO-E stakeholder meeting. The structure is similar to the Day Ahead market and each of thefunctions have a similar role. However a notable differencebetween Intraday and Day Ahead is that the responsibility forpublishing market results is a market operator function, whereas forthe day ahead it was the System Operator. SOB and CMM stand for Shared Order Book and CapacityManagement Module. These are both contained within the MarketOperator function. The Shared Order Book is a European wide listof all cross zonal orders. The CMM is the functionality that storesthe capacities available between market areas.12

Impact on GB Potential for market splitting Market pan European No day ahead or intraday explicit auctions on interconnectors Implementation of flow based methodology may reduce ourinterconnector capacities to Europe Minimal impact to market structure and processes13

Speaker Notes The major impact on GB is that our market could be split. The commissionpresents a slide which has multiple market areas within the GB. If the market were to be split, ultimately the final decision would rest withOfgem. It would not be split without industry consultation and the zoneswould be stable across time periods. Obviously an impact of the CACM code will be that our market will now bepan European. Currently market participants buy and sell capacity on interconnectorsusing explicit auctions. Under CACM all cross zonal capacity is soldimplicitly, therefore these auctions will no longer run and marketparticipants will automatically buy capacity on any links they need throughthe market structure.14

Speaker Notes One impact which is not a consequence of the code,but is due to the implementation method, is that thecapacity available to the markets on our interconnectorsmay well decrease. Generally, all the capacity on thelink is made available to market participants. This isbecause the link is treated ATC. However under theinterim solution, the link may be modelled as a FBconstraint, this will drop the capacity available due toconstraints elsewhere in Europe. Having said all the above, the actual impact on currentmarket structures and processes is minimal.15

Update on previous JESGdiscussion topics Should losses be included in market design?– Yes, at TSO discretion Who is responsible for publishing market results TSO or PX?– Split, Day ahead TSO, Intraday PX Should the source code of the market coupling algorithm bepublically available?– Yes Who should bear the set up costs/operational costs of running themarket?– Everyone (!) How should the code be written? (functional or TSO/PX)- Functional16

Speaker Notes At the previous JESG, I mentioned that the following topics were underdiscussion within ENTSO-E. Here is an update on how the discussionswent. It was decided that losses should be included within the market design,however only where the TSO decides that it is appropriate. Thereforelosses are likely to be only a few DC links between market areas eg IFA,Britned etc. Who should be responsible for publishing market results? – as the slidesshow this has been split between TSOs and PX. Should the source code of the market coupling algorithm be publicallyavailable. ENTSO-E is still including the requirement to publish the sourcecode in the network code. However this is subject to legal approval.17

Speaker Notes Who should bear the set up costs/operational costs ofrunning the market? The Network code as a wholesection on cost recovery and the parties that pay arethe PXs (who would pass it through to marketparticipants) or TSOs through national network tariffs. Previously there was a debate within ENTSO-E as tohow the code should be written, should it be written infunctional form or state that TSOs shall do xyz. As youcan see, the code is written in a functional form.18

Current topics of discussion Should there be a harmonised Intraday gate opening? Should the code prescribe a timetable for algorithm development? Should there be a fall back for intraday? How should capacity pricing be specified within the code?19

How to get involved Get in touch with me Industry meetings 2nd Feb – ENTSO-E/Stakeholders meeting (Brussels)Ruud OtterAnne-Malorie Joint European Standing Group (JESG) Industry consultations Network code consultation (Spring) We will run CACM briefing meetings during consultation phase.20

Any questions?Will Kirk-Wilson01926 65542407554 225984William.kirkwilson@uk.ngrid.com21

The target model is that the day ahead market is an auction, but the intraday market is continuous. 6 Day ahead structure GCT PX (MO) TSO (SO) 12.00 a.m. CET Capacity Coordinator Capacity Coordinator Market Operator (Market Coupling Algorithm) Market Operator (Market . The S

Related Documents:

from RFID devices. Keywords . Traffic congestion, Traffic detection, Congestion management, Active RFID . 1. Introduction . Road congestion is an ever growing problem as the number of vehicles is growing expo. nentially and the road infrastructure cannot be increased proportionally. This leads to increasing traffic congestion. Traffic

(QoS) [5] in a wireless sensor network. In this paper, a congestion control predictor model is proposed for wireless sensor networks, in which three plans, energy control, congestion prevention, and congestion control plan are em

430 allocation to elianto cfd o&m 20,577.32 440 allocation to trillium west cfd o&m 27,267.00 450 allocation to west park cfd o&m 70,008.22 460 allocation to festival ranch cfd o&m 177,790.54 480 allocation to tartesso west cfd o&m 27,809.17 481 allocation to anthem sun valley cfd o&

This is known as the capacity calculation process. The capacity calculation process has to be distinguished from the capacity allocation process, which takes place for e.g. day-ahead at the power exchanges. The result of the capacity calculation process is to be used as an input to the capacity allocation process. This document is a

Automated store allocation represents the automated generation of allocation tables for typical DC allocation . Computing Center Management System (CCMS). Nevertheless, you can start automated store allocation manually for test purposes or for immediate execution . 5 Usage of optimized technical set-up for parallel processing

Chapter 12 Routing in Switched Networks 351 12.1 Routing in Packet-Switching Networks 352 12.2 Examples:Routing in ARPANET 362 12.3 Least-Cost Algorithms 367 12.4 Recommended Reading 372 12.5 Key Terms,Review Questions,and Problems 373 Chapter 13 Congestion Control in Data Networks 377 13.1 Effects of Congestion 379 13.2 Congestion Control 383

Congestion Investigation Institution of Civil Engineers Congestion in London has risen noticeably between the years of 2012 and 2015 with journey times in Central London increasing by 12% annually. Car traffic, including taxis and private hire vehicles (PHVs), is decreasing in . -Taxis: Best information to pick up passengers

(3) Congestion-aware load-balancing. The last component of Clove is an algorithm that reacts to both short-term congestion, e.g., result-ing from poor load-balancing, and long-term network asymmetry, e.g., resulting from failures or from asymmetrical workloads, by increasing the probability of picking uncongested paths for new flowlets.