Comm OC IS

NORTH AMERICAN ELECTRIC RELIABILITY COUNCIL
Princeton Forrestal Village, 116-390 Village Boulevard, Princeton, New Jersey 08540-5731
Interconnected Operations Subcommittee Meeting

February 16, 2000 15 p.m.
February 17, 2000 8 a.m.5 p.m.
February 18, 2000 8 a.m.noon
DoubleTree Hotel Albuquerque
Albuquerque, New Mexico
AGENDA
February 16, 2000
eSCHEDULING MINI-WORKSHOP JOHN POPE, GORDON SCOTT
a) Participants Introductions
b) Workshop Agenda and Objectives
February 17, 2000
1.
Administrative Gordon Scott

a.
Introductions
b.
Arrangements
c.
Agenda
i)
d.
2.
Minutes of December 68, 1999 Meeting
Roster
Subcommittee Reorganization John Pope
Policy 3, Interchange
3.
Draft Policy 3, Version 3 for BOT Consideration
4.
PITF Findings John Pope
5.
Transaction Parking Gordon Scott

Phone 609-452-8060 v Fax 609-452-9550 v URL www.nerc.com
Interconnected Operations Subcommittee Agenda

February 1618, 2000
6.
Transaction Terminations
7.
Tagging Issues Ben Li

a.
Tag Submission Times for Market Redispatch Charles Yeung
b.
Tagging Across Interconnection Boundaries Jerry Hagge
c.
Use of Replace Option Jerry Hagge
8.
Public Comments on Appendix 3A1, 3A3, 3A4, and 3D
9.
WSCC Opinions regarding E-Tag Specification
10. Transaction Start Time Gordon Scott

11. Dynamic Schedules vs. Transfers
12. Request from Pat Connors on Tagging Network Transactions
Policy 2, Transmission
13. Policy 2, Transmission

a.
Add reference to calling TLRs to mitigate OSLs in Policy 2A
b.
OSL Violations
i)
OSL Report Form
ii)
IMO, February 2, 2000 Event
Other Items
14. Disturbance Analysis Working Group Report for Summer 1999

15. Review of Minority Opinions and Issues for Further Discussion
-2-
Electronic Scheduling
Discussion Outline for Mini-Workshop
February 16, 2000
Objective
Perform initial brainstorming to begin an industry-wide process of identifying information and functional
needs for electronic scheduling.
Background
The Federal Energy Regulatory Commission (FERC) originally envisioned electronic scheduling as part
of its Order No. 888 on Transmission Open Access. Development of industry-wide electronic scheduling
standards and tools was deferred until OASIS Phase II.
The industry has yet to agree on scheduling requirements. As a result, to obtain transmission service,
three separate processes exist: 1) transmission reservation using OASIS; 2) transfer of reliability
information through a NERC electronic tag (E-tag); and 3) interchange transaction scheduling through a
provider-designated system. Some providers use the NERC E-tag as a medium for an interchange
transaction request. A subset of these providers adds special requirements to the E-tag submittal in order
to meet their scheduling information needs.
The Market Interface Committee (MIC), recognizing the need to standardize electronic scheduling
requirements and to streamline transmission reservation and scheduling processes, made the following
resolution in November 1999:
The MIC recommends that as soon as practical, a process be developed to include
reliability information and scheduling information that the provider must accept, as
adopted on an Interconnection basis, in an interchange transaction request.
The purpose of this resolution was to encourage a merging of tagging and transaction scheduling
processes in a streamlined electronic process in order to reduce the burden of handling an interchange
transaction.
In a January 28, 2000 Order, the FERC further states:
[W]e encourage NERC to take steps to standardize the information for scheduling
required by different systems to the maximum extent practicable, and we urge NERC to
include this among its revisions to the E-tag system. We also encourage NERC to do so
in a manner, which includes all segments of the industry.1 These electronic scheduling
procedures would be used on an interim basis until the Commission considers scheduling
and other standards in the OASIS Phase II proceeding.
Based on recommendations from the OASIS How Working Group and the Transaction Information
System (TIS) Working Group, the MIC has requested the formation of a what group with balanced
representation to define the functional and information requirements for electronic scheduling. The
present mini-workshop, being held in conjunction with an Interconnected Operations Subcommittee
meeting in Albuquerque, New Mexico, is an interim step to get a jumpstart on electronic scheduling
ideas.
Of course, any such revisions should be submitted to the Commission for review.
Electronic Scheduling
Discussion Outline for Mini-Workshop
Discussion Questions
The discussion participants should progress as far as possible through these questions.
1. Who are the potential clients or users of electronic scheduling information?
2. For each client what are the processes that must be supported (i.e. control area scheduling,
Interchange Distribution Calculator input, transaction accounting and settlement, etc.)?
3. For each client what are the desirable features of an electronic scheduling process?
4. What information elements are needed to support each process? Which of these information elements
can be standardized on an industry-wide or Interconnection-wide basis? Which are unique to a region
or provider?
Expected Workshop Results

The workshop will brainstorm and capture as much information related to electronic scheduling as
possible. The session will not make decisions on the value of the information presented, nor will it focus
on consensus building for one process over another.
As the workshop lists items in answer to the Discussion Questions above, that information will be
further categorized as follows:
What scheduling items are - Basic, Common, Unique, Special, or Regional?
Issues List.
How should the information be communicated to the scheduling entity?
What are the barriers to implementation?
What strategies can help to overcome the barriers?
-2-
February 16, 2000

INTERCONNECTED OPERATIONS SUBCOMMITTEE MEETING

December 68, 1999
Embassy Suites Westshore
Tampa, Florida
MINUTES
A regular meeting of the Interconnected Operations Subcommittee was held on December 68,
1999 in Tampa, Florida. Subcommittee Chairman John Pope presided, and a quorum was present. The
meeting notice, agenda, and attendance list are affixed as Exhibits A, B, and C, respectively.
Minutes of Previous Meeting
The minutes of the September 2728, 1999 Interconnected Operations Subcommittee meeting
were approved by unanimous consent.
The Subcommittee reviewed the changes to Policy 3, Version 3, made by the Security Committee
at its November 1617, 1999 meeting. The Subcommittee discussed the issues for requiring active
approvals of Interchange Transactions, and decided it will continue working on this issue when it begins
developing the next version of Policy 3 in 2000. (Note from DMB: At its December 1617, 1999
meeting, the Security Committee reverted to the passive approval default found in Policy 3, Version 2.)
Response to Market Interface Committee Recommendations
The Subcommittee reviewed each of the recommendations from the Market Interface
Committees November 1718, 1999 meeting. The Subcommittees responses to each of the
recommendations is affixed as Exhibit D. These will be presented at the Security Committees
December 1617, 1999 adjourned meeting. As a result of the review of the MICs recommendations, the
Subcommittee drafted several Policy 3 changes as well as new Appendixes 3A1, 3A3, 3A4, and 3D.
These are all affixed as Exhibits E, F, G, H and I.
Tag Submission Timing Standards
The Subcommittee spent significant time discussing the Tag Submission Timing Requirements in
Appendix 3A1. The Market Interface Committee Executive Committee requested a change in tagging
definitions such that Interchange Transactions of one or more hours duration that would begin in the next
hour would be tagged at least 20 minutes before the start of the transaction. Several members of the
-1-
Draft: December 8, 1999
Interconnected Operations Subcommittee Meeting Minutes

December 68, 1999
Subcommittee expressed their concern that if an Interchange Transaction was to last two hours or longer,
the tag submission time would have to be extended beyond 20 minutes to perhaps 30 or 45 minutes.
Al DiCaprio then moved to document these issues and ask the Security Committee and Market
Interface Committee for their opinions. After discussion, the motion was approved with four in favor and
one opposed.
Policy 3 Status
The Subcommittee agreed that it would send Version 3 of Policy 3 along with Appendix 3A2,
Tagging Across Interconnection Boundaries to the Security Committee for final approval. Appendixes
3A1, Tag Submission Timetable, 3A3, Tag Failure Procedure, 3A4, Required Tag Data, and 3D,
Transaction Tag Actions will be sent to the Security Committee for interim implementation and posted
for public comment as part NERCs Procedure for Developing and Approving Standards.
E-tag Specification 1.5
Andy Rodriquez, chairman of the Transaction Information System Working Group, reviewed the
changes included in the implementation of E-tag Functional Spec 1.5. These include:
Replacement tag
Tag adjustments (instead of removal and resubmission of tag)
Tagging for market redispatch
Parties who receive the tag
Tag security mechanisms
Tagging Intra-Control Area Transactions

The Subcommittee reviewed a letter from Pat Connors requesting that intra-Control Area
transactions using network service be tagged. The Subcommittee did not resolve this issue, and it will be
discussed at the next Subcommittee meeting.
Approving Schedule Changes
The Subcommittee discussed Policy 3, Version 3, Section B.4.1.2, which states that Control
Areas shall operate such that interchange schedules or schedule changes do not knowingly cause other
systems to violate established operating reliability criteria. One can infer from this requirement that even
if an Interchange Schedule must be reduced due to a transaction termination, the schedule reduction could
not take place if it caused an Operating Security Limit Violation on another system. This led to the
question of who pays for the generation if the Control Areas do not agree to the reduction. The
Subcommittee agreed more discussion was needed and decided to defer this issue to its next meeting.
Definitions of Source and Sink
John Pope explained that the Board of Trustees Policy Interpretation Task Force report on the EnronTVA dispute indicated that the Interchange Transaction tag did not have to show the ultimate source
and sink. Some Subcommittee members believe that it is impossible to determine the true and ultimate
source and sink of any Interchange Transaction even if the source and sink Control Areas are identified
on the Interchange Transaction tag. The important issue is what generation actually changes in the
Interconnection when a transaction is implemented, terminated, or curtailed.
-2-
Interconnected Operations Subcommittee Meeting Minutes

December 68, 1999
Modifying Tags via the IDC

Andy Rodriquez discussed the request from the Transaction Information System Working Group
regarding automatic tag modifications via the Interchange Distribution Calculator upon curtailment. The
Subcommittee discussed this proposal but did not believe there was a need for the IDC to change the Etag. The IDC already adjusts its internal transaction database to reflect the curtailments.
Dynamic Schedules
John Beachman reported that he has been discussing a problem that Carroll Scheer has
experienced where some Control Areas require interchange accounting in whole megawatt increments.
Mr. Scheer had recommended to the Subcommittee that it replace the term Dynamic Scheduling with
the term Dynamic Transfer, which Mr. Scheer believes would clear up this problem.
The Subcommittee discussed the issue. It did not see anything in NERC policy that requires
interchange accounting in whole megawatt increments, nor do the Policies preclude accounting on a
kilowatt basis, and, therefore, the Subcommittee does not believe the suggested change offered by Mr.
Scheer will address this issue.
Relationship between Subgroups
John Pope led a discussion of the relationship between the TIS Working Group, Market Interface
Committee, Interconnected Operations Subcommittee, and other NERC technical groups. The
Subcommittee also discussed how the questions requested of the Market Interface Committee by the TIS
Working Group were handled. The Subcommittee generally agreed that the entire Subcommittee should
review formal requests before they are forwarded to other subcommittees or standing committees for
review. This will ensure that the entire Subcommittee has an opportunity to ask the questions that it feels
are pertinent to the issues at hand.
Meetings for 2000
The Interconnected Operations Subcommittee agreed to the following meeting schedule for 2000:
February 1618 Albuquerque, NM

April 1113 California ISO
June 68 PJM Interconnection office
August 810 Chicago, IL
October 1719 New England ISO (Hartford, CT)
December 57 Tampa, FL
Adjourn
There being no further business before the Subcommittee, the meeting was adjourned at 11:54
a.m. on December 8.
Donald M. Benjamin
Secretary
-3-
Exhibit A
X-POP3-Rcpt: barbara@euclid
X-Authentication-Warning: nerc1.nerc.com: majordomo set sender to
owner-iosubc@nerc.com using -f
X-Sender: barbara@206.231.20.22
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Tue, 26 Oct 1999 14:22:22 -0400
To: iosubc@nerc.com
From: Barbara Bogenrief <barbara@nerc.com>
Subject: IOSubcommittee December 6-8, 1999 Meeting Announcement
Cc: karenann@nerc.com
Sender: owner-iosubc@nerc.com
Dear Interconnected Operations Subcommittee members:
Here is the information for the December 6-8, 1999 IOS meeting:
Embassy Suites
555 North Westshore Blvd.
Tampa, FL 33609
Phone: 813-875-1555
Fax: 813-287-3664
The meeting schedule follows:
Monday, December 6, 1999:
Tuesday, December 7, 1999:
Wednesday, December, 8, 1999:
1 p.m.-5 p.m.
8 a.m.-5 p.m.
8 a.m.-noon
Rooms are blocked the nights of December 6-7, 1999 for the rate of $124
single/double occupancy. Check in time is 3 p.m. and check out is noon.
Cut-off date for sleeping rooms is November 22, 1999.
When making your hotel reservations, please make sure to mention NERC
so your reservation is credited to our room block. A penalty make be
charged to NERC if the total rooms blocked for this event are not
picked up. Please inform us immediately if you are unable to attend.
Also, if you are using an agency for your travel plans, make sure they
mention NERC.
The Embassy Suites is three miles from the Tampa International Airport.
To arrange a complimentary shuttle, call the hotel on the courtesy
phone located in baggage claim. A taxi costs about $7.
Please let me know if you have any questions. Thanks.
Barbara
Exhibit B

Interconnected Operations Subcommittee Meeting Agenda

December 6 (15 p.m.), 7 (8 a.m.5 p.m.), 8 (8 a.m.noon), 1999
Embassy Suites Westshore
Tampa, Florida
1.
2.
3.
Administration Don Benjamin

a.
Introductions
b.
Arrangements
c.
Agenda
d.
Minutes of September 2728, 1999 Meeting
e.
Roster
a.
Security Committee Revisions to Policy 3
b.
MIC Meeting Review
c.
Policy 3A2.1 Tagging intra-control area transactions using non-firm network service
d.
Policy 3A5 Active approval time notification
e.
Policy 3B4.1.2 Schedule changes that cause OSL violations
f.
Policy 3C Block accounting
g.
Definitions of Source and Sink
h.
Modifying tags from IDC (Data Flow letter from TISWG to SCS and
IOSubcommittee)
i.
Dynamic Transfers Carroll Scheer
Policy 2, Transmission
a.
b.
OSL Violation Form
4.
Review of Minority Opinions and Issues for Further Discussion
5.
Future Meetings
a.
b.
February 1618, 2000 Albuquerque

Set meeting schedule for remainder of 2000
Phone 609-452-8060 v Fax 609-452-9550 v URL www.nerc.com
Exhibit C
Interconnected Operations Subcommittee Meeting
Attendance
December 68, 1999
John Pope, Chairman
SERC
John Beachman
ECAR
Jim Byrd (for Sam Jones)
ERCOT
Ron Donahey
FRCC
Al DiCaprio (for Bruce Balmat)
MAAC
Paul Shortley
NPCC
Carl Monroe (for Scott Moore)
SPP
Don Lacen
WSCC
Spence Geber
WSCC
Charles Yeung
EPMI
Andy Rodriquez
TIS WG Chair
Gordon Scott
Don Benjamin
NERC
Summary of Market Interface Committee Action

Dealing with Interchange Transaction Issues
November 17 18, 1999
Exhibit D
Not necessarily in the order in which the MIC dealt with the issues.
Includes Responses from December 6 8, 1999 Interconnected Operations Subcommittee

meeting.
1.
Purpose of a tag. The MIC recognizes that today a tag is a document that contains reliability
information only, unless otherwise authorized by tariff.
a.
To clarify, the term reliability information is defined to mean only that information that
is required to support the IDC for the Eastern Interconnection, and any other security
system required by the Western or ERCOT Interconnections. This information includes
OASIS reference numbers.
Response:
Will develop an Appendix 3A4 to denote those tag elements that are used for transaction
assessment for Security Committee approval on December 16 17, 1999 on an interim basis.
2.
Need for standard tag/scheduling process. The MIC recommends that as soon as practical, a
process be developed to include reliability information and scheduling information that the
provider must accept, as adopted on an Interconnection basis, in an interchange transaction
request.
Response:
The Interconnected Operations Subcommittee plans to work on this as a project for 2000. The MIC
will be requested to provide assistance.
3.
Who gets the tag (East and ERCOT). Entities that are identified in a tag without approval rights
should be allowed to see only the information in a tag that is pertinent to their role in the
transaction, for transactions wholly within the Eastern and ERCOT Interconnections.
Response:
Will add Policy 3A2.2.1 to allow this limited tag information. This will apply only to the Eastern
Interconnection. In ERCOT, the tag information is provided to the ERCOT ISO, Source and Sink
Control Area, and the PSE requesting the transaction.
a.
(West). For all transactions that are wholly or partially within the Western
Interconnection, all PSEs that are identified on the tag shall be allowed to view the
information in that tag.
Response:
This is already accommodated in Policy 3A2.2. No change needed.

4.
Active and passive approval definitions. The MIC adopts the following definitions for active
and passive approval of NERC tags:
a.
Active Approval A portion of a tag is approved by an entity with approval rights on

that portion of the tag, only if that entity takes specific action to approve that portion of
the tag. The default condition for the tag is denied.
-1-
Summary of MIC Actions

b.
Passive Approval A portion of a tag is implicitly approved when an entity with

approval rights for that portion of the tag takes no action to approve that portion of the
tag within a specific time period. The default condition for the tag is approved.
Response:
The Interconnected Operations Subcommittee understands that these are definitions to help the
MIC frame its discussions. No Policy change is required. The Security Committee added the
passive approval default at its November 16 17, 1999 meeting.
5.
Who has passive approval rights. All control areas and transmission providers that are party to
an interchange transaction shall have passive approval rights for the tag.
Response:
Already addressed in Policy 3A5.

6.
Reason must accompany denial. The MIC resolves that a denial of a tag must include a reason
for denial and the denial must be provided in a timely manner.
Response:
Appendix 3A1 specifies tag response times for both approvals and denials. Policy 3A5.1 already
requires reasons for denied transactions.
7.
Entities without approval rights. The MIC resolves that generator and load serving PSEs, the
source and sink, and all other PSE entities party to a transaction do not have approval rights for a
tag.
Response:
New Appendix 3D covers which entities are responsible for approving Interchange Transactions.
8.
Permissible use of CANCEL. The MIC resolves that a tag approval authority shall only be able
to use CANCEL as a result of a curtailment event.
Response:
SCS Issues. SCS is

working on these.
New Appendix 3D will address this.

9.
MRD Pilot report and extension. By December 1, 1999, the MIC will file with
FERC the final report on the MRD pilot. The MIC will request the Commission
to extend the pilot MRD process through the summer of 2000, subject to
modifications that will be filed with the Commission by April 2000.
10.
SCS proposals. The MIC requests the SCS to work with the CMWG to
integrate the four SCS proposals presented today into consideration for the
CMWG TLR 2000 effort and requests the CMWG bring recommendations back
to MIC at the January 2000 MIC meeting.
-2-

11.
12.
Additional TLR issues. The MIC supports the CMWG working in concert with the SCS to
develop specific revisions to Operating Policy 9 TLR Procedures and uniform practices for
implementing TLR that address at least:
a.
Definition of new transaction and hold (Note: The Security Committee expects a
definition by December 1, 1999. dmb)
b.
An effective and fair process for reallocation and reordering transactions
c.
Process refinements, including technology solutions and automation, transaction

management methods (e.g. LIFO vs. partial curtailments vs. Pyramid method, etc.), and
communications.
d.
CMWG recommendations are to be presented at the January 2000 MIC meeting for
endorsement by the MIC.
OASIS. The MIC endorses the proposed changes to the S&CP, as presented today, for filing with
FERC by December 31, 1999. The MIC will work with the How WG to modify the OASIS
Business Practices to reflect standards for changes to reservations.
-3-

13.
Appendix 3A1 Tag Submission Timetable.
Appendix 3A1
Modifications to the wording in the left column would help clarify the limits and also
alleviate some of the concerns of marketers:
Existing Wording
Next Hour Hourly
Hourly/Daily Same Day
Hourly/Daily Next Day
New Wording
Hourly/multi-hour starting less than 60 minutes in the future
Hourly (both single hour and multi-hour)/Daily (starting 60
minutes or more, but less than 24 hours, in the future)
Hourly (both single hour and multi-hour)/Daily (starting 24
hours or further into the future)
The MIC agreed to allow Mr. Moore, Mr. Yeung, and Ms. Vollmer to complete the editing of the timing
table. The MIC defers to the MIC Executive Committee to approve the revisions prior to the next
meeting of the Interconnected Operations Subcommittee on December 6, consistent with the discussions
at this meeting.
-4-
Policy 3 Interchange
Version 3, Draft 5b
As revised by Security Committee, November 17, 1999
As revised by Interconnected Operations Subcommittee, Dec 6 8,
1999
Policy Subsections
A.
B.
C.
D.
E.
Interchange Transaction Implementation

Interchange Schedule Implementation
Interchange Schedule Standards
Interchange Transaction Cancellation, Termination, and Curtailment
Transfer Capability
Definitions will be moved to Terms section of Operating Manual

Control Area. An electrical system bounded by interconnection (tie-line)
metering and telemetry. It controls generation directly to maintain its
INTERCHANGE SCHEDULE with other CONTROL AREAS and contributes
to frequency regulation of the INTERCONNECTION.
Adjacent Control Areas. Two CONTROL AREAS that are interconnected:
Directly to each other, or
Via a multi-party agreement or transmission tariff. (Examples include Independent System

Operator and Power Pool agreements.)
Dynamic Schedule. A telemetered reading or value which is updated in real time and which is used as a
schedule in the AGC/ACE equation and the integrated value of which is treated as a schedule for
interchange accounting purposes. Commonly used for scheduling jointly owned generation to or
from another control area.
Overlap Regulation Service. A method of providing regulation service in which the control area
providing the regulation service incorporates all of the other control areas tie lines, frequency
response, and schedules into its own AGC/ACE equation.
Su Tw (respons33lation Service) Tj 127.44 -251D /F3 11.04 Tf -0.1418 Tc 0.2718 Tw (. A method of providing re
Version 3
P31
Draft 5b: December 8, 1999
Intermediary Control Area. A CONTROL AREA on the SCHEDULING PATH between the SOURCE
CONTROL AREA and SINK CONTROL AREA.
Interchange. Energy transfers that cross CONTROL AREA boundaries.
Total Actual Interchange. The algebraic sum of all INTERCHANGE metered with all PHYSICALLY
ADJACENT CONTROL AREAS. It is, in essence, the actual interchange with the Interconnection.
Actual Interchange. The metered interchange over a specific INTERCONNECTION between two
PHYSICALLY ADJACENT CONTROL AREAS.
Net Actual Interchange. The algebraic sum of all metered interchange over all INTERCONNECTIONS
between two PHYSICALLY ADJACENT CONTROL AREAS.
Transaction. An agreement arranged by a PURCHASING-SELLING ENTITY to transfer energy from seller
to a buyer.
Interchange Transaction. A TRANSACTION that crosses one or more Control Area boundaries.
Interchange Transaction Curtailment: The complete or partial interruption of an INTERCHANGE
TRANSACTION that has started or holding of a new INTERCHANGE TRANSACTION that has not
yet started by a TRANSMISSION PROVIDER, SECURITY COORDINATOR, or CONTROL AREA to
maintain operating security.
Interchange Transaction Cancellation. The complete withdrawal of an INTERCHANGE TRANSACTION by
a PURCHASING-SELLING ENTITY prior to the start time of the TRANSACTION.
Interchange Transaction Termination. The complete interruption of an INTERCHANGE TRANSACTION by
a PURCHASING-SELLING ENTITY after the start time of the TRANSACTION.
Interchange Schedule. The planned INTERCHANGE between two ADJACENT CONTROL AREAS that results
from the implementation of one or more INTERCHANGE TRANSACTION(S).
Inadvertent Interchange. The difference between the control areas NET ACTUAL INTERCHANGE and
NET SCHEDULED INTERCHANGE.
Net Interchange Schedule (or Net Schedule). The algebraic sum of all INTERCHANGE SCHEDULES with
each ADJACENT CONTROL AREA.
Scheduled Total Interchange. The net of all INTERCHANGE SCHEDULES with all ADJACENT CONTROL
AREAS. It is, in essence, the scheduled interchange with the INTERCONNECTION.
Purchasing-Selling Entity (PSE). An entity that is eligible to purchase or sell energy or capacity and
reserve transmission services.
Scheduling Path. The Transmission Service arrangements reserved by the PURCHASING-SELLING ENTITY
for a TRANSACTION.
Security Coordinator. An entity that provides the security assessment and emergency operations
coordination for a group of control areas. Security Coordinators must not participate in the
wholesale or retail merchant functions.
Transmission Provider. As defined by FERC, the public utility (or its Designated Agent) that owns,
controls, or operates facilities used for the transmission of electric energy in interstate commerce
and provides transmission service under the Tariff. As used in the NERC Policies: Any entity that
provides Transmission Service.
Version 3
P32
Transmission Service. (FERC-defined term). Point-To-Point Transmission Service provided under Part
II of the Tariff on a firm and non-firm basis.
Version 3
P33
Introduction
1.
Overview
Overview
1
PSE Develops
Tag
This Policy addresses the following issues:
Responsibilities of all PURCHASING-SELLING ENTITIES

involved in INTERCHANGE TRANSACTIONS. 1
Information requirements for INTERCHANGE TRANSACTIONS.
Requirements of CONTROL AREAS to assess and confirm

INTERCHANGE TRANSACTIONS.
Accountability of CONTROL AREAS for implementing all

INTERCHANGE SCHEDULES in a manner that ensures the
reliability of the INTERCONNECTIONS.
2.
Standards for INTERCHANGE SCHEDULES between CONTROL

AREAS.
The Relationship between Interchange Transactions and

Interchange Schedules
2
Tag to Sink
Control Area
Submit
3
Transaction
Implementation
Request
Assess
4
Tag to Control Areas,
Trans Providers
5
Transaction
Approval
E-tag
Concepts
Approve
6
Schedule
Implementation
Request
Implement
7
Tag to Adjacent
Control Areas
Schedule
Policy 3.A. explains the process for arranging and implementing

8
Confirmation
INTERCHANGE TRANSACTIONS. Policy 3.B. explains the procedures for
assessing and confirming INTERCHANGE TRANSACTIONS and implementing
9
Control Area
INTERCHANGE SCHEDULES. The flowchart on the right explains the process
enters into EMS
by which INTERCHANGE TRANSACTIONS become INTERCHANGE SCHEDULES.
Some of these functions are handled by the tagging system used in the INTERCONNECTION. Refer to the Etag Reference Document and the ERCOT Tagging Reference Document for further details.
PURCHASING-SELLING ENTITIES arrange INTERCHANGE TRANSACTIONS that is, they buy or sell
energy and capacity and record the transaction by forwarding the required data via an INTERCHANGE
TRANSACTION tag to the appropriate CONTROL AREA(S).
1
This Policy deals predominately with INTERCHANGE TRANSACTIONS, that is, those that cross one or more
CONTROL AREA boundaries. The more general term TRANSACTION includes INTERCHANGE TRANSACTIONS and
TRANSACTIONS that are entirely within a CONTROL AREA. At this time, the only reference to the general term
TRANSACTION is the tagging requirement in Requirement 3.A.2.1.
Version 3
P34
CONTROL AREAS assess and approve or deny INTERCHANGE TRANSACTIONS based on reliability
criteria and arrangements for INTERCONNECTED OPERATIONS SERVICES and transmission rights.
Transmission Providers assess the impact of providing the requested transmission service when the service
is approved. To implement the INTERCHANGE TRANSACTION, all affected CONTROL AREAS incorporate
the INTERCHANGE TRANSACTION into their INTERCHANGE SCHEDULES as explained on the following
pages.
In this example, there are three INTERCHANGE TRANSACTIONS, IT1, IT2, and IT3, that result in a number
of INTERCHANGE SCHEDULES between CONTROL AREAS A, B, C, and D. (Refer to the
figure on the right and table below. For simplicity, we are ignoring losses.)
A
Interchange Transaction 1 (IT1)
CONTROL AREA A is the SOURCE CONTROL AREA for INTERCHANGE TRANSACTION 1
(IT1) and CONTROL AREA B is the SINK CONTROL AREA. To make IT1 occur, CONTROL
AREA A implements an INTERCHANGE SCHEDULE with CONTROL AREA B (SAB-IT1). In this
case, the SOURCE CONTROL AREA A is the SENDING CONTROL AREA, and the SINK
CONTROL AREA B is the RECEIVING CONTROL AREA.
CONTROL AREA A is also the SOURCE CONTROL AREA for INTERCHANGE TRANSACTION
2 (IT2). CONTROL AREA D is the SINK CONTROL AREA for this INTERCHANGE
TRANSACTION. B and C are INTERMEDIARY CONTROL AREAS. The resulting
INTERCHANGE SCHEDULES are from SENDING CONTROL AREA A to RECEIVING
CONTROL AREA B (SAB-IT2), SENDING CONTROL AREA B to RECEIVING CONTROL AREA C
(SBC-IT2), and SENDING CONTROL AREA C to RECEIVING CONTROL AREA D (SCD-IT2).
SAB
IT1
IT2
B
SBC
IT3
C
SCD

CONTROL AREA C is the SOURCE CONTROL AREA for INTERCHANGE TRANSACTION 3 (IT3) and
CONTROL AREA A is the SINK CONTROL AREA. B is the INTERMEDIARY CONTROL AREA. To make IT3
occur, SENDING CONTROL AREA C implements an INTERCHANGE SCHEDULE with RECEIVING CONTROL
AREA B (SCB-IT3) and SENDING CONTROL AREA B to RECEIVING CONTROL AREA A (SBA-IT3).
Net Schedules
CONTROL AREAS A and B can calculate a NET INTERCHANGE SCHEDULE between these two CONTROL
AREAS by adding SAB-IT1 and SAB-IT2 and SBA-IT3. Control Areas B and C can calculate a NET INTERCHANGE
SCHEDULE between these two CONTROL AREAS by adding SBC-IT2 and SCB-IT3.
The NET SCHEDULED INTERCHANGE for A is SAB-IT1 + SAB-IT2 + SBA-IT3, The NET SCHEDULED
INTERCHANGE for B is SAB-IT1 + SAB-IT2 + SBA-IT3 + SBC-IT2 + SCB-IT3.
Relationship Between Control Areas, Interchange Schedules, and Interchange Transactions
Control
Area
Sink
Control
Area for:
Source
Control
Area for:
IT3
IT1, IT2
IT1
Sending
Control Area
for:
Receiving
Control Area for:
Net Interchange
Schedules
IT1, IT2
IT3
SAB-IT1 + SAB-IT2 + SBA-IT3
IT2, IT3
IT1, IT2, IT3

SBC-IT2 + SCB-IT3
C
D
Version 3
IT3
IT2, IT3
IT2
P35
IT2
SBC-IT2 + SCB-IT3
SCD-IT2
IT2
SCD-IT2
Match
Match
Match
3.
Interchange Schedules within a Multi-Party Regional Agreement or Transmission

Tariff
If CONTROL AREAS A, B, C, and D are parties to a transmission agreement or tariff, such as a Regional
agreement or ISO, then there is no need for the INTERCHANGE SCHEDULES from B to C or C to D as in the
previous example. In this case, all four CONTROL AREAS are considered ADJACENT CONTROL AREAS and
can schedule directly with each other.
Interchange Transaction 1
CONTROL AREA A is the SOURCE CONTROL AREA for INTERCHANGE TRANSACTION
1 (IT1) and CONTROL AREA B is the SINK CONTROL AREA. To make IT1 occur,
CONTROL AREA A implements an INTERCHANGE SCHEDULE with CONTROL AREA
B (SAB-IT1). In this case, the SOURCE CONTROL AREA A is the SENDING CONTROL
AREA, and the SINK CONTROL AREA B is the RECEIVING CONTROL AREA and these
two control areas are adjacent to each other.
A
SAB = IT1
SAD = IT2
B
SCA = IT3
CONTROL AREA A is also the SOURCE CONTROL AREA for INTERCHANGE
TRANSACTION 2 (IT2). CONTROL AREA D is the SINK CONTROL AREA for this
INTERCHANGE TRANSACTION. The resulting INTERCHANGE SCHEDULE is directly from
SOURCE (SENDING) CONTROL AREA A to SINK (RECEIVING) CONTROL AREA D (SAD-IT2).
CONTROL AREA C is the SOURCE (SENDING) CONTROL AREA for INTERCHANGE TRANSACTION 3 (IT3)
and CONTROL AREA A is the SINK (RECEIVING) CONTROL AREA. To make IT3 occur, SENDING CONTROL
AREA C implements an INTERCHANGE SCHEDULE directly with SINK (RECEIVING) CONTROL AREA A
(SCA-IT3).
Net Schedules
There are only three NET INTERCHANGE SCHEDULES:
SAB = IT1, SAD = IT2, and SCA = IT3
The NET SCHEDULED INTERCHANGE for A is SAB-IT1 + SCA-IT3 + SAD-IT2. For B is SAB-IT1. For C is SCA-IT3, For
D is SAD-IT2.
Relationship between Control Areas, Interchange Schedules, and Interchange Transactions
Control
Area
Sink
Control
Area for:
Source
Control
Area for:
IT3
IT1, IT2
B
C
D
IT1
Version 3
Sending
Control Area
for:
IT1, IT2
Receiving
Control Area for:
IT3
IT1
IT3
IT3
IT2
IT2
P36
SAB-IT1
SCA-IT3
SAD-IT2
SAB-IT1
SCA-IT3
SAD-IT2
Match
Match
Match
4.
Confirming Interchange Schedules
Interchange Schedules are confirmed between Adjacent Control
Areas. The RECEIVING CONTROL AREAS are responsible for
initiating contact with the SENDING CONTROL AREAS; however, it is
also permissible for the SENDING CONTROL AREA to initiate contact
with the RECEIVING CONTROL AREA.
Sending/Source
Control
C
Schedule
Receiving/Sending
Intermediary
B
The diagram on the right shows the confirmation path.
D
Curtailing, Canceling, or Terminating Interchange
C
Receiving/Sink
Transactions
Control
Curtailing Interchange Transactions
Notifying the Sink Control Area. When a CONTROL AREA or TRANSMISSION PROVIDER must curtail an
INTERCHANGE TRANSACTION, it begins the process by contacting its SECURITY COORDINATOR and the
SINK CONTROL AREA. When a SECURITY COORDINATOR curtails an INTERCHANGE TRANSACTION, it
contacts all other SECURITY COORDINATORS. Then the SECURITY COORDINATOR of the SINK CONTROL
AREA notifies that CONTROL AREA of the curtailment.
TC
I
Interchange
Curtailment,
5.
Notifying other entities. Once the SINK CONTROL

AREA has been notified, it contacts the SOURCE
CONTROL AREA directly, confirms the curtailment and
the resulting change in their INTERCHANGE
SCHEDULES. The SINK CONTROL AREA then contacts
the INTERMEDIARY CONTROL AREAS and
TRANSMISSION PROVIDERS on the SCHEDULING PATH
as well as the PURCHASING-SELLING ENTITY who
submitted the tag (this is accomplished via the tagging
system). Following this notification, if the SOURCE
CONTROL AREA and SINK CONTROL AREA are not
adjacent, they begin implementing the INTERCHANGE
SCHEDULE adjustments with their ADJACENT
CONTROL AREAS.
Cancellation, or
Termination Confirmation
Source
S
C
Control
Area
A
Direct Sink-to-Source
Control Area Confirmation of Curtailment
B
Confirmation with
Adjacent Control Areas
on Schedule Path
Sink
S
C
Control
Area
C
Curtailment
request
Cancellation or
Termination request
Purchasing-Selling
Entity
Control Area,
Transmission Provider,
or Security Coordinator
Canceling or Terminating Interchange Transactions

When a PURCHASING-SELLING ENTITY must cancel an INTERCHANGE TRANSACTION before it begins, or
A
REA to
INTERCHANGE
which
it submitted
TRANSACTION
the the tag.
The SINK-S
CELLING
ONTROLEA
REA shall
terminates
one that
is in
progress,
PURCHASING
NTITY
shallthen
contact the SINK CONTROL
ITY
contact
COORDINATOR
its
, all CONTROL AREAS, and TRANSMISSION PROVIDERS on the
RCHANGE TRANSACTIONSection
curtailment
3D, are
Interchange
found in
Policy 9, Security Coordinator Procedures.
Version 3
P37
A.
[Policy 2A, TransmissionTransmission Operations]

[Appendix 3A1, Tag Submission and Response Timetables]
[Appendix 3A2, Tagging Across Interconnection Boundaries]
[E-tag Reference Document]
[Transaction Tagging Process within ERCOT Reference Document]
[Tagging Instruction Reference Document]
Security Committee
Change
Introduction
This section specifies the PURCHASING-SELLING ENTITYS requirements for
tagging all INTERCHANGE TRANSACTIONS, and the CONTROL AREAS obligations
for accepting the tags and implementing the INTERCHANGE TRANSACTIONS. The
tag data is integral for providing the CONTROL AREAS, SECURITY
COORDINATORS, and other operating entities the information they need to assess,
confirm, approve or deny, implement, and curtail INTERCHANGE TRANSACTIONS
as necessary to accommodate the marketplace and ensure the operational security
of the INTERCONNECTION.
This document has not

been prepared.
Requirements
1.
INTERCHANGE TRANSACTION arrangements. The PURCHASINGSELLING ENTITY shall arrange for all Transmission Services,
INTERCONNECTED OPERATIONS SERVICES, tagging, and personnel to
contact for each INTERCHANGE TRANSACTION to which it is a party.
1.1.
Transmission services. The PURCHASING-SELLING ENTITY shall

arrange the Transmission Services necessary for the receipt,
transfer, and delivery of the TRANSACTION.
1.2.
Interconnected Operations Services. The PURCHASINGSELLING ENTITY shall provide or arrange for all associated
INTERCONNECTED OPERATIONS SERVICES.
1.3.
Time Zone standard. All electronic INTERCHANGE

TRANSACTIONS communications shall be communicated, both
verbally and electronically, in Central Standard Time. (Daylight
saving time will not be used.)
1.4.
Tagging. The PURCHASING-SELLING ENTITY serving the load

shall be responsible for providing the INTERCHANGE
TRANSACTION tag. (NOTE: 1) Any PSE may provide the tag;
however, the load-serving PSE is responsible for ensuring that a
single tag is provided. 2) If a PSE is not involved in the
TRANSACTION, such as delivery from a jointly-owned generator,
then the SINK CONTROL AREA is responsible for providing the
tag. PSEs must provide tags for all Interchange Transactions in
accordance with Requirement 2.
1.5.
Contact personnel. Each PURCHASING-SELLING ENTITY with

