RUC Implementation Clarification

1. RUC Implementation Clarification MMS Project

2. RUC Snapshot • Protocol section 5.3(2) -“For each DRUC, ERCOT shall use a snapshot of Resource commitments taken at 1430 in the Day Ahead to settle RUC charges.” • Current implementation • Snapshot is taking at the time of RUC execution. • This will enable us to get the correct input if DRUC execution is delayed later than 1430

3. Considering DC Ties in RUC • Protocol section 4.4.4(7) & (8)-“ ERCOT shall confirm each valid DC Tie Schedule with the applicable interconnected non-ERCOT Control Area and shall coordinate the approval process for the NERC tags for the ERCOT Control Area” & “Using the DC Tie Schedule information submitted by QSEs, ERCOT shall update and maintain a Current Operating Plan for each DC Tie ….” • Current implementation • OATI interface for E-Tags is ported from Zonal implementation for Nodal. • DC Tie Schedule can be submitted only after the E-tag is approved by the operator. A COP entry for the DC Tie is automatically created for every valid submission. • E-Tags can be submitted and approved 20 minutes before it flows. For those E-Tags, the QSE will not be able to submit DC Tie schedules and the COP entry for the transaction will not be created since the deadline for submitting DC Tie schedule is end of Adjustment Period. I.e. E-Tags approved near Real Time will not be considered in RUC optimization.

4. Executing HRUC for Next Operating Day after 1800 • Protocol section 5.1(6) -“The RUC Study Period for HRUC is the balance of the current Operating Day plus the next Operating Day if the DRUC for the Operating Day has been solved.” • Current implementation • The RUC Study Period for HRUC is the balance of the current Operating Day plus the next Operating Day if the DRUC for the Operating Day has been solved or if the current time is greater than 1800. • If DRUC does not finish by 1800, then it will have to be aborted since HRUC will start executing for next Operating Day.

5. Issuing VDI when RUC fails • MP understanding -If RUC optimization is not running then the operator should manually commit the Resources needed and send the instructions as RUC commitment/de-commitment • Current implementation • The module that sends manually entered commitments cannot be run independently of the optimization module, since the settlement snapshot is associated with the initiation of the entire RUC sequence. • Commitment/De-commitment would be through VDI if RUC is not working.

6. Submitting 3PO for Operating Day between 1000 and 1800 • MP understanding –QSEs will be allowed to submit 3PO seven days in advance until the end of Adjustment Period. • Current implementation • QSEs will not be allowed to submit/change 3PO for the next Operating Day between 1000 & 1800. • This is to ensure that DAM and DRUC uses the same 3PO.

7. Incorporating VDIs/Previous HRUC Instructions • Protocol section 5.5.3(4)–The QSE shall acknowledge the notice or commitment or de-commitment by changing the Resource Status of the affected Resources in the COP for RUC-Committed Intervals.5.3(2) -For each DRUC, ERCOT shall use a snapshot of Resource commitments taken at 1430 in the Day Ahead to settle RUC charges. For each HRUC, ERCOT shall use a snapshot of Resource commitments from each QSE’s most recently submitted COP before HRUC execution to settle RUC charges. 5.5.2(1)- The RUC process takes into account Resources already committed in the DAM, Resources already self-committed in the COPs, Resources already committed in previous RUCs, and Resource capacity already committed to provide Ancillary Service. 5.5.2(5)-ERCOT shall use the RUC process to evaluate the need to commit Resources for which a QSE has submitted Three-Part Supply Offers and other available Off-Line Resources in addition to Resources that are planned to be On-Line during the RUC Study Period. All of the above commitment information must be as specified in the QSE’s COP. • Current implementation • In HRUC optimization, COP “OFF” status is overridden to ONRUC for previous RUC instructions or VDIs issued within the last X minutes (configurable time- default 1 hr) • This is to avoid RUC from committing Resources for capacity or congestion that was already accounted for by the last RUC run or previous VDIs. • This will not affect Settlements. Settlements will only use the COP submitted by the QSE.

