Change Request System in
CROW Outage Scheduler
Midwest ISO
Session Goal
Clarify requirements and expectations in
CROW’s Change Request System
2
Introduction
Review of the Change Request System
– The three types of Change Requests
– Who does what with a Change Request
– Best practices
3
CROW Change Request System
The system within CROW that “documents” any
change requested for an outage
– Who requested the change
– When the change was requested
– Why the change was necessary
4
CHANGE REQUEST TYPES
Three Types of Change Requests
•
Request Change – use prior to the
Implementation Status
•
Request Schedule Change – use during
the Implementation Status
•
Cancel Request – use to cancel an outage
request once the request is beyond the
Submitted Status and prior to
implementation
6
Request Change
CROW allows TOs and GOs to submit a
Request Change Prior to Implementation Status
in one of these states:
• Submit
• Study
• Pre-approved
• Approved (if not previously implemented)
7
Request Change
Only the Planned Start date/time has a restriction:
• Planned Start date/time can be modified if the
outage submission rules allow the submission of a
new outage request
• Planned End date/time, equipment, notes, etc., can
all be modified
Note: Cannot submit a Change Request to change only the
comment field in an Outage Request (should be removed with
next crow release)
8
Request Schedule Change
Use during the Implementation Status
• Modify Planned End date/time only
• Two types are available
• Non-Forced - schedule change is a request;
subject to Midwest ISO approval
• Forced - Schedule change is unavoidable under
given circumstances and is acknowledged by
Midwest ISO
9
Request Cancel
Use to cancel…
•
Entire request or a single period of an outage
request
and
• is beyond the Submitted Status and prior to
the Implemented Status
NOTE: Request Cancel requests must be acknowledged by Midwest
ISO before the outage changes to the canceled status
10
Recap
• Three types of Change Requests: Request Change,
Request Schedule Change, and Cancel Request
• Submit Request Change allowed prior to
Implementation status: Submit, Study, PreApproved, and Approved (if not implemented)
• Request Schedule Change: during Implementation
status
• Request Cancel: Beyond Submitted and prior to
Implemented
11
RESPONSIBILITIES WITHIN CROW CHANGE REQUEST Change Request Responsibilities
Who submits change requests?
– Primary
• the TO/GO should submit the change requests
– Secondary
• submitted by Midwest ISO on requestor’s behalf when
necessary
NOTE: Change Request System TO/GO capabilities limited based on
outage request Priority and type of changes desired
13
Change Request Responsibilities
Who at the Midwest ISO monitors change
requests?
• The role responsible for the outage request in the time
frame when the change request is submitted is
responsible for monitoring and dispensing of the change
request
• This is the same as outage study/approve responsibility
time frame
14
Who Monitors Change Requests?
Role
Monitors For…
ROE
CRs on outages in progress or planned to start
same day and into next day
TSP
CRs on outages starting the next day or
weekends
OCE
CRs on outage starting next business day
forward
Role Definitions
ROE – Regional Operations Engineer
TSP – Transmission Security Planning Engineer
OC – Outage Coordination Engineer
15
Response to Change Requests…
Change Requests submitted for an outage two or
more business days in advance of the start date…
– Midwest ISO treats these in the same manner as a new outage
request
– Midwest ISO cannot guarantee automatic acceptance since a
reliability assessment/study must be conducted prior to
accepting any change request
– Midwest ISO will respond as soon as practical, and within the
time period allowed for study of a new outage request
– Under extenuating circumstances, the GOP/TOP may
contact/call the Outage Coordination Engineer and request
expedited processing of the change request
16
Response to Change Requests…
Change Requests submitted for an outage day
prior to the planned start date…
– Midwest ISO cannot guarantee automatic acceptance since a
reliability assessment/study must be conducted prior to
accepting any change request
– Midwest ISO will respond as soon as practical, normally within
12 hours or midnight day prior (whichever comes first)
– Under extenuating circumstances, the GOP/TOP may
contact/call the TSP Engineer and request expedited processing
of the change request
17
Response to Change Requests…
Change Requests submitted for an outage
applicable same day…
– Midwest ISO cannot guarantee automatic acceptance since a
reliability assessment/study must be conducted prior to
accepting any change request
– Midwest ISO will respond as soon as practical, normally within 4
hours
– Under extenuating circumstances, the GOP/TOP may
contact/call the Regional Operations Engineer and request
expedited processing of the change request
18
Recap
• TO/GO submits Change Requests, with Midwest
ISO submitting on requestor’s behalf when
necessary
• The role responsible for the outage request in the
time frame when the change request is submitted is
responsible for monitoring and dispensing of the
change request
19
BEST PRACTICES
Best Practices for TO & GO Customers
• Outage Operations at Midwest ISO are handled by
different teams depending on the time frame
– using a change request versus a new outage submission
is determined by understanding the Midwest ISO time
frames
• If the original outage schedule will not proceed if a
change request is denied, consider canceling and
submitting a new request
•
A Change Request is best used for incremental
changes
21
Best Practices – Improper Use
• Request Change to modify the Priority of a planned
outage, specifically to move to Emergency or Forced
– Submit a new forced outage request and implement, follow
up with a cancel request for the planned outage
• Modify the Derate level of an implemented outage
– Complete the current outage in progress and submit a new
outage and implement for 1 minute after the previous
completion time
Note: the Midwest ISO is currently working to provide changes to
better handle Derate outages
22
Best Practices – New Outage Request
? My change request was Denied and I was asked to
submit a new outage request…
When a Midwest ISO engineer/operator cannot respond to the
change request (i.e. perform the necessary evaluation) in the
time available and required for a response:
– Outages must be canceled in order to prevent impact
• in the day-ahead and FRAC markets
• in next day security assessments
– TO/GO must submit a new outage request
• Planned if appropriate otherwise as an Opportunity
NOTE: Midwest ISO engineer can submit an Opportunity outage
for the TO, if within 24 hours
23
Best Practices
? Should I submit a change request or new outage
request?
If the Midwest ISO team responsible for study and approval
of the outage timeframe is the same as the new change
timeframe: a change request may be used
– Example: ROE is monitoring outage to start today
• One hour prior to the planned start of the outage a change
request comes in to reschedule the outage out 1 week
• Change request will likely be denied, it is not within the
ROE study horizon
NOTE: Outage Coordination will study/approve an outage in this time
frame
24
Best Practices
Outages Pending Implementation
– when planned start of the original request is
greater than 2 business days out submit a
Change Request
– Exception - advancing the Planned Start into
Real-Time, then contact the Operations
Engineer desk
25
Best Practices
When planned start date is the same day, next
day, or over the weekend…
– Use a Change Request* when Delay the planned start
out one day or within the previous approved outage
window
– Cancel the original request and submit a new outage
request when Delay the start of the outage by several
days or outside the previously approved outage
window (this is not within the ROE and TSP study horizon)
*May need to contact Operations Desk for assistance submitting the
change request depending on outage Category and Priority
26
Recap
• A Change Request is best used for incremental
changes
• Improper use: 1. modify the Priority of a planned
outage to Emergency or Forced and 2. modify the
Derate level of an implemented outage
• If the Midwest ISO team responsible for study and
approval of the outage timeframe is the same as the
new change timeframe: a Change Request may be
used
27
Transmission & Generation Outage
Submission Timeline
REFERENCE
Transmission Submittal Timelines
Outage Class Reference Table
Outage Class Submittal Timeline
Class I
at least 14 Calendar Days in advance of
the planned start date
Class II
at least 7 Calendar Days in advance of
the planned start date
Class III
at least 48 hours in advance of the
planned start date
Class V
by 1400 hours EST the day prior to the
outage
29
Transmission Outage
Submission Time Requirements
Priority
E.R.T.
Fac. Class
Lead Time Reqd.
Planned
OOS,ISNO
Class I
> 14 days
OOS, ISNO
Class II
> 7 days
OOS, ISNO
Class III
> 24 hours
GSP
All
> 48 hours
HLW, INFO
All
> 24 hours
OOS,ISNO
Class I
24 hours to 14 days
OOS, ISNO
Class II
24 hours to 7 days
OOS, ISNO
Class III
> 24 hours
HLW, GSP, INFO
All
> 24 hours
Discretionary
All
All
> 24 hours
Urgent
All
Class I
24 hours to 14 days
All
Class II
24 hours to 7 days
Emergency
All
All
< 24 hours
Forced
All
All
< Present System Time
Opportunity
30
Generation Outage
Submission Time Requirements
Priority
E.R.T.
Fac. Class
Lead Time Reqd.
Planned
OOS
All
> 48 hours
Derate To,
ECON
All
> Present System
Time
All
All
24 hours to 7 days
Emergency All
All
< 24 hours
Forced
All
< Present System
Time
Urgent
All
31
QUESTIONS ?
Thank you!
jbrown@midwestiso.org
32