title to an INTERCHANGE TRANSACTION must have, or arrange to
have, personnel directly and immediately available for notification
of INTERCHANGE TRANSACTION changes. These personnel shall
be available from the time that title to the INTERCHANGE
Version 3
P38
Security Committee
Change
Security Committee did
not agree that a time
zone standard was
needed for verbal
communications
A. Interchange Transactions
TRANSACTION is acquired until the INTERCHANGE TRANSACTION

has been completed.
2.
INTERCHANGE TRANSACTION tagging. Each INTERCHANGE

TRANSACTION shall be tagged before implementation as required by each
INTERCONNECTION as specified in the E-tag Reference Document, or
Transaction Tagging Process within ERCOT Reference Document.
In addition to providing necessary operating information, the
INTERCHANGE TRANSACTION tag is the official request from the
PURCHASING-SELLING ENTITY to the CONTROL AREAS to implement the
INTERCHANGE TRANSACTION. The information that must be provided on
the tag is listed in Appendix 3A4.
2.1.
2.2.
Added new Appendix

3A4 to list required
tag data.
Application to TRANSACTIONS. All INTERCHANGE

TRANSACTIONS and certain INTERCHANGE SCHEDULES shall be
tagged. In addition, intra-Control Area transfers using Point-toPoint Transmission Service2 shall be tagged. This includes:
INTERCHANGE TRANSACTIONS (those that are between

CONTROL AREAS.)
TRANSACTIONS that are entirely within a CONTROL AREA.
DYNAMIC INTERCHANGE SCHEDULES (tagged at the expected

average MW profile for each hour.) (Note: a change in the
hourly energy profile of 25% or more requires a revised tag.)
INTERCHANGE TRANSACTIONS for bilateral INADVERTENT

INTERCHANGE payback (tagged by the Sink Control Area.)
INTERCHANGE TRANSACTIONS established to replace

unexpected generation loss, such as through prearranged
reserve sharing agreements or other arrangements, are exempt
from tagging for 60 minutes from the time at which the
INTERCHANGE TRANSACTION begins. (tagged by the Sink
Control Area). [See also, Policy 1E2 and 2.1, Disturbance
Control Standard]
Parties to whom the complete tag is provided. In the EASTERN

INTERCONNECTION, the tag shall be provided to the CONTROL
AREAS and TRANSMISSION PROVIDERS on the SCHEDULING
PATH. In the WESTERN INTERCONNECTION, the tag shall be
provided to the CONTROL AREAS and Transmission Providers on
the SCHEDULING PATH as well as the PURCHASING-SELLING
ENTITIES who are parties to the INTERCHANGE TRANSACTION.
Interconnected
Operations
Subcommittee Change
To addres MIC
Recommendation #3:
Entities allowed to see
tag information.
2.2.1. Parties to whom limited tag information is provided.

In the EASTERN INTERCONNECTION, tag information that
is pertinent to their role in the INTERCHANGE
TRANSACTION shall be provided to the source
PURCHASING-SELLING ENTITY, the LOAD-SERVING
2
This includes all grandfathered and other non-888 Point-to-Point Transmission

Service
Version 3
P39
ENTITY, and other PURCHASING-SELLING ENTITIES with

transmission reservations.
2.3.
Method of transmitting the tag. The PURCHASING-SELLING

ENTITY shall submit the Interchange Transaction tag in the
format established by each INTERCONNECTION. [E-Tag
Reference Document or Transaction Tagging Process
within ERCOT Reference Document]
2.3.1. Tags for Interchange Transactions that cross
Interconnection boundaries. Procedures are found in
Appendix 3A2, Tagging Across Interconnection
Boundaries.
2.4.
INTERCHANGE TRANSACTION submission time. To provide

adequate time for INTERCHANGE SCHEDULE implementation,
INTERCHANGE TRANSACTIONS shall be submitted as specified in
Appendix 3A1, Tag Submission and Response Timetable.
Security Committee
Change
Security Committee
agreed to implement
Appendix 3A2 on Dec
1, 1999
2.4.1. Exception for security reasons. Exception to the

submission time requirements in Section 2.4 is allowed if
immediate changes to the INTERCHANGE TRANSACTIONS
are required to mitigate an OPERATING SECURITY LIMIT
violation. The tag may be submitted after the emergency
TRANSACTION has been implemented but no later than 60
minutes.
2.5.
Confirmation of tag receipt. Confirmation of tag receipt shall

be provided to the PURCHASING-SELLING ENTITY who submitted
the tag in accordance with INTERCONNECTION tagging practices.
[E-Tag Reference Document]
2.6.
Tag acceptance. An INTERCHANGE TRANSACTION tag shall be

accepted if all required information is valid and provided in
accordance with the tagging specifications in Requirement 2
3.
INTERCHANGE TRANSACTION tag receipt verification. The SINK

CONTROL AREA shall verify the receipt of each INTERCHANGE
TRANSACTION tag with the TRANSMISSION PROVIDERS, and CONTROL
AREAS on the SCHEDULING PATH before the INTERCHANGE
TRANSACTION is implemented.
4.
INTERCHANGE TRANSACTION assessment. Transmission Providers,

CONTROL AREAS on the SCHEDULING PATH, and other operating entities
responsible for operational security shall be responsible for assessing and
approving or denying INTERCHANGE TRANSACTIONS on behalf of
PURCHASING-SELLING ENTITIES, based on established reliability criteria
and adequacy of INTERCONNECTED OPERATIONS SERVICES and
transmission rights as well as the reasonableness of the INTERCHANGE
TRANSACTION tag. This assessment shall include the following:
The CONTROL AREA Assesses:
Transaction start and end time
Energy profile (ability of generation maneuverability to
accommodate)
Version 3
P310
NERC expects that the

Control Areas and
Transmission Providers to
have the proper tools to
perform these
assessments. Lack of these
tools is not a reason to
deny an Interchange
Transaction.
Scheduling Path (proper connectivity of ADJACENT CONTROL

AREAS)
The TRANSMISSION PROVIDER Assesses:

Valid OASIS reservation number or transmission contract
identifier
Proper transmission priority
Energy profile accommodation (does energy profile fit OASIS
reservation?)
OASIS reservation accommodation of all Interchange
Transactions
Loss accounting
4.1.
5.
Tag Corrections. During the CONTROL AREAS and

TRANSMISSION PROVIDERS Assessment Time, the PURCHASINGSELLING ENTITY who submitted the tag may elect to submit a tag
correction. Tag corrections are changes to an existing tag that do
not affect the reliability impacts of the INTERCHANGE
TRANSACTION; therefore, tag corrections do not require the
complete re-assessment of the tag by all CONTROL AREAS and
TRANSMISSION PROVIDERS on the SCHEDULING PATH, or the
completion and submission of a new tag by the PURCHASINGSELLING ENTITY. The SINK CONTROL AREA shall notify all
CONTROL AREAS and TRANSMISSION PROVIDERS on the
SCHEDULING PATH of the correction, and specifically alert those
entities for which a correction has impact. Although the correction
does not itself change the approval decision of the affected party,
it does allow for that party to make a change in decision based on
the supplied correction. Tag items that may be corrected are
found in Appendix 3A4, Required Tag Data. A description of
those entities who may correct an INTERCHANGE TRANSACTION
tag is found in Appendix 3D, Transaction Tag Actions.
INTERCHANGE TRANSACTION approval or denial. Each CONTROL

AREA or TRANSMISSION PROVIDER on the SCHEDULING PATH
responsible for assessing and approving or denying the INTERCHANGE
TRANSACTION shall notify the SINK CONTROL AREA. The SINK CONTROL
AREA in turn notifies the PURCHASING-SELLING ENTITY who submitted
the INTERCHANGE TRANSACTION tag, plus all other CONTROL AREAS and
TRANSMISSION PROVIDERS on the SCHEDULING PATH. Assessment
timing requirements are found in Appendix 3A1, Tag Submission and
Response Timetable. A description of those entities who may approve
or deny an INTERCHANGE TRANSACTION is found in Appendix 3D,
Transaction Tag Actions.
5.1.
Version 3
Interconnected Operations
Subcommittee Change
Needed to allow a PSE to
make minor corrections to
the tag without a
resubmittal. Policy change
needed to implement in the
E-tag Spec v1.5 This
addresses issues raised by
the MIC related to the use
of Cancellation and Denial
by the Transmission
Providers.
Note addition of new
Appendixes 3A4 and 3D.
Added reference to
Appendix 3A1 to address
time requirements for
assessing Interchange
Transactions.
INTERCHANGE TRANSACTION denial. If denied, this notification

shall include the reason for the denial.
P311
5.2.
6.
INTERCHANGE TRANSACTION approval. The Interchange

Transaction is considered approved if the PURCHASING-SELLING
ENTITY who submitted the INTERCHANGE TRANSACTION tag has
received confirmation of tag receipt and has not been notified that
the transaction is denied.
Responsibility for INTERCHANGE TRANSACTION implementation. The

SINK CONTROL AREA is responsible for initiating the implementation of
each INTERCHANGE TRANSACTION as tagged in accordance with Policy
3.A. Requirement 2 (and its subparts). The INTERCHANGE TRANSACTION
is incorporated into the INTERCHANGE SCHEDULE(S) of all CONTROL
AREAS on the SCHEDULING PATH in accordance with Policy 3B.
6.1.
IOSubcommittee
suggests
removing
Tag requirements for Interchange Transaction

implementation. The CONTROL AREA shall implement only those
INTERCHANGE TRANSACTIONS that:
Have been tagged in accordance with

Requirement 2 above, or,
Are exempt from tagging in accordance with

Requirement 2.1 above.
7.
Interchange Transaction Termination. The
PURCHASING-SELLING ENTITY must provide at least 30 minutes
notification before an INTERCHANGE TRANSACTION TERMINATION is to
take place.
8.
9.
Tag requirements after Curtailment has ended. Following After the

CURTAILMENT of a TRANSACTION has ended, the INTERCHANGE
TRANSACTIONS energy profile will remain at its curtailed value until:
The INTERCHANGE TRANSACTION expires, or
The INTERCHANGE TRANSACTION crosses midnight, at which time its

energy profile automatically returns to its original value, or
The PURCHASING-SELLING ENTITY submits a new or revised tag.
Security Committee
Change
The Security Committee
decided to retain passive
approval, and reverted to
the wording in present
version of Policy 3.
For information only.

Requirement 7 will not be
effective until further
consideration by the
IOSubcommittee and
Market Interface
Committee followed by
NERCs formal Standards
approval process.
Change recommended by
NERC staff and
Subcommittee.
Confidentiality of information. SECURITY COORDINATORS, CONTROL

AREAS, TRANSMISSION PROVIDERS, and entities serving as tag agents or
service providers as provided in the E-tag Reference Document shall
not disclose INTERCHANGE TRANSACTION information to any
PURCHASING-SELLING ENTITY without the permission of the
PURCHASING-SELLING ENTITY who submitted the tag.
Version 3
P312
B.
Introduction
This section explains CONTROL AREA requirements for implementing the
INTERCHANGE SCHEDULES that result from the INTERCHANGE TRANSACTIONS
tagged by the PURCHASING-SELLING ENTITIES in Section A. Many of these
functions are performed automatically as part of the Tagging system.
Requirements
1.
CONTROL AREAS must be adjacent. INTERCHANGE SCHEDULES shall

only be implemented between ADJACENT CONTROL AREAS.
2.
Sharing INTERCHANGE SCHEDULES details. The SENDING CONTROL

AREA and RECEIVING CONTROL AREA must provide the details of their
INTERCHANGE SCHEDULES via the Interregional Security Network as
specified in Policy 4.B.
3.
Providing tags for Approved Transactions to the Security

Coordinator. The SINK CONTROL AREA shall provide its SECURITY
COORDINATOR the information from the INTERCHANGE TRANSACTION
tag electronically for each Approved INTERCHANGE TRANSACTION.
4.
INTERCHANGE SCHEDULE confirmation and implementation. The

RECEIVING CONTROL AREA is responsible for initiating the
CONFIRMATION and IMPLEMENTATION of the INTERCHANGE SCHEDULE
with the SENDING CONTROL AREA.
4.1.
INTERCHANGE SCHEDULE agreement. The SENDING CONTROL

AREA and RECEIVING CONTROL AREA shall agree with each
other on the:
Interchange Schedule start and end time
Ramp start time and rate
Energy profile
This agreement shall be made before either the SENDING

CONTROL AREA or RECEIVING CONTROL AREA makes any
generation changes to implement the INTERCHANGE SCHEDULE.
4.1.1. INTERCHANGE SCHEDULE standards. The SENDING
CONTROL AREA and RECEIVING CONTROL AREA shall
comply with the INTERCHANGE SCHEDULE Standards in
Policy 3C, Interchange Schedule Standards.
4.1.2. Operating Reliability Criteria. CONTROL AREAS shall
operate such that INTERCHANGE SCHEDULES or schedule
changes do not knowingly cause any other systems to
violate established operating reliability criteria.
Version 3
P313
B. Interchange Schedules
4.1.3. DC tie operator. SENDING CONTROL AREAS and

RECEIVING CONTROL AREAS shall coordinate with any
dc tie operators on the SCHEDULING PATH.
Version 3
P314
C.
Introduction
All CONTROL AREAS must account for their

INTERCHANGE SCHEDULES the same way to enable
them to confirm their NET INTERCHANGE SCHEDULES
each day with their ADJACENT CONTROL AREAS as
required in Policy 1F, Inadvertent Interchange.
NERC requires block INTERCHANGE SCHEDULE
accounting, which assumes, for energy accounting
purposes, that the beginning and ending ramps have zero
duration. This, in effect, moves the energy associated with
the starting and ending ramps into their adjacent starting
and ending clock hours of the INTERCHANGE SCHEDULE.
100 MWH
MP
100 MW
RA
MP
INTERCHANGE SCHEDULES usually start and end on the

clock hour. However, PURCHASING-SELLING ENTITIES
may wish to begin or end an INTERCHANGE
TRANSACTION at other times, and the CONTROL AREAS
should try to accommodate the resulting off-hour
INTERCHANGE SCHEDULES if possible.
100 MWH
Tag
Submitted
RA
When the SENDING CONTROL AREA and RECEIVING

CONTROL AREA implement an INTERCHANGE SCHEDULE
between each other, they must begin their generation
adjustments at the same time using the same ramp rates. A
mismatch of these parameters will cause a frequency error
in the INTERCONNECTION.
1 Hour
Schedule
Start Time
Schedule
End Time
TIME
Interchange Schedule resulting from 100 MW

Interchange Transaction for two hours showing
ramp start time and durations and energy
accounting for each hour.
100 MW
7:00
7:20
7:40
8:00
8:20
8:40
9:00
9:20
Block accounting moves the ramp energy into the

adjacent clock hours.
Finally, because INTERCHANGE TRANSACTIONS often cross two or more time

zones, NERC requires that all INTERCHANGE SCHEDULES be communicated in
Central Standard Time throughout the year. (Daylight Saving Time will not be
used because 1) it creates 23- and 25-hour days during the transition, 2) the
transition itself does not occur uniformly across the time zones, and 3) not all
areas observe DST.)
Requirements
1.
INTERCHANGE SCHEDULE start and end time. INTERCHANGE

SCHEDULES shall begin and end at a time agreed to by the SOURCE
CONTROL AREA, SINK CONTROL AREA, and the INTERMEDIARY
CONTROL AREAS.
2.
Ramp start times. CONTROL AREAS shall ramp the INTERCHANGE

equally across the start and end times of the schedule.
3.
Ramp duration. CONTROL AREAS shall use the ramp duration

established by their INTERCONNECTION as follows unless they agree
otherwise:
Version 3
P315
Security Committee Change

Security Committee returned
this concept. While it approves
of a default, the Control Area
should have leeway to change
the ramp rate if needed.
D. Interchange Schedule Standards
3.1.
Interchange Schedules within the Eastern and ERCOT

INTERCONNECTIONS. 10-minute ramp duration.
3.2.
Interchange Schedules within the Western

INTERCONNECTION. 20-minute ramp duration.
3.3.
Interchange Schedules that cross an INTERCONNECTION

boundary. The CONTROL AREAS that implement INTERCHANGE
SCHEDULES that cross an INTERCONNECTION boundary must use
the same start time and ramp durations.
3.4.
Exceptions for Compliance with Disturbance Control

Standard and Line Load Relief. Ramp durations for
INTERCHANGE SCHEDULES implemented for compliance with
NERCs Disturbance Control Standard (recovery from a
disturbance condition) and INTERCHANGE TRANSACTION
curtailment in response to line loading relief procedures may be
shorter, but must be identical for the SENDING CONTROL AREA
and RECEIVING CONTROL AREA [See also Policy1E2,
Generation Control Performance Performance Standard]
4.
Time Zone standard. All electronic INTERCHANGE SCHEDULES

communications shall be communicated, both verbally and electronically,
in Central Standard Time. (Daylight saving time will not be used.)
Security Committee
Change
5.
Interchange Schedule accounting. Block accounting shall be used.
Similar to change in
3A1.3
Version 3
P316
D.
Interchange Transaction Cancellation,

Termination, and Curtailment
1.
INTERCHANGE TRANSACTION cancellation and termination. When a

PURCHASING-SELLING ENTITY must terminate an INTERCHANGE
TRANSACTION that is in progress, or cancel an INTERCHANGE
TRANSACTION that has not started, the PURCHASING-SELLING ENTITY
shall contact the SINK CONTROL AREA to which it submitted the
INTERCHANGE TRANSACTION tag. The SINK CONTROL AREA shall then
directly contact its SECURITY COORDINATOR and all INTERMEDIARY
CONTROL AREAS and TRANSMISSION PROVIDERS on the SCHEDULING
PATH. A description of those entities who may cancel or terminate an
Interchange Transaction is found in Appendix 3D, Transaction Tag
Actions.
2.
INTERCHANGE TRANSACTION Curtailments. When a SECURITY

COORDINATOR, CONTROL AREA, or TRANSMISSION PROVIDER must
curtail or hold an INTERCHANGE TRANSACTION due to loss of generation
or load, or to mitigate an OPERATING SECURITY LIMIT violation, it will
notify the SINK CONTROL AREA. The SINK CONTROL AREA shall
immediately contact the SOURCE CONTROL AREA to agree upon an
implementation time for the curtailment. The SINK CONTROL AREA will
also contact all INTERMEDIARY CONTROL AREAS and TRANSMISSION
PROVIDERS on the SCHEDULING PATH as well as the PURCHASINGSELLING ENTITY who submitted the INTERCHANGE TRANSACTION tag.
The SINK CONTROL AREA and SOURCE CONTROL AREA shall then adjust
their resulting INTERCHANGE SCHEDULES with their ADJACENT
CONTROL AREAS. . A description of those entities who may curtail
an Interchange Transaction is found in Appendix 3D, Transaction
Tag Actions. [See also Policy 9, Security Coordinator
Procedures]
2.1.
Curtailments not initiated by the SECURITY

COORDINATOR. If the INTERCHANGE TRANSACTION was
curtailed by a CONTROL AREA or TRANSMISSION
PROVIDER, in addition to the actions specified in
Requirement 2 above, that entity shall immediately inform
its SECURITY COORDINATOR. The SINK CONTROL AREA
shall issue a revised INTERCHANGE TRANSACTION tag at
the curtailed value.
2.2.
INTERCHANGE TRANSACTION curtailment notification.

The SINK CONTROL AREA shall initiate the INTERCHANGE
TRANSACTION curtailment notification directly with the
SOURCE CONTROL AREA and any dc tie operators prior to
the start of the curtailment. (This notification must include
a common time (specified as xxxx hours) at which the
curtailment or adjustment is to take place, as well as ramp
rates, to avoid affecting INTERCONNECTION frequency and
causing INADVERTENT INTERCHANGE.) .
Version 3
P317
.500.0.500.0.500.RG 1974.DVE39
E.
Transfer Capability
Requirements
[Available Transfer Capability Definitions and Determination, NERC, June 1996.]
1.
2.
Maximum scheduled interchange. The maximum NET INTERCHANGE SCHEDULE between two
CONTROL AREAS shall not exceed the lesser of the following:
1.1.
Total capacity of facilities. The total capacity of both the owned and arranged-for
transmission facilities in service between the two CONTROL AREAS, or
1.2.
Total Transfer Capability. The established network Total Transfer Capability (TTC)
between the CONTROL AREAS which considers other transmission facilities available to
them under specific arrangements, and the overall physical constraints of the transmission
network. Total Transfer Capability is defined in Available Transfer Capability
Definitions and Determination, NERC, June 1996.
Available Transfer Capability. Available Transfer Capability (ATC) is an indication of the

additional transfer capability remaining in the physical transmission network for further
commercial activity over and above already committed uses between two CONTROL AREAS.
Available Transfer Capability is defined in Available Transfer Capability Definitions and
Determination, NERC, June 1996.
Version 3
P319
Exhibit F
Appendix 3A1 Tag Submission and
Response Timetables
For Security Committee approval

for interim implementation:
February 15, 2000 until March 30,
2000.
For implementation April 15, 2000
in WSCC

Appendix Subsections
A.
B.
B.C.
Eastern Interconnection
Western Interconnection
ERCOT Interconnection
A.
Eastern and Western Interconnection
Includes revisions from the Interconnected

Operations Subcommittee meeting,
December 6 8, 1999
The table below represents the recommended business practices for tag submission and assessment
deadlines. These are default requirements; some regulatory or provincially approved provider practices
may have requirements that are more stringent. Under these instances, the more restrictive criteria shall
be adhered to.
New columns to
provide clarity
Transaction Type
Transaction
Start Time
Single Hour starting

Next-Hour Hourly
New
# 1 Hour
Multi-hour
< 24 hrs duration
starting Next-Hour
# 1 Hour
Single hour, multi-hour

< 24 hrs duration, or
Daily,Hourly/Daily
(Same Day)
starting beyond Next
Hour
> 1 Hour and