8. Commitments for AS Insufficiency • Protocol section 5.1(11) - The RUC process may not be used to buy Ancillary Service unless the Ancillary Service Offers submitted in the DAM are insufficient to meet the requirements of the Ancillary Service Plan 6.5.9.3.3(5)- If ERCOT issues an Alert because insufficient Ancillary Service Offers were received in the DAM, and if the Alert does not result in sufficient offer and the DAM is executed with insufficient offers, then ERCOT shall acquire the insufficient amount of Ancillary Services in the DRUC and shall issue Dispatch Instructions to the QSEs for Resources that were RUC-Committed to provide Ancillary Services, informing them of the requirement that the Resources be prepared to provide those Ancillary Services. • Current implementation – Commitment for AS insufficiency is done as part of the RUC process but outside the optimization.

9. AC Contingency Analysis • Protocol section 5.5.1(7) -As part of the Network Security Analysis, for each hour of the RUC Study Period, ERCOT shall analyze all selected contingencies and perform the following: (a) Perform full AC analysis of all contingencies; • Current implementation • Full AC analysis is done for Base Case only. Only MW flows are considered in the contingency analysis. • RUC is an iteration process for 24-30 hrs and full AC contingency analysis drastically reduces the efficiency. Even RTCA, which runs for one snapshot, does AC contingency analysis for only a selected set of contingences.

10. Posting Active Constraints • Protocol section 5.3(3) - For each RUC process, ERCOT shall: (b) Post to the MIS Secure Area, the following information related to the RUC: (i) All active and binding transmission constraints (contingency and overloaded element pair information where available) used as inputs to RUC; and • Current implementation • Only binding/violated constraints are posted. • Since RUC is an iterative process and constraints are added in each iteration, the number of active constraints in the final iteration might become very huge. Exporting these will affect the performance of the RUC execution.

11. Submission Issues for SGR in RUC Conflicting COP Resource Status • If all SGRs (Split Generation Resources) in a generating facility have submitted a COP and at least one of them has an“ONLINE” COP Resource Status in a particular hour then Resource Status all SGRs at the generating facility are changed to “ONLINE” for that hour except if any of those have OUT status. • If any SGR has OUT status for any hour then the other SGRs corresponding to the physical Resource are also made unavailable for the hour Missing COP before RUC study period • If COP is not available for any SGR for any particular hour from the current hour to the start of the RUC study then the Resource Status for those hours are considered as equal to that of the last known hour’s COP for that SGR. • Once the COP Resources Status for all SGRs are identified, it is corrected to resolve any conflicting statuses among SGRs corresponding to the physical Resource for the hour. • The SGR whose status is changed will not get a RUC commitment due to the change. Missing COP within RUC study period • If COP is not submitted for any SGR in any hour within the RUC study period then the SGR is set as unavailable. For those hours, none of SGR in the same facility can be committed by RUC.

12. Submission Issues for CC in RUC Conflicting COP Resource Status before RUC study period • If multiple configurations for the same CC plant is show as ONLINE for any particular hour then the ONLINE configuration which has been ON for the longest is considered as ONLINE and all other ONLINE configurations are considered as OFF Conflicting COP Resource Status within RUC study period • If multiple configurations for the same CC plant is show as ONLINE for any particular hour then the ONLINE configuration with largest HSL is considered as ONLINE and all other ONLINE configurations are considered as OFF Missing COP before RUC study period • If COP is not available for any particular hour from the current hour to the start of the RUC study for any CC configuration then the Resource Status for those hours are considered as equal to that of the last known hour’s COP for that configuration. • Once the COP Resources Status for all configurations for a CC plant are identified, it is corrected to resolve any conflicting statuses among the other configurations of the CC plant for the hour. • The configuration whose status is changed will not get a RUC commitment due to the change. Missing COP within RUC study period • If COP is not submitted for any hour in the RUC study period then the configuration is set as unavailable for those hours

13. Real Time Telemetry Issues RLC sets HDL = LDL = Telemetered net MW if any of the following conditions are met: • HSL<LSL, • Resource Status =OFF, OUT, OFFNS and telemetered net MW>2 MW • Resource Status = ON and telemetered net MW<0 [RLC sets HDL and LDL to 0] • HSL <= Reg-Up Resource Responsibility + Responsive Resource Responsibility + Non-Spin Resource Responsibility • (HSL-LSL) < SUM(AS Responsibilities) • Telemetered Resource Responsibility or Schedule <0 for any Ancillary Service [RLC sets that Resource Responsibility or Schedule to 0] • HSL <=0 • LSL <0 • Invalid Combined Cycle Plant configuration