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 <bharsh@puget.com>
X-To: Interchange Scheduling & Accounting Subcommittee (ISAS) <isas@wscc.com>
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
> 
> 
> >>> <sccobb@srpnet.com> 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.
> 
> 
> 
> 
>  <<E-Tag  Functionality Test Ver 1_1-25-02.doc>> 
> 
> 
> 
>  
> 