# 24 Hours
Hourly/Daily (Next Day)
24 Hours
Transaction
Duration
# 1 Hour
Tag
Submission
Time prior to
Transaction
Start Time
Transmission
Provider and
Control Area
Assessment
1
Time
(AgentAuthority)
(ApprovalAuthority)
20 minutes
# 10 minutes from
prior to start
tag receipt.
> 1 Hour and

# 24 Hours
45 minutes
# 35 minutes from
prior to start
tag receipt.
> 1 Hour and

# 168 Hours
90 minutes
# 45 minutes from
prior to start
tag receipt.
By 1400 CST
day prior
# 4 hours from tag
By 0000 CST of
Time Left before

Start of
Transaction
410 minutes
10 minutes
45 minutes
(1 Week)
> 1 Hour and

# 168 Hours
6 hours
receipt.
(1 Week)
Other
24 Hours
168 Hours
(1 Week)
day prior24
hours prior to
start
12 hours from
tag receipt.
12 hours
TRANSMISSION PROVIDER or CONTROL AREA may not Deny an INTERCHANGE TRANSACTION after the Assessment
time has expired.
Version 1
A3A1-1
Appendix 3A1 Tag Submission and Response Timetable
B.
Transaction Duration
Tag Submision Time

priror to Transaction
Transmission Provider
and Control Area
Assesment Time
Time Left Before Start of

Transaction
New Section
as agreed to
by SC
Start (Agent/Authority)
(Approval/Authority)
Hourly/multi-hour starting
30 minutes prior to start # 10 minutes from Tag
less than 60 minutes in the
of initial hour.
receipt.
future
Hourly (both single hours
and multi-hour)/Daily
(starting 60 minutes or
more in the future but
within current day).
90 minutes prior
Hourly (both single hour

No later than 14:00 one
day prior in the Eastern
(starting at 00:00 or further most time zone
into the future).
10 minutes prior to
ramp.
# 45 minutes from receipt 35 minutes prior to initial

ramp.
# 6 hours prior to
6 hours prior to start.
transaction start day.
This table has not been approved by the

WSCC.
Version 1
A3A1-2
B.
C.
No changes to ERCOT
timing tables.
ERCOT
All transmission service in ERCOT is Network Service between transmission

zones. Transmission Service is either Unplanned or Planned
Energy transfers using Unplanned Transmission Service
Transaction
Duration
TAG
Submission
Time Time
prior to
Transaction
Start Time
ISO
AssessmentApproval
Time left
before Start
Next-Hour
Hourly
20 minutes
prior to start
10 minutes from
request
10 minutes
Next-Hour
(Same Day)
20 minutes
prior to start
10 minutes from
request
10 minutes
Next Day
By 1400 day
prior
4 hours from
request
6 hours
Weekly
2 days prior to
start
24 hours from
request
24 hours
Monthly
4 days prior to
start
48 hours from
request
48 hours
Arranging Planned Transmission Service

Annual Planned Transmission Service is a nomination process in October of each year for the
following year. Requests for daily, weekly and monthly Planned Transmission Service is
arranged through the ERCOT ISO prior to requesting energy transfers. Approval times are:
Type Planned
Service
Submitted
Approval
Annual
October
January
Monthly
8 days prior
7 days from
request
Weekly
2 days prior
Daily
2 days prior
24 hours from
request
24 hours from
request
Version 1
A3A1-3
Energy transfers using approved Planned Service

Transaction
Duration
Version 1
TAG
Submission
Time
ISO
AssessmentApproval
Time left
before Start
Next Day
By 1400
hours day
prior
4 hours from
request
6 hours
Weekly
By 1400
hours day
prior
4 hours from
request
6 hours
Monthly
By 1400
hours day
prior
4 hours from
request
6 hours
A3A1-4
Appendix 3A3 Electronic Tagging Service

Failure Procedures
Exhibit G
New Appendix
This document describes basic methods to be used to determine the appropriate

action of a market participant should a portion of the E-Tag system appear to be
functioning improperly. As with any large-scale system, situations will arise which
cause components of the system to fail unexpectedly. In order to maintain the flow
of business throughout the marketplace, it is suggested that the following practices
be observed with regard to the E-Tag system.
Decision Flow Chart

The flow chart below shows a general method for determining when a user should
utilize an out of band method to communicate market information to transaction
participants. This method can be applied to all outbound messages; specific
explanations of out of band methods for each entity/message are detailed
For Security Committee

approval for Interim
Implementation:
December 16 17, 1999
through March 30, 2000.
Interconnected
Operations
Subcommittee changes
Changes are shown from
current version that is in
Section J of the E-Tag
Reference Document
Send Message
Yes
Successful
Response?
Call Recipient
No
No
Error
Message?
Yes
Can Fix
Error?
Yes
No
Is
Recipient Having
Prolems?
No
Call Info Tech

Staff
Yes
Done
Use Out of Band

Communications
No
Can
Info Tech Staff
fix?
Yes
Correct Problem
following.
Version 1
-1-
Draft: September 30, 1999
Appendix 3A3 Electronic Tagging Service Failure Procedures
Out-Of-Band Communication Methods

There are two primary methods for describing transaction information outside of the E-Tag system:
verbally via telephone and in written form via fax. Faxed tags must be accompanied by telephone
confiramation, and must indicate the reason for the E-tag failure, and when the E-tag system is expected
to become available.
The sections below describe which methods are appropriate for each of the various failure scenarios.
Agent SUBMIT There are several possible cases where the Agent, for some reason, would be
unable to SUBMIT a tag to the Authority. For all practical purposes, there are only two that need to
be described here:
1. Authority is up and running, but the Agent cannot send information to it (Agent is down,
Internet connectivity issues, Agent cannot generate a valid SUBMIT message). In this case, the
Agent has a number of choices. It can have the Agent service backed up with redundant systems,
wait and re-submit the tag when communication problems are relieved, contact another Agent and
request the Agent enter the tag for them, or it may send a hardcopy fax tag (see Section 2,
Functional Specification, Appendix D) to the Load Control Area and request that the Authority
enter the tag for them.
2. Authority is down. In this case, action may be dependent upon whether the tag is for next day or
next hour. For next day tags, it may be possible for the Agent user to wait a short period of time
until the authority is back up and running. However, ifTo meet tag submission deadlines are
approaching or for next hour tags, the Agent user may need to fax a copy of the tag to all parties
of the transaction. In this event, each Control Area on the Scheduling Path shall verify the
Interchange Schedules with its Adjacent Control Areas prior to implementation of the Interchange
Transaction. Each Transmission Provider on Once the Load Control Area has collected all the
UPDATE messages for a tag, it should then fax a copy of the Tag to their Security Coordinator,
followed by a confirmation call via telephone. Thethe Scheduling Path shall evaluate their
associated transmission reservations and report any reasons for denial to their respective Control
Areas. The Load Control Area shall provide the Security Coordinator will utilize the tools
available to ensure the tag is entered into the iIDC/IDC. with the tag to enable the Security
Coordinator to consider the Interchange Transaction should line load relief become necessary.
Note: if there is adequate time prior to schedule implementation, the Security Coordinator/Load Control
Area may request the Agent user to re-submit the tag electronically when the Authority returns to service
as one means of entering the tag into the iIDC/IDC.
Agent CANCEL Should the Agent be unable to issue a CANCEL message, the Agent user should
verbally request the CANCEL of the Load Control Area via telephone. The LCA should execute the
CANCEL on the Agents behalf using override functionality provided by the Authority.
Agent STATUS Should the Agent be unable to issue a STATUS request, the Agent user should
verbally request the STATUS from the Load Control Area via telephone.
Agent DSTATUS In event of a failure, the DSTATUS request should be considered excessive and
should not be requested. However, the Load Control Areas may choose to honor these requests as it
sees fit.
Other Agent Responsibilities The Load Control Area may request the Agent user to fax
information to other parties (parties in the chain that the Authority cannot reach). The Agent user
should honor these requests in as quickly a manner as possible, as these faxes may directly affect the
acceptance/refusal of the transaction by the recipient. As above, faxes should be followed up with
phone calls to confirm receipt.
Version 1
-2-
Authority ASSESS Should the Authority be unable to send ASSESS messages to the various
Approvals (i.e. state of ERROR or INVALID), the Load Control Area should call the tag author via
telephone and verbally request the Load Control Areatag author to fax a copy of the tag to the party
having difficulty.
Note: It is not necessary for the Agent to wait for the authority to verbally request this action. The
Agent user who is monitoring status may choose to proactively send this fax whenever he sees an
ERROR status. This will expedite tag assessment.
Authority IMPLEMENT Should the Authority be unable to send an IMPLEMENT message to the
IDC or other forwarding URL, the Load Control Area should fax a copy of the Tag to its Security
Coordinator, followed by a confirmation call via telephone. The Security Coordinator will utilize the
tools available to it to ensure the tag is entered into the iIDC/IDC.
Approval UPDATE Should the Approval be unable to issue an UPDATE message, the Approval
user should verbally request the update change of the Load Control Area via telephone. The LCA
should execute the UPDATE on the Approvals behalf using override functionality provided by the
Authority.
Approval CANCEL Should the Approval be unable to issue a CANCEL message, the Approval
user should verbally request the CANCEL of the Load Control Area via telephone. The LCA should
execute the CANCEL on the Approvals behalf using override functionality provided by the
Authority.
Approval STATUS Should the Approval be unable to issue a STATUS message, the Approval
user should verbally request the STATUS of the Load Control Area via telephone.
Approval DSTATUS Should the Approval be unable to issue a DSTATUS request, the Approval
user should request a fax of the tag from the PSE via telephone.
Additional Information
Recipients of out-of-band requests should treat the requests in a non-discriminatory manner. Should any
party seem to be relying excessively on out-of-band communications method, data should be collected
and supplied to NERC that documents this behavior. Information supplied to NERC should contain the
following:
name of the entity,
the duration of time which the data represents,
the number of E-Tag requests received,
the number of out-of-band requests received, and
details of individual requests (Did the requestor appear to follow the flow chart methods described
above? What reason was given for the failure? Was the problem resolved, or have all request been
due to the same problem? What are the details of the request?).
NERC will review this information, investigate the manner, and make judgements as to how to handle the
situation.
Version 1
-3-
Appendix 3A4 Required Tag Data

This table lists all data elements on the Interchange Transaction tag. Those
elements denoted as Required must be included on the tag, and are the only
elements that may be used by the CONTROL AREAS and TRANSMISSION
PROVIDERS in their tag assessment procedures. The tag will be judged as
complete if it includes those items. A tag may not be denied based on those
elements denoted as not required.
Data elements denoted as Correctable may be revised by the PURCHASINGSELLING ENTITY during the Transaction assessment time.
Data Item
Required
Correctable
Interchange Transaction ID
Yes
No
TEST Identifier
Yes
No
Transaction Start and Stop Dates
Yes
No
Transaction Days
Yes
No
Time Zone
N/A
N/A
Purchasing-Selling Entity
Yes
No
PSE Deal Reference
No
Yes
PSE Contact Name
No
Yes
PSE Contact Telephone Number
No
Yes
10
PSE Contact 24-hour Telephone

Number
Yes
Yes
11
PSE Contact Fax Number
No
Yes
12
Source Entity
Yes
No
13
Source Phone Number
No
Yes
14
Source Fax Number
No
Yes
15
Sink Entity
Yes
No
16
Sink Phone Number
No
Yes
17
Sink Fax Number
No
Yes
18
Remarks
No
Yes
Version 1
-1-
Exhibit H
New Appendix
For Security Committee
approval for interim
implementation:
December 16 17, 1999 through
March 30, 2000
Markups from Dec 16-17, 1999
SC meeting.
Comments
Supplied by tag software
Control Area or Nname of

generator, generator zone, or
system for intra-Control Area
transactions.
Control Area or Nname of load,

load zone, or system for intraControl Area transactions.
Draft 1: December 7, 1999
Data Item
Required
Correctable
Comments
Energy Profile
19
Start Time
Yes
No
20
Stop Time
Yes
No
21
MW
Yes
No
22
MWH
No
No
23
Ramp Start
No
No
24
Ramp Duration
No
No
Transaction Path
25
Control Area
Yes
No
26
Yes
No
27
Yes
Yes
28
Path (POR/POD)
Yes
Yes
29
Product
Yes
Yes
30
OASIS Assignment Reference
Yes
Yes
31
Product Level
Yes
Yes
32
Miscellaneous Information
No
Yes
33
Miscellaneous Reference
No
Yes
Required for the source PSE,

load-serving PSE, and those
PSEs with Transmission
reservations
Required only when using

multiple reservations for a
single transmission segment
Loss Accounting
34
Yes
No
35
Start Time
Yes
No
36
Stop Time
Yes
No
37
Path
Yes
No
38
MW at POR
Yes
No
39
MW at POD
Yes
No
40
Loss Supply
Yes
Yes
Version 1
-2-
Required at option of the

Can not change to or from in

kind
41
Data Item
Required
Correctable
Supply Reference
No
Yes
Version 1
-3-
Comments
Appendix 3D Transaction Tag Actions
Exhibit I
For Eastern and Western Interconnections
New Appendix
The table below explains the various tag actions that are possible, and the
entities who are entited to initiate these actions.
For Security Committee approval

for Interim Implementation
December 17, 1999
Reason:
Energy Profile
Revision:
Tag Status:
Complete or
Partial
Ends or
Modified
Tag Actions
Reliability or
Economics
Called by
Timing
Cancel
Economic
PSE*
Before Transaction
Start
Complete
Ends
Terminate
Economic
PSE*
After Transaction
Start
Complete
Modified
Withdraw
Economic
PSE*
Before Approval
Complete
Ends
Correct
Economic
PSE*
Before Close of
Assessment Time
N/A
N/A
Curtail
Reliability
TP, SC, CA
Before or After
Transaction Start
Either
Modified
Deny
Reliability
TP, CA
Before Close of
Assessment Time
Complete
Ends
Approve
Reliability
TP, CA
Before Close of
Assessment Time
Complete
N/A
*Note: In some situations, CONTROL AREAS implement certain INTERCHANGE TRANSACTIONS or INTERCHANGE
SCHEDULES, such as bilateral inadvertent payback, DYNAMIC SCHEDULES, and emergency schedules from
RESERVE SHARING GROUPS. In these situations, the CONTROL AREA serves as the PSE and can perform these
actions.
Tag Submit
Actions By CA,
TP, SC
Transaction
Approval
Transaction
Approval
Deadline
Assess
(Approve/Deny)
Transaction
Start
Transaction
End
Curtail
Correct
Withdraw
Cancel
Terminate
Actions By PSE
Version 1
A3A3-1
Interconnected Operations Subcommittee

Chairman
SERC
Item 1d
John W. Pope
Director, Bulk Power
Operations
Southern Company Services, Inc.

600 North 18th Street
PCC Corporate Headquarters
Birmingham, Alabama 35202
Ph: (205) 257-5450

Fx: (205) 257-6663
Em:jwpope@
southernco.com
John R. Beachman
Manager, Power Control
American Electric Power

P.O. Box 16631
4th Floor
Columbus, Ohio 43216-6631
Ph: (614) 223-3422

Fx: (614) 223-3404
Em:jrbeachman@aep.
com
ERCOT
James A. Byrd
Vice President, Transmission
Grid Management
TXU Electric
2233-B Mountain Creek Parkway
Dallas, Texas 75211-6716
Ph: (214) 743-6870

Fx: (972) 263-6710
Em:jbyrd@txu.com
FRCC
Ronald L. Donahey
Manager, System Operations
Energy Delivery Systems
Tampa Electric Company

P.O. Box 111
Tampa, Florida 33601-0111
Ph: (813) 623-5120

Fx: (813) 630-6299
Em:RDonahey@
worldnet.att.net
MAAC
Bruce M. Balmat
Vice President, Operations
PJM Interconnection, L.L.C.

955 Jefferson Avenue
Valley Forge Corporate Center
Norristown, Pennsylvania 19403-2497
Ph: (610) 666-8860

Fx: (610) 666-4286
Em:balmatbm@pjm.
com
MAIN
Tom Wiedman
Bulk System Security Manager
Commonwealth Edison Company

Electric Operations
1N301 Swift Road
Lombard, Illinois 60148
Ph: (630) 691-4478

Fx: (630) 691-4776
Em:Thomas.
E.Wiedman@ucm.com
MAPP
Jerry W. Hagge
Senior Operations Consultant
Nebraska Public Power District

P.O. Box 1000
Doniphan, Nebraska 68832-1000
Ph: (402) 845-5200

Fx: (402) 845-5204
Em:jwhagge@nppd.
com
NPCC
Michael C. Calimano
Director Pool Operations
New York Independent System

Operator
3890 Carman Road
Schenectady, New York 12303
Ph: (518) 356-6129

Fx: (518) 356-6118
Em:mcalimano@
nyiso.com
SPP
Scott P. Moore
Director, System Operations
Central and South West Corporation

P.O. Box 660164
Dallas, Texas 75266-0164
Ph: (214) 777-1549

Fx: (214) 777-1429
Em:smoore@csw.com
WSCC
Kellan L. Fluckiger
Vice President of Operations
California ISO
151 Blue Ravine Road
Folsom, California 95630
Ph: (916) 351-4439

Fx: (916) 351-2310
Em:kfluckiger@
caiso.com
WSCC
Donald P. Lacen
Transmission Services
Coordinator
Public Service Company of New

Mexico
Alvarado Square, MS-EP11
Albuquerque, New Mexico 87158
Ph: (505) 241-2032

Fx: (505) 241-2582
Em:dlacen@mail.
pnm.com
EC Liaison
To Be Named (IOS ACLiaiso)
IPP
Darrell Hayslip
Vice President, Asset
Management
Calpine Power Services Company

700 Louisiana
Suite 2350
Houston, Texas 77002
Ph: (713) 830-2034

Fx: (713) 830-2001
Em:darrellh@
calpine.com
ECAR
Item 2. Subcommittee Reorganization

With the Security Committee in place, it is now looking at the organization of its subcommittees.
This is being driven by two factors:
1. The need for greater market segment diversity in the subcommittees, and
2. The unbundling of the roles of the traditional Control Area
Market segment representation. Many Transmission Customers have complained that they are
not adequately represented on the Security Committees subcommittees. Because the
Subcommittees are responsible for developing Operating Policies and Standards, the Committee
believes it important to provide a balance among those market segments who are materially
affected by these Policies and Standards.
At its December 16 17, 1999 meeting, the Security Committee agreed to the following motion:
That each subcommittee should have fair and adequate voting representation
from each segment of the industry.
While one may argue the ratio that provides for fair and adequate, it is fair to say that
subcommittees should include a goodly mixture of Transmission Providers, Transmission
Customers, Control Areas, Security Coordinators, and so on.
New roles, new entities. The other factor driving subcommittee reorganization is the new role
that Control Areas play in the industry. While NERCs Operating Policies continue to assume
that Control Areas own generation and ensure transmission security, in fact, many no longer serve
these roles. Furthermore, because NERC restricts interchange scheduling to Control Areas, we
are seeing a new interest in merchant generators applying for Control Area statusgenerationonly Control Areas that do not serve ultimate customers.
The Control Area Criteria Task Force has made significant strides in the last few months in
enumerating the basic operating functions needed for operational reliability, with the result that
the Control Area unbundles into Balancing Authorities, Interchange Authorities, Transmission
Providers and Generators. Therefore, the Security Committee believes its subcommittees need to
realign themselves if they are to successfully address these functions.
The Subcommittee chairmen recently met with the Security Committee Executive Committee and
developed a straw man organization structure and membership criteria for the subcommittees.
One of the decisions made by this group was to unbundle the Interconnected Operations
Subcommittee into a separate Interchange Subcommittee and a Transmission Subcommittee. The
group also developed a new membership strategy that includes greater participation by the market
segments on the subcommittees. The Technical Steering Committee has a meeting planned for
February 17, 2000, to review these recommendations. [Attachment: Proposed Security
Committee Organization]
Discussion
John Pope will review these proposals. The Subcommittee is welcome to provide comments.
Compliance Program
Compliance Program
Disturbance Reviews
Disturbance Reviews
TLR Reviews
TLR Reviews
Perf Monitoring
Perf Monitoring
Board of Trustees
Board of Trustees
Operating Committee
Organization
Staff
Staff
ATC Implementation
ATC Implementation
Rev 4a
January 28, 2000
Technical Support
Technical Support
Various subgroups as
Various subgroups as
needed
needed
Security
Security
Committee
Committee
Resources
Resources
Policies
P1
P51
P61
Transmission
Transmission
P2
P51
P61
Interchange
Interchange
P3
*Notes:
1. Policy 5 and 6 to be divided among RS and TOS
2. Policy 10 may be divided or assigned to separate subcommittee
3. Each Subcommittee should have representation from each Region, Interconnection, and from
Canada.
Security
Security
P9
P4
P7
"Personnel"
"Personnel"
P8
Item 3. Draft Policy 3, Version 3 for BOT Approval

At its November 16 17 and December 16 17, 1999 meetings, the Security Committee made
several changes to Policy 3, Version 3, before submitting this draft and Appendix 3A2 to the
NERC Board of Trustees for final approval. [Attachments: Policy 3, Version 3 for Board
approval; Appendix 3A2 for Board approval]
Discussion
No action is needed. The Subcommittee may wish to briefly review the changes the Security
Committee made. These are noted on the attached drafts.
For implementation
February 15, 2000
Version 3, Draft 5
April 15, 2000 in WSCC
Policy Subsections
A.
B.
C.
D.

Interchange Transaction Cancellation, Termination,
and Curtailment
E. Transfer Capability
Definitions will be moved to Terms section of

Operating Manual
Control Area. An electrical system bounded by

interconnection (tie-line) metering and telemetry. It
controls generation directly to maintain its
INTERCHANGE SCHEDULE with other CONTROL AREAS
and contributes to frequency regulation of the
INTERCONNECTION.
For Board of Trustees approval

February 7 8, 2000
This draft is annotated to explain the

changes from Version 2 now in the
Operating Manual
It is expected that E-tag version 1.5 will

be in place when this Policy is
implemented.
All sections revised, except E, Transfer

Capability
This new version replaces Interim Version
2a.
Adjacent Control Areas. Two CONTROL AREAS that are

interconnected:
Directly to each other, or
Via a multi-party agreement or transmission tariff. (Examples include Independent System

Operator and Power Pool agreements.)
Dynamic Schedule. A telemetered reading or value which is updated in real time and which is used as a
schedule in the AGC/ACE equation and the integrated value of which is treated as a schedule for
interchange accounting purposes. Commonly used for scheduling jointly owned generation to or
from another control area.
Overlap Regulation Service. A method of providing regulation service in which the control area
providing the regulation service incorporates all of the other control areas tie lines, frequency
response, and schedules into its own AGC/ACE equation.
Supplemental Regulation Service. A method of providing regulation service in which the control area
providing the regulation service receives a signal representing all or a portion of the other control
areas ACE.
Physically Adjacent Control Areas. Two CONTROL AREAS that are directly interconnected with each
other.
Source Control Area. The CONTROL AREA in which the generation (source) is located for an
INTERCHANGE TRANSACTION. (This will also be a SENDING CONTROL AREA for the resulting
INTERCHANGE SCHEDULE.)
Sink Control Area. The CONTROL AREA in which the load (sink) is located for an INTERCHANGE
TRANSACTION. (This will also be a RECEIVING CONTROL AREA for the resulting INTERCHANGE
SCHEDULE.)
Sending Control Area.
Receiving Control Area.
Version 3
The CONTROL AREA exporting the INTERCHANGE

The CONTROL AREA importing the INTERCHANGE.
P31
Intermediary Control Area. A CONTROL AREA on the SCHEDULING PATH between the SOURCE
CONTROL AREA and SINK CONTROL AREA.
Interchange. Energy transfers that cross CONTROL AREA boundaries.
Total Actual Interchange. The algebraic sum of all INTERCHANGE metered with all PHYSICALLY
ADJACENT CONTROL AREAS. It is, in essence, the actual interchange with the Interconnection.
Actual Interchange. The metered interchange over a specific INTERCONNECTION between two
PHYSICALLY ADJACENT CONTROL AREAS.
Net Actual Interchange. The algebraic sum of all metered interchange over all INTERCONNECTIONS
between two PHYSICALLY ADJACENT CONTROL AREAS.
Transaction. An agreement arranged by a PURCHASING-SELLING ENTITY to transfer energy from seller
to a buyer.
Interchange Transaction. A TRANSACTION that crosses one or more Control Area boundaries.
Interchange Transaction Curtailment: The complete or partial interruption of an INTERCHANGE
TRANSACTION that has started or holding of a new INTERCHANGE TRANSACTION that has not
yet started by a TRANSMISSION PROVIDER, SECURITY COORDINATOR, or CONTROL AREA to
maintain operating security.
Interchange Transaction Cancellation. The complete withdrawal of an INTERCHANGE TRANSACTION by
a PURCHASING-SELLING ENTITY prior to the start time of the TRANSACTION.
Interchange Transaction Termination. The complete interruption of an INTERCHANGE TRANSACTION by
a PURCHASING-SELLING ENTITY after the start time of the TRANSACTION.
Interchange Schedule. The planned INTERCHANGE between two ADJACENT CONTROL AREAS that results
from the implementation of one or more INTERCHANGE TRANSACTION(S).
Inadvertent Interchange. The difference between the control areas NET ACTUAL INTERCHANGE and
NET SCHEDULED INTERCHANGE.
Net Interchange Schedule (or Net Schedule). The algebraic sum of all INTERCHANGE SCHEDULES with
each ADJACENT CONTROL AREA.
Scheduled Total Interchange. The net of all INTERCHANGE SCHEDULES with all ADJACENT CONTROL
AREAS. It is, in essence, the scheduled interchange with the INTERCONNECTION.
Purchasing-Selling Entity (PSE). An entity that is eligible to purchase or sell energy or capacity and
reserve transmission services.
Scheduling Path. The Transmission Service arrangements reserved by the PURCHASING-SELLING ENTITY
for a TRANSACTION.
Security Coordinator. An entity that provides the security assessment and emergency operations
coordination for a group of control areas. Security Coordinators must not participate in the
wholesale or retail merchant functions.
Transmission Provider. As defined by FERC, the public utility (or its Designated Agent) that owns,
controls, or operates facilities used for the transmission of electric energy in interstate commerce
and provides transmission service under the Tariff. As used in the NERC Policies: Any entity that
provides Transmission Service.
Version 3
P32
Transmission Service. (FERC-defined term). Point-To-Point Transmission Service provided under Part
II of the Tariff on a firm and non-firm basis.
Version 3
P33
Introduction
1.
Overview
Overview of Transaction-toSchedule process via E-tag

1
PSE Develops
Tag
This Policy addresses the

following issues:
Responsibilities of all PURCHASING-SELLING ENTITIES

involved in INTERCHANGE TRANSACTIONS. 1
Information requirements for INTERCHANGE TRANSACTIONS.
Requirements of CONTROL AREAS to assess and confirm

INTERCHANGE TRANSACTIONS.
2.
Overview
Accountability of CONTROL AREAS for implementing all

INTERCHANGE SCHEDULES in a manner that ensures the
reliability of the INTERCONNECTIONS.
Standards for INTERCHANGE SCHEDULES between CONTROL
AREAS.
The Relationship between Interchange Transactions and

Few changes in this
2
Tag to Sink
Control Area
Submit
3
Transaction
Implementation
Request
Assess
4
Tag to Control Areas,
Trans Providers
5
Transaction
Approval
E-tag
Concepts
Approve
6
Schedule
Implementation
Request
Implement
7
Tag to Adjacent
Control Areas
Schedule
8
Confirmation
section. Added pointers

Policy 3.A. explains the process for
to two new Ref Doc.
arranging and implementing
9
Control Area
INTERCHANGE TRANSACTIONS. Policy
enters into EMS
3.B. explains the procedures for assessing
and confirming INTERCHANGE TRANSACTIONS and implementing INTERCHANGE SCHEDULES. The
flowchart on the right explains the process by which INTERCHANGE TRANSACTIONS become
INTERCHANGE SCHEDULES. Some of these functions are handled by the tagging system used in the
INTERCONNECTION. Refer to the E-tag Reference Document and the ERCOT Tagging Reference
Document for further details.
PURCHASING-SELLING ENTITIES arrange INTERCHANGE TRANSACTIONS that is, they buy or sell
energy and capacity and record the transaction by forwarding the required data via an INTERCHANGE
TRANSACTION tag to the appropriate CONTROL AREA(S).
This Policy deals predominately with INTERCHANGE TRANSACTIONS, that is, those that cross one or more
CONTROL AREA boundaries. The more general term TRANSACTION includes INTERCHANGE TRANSACTIONS and
TRANSACTIONS that are entirely within a CONTROL AREA. At this time, the only reference to the general term
TRANSACTION is the tagging requirement in Requirement 3.A.2.1.
Version 3
P34
CONTROL AREAS assess and approve or deny INTERCHANGE TRANSACTIONS based on reliability
criteria and arrangements for INTERCONNECTED OPERATIONS SERVICES and transmission rights.
Transmission Providers assess the impact of providing the requested transmission service when the service
is approved. To implement the INTERCHANGE TRANSACTION, all affected CONTROL AREAS incorporate
the INTERCHANGE TRANSACTION into their INTERCHANGE SCHEDULES as explained on the following
pages.
In this example, there are three INTERCHANGE TRANSACTIONS, IT1, IT2, and IT3, that result in a number
of INTERCHANGE SCHEDULES between CONTROL AREAS A, B, C, and D. (Refer to the
figure on the right and table below. For simplicity, we are ignoring losses.)
A
CONTROL AREA A is the SOURCE CONTROL AREA for INTERCHANGE TRANSACTION 1
(IT1) and CONTROL AREA B is the SINK CONTROL AREA. To make IT1 occur, CONTROL
AREA A implements an INTERCHANGE SCHEDULE with CONTROL AREA B (SAB-IT1). In this
case, the SOURCE CONTROL AREA A is the SENDING CONTROL AREA, and the SINK
CONTROL AREA B is the RECEIVING CONTROL AREA.
CONTROL AREA A is also the SOURCE CONTROL AREA for INTERCHANGE TRANSACTION
2 (IT2). CONTROL AREA D is the SINK CONTROL AREA for this INTERCHANGE
TRANSACTION. B and C are INTERMEDIARY CONTROL AREAS. The resulting
INTERCHANGE SCHEDULES are from SENDING CONTROL AREA A to RECEIVING
CONTROL AREA B (SAB-IT2), SENDING CONTROL AREA B to RECEIVING CONTROL AREA C
(SBC-IT2), and SENDING CONTROL AREA C to RECEIVING CONTROL AREA D (SCD-IT2).
SAB
IT1
IT2
B
SBC
IT3
C
SCD

CONTROL AREA C is the SOURCE CONTROL AREA for INTERCHANGE TRANSACTION 3 (IT3) and
CONTROL AREA A is the SINK CONTROL AREA. B is the INTERMEDIARY CONTROL AREA. To make IT3
occur, SENDING CONTROL AREA C implements an INTERCHANGE SCHEDULE with RECEIVING CONTROL
AREA B (SCB-IT3) and SENDING CONTROL AREA B to RECEIVING CONTROL AREA A (SBA-IT3).
Net Schedules
CONTROL AREAS A and B can calculate a NET INTERCHANGE SCHEDULE between these two CONTROL
AREAS by adding SAB-IT1 and SAB-IT2 and SBA-IT3. Control Areas B and C can calculate a NET INTERCHANGE
SCHEDULE between these two CONTROL AREAS by adding SBC-IT2 and SCB-IT3.
The NET SCHEDULED INTERCHANGE for A is SAB-IT1 + SAB-IT2 + SBA-IT3, The NET SCHEDULED
INTERCHANGE for B is SAB-IT1 + SAB-IT2 + SBA-IT3 + SBC-IT2 + SCB-IT3.
Relationship Between Control Areas, Interchange Schedules, and Interchange Transactions
Control
Area
Sink
Control
Area for:
Source
Control
Area for:
IT3
IT1, IT2
IT1
Sending
Control Area
for:
Receiving
Control Area for:
Net Interchange
Schedules
IT1, IT2
IT3
IT2, IT3
IT1, IT2, IT3

SBC-IT2 + SCB-IT3
C
D
Version 3
IT3
IT2, IT3
IT2
P35
IT2
SBC-IT2 + SCB-IT3
SCD-IT2
IT2
SCD-IT2
Match
Match
Match
3.
Interchange Schedules within a Multi-Party Regional Agreement or Transmission

Tariff
If CONTROL AREAS A, B, C, and D are parties to a transmission agreement or tariff, such as a Regional
agreement or ISO, then there is no need for the INTERCHANGE SCHEDULES from B to C or C to D as in the
previous example. In this case, all four CONTROL AREAS are considered ADJACENT CONTROL AREAS and
can schedule directly with each other.
CONTROL AREA A is the SOURCE CONTROL AREA for INTERCHANGE TRANSACTION
1 (IT1) and CONTROL AREA B is the SINK CONTROL AREA. To make IT1 occur,
CONTROL AREA A implements an INTERCHANGE SCHEDULE with CONTROL AREA
B (SAB-IT1). In this case, the SOURCE CONTROL AREA A is the SENDING CONTROL
AREA, and the SINK CONTROL AREA B is the RECEIVING CONTROL AREA and these
two control areas are adjacent to each other.
CONTROL AREA A is also the SOURCE CONTROL AREA for INTERCHANGE
TRANSACTION 2 (IT2). CONTROL AREA D is the SINK CONTROL AREA for this
INTERCHANGE TRANSACTION. The resulting INTERCHANGE SCHEDULE is directly from
SOURCE (SENDING) CONTROL AREA A to SINK (RECEIVING) CONTROL AREA D (SAD-IT2).
A
SAB = IT1
SAD = IT2
B
SCA = IT3
CONTROL AREA C is the SOURCE (SENDING) CONTROL AREA for INTERCHANGE TRANSACTION 3 (IT3)
and CONTROL AREA A is the SINK (RECEIVING) CONTROL AREA. To make IT3 occur, SENDING CONTROL
AREA C implements an INTERCHANGE SCHEDULE directly with SINK (RECEIVING) CONTROL AREA A
(SCA-IT3).
Net Schedules
There are only three NET INTERCHANGE SCHEDULES:
SAB = IT1, SAD = IT2, and SCA = IT3
The NET SCHEDULED INTERCHANGE for A is SAB-IT1 + SCA-IT3 + SAD-IT2. For B is SAB-IT1. For C is SCA-IT3, For
D is SAD-IT2.
Relationship between Control Areas, Interchange Schedules, and Interchange Transactions
Control
Area
Sink
Control
Area for:
Source
Control
Area for:
IT3
IT1, IT2
B
C
D
IT1
Version 3
Sending
Control Area
for:
IT1, IT2
Receiving
Control Area for:
IT3
IT1
IT3
IT3
IT2
IT2
P36
SAB-IT1
SCA-IT3
SAD-IT2
SAB-IT1
SCA-IT3
SAD-IT2
4.
Confirming Interchange Schedules
Interchange Schedules are confirmed between Adjacent Control
Areas. The RECEIVING CONTROL AREAS are responsible for
initiating contact with the SENDING CONTROL AREAS; however, it is
also permissible for the SENDING CONTROL AREA to initiate contact
with the RECEIVING CONTROL AREA.
Sending/Source
Control Area
Schedule
Confirmation
Receiving/Sending
Intermediary Control Areas
B
The diagram on the right shows the confirmation path.
D
Curtailing, Canceling, or Terminating Interchange
C
Receiving/Sink
Transactions
Control Area
Curtailing Interchange Transactions
Notifying the Sink Control Area. When a CONTROL AREA or TRANSMISSION PROVIDER must curtail an
INTERCHANGE TRANSACTION, it begins the process by contacting its SECURITY COORDINATOR and the
SINK CONTROL AREA. When a SECURITY COORDINATOR curtails an INTERCHANGE TRANSACTION, it
contacts all other SECURITY COORDINATORS. Then the SECURITY COORDINATOR of the SINK CONTROL
AREA notifies that CONTROL AREA of the curtailment.
5.
Notifying other entities. Once the SINK CONTROL

AREA has been notified, it contacts the SOURCE
CONTROL AREA directly, confirms the curtailment and
the resulting change in their INTERCHANGE
SCHEDULES. The SINK CONTROL AREA then contacts
the INTERMEDIARY CONTROL AREAS and
TRANSMISSION PROVIDERS on the SCHEDULING PATH
as well as the PURCHASING-SELLING ENTITY who
submitted the tag (this is accomplished via the tagging
system). Following this notification, if the SOURCE
CONTROL AREA and SINK CONTROL AREA are not
adjacent, they begin implementing the INTERCHANGE
SCHEDULE adjustments with their ADJACENT
CONTROL AREAS.
A
B
Canceling or Terminating Interchange Transactions

When a PURCHASING-SELLING ENTITY must cancel an INTERCHANGE TRANSACTION before it begins, or
terminates one that is in progress, the PURCHASING-SELLING ENTITY shall contact the SINK CONTROL
AREA to which it submitted the INTERCHANGE TRANSACTION tag. The SINK CONTROL AREA shall then
directly contact its SECURITY COORDINATOR, all CONTROL AREAS, and TRANSMISSION PROVIDERS on the
SCHEDULING PATH.
Additional details of INTERCHANGE TRANSACTION curtailment are found in Section 3D, Interchange
Transaction Cancellation and Curtailment, and Policy 9, Security Coordinator Procedures.
Version 3
P37
A.

[Appendix 3A1, Tag Submission and Response Timetables]
[Appendix 3A2, Tagging Across Interconnection Boundaries]
[E-tag Reference Document]
[Tagging Instruction Reference Document]
Most of the changes in this

section provide more
details on tagging
Interchange Transactions.
Security Committee
Change
Introduction
This section specifies the PURCHASING-SELLING ENTITYS requirements for
tagging all INTERCHANGE TRANSACTIONS, and the CONTROL AREAS obligations
for accepting the tags and implementing the INTERCHANGE TRANSACTIONS. The
tag data is integral for providing the CONTROL AREAS, SECURITY
COORDINATORS, and other operating entities the information they need to assess,
confirm, approve or deny, implement, and curtail INTERCHANGE TRANSACTIONS
as necessary to accommodate the marketplace and ensure the operational security
of the INTERCONNECTION.
This document has not

been prepared.
Requirements
1.
INTERCHANGE TRANSACTION arrangements. The PURCHASINGSELLING ENTITY shall arrange for all Transmission Services,
INTERCONNECTED OPERATIONS SERVICES, tagging, and personnel to
contact for each INTERCHANGE TRANSACTION to which it is a party.
1.1.
1.2.
Security Committee
Change
Transmission services. The PURCHASING-SELLING ENTITY shall

arrange the Transmission Services necessary for the receipt,
transfer, and delivery of the TRANSACTION.
Interconnected Operations Services. The PURCHASINGall associated
Interconnected
Operations Services are
still being defined in
Proposed Policy 10.
SELLING ENTITY shall provide or arrange for

INTERCONNECTED OPERATIONS SERVICES.
New Req 1.3.
See also
Section C4 for
companion.
1.3.
1.4.
1.5.
Version 3
Time Zone standard. All electronic INTERCHANGE

TRANSACTIONS communications shall be communicated, both
verbally and electronically, in Central Standard Time. (Daylight
saving time will not be used.)
Tagging. The PURCHASING-SELLING ENTITY serving the load
shall be responsible for providing the INTERCHANGE
TRANSACTION tag. (NOTE: 1) Any PSE may provide the tag;
however, the load-serving PSE is responsible for ensuring that a
single tag is provided. 2) If a PSE is not involved in the
TRANSACTION, such as delivery from a jointly-owned generator,
then the SINK CONTROL AREA is responsible for providing the
tag. PSEs must provide tags for all Interchange Transactions in
accordance with Requirement 2.
Contact personnel. Each PURCHASING-SELLING ENTITY with
title to an INTERCHANGE TRANSACTION must have, or arrange to
have, personnel directly and immediately available for notification
of INTERCHANGE TRANSACTION changes. These personnel shall
be available from the time that title to the INTERCHANGE
P38
Security Committee
Change
Security Committee did
not agree that a time
zone standard was
needed for verbal
communications
Sink CA shall tag any

