Discuss Options to Improve Market Visibility to RTBES Presented by: Matt Mereness Friday, October 27, 2006

Objective  Discuss Options to Improve Market Visibility to RTBES  Specifically, look at technical options for providing closer to real-time pricing information when Non-Spinning Reserve Services (NSRS) are deployed

Background  PRR650 was effective 9/1/06  Requires ERCOT to: send an emergency notification to all QSEs when NSRS is being deployed send an emergency notification to all QSEs when NSRS is being deployed send an emergency notification to all QSEs when NSRS is being discontinued send an emergency notification to all QSEs when NSRS is being discontinued manually recalculate the Market Clearing Price for Balancing Energy Services (MCPE) when NSRS is deployed the next business day. manually recalculate the Market Clearing Price for Balancing Energy Services (MCPE) when NSRS is deployed the next business day.  MCSM was removed 10/1/06 by PUCT  Removed historical need for price corrections, except for held intervals, and shadow price errors.

Background (cont’d)  FRR650 requires a manual method for MCPE adjustment:  ERCOT runs a custom program that creates a market file without NSRS schedules (which are combined with the energy schedules)  ERCOT re-runs the market clearing process with these modified schedules to generate the adjusted MCPEs  Not performed if there are any binding CSC constraints  Adjusted MCPE is posted the next business day in the Balancing Energy Services report, and communicated to the Settlements systems at ERCOT

Results of Initial Research  ERCOT was asked by PUCT staff to look at alternatives to provide a pricing signal closer to real-time, including two alternative discussed in meeting with them:  Running two Market Clearing Engines (MCE) in parallel, one for dispatch, one for pricing  Post remaining Balancing Energy Services bidstack when NSRS is deployed for Market Participants to download and derive an estimate of where the adjusted MCPE may fall.

Results (cont’d) ERCOT looked at the following options: 1a) Run two Market Clearing Engines in parallel, one for dispatch, one for pricing  Implementation: Additional four Market Clearing Engine servers (a “pricing MCE” at both sites, with redundancy), create additional SPDMKT file without NSRS schedules, and perform integration work to update MOS database with separate dispatch and price solution.  Timing: If resources available, perhaps 4-6 months to procure equipment, configure, code interfaces, test.  Benefit: Real-time price signal to market, no vendor involvement, minimal risk of increasing time to reach market solution.  Risk: Operational complications of extra engines involved in solution, resource risks as nodal equipment currently being installed and configured  Resources involved: Procurement, IT Hardware configuration, EMMS development, EMMS support, testing.

Results (cont’d) 1b) Run two passes through the same Market Clearing Engine with two different SPD files  Implementation: create additional SPDMKT file without NSRS schedules, and perform development of logic to run a second market clearing process when NSRS deployed, and integration work to update MOS database with separate dispatch and price solution.  Timing: If resources available, perhaps 3 months to configure, code interfaces, test.  Benefit: Real-time price signal to market, no vendor involvement  Risk: Slows down market solution to run second pass, program only runs when NSRS deployed (infrequently).  Resources involved: EMMS development, EMMS support, testing.

Results (cont’d) 1c) Have vendor modify Market Clearing Engine to add additional step to create separate pricing.  Implementation: AREVA enhancement to create necessary SPDMKT and MCE changes to add pricing step.  Timing: Dependent on vendor availability and ERCOT testing resources.  Benefit: Although more expensive, would not involve resource constrained ERCOT staff, and provides real-time price signal to market  Risk: Would have timing impact to run additional pricing step to achieve market solution.  Resources involved: AREVA, EMMS support, testing.

Results (cont’d) 2) Post remaining Balancing Energy bidstack  Not pursuing at this time  ERCOT would sanitize and truncate the remaining bidstack and post to the web for download by the market.  Perceived issues: The notice to the market that NSRS is deployed does not include the initial amount and does not update each interval on the amount of NSRS deployments The notice to the market that NSRS is deployed does not include the initial amount and does not update each interval on the amount of NSRS deployments Most load-serving QSEs are not equipped to programmatically download a bidstack and quickly assess where in the bidstack the price would fall. Most load-serving QSEs are not equipped to programmatically download a bidstack and quickly assess where in the bidstack the price would fall. Posting the aggregate bidstack would not be equivalent to the "available bidstack" where certain QSEs are skipped in the stack that are down-balancing or ramp-rate constrained. Posting the aggregate bidstack would not be equivalent to the "available bidstack" where certain QSEs are skipped in the stack that are down-balancing or ramp-rate constrained.

Option Summary Option Est. Time BenefitRisk 1a- run parallel engines 4-6 mo. (procurement) No vendor involvement, minimal risk of increasing time to reach market solution Complications of extra engines involved in solution, resource risks with nodal Cost k? 1b-run two passes through one engine 3 mo. No vendor involvement Slows down market solution to run second pass, program only runs when NSRS deployed Cost k? 1c-vendor modify engine to add step Vendor timing Would not involve resource- constrained ERCOT staff except for testing More expensive, probably would slow down market solution to run additional pricing step Cost k?

Other Notes  This summer ERCOT employed a desk procedure that deploys NSRS when reserves are diminishing. This has been the most frequent cause of NSRS deployments since September 1 with minimal pricing impacts.  This creates more common scenarios of NSRS deploying before the hitting the 95% bidstack, so the price adjustments are more subtle (or on October 17 th, prices decreased).  ERCOT’s use of Replacement Reserves may be minimizing the amount of Non-Spin deployed due to bidstack depletion. Yesterday, October 26 was first case of NSRS depletion since PRR650 went into effect.  ERCOT’s intra-day updates (via the ROS exploder) publicize shortfalls in supply. This may be resulting in market behavior that is minimizing the amount of Non-Spin deployed.

Next Steps  Market could consider PRR(s) to make changes  To automate correction in real-time: If MCE changes warranted, need change to protocol to remove “afterward” price adjustment. If MCE changes warranted, need change to protocol to remove “afterward” price adjustment.  This PRR would also help prioritize with other projects  To remove other NSRS deployments not related to bidstack depletion: Consider modifying protocols to limit notice and price correction only to cases when NSRS is deployed for BES bidstack depletion (no system changes). Consider modifying protocols to limit notice and price correction only to cases when NSRS is deployed for BES bidstack depletion (no system changes).  This may be difficult to combine with MCE change in Real-Time Consider max function in price correction to take higher price to prevent deployments below bid price (no system changes). Consider max function in price correction to take higher price to prevent deployments below bid price (no system changes).  Other options?

Prices for 10/26/2006  MCPE Prices discussed at meeting: 26-Oct-06Original MCPE Corrected per PRR650 7:00$200.01n/a 7:15$295.00n/a 7:30$200.00$ :45$85.01$ :00$85.01$ :15$69.90$ :30$68.77$ :45$77.08$ :00$ :15$51.87$ :30$72.73n/a 19:15$77.08n/a 19:30$1,000.00n/a 19:45$1,000.00n/a 20:00$1,000.00n/a 20:15$102.75n/a