Board Report
SCR Number / 783 / SCR Title / Outage Scheduler Enhancements – Groups2 and 3, Group Outage, Usability and Filtering Enhancements
Timeline / Normal / Action / Approved
Date of Decision / February 10, 2015
Effective Date / Upon system implementation.
Priority and Rank Assigned / Priority – 2015; Rank – 1240
Supporting Protocol or Guide Section(s) / Protocol Section 3.1.4.5, Notice of Forced Outage or Unavoidable Extension of Planned or Maintenance Outage Due to Unforeseen Events
3.1.5.1, ERCOT Evaluation of Planned Outage and Maintenance Outage of Transmission Facilities, for TSPs
3.1.6.6, Timelines for Response by ERCOT for Resource Outages, for QSEs
Nodal Operating Guide Section 3.2.3, Regulatory RequiredIncident and Disturbance Reports
Other Document Reference/Source / Requirements, as compiled and categorized into groups during the NPRR219 and Outage Scheduler Enhancement Workshops conducted in April and June of 2014, along with the tracking identification, can be found at the following link:
System Change Description / This System Change Request (SCR) will provide group Outage, usability and filtering enhancements in the Outage Scheduler.
Reason for Revision / Addresses current operational issues.
Meets Strategic goals (tied to the ERCOT Strategic Plan or directed by the ERCOT Board).
Market efficiencies or enhancements
Administrative
Regulatory requirements
Other: This SCR addresses the items discussed during a series ofOutage Scheduler Enhancement Workshops.
Procedural History / On 9/24/14, SCR783 and an associated Impact Analysis were posted.
On 10/9/14, PRS considered SCR783.
On 12/4/14, ERCOT comments were posted.
On 12/11/14, PRS again considered SCR783.
On 12/19/14, a revised Impact Analysis was posted.
On 1/15/15, PRS considered the 12/11/14 PRS Report and Impact Analysis for SCR783.
On 1/27/15, CenterPoint Energy comments were posted.
On 1/29/15, TAC considered SCR783.
On 2/10/15, the ERCOT Board considered SCR783.
PRS Decision / On 10/9/14, PRS unanimously voted to table SCR783. All Market Segments were present for the vote.
On 12/11/14, PRS unanimously voted to recommend approval of SCR783 as amended by the 12/4/14 ERCOT comments and as revised by PRS. All Market Segments were present for the vote.
On 1/15/15, PRS unanimously voted to endorse and forward to TAC the 12/11/14 PRS Report and Impact Analysis for SCR783 with a recommended Priority of 2015 and rank of 1240. All Market Segments were present for the vote.
Summary of PRS Discussion / On 10/9/14, it was explained that a workshop would be scheduled to allow for additional review and input.
On 12/11/14, it was explained that the 12/4/14 ERCOT comments reflect the efforts of the Market Participant workshops to reduce the costs for implementation.
On 1/15/15, ERCOT Staff reviewed the revised Impact Analysis and noted that SCR783 could be implemented with NPRR219, Resolution of Alignment Items A33, A92, A106, and A150 - TSPs Must Submit Outages for Resource Owned Equipment and Clarification of Changes in Status of Transmission Element Postings, as a single project. Market Participants opined that the cost of the enhancements to the Outage Scheduler is significantly less than the cost to replace the Outage Scheduler. It was clarified that Market Participants would be able to see their own Outage information.
TAC Decision / On 1/29/15, TAC unanimously voted to recommend approval of SCR783 as recommended by PRS in the 1/15/15 PRS Report. All Market Segments were present for the vote.
Summary of TAC Discussion / On 1/29/15, participants discussed the benefits of the proposed enhancements to the Outage Scheduler; that extensive efforts were made by Market Participants to reduce implementation costs while maintaining necessary improvements; and that SCR783 along with NPRR219 represent an affordable improvement to the current Outage Scheduler.
ERCOT Opinion / ERCOT supports approval of SCR783.
Board Decision / On 2/10/15, the ERCOT Board approved SCR783 as recommended by TAC in the 1/29/15 TAC Report.
Business Case
Qualitative Benefits / The revised SCR783 restores needed functionality that existed in the Zonal Outage Scheduler and adds functionality that Market Participants expected and needed in the Nodal Outage Scheduler. In tandem with the implementation of NPRR219, Resolution of Alignment Items A33, A92, A106, and A150 - TSPs Must Submit Outages for Resource Owned Equipment and Clarification of Changes in Status of Transmission Element Postings, the visibility and tracing of outages for all Market Participants will enable Market Participants and ERCOT to use Outage Scheduler information in Real-Time operations and in audits conducted pursuant to the Nodal Protocols and Guides and the NERC Reliability Standards.
Quantitative Benefits / Not quantified.
Impact to Market Segments / Transmission Service Providers (TSPs), Resource Entities, Qualified Scheduling Entities (QSEs) and Independent Power Marketers (IPMs) will all have access to, and use, the functionality enabled by SCR783.
Other / Additional Business Case information has been provided below with each issue.
Sponsor
Name / Woody Rickerson
E-mail Address /
Company / ERCOT
Phone Number / 512-248-6501
Cell Number
Market Segment / Not applicable.
Market Rules Staff Contact
Name / Cory Phillips
E-Mail Address /
Phone Number / 512-248-6464
Comments Received
Comment Author / Comment Summary
ERCOT 120414 / Proposed revisions to reduce the scope of the enhancements to the Outage Scheduler in an effort to reduce implementation cost.
CenterPoint Energy 012715 / Supported the enhancements to the Outage Scheduler proposed by SCR783 and NPRR219.
Business Case for Proposed System Change
The following are the proposed modifications to SCR783:
Issue 1 (Tracking ID OS.06):
Allow entry of the New Planned End Date up to two hours past the current Planned End Date.
Resolution:
Allow submitters to change the Planned End Date up to two hours past Planned End.
Business Case:
Submitters will have more flexibility in extending Outages and will not be forced to enter a new Outage type if the Planned End time has passed.
Issue 2 (Tracking ID OS.04):
Create a view which displays group and related elements as a single line entry.
Resolution:
Allow Market Participants to show more groups on a Summary page.
Business Case:
Group Outages are a useful feature of the Outage Scheduler. Ensures that the viewer of the grouped Outage has the ability to see and evaluate based on the entire grouped Outage when making decisions. Also, this change will allow more groups to be viewed in less screen space.
Issue 3 (Tracking ID OS.07):
Nature of work, High Sustained Limit (HSL)/Low Sustained Limit (LSL), restoration time, requestor phone, and notes, for a group Outage addition and removal of equipment fields should be editable at any point for received at ERCOT Outages.
Resolution:
Allow group Outages in Received status to be changed.
Business Case:
Outage submitters should be able to change the information associated with an Outage. This change will allow more up to date information to be entered without starting a new Outage. The change will apply only to Outages with a Received status.
Issue 4 (Tracking ID OU.02):
Outage Scheduler should have a full audit trail of all actions for an Outage (an Outage history).
Resolution:
Allow audit trail to be viewed by Market Participants.
Business Case:
Outage submitters need to be able to track the life span of an Outage. This change enables the audit trail for the full life cycle of the Outage to be available to Outage submitters.
Issue 5 (Tracking ID OS.03):
Allow addition of elements to a grouped Outage in Received status only.
Resolution:
Allow elements to be inserted in Group Outages (Received status only).
Business Case:
This change will allow Outage submitters to add elements to Groups that are in Received status at ERCOT, increasing the usability of the Outage Scheduler for submitters. The change will apply only to Outages with a Received status.
Issue 6 (Tracking ID OS.05):
Derate Outages should be allowed to overlap considering the total value across all overlapping Derates.
Resolution:
Allow Derate overlapping for Resources.
Business Case:
Units often need to Derate their capability. Simultaneous Derates of different amounts and durations do occur for the same unit. This change will allow these to be represented independently in the Outage Scheduler as separate Derate Outages.
Issue 7 (Tracking ID FQ.01):
Ability to filter by station without having to drill down.
Resolution:
Enhance the filter functionality allowing station only search criteria.
Business Case:
Outage submitters need to be able to use the station as a filtering criterion without knowing the owner and operator of the station. Removing the dependency on a hierarchy filter will allow the submitter to find stations without having to know the dependent hierarchy fields currently in the filter. This will increase the usability and find capability of the Outages in Outage scheduler.
Issue 8 (Tracking ID FQ.02):
Ability to filter by Nature of Work.
Resolution:
Increase the filter functionality by allowing the Nature of Work to be part of the criteria.
Business Case:
Outage submitters need to be able to use the Nature of Work as a filtering criterion in order to manage their Outages. This change will provide that capability.
Issue 9 (Tracking ID OS.02):
The maximum number of pieces of equipment which can be included in a Group Outage is currently set at 30. For TSPs, long transmission lines may have more than 30 devices in the Network Operations Model which must be entered into the Outage Scheduler. In these situations, TSPs must enter two or more Group Outages.
Resolution:
Increase the number of elements allowable in a Grouped Outage to 60
Business Case:
TSPs would like the maximum number of devices which may be submitted in a Group Outage increased from 30 to 60 pieces of equipment. This increase should handle all current and future transmission system configurations.
Issue 10 (Tracking ID FQ.05):
Due to the huge amount of data stored in the Outage Scheduler database the Custom Filter and Application Programmatic Interface (API) cannot currently return all of the requested information when filtering for large amounts of data.
Resolution:
Fix the maximum records returnable on a filter and API (current limit is 73000 records).
Business Case:
The Custom Filter feature and API needs to be fixed to allow the maximum record limit of 7000 to ensure the return of large data requests.
Issue 11 (Tracking ID OU.01):
For requesting entities communicating with the ERCOT Outage Scheduler via External Web Services, the requestor name being captured in the Outage records is the External Web Services Certificate name and not the name of the actual requestor. In most cases this is a cryptic name or number which has no meaning.
Resolution:
Name of person submitting Outage should be displayed, not the username on the API certificate.
Business Case:
Outage records need to capture the actual name of the requestor logged in to the Outage Scheduler and not the External Web Services certificate name. ERCOT needs the name of the requestor to contact if more information, clarification etc. is needed pertaining to submitted Outages.
Issue 1 (Tracking ID OS.06):
For Planned Outages, there is no dead band in the Outage Scheduler for Outages which are not completed by the exact Planned End Time (to the second). The purpose of this change is to allow the requesting Entity to submit an Unavoidable Extension for a defined period past the Planned End.
Resolution:
Allow entry of the new Planned End Date up to two hours past the current Planned End Date.
Business Case:
Current process requires the creation of a Forced Outage if a Planned Outage is not completed or Extended by the exact Planned End Time. This change will more accurately reflect the true number of Unavoidable Extensions and Forced Outages as defined in Protocol Section 3.1.4.5, Notice of Forced Outage or Unavoidable Extension of Planned or Maintenance Outage Due to Unforeseen Events.
Issue 2 (Tracking ID OS.04):
Each Outage Summary screen display shows 25 lines of active Outages. This change will collapse Group Outages (which can have up to 30 devices currently, possibly 60 future) to one single reference line which can be expanded or condensed as needed.
Resolution:
Create a view which displays group and related elements as a single line entry
Business Case:
When Groups are condensed - displays more active Outages per summary screen. Also improves ability to locate an Outage and enter Actual Start and Actual End Times.
When Groups are expanded - improves ability to focus on just the Outages within a Group.
Issue 3 (Tracking ID OS.07):
When an Outage is in Received status, only the Outage Planned/Earliest Start and Planned/Latest End fields may be edited. If any fields other than these needs to be edited, the request must be Canceled and completely re-submitted.
For Approved/Accepted Outages, if any fields need to be revised prior to the Outage becoming Active (Actual Start), the Outage must be Canceled, Copied or modified and resubmitted.
Resolution:
Nature of work, High Sustained Limit (HSL)/Low Sustained Limit (LSL), restoration time, requestor phone, and notes, addition and removal of equipment fields should be editable at any point for received Outages; if an Outage is in Accepted or Approved status, the Outage will go back to Received.
Business Case:
When in Received status, this change will allow the requestor to edit all of the enterable fields in an Outage request, which will reduce the number of Canceled and resubmitted Outages.
When in Approved/Accepted status (and prior to Actual Start), the requestor will be able to modify the original request and resubmit the Outage – which will automatically change the status back to Received status.
Issue 4 (Tracking ID OU.02):
Transmission Service Providers (TSPs) and Resource Entities must often recreate the events which occurred during Outages for audits, investigations, incidents and disturbances. The current Outage Scheduler does not have the ability for requestors to view and download or copy an Outage history. At a minimum, Market Participants need access to a history log with:
Date & time for each action
Entity making the submittal or change
Record of the data submitted or changed.
Resolution:
Outage Scheduler should have a full audit trail of all actions for an Outage (an Outage history)
Business Case:
Provides Market Participants access to Outage history records which may be requested or used during ERCOT, North American Electric Reliability Corporation (NERC)/Texas Reliability Entity (Texas RE) and Independent Market Monitor (IMM) audits, spot checks, disturbance & incident reports and investigations.
Supports Nodal Operating Guide Section 3.2.3, Regulatory Required Incident and Disturbance Reports.
Supports NERC Standard TOP-003-1, Planned Outage Coordination: each responsible Entity will be audited every three years. Outage history data must be retained for one calendar year without a violation from the time of a violation.
Issue 5 (Tracking ID OU.05):
Qualified Scheduling Entities (QSEs) must open a separate Outage Scheduler session for each of the sub-QSEs and other QSEs which they represent, with each session having its own 30 minute timeout window.
Resolution:
Login using multiple Digital Certificates or the ability to select a Digital Certificate without logging out / back in.
Business Case:
QSEs would like the ability to open multiple Digital Certificates for each of the sub-QSEs and other QSEs which it represents in one Outage Scheduler session. This capability will be very important when submitting Outages on Resource Entity-Owned transmission assets in the QSE’s portfolio.
Issue 6 (Tracking ID OS.11):
“Invisible” or “Null” characters periodically get input to the Outage Scheduler Notes fields, including entries via External Web Service. This usually occurs while cutting-and-pasting in the Notes areas. If the Market Participant filters for a day that has an Outage with special characters, it will lock the Outage Scheduler User Interface until ERCOT Production Support Staff can manually remove them.
Resolution:
Resolve issue where special characters in the Notes field will lock up the Outage Scheduler
Business Case:
If the Outage Scheduler User Interface locks when filtering due to special characters in the Notes fields, the Market Participant does not have visibility of any ongoing Outages until the problem is manually corrected by ERCOT Staff. This change request will fix the issue of the Outage Scheduler User Interface locking the Market Participant from Outage Schedule usability.
Issue 7 (Tracking ID OS.03):
As stated in Issue 3 (OS.07) above, once an Outage is initially submitted, all entry fields except Planned/Earliest Start and Planned/Latest End are locked. Devices cannot be added or removed from a Group Outage request while in Received status.
Resolution:
Allow addition of elements to a grouped Outage in Received status only.
Business Case:
As stated in Issue 3 (OS.07), allows a requestor to add or remove devices in a Group Outage while in Received status without having to Cancel and resubmit the request.
Issue 8 (Tracking ID OS.05):
Each Resource may only have a one Planned, Forced or Maintenance Derate Outage at a time with no overlaps. If an additional Derate Outage causing a change to the HSL of a Resource occurs, the original Outage must be canceled and resubmitted as a new Outage request.
Resolution:
Derate Outages should be allowed to overlap considering the total MW value across all overlapping Derate Outages.
Business Case:
The Outage Scheduler Derate Outage process must be modified to allow multiple overlapping Derate Outages to occur on a Resource at the same time.
Issue 9 (Tracking ID FQ.01, FQ.02, FQ.03 and FQ.04):
Current Custom Filter only allows filtering for:
Specific From/To Dates
Outage ID
Group Name
Outage Type
Outage Status
Requesting Entities
Substation Name & Equipment
Resolution:
Ability to filter by station without having to drill down
Ability to filter by Nature of Work
Ability to filter by area (interconnect)
Ability to filter by in-service date
Business Case:
Market Participants would like the ability to filter on the Station name only when filtering for Outages. This will significantly reduce the time it takes to filter Outages plus reduce the chance of an Outage not appearing in the results.
Market Participants would like the ability to apply the Custom Filter to these additional categories to help locate specific Outages in the database.
783SCR-10Board Report 021015Page 1 of 11
PUBLIC