Pseudo-tie Registration in Electric Industry Registry Discussion Paper - 02/18/2013

The North American Electric Reliability Corporation’s (NERC) Dynamic transfer Reference Guidelines (Version 2) provides an excellent overview of the nature of the two dynamic transfers, Dynamic Schedules and Pseudo-ties, and the implementation issues associated with them. These issues are both reliability centered and commercially centered.

One such issue cites a fundamental obligation:

Before implementing the dynamic transfer, all parties to the dynamic transfer must agree on all implementation issues.

This applies source to sink, all Balancing Authorities (BA), all transmission providers, and all purchasing-selling entities involved in the dynamic transfer.

NERC’s Project 2008-12 standard drafting team recognized the importance of this obligation and drafted a reliability standard requirement to ensure all implementation issues impacting reliability have been agreed upon prior to operation of a pseudo-tie. The BA implementing a pseudo-tie in its ACE equation must provide evidence that all parties aware of and have agreed to implementation issues of the pseudo-tie.

The standards drafting team was however concerned about the administrative burden of collecting and maintaining documentation and affidavits demonstrating compliance with this requirement. As such, it was suggested that the Electric Industry Registry could be modified to facilitate the entry and approval of pseudo-ties. The electronic version of documentation and affidavits would be easily accessible and transparent to all.

As such, the drafting team submitted an EIR Enhancement Request to the North American Energy Standards Board (NAESB), owner of the EIR, to develop a new registry object called Pseudo-tie that would require approvals by entities listed within the object. This paper presents one possible vision of the design and implementation of the Pseudo-tie registration.

What Information is Registered?

Basically it would be a representation of the e-Tag’s “physical path”. The physical path is comprised of three physical segments, generation, transmission, and load, which are described in the e-Tag specification as follows:

Generation Segments contain information that describes a generation resource, such as the location of the generation, the firmness of the energy supplied by the resource, and contract references that identify the resource commitment. Generation Segments may only utilize products in the Electric Industry Registry related to Generation.

Transmission Segments contain identification that describes a transmission service, such as the identity of the provider, the POR and POD of the service, the firmness of the service, simple loss information, and contract references that identify the service commitment. Transmission Segments may only utilize products in the Electric Industry Registry related to Transmission.

Load Segments contain information that describes a load, such as the location of the load, the interrupt-ability of the load, and contract references that identify the load obligation. Load Segments may only utilize products in the Electric Industry Registry related to Load.

For the purposes of registration, not all physical segment information is needed. Below is the recommended required information:

Segment / Registration Information
Generation (only 1 segment) /
  • Source BA
  • Source Point

Transmission (at least 1 segment) / For each segment:
  • POR
  • POD
  • Transmission Service Provider
  • Contract Reference Number (e.g., OASIS a_ref, etc.)
  • Scheduling Entity (e.g., BA in which the POR-POD reside.)

Load (only 1 segment) /
  • Sink BA
  • Sink Point

All information would be available via drop-downs except the Contract Reference Number.

Although not directly related to the physical segments, the submitter would also need to include all Reliability Coordinators (RCs) through which the pseudo-tie in located.

And, besides physical path information, each pseudo-tie would have a unique identifier, a start & stop date, an existing pseudo-tie check box, and a comment field.

Who Would Approve?

All entities listed in the registration would be notified of a pending approval which they need to respond. By approving, the entity is agreeing that from their perspective, the information entered is correct and all agreements have been established to ensure reliability and commercial obligations.

Below is the list of who is expected to be required to approve the registration:

Segment / Required Approver
Generation (only 1 segment) /
  • Source BA
  • PSE who registered the Source Point

Transmission (at least 1 segment) /
  • Each Transmission Service Provider identified with a POR-POD segment
  • Each Scheduling Entity that is not the Source or Sink BA

Load (only 1 segment) /
  • Sink BA
  • PSE who registered the Sink Point

Other / Each RC that is associated with any BA or Transmission Service Provider listed above

Process

Typically the BA implementing the pseudo-tie would provide the initial entry of information. Upon submission, the EIR would assign an unique identifier to the pseudo-tie object and send notifications to all approving entities that their review is needed and start a countdown for the approval period (initially suggest 10 days). By accessing the Pending Approvals in the EIR interface, the approving entity can view the pending Pseudo-tie object and all its information. The approving entity can either approve or deny with a comment required. The registering entity (submitter) will receive notification of any denial and be able to access the approvers denial comment. Approving entities can change their approvals/denials anytime during the approval period.

Once all approvals have been submitted, a notification will be sent to all involved that the pseudo-tie will be included in the next regularly scheduled EIR publication.

Approved Pseudo-tie objects can be modified to reflect changes in information (e.g., Transmission Contract Numbers, etc.). Changes to any physical segment will require re-approval by approval entities and any RC listed in the pseudo-tie object.

Once approved, a Pseudo-tie object would remain valid unless terminated by the registering entity. Approved Pseudo-tie objects can be terminated by the registering entity with a one week lead time. The EIR will notify all approval entities of the pending termination. Terminations can be cancelled during the one week lead time. Cancellation of the pending termination will be communicated to all approval entities.

Other Opportunities

This registration process could also serve additional purposes, such as:

  1. In order to assist in compliance with INT-004 R1, the registration process could include a question related to how the pseudo tie is considered in congestion management processes. This would be a place a PSE could point to if they do not need to submit e-Tags for this pseudo-tie. There could be a question such as: “Will this pseudo-tie be explicitly modeled in congestion management processes or will it be tagged? (Modeled/Tagged)”
  2. e-Tag Agent Service vendors could pre-populate new pseudo-tie type tags with the registry data to assist in the creation of the e-Tag.

1