RECOMMENDATION TO NAESB EXECUTIVE COMMITTEE
For Quadrant: Wholesale Electric Quadrant (WEQ)
Requesters: OASIS Subcommittee
Request No.: 2011 API 2.a.iii.1 through 2.a.iii.3
Request Title: Service Across Multiple Transmission Systems (SAMTS)
Comments from OATI on the proposed recommendation for SAMTS
April 21, 2011
General Comments:
The following are general comments and suggested changes to be considered to the SAMTS recommendation. OATI has no problems with the suggested functionality, but there are some changes to the data requirements and clarifications to some of the BPs that may better clarify the intent of the standards without change the basic concepts and requirements agreed to within the OASIS Subcommittee.
1. The recommendation proposes addition of two new STATUS values, CR_COUNTEROFFER and CR_ACCEPTED. It is possible to handle the SAMTS requirements for confirmation time limit and the hold on final action for all requests in the coordinated group based solely on the combination of STATUS and CG_FLAG. The new STATUS values may stand out to all Customer’s that the TSR under consideration is ‘special’, but if there are significant comments to reduce the overall scope of technical changes on OASIS, these new status values are not strictly required to implement SAMTS.
2. In the WEQ-013 discussion of withdrawal of pre-confirmed requests, there is an exception that long-term coordinated requests may not be withdrawn. It is suggested that this exception be removed and a coordinated long-term request may be withdrawn at any time.
a. Note that 001-xx.3.5.1 does explicitly allow for withdrawal with proviso that it does not let any other CRs off the hook. If the exception is retained xx3.5.1 needs to be removed. Suggest instead that XX.3.5.1 be included and the exception in WEQ-013 removed.
b. 05/03/11 moved to parking lot item 1) dated 05/03/11
3. Note that there is the provision that when final actions are taken (xx.3.5), the Customer must update all other Coordinated Requests and indicate that the withdrawn request has been acted on (later comment suggest that this action be incorporated into the CR_ACCOMMODATED data element). Once any Coordinated Request is not granted in full they can withdraw the other requests. In the text for 4.9.4 and 4.9.5, the BPs should be based on the information that is available on any given Coordinated Request. So, the standards should make only reference to the CAPACITY_GRANTED and CAPACITY_REQUESTED for a specific CR and the CR_ACCOMMODATED value for all other CRs in the CG.
4. 05/03/11 moved to parking lot item 2) dated 05/03/11
5. In recommendation 4.11.1, there is a provision to move CR_ACCEPTED to CONFIRMED. 4.11 already gives the right to move CR_COUNTEROFFER to RETRACTED, so that really isn’t an exception. Why shouldn’t the TP have the right to force confirmation of a CR_COUNTEROFFER as well as the CR_ACCEPTED state? The Customer has had time to evaluate the offer, and has been given an extended period of time to act and hold queue position, so might consider that for those extra rights comes the consequence that if do not take timely action, you may be forced to take service by the TP.
6. 05/03/11 moved to parking lot item 3) dated 05/03/11 and made decision.
7. Suggest that the timing information from the SAMTS section be explicitly included in the Table 4-2 rather than having the table forward reference to SAMTS. Also the measurement time can’t be from when all Coordinated Requests in CG are first moved to CR_ACCEPTED or CR_COUNTEROFFER, because the OASIS of one TP is not monitoring any other nodes. The wording in the footnote should be revised to base the time as being from time TSR is set to CR_ACCEPTED or CR_COUNTEROFFER AND CR_ACCOMMODATED in all CR’s in the CG is set to a value other than PENDING.
8. Wordsmithing issue will address when we get there
9. Suggest that standard 001-xx.3.1, requirement for preconfirmation, is actually a condition of eligibility and should be moved to 001-xx.2.
10. 05/03/11 subcommittee decided to move it.
11. The information requirements for SAMTS should be reconsidered as follows:
a. There is a contiguity requirement, but nowhere is there any indication of the time frames of any of the CRs in the CG communicated. It would seem that time is actually of more importance then the capacity values proposed. It would also seem that one could remove the CG_CONTIGUITY ‘attestation’ if you required the Customer to provide the evidence of all requests and reservations that satisfy that requirement. There is no obligation of the TP to verify that the data is correct on other nodes, but at least there would be information supplied that could be used to verify contiguity. Without that, there is little one could do to prove comparable treatment. The OS should reconsider whether there is value in requiring at least information on the total start/stop interval of each CR and possible of each reservation used to back the CG.
b. 05/03/11 moved to parking lot item 4) dated 05/03/11 and made decision.
c. The CR_CAPACITY_REQUESTED and CR_CAPACITY_GRANTED are somewhat problematic as these could be profiled values. What should be reported? Minimum? Maximum? The BP would need to be specific on treatment. These elements really provide no more information than could be captured by having the Customer required to indicate if the CR was granted in FULL or PARTIAL or not at all in the CR_ACCOMMODATED element. Or, one could actually just require that CR_ACCOMMODATED be set to final state of each TSR or CR_ACCEPTED or CR_COUNTEROFFER as applicable when each CR in CG is completed. Once all CR_ACCOMMODATED elements in the CG are no longer PENDING the request will go forward with confirmation deadlines.
d. 05/03/11 moved to parking lot item 5) dated 05/03/11 and made decision.
e. Included CR_TS_CLASS and CR_INTERVAL in the information. The timing table in 4-2 only addresses PTP, and the NITS timelines may not necessarily be on par with the PTP, so suggest that adding CR_TS_TYPE to the elements would be of value in the event there were a change and NITS and PTP did not have identical timelines.
f. 05/03/11 moved to parking lot item 6) dated 05/03/11 and made decision.
g. CR_ACCOMMODATED should be used to provide the information if other CRs in the CG were accepted in full or part or even withdrawn early from the CG if we allow long-term CR withdrawals (which is recommended).
h. 05/03/11 already included in the answer to b.
i. CR_SUBMIT_DEADLINE functionally can be handled using the RESPONSE_TIME_LIMIT data element rather than defining a new data element.
j. Subcommittee decided to keep the same concept of two different timelines.
k. CG_FLAG and CG_CONTIGUITY can be collapsed into a single data element by using enumerated valus such as PROPOSED (or PENDING) when first submitted, SUBMITTED when all CRs in the CG documented, and NONE or N if the request is not or no longer part of a CG. Specific enumerated values can be determined by the OS.
l. 05/03/11 moved to parking lot item 7) dated 05/03/11 and made decision.
m. There is an inconsistency within the recommendation on use of CR_REQUESTED and CR_GRANTED vs. CR_CAPACITY_REQUESTED and CR_CAPACITY_GRANTED that needs to be rectified.
n. 05/03/11 already included in the answer to b.
o. Summary of changes recommended:
i. Merge information conveyed by CG_FLAG and CG_CONTIGUITY into single data element.
ii. Remove CR_CAPACITY elements and convey information in CR_ACCOMMODATED.
iii. Add TS_TYPE to service attributes captured.
iv. Remove CR_SUBMIT_DEADLINE and use RESPONSE_TIME_LIMIT.
v. Suggest some name changes to data element names in addition to defining separate template for these elements.
vi. 05/03/11 already included in the answer in a-g above
12. For the OASIS S&CP recommended changes, the SAMTS data elements have been added to the basic TSR transstatus template structure as continuation records. This use of continuation records is only spelled out for transcust but if used really applies to transrequest and transstatus as well and needs to be explained. The last set of changes made to OASIS S&CP for cco and rollover were originally proposed as extensions to transstatus in continuation records but commenter’s objected to making such drastic changes to existing template structures so the OS opted to build the separate companion templates. Suggest that the same action be taken in handling SAMTS. Only include in the transstatus template the addition of the CG_FLAG and let that data element (maybe renamed) be used for the current proposed use of both CG_FLAG and CG_CONTIGUITY.
13. 05/03/11 moved to parking lot item 8) dated 05/03/11 and made decision.
14.
15. To the greatest extent possible, it is recommended that OASIS Data Element names not be included in the WEQ-001 standards. The specifics are better included in the WEQ-002 and WEQ-013 standards. This may be too drastic a revision to the recommendation at this point in time, but specific changes are provided in these comments that might be considered by the OS to make the WEQ-001 less dependent on specifics better dealt with in WEQ-002 and WEQ-013.
16. This is a word smitting item
17. WEQ-001-xx.3.4.2.3 allows for resetting of the preconfirmed flag, but this data element was removed and has not been reinstated in the transcust template.
18. 05/03/11 moved to parking lot item 9) dated 05/03/11 and made decision.
The following are specific recommendations for changing the SAMTS and related BPs shown as track changes. To make the changes to WEQ-001-xx.* show up better, I flipped that section of the recommendation to not be in hard redlines so only our comments appear as redlines.
Recommended Standards:
The following modifications to WEQ-000, WEQ-001, WEQ-002, WEQ-003 and WEQ-013 are recommended to implement the Commission’s findings in Orders 890.
Additions to WEQ-000-1 (Acronym)
SAMTS – Service Across Multiple Transmission Systems
Additions to WEQ-000-2 (Glossary)
Coordinated Group – Two or more PTP and/or NITS requests that are linked together for the purpose of procuring service across multiple transmission systems on a Transmission path. The Coordinated Group shall be made up of two or more requests, and may include reservations, such that there is no gap in service over a given path to meet contiguity requirements.
Coordinated Request – A PTP or NITS request that is part of a Coordinated Group.
Network Customer –Shall have the same meaning as defined in the FERC Pro Forma OATT.
Revisions & Additions to WEQ-001
001-4.6 A Transmission Provider/Reseller shall respond to a Transmission Customer’s service request, consistent with filed tariffs, within the Transmission Provider evaluation time limit defined in Business Practice Standard WEQ-001 Table 4-2 Request Timing Requirements. The time limit is measured from the time the OASIS Transmission Service request is QUEUED. A Transmission Provider may respond by setting the state of the reservation request to one of the following:
I. INVALID
II. DECLINED
III. REFUSED
IV. COUNTEROFFER or CR_COUNTEROFFER
V. ACCEPTED or CR_ACCEPTED
VI. RECEIVED or STUDY (leading to REFUSED, COUNTEROFFER, CR_COUNTEROFFER, CR_ACCEPTED or ACCEPTED, or CR_ACCEPTED).
001-4.7 Prior to setting a request to ACCEPTED, CR_ACCEPTED, COUNTEROFFER, CR_COUNTEROFFER, or REFUSED a Transmission Provider shall evaluate the appropriate resources and ascertain that the requested ATC is (or is not) available.
001-4.7.2 If the Transmission Provider determines there is sufficient ATC available to grant the Transmission Customer’s request and the customer’s bid price is at least equal to the Transmission Provider’s current posted offer price over time and all other Transmission Provider requirements have been met, the Transmission Provider shall respond by setting the request status to ACCEPTED or for a Coordinated Request the Transmission Provider shall respond by setting the request to CR_ACCEPTED.
001-4.7.2.1 If the Transmission Customer does not specify a bid price, the Transmission Provider shall consider the bid price to be equal to the current posted offer price when evaluating the request.
001-4.7.3 The Transmission Provider shall use the status of COUNTEROFFER, or for a Coordinated Request the Transmission Provider shall use the status of CR_COUNTEROFFER, to initiate the negotiation of requested capacity (Partial Service) and/or price.
001-4.7.3.2 If the ATC can support only a portion of the total capacity requested by the Transmission Customer and the Transmission Provider is obligated or elects to offer what limited capability is available to the Transmission Customer, the Transmission Provider shall notify the Transmission Customer on OASIS by setting the amount of capacity being offered over time in the transmission request and updating the request status to COUNTEROFFER or for a Coordinated Request the Transmission Provider shall update the request status to CR_COUNTEROFFER.
001-4.7.3.4 If the Transmission Provider elects to continue to negotiate price, the Transmission Provider shall update the offer price over time in the transmission request, indicate whether the price being negotiated is higher or lower than the posted price, and set the request status to COUNTEROFFER or for a Coordinated Request the Transmission Provider shall set the request status to CR_COUNTEROFFER.
001-4.7.3.4.1 If negotiation of price on one Coordinated Request is continued by the Transmission Provider, through CR_COUNTEROFFER, such negotiation of price only does not automatically initiate negotiation of price or capacity on other Coordinated Requests in the Coordinated Group.
001-4.7.3.5 If both capacity and price are being negotiated, that negotiation shall be performed simultaneously.
001-4.9 The Transmission Customer may change a request from QUEUED, RECEIVED, STUDY, COUNTEROFFER, CR_COUNTEROFFER, REBID, CR_ACCEPTED or ACCEPTED, or CR_ACCEPTED to WITHDRAWN at any time prior to CONFIRMED except as follows:
001-4.9.4 When the CAPACITY_GRANTED is less than the original CAPACITY_REQUESTED for any Coordinated Request in a Coordinated Group, the The Transmission Customer shall be is permitted, but is not required, to withdraw any preconfirmed Coordinated Request in the Coordinated Group when the Transmission Customer has notified the Transmission Provider that one or more of the other Coordinated Requests in the Coordinated Group was denied or granted at a lower capacity than requested.
001-4.9.5 The Transmission Customer shall not change the status of any preconfirmed Coordinated Request from CR_ACCEPTED to WITHDRAWN unless one or more of the other Coordinated Requests in the Coordinated Group was denied or granted at a lower capacity than requested. the value for CR_ACCOMMODATED is set to “N”, in accordance with Business Practice Standard WEQ-001-xx.3.4.1.1, for at least one Coordinated Request in the same Coordinated Group.