Multiple SINKs defined to represent discreet load pockets i

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 Challengers capacity
• Issue MATCHING COUNTEROFFER requests to all
  Defenders 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
  Customers behalf
• Ensure MATCHING requests are feasible, but not
  necessarily simultaneously feasible
• Simultaneously infeasible MATCHING requests go to
  first to CONFIRM