30
e-Tag 1.8 An industry tutorial

e-Tag 1.8

  • Upload
    nelia

  • View
    24

  • Download
    3

Embed Size (px)

DESCRIPTION

e-Tag 1.8. An industry tutorial. Authority Service validates requests and manages approval process. Approval Services are used by various entities to assess, approve, and submit changes. e-Tag 1.8. The basics features of e-Tag 1.8 are much the same as in the current 1.7097 version. - PowerPoint PPT Presentation

Citation preview

Page 1: e-Tag 1.8

e-Tag 1.8

An industry tutorial

Page 2: e-Tag 1.8

e-Tag 1.8

The basics features of e-Tag 1.8 are much the same as in the current 1.7097 version

The tag author

uses Agent Service to create and

submit requests

Authority Service

validates requests and

manages approval process

Approval Services are

used by various entities to

assess, approve, and

submit changes

Page 3: e-Tag 1.8

e-Tag 1.8 “Requests” are a basic of e-Tag There are new tag requests – the

initial submittal of a Request for Interchange. Once fully approved, it becomes the e-Tag.

There change requests – a market adjustment and a reliability curtailment are two examples of change requests

Page 4: e-Tag 1.8

e-Tag 1.8

Requests have status assigned by the authority service to describe its overall state

Page 5: e-Tag 1.8

e-Tag 1.8

1.7097 1.8• Pending• Implemented• Dead

• Pending• Approved• Withdrawn• Denied• Expired

Request states

Page 6: e-Tag 1.8

e-Tag 1.8

Almost every request requires assessment and response from approval entities

Each approval entity’s response is assigned an approval state

Page 7: e-Tag 1.8

e-Tag 1.8

1.7097 1.8• NA• Pending• Approved• Denied• Study

• NA• Pending• Approved• Denied• Study• Expired

Individual Approval States

Page 8: e-Tag 1.8

e-Tag 1.8

The composite state indicates the overall state of the e-Tag

Page 9: e-Tag 1.8

e-Tag 1.8

1.7097 1.8• Pending• Implemented• Dead

• Pending• Confirmed• Implemented• Cancelled• Terminated• Withdrawn• Denied• Expired

Composite States

Page 10: e-Tag 1.8

e-Tag 1.8

Formalization of the Time Classification schema element

Authority Service assigns based on the relative start and submittal times On-time LATE ATF

Page 11: e-Tag 1.8

e-Tag 1.8 Improved loss calculations for curtailments In 1.7097 the Authority Service recalculated

in-kind losses for a curtailment from the source BA to the sink BA, regardless of the curtailed segment

In 1.8 the curtailing entity will specify the segment with the restriction and the Authority Service will recalculate losses both up-stream and down stream of that segment

Page 12: e-Tag 1.8

e-Tag 1.8

In 1.7097…

~100 MWs 1 MWs 2 MWs 95 MWs2 MWs

Third segment has a 50 MW restriction, Authority recalculates:

~50 MWs 0 MWs 1 MWs 48 MWs1 MWs

Page 13: e-Tag 1.8

e-Tag 1.8

In 1.8…

~100 MWs 1 MWs 2 MWs 95 MWs2 MWs

Third segment has a 50 MW restriction, Authority recalculates:

~51 MWs 0 MWs 1 MWs 49 MWs1 MWs

Page 14: e-Tag 1.8

e-Tag 1.8

Carbon Copy Field In 1.8 the Tag Author may specify

other BAs, TSPs, or PSEs who need to know about the transaction but who are not listed in either the market or physical paths in the e-Tag.

Carbon Copy entities do not have approval rights

Page 15: e-Tag 1.8

e-Tag 1.8

Terminating ATF e-Tags In 1.7097, ATF e-Tags could not be

Terminated if a mistake was made In 1.8 an ATF e-Tag can be

Terminated

Page 16: e-Tag 1.8

e-Tag 1.8

Dynamic Adjustments E-Tag 1.8 will allow the Source and

Sink BAs to submit an adjustment to a Dynamic type e-Tag

This is in addition to the e-Tag Author

Page 17: e-Tag 1.8

e-Tag 1.8

Energy and Transmission Profiles The Agent and Authority Services will