Transaction not set up
by a Purchasing-Selling
Entity merchant.
TRANSACTION is acquired until the INTERCHANGE TRANSACTION

has been completed.
2.
INTERCHANGE TRANSACTION tagging. Each INTERCHANGE

TRANSACTION shall be tagged before implementation as required by each
INTERCONNECTION as specified in the E-tag Reference Document, or
Transaction Tagging Process within ERCOT Reference Document.
In addition to providing necessary operating information, the
INTERCHANGE TRANSACTION tag is the official request from the
PURCHASING-SELLING ENTITY to the CONTROL AREAS to implement the
INTERCHANGE TRANSACTION. The information that must be provided on
the tag is listed in Appendix 3A4.
2.1.
2.2.
Application to TRANSACTIONS. All INTERCHANGE

TRANSACTIONS and certain INTERCHANGE SCHEDULES shall be
tagged. In addition, intra-Control Area transfers using Point-toPoint Transmission Service2 shall be tagged. This includes:
INTERCHANGE TRANSACTIONS (those that are between

CONTROL AREAS.)
TRANSACTIONS that are entirely within a CONTROL AREA.
DYNAMIC INTERCHANGE SCHEDULES (tagged at the expected

average MW profile for each hour.) (Note: a change in the
hourly energy profile of 25% or more requires a revised tag.)
INTERCHANGE TRANSACTIONS for bilateral INADVERTENT

INTERCHANGE payback (tagged by the Sink Control Area.)
INTERCHANGE TRANSACTIONS established to replace

unexpected generation loss, such as through prearranged
reserve sharing agreements or other arrangements, are exempt
from tagging for 60 minutes from the time at which the
INTERCHANGE TRANSACTION begins. (tagged by the Sink
Control Area). [See also, Policy 1E2 and 2.1, Disturbance
Control Standard]
Added new Appendix

3A4 to list required tag
data.
More details. Trying to

capture all
Transactions using
Point-to-Point
Transmission Service
and that have sourcesink pairs.
Removed reference to
tagging bilateral
inadvertent payback. It
must be scheduled,
but its no different
than any other
Schedule.
Parties to whom the complete tag is provided. In the EASTERN

INTERCONNECTION, the tag shall be provided to the CONTROL
AREAS and TRANSMISSION PROVIDERS on the SCHEDULING
PATH. In the WESTERN INTERCONNECTION, the tag shall be
provided to the CONTROL AREAS and Transmission Providers on
the SCHEDULING PATH as well as the PURCHASING-SELLING
ENTITIES who are parties to the INTERCHANGE TRANSACTION.
2.2.1. Parties to whom limited tag information is provided.
In the EASTERN INTERCONNECTION, tag
information that is pertinent to their role in the
INTERCHANGE TRANSACTION shall be provided
to the source PURCHASING-SELLING ENTITY,
Security Committee
Change
Recommended by MIC
This includes all grandfathered and other non-888 Point-to-Point Transmission

Service
Version 3
P39
the LOAD-SERVING ENTITY, and other

PURCHASING-SELLING ENTITIES with
transmission reservations.
2.3.
2.4.
Method of transmitting the tag. The PURCHASING-SELLING

ENTITY shall submit the Interchange Transaction tag in the
format established by each INTERCONNECTION. [E-Tag
Reference Document or Transaction Tagging Process
within ERCOT Reference Document]
2.3.1. Tags for Interchange Transactions that cross
Interconnection boundaries. Procedures are found in
Appendix 3A2, Tagging Across Interconnection
Boundaries.
Reference to new
Appendix 3A2.
INTERCHANGE TRANSACTION submission time. To provide

adequate time for INTERCHANGE SCHEDULE implementation,
INTERCHANGE TRANSACTIONS shall be submitted as specified in
Appendix 3A1, Tag Submission and Response Timetable.
Reference to new
Appendix 3A1 replaces
20-miin spec in Policy.
See Appendix for
issue that needs
resolving.
2.4.1. Exception for security reasons. Exception to the

submission time requirements in Section 2.4 is allowed if
immediate changes to the INTERCHANGE TRANSACTIONS
are required to mitigate an OPERATING SECURITY LIMIT
violation. The tag may be submitted after the emergency
TRANSACTION has been implemented but no later than 60
minutes.
3.
4.
2.5.
Confirmation of tag receipt. Confirmation of tag receipt shall

be provided to the PURCHASING-SELLING ENTITY who submitted
the tag in accordance with INTERCONNECTION tagging practices.
2.6.
Tag acceptance. An INTERCHANGE TRANSACTION tag shall be

accepted if all required information is valid and provided in
accordance with the tagging specifications in Requirement 2
INTERCHANGE TRANSACTION tag receipt verification. The SINK

CONTROL AREA shall verify the receipt of each INTERCHANGE
TRANSACTION tag with the TRANSMISSION PROVIDERS, and CONTROL
AREAS on the SCHEDULING PATH before the INTERCHANGE
TRANSACTION is implemented.
INTERCHANGE TRANSACTION assessment. Transmission Providers,
CONTROL AREAS on the SCHEDULING PATH, and other operating entities
responsible for operational security shall be responsible for assessing and
approving or denying INTERCHANGE TRANSACTIONS on behalf of
PURCHASING-SELLING ENTITIES, based on established reliability criteria
and adequacy of INTERCONNECTED OPERATIONS SERVICES and
transmission rights as well as the reasonableness of the INTERCHANGE
TRANSACTION tag. This assessment shall include the following:
The CONTROL AREA Assesses:
Transaction start and end time
Version 3
P310
2.4.1 is new. Similar to

last item in 2.1 above.
E-tag handles this, and

many other
notification steps.
To prevent capricious
rejections.
E-tag handles this, and

many other
notification steps.
Bullet lists added for

clarity.
NERC expects that the

Control Areas and
Transmission Providers to
have the proper tools to
perform these
assessments. Lack of these
Draft 5: December
1999 to
tools is not17,
a reason
deny an Interchange
Transaction.
Energy profile (ability of generation maneuverability to

accommodate)
Scheduling Path (proper connectivity of ADJACENT CONTROL
AREAS)
The TRANSMISSION PROVIDER Assesses:

Valid OASIS reservation number or transmission contract
identifier
Proper transmission priority
Energy profile accommodation (does energy profile fit OASIS
reservation?)
OASIS reservation accommodation of all Interchange
Transactions
Loss accounting
4.1.
5.
Tag Corrections. During the CONTROL AREAS and

TRANSMISSION PROVIDERS Assessment Time, the PURCHASINGSELLING ENTITY who submitted the tag may elect to submit a tag
correction. Tag corrections are changes to an existing tag that do
not affect the reliability impacts of the INTERCHANGE
TRANSACTION; therefore, tag corrections do not require the
complete re-assessment of the tag by all CONTROL AREAS and
TRANSMISSION PROVIDERS on the SCHEDULING PATH, or the
completion and submission of a new tag by the PURCHASINGSELLING ENTITY. The SINK CONTROL AREA shall notify all
CONTROL AREAS and TRANSMISSION PROVIDERS on the
SCHEDULING PATH of the correction, and specifically alert those
entities for which a correction has impact. Although the correction
does not itself change the approval decision of the affected party,
it does allow for that party to make a change in decision based on
the supplied correction. Tag items that may be corrected are
found in Appendix 3A4, Required Tag Data. A description of
those entities who may correct an INTERCHANGE
TRANSACTION tag is found in Appendix 3D, Transaction Tag
Actions.
INTERCHANGE TRANSACTION approval or denial. Each CONTROL

AREA or TRANSMISSION PROVIDER on the SCHEDULING PATH
responsible for assessing and approving or denying the INTERCHANGE
TRANSACTION shall notify the SINK CONTROL AREA. The SINK CONTROL
AREA in turn notifies the PURCHASING-SELLING ENTITY who submitted
the INTERCHANGE TRANSACTION tag, plus all other CONTROL AREAS and
TRANSMISSION PROVIDERS on the SCHEDULING PATH. . Assessment
timing requirements are found in Appendix 3A1, Tag Submission and
Response Timetable. A description of those entities who may approve
or deny an INTERCHANGE TRANSACTION is found in Appendix 3D,
Version 3
P311
Req. 4.1 Effective 10/1/00.
Security Committee
Change
Addition of Tag
Correction. Needed to
allow a PSE to make minor
corrections to the tag
without a resubmittal.
Policy change needed to
implement in the E-tag
Spec v1.5 This addresses
issues raised by the MIC
related to the use of
Cancellation and Denial by
the Transmission
Providers.
Note addition of new
Appendixes 3A4 and 3D.
Added reference to
Appendix 3A1 to address
time requirements for
assessing Interchange
Transactions.
6.
5.1.
INTERCHANGE TRANSACTION denial. If denied, this notification

shall include the reason for the denial.
5.2.
INTERCHANGE TRANSACTION approval. The

Interchange Transaction is considered approved if the
PURCHASING-SELLING ENTITY who submitted the
INTERCHANGE TRANSACTION tag has received
confirmation of tag receipt and has not been notified that the
transaction is denied.
Responsibility for INTERCHANGE TRANSACTION implementation. The

SINK CONTROL AREA is responsible for initiating the implementation of
each INTERCHANGE TRANSACTION as tagged in accordance with Policy
3.A. Requirement 2 (and its subparts). The INTERCHANGE TRANSACTION
is incorporated into the INTERCHANGE SCHEDULE(S) of all CONTROL
AREAS on the SCHEDULING PATH in accordance with Policy 3B.
6.1.
7.
New.
8.
Security Committee
Change
Tag requirements for Interchange Transaction

implementation. The CONTROL AREA shall implement only those
INTERCHANGE TRANSACTIONS that:
Have been tagged in accordance with Requirement 2 above,

or,
Are exempt from tagging in accordance with Requirement 2.1

above.
Tag requirements after Curtailment has ended. Following After the

CURTAILMENT of a TRANSACTION has ended, the INTERCHANGE
TRANSACTIONS energy profile will remain at its curtailed value until:
The INTERCHANGE TRANSACTION expires, or
The INTERCHANGE TRANSACTION crosses midnight, at which time its

energy profile automatically returns to its original value, or
The PURCHASING-SELLING ENTITY submits a new or revised tag.
Confidentiality of information. SECURITY COORDINATORS, CONTROL

AREAS, TRANSMISSION PROVIDERS, and entities serving as tag agents or
service providers as provided in the E-tag Reference Document shall
not disclose INTERCHANGE TRANSACTION information to any
PURCHASING-SELLING ENTITY without the permission of the
PURCHASING-SELLING ENTITY who submitted the tag.
Version 3
The Security Committee

decided to retain passive
approval, and reverted to
the wording in present
version of Policy 3. This
would help ensure that a
Transaction would not be
denied simply because a
Transmission Provider or
Control Area had taken no
action to approve it.
P312
Security Committee
Change
For clarification
As worded in present
Section 7, all PSEs who are
party to the Transaction
could get the tag.
Procedures for canceling

(and terminating)
Interchange Transaction
moved to new Section D.
B.
Introduction
This section explains CONTROL AREA requirements for implementing the
INTERCHANGE SCHEDULES that result from the INTERCHANGE TRANSACTIONS
tagged by the PURCHASING-SELLING ENTITIES in Section A. Many of these
functions are performed automatically as part of the Tagging system.
Requirements
1.
CONTROL AREAS must be adjacent. INTERCHANGE SCHEDULES shall

only be implemented between ADJACENT CONTROL AREAS.
2.
Sharing INTERCHANGE SCHEDULES details. The SENDING CONTROL

AREA and RECEIVING CONTROL AREA must provide the details of their
INTERCHANGE SCHEDULES via the Interregional Security Network as
specified in Policy 4.B.
3.
Providing tags for Approved Transactions to the Security

Coordinator. The SINK CONTROL AREA shall provide its SECURITY
COORDINATOR the information from the INTERCHANGE TRANSACTION
tag electronically for each Approved INTERCHANGE TRANSACTION.
4.
INTERCHANGE SCHEDULE confirmation and implementation. The

RECEIVING CONTROL AREA is responsible for initiating the
CONFIRMATION and IMPLEMENTATION of the INTERCHANGE SCHEDULE
with the SENDING CONTROL AREA.
4.1.
INTERCHANGE SCHEDULE agreement. The SENDING CONTROL

AREA and RECEIVING CONTROL AREA shall agree with each
other on the:
Interchange Schedule start and end time
Ramp start time and rate
Energy profile
This agreement shall be made before either the SENDING

CONTROL AREA or RECEIVING CONTROL AREA makes any
generation changes to implement the INTERCHANGE SCHEDULE.
4.1.1. INTERCHANGE SCHEDULE standards. The SENDING
CONTROL AREA and RECEIVING CONTROL AREA shall
comply with the INTERCHANGE SCHEDULE Standards in
Policy 3C, Interchange Schedule Standards.
4.1.2. Operating Reliability Criteria. CONTROL AREAS shall
operate such that INTERCHANGE SCHEDULES or schedule
changes do not knowingly cause any other systems to
violate established operating reliability criteria.
Version 3
Section 4 reworked
for better flow and
clarity.
P313
Removed reference
to bilateral
inadvertent payback.
They are Interchange
Schedules and
follow these same
rules.
Curtailment
procedures moved to
new Section D.
B. Interchange Schedules
4.1.3. DC tie operator. SENDING CONTROL AREAS and

RECEIVING CONTROL AREAS shall coordinate with any
dc tie operators on the SCHEDULING PATH.
Version 3
P314
Existing Policy (V2a) sets

defaults and allows Control
Areas to agree otherwise.
C.
This version sets specific

Standards that are not optional,
except for Req. 3 .
Introduction
Note highlighted sections.
All CONTROL AREAS must account for their

INTERCHANGE SCHEDULES the same way to enable
them to confirm their NET INTERCHANGE SCHEDULES
each day with their ADJACENT CONTROL AREAS as
required in Policy 1F, Inadvertent Interchange.
NERC requires block INTERCHANGE SCHEDULE
accounting, which assumes, for energy accounting
purposes, that the beginning and ending ramps have zero
duration. This, in effect, moves the energy associated with
the starting and ending ramps into their adjacent starting
and ending clock hours of the INTERCHANGE SCHEDULE.
MP
100 MW
RA
1 Hour
Schedule
Start Time
Interchange Schedule resulting from 100 MW

Interchange Transaction for two hours showing
ramp start time and durations and energy
accounting for each hour.
100 MW
7:00
7:20
7:40
INTERCHANGE SCHEDULE start and end time. INTERCHANGE

SCHEDULES shall begin and end at a time agreed to by the SOURCE
CONTROL AREA, SINK CONTROL AREA, and the INTERMEDIARY
CONTROL AREAS.
2.
Ramp start times. CONTROL AREAS shall ramp the INTERCHANGE

equally across the start and end times of the schedule.
3.
Ramp duration. CONTROL AREAS shall use the ramp duration

established by their INTERCONNECTION as follows unless they agree
otherwise:
P315
8:00
8:20
8:40
9:00
9:20
Block accounting moves the ramp energy into the

adjacent clock hours.
Requirements
Version 3
Schedule
End Time
TIME
Finally, because INTERCHANGE TRANSACTIONS often cross two or more time

zones, NERC requires that all INTERCHANGE SCHEDULES be communicated in
Central Standard Time throughout the year. (Daylight Saving Time will not be
used because 1) it creates 23- and 25-hour days during the transition, 2) the
transition itself does not occur uniformly across the time zones, and 3) not all
areas observe DST.)
1.
100 MWH
MP
INTERCHANGE SCHEDULES usually start and end on the

clock hour. However, PURCHASING-SELLING ENTITIES
may wish to begin or end an INTERCHANGE
TRANSACTION at other times, and the CONTROL AREAS
should try to accommodate the resulting off-hour
INTERCHANGE SCHEDULES if possible.
100 MWH
Tag
Submitted
RA
When the SENDING CONTROL AREA and RECEIVING

CONTROL AREA implement an INTERCHANGE SCHEDULE
between each other, they must begin their generation
adjustments at the same time using the same ramp rates. A
mismatch of these parameters will cause a frequency error
in the INTERCONNECTION.
Provide greater flexibility for

the marketplace. Existing
Policy assumes clock hour
start/end.
Security Committee Change

Security Committee returned
this concept. While it approves
of a default, the Control Area
should have leeway to change
the ramp rate if needed.
Accommodate
Interconnection
differences.
3.1.
Interchange Schedules within the Eastern and ERCOT

INTERCONNECTIONS. 10-minute ramp duration.
3.2.
Interchange Schedules within the Western

INTERCONNECTION. 20-minute ramp duration.
3.3.
Interchange Schedules that cross an INTERCONNECTION

boundary. The CONTROL AREAS that implement INTERCHANGE
SCHEDULES that cross an INTERCONNECTION boundary must use
the same start time and ramp durations.
3.4.
Exceptions for Compliance with Disturbance Control

Standard and Line Load Relief. Ramp durations for
INTERCHANGE SCHEDULES implemented for compliance with
NERCs Disturbance Control Standard (recovery from a
disturbance condition) and INTERCHANGE TRANSACTION
curtailment in response to line loading relief procedures may be
shorter, but must be identical for the SENDING CONTROL AREA
and RECEIVING CONTROL AREA [See also Policy1E2,
Generation Control Performance Performance Standard]
But must use same

time when crossing
Interconnection
boundary. Otherwise,
dc tie Control Area is
left to supply
difference.
Allows for faster

ramps to meet DCS.
4.
Time Zone standard. All electronic INTERCHANGE SCHEDULES

communications shall be communicated, both verbally and electronically,
in Central Standard Time. (Daylight saving time will not be used.)
Security Committee
Change
5.
Interchange Schedule accounting. Block accounting shall be used.
Similar to change in
3A1.3
Most on IOSubcommittee prefer

block accounting for its simplicity.
Minority opinions:
Integrated accounting is more
accurate than block accounting.
Version 3
P316
New Section. Includes existing

Sections A.6 and B.7.
D.
Many more details on how to

handle curtailments and
cancellations. Terminations added.
1.
2.
Interchange Transaction
Cancellation, Termination, and
Curtailment
Many functions handled by E-tag.
INTERCHANGE TRANSACTION cancellation and termination.

When a PURCHASING-SELLING ENTITY must terminate an
INTERCHANGE TRANSACTION that is in progress, or cancel an
INTERCHANGE TRANSACTION that has not started, the
PURCHASING-SELLING ENTITY shall contact the SINK CONTROL AREA to
which it submitted the INTERCHANGE TRANSACTION tag. The SINK
CONTROL AREA shall then directly contact its SECURITY COORDINATOR
and all INTERMEDIARY CONTROL AREAS and TRANSMISSION PROVIDERS
on the SCHEDULING PATH. . A description of those entities who may
cancel or terminate an Interchange Transaction is found in Appendix 3D,
Security Committee
changes
Requested by MIC.
Cancallation and
Termination
Procedures
PSE who submitted
tag contacts Sink
Control Area.
INTERCHANGE TRANSACTION Curtailments. When a SECURITY

COORDINATOR, CONTROL AREA, or TRANSMISSION PROVIDER must
Sink Control Area
contacts its Security
curtail or hold an INTERCHANGE TRANSACTION due to loss of generation
Coordinator.
or load, or to mitigate an OPERATING SECURITY LIMIT violation, it will
notify the SINK CONTROL AREA. The SINK CONTROL AREA shall
Sink Control Area
contacts all Intermediary
immediately contact the SOURCE CONTROL AREA to agree upon an
Control Areas and
Transmission Providers
implementation time for the curtailment. The SINK CONTROL AREA will
on the Scheduling Path.
also contact all INTERMEDIARY CONTROL AREAS and TRANSMISSION
PROVIDERS on the SCHEDULING PATH as well as the PURCHASINGSELLING ENTITY who submitted the INTERCHANGE TRANSACTION tag.
The SINK CONTROL AREA and SOURCE CONTROL AREA shall then adjust
their resulting INTERCHANGE SCHEDULES with their ADJACENT
CONTROL AREAS. A description of those entities who may curtail
Curtailment Procedures
an Interchange Transaction is found in Appendix 3D, Transaction
Tag Actions. [See also Policy 9, Security Coordinator
Initiated by Control
Initiated by
Area or
Security
Procedures]
Transmission
Coordinator.
Provider.
2.1.
2.2.
Version 3
Curtailments not initiated by the SECURITY

