|
|
Enron Mail |
Jim and Rick
Please read Mike Gildea's issue 2. I work with Mike closely on operating policy issues. He is with Duke NA, the IPP side, formerly with EEI. I need some help on where Enron stands on current legislation as it relates to his question. Do we think the language empowers NERC with too much authority? Or does it allow for any organization, i.e. GISB/EISB to perform the functions. I know Enron agrees with NERC not imposing restrictions on the RTOs and slow down market formation - but we certainly don't want to have to deal with every RTO as a reliability standard setting organization. ---------------------- Forwarded by Charles Yeung/HOU/ECT on 04/27/2001 02:04 PM --------------------------- "Michael F Gildea" <mfgildea@duke-energy.com< on 04/27/2001 01:36:40 PM To: Charles.Yeung@enron.com cc: Subject: Re: NERC Issues Charles, 1. I believe we need a conference call with yourself, Lydia and few others to assess the landscape, come to a common position and goal here. I believe the ugly train has left the station and we are in damage control at the moment. Optimally, we need the three of us on the same page when we go to the TCCG meeting in Tampa, from there we can try to spread our common message. 2. On another front, - the reliability legislation. I told our DC office (not that they will listen) that the legisation NERC is pushing on the Capitol Hill is now outdated and puts too much emphasis for standards in NERC hands when the game today is inthe RTOs. A powerful NERC may slow up market development. What is the view of Enron here? I assume the same, but curious. Apparently, some Hill Staffers called our DC office for opinions on the NERC reliability legislation - so something afoot. Micheal Charles.Yeung @enron.com To: mfgildea@duke-energy.com cc: 04/27/01 bcc: 01:06 PM Subject: Re: when the LCA is not the Sink ---------------------- Forwarded by Charles Yeung/HOU/ECT on 04/27/2001 01:05 PM --------------------------- Charles Yeung@ECT 04/27/2001 12:53 PM To: LVollmer@pwrteam.com @ ENRON cc: Richard.Ingersoll@enron.com@ENRON, Charles.Yeung@enron.com@ENRON, mike_gildea@duke-energy.com@ENRON Subject: Re: when the LCA is not the Sink (Document link: Charles Yeung) I want to forward this to TCCG as agneda items for the Tampa meeting. LVollmer@pwrteam.com on 04/27/2001 10:02:16 AM To: Richard.Ingersoll@enron.com cc: Charles.Yeung@enron.com, mike_gildea@duke-energy.com Subject: Re: when the LCA is not the Sink Charles and Mike - At yesterday's Security Subcommittee meeting, a motion passed to change SMEPA control area configuration in the IDC to reflect the location of their share of generation in Entergy's territory that is needed to serve their load. The way the IDC was working was giving erroneous information about an overload on the Weber-Richard line, which in fact was not happening. I tried to prevent this change for occurring stating that policy 9 allows for the security coordinators to adjust the cut list when known errors are occurring. We need to have a definite action plan for how and when increased granularity will be allowed to happen. Lanny Nickell is suppose to make a presentation at the next MIC meeting about this. But we all need to be on the same page to have an action plan in place that we can start shopping to MIC members. I have volunteered to head a group to try to define the "end state" of total granularity that we would ultimately want for the IDC and the asociated costs to get there. Another important issue that we need to address head on is the desire of the SCs to allow for lowering of the impact thresholds for certain flowgates that are now not getting relief at 5%. I asked if this motion was passed would it guarantee that less MW's will be cut in order to get the relief needed -- the answer was no. Therefore, why should we support any change? This entire issue centers around a fundamental issue that has existed from day one when flowgates were first allowed -- what are the standards for allowing new flowgates? To what extent should local problems be addressed by the transmission provider with those problems, versus putting the pain on the entire market place because the TP can't or won't improve their transmission facility? (In the first days of TLR, I raised this issue over and over again when MAIN used a 500 kV line as a proxy for the Albion Transformer -- which caused about 2,500 source-sink pairs to be cut throughout the eastern interconnection). This is an issue that ultimately will be handled by the RTOs, but education is the key here as flowgates are being defined around the country. Another issue is OSL determination. Ben Li has prepared Appendix 9C1A. There was discussion at the meeting that implementing this would further restrict transmission access. The SCs are all over the board on this. I reminded them that the MIC had asked for data for each flowgate now in existence for TLR purposes to define for us how they determine their own limits -- I was told at this meeting it was never done because there was no agreement on how to measure the OSL. So how, I asked, can a OSL be determined via of a NERC standard? I have real heartburn that NERC does not have any measurable standards for allowing the items discussed above. We have to force criteria and measurable standards. Let me know what you think. Also, what we need to do to flesh out these issues so everyone can understand them. Lydia Vollmer Exelon Power Team 300 Exelon Way Kennett Square, PA 19348 610-765-6620 lvollmer@pwrteam.com Richard.Ingersoll @enron.com To: Charles.Yeung@enron.com cc: bill.rust@enron.com, dgcipriany@aep.com, drboezio@aep.com, 04/24/2001 11:05 hyan@pwrteam.com, idcgtf@nerc.com, idcusers@nerc.com, AM lvollmer@pwrteam.com, pehoffer@aep.com, ringers@ect.enron.com, vapr@dynegy.com Subject: Re: when the LCA is not the Sink Charles, I agree with you buti think we need to resist increased granularity at this time. ?It will only decrease transmission and increase TLR,s. ?Also the increase in transmission segments will make it more dificult to put a transaction together. Charles Yeung ? ? ? ? To: pehoffer@aep.com @ 04/23/2001 06:28 AM ENRON ? ? ? ? cc: idcgtf@nerc.com@ENRON , idcusers@nerc.com@ENR ON, dgcipriany@aep.com@EN RON, drboezio@aep.com@ENRO N, hyan@pwrteam.com, lvollmer@pwrteam.com, bill rust, ringers@ect.enron.com , vapr@dynegy.com ? ? ? ? Subject: Re: when the LCA is not the SinkLink This sounds like a tagging problem and not an IDC granularity problem. Yes - this can be fixed with a IDC granularity change but does NERC want to change IDC granualaruty on a piecemeal basis for this and the othe 14 control areas? ?What abot when these 15 control areas change to another control area service provider? ?What about the next 15? I don't think that AEP's customers actually disconnected from the AEP grid and reconnected at some other point in another control area's transmission network. The IDC is not mapping flows for that customer any more "wrongly" than when that customer purchased control area services from AEP. This is why hard criteria is needed to verify whether these 15 situations require granularity change or whether ALL existing control areas need more granularity for that matter. Sent by: ? ? ? ?owner-idcgtf@nerc.com To: ? ? ? ?idcgtf@nerc.com, idcusers@nerc.com cc: ? ? ? ?dgcipriany@aep.com, drboezio@aep.com Subject: ? ? ? ?when the LCA is not the Sink We have been informed by one of our customers who serves a load which has been electronically removed from the AEP Control Area that ?from now on they will use the Electronic Control Area as the LCA, instead of using the Physical Control Area (AEP) as the LCA. In this way, the Electronic Control Area will be properly notified of any adjustments and approvals regarding this transaction. Unfortunately, the IDC will be mapping the flow into one CA while it's really going to another. Our representative to the SSC will be arguing strenuously at their next meeting that these types of situations need to be addressed. Historically, the creation of a new control area has been the answer. Lou has indicated that there are 14 of these situations pending in the Eastern Interconnect.
|