05/14/2025 09:30 AM
Video Player is loading.
Advertisement
Current Time 3:40:17
Duration 3:54:14
Loaded: 94.10%
Stream Type LIVE
Remaining Time 13:57
1x
  • Chapters
  • descriptions off, selected
  • captions off, selected
  • default, selected
x
ZOOM HELP
Drag zoomed area using your mouse.
100%
Search
  • 00:00:00
    Meeting reminders, as we get situated here.
    If you're here in person, please remember to use the sign in sheet outside the meeting room.
    We are using a managed queue.
    So if you are on the Webex, please enter yourself in the chat.
    If you are here in the meeting room, you can enter yourself in the chat if you're signed in, or you can raise your card.
  • 00:00:22
    And Jordan's over here in the right side of the room, and he will enter you in the chat.
    Please wait for the chair to recognize you.
    And then as we get to the balloting process, those of you that intending to vote today and those of you, on the Webex, please make sure that you unmute yourself as we come to your segment and then return to the mute function after you vote.
    So that'll help us be a little more efficient.
    And then finally, if the Webex ends for any reason, give us just a few minutes, and we will restart the meeting with the same Webex information, or we will send something to the PRS listserv.
  • 00:00:59
    And with that, we do have a quorum, Diana, and are ready to begin when you are.
    Good morning, everyone.
    Welcome to the May 14 PRS meeting.
    We have a lot of folks here.
    We have a lot of folks online, so welcome.
  • Item 1 - Antitrust Admonition
    00:01:13
    We'll start with the antitrust admonition that we have every month.
    We won't read this to you, but if you need more information, the statement of position on antitrust is located on the ERCOT website and all materials and presentations.
    Biomarket participants or other entities to ERCOT are considered public in accordance with the ERCOT website content management operating procedures.
    Thank you, Corey.
    Okay.
  • Item 3 - TAC Update
    00:01:40
    So that takes us to, the third item, the TAC update.
    They approved everything that we sent to them, including including our strategic objectives.
    So that was successful.
    We have those for the rest of the year.
  • Item 2 - Approval of Minutes (Vote)
    00:01:56
    And, I skipped the approval of the meeting minutes.
  • 00:02:00
    Susie, did we have any edits or changes to any of the meeting minutes that we have posted?
    No.
    We did not.
    Okay.
    So So if everyone is good with that, we can put the meeting minutes on the combo ballot unless we see any reason not to.
  • 00:02:14
    Okay, Corey.
    Thank you.
    Alright.
    So that takes us to Troy.
    Troy, I know that you had, two updates for us.
  • 00:02:22
    One that you're teeing up and one is our monthly usual project update.
    We'll turn it over to you.
    Great.
    Thank you, Diana.
    Good morning.
  • Item 4 - Project Update
    00:02:30
    I'm Troy Anderson with their portfolio management for the project update this month.
    We can jump on to slide three, Corey.
    Okay.
    Just a reminder of what we have going live here in a couple weeks with NPRR1253, the ICCP, and public API implementation of ESR charging load information.
    So this is a repeat from last month, the slide, no changes.
  • 00:02:57
    So just wanted to keep that, in front of everyone's mind.
    Next slide.
    No changes here because, we have, you know, been keeping the deck clear for RTC+B, which continues to chug along.
    Next slide.
    No changes here either.
  • 00:03:19
    Although I am working on what sounds like an MPIM update to the bottom portion of this.
    We got some internal things going on that might change some timing.
    So and as well as some, NPRRs that are likely to come out very soon.
    Onward.
    Okay.
  • 00:03:39
    So we'll have four IAs here today.
    Finally got caught up on some of these that we've been asking for more time on.
    You see a lot of TBDs because I think we're gonna talk about priority options when we get to them.
    And there's some other discussion points I've built in as well.
    So, we're we wanna talk about those at that portion of the agenda.
  • 00:04:03
    And next, TWG had its meeting on the twenty fourth and meet again on May 29.
    Lot of RTC content as you would expect.
    Okay.
    Now for the the main part of today's discussion, every now and then, we pull up all the aging revision request projects that are out there, things that have not been able to make it into the project queue because of higher priorities.
    Now that RTC is approaching its December go live, we all know it'll be valuable to have a reprioritized version of this list for 2026.
  • 00:04:44
    So what was posted yesterday is a revision to that file that we used last year.
    And what I'm proposing is that today, I'm just gonna walk through the information that I I have out there so that you have the next month to think about what you would want to propose rises to the top of the list, and we can have that prioritization discussion in June.
    Then over the July slash August time frame, I can assess the labor for the things that you're suggesting your highest priority to see what seems to fit in in that 2026 time frame.
    And we must not forget that, there will be legislative priorities that we also have to keep in mind.
    So the next slide, the final slide, in fact, this was the graphic I was using all through last year.
  • 00:05:37
    If you recall, I would add a column for every month, and we kinda we've whittled that market input number down to zero.
    But with the refresh, I've added anything that we've subsequently approved through PRS and up up to the commission.
    I've also included things that are at the board and commission because we know those are approaching potential approval.
    And that file now adds up to about 61 items that we would wanna be considering as we talk about priorities, of which a lot of them we'd already flagged as post RTC.
    So we'll we'll wanna be taking a look at those.
  • 00:06:14
    Several of the other groupings, changed if items got into the queue, and they're either in flight or complete at this point.
    So let's jump over to the Excel file, if you don't mind, Corey.
    So can you, yeah, zoom it a little bit?
    Okay.
    So this I started with the exact file we used last year.
  • 00:06:39
    So columns p and q still contain last year's recommendations and notes.
    Added the column o ahead of that, which is gonna be what we use to flag our priorities this year in 2025.
    I also updated that column o for any new changes to any items.
    So maybe something, is now in flight or something is complete or some things were added to the RTC plan, things like that.
    Yep.
  • 00:07:09
    If you scroll to the bottom, you'll see some that are grayed at gray in columns p and q.
    Those are the new additions.
    So by default, they get a market input needed designation, but, that's how you can tell what's been added since we last went through this exercise.
    There's some of the other columns that I hid because I haven't really caught up on all the data that's required for all these columns, but, the key points from the IAs are all here as well as, who is the submitting entity and things like that.
    And, of course, the priority and rank, which you've already been getting ahead of by putting some things in '27 and even one thing in 2028.
  • 00:07:54
    So that in column d there, if you wanna scroll to the bottom, Corey, there you'll see, I sorted this by priority and rank, priority first.
    So those future year things kinda fall down to the bottom.
    And, of course, some of that 2024 information is gonna be important.
    There were about seven item I think seven revision requests that that you would ask ERCOT, please try to squeeze these in prior to RTC.
    And, those are all gonna be flagged accordingly in that 2024 area.
  • 00:08:27
    So, so when, we come back to this next month, that'll help flag, you know, the items that were previously important to us.
    And I think out of that seven, we only really got one done.
    It was, what, October, unfortunately.
    The rest had to be set aside because they just conflicted too much with RTC.
    So for today, I just wanted to tee up.
  • 00:08:50
    Here's the data.
    We're gonna dig into it next month in a more in-depth fashion.
    I wanna give everyone some time with it since especially since it was just posted yesterday.
    I can take any questions.
    Thank you, Troy.
  • 00:09:08
    I don't see any questions in the queue.
    So this is our first look at the prioritization for the items that are still in the queue, and then we will come back to this file next month.
    And then if we have any particular items that maybe are important or we're wondering about, we can dive into those a little deeper next month.
    Is that what we're hearing?
    Yep.
  • 00:09:33
    And we wanna do this.
    Okay.
    We've had a couple of, different sets of comments since our, April meeting, and we will, try to go through those comments, and then we will work through our queue.
    How does that sound?
    There's a 50 things over the past five years that have been going through the queue, and so that's where you can find, like like, there's a handful that are in execution.
  • 00:09:58
    In fact, 10 of them are already in flight.
    So you're wondering, hey.
    So we are we're good on that way.
    So does anybody from ERCOT wanna raise this, or do we wanna start with the comments?
    Okay.
  • 00:10:16
    Well, thank you very much, and, I can take any questions as they come up throughout the day.
    Thank you, Troy.
    Troy, just an overarching question.
    Since we know that there's a lot of projects that are on hold until RTC is implemented, we'll probably take a look, I'm assuming, maybe in the spring next year as to where we are and have a better idea of what the landscape looks like for what those that project, timelines will look like?
    Absolutely.
  • 00:10:48
    Okay.
    Yeah.
    This is kind of our chance to assess, you know, what what on this list needs to rise to the top.
    But, absolutely, early twenty twenty six, we'll be talking about, are there any remnants of RTC that need to be addressed?
    Are there things like DRRS that clearly need to be into the queue and moving other legislative items?
  • 00:11:11
    So this is an input to what next year's plan will be.
    It won't be the plan, just input to it.
    Okay.
    Perfect.
    Thank you, Troy.
  • 00:11:20
    We know that that's a a heavy lift for you all, and we appreciate it.
    And we'll take a look at it again next month.
    Okay?
    Alright.
  • Item 5 - Urgency Vote (Possible Vote)
    00:11:31
    Moving forward, we have two items up for urgency vote today, both with no impact, both with no price, both of them coming to us from ERCOT.
  • 00:11:46
    Alright.
    So let's see.
    And we wanna do this.
    ERCOT, do you what we can do is we can have ERCOT lay this out for us, and then we can go through the comments that we've received thus far.
    We've had a couple of, different sets of comments since our, April meeting, and we will, try to go through those comments, and then we will work through our queue.
  • 00:12:12
    How does that sound?
    I should say people.
    And just as a reminder, since, both of twelve eighty two and twelve eighty three were posted in time.
    We don't have to vote in order to discuss it.
    So we are we're good on that way.
  • 00:12:31
    So does anybody from ERCOT wanna raise this, or do we wanna start with the comments?
    No.
    Yeah.
    Okay.
    Sorry.
  • 00:12:46
    I couldn't see you back then.
    Please tell me about that.
    I was looking for you over here.
    I was like, she's usually over here, and you changed on me.
    Sorry about that.
  • 00:12:57
    She found the corner.
    Good job.
  • Item 5.1 - NPRR1282, Ancillary Service Duration under Real-Time Co-Optimization
    00:12:59
    Alright.
    I can set it up.
    So what I'll do is I'll set up the NPRR, and then I'll request Dave to, chime in about the comments that we filed so that we will hear from both of us, both the the reason for the urgency and what potential options we think, could be considered.
  • 00:13:17
    And, so so, of course, the the setup of this NPRR is, there was a topic related to duration, penciled for discussion at the RTCTF.
    And ERCOT, did, as a part of that, line item, work through, look at the do a lot of analysis around each of the ancillary services to, first validate what durations were already contemplated in in the, RTC language doing, and ensure if they were sufficient or if a change was needed.
    Now we did analysis.
    We shared our results of those analysis and, in detail at the RTCTF meeting.
    And what you're seeing here is a is, an outcome of the that analysis.
  • 00:14:09
    Now at a high level, you are seeing three type of changes being, recommended, from ERCOT in this NPRR.
    Two of the changes are related to regulation and responsive reserve, and the third one's related to ECRS.
    Now what I'll do is, Corey, if you want, scroll down to the justification and maybe I'll set up, and start from the bottom.
    Let's not start from the top.
    So yep, right, start right here.
  • 00:14:39
    So what what I'll do first is I'll lay out the the the need tied to regulation and responsive reserve and then go backwards up.
    Now in case of regulation and responsive reserve, we are recommending to increase the duration requirements.
    The current, RTC language contemplates this to be a fifteen minute requirement, and we are recommending that this should be increased to at least thirty minutes.
    Now the underlying basis for this is by increasing the duration, it helps reduce the risk of ERCOT, violating its NERC obligations, specifically related to BAL-001.
    In the event, we, we'll find ourselves in a situation where SCED is not running.
  • 00:15:28
    So we have looked back at historical SCED failure events.
    Now these this is the, the a SCED that we've had now running since nodal go live.
    And what we've noticed is eight out of 10 times, the length of the sched failure events lasts up to thirty minutes.
    Now what will happen under RTC?
    If SCED were to go down and LFC is still up, we would be using the resources that have a regulation award to balance frequency.
  • 00:16:02
    We would be relying on the resources that have frequency response, RRS headroom, to balance frequency or to maintain frequency as far as possible.
    So these two reserves are essentially the first line of defense.
    Now under these situations, NERC requires us to ensure that we continue to control frequency and maintain a certain set of, maintain frequency within a certain set of alarming values.
    So this particular thirty minute requirement is essential to help reduce the risk of ERCOT violating its NERC requirements.
    K?
  • 00:16:39
    So now let's go back up.
    Let's talk about now ECRS.
    Now the way ECRS is written, the the change, that we are recommending here is in opposite direction.
    So there is, right now, the protocols, for RTC use a two hour duration for ECRS.
    We have looked at, the, a variety of things in case of ECRS, including, historical events where we've needed ECRS to cover the, the ramp that we see on the system.
  • 00:17:11
    We've looked at how the variability on our system's changing and expected to change with solar coming.
    And lastly, we've also taken into account the relevant NERC standards.
    And the really, the most relevant NERC standard in in case of ECRS is BAL zero zero two.
    So this is the, standard which requires us to ensure we have sufficient, reserves available to recover frequency following an event and restore our reserves.
    And there are times associated with both of them.
  • 00:17:42
    Looking at the data, looking at how our system's evolving, this was one place where we felt we could start by lowering the duration to one hour.
    Now, and we definitely caution.
    It comes with a a lot of, caution in our minds because we are also looking at NERC requirements.
    And to us, at least, the way, the way we set this up in our recommendation was, were we to see an issue in recovering frequency or recovering reserves in a manner that starts violating or that starts bringing us into that zone where we are worried about violating by two, we may want to come back and talk about a different duration.
    But at least the setup today, given the variability we see coming with, the the growth of solar in our fleet, given how we've seen the systems operated and how our forecasts have done, we think one hour is sufficient.
  • 00:18:37
    And now if you can scroll up.
    The last one, that we'll talk about a little, it's we've not recommended any changes per se is non spin.
    Non spin right now in the RTC requirements has a four hour duration.
    We have looked at historical events and, and how the system has responded to those.
    We used, in this case, we used, at least, to ensure that we were looking at events that are relevant to non spent so this would be forecasted events.
  • 00:19:13
    This would be forced outage events.
    We did look we used a historical deployment of non spin as a proxy of identifying those days.
    Now when we looked at historical deployments, we we looked at not just days when we had scarcity, but also on days when we did not have scarcity and tried to look through what was going on on those days.
    And sure enough, what you will notice is on days when non spin was deployed and there was really it was not scarce, I e, there were certain resources that were still offline.
    What we noticed is in many cases, there was a sustained under forecast in our net load.
  • 00:19:55
    They're tied to weather in certain cases and some they are and there were other cases where there was a a a decent amount of forced outages that that came throughout the day and brought us into a situation where the amount available capacity on the system was tight and not sufficient to cover the, the net load that we were seeing.
    And on all on and there were at least a a good portion of days in this analysis where the duration of energy needed from non spend lasted more than four hours.
    Looking at this dataset, and looking at how the system responded on those days when we were dealing with forecast errors and forced outages, things that are not planned for, things that we cannot, we cannot take into account entering into operations on a particular day.
    Four hours to us is a good duration to start out RTC with.
    We are happy to go back once this we've had some more experience with the newer tools that RTC will bring in with the newer analysis, and we see how the how, the operations is evolving across the board, not just at ERCOT, but even, to at the stakeholder end.
  • 00:21:10
    We will be happy to revisit.
    One I one thing I did notice, one time I'm certain we will want to revisit non spin duration is when we have d r s DRRS, in place, but it doesn't mean that that's the only time.
    So I'll pause with that setup.
    There is another last piece of change in here, and that's related to duration that we will use in Ruck analysis.
    And at least for Ruck, we've recommended using sixty minutes.
  • 00:21:37
    I don't think I've heard any more feedback on this one, so I'm assuming people are generally comfortable with this.
    So with that, I'll pause.
    Dave, I'll invite you to also probably layout.
    Hey, Anita.
    Can you all hear me?
  • 00:21:57
    We can hear you.
    Go ahead.
    Perfect.
    Thank you.
    Yeah.
  • 00:22:00
    Just to talk really quickly about our comments earlier this week, we had filed some comments on Monday.
    You know, they were really focused more on discussions on the timing of moving forward.
    So, obviously, Nitika has talked through the NPRR and at least the our thoughts on on how we came to conclusions on how to set the parameters.
    More what we wanted to share with the comments was just trying to, communicate our feelings of, urgency in trying to get something moved forward with 1282.
    There's a strong desire as we are already starting to move into market trials, and with the the overall timings of approvals to to try and move forward with some parameters so that we can properly test and consider them as we move into, just the various phases of market trials.
  • 00:22:52
    So with within our comments that we had, filed, sort of looked at at two options.
    But by far, I would say our preference is option one is to get something moving forward today.
    Obviously, recognize there's, some some comments that we'll walk through from a a variety of market participants, but to try and to get have something move forward today so it can be approved by TAC later this month and the board in June, and and we'll have what we need and know what we want to be doing going into market trials.
    Separately, we talked about potentially considering, alternate proposals as, as separate NPRRs for something that could be passed, later this year in September.
    Of course, that is not preferable for us.
  • 00:23:40
    There's obviously some risk around, being able to touch with those new parameters, and as well, we wanted to note that at at least some of the ideas being discussed are are more complex than simply updating the parameters and and simply won't be able to be part of the scope of the RTC+B go live.
    Now with that last comment, I recognize that we had a number of comments come in over the the last couple days following our comments, and it seems like folks have obviously recognized the the concern around the complexity and have focused more on just simply updating parameters, but but at least did want to note that as part of our comments.
    I'll stop there and see.
    I know we have some folks in the queue.
    Thank you.
  • 00:24:22
    Okay.
    Thank you both.
    Excuse me.
    Let's go to Bill.
    Question was about the RUC piece.
  • 00:24:31
    Is that a system limitation is why you're just using one duration requirement for all services?
    Just curious why that was So decision.
    Bill, it's it's kind of like we have only one dispatch running for that entire one hour, and we want to kind of look at the the it's kind of like an average sched for that time period.
    So that's why we use sixty sixty minutes for that.
    And there are two sets of rut duration requirements.
  • 00:25:04
    One is for how much energy you need to support, AS for that hour.
    The other one is how much what is the duration required for the, the special way we model batteries in rock where we don't dispatch them.
    We self schedule it schedule them to their submitted date of charge.
    So we use a duration to say what is the expected consumption of that energy due to AS deployment.
    And that's that's another set of duration parameters.
  • 00:25:35
    So both of them, we are setting at sixty minutes.
    Okay.
    Thanks.
    Caitlin?
    Thanks, Diana.
  • 00:25:46
    Caitlin Smith, Jupiter Power.
    I'm I'm not gonna go into our position right now, but I wanted to ask a couple clarifying questions of ERCOT.
    I just want I think this is clear, but I wanted to confirm that on the parameters of values for for the duration, we can code those in such a way that it would not take a system change to to later change those values?
    And is that the plan?
    Yes.
  • 00:26:17
    They are being coded as a parameter.
    So the parameter's value can be changed.
    Okay.
    Great.
    Corey, can you scroll up to the non spin part?
  • 00:26:29
    I wanted to ask we have a reference in ECRS to revisiting this later.
    Okay.
    And then non spin, I see it also should be periodically revisited.
    So is there is there a way I'd you know, I kinda hate when people get you to commit to things verbally, but but could we commit to revisiting these at a certain period of time after RTC implementation?
    Or maybe the better way to phrase it would be, I think you said we could revisit it.
  • 00:27:05
    So what what does that revisiting look like to ERCOT?
    Pretty much after, the way to describe this is probably and anytime we have an interesting days or significant days, we tend to look at how the system be operated from all aspects.
    I would and I would expect us to do almost something very similar.
    Now I don't know that I can commit to a date, but we are we are, we tend to find ourselves in a spot with the type of grid we have that the system's changing quite constantly.
    So there would be some sort of inciting event that would okay.
  • 00:27:47
    Exciting.
    Inciting.
    But, you know, every well, every stakeholder meeting is exciting.
    So alright.
    Those are my questions for now.
  • 00:27:56
    Okay.
    Katie?
    Rich?
    Thanks, Diana.
    So as Monica is aware, we previously expressed a couple concerns, you know, making sure that reserves are there when we need them and not putting ourselves in a position where we're running through EEA levels quickly.
  • 00:28:14
    But if there's not an appetite for what we've talked about, which is aligning the RTC, SoC requirements for IRS and reg with p r PRC's forty five minute window and then maintaining that two hour duration for ECRS.
    We believe ERCOT's proposal is the best approach.
    You know, in part, our concern is about these comments that we just heard on revisiting this, you know, in a time when we do need some market certainty.
    So we appreciate you hearing out our comments.
    Okay.
  • 00:28:50
    Alright.
    So we also had comments from Texas Solar with Mark Stover, and we had, the IMMs comments.
    Mark, are you did you wanna speak to your comments?
    Mark is at the capital today.
    Oh, he's okay.
  • 00:29:09
    And I think he's been coordinating with Caitlin Okay.
    Perfect.
    Also to the extent necessary.
    I'm not voting on this item, and rep and representing TSSA instead.
    Okay.
  • 00:29:20
    Perfect.
    Andrew, did you wanna speak to, I'm sorry.
    Okay.
    Andrew, did Yeah.
    Do you wanna speak to the IMM's comments that, were posted yesterday?
  • 00:29:34
    Yeah.
    That sounds good.
    Andrew Reimer's IMM.
    We filed these comments yesterday.
    I don't think much of what is in them will be new content for anyone who's been following this issue.
  • 00:29:48
    We presented a lot of this stuff at the January RTC+BTF meeting.
    And then at the most recent, RTC+BTF meeting last week, we had a lot of these comments.
    So the structure of these comments, initially, we kind of recharacterize the metric of the length of non spin deployments as being maybe, inappropriate metric for figuring out what the duration requirements should be, partly because that is pretty heavily influenced by how big the non spin plan is now.
    If you look at pre and post kind of non spin volumes being increased, the frequency at which they're deployed has gone up a lot, and that mostly just has to do with ERCOT's carrying a lot more of them.
    Then we get into the argument that we've made a bunch of different times now that both implicitly and explicitly, I think having these longer duration requirements is going to incentivize batteries to produce energy earlier into reliability events rather than carry reserves.
  • 00:31:01
    And we can either walk through that story today or you can read the comments.
    It's something we've talked about a few times now.
    Then we kinda roll through some IMM greatest hits on alternative market design improvements that we think would more effectively manage this situation.
    And in particular, I just wanna point out, the multi interval market, the more we think about issues like this, that's really the most effective way to explicitly preserve state of charge over time.
    And from what I understand, ERCOT is amenable to considering this kind of market design improvement after RTC.
  • 00:31:44
    With 12,000 megawatts of batteries going on, 18,000 megawatts of batteries, there's really no way around eventually needing to implement something like this.
    We also mentioned DRS.
    That's another product that could more effectively manage issues like this, and making the whole non spin plan have this four hour duration requirement.
    I wanna be clear.
    We do mention forecast stuff, and that isn't meant to be, throwing anybody under the bus.
  • 00:32:16
    But a lot of this issue is related to forecast errors.
    So if you have, for example, over forecasts of solar and then it turns out that solar is coming in under forecast for hours at a time, that continues to send inefficient signals as far as thermal units committing.
    And so a lot of this problem could potentially more effectively be solved with looking into new forecast options.
    I'm sure that has not, escaped the attention of our operations.
    So I'm sure they're doing the best they can with that load.
  • 00:32:53
    Load forecasting, I think, has gotten a lot more complicated with all of the price responsive load and all that.
    So there may need to be some new types of forecasting tools implemented to deal with that.
    So that's the gist of our comments.
    And in summary, we would recommend having both ECRS and non spin, duration requirements set at one hour each.
    Okay.
  • 00:33:16
    Thank you, Andrew.
    Katie?
    Thanks, Diana.
    Andrew, I just wanted to ask you kind of a couple questions about timing because it seems like some of this could go into the 2026 reliability assessment.
    Right?
  • 00:33:30
    If there are issues that come up there, then those are suggestions that could be included in that.
    Something like the forecasting could be included there.
    So, you know, in terms of what you're asking for today, it seems like the only thing on the table would be the should we look at the shorter duration requirements, and a lot of the the rest of it would be kind of an after RTC approach.
    Is that correct?
    Yeah.
  • 00:33:55
    That that sounds right.
    We we do think that these duration requirements should be set at an hour today, because setting them at four hours isn't actually going to be very effective at achieving the goal it's meant to achieve.
    The the batteries are not going to respond to a four hour duration requirement by providing four hours of reserves under scarcity events.
    They're going to be incentivized to sell energy instead.
    And so even if we want to grant that there needs to be some way of managing these, like, prolonged forecast error events, this strategy is probably not going to be very effective at doing that.
  • 00:34:38
    Bill?
    My comment, I think, was really more for Nitika.
    It's related to the for our, duration limit for non spin.
    I was expecting to see in ERCOT's comments, part of the risk.
    I think Woody flagged, I think it was at a board meeting, and it had to do with, being too dependent on battery capacity for PRC during potential scarcity events and the fact that you don't have recoverable frequency.
  • 00:35:10
    Typically, when we think of PRC, that is frequency responsive capacity.
    It's what our whole kind of health of our systems measured on and the ability for those, resources, let's say, like, a 4,000 megawatt of PRC can react to a frequency event and then, be immediately available for the, foreseeable future versus decaying over time if their stated charge stated charge gets depleted.
    And I'm just wondering if that issue is either resolved or not as much of a concern as when it was initially flagged and whether that's related to ERCOT's desire to have a four hour duration limit for non spend or not or if we're thinking of DRS or some other product to help solve that problem.
    Because that one is caught our attention and seems pretty concerning going forward.
    Thanks.
  • 00:36:00
    So so I think Katie flagged this also and and has and mister has been bringing up this conversation.
    Keeping the durations of ECRS and non spin the way we have proposed allows us to have, a better runway when the system starts seeing events where we need additional energy because we weren't able to forecast it or an outage happened.
    You you saw the examples of that the the day when we had a series of outages on the system.
    So certainly, these durations will help play a role in reducing the risk, or or changing the risk.
    The as you shorten them, you take more risk of running into those conditions often.
  • 00:36:52
    By keeping them a a slight wider, you give the control room more time to be able to react to the situation and operate the grid and probably stay away from the edge.
    So there is a balance here.
    I absolutely understand the the to us, we are entering into RTC with a new set of tools.
    Certainly, they'll have more awareness, but the system's changing under us constantly.
    So the but this proposal to us sets us up, on day one of RTC with a decent amount of energy on the system so that we can learn to operate the system and see how the the rest of the stakeholders change their operations in response to this new, to to the new setup that we are putting out.
  • 00:37:36
    This does not mitigate the concerns Woody raised.
    That will continue to be an issue we'll continue to work on, but this at least helps reduce the risk.
    The way we see of entering into those conditions, it gives us more runway.
    So I'll pause with that, see if that helps.
    Okay.
  • 00:37:59
    Alright.
    I think we see have a clear queue for Andrew's comments, and then we also had comments from Jupyter and joint commenters.
    Caitlin, do you wanna tee yours up and or the joint commenters that were I think the Jupiter ones were pre That was for the RCC.
    Yes.
    Okay.
  • 00:38:20
    So let's do the joint comments.
    Yeah.
    So there were Jupiter comments and TSA TSSA comments before the task force meeting, which which we really appreciated, and I think we had, you know, so much discussion that I only had fifteen minutes to to present.
    Thank you, Eric.
    But, there were follow on comments from Jupiter and NG.
  • 00:38:42
    And then on top of these, some sort of supportive comments with TSSA.
    I'm a member.
    I've been working closely with them, so I can cover both.
    You know, in in short, we are proposing shorter durations, and we are proposing sort of the decoupling between the the qualification and the what is required in real time to be picked up by SCED.
    I understand there's concerns with the the decoupling.
  • 00:39:12
    I'm not wedded to that, but the point was that so the qualifications could remain longer to address some of the the concerns from ERCOT and incentivize longer duration participation in these ancillary services.
    You know, I'd also say we we completely understand the urgency.
    We think, you know, something should be voted ahead of market trials.
    I think that's really important.
    Understand what Nitika said as well and having a new set of tools to get used to and operate.
  • 00:39:46
    But I I would say that the tools are based on flexibility.
    Corey, I'm gonna go to a lower part of the comments far farther down.
    And so I'm a little bit confused on why we are using historical length of deployment to, determine what the duration would be.
    I think it's weird to assume that, you know, only one set of resources will be available for that whole deployment.
    There will be no other headroom, especially, I think the value of RTC is that we can make those decisions every five minutes.
  • 00:40:21
    So it sort of ignores that and flies in the face of it to say, but but we're gonna need, you know, a for our resource to be there for four hours and not be able to reaward or reoptimize, which we will do.
    I I think we are aligned with the IMM on the non spin proposal.
    I think theirs is one hour qualification and one hour SOC, which which I would be fine with.
    I'd like to see that ECRS number go down.
    An option would be edits to to the IMM's comments to to bring that ECRS number to fifteen minutes.
  • 00:40:57
    I'll I'll let Andrew discuss that in a minute.
    But, you know, overall, I think this obviously has implications for batteries, but I think it has implications for the supply of ancillary services and ultimately the the price.
    Right?
    We are talking about a four hour SOC requirement for non spin for a five minute award.
    So that's 48 times the SOC.
  • 00:41:21
    I I'm not saying we shouldn't have any SOC.
    I'm not even saying we shouldn't have multiples of SOC, but something like 48 times is a lot.
    And since we're in five minute intervals, that kind of restarts every five minutes.
    So we're just looking for something that would, you know, kind of keep prices aligned, with what they should be and and supply of ancillary services aligned with what is actually available and not, stranded megawatts that are willing and able to provide ancillary services.
    I'll leave it at that.
  • 00:41:54
    Thank you, Caitlin.
    Nanika, go ahead.
    So maybe I'll start here.
    To this conversation about duration is less relevant to the fact that SCED can go and reprocure AS every five minutes.
    Because when you say, hey.
  • 00:42:12
    SCED can go and get it from some other resource, you are inherently assuming there is somebody else available with energy, and that's not a given.
    At least right now, so I mean, if you think about how the tools are being set up, we don't know for a fact that there will be some other resource available.
    So coming back, the duration, the requirement here is really tied to the product that we are procuring and is in is and helping describe how much energy we need when we procure non spend, how much energy do we need to be available on the system, How much energy do we need to be available on the system when you procure ECRS?
    The the fact that we can go procure it from some other resource, yes, it's correct, but it's not this is more about how do we want to define the product and less about where we procure it from.
    So I don't think the fact that you get flexibility alone is sufficient.
  • 00:43:08
    What we are trying to ensure is there are resources available on the system with the energy so that when we have events, these are unforeseen events.
    When we have events, we have runway to operate the system reliably.
    So so this conversation to us, is truly focused on ensuring energy is available.
    Now one other piece, here that I'll I'll point out, I know there were quite a few points made, in your conversation.
    We did look at externally outside of ERCOT what were other regions using to set up their duration requirement.
  • 00:43:45
    And every region that we looked at has a sixty minute requirement for all of their AS products.
    Is the only one that's different where regulation alone is a thirty minute product.
    Everything else is a sixty minute product.
    Now I'll put to you the numbers you've proposed here are on an islanded grid like a cart, which is solely reliant on its own energy, and it's looking at a big fleet of storage coming in.
    So I so when you when you post some of these numbers, also keep in mind what is the world outside of us which has more resources to rely on, looking as their policy standards versus what we are doing.
  • 00:44:22
    To us, where we are starting out for regulation and responsive reserve are completely needed to ensure that when we have events and this is a new tool that we'll be putting into the system.
    When we have that new tool, have issues.
    When that tool goes down, we are able to operate the system and continue to operate reliably and not find ourselves in fault.
    Now same thing applies in the non spent case also.
    I know the questions being asked was, well, how is history of deployments alone sufficient?
  • 00:44:52
    You are right.
    Potentially, the length of deployments may change as we enter into this new system and we operate the system differently.
    All of the capacity that's available and all of the energy in in the in RTC is available for RTC to use.
    So it's very possible that deployment lengths may change.
    And that's partly why we conceded it that there is value in revisiting these durations periodically to ensure that they they meet reliability objectives and, and and other objectives.
  • 00:45:23
    But at least as we enter into RTC, go as we are thinking about going live with this new set of market, four hours is justified based off of how we've seen the events, come up up on our system.
    I'll pause with that.
    Thank you, Nedika.
    Okay.
    We have a queue.
  • 00:45:41
    Let's start with Blake.
    Blake Cole, LCRA.
    Just listening to the conversation play out between the the sets of comments.
    We think that the IMM suggestions may have some merit, but to Katie's point, maybe longer term than we need today, maybe a bit out of scope than what we can handle today.
    In terms of the the comments on the screen here, we we have some concerns with decoupling the duration requirements, especially given the concerns Nitika laid out, concerns that ERCOT would not have the reserves that they think they need, for the longer duration events.
  • 00:46:21
    So I think that just kind of and I know that there are folks in the room that disagree with that point of view.
    So I think there is merit in pushing that debate, out, which I think was suggested in Burcotte's comments.
    Let's have that conversation on a different path.
    What's most important to us is to get something in for the testing phase, so I think it would be reasonable to get ERCOT's suggestions in.
    We see how that plays out during tests and perhaps, some of the other points are are kinda proven out during that process.
  • 00:46:54
    So I guess we would be supportive of moving forward with their comments.
    Thanks.
    Like, is that a motion?
    Not a motion.
    I'd like to hear some more conversation.
  • 00:47:06
    Okay.
    Perfect.
    Shane?
    Shane Thomas Shell.
    Yeah.
  • 00:47:12
    We're supportive of the the ERCOT comments as well and have a lot of concerns with decoupling.
    To me, it's ERCOT has identified, you know, a potential, you know, design parameter requirement that we need these this line of a duration to maintain liability, you know, based on the current, state of the grid.
    And if I know that potentially, you know, ASL often compared to insurance.
    If I know that potentially I'm gonna need a hundred thousand dollars of coverage to replace my house, and I go out and I procure insurance, and I've been keep procuring it for a long period of time.
    So I'm paying one company for, you know, twelve hours, you know, for twelve years in the insurance role to supply my hundred thousand dollars, but I know this whole time, they've only had $200,000 in the bank.
  • 00:48:08
    Well, they're they're kind of saying, well, don't worry.
    There's some other insurance companies that will step in and finish paying it out for you.
    Well, not really fair to the other companies that haven't been getting paid for twelve years to provide that service.
    They're only getting paid after the fact.
    And maybe those people also had you know, it was a bigger event, and they also got depleted by having to provide, you know, to people that they were covering.
  • 00:48:32
    So they're were also depleted at the same time.
    There's no guarantee that those other, you know, insurance companies will be there to provide this in a big state of emergency.
    I also think that, you know, longer duration requirements could encourage, you know, longer duration resources, which is always a good thing when we're looking at the state of the grid.
    And there's not a lot of, things encouraging that right now.
    So at least one market signal out there would be good.
  • 00:49:00
    I mean, you can look at the ELCCs, and it's obvious that longer durations can provide more reliability.
    Revisiting, these metrics post RTC, I think there's merit in that as well as we're getting seeing how the grid operates, and the system will continue to change, and so the reliability needs of the grid will continue to change.
    Reducing AS requirements, AS duration requirements, you know, pretty significantly, potentially going into RTC when we don't know how it's how it's actually gonna play out in real time is pretty concerning to me.
    I think that it'd be much better to go into this hiring on the conservative side, you know, especially going into winter.
    We're going straight into winter when RTC goes live.
  • 00:49:53
    And winter events, you know, there's been some pretty long duration winter events.
    You know, some would even wait to greater than four hours in there.
    So, and to point out, at ERCOT's, analysis around the four hour duration requirement for non spend, there were a lot of events in that that were greater than four hours even, much greater.
    And so this won't cover those, and they didn't impose any kind of decide decision to cover all the events that they've seen historically.
    So they're still being pretty conservative on the four hours, in my opinion.
  • 00:50:31
    Thank you, Shane.
    Next up, we have Mandy with Plus Power.
    Hi.
    Hi.
    This is Mandy Metters from Plus Power.
  • 00:50:43
    I'm I'm new.
    I'm gonna caveat this with I'm new to this, to the RTC plus b process.
    So if if there's an ignorant statement, then, you know, please forgive it.
    But as I look I'm I'm not new to the I'm not new to the industry.
    And as I look at this at at what ERCOT's trying to do, it it looks, smells, and tastes like this is trying to to give batteries a firm fuel requirement and and make it act like a thermal generator, which it's not.
  • 00:51:11
    And and I think that fundamentally misuses and and underestimates the ability of batteries.
    The the the purpose of having batteries on the system is is the millisecond response.
    And if we're requiring if we're requiring a four hour duration, that that's that's fundamentally and I understand it's not a five minute award, and we'll get I'm gonna get to that next.
    But that's that's misusing the the benefits of batteries.
    I don't think you're gonna get the benefit that you want and that you're looking for in reliability by having that loan of a duration.
  • 00:51:47
    And so we for that, we agree with, the IMM's comments.
    We are really we are deeply concerned.
    Pulsed Power is deeply concerned about the five minute award versus the four hour state of charge.
    That that that's that's a huge concern of ours.
    And I wanted to speak to you know, Shane may made an analogy of insurance companies, and he he's going in the right direction, but it's not the right analogy.
  • 00:52:13
    What ERCOT is trying to do here is procure $400,000 of insurance on a hundred thousand dollar asset.
    And and that's if we're going with the insurance analogy, that's how we should be looking for it.
    And would would anybody go out and procure $400,000 of insurance on a hundred thousand dollar house?
    We would not.
    And and, frankly, the insurance companies won't pay that either.
  • 00:52:34
    And and ERCOT's not trying to pay for it.
    They're trying to pay for a five minute award.
    Those are my comments.
    Thank you, Mandy.
    Katie?
  • 00:52:45
    Thanks, Diana.
    So based on my earlier comments, based on Nitika's response to the joint comments, and then based on the comments from Blake and Shane, I would like to make a motion to approve the ERCOT comments.
    Okay.
    We have a motion by Katie to approve the ERCOT comments to move us Just I'm sorry, Katie.
    It's real quick.
  • 00:53:10
    ERCOT comments didn't have any red lines to them.
    They were just laying out So is it endpoints.
    So this would be as submitted.
    Okay.
    Yep.
  • 00:53:18
    As submitted.
    The NPRR as submitted.
    And could it also include urgency?
    With urgency.
    Yes, sir.
  • 00:53:24
    So it would look something like this.
    Grant 1282 urgent status, recommend approval of 1282 as submitted, and to forward detect 1282, and it's, April 29, no impact IA.
    So next time, can Corey just make a motion for it?
    Because I he has several, I'm sure, just waiting.
    Put through an MTRR to grant me such power.
  • 00:53:43
    That it could never go wrong.
    Okay.
    Let's, so we have a second by Blake.
    Okay.
    So we have a motion by Katie and a second by Blake.
  • 00:53:58
    Sorry, Bill.
    Did I miss your second?
    Okay.
    Okay.
    Do we wanna keep working through the queue?
  • 00:54:08
    Okay.
    Just wanna make sure everybody was all good.
    Xin with the Aiolian?
    Yeah.
    Thanks.
  • 00:54:17
    Yeah.
    I think, you know, the the challenge I I I suppose I have two points.
    I I do have a question for the joint commenters, but, just in regards to the philosophy behind this, I really feel like we're revisiting a lot of the things that we were trying to come to agreement on an NPRR1186 and just feels like this is a step backwards.
    I would say, you know, the four hour requirement and the duration requirement, the one thing that's really different about this compared to NPRR1186 is that at least with the the sloping line over the course of the hour, there was credit for deployment.
    Under this new version, there's actually no credit for deployment.
  • 00:55:08
    So every every schedule, we are, we are judged based on a four hour requirement.
    Right?
    There's no there there's no credit here for deployment whatsoever.
    So so any battery that's in a long duration product, I actually think it's runs counter a bit to the IMM.
    They're not gonna wanna deploy.
  • 00:55:29
    They're if they have a day ahead obligation, they're gonna wanna stay in, in ancillaries, especially if those ancillary services are spiking relative to their LMP.
    If if there's a lot of batteries on the system, you know, I suppose what's the what's the point of having them there?
    I do appreciate that that we are looking at reducing the the duration requirements, but I I don't understand the purpose of of four hours with, with with with essentially no credit for deployment.
    Thank you.
    I I also just wanted to ask another question too for for the joint commenters.
  • 00:56:19
    Yeah.
    This notion of decoupling, I think it's in section six.
    Yeah.
    Enforcement.
    Again, this this goes back to November and and one of the things that we were we were fighting so hard for, you know, the the use of the word enforcement, we think, is is is not the best choice, the use of the word, because we really don't think that this is about enforcement.
  • 00:56:55
    This is about how how the SCED clearing engine works.
    And enforcement sounds like there is a there there's a there's a penalizing action here.
    But I don't think that was really the intent, was it, Caitlin?
    Yeah.
    I I agree with you.
  • 00:57:14
    So well, there there's a penalizing action in in RTC.
    Right?
    If you you don't get the if you had a day ahead AS award and somebody more technical than me don't get mad and you don't get the award in real time, there's an imbalance charge.
    I may maybe that's semantics to not call that an enforcement action, but there is a consequence to not having the SOC that you need to have to fulfill the award either way.
    And Right.
  • 00:57:45
    As you articulated, SCED will only give you that award if you have the SOC, which I think is appropriate.
    But if it's a matter of of using that word, I I see Andrew in the chat says constraint could work.
    Yeah.
    Yeah.
    I think I think that would be more appropriate.
  • 00:58:07
    Yeah.
    I do think the imbalance payment, you're right, is the penalty.
    Right?
    That is the penalty.
    I mean, what's the penalty insofar as you have you have made a day ahead obligation or you've been paid in the day ahead, and now you're being asked to to fulfill that in real time.
  • 00:58:24
    And that's actually a hazard for any resource, by the way.
    You know, any resource who's committed in the day or or has been paid in the real in the day ahead is potentially in a hazard of not being able to fulfill that in real time.
    And if RTC, which, you know, in a scarcity event favors energy, because it has to release something, right, like it has to release something, you know, the longer that duration requirement, the less likely it is that, that that, you know, a battery is going to want to participate in that product.
    Maybe that's maybe that's really the design of the system.
    Okay.
  • 00:59:05
    Thank you.
    Andrew?
    Oh, oh, sorry.
    I'll cede to Andrew, but I still had comments that adds my response.
    But but you can No.
  • 00:59:17
    I I took myself out of the queue.
    Okay.
    Hey.
    So we can keep it moving.
    Yeah.
  • 00:59:22
    Caitlin, go ahead.
    I'm sorry.
    Okay.
    Thanks, Diana.
    So I would point out that we are, quote, unquote, decoupled today, at least for non spin and ECRS.
  • 00:59:33
    And I actually think it makes more sense under RTC because of the real time flexibility.
    But as I said earlier, I'm I'm not wedded to it.
    Right?
    The point of that was for us to offer as a compromise the longer qualification durations to address some of the concerns about capabilities of resources, and and, you know, being able to to cover things and and the incentive for maybe longer duration batteries to to provide these services.
    Mandy, I was going to make the exact point you did to to Shane.
  • 01:00:13
    Sorry, Shane, to to harp on your, your analogy.
    But in the insurance analogy, right, it's it's not that we would have a hundred thousand or or less.
    It's that we are being asked to have 400,000.
    And, you know, if you have a two hour startup time where you're at half an hour startup time where you're not online yet, maybe you only have the eightieth 80 ish thousand instead of a hundred thousand.
    So I just wanted to make that point.
  • 01:00:41
    We don't talk about it very much.
    I will not surprisingly be voting no on the the the motion on comments.
    I would be willing, if that fails, to offer a motion on the IMM's comments, ideally changing the ECR restoration on their comments to thirty minutes.
    But but I will let the the motion play out.
    Thank you, Caitlin.
  • 01:01:09
    Harika?
    Well, hi.
    Good morning.
    Thank you so much for letting me comment.
    I only wanna refer to do answer service study.
  • 01:01:18
    The commission did an approved findings because there were some comments made.
    Okay.
    If we agree to ERCOT's proposal, will ERCOT really come back and address other issues?
    Yes.
    They will, and they have to.
  • 01:01:31
    And this was a finding.
    I put the link, to the our AIS, final findings of commission in the chat.
    I also put the finding seven d.
    Derivation requirements, is an item commission asked our current stakeholder to revisit, but only after RTC has been stabilized.
    So there is an action item in our homework to revisit all these issues as the grid is changing.
  • 01:01:56
    So I just wanted to bring that to to your attention.
    That's all.
    Thank you.
    Thank you, Hariko.
    Bill, are you still in?
  • 01:02:08
    Okay.
    Eric?
    Mark, go ahead.
    Sorry.
    It's Mark.
  • 01:02:20
    I was just using Eric's card.
    I might be able to get on board with the motion, but what I'd like to ask is that in order to do that, we modify the motion to establish a date certain for revisiting the parameters in a joint ERCOT and stakeholder process.
    You know, I don't wanna belabor past history, but we we had what seems to me kind of a similar issue with ECRS where, we knew we needed to revisit the process of deployment of ECRS, but we couldn't get it done until we set a date certain into the rules.
    And the date certain led to ERCOT doing a more creative analysis, and we resolved the problem without even an NPRR or anything like that.
    So, in order to get me behind the proposal, I have to have agreement on some kind of date certain to revisit in a joint stakeholder in our cut process.
  • 01:03:19
    Thank you.
    Thank you, Mark.
    Okay.
    Eric Gough, are you in?
    No.
  • 01:03:32
    Okay.
    Bob, go ahead.
    Yeah.
    A lot of what, I was going to say has been said, but I just wanna put an emphasis on a couple of things.
    You know, it it kinda tends what I'm kinda trying to hear from sitting back listening is that somehow what we've put out here is increasing risk.
  • 01:03:59
    I don't see that.
    It's doing the same thing that we do today pretty much, with the decoupling of day ahead and real time.
    That's what we did with NPRR1186.
    So I just wanna throw that in there.
    The other piece is is, you know, that was brought up about the imbalance, and there's also the potential.
  • 01:04:15
    I think, Saez told me it may not, but I'm I haven't got my head around it yet, is the ruck short charges also.
    I mean, if you look at the way the day ahead and real time plays out today is you have an hour obligation in the day ahead, and then you fulfill that.
    And you have in that hour, you've got your triangle that you do.
    What this does when you go to real time co optimization, it still does that triangle.
    But it does it by SCED dispatch.
  • 01:04:49
    And as was mentioned the other, you don't get credit for that.
    Like, for every five minutes, it's gonna constantly be reduced down.
    You're gonna create imbalances if you look at it that way.
    And then I'm also concerned about the potential for Ruck short charges whenever you're off that that one hour requirement you had in day ahead.
    So that's my other concern with that.
  • 01:05:11
    So I'll just leave it at that.
    So, of course, you know where I'm gonna be going.
    Thank you, Bob.
    Jeff Billow?
    Good.
  • 01:05:21
    Just, wanted to respond to some of the comments and and also clarify that the the real issue here is that SCED only looks ahead five minutes.
    And you have a needs.
    We have historical needs that we have seen where we need this non spin AS product.
    We we need to call on that for, we we've had 65 instances in the last seven years.
    If you look at the analysis that Nithka presented, 65 instances where that need lasts longer than five minutes.
  • 01:05:58
    And we've had several instances where that need has lasted at least four hours.
    And so SCED, it it's it it's procuring that product, but it can't see more than five minutes ahead.
    And so so with that design, we have to make sure that the the resources that are providing that service, that they have enough energy to be able to provide that product for the the length of time that we need to call on that product.
    Now I I think that, IMM in their comments, somewhat Eric in in his comments pointed out that, hey.
    There may be better ways to do that where you don't have to, make sure that you have that energy that you're procuring in RTC.
  • 01:06:44
    You don't there may be better ways to do that, and we agree that that's something worth looking at.
    But that's not go live.
    That that's not the system that we're gonna have.
    We're gonna have a system that is only able to see five minutes ahead.
    If we can make sched look multiple hours ahead, you know, that that may be a different story, but at go live, it it's really only looking five minutes ahead.
  • 01:07:07
    And so, you know, we we want to make sure that when we're procuring that in real time that that we've got that that energy that we need, when we need it.
    We and to go back, I I think the the flaw in some of the comments is assuming that there will always be something else out there, some other resource out there that we can call on.
    And I think that that's just not we we've seen historically.
    That's not always the case.
    And and so we need to make sure that we're getting the energy that we need.
  • 01:07:40
    Also wanna say, remember, non spin is a small portion of the market.
    We are not asking batteries to be thermal plants in all of the rest of the market.
    It it's this one AS product we're saying we need four hours because that that is what that product is.
    It it's not just a capacity.
    It's it's a capacity, plus there's some energy that needs to be behind that that capacity.
  • 01:08:06
    Also wanted to address the the triangle comment.
    I I think that the triangle was a kind of kludgy Band Aid way of, doing, getting what we needed when, we had the AS procured in DAM and not reprocured in real time every five minutes.
    So it's it it's it was a lot of flaws with that methodology.
    I think nobody ended up liking the the way that that's working today.
    The operators hate it.
  • 01:08:39
    Everybody we don't like it, but that's that's what it was.
    We're you know?
    So I I don't wanna use that as as, the the the poster child for this is the way things should work.
    That that was not a good way to you know?
    But it was based on our system limitations that we had going in, to, before RTC, then that that's what that was.
  • 01:09:00
    So, I think that's all I have for right now.
    Thanks.
    Thanks, Jeff.
    Navaraj?
    Yes.
  • 01:09:08
    Thank you.
    So my question to Andrew, this is straight to I think Caitlin mentioned about the thirty minute ECRS.
    Right?
    So question to Andrew is, are you guys okay with that thirty minute plan?
    Hi, Nava.
  • 01:09:27
    Right now, we're having a hard time convincing people to do one hour for non spin.
    So the idea of really making the case for thirty minute ECRS seems sort of implausible right now.
    We did some analysis on this during the AS study, and that analysis was not particularly sophisticated and airtight.
    But it did seem to suggest that one hour was longer than necessary for ECRS.
    Gets a little weird.
  • 01:09:54
    Maybe it's thirty minutes.
    Maybe it's forty five minutes.
    So I don't have any particular heartburn about ECRS, only lasting thirty minutes.
    That said, there is one kinda wonky concern we have going forward, which relates to comments we've made about shortage pricing and ancillary services in general, which is that if we ever want to design the ancillary services to be more kind of hierarchically substitutable with each other, it can be tricky if they have different duration requirements.
    And, you know, as far as reformulating the AS demand curves, all of that gets a little weird.
  • 01:10:33
    And so that would be a concern kind of down the line.
    But if we were just drop DCRS to thirty minutes with the current shortage pricing mechanism we have, I don't think that we would necessarily be opposed to that.
    Thanks.
    Brian Sims.
    I was really encouraged to hear Mark Dreyfus try and compromise, with a date certain, and I also would support some kind of date certain review.
  • 01:11:06
    It seems like, one, we have an assignment from the commission to review this anyway, with the comments that Harika posted into the chat.
    And secondly, I think there's a annual review of ancillary service, procurement where the, qualification can also change.
    But then I also saw a vigorous discussion between, Corey and Mark here just a minute ago about what, amendment to the motion might look like.
    So just curious.
    Fill us in on your conversation.
  • 01:11:42
    Bart can counter me.
    He he had name checked ECRS.
    So, obviously, that triggered a trauma response in me.
    The when NPRR863, after its numerous metamorphosis has turned into ECRS, there were dates certain put into that motion.
    But unlike this one, those were dates certain far enough in the future to say do not implement certain pieces of this language until some date in the future.
  • 01:12:07
    So that was intentionally baking in runway to not shock the system with new ancillary services, give folks time to file corrective NPRRs to fix things that they didn't like or get everything in place.
    So I was making sure that Mark understood that the dates that we worked into ECRS don't apply here because these are things we're trying to put in right away to make sure RTC market trials look great.
    And then anyone is free to file an NPRR to modify any and all of these dates or any of the other 2,000 plus pages of protocols at any such time as they want.
    And so getting a commitment from ERCOT to say, we'll do an analysis on noon of January thirteenth of twenty twenty six wouldn't mean anything.
    So my vigorous conversations with them were, is there some way of verbally committing to the market that in addition to all the timelines that were being given from the commission, we'll obviously we'll adhere to those, but that any reviews of the AS methodology that we'll be undergoing, like, certainly for ancillary services for 2027, this would be one of those things that gets brought into the discussion of, have you thought about this?
  • 01:13:11
    So if there was any kind of certainty folks needed of that, yes, we'll talk about this stuff again, I would think every conversation about AS starting in 2026 forward would have some component of folks asking or cut about this analysis.
    Yeah.
    You you make a really great point.
    It seems like the 2027 ancillary service methodology is gonna have this conversation as part of it anyway.
    Or RTC has fixed everything, so, you know, we won't need it'll be a very short conversation.
  • 01:13:36
    But, yeah, that would be my hope, but I'll stop talking for Nitika.
    That's dangerous.
    Yeah.
    I mean, I've said this again and again.
    I we are happy to revisit this with with more experience.
  • 01:13:54
    Harika has pointed out that we are held to revisiting it under what was written with the AS study.
    And, definitely, the the task we have under AS study is an involved task.
    There is several components to it.
    So we will, we will be open to revisiting it.
    I if you want me to say twenty twenty seven AS methodology, sure.
  • 01:14:17
    Yes.
    We can do that.
    But this is, we under we don't take this recommendation lightly.
    We understand what we are asking for.
    So, yes, we are definitely looking, eagerly to see how the the system outcomes will change our change the change the risks we foresee on the sis to come down the road.
  • 01:14:45
    Okay.
    Thank you.
    Caitlin.
    Okay.
    I took notes.
  • 01:14:50
    I was encouraged by Brian being encouraged, but I think Corey ruined it.
    I I appreciate the conversation around revisiting this.
    I'm still gonna vote no.
    Corey, I do have a procedural question.
    We coupled the urgency and the motion to approve to together.
  • 01:15:09
    Correct?
    But they would be separate motions?
    If someone would like to vote, like, because I am willing to vote yes for urgency, but I would vote no on the substance.
    So I can vote no on the whole thing or Eric's motion to divide the question.
    I don't know what that means.
  • 01:15:35
    Would would you be the people making the motion be agreeable to separating those into two motions?
    I mean, Caitlin, I'm not sure what that gets us.
    Right?
    If everybody I would just have to get some urgency, but then we really need to pass something today.
    So, I don't wanna say I'm opposed, but I I would like to see how this vote goes.
  • 01:15:58
    It's been out there for a while.
    So would like to see how this goes with the motion on the table.
    Okay.
    Okay.
    Harika, thank you for reminding us of that provision.
  • 01:16:11
    I think I would just note, that, you know, us having different durations would not make this take more time.
    You know, that was my point in supporting urgency.
    We we do want this on time for market trials.
    We're we're not asking for months of analysis or anything that would require a system change, and we did all of that.
    And for the sake of of compromise in getting this through for market trials, we would just be wanting different parameters at this time.
  • 01:16:39
    And and I'll reiterate that the future motion I would make, if even applicable, would be the IMM's comments to the the one hour for non spin, but to make desktop edits to that to go to thirty minutes for ECRS, and we can not decouple those.
    I appreciate ERCOT's concerns with not being able to see five minutes more than five minutes out.
    With those values I said, you would still get 12 times that and six times that.
    And I will leave it at that.
    Thank you, Caitlin.
  • 01:17:16
    John?
    Yes.
    My question is not really about most of the last part of the discussion, but whenever ERCOT said that there was only one SCED that brought to mind NPRR351, which, which, is has a look ahead SCED, is what it was called.
    And are we not gonna have that piece in the real time in the RTCP, RTC+B, or so that these things could happen?
    We will continue to have an indicative pricing that's hosting both the LMPs and the ASMCPCs out, I think, maybe fifteen minutes or so like it is today.
  • 01:18:05
    $3.51 is fifteen minutes.
    Yeah.
    So I I think that that that was the minimum thing, but I think we do post more than that.
    I think you post an hour, actually.
    Yeah.
  • 01:18:14
    Yeah.
    Okay.
    Then And so super interesting.
    Will it include state of charge in look ahead, sched?
    That's was It will be the same optimization model as state of charge, but there are a bunch of assumptions in that.
  • 01:18:29
    So, I'll have to get the details back to you.
    And because I think all that it is doing is, we don't know how the energy accounting I don't know that fact yet.
    I have to talk to development and figure that out.
    Yeah.
    But main main thing is it's not binding.
  • 01:18:48
    Right?
    So so if if you run out if it sees you run out, it's not gonna change how we dispatch the next five minutes.
    Right.
    But it is a forecasted, that is available.
    We don't have just the next five minutes.
  • 01:19:05
    So that's all I'm trying to get to is that I thought that there was some pieces in here that would help this, but, because I have not made up my mind on some of this yet.
    But so Yeah.
    It it This that's all I was asking was, is it gonna be there?
    Is it and could ERCOT leverage that?
    Yeah.
  • 01:19:31
    I I I think if you could take that and make it binding, then I think that would help.
    But that's that's a system change, and they're you you know, Sai and Andrew will tell you there's a bunch of hair on that that we'd have to kinda work through with stakeholders.
    We have an all we'll have an intense discussion on the make whole payments required.
    So I I think that's the multi interval market that Andrew is talking about.
    We need a separate task force for that.
  • 01:20:05
    Okay.
    Dave, did you wanna join this conversation, or should we or is it on something different?
    If you don't mind, I can make it quick.
    I I just wanna be clear just what what Jeff and and Sai were saying.
    I to the to the question and and why it's not particularly helpful for this is it's not really designed when we talk about the look ahead scan and indicative pricing, it's not really designed to optimize around the full study window and to change the dispatch for the current interval to try to account for what's happening later, particularly because it's just for indicative pricing.
  • 01:20:42
    It's it's essentially designed to not affect the dispatch for that first interval.
    So that's just a really big distinction of why it can't be useful in its current form for for what we're talking about here.
    You really have to go the path that I think Andrew's thinking about, that Sai we're talking about, where we would actually look at the whole study window and try to potentially adjust what we're doing for this first interval to account for what may happen later.
    So thank you.
    I just hopefully, that's helpful.
  • 01:21:13
    Thank you, Dave.
    Andrew?
    Yeah.
    Sorry to interrupt you, John.
    I just get a little excited when we start talking about look ahead, sched.
  • 01:21:22
    That doesn't happen very often.
    I used to work on that when I worked in market operations that ERCOT.
    So, I want to agree with a lot of what Jeff Billow said and for the parts I don't agree with, express some sympathy with them.
    I do think that a multi interval real time market and or some combination of that and some kind of short term unit commitment process is probably what's actually needed to resolve this problem.
    All of this horse trading over duration requirements is just kind of beating around a more explicit solution.
  • 01:22:00
    That said, our concern with these duration requirements is that they're not going to get you the reliability you're trying to get by imposing these duration requirements.
    And I'll I don't wanna belabor the stuff that I wrote in the comments, but I'll just give a pretty simple example.
    And I'll relate it to what various folks have said about the imbalance risk.
    There's a lot of risk for batteries participating in DAM at all under RTC because there's inherently going to be uncertainty between day ahead and real time and their ability to fulfill their ancillary service obligations given that their state of charge is necessarily going to change from what they thought it would be in day ahead to real time.
    And there are things that could be incorporated to make that less risky.
  • 01:22:50
    DAM doesn't even account for state of charge right now, so that's already a pretty big risk inherent in participating in DAM.
    And to the extent that participating in DAM can give both the operators and the resource owners more certainty about what's going to be going on in the next day, it is beneficial for system reliability to have more resources participating in DAM.
    So that is a legitimate issue to be kind of sorted out.
    Our concern really is how this stuff plays out in real time.
    And if we're looking at a multi hour period during the day where prices are going to be elevated and I'm a battery, let's forget about whether or not I have any damn positions.
  • 01:23:35
    I can only sell a quarter of my capacity as non spin, whereas I can sell all of my capacity as energy.
    I'm gonna reflect that in our my offers.
    And when SCED sees how expensive it is to give me non spin versus how expensive it is to award me energy, I'm gonna get dispatched for energy.
    And so that's the there's both an implicit and an explicit way that this kind of requirement is going to lead to batteries being discharged.
    The implicit way is how people are going to formulate those offers.
  • 01:24:04
    The explicit way is then how SCED reads those offers in deciding, you know, how much any of this stuff is going to cost.
    The offer for non spin is going to be a lot higher.
    And at some point, the price spread can only be so high.
    And if you have the same price for non spin or energy, SCED's going to want to get four times as much energy than getting a quarter as much non spin.
    And so I just don't think that these duration requirements are going to result in getting longer lasting reserves.
  • 01:24:32
    They're going to result in more expensive reserves, more expensive energy, batteries selling energy, running out of energy.
    So that is the gist of the concern that we have as far as how this will play out in real time.
    Thank you.
    Sheen?
    Okay.
  • 01:25:00
    If you're talking, we can't hear you.
    Sorry about that.
    I thought Oh, you're good.
    Okay.
    There you are.
  • 01:25:05
    Yeah.
    I thought I did.
    Yeah.
    I just wanted to say, yeah.
    Yeah.
  • 01:25:11
    Sorry sorry.
    I kind of got heated there for a bit.
    You know, November was a was a long fight for us and then, you know, just some trauma there.
    But, yeah, to Andrew's point, you know, I think taking away the data position, you know, absolutely we feel the the same way and very much the same thing.
    You know, we understand that there's trade offs in every design, and we think that this is the likely outcome for now.
  • 01:25:37
    But we appreciate, you know, ERCOT's willingness to to revisit this.
    And we like the idea of a date certain, you know, sometimes hard to achieve.
    We like the idea of it, though.
    We think that that allows us as stakeholders to revisit this.
    And, you know, frankly, you know, we we'd love to, we'd love to figure out how to, sidle up with the IMM and and ERCOT to figure out, you know, really how to be more forward looking about this.
  • 01:26:09
    And, I think I think we're still on the fence on how we'll vote today.
    You know, we don't like the urgency.
    Obviously, I think this is driven more by software timelines, but but we like that that ERCOT is saying that they're open to it, and we'd like to figure out how to how to work with them on that.
    Okay.
    Thank you.
  • 01:26:31
    Mark?
    Thank you, chair.
    You know, I think most of us in the room and in these stakeholder processes, we don't have individual experience into how these important resources are being deployed.
    So we have to listen to these conversations in order to to evaluate, you know, what we believe is right for the market and and how to vote.
    And and I have to tell you, Andrew's comments make a lot of sense to me.
  • 01:27:05
    Though, as I said, I'm not a detailed expert in how this operates, but that makes a lot of sense to me.
    And and so I'm back to I think we need to set a date certain for reviewing the duration parameters in a a really thoughtful and deep way so we make sure that we have, the right answer for the long term going forward as we integrate these really critical resources into our system.
    So I wanna be sure that that I interpreted Nitika accurately, that she is agreeing that for the 2027 ancillary services methodology study, which seems like a long way away to me, that we have a full commitment that we're going to do, a deep dive to revisit these first, and then I have a second question.
    Can I request you to repeat typos in a side buying world?
    So I I thought I heard you to say that for the 2027 ancillary services methodology, that we would have a deep dive into duration parameters with stakeholder input.
  • 01:28:26
    And if that is correct, then I am I am more open to supporting this, this motion recognizing that that it's a year away, and that seems like a long time to me.
    And I I heard your comment and Corey's comment about whether or not we have interesting days between now and then.
    But So I'll put it to you this way.
    Back to the AS study, there was a variety of different things we laid out in the plan of what our cut will do.
    One was transition to a probabilistic method for computing AS.
  • 01:29:03
    Next was they explore a dynamic AS procurement concept.
    Now and and I think, the p as, Erica pointed out, there is a timeline that at least the PUC put on our backs of by when we would look to, work with those, recommendations.
    There is a workshop on Monday where we are looking to kick off the AS methodology for this year, and we are I I'll give you a preview trying to shoot ahead of the timeline that the PUC put on us.
    So what that means is we'll try to bring a a probabilistic method this year.
    And with that to move through, next year, we'll be looking to work on that dynamic AS concept.
  • 01:29:46
    Now potentially, from a timing perspective, there may be value in us asking the question of duration, were we to be on that path.
    So there to me, there may be more natural, transitions.
    Just tied to, hey.
    We are looking to change how we procure our quantities.
    Does this impact how we see duration?
  • 01:30:04
    So there is some natural tying in.
    So we are happy to to, and now I'll go I'll put one more step further.
    Typically, when we talk about AS methodology, we do a backwards review anyways to see how did this how did the system perform with the quantities we procured, with the tools that we have.
    Do we need to change anything?
    So as a part of that, we are we will look to look at duration also because now duration is intricately tied to how AS is procured and how we operate our system.
  • 01:30:32
    So I'll see if that helps.
    I mean, if you want us to go any deeper into that saying, hey.
    We will commit to looking at it.
    I I think it will naturally be a point of question for us to ask in 2027.
    Okay.
  • 01:30:45
    I I think that is an answer yes to my question, which I appreciate.
    I I guess I have a second question, and that is related to, we're we're gonna put these parameters in place for the market trials.
    How will we review and evaluate the market trials and the success of the market trials at their conclusion?
    And will that evaluation include some review of of this issue?
    I do believe there will be some, but I'm also looking to see if Dave is on the line and wants to opine.
  • 01:31:27
    He may be able to have give you a better line of sight on market tile evaluation.
    Market tile serves multiple purposes.
    Understood.
    Right.
    One amongst it is giving the stakeholders a chance to test out the systems and understand how it plays and make sure that they are ready.
  • 01:31:41
    There is a closed loop aspect of it, where we'll test LFC and make sure frequency can be controlled.
    So, certainly, there is some of those we I don't know that we are intricately designing, a a specific test on duration.
    But things should read out as people start testing, and we will certainly be looking to look at the results also.
    So I'll pause with that.
    I'll see if Dave wants to, give you an answer.
  • 01:32:07
    Dave, go ahead.
    Hey.
    Yeah.
    Yeah.
    I can add to that.
  • 01:32:09
    Yeah.
    Thank you so much for letting me jump the queue a little bit.
    I guess there's and, Nitika, you're right.
    I guess I where I would see this likely coming into play, and and we've not necessarily listed as, one of the explicit things we're focused on, but it but it, of course, can be looked at, is probably more in the coordinated open loop testing.
    So we sort of had two forms of testing that we'll get into later this year.
  • 01:32:35
    One is focused on coordinated open loop testing where people will sort of altogether start to submit offers and telemetry and things of that nature into our real time coauthorization plus battery systems and and kinda see the outcomes that, come out of it.
    Why I'm thinking that may be a better way to or better time to focus on this question is you'll hopefully see more the type of telemetry and type of offers that people have in mind as we go into RTC+B, and you'll get to see some of the pricing, ramifications, I guess, if you wanna call it and and, you know, test some of the hypotheses that are being raised in terms of outcomes we may see.
    Closed loop testing, there may still be some value.
    It may not be as valuable for digging into this specific question, and I say that because for closed loop testing, we will have specific rules that govern the information that QSEs are sending us for their resources for the RTC systems because that test is really focused on how are we controlling the system.
    It's really testing our LFC and then it's working appropriately as opposed to sort of looking at what the market outcomes would be under RTC.
  • 01:33:52
    So, hopefully, that's helpful that just to kind of make a distinction between the two types of testing that we'll have and and where this may fit best.
    Yeah.
    Thank thank you for that, Dave.
    I I'd just say that at at the end of the market trials, we should have a check-in and see if we learned any valuable lessons and give everybody who participated the opportunity to share in that discussion.
    Thanks.
  • 01:34:17
    Okay.
    Bob Helden?
    Yeah.
    A couple of things.
    First thing is on on process.
  • 01:34:26
    You know, generally, we vote for urgency before we even discuss the language, and that's traditionally the way we've done things.
    In on a lot of cases, I don't know if we changed that completely.
    That's if it's not been posted in time.
    Yeah.
    Okay.
  • 01:34:41
    That's what I was just being checking.
    Wise, there are times where something gets posted where it's within the 14 call period.
    We pick it up, so urgency has to be taken up first before we can talk about that.
    And that's what I'm trying to get to is the urgency piece.
    I don't wanna vote no on urgency for for this, NPRR, but I I am gonna vote no for the way it's submitted.
  • 01:35:02
    But, I mean, I can make a motion to amend to pull out the urgency piece.
    And, well, first, let me ask another question.
    Because I'm trying I'm trying to understand the process on what we're gonna do.
    We've got a motion on the table that has urgency and, and the as submitted.
    If that fails, what happens to the urgency side?
  • 01:35:29
    It's it's available to be added in the subsequent motion.
    So if anyone wants to approve with the WMS, they can tack urgency on theirs.
    Right.
    Okay.
    Alright.
  • 01:35:37
    So that's one piece there.
    But I really rather just vote for urgency and then vote for this thing.
    I mean, if you want me to make a motion to amend and go down another vote, which I don't know which way it'll go, I'll do that.
    But, but that's what I wanna ask these one more time to the motion and the seconder if they wanna do that.
    If they don't, then I'm gonna make a motion to amend.
  • 01:36:00
    Bob, you got it.
    Let's do it.
    Let's break it up.
    Are we at the end of the queue?
    Are we at a point that we can vote?
  • 01:36:07
    We have three more people in the queue.
    Do we wanna take that?
    And then I agree with Bob.
    I second his hypothetical motion, but thank you, Kate.
    Thank you, Katie, for There's a need for a separate motion.
  • 01:36:20
    Let me just break the two out.
    I think I'm fine.
    Thank you, Katie.
    Appreciate it.
    Okay.
  • 01:36:25
    Okay.
    We still Seth is in the queue, and I think that might be the end of and then we'll see if we can get a vote going.
    Seth, go ahead.
    Yeah.
    It's just a quick question.
  • 01:36:36
    Am I able to vote even though I'm not in person?
    And I'm not a standing member of PRS, but I'm a corporate member.
    So may am I able to cast a vote, Corey?
    I've I'll go to a higher authority than me than me and go with Susie and the intent to vote.
    I don't know about that.
  • 01:36:53
    But, yes, Seth, if you would like, we we do prefer those, notifications in advance, but that is fine.
    If you will just send me an email to stakeholderservices@ERCOT.com that you are participating by Webex only so that we can validate you for voting purposes, but you are a corporate member and you are eligible to vote.
    Okay.
    Okay.
    Thank you.
  • 01:37:14
    You're welcome.
    Okay, Corey.
    So that officially takes us to a clear queue, I believe.
    Bob, go ahead.
    Yeah.
  • 01:37:23
    The the other part I wanted to talk about, there's been a lot of talk.
    Mark, you really hit it about revisiting these and doing that and then looking at doing it during the 2027 ancillary service methodology.
    This is gonna be in the protocol.
    So it's gonna take another protocol change to change this.
    It's not gonna be able to be changed just by the ancillary services methodology.
  • 01:37:45
    So I just wanted to clarify that, which we don't even approve the AS methodology to begin with.
    The board approves that.
    We only recommend approval or recommend nonapproval.
    So I just wanted to talk about the differences between that.
    It will take a new protocol revision to change this.
  • 01:38:05
    Thank you.
    Okay, Corey.
    So let's see if we can take the urgency first and then take up the motion.
    Is that what we Yeah.
    Okay.
  • 01:38:31
    K.
    First, I wanna confirm with Susie that the motioner and the seconder willingly changed their motion urgency.
    Okay.
    Bob Bob's threat of triggering three votes will now make us have two votes.
    Yes.
  • 01:38:43
    So get to the same part, but It's very much appreciated.
    Okay.
    So now we have a motion and a second by motion by Katie, second by Blake to grant twelve eighty two urgent status only.
    Okay.
    Corey, let's go.
  • 01:39:06
    Sorry.
    I gotta figure out where to slot Seth in.
    I'm so used to Seth being with DC Energy.
    I gotta figure out where he is and where he goes now.
    What Suzy, where does he belong?
  • 01:39:18
    The same as generator.
    Mhmm.
    Generator.
    I I I'm a power marketer.
    He's a marketer.
  • 01:39:25
    Wait.
    I'm they're marketers.
    I'm sorry.
    IPN.
    Thank you.
  • 01:39:29
    We don't want Seth in this segment.
    I heard that.
    Okay.
    On the motion to grant twelve eighty two urgent status, we will start up with consumers.
    Eric's not voting on this one, so Nava.
  • 01:39:59
    Is he yes, Nava?
    Mark?
    Yep.
    Thank you.
    Melissa?
  • 01:40:03
    Yes.
    Thank you.
    Thank you.
    Mark?
    Staying.
  • 01:40:12
    Thank you.
    Onto our co ops, Eric Blakey.
    Yes.
    Thank you.
    Joe down.
  • 01:40:17
    Yes, please.
    Thank you, Clark.
    Thank you.
    Blake.
    Yes.
  • 01:40:20
    Thank you.
    Lucas.
    Yes.
    Thank you.
    Thank you.
  • 01:40:24
    Andre, independent generator, Andy?
    Yes.
    Thank you.
    Caitlin?
    Yes.
  • 01:40:29
    Thank you.
    Katie?
    Yes.
    Thank you.
    Bob?
  • 01:40:32
    Yes, sir.
    Thank you.
    Brian?
    Yes.
    Thank you.
  • 01:40:34
    Thank you.
    Chase?
    Yes.
    Thank you.
    Shane?
  • 01:40:40
    Yes.
    Thank you.
    Kevin?
    Yes.
    Thank you.
  • 01:40:43
    Thank you.
    IPM's John?
    Yes.
    Thank you.
    Seth?
  • 01:40:50
    Yes.
    Yes.
    Thank you.
    Shane.
    Yes, sir.
  • 01:40:54
    Thank you.
    Onto our iReps, Bill.
    Yes.
    Thank you.
    Austin.
  • 01:41:02
    Yes.
    Thank you.
    Onto the IOUs, Jim.
    Yes.
    Thanks.
  • 01:41:10
    You, Aaron.
    Yes.
    Thank you.
    Bob.
    Yes.
  • 01:41:15
    Thank you.
    On to the.
    Yes.
    Thank you.
    Thank you.
  • 01:41:21
    Ashley?
    Yes.
    Thank you.
    Thank you.
    And Diana?
  • 01:41:26
    Yes.
    Thank you.
    Motion carries.
    Unopposed, one abstention.
    So you have now made twelve eighty two urgent status.
  • 01:41:36
    Okay.
    It's free for anyone else to make a motion now.
    Well, we have Katie's and we have Blake.
    So No.
    They that's the thing.
  • 01:41:45
    They they took theirs down.
    So by now, it's free.
    Anyone can make one.
    Alright.
    So can we make a motion to approve the NPRR as submitted with a second pipeline.
  • 01:41:59
    K.
    Not that anyone would have ever been as so sneaky as to use your change in motion to slide in ahead of you.
    Mhmm.
    Get a second ballot up.
    Bob, I'm I'm glad that wasn't your plan to slide it in.
  • 01:42:39
    I appreciate that very much.
    That's what we were over here laughing about.
    That's fair.
    Wasn't gonna do that.
    Yeah.
  • 01:42:46
    I do think we missed an opportune we've never done a motion to split a motion before.
    Right, Anne?
    It was a missed opportunity.
    Okay.
    Now we're back to the other half of the original motion.
  • 01:43:22
    Is there any other discussion on this motion?
    Are we good to run through?
    Alright.
    We will begin up again with the consumers with Nava.
    So is this the original motion?
  • 01:43:39
    The original motion was gonna be a combination of urgency and the language as submitted.
    Now that we've taken up urgency, we're back to the original mover and seconder made the same motion.
    So this is the ERCOT version as submitted.
    So not the joint comments, not the IMM comments, just good old recommendation.
    Yeah.
  • 01:43:58
    I'll go now.
    Thank you.
    Mark Dreyfus.
    Thank you.
    Melissa.
  • 01:44:08
    All abstain.
    Thank you.
    K.
    Thank you.
    Mark Smith.
  • 01:44:16
    No.
    Thank you.
    Onto the co ops, Eric Blakey.
    Yes.
    Thank you.
  • 01:44:22
    Joe down.
    Yes, please.
    Thank you.
    Blake.
    Yes.
  • 01:44:25
    Thank you.
    Lucas.
    Yes.
    Thank you.
    Onto our independent generators, Andy.
  • 01:44:30
    Yes.
    That's Corey.
    Thank you.
    Caitlin.
    No.
  • 01:44:33
    Thank you.
    Katie.
    Yes.
    Thank you.
    Bob Hilton.
  • 01:44:37
    No, sir.
    Thank you, sir.
    Brian.
    Yes.
    Chase.
  • 01:44:45
    No.
    Thank you.
    Shen?
    No.
    Thank you.
  • 01:44:50
    Kevin?
    No.
    Under IPMs, John?
    Abstain.
    Seth?
  • 01:45:01
    No.
    Thank you.
    Shane?
    Yes, sir.
    Thank you.
  • 01:45:06
    Thank you.
    On to the Ira, Bill?
    Yes.
    Thank you.
    Austin?
  • 01:45:11
    Yes.
    Thank you.
    Onto the IOUs, Jim.
    Yes.
    Thanks.
  • 01:45:15
    Thank you, Aaron.
    Yes.
    Thank you.
    Thank you, Rob.
    Yes.
  • 01:45:18
    Thank you.
    Onto the Munis.
    Hey.
    Yes.
    Thank you.
  • 01:45:21
    Thank you, Ashley.
    Yes.
    Thank you.
    Thank you.
    Diana.
  • 01:45:25
    No.
    Thank you.
    Motion carries.
    Slim.
    70% for, 30% against, two extensions.
  • 01:45:43
    Congrats.
    You've moved one NPRR off your agenda.
    Okay.
    Since we've been at this for a little while, let's take a ten minute break, and then we'll come back and we'll get into the rest of the agenda.
    Alright.
  • 01:45:58
    We'll see everybody back here around 11:26.
    Yeah.
    I'm gonna get on the schedule.
    What schedule?
    I'm gonna res reply because I was kinda at the the the validation note.
  • 01:47:22
    Got it.
    I didn't see anything in there about it.
    And I was like, oh, I guess I have made two for PRS.
    And then who?
    I didn't see it.
  • 01:47:33
    Well, it's on the website, on that one.
    And I and I've been sending it with a listserv, but on your validation thing, I didn't and even was telling me there's a way to do, like, a SEO in there.
    But the problem is, I can do that on your regular email.
    We haven't figured out how to do that in this.
    The way that I have to generate those codes with the formula, and then I do the mail merge.
  • 01:47:56
    Hey, Susie.
    You're not doing that yourself.
    So No.
    It's not yet.
    And today and it doesn't really matter either way.
  • 01:48:05
    Well, this one is so small.
    But today, because Okay, guys.
    Let's start to get back so we can keep going.
    Corey, is this some sort of, record for, like, one item by 11:30?
    Is that, like, a new No.
  • 01:58:41
    No way.
    The fast six six seven, rest in peace, had plenty.
    I think 863 had plenty.
    So now this is See.
    It's not as bad as it could be.
  • 01:58:54
    See.
    It's it's good.
    Tagline for PRS is always it could be worse.
    Cautiously optimistic.
    Right?
  • 01:59:23
    Okay.
    Let's go ahead and get started.
  • Item 5.2 - NPRR1283, Modification of SSR Mitigation Timeline
    01:59:26
    So the second item that we have for urgency vote is 1283.
    This is also coming to us from ERCOT with an urgent status.
    Does someone from ERCOT want to tee this one up for us?
  • 01:59:38
    I don't know, Matt, if this is you or Agee.
    Yeah.
    Diana, this is Agee from ERCOT.
    I can speak to it.
    So, this NPRR is fairly simple in in what it's trying to accomplish.
  • 01:59:53
    We've identified and recognized a a growing risk from subsynchronous pair resonance, and have identified a couple of events of subsynchronous bare resonance on the system, including one from, a generator that had, started through the commissioning portion of the, interconnection process.
    Because SSFR is, related to an interaction between the transformer and the system, there is that risk that, we might be allowing, initial immunization, to a project that is is, at risk for that under current protocols.
    So the current protocol language, requires that the SSR study, if it's required, and any mitigation be in place by initial synchronization.
    But because of this new risk, that is potentially present, upon initial energization.
    So this NPRR would update the relevant sections, to change that requirement that the, SSR study and mitigation be in place, from it'll move it up from initial synchronization to initial energization.
  • 02:01:17
    The reason we're asking for urgency, as I mentioned a moment ago, is that we've already identified a couple of events that have occurred on the system, and we are aware of some projects in the interconnection queue currently that are nearing commissioning and have this risk.
    So, we are looking to update the protocols to, protect the system prior to those projects seeking initial under station.
    Great.
    Thank you, Agee.
    Bob?
  • 02:01:50
    Yeah.
    Are we talking both urgency and language now?
    We're gonna try to I'm just joking.
    I'm I'm joking.
    A couple of things.
  • 02:01:58
    I understand what ERCOT's trying to do here.
    It's it's it's not as simple of a change as you think it is.
    It is on paper.
    But what this is going to do is for I don't know how many projects out there.
    It's gonna push them out.
  • 02:02:15
    That's gonna happen because of if you just change that to have all that done before your initial energization, that's gonna push the project out.
    So I don't know how many that's gonna affect.
    I don't know if ERCOT's even looked at that to see what that's gonna do.
    But, I've got my guys looking at that right now to see what what that would do to several of ours we have in the queue.
    So I think that as we do this, and I think we need to have more of a discussion on this than just approving it today out of here.
  • 02:02:46
    If you wanna call it urgent, I'm not sure about the urgency.
    I don't know what projects he's talking about that are currently could be a risk, but it appears to me through what they've written that this hasn't happened since 2023.
    So that kinda confused me on why it's all of a sudden from 2023 to now become an urgent issue.
    So I'd like to have the answer to that.
    The other one is there are if you push projects back that aren't gonna be here for the winner, which is worse?
  • 02:03:20
    Okay?
    So that is the potential for do for passing this urgently and not phasing it in in a time frame that would match what's going on in the world right now for what what we call delivery phase.
    And that changed the whole concept of that.
    So thank you.
    Agee, did you wanna respond or just leave it as is?
  • 02:03:43
    Yeah.
    I I don't have, specifics on the projects that we're concerned about now.
    I will say, you know, just despite the the events that are cited in this, the justification section occurring in 2023, I would also just add that this is a relatively, new risk to the system that we've become aware of.
    So, you know, I I think we're we're we know enough now to know that this really does need to be addressed prior to initial aneurysm.
    And so, you know, we're we're looking to have the the protocol language to accomplish that, and so that's the reason behind the urgency.
  • 02:04:27
    Bob, did you wanna respond?
    Yeah.
    Yeah.
    Hey.
    I get it.
  • 02:04:31
    I I fully agree.
    We've got a risk that's gonna get out there that we need to address.
    And that that was part of, you know, part of what I agree with.
    What I don't agree with is the timing of what we're trying to do it and the effects it's gonna have on the potential generation being here for potentially this winter or this spring.
    And I think that's a concern that we need to be looking at also.
  • 02:04:53
    And so that's what concerns me on doing it now.
    Because if let's think about it.
    If we do urgency and it does pass today, then it's gonna go in effect in maybe a month or two.
    And the plants that are out there that are already in the middle of their commissioning and everything else are gonna go, well, wait a minute.
    What the heck?
  • 02:05:11
    I've already got investments and everything else.
    It's already done on this.
    Now I'm gonna push back the COD dates for these things.
    So I while I agree we need to address the problem, I think we need to do it in an organized manner that doesn't disrupt the market and what's coming online here in the next six months or so.
    Thank you, Bob.
  • 02:05:33
    Chase?
    Thank you, madam chair.
    I'll just reiterate this is Chase from Southern Power.
    I'll reiterate Bob's comment, and that was kind of my the main thrust I wanted to get across to.
    I understand what ERCOT is attempting to achieve here and, and not necessarily concerned with the proposal in and of itself, but I am concerned with with, timing of of projects that are kind of in flight close to achieving energization and going through commissioning activities.
  • 02:06:11
    You know, the just the the impact that this may have, from a timing standpoint.
    So, I recognize ERCOT wants to, see see the needs to make this change and try and mitigate this risk.
    I'm also just curious if, you know, is is there some sort of time future time that can be agreed upon, to just give a little bit more of, advanced notice for projects in flight.
    Right?
    So, you know, this can become effective at some point, you know, if it's three months or, you know, sometime later in 2025.
  • 02:06:50
    Right?
    That, I I I recognize there's the balance of ERCOT saying it's needed to address projects in flight, but also, you know, I think there's probably some, geos who may have concerns with with projects that are quite far along and the potential impact of this.
    So that's one comment.
    And then the second one, you know, I think related, but not necessarily brought up specifically in this set of in this NPRR is just the timing of delivery of SSR studies.
    You know, I just I have some concern that currently that is and I know it's a very complex phenomenon that needs to be studied and takes time.
  • 02:07:37
    But currently, those studies can be delivered closer to energization and synchronization.
    And, you know, is there is there some I think we just need to have a conversation about the exact process and timing and delivery of that study so that if risk is identified, there is some time period, for the generation owner to evaluate that and work on mitigation, in advance of what would then be energization.
    If, you know, this NPRR is approved at some point and becomes implemented.
    So those are those are my comments.
    I'll stop there and see if, you know, be actually see if ERCOT has any, you know, any, reaction, to to the to those comments, or questions.
  • 02:08:24
    Thanks.
    Thanks, Chase.
    H.
    G, did you wanna address any of those?
    Certainly, understand, you know, both, Bob and Chase's comments about the impact to to projects in the queue.
  • 02:08:44
    I I don't think from the ERCOT perspective, we we feel that we can necessarily push this one out.
    I I do think it is worth exploring, you know, potential ways to screen for this in earlier in the process.
    But at the end of the day, you know, as as we cited in the justification, we've already had one incident of a project that was granted initial energization was in the commissioning process, and, we observed this resonant effect.
    So, you know, I I think our our desire for for urgency and approval on this one stands.
    Okay.
  • 02:09:31
    Thank you.
    Brian Sams?
    Same issue about catching new facilities that are in this, kind of gap period, I guess, is what I'm gonna call it.
    You know, Calpine is building a a new gas peaker, and, we expect to have a COD by March of twenty twenty six.
    And so, you can imagine the Gantt chart, what that looks like for construction.
  • 02:10:01
    So just changing the, some of the requirements, you know, could be just an upset for, what that that time loading looks like.
    And to be totally clear, I'm not even sure if if this would apply to that plant, but, I hear the point that others are making here about, you know, going down a a a particular path for your commissioning and and, potentially being upset.
    Thank you.
    Thank you, Brian.
    Whitmire?
  • 02:10:48
    Yeah.
    We have a Texas Energy Fund out there that has bonus payments by the by the state for completion of projects on time.
    Did we do a prescreen to see if any of those projects are gonna be impacted by this?
    I mean, it would be pretty ugly for the state to offer a bonus and then the state to shut it down through a process like this.
    Thank you.
  • 02:11:15
    Just, just to be clear that my project is one of those.
    I did not know it, Brian, but thank you.
    John?
    I think that, there is a timing problem with this.
    And, I think it actually needs to be talked about at ROS because, the planning studies the the timeline for planning studies and all the different studies are listed in the planning process.
  • 02:11:50
    And, I have not looked at it in a very long time, but I did not think that there was any prescreening or screening for this unless certain milestones in the other parts of the planning process were happened.
    So I think that we need to think about all the processes and not just make a quick change in the protocols to just say, oh, we made it happen.
    So I would suggest that we send it to ROS.
    And so I'm not sure about the urgency if that's really needed.
    Thank you.
  • 02:12:31
    Thanks, John.
    Bob Hilton?
    I'll hold off right now.
    Okay.
    Shane?
  • 02:12:40
    Shane Thomas, Shell Energy.
    Yeah.
    So I'm gonna just try and get some more information about this right now.
    The what they ask is is, I guess, to do this study earlier to identify the risk.
    And if there is a risk identified, they won't, be able to start the energization, knowledge check line assist until it's been resolved.
  • 02:13:05
    Is there kind of the chance what this is kind of looking at?
    Is there a pension now for a generator to start this energization process and be unaware of a SSFR SFFR potential.
    I mean, I see that as kind of a a problematic I mean, I don't want a turbine to get a shaft bent and then be out for however long it takes to replace that.
    I don't know what I imagine it takes longer to replace a turbine shaft than it does to do a SSFR study.
    But putting things back on retroactively, like, kind of through the process is kind of not a great precedent.
  • 02:13:48
    And I do have some worry risk about some people meeting some timelines and deadlines and things like that, but I also see that the risk is to the turbine itself.
    So if they try to start up and there is a frequency resonance event, like, they're basically gonna be screwed about meeting their timelines.
    So I don't know.
    Sun, I see you in the queue.
    Did you wanna address some of the thoughts that Shane was sharing with us?
  • 02:14:20
    Yeah.
    This is Hassan from ERCOT.
    I I, yeah, I I see some concern around the timing, but regarding, you know, whether, you know, we give a heads up, on whether more detail detailed, you know, in-depth subsequent resonant studies need to be done or not, it's it's already in the process.
    So, you know, early in the stage of the gen interconnection process, you know, during the, you know, screening studies, or Carlos will conduct some polish check to make a determinations of whether, you know, SSR studies, which include SSFR, right, is needed or not.
    So if you go through the Rio, right, Rio system, you can find that, you know, that checkbox and and and that which indicates whether, you know, your projects is, relevant to that, study or not earlier in the stage.
  • 02:15:23
    That that's just what I wanna mention.
    Okay.
    Perfect.
    Thank you.
    Katie?
  • 02:15:32
    Hey, Sunwook.
    Since, John over here had my ROS antenna raised, can you respond to his comments as well on the timing?
    Are you, as far as, are you are you asking about the whether yeah.
    Go ahead.
    He was talking about the the timing of the planning studies, and then, you know, the the piece about whether there's, you know, no prescreening or screening unless the other parts of the milestones have been met.
  • 02:16:11
    Can you speak to those two points?
    Is that something that we need to deal with it, ROS, or is that something that you like you've said, was already being, Yeah.
    Taken care of?
    Yeah.
    It's already been taken care of.
  • 02:16:25
    It's already available in the planning guide section five point three point one.
    So, yeah, it the the the we have some language already that indicates that, you know, you you yeah.
    You you you basically know you will know, you know, whether SSR study is needed or not.
    If it's not needed, you you don't have anything to do with, you know, SSFR.
    But if it is needed, then, you know, you you projects you you and TSPs need to work together to to conduct the studies.
  • 02:17:00
    But I think what, you know, Agee is really trying to achieve is, you know, during the interconnection process, trying to, you know, move up stage requirements, you know, one step up from, you know, energy I mean, synchronizations to energizations because your transformer will be energized at the time.
    Right?
    So, you know, it it it kinda give indications that, you know, SSFR is related to transformer excitations and in energy interactions between, you know, six capacitors.
    So before you put our new transformers, you know, we hope to have some, a better design and to minimize any unacceptable, you know, unpredicted, you know, SSR power issues.
    So trying to move up the stage, you know, a little bit here to make sure that, you know, your payment is safe.
  • 02:18:06
    K.
    Katie, did that give you the clarity that you needed for the the ROS discussion?
    No.
    It sounds like John had a further question about, you know, the if the transformer is, you know, known and it's part of the model, why isn't it decided sort of earlier in the process what's needed?
    Okay.
  • 02:18:42
    Freddie?
    Yeah.
    Sure.
    I just wanted to respond to to Shane's question about, if there's a resource already in the commissioning process, what would happen?
    And and Agee was referring to a resource, I mean, it was two years ago now that where it exhibited this SSF bar, phenomenon.
  • 02:19:06
    That resource was in the commissioning process, and it the you know, moving through the commissioning process was actually paused until they could come up with a corrective action plan because it did impact, you know, other generators nearby.
    So I think if we were to see a resource that was going through the commissioning process currently and it did exhibit SSFR in real time, I think that, we would probably do something similar, because it does pose damage to other transmission facilities in in in the area as well.
    But, the, you know, you know, the example Agee was mentioning that that's, actually what happened with that with that.
    So just wanted to clarify that.
    Thank you, Freddie.
  • 02:20:01
    Mhmm.
    Bob?
    Yeah.
    Couple things.
    Now for the, SSFR Yep.
  • 02:20:14
    Is that part of the original SSO study, or are you going to are you revising the SSO, study process to include this?
    That's my first question.
    Can can I make a comment?
    Yeah.
    Yeah.
  • 02:20:38
    Yeah.
    It's I I was asking this question for you, Freddie.
    Orson, whomever.
    Yeah.
    The the question is is, are you have does the original SSO study we've been doing forever include the look for SSFR?
  • 02:20:55
    What do you call it?
    Yes.
    Yeah.
    Yes.
    It's part of the study.
  • 02:20:59
    Yes.
    So we should know that before we're going into that on whether SSFR is an issue, but it may not be an issue just because you're having an SSO study done.
    Right?
    Correct.
    It it may not be an SSFR, but it may be something else.
  • 02:21:21
    Yeah.
    But SSO study includes, you know, the the SSF SSFR study as well.
    And the way I'm reading this, tell me if I'm wrong, if this one says if you have an SSO study, that you will not be able to synchronize you will not be able to energize until everything in the SSO study is done and mitigated, where and that particular unit could have SSO issues, but doesn't have the SSFR issue.
    But they're not they're included in this NPRR too.
    Am I right?
  • 02:22:02
    Well, so SSO study, let let me say this.
    So, you know, during the, studies, it looks at the various different, scenarios.
    Right?
    You know, minimum generation dispatch and, you know, high eye dispatch and all that.
    Right?
  • 02:22:25
    And and and and different system conditions based on the scope.
    But when they study it, it it doesn't separate whether it's a transformer issue, whether it's excitation issue, whether it's a IBR issue.
    It just the study basically look at everything together.
    Right?
    And as a result of the study so once the study, complete, we'll be able to know whether it's SFR issue or it's some something or subsynchronous control interaction issue.
  • 02:22:56
    You know, the study need to be complete to understand whether that's belong to SSFR or something else.
    So that's that's you know, we can ideally separate them into, you know, two different buckets.
    It's just one study.
    You need to find out what that issue would be.
    Right.
  • 02:23:14
    Yeah.
    I've I've read those.
    They're no fun to read.
    Okay.
    I'm not sure that helps one way or the other.
  • 02:23:25
    I'll turn off for now.
    Okay.
    Chase Smith.
    Thank you, chair.
    Chase Smith, Southern Power.
  • 02:23:37
    Sunwook, you can you clarify?
    Because my understanding is in that security screening study earlier in the process, ERCOT will do kind of a high level review and, kind of flag if if it thinks SSR is a risk that requires this more in-depth study to be completed.
    But I'm not aware is is there, like, a a due date in the process when that in-depth SSR study is due?
    And kinda what I'm getting at here is, you know, if or or one of my concerns is, you know, if a resource cannot energize until this SSR study is complete and, you know, if risk has been identified, the SSR study has been complete and then mitigation appropriate mitigation implemented.
    You know, I'm concerned about, well, if does the resource have that in-depth SSR study as it's approaching enterization and and, you know, and and going through the integration and commissioning process.
  • 02:24:44
    My understanding is that, you know, that at times, you know, may, you know, the TSP may be working on that study, even kinda getting close-up to energization and synchronization.
    So can you help me understand that?
    Is is there is there a kind of a due date for for an expectation on when that in-depth SSR study is complete?
    Thanks.
    Yes.
  • 02:25:09
    So, I I believe that it's credit it's clearly stated in the section c 22 as well as planning guide section five.
    The the the, you know, the original due date is, you know, prior to synchronization date.
    Right?
    Study need to be done, and if studies say mitigation need to be, you know, implemented, and that that has to be done before synchronization.
    But there's no nothing changes, and this NPRR basically trying to move the stage up to, you know, to to to the, energization, instead of synchronization.
  • 02:25:53
    That that's that's all it, trying to achieve here.
    But as far as that line, it's it's stated in the planning guide and protocol.
    Okay.
    And I'm not I'm not aware exactly where that is off the top of my head, but is or or is there a corresponding change being proposed that that the SSR study be completed earlier too?
    Right?
  • 02:26:15
    Like, if it can't be due by synchronization, but then if potentially, you know, prevent prevent an energization if if that resource doesn't have the SSR study complete.
    Right?
    Am I am I following that?
    Correct.
    If there is an issue, right, you need to mitigate it.
  • 02:26:34
    And if without the mitigation, how can we, synchronize your unit?
    Right?
    Because it's gonna damage your equipments and damage transmissions and things.
    And same thing goes to this, NPRR.
    So now if you're talking energization, the mitigation has to happen, before the, you know, the energization here.
  • 02:26:59
    So the study need to be done, and everything need to be done.
    That makes sense to me as far as what ERCOT's trying to achieve.
    What I guess what I'm confused by is what I'm hearing is that the due date for the SSR study is by think.
    And then, you know, this this NPRR would shift up, you know, earlier in the schedule, you know, and potentially cause an impact for resources that do have this identified SSFR.
    Risk, and if they don't have the SSR study yet, they can't do anything.
  • 02:27:30
    They can't do anything.
    So I think I think we just need to make sure that.
    You know, if if this proposal goes forward that the SSR study is also appropriately shifted up in time.
    So, that, you know, affected resources can review the study results and then work on mitigation, you know, if that's applicable and have been identified.
    Thank you.
  • 02:27:59
    Chase, this is Agee Springer.
    If I could just make one comment on that.
    You know, the the language that Sanuk was just referencing is also the governs the the requirement of when that SSR study currently has to be done.
    So that is effectively an existing risk to projects, under the current protocols.
    The this NPRR modifies those those sections in three dot 22 that Sunuk was referencing.
  • 02:28:27
    And so the it's simply shifting the requirement that those studies and mitigation be done from initial synchronization to initial immunization.
    So, yeah, I guess, my my response back to your question would would also be, you know, that there's an existing risk to projects right now that they may get to the commissioning portion of the process.
    And if the SSR study has not been done, they are effectively stuck without being able to synchronize, until the mitigation is in place.
    So this is moving up that milestone a little bit, but but it doesn't change the overall structure of what exists today.
    Okay.
  • 02:29:14
    Thank you.
    Thank you, AJ.
    That's helpful.
    I I I'll read over the language a little bit more.
    I I think maybe I was confused.
  • 02:29:19
    I didn't it was not clear to me as far as the SSR study would also be delivered at an earlier time.
    But sounds like you're what you're saying is that that that kind of included in here that that's just the the study will also be, completed at an earlier time with this change that's being proposed.
    I might describe it a little bit differently.
    There to my knowledge, there's not currently a requirement in the protocols that requires the study to be delivered by a certain time.
    Rather, the requirement states that currently states that the study and any, subsequent mitigation must be done prior to initial synchronization.
  • 02:30:08
    And so this this modifies that requirement to energization, but I don't it does not add any explicit language, on when the study must be completed, and there is no explicit language to my knowledge today.
    Okay.
    Thank you.
    That's helpful.
    Helpful very helpful for me to understand.
  • 02:30:33
    I think that kind of going back to Rich some some previous comments just, you know, understand that this ultimately goes forward at some point and it's known and can be planned for in the future.
    But for projects that are far along, currently, you know, the plan should be that the SSR study is done by think, and it may not, you know, there could be a a a time a time gap that's created.
    So just just something for consideration, as we're as we're, you know, trying to know what action to take.
    Thank you.
    Thanks, Chase.
  • 02:31:09
    Blake?
    Blake Cole, LCRA.
    Diana, I missed the first part of the conversation.
    Apologies.
    Do we have a direction on where this one is going, or are we still seeking a vote on that?
  • 02:31:26
    I I'm seeing a head nod from Andy.
    Given some comments made by Brian and Bob, I I think I need to have some more conversations internally under a different lens.
    So I I would appreciate some more time to review this.
    Okay.
    Thanks.
  • 02:31:39
    The conversation that we initially started having was for us to look at this.
    And so if that seems like that's something that would be amenable to everybody to table this and refer it over to ROS, that could be a conversation that we have over there.
    John?
    Yes.
    I would, again, should I make that motion to, table it and send it to ROS so that we can because I believe the timing the planning process and everything needs to be synchronized and not just this little piece put in here.
  • 02:32:20
    So, I would like to make the motion to table and send it to ROS.
    Okay.
    Before we make a motion, and Corey can, correct me if I'm wrong, is everybody okay with this, or does anybody have a need for an individual vote to table twelve eighty three and refer it over to ROS?
    Okay.
    Looks like we don't need an individual ballot, so this might be a good Agee, go ahead.
  • 02:32:47
    You know, certainly understand the discussion that's been had here today, but I I do just want to maybe, you know, prior to this being the decision, emphasize the comment that Freddie made, earlier in this discussion that, you know, in the instance where we have encountered this issue during the commissioning process, that that resources commissioning was halted until the issue could be addressed.
    So this is an existing reliability risk to the system, and it does have the potential to impact projects that are going through the interconnection process now.
    This is simply going you know, this NPRR standardizes where that risk is addressed, but not passing this NPRR and tabling it for additional discussion does not remove that risk to the the interconnection of projects in in the queue right now.
    Thank you, Agee.
    Corey, since this one has urgent status on it, do we need to do something with that request or by tabling it and referring it to ROS captures what we need to do for this one?
  • 02:34:03
    Yeah.
    If if the will of the group is to table and refer it to ROS, you don't need to vote on the urgency.
    Okay.
    At some time in the future when it's taken up, you can always grant it at that point depending on where the meeting timelines line up to see if that would do anything.
    But if if everyone's cool with it, I'll put table and refer to ROS on the combo ballot.
  • 02:34:20
    Okay.
    And and I can't make your comment.
    I just wanted to respond to Agee since this is going to ROS.
    So what you just said about the one resource instance, I think what you're hearing from folks is that the timeline that you're setting out could produce the same result even if you're moving it back a step.
    So I think that's why you're seeing folks want to look at this timeline holistically and figure out, did you plug it in in the right place, or do we need to move it back a couple of steps?
  • 02:34:49
    So just wanted to clarify why you're seeing folks wanna send it over to ROS and review it.
    Thanks, Katie.
    Understood.
    Bob, are you in the queue still?
    Yep.
  • 02:35:01
    Okay.
    Brian, are you good?
    Okay.
    Okay.
    So we'll put 1283 on the combo ballot.
  • Item 6 - Review PRS Reports, Impact Analyses, and Prioritization - Vote - * denotes no impact
    02:35:10
    Alright.
    So then we have the impact analysis under section six.
  • Item 6.01 - NPRR1214, Reliability Deployment Price Adder Fix to Provide Locational Price Signals, Reduce Uplift and Risk
    02:35:18
    So the first one up we have is 1214.
    This is coming to us from the joint sponsors.
    I believe wanted to speak to a request for us to table twelve fourteen.
  • 02:35:37
    We do have an IA for the proposed language that we approved last month.
    Dave, go ahead.
    Hi there.
    Thank you very much.
    And and, also, I want you all to to walk through the IA as well and and see what questions you have.
  • 02:35:52
    Separate from the IA, but this was also part of the AI process, we have been finding some additional clarifications and discussions that's needed related to this NPRR.
    We had already been looking at some comments to try to address some, issues with how the emergency pricing program would work and how the language works around the emergency price pricing program with the twelve fourteen language.
    And, anyways, that has unearthed some some additional discussions that we've been having, and we've been, diligent diligently working on some on some comments.
    The the topics have been fairly technical and have been requiring a lot of internal discussion on it, so we've not been able to complete those yet.
    We are hoping to and intending to have those for sure by the next PRS meeting when you all meet in June.
  • 02:36:49
    Just to kind of give you a flavor of of some of what we are, struggling through a bit, really, if you think about how twelve fourteen is working, we, under the current language, are still referring to them as price adders, but they can actually move in both directions.
    And so, really, the way to think about it is the binding prices are the prices coming out of the RDPA process, not necessarily, just an an adder to what is already in the dispatch.
    And as we've kind of been thinking through that, that's actually part of what's creating some some concerns with the language that we're having, again, around things like the emergency pricing program.
    Also, in digging through it, thinking about now, there's a section that talks about, energy indifference payments, In talking internally as well as to the vendor, as we thought about the IA process, there are some scenarios that don't seem to be covered by the way that that language has been written.
    And so we're trying to think through that new section and how those indifferent payments work and and if there's things we need to add or or or consider a little differently than what the current language is is showing.
  • 02:38:08
    One other thing to keep in mind is and and this is I just mentioned as you think about the energy prices that they're not really an adder anymore as they can move in both directions.
    As it's currently written, we're seeing some similar, language questions as it comes to Ansley services.
    Those are still written as an adder, where we think what makes more sense and what's really trying to be accomplished out of this is to, essentially have the binding prices for ancillary services be those that are coming out of, the pricing run.
    So, anyways, that's a sort of a flavor of the things that we're trying to work through and to make sure the language all works.
    You know, one thing I did want to note is, and this is already recognized in the way the language has been developed, is that this is going to be a post RTC+B implementation project.
  • 02:39:02
    So, hopefully, it's helpful to know that delaying and potentially tabling the NPRR today, if folks are are willing to do that, has no real effect on when this will be implemented.
    This is more about, making sure that we get it all clear and that the IAE properly reflects what, what we're trying to accomplish.
    In terms of, how our changes we're considering may impact in the IA, to some degree, I I think, hopefully, in the way we're looking at it, it's going to make things much clearer for implementation.
    So I see that as an overall, plus in thinking about what the IA, would look like.
    To some degree, on the flip side, as we're talking about the indifference payments and making sure we have all the scenarios covered, that may mean that has to be a little bit more complex.
  • 02:39:53
    But, my my intuition, if I had to tell you today, is that this really isn't affecting the the range we have in the IA.
    It's really more about just ensuring that we get the language correct and and are understanding all the scenarios.
    So I'll stop there.
    I see there's a couple of folks in the queue.
    Okay.
  • 02:40:11
    Great.
    Thanks, Dave.
    Eric?
    So, Dave, one of the key reasons that residential and consumers across the board generally supported this was, its ability to both increase and decrease prices contextually.
    And and so we hope that your revisions keep that, in place.
  • 02:40:36
    I think the way you described it that it would accept for potentially doing the emergency pricing program.
    And do you do you need to have, like, an additional exception to this so that the emergency pricing program would override in in that when it's in effect?
    Go ahead, Steve.
    Sorry.
    But the comment didn't make you, but really was just a response to to Eric's question.
  • 02:41:03
    So, absolutely, the way we are looking at the comments, there retain exactly what you're describing.
    I think what we're trying to make clear here is it it in that sense, it's really not an adder anymore in the sense that it can be negative for some locational prices.
    And so Right.
    As we're thinking through these processes and how to best describe them, it seems much clearer to us to say that the binding prices are simply the prices coming out of the pricing run when that's triggered and not necessarily some adder that can be a negative adder, which just seems very unintuitive and and was raising a lot of questions for our technical staff as we were talking about details.
    Specific to the emergency pricing program, that doesn't necessarily affect it either.
  • 02:41:50
    We could still see prices move in both directions.
    The only reason I bring it up is, as we were getting into and reviewing that language and thinking about the IA, we essentially need now a separate, price quote unquote price adder, which again also could potentially move either direction under 1214 for system Lambda, because that's not an inherent value that we otherwise describe within, many of the protocols.
    So it was more of a technicality that was was driving us to look at some of the EPP language, but overall, we're we're absolutely retaining exactly what you're describing and and hopefully, actually making a lot more clear to people in terms of what the binding prices are.
    Okay.
    Okay.
  • 02:42:39
    Bob?
    Yeah.
    With that, I'm assuming we're gonna need a motion to table, and I would suggest a combo ballot.
    Is everybody good to table twelve fourteen and give ERCOT an, some more time as they're looking at those issues and file some comments on that cleanup language?
    Okay.
  • 02:43:06
    Shams?
    Or What was your name?
    Sai.
    Oh, Shams.
    Yeah.
  • 02:43:12
    Please go ahead.
    Can you hear me?
    Yes.
    We can.
    Go ahead.
  • 02:43:17
    Okay.
    No.
    I'd like, to thank for, really looking at this closely and making sure we get everything right.
    I know that, this we implemented post RTC, but it's it's actually quite an important NPRR in terms of the indifference payments and the reliability impact of not having indifference payments, as well as, you know, sending wrong price signals.
    Now that we have so much crypto and other flexible load, it's very important to get this in as soon as possible.
  • 02:43:45
    So I'm hoping that, taking more time doesn't further delay it because I think the first instance we have of scarcity pricing and stuff, the market's gonna be pretty, surprised by the outcome.
    So, hopefully, we can get this done in the same sort of time frame even though we're, you know, we're sort of tabling it for a month.
    Thanks.
    Thank you.
    And, Sai, we see your comments in the chat as well.
  • 02:44:15
    Okay.
    Any further discussion on 1214?
    Okay.
  • Item 6.02 - NPRR1226, Estimated Demand Response Data
    02:44:25
    So, Corey, I think that takes us to 1226, comes to us from the steel mills.
    We tabled this back in March.
  • 02:44:36
    And I have a note that desktop edits are gonna be needed for one of the.
    Yeah.
    Well, what once we go for the IA, I'll add in the desktop edits I wanna talk about.
    Okay.
    Okay.
  • 02:45:03
    How does everyone feel, Mark?
    Yeah.
    This was filed over a year ago, and it's gone through, WMS.
    I think it's gone through ROS.
    It started in the large flexible loads task force.
  • 02:45:24
    It's been approved with, or recommended for approval without any opposing votes everywhere it's gone.
    The last this was approved by PRS in February.
    But I, I think, they, ERCOT wanted more time to do an IA, which they finally did.
    So that's what's here today, and I'd like to get the IA approved and see what we need to do to get this moving forward.
    Alright.
  • 02:45:58
    Troy?
    Yes.
    The IEA is concluded as you see here.
    I didn't have a recommended priority and rank.
    I thought we might want to discuss.
  • 02:46:09
    Obviously, it's got an EMS impact, so it would be, no sooner than 2026.
    And I could suggest if that's when we wanna target it, it could be 2026 with a rank of forty seven seventy.
    Of course, that it will be in the pile of revision requests to be discussed in the next coming months as we plan out, future years.
    And I could also pass a message from, Matt Marinis and Mark Patterson that ERCOT well, this is more of a posting.
    ERCOT does see value in a future demand response dashboard, and we're considering that as a future internal ERCOT project that could be deployed.
  • 02:46:54
    Thank you, Troy.
    Yeah.
    We've had a lot of discussions and conversations in the various working groups on 1226.
    Okay.
    How does everyone feel to put 1226?
  • 02:47:06
    It's IA on the on the combo.
    Okay.
    Getting a lot of head nods to Corey if we can add that one as well.
    One minor desktop edit.
    In the development of the IA process, as we were carrying down the posting requirement into the RTC gray box, in this particular row of the table that has a sea of unnumbered paragraphs.
  • 02:47:29
    I dropped the red lines originally down here into this paragraph, which structurally has a lot of the same words as the paragraph right above it.
    But a different team at ERCOT owns this paragraph.
    So as Troy was doing the IA, there were a lot of folks freaking out over, wait, I have to build this report now?
    So just by sliding these words from below here up into this paragraph, which matches the black line version above, will maintain harmony, within the ERCOT folks and get you the exact same thing, exact same way.
    But, some minor desktop edit if y'all be willing to be accept the IA with this PRS report as revised, which is literally just copy and pasting up into the correct paragraph.
  • 02:48:09
    So that would be your lengthier motion on the combo ballot would be to move it forward with the priority and rank from Troy of twenty twenty six forty seven seventy.
    Still seeing add ons.
    Are we good with that?
    Okay.
    With the desktop edit included with twelve twenty six.
  • 02:48:25
    Thank you.
    Thank you.
    Bob Whitmire?
    Are we done with 1226?
    Oh, okay.
  • 02:48:33
    Sorry.
    Okay.
    Alright.
  • Item 6.03 - NPRR1238, Registration of Loads with Curtailable Load Capabilities
    02:48:37
    Next one is 1238.
    Go ahead, Bob.
  • 02:48:45
    Okay.
    Twelve thirty eight.
    So this was intended to be low hanging fruit from large flexible load task force.
    It seemed ridiculous to us that we had flexible loads that wanted to come offline to be obligated to stay online for purposes of compliance.
    However, at a million dollar price tag, it's clearly not low hanging fruit.
  • 02:49:14
    SB6, while it doesn't directly address the problem here, it will trigger, ERCOT to come up with a similar kind of program, and, hopefully, we can tweak that.
    And then, selfishly, if we wait for ERCOT to come up with their senate bill six thing, that will come out of ERCOT's regulatory budget rather than the stakeholder budget.
    I'll, however, everything that I have said on this NPRR about the problems associated with it is still all valid.
    The issue we have now, million dollars and end to fourteen months, We were hoping that we could simply edit the load shed table that's kept in Excel and knock that down, but, clearly, that is not the case.
    Approving this today will not help us for winter of twenty five or summer of twenty six.
  • 02:50:14
    So I'm not sure that this should be approved today.
    Thank you.
    Thank you.
    Joe Dan?
    Joe Dan Wilson from Golden Spread Electric Cooperative.
  • 02:50:27
    You know, if we don't implement something like this in NPRR, entities like Golden Spread and our distribution co op members will still face compliance issues, or potential compliance issues when it comes to load shed obligations.
    While ten to fourteen months is definitely disappointing, for implementation time, we still don't see anything else on the horizon that does the same thing as this.
    Even when we look at, senate bill six, we do see some language that, you know, wants to competitive competitively procure the demand.
    But this implies that not all demand in our territory would be competitively, procured.
    This leaves, the same compliance, concern and same same, risk for golden spread in our members.
  • 02:51:15
    So again, another thing is it also doesn't include, any, the senate bill six also prohibits participation by any large load that curtails in response to wholesale pricing.
    Well, this would take out crypto loads as well.
    So if we're now can't fit a crypto load onto our territory as well either.
    And so s b six, while there's some things that we're we're definitely supportive of that help codify some things, it definitely doesn't cover everything.
    So continuing to wait for that and continuing to wait for s b six to make it through the PUC and then down to ERCOT so that we can finish off in NPRR, that would virtually get us back to the same spot we are today.
  • 02:51:54
    So while I can agree with Bob that, you know, the urgency has probably been taken off of this now, as far as trying to get it in before the next winter for reliability purposes, You know, Golden Spirit still sees compliance.
    If if reliability is not the focus of of where we're headed up, you know, as far as urgency, well, then we still have a compliance issue that we have to take into consideration.
    While the cost are 700,000 to $1,000,000, Golden Spirit doesn't see that there's economic decision to be made when it comes to compliance.
    We want to comply.
    We want to provide solutions.
  • 02:52:24
    This is Golden spread's second solution to bring to the table in the last two to three years.
    And so this is, again, is gonna potentially not get implemented and leave us out for another year that could cause these issues.
    We've had we've heard some folks say that maybe, Golden Spread doesn't need to take on these loads, and there's a little bit of frustration when we hear those type of comments because the rest of Texas is allowed to engage in the economic, boom that's taken place.
    But because of, policies that can't pass like this, we're unable to, potentially, compete with those same, loads that are out there.
    And so it kind of tends to shut us off.
  • 02:53:07
    We would really like for for this, PRS to consider at least passing this to the TAC, allowing the TAC to have this discussion a little bit further.
    We understand that it may need to be tabled up there while we talk about the sticker shock that was kind of passed down with this impact analysis.
    But even with the sticker shock and even with the long and disappointing timeline, we still believe this is something that should be passed at and looked at pretty seriously.
    Thank you.
    Katie?
  • 02:53:35
    Thanks, Diana.
    I I know how long Golden Spread has worked on this.
    I may have worked on this in a former life, although it was a a much more abbreviated change.
    So, I do understand where you're coming for.
    I am coming from.
  • 02:53:50
    I am sympathetic.
    As ROS chair, it puts us in kind of, a conundrum because we have the NOGRR before us that now has a no cost IA because everything is tied to this NPRR.
    So, even if I were to move that forward, I'm not sure it helps golden spread.
    So that that kind of puts me in a difficult position because I would like to see you get the support that you need.
    Clayton?
  • 02:54:22
    Yeah.
    I was gonna ask about it.
    Is there a manual workaround?
    You know, I hear Bob talking about the this is just a spreadsheet table that can be updated.
    What was all of this for?
  • 02:54:35
    I mean, I see I see, you know, beyond what is in the in the paper here, you know, 69% market management.
    What are you actually doing in the market management system, energy management system?
    Are you, like, putting notation in this so that they know that the tables are you know, the expectation is that the the cooperatives is not gonna be providing this load plus the load of the the data centers, just the load that's native to the cooperative before the data center showed up?
    Troy, go ahead.
    Thank you.
  • 02:55:09
    I might, in fact, I'm certain to need some backup from ERCOT folks if they can help.
    But, we did take into the IA process the the wish that this be simplified to what degree it could be, and, the team took that request seriously.
    But coming out of the process, we just see that, you know, there's, you know, there's changes to the registration systems that feed into the network model, feed into EMS, operator displays, telemetry, reporting, including four CP, vendor impacts as well, plus XML communications.
    So all kinds of things came into play here that resulted in, you know, a five thousand hour project, basically.
    So consumer cut folks help provide context to this for me to to help PRS understand what is, really driving all this labor?
  • 02:56:11
    Fred, go ahead.
    It look like Fred.
    Hi.
    It's Fred from.
    I think they just tried to address the question.
  • 02:56:20
    I think, originally, the concept was to have a two separate load share table.
    One is the t o load share table as it is today, but it's crude like that load to be the QSE concept like, QSE load share table.
    We did a kind of, analysis that essentially just make it a challenge as an uncertainty to the QSE label, which we still have issues.
    The approach here is to have lost data provided through real time similar to the and deploy us the EIs.
    So in the control room, the operator will have a full visibility and awareness as how much available in real time, and they know where to deploy it and how much to deploy in real time.
  • 02:57:15
    That is a much better and reliable way to do it.
    Have a offline table still will be calculated offline.
    The uncertainty, as kind of point out, the real time consumption is still not be will not be captured in real time.
    So we try to minimize that uncertainty and then try to have a appointment and deployment approach as we kind of provide in our comments and which is the version provided, in this approval version.
    So I guess maybe what I'm hearing is is when you ask for a block, you need to know how much of that block you're gonna get from from a data center versus the actual load?
  • 02:57:54
    I think with the, concept in this approved version, we will know.
    With the offline table, which is calculated based on a snapshot, it's going to be very difficult to, recognize the their real time, situation, especially when we need to deploy them close to the tighter condition.
    Well, I think most of these guys are gonna have telemetry on their sites, but, so I think you'll know at least what happened.
    But, you know, I I get that it doesn't give you the same level of control you'd prefer.
    What I'm asking for is there something that's that's okay.
  • 02:58:34
    Because when you're in one of these events, you're just looking for load to come off.
    I know it needs to be in a in a controlled manner.
    You need to know kind of what level you're looking for, but close enough, I would think, would be close enough whenever you're dealing with one of these events.
    It doesn't have to be exact.
    And maybe I I don't wanna get too too down into the weeds.
  • 02:58:55
    I'm just trying to find find out if there's a better way to do this.
    Because the answer that, you know, you shouldn't put any of these loads in a co op or muni territory, that's not acceptable.
    That that's that's that's a nonsensical answer.
    And so, we just have to find figure out how to make this work.
    Yeah.
  • 02:59:14
    And then maybe, Troy can help.
    I think when we go through the IA, we actually try to identify what portion we can, I would say, implement as a interim solution and implement sooner than later?
    But come to the situation awareness, the information, is really critical for the real time operations.
    We think they are they need to be, and we do identify some other options we can implement sooner.
    That's why we have a range layer.
  • 02:59:44
    But based on all the, say, scheduling the projects, we believe the estimated time frame, is the one is kind of practical we can implement it.
    Yeah.
    To add to what Fred said, we we as recent as last week, we had a two phase IA in the works.
    And then as we drew to the conclusion, they ended up being so similar that, we ended up just with a single, delivery.
    So, we we did go down that path and and try to figure out what pieces could go first to accomplish the desired result, and we still ended up with a a pricey extended effort.
  • 03:00:32
    Okay.
    Thank you, Troy.
    Thank you, Troy.
    I think that this still needs to move forward, even with this price tag.
    This is this is a huge amount of tax revenue for the state.
  • 03:00:42
    It's a huge amount of business for the state.
    So, I mean, even at a million dollars, that pales in comparison to what's what's coming here economically.
    Thank you.
    Thanks, Clayton.
    Bob Whitmire?
  • 03:00:56
    Yeah.
    I'll just point out that if this was price sensitive load, at the time we're looking for load shed, the QSE load shed table that we just talked about should read zero because they're signing up for this as price sensitive folks.
    The only reason this is a problem is if they missed the coincident peak last season, they're in the load shed table of the TDSP.
    They will be offline or they will be at minimum consumption at the time this is called for, assuming we have prices in the market that reflect the shortage.
    If we don't, we have bigger issues.
  • 03:01:44
    But remember, the intent here was no additional load is expected to be shed as a result of 1238 going forward.
    That load should already be offline.
    The intent behind 1238 was an absolute guarantee that that load was offline.
    Thank you.
    John?
  • 03:02:12
    Yes.
    I want to go ahead with this, like the blast in the past on the on the speakers there.
    And but I wish that we could figure out how to, implement it where it's not implemented like ERCOT's thinking, but more like Bob's thinking on the way the implementation happens.
    And I'm not sure how to get those two to work together, but I think whatever it is, we need to have it soon.
    K.
  • 03:02:52
    Clayton, we see your, comment in the chat.
    Did you wanna address that?
    Well, some of the like, the Bitcoin mining loads will obviously be very price sensitive.
    Some of the data center load is not price sensitive, but they should be moving over they're politically sensitive, so they should be moving over to backup gen just from a standpoint of if you're in a firm load shed situation in ERCOT, a lot of those guys should be gone.
    To get back to John's question on I I think what what I'm hearing is is the main difference is ERCOT wants to have the exact situational awareness of what is happening in real time during one of these events, which is very important, but you do have the telemetry there.
  • 03:03:36
    So you it's I think you can you'll you'll know maybe it's a little bit after the fact, and and maybe that's not satisfying to ERCOT.
    But even if you just use the table and and monitor the telemetry, I I think it gets you where you need to be at least on the short run.
    And it's better than what we have now is I I think the main point is would it wouldn't it be better to have some of these guys operating sooner rather than later?
    Thanks.
    I just played it.
  • 03:04:08
    Maybe I didn't say it clearly earlier.
    So today, the con as I go back to the concept, the concern is the PO load sheet of table will be the concern, especially when if ladder load is on or off, can change the ratio significantly, for a certain PO to meet other expectation.
    If we move, like, the portion out, tier is okay, but the other portion will go to the QSE.
    So the QSE label load share table will face exactly the same issue.
    So the QSC now, we have the challenge to make sure limit the load share table application.
  • 03:04:55
    So our suggestion and the feedback is instead of go to the offline table, which you have uncertainty compared to the moment you calculate the load sheet of table versus what actually happened in real time is we have a real time chemistry come to ERCOT, and we will have a good awareness to know how much left and the two parts point.
    If they are zero, then we already know they are zero.
    But at least we know how much left and where are they, and the operator can make the best decision to make the deployment under the need of base.
    That's kinda our another approach is similar to almost like a real time, load sheet table calculation, and then the impact will be very similar.
    Thank you.
  • 03:05:41
    Thank you, Fred.
    John Russ?
    John Russ Hubbard with TIEC.
    We're sensitive to the compliance issues that Golden Spread has mentioned, but still given the the the price and the timing of senate bill six, I think it's smart to to wait on this until, there's some more clear direction post senate bill six and our cut's analysis of of what needs to happen.
    Thanks.
  • 03:06:10
    Thank you.
    Shane?
    Yeah.
    I think it's I think it's important that we move this forward, Shane Thomashile.
    But I think it's important that we kinda continue moving forward.
  • 03:06:21
    I think if we could get, ERCOT to maybe just go rack the the chalkboard one more time and see if there's anything else we can get, that'd be great.
    We had the a similar issue with the, ESR charging load, report when we were looking at that, and ERCOT was able to to find something.
    I mean, there's a lot of smart people over there.
    But, yeah, I'm worried about without this, you know, there are still issues that are gonna be coming up.
    So we're either, you know, Anne ERCOT could potentially not be getting all the load that they're requesting.
  • 03:06:56
    So they're either gonna have to request more load or this load's already shed and it's not available to be shed, so we're gonna see more residential loads being shed.
    You know, that's an issue, but it's also an issue with just ERCOT.
    The this coop.
    I mean, we can't physically can't shed that much load, and so ERCOT's not going to get what it's expecting.
    And it's gonna be short, and we're not gonna get, you know, potentially that frequency or rest.
  • 03:07:23
    I have to do additional load shedding and things like that.
    So there's definitely issues on both sides of it.
    So I think it's important that we gotta keep moving forward and see what else we can come up with doing that.
    Okay.
    Thank you, Shane.
  • 03:07:38
    Julianne?
    Okay.
    Let me let John go first.
    Go ahead, John.
    I was wanting to try to figure out if if the pros if we could go ahead and pass this today, but put in the motion that before tag, that it that ERCOT, takes a better look at it, about the processes needed to be so to keep, people compliant, until the stuff that happens with senate bill six?
  • 03:08:15
    How to how can we do that on a on the side, essentially, to, so that they can be feel so that they can feel that they're compliant with everything that's needed and, whenever they do their load shed.
    Okay.
    Corey can correct me if I'm wrong, but I believe if we wanted to add language into what is in December and that was amenable to the group, I think that would be a desktop edit.
    Right, Corey?
    Because I'm not sure if we could give a directive to ERCOT outside of the language that's being proposed.
  • 03:08:50
    Yep.
    You got it.
    Okay.
    And the language, Fred touched on it a little bit.
    We've got Burkhart comments to be worked into any kind of motion.
  • 03:08:58
    But in terms of they request to sharpen the pencils on the IA, Troy does that after every meeting with with you know, he's always looking to save y'all money.
    But that doesn't need to be in the motion?
    No.
    Because that implies that that's somehow it's already spelled out in protocol section 21 that after a PRS report is issued and it goes to TAC that ERCOT ERCOT the language in section 21 that says an IA is issued, it mentions that ERCOT shall review for possible revising of IAs at every step along the way.
    So adding any kind of wording to the motion would imply that all your other motions that don't mention it means, hey, ERCOT, don't look at the IA.
  • 03:09:38
    And so it's it's a directive that we're already taking.
    You know, Troy's never done.
    He doesn't put any of these numbers in pen.
    They're always pencil.
    So so, yes, if there's any revisions to the IA, you'll get them as soon as he's ready with them.
  • 03:09:51
    Do the com do the, the ERCOT comments, do are they what's causing the price increase, or is was the price increase figured in before the ERCOT comments that are that you're you were alluding to?
    The IA relates to the approved language Okay.
    Not the comments.
    Do will the comments reduce the price or increase?
    Was that the XML piece, Fred?
  • 03:10:26
    Yeah.
    Maybe just I don't know if we can just go through the comments we file and just kind of partially also we address your questions.
    So when we go through the IA, there are some area, especially the the one shown on the screen, the paragraph two c, under section six five nine four one.
    We identify, the current version of the language will need to have a HTML message to the TSPs.
    And, we recognize that could have a potential impact not only to our card system, but also to all the TOs.
  • 03:11:11
    So we actually try to identify what could be a more efficient way to provide the TSP's need.
    And, we can work with, Oncor in in his case and, try to make sure we provide enough information they needed, but, also, hopefully, it's a cost effective option.
    So that's really the change of the protocol here is suggest to remove the SML message requirement to the TSP because we already have a requirement on a real time chemistry data.
    So, like, we provide a sufficient information, and the TSP will have access directly to loads.
    You don't need to update your system and, your FTE to do other, support.
  • 03:11:51
    The other two related minor language is when we go through the language and, there are some area ready.
    The terminology need to be updated just to ensure you make the process so that another one has no impact.
    So this kind of the, kind of overall our comments.
    So that's really the change of the protocol here is suggest to remove the SML message requirement to the TSP because we already have a requirement on a real time chemistry data.
    So, like, we provide a sufficient information, and the TSP will have access directly to loads.
  • 03:12:12
    You don't need to update your system and, your FTE to do other, support.
    The other two related minor language is when we go through the language and, there are some area ready.
    The terminology need to be updated just to ensure you make the process so that another one has no impact.
    So this kind of the, kind of overall our comments.
    Thank you.
  • 03:12:24
    Okay.
    So where does that take us for this item.
    Yes, Jodhan.
    Please go ahead.
    Jodhan Wilson from Golden Spread.
  • 03:12:39
    Yeah.
    I'd like to try to make a motion to see if we could move this to TAC.
    So my thought there is I'm obviously hearing of the importance here.
    So, 2026 is after RTC.
    And in terms of a rank, I've been looking at it this doesn't feel like something we wanna add to the end of the the list.
  • 03:13:12
    It feels like something we wanna, you know, place ahead of some previously approved things.
    Admittedly, we'll be talking about priorities of everything over the next few months, but I'd suggest forty five thirty five will bump it ahead of the last eight to 10 items that have come through the queue.
    Okay.
    Shing, did you have a question?
    Yeah.
  • 03:13:34
    Is there any issue with getting this on the combo?
    I was about to ask that.
    I wanted to see, do we need an individual ballot, or does the group agree?
    Go ahead, Eric.
    I don't think we need, an individual ballot in part because we can discuss all these issues again at TAC, as it relates to the IA.
  • 03:13:56
    That's exactly right.
    That's a good reminder, Eric.
    Okay.
    Everybody good to have add twelve thirty eight?
    Okay.
  • 03:14:06
    Corey, let's go ahead and add it to the combo ballot.
    Don't think we need to Hey, Diana.
    I'm sorry.
    I'd like to stay in the vote.
    Okay.
  • 03:14:16
    So let's go with the original Okay, Corey.
    We're ready whenever you are.
    Okay.
    Susie, you've got motion seconder?
    We're good?
  • 03:14:36
    Okay.
    Cool.
    Then on the motion to endorse and forge attack, the April PRS report as amended by the five seven ERCOT comments and the 5/13 IA for 1238 with the recommended priority of 2026 and rank of forty five thirty five, we will start up with consumers with Eric.
    Yes.
    Thank you.
  • 03:14:55
    Mark Dreyfus.
    Thank you.
    Melissa.
    But staying.
    Thanks.
  • 03:14:59
    Thank you.
    Mark Smith.
    Yes.
    Thank you.
    Onto the co ops.
  • 03:15:03
    Eric Blakey.
    Yes.
    Thank you.
    Jodan.
    Yes, please.
  • 03:15:06
    Thank you, Corey.
    Sir.
    Blake.
    Yes.
    Thank you.
  • 03:15:09
    Lucas.
    Yes.
    Thank you.
    Onto our independent generators, Andy?
    Yes.
  • 03:15:14
    Thank you.
    Caitlin?
    Yes.
    Thank you.
    Katie?
  • 03:15:18
    Yes.
    Thank you.
    Bob Hilton?
    Yes, sir.
    Thank you, sir.
  • 03:15:22
    Brian?
    Yes.
    Thank you.
    Thank you.
    Chase?
  • 03:15:27
    Yes.
    Thank you.
    Chen?
    Epstein.
    Okay.
  • 03:15:33
    Thank you.
    Kevin?
    Yes.
    Thank you.
    Thank you.
  • 03:15:37
    On to our IPMs, John?
    Yes.
    Thank you, Seth.
    Seth bail on us?
    How about Shane?
  • 03:15:53
    Yes, sir.
    Thanks thanks, sir.
    Onto the I reps, Bill.
    Yes.
    Thank you.
  • 03:15:59
    Austin.
    Yes.
    Thank you.
    Under IOUs, Jim.
    Yes.
  • 03:16:05
    Thanks.
    Thank you.
    Aaron.
    Yes.
    Thank you.
  • 03:16:08
    Thank you.
    Rob.
    Yes.
    Thank you.
    Under our Munis, Faye.
  • 03:16:14
    I've got your yes in chat, Faye.
    Thank you.
    Ashley?
    I see you're on, but I don't Ashley, are you still with us?
    I can take in chat if you're having mic issues.
  • 03:16:36
    Alright.
    How about Diana?
    Yes.
    Thank you.
    Motion carries.
  • 03:16:41
    Unopposed, two abstentions.
    Okay.
    Thank you, everybody.
    On behalf of LFL, thank you.
    Okay.
  • Item 6.04 - NPRR1267, Large Load Interconnection Status Report
    03:16:51
    So that takes us to 1267, which was sponsored by the joint sponsors.
    We had a an IA that was filed yesterday.
    I don't know if we wanna bring that one up and see if anybody has any thoughts.
    Troy, please go ahead.
    I I'd just like to comment on this one that the cost you see here is to automate the report, but ERCOT can deliver a manual approximation of it within one to two months.
  • 03:17:19
    So the the five to eight months is more of an automation effort.
    And I got a recommended priority in ranking my slides.
    Okay.
    Perfect.
    Bill Barnes?
  • 03:17:34
    George just answered my question.
    That's exactly what I was gonna ask is, whether this could be implemented manually sooner, it sounds like.
    Yes.
    So thanks.
    Okay.
  • 03:17:45
    Great.
    So for everybody, Phil, on December, we could put this on the combo.
    Okay, Corey.
    Let's add that one as well, please.
    Alright.
  • Item 6.05 - NPRR1275, Expansion of Qualifying Pipeline Definition for Firm Fuel Supply Service in Phase 3*
    03:17:55
    Next up, we have 1275.
    ERCOT sponsored.
    No impact.
    I believe we had WMS file comments that they wanted to keep this tabled.
    I don't think we have to do anything on this, Corey, because it's already tabled, so we're just okay.
  • Item 6.06 - NPRR1276, Move OBD to Section 22 – Emergency Response Service Procurement Methodology
    03:18:10
    And then 1276, this is also coming to us from ERCOT, and they had an IA of less than 5,000, which is there on the screen.
    How does everybody feel about twelve seventy six on the comma ballot?
    Alright.
    See, now we're moving.
  • Item 7 - Revision Requests Tabled at PRS (Possible Vote)
    03:18:30
    Okay.
  • 03:18:31
    I think there was only one item on the tabled items for discussion and possibly question.
  • Item 7.12 - NPRR1277, Revisions to EAL Formula (PRS)
    03:18:39
    1277.
    I know that we were asked to table this for an additional month to give folks some time to look it over.
    We haven't seen any comments filed, and the language was endorsed by CFSG back in December before it was filed.
    See where we are on this one and how folks feel about twelve seventy seven.
  • 03:19:02
    It's already tabled, so we don't have to do something with it, but we can add it to the combo ballot combo.
    Okay, Corey.
    Let's add twelve seventy seven as well, please.
    Alright.
    Now the approval last submitted, I hope, since there's some really other options.
  • 03:19:19
    Yep.
    It looks like approved as submitted.
    Can we just change EAL to EEL throughout the document and then just approve from there?
    Do do not give Corey Hartburn.
    We're already we're already testing our limits.
  • 03:19:37
    Okay.
    Anybody have anything else that we didn't raise under the table items under Section 7?
  • Item 7.07 - NPRR1264, Creation of a New Energy Attribute Certificate Program (WMS)
    03:19:46
    Austin, for 1264?
    Oh, okay.
    Yeah.
  • 03:19:52
    So 1264 I don't know if you wanna say anything about this, Eric.
    I just wanna bring it up to y'all's attention.
    ERCOT's still unsure of their position on that, and so they wanted to provide a little more transparency, and awareness to the board and the commission.
    So we are teeing that up for discussion at the June board meeting.
    So just wanna make sure y'all were aware of that so you weren't caught off guard because that's that's different.
  • 03:20:21
    So this is one's a little different.
    So Great.
    Thank you.
    We appreciate that heads up.
    Okay.
  • 03:20:29
    Anything else under section seven?
    Okay.
  • Item 8 - Review of Revision Request Language (Vote)
    03:20:33
    So that will take us to new language.
  • Item 8.01 - NPRR1278, Establishing Advanced Grid Support Service as an Ancillary Service
    03:20:37
    We have 1278, which is coming to us from joint sponsors.
    Wanna see if NG or Jupiter Power wanna lay this one out for us.
  • 03:20:46
    Bob, is that you?
    Or It's Bob.
    Oh, yeah.
    Yeah.
    Yeah.
  • 03:20:51
    Sorry.
    I was multitasking here.
    Yeah.
    This one is trying to it's it's based on what, NOGRR272 has in making a mandatory standard.
    What this does, it it would implement the exact same, reliability requirements, but it would would be done through an ancillary service.
  • 03:21:14
    And the way this is, crafted, since it is different than other ancillary services, it's more like a black start issue.
    It is completely done through an RFP process on a yearly basis and would be put together by ERCOT.
    Now what this does is a couple of things and because I don't with time going, I think that we're gonna send this to WMS and to ROS.
    I'm gonna make that motion here in a minute, so I don't wanna get into a WMS or an ROS meeting here today.
    We can discuss those comments later.
  • 03:21:44
    But what from our from my perspective, what this does is it gives us a couple of things.
    It gives us the ability to look at a larger piece of who can supply this rather than just the, the new e r ESRs coming online, which will take time to come through.
    This will allow once it's in the system, ERCOT can decide what they want, how much they want, and actually where they want it potentially.
    But that would bring up some market power issues that we would have to probably address if that went down that road.
    But it it will also allow ERCOT in the future through the RFP process without changing anything in protocols that if there's a new software design that's out there, new other things that have come out that could be available that ERCOT feels that the the, the system needs, they could put that in the RFP and ask for that.
  • 03:22:42
    And then those that wanted to participate in that could go out, make those purchases, look at what that cost would be, and then offered it to the system.
    So that that's kinda what it is.
    OWG and PCWG have already talked about this at two meetings, and they're moving it through from a reliability standpoint, which I think still needs more work, whether it's 272 or or this one.
    So they've got work to do.
    WMS, of course, is where the market conversation needs to take place on whether this is is viable and should be the way to go rather than a mandate.
  • 03:23:20
    So with that, I would go ahead and make a motion to table 1278 and remand I can't hear you.
    Combo.
    Yeah.
    Is that okay for the combo?
    Yeah.
  • 03:23:35
    To remand WMS and ROS.
    Any other thoughts on 1278?
    Brian?
    Support Bob's motion and just, for ROS and for WMS discussion.
    Interested to look at if there are other resources that can provide this service, also support it being a paid service.
  • 03:23:59
    Thank you.
    Okay.
    Alright.
    So sounds like we're supportive.
    Does anybody have thoughts on 1278?
  • 03:24:08
    Okay.
    Table and Caitlin.
    I just wanted to say, you know, thank you to Bob for the layout, and and thanks to Brian.
    I I think we agree with that technology neutral approach, as long as you're willing to do the work and and help us write the language for that.
    Okay.
  • 03:24:30
    So 1278 table and refer to WMS and ROS.
    Okay.
    Alright.
    Twelve seventy nine.
    Andy, I'll turn it over to you.
  • 03:24:41
    Yeah.
    Thanks.
  • Item 8.02 - NPRR1279, Reinstate Enhancements to the Exceptional Fuel Cost Process
    03:24:42
    Andy Nguyen with Constellation.
    NPRR1279 reinstitute enhancements to the EFC process.
    This might take y'all down memory lane, but this is actually an NPRR we passed back, in 2023.
  • 03:24:58
    It was NPRR1177.
    Just to remind folks, at that time, there was a sunset date put on it because we expeditiously filed the NPRR due to the need to ensure that we could recognize our fuel cost.
    The sunset date did expire at the beginning of this year, and so we're still needing a process to, ensure that resources can recognize their, fuel cost in real time without the risk of mitigation.
    As a reminder, ERCOT has a mitigated offer curve, based on some generic costs.
    We have unveiled that there are actually additional contractual costs that aren't recognized in that mitigation.
  • 03:25:45
    And, additionally, if the resource is mitigated and they do incur these costs, there is really no way to recover those costs because per protocols, LMP is supposed to compensate you for that.
    So, this was a heavily debated topic.
    We, Constellation, are filing this NPRR as is.
    There is one caveat that there was a sunset date.
    We're not following a sunset date here.
  • 03:26:13
    As a starting point, we believe that this at least gives the ability for resources to achieve the energy offer curves needed so that the mitigation can, be replaced with the energy offer curves.
    With all of that said, if folks are supportive, we'd be happy to have this table and refer to WMS and WMWG, for further discussion.
    Our goal is to have this approved by the wintertime when their resources are more subject to gas curtailment, which really impacts these gas costs.
    But, with that, happy to answer any questions.
    Eric, go ahead.
  • 03:26:59
    I'll keep it brief so I don't repeat myself at WMS.
    But, I I appreciate the offer to table and refer.
    I do think we can have a productive conversation around here.
    I appreciate you reaching out in advance of filing this.
    And I I hope there's a a version of this that that we can agree to along the lines of of what we've discussed, and and we can discuss that at WMS.
  • 03:27:24
    K.
    Thank you, Eric.
    Katie?
    Andy, thanks for bringing this back.
    And at first, I was maybe hoping since this was just bringing back the what was expired that we could move this forward today.
  • 03:27:37
    But if you feel like we need to have the discussion at WMS and WMG, I'm I'm fine with that, but just wanted you to know that you have our support.
    Okay.
    Any other thoughts on 1279?
    Sounds like wanna table it and refer to WMS.
    Okay.
  • 03:28:04
    Put that on the combo ballot.
    We're ready.
    Good.
    Austin, did we forget 1277?
    No.
  • 03:28:12
    That's take that's on combo.
    I did.
    I forgot to bring it up.
    I believe that's tabled here.
    No.
  • 03:28:19
    We we added it to combo valid.
    Oh, you did?
    It's approved.
    Oh, never mind.
    Yeah.
  • 03:28:24
    You're good.
    Thanks.
    Okay.
  • Item 8.03 - NPRR1280, Establish Process for Permanent Bypass of Series Capacitor
    03:28:34
    So that takes us to 1280.
    We have the IA posted, and this comes to us from ERCOT.
  • 03:28:43
    Somebody at ERCOT modeling yeah.
    Please go ahead.
    Yeah.
    This is Sanuk.
    Yeah.
  • 03:28:48
    Just just give a high level summary on this.
    So, through this NPRR, ERCOT, is trying to set up an an RPG review process, for TSP's proposal to permanently bypass existing series capacitors.
    And as you know, currently, we have about 18 series capacitors.
    They're all on the major 345 kV transmission line.
    And, originally, they were installed to improve, you know, power transfers from gen, from generation to load centers and also to support some voltages here, by, you know, reducing, you know, line impedances, the long 345 kV transmission lines.
  • 03:29:33
    But over time, as, you know, major transmission upgrade are put in place, that original needs and benefits of these capacitors may no longer apply, and and our system, you know, may no longer need the series capacitors.
    So right now, you know, there is no formal process to come on and bypass this capacitor.
    So this NPRR, will put a formal process in place, so that the stakeholder can provide any comments, you know, during the RPG review process.
    And once it's permanently bypassed, stakeholders, don't need to do any, you know, SSO studies associated with that, you know, permanent bypass to these capacitors.
    They don't need to figure out, you know, the SSO mitigation plan that, permanent bypass to these capacitors.
  • 03:30:28
    So what that really mean is it saves a lot of time and cost and and for studies and mitigation plan and for generation and connection, you know, developers and, you know, load customers as well as TSPs.
    This is, it helps everybody involved in that, you know, SSO here.
    So if, you know, PRS agrees, then, I hope that, this refers to, the ROS, so that the ROS can, ask, maybe PLWG for further discussion on this NPRR1280 here.
    Okay.
    Thank you so much.
  • 03:31:18
    John?
    Yes.
    A lot of these, series capacitors have been put in in the last ten years.
    And, I was wondering if there was any thought on how much depreciate I mean, will they be able to keep depreciating them after they since, you know, it's usually on transmission is forty year depreciation on transmission.
    So, if we're not if they're not being used, are they will this cause any problems with dollars in the, you know, for the TOs?
  • 03:32:07
    But it's just a thought because I'm not I haven't thought about this much.
    But Yeah.
    So I I I would rely on, I mean, TSP's input on that.
    But, you know, again, this NPRR is not about the retiring or anything, but it just permanently bypass the capacitors.
    Who knows?
  • 03:32:35
    At some point in the future, you know, do we need a capacitor again?
    That that's open questions.
    But, as you know, ERCOT, you know, have some major transmission upgrades.
    Right?
    For example, like, you know, lower your Grand Valley transmission in from projects, which provides, multiple, you know, input pass into the valley, you know, that that that, you know, provide a significant improvements in the transfer capability.
  • 03:33:08
    So, you know, that kind of projects may, you know, diminish the initial original, benefits and need for the series capacitors.
    And and if if TSP, you know, believes that, it can be a permanent bypass, I mean, they should be able to, go through this process to have, you know, further conversations or comments like what you have, you know, through the IPG process.
    So Okay.
    Thank you so much.
    Mark Smith?
  • 03:33:49
    Yeah.
    I was just wondering whether it was detrimental at all, to retain the, if they're not being used to to keep them on the transmission line or whether, whether they there needs to be some, program or something to remove existing ones that are no longer useful.
    Those might be some of the conversations we have at the the other working groups too.
    It sounds like we wanna table this and at least send it to ROS so that might we might have some more engaged conversation there.
    Thanks.
  • 03:34:28
    Mister Helton?
    Thank you for writing this protocol revision.
    Anything we can do to get these things, off the system when they're not needed and help with our self inflicted wound, that these cause will be great.
    Brian?
    I was just gonna say that the regulatory rate treatment for stranded assets is kinda beyond the purview of of, ERCOT, and so not really an issue for us to take up here.
  • 03:35:02
    But, Diana, I heard you give us direction to refer this to ROS, and I I wholeheartedly support that and look forward to moving on to the next thing in our agenda.
    Okay.
    Brian wants to get out of here.
    He's hungry.
    Okay.
  • 03:35:18
    So I think what we heard is to table twelve eighty and refer it to ROS.
    Okay.
    Put that on the combo ballot, please.
    Okay.
    Last but not least, 1281, comes to us from LCRA.
  • 03:35:36
    First time that we've had it here.
    I don't see Blake.
    What are everybody's thoughts on, twelve eighty?
    You say his name and he appears.
    Sorry, Blake.
  • Item 8.04 - NPRR1281, Improvements to Alternate FFSS Resource Designation
    03:35:56
    Alright.
    I'm up.
    Up.
    Blake Holt, LCRA.
    This NPRR was filed, specific to the alternate resource situation presented in Perpule Supply Service.
  • 03:36:09
    So, currently, if the QSC has an issue with their primary resource and would like to switch to the alternate resource, they're required to send an email, to ERCOT operations to notify of the switch.
    What also happens here is the settlements group takes that email and has to make a manual adjustment in their system in order to recognize the availability, and make sure the settlement process plays out correctly.
    So should the QSE not send a timely email or have some incorrect information in their email or should ERCOT not process that email timely.
    You'll see situations where settlement will be incorrect even though the units are available.
    Specifically, each primary and alternate resource have to submit availability flags for every hour indicating whether they are available or unavailable.
  • 03:37:08
    And so what this NPRR aims to do is to modify the settlement system to recognize those availability flags and have a more systematic approach to to settlement and, reduce the instances of manual error.
    Given the likely expansion of the program, there will be more resources, likely more alternates available, and this NPRR would actually reduce, ERCOT's burden in terms of processing, those those cases.
    So that is the pitch for the NPRR.
    I will say that there is some additional modifications, instead of an email to ERCOT operations, to notify of the switch.
    There is a phone call instead just to create some operational awareness for the operators.
  • 03:38:01
    And then there's an additional modification that states that the generation resource may only be offered as an alternate resource for one primary resource.
    Happy to take any questions, on the change.
    Any thoughts, comments?
    Eric, please.
    I wanna move quickly to keep Brian happy.
  • 03:38:26
    But, two questions.
    One for ERCOT.
    Do y'all, at a high level, agree with the summary, or do you think there's anything else that is is worth understanding about this NPRR?
    Because if you do agree, then it seems the key question is what is the impact analysis versus if you don't agree, then we should send it to WMS.
    So that's why I asked.
  • 03:38:53
    I see Magie in the queue.
    Magie, go ahead.
    Yes.
    This is Magie, Shanks from ERCOT.
    We actually did see this language prior.
  • 03:39:03
    LCRA did share it with us.
    We're fine with this since it does automate an existing manual process, and Blake did summarize it well.
    Great.
    We have new additional So if that's the case, then maybe a combo ballot to approve so we can see where the IAA is.
    Brian?
  • 03:39:22
    Yeah.
    I support that.
    I did just why why limit it to one resource?
    Are the one resource resource?
    The language here?
  • 03:39:33
    Yes.
    Evidently, there has been a situation in the past where, there has been an alternate resource that operated for multiple primaries.
    I'm getting a head nod from MENO.
    If that were to still be in place, I think there would be some complication introduced with this or logic that's gonna be implemented.
    I think, Magie or or Eno could probably speak to that complication, if needed.
  • 03:40:01
    Good good enough.
    Okay.
    Thank you.
    Okay.
    We got a good enough from Brian.
  • 03:40:07
    Okay.
    So it sounds like 1281 is good to go on the combo ballot as submitted.
    Okay.
    Alright, Corey.
    Where does that take us?
    EditCreate clip
  • 03:40:17
    Okay.
  • Item 9 - Notice of Withdrawal
    03:40:17
    So we have a notice of withdrawal.
  • Item 9.01 - NPRR1262, Ancillary Service Opt Out Clarification
    03:40:20
    There's no PRS action needed just as a notification that 1262 is being withdrawn.
    I don't know if anybody needs to add anything on that, but just as an awareness item.
  • Item 11 - Combo Ballot (Vote)
    03:40:30
    And then here is our our list of our combo items.
  • 03:40:37
    So we'll need a motion and a second motion by Kevin Hanson.
    Second by Bob.
    A very eager motion.
    Thank you, Corey.
    Alright.
  • 03:40:56
    On our combo ballot, we will begin up with the consumers.
    With Eric?
    Yes.
    Thank you.
    Mark Dreyfus.
  • 03:41:03
    Oh, yeah.
    He he said he was gonna bail at one, and he did.
    Man of his word.
    Melissa.
    Yes.
  • 03:41:08
    Thanks.
    Thank you.
    Mark Smith.
    Yes.
    Thank you.
  • 03:41:12
    Onto our co ops, Eric Blakey?
    Yes.
    Thank you.
    Joe Down.
    I've got your yes in chat, Joe Down.
  • 03:41:22
    Thank you.
    Blake?
    Yes.
    Thank you.
    Lucas?
  • 03:41:26
    Yes.
    Thank you.
    Onto our independent generators, Andy?
    Yes.
    Thanks, Mark.
  • 03:41:31
    You.
    Caitlin?
    Yes.
    Thank you.
    Katie?
  • 03:41:36
    Yes.
    Thank you.
    Bob Hilton?
    Yes, sir.
    Thank you, sir.
  • 03:41:39
    Ryan?
    Yes.
    Thank you.
    Thank you.
    Chase?
  • 03:41:43
    Yes.
    Thank you.
    Jim?
    Yes.
    Thank you.
  • 03:41:48
    Kevin?
    Yes.
    Thank you.
    Thank you.
    Under IPMs, John?
  • 03:41:53
    Yes.
    Thank you.
    Seth, are you still with us?
    Yes.
    Shane?
  • 03:42:03
    Yes, sir.
    Thank you.
    Thanks, sir.
    Under our Ira, it's Bill.
    Yes.
  • 03:42:08
    Thank you.
    Austin.
    Yes.
    Thank you.
    Under IOUs, Jim.
  • 03:42:15
    Yes.
    Thanks, Warren.
    You.
    Aaron.
    Yes.
  • 03:42:17
    Thank you.
    Thank you, Rob.
    Yes.
    Sir, under our Munis, Faye.
    Got your yes in chat, Faye.
  • 03:42:25
    Thank you.
    Ashley.
    Yes.
    Thank you.
    And Diana.
  • 03:42:31
    Yes.
    Thank you.
    Motion carries unanimously.
    Okay.
    Thank you so much, guys.
  • 03:42:37
    We appreciate all the the feedback and the input today.
  • Item 12 - Adjourn
    03:42:40
    We will see everybody next month in June.
2025 PRS NPRR1282 Ballot 20250514
May 13, 2025 - xls - 113 KB
2025 PRS NPRR1282 Urgency Ballot 20250514
May 13, 2025 - xls - 113 KB
2025 PRS NPRR1238 Ballot 20250514
May 13, 2025 - xls - 109.5 KB
2025 PRS Combined Ballot 20250514
May 13, 2025 - xls - 111 KB
Agenda_PRS_20250514
May 06, 2025 - docx - 46.5 KB
Draft Minutes PRS 20250409
May 06, 2025 - docx - 83.3 KB
PRS_May_2025_Project_Update
May 12, 2025 - pptx - 229.4 KB
AgingRevRqstProjects_PRS_Review_2024-05_v1
May 12, 2025 - xlsx - 100.9 KB
May 14, 2025 PRS Meeting Materials
May 12, 2025 - zip - 8.1 MB