COORDINATOR. If the INTERCHANGE TRANSACTION was
curtailed by a CONTROL AREA or TRANSMISSION
PROVIDER, in addition to the actions specified in
Requirement 2 above, that entity shall immediately inform
its SECURITY COORDINATOR. The SINK CONTROL AREA
shall issue a revised INTERCHANGE TRANSACTION tag at
the curtailed value.
INTERCHANGE TRANSACTION curtailment notification.
The SINK CONTROL AREA shall initiate the INTERCHANGE
TRANSACTION curtailment notification directly with the
SOURCE CONTROL AREA and any dc tie operators prior to
the start of the curtailment. (This notification must include
a common time (specified as xxxx hours) at which the
curtailment or adjustment is to take place, as well as ramp
P317
Security Coordinator
notifies Sink Control
Area.
CA or TP
contacts Sink
Control Area.
Sink Control Area

contacts Source
Contorl Area.
Sink Control Area

notifies its Security
Coordinator.
Sink Control Area

notifies PSE who
submitted tag.
Sink Control Area

contacts all Intermediary
Control Areas and
Transmission Providers
on the Scheduling Path
rates, to avoid affecting INTERCONNECTION frequency and

causing INADVERTENT INTERCHANGE.) .
2.3.
Version 3
Returning INTERCHANGE TRANSACTIONS after curtailment.

Following the curtailment, the CONTROL AREA shall continue to
implement the Interchange Transaction as specified in
Requirement 3.A.7 above.
P318
E.
No changes in this
Section.
Transfer Capability
Requirements
[Available Transfer Capability Definitions and Determination, NERC, June 1996.]
1.
2.
Maximum scheduled interchange. The maximum NET INTERCHANGE SCHEDULE between two
CONTROL AREAS shall not exceed the lesser of the following:
1.1.
Total capacity of facilities. The total capacity of both the owned and arranged-for
transmission facilities in service between the two CONTROL AREAS, or
1.2.
Total Transfer Capability. The established network Total Transfer Capability (TTC)
between the CONTROL AREAS which considers other transmission facilities available to
them under specific arrangements, and the overall physical constraints of the transmission
network. Total Transfer Capability is defined in Available Transfer Capability
Definitions and Determination, NERC, June 1996.
Available Transfer Capability. Available Transfer Capability (ATC) is an indication of the

additional transfer capability remaining in the physical transmission network for further
commercial activity over and above already committed uses between two CONTROL AREAS.
Available Transfer Capability is defined in Available Transfer Capability Definitions and
Determination, NERC, June 1996.
Version 3
P319
Appendix 3A2 Tagging Across

Interconnection Boundaries
Between ERCOT and Eastern Interconnections
For Board of Trustees

approval
February 7 8, 2000
(Note: already in effect on
interim basis)
A PURCHASING-SELLING ENTITY that is seeking transmission arrangements to

schedule energy between the ERCOT and Eastern Interconnections will coordinate
through the SPP Security Coordinator. Requests for service must be made to the
SPP Security Coordinator for service into or through SPP (including service across
either the North or East DC Ties) via the SPP OASIS. Request for service must also
be made in ERCOT via the ERCOT OASIS. The SPP Security Coordinator will
coordinate approval of reservations and schedules involving the SPP portion of
transmission service (including the DC ties) and service in ERCOT.
The following procedures are followed when scheduling transmission service
between SPP and ERCOT:
The PURCHASING-SELLING ENTITY must receive approval for DC tie service

and transmission service in SPP from the SPP Security Coordinator for the
proposed transaction and arrange required ancillary services.
For all transmission service requests, the PURCHASING-SELLING ENTITY will

create a NERC Tag and submit it to the SPP Security Coordinator. The SPP
Security Coordinator will validate certain information on the tag and check that
a reservation exists before approving the tag. The approved tag will be
available to the parties to the transaction and the ERCOT ISO.
Simultaneous with submitting requests using the NERC TAG to the SPP
Security Coordinator (for next hour, non-firm and all other transmission service
requests), the PURCHASING-SELLING ENTITY submits requests to the ERCOT
ISO via the ERCOT OASIS. The MW profile information submitted to ERCOT
must exactly match the information on the NERC Tag supplied to ERCOT by
the SPP Security Coordinator. (See note. )
Tagging Across
ERCOT/Eastern
Interconnection
PSE Receives
Interface
Approval from SPP
dc Tie Operator and
ISO
PSE Creates Tag

and Sends to
SPP SC
SPP SC validates
SPP SC sends tag to ERCOT
PSE Sends Tag to Others PSE
Submits Tag
via ERCOT OASIS
SPP SC and ERCOT

ISO Coordinate ATC
ERCOT ISO
Notifies S/R CAs
in ERCOT
S/R CAs Confirm

Schedule with CAs in
EI and dc Tie Operator
dc Tie Operator Sets

Flows per NERC Tag
SPP SC Enters Tag
into IDC
The SPP Security Coordinator coordinates approval of the transaction if ATC is

available in SPP and across the DC tie, and works with the ERCOT ISO to
coordinate ATC calculations in ERCOT.
The ERCOT ISO notifies the delivering/receiving ERCOT control area of the approved transaction
and provides a copy of the NERC Tag and ERCOT schedule request.
The delivering/receiving ERCOT control area communicates with the delivering/receiving control
area outside of ERCOT, confirms the transaction/schedule, and confirms with the DC tie operator.
The DC tie operator will follow the NERC Tag when setting flows across the tie.
The SPP Security Coordinator will use the NERC Tag to populate the iIDC and to determine
constrained facility ATC in the operating horizon.
ERCOT ISO requires transactions/schedules involving use of the DC ties to include the NERC Tag
reference in the comments field on the ERCOT schedule request.
Note: In ERCOT, there are two types of wholesale transmission servicesplanned and unplanned. Planned
Transmission Service is service for nominated generating resources to specified loads. All other transmission
service is unplanned.
Version 1
A3A2-1
Approved by Security Committee
For Interim Implementation: November 17, 1999
Appendix 3A2 Tagging Across Interconnection Boundaries
Between Western and Eastern Interconnections

The NERC Operating Committee granted a waiver on NERC electronic tagging (E-Tag) until the start of
the second quarter of 2000. The Operating Committee also agreed to provide the WSCC with periodic
updates of the lists of control areas, transmission providers, and purchasing-selling entities (TIS lists)
that are needed by the tagging software. These updates will continue until the WSCC implements the ETag system.
Due to the NERC waiver granted to WSCC members, tagging requirements shall remain unchanged
within WSCC (Reference the WSCC NERC Policy 3 Implementation Plan for details). These
requirements shall remain in effect throughout the duration of the waiver unless otherwise posted.
Tagging requirements on day ahead transactions flowing between WSCC and Eastern Interconnections
shall remain unchanged during the waiver period with the following exceptions:
During the interim period, fax delivery of the NERC Tags will be the minimum required delivery
application utilized for those INTERCHANGE TRANSACTIONS that cross the Interconnection EasternWestern Interconnection boundary.
Interchange Transactions where the sink is in the Western

Interconnection
The WSCC PSE responsible for submitting the tag will fax the NERC tag to all
the appropriate parties in the Eastern interconnection. The WSCC PURCHASINGSELLING ENTITY responsible for submitting the tag will fax the NERC tag to all
the appropriate parties in WSCC and the sink PURCHASING-SELLING ENTITY in
the Eastern Interconnection (last PSE before the DC Tie). The Eastern
Interconnection sink PURCHASING-SELLING ENTITY shall be responsible for
providing the INTERCHANGE TRANSACTION tag (E-Tag).
This revision made by the

Security Committee on
November 16-17, 1999
Interchange Transactions where the sink is in the Eastern Interconnection
The PURCHASING-SELLING ENTITY serving the load shall be responsible for providing the
INTERCHANGE TRANSACTION tag (see Policy 2A. Requirements 1.4 and 2). The Eastern sink
PURCHASING-SELLING ENTITY will fax the tag (or E-tag) to all appropriate parties in the WSCC.
Hourly, real-time and day-ahead INTERCHANGE TRANSACTIONS shall be communicated and

confirmed between PURCHASING-SELLING ENTITIES and CONTROL AREAS as is currently practiced
within WSCC and between WSCC and Eastern Interconnections.
Version 1
A3A2-2
Approved by Security Committee

For Interim Implementation: November 17, 1999
Item 4. Policy Interpretation Task Force Findings

The Boards Policy Interpretation Task Force decided a number of issues regarding how Enron
may operate its generation-only control areas. [Attachment: Letter from PITF to Messrs.
Skilling, Boston, and Reinke]
Discussion and Action

The Subcommittee should review the PITFs decisions and determine if changes are needed in
Policy 3 to either 1) embody the Task Forces interpretations in the Policy, or 2) revise the Policy
in those areas where the Subcommittee believes the Task Forces interpretation was not the
Policys intent.

P r i n c e t o n F o r r e s t a l V i l l a g e , 1 1 6 - 3 9 0 V i l l a g e B o u l e va r d , P r i n c e t o n , N e w J e r s e y 0 8 5 4 0 - 5 7 3 1
October 26, 1999
Mr. Jeffrey K. Skilling

President & Chief Operating Officer
Enron Corp.
1400 Smith Street
Houston, Texas 77002
Mr. W. Terry Boston

Executive Vice President
Transmission /Power Supply Group
Tennessee Valley Authority
1101 Market Street
Chattanooga, Tennessee 37402-2801
Mr. William F. Reinke

Chairman
Southeastern Electric Reliability Council
600 North Eighteenth Street
P.O. Box 2641
Birmingham, Alabama 35291
Gentlemen:
Dispute Between Enron and TVA
This letter provides interpretations by NERCs Policy Interpretation Task Force of certain existing
NERC Policies that are implicated in a dispute between Enron Corp. and the Tennessee Valley Authority over
the terms and conditions under which Enron may operate three control areas located within the control area
operated by TVA. NERCs Board of Trustees established the Policy Interpretation Task Force at its September
1999 meeting to, among other things, act on behalf of the Board to provide interpretations of existing NERC
Policies concerning control areas and related issues. Its membership comprises Howard Hawks (Chairman),
John Q. Anderson, Paul Barber, Tom Berry, Richard Drouin, Charles Durkin, Mike Greene, and Roy Thilly, all
members of the NERC Board of Trustees.
The issues presented in the dispute between Enron and TVA are important ones that affect the entire
electric industry. Fundamentally they concern the ability of the institutions and procedures designed to assure
the reliability of the transmission system to keep pace with the developments and demands of the burgeoning
competitive marketplace in electricity. To that end, NERC has established a Control Area Criteria Task Force
that is examining the whole range of issues and functions associated with the activity that has heretofore been
performed by control areas. For that reason, the interpretations of current NERC Policies contained in this
letter are limited to the specific factual circumstances presented by the parties, as described below. Equally, the
policy
Phone 609-452-8060 Y Fax 609-452-9550 Y URL www.nerc.com
Messrs. Skilling, Boston, and Reinke

October 26, 1999
Page 2
recommendations that result from the work of the Control Area Criteria Task Force and gain approval of the
NERC Board of Trustees will apply to all control areas. There will be no grandfathering of control areas by
virtue of them having satisfied earlier, superceded criteria. The Task Force followed two central principles in
its work: First, all market participants must be treated comparably, and second, all market participants share
responsibility for maintaining the reliability of the interconnected network.
Process Followed
Enron brought the dispute to the Board of Trustees in a letter dated August 31, 1999, from Jeff Skilling
to Michehl Gent. At that time, the matter was also being considered within the Southeastern Electric Reliability
Council. In order to provide SERC and the parties an opportunity to resolve the matter within the Region, I
requested that SERC, Enron, and TVA work to resolve the dispute and provide the Task Force with the results
of their efforts by September 25, 1999. By mutual agreement, that date was extended to October 4, 1999.
Because the parties and SERC had not resolved the dispute by that date, I asked each to send to the Task Force
a statement of its views on the issues presented in the dispute. Enron and TVA sent letters in response dated
October 6, 1999. SERC supplemented the responses on October 8, 1999. The interpretations in this letter are
based upon the statements of facts and issues presented in those three letters.
Statement of Facts
Enron owns three generators located within the TVA control area. Enron sought to establish each as a
separate control area and installed energy management systems, control room equipment, and appropriate
staffing for the three plants. SERC audited the three Enron sites and certified that each met the criteria for a
control area. Each control area has one combustion turbine and is radially connected to TVAs system, as
follows: Brownsville, 460 MW generator, 631 MW transformer; Caledonia, 450 MW generator, 593 MW

October 26, 1999
Page 3
states that Security Coordinators cannot properly analyze these transactions, and they are not properly
represented in the Interchange Distribution Calculator used by Security Coordinators to assess the impact of
parallel flows on regional transmission facilities. TVA states that this method of scheduling leaves the TVA
system and other interconnected systems in an unanalyzed state. TVA states that the practice also can lead to
seriously inaccurate ATC postings.
Enron alleges that TVAs decision to unilaterally reduce ATCs, after several weeks of reliable
operation, was intended to exclude Enron from competing with TVA, and reduced the amount that Enron could
schedule into its control areas from thousands of megawatts to hundreds of megawatts. Enron further asserts
that TVA experienced no operational difficulties during the period when it initially accorded Enron all the
rights it would accord other certified control areas, including the opportunity to utilize ATC of all transmission
paths into and out of the control area when scheduling its interchange.
Issues Presented
Based upon the letters from Enron, TVA, and SERC, the Task Force has identified the following issues
concerning NERC policies that are relevant to this dispute.
1. Whether, in the circumstances of this case, ATC should be limited by the thermal transfer
capability of the interconnection (transformer) between each of the Enron control areas and TVA?
2. Whether NERC policy prohibits scheduling to a generation-only control area?
3. What should be the status of a control area when its generation is not operating?
4. Whether it is appropriate for Enron to net the schedules into and out of its control areas, such that
the net schedule of each remains within the thermal limits of the interconnection between each
Enron control area and TVA?
5. Whether it is appropriate for Enron to make reservations or schedules over the TVA system into the
Enron control area, knowing that the transaction will not sink there? Similarly, is it appropriate for
Enron to make reservations and schedules out of the Enron control area, knowing that it is not the
source of the transaction? A corollary question is whether Enron may schedule into its control area
on a day-ahead basis, with the offsetting schedule submitted in advance of implementation of the
schedule.
Control Area Definition and Requirements
NERC defines a control area as an electrical system bounded by interconnection (tie-line) metering
and telemetry. It controls generation directly to maintain its Interchange Schedule (i.e., its planned interchange)
with other control areas and contributes to frequency regulation of the Interconnection. (Operating Manual,
Terms Used in the Policies, page P3-1.) A control area has the following obligations (Operating Manual,
Introduction to the Operating Policies, page I-3):
To directly control its generation to continuously balance its actual interchange and its scheduled
interchange, and
To help the entire Interconnection regulate and stabilize the Interconnections alternating-current
frequency.
To be recognized as a control area, the Region and the Performance Subcommittee representative must review
and confirm that the system meets the following requirements (Operating Manual, Introduction to the
Operating Policies, I-5):
Operates generation;

October 26, 1999
Page 4
Has metered connections (ties) with other control areas and the necessary contracts to use those
connections;
Has the ability to control generation and match its net actual interchange to its net scheduled
interchange;
Has generator governors that are allowed to respond properly to Interconnection frequency
changes;
Uses tie-line bias control (unless doing so would be adverse to its or the Interconnections
reliability); and
Has a control center with 24-hour-per-day staffing.
Discussion of Issues and Interpretation of Policy

Issue No. 1: Whether, in the circumstances of this case, ATC should be limited by the thermal
transfer capability of the interconnection between Enron and TVA?
The Task Force concludes that, on the facts of this case, ATC should not be limited by the thermal
transfer capability of the interconnection between Enron and TVA. The determination of ATC is governed by
the NERC ATC Principles in the 1996 ATC Reference Document and the NERC Planning Standards. Although
some discretion is granted transmission providers in determining ATC, they must not violate any NERC
Policies and must comply with Regional guidelines. In this case, Enron is a control area without load.
Therefore, any transaction listing the Enron control area as the sink is actually parking the transaction, in the
sense that the designation is temporary and incomplete. This being the case, the ATC for the Point-OfReceipt/Point-Of-Delivery connection between Enron and TVA for these transactions is irrelevant, since no
power will actually flow there, unless Enrons generator is running. Enron should be afforded the ability to
reserve transmission service and schedule the same amounts of interchange transactions into and out of its
control area as TVA can with its neighbors. These ATCs must be determined taking into consideration overall
system conditions, including contingencies and constraints elsewhere on the grid.
The ATC principles do not specifically address the netting of transmission service reservations, nor do
they address the determination of ATC for sink points having no load. However, the determination of ATC
may not violate NERC policy. NERC Operating Policy 3 limits the maximum net scheduled interchange
between two control areas to the lesser of the physical transfer capability between two control areas or the
actual limitation, taking into account all facilities on the network. Certainly, the amount of transmission
available for sale (ATC) cannot exceed this amount, or NERC policy will be violated. Currently, however,
transmission providers are given latitude in the degree to which they will consider countervailing transactions
(netting) in the determination of ATC values. Transmission providers must consider the likelihood that
countervailing transmission service reservations will actually be used for interchange transactions that will
produce flows in the opposite direction. (See the additional discussion of net scheduling under Issue 4, below.)
Issue No. 2: Whether NERC policy prohibits scheduling to a generation-only control area?
The existing NERC control area criteria do not require a control area to have load, and NERC Policies
do not prohibit a generation-only control area from scheduling into its boundaries. Historically, one of the
principal functions of a control area has been to ensure that generation and load within its area remain in
balance from moment to moment, and to provide the interchange scheduling to either serve its load or sell
generation. When Enron pre-schedules large blocks of power into its control area, it is not so much fictional, as
TVA alleges, as it is incomplete. Because there is no load within the Enron control area, power scheduled in
cannot sink there. Before the transaction can be implemented, Enron must schedule offsetting blocks of power
out of its control area, or run its generation, so as to remain in balance.

October 26, 1999
Page 5
Issue No. 3: What should be the status of a control area when its generation is not operating?
The NERC control area criteria do not require that the generation within a control area be operating at
all times. A control area must have the continuing ability to meet its obligations, but that does not mean that its
generation must be on-line at all times. Further, a control area must meet control area performance standards on
an ongoing basis. However, once a control area has been properly certified, it retains its control area status until
it no longer has the ability to meet its control area obligations. (Some Regions have a periodic, e.g., three-year,
recertification requirement.) Accordingly, it is consistent with NERC policy for Enron to retain its control area
status when its generation is not on-line.
Issue No. 4: Whether it is appropriate for Enron to net schedules into and out of its control area,
such that the net schedule does not exceed the thermal limits of the interconnection between
Enron and TVA?
Under the circumstances presented in this case, current NERC policy permits Enron to net schedules
into and out of its control areas, subject to two conditions: First, the net schedule must not exceed the thermal
limits of the interconnection between Enron and TVA. Second, the net schedule must not cause an overload on
other paths in the network.
Policy 3D, Interchange Transfer Capability, allows a Control Area to net its Interchange
Schedules up to the limits of its interconnection with the grid. This is examined
from two viewpoints, the more conservative of which sets the limit. The
descriptions below reference the diagram on the right, which depicts three
control areas A, B, and C connected to each other with a single
transmission line. Consider an Interchange Schedule that is set up from A to B.
Policy 3D. Requirement 1.1 Total Capacity of the Facilities.

In the diagram on the right, if the line connecting A to B can carry 300 MW,
then A may have a net schedule of no more than 300 MW to B. This
Requirement does not take into consideration other parts of the network its
intent is to prevent two control areas from simply constructing a contract path
line of minimal capacity and scheduling far beyond the lines capacity assuming that the interchange will most
likely follow parallel paths, such as A C B.
Policy 3D. Requirement 1.2 Total Transfer Capability.

This part of the Policy prevents an Interchange Schedule from A to B from overloading the parallel paths.
Assume that the line from A to C can carry 100 MW. Further assume that the Transfer Distribution Factor from
A to C for an Interchange Schedule from A to B is 40%. (That is, when A is selling to B, 60% of that
transaction flows directly from A to B, and 40% actually flows over the parallel path A C B.) Therefore,
when A sells 300 MW to B, the A C line will carry 120 MW. This is 20 MW over the lines limit.
Therefore, the Total Transfer Capability from A to B is actually:
TTC =
100MW
= 250 MW
40%
Therefore, the Maximum Scheduled Interchange from A to B is the lesser of the two Requirements above, or
250 MW.

October 26, 1999
Page 6
Effects of Netting
Now consider the second example on the right where we have Control
Area D that is radially connected to Control Area C. Assume the line (or
connection) from C to D can carry 50 MW. First of all, an Interchange Schedule
from C to D has a 100% Transfer Distribution Factor on the C D line, and a 0%
TDF on all other lines. Therefore, we are only restricted to the rating of the C
D line itself. Policy 3 calculates limits on the maximum net scheduled
Interchange, which in this case is limited by the total capacity of the facilities
(Requirement 3D.1.1), or 50 MW. Thus, D can buy, say, 250 MW from A
(through C) and sell 250 MW to B (through C) with a net scheduled Interchange of
0 MW, which is within the 50 MW rating. In this example, D could buy 50 MW
more than it sold (if it had load) or sell 50 MW more than it purchased (if it had
generation), as long as other path limits in the network (AB, AC, or BC) were
not exceeded. In the Enron-TVA situation, there is no line per se the
interconnection consists of a bus at which the Enron step-up transformer is located.
B
C
D
Issue No. 5: Whether it is appropriate for Enron to make reservations or schedules over the TVA
system into the Enron control area, knowing that the transaction will not sink there? Similarly,
is it appropriate for Enron to make reservations and schedules out of the Enron control area,
knowing that is not the source of the transaction? A corollary question is whether Enron may
schedule into its control area on a day-ahead basis, with the offsetting schedule submitted in
advance of implementation of the schedule.
This is the most difficult and the most important of the issues presented by the dispute. On the one
hand, TVA is correct that accurate source and sink data must be available so that control areas and security
coordinators can analyze system operations for potential security violations before implementing an Interchange
Transaction. By definition, a generation-only control area has no load that means it cannot be a sink. On the
other hand, Enron wants to list its control area as a sink on a temporary basis until it schedules the offsetting
side of its transactions, in effect scheduling source-to-hub and hub-to-sink. Current NERC Operating Policies
do not require that Interchange Transactions be tagged with their true or ultimate sources and sinks. Thus, the
practice proposed by Enron is permissible under current policies.
From a reliability standpoint, Security Coordinators can do their jobs if all tags are available and
correctly identify sources and sinks, even if hubs are involved in the transactions. And that information must
be available from all control areas, not just Enron. Whenever a Purchasing-Selling Entity schedules into and
out of the same control area, there has been a loss of the source-sink relationship. However, from the
standpoint of analyzing the system for reliability purposes, it is as sufficient to have the tags for the hubbed Ato-C and C-to-B transaction as it is to have the tag for the actual A-to-B transaction. One of the things we are
struggling with as an industry is that such information is not always available for all transactions far enough in
advance of the implementation of the schedules to allow adequate analysis and coordination. Electronic
tagging should help. The question is, how long before the hour must that information be available?
What this policy interpretation requires in the short run are that all market participants be treated the
same and that all operate in good faith within the capability of available tools. Thus, it is permissible under
current NERC policy for Enron to schedule into its control area on a day-ahead basis, with the offsetting
schedule submitted in advance of implementation of the schedule, by the appropriate deadline. If the volume of
last-minute transactions makes it impossible to analyze flows on the system, then the scheduling window must

October 26, 1999
Page 7
be closed earlier, for everyone. It is not an acceptable solution to put system security at risk. Nor is it
acceptable to treat some entities in a discriminatory fashion.
Conclusion
This analysis ends where it began. All market participants must be treated comparably, and all market
participants share responsibility for the reliable operation of the interconnected network. The Control Area
Criteria Task Force has important work to do, and all in the industry must support that effort.
The Policy Interpretation Task Force expects Enron and TVA to resolve their differences in accordance
with these interpretations of existing NERC Policies.
Sincerely,
Howard Hawks
Howard L. Hawks
Chairman
Policy Interpretation Task Force
cc:
Gary L. Neale, Chairman, NERC Board of Trustees

James N. Maughn, Administrative Manager, SERC
Michehl R. Gent, President, NERC
NERC Board of Trustees Executive Committee
Item 5. Transaction Parking

Affiliate merchants can use their Control Area to line up generation sources or customers, or
both, in other Control Areas, which is what interchange scheduling is all about. This ability to
mix and match resources and loads is giving rise to independent power producers desire to
become Control Areas. One of the Control Area Criteria Task Forces goals is to unbundle the
basic operating functions to enable merchants to set up these generation and load portfolios
without having to form one or more Control Areas to do this. It will probably be many months
before these new concepts can be put into practice.
Until then, the Task Force has talked about the possibility of establishing a new kind of
Interchange Transaction, called a Parked Transaction. It would provide a means for merchants
to use any Control Area to develop a balanced interchange portfolio under existing NERC
Operating Policies. It would be defined as:
Parked Transaction. A Transaction that identifies either the Source Control Area (or generation)
or the Sink Control Area (or Load-Serving Entity) and is a precursor to the complete
Transaction. A Parked Transaction should
not be evaluated for security purposes.
The CACTF has not worked out the details. For
example, in the diagram on the right, merchant M has
parked a transaction from an IPP in Control Area B
at Control Area As doorstep. Control Area A is not
the intended sink. Some questions:
How are the transmission arrangements

handled?
Does M have to arrange for Point-to-Point

Transmission Service from B to A even if it
knows that the Interchange Transaction will
not really sink in A, but rather in C? (C is not on the diagram.)
If M arranges for Firm Point-to-Point Transmission Service from B to A and then, when
the deal is finally consummated, tags the Interchange Transaction as B to C, does the
Transmission Service revert to Secondary Points of Receipt and Delivery?

The Control Area Criteria Task Force will discuss this concept at its February 15 16, 2000
meeting. Task Force Chairman Jim Byrd and Gordon Scott from the NERC staff will be at that
meeting and will let the Interconnected Operations Subcommittee know if the CACTF plans to
pursue this concept. If it does, the Interconnected Operations Subcommittee needs to develop the
Policy language and work out the details.
Item 6. Transaction Terminations

The NERC staff has received two complaints from merchants regarding the manner in which
Interchange Transaction Terminations are being handled. Tenaska formally requested an
interpretation of Policy 3D1 which deals with Transaction Terminations and Cancellations. El
Paso Energy wrote the NERC staff with a similar issue. [Attachments: 1) Tenaska letter; 2) El
Paso Energy (Bob Erbrick) memo]
The NERC staff has drafted a response to the Tenaska request for interpretation for the
Interconnected Operations Subcommittees consideration. [Attachments: 1) Draft interpretation;
2) draft Policy Interpretation Procedure]

The Subcommittee needs to do three things:
1. Review the interpretation response to Tenaskas letter, revise as necessary, and approve
for submission to the Security Committee Executive Committee.
2. Review El Paso Energy memo.
3. Considering these letters and the Policy Interpretation, consider whether changes to
Policy 3 are needed. If so, begin scoping out the concepts for NERC staff to draft for
consideration at the next Subcommittee meeting.
January 12, 2000

Mr. Don Benjamin
North American Electric Reliability Council
Princeton Forrestal Village
116-390 Village Boulevard
Princeton, NJ 08540-5731
Dear Don:
It has come to our attention that a serious problem exists with respect to various control
area operators adamant refusal to adjust interchange schedules under NERC policies,
and more specifically NERC Operating Policy 3. This problem occurs as a result of
control areas that are unwilling to reduce an interchange schedule even when they are
informed that the generation source for a particular schedule has been lost. In at least one
instance, the control area operators rationale for refusing to adjust the interchange
schedule is that NERC policy will not allow such a change. The problem may be best
illustrated by the following example:
A marketer purchases capacity and energy from Generator A and
contracts to sell such capacity and energy to Load C. Generator A is
located in Control Area X and Load C is located in Control Area Z.
Control Area X is connected to Control Area Y which in turn is
connected to Control Area Z.
The marketer arranges for
transmission service with the transmission providers in Control
Areas X, Y, and Z in accordance with the transmission providers
open access transmission tariffs. The marketer then submits an
interchange schedule for the next several hours in accordance with
NERC policies. At 15 minutes past the top of an hour, Generator A
trips. Within 2 minutes, Generator A notifies Control Area X that it
has lost the generation source and that the schedule needs to be
adjusted to zero for the remainder of the hour.
What should happen next under the NERC policies? Should Control Area X (source
control area) notify Control Area Z (sink control area) that the generator has been lost
and that the interchange schedule will be adjusted to zero at a particular time? Should
Control Area Z be contacted before Control Area X? Can any of the control areas refuse
to adjust the schedule upon request? Do NERC policies provide a maximum time for a
schedule adjustment? Does a schedule adjustment require a new Tag to be submitted?
At this time, various control areas around the country are filing tariffs with the FERC
wherein merchant generators are being required to purchase generation imbalance service
while interchange schedules are being adjusted. Further, some control areas are
interpreting NERC policies to state that a control area in a schedule chain may refuse to
adjust a schedule. As a result, the source control area where the generator was lost will
not adjust the schedule and will require the merchant generator to purchase generation
imbalance service, a service which is often accompanied by a high price tag.
In light of this situation, we are requesting NERC to provide us with an interpretation of
the NERC policies based on the above example in order to correct any confusion that
may exist. Furthermore, if NERC believes that the intent of its policies is not being
properly communicated through its written policies, then we respectfully request that
NERC immediately correct its written policies to properly reflect the intent of this
schedule adjustment issue.
As stated above, this is a very serious issue and needs to be addressed immediately.
Please do not hesitate to contact me at 817-462-1512 if you have any questions or need
more information.
Sincerely,
Scott M. Helyer, Manager