require the e-Tag’s transmission allocation profile to be > the energy profile

Page 18: e-Tag 1.8

e-Tag 1.8

A new ATF e-Tag is restricted to a duration of one hour, except for e-Tag transaction type DYNAMIC.  A DYNAMIC type ATF e-Tag may be submitted with a start time up to 168 hours in the past.

Page 19: e-Tag 1.8

e-Tag 1.8

Currently, Dynamic type e-Tags can only be adjusted up to 96 hours in the past.

Under 1.8, this capability has been extended to 168 hours – again just for Dynamic type e-Tags.

Page 20: e-Tag 1.8

e-Tag 1.8 Added new transaction type “Pseudo Tie” Within the context of e-Tag 1.8, this type

behaves exactly like Dynamic transaction type (it is just a different label for unique identification purposes).

JISWG is not proposing when or where this transaction type should or should not be used.

Other systems using e-Tags may need modification to properly account for the Pseudo Tie transaction type.

Page 21: e-Tag 1.8

e-Tag 1.8

Scheduling Entity Field NERC Glossary says: An entity

responsible for approving and implementing Interchange Schedules.

1.8 may require a single BA in each Scheduling Entity field – very similar to WECC requirements

Page 22: e-Tag 1.8

e-Tag 1.8 Ramp Rate is replaced with Ramp Duration Users will no longer see a ramp duration on

intermediate interchange scheduled blocks CI Standards specify ramp start and ramp

stop times Uses a default ramp duration of zero for

reliability adjustments Uses separate straddled default ramps for

Western and Eastern Interconnection.

Page 23: e-Tag 1.8

e-Tag 1.8 Within e-Tag 1.8, a rounding standard was

added to be used in loss calculations. MW values in e-Tag profiles are sometimes integrated into MWh values across schedule intervals. e-Tag profiles that start or stop within schedule intervals may result in fractional MWh values being calculated. These MWh values must be rounded to the nearest whole MWh.

(< .50 down, >= .50 up).

Page 24: e-Tag 1.8

e-Tag 1.8

Improved Recovery Function Recovery is a mechanism that an

Agent or Approval Service can request updates from all Authority Services for any missed requests

Vendor displays may vary – user initiated recovery not always available

Page 25: e-Tag 1.8

e-Tag 1.8 Added SSL via HTTPS and client certificate

requirement based on NAESB PKI standard. The full implementation of this functionality is

dependent on implementation of the new Electric Industry Registry.

The e-Tag specification allows this functionality to be enabled at the discretion of each company without impacting any other company.

The initial rollout will encrypt data sent to the Authority services and allow for the encryption of data sent by all of the Authority services to any entity who has registered a secure URL (i.e. https rather than http).

Companies will need to work with their specific vendor as implementation requirements will vary.

Page 26: e-Tag 1.8

e-Tag 1.8

The Buy-At-Market capability was removed from 1.8 specifications.

Page 27: e-Tag 1.8

e-Tag 1.8 The Rollout Schedule Remote Interoperability Vendor Testing

with NERC/NAESB facilitation on August 7th, 8th, 13th, 15th, 20th, and 22th

August 29-30 JISWG meeting 9-5 and 9-noon – finalize tutorial in Vancouver, BC

Starting Sept. 7 through Nov. 2, 2007, User Training and Testing - industry participants and vendors may use this time to train their users and modify their back-office software, as necessary, for 1.8 changes

Page 28: e-Tag 1.8

e-Tag 1.8 The Rollout Schedule (con’t.) September 7, 11, and 25, 2007 Industry

Tutorial/Q&A/Information Sharing through three 2-hour conference calls/webcasts

September 19-20, 2007 IS meeting in Montreal

Oct 3-4, 2007 JISWG meeting in Houston Nov 5-9 Final Interoperability Testing

Page 29: e-Tag 1.8

e-Tag 1.8 The Rollout Schedule (con’t.) November 14-15, 2007 NERC IS

meeting in San Francisco November 15-16 JISWG meeting in

San Francisco December 4, 2007 e-Tag 1.8

Implementation December 19-20 JISWG meeting in

Houston

Page 30: e-Tag 1.8

Questions?

FIN