Message-ID: <23511316.1075840021522.JavaMail.evans@thyme> Date: Wed, 30 Jan 2002 16:48:05 -0800 (PST) From: bharsh@puget.com To: isas@wscc.com Subject: RE: E-Tag 1.7 Test Procedure Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: Harshbarger, Robert X-To: Interchange Scheduling & Accounting Subcommittee (ISAS) X-cc: X-bcc: X-Folder: \ExMerge - Scholtes, Diana\Inbox X-Origin: SCHOLTES-D X-FileName: Raymond - Since I have not seen any other responses to your e-mail, I am concerned. In item 1 of your email, what I think you describe here sounds like NERC's "functional model" or what came out of the CACTF work. In that model they said that check-out was only between GCAs and LCAs - intermediate CAs (balancing authorities) would not need to know of the wheel throughs. However, the TP function(s) from source to sink would need to see the tag to manage their respective transmission assets. I hope that what is described here is not NERC's functional model. My control area, too, is not prepared to change check-out and accounting procedures suggested in the CACTF's work. Perhaps, embedded in the 1.7 registry tables there are pointer's to/from TPs to/from CAs and this is why intermediate CAs are optional in OATI's tag agent. However, as you point out, there is not a one-to-one correspondence of TP to CA or vice-versa within the WSCC. I hope that there are experts out there that can answer this item and tell us every thing is going to be all right. Items 2 & 3 seem to touch on a current debate going on in the NERC IS and TISWG email forums on extensions of tags. From those discussions, one thing seems to be clear, once a tag reaches its stop hour and that transaction ends, it is considered finished or in 1.7 speak, Dead. It can not be restarted or extended. However when where how much an extension be for is still be debated. Hope the answers come soon, seems a bit late in the game to have so much uncertainty out there. Robert Harshbarger Puget Sound Energy OASIS Trading Manager 425.462.3348 (desk) 206.604.3251 (cell) mailto:bharsh@puget.com > ---------- > From: RAYMOND VOJDANI[SMTP:AVOJDANI@wapa.gov] > Sent: Monday, January 28, 2002 4:54 PM > To: Interchange Scheduling & Accounting Subcommittee (ISAS) > Subject: Re: E-Tag 1.7 Test Procedure > > Hi Steve, > > As we approach the impending implementation of E-Tag 1.7, we have begun > reviewing and studying the new features of the Tag Services interface as > explained at the NERC Workshops and as developed by our vendor, OATI. > The implementation of the E-Tag 1.7 Specifications has raised some > questions. > > 1. On the section of the tag where the PSE creates the Physical Path > for the transaction, there are required fields for the Generating > Control Area, the Load Control Area, and the intermediate Transmission > Providers. There is not a requirement to document the intermediate > Control Areas (there is a location to include them as Scheduling > Entities, but those fields are optional). This would seem to be a > significant obstacle to providing all Control Areas the information they > need to perform hourly schedule checks with their neighboring Control > Areas. Also, in WSCC, where certain Control Areas are responsible for > managing constrained paths, this would be an obstacle in determining > scheduled flows across the constrained paths. It is possible (even > likely) to create tags where the Control Area would not see the tag, > because the transmission used is owned by Transmission Providers other > than the Control Area. Was it the intent of the NERC E-Tag 1.7 > Specification to remove intermediate Control Areas from visibility and > approval of the tags? > > 2. Once an E-Tag has been approved, and has achieved the Implement > state, it appears to have immortality. Even when the 'final hour' of > the current version of the tag has passed, the tag does not appear to be > inactive; it is available for the creating PSE to access and extend by > an Adjust request. This feature could potentially bog our system down > with numerous tags that are presently 'inactive' but always available > for adjusting. Did the NERC specifications intend for an Implemented > tag to eventually become 'inactive' and unavailable for adjustment? > > 3. A related concern to tag Adjustment Requests; under E-Tag 1.7, a PSE > may now create a tag and accomplish ongoing scheduling through the > Extension of the tag by adjusting (oh, boy, account number scheduling > has returned). At the NERC E-Tag 1.7 Training Workshop, the Timing > Requirement for Profile Changes, WSCC, is 15 minutes to evaluate any > early notice. This could be a significant business change; the PSE can > accomplish preschedule functions by requesting tag extensions (15 > minutes evaluation time) rather than creating new tags (3 hour > evaluation time). The clear distinction between Next Day schedules and > Real Time schedules is being lost. Perhaps the evaluation time of an > any Profile Change Request could be linked directly to the impact time > of that change request, similar to the timing requirements for > submission and evaluation of New Tag Requests. > > Considering the above shortcomings, especially item #1, it is > impossible for us to move toward implementation of E-Tag 1.7, for, we > will not be able to check out the net interchange with our neighboring > control areas or be able to manage the constrained paths in our control > area. Please give me a call should you have any question or if you want > to discuss this further. Thanks. > > Raymond > (970) 461-7379 > > Raymond R. Vojdani, P.E. > Transmission Scheduling and Security Manager > Rocky Mountain Region > Western Area Power Administration > > > >>> 01/25/02 05:08PM >>> > ISAS Members, > > Attached is a draft test procedure for E-Tag 1.7. It was created and > approved by a small "swat team" of ISAS members and WSCC Staff. Please > review this draft procedure and provide any comments you may have by > 1200 > MST Tuesday, January 29, 2002. > > Thanks. > > > > > <> > > > > >