Transmission and Marketing Services
Cc:
Howard Hawks
Darrell Bevelhymer
Neil L. Levy, Esq.
On 1/28/2000 El Paso Merchant Energy (EPME) had several transactions a total of 554
MW originating from the Com Ed (CE) Control Area (Table 1), at approximately 09:50
CST we were notified that our unit would be ramping down at 10:00 CST due to
operational problems. We then immediately started calling the sinks of our transactions
and the transmission providers on which we had scheduled our transactions to cut our
transaction at 10:00 CST. CE told us they would not cut the schedule until they received
a terminated tag. Although we had called CE before 10:00 CST to curtail the transactions
CE didnt acknowledge the cut until 10:30 CST. CE told us that they would not cut the
transaction until the tag was terminated. The one tag (CE_EPMEPS_0000085_SOCO)
created by EPME was terminated at 10:02 CST, the other tags had to be terminated by
the PSE that submitted them. CE later told us that the cut had taken place at 10:30 CST
and they had checked out with all 4 sinks. After talking with the sinks only1had agreed to
the 10:30 CST cut (SOCO), the other 3 sinks (IP, MECS and AEP) did not agree to the
10:30 CST cut and complained about their build up of inadvertent interchange due to CE
continuing the schedule until 10:30 CST. El Paso Merchant Energy believes that not
accepting the cut of the schedule by phone and insisting on a terminated tag is beyond the
requirements set forth by NERC Policy 3 and is a misuse of the current ETAG system.
We also believe this practice is damaging to system reliability. As a matter of course we
at El Paso Merchant Energy contact first the sink and then each CA back to the source to
ensure that everyone involved has been notified about the schedule cut.
Table 1 EPME Transactions

Source
CE
AMRN
TVA
Sink
SOCO
Sink MW
200
CE
AEP
CE
CE
MECS
82
AEP IP
100
150
NOTE: This is a draft Policy

interpretation. It has not
been approved by the NERC
Operating Committee.
Interpretation of Policy 3
Re: Interchange Transaction Terminations
Draft from NERC staff for Interconnected Operations Subcommittee consideration
Summary of the Issue

Tenaska is requesting an interpretation of Policy 3, Interchange, with regard to Control Area obligations
following the Termination of an Interchange Transaction by a Purchasing-Selling Entity. The following is
an excerpt from its letter to NERC (illustration for the example provided by NERC staff):
It has come to our attention that a serious problem exists with respect to various control area operators
adamant refusal to adjust interchange schedules under NERC policies, and more specifically NERC
Operating Policy 3. This problem occurs as a result of control areas that are unwilling to reduce an
interchange schedule even when they are informed that the generation source for a particular schedule has
been lost. In at least one instance, the control area operators rationale for refusing to adjust the
interchange schedule is that NERC policy will not allow such a change. The problem may be best
illustrated by the following example:
A marketer purchases capacity and energy from Generator A and contracts to sell such
capacity and energy to Load C. Generator A is located in Control Area X and Load
C is located in Control Area Z. Control Area X is connected to Control Area Y
A
X
which in turn is connected to Control Area Z. The marketer arranges for
transmission service with the transmission providers in Control Areas X, Y, and Z
in accordance with the transmission providers open access transmission tariffs.
Y
The marketer then submits an interchange schedule for the next several hours in
accordance with NERC policies. At 15 minutes past the top of an hour, Generator
A trips. Within 2 minutes, Generator A notifies Control Area X that it has lost the
C
Z
generation source and that the schedule needs to be adjusted to zero for the
remainder of the hour.
Tenaska then asks the following questions:
1. What should happen next under the NERC policies?
2. Should Control Area X (source control area) notify Control Area Z (sink control area) that the
generator has been lost and that the interchange schedule will be adjusted to zero at a particular
time?
3. Should Control Area Z be contacted before Control Area X?
4. Can any of the control areas refuse to adjust the schedule upon request?
5. Do NERC policies provide a maximum time for a schedule adjustment?
6. Does a schedule adjustment require a new Tag to be submitted?
-1-
NERC Staff Draft: January 31, 2000
How Policy 3 Deals with these Issues

The current version of Policy 3 (Version 2a2) Requirement A6 in the NERC Operating Manual refers to
Interchange Transaction Cancellations, and, from the context of the Policy, we conclude that a
Cancellation occurs when a Purchasing-Selling Entity (PSE) must interrupt a Transaction that is in
progress:
6.
INTERCHANGE TRANSACTION cancellation. When a PURCHASING-SELLING ENTITY must cancel

an INTERCHANGE TRANSACTION that is in progress, the PURCHASING-SELLING ENTITY shall
contact the SINK CONTROL AREA to which it submitted the INTERCHANGE TRANSACTION tag.
The S INK CONTROL AREA shall then directly contact the SOURCE CONTROL AREA and its
SECURITY COORDINATOR. If the SOURCE CONTROL AREA and SINK CONTROL AREA are not
adjacent, they then contact their ADJACENT CONTROL AREAS on the SCHEDULING PATH.
The Policy specifies the Control Area notification that must take place, but does not explain what the
Control Areas are required to do.
This version of Policy 3 is expected to be replaced on February 15, 2000, with Version 3. Accordingly,
this discussion and interpretation will focus on Version 3 of Policy 3.
In Version 3, a PSEs action to interrupt a Transaction that is underway is defined as a Termination,
while a Cancellation refers to a Transaction that has not yet begun. Transaction Terminations are found
in Policy 3, Version 3, Requirement D1:
1.
INTERCHANGE TRANSACTION cancellation and termination. When a PURCHASING-SELLING

ENTITY must terminate an INTERCHANGE TRANSACTION that is in progress, or cancel an
INTERCHANGE TRANSACTION that has not started, the PURCHASING-SELLING ENTITY shall
contact the SINK CONTROL AREA to which it submitted the INTERCHANGE TRANSACTION tag.
The S INK CONTROL AREA shall then directly contact its SECURITY COORDINATOR and all
INTERMEDIARY CONTROL AREAS and TRANSMISSION PROVIDERS on the SCHEDULING PATH. . A
description of those entities who may cancel or terminate an Interchange Transaction is found in
Appendix 3D, Transaction Tag Actions.
This language is almost identical to that in Version 2a2, and neither explains what the Control Areas are
expected to do after being notified.
In Section D2, we read that when an Interchange Transaction is Curtailed by a Security Coordinator:
2.
INTERCHANGE TRANSACTION Curtailments. When a SECURITY COORDINATOR, CONTROL

AREA, or TRANSMISSION PROVIDER must curtail or hold an INTERCHANGE TRANSACTION due to
loss of generation or load (emphasis added), or to mitigate an OPERATING SECURITY LIMIT
violation, it will notify the S INK CONTROL AREA. AndThe SINK CONTROL AREA and
SOURCE CONTROL AREA shall then adjust their resulting INTERCHANGE SCHEDULES with their
ADJACENT CONTROL AREAS.
Unlike Requirement D1, this Requirement includes the directive that The Sink Control Area and Source
Control Area shall then adjust their resulting Interchange Schedules with their adjacent Control Areas.
Furthermore, Section 2.2 requires that the Control Areas agree to the time at which the Interchange
Schedule adjustment is to take place:
2.2
INTERCHANGE TRANSACTION curtailment notification. (This notification must include a

common time (specified as xxxx hours) at which the curtailment or adjustment is to take place, as
well as ramp rates, to avoid affecting INTERCONNECTION frequency and causing INADVERTENT
INTERCHANGE.) .
Policy 3 does not, however, specify the time to effect the Interchange Schedule changes.
-2-
Other Agreements and Considerations

When providing an interpretation of Policy 3 regarding Transaction Terminations due to generation loss,
it is important to also consider other contracts and agreements that may be in effect. For example, there
are most likely contracts between the generation provider and its host Control Area. These contracts
probably include agreements on whether energy from the unit will be sold off system, what ancillary
services the unit will provide to the Control Area, notification of unit status, MW output, and
arrangements for handling unexpected unit output variations or trips. Furthermore, if the merchant is
selling its generation to another system, the merchant must arrange for transmission service via the
OASIS (including Scheduling, System Control and Dispatch Ancillary service). Control Areas are not
free to enter into agreements that conflict with NERC Policies. By the same token, NERC Policies cannot
override contractual provisions, at least absent a threat to the reliability of the Interconnection.
Finally, the resulting Transaction must be tagged.
Response to Tenaskas Request

General Comments
The overall intent of Policy 3 is to
1. Implement the merchants Interchange Transactions via Interchange Schedules between Control
Areas, and
2. Do so in a manner that ensures reliable operation of the Interconnection.
To accomplish its goals, Policy 3 specifies the obligations of both the Purchasing-Selling Entities and the
Control Areas. Just as the Control Areas are required to implement new Interchange Transactions at the
request of the Purchasing-Selling Entities, the Control Areas are also obligated to accommodate
Interchange Transaction Terminations. This interpretation addresses these obligations. However, some of
Tenaskas questions deal with the timing requirements for Control Area action that are not expressly
stated in Policy 3 at present. Answers to these timing issues require development through the Process for
Developing and Approving NERC Standards, and this interpretation cannot not address them.
Tenaskas Questions and NERCs Answers

1. What should happen next under the NERC policies?
2. Should Control Area X (source control area) notify Control Area Z (sink control area) that the
generator has been lost and that the interchange schedule will be adjusted to zero at a particular
time?
3. Should Control Area Z be contacted before Control Area X?
These questions will be answered these together:
As Policy 3D1 states, when the merchant must Terminate an Interchange Transaction, he shall contact the
Sink Control Area to which he submitted the tag. Policy 3 does not state a time requirement for this
notification, but it should be as soon as possible. This interpretation cannot specify a time, because that
would be a new Standard.
The Source Control Area is also the Host Control Area for the generator, and NERC assumes that the
Source knows of the generation loss via SCADA or other arrangements agreed to by the Generator and
Control Area.
As to What should happen next, we interpret the intent of Policy 3D1 to be the same as 3D2. The
Source and Sink Control Areas must then confirm the Interchange Schedule adjustment that results from
the generation loss. They must agree on when the Interchange Schedule adjustment is to begin, and its
-3-
ramp rate. It makes no difference whether the Source (X) initiates contact with the Sink (Z) or vice versa.
The Source and Sink Control Areas must then begin to adjust their Interchange Schedules as soon as
possible. Policy 3 does not state how long they have to do this, and we do not believe this interpretation
can specify that timethat would be a new Standard. While the PSE who submitted the original tag must
now issue a revised tag (or a new one) with the zero energy schedule, the Control Areas should not wait
for this tag before adjusting their Interchange Schedules.
4. Can any of the control areas refuse to adjust the schedule upon request?
From an operational security standpoint, there is no reason for refusing to adjust its Interchange Schedule
for the generation loss. If the adjustment was to cause an Operating Security Limit violation elsewhere,
local, Regional, and Interconnection line load relief procedures (e.g., the NERC TLR Procedure) are
available to mitigate Operating Security Limit violations by curtailing Interchange Transactions or
providing some type of redispatch options. Refusing to adjust an Interchange Schedule in order to avoid
an Operating Security Limit violation and the initiation of TLR is tantamount to providing a redispatch
service to maintain existing Interchange Transactions. Unless there is some contract or agreement to
provide for this, there is nothing in Policy 3 that would compel a Control Area to refuse to adjust its
Interchange Schedule upon the generation loss.
5. Do NERC policies provide a maximum time for a schedule adjustment?
No. However, this interpretation cannot provide that time because that would amount to setting a
Standard without using the Procedure for Developing and Approving NERC Standards. The
Interconnected Operations Subcommittee is addressing this issue in the next version of Policy 3.
6. Does a schedule adjustment require a new Tag to be submitted?
Yes. Just as a new tag is required for any change in the energy profile. This is especially important for
IDC update. However, the Source and Sink Control Areas should not wait to receive the new tag before
they adjust their Interchange Schedules.
Further Considerations and Actions Resulting From This Interpretation

1. This interpretation must be ratified by the full Security Committee because it includes specific
directives not expressly stated in the Operating Policies. The Security Committee may also revise
the interpretive statements.
2. Upon ratification, the Security Committee shall direct the Interconnected Operations
Subcommittee to incorporate these interpretations into Policy 3 for interim implementation.
3. These changes shall be posted for public comment in the next version of Policy 3, and no later
than November 30, 2000.
4. Tenaskas letter and this interpretation shall be provided to the Interconnected Operations
Services Implementation Task Force to see if any changes in Policy 10 are warranted.
-4-
NERC Policy or Standard Interpretation Procedure

Version 1, Draft 1
Introduction
NERC expects that entities such as Control Areas, Transmission Providers, Generators, Load-Serving
Entities, and Purchasing-Selling Entities will request an interpretation of a NERC Operating Policy or
Planning Standard for various reasons, such as:
The Entity finds that a Policy or Standard is ambiguous or unclear, or
The Entity has been challenged that its operating practices are not compliant with NERC Policies
or Standards, or
A Policy or Standard is silent on how certain situations are to be handled, or
A Policy or Standard does not adequately explain other entities responsibilities.
In these situations, an Entity may request from the Operating Committee or Adequacy Committee an
interpretation of an Operating Policy or a Planning Standard.
The following section explains the Policy or Standard interpretation procedure. The requesting Entity
should expect a response within one month.
Interpretation Request
1.
Interpretation request. The entity shall send its request to the secretary of the appropriate
standing committee (either the Operating Committee or the Adequacy Committee), preferably as
an e-mail with attachments as necessary.
1.1.
Specific Policy or Standard. The request must include the specific Operating Policy or
Planning Standard, including its name and reference number.
1.2.
Details of request. The Entity shall include an explanation of the situation(s) it is facing
and how the Policy or Standard fails to provide clear direction.
1.3.
Explanation for Interpretation Request. The Entity shall explain the reasons for
requesting the interpretation. These might include:
1.3.1. Ambiguity or lack of clarity. The Entity finds that the Policy or Standard has
multiple interpretations or does not explain what the Entity is supposed to do, or
what other entities are supposed to do in certain situations.
1.3.2. Compliance challenges. Another entity claims that the Entity requesting the
interpretation is not following one or more NERC Policies or Standards.
1.3.3. Missing steps. The Entity finds that the Policy or Standard is incomplete.
2.
Staff drafts interpretation. The NERC staff will prepare a draft interpretation for submission to
the Subcommittee responsible for the Policy or Standard. (Time: 1 week)
3.
Staff submits response to Subcommittee. The NERC staff will send its draft response to the
Subcommittee and request a response due in one week. (Time: 1 week)
3.1.
4.
Conference call. The NERC staff will hold a conference call with the Subcommittee and
requesting Entity to review the details of the request.
Provide Subcommittees interpretation to Operating

Committee or Adequacy Committee. The NERC staff
will send the Subcommittees interpretation to the full
Operating Committee or Adequacy Committee as well as
Version 1
-1-
It may also be necessary to involve

the MIC or its Executive Committee,
or both.
Draft 1: January 25, 2000
NERC Policy or Standard Interpretation Procedure
their respective Executive Committee for comments, which are due within one week. (Time: 1
week)
5.
Executive Committee conference call. The Executive Committee will hold a conference call,
review the Operating Committee or Adequacy Committee comments, and agree on an
interpretation. The requesting entity will be invited to participate.
5.1.
6.
Decision on Policy or Standard revision. The Executive Committee will also decide
whether a Policy or Standard revision is necessary to support the interpretation. If a
revision is necessary, the Executive Committee will recommend this to the Subcommittee
responsible for the Policy or Standard. The Subcommittee will consider this request at its
next regular meeting.
Ratification. At its next regular meeting, the Operating Committee or Adequacy Committee will
ratify its Executive Committees decision. If ratification is needed sooner, then the NERC staff
will poll the Operating Committee or Adequacy Committee for a vote via e-mail.
Version 1
-2-
Draft 1: January 25, 2000
Item 7. Tagging Issues

a. Tag Submission Times for Market Redispatch Charles Yeung
b. Tagging Across Interconnection Boundaries Jerry Hagge
c. Use of Replace Option Jerry Hagge
a.
Tag Submission Time for Market Redispatch
Charles Yeung will review the special tagging provisions for Market Redispatch. This includes
the latest decisions by the Congestion Management Working Group at its February 1 2, 2000
meeting. [Attachment: MRD Tag Submission Time]
Discussion
The Subcommittee needs to discuss these tagging provisions for possible inclusion in Policy 3, as
well as for the E-tag functional specification.
b.
Tagging Across Interconnection Boundaries
Appendix 3A2 explains how tagging is accomplished when Interchange Transactions cross the
Eastern-Western or Eastern-ERCOT Interconnection boundaries. The Appendix does not address
the differences in tag submission time requirements, however.

Jerry Hagge will lead this discussion. The Subcommittee needs to decide if changes in Appendix
3A2 or Policy 3 are needed. Appendix 3A2 is attached as part of Item 3 above.
c.
Use of Replace Option
The Transaction Information System Working Group has requested the Interconnected
Operations Subcommittee discuss this issue.
Action
There was a discussion at TISWG on when you can use the new REPLACE tag in E-Tag. It was
a toss-up in the TISWG with the vote 5 to 4. The two options discussed were:
1. It can only be used prior to the expiration time of the tag it is to replace, or
2. It can be used prior to the expiration time of the tag it is to replace and if the replace tag
abuts the tag it is to replace.
A motion was passed to ask the IOSubcommittee for their direction.
Basis for MRD Tag Submission Time Line

MRD is not usually arranged to protect next-hour hourly
transactions (concurred by market segment of CMWG)
CAs and TPs need 10 minutes to approve MRD tags
Security Coordinators needs 5 minutes to confirm
effectiveness of MRD
As soon as the SC confirmation is completed, the MRD
may be scheduled anytime when a TLR is called
A time period is required to implement the MRD
transaction schedule (as required by Policy 3)
Current Policy 3 requires that tags for multi-hour
transactions be submitted 40 minutes prior to hour
MRDs are usually arranged anticipating transmission
constraints and hence time line needs to consider
1
reallocation process
MRD Tag Submission Time Line Prior to Implementation

Current
FG flow
and Limits
Predictive FG flow, next hour
IDC
MRD may be
implemented
if TLR3 or
higher is
declared and IT
is to be cut
10 Minutes 5 Minutes
Time
Previous
Hours
Future
Hours
PSEs submit
MRD Tags
TP/CA
Approves
MRD Tags
SC confirms
effectiveness
of MRD.
MRD ready for
implementation
MRD Tag Submission Time Line Requirements for

Implementation Under Coordinated Scheduling
Current
FG flow
and Limits
Predictive FG flow, next hour
IDC
TP/CA
Approves
MRD Tags
TLR 1
SC Confirms
effectiveness
of MRD.
MRD ready for
implementation
MRD may be
implemented
anytime if TLR
3b or higher is
declared and IT
is to be cut
PSEs submit
MRD Tags
Hours Current
Ahead Hour
Y+15 Min
Prior
Y+5 Min
Prior
Y Min
Prior
Start of
Next
Hour
Notes: Y minutes are required to schedule the MRD transaction
MRD Tag Submission under Reallocation

FG flow
and Limits,
TLR level
Firm and next

Day Non-firm
Schedules
Normally
Submitted
2:00 pm
TLR 2 Upgraded to TLR 3 a to accommodate

new transactions at higher priorities
Tags approved
and entered into
IDC. Then SC
runs IDC to get
Reallocation List
TLR 2 Declared, approaching OSL
Transition State
as TLR 2 is
intended to be
SCS has adopted
a max. of 30 min.
Day
Day
At Hand
Ahead
New/Revised
Transaction
tags and MRD
Tags submitted
by PSEs*
TLR Cuts
completed;
new/revised
transaction
started
SC sends
reallocation
notifications; CAs
implement changes
and notify PSEs
X Min
60 Min
Prior
X+15 Min
Prior
X+5 Min X Min

Prior
Prior
X = 30 minutes at this time

* Issue: Need to address whether PSEs may submit tags for
the initial transaction and its associated MRD at the same time
MRD may be
implemented
anytime if TLR
3b or higher is
declared and IT
is to be cut
Start of
Next
Hour
4
Summary of MRD Tag Submission Time Line

MRD tags are to be treated the same as at least the
transaction tags for multi-hour hourly transactions and
hence need to be submitted > 40 minutes prior to the hour
Adding 5 minute that the SCs will need to evaluate MRD
effectiveness to negate a TLR, MRD tags need to be
submitted 45 minutes prior
Meeting this submission time line also puts the MRD and
the IT under the consideration for reallocation
While this 45 minute requirement is a general requirements
for conditions under TLR 3a and lower, the MRD may be
implemented upon SCs confirmation when a TLR 3b or
higher is called
5
Tool Changes to Support MRD Tagging

E-tag/IDC must link MRD tags to protected transaction tags
IDC feature is needed to allow SCs to confirm masking of
protected transaction from curtailment (initial confirmation
by the SC is insufficient since system conditions may have
changed when the TLR is called)
IDC needs to post estimated flowgate flows for the next
hour, taking into consideration the current flows and the
submitted transaction tags only
IDC needs to provide study mode capability to help PSEs to
assess transaction impacts and to arrange MRDs
Parked Issue:
Can tags for MRD and Protected Transaction

6
be submitted at the same time?
CMWG Resolutions - MRD TXs and Tagging

Adopted at Its Feb 1-2 Meeting
Motion 3: Passed with one dissenting vote.
The E-Tag assessment period for all MRD tags shall be ten minutes
such that the ETag submission time shall be 45 minutes, to be altered
as required to remain consistent with the submission time associated
with reallocation procedures.
Motion 4: Passed with one dissenting vote.
The CMWGs intent is to provide the capability for the restoration of
previously curtailed transactions subject to, and consistent with, the
incorporation of reallocation procedures in NERC Policy.
[This motion will require recognition in the IDC of the linkage between MRD and
protected TX (including curtailed TX now). Notification via the IDC to the SCs of
the TXs would be required.]
Motion 5: Passed, 14 Yes; 7 No; 1 Abs.

The ability to restart a previously curtailed transaction within a
reasonable time period via the MRD procedure will be in place for
summer 2000.
(Already in MIC report to BoT Feb 7-8)
Comments to be
mailed separately.
Item 8. Public Comments on Appendix 3A1, 3A3, 3A4, 3D
The Security Committee approved these four Appendixes at its December 16 17, 2000 meeting
at the recommendation of the Interconnected Operations Subcommittee. It was also understood
that NERC would post these Appendixes for public comment (due February 11) as part of
NERCs Procedure for Developing and Approving Standards. [Attachments: Appendixes]

The Subcommittee needs to review the public comments, provide responses, and post the next
draft of these Appendixes (unless by some divine miracle the drafts were perfect to start with).
There will probably not be enough time for the NERC staff to review the public comments and
draft responses before the Interconnected Operations Subcommittee meeting. Therefore, the
Subcommittee needs to decide whether it can respond and redraft the Appendixes at its meeting,
or that it needs to wait until its next meeting, during which time the NERC staff will have drafted
responses to the comments. Gordon Scott will lead this discussion.
Comments being requested for tag

submission timetable on Page 2.
Appendix 3A1 Tag Submission and

Response Timetables
Comments due February 11, 2000.
Version 2

Appendix Subsections
A.
B.
C.
ERCOT Interconnection
A.
The table below represents the recommended business practices for tag submission and assessment
deadlines. These are default requirements; some regulatory or provincially approved provider practices
may have requirements that are more stringent. Under these instances, the more restrictive criteria shall
be adhered to.
Tag submission times
now in effect
Transaction Type
Tag
Submission
Time prior to
Transaction
Start Time
Transmission
Provider and
Control Area
Assessment
1
Time
(AgentAuthority)
(ApprovalAuthority)
Time Left before

Start of
Transaction
1 Hour to 24 Hours
duration
20 minutes
prior to start
10 minutes from
tag receipt.
10 minutes
Greater than 24 Hours

duration
4 hours prior
to start
2 hours
2 hours
TRANSMISSION PROVIDER or CONTROL AREA may not Deny an INTERCHANGE TRANSACTION after the Assessment
time has expired.
Version 2
A3A1-1
Transaction
Description
Transaction
Duration
Tag Submission Time

prior to Transaction
Start Time
Transmission Provider and Control

1
Area Assessment Time
(Agent-Authority)
(Approval-Authority)
Single Hour
1 Hour
20 minutes prior to start
Greater of: 10 minutes or 50% of the

time to start, but not to exceed 4 hours.
Multi-hour
> 1 Hour and

24 Hours
40 minutes prior to start

Multi-hour > 24 hours

duration
> 24 Hour and

168 Hours
(1 Week)
120 minutes prior to

start

Other
>168 Hours
(1 Week)
24 hours prior to start
12 hours
The Transaction Information System

Working Group recommends these tag
submission times. These times are
being considered by the Market
Interface Committee and Interconnected
Operations Subcommittee, and are
included here for information only. This
table is being posted for public
comment.
Version 2
A3A1-2
B.
Transaction Duration
Tag Submission Time

prior to Transaction
and Control Area
Assessment Time
Time Left Before Start of

Transaction
Start (Agent/Authority)
(Approval/Authority)
Hourly/multi-hour starting 30 minutes prior to start
less than 60 minutes in the of initial hour.
future
Hourly (both single hours
(starting 60 minutes or
more in the future but
within current day).
90 minutes prior
Hourly (both single hour

No later than 14:00 one
day prior in the Eastern
(starting at 00:00 or further most time zone
into the future).
10 minutes from Tag

receipt.
10 minutes prior to ramp.
45 minutes from receipt
35 minutes prior to initial

ramp.
6 hours prior to
transaction start day.
6 hours prior to start.
This table has not been approved by the

WSCC. Comments are not being
requested.
Version 2
A3A1-3
C.
ERCOT
All transmission service in ERCOT is Network Service between transmission zones. Transmission
Service is either Unplanned or Planned
Included for reference.
ERCOT tagging
requirements are
approved by the Texas
PUC.
Energy transfers using Unplanned Transmission Service
Transaction
Duration
TAG
Submission
Time prior to
Transaction
Start Time
ISO
AssessmentApproval
Time left
before Start
Next-Hour
Hourly
20 minutes
prior to start
10 minutes from
request
10 minutes
Next-Hour
(Same Day)
20 minutes
prior to start
10 minutes from
request
10 minutes
Next Day
By 1400 day
prior
4 hours from
request
6 hours
Weekly
2 days prior to
start
24 hours from
request
24 hours
Monthly
4 days prior to
start
48 hours from
request
48 hours
Arranging Planned Transmission Service

Annual Planned Transmission Service is a nomination process in October of each year for the
following year. Requests for daily, weekly and monthly Planned Transmission Service is
arranged through the ERCOT ISO prior to requesting energy transfers. Approval times are:
Type Planned
Service
Submitted
Approval
Annual
October
January
Monthly
8 days prior
7 days from
request
Weekly
2 days prior
Daily
2 days prior
24 hours from
request
24 hours from
request
Version 2
A3A1-4
Energy transfers using approved Planned Service

Transaction
Duration
Version 2
TAG
Submission
Time
ISO
AssessmentApproval
Time left
before Start
Next Day
By 1400
hours day
prior
4 hours from
request
6 hours
Weekly
By 1400
hours day
prior
4 hours from
request
6 hours
Monthly
By 1400
hours day
prior
4 hours from
request
6 hours
A3A1-5
Comments due February 11,

2000.
Appendix 3A3 Electronic Tagging Service

Failure Procedures
This Appendix was

implemented on an interim
basis from November 17,
1999 through March 30, 2000.
This document describes basic methods to be used to determine the

appropriate action of a market participant should a portion of the E-Tag
system appear to be functioning improperly. As with any large-scale system,
situations will arise which cause components of the system to fail
unexpectedly. In order to maintain the flow of business throughout the marketplace, it is suggested that
the following practices be observed with regard to the E-Tag system.
Decision Flow Chart

The flow chart below shows a general method for determining when a user should utilize an out of band
method to communicate market information to transaction participants. This method can be applied to all
outbound messages; specific explanations of out of band methods for each entity/message are detailed
following.
Send Message
Yes
Successful
Response?
Call Recipient
No
No
Error
Message?
Yes
Can Fix
Error?
Yes
No
Is
Recipient Having
Prolems?
No
Call Info Tech

Staff
Yes
Done
Use Out of Band

Communications
No
Can
Info Tech Staff
fix?
Yes
Correct Problem
Version 1
-1Approved by Security Committee

For Interim Implementation: November 17, 1999 March 30, 2000
Out-Of-Band Communication Methods

There are two primary methods for describing transaction information outside of the E-Tag system:
verbally via telephone and in written form via fax. Faxed tags must be accompanied by telephone
confirmation, and must indicate the reason for the E-tag failure and when the E-tag system is expected to
become available.
The sections below describe which methods are appropriate for each of the various failure scenarios.
Agent SUBMIT There are several possible cases where the Agent, for some reason, would be
unable to SUBMIT a tag to the Authority. For all practical purposes, there are only two that need to
be described here:
1. Authority is up and running, but the Agent cannot send information to it (Agent is down,
Internet connectivity issues, Agent cannot generate a valid SUBMIT message). In this case, the
Agent has a number of choices. It can have the Agent service backed up with redundant systems,
wait and re-submit the tag when communication problems are relieved, contact another Agent and
request the Agent enter the tag for them, or it may send a hardcopy fax tag (see Section 2,
Functional Specification, Appendix D) to the Load Control Area and request that the Authority
enter the tag for them.
2. Authority is down. To meet tag submission deadlines, the Agent user may need to fax a copy of
the tag to all parties of the transaction. In this event, each Control Area on the Scheduling Path
shall verify the Interchange Schedules with its Adjacent Control Areas prior to implementation of
the Interchange Transaction. Each Transmission Provider on the Scheduling Path shall evaluate
their associated transmission reservations and report any reasons for denial to their respective
Control Areas. The Load Control Area shall provide the Security Coordinator with the tag to
enable the Security Coordinator to consider the Interchange Transaction should line load relief
become necessary.
Note: if there is adequate time prior to schedule implementation, the Security Coordinator/Load Control
Area may request the Agent user to re-submit the tag electronically when the Authority returns to service
as one means of entering the tag into the IDC.
Agent CANCEL Should the Agent be unable to issue a CANCEL message, the Agent user should
verbally request the CANCEL of the Load Control Area via telephone. The LCA should execute the
CANCEL on the Agents behalf using override functionality provided by the Authority.
Agent STATUS Should the Agent be unable to issue a STATUS request, the Agent user should
verbally request the STATUS from the Load Control Area via telephone.
Agent DSTATUS In event of a failure, the DSTATUS request should be considered excessive and
should not be requested. However, the Load Control Areas may choose to honor these requests as it
sees fit.
Other Agent Responsibilities The Load Control Area may request the Agent user to fax
information to other parties (parties in the chain that the Authority cannot reach). The Agent user
should honor these requests in as quickly a manner as possible, as these faxes may directly affect the
acceptance/refusal of the transaction by the recipient. As above, faxes should be followed up with
phone calls to confirm receipt.
Authority ASSESS Should the Authority be unable to send ASSESS messages to the various
Approvals (i.e. state of ERROR or INVALID), the Load Control Area should call the tag author via
telephone and verbally request the tag author to fax a copy of the tag to the party having difficulty.
Version 1

Note: It is not necessary for the Agent to wait for the authority to verbally request this action. The
Agent user who is monitoring status may choose to proactively send this fax whenever he sees an
ERROR status. This will expedite tag assessment.
Authority IMPLEMENT Should the Authority be unable to send an IMPLEMENT message to the
IDC or other forwarding URL, the Load Control Area should fax a copy of the Tag to its Security
Coordinator, followed by a confirmation call via telephone. The Security Coordinator will utilize the
tools available to it to ensure the tag is entered into the IDC.
Approval UPDATE Should the Approval be unable to issue an UPDATE message, the Approval
user should verbally request the update change of the Load Control Area via telephone. The LCA
should execute the UPDATE on the Approvals behalf using override functionality provided by the
Authority.
Approval CANCEL Should the Approval be unable to issue a CANCEL message, the Approval
user should verbally request the CANCEL of the Load Control Area via telephone. The LCA should
execute the CANCEL on the Approvals behalf using override functionality provided by the
Authority.
Approval STATUS Should the Approval be unable to issue a STATUS message, the Approval
user should verbally request the STATUS of the Load Control Area via telephone.
Approval DSTATUS Should the Approval be unable to issue a DSTATUS request, the Approval
user should request a fax of the tag from the PSE via telephone.
Additional Information
Recipients of out-of-band requests should treat the requests in a non-discriminatory manner. Should any
party seem to be relying excessively on out-of-band communications method, data should be collected
and supplied to NERC that documents this behavior. Information supplied to NERC should contain the
following:
name of the entity,
the duration of time which the data represents,
the number of E-Tag requests received,
the number of out-of-band requests received, and
details of individual requests (Did the requestor appear to follow the flow chart methods described
above? What reason was given for the failure? Was the problem resolved, or have all request been
due to the same problem? What are the details of the request?).
NERC will review this information, investigate the manner, and make judgments as to how to handle the
situation.
Version 1


This Appendix was implemented on
an interim basis from November 17,
[Appendix 3D, Transaction Tag Action]
This table lists all data elements on the Interchange Transaction tag.
Those elements denoted as Required must be included on the tag, and
are the only elements that may be used by the CONTROL AREAS and
TRANSMISSION PROVIDERS in their tag assessment procedures. The tag
will be judged as complete if it includes those items. A tag may not be denied based on those elements
denoted as not required.
Data elements denoted as Correctable may be revised by the PURCHASING-SELLING ENTITY during the
Transaction assessment time.
Data Item
Required
Correctable
Interchange Transaction ID
Yes
No
TEST Identifier
Yes
No
Transaction Start and Stop Dates
Yes
No
Transaction Days
Yes
No
Time Zone
N/A
N/A
Yes
No
PSE Deal Reference
No
Yes
PSE Contact Name
No
Yes
PSE Contact Telephone Number
No
Yes
10
PSE Contact 24-hour Telephone

Number
Yes
Yes
11
PSE Contact Fax Number
No
Yes
12
Source Entity
Yes
No
13
Source Phone Number
No
Yes
14
Source Fax Number
No
Yes
15
Sink Entity
Yes
No
16
Sink Phone Number
No
Yes
17
Sink Fax Number
No
Yes
18
Remarks
No
Yes
Version 1
Comments
Supplied by tag software
Control Area or name of

generator, generator zone, or
system for intra-Control Area
transactions.
Control Area or name of load,

load zone, or system for intraControl Area transactions.

For Interim Implementation: December 17, 1999 March 30, 2000
Data Item
Required
Correctable
Comments
Energy Profile
19
Start Time
Yes
No
20
Stop Time
Yes
No
21
MW
Yes
No
22
MWH
No
No
23
Ramp Start
No
No
24
Ramp Duration
No
No
Transaction Path
25
Control Area
Yes
No
26
Yes
No
27
Yes
Yes
28
Path (POR/POD)
Yes
Yes
29
Product
Yes
Yes
30
OASIS Assignment Reference
Yes
Yes
31
Product Level
Yes
Yes
32
Miscellaneous Information
No
Yes
33
Miscellaneous Reference
No
Yes
Required for the source PSE,

load-serving PSE, and those
PSEs with Transmission
reservations
Required only when using

multiple reservations for a
single transmission segment
Loss Accounting
34
Yes
No
35
Start Time
Yes
No
36
Stop Time
Yes
No
37
Path
Yes
No
38
MW at POR
Yes
No
39
MW at POD
Yes
No
40
Loss Supply
Yes
Yes
Version 1
Required at option of the

Can not change to or from in

kind

Data Item
Required
Correctable
41
No
Yes
Supply Reference
Version 1
Comments

Appendix 3D Transaction Tag Actions
For Eastern and Western Interconnections
This Appendix was implemented on

an interim basis from November 17,
The table below explains the various tag actions that are possible, and the
entities who are entitled to initiate these actions.
Reason:
Energy Profile
Revision:
Tag Status:
Complete or
Partial
Ends or
Modified
Tag Actions
Reliability or
Economics
Called by
Timing
Cancel
Economic
PSE*
Before Transaction
Start
Complete
Ends
Terminate
Economic
PSE*
After Transaction
Start
Complete
Modified
Withdraw
Economic
PSE*
Before Approval
Complete
Ends
Correct
Economic
PSE*
During Assessment
Time
N/A
N/A
Curtail
Reliability
TP, SC, CA
Before or After
Transaction Start
Either
Modified
Deny
Reliability
TP, CA
Before Close of
Assessment Time
Complete
Ends
Approve
Reliability
TP, CA
Before Close of
Assessment Time
Complete
N/A
*Note: In some situations, CONTROL AREAS implement certain INTERCHANGE TRANSACTIONS or INTERCHANGE
SCHEDULES, such as bilateral inadvertent payback, DYNAMIC SCHEDULES, and emergency schedules from
RESERVE SHARING GROUPS. In these situations, the CONTROL AREA serves as the PSE and can perform these
actions.
Tag Submit
Actions By CA,
TP, SC
Transaction
Approval
Transaction
Approval
Deadline
Assess
(Approve/Deny)
Transaction
Start
Transaction
End
Curtail
Correct
Withdraw
Cancel
Terminate
Actions By PSE
Version 1

Item 9
Western Systems Coordinating Council

REPLY TO:
Mark W. Hackney, Chairperson
Interchange Scheduling and Accounting
Subcommittee
Arizona Public Service Company
P.O. Box 53999
Station 2260
Phoenix, AZ 85072-3999
Tel: (602) 250-1128
Fax: (602) 250-1155
February 1, 2000
NERC Interconnected Operations Subcommittee (IOS):
The WSCC Interchange Scheduling and Accounting Subcommittee (ISAS)
has been discussing with the NERC TISWG the modifications necessary to
implement E-Tagging within the Western Interconnection. These discussions
and subsequent requests for E-Tag specification modifications to
accommodate the tagging and scheduling practices of the WSCC members
have been very productive. Productive to the point that the proposed
specification, version1.5, incorporates items that the WSCC members find are
necessary for the West to implement E-Tag. I would like to thank the IOS for
assisting in this effort by its deference to WSCC practices and procedures.
As we move forward into the implementation of E-Tagging in the West, I
would like to clear up points of possible confusion. One of those items is the
phased-in implementation plan the ISAS has worked on with WSCC member
systems to manage the transition. The phase-in plan is consistent with the
current language in NERC Policy 3, effective February 2000 and the NERC
granted variance for WSCC E-Tag Implementation but modifies the overall
timeline. The plan is also coordinated with NERC TISWG for E-Tag training
and interoperability testing of version 1.5. That plan is attached, but
highlighted below are several items I feel should be pointed out:
January 25, 2000 - Approval of E-Tag Spec. Version1.5 by IOS/SCEC and/or
SC as written with the WSCC needs incorporated.
February 1, 2000 - Checkpoint: If Spec. Version 1.5 is not released or

missing features required by the WSCC members, WSCC to delay E-Tag
implementation until fall CY2000 after notice to the NERC IOS.
March 10, 2000 - Proposed: All entities ready to test E-Tag (Spec. 1.5
version).
March 17, 2000 - Proposed: All entities participate in 4-hour parallel process
system-wide test of all E-Tag functions for preschedule tags.
March 28,29, 2000- Proposed: All entities participate in 8-hour parallel
process system-wide test of all E-tag functions for Preschedule tags.
April 3, 2000 - Checkpoint: If E-Tag test results are not satisfactory, delay
E-Tag implementation to May 16, 2000 and reschedule additional testing.
April 18, 2000 - Proposed: Implement preschedule E-Tagging system for
April 19, 2000 interchange transactions.
May 16, 2000 - The drop-dead date for implementing E-Tag within the
WSCC prior to summer CY2000, otherwise delay until October 17, 2000.
These are just some of the highlighted dates within the WSCC ISAS E-Tag
implementation plan. Included in the attached plan is the schedule for realtime E-Tag implementation. We believe that this plan moves the WSCC
forward in implementing E-Tag within the West. At the same time the plan
does not jeopardize the integrity and reliability of the system by introducing
real-time E-Tagging into the control centers prior to the start of the summer
season. Please note that most western real-time personnel have only dealt
with preschedule tags created with the existing system. Additionally, this
will allow our membership to gear up for the conversion to a new transaction
tagging system that has just recently been modified to accomplish what the
West has been doing with the older transaction tagging system. This phasein plan also supports subsequent releases of versions of the E-Tag
Specification planned by NERC for later this year.
In addition, as Jim McIntosh stated in his letter to this Subcommittee last
year, the Western Interconnection does not require the IDC and hence our
use of the new E-Tag is not a requirement for system security. It does
however integrate the EI and WI tagging for schedules across the boundary
and to that effort the WSCC ISAS supports the need to move ahead with a
common transaction tagging system among NERC member councils. As such,
we are requesting NERCs approval for WSCC to amend the E-tag
implementation schedule as discussed herein.
Page 2 of 3
Sincerely,
Mark W. Hackney
Mark W. Hackney
Chairperson
WSCC Interchange Scheduling and Accounting Subcommittee
Page 3 of 3
Item 10.
Transaction Start Time
On June 10, 1999, a PECO Power Team transaction, scheduled to start at 1000, was held due to a
TLR Level 2. The hold was released at 1014; however, PECO submitted a new tag with a start
time of 1100. PECO asked the SCS to review this TLR event.
When the review team asked PECO why they didnt try to start their transaction at 1014, they
indicated that Control Areas will not usually start transactions at other than the top of the hour.
The review team said it would ask the Interconnected Operations Subcommittee to look into this.
Policy 3 does not require a top-of-hour start time. In the Introduction to Section C., Interchange
Schedule Standards, it states:
INTERCHANGE SCHEDULES usually start and end on the clock
hour. However, PURCHASING-SELLING ENTITIES may wish to begin or
end an INTERCHANGE TRANSACTION at other times, and the CONTROL
AREAS should try to accommodate the resulting off-hour INTERCHANGE
SCHEDULES if possible.
Requirement 3C1 states:
1. INTERCHANGE SCHEDULE start and end time. INTERCHANGE SCHEDULES shall begin
and end at a time agreed to by the SOURCE CONTROL AREA, SINK CONTROL AREA, and
the INTERMEDIARY CONTROL AREAS.

The Subcommittee should consider whether Policy 3C should state more explicitly that Control
Areas are to implement Interchange Transactions at the time that is tagged. In PECOs situation,
it seems they could have tagged the Transaction at 1014 (when the Hold was released) to start at
1034 (tag submitted 20 minutes before start).
Item 11.
Dynamic Schedules v. Dynamic Transfers
This is a follow-up to the Subcommittees discussion at its last meeting. This was requested by
Carroll Scheer as follows:
The way Dynamic Schedule is defined the adjustment is to the schedule which
has to be in full MW. I would suggest using Dynamic Transfer which would allow
you to adjust either the schedule or interchange. You can adjust the
interchange by kW depending on the k of the meter. This allows smaller
entities to follow load in another control area. The statement that Dynamic
Schedules are used for common generation may be true in some area, but I think
you will find that some adjust the interchange value. I just want the
flexibility to adjust either one depending on the need. This will happen with
retail wheeling I can assure you. A definition for Dynamic Transfer could be
used allowing adjustment to either the schedule or interchange.
Mr. Scheer reported that Amp Ohio was being charged an energy imbalance due to the roundoff
that occurs when dynamic schedules are calculated to the nearest MW, while the actual
interchange was calculated to the nearest kWh.
At its December 6 8, 1999 meeting, the Subcommittee did not believe that changing the use of
Dynamic Schedule to Dynamic Transfer would solve Mr. Scheers problem. The NERC staff will
be discussing this with Mr. Scheer to see if a change in Policy 1 was necessary. This is where
Dynamic Schedules are discussed. Dynamic Transfers are explained in Policy 10.

Gordon Scott will report on the staffs follow-up with Mr. Scheer.
Item 12.
Request from Pat Connors on Tagging Network

Transactions
This is another follow-up item. Last fall, Mr. Connors (WPPI) sent Don Benjamin a letter
requesting that the Interconnected Operations Subcommittee investigate the need to require
tagging for transaction using Network Integration Transmission Service. [Attachment: Letter
from Mr. Connors]. The Subcommittee discussed this at its December 6 8 meeting, but could
not reach a conclusion on how to tag transactions using network transmission service because of a
lack of an identifiable source-sink pair.
Gordon Scott will be in touch with Mr. Connors do discuss this further, and will report to the
Subcommittee.

The Subcommittee should continue its discussion of Mr. Connors issues and determine if a
change to Policy 3 is needed. (Mr. Connors second issue regarding revised energy profiles was
addressed by a change in Policy 3 made at the December 16 17, 1999 Security Committee
meeting. This is no longer a problem.)
November 9, 1999
Mr. Donald Benjamin

Director - Operations
116-390 Village Boulevard
Princeton, New Jersey 08540-5371
Re: Comments on October 15, 1999

Draft of NERC Policy 3
Dear Mr. Benjamin:

NERC Policy 3 needs to be revised so that load-serving entities are required to submit a
NERC TAG for all interchange transactions and intra-control area schedules. Comparability
requires that all entities meet the same requirements. Without this requirement, load serving
entities that operate a control area will continue to have a competitive advantage over
transmission dependent load serving entities that are required to obtain an approved transmission
reservation and NERC TAG for all purchases and sales.
NERC Policy 3 states at A.2.1 that only certain Interchange Schedules shall be tagged and
only intra-Control Area transfers using point-to-point transmission service shall be tagged. NERC
Policy 3 should require approved tags for all Interchange Schedules. NERC Policy 3 should also
require approved tags for all intra-control area transfers, including deliveries from designated and
undesignated network resources that are entirely internal to a control area. Since TAGs are used
to calculate NERC TLR curtailments, it is imperative that all uses of the transmission system be
tagged in order to ensure comparable curtailment treatment. Unless intra-control area deliveries
from undesignated network resources are tagged, there is no assurances that such non-firm
deliveries will be curtailed in a manner comparable with non-firm transactions that are tagged.
Further, transmission customers will have significantly more confidence in the computed TLR
curtailment amounts if the TLR curtailment calculation is performed by a single entity such as
NERC and all Interchange Schedules and intra-control area deliveries are included in the NERC
IDC.
NERC Policy 3 also states at A.8 that the interchange transaction energy profile will
remain at its curtailed value until the interchange transaction expires. NERC needs to clarify this
provision, since transmission providers and NERC Regions are interpreting this statement
differently. Apparently, some transmission providers will allow additional transmission

reservations and schedules as long as the total amount reserved and schedule is less than or equal
to the curtailed value while other transmission providers will not allow any new schedule profiles
or changes to an existing schedule profiles until TLR expires. At a minimum, NERC needs to
revise section A.8 of NERC Policy 3 to clarify exactly when new transmission reservations and
schedules are allowed during a NERC TLR event.
Thank you for the opportunity to provide comments. If you have any questions, please
call me at (608) 834-4559.
Very truly yours,
Patrick Connors
Director of Transmission and
Power Supply Arrangements
CC:
Pete Steitz
NERC IOS
Item 13.
Policy 2, "Transmission"
a. Add reference to calling TLRs to mitigate OSLs in Policy 2A

b. OSL Violation form
This item was on the Interconnected Operations Subcommittees December 6 8, 2000 meeting
agenda, but there was no time to cover it.
a.
A draft of Policy 2, Version 2 is attached to help the Interconnected Operations Subcommittee get
started on bringing this Policy up to date. This draft includes notification of Security
Coordinators, requesting line load relief, and brings the Transmission Provider into the picture.
[Attachment: Draft Policy 2, Version 2]

The Subcommittee needs to develop a plan for revising this Policy during 2000.
b.
OSL Violations
OLS Violation Form

The Interconnected Operations Subcommittee reviews Operating Security Limit violations, which
are reported on NERCs disturbance analysis report form found in Appendix 5f. This form was
adapted for reporting Operating Security Limit violations, but a form specifically designed to
report these operating events would be better.

A proposed Operating Security Limit Violation report form is attached for the Subcommittees
consideration [Attachment] Don Benjamin will lead the discussion. If approved, this could either
be included as part of Appendix 5f or incorporated into a new appendix for Policy 2.
OSL Violation: IMO February 2, 2000
Discussion
The Subcommittee reviews all OSL Violations that are reported to the NERC staff for lessons
learned. [Attachment: IMO OSL Violation of February 2, 2000]
Policy 2 Transmission
Version 2, Draft 0 (markup)
Policy Subsections
A.
B.
Draft for December 6 8, 1999

Subcommittee meeting
Transmission Operations
Voltage and Reactive Control
Introduction
This Policy specifies the requirements for operating the transmission system to
maintain transmission security. These requirements include transmission operation,
establishment of one or more SECURITY COORDINATORS, and voltage and reactive
control.
A.
Transmission Operations
[Policy 4B System Coordination Operational Security Information]

[Policy 5C Transmission System Relief]
[Policy 9 Security Coordinator Procedures]
Standards
1.
Basic reliability requirement regarding single

contingencies. All CONTROL AREAS shall
operate so that instability, uncontrolled
separation, or cascading outages will not occur
as a result of the most severe single contingency.
1.1.
1.2.
2.
Multiple outages. Multiple outages of

a credible nature, as specified by
Regional policy, shall also be examined
and, when practical, the CONTROL
AREAS shall operate to protect against
instability, uncontrolled separation, or
cascading outages resulting from these
multiple outages.
Operating Security
Limit Violation
Occurs
t=0
Pre-contingency.
Can securely
withstand
first contingency
Post-contingency.
Cannot withstand
next contingency.
Must be 30 minutes
or less.
t=0
OPERATING SECURITY LIMITS.

OPERATING SECURITY LIMITS define the acceptable operating
boundaries.
t# 30
Time in Minutes
Return from OPERATING SECURITY LIMIT Violation. Following a

contingency or other event that results in an OPERATING SECURITY LIMIT
violation, the CONTROL AREA shall return its transmission system to within
OPERATING SECURITY LIMITS soon as possible, but no longer than 30
minutes.
2.1.
Version 2
Can again securely

withstand
first contingency
This should be in the

Terms section. Its not
a Standard.
REPORTING Non-compliance. Each violation of this Standard

shall be reported to the Regional Council and NERC Compliance
Subcommittee within 72 hours.
P21
Draft 0: November 28, 1999
A. Transmission Operations
2.2.2.1.1. Reporting format. The report will be submitted on

the NERC Preliminary Disturbance Report Form as found
in Appendix 5F, Reporting Requirements for Major
Electric System Emergencies.
Requirements
1.
2.
Policies for dealing with transmission security. TRANSMISSION

PROVIDERS and CONTROL AREAS, individually and jointly, shall develop,
maintain, and implement formal policies and procedures to provide for
transmission security. These policies and procedures shall address the
execution and coordination of activities that impact inter- and intraRegional security, including:
Equipment ratings
Monitoring and controlling voltage levels and real and reactive

power flows
Switching transmission elements
Planned outages of transmission elements
Development of OPERATING SECURITY LIMITS
Responding to OPERATING SECURITY LIMIT violations.
1.1.
Responsibility for transmission security. When OPERATING

SECURITY LIMIT violations occur, or are expected to occur, the
TRANSMISSION PROVIDERS and CONTROL AREAS affected by and
the CONTROL AREAS contributing to these violations shall
implement established joint actions to restore transmission
security.
1.2.
Notifying Security Coordinator. The TRANSMISSION PROVIDER

with the OPERATING SECURITY LIMIT violation shall notify its
SECURITY COORDINATOR of this violation.
1.3.
Requesting Relief. If the TRANSMISSION PROVIDER believes that

it can not mitigate the CONSTRANT, it shall request its SECURITY
COORDINATOR to implement either a local line load relief
procedure or an Interconnection-wide line load relief procedure.
[See Policy 9C]
1.2.1.4.
Action to keep transmission within limits. TRANSMISSION

PROVIDERS and CONTROL AREAS shall take all appropriate action
up to and including shedding of firm load in order to comply with
Standard 2.A.2.
Security Coordination. Every Region, subregion, or interregional

coordinating group shall establish one or more SECURITY COORDINATORS
to continuously assess transmission security and coordinate emergency
operations among the CONTROL AREAS within the Subregion, Region, and
across the Regional boundaries.
Version 2
P22
Time to specify
actions required of
Transmission
Providers
This ties Policy 2

with Policy 9.
Should this go
somewhere else?
A. Transmission Operations
2.1.
3.
TRANSMISSION OPERATING ENTITIESPROVIDERS shall cooperate

with their HOST CONTROL AREAS to ensure their operations
support the reliability of the INTERCONNECTION.
Coordinating transmission outages. TRANSMISSION PROVIDERS shall

coordinate Pplanned transmission outages shall be coordinated with any
system that other TRANSMISSION PROVIDERS and CONTROL AREAS that
operations planning studies show might be affected. TRANSMISSION
PROVIDERS shall also provide their transmission outage schedule to their
SECURITY COORDINATOR.
Version 2
P23
B.
Voltage and Reactive Control
Requirements
1.
Monitoring and controlling voltage and MVAR flows. Each CONTROL AREA, individually and
jointly, shall ensure that formal policies and procedures are developed, maintained, and implemented
for monitoring and controlling voltage levels and MVAR flows within its boundaries and with
neighboring CONTROL AREAS.
2.
Providing reactive resources. Each CONTROL AREA shall supply reactive resources within its
boundaries to protect the voltage levels under contingency conditions. This includes the CONTROL
AREAS share of the reactive requirements of interconnecting transmission circuits.
2.1.
3.
Providing for reactive requirements. Each PURCHASING-SELLING ENTITY shall arrange

for (self-provide or purchase) reactive resources for its reactive requirements.
Operating reactive resources. Each CONTROL AREA shall operate their capacitive and inductive
reactive resources to maintain system and INTERCONNECTION voltages within established limits.
3.1.
Actions. Reactive generation scheduling, transmission line and reactive resource switching,
etc., and load shedding, if necessary, shall be implemented to maintain these voltage levels.
3.2.
Reactive resources. Each CONTROL AREA shall maintain reactive resources to support its
voltage under first contingency conditions.
3.3.
3.2.1.
Location. Reactive resources shall be dispersed and located electrically so that they
can be applied effectively and quickly when contingencies occur.
3.2.2.
Reactive restoration. Security Limit Violations resulting from reactive resource

deficiencies shall be corrected in accordance with Standard 2.A.1. and 2.A.2.
Field excitation for stability. When a generators voltage regulator is out of service, field
excitation shall be maintained at a level to maintain Interconnection and generator stability.
4.
Operator information. The SYSTEM OPERATOR shall be provided information on all available
generation and transmission reactive power resources, including the status of voltage regulators and
power system stabilizers.
5.
Preventing Voltage Collapse. The SYSTEM OPERATOR shall take corrective action, including load
reduction, necessary to prevent voltage collapse when reactive resources are insufficient.
6.
Voltage and reactive devices. Devices used to regulate transmission voltage and reactive flow shall
be available under the direction of the SYSTEM OPERATOR.
Version 2
P24
B. Voltage and Reactive Control
Guides
1.
Keeping lines in service. Transmission lines should be kept in service as much as possible. They
may be removed from service for voltage control only after studies indicate that system reliability
will not be degraded below acceptable levels.
2.
Keeping voltage and reactive control devices in service. Devices used to regulate transmission
voltage and reactive flow, including automatic voltage regulators and power system stabilizers on
generators and synchronous condensers, should be kept in service as much of the time as possible.
3.
Voltage and reactive devices. Devices used to regulate transmission voltage and reactive flow
should be switchable without de-energizing other facilities.
4.
DC equipment. Systems with dc transmission facilities should utilize reactive capabilities of

converter terminal equipment for voltage control.
5.
Reactive capability testing. Generating units and other dynamic reactive resources should be tested
periodically to determine achievable reactive capability limits.
Version 2
P25
Operating Security Limit Violation Report
1.
Organization filing report:
2.
Name of person filing report:
3.
Telephone number:
4.
Date and time of violation:
Date (mm/dd/yy)
/
5.
/Time/Zone
Describe the circumstances surrounding the Operating Security Limit violation. Include:
Cause.
o Explain if it was caused by an operating situation on your system or another
Transmission Providers system
Chronology of actions (including times) to return the transmission system to normal operations
o Include time of notification of Security Coordinator (see following page for chronology
report form)
What would have happened had the facility in violation tripped off or failed (failure scenario)
Cause
Failure Scenario
Chronology of Action
Time (Time Zone)
Action
1515 BROADWAY, NEW YORK, NY 10036-8901 TELEPHONE: (212) 840-1070 FAX: (212) 302-2782
Date:
February 2, 2000
Memo to:
Members, Task Force on Coordination of Operation:
Mr. Michel Armstrong

Transnergie
Mr. Donald Berringer
Nova Scotia Power, Inc.
Mr. Michael C. Calimano
New York Power Pool
Mr. P. S. (Ben) Li
Independent Electricity Market Operator (Ontario)
Mr. Frank X. Macedo
Ontario Hydro Services Company
Mr. Albert Poir
Transnergie
Mr. Daniel Schmidt
Independent Electricity Market Operator (Ontario)
Mr. Paul B. Shortley
ISO New England Inc.
Mr. Wayne N. Snowdon
New Brunswick Power
Mr. Wesley J. Yeomans
Niagara Mohawk Power Corporation
Mr. Roger C. Zaklukiewicz
Northeast Utilities
and
Mr. Donald M. Benjamin
Director-Operations
Mr. Glenn W. Brown
NPCC Representative
NERC Disturbance Analysis Working Group
Mr. Robert W. Cummings
Director-Transmission Services
Mr. Eugene F. Gorzelnik
Director-Communications
Re:
Disturbance Report
Independent Electricity Market Operator- February 2, 2000
From:
John G. Mosier, Jr.

Attached is the preliminary report by the IMO acknowledging a security
limit violation which occurred due to the failure of implementation of a
special protection system. No load or transmission was lost. You may
also download this report as a Version 3.0 Adobe Acrobat file (.pdf) from
the HomePage of the Northeast Power Coordinating Council at
http://www.npcc.org/. Click on NPCC WWW BBS, click on Publications
and open the folder Disturbances. The file for the subject report is
named IMO-000202-Disturbance_Report.pdf.
JGM
JGM:mr
cc:
Members, System Operations Managers Working Group (Working Group CO-8)

Members, Task Force on System of Protection
Mr. Bruce M. Balmat
Mr. Jim D. Cyrulewski
Mr. Charles J. Durkin, Jr.
Mr. Ronald J. Falsetti
Mr. Joseph Farella
Mr. Jorn C. Haahr
Mr. Vinod C. Kotecha
Mr. Kenneth C. Lotterhos
Mr. Michael L. Schiavone
Mr. Edward A. Schwerdt
Mr. Roy Sepa
Mr. Karl Tammar
Mr. Peter Wong
email:
co8@npcc.org, tfsp@npcc.org, armstrong.michel@hydro.qc.ca, balmatbm@pjm.com,
mcalimano@nyiso.com, don.benjamin@nerc.com, don.berringer@nspower.ns.ca,
gbrown@nbpower.com, mcalimano@nyiso.com, cummings@nerc.com,
cyrulewskij@mepcc.com, cdurkin@npcc.org, ron.falsetti@iemo.com, farellaj@nimo.com,
efg@nerc.com, jhaahr@npcc.org, kotechav@coned.com, ben.li@iemo.com, klotter@npcc.org,
frank.macedo@ohsc.com, jmosier@npcc.org, poire.albert@hydro.qc.ca,
schiavonem@nimo.com, dan.schmidt@iemo.com, eschwerdt@npcc.org, roy.sepa@iemo.com,
pshortley@iso-ne.com, wsnowdon@nbpower.com, ktammar@nyiso.com, pwong@iso-ne.com,
yeomansw@nimo.com, zaklurc@nu.com
Item 14.
Disturbance Analysis Working Group Report for

Summer 1999
During summer 1999, five low transmission voltage events occurred on the Eastern
Interconnection. These events, which were discussed briefly during the September Board of
Trustees meeting, raised questions about transmission systems being able to identify conditions
preceding such events and to take the necessary steps to addressed these conditions before low
transmission voltages occur. The Disturbance Analysis Working Group (DAWG) reviewed these
events and prepared summary reports for them with the assistance of the Regional Reliability
Councils. [Attachments: DAWG Report]
System Conditions in Northwest Ohio on June 10 and 11
System Loadings in ECAR, MAIN, and the TVA Subregion of SERC on August 19 and
20
Low Voltage in MAAC on July 6
Low Voltage Conditions in the Atlanta, Georgia Area on August 18
Low Voltage Conditions in Arkansas and Oklahoma on August 13
At its January 23 24, 2000 meeting, the Security Committee Executive Committee reviewed the
DAWG report, and assigned recommendations to the SCS and Adequacy Committee as detailed
below:
1.
Modeling practices SCS. Not only their models, but the transmission systems within
their Security Area.
2.
Modeling for multiple contingencies SCS.
3.
Review demand forecasts SCS for short-term, AC for long term.
4.
Review ability of generators to deliver reactive support and provide information to

Security Coordinators SCS for short-term, AC for long term
5.
Review of reactive location SCS for short-term, AC for long term
6.
Review transmission operating guides IOSubcommittee
7.
Review transmission reservation practices FBATF
8.
Review planning criteria SCS for short-term, AC for long term

The Subcommittee needs to review the DAWGs recommendation #6 and decide if changes are
needed to Policy 2.
Disturbance Analysis Working Group Report to the Security

Committee, November 1617, 1999
Low-voltage and System Loading Events in the Eastern Interconnection
Summer 1999
During summer 1999, five low transmission voltage and system loading events of significance occurred
on the Eastern Interconnection. These events, which were discussed briefly during the September Board
of Trustees meeting, raised questions about transmission systems being able to identify conditions
preceding such events and to take the necessary steps to address these conditions before low transmission
voltages occur.
The Disturbance Analysis Working Group (DAWG) reviewed these events and prepared summary reports
for them with the assistance of the Regional Reliability Councils. The five incidents were:
System Loadings in the ECAR, MAIN, and the TVA Subregion of SERC on August 19 and 20,
Low Voltage Conditions in ECAR on June 10 and 11,
Low Voltage Conditions in MAAC on July 6 and 19
Low Voltage Conditions in the Atlanta, Georgia on August 18, and
Low Voltage Conditions in Arkansas and Oklahoma on August 13.
Copies of the DAWG reports on these events are attached.

It is obvious, from the fact that the events did occur, that systems were not able to adequately identify
conditions preceding them in time to take preventative corrective action. Furthermore, it is fundamental
to system security and reliability that adequate reactive resources as well as real power resources are
available in appropriate locations to assure adequate reserves. Several problem areas were apparent from
the DAWG review:
System modeling studies did not have sufficient, and/or accurate data, or failed to take into account
enough contingencies,
Customer demand (MW and especially MVAr) under hot weather conditions was underestimated, and
The ability of generators to deliver reactive support during periods of peak demand was over
estimated.
On the positive side, the reviews demonstrated the usefulness and importance of the Security Coordinator
function and transmission loading relief (TLR) process and the benefits of the interim interchange
distribution calculator (iIDC) in restoring system conditions.
The failure to anticipate system conditions in each of the events reviewed appears to be due to the
inability of system models to accurately predict system conditions, particularly in regard to low voltage
conditions. Predictive capability, in turn, is related to the quantity and accuracy of the input data. With
the tremendous increase in transactions and limited system reinforcements under construction or planned,
the need for accurate modeling to ensure system security is greater than ever.
-1-
Draft: November 5, 1999
NERC Operating Policies, on paper, appear to provide adequate procedures to prevent events such as
those studied. Security Coordinator Procedures, Criteria, and Functions are well defined in Policy 9 and
Appendix 9D. Policy 2 Transmission, Section B Voltage and Reactive Control, contains explicit
requirements for monitoring and controlling voltage and MVAr flows and for providing reactive
resources. Appendix 4B Electric System Security Data, lists the data that control areas are to provide
to Security Coordinators.
What is not covered in the Operating Manual are criteria for the judgement factors that systems have to
use in determining how much data is enough and how good the data must be. This determination is
something that Regions, security coordinators, control areas, and electric utility systems will have to work
out among themselves. The DAWG recommendations listed below are intended to help focus on this
need.

Based on their review of the events, the DAWG requests the Security Committee endorse the following
recommendations for regions, control areas, and systems:
1. Review modeling practices to ensure that sufficient data points are being captured to accurately assess
system conditions, real-time data is used in the model to the extent possible, and real system
conditions are being used to calibrate the models.
2. Consider modeling of system configurations involving multiple contingencies (transmission and
generation) to the extent possible.
3. Review demand forecasts in light of the weather and demand conditions experienced in 1999 to
ensure that estimates of MW and MVAr demand are realistic and not conservative.
4. Review the ability of generators to deliver reactive support during periods of peak system demand
and ensure that generator MW and MVAr capability and output is being provided to Security
Coordinators according to Appendix 4B.
5. Review the availability and location of transmission system reactive support in light of higher than
anticipated reactive power demands experienced during 1999 to comply with the requirements of
Policy 2.
6. Review transmission operating guides to ensure that they include procedures, in addition to TLR, to
return the system to a secure state.
7. Review transmission reservation procedures to ensure that available transmission capability (ATC)
and total transmission capability (TTC) are calculated accurately and updated as necessary so that
transmission systems are not over subscribed or causing parallel flow problems on neighboring
systems.
8. Review the planning criteria for reactive reserve adequacy.
-2-
Draft: November 5, 1999
11/5/99
LOW VOLTAGE CONDITIONS IN OHIO ON JUNE 1011, 1999

Summary
During the week of June 7, temperatures in Indiana, Michigan, and Ohio were
consistently in the mid 90s. These high temperatures, combined with isolated facility
outages, resulted in heavy burdens on the American Electric Power (AEP) transmission
system and neighboring transmission providers. On Thursday, June 10, the AEP internal
demand peaked at about 19,300 MW and the total demand served by the AEP
transmission system was about 31,000 MW. The heavy power flows, together with
equipment outages, contributed to low voltage conditions in central Ohio, with a reading
at one location on the 138 kV bus as low as 90% of the nominal voltage. Generally,
voltage levels on the 138 kV network were above 95%. The following material provides
a recap of the system conditions and corrective actions that were taken Thursday, June 10
and Friday, June 11.
Condition of the EHV System and Adjoining Systems - June 10, 1999
On Thursday, June 10, power flows to the north and west of AEP were heavy throughout
the day. Transmission service through AEP was also at a high level. At about 1400
hours EST, power transfers to systems to the north and west were as follows: 2,462 MW
to Michigan Electric Coordinated System (MECS), 608 MW to First Energy (FE), and
1,200 MW to ComEd (CE). At about this time, a transmission loading relief level 3
(TLR-3) was called by the ECAR/MET Security Coordinator due to low-voltage
conditions in central Ohio. The TLR resulted in the curtailment of a 175 MW non-firm
AEP-FE transaction and a 308 MW Virginia Power (VP)-CE transaction. AEP internal
demand continued to increase, peaking at over 19,300 MW at 1600 EST, while the total
demand served from the AEP transmission system declined by about 1,200 MW to about
30,000 MW over the same period. The heavy loadings in northwest Ohio were
aggravated by equipment outages outside this area. In First Energy, the RichlandRidgeville 138 kV circuit (which is north of AEPs Lima service area) and First Energy
generating units Avon 9 (596 MW) and New Castle 5 (137 MW) were out of service. In
Detroit Edison (DE), two of the four 750 MW units at the Monroe Plant (located about 60
miles north of Lima) were out of service.
Within AEP, all major generating units were on-line and generally operating at near
capacity, except for the two Cook units (1020 and 1090 MW); the EHV transmission
network was intact. However, a trip due to a fault of the Canton Central-Cloverdale
(AEP-FE) 138 kV circuit and mis-operation of the system protection breaker failure
scheme resulted in the additional outages of the Tidd-Canton Central (AEP) 345 kV
circuit and the Canton Central 345/138 kV transformers. These facilities were all
returned to service that evening. In Indiana, AEP had two scheduled outages of 138 kV
circuits the Mullin circuit at Deer Creek for a breaker upgrade, and the Jay circuit at
DeSoto for a wave-trap replacement. The Indiana outages had virtually no impact on the
conditions in northwest Ohio.
11/5/99
Generally, voltage levels on the 138 kV network were above 95% of nominal voltage.
However, the unavailability of the two Cook units, outages at DEs Monroe Plant, and
transmission outages near the Lima Area continued to have negative impacts on system
voltages.
Conditions of the EHV System and Adjoining Systems - June 11, 1999
All transmission outages in Ohio had been restored the previous evening, June 10. One
of Detroit Edisons Monroe units returned to service on the morning of June 11. Due to
the improved status of the transmission network, a slight moderation in internal demand,
and reduced transfers across AEPs transmission system there was a general
improvement in voltages.
On Friday, June 11, power flows to the north and west of AEP were similar to the day
before. At 1300 EST, power transfers to the north and west were: 2,548 MW to MECS,
300 MW to FE, and 1,205 MW to CE. At about this time, the ECAR/MET Security
Coordinator called a TLR-3 on the Dumont 765/345 kV transformer for a contingency
loss of the Cook 765/345 kV transformer. The TLR resulted in the curtailment of 306
MW of non-firm transactions to MECS and a 500 MW AEP-CE non-firm transaction.
AEP internal demand peaked near 18,600 MW at about 1500 hours, and the total demand
served from the AEP transmission system was about 28,000 MW, down about 500 MW
from a peak two hours earlier.
Conditions on the Northwest Ohio Area Transmission System June 10 - 11, 1999
The Northwest Ohio local area transmission system (138 kV and lower) primarily serves
demand in the Lima-VanWert-Fostoria-Fremont-Howard areas of the AEP System. The
projected area peak demand, for 1999 summer, was 1,650 MW. The area also contains
over 550 MVAr of reactive power correction for local area voltage support.
On June 10-11, as the power flows on the overall transmission system increased in order
to serve both native demand and the power requirements of neighboring systems,
voltages in the area declined. During the morning and evening hours on June 10-11,
system voltages of 100% or more of nominal voltage were recorded on the local
transmission system. During the same period, voltages on the 345 kV system were about
99% of nominal system voltage. By late afternoon, voltages declined to about 90% at the
Howard 138 kV bus and 95-96% at various locations in the Lima area 138 kV system.
On the lower voltage system (below 138 kV) recorded voltages reached about 94%. The
Western Transmission Region reported that all critical area station capacitor banks, 34.5
kV through 138 kV, were in service or available to automatically switch into service on
June 10 and 11. The Sterling Station 13 kV, 20 MVAr condenser and 34.5 kV, 14.4
MVAr capacitor bank were out of service for a complete replacement of the capacitor
bank.
11/5/99
Conclusions
A review of the available data indicates that the reactive power support to the 138 kV
system from the 345 kV system was minimal (about 50 MVAr). This low reactive
support is a further indication that the sagging EHV system voltage, resulting from
contingencies on neighboring systems and heavy power flows on the EHV network, was
a major contributor to the lower area voltages. In addition, on June 10, contingencies on
the First Energy system contributed to the low voltage conditions in Lockwood Road
area. Specifically, the outage of a 138 kV circuit into the Richland substation, on the
First Energy system, reduced the support to the Lockwood Road area.
On a positive note, the availability of reactive power correction on the local area
transmission and distribution systems, coupled with the fact that the taps on the 345/138
kV transformers supplying the local transmission were set to boost 138 kV system
voltages, resulted in the 138 kV system voltages remaining higher than the 345 kV
system voltages by 3-4%. Area voltages remained above 95% in all but the FostoriaHoward and Lockwood Road (Mark Center) areas. Although these area voltages fell
below 95% on the transmission system, not all customers experienced low voltage
conditions. The majority of the customers are served from AEPs distribution system
where the regulation and shunt capacitors are designed to compensate for lower
transmission system voltages.
Recommendations
As a result of the high loads experienced in June and later periods in the summer, AEP
has decided to add 737 MVAr of shunt reactive support to the transmission system in the
Ohio and Eastern Indiana areas to correct the low voltage conditions and to support
additional load growth.
11/5/99
SYSTEM LOADING CONDITIONS IN ECAR ON AUGUST 19 20, 1999
On August 19 - 20, 1999, the temperatures throughout the northern portion of the Eastern
Interconnection were in the 80s, while temperatures throughout the southern portion were in the
90s and 100s. Consequently, there were many interchange transactions scheduled from the
North to the South, which resulted in high transmission system loadings. The weather pattern
and heavy North to South flow conditions experienced in ECAR on August 19 and 20 were
similar to those that occurred on July 23, 1993 an incident which was investigated and written
up in the 1993 NERC System Disturbances Report. In both incidents, line loading relief was
utilized extensively to maintain system security.
Concerns have been raised regarding why, if the incident was addressed in 1993, did it happen
again? In all likelihood, it should not have.
After the investigation of the July 23, 1993 event was completed, ECAR, MAIN, and TVA
realized that the problem was caused by too many transfers from ECAR and MAIN to TVA and
south of TVA. ECAR, MAIN, and TVA had many discussions concerning this problem and
developed a MET (MAIN, ECAR, TVA) procedure to prevent future occurrences. This
procedure established methods for coordinating transfers from ECAR and MAIN to TVA and
south of TVA to a level that the interconnected network could handle. A special computer
system was installed to implement the new MET procedure and to facilitate the exchange of
information between the MET participants.
Following the 1993 incident, coordinated MET system seasonal studies were performed
annually. These studies were eventually replaced by an on-line system analysis program. The
on-line load flow program runs automatically every 20 minutes and covers the ECAR/MET
control areas. The program can also be run at any time by the security coordinators for special
case analysis. As the real time ISN data becomes available, it is being fed into the load flow
program, which makes the program more accurate. The on-line load flow program gives more
accurate results for actual existing system conditions than the old seasonal studies could provide.
With the establishment of the NERC TLR procedures and the NERC security coordinator
positions, expectations existed for the new security coordinators to be able to monitor the
interconnected system conditions sufficiently to prevent a recurrence of the 1993 incident. After
all, the problem had not recurred in six years. However, as the August incident demonstrated,
this expectation was not justified. After the event, the parties recognized a need to improve the
quality of information being analyzed. After reviewing the August 19-20, event, the AEP
Security Coordinator and the associated control areas began identifying the need for additional
flowgates on the affected systems to increase the amount of information reported to the
monitoring system.
The August incident did, however, provide a good example of the ability of the security
coordinator process, using the recently established iIDC, to respond to system problems. When
the security coordinators ran an analysis on August 19, 1999 using the iIDC, the analysis
11/5/99
indicated that no transactions acted in the Kentucky Utilities, Louisville Gas & Electric, or Big
Rivers systems at 5% or more. The loading on these systems was caused by parallel flows,
which had less than 5% responses. Corrective action taken for August 20, 1999 was to reduce
the available transfer capacity from AEP to TVA and to coordinate all transfers with MAIN.
On-line load flows were run to verify the desired results. In contrast it took ECAR several
months to unwind the transactions which contributed to the 1993 incident.
11/5/99
LOW VOLTAGE CONDITIONS IN MAAC ON JULY 6 &19, 1999

The MAAC Reliability Assessment for the summer of 1999 indicated that MAAC and all sub
areas satisfied the system Network Transfer Capability requirements for the system as forecast.
However, the assessment indicated that eastern PJM and several sub areas possessed limited
margin.
System Conditions July 6, 1999

On July 6, 1999 the MAAC region experienced sustained region wide high temperatures with
corresponding high loads. The Temperature Humidity Index (THI) of 85.3 that was observed on
July 6, 1999 was very unusual and is estimated to occur only once every 25 years. This record
sustained heat resulted in a new peak demand of 51,600 MW (with all load management
programs and a 5% voltage reduction in effect) compared to the 1999 forecast peak demand of
47,570 MW (with interruptible load removed). The July 6, 1999 demand of 51,600 MW
compares with the forecast peak demand for the summer of the year 2004 (51,603 MW with
interruptible load removed).
The record high demand was served with the aid of approximately 6000 MW of transactions into
PJM and the use of PJM emergency procedures which included Load Management, Voluntary
Customer Load Curtailment, and a 5% Voltage Reduction. With the high MW and MVAr loads,
and increased MVAr losses, the PJM bulk power system experienced a widespread reduction in
system voltage beginning at approximately 12:00 noon. Transactions from the systems north of
PJM were not possible and additional transactions from ECAR and SERC could not be delivered
over the transmission network into eastern PJM due to the low voltage conditions. After having
implemented all its emergency action steps except manual load shedding, and as a last resort,
PJM acted to improve the voltage condition by declaring TLR Level 3 to reduce circulation
through PJM. An estimated 200 MW of flow was reduced through eastern PJM by curtailing
1200 MW of transactions.
Voltage Profile 500kV - 7/6/99
BRANCHBURG
550
545
DEANS
540
KiloVolts (kV)
535
N.FREEDOM
530
SALEM
525
520
PEACH
BOTTOM
KEENEY
515
510
505
500
TMI
495
23:00
22:00
21:00
20:00
19:00
EWINDSOR
18:00
17:00
16:00
15:00
14:00
13:00
12:00
11:00
10:00
490
Time
496kV
HOSENSACK
11/5/99
In addition to the widespread voltage situation on July 6, 1999, several sub areas of MAAC,
identified in the MAAC Reliability Assessment as possessing limited margin, sustained forced
transmission facility outages or disproportionate generation outages resulting in the need for
localized load shedding to maintain sub area reliability. Conectiv shed 140 MW of load for local
reliability in the Delmarva Peninsula area, and multiple transformer failures at Redbank
substation in central New Jersey resulted in approximately 600 MW of distribution load being
shed.
System Conditions July 19, 1999

On July 19, 1999, PJM peak demand exceeded 50,500 MW, and the MAAC region began
experiencing an unexpected rapid decline in the bulk power system voltage at approximately
12:00 noon. PJM loaded all available eastern PJM generation and implemented PJM emergency
procedures (all steps of load management and a 5% voltage reduction in eastern PJM) to quickly
restore the bulk power system to the desired level.
550
545
540
535
530
525
520
515
510
505
500
495
490
BRANCHBURG
DEANS
NEWFREED
SALEM
PEACHBOT
KEENEY
TMI
EWINDSOR
HOSENSACK
0:00
1:00
2:00
3:00
4:00
5:00
6:00
7:00
8:00
9:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
19:00
20:00
21:00
22:00
23:00
KiloVolts (kV)
Voltage Profile 500kV - 7/19/99
Low Voltage - Root Cause Analysis

Initial PJM analysis of the July 6 and July 19 incidents resulted in the discovery that generator
MVAr capability used in real-time Security Analysis and study power flow analysis was not
achievable under the ambient temperature conditions that existed on those dates. Interim
Operating Actions were implemented pending a review of all causes of the low voltage
conditions. These interim actions included: modifications to the generator reactive capability
model to better reflect actual capability experienced on these days; the development of additional
voltage interface limits to assist in the prediction of voltage problems; conservative adjustment to
the PJM post-contingency voltage drop criteria; an increase in the use of newly installed EMS
advanced application programs; and increased staffing at the transmission desk.
11/5/99
PJM initiated a Root Cause Analysis investigation to determine all of the conditions leading to
the low voltage situations which occurred on both July 6 and July 19, 1999. The Root Cause
Analysis is underway with final results expected prior to the end of 1999.
11/5/99
LOW VOLTAGE CONDITIONS IN THE ATLANTA, GEORGIA AREA ON

AUGUST 18, 1999
On the afternoon of August 18, 1999, the northwest Georgia area experienced low voltage
conditions on the transmission grid. The event occurred during hot weather with a Southern
Company control area peak demand of about 39,000 MW. Low voltage conditions started to
occur at about 1300 CDT; system peak occurred about 1500 CDT. The 115 kV system voltage
in the Metro Atlanta area was near 109 kV; at Nelson substation, a bus voltage of 104 kV was
recorded. The following generators were out of service at the time: McDonough unit 2 (250
MW), Atkinson unit 2 (60 MW), Buford Hydro (105 MW), and Allatoona Hydro (80 MW).
Additionally, Atkinson unit 3 (65 MW) and Wansley units 1 & 2 (860 MW each) had degraded
reactive capability.
All Metro Atlanta area shunt capacitors were on line. There were no unusual transmission
equipment outages at the time.
Energy flows in the Southern Company control area to serve native load and support energy
transactions were significant. The system was well beyond the Transmission Planning criteria of
loss of any two (2) generating units, with the implied assumption that all remaining units can
produce their design MVAr capacity. Since the actual conditions were beyond Transmission
Planning criteria, prior system modeling studies had not predicted the low voltage conditions that
occurred. Subsequent system modeling with actual reactive data produced results in close
agreement with conditions experienced on the 18th .
Most of the neighboring utilities were also experiencing low voltages. During the event, no
customers were interrupted and no reports of customer problems were noted. Subsequent
modeling studies indicated selected contingencies could have produced severe operating
problems in north Georgia. The total amount of transmission voltage shunt capacitors in the
Northern Georgia area is approximately 5,600 MVAr, all of which are key to the voltage
sensitivity of the Atlanta area. Some load flow models failed to solve with 200 MVAR of shunt
capacitors removed from the system.
The following conclusions have been reached:
Reactive loads in the Metro Atlanta area are greater than forecast.
The Metro Atlanta region load to generation mix is such that MW imports to the region
are required. Since the import of MVArs is more difficult to achieve (as it is basically
limited by voltage level regulation), local sources of MVArs are important to the Metro
Atlanta region.
Several hundred MVAr of fixed capacitors were added to the system in the form of
transmission capacitor banks since the summer of 1998. These capacitors were crucial to
the system during this event.
11/5/99
Recommendations:
Generation VAr limits in the Transmission Planning model are to be reviewed by
Planning, Operations, and Generation Field Services personnel to ensure their accuracy in
the planning models.
Planning for hot weather scenarios should be made assuming higher reactive demands
than have been previously forecast.
Maintaining voltage schedules at generating plants must continue to be emphasized.
Consider trading MWs for MVArs policy.
11/5/99
LOW VOLTAGE CONDITIONS IN ARKANSAS AND OKLAHOMA ON

AUGUST 13, 1999
Summary
On August 13, 1999, at about 1400 CDT, the northwestern part of Arkansas and
northeastern part of Oklahoma experienced unusually low voltage on the 115 kV and 161
kV systems. At the time, Entergy Electric System (EES) was seeking voltage/VAr
support for the area. The SPP Security Working Group (SWG) requested an analysis of
the situation. Data collection surveys were sent to eight SPP control areas, (Central
Louisiana Electric Company (CLEC), Central and Southwest (CSWS), Grand River Dam
Authority (GRDA), Kansas City Power & Light (KCPL), Oklahoma Gas and Electric
(OKGE), Southwestern Power Administration (SPA), Southwest Public Service (SPS)
and Western Resources (WR)), and four neighboring Region control areas, Associated
Electric Cooperative (AECI), Ameren (AMRN), Entergy (EES) and Tennessee Valley
Authority (TVA). The survey requested schedules and interchange information, load
values, line and generator status details, generation MW and MVArs, capacitor and
reactor status details, bus voltages (especially those with low voltages), and tie-line flows
and flowgate flows. Data provided by the responding utilities were included in the model
to complete the analysis. The following material provides a recap of the system
conditions and results of simulation analysis of the event.
System Conditions on August 13, 1999
There were low voltages in two distinct areas: in the area bordering northwest Arkansas
and southwest Missouri and in the area bordering northwest Arkansas and northeast
Oklahoma. Low voltages were reported on the161 kV system in northern Arkansas
ranging from 147.7 kV to 157 kV. At Fort Smith, Arkansas, the 345 kV bus voltage was
329.5 kV. The flow on the Arkansas Nuclear One (ANO) Ft. Smith 500 kV line is
typically from ANO to Ft. Smith, but at 1400 CDT, the flow was approximately 400 MW
in the opposite direction.
A review of all the system data indicated that significant transfers were occurring from
Western Resources, MAPP control areas (Omaha Public Power District, Nebraska Public
Power District and others), AECI and AMRN to EES and TVA (some of which was
continuing on to Southern Company (SOCO) and Florida control areas). The composite
transfer from MAPP, MAIN and SPP control areas to the EES, SOCO and TVA
combination was about 3,000 MW. The schedules from WR to EES were close to 1,000
MW (this included 325 MW from WR generators and the remaining from MAPP and
other control areas). There was about 1,000 MW scheduled to TVA (785 MW from
AMRN and 153 MW from AECI). And, there was about 1,000 MW (net) scheduled
from TVA to EES (actual TVA to EES schedules of 1,663 MW with EES delivering 633
MW to SOCO). TVA also had 1,633 MW scheduled to SOCO. EES normally sells over
1,000 MW to AECI during summer peak conditions. But at 1400 hours on August 13,
1999, EES had only a 20 MW net schedule going to AECI.
11/5/99
EES had outages of its White Bluff Unit 2 (844 MW) and Independence Unit 1 (836
MW), both located in northern Arkansas. If Independence Unit l and White Bluff Unit 2
had been available, their output would have resulted in a displacement of power and
would have resulted in a totally different set of system conditions. Independence Unit 1
was synchronized onto the system at 1336 hours and was at full load by the time of the
peak, around 1700 hours. The availability of this generation provided reactive support
and reduced the level of imports. At the time of the system peak, system conditions were
improving and returning to a state of normalcy.
With a 2-3 day build-up of daily high temperatures and high humidity over the period, the
Oklahoma and Arkansas areas experienced near peak load demands on August 12 and
again on August 13. The survey data indicated that some of the substations in northern
Arkansas had real power demands that were significantly higher than typical summer
demands. This resulted in increased reactive requirements for the area.
Unfortunately, the survey data lacked operating data detail that could be used to
determine power factors at the individual substations. Lacking this operating data detail,
it is impossible to identify one or two substations or a group of substations where high
reactive demand combined with a lack of local voltage support (from generators,
transmission capacitors and distribution capacitors) can be used to explain a localized
voltage problem. It is probably safe to say that while high reactive demand was not the
only contributor to the voltage problems on August 13, when this factor is combined with
the several other factors described in this report, they all contributed to the voltage
problems on that day.
Simulation Analysis
SPP utilized the data provided by the various systems to create a power flow case that
simulated system conditions for 1400 CDT on August 13, 1999. Even though there
wasnt sufficient recorded information on generator voltage readings and reactive
generation on that day, the model was able to simulate some of the low voltages
experienced in the area bordering northwest Arkansas and southwest Missouri.
Low voltages could not be simulated at Van Buren and Branch areas (the area bordering
northwest Arkansas and northeast Oklahoma) using the data provided. The power flow
model produced a 97% voltage at Van Buren, VBI, 3rd Street and Ft. Smith. Not being
able to duplicate low voltage conditions using a power flow model is a common industry
problem. The power flow model tends to overstate voltage conditions because it assumes
all units are committed and supplying reactive support during the peak demand, and it
assumes the units that are running can produce MVArs at their capability limit.
SPP made several sensitivity runs to evaluate the isolated effects of a transmission line
maintenance project, having two EES generators off-line and the high imports into the
EES, TVA and SOCO control areas with the following results.
11/5/99
The outage of a section of the Danville-Hot springs 115 kV line reported by EES did
not result in low voltages in the model.
The effect of having Independence Unit 1 and White Bluff Unit 2 on for voltage
support was analyzed by bringing these units on while backing down generators in
the south Louisiana area. This scenario simulated a condition where the coal-fired
units were on for only voltage support without any impact on the high imports into
EES. The analysis found that by just bringing the units on, and not doing anything to
imports, the voltages in the Harrison and Branson areas improved only 0.3% to 0.5%
and there was no significant improvement to the voltages in the Van Buren and
Branch areas.
By reducing EES imports by 1,300 MW with Independence Unit 1 and White Bluff
Unit 2 off, the voltages in the Harrison and Branson areas improved by 3% to 4%. If
both the imports were cut and the units were brought on, the simulated voltages
returned to near normal conditions.
Conclusion
Low voltage conditions in northwest Arkansas and northeast Oklahoma were caused by a
combination of generators being off in the EES system, high transfers to EES, TVA and
SOCO (some of which made up for the EES lost generation), and a number of local
conditions. The local conditions included:
Systems being close to their near peak loads with high reactive demands to
serve native loads.
Apparent lack of local voltage support from generators, transmission
capacitors and distribution capacitors.
Recommendations
SPP will continue to investigate August 13 conditions to see whether a voltage collapse
situation would have occurred after loss of another transmission line or a generator.
Measures to avoid similar conditions occurring in the future need to be analyzed,
developed and implemented prior to April 2000. The SPP Security Working Group, at its
December, 1999 meeting, will review the analysis of the incident.

Comm OC IS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Comm OC IS

Uploaded by

Copyright:

Available Formats

NORTH AMERICAN ELECTRIC RELIABILITY COUNCIL

Interconnected Operations Subcommittee Meeting

Administrative Gordon Scott

Minutes of December 68, 1999 Meeting

Subcommittee Reorganization John Pope

Draft Policy 3, Version 3 for BOT Consideration

PITF Findings John Pope

Transaction Parking Gordon Scott

Interconnected Operations Subcommittee Agenda

Tagging Issues Ben Li

Tag Submission Times for Market Redispatch Charles Yeung

Tagging Across Interconnection Boundaries Jerry Hagge

Use of Replace Option Jerry Hagge

Public Comments on Appendix 3A1, 3A3, 3A4, and 3D

WSCC Opinions regarding E-Tag Specification

10. Transaction Start Time Gordon Scott

13. Policy 2, Transmission

Add reference to calling TLRs to mitigate OSLs in Policy 2A

OSL Report Form

IMO, February 2, 2000 Event

14. Disturbance Analysis Working Group Report for Summer 1999

Expected Workshop Results

What scheduling items are - Basic, Common, Unique, Special, or Regional?

How should the information be communicated to the scheduling entity?

What are the barriers to implementation?

What strategies can help to overcome the barriers?

February 16, 2000

NORTH AMERICAN ELECTRIC RELIABILITY COUNCIL

INTERCONNECTED OPERATIONS SUBCOMMITTEE MEETING

Draft: December 8, 1999

Interconnected Operations Subcommittee Meeting Minutes

Tagging Intra-Control Area Transactions

Draft: December 8, 1999

Interconnected Operations Subcommittee Meeting Minutes

Modifying Tags via the IDC

February 1618 Albuquerque, NM

Draft: December 8, 1999

NORTH AMERICAN ELECTRIC RELIABILITY COUNCIL

Interconnected Operations Subcommittee Meeting Agenda

Administration Don Benjamin

Minutes of September 2728, 1999 Meeting

Security Committee Revisions to Policy 3

MIC Meeting Review

Policy 3A5 Active approval time notification

Policy 3B4.1.2 Schedule changes that cause OSL violations

Policy 3C Block accounting

Definitions of Source and Sink

Dynamic Transfers Carroll Scheer

Add reference to calling TLRs to mitigate OSLs in Policy 2A

OSL Violation Form

Review of Minority Opinions and Issues for Further Discussion

February 1618, 2000 Albuquerque

Phone 609-452-8060 v Fax 609-452-9550 v URL www.nerc.com

John Pope, Chairman

Jim Byrd (for Sam Jones)

Al DiCaprio (for Bruce Balmat)

Carl Monroe (for Scott Moore)

Summary of Market Interface Committee Action

Includes Responses from December 6 8, 1999 Interconnected Operations Subcommittee

This is already accommodated in Policy 3A2.2. No change needed.

Active Approval A portion of a tag is approved by an entity with approval rights on

Summary of MIC Actions

Passive Approval A portion of a tag is implicitly approved when an entity with