1 / 9

NITS Concepts

NITS Concepts. Contract Data Model: NITS Agreement represented as a Contract Contract has one or more Facilities Facility may be one or more Resources or Loads Load assigned unique SINK name: Multiple SINKs defined to represent discreet load pockets if there are deliverability constraints

aadi
Télécharger la présentation

NITS Concepts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NITS Concepts • Contract Data Model: • NITS Agreement represented as a Contract • Contract has one or more Facilities • Facility may be one or more Resources or Loads • Load assigned unique SINK name: • Multiple SINKs defined to represent discreet load pockets if there are deliverability constraints • Resources assigned unique SOURCE name: • SOURCE may be discreet generator or a system purchase contract • Loads and Resources have multiple associated time-varying profiled data elements, e.g., load forecasts, designated capacity, unit Pmax, etc.

  2. NITS Data Requirements • Contract: • Base Information: • Customer • Term • Eligibility Attestation • Load: • Base Information: • Name (SINK assigned by TP) • Description • Type (non-interruptible/interruptible) • Load Control Area • Point of Delivery • Profiles: • Load Forecast • Interruptible Capacity

  3. NITS Data Requirements • Deliverability Constraints: • Only required if need to limit maximum scheduled MWs from specific Resource (SOURCE) to specific Load (SINK) • Similar to a TSR/TSN • ATC Impact Matrix: • Distribution Factor type representation of impact on ATC from SOURCE to SINK

  4. NITS Data Requirements • Resource: • Base Information: • Name (SOURCE assigned by TP or GCA) • Description • Type (?) • Generating Control Area • Point of Receipt • Profiles: • Unit Size • Designated Capacity • Re-dispatch Cost • Dispatch Merit Order or Block Loading

  5. NITS Transaction Concepts • Transaction Requirements: • Designate Resource (Capacity) • Undesignate Resource • Designate Load (Capacity) • Undesignate Load • Transaction Processing: • Transaction is a request to change Contract • On approval, changes are reflected in the Contract • Transaction itself does not represent the transmission service • Transaction log is audit record of designations, undesignations, etc.

  6. NITS Transaction Concepts • Short Term Requests (daily, weekly, monthly): • Requests for additional Firm or Secondary Network service • Should these be handled as a TSR? • Special Transactions: • Similar in nature to Redirect with respect to ATC/AFC: • Redesignation of network resource • Undesignation with simultaneous request for PTP Service • Tag Processing: • Validations performed against the Contract not a TSR

  7. Preemption and Competition • Concepts Influenced by BPA and MAPP • Issues to Address: • Duration and Pre-confirmation Priority • Conditional Service • Right of First Refusal • Identify Potential Challenger: • Fails AFC/ATC • Flat MW profile over entire duration of request • Preemption: • Unilaterally SUPERSEDE all pending requests of lower “priority” that enhance ability to offer service to higher priority request. • Introduces potential for gaming?

  8. Preemption and Competition Continued • Competition • Identify all conditional reservations of lower priority that would enhance ability to offer service to higher priority request (Challenger) AND that could be accommodated if extended to match Challenger (Defenders). • Extend (partial) offer of service to Challenger. • If Challenger fails to confirm service, no action required. • If Challenger confirms service: • RECALL capacity “At Risk” from all Defenders to meet Challenger’s capacity • Issue MATCHING COUNTEROFFER requests to all Defender’s for ROFR • As each Defender confirms match, RECALL capacityfrom Challenger

  9. Preemption and Competition Continued • Driving Principles • Secure higher priority service before initiating any recalls of lower priority reservations • Eliminate customer confusion on what is required to initiate ROFR by creating MATCHING request on Customer’s behalf • Ensure MATCHING requests are feasible, but not necessarily simultaneously feasible • Simultaneously infeasible MATCHING requests go to first to CONFIRM